White Paper 2006 Una Introduccin a CMMI

White Paper 2006

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

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

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

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

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 ii

CMMI es servicio registrado de Carnegie Mellon University. Otros modelos de madurez son: SA-CMM (Software acquisition), P-CMM (People CMM), SE-CMM (Systems Engineering).

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).

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.

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

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.

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.

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

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 SG 1 Administrar Requerimientos Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto. Prcticas Especficas 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 SG 1 Administrar Requerimientos Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto. Prcticas Especficas 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 SG 1 Establecer estimaciones Se realizan y mantienen estimaciones de las magnitudes del proyecto. Prcticas Especficas 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 SP 1.4 Definir el ciclo de vida del proyecto 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 SP 2.3 SP 2.4 Identificar los riesgos del proyecto Planificar la administracin de datos del proyecto 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 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. Establecer el plan 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 SG 1 Monitorear el Proyecto El avance y la performance del proyecto se monitorean respecto a lo establecido en el plan de proyecto.

Prcticas Especficas SP 1.1 Monitorear los parmetros de planificacin del proyecto SP 1.2 SP 1.3 SP 1.4 SP 1.5 SP 1.6 SP 1.7 Monitorear los compromisos Monitorear los riesgos del proyecto Monitorear la administracin de datos del proyecto Monitorear la participacin de los interesados Conducir revisiones de avance Conducir revisiones de cumplimiento de hitos Analizar temas pendientes Ejecutar acciones correctivas Administrar acciones correctivas

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 SP 2.2 SP 2.3

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 SG 1 Alinear actividades de medicin y anlisis Las actividades de medicin y anlisis estn alineadas con los objetivos y necesidades de informacin. Prcticas Especficas SP 1.1 SP 1.2 Establecer objetivos de las mediciones Especificar mtricas

SP 1.3 Especificar procedimientos de recoleccin y almacenamiento de datos SP 1.4 Especificar procedimientos de anlisis Recolectar datos Analizar datos Almacenar datos y resultados Comunicar resultados

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

SP 2.1 SP 2.2 SP 2.3 SP 2.4

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 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. Prcticas Especficas SP 1.1 SP 1.2 Evaluar procesos objetivamente 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 SG 1 Establecer lneas base Se establecen lneas base de los artefactos puestos bajo administracin de la configuracin. Prcticas Especficas 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 Monitorear pedidos de cambio Controlar tems de configuracin

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

SP 2.1 SP 2.2

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 SG 1 Establecer acuerdos con proveedores Se establecen y mantienen acuerdos con proveedores. SG 2 Satisfacer acuerdos con proveedores Los acuerdos con los proveedores son satisfechos por el proyecto y por los proveedores. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 SP 2.3 SP 2.4 Determinar tipo de adquisicin Seleccionar proveedores Establecer acuerdos con proveedores Revisar productos adquiridos Ejecutar acuerdos con proveedores Aceptar el producto adquirido 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 SG1 Desarrollar Requerimientos del Cliente Se relevan las necesidades, expectativas, restricciones e interfaces y se traducen en 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. Prcticas Especficas SP 1.1 SP 1.2 Relevar Necesidades Desarrollar los Requerimientos del Cliente

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 Desarrollar Concepto de Operacin y Escenarios

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

SP 3.1

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

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 SG1 Seleccionar Soluciones Soluciones para el producto o para sus componentes son seleccionadas. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 SG2 Desarrollar el Diseo Se disean el producto y sus componentes. SP 2.1 SP 2.2 SP 2.3 SP 2.4 SG3 Implementar el Diseo del Producto Las componentes del producto y la documentacin de soporte son desarrolladas a partir del diseo. SP 3.1 SP 3.2 Desarrollar Soluciones Alternativas y Criterios de Seleccin Evolucionar Conceptos Operacionales y Escenarios Seleccionar Soluciones Disear el Producto y las Componentes Desarrollar un Paquete Tcnico de Datos Disear Interfaces Realizar Anlisis de Construir, Reusar o Comprar Implementar el Diseo 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 SG1 Preparar la Integracin del Producto Se prepara la integracin del producto a partir de sus componentes. SG2 Garantizar la Compatibilidad de las Interfaces Las interfaces internas y externas son compatibles. SG3 Ensamblar las Componentes y Liberar el Producto Las componentes verificadas son ensambladas y el producto integrado, verificado y validado es entregado. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 Determinar la Secuencia de Integracin Establecer el Ambiente de Integracin Establecer Procedimientos y Criterios de Integracin Revisar las Descripciones de las Interfaces Administrar Interfaces

SP 3.1 Confirmar Aptitud de Componentes para la Integracin SP 3.2 SP 3.3 SP 3.4 Ensamblar las Componentes del Producto Evaluar los Componentes Ensamblados 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 SG1 Preparar la Verificacin Se prepara la verificacin de los artefactos. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 SG2 Realizar Revisiones de Pares Se realizan revisiones de pares sobre artefactos seleccionados. SP 2.1 SP 2.2 SP 2.3 SG3 Verificar Artefactos Seleccionados Artefactos seleccionados son verificados versus los requerimientos especificados. SP 3.1 Seleccionar Artefactos para su Verificacin Establecer el Ambiente de Verificacin Establecer Procedimientos y Criterios de Verificacin Preparar la Revisin de Pares Conducir la Revisin de Pares Analizar Datos de la Revisin de Pares 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 SG1 Preparar la Validacin Se realiza la preparacin de la validacin. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 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 SP 2.2 Seleccionar Productos para Validacin Establecer el Ambiente de Validacin Establecer Procedimientos y Criterios de Validacin Realizar la Validacin 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 SG1 Determinar Oportunidades de Mejora de Procesos Peridica o eventualmente se identifican fortalezas, debilidades y oportunidades de mejora a los procesos de la organizacin. Prcticas Especficas 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 SP 2.1 SP 2.2 SP 2.3 Establecer Planes de Accin Implementar Planes de Accin Desplegar Activos de Proceso

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.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 xii

Ver el Glosario. 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 SG1 Establecer Activos de Proceso Se establece y mantiene un conjunto de activos de proceso. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 SP 1.4 Definir Procesos Estndar Definir Modelos de Ciclo de Vida Definir Criterios y Guas para Adaptar Procesos 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 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. Prcticas Especficas 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 SG2 Proveer el Entrenamiento Necesario Se provee el entrenamiento necesario para que las personas desempeen efectivamente sus roles. SP 2.1 SP 2.2 SP 2.3 Establecer Capacidades de Entrenamiento Proveer Entrenamiento Establecer Registros del Entrenamiento 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 SG1 Preparar la Gestin del Riesgo Se establece y mantiene una estrategia para identificar, analizar y mitigar riesgos. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 SG2 Identificar y Analizar Riesgos Los riesgos son identificados y analizados para determinar su importancia relativa. SG3 Mitigar Riesgos Los riesgos son manejados y mitigados para reducir su impacto negativo en los objetivos. SP 2.1 SP 2.2 SP 3.1 SP 3.2 Determinar Fuentes y Categoras de Riesgo Definir Parmetros de Riesgo Establecer una Estrategia para la Gestin del Riesgo Identificar Riesgos Evaluar, Categorizar y Priorizar Riesgos Desarrollar Planes de Mitigacin de Riesgo 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 xvi

Project Management Body of Knowledge: http;//www.pmi.org 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 SG 1 Evaluar Alternativas Las decisiones estn basadas en la evaluacin de alternativas usando criterios establecidos. Prcticas Especficas SP 1.1 Establecer Lineamientos para el Anlisis de Decisiones SP 1.2 SP 1.3 SP 1.4 SP 1.5 SP 1.6 Establecer Criterios de Evaluacin Identificar Soluciones Alternativas Seleccionar Mtodos de Evaluacin Evaluar Alternativas 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 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. Prcticas Especficas 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 SP 1.4 Integrar Planes 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. SG 3 Usar la Visin Compartida del Proyecto (slo para IPPD) El proyecto es dirigido empleando 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 2.1 SP 2.2 SP 2.3 Administrar el Involucramiento de los Interesados Administrar Dependencias Resolver Problemas de Coordinacin

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

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 SG 1 Analizar y Seleccionar Proveedores de Productos

Prcticas Especficas 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. 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 1.2 Evaluar y Determinar Proveedores de Productos

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 SG 1 Proveer Infraestructura para IPPD Se provee una infraestructura que maximiza la productividad de la gente y facilita la colaboracin. Prcticas Especficas SP 1.1 SP 1.2 Establecer la Visin Compartida de la Organizacin Establecer un Ambiente de Trabajo Integrado

SP 1.3 Identificar Requerimientos de Capacidades Propias para IPPD SP 2.1 Establecer Mecanismos de Liderazgo

SG 2 Gestionar la Integracin del P l

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 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. SG 2 Gobernar la Operacin del Equipo La operacin del equipo integrado es gobernada de acuerdo a principios establecidos.

Prcticas Especficas SP 1.1 Identificar las Tareas del Equipo

SP 1.2 Identificar Necesidades de Conocimientos y Habilidades SP 1.3 SP 2.1 SP 2.2 SP 2.3 SP 2.4 SP 2.5 Asignar Miembros de Equipo Apropiados Establecer una Visin Compartida Establecer el Acuerdo del Equipo Definir Roles y Responsabilidades Establecer Procedimientos Operativos 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 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. Prcticas Especficas SP 1.1 SP 1.2 SP 1.3 SP 1.4 SP 1.5 Seleccionar Procesos Establecer Mtricas de Desempeo de los Procesos Establecer Objetivos de Calidad y Desempeo Establecer Lneas Base de Desempeo 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 SP 1.2

Establecer los Objetivos del Proyecto Ensamblar el Proceso Definido para el Proyecto

SP 1.3 Seleccionar Subprocesos a Ser Administrados Estadsticamente SP 1.4 Administrar el Desempeo del Proyecto Seleccionar Mtricas y Tcnicas de Anlisis

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

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. SG2 Implantar Mejoras Las mejoras a los procesos y las tecnologas de la organizacin son continua y sistemticamente implantados.

SP 1.1 SP 1.2 SP 1.3 SP 1.4 SP 2.1 SP 2.2 SP 2.3

Recibir y Analizar Propuestas de Mejora Identificar y Analizar Innovaciones Realizar Pilotos de las Innovaciones Seleccionar Mejoras para Implantacin Planificar la Implantacin Gestionar la Implantacin 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 causas de defectos/problemas (CAR)

Poder identificar defectos tempranamente y evitar sus consecuencias es una caracterstica fundamental de las organizaciones pertenecientes al nivel 5. Las prcticas incluidas aqu apuntan a identificar, analizar y eliminar las causas no slo de los defectos sino tambin de los problemas (por ejemplo, para mejorar atributos de calidad de productos y servicios). Los objetivos y prcticas especficos son las siguientes:
Objetivos Especficos SG1 Determinar Causas de Defectos Las causas raz de defectos y otros problemas son sistemticamente identificadas. SG2 Resolver Causas de los Defectos Las causas raz de defectos y otros problemas son sistemticamente resueltas para prevenir su ocurrencia. Prcticas Especficas SP 1.1 SP 1.2 Seleccionar Datos de Defectos para Analizar Analizar Causas

SP 2.1 SP 2.2 SP 2.3

Implementar Acciones Propuestas Evaluar el Efecto de los Cambios Registrar Datos

Estos objetivos suelen ser satisfechos mediante la definicin e implementacin de un proceso que sistemticamente realice, a escala organizacional y por proyecto, el anlisis de los defectos y problemas encontrados, y la definicin y ejecucin de acciones concretas que permitan resolver sus causas de origen.

43

Una buena manera de implementar este anlisis, al menos a nivel proyecto, es realizar el cierre formal de los proyectos, registrando lecciones aprendidas y sugiriendo acciones de mejora. Otra alternativa es que el grupo de la organizacin a cargo de los temas de calidad sistemticamente examine los indicadores disponibles (por ejemplo, densidad de defectos o cantidad de incidentes en produccin) y que los analice con el propsito de identificar posibles causas de su comportamiento. Las herramientas que pueden emplearse en el anlisis son las que clsicamente han sido usadas por la calidad total: el diagrama de Pareto (ver Fig. 9), el de causa-efecto (ver Fig. 10) y el de dispersin.

Fig. 9: Un diagrama de Pareto

44

Fig. 10: Un diagrama de causa-efecto o de Ishikawa

Una vez realizado el anlisis deben definirse e implementarse las mejoras, las que podrn ejecutarse dentro de este proceso o en aquel relacionado con el rea de proceso Innovacin organizacional y despliegue (OID).

Definiendo los procesos de la organizacin

Como dijimos en secciones anteriores, CMMI es solamente un modelo de referencia que describe las caractersticas que debera reunir un proceso de desarrollo de productos de clase mundial. El proceso de desarrollo que definamos para nuestra organizacin debera tener una estructura adecuada a nuestras necesidades. No debemos caer en la tentacin de organizar nuestro proceso alrededor de las reas del modelo. En general, el proceso de desarrollo suele organizarse en fases y actividades, algunas de las cuales podrn pertenecer a distintas disciplinas o especialidades (gestin del proyecto, diseo y desarrollo, etc.) Esas actividades sern las encargadas de implementar las reas de proceso de CMMI. En algunas organizaciones, los procesos relacionados con administracin de la configuracin y aseguramiento de la calidad sern independientes del proceso de desarrollo empleado por los proyectos. Lo mismo ocurrir con el proceso encargado de identificar inicialmente las necesidades de los clientes que darn origen a los proyectos (el que suele ser llamado gestin de demanda). Idntica situacin se dar con los

45

procesos relacionados con el anlisis y la mejora de procesos. Pero adems del proceso productivo, ser necesario definir otros procesos que son vitales para cualquier organizacin y que CMMI no cubre por ser un modelo de referencia para procesos de desarrollo. Puntualmente, todas las actividades relacionadas con lo que ocurre despus de que el producto ha sido entregado no estn incluidas en el modelo. Ser necesario, entonces, definir los procesos relacionados con el soporte a los usuarios (atencin de incidentes y consultas, gestin de problemas, etc.) y con la operacin de la solucin (resguardo, procesamiento, anlisis de performance, seguridad, etc.), de manera de obtener as una organizacin balanceada: de poco servir ser muy buenos produciendo si no podemos administrar el producto una vez salido de la fbrica.

Otros estndares y modelos de referencia

Adems de CMMI, existen otros modelos y estndares que pueden ser empleados como referencia para definir e implantar procesos: ISO 9001, CobIT, ITIL y eSCM (ver Tabla 1). A continuacin, describimos sus principales caractersticas y mbitos de aplicacin.

ISO 9001:2000
El ms conocido de los mencionados anteriormente es ISO 9001:2000, un estndar internacional que puede ser aplicado a cualquier tipo de organizacin. Este estndar, que establece los requerimientos que debe cumplir un sistema genrico de gestin de la calidad (QMS, por sus siglas en ingls), puede ser usado para mejorar procesos internos, para obtener una certificacin o para establecer relaciones contractuales. Si bien su mbito de aplicacin es ms amplio, existen lineamientos para su uso en organizaciones de sistemas.6 Los requerimientos de la norma se agrupan en cinco captulos: sistema de gestin de calidad, responsabilidad de la direccin, gestin de recursos, realizacin del producto y medicin, anlisis y mejora. Dentro de cada uno de ellos encontraremos las clusulas que describen los requerimientos que deben satisfacerse para cumplir con el modelo. ISO 9001:2000 y CMMI tienen varios puntos de contacto, y algunas diferencias (ver Tabla 1 para ms detalles)xviii. Si bien es necesario analizar las situaciones caso por caso, podramos decir que una organizacin deseosa de certificar el estndar debera cumplir con las reas de proceso de nivel 2 y nivel 3, ms algunas de las correspondientes a los niveles cuatro y cinco. En la Fig. 1 se ilustran las relaciones entre cada uno de los captulos del estndar y las reas de proceso y prcticas genricas de CMMI.7

xviii

Por ejemplo, ISO 9001:2000 plantea requerimientos para los procesos de relacionamiento con los clientes, aspectos omitidos en CMMI.

46

Fig. 11: Relacin entre CMMI e ISO 9001:2000

CobIT
CobIT, por otro lado, es un modelo desarrollado por el IT Governance Institutexix cuyo propsito es establecer una serie de objetivos de control para las actividades de la organizacin de IT. CobIT se organiza en cuatro dominios, los cuales a su vez se descomponen en procesos que contienen los objetivos de control (ver Fig. 12).

xix

www.itgi.org

47

Fig. 12 Dominios y procesos de CobIT

Como puede apreciarse en la Fig. 12, varios de los procesos tienen puntos de contacto con CMMI. Por ejemplo, P09 Administrar Riesgos est claramente relacionado con Gestin del Riesgo (RSKM) (aunque los alcances son distintos) y P10 Administrar Proyectos con Planificacin del Proyecto (PP), Monitoreo y Control del Proyecto (PMC) y Administracin Integrada del Proyecto (IPM). Sin embargo, debe recordarse que ambos modelos tienen propsitos distintos: uno apunta a facilitar la evaluacin y mejora de procesos, mientras que el otro est enfocado en proveer objetivos y guas para controlar las actividades de IT. Podramos pensar, entonces, que las prcticas descriptas en CMMI, una vez implementadas, deberan facilitar el cumplimiento de algunos de los objetivos de control de CobIT.

ITIL
ITIL es el acrnimo de Information Technology Infrastructure Library.8 Desarrollado en los aos ochenta por la CCTA (Central Computer & Telecommunications Agency) del Reino Unido y administrado actualmente por la OGC (Office of Government Commerce), ITIL es un marco para organizar las actividades de provisin de servicios de IT. No es un estndar, sino un conjunto de best practices organizado alrededor de diez procesos (ver Fig. 13).

48

Fig. 13: Procesos de ITIL

La principal caracterstica de ITIL es que no prescribe sino que describe: en cada uno de los libros correspondientes a cada proceso se proveen lineamientos detallados de los procedimientos y actividades necesarias para implementarlo. Esta es una diferencia sustancial respecto a los distintos frameworks incluidos en esta seccin. A pesar de lo antes mencionado, hay dos estndares basados en ITIL: BS15000 y el ms reciente ISO 20000. Si bien ITIL implementa las actividades relacionadas con lo que pasa luego de que la solucin es puesta en produccin -uno de los aspectos no contemplados por CMMI- hay muchos puntos de contacto con dicho modelo; por ejemplo, change, configuration y release management estn claramente relacionados con el rea de proceso Administracin de la Configuracin (CM). Tambin Problem management tiene muchos puntos de contacto con Anlisis y resolucin de causas de defectos/problemas (CAR).

eSCM
Este modelo (eSourcing Capability Model) es el desarrollo ms reciente de la Carnegie Mellon University, pero en esta ocasin su origen no es el Software Engineering Institute sino el IT Services Qualification Center (ITsqc)xx, dependiente del Institute for

xx

Participaron adems empresas como IBM, Accenture y EDS, entre otras.

49

Software Research International de la Facultad de Ciencias de la Computacin.xxi Este modelo de capacidades apunta a cubrir ciertos aspectos relacionados con la provisin de servicios basados en IT que el resto de los modelos no cubre (por ejemplo, transferencia de conocimientos al proveedor del servicio, contratacin, gestin de relaciones, etc.) Su propsito es que los proveedores de servicios sean ms eficaces y eficientes, que sus contratos no sean interrumpidos por mal desempeo, y que haya una mejor relacin entre proveedores, clientes y organizaciones asociadas. Existen dos variantes del modelo, uno destinado a los proveedores del servicio (eSCMSP) y otro a los clientes del servicio (an no liberado) Claramente, el modelo es aplicable en aquellas situaciones en donde una organizacin desee tercerizar no slo sus servicios de IT (desarrollo, help desk, etc.) sino tambin procesos de negocio que hagan uso intensivo de la tecnologa (call centers, facturacin, etc.). A toda esta gama de actividades tercerizadas es a las que eSCM llama eSourcing.

Fig. 14: Fases y reas de capacidad de eSCM

El modelo tiene muchas particularidades (ver Fig. 14). Por un lado, las prcticas
xxi

De todas maneras, es interesante observar que uno de sus autores es Mark Paulk, quien fue tambin autor del CMM-SW.

50

pueden agruparse por reas de capacidad (similares a las categoras de proceso de CMMI), por fase, en funcin de la etapa en la cual se encuentre la provisin del servicio (iniciacin antes de la formalizacin del contrato-, despliegue, prestacin del servicio, cierre y ongoing para aquellas prcticas que se aplican en todas las fases anteriores-), y por niveles (2, 3 y 4). Otro de los aspectos interesantes es que no es un modelo de madurez, sino de capacidad. Esto implica que las reas pueden ser evaluadas individualmente (de manera similar a cuando se emplea la representacin continua de CMMI) y reciben una clasificacin entre 2 y 5 en funcin de las prcticas implementadas. Otra de las particularidades es que el nivel de capacidad 5 se otorga luego de haber certificado dos veces seguidas la de nivel 4 (existe una certificacin formal realizada por el ITsqc).

Integrando los modelos

Cada uno de los modelos y estndares propuestos tiene un propsito y un alcance claros (ver Tabla 1). Sin embargo, cada uno de ellos puede ser usado simultneamente de ser necesario. Por ejemplo, CMMI y eSCM podran ser usados concurrentemente en aquellas situaciones en donde se tercerice el desarrollo y mantenimiento de software (software factory). ITIL ( ISO 20000) podra aplicarse para resolver los temas no cubiertos por CMMI. CobIT es un framework que es propuesto como modelo de IT Governance, de manera que hay muchos puntos de contacto con ITIL y CMMI que deberan ser analizados, sobre todo en organizaciones internas de sistemas.xxii ISO 9001:2000 y CMMI comparten filosofa (la mejora continua y la gestin de procesos) y prcticas. Una alternativa sera usar CMMI como gua para obtener una certificacin ISO 9001:2000. Sin embargo, debe hacerse un anlisis detallado ya que el mapeo entre el estndar y el modelo de referencia no es necesariamente lineal (ver Fig. 11).
Tabla 1: Comparacin entre CMMI, ISO 9001, CobIT, ITIL y eSCM9

CMMI Organizaciones de desarrollo de sistemas basados en software. Proveer las mejores prcticas para el desarrollo de software, sistemas, productos y
xxii

ISO9001 Proveedores de cualquier tipo de producto/servicio.

CobIT Organizaciones de IT.

ITIL Proveedores de servicios de IT

eSCM-SP Proveedores de servicios basados en IT.

Requerimientos para el establecimiento de un sistema de calidad.

Auditora y control de sistemas de informacin. Alineamiento y gobierno de IT.

Marco de trabajo para organizar los procesos de provisin de servicios de IT.

Desarrollar y mejorar las habilidades del proveedor para cumplir con las necesidades del

De hecho, el dominio Entrega y Soporte de CobIT est basado en ITIL.

51

procesos integrados, y adquisicin.

cliente durante todo el ciclo de vida.

628 prcticas en 25 reas de proceso

51 clusulas.

4 dominios, 34 procesos de IT y 318 objetivos de control. Reporte del auditor; no hay certificacin formal.

10 procesos.

84 prcticas en 10 reas de capacidad.

Reporte de evaluacin/assess ment; no hay certificacin formal.

Certificacin por entes autorizados.

Es un modelo de referencia y una descripcin de procesos al mismo tiempo. No se certifica ni se evala formalmente. El nuevo estndar ISO 20000 est inspirado en l

Certificacin de CMU.

Conclusiones
CMMISM es un modelo ms que interesante si lo que nos preocupa es mejorar la forma en la cual desarrollamos nuestros productos. Si bien hay muchas voces a su favor y varias otras en su contra, el modelo representa bastante bien la visin actual de cmo los conceptos de calidad deberan ser aplicados a las industrias relacionadas con las tecnologas de la informacin (y, en general, a todas aquellas que desarrollen productos). Por supuesto que para ser exitosos en su aplicacin hay varios aspectos que no deberamos perder de vista. El primero tiene que ver con el contexto en el cual queramos aplicarlo: CMMISM es solamente un marco de referencia, por lo que queda librado a nuestro sentido comn cmo interpretarlo y cmo aplicarlo en funcin de las caractersticas de nuestra organizacin y del tipo de industria en la que nos encontremos. No es lo mismo una pequea casa de software que atiende clientes locales que una gran software factory con clientes en el extranjero; claramente, ambas tendrn factores en comn (planificacin, seguimiento, manejo de requerimientos, etc.), pero tambin tendrn diferencias sustanciales (escala, complejidad tcnica, formalidad en el manejo de la demanda de los clientes, etc.) que ser necesario analizar antes de aplicar las ideas detrs de CMMISM. Otro aspecto que no debe perderse de vista es que CMMISM apunta fundamentalmente a la eficiencia operativa. Por consiguiente, alcanzar un determinado nivel de madurez no garantiza el xito de la organizacin; son la estrategia de negocio y la capacidad de ponerla en prctica las que permiten hacerlo. Endilgarle al modelo fortalezas o

52

debilidades en ese rubro es no comprender las ideas que le dieron origen. Y, por ltimo, no debemos olvidarnos del aspecto humano. Contar con un proceso formalizado no es una excusa para pensar que las personas son recursos fcilmente reemplazables. Muchas organizaciones han cado en la tentacin de sobreespecificar sus procesos, llegando a describir hasta el ms mnimo detalle. Eso agobia a la gente que debe ejecutarlos. Debemos ser conscientes de que es sumamente importante lograr un equilibrio entre la formalidad de nuestros procesos y la flexibilidad que necesitan quienes harn uso de ellos.

Sergio Villagra & Axentia, 2006

53

Glosario
Aseguramiento de la calidad Todas aquellas acciones planeadas y sistemticas necesarias para proveer una adecuada confianza de que un producto o servicio satisfar determinados requerimientos de calidad (ISO 8402). Variaciones en la salida de un proceso originada en el propio proceso (mano de obra, materiales, mtodos, maquinaria, mtricas, medio ambiente) Variacin no aleatoria en la salida de un proceso, atribuible a causas externas especficas (por ejemplo, falta de entrenamiento, materia prima de baja calidad, no seguimiento del proceso, fallas en las herramientas, etc.) Las actividades y tcnicas operativas usadas para cumplir con los requerimientos de calidad (ISO 8402). Commercial-of-the-Shelf. Productos de software disponibles para ser comprados y usados sin necesidad de realizar actividades de desarrollo. Software Engineering Process Group. Grupo de trabajo encargado de coordinar las actividades de mejora de procesos en una organizacin de desarrollo de software. Technical Working Group. Grupo de trabajo encargado de identificar e implementar mejoras a los procesos. En general, est formado por personal involucrado en los procesos que se pretende mejorar.

Causa comn de variacin

Causa especial de variacin

Control de calidad

COTS

SEPG

TWG

54

Referencias
1 La informacin de CMMI empleada para elaborar este artculo ha sido tomada de Capability Maturity Model Integration Version 1.1 Staged Representation, CMU/SEI-2002-TR-012. 2 3 4 5 6 7

Watts S. Humphrey; Managing the Software Process; Addison-Wesley, 1989. Paulk, Weber, Curtis, Chrissis; Capability Maturity Model for Software Version 1.1; CMU/SEI-93-TR-24. William Florac, Robert Park, Anita Carleton; Practical Software Measurement; CMU/SEI-97-HB-003. Robert Kaplan, David Norton; The Strategy Focused Organization; Harvard Business School, 2001 ISO/IEC; Software engineering Guidelines for the application of ISO 9001:2000 to computer software; ISO/IEC 90003.

Boris Mutafelija, Harvey Stromberg; Systematic Process Improvement Using ISO 9001:2000 and CMMI; Artech House Publishers, 2003
8 9

itSMF; IT Service Management: An Introduction; Van Haren Publishing, 2002

Mark Paulk, Elaine Hyder, Keith Heston; The eSCM SP v2: Model Overview; Information Technology Qualification CenterCarnegie Mellon University.

55