una introduccion a cmmi

Upload: hermes-salazar

Post on 18-Oct-2015

15 views

Category:

Documents


0 download

TRANSCRIPT

  • White Paper 2006 Una Introduccin a CMMI

    Whi

    te P

    aper

    200

    6

  • Contenidos

    INTRODUCCIN............................................................................................................................. 4 NIVELES DE MADUREZ Y REAS DE PROCESO..............................................................................................4 UN MODELO DE REFERENCIA NO ES LA DESCRIPCIN DE UN PROCESO .................................................................7

    PROCESOS ESTADSTICAMENTE CONTROLADOS............................................................................ 7 ESTABILIDAD DEL PROCESO...................................................................................................................9

    LOS CINCO NIVELES DE MADUREZ............................................................................................... 11

    ARQUITECTURA DEL MODELO ...................................................................................................... 12 OBJETIVOS Y PRCTICAS GENRICAS .....................................................................................................12 OBJETIVOS Y PRCTICAS ESPECFICAS ....................................................................................................13 DISCIPLINAS ..................................................................................................................................13

    REAS DE PROCESO DE NIVEL 2 .................................................................................................. 15 ADMINISTRACIN DE REQUERIMIENTOS (REQM).......................................................................................15 PLANIFICACIN DEL PROYECTO (PP)......................................................................................................17 MONITOREO Y CONTROL DEL PROYECTO (PMC).........................................................................................18 MEDICIN Y ANLISIS (MA) ...............................................................................................................19 ASEGURAMIENTO DE LA CALIDAD DE PRODUCTOS Y PROCESOS (PPQA)............................................................19 ADMINISTRACIN DE LA CONFIGURACIN (CM) ........................................................................................21 ADMINISTRACIN DE ACUERDOS CON PROVEEDORES (SAM).........................................................................22

    REAS DE PROCESO DE NIVEL 3 .................................................................................................. 24 DESARROLLO DE REQUERIMIENTOS (RD) ................................................................................................24 SOLUCIN TCNICA (TS)...................................................................................................................25 INTEGRACIN DEL PRODUCTO (PI)........................................................................................................26 VERIFICACIN (VE) .........................................................................................................................26 VALIDACIN (VA) ...........................................................................................................................29 ENFOQUE ORGANIZACIONAL EN EL PROCESO (OPF) ...................................................................................29 DEFINICIN ORGANIZACIONAL DEL PROCESO (OPD) ..................................................................................31 ENTRENAMIENTO ORGANIZACIONAL (OT)................................................................................................32 GESTIN DEL RIESGO (RSKM)............................................................................................................33 ANLISIS Y TOMA DE DECISIONES (DAR) ...............................................................................................34 ADMINISTRACIN INTEGRADA DEL PROYECTO (IPM)...................................................................................35 GESTIN INTEGRADA DE PROVEEDORES (SS) (ISM)..................................................................................36 AMBIENTE ORGANIZACIONAL PARA LA INTEGRACIN (IPPD) (OEI).................................................................37 EQUIPO INTEGRADO (IPPD) (IT) .........................................................................................................38

    REAS DE PROCESO DE NIVEL 4 .................................................................................................. 39 DESEMPEO DEL PROCESO DE LA ORGANIZACIN (OPP) .............................................................................39 ADMINISTRACIN CUANTITATIVA DE PROYECTOS (QPM)..............................................................................40

    REAS DE PROCESO DE NIVEL 5 .................................................................................................. 42 INNOVACIN ORGANIZACIONAL Y DESPLIEGUE (OID)..................................................................................42 ANLISIS Y RESOLUCIN DE CAUSAS DE DEFECTOS/PROBLEMAS (CAR).............................................................43

    DEFINIENDO LOS PROCESOS DE LA ORGANIZACIN................................................................... 45

    1

  • OTROS ESTNDARES Y MODELOS DE REFERENCIA ...................................................................... 46 ISO 9001:2000............................................................................................................................46 COBIT .........................................................................................................................................47 ITIL ............................................................................................................................................48 ESCM..........................................................................................................................................49 INTEGRANDO LOS MODELOS ................................................................................................................51

    CONCLUSIONES ........................................................................................................................... 52

    GLOSARIO ................................................................................................................................... 54

    REFERENCIAS .............................................................................................................................. 55

    2

  • Figuras y Tablas

    Fig. 1: Niveles de Madurez..................................................................................................................5 Fig. 2: reas de Proceso por Nivel de Madurez ......................................................................................6 Fig. 3: reas de Proceso por Categora .................................................................................................7 Fig. 4: Un ejemplo de grfico de control ...............................................................................................8 Fig. 5: Variacin debida a causas comunes .........................................................................................10 Fig. 6: Variacin debida a causas especiales........................................................................................10 Fig. 7: Estructura de la representacin por niveles...............................................................................13 Fig. 8: Tcnica de inspeccin.............................................................................................................28 Fig. 9: Un diagrama de Pareto...........................................................................................................44 Fig. 10: Un diagrama de causa-efecto o de Ishikawa............................................................................45 Fig. 11: Relacin entre CMMI e ISO 9001:2000 ...................................................................................47 Fig. 12 Dominios y procesos de CobIT ................................................................................................48 Fig. 13: Procesos de ITIL ..................................................................................................................49 Fig. 14: Fases y reas de capacidad de eSCM......................................................................................50

    Tabla 1: Comparacin entre CMMI, ISO 9001, CobIT, ITIL y eSCM.........................................................51

    3

  • Introduccin El Capability Maturity Model Integration (CMMISMi de aqu en adelante)1 es un marco de referencia que las organizaciones pueden emplear para mejorar sus procesos de desarrollo, adquisicin, y mantenimiento de productos y servicios. Nacido en el Software Engineering Institute perteneciente a la Carnegie Mellon University, CMMI es la nueva generacin de una lnea de modelos de madurez que se inici a principios de los noventa con el famoso CMM-SW (Capability Maturity Model for Software Engineering)2, ,3 ii

    Basados en los principios de la calidad total (TQM) popularizados por autores como Crosby, Deming y Juran, estos modelos proponen un conjunto de prcticas que las organizaciones pueden adoptar para implantar procesos productivos ms efectivos. Son llamados modelos de madurez porque proponen adoptar dichas prcticas en forma gradual: primero deben ponerse en prctica reas de proceso pertenecientes a un nivel determinado, para luego, sobre esta base, introducir las correspondientes al nivel siguiente.

    Niveles de Madurez y reas de Proceso Al igual que los restantes modelos de la familia, CMMI plantea que las organizaciones pueden ubicarse en alguno de cinco posibles niveles de madurez, dependiendo del grado de sofisticacin de sus procesos (ver Fig. 1) A su vez, cada nivel de madurez -con excepcin del inicial- queda caracterizado por un conjunto de reas de proceso que agrupan prcticas que, al ser ejecutadas colectivamente, permiten cumplir con algn objetivo que es considerado importante para el modelo.

    i CMMI es servicio registrado de Carnegie Mellon University.

    ii Otros modelos de madurez son: SA-CMM (Software acquisition), P-CMM (People CMM), SE-CMM (Systems Engineering).

    4

  • Fig. 1: Niveles de Madurez

    Como puede apreciarse en la Fig. 2, antes de introducir prcticas de un nivel determinado deben estabilizarse las prcticas del nivel anterior. Es as que, por ejemplo, antes de introducir el rea de proceso RSKM-Administracin de Riesgos (perteneciente al nivel 3 definido) deben estabilizarse las relacionadas con la gestin del proyecto (PP-Planificacin del Proyecto y PMC-Monitoreo y Control del Proyecto, pertenecientes al nivel 2 administrado).

    5

  • Fig. 2: reas de Proceso por Nivel de Madureziii

    Adems de poder ver las reas de proceso por nivel de madurez, el modelo propone una vista alternativa (llamada continua) en donde las reas estn agrupadas por categora (ver Fig. 3) Esta es una diferencia sustancial respecto a los modelos anteriores, que slo permitan una vista u otra (Por ejemplo, CMM-SW propona una vista por niveles de madurez, mientras que el CMMI-SE lo haca por categoras).

    iii Para facilitar la referencia al modelo, hemos dejado en el grfico las reas de proceso con sus iniciales y nombres en ingls.

    6

  • Fig. 3: reas de Proceso por Categora

    Un modelo de referencia no es la descripcin de un proceso Llegados a este punto, es importante hacer una aclaracin: CMMI, como su nombre lo indica, es un modelo que propone un conjunto de best practices que pueden emplearse para evaluar y mejorar procesos; de ninguna manera debe suponerse que estamos ante la descripcin de un proceso. Ser nuestro trabajo definir el proceso productivo de nuestra organizacin que seguramente tendr una estructura completamente diferente a la de CMMI- de manera tal que cumpla con los atributos y mejores prcticas propuestos por el modelo.

    Procesos Estadsticamente Controlados Uno de los principios fundamentales de la calidad total sobre los cuales est basado este modelo- es el de control estadstico de procesos. Segn l, la variabilidad de un proceso puede ser controlada y, por consiguiente, sus resultados pueden ser

    7

  • predecibles4. Que los resultados de un proceso sean predecibles no quiere decir que sean idnticos, sino que estos variarn dentro de lmites conocidos.

    Veamos un ejemplo tomado de Practical Software Measurement. Un grupo de trabajo es responsable del desarrollo de una nueva versin de una aplicacin, mientras que al mismo tiempo debe dar soporte a los usuarios de la vieja versin. El proyecto ha sido planificado bajo el supuesto de que seran necesarias 40 horas-hombre diarias de soporte.

    Luego de finalizado el proyecto, y con la informacin de la cantidad real de horas incurridas diariamente en actividades de soporte, se realiza el siguiente grafo de control (ver Fig. 4), en el que podemos observar su evolucin a lo largo de las diecisis semanas del periodo.

    Fig. 4: Un ejemplo de grfico de control

    No es nuestro propsito en adentrarnos en el detalle de cmo construir este tipo de grficos; por el momento diremos que, luego de realizado el anlisis, podemos afirmar que el esfuerzo aplicado a actividades de soporte durante las diecisis semanas que dur el proyecto estuvo en torno a las 45.03 horas-hombre por da (la lnea punteada identificada en el grfico como CL=45.03). Mediante un clculo que forma parte de esta tcnica podemos, adems, determinar los lmites inferior y superior del proceso (LCL=40.66 y UCL=49.41, respectivamente), los que corresponden a +/- 3 desviaciones estndariv.

    Para determinar si el proceso se encuentra estadsticamente controlado debemos

    iv La desviacin estndar (sigma) es la dispersin de una distribucin normal. Por regla sabemos que el 99.74% de superficie por debajo de la curva normal debera estar dentro de +/- 3 veces sigma.

    8

  • verificar si en el grfico se cumplen o no una serie de reglas. Para ello ser necesario identificar tres zonas en el grfico, llamadas A, B y C. Cada una de las zonas representa, respectivamente, la distancia entre la media y +/- una, dos y tres desviaciones estndar (o sea, deberamos dividir en tres zonas iguales la distancia entre la media y los lmites inferior y superior) Un proceso estar fuera de control si se cumple alguna o varias de las siguientes reglas:

    Dos de tres puntos consecutivos estn en la zona C Cuatro de cinco puntos consecutivos al mismo lado de la lnea central en las zonas

    B y C.

    Nueve puntos consecutivos estn por encima o por debajo del promedio. Hay seis puntos consecutivos crecientes o decrecientes. Hay catorce puntos consecutivos alternndose arriba y abajo del promedio. Hay quince puntos consecutivos dentro de la zona A. De acuerdo a lo que podemos observar, el grfico de la Fig. 4 no cumple con ninguna de estas reglas, con lo cual estamos en condiciones de afirmar que se encuentra estadsticamente controlado. En otras palabras, la estimacin de 40 horas-hombre fue ms que aceptable.

    Estabilidad del proceso Las caractersticas de todos los procesos y productos presentan algn tipo de variacin cuando las medimos a lo largo del tiempo. Dicha variacin puede tener dos fuentes: la misma naturaleza del proceso (la variacin normal o natural del proceso, relacionada con la interaccin entre sus distintos componentes personal, maquinaria, materiales, mtodos y ambiente-) por un lado, y las causas relacionadas con alguna causa especfica por el otro (las variaciones especiales).v

    La variacin normal del proceso (llamada causa comn de variacin) tiene un comportamiento al azar, pero con un patrn estable y dentro de ciertos lmites (ver Fig. 5 [reproducida de Practical Software Measurement]) Si un proceso presenta nicamente este tipo de variacin estaremos ante un proceso estadsticamente controlado.

    v Ver la seccin Glosario para una definicin formal de causas especiales y comunes.

    9

  • Fig. 5: Variacin debida a causas comunes

    La variacin especial, por el contrario, no tiene un patrn de comportamiento que pueda ser identificado (ver Fig. 6, reproducida de la misma obra) El impacto de este tipo de variaciones en la performance del proceso y en las caractersticas del producto son importantsimos, a tal punto que es imposible predecir los resultados.

    Fig. 6: Variacin debida a causas especiales

    Las variaciones especiales no tienen su origen en el proceso, sino en causas externas tales como el medio ambiente, el material de input al proceso, personal no capacitado, mtodos o herramientas incorrectamente usados, etc.

    Una vez que las variaciones originadas en causas especiales sean removidas, nos encontraremos con un proceso estable (estadsticamente controlado) Una vez alcanzado este estado, podremos optimizar el proceso, reduciendo la variabilidad o corriendo la media.

    Como veremos en las prximas secciones, las organizaciones de nivel de madurez 5 de CMMI se esfuerzan en remover las causas comunes, mientras que las de nivel 4 se enfocan en remover las especiales.

    10

  • Los Cinco Niveles de Madurez En general, los niveles de madurez suelen explicarse en orden creciente; tomaremos aqu una direccin distinta y los explicaremos exactamente al revs: desde el nivel cinco al nivel uno.

    Imaginmonos por un momento que estamos en una organizacin de nivel cinco. En este tipo de organizaciones, como dijimos en la seccin anterior, los procesos son analizados para eliminar las causas comunes de variacin, o sea, aquellas que tienen que ver con la misma naturaleza del proceso, no atribuibles a causas externas. Las variaciones en las salidas de los procesos son al azar, pero se encuentran controladas estadsticamente (podemos predecir los resultados de los procesos con cierto nivel de confiabilidad)

    Para poder haber arribado a este nivel, la organizacin debera primero haber eliminado las causas especiales de variacin, aquellas que tienen que ver con causas externas, como por ejemplo falta de entrenamiento del personal, problemas con las herramientas, etc. Este tipo de causas no son aleatorias: Si examinramos los resultados podramos ver las tendencias que claramente nos indicaran que las variaciones tienen un origen concreto. En una organizacin de nivel cuatro, entonces, las causas especiales de variacin son identificadas y eliminadas.

    Para poder llegar a identificar causas de variacin necesitamos tener un proceso estndar: difcil sera poner bajo control estadstico un proceso que no se encuentre mnimamente formalizado.

    As llegamos al nivel tres, en el cual los proyectos emplean un proceso productivo adaptado del proceso estndar de la organizacin. Las actividades tcnicas y de gestin son realizadas de acuerdo a polticas, procesos y procedimientos formalizados en algn tipo de estndar organizacional profundamente arraigado en la cultura. La gente est entrenada y dispone de recursos para poder hacer su trabajo. Tambin hay una infraestructura bsica (personal, herramientas, etc.) para definir y mejorar el proceso productivo.

    Pero para poder arribar a semejante situacin es necesario pasar por una etapa previa: difcilmente podamos introducir en una organizacin prcticas estndar relacionadas con la ingeniera del producto (anlisis, diseo, etc.) si no ofrecemos un contexto en donde ellas puedan ser correctamente ejecutadas. Ese es el foco del nivel dos: poner en orden las prcticas relacionadas con el manejo elemental de los proyectos.

    En el nivel dos, los proyectos de la organizacin siguen algn tipo de proceso para realizar las actividades relacionadas con la gestin del proyecto (planificacin, control), para administrar los requerimientos y las configuraciones, y para medir y analizar la calidad de los productos y el desempeo de los procesos. Tambin hay prcticas de aseguramiento de la calidad que permiten garantizar que cada proyecto sigue sus propios estndares.

    11

  • En el nivel dos no importan tanto las tcnicas y los mtodos que empleemos para desarrollar y construir nuestros productos y servicios: Lo importante es que podamos tener un mnimo de capacidad de gestin de proyectos.

    Y as llegamos al nivel uno: La situacin aqu es catica. No tenemos procesos (no al menos en el sentido del modelo) y la performance de los proyectos depende profundamente de la buena voluntad y la capacidad de la gente.

    Arquitectura del Modelo En la representacin por niveles (ver Fig. 7), cada nivel de madurez contiene varias reas de proceso, las que a su vez quedan definidas por uno o varios objetivos especficos y un objetivo genrico. Cada uno de ellos tiene vinculado un conjunto de prcticas, llamadas especficas y genricas respectivamente.

    Objetivos y Prcticas Genricas Los objetivos y prcticas genricas tienen que ver con el grado de institucionalizacin de los procesos (compromiso con la ejecucin, capacidad para ejecutar, direccin de la ejecucin, verificacin de la ejecucin) Son llamados as porque son los mismos en todas las reas de proceso (aunque hay aspectos especficos para cada una de ellas). Cumplir con un objetivo genrico de un rea de proceso determinada implica tener un mayor control de la planificacin e implementacin de los procesos vinculados a esa rea de proceso. En el nivel 2, el objetivo (GG) y las prcticas genricas (GP) son los siguientes:

    GG 2 Institucionalizar un proceso administrado > GP 2.1 Establecer polticas organizacionales > GP 2.2 Planificar el proceso > GP 2.3 Proveer Recursos > GP 2.4 Asignar responsabilidades > GP 2.5 Entrenar al personal > GP 2.6 Administrar la configuracin > GP 2.7 Identificar e involucrar a los interesados > GP 2.8 Monitorear y controlar los procesos > GP 2.9 Evaluar adhesin objetivamente > GP 2.10 Revisar el estado con la alta gerencia

    En los niveles 3, 4 y 5, a los anteriores se agregan los siguientes:

    GG 3 Institucionalizar un proceso definido > GP 3.1 Establecer un proceso definido > GP 3.2 Recolectar informacin para mejoras

    12

  • Fig. 7: Estructura de la representacin por niveles

    Objetivos y prcticas especficas Los objetivos y prcticas especficas estn vinculados a un rea de proceso determinada. Son considerados elementos que deben ser satisfechos para implementar exitosamente los procesos relacionados con un rea de proceso en particular. Por ejemplo, en el rea Administracin de Requerimientos (REQM), los objetivos y prcticas son las siguientes:

    Objetivo Especfico Prcticas Especficas

    SG 1 Administrar Requerimientos

    Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto.

    SP 1.1 Comprender el significado de los requerimientos

    SP 1.2 Obtener compromiso de los participantes/interesados acerca de los requerimientos

    SP 1.3 Administrar cambios a los requerimientos

    SP 1.4 Mantener la trazabilidad bidireccional de los requerimientos

    SP 1.5 Identificar inconsistencias entre los requerimientos y otros productos del proyecto

    Disciplinas El modelo incluye cuatro cuerpos de conocimiento distintos: ingeniera de software, ingeniera de sistemas, desarrollo integrado de productos y procesos, y adquisicin de

    13

  • productos. Si bien el modelo es esencialmente el mismo para las cuatro disciplinas, en algunas de ellas se agregan reas de proceso o prcticas puntuales. Tambin pueden aparecer comentarios particulares que clarifican su aplicacin en el contexto de alguna de las cuatro disciplinas (amplificaciones)

    Las disciplinas de ingeniera de software e ingeniera de sistemas (SW y SE son sus siglas en ingls) no merecen mayor aclaracin (en cierta manera, cubren el alcance del SW-CMM y de SE-CMM, respectivamente); la recomendacin que da el modelo es que se use la segunda, ya que toda pieza de software forma parte de un sistema mayor.

    Adquisicin de productos (SS, por supplier sourcing) es un cuerpo de conocimiento que debe ser aplicado siempre que el proyecto dependa de actividades crticas que deban realizar proveedores. El modelo agrega un rea especfica para esta disciplina, Gestin Integrada de Proveedores (ISM).

    Por ltimo, desarrollo integrado de productos y procesos (IPPD, por su denominacin en ingls) es una disciplina aplicable en aquellas situaciones en donde sea necesario desarrollar, en forma concurrente, no slo el producto sino tambin los procesos a emplear para disearlo, construirlo y mantenerlo (incluyendo el soporte a los usuarios). Se agregan dos reas de proceso especficas, Equipo Integrado (IT) y Ambiente Organizacional para la Integracin (OEI). IPPD debe ser usada junto a alguna de las otras disciplinas disponibles.vi

    vi Para mayor informacin respecto a IPPD puede consultarse http://www.npd-solutions.com/ippdtenets.html

    14

  • reas de Proceso de Nivel 2 En una organizacin que haya alcanzado este nivel de madurez encontraremos que hay una disciplina para la gestin de proyectos que se mantiene an en periodos de estrs. Los recursos estarn capacitados para hacer su trabajo, y habr polticas organizacionales formalmente establecidas, cuyo cumplimiento ser monitoreado. Habr visibilidad de las actividades realizadas, y los proyectos se ejecutarn siguiendo un plan y de acuerdo a un proceso formalmente establecido.

    Si bien el establecimiento de estndares organizacionales recin es contemplado en el siguiente nivel, aqu nos encontraremos con procesos definidos en el contexto de cada proyecto. Por supuesto que pueden definirse procesos ms o menos generales (que puedan ser usados por ms de un proyecto), pero el modelo no lo prescribe por la sencilla razn de que primero es necesario poner orden dentro de cada proyecto para luego ordenar el resto de la organizacin (el foco de nivel 3).

    Las reas de proceso del nivel 2 son siete en total, las cuales describimos rpidamente en las prximas secciones.

    Administracin de Requerimientos (REQM) Esta rea de proceso tiene como propsito mantener bajo control los requerimientos que el producto a desarrollar deber satisfacer. Las prcticas incluidas aqu apuntan a que los requerimientos no solo estn claramente identificados, sino tambin que todos los involucrados en el proyecto (el cliente, el equipo de proyecto, etc.) estn de acuerdo en su significado. Adicionalmente, los requerimientos deben ser la entrada a las actividades de planificacin (ver Planificacin del Proyecto (PP)) y a las tcnicas incluidas en nivel 3.

    Un tema fundamental planteado en esta rea de proceso es que cualquier cambio realizado a los requerimientos se efecte de manera controlada (por ejemplo, solamente un grupo reducido de personas debera proponer cambios) y que el resto de los artefactos del proyecto (planes, especificaciones, diseo, etc.) se mantengan consistentes.

    Otro aspecto importante incluido en esta rea es el de trazabilidad bidireccional. Cuando los requerimientos son correctamente administrados deberamos estar en condiciones de relacionar cul ha sido el origen de los requerimientos, cul es la relacin entre los requerimientos de bajo nivel y los de alto nivel (por ejemplo, cules son derivados y de cul requerimiento), cules son los artefactos relacionados con los requerimientos (por ejemplo, especificaciones, documentos de diseo o planes), y cules componentes del producto implementan cada requerimiento. Esta prctica es sumamente importante para poder realizar un buen anlisis de impacto ante posibles cambios, y fundamental para poder determinar si el alcance del proyecto ha sido cubierto o no (han sido satisfechos todos los requerimientos?).

    En esta rea hay solamente un objetivo especfico SG 1 Administrar Requerimientos-y

    15

  • cinco prcticas:

    Objetivo Especfico Prcticas Especficas

    SG 1 Administrar Requerimientos

    Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto.

    SP 1.1 Comprender el significado de los requerimientos

    SP 1.2 Obtener compromiso de los participantes/interesados acerca de los requerimientos

    SP 1.3 Administrar cambios a los requerimientos

    SP 1.4 Mantener la trazabilidad bidireccional de los requerimientos

    SP 1.5 Identificar inconsistencias entre los requerimientos y otros productos del proyecto

    Desde el punto de vista prctico, el rea de proceso se satisface poniendo en marcha algn tipo de mecanismo o sistema que:

    Identifique quienes son las fuentes oficiales de requerimientos;

    Identifique cules son los canales vlidos para ingresar requerimientos al proyecto;

    Controle los cambios (no cualquiera estara en condiciones de generar un cambio a un requerimiento);

    Permita determinar si todos los involucrados tienen la misma visin respecto al significado de los requerimientos (por ejemplo, mediante la aprobacin de algn tipo de documento formal);

    Mantenga la trazabilidad entre los requerimientos y otros artefactos (incluyendo al producto y sus componentes)

    Si bien a esta altura no es necesario definir ninguna tcnica de especificacin en particular (tema atacado recin en el nivel 3), lo ms usual es que se avance en esa direccin para poder tener efectivamente requerimientos para administrar.

    Vale aclarar que para este modelo, los requerimientos se clasifican en tres categoras: los del usuario (aquellos que formula el usuario y que, por ejemplo, pueden ser documentados en una minuta de reunin), los del producto (derivados a partir de los primeros; generalmente descriptos en un lenguaje ms cercano al equipo de proyecto), y los de las componentes del producto (derivados de los anteriores)

    En algunas organizaciones los usuarios suelen volcar sus necesidades en algn tipo de herramienta (por ejemplo, en un workflow), las que posteriormente sern elaboradas por el equipo de proyecto y formalizadas en algn tipo de documento con un nivel de detalle suficiente para poder conducir las actividades tcnicas y de gestin (por ejemplo, una Visin o un Acuerdo de Proyecto)

    16

  • Planificacin del Proyecto (PP) Esta rea de proceso tiene como propsito establecer y mantener el plan que ser empleado para ejecutar y monitorear el proyecto. El plan se desarrolla sobre la base de los requerimientos administrados por el rea REQM (ver seccin anterior)

    Dentro de esta rea de proceso se incluyen todas las actividades necesarias para determinar el alcance del proyecto (funcionalidad a desarrollar, actividades incluidas y excluidas, etc.), estimar esfuerzo y costos, establecer el cronograma, identificar riesgos, y obtener el compromiso de todos los involucrados respecto al plan de proyecto. Sus objetivos y prcticas especficas son las siguientes:

    Objetivos Especficos Prcticas Especficas

    SG 1 Establecer estimaciones Se realizan y mantienen estimaciones de las magnitudes del proyecto.

    SP 1.1 Estimar el alcance del proyecto

    SP 1.2 Estimar atributos de las tareas y de los productos del proyecto

    SP 1.3 Definir el ciclo de vida del proyecto

    SP 1.4 Estimar esfuerzo y costo del proyecto

    SG 2 Desarrollar el plan de proyecto Se establece y mantiene un plan de proyecto que es empleado para administrar el proyecto.

    SP 2.1 Establecer el cronograma y el presupuesto del proyecto

    SP 2.2 Identificar los riesgos del proyecto

    SP 2.3 Planificar la administracin de datos del proyecto

    SP 2.4 Planificar recursos necesarios para el proyecto

    SP 2.5 Planificar la adquisicin de conocimiento y habilidades

    SP 2.6 Planificar la participacin de los interesados en el proyecto

    SP 2.7 Establecer el plan del proyecto

    SG 3 Obtener el compromiso de los interesados acerca del plan de proyecto Los compromisos con el plan estn formalmente establecidos y son mantenidos a lo largo del proyecto.

    SP 3.1 Revisar todos los planes que puedan afectar al proyecto

    SP 3.2 Ajustar el plan de proyecto para reflejar recursos estimados vs. disponibles

    SP 3.3 Obtener compromisos respecto al plan

    Las actividades de esta rea suelen implementarse mediante la combinacin de varios elementos. Por un lado, ser necesario establecer algn tipo de mecanismo de estimacin que emplee como input los requerimientos del proyecto. Tambin ser necesario formalizar el plan de proyecto (que no es solamente el cronograma), el ciclo de vida a emplear (por lo menos, fases e hitos), y los mecanismos de aprobacin.

    Si bien no est explcitamente indicado en el modelo, el establecimiento de una funcin tipo PMO (Project Management Office) podra actuar como facilitador de la implementacin de esta rea de proceso y de la siguiente (Monitoreo y Control del

    17

  • Proyecto (PMC))

    Monitoreo y Control del Proyecto (PMC) No tiene sentido formular planes para algo que no se tiene intenciones de gestionar. Esta rea de proceso es complementaria y una consecuencia- de Planificacin del Proyecto (PP): su propsito es monitorear la ejecucin del proyecto empleando para ello el plan- y gestionar acciones correctivas en el caso de detectarse desvos.

    Objetivos Especficos Prcticas Especficas

    SG 1 Monitorear el Proyecto El avance y la performance del proyecto se monitorean respecto a lo establecido en el plan de proyecto.

    SP 1.1 Monitorear los parmetros de planificacin del proyecto

    SP 1.2 Monitorear los compromisos

    SP 1.3 Monitorear los riesgos del proyecto

    SP 1.4 Monitorear la administracin de datos del proyecto

    SP 1.5 Monitorear la participacin de los interesados

    SP 1.6 Conducir revisiones de avance

    SP 1.7 Conducir revisiones de cumplimiento de hitos

    SG 2 Gestionar Acciones Correctivas Cuando los resultados o la performance del proyecto se desvian significativamente del plan se gestionan acciones correctivas.

    SP 2.1 Analizar temas pendientes

    SP 2.2 Ejecutar acciones correctivas

    SP 2.3 Administrar acciones correctivas

    Para poder cumplir con estos objetivos ser necesario implementar prcticas de seguimiento, tales como el reporte de horas trabajadas en el proyecto, el informe de avance peridico, revisiones en puntos particulares del proyecto (por ejemplo, al final de cada fase), etc. Si bien esto suena sencillo, conseguir cambiar la cultura (que en general favorece la no-visibilidad de los proyectos) es una tarea dursima.

    La PMO (Project Management Office) tambin puede jugar un papel importante aqu, realizando el seguimiento a alto nivel- de los proyectos en ejecucin, y generando los indicadores correspondientes (ver Medicin y Anlisis (MA)).

    Por supuesto que, al igual que el rea de proceso anterior, es imprescindible identificar personas dentro de la organizacin que puedan cubrir el rol de lder o gerente de proyecto. Esto puede sonar redundante, pero es bastante habitual encontrar organizaciones que ni siquiera reconocen la existencia del rol.

    18

  • Medicin y Anlisis (MA) Una premisa presente en todos los movimientos de calidad es que lo que no puede medirse no puede mejorarse. Esta rea de proceso apunta, justamente, a desarrollar y mantener capacidades de medicin que permitan satisfacer las necesidades de informacin de la organizacin. Sus objetivos y prcticas son las siguientes:

    Objetivos Especficos Prcticas Especficas

    SG 1 Alinear actividades de medicin y anlisis Las actividades de medicin y anlisis estn alineadas con los objetivos y necesidades de informacin.

    SP 1.1 Establecer objetivos de las mediciones

    SP 1.2 Especificar mtricas

    SP 1.3 Especificar procedimientos de recoleccin y almacenamiento de datos

    SP 1.4 Especificar procedimientos de anlisis

    SG 2 Proveer los resultados de la medicin Se proveen mediciones que satisfacen necesidades y objetivos de informacin.

    SP 2.1 Recolectar datos

    SP 2.2 Analizar datos

    SP 2.3 Almacenar datos y resultados

    SP 2.4 Comunicar resultados

    Estos objetivos pueden satisfacerse bsicamente mediante la puesta en marcha de un programa de mtricas que defina:

    Objetivos de la organizacin (por ejemplo, aumentar la productividad un X% o disminuir los defectos en produccin un Z%);

    Mtricas que permitan determinar si se cumplen o no con los objetivos (por ejemplo, productividad, densidad de defectos, etc.);

    Mecanismos de obtencin de las mtricas (procedimientos manuales, aplicaciones, orgenes de datos)

    Usualmente, los indicadores pueden agruparse en dos: por un lado, los empleados para monitorear cada proyecto (valor ganado, densidad de defectos, etc.), y por el otro los ms generales (porcentaje de proyectos finalizados en fecha, desvo promedio, etc.)

    Un enfoque muy interesante que puede emplearse para implementar los indicadores del segundo grupo es el balanced scorecard propuesto por Kaplan y Norton.5

    Aseguramiento de la Calidad de Productos y Procesos (PPQA) Una vez establecidos procesos y estndares ser necesario evaluar su aplicacin. El objetivo de esta rea es justamente ese: proveer una evaluacin objetiva de los procesos y de los artefactos producidos.

    Es importante aclarar que las prcticas de esta rea implican:

    19

  • Evaluar los procesos ejecutados, los artefactos producidos y los servicios provistos versus los estndares y descripciones de proceso aplicables;

    Identificar no conformidades, comunicarlas a los responsables, y asegurar su resolucin;

    Informar a los interesados (bsicamente, el equipo de proyecto y la gerencia) el resultado de las actividades de aseguramiento de la calidad.

    De ninguna manera debe confundirse esta rea con la de Verificacin (VE) incluida en el nivel 3, cuyo propsito es garantizar que se satisfagan los requerimientos. El foco aqu est puesto en garantizar que se apliquen los estndares y que los procesos se ejecuten de acuerdo a lo previsto (ver el Glosario para una definicin de control y aseguramiento de la calidad).

    Un tema importante es el de la objetividad. Debe garantizarse un nivel apropiado de independencia entre los productores y los evaluadores (aquellos que ejecuten actividades de aseguramiento de la calidad). Un canal de reporte con la gerencia tambin es importante para comunicar las no conformidades y garantizar que se resuelvan.

    Los objetivos y prcticas especficas del rea son lo siguientes:

    Objetivos Especficos Prcticas Especficas

    SG 1 Evaluar objetivamente procesos y artefactosvii Se evala objetivamente la adhesin de los procesos y artefactos a los estndares y descripciones de proceso vigentes.

    SP 1.1 Evaluar procesos objetivamente

    SP 1.2 Evaluar productos y servicios objetivamente

    SG 2 Proveer realimentacin objetivamente El no cumplimiento de los estndares y descripciones de proceso es objetivamente comunicado y su resolucin asegurada.

    SP 2.1 Comunicar y asegurar la resolucin de cuestiones de calidad

    SP 2.2 Establecer y mantener registros de las actividades de aseguramiento de la calidad

    Estas prcticas suelen implementarse mediante la creacin de un rol (no necesariamente full-time) encargado de estas actividades, y, por supuesto, de los procesos y estndares correspondientes.

    Algunas actividades de aseguramiento de la calidad podrn estar embebidas en el proceso de produccin (por ejemplo, como una actividad en el plan de proyecto), mientras que otras podrn ejecutarse independientemente y tener su propio plan (ms en el estilo de una auditora).

    vii Hemos adoptado el trmino artefacto para traducir lo que en el original figura como workproduct. Un artefacto es todo aquello producido por un proceso (el producto final, los productos intermedios).

    20

  • Es sumamente importante que el nivel de management adecuado reciba los informes de no-conformidad y facilite su regularizacin. Por supuesto que su postura no debe ser coercitiva.

    Administracin de la Configuracin (CM) Esta rea de proceso tiene como propsito mantener la integridad de todos los artefactos (entregables o no ) producidos por el proyecto, lo cual implica identificar los tems de configuracin, realizar sobre ellos cambios de manera controlada, generar y mantener lneas base, y proveer informacin precisa acera del estado del estado de la configuracin a todos los interesados.

    Los objetivos y prcticas incluidas son los siguientes:

    Objetivos Especficos Prcticas Especficas

    SG 1 Establecer lneas base Se establecen lneas base de los artefactos puestos bajo administracin de la configuracin.

    SP 1.1 Identificar tems de configuracin

    SP 1.2 Establecer un sistema de administracin de la configuracin

    SP 1.3 Crear o liberar lneas base

    SG 2 Monitorear y controlar cambios Los cambios a los artefactos son monitoreados y controlados.

    SP 2.1 Monitorear pedidos de cambio

    SP 2.2 Controlar tems de configuracin

    Esta rea de proceso es, probablemente, una de las ms difciles de implementar de todas las incluidas en este nivel. Adems de tener problemas para planificar y ejecutar sus actividades de acuerdo a esos planes, las organizaciones de nivel 1 suelen tener serias complicaciones para identificar y mantener las versiones correctas de sus productos y artefactos asociados. Es bastante comn encontrarse con organizaciones que tienen mltiples versiones activas de una misma aplicacin, sin poder llegar a controlarlas del todo e invirtiendo ingentes recursos en arreglar los mismos problemas una y otra vez. Estas prcticas apuntan, justamente, a resolver este tipo de problemas.

    Cmo se implementan? En general, ser necesario contar con algn tipo de sistema (preferiblemente, total o parcialmente automatizado) que permita realizar las actividades tpicas de administracin de la configuracin:

    Identificar tems de configuracin y mantener sus relaciones con otros tems;

    Crear, extraer (checkout) e ingresar (checkin) tems de configuracin del/al sistema de administracin de la configuracin;

    Generar lneas base en determinados hitos del proyecto;

    21

  • Auditar tems, lneas base y el sistema de administracin de la configuracin;

    Elevar, analizar y aprobar pedidos de cambio.

    La introduccin de una herramienta de este tipo tendr un impacto importantsimo en el trabajo diario de todos los miembros del proyecto (o de la organizacin, dependiendo de su alcance), sobre todo en la de los desarrolladores.

    Administracin de Acuerdos con Proveedores (SAM) Esta rea de proceso apunta a resolver otro de los problemas habituales en muchas organizaciones: el de la tercerizacin.

    Si bien est originalmente pensada para todo lo relacionado con la adquisicin de productos que vayan a ser incorporados en la solucin a entregar al cliente, las prcticas incluidas aqu tambin sirven para todo aquello que sea necesario comprar pero que no ser finalmente entregado al cliente, como por ejemplo herramientas de desarrollo.

    Los objetivos y prcticas del rea son las que se indican en el siguiente cuadro:

    Objetivos Especficos Prcticas Especficas

    SG 1 Establecer acuerdos con proveedores Se establecen y mantienen acuerdos con proveedores.

    SP 1.1 Determinar tipo de adquisicin

    SP 1.2 Seleccionar proveedores

    SP 1.3 Establecer acuerdos con proveedores

    SG 2 Satisfacer acuerdos con proveedores Los acuerdos con los proveedores son satisfechos por el proyecto y por los proveedores.

    SP 2.1 Revisar productos adquiridos

    SP 2.2 Ejecutar acuerdos con proveedores

    SP 2.3 Aceptar el producto adquirido

    SP 2.4 Transicionar productos

    Para poner en prctica esta rea de proceso ser necesario definir los mecanismos mediante los cuales:

    Se seleccionarn los potenciales proveedores (por ejemplo, mediante un proceso que implique le creacin de RFIs y RFPs);

    Se elegirn los proveedores que suministrarn al proyecto los productos/servicios necesarios;viii

    Se formalizarn los acuerdos con los proveedores (por ejemplo, mediante un contrato o mediante un acuerdo de nivel de servicio);

    viii En el nivel 3 existe un rea de proceso llamada Anlisis y Toma de Decisiones (DAR) que propone un enfoque formal para la toma de decisiones, el cual podra ser empleado para seleccionar proveedores seguramente, una vez arribados a dicho nivel-.

    22

  • Se formalizar la entrega de los requerimientos al proveedor;

    Se formalizar la recepcin del producto/servicio solicitado al proveedor, y los correspondientes criterios de aceptacin.

    Es importante aclarar que:

    Los proveedores de los que habla el rea de proceso no necesariamente pertenecen a otra empresa u organizacin; todo grupo que deba suministrar productos y servicios al proyecto (inclusive, otros proyectos) puede ser considerado un proveedor. Ser necesario, entonces, formalizar con ellos el acuerdo.

    Si la solucin a entregar al cliente necesitar de algn tipo de producto COTSix (por ejemplo, un motor de base de datos o algn tipo de componente puntual), tambin ser necesario formalizar el acuerdo con el proveedor correspondiente.

    ix Ver el Glosario.

    23

  • reas de Proceso de Nivel 3 Para alcanzar este nivel de madurez deben ser formalizadas las actividades de ingeniera del producto (diseo, desarrollo, verificacin, etc.) y ser adoptadas prcticas de gestin de proyectos ms avanzadas (por ejemplo, gestin de riesgos) Tambin deben definirse procesos, procedimientos y estndares ms detallados que, a diferencia del nivel anterior, tendrn alcance organizacional-. Adicionalmente, tienen que ser establecidas las estructuras y los mecanismos necesarios para instrumentar la mejora continua de procesos (por ejemplo, el SEPG, los TWGs, etc.)x

    En este nivel de madurez hay un total de catorce reas de proceso, dos de ellas especficas para IPPD y una puntualmente necesaria para SS.

    Desarrollo de Requerimientos (RD) En el nivel anterior nuestra preocupacin pasaba ms por administrar los requerimientos que por tener una manera estndar para identificarlos y especificarlos. Justamente es esta rea de proceso la encargada de producir y analizar los requerimientos del cliente, del producto, y de las componentes del producto.

    El rea incluye tres objetivos especficos y diez prcticas especficas:

    Objetivos Especficos Prcticas Especficas

    SG1 Desarrollar Requerimientos del Cliente Se relevan las necesidades, expectativas, restricciones e interfaces y se traducen en requerimientos del cliente.

    SP 1.1 Relevar Necesidades

    SP 1.2 Desarrollar los Requerimientos del Cliente

    SG2 Desarrollar los Requerimientos del Producto Los requerimientos del cliente son refinados y elaborados para obtener los requerimientos del producto y sus componentes.

    SP 2.1 Establecer Requerimientos del Producto y sus Componentes

    SP 2.2 Asignar Requerimientos a las Componentes del Producto

    SP 2.3 Identificar Requerimientos de Interfaz

    SG3 Analizar y Validar Requerimientos Los requerimientos son analizados y validados, y se desarrolla una definicin de la funcionalidad requerida.

    SP 3.1 Desarrollar Concepto de Operacin y Escenarios

    SP 3.2 Desarrollar una Definicin de la Funcionalidad Requerida

    SP 3.3 Analizar Requerimientos

    SP 3.4 Analizar Requerimientos para Balancear Necesidades y Restricciones

    SP 3.5 Validar Requerimientos

    x Estos dos ltimos puntos la definicin ms detallada de procesos y el establecimiento de la mejora continua- estn soportados por el objetivo GG3 y las prcticas genricas GP 3.1 y 3.2, correspondientes a este nivel.

    24

  • Esta rea suele implementarse mediante la adopcin de tcnicas de relevamiento y anlisis de requerimientos, como por ejemplo prototipado, escenarios de operacin, casos de uso, etc. Ms all de las tcnicas elegidas es importante que se formalice:

    Cmo se obtendrn los requerimientos del usuario;

    Cmo se refinarn dichos requerimientos hasta obtener los del producto y los correspondientes a sus componentes;

    Cmo se especificarn, analizarn y validarn los requerimientos.

    Solucin Tcnica (TS) En el nivel 2 no importaba tanto formalizar el diseo y la construccin del producto; una vez que la organizacin ha arribado a este nivel necesitaremos hacerlo.

    Esta rea de proceso incluye todas las actividades necesarias para:

    Identificar y seleccionar una solucin a los requerimientos;

    Desarrollar el diseo del producto;

    Implementar el diseo y obtener el producto.

    Los objetivos y prcticas del rea son las siguientes:

    Objetivos Especficos Prcticas Especficas

    SG1 Seleccionar Soluciones Soluciones para el producto o para sus componentes son seleccionadas.

    SP 1.1 Desarrollar Soluciones Alternativas y Criterios de Seleccin

    SP 1.2 Evolucionar Conceptos Operacionales y Escenarios

    SP 1.3 Seleccionar Soluciones

    SG2 Desarrollar el Diseo Se disean el producto y sus componentes.

    SP 2.1 Disear el Producto y las Componentes

    SP 2.2 Desarrollar un Paquete Tcnico de Datos

    SP 2.3 Disear Interfaces

    SP 2.4 Realizar Anlisis de Construir, Reusar o Comprar

    SG3 Implementar el Diseo del Producto Las componentes del producto y la documentacin de soporte son desarrolladas a partir del diseo.

    SP 3.1 Implementar el Diseo

    SP 3.2 Desarrollar la Documentacin de Soporte

    La implementacin de las actividades aqu descriptas es bastante compleja. En parte, los objetivos especficos quedaran satisfechos de poner en prctica alguna tcnica o mtodo de diseo y programacin particular (diseo orientado a objetos, patrones de diseo, etc.) que permitan obtener el producto deseado a partir de los requerimientos y respetando el plan de proyecto. Hay que ser muy cuidadoso para no formalizar la

    25

  • prctica ms all de lo recomendable.

    Tambin ser necesario formalizar la evaluacin de las posibles alternativas de solucin a los requerimientos (ver Anlisis y Toma de Decisiones (DAR) para un enfoque formal de toma de decisiones)

    Integracin del Producto (PI) El propsito de esta rea de proceso es ensamblar el producto a partir de sus componentes, garantizando que su funcionamiento sea el previsto. Tiene tres objetivos y ocho prcticas especficas:

    Objetivos Especficos Prcticas Especficas

    SG1 Preparar la Integracin del Producto Se prepara la integracin del producto a partir de sus componentes.

    SP 1.1 Determinar la Secuencia de Integracin

    SP 1.2 Establecer el Ambiente de Integracin

    SP 1.3 Establecer Procedimientos y Criterios de Integracin

    SG2 Garantizar la Compatibilidad de las Interfaces Las interfaces internas y externas son compatibles.

    SP 2.1 Revisar las Descripciones de las Interfaces

    SP 2.2 Administrar Interfaces

    SG3 Ensamblar las Componentes y Liberar el Producto Las componentes verificadas son ensambladas y el producto integrado, verificado y validado es entregado.

    SP 3.1 Confirmar Aptitud de Componentes para la Integracin

    SP 3.2 Ensamblar las Componentes del Producto

    SP 3.3 Evaluar los Componentes Ensamblados

    SP 3.4 Empaquetar y Entregar el Producto o Componente

    Esta rea se puede implementar mediante la definicin de procedimientos para mantener bajo control las interfaces internas y externas (probablemente, uno de los problemas ms habituales en el desarrollo de software) y para integrar peridicamente el producto (las prcticas de daily build y smoke test propuestas por Microsoft son un ejemplo tpico de integracin progresiva). Quizs el aspecto ms complicado de poner en marcha sea el de disponer de un ambiente de integracin estable; sin embargo, de contar con un buen sistema de administracin de la configuracin que permita identificar distintos ambientes (desarrollo, integracin, prueba, etc.), la implementacin se facilita notablemente.

    Verificacin (VE) Esta rea de proceso tiene como objetivo garantizar que los artefactos seleccionados cumplan con los requerimientos asignados. Similar en ciertos aspectos a Validacin (VA) esta rea de proceso apunta a evaluar si el producto final y los productos intermedios del proyecto cumplen con los requerimientos del cliente, del producto, y

    26

  • de las componentes del producto. Sus objetivos y prcticas son las siguientes:

    Objetivos Especficos Prcticas Especficas

    SG1 Preparar la Verificacin Se prepara la verificacin de los artefactos.

    SP 1.1 Seleccionar Artefactos para su Verificacin

    SP 1.2 Establecer el Ambiente de Verificacin

    SP 1.3 Establecer Procedimientos y Criterios de Verificacin

    SG2 Realizar Revisiones de Pares Se realizan revisiones de pares sobre artefactos seleccionados.

    SP 2.1 Preparar la Revisin de Pares

    SP 2.2 Conducir la Revisin de Pares

    SP 2.3 Analizar Datos de la Revisin de Pares

    SG3 Verificar Artefactos Seleccionados Artefactos seleccionados son verificados versus los requerimientos especificados.

    SP 3.1 Realizar la Verificacin

    SP 3.2 Analizar los resultados de la Verificacin e Identificar Acciones Correctivas

    Las tcnicas empleadas para realizar la verificacin pueden ser similares a las utilizadas en la validacin (inspecciones, revisiones, pruebas, etc.); sin embargo, el propsito de esta rea es determinar si estamos construyendo el producto correctamente.

    La verificacin siempre es progresiva: a lo largo del ciclo de vida del proyecto tendremos varios momentos en los cuales revisaremos los resultados de las actividades con el propsito de comprobar si cumplen o no con los requerimientos que les han sido asignados (por ejemplo, si la salida de la actividad de diseo cumple con los requerimientos asignados a dicha actividad). De esta manera se detectan problemas tempranamente y se evita que lleguen al producto final.

    Uno de los mecanismos para realizar verificaciones que propone el modelo es el de revisin de pares. En este tipo de revisiones, pares del productor o autor de un artefacto lo revisan con el propsito de identificar defectos o cambios. Una tcnica de revisin de pares muy popular es la de inspecciones (ver Fig. 8).

    27

  • Fig. 8: Tcnica de inspeccin

    Para implementar esta rea de proceso es necesario identificar puntos clave en donde realizar las revisiones, y las tcnicas correspondientes para hacerlo. Tambin ser necesario disponer de un ambiente para realizar la verificacin (esto se ve muy claro cuando la verificacin involucre algn tipo de testing).

    Aqu van algunos ejemplos:

    Al final de la primer fase del proyecto, en donde se define el alcance y se establece el plan, inspeccionar los artefactos relacionados con la funcionalidad a desarrollar (acuerdo de proyecto, visin, especificacin de requerimientos, etc.);

    Revisar el modelo de datos y la especificacin de diseo al final de las actividades de diseo;

    Inspeccionar el cdigo fuente de componentes de software clave;

    Realizar pruebas de software durante la construccin;

    Inspeccionar manuales de usuario y material de entrenamiento;

    Etc.

    28

  • Validacin (VA) A diferencia del rea de proceso anterior, sta est enfocada en demostrar si el producto (o sus componentes) satisface las necesidades de uso en el ambiente deseado.

    As como Verificacin se focaliza en determinar si lo construimos bien, Validacin se ocupa de evaluar si construimos el producto correcto.

    Los objetivos y prcticas especficas del rea son los siguientes:

    Objetivos Especficos Prcticas Especficas

    SG1 Preparar la Validacin Se realiza la preparacin de la validacin.

    SP 1.1 Seleccionar Productos para Validacin

    SP 1.2 Establecer el Ambiente de Validacin

    SP 1.3 Establecer Procedimientos y Criterios de Validacin

    SG2 Validar el Producto o sus Componentes El producto o sus componentes son validados para garantizar que ellos son adecuados para ser usados en el ambiente operativo deseado.

    SP 2.1 Realizar la Validacin

    SP 2.2 Analizar los Resultados de la Validacin

    Verificacin y validacin suelen ocurrir simultneamente y usar el mismo ambiente. A menudo, los usuarios estn involucrados.

    Esta rea de proceso se implementa mediante la inclusin de actividades de validacin en lugares clave del proceso productivo. Las tcnicas y mtodos a emplear podrn ser similares a los utilizados en las actividades de verificacin (pruebas, revisiones, inspecciones, etc.).

    Son varios los aspectos importantes que deben ser contemplados antes y durante la validacin:

    Ambientes para realizar la validacin (por ejemplo, procesadores, redes, datos, infraestructura, etc.);

    Herramientas para realizar la validacin;

    Personal capacitado.

    Enfoque Organizacional en el Proceso (OPF) Una organizacin de nivel 3 debe tener un enfoque formal y disciplinado para continuamente mejorar sus procesos. Esta rea junto a Definicin Organizacional del Proceso (OPD) y Entrenamiento Organizacional (OT)- contribuye a alcanzar dicho

    29

  • objetivo.

    El propsito de esta rea en particular es planificar e implementar las mejoras a los procesos de la organizacin. OPD, por su lado, es la encargada de establecer y mantener los activos de proceso (polticas, descripciones de procesos y procedimientos, estndares, mtricas, etc.), mientras que OT es la responsable de desarrollar los conocimientos y habilidades del personal para que puedan desempear sus roles de manera adecuada.

    Los objetivos y prcticas especficas de esta rea son:

    Objetivos Especficos Prcticas Especficas

    SG1 Determinar Oportunidades de Mejora de Procesos Peridica o eventualmente se identifican fortalezas, debilidades y oportunidades de mejora a los procesos de la organizacin.

    SP 1.1 Determinar Necesidades de los Procesos de la Organizacin

    SP 1.2 Evaluar los Procesos de la Organizacin

    SP 1.3 Identificar Mejoras a los Procesos de la Organizacin

    SG2 Planificar e Implementar Actividades de Mejora Las mejoras son planeadas e implantadas, los activos de proceso son distribudos, y se incorpora la experiencia adquirida en los activos de proceso.

    SP 2.1 Establecer Planes de Accin

    SP 2.2 Implementar Planes de Accin

    SP 2.3 Desplegar Activos de Proceso

    SP 2.4 Incorporar Experiencias Reales en los Activos de Proceso

    Esta rea de proceso se implementa poniendo en marcha la infraestructura bsica para la mejora de procesos (SEPG, TWGs, etc.)xi, planificando las actividades de mejora, y formalizando la evaluacin (appraisal) de los procesos de la organizacin.

    Probablemente, ya desde nivel 2 exista algn tipo de infraestructura para realizar este tipo de actividades; lo que cambia es que en este nivel hay un mayor grado de formalizacin y compromiso.

    Este tipo de iniciativas deben manejarse como proyectos ejecutados en el contexto de un programa de mejora continua a mediano plazo (de tres a cinco aos), con planes tcticos de menor alcance. El modelo de mejora propuesto por el SEI es IDEAL (Initiating, Diagnosing, Establishing, Acting, Leveraging, las iniciales de las cinco fases del modelo), un proceso para ejecutar y guiar programas de este tipo.xii

    Un tema crtico es la pelea por los recursos: ante la posibilidad de ejecutar un proyecto de mejoras y un proyecto ms relacionado con el negocio, probablemente la balanza se inclinar a favor del ltimo. Una manera de resolver este tipo de conflictos es tener un comit que auspicie la iniciativa, a la vez que se encuentre en funcionamiento una PMO que tenga a su cargo balancear la cartera de proyectos. xi Ver el Glosario.

    xii Ms informacin al respecto: http://www.sei.cmu.edu/ideal/

    30

  • Por otro lado, las evaluaciones (los appraisals de los que habla el modelo) deben realizarse siguiendo el proceso oficial, llamado SCAMPI (Standard CMMI Appraisal Method for Process Improvement).xiii Hay tres tipos posibles (A, B y C), dependiendo del objetivo que se persiga (evaluacin interna o externa, generacin de rating nivel de madurez o capacidad-). Para demostrar que una prctica especfica de un rea de proceso determinada se encuentra implementada, es necesario mostrar evidencias directas (resultado directo de su ejecucin) e indirectas (consecuencia no directa de su implementacin).

    En resumen, esta rea de proceso se resuelve teniendo un proceso definido para efectuar mejoras a los procesos de la organizacin. Ni ms ni menos.

    Definicin Organizacional del Proceso (OPD) Esta rea de proceso, complementaria de la anterior, tiene como propsito establecer y mantener un conjunto utilizable de activos de proceso. En este contexto, un activo es cualquier elemento que forme parte de los procesos de la organizacin (una poltica, la descripcin de un proceso, un estndar, la plantilla de un documento, etc.) y que sea empleado para describir, implementar y mejorar procesos.

    El objetivo y las prcticas de esta rea son las siguientes:

    Objetivo Especfico Prcticas Especficas

    SG1 Establecer Activos de Proceso Se establece y mantiene un conjunto de activos de proceso.

    SP 1.1 Definir Procesos Estndar

    SP 1.2 Definir Modelos de Ciclo de Vida

    SP 1.3 Definir Criterios y Guas para Adaptar Procesos

    SP 1.4 Establecer Repositorio Organizacional de Mtricas

    SP 1.5 Establecer la Biblioteca de Activos Organizacionales de Proceso

    Esta rea de proceso se implementa documentando los activos y resguardndolos en algn tipo de repositorio (una intranet, un conjunto de documentos en un directorio, una base de conocimiento, etc.) que pueda ser fcilmente consultado por todos los interesados.

    Usualmente, las organizaciones definen una arquitectura general en donde identifican sus grandes procesos (por ejemplo, desarrollo de software, implantacin de paquetes, administracin de cambios, etc.); posteriormente, cada uno de los procesos es bajado a mayor nivel de detalle (subprocesos, actividades). Para cada actividad podrn definirse tcnicas (por ejemplo, cmo construir el modelo de datos) y procedimientos detallados (cmo usar una herramienta determinada para completar una tarea especfica). Las actividades consumirn y producirn algn tipo de artefacto

    xiii Ms informacin: http://www.sei.cmu.edu/cmmi/appraisals/appraisals.html

    31

  • (especificaciones, planes, modelos, componentes de software, etc.) para los cules existir un estndar (por ejemplo, una plantilla). Para las actividades y artefactos se definirn, probablemente, checklists para su revisin.

    Adems de todo esto, el repositorio deber incluir lineamientos para adaptar los procesos a las necesidades de cada proyecto en particular. Usualmente, tambin incluir polticas, material de entrenamiento y capacitacin, manuales de productos, mtricas, lecciones aprendidas en otros proyectos, etc.

    La experiencia ha demostrado la importancia de gestionar el conocimiento y la experiencia organizacional. Sin un adecuado manejo de estos temas ser difcil comunicar y sustentar en el tiempo los procesos adoptados por la organizacin.xiv

    Entrenamiento Organizacional (OT) Los esfuerzos de mejora deben ser complementados con el entrenamiento necesario para que todos los integrantes de la organizacin estn preparados para realizar su trabajo de manera adecuada. El propsito de esta rea es, justamente, proveer los conocimientos y habilidades necesarios para que el personal pueda desempear sus roles eficaz y eficientemente, y as facilitar el cumplimiento de los objetivos estratgicos de la organizacin y las necesidades tcticas de los proyectos y reas de soporte.

    Sus objetivos y prcticas especficas son las siguientes:

    Objetivos Especficos Prcticas Especficas

    SG1 Establecer Capacidad de Entrenamiento Organizacional Se establece y mantiene una capacidad de entrenamiento que permite desarrollar los conocimientos y habilidades necesarias para las actividades de la organizacin.

    SP 1.1 Determinar las Necesidades Estratgicas de Entrenamiento

    SP 1.2 Determinar Cules Necesidades de Entrenamiento son Responsabilidad de la Organizacin

    SP 1.3 Establecer un Plan Tctico de Entrenamiento Organizacional

    SP 1.4 Establecer Capacidades de Entrenamiento

    SG2 Proveer el Entrenamiento Necesario Se provee el entrenamiento necesario para que las personas desempeen efectivamente sus roles.

    SP 2.1 Proveer Entrenamiento

    SP 2.2 Establecer Registros del Entrenamiento

    SP 2.3 Evaluar la Efectividad del Entrenamiento

    Esta rea de proceso normalmente se resuelve estableciendo un programa de capacitacin y entrenamiento basado en los conocimientos y habilidades necesarios para que el personal pueda desempear los roles que les hayan sido asignados. Esto suele llevar a que la organizacin formalice la definicin de los puestos y los planes de

    xiv Un excelente enfoque para el manejo de conocimiento es el propuesto por Basili, Caldiera y Rombach en The Experience Factory: http://www.cs.umd.edu/~mvz/handouts/fact.pdf

    32

  • carrera del personal.

    El entrenamiento y la capacitacin debern incluir todos aquellos temas relacionados con los procesos de la organizacin y, en funcin de cules reas de conocimiento queden en manos de cada individuo y cules no, todos aquellos considerados importantes para desempear exitosamente el puesto asignado.

    Por ejemplo, una organizacin podra definir que sus lderes de proyecto tengan un adecuado manejo de los procesos planteados por el PMBOKxv o que sus desarrolladores satisfagan determinadas reas de conocimiento del SWEBOK.xvi Otra alternativa sera obtener algn tipo de certificacin de un ente reconocido, como por ejemplo, la certificacin de Project Management Professional otorgada por el Project Management Institute, o la de Certified Software Development Professional de la IEEE Computer Society.

    Gestin del Riesgo (RSKM) Esta rea es una evolucin de las prcticas bsicas de manejo de riesgo incluidas en Planificacin del Proyecto (PP) y Monitoreo y Control del Proyecto (PMC) pertenecientes al nivel 2. Aqu se plantea un enfoque sistemtico para planear, anticipar y mitigar riesgos para proactivamente minimizar su impacto en el proyecto. Sus objetivos y prcticas especficas son las siguientes:

    Objetivos Especficos Prcticas Especficas

    SG1 Preparar la Gestin del Riesgo Se establece y mantiene una estrategia para identificar, analizar y mitigar riesgos.

    SP 1.1 Determinar Fuentes y Categoras de Riesgo

    SP 1.2 Definir Parmetros de Riesgo

    SP 1.3 Establecer una Estrategia para la Gestin del Riesgo

    SG2 Identificar y Analizar Riesgos Los riesgos son identificados y analizados para determinar su importancia relativa.

    SP 2.1 Identificar Riesgos

    SP 2.2 Evaluar, Categorizar y Priorizar Riesgos

    SG3 Mitigar Riesgos Los riesgos son manejados y mitigados para reducir su impacto negativo en los objetivos.

    SP 3.1 Desarrollar Planes de Mitigacin de Riesgo

    SP 3.2 Implementar Planes de Mitigacin de Riesgo

    Los objetivos de esta rea se satisfacen mediante la puesta en marcha de mecanismos formales para manejar los riesgos. En este nivel no basta simplemente con identificarlos (ver la SP 2.2 de Planificacin del Proyecto (PP)) y administrarlos en la medida que vayan ocurriendo; aqu ser necesario establecer un proceso para definir y ejecutar una estrategia para gestionarlos.

    Por ejemplo, podra establecerse un esquema de clasificacin de riesgos y posibles xv Project Management Body of Knowledge: http;//www.pmi.org

    xvi Software Engineering Body of Knowledge: http://www.swebok.org

    33

  • respuestas basado en experiencias anteriores. Tambin podran identificarse probabilidades de ocurrencia y magnitudes de impacto en funcin de aspectos tcnicos y de gestin, basados en lo ocurrido en proyectos previos.

    En resumen, una organizacin de nivel 3 debe proponerse tener un enfoque mucho ms formal para identificar riesgos y clasificarlos, y para planear posibles acciones de mitigacin y contingencia.xvii

    Anlisis y Toma de Decisiones (DAR) Esta rea tiene como propsito que determinadas decisiones sean tomadas de acuerdo a un proceso formal. Por ejemplo, decidir entre distintas alternativas de solucin, o seleccionar un producto o un proveedor, son todas decisiones que podran tomarse mediante un proceso formal compatible con los objetivos y prcticas de esta rea de proceso.

    Cuando hablamos de un proceso de evaluacin formal nos estaremos refiriendo a un enfoque estructurado para evaluar alternativas y recomendar una solucin a un problema determinado. Esto implica que se debern:

    Establecer criterios (qu decisiones es recomendable que pasen por este proceso y cules no, cules son los criterios de evaluacin, etc.);

    Identificar soluciones alternativas;

    Determinar mtodos para evaluarlas;

    Evaluar las soluciones alternativas y recomendar una de ellas.

    El rea tiene un nico objetivo especfico y seis prcticas:

    Objetivo Especfico Prcticas Especficas

    SG 1 Evaluar Alternativas Las decisiones estn basadas en la evaluacin de alternativas usando criterios establecidos.

    SP 1.1 Establecer Lineamientos para el Anlisis de Decisiones

    SP 1.2 Establecer Criterios de Evaluacin

    SP 1.3 Identificar Soluciones Alternativas

    SP 1.4 Seleccionar Mtodos de Evaluacin

    SP 1.5 Evaluar Alternativas

    SP 1.6 Seleccionar Soluciones

    Estas prcticas se implementan mediante la definicin y uso de un procedimiento (o de varios, segn el caso) mediante el cual determinados tipos de decisiones sean tomadas. Por ejemplo, podra plantearse un procedimiento que haga uso de una matriz

    xvii Un enfoque muy interesante es el Software Risk Evaluation Method propuesto por el SEI: http://www.sei.cmu.edu/risk/main.html

    34

  • de criterios de seleccin para evaluar potenciales proveedores o productos. dem para decisiones relacionadas con temas tcnicos (por ejemplo, diseos o arquitecturas alternativas).

    Lo ms interesante de esta rea de proceso, adems de proveer un marco para un anlisis racional de alternativas, es que otorga transparencia al proceso decisorio. Probablemente, una de las reas de proceso ms difciles de implementar.

    Administracin Integrada del Proyecto (IPM) Junto a Gestin del Riesgo (RSKM) y Equipo Integrado (IPPD) (IT), esta es una de las reas de gestin avanzada de proyectos incluidas en el nivel 3. Elaborada sobre las prcticas del nivel anterior, su propsito es administrar el proyecto y el involucramiento de todos los interesados mediante un proceso que, basado en el proceso estndar de la organizacin, ha sido adaptado a las necesidades particulares del proyecto.

    El rea tiene cuatro objetivos, dos de ellos vlidos solamente si se est usando la disciplina IPPD (ver la seccin Disciplinas). Los objetivos y prcticas son los siguientes:

    Objetivos Especficos Prcticas Especficas

    SG 1 Usar el Proceso Definido para el Proyecto El proyecto es dirigido usando un proceso definido, adaptado del conjunto de estndares de proceso de la organizacin.

    SP 1.1 Establecer el Proceso Definido para el Proyecto

    SP 1.2 Usar los Activos de Proceso de la Organizacin para planificar las actividades del proyecto.

    SP 1.3 Integrar Planes

    SP 1.4 Gerenciar el Proyecto Usando Planes Integrados

    SP 1.5 Contribuir a los Activos de Proceso de la Organizacin

    SG 2 Coordinar y Colaborar con los Interesados La coordinacin y la colaboracin del proyecto y los interesados es manejada adecuadamente.

    SP 2.1 Administrar el Involucramiento de los Interesados

    SP 2.2 Administrar Dependencias

    SP 2.3 Resolver Problemas de Coordinacin

    SG 3 Usar la Visin Compartida del Proyecto (slo para IPPD) El proyecto es dirigido empleando la visin compartida del proyecto.

    SP 3.1 Definir el Contexto de la Visin Compartida del Proyecto.

    SP 3.2 Establecer la Visin Compartida del Proyecto.

    SG 4 Organizar Equipos Integrados (slo para IPPD) Los equipos integrados necesarios para ejecutar el proyecto son identificados, definidos, estructurados y asignados.

    SP 4.1 Determinar la Estructura del Equipo Integrado de Proyecto

    SP 4.2 Desarrollar una Distribucin Preliminar de los Requerimientos a los Equipos Integrados.

    SP 4.3 Establecer Equipos Integrados

    35

  • Implementar esta rea de proceso implicar:

    Definir el proceso que seguir el proyecto tomando como base los procesos y ciclos de vida estndar de la organizacin, siguiendo las recomendaciones de adaptacin incluidos en el repositorio de activos de proceso. En aquellos casos en donde no pueda realizarse la adaptacin, solicitar una excepcin a quien corresponda (por ejemplo, el rea de calidad o la PMO). El proceso del proyecto, as definido, deber quedar documentado en el plan de proyecto.

    Emplear los activos de proceso para estimar y planificar el proyecto. Integrar el plan de proyecto con otros planes (por ejemplo, el plan de marketing,

    capacitacin, etc.)

    Identificar y administrar las interfaces entre el proyecto y otros grupos de trabajo y/o individuos.

    Gerenciar el proyecto usando el plan del proyecto, el proceso del proyecto, y otros planes.

    Contribuir al repositorio de activos de la organizacin (nuevas plantillas, mtricas, nuevos procesos definidos por el proyecto, lecciones aprendidas, etc.)

    Adicionalmente, de emplearse IPPD se deber:

    Establecer la visin compartida del proyecto (todos los participantes/interesados deben estar involucrados en su desarrollo).

    Usar la visin para gerenciar el proyecto. Establecer equipos interdisciplinarios a cargo de los distintos aspectos del

    proyecto.

    Un comentario adicional es que, en muchos casos, adems de definir el proceso del proyecto ser necesario establecer los procesos de soporte y produccin (por ejemplo, si el proyecto consiste en disear un avin necesitaremos definir tambin cmo lo fabricaremos).

    Gestin Integrada de Proveedores (SS) (ISM) Esta rea de proceso, aplicable solamente en el contexto de la disciplina supplier sourcing o adquisicin de productos, tiene como propsito identificar potenciales proveedores de productos y establecer con ellos relaciones mutuamente beneficiosas.

    Sus objetivos y prcticas especficas son las que se detallan a continuacin:

    Objetivos Especficos Prcticas Especficas

    SG 1 Analizar y Seleccionar Proveedores de Productos

    SP 1.1 Analizar Potenciales Proveedores de Productos

    36

  • Se identifican, analizan y seleccionan aquellos proveedores potenciales cuyos productos mejor satisfagan las necesidades del proyecto.

    SP 1.2 Evaluar y Determinar Proveedores de Productos

    SG 2 Coordinar Trabajo con Proveedores El trabajo con los proveedores es coordinado con el propsito de garantizar que el acuerdo con el proveedor sea ejecutado apropiadamente.

    SP 2.1 Monitorear Procesos Seleccionados del Proveedor

    SP 2.2 Evaluar Artefactos Seleccionados del Proveedor

    SP 2.3 Revisar el Acuerdo con el Proveedor

    Esta rea de proceso podra implementarse a travs de un proceso que permita formalizar la seleccin y alianza estratgica con proveedores que estn en condiciones de entregar productos y servicios del nivel de calidad exigido por la organizacin. La evaluacin y seleccin debera ser extremadamente formal una alternativa sera usar Anlisis y Toma de Decisiones (DAR)- y el acuerdo con el proveedor podra formalizarse con algn tipo de contrato marco en donde se establezcan las condiciones generales de la relacin (trminos legales, niveles de servicio, auditora de productos y procesos, revisin peridica, etc.)

    Ambiente Organizacional para la Integracin (IPPD) (OEI) Esta rea de proceso vlida solamente para la disciplina IPPD- tiene como propsito proveer la infraestructura necesaria para que los distintos grupos implicados en el proyecto trabajen de manera integrada. En general, la infraestructura mencionada contendr los siguientes elementos:

    Una definicin de la visin de la organizacin, la que deber hacer referencia a valores y prcticas importantes para esta disciplina (trabajo en equipo, desarrollo de productos en forma concurrente, etc.)

    Un ambiente de trabajo preparado para la colaboracin e integracin del personal y de los distintos grupos involucrados.

    Personal especialmente entrenado para integrarse, colaborar y liderar a otros.

    El rea de proceso tiene dos objetivos especficos y un total de seis prcticas especficas:

    Objetivos Especficos Prcticas Especficas

    SG 1 Proveer Infraestructura para IPPD Se provee una infraestructura que maximiza la productividad de la gente y facilita la colaboracin.

    SP 1.1 Establecer la Visin Compartida de la Organizacin

    SP 1.2 Establecer un Ambiente de Trabajo Integrado

    SP 1.3 Identificar Requerimientos de Capacidades Propias para IPPD

    SG 2 Gestionar la Integracin del P l

    SP 2.1 Establecer Mecanismos de Liderazgo

    37

  • Personal El personal es gerenciado para nutrir los comportamientos colaborativos y de integracin.

    SP 2.2 Establecer Incentivos para la Integracin

    SP 2.3 Establecer Mecanismos para Balancear las Responsabilidades del Equipo y la Organizacin

    Equipo Integrado (IPPD) (IT) Esta es otra de las reas de proceso aplicable nicamente cuando se emplea la disciplina IPPD. Su propsito es establecer y mantener equipos integrados para el desarrollo de productos. En este contexto, el grupo de trabajo puede estar integrado por representantes de distintas reas funcionales y tcnicas-, proveedores o clientes. Cada uno de estos representantes estn autorizados por sus respectivas organizaciones para actuar y tomar decisiones en su nombre.

    El rea de proceso incluye dos objetivos y ocho prcticas especficas:

    Objetivos Especficos Prcticas Especficas

    SG 1 Establecer Composicin del Equipo Se establece y mantiene una estructura de equipo que provee los conocimientos y habilidades necesarias para proveer el producto del equipo.

    SP 1.1 Identificar las Tareas del Equipo

    SP 1.2 Identificar Necesidades de Conocimientos y Habilidades

    SP 1.3 Asignar Miembros de Equipo Apropiados

    SG 2 Gobernar la Operacin del Equipo La operacin del equipo integrado es gobernada de acuerdo a principios establecidos.

    SP 2.1 Establecer una Visin Compartida

    SP 2.2 Establecer el Acuerdo del Equipo

    SP 2.3 Definir Roles y Responsabilidades

    SP 2.4 Establecer Procedimientos Operativos

    SP 2.5 Colaborar entre los Equipos Participantes

    38

  • reas de Proceso de Nivel 4 En una organizacin de este nivel, los procesos son analizados con el propsito de resolver las causas especiales de variacin (ver Glosario) Las mtricas son empleadas para establecer objetivos y requerimientos de calidad para los productos y servicios, adems de ser usadas para fijar las metas de desempeo de los procesos.

    En este nivel, los procesos son predecibles y cuantitativamente comprendidos. Se emplean herramientas estadsticas para entender cul es la performance real de los procesos y la calidad de los productos y servicios de la organizacin. Las mismas herramientas se usan para predecir el futuro desempeo de los procesos, y los niveles de calidad de los productos y servicios.

    Solamente hay dos reas de proceso en el nivel 4: Desempeo del Proceso de la Organizacin (OPP) y Administracin Cuantitativa de Proyectos (QPM)

    Desempeo del Proceso de la Organizacin (OPP) Esta rea de proceso tiene como propsito comprender cul es la performance de los procesos de la organizacin y emplear dicha informacin para administrar cuantitativamente los proyectos.

    En una organizacin en este nivel, las mtricas de los procesos (por ejemplo, esfuerzo, efectividad del testing, etc.) y del producto (por ejemplo, densidad de defectos, confiabilidad, etc.) son empleadas para modelar la performance pasada y para predecir la futura. A su vez, estos modelos son empleados como base para contrastar el desempeo real de los proyectos.

    Con esta informacin la organizacin estar en condiciones de determinar cules procesos son estables, cules merecen atencin, cules deberan ser estadsticamente controlados y cmo, y cules procesos deberan ser mejorados.

    El rea tiene un solo objetivo y cinco prcticas especficas, a saber:

    Objetivo Especfico Prcticas Especficas

    SG 1 Establecer Lneas Base y Modelos

    Se establecen y mantienen modelos y lneas base que caracterizan el desempeo esperado del conjunto de procesos estndar de la organizacin.

    SP 1.1 Seleccionar Procesos

    SP 1.2 Establecer Mtricas de Desempeo de los Procesos

    SP 1.3 Establecer Objetivos de Calidad y Desempeo

    SP 1.4 Establecer Lneas Base de Desempeo

    SP 1.5 Establecer Modelos de Desempeo

    Estas prcticas pueden implementarse, por ejemplo, mediante un buen programa de mtricas que contemple la generacin de modelos de performance. Ser necesario,

    39

  • adems, contar con un proceso definido para realizar estas actividades, que podran ser asignadas al departamento de aseguramiento de la calidad (si existiere) u a otro similar.

    Las herramientas y tcnicas que pueden emplearse aqu son las clsicas popularizadas por la calidad total: diagramas de control, prueba de hiptesis, etc.

    Ms all de quin realice estas actividades, es importante tener en claro que no todos los procesos debern (o podrn) ser controlados estadsticamente. La decisin de cules son esos procesos deber tomarse en funcin de las necesidades del negocio y del proyecto.

    Son muchos los procesos candidatos a ser controlados estadsticamente. Por ejemplo, el proceso de testing podra ser analizado para determinar su efectividad (defectos post-release) y as predecir su comportamiento en el futuro. Tambin podramos buscar determinar el nivel de confiabilidad de nuestro proceso de estimacin, el tiempo medio entre fallas de nuestros productos, el nivel de productividad de la organizacin, etc.

    Administracin Cuantitativa de Proyectos (QPM) El propsito de esta rea de proceso es administrar el proyecto de manera tal de cumplir con sus objetivos de calidad y desempeo. El proyecto es gestionado cuantitativamente, lo cual implica:

    Establecer y mantener los objetivos de calidad y desempeo del proyecto;

    Configurar el proceso que emplear el proyecto seleccionando aquellos subprocesos sobre la base de su estabilidad y/o capacidad (lo que se encuentra en los modelos y lneas base mencionados en el rea de proceso anterior);

    Seleccionar los subprocesos del proceso del proyecto que sern estadsticamente administrados, y con cules tcnicas y herramientas;

    Monitorear el comportamiento del proyecto para determinar si se cumplen o no los objetivos de calidad y desempeo;

    Monitorear el desempeo de los subprocesos seleccionados para determinar si pueden cumplir sus objetivos de calidad y desempeo, y tomar acciones correctivas de ser necesario;

    Alimentar el repositorio de mtricas de la organizacin con los datos del desempeo y calidad reales.

    Los objetivos y prcticas especficas del rea son las siguientes:

    Objetivos Especficos Prcticas Especficas

    40

  • SG 1 Administrar el Proyecto Cuantitativamente

    El proyecto es cuantitativamente administrado usando objetivos de calidad y desempeo.

    SP 1.1 Establecer los Objetivos del Proyecto

    SP 1.2 Ensamblar el Proceso Definido para el Proyecto

    SP 1.3 Seleccionar Subprocesos a Ser Administrados Estadsticamente

    SP 1.4 Administrar el Desempeo del Proyecto

    SG 2 Administrar Estadsticamente el Desempeo de los Subprocesos

    El desempeo de los subprocesos seleccionados, pertenecientes al proceso definido del proyecto, es administrado estadsticamente.

    SP 2.1 Seleccionar Mtricas y Tcnicas de Anlisis

    SP 2.2 Aplicar Mtodos Estadsticos para Entender la Variacin

    SP 2.3 Monitorear el Desempeo de los Subprocesos Administrados

    SP 2.4 Registrar Datos de la Gestin Estadstica

    Las herramientas que pueden usarse para implementar estas prcticas son similares a las propuestas para el rea anterior: todas las de gestin estadstica de procesos. La diferencia radica en que aqu las empleamos para tener un conocimiento cabal del comportamiento de los subprocesos del proyecto (naturaleza de las variaciones, estabilidad, etc.)

    41

  • reas de Proceso de Nivel 5 Las organizaciones de este nivel trabajan en el anlisis de sus procesos con el objetivo de identificar y eliminar las causas comunes de variacin (ver Glosario) Para ello hacen uso de mtricas que les permiten:

    Seleccionar mejoras e innovaciones Estimar los costos y beneficios de las mejoras e innovaciones Medir los costos y beneficios reales de las mejoras e innovaciones

    La permanente bsqueda de mejores maneras de hacer las cosas, basada en la medicin de los procesos y sin alterar su estabilidad, est arraigada en lo ms profundo de la cultura de la organizacin. No hay otra manera de manejar el negocio.

    La diferencia entre este nivel y el anterior radica fundamentalmente en el tipo de causas de variacin que son atacadas: en nivel 4 se trabaja sobre las causas especiales (aquellas que producen variaciones no al azar en los resultados del proceso y que son atribuibles a factores externos, como por ejemplo condiciones en el medio ambiente), mientras que en nivel 5 el objetivo son las causas comunes (aquellas que producen variaciones al azar en los resultados del proceso y que tienen por origen el propio proceso)

    Solamente hay dos reas de proceso en este nivel: Innovacin organizacional y despliegue (OID) y Anlisis y resolucin de causas de defectos/problemas (CAR).

    Innovacin organizacional y despliegue (OID) El propsito de esta rea es seleccionar e implantar cambios que, de manera incremental, permitan mejorar en forma medible- los procesos y las tecnologas empleadas por la organizacin, al mismo tiempo que se alinean los objetivos de calidad y desempeo con los objetivos del negocio. En general, las mejoras estarn relacionadas con el incremento de la satisfaccin de los clientes o usuarios, la disminucin de los tiempos de desarrollo, o con el aumento de la productividad.

    En este nivel de madurez, las organizaciones poseen una cultura y una infraestructura que facilitan y estimulan la participacin de todos sus integrantes en las actividades de innovacin. La identificacin de potenciales mejoras puede ser realizada por cualquiera, sin importar su jerarqua o posicin en la organizacin. Los cambios seleccionados son efectivamente implementados, y sus consecuencias, medidas.

    El rea tiene dos objetivos especficos y un total de siete prcticas especficas, los que se describen a continuacin:

    Objetivos Especficos Prcticas Especficas

    42

  • SG1 Seleccionar mejoras

    Se seleccionan mejoras a las tecnologas y a los procesos que contribuyan a alcanzar los objetivos de calidad y desempeo.

    SP 1.1 Recibir y Analizar Propuestas de Mejora

    SP 1.2 Identificar y Analizar Innovaciones

    SP 1.3 Realizar Pilotos de las Innovaciones

    SP 1.4 Seleccionar Mejoras para Implantacin

    SG2 Implantar Mejoras

    Las mejoras a los procesos y las tecnologas de la organizacin son continua y sistemticamente implantados.

    SP 2.1 Planificar la Implantacin

    SP 2.2 Gestionar la Implantacin

    SP 2.3 Medir los Efectos de la Mejora

    Estos objetivos se pueden satisfacer de contarse con un proceso para realizar mejoras sistemticas a los procesos de la organizacin. Por ejemplo, podra plantearse que las propuestas de mejora sean elevadas a algn tipo de comit para su evaluacin, y que las que finalmente resulten aprobadas sean definidas e implementadas por una iniciativa que deber ser manejada como un proyecto ms con alcance, plan, presupuesto, recursos asignados, etc.-

    Si bien mecanismos de este tipo existirn en los niveles anteriores, en este nivel el manejo del tema es ms sistemtico y formal.

    Anlisis y resolucin de c