Javier Garzs Parra Emanuel A.

Irrazbal Roberto Santa Escolstica

Gua prctica de supervivencia en una auditora CMMI

Nmero 2011-002

Boletn de la ETSII ISSN: 2172-6620 Escuela Tcnica Superior de Ingeniera Informtica Universidad Rey Juan Carlos

Gua prctica de supervivencia en una auditora CMMI

Javier Garzs Parra1, Emanuel A. Irrazbal1, Roberto Santa Escolstica2
1

Kybele Research Group, Universidad Rey Juan Carlos; Madrid, Espaa {javier.garzas, emanuel.irrazabal}@urjc.es 2 Kybele Consulting, C/Oliva 18, 3A, 28231 Las Rozas, Madrid, Espaa {roberto.santaescolastica}@kybeleconsulting.com

Abstract. Enfrentarse por primera vez a una auditora CMMI supone tener que superar una gran carga de actividades y enfrentarse a una gran cantidad de terminologa nueva y compleja. Por ello, esta gua pretende facilitar la tarea de preparacin de una auditora CMMI, ayudando as a reducir el importante sobreesfuerzo que habitualmente supone su realizacin. Keywords: CMMI, SCAMPI, auditora, desarrollo, software.

Prefacio

Enfrentarse por primera vez a una auditora CMMI [1] supone tener que superar una gran carga de actividades y enfrentarse a una gran cantidad de terminologa nueva y compleja. A esto se aade que es habitual que las empresas, inmersas en su rutina diaria, no dispongan de mucho tiempo para preparar las auditoras. Bajo estos precedentes, conscientes de la necesidad cada vez mayor por parte de las empresas de disponer de certificaciones software, pretendemos con esta gua facilitar la tarea de preparacin de una auditora CMMI, ayudando a reducir el importante sobreesfuerzo que supone su realizacin. Pretendemos que esta gua sea un manual de supervivencia a la hora de enfrentarse a una auditora de CMMI. Y como tal herramienta de supervivencia, proporciona lo ms bsico y esencial para poder afrontar la auditora y de ah que hayamos pretendido que no supere 40 pginas de enfoque puramente prctico, an a riesgo de obviar por ello algn detalle o matizacin terica, pero para este tipo de detalles existen otros muchos libros. Comentar tambin, que este no es un documento de consultora, y tampoco est enfocado a implantar CMMI o mejorar los procesos software, eso lo dejamos para otros textos. Este es un documento esencialmente de preparacin para la auditora, que normalmente te ser de utilidad si has liderado una mejora CMMI y en breve te enfrentars a la auditora o si te han

invitado a participar en el equipo de auditora. 1.1 Aclaracin sobre la terminologa

El trmino auditora. Siendo rigurosos, ms que auditora en CMMI el trmino correcto sera evaluacin, que proviene del trmino anglosajn appraisal y que es el que se usa en CMMI. Sin embargo, durante el texto utilizaremos la palabra auditora por ser la ms utilizada en el da a da de las empresas, facilitando as el objetivo de simplificar la terminologa de cara a la preparacin de una auditora CMMI. Niveles de madurez y capacidad. CMMI define dos maneras de evaluar los procesos, por niveles de capacidad y por niveles de madurez. La ms comn es esta ltima, que permite la obtencin de un nivel de madurez para la organizacin. Por ello, durante esta gua cuando hablamos de la auditora nos referiremos nicamente a la evaluacin por niveles de madurez. Terminologa en ingls. A lo largo de esta gua, en ocasiones aparecern ciertas expresiones en ingls relacionadas con la auditora. Hemos decidido mantener esta terminologa en ingls debido a que es la que se utiliza comnmente durante la auditora, y con la que deberemos acabar familiarizndonos. Trminos en castellano. Para mantener la mayor rigurosidad posible, los trminos utilizados en esta gua y relacionados con CMMI que estn en castellano han sido extrados de la traduccin realizada por la Ctedra de Mejora de Procesos de Software en el Espacio Iberoamericano de la Universidad Politcnica de Madrid, publicada por el SEI como traduccin de la versin 1.2 de CMMI for Development y titulada CMMI: Gua para la integracin de procesos y la mejora de productos [2]. 1.2 Versin del modelo

Esta gua est basada en la versin 1.2 del mtodo SCAMPI (ver captulo 2) de CMMI [3]. En el momento de elaboracin de esta gua, la versin 1.3 [4] del citado mtodo acababa de ser liberada. Sin embargo, la versin 1.2 es an la de mayor uso y sobre la que se tiene una mayor experiencia, por lo que esta gua entra en detalle en esa versin del mtodo. Los detalles ms importantes en los que se diferencian las versiones 1.2 y 1.3 del SCAMPI son comentados a lo largo de esta gua. Por otro lado, si bien existen actualmente 3 constelaciones CMMI, este documento se centra en el modelo CMMI-DEV, que corresponde a desarrollo.

Las auditoras CMMI

Cuando una organizacin ha conseguido mejorar sus procesos e implantar los correspondientes a un nivel de madurez CMMI (ver anexo), es comn que decida que ha llegado el momento de presentarse a una auditora que corrobore dicha implantacin por un tercero, un auditor externo. Y es ah cuando aparecen una serie de peculiaridades, tareas y trminos que suelen causar mucha confusin en el equipo de mejora. En este captulo aclararemos las principales dudas de carcter general que se plantean en el momento de comenzar con una auditora CMMI. 2.1 Qu es un SCAMPI A y quin lo realiza?

Se denomina as a la evaluacin o auditora final de concesin oficial de un nivel de madurez de CMMI. SCAMPI es el acrnimo de Standard CMMI Appraisal Method for Process Improvement [3]. Este es un mtodo sobre cmo evaluar los diferentes procesos de la organizacin, definiendo el nivel de madurez. Se distinguen tres tipos de SCAMPI (A, B C) en funcin de la formalidad y la dificultad del mismo. El ms riguroso es el SCAMPI A y es el que permite obtener el nivel de madurez oficial. Una vez superado el SCAMPI A, es comn que la organizacin reciba un diploma acreditativo que indica el nivel de madurez alcanzado. El SCAMPI A debe ser realizado por una figura denominada Lead Appraiser. El Lead Appraiser es una persona acreditada por el SEI (Software Engineering Institute, organizacin propietaria del modelo CMMI) para realizar la evaluacin CMMI. Finalmente, es el Lead Appraiser quin emite lo que se conoce como Appraisal Disclosure Statement, documento que muestra los resultados de la evaluacin [5]. 2.2 Quin respalda una auditora CMMI?

Comnmente se piensa que es el Software Engineering Institute (SEI), ya que es la organizacin propietaria del modelo. Sin embargo, el SEI solamente acredita a los auditores o Lead Appraiser para que puedan realizar evaluaciones CMMI. No es el SEI quien emite un certificado, sino que son los auditores los que emiten un diploma en el que se indican los datos y resultados de la auditora. Son estos auditores y las empresas partner del SEI en las que trabajan los que se responsabilizan de los resultados de la evaluacin. Por ello normalmente se utiliza el concepto evaluacin en vez de certificacin cuando nos referimos a una auditora CMMI.

2.3

Durante cunto tiempo son vlidos los resultados de la evaluacin?

Los resultados de la evaluacin son vlidos durante un mximo de 3 aos desde la fecha en que se emite el Appraisal Disclosure Statement. 2.4 Es necesario evaluar todas las reas de proceso?

En funcin del nivel de madurez que se pretenda alcanzar, ser necesario evaluar una serie de reas de proceso. Todas las reas de proceso correspondientes a un nivel de madurez son obligatorias a excepcin de SAM (Supplier Agreement Management) (ver anexo para el listado completo de reas de proceso de CMMI por nivel de madurez), que puede no ser aplicable a la organizacin y por tanto no ser evaluada. 2.5 Qu costes internos han de tenerse en cuenta?

Adems de los costes propios de contratar la auditora, es necesario tener en cuenta que 4 personas deben de participar plenamente durante la misma (aproximadamente entre 8 y 12 das). Estas 4 personas deben cumplir con unos requisitos bastante estrictos (ver captulo 5) por lo que normalmente se corresponden con perfiles cualificados dentro de la empresa. Por lo tanto, no hay que olvidar que la organizacin tendr que soportar unos costes internos.

Fases y la duracin de la auditora

La realizacin de una auditora CMMI requiere llevar a cabo una serie de actividades. El mtodo SCAMPI define varias actividades a realizar, que abarcan desde que la definicin de los objetivos de la auditora hasta el reporte de los resultados de la evaluacin. Para evitar complejidad innecesaria, no vamos a detallar todas las etapas, slo las que afectan ms a la organizacin, que agruparemos en 3 fases. Para cada una de estas fases, se indica una estimacin de su duracin. Hay que destacar que estas duraciones se refieren a la duracin temporal de cada una de las fases, no al esfuerzo necesario para realizarlas (no son das/hombre): Preparacin y planificacin de la auditora: en esta fase se seleccionan los objetivos de la mejora, se define el mtodo de captura de evidencias, etc. Esta fase es realizada por el Lead Appraiser y tiene una duracin aproximada de 2 jornadas. Readiness-review: en esta fase se estudia si la organizacin est preparada para la auditora. La duracin de esta fase, que es realizada por el equipo de evaluacin, es de aproximadamente 3 jornadas. Ampliaremos la informacin de esta fase en el captulo 6.

Ejecucin de la auditora y comunicacin de resultados: durante esta actividad se realiza la auditora final de concesin de un nivel de madurez de CMMI. Es realizada por el equipo de evaluacin, y tiene una duracin estimada de 5 jornadas para el nivel de madurez 2 y de 10 jornadas para el nivel de madurez 3.

Fig. 1. Fases de una evaluacin SCAMPI

Los proyectos que sern auditados y la unidad organizacional

Cuando se va a realizar una auditora SCAMPI, es necesario tener claro qu parte de la organizacin va a ser evaluada. Al subconjunto de la organizacin que ser evaluado se le denomina unidad organizacional. Este punto es importante porque una vez concedido el nivel, el diploma que nos entreguen contendr explcitamente la unidad organizacional evaluada. Por otro lado, una vez definida la unidad organizacional, se determinar qu proyectos van a ser evaluados del total de la misma, estos proyectos formarn la muestra de proyectos. 4.1 La unidad organizacional

La unidad organizacional se corresponde con la parte de la organizacin que va a ser evaluada. Las partes o departamentos de una organizacin que componen la unidad organizacional debern tener unos objetivos de negocio comunes y un conjunto de procesos coherentes. Una unidad organizacional puede ser un departamento, un conjunto de departamentos, una tipologa de proyectos, etc., o, en caso de ser una empresa pequea, toda la organizacin. Por ejemplo, puede darse el caso de una empresa multinacional con sedes en Madrid, Buenos Aires y Cceres que defina que la unidad organizacional sea solamente una de las sedes. Pero tambin puede darse el caso de una organizacin con varias sedes pero con tres departamentos bien definidos (desarrollos internos, desarrollos a medida y desarrollos para

sistemas empotrados) que decida que la unidad organizacional sea el departamento de desarrollos a medida, aunque este involucre a varias sedes. 4.2 La muestra de proyectos

Cuando se va a realizar una evaluacin SCAMPI, normalmente no se evalan todos los proyectos de la unidad organizacional, sino que se selecciona una muestra de proyectos representativa de la misma. La seleccin de los proyectos adecuados para la muestra es una tarea importante dentro de una auditora CMMI, ya que estos deben cubrir todos los factores crticos que se identifiquen dentro de la unidad organizacional. A la hora de realizar la evaluacin, se distinguen tres tipos de proyectos, que pueden formar parte de la muestra1: Proyecto objetivo: es un proyecto que aporta evidencia objetiva (veremos qu es una evidencia en el captulo 7) de todas las reas de proceso del nivel de madurez a evaluar. A la hora de evaluar el proyecto no importa si este ha terminado o no (hay por ejemplo proyectos que estn en mantenimiento un gran nmero de aos), solamente se comprueba si proporciona evidencia para cada una de las reas de proceso definidas en el nivel CMMI a evaluar. Un ejemplo de un proyecto de este tipo puede ser un proyecto de desarrollo para un cliente que se encuentra al final de la fase de pruebas. En el caso de que a lo largo del proyecto se hayan seguido correctamente los procesos definidos en la organizacin, el proyecto podr proporcionar evidencia de cada una de las reas de proceso del nivel de madurez evaluado. Proyecto no objetivo: es un proyecto que aporta evidencia objetiva de alguna de las reas de proceso dentro del alcance de la evaluacin. Estos proyectos sirven como complemento de los proyectos objetivos, para obtener mayor nmero de evidencias de la realizacin de cada una de las prcticas definidas en CMMI (explicaremos qu es una prctica en el captulo 7). Un ejemplo de un proyecto de este tipo puede ser un proyecto de desarrollo de una Web iniciado en las ltimas fases de la implantacin de CMMI, y que se encuentra an en el anlisis de requisitos. Este proyecto puede proporcionar evidencias en algunas reas de proceso, como en la Gestin de Requerimientos, pero difcilmente podr proporcionar evidencias para todas las reas de proceso de nivel de madurez 2. Funcin de apoyo: funcin organizativa que aporta evidencia objetiva de las reas de proceso organizativas, por ejemplo formacin, el aseguramiento de la calidad, RRHH, etc. Para superar una evaluacin SCAMPI, es necesario presentar al menos un proyecto objetivo. Adems, es necesario presentar tantos proyectos, objetivos o no objetivos, como
1

A partir de la versin 1.3 de SCAMPI ya no se distingue entre proyectos objetivos y no objetivos. Adems, los proyectos pasan a ser denominados unidades bsicas.

sean necesarios para obtener al menos 3 evidencias de la realizacin de cada una de las prcticas de cada rea de proceso a evaluar.2 Esto no es as para todas las reas de proceso. CMMI cuenta con algunas reas de proceso que son a nivel de organizacin (por ejemplo, Formacin organizativa - OT)3. En el caso de las prcticas de estas reas de proceso, slo es necesario proporcionar una evidencia, por lo que la cuestin de nmero de proyectos no aplica para ellos.

Los participantes en la auditora

Para poder llevar a cabo una auditora CMMI, es necesario un equipo de trabajo que cumpla unos requisitos mnimos. De esta manera se asegura la experiencia, el conocimiento y las habilidades necesarias para participar en la auditora. El personal necesario para participar en actividades o realizar tareas en una evaluacin SCAMPI A (tanto de la organizacin a evaluar como de la organizacin evaluadora) incluye los siguientes roles: Sponsor. Es el encargado de liderar el proyecto de mejora. Normalmente, se corresponde con un directivo de la organizacin. Jefe del equipo de evaluacin (Appraisal Team Leader). Responsable de realizar la evaluacin. El jefe del equipo de evaluacin debe ser un Lead Appraiser, y pertenecer a una empresa partner del Software Engineering Institute (SEI) para poder realizar la evaluacin, as como tener la experiencia y entrenamiento necesario. Coordinador de la organizacin (Organizational Unit Coordinator u OUC). Encargado de facilitar la realizacin de la auditora. Proporciona la informacin necesaria al evaluador. Es comn que se corresponda con el responsable de calidad de la organizacin. Miembros del equipo de evaluacin (Appraisal Team Members o ATM). Personal de la organizacin a auditar y que cumple con los requisitos para formar el equipo de evaluacin, y que cuenta con la experiencia y el entrenamiento suficiente. Participantes seleccionados. Encargados de proporcionar la informacin necesaria. Es comn que sean jefes de proyecto de los proyectos evaluados. La evaluacin SCAMPI A debe ser realizada por un equipo evaluador formado por un evaluador lder -SCAMPI Lead Appraiser y 4 integrantes (ATM). Cada uno de estos 4
2

En la versin 1.3 de SCAMPI, el nmero de proyectos a incluir en la muestra se calcula cuantitativamente, en funcin del nmero de los subgrupos (proyectos de la organizacin que cuentan con unas mismas caractersticas para la implementacin de los procesos en cuanto a lugar de implementacin, cliente, tamao, etc.) y de las unidades bsicas. 3 Los procesos y sus acrnimos pueden ser consultados en el Anexo de este documento.

ATM, debe satisfacer los siguientes requisitos: Debe haber asistido previamente al curso oficial del SEI Introduction to CMMI. Debe tener disponibilidad completa durante la evaluacin (fases de preparacin y ejecucin). Aproximadamente 8 y 12 das para los niveles de madurez 2 y 3 respectivamente. Debe ser independiente de los proyectos evaluados. No podr por tanto ser responsable de ninguno de los proyectos seleccionados para la evaluacin, ni ser responsables directos o indirectos de aquellas personas que sern entrevistadas durante la evaluacin. Cada miembro del equipo evaluador debe tener al menos 6 aos de experiencia promedio en el campo de desarrollo software y la suma de experiencias de los miembros del equipo debe ser de al menos 25 aos como experiencia total del grupo. Es recomendable que cada miembro del equipo tenga al menos 3 aos de experiencia en cada una de las disciplinas que sern parte de la evaluacin 4. Al menos un miembro del equipo de evaluacin deber tener al menos 6 aos de experiencia en la gestin de proyectos software. El equipo evaluador en total deber tener al menos 10 aos de experiencia en dicha gestin. El equipo de evaluacin deber tener unos conocimientos adecuados de las diferentes fases del ciclo de vida de desarrollo de los proyectos y sobre diferentes entornos y dominios de negocio de los proyectos de la organizacin evaluada. Al menos dos miembros del equipo han de tener experiencia prctica. Es altamente recomendable que los miembros del equipo de evaluacin puedan leer documentacin tcnica en ingls, dado que mucho del material de soporte del mtodo SCAMPI est en este idioma. El SCAMPI Lead Appraiser es quien finalmente decide la aceptacin o no de los miembros del equipo evaluador y es el responsable de asegurar que sus cualificaciones y su sostenibilidad estn acordes con el propsito de la evaluacin.

La fase Readiness review

El objetivo de esta fase es conocer si la organizacin est preparada para afrontar la auditora. En esta fase se analizan las evidencias objetivas, la preparacin del equipo de evaluacin y la preparacin logstica (instalaciones, equipamiento, disponibilidad, etc.) para conocer si es posible llevar a cabo la auditora. Tras la realizacin de esta etapa, se decide si continuar con el plan tal como estaba previsto, si es necesario realizar una re-planificacin o si es mejor cancelar el proyecto. El Lead Appraiser es el responsable de tomar esta decisin, en funcin de los resultados de la realizacin de esta evaluacin.

En la versin 1.3 de SCAMPI, los requisitos para formar parte del equipo de evaluacin se han modificado ligeramente. Ya no es necesario tener 3 aos de experiencia en el campo de la evaluacin, sino 2 aos. Adems, se han endurecido los requisitos para los niveles altos de madurez.

En la fase readiness review deben participar al menos: El jefe del equipo de evaluacin. Es recomendable que participe al menos un representante de cada proyecto evaluado dentro de la unidad organizacional. Cualquier otro representante de la unidad organizacional que se desee. Las tareas principales que se realizan en esta fase son las siguientes: Evaluar las evidencias para la auditora. En esta fase, se analizan las PIIDB o bases de datos de evidencias (en el captulo 7 se trata en detalle este tema), analizando los artefactos incorrectos, los que faltan y los que estn incompletos, para los diferentes proyectos de la muestra. Evaluar las instalaciones, el equipamiento y la disponibilidad del equipo, para concretar si es posible llevar a cabo una auditora CMMI. Evaluar la preparacin del equipo. En esta fase se realiza una formacin para que el equipo est preparado para la auditora. Durante esta fase se determina si el equipo est preparado para superar una evaluacin CMMI, para lo que se analiza cmo operan los equipos entre s, su efectividad, etc. Una vez que se ha completado la fase Readiness Review, se lleva a cabo la evaluacin final, que en caso de superarla da como resultado el nivel de madurez alcanzado.

Los indicadores de implementacin de la prctica (PII) y la base de datos de indicadores (PIIDB)

Para comprender qu son los indicadores de implementacin de la prctica es necesario conocer primero la estructura de un rea de proceso. Las reas de proceso estn compuestas de unos objetivos, que deben ser alcanzados para cumplir con el rea de proceso. Se distinguen dos tipos de objetivos, los objetivos genricos (GG), que son comunes a todas las reas de proceso, y los objetivos especficos (SG), que son definidos por cada rea de proceso. Estos objetivos se dividen a su vez en prcticas, que son actividades que se consideran importantes para alcanzar el objetivo del rea de proceso. Se distinguen tambin dos tipos de prcticas, las prcticas genricas (GP), que son comunes a todas las reas de proceso, y las prcticas especficas (SP), que son propias de cada rea de proceso. La Figura 2 muestra como se estructura un rea de proceso en cuanto a sus objetivos y prcticas.

Fig. 2. Estructura de un rea de proceso

Cuando se est realizando una auditora CMMI, es necesario comprobar que todos los objetivos de cada rea de proceso definida en el nivel de madurez a evaluar han sido alcanzados. Para ello, se comprueba que todas las prcticas definidas de cada objetivo han sido satisfechas5. Si esto es as, la realizacin de cada prctica dejar algn tipo de rastro (por ejemplo un documento, un acta de reunin, un email, etc.). A estos rastros se les conoce como indicadores de implementacin de la prctica6 (Practice Implementation Indicators o PII), que son, por lo tanto, el resultado de la implementacin de una prctica y que sirven para comprobar que esta implementacin se ha realizado correctamente. Estos indicadores de implementacin es lo que busca el auditor durante la auditora para comprobar que se est realizando cada una de las prcticas y que se alcanzar, por lo tanto, cada uno de los objetivos del rea de proceso correspondiente. Se distinguen tres tipos de PII: Artefacto directo: salidas tangibles que resultan de la implementacin directa de una prctica. Los artefactos directos pueden ser documentos, entregables, productos, material de formacin, etc. Un ejemplo de un artefacto directo para el SP 1.2 del proceso de Planificacin del Proyecto, Establecer las estimaciones de los atributos del producto de trabajo y de las tareas, puede ser un documento con la estimacin de cierto proyecto resultante de la aplicacin del mtodo de estimacin por analoga. Casos especiales en artefactos directos: En el caso de algunas prcticas, pueden aceptarse documentos como artefactos directos incluso si estos no tienen el objetivo primario de conseguir la prctica. Por ejemplo, para la prctica especfica SP 1.2 del proceso de Gestin de Configuracin: Establecer un

Esto es as en la mayora de las auditoras, aunque el modelo deja claro que los objetivos son obligatorios pero las prcticas son solamente recomendadas. 6 A partir de la versin 1.3 de SCAMPI, los indicadores de implementacin de la prctica pasan a llamarse evidencias objetivas.

sistema de gestin de la configuracin, puede ser considerado un artefacto directo un esquema o descripcin del sistema de libreras del gestor de configuracin. Artefacto indirecto: artefactos que son consecuencia de la implementacin de una prctica, pero que no son el propsito para el cual se realiza la prctica. Los artefactos indirectos pueden ser actas de reunin, informes de estado, presentaciones, correos electrnicos, etc. Un ejemplo de artefacto indirecto para el SP 1.2 del proceso de Planificacin del Proyecto, Establecer las estimaciones de los atributos del producto de trabajo y de las tareas, puede ser un informe con las horas imputadas a la realizacin de la estimacin por analoga del proyecto. Afirmacin: confirmaciones de palabra (entrevistas) o escritas que corroboran la implementacin de una prctica especfica o genrica. Ejemplos: entrevistas, teleconferencias, cuestionarios, etc. Los PII son utilizados por tanto para demostrar que existe evidencia objetiva de la implementacin de cada una de las prcticas (ya sean especficas SP- o genricas SG-) que van a ser evaluadas. Para que exista evidencia objetiva, el mtodo SCAMPI indica que debe existir un artefacto directo que demuestre el propsito de la prctica y que este a su vez sea corroborado por artefactos directos o afirmaciones7. Por lo tanto, para comprobar que existe evidencia objetiva de la implementacin de la prctica, puede utilizarse la siguiente frmula: EVIDENCIA OBJETIVA = ARTEFACTO DIRECTO AND (ARTEFACTO INDIRECTO OR AFIRMACION) 7.1 La PIIDB

Una Base de Datos de Indicadores de Implementacin de la Prctica 8 (Practice Implementation Indicators DataBase o PIIDB) es una base de datos que almacena evidencias de la implementacin de las diferentes prcticas (SP y SG) definidas en CMMI. Las organizaciones pueden proporcionar una PIIDB como entrada a la evaluacin9 (de hecho es muy recomendable trabajar desde el inicio con una PIIDB, para ordenar el trabajo
7

Para la versin 1.3 se han realizado intentos de simplificacin para la recoleccin de evidencias. A

partir de la versin 1.3, no existirn artefactos directos e indirectos, sino que sern conocidos como artefactos simplemente. Con ello, simplemente ser necesario centrarse en que existen artefactos que cumplan con la prctica evaluada. Por su parte, las afirmaciones debern ser ms completas, de manera que ayuden a entender la prctica. A partir de la versin 1.3, la frmula para comprobar la existencia de una evidencia es: EVIDENCIA = ARTEFACTO AND AFIRMACIN
8 9

A partir de la versin 1.3 de SCAMPI, la PIIDB pasa a llamarse Base de Datos de Evidencias Objetivas. Una PIIDB est compuesta de tantas Descripciones de PII (PII Description o PIID) como prcticas existan en las reas de proceso que van a ser evaluadas. Una PIID es una estructura que almacena la informacin necesaria de un PII (por ejemplo su descripcin, el artefacto directo, el artefacto indirecto y la afirmacin).

y obtener una evaluacin constante). Esta PIIDB mostrar la trazabilidad de las prcticas del modelo a las reas de proceso correspondientes y a las evidencias objetivas usadas para verificar la implementacin de la prctica. En la Figura 3 se muestra un extracto de una PIIDB, en la que se muestran los campos a completar para la prctica 1.4 Determinar estimaciones de esfuerzo y costes del rea de proceso de planificacin del proyecto (PP). Para que exista evidencia objetiva de la realizacin de esta prctica, este extracto de la PIIDB debera contener para cada proyecto un artefacto directo y un artefacto indirecto o una afirmacin.

Fig. 3. Campos a completar en una PIIDB para una prctica Tabla 1. La PIIDB de nivel 2 en nmeros

La PIIDB de nivel 2 en nmeros Por cada rea de proceso (en total son 7) y por cada prctica especfica (SP) y cada prctica genrica (SG) ser necesario completar un total de entre 6 y 9 indicadores (PII). La diferencia est en si se presenta solo un artefacto indirecto, solo una afirmacin o ambos. En ocasiones la misma empresa buscar tener ambos indicadores para dar mayor fortaleza a la evidencia. La cantidad total de SP y SG es de 136. La cantidad total de indicadores entonces sern entre 816 y 1224.

Ejemplo de PIIDB

Normalmente, completar una PIIDB es una tarea extensa y que lleva asociados unos importantes costes internos. Es por ello que se recomienda comenzar a trabajar con ella cuanto antes, e ir completando progresivamente los indicadores, consiguiendo as encontrar y comprobar tanto los puntos fuertes del proceso de desarrollo como los aspectos ms dbiles, en los que deberan centrarse los mayores esfuerzos. A lo largo de este captulo vamos a detallar ejemplos de artefactos directos e indirectos para cada una de las prcticas de las reas de proceso de nivel 2. Estas tablas deben tomarse solo como un ejemplo, por lo que en la implantacin que las empresas llevan a cabo pueden encontrarse otros artefactos.

8.1

Prcticas genricas de nivel 2

Tabla 2. Prcticas genricas de nivel 2

GP 2.1 Establecer una poltica de la organizacin

GP 2.2 Planificar el proceso

GP 2.3 Proporcionar recursos

GP 2.4 Asignar responsabilidad GP 2.5 Formar al personal

ARTEFACTO DIRECTO Plan de calidad que contemple el desarrollo software, los procesos de nivel 2 y que se encuentre firmado y respaldado por la gerencia. Documentos para planificar cada uno de los procesos, y que contienen su descripcin, sus objetivos, sus responsabilidades, sus dependencias, las mediciones a realizar para el proceso, etc. Descripcin de los equipos y recursos (humanos y materiales) disponibles para la realizacin del proceso. Documento de roles y responsabilidades para cada proceso. Tareas de formacin realizadas: temario de los mismos, materiales, objetivos de la realizacin de la formacin, exmenes, etc. Gestor de configuracin del cdigo fuente (SVN, CVS, etc.). Gestor de configuracin documental (SharePoint, wiki, etc.). Sistemas de copias de seguridad.

ARTEFACTO INDIRECTO Comunicacin del plan de calidad a la empresa (correos, wiki, pgina Web, etc.).

Horas proyecto.

imputadas

al

Facturas de compra de equipos o de herramientas. Horas imputadas a las tareas de gestin del proyecto. Actas de reunin convocadas en las que se nombran los responsables. Informe de asistencia a los cursos de formacin por parte del personal.

GP 2.6 Gestionar configuraciones

Logs que muestren el uso de cada una de las herramientas de gestin de configuracin.

GP 2.7 Identificar e involucrar a las partes interesadas relevantes GP 2.8 Monitorizar y controlar el proceso

Plan de comunicacin establecido en el que se identifican a los implicados en el proceso. Informes de medicin intermedios de los productos software. Informes de medicin del rendimiento de los procesos. Informes de auditora interna y externa de los procesos.

Actas de reunin en la que participan los diferentes involucrados en el proyecto. Correos de convocatoria. Acciones correctivas asociadas a las mediciones del rendimiento de los procesos. Comunicacin de los resultados.

GP 2.9 Evaluar objetivamente la adherencia GP 2.10 Revisar el estado con el nivel directivo

Horas imputadas a tareas de auditora. Registros de auditora, contratacin de auditores, etc. Actas de reunin, convocatorias, calendario de planificacin, etc.

Resultado de la reunin con la direccin para revisar los procesos de la organizacin.

8.2

rea de proceso: Gestin de Acuerdos con Proveedores (SAM)

Tabla 3. rea de proceso: Gestin de Acuerdos con Proveedores (SAM)

ARTEFACTO ARTEFACTO DIRECTO INDIRECTO SG 1 Establecer los acuerdos con proveedores SP 1.1 Determinar el tipo de compra Poltica de acuerdos con proveedores, definiendo los tipos de compras posibles (productos off-the-shelf, productos a medida, etc.). Plantilla de homologacin de proveedores. Listado de proveedores. Contrato con el proveedor. Requisito del proyecto donde se describe el mdulo a contratar.

SP 1.2 Seleccionar los proveedores

Informe de homologacin.

SP 1.3 Establecer los acuerdos con el proveedor

Acta de reunin donde se ha realizado el acuerdo.

SG 2 Satisfacer los acuerdos del proveedor SP 2.1 Realizar el acuerdo del proveedor Informes de cierre de acuerdos y de progreso del proveedor. Informes de seguimiento del proveedor. Informes de discrepancias. Listado de productos de trabajo seleccionados a evaluar del proveedor e informes sobre la seleccin. Procedimiento y resultados de pruebas de aceptacin. Planes de transicin y despliegue, gestin del cambio, paso a produccin, a pre-produccin, etc. Informes de formacin sobre los nuevos productos. Incidencias registradas. Actas de reuniones de seguimiento. Horas imputadas a la monitorizacin de actividades del proveedor.

SP 2.2 Monitorizar los procesos seleccionados del proveedor

SP 2.3 Evaluar los productos a medida seleccionados del proveedor SP 2.4 Aceptar los productos adquiridos SP 2.5 Transferir los productos

Horas imputadas a la evaluacin de productos de terceros. Incidencias resolucin. histricas y

Horas imputadas por cada empleado involucrado a actividades de formacin relacionadas con el producto. Informe de incidencias durante el despliegue.

8.3

rea de proceso: Gestin de requerimientos (REQM)

Tabla 4. rea de proceso: Gestin de requerimientos (REQM)

ARTEFACTO DIRECTO SG 1 Gestionar los requerimientos SP 1.1 Obtener una comprensin de los requerimientos Aplicacin de un listado de criterios definidos para la evaluacin y la aceptacin de los requisitos. Resultados del anlisis de los requisitos frente a los criterios de aceptacin. Documento de requisitos aceptado.

ARTEFACTO INDIRECTO Correos electrnicos o actas de reunin en los cuales se evidencia el entendimiento, negociacin o cambio de requisitos. Histrico requisitos de cuyo

SP 1.2 Obtener el compromiso sobre los

requerimientos Acta de reunin donde se aceptan los requisitos. Peticiones de cambio asociadas con requisitos. Requerimientos versionados. Tareas para cada peticin de cambio: trazabilidad de la peticin de cambio con las tareas. SP 1.4 Mantener una trazabilidad bidireccional de los requerimientos Matriz de trazabilidad entre requisitos y los dems elementos que componen el producto software (ej. diseo, casos de prueba, cdigo fuente, etc.). Informe de pruebas. Listado de inconsistencias.

estado pasa a ser aceptado. Histrico de requisitos cuyo estado haya pasado a abierto tras haber sido cerrado. Estimacin de las tareas asociadas al cambio en un requisito. Anlisis de cambio donde se ha utilizado la matriz de trazabilidad para valorar el impacto. Acciones correctivas asociadas a las inconsistencias encontradas entre el proyecto y los requisitos.

SP 1.3 Gestionar los cambios en los requerimientos

SP 1.5 Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos

8.4

rea de proceso: Planificacin de Proyecto (PP)

Tabla 5. rea de proceso: Planificacin de Proyecto (PP)

SP 1.1 Estimar el alcance del proyecto

SP 1.2 Establecer las estimaciones de los atributos del producto de trabajo y de las tareas

ARTEFACTO ARTEFACTO DIRECTO INDIRECTO SG 1 Establecer estimaciones Oferta o plan de Horas imputadas a la tarea proyecto donde se indican de estimacin del alcance, el alcance del sistema. oferta inicial, estudio de viabilidad, etc. Descripcin de las tareas a realizar durante el proyecto. Diagrama de Gantt en el Horas imputadas a la que se describen la duracin realizacin de la estimacin de las tareas, en base a una por analoga, punto funcin, estimacin por analoga. puntos pker, etc.

Planificacin del sprint backlog. Informe con los resultados de la estimacin. Una seccin, usualmente incorporada al plan de proyecto donde se describen las fases que contendr el proyecto (anlisis, diseo, despliegue, iteraciones, etc.), la relacin entre estas fases y su ordenacin temporal (cascada, iterativo, incremental, etc.). Informe en el que se representan los resultados de la estimacin del esfuerzo necesario y el mtodo usado. Hoja de costes para el proyecto y el procedimiento de clculo. Definicin de recursos necesarios (memoria, capacidad de red, etc.) para la realizacin del proyecto. SG 2 Desarrollar un plan de proyecto Seccin de presupuesto Horas imputadas a la tarea del documento del plan de de elaboracin del Proyecto. presupuesto y calendario. Diagrama de PERT en el que se identifican las distintas tareas y sus dependencias. Matriz de riesgos identificados para el proyecto. Checklist que evala los riesgos para el proyecto. Herramienta de clculo de esfuerzo y coste completada.

SP 1.3 Definir el ciclo de vida del proyecto

Hitos definidos en un diagrama de Gantt.

SP 1.4 Determinar las estimaciones de esfuerzo y costes

Horas imputadas a la tarea de estimacin. Herramienta de clculo de esfuerzo y coste completada.

SP 2.1 Establecer el presupuesto y el calendario

SP 2.2 Identificar los riesgos del proyecto

Catlogo riesgos.

genrico

de

Horas imputadas a la tarea de identificacin de riesgos.

SP 2.3 Planificar la gestin de los datos

Listado de los datos gestionados en el proyecto, con la descripcin del formato, requisitos de privacidad y seguridad. Descripcin del sistema de Backup. Datos que requieren confidencialidad. Listado de equipamiento, instalaciones y software asociado con el proyecto. Listado de recursos humanos necesarios. Listado de habilidades necesarias por parte de los miembros del equipo. Plan de personal y de nuevas contrataciones. Listado de los participantes del proyecto y rol que juegan en el mismo. Comunicacin formal a las personas que participarn en el proyecto (cliente, desarrolladores, equipo de pruebas, etc.). Plan de comunicacin y relaciones entre los participantes. Plan de proyecto.

Estructura de carpetas y permisos para controlar datos confidenciales. Logs de backups realizados para el proyecto.

SP 2.4 Planificar los recursos del proyecto

Orden de equipamiento.

compra

de

Acta de reunin interna de arranque. Actividades de formacin para los perfiles del proyecto. Material de formacin.

SP 2.5 Planificar el conocimiento y las habilidades necesarias

SP 2.6 Planificar la involucracin de las partes interesadas

Acta de reunin de arranque del proyecto en la que participan tanto el cliente como los principales involucrados en el proyecto y se explica el plan de comunicacin.

SP 2.7 Establecer el plan de proyecto

Horas imputadas a la tarea de planificacin.

SP 3.1 Revisar los planes que afectan al proyecto

Plantilla de plan de proyecto. SG 3 Obtener el compromiso con el plan Matriz de relaciones Registro de resolucin de entre proyectos, conflictos (correo, acta, etc.). planificacin de proyectos y recursos asignados en la

unidad organizacional. Documento con la ocupacin de recursos de la organizacin. Presupuestos renegociados. Control de la asignacin y capacidad de los recursos Reestimacin de las tareas de los implicados que tengan una dedicacin que no sea aceptable. Aceptacin por los afectados del plan de proyecto.

SP 3.2 Reconciliar los niveles de trabajo y de recursos

Revisin en herramienta de gestin de personal y control de horas, as como el ajuste de recursos y tareas.

SP 3.3 Obtener el compromiso con el plan

Acta de reunin de inicio del proyecto con la participacin del equipo.

8.5

rea de proceso: Monitorizacin y Control del Proyecto (PMC)

Tabla 6. rea de proceso: Monitorizacin y Control del Proyecto (PMC)

ARTEFACTO ARTEFACTO DIRECTO INDIRECTO SG 1 Monitorizar el proyecto frente al plan SP 1.1 Monitorizar los parmetros de planificacin del proyecto Actas de las reuniones de seguimiento llevadas a cabo. Herramienta de seguimiento (por ejemplo Gantt de seguimiento, Trac, etc.). Identificacin de desviaciones en el proyecto. Actas de reunin de seguimiento, informes de avance, de cumplimiento de hitos, etc. Histrico de cambios en los riesgos. Registro de la revisin de las horas imputadas al proyecto.

SP 1.2 Monitorizar los compromisos

Horas imputadas seguimiento del proyecto.

al

SP 1.3 Monitorizar los riesgos del proyecto

Acta de reunin de seguimiento en la que se tratan explcitamente los riesgos del

SP 1.4 Monitorizar la gestin de datos

Identificacin de nuevos riesgos a lo largo del proyecto. Servidor de integracin continua. Registro de tareas de gestin de datos. Actas de reunin de entrega de hitos intermedios. Informes de avance del seguimiento. Actas de reunin de seguimiento.

proyecto.

Logs del backups.

sistema

de

SP 1.5 Monitorizar la involucracin de las partes interesadas SP 1.6 Llevar a cabo revisiones de progreso

Histrico de revisiones en gestor de configuracin. Correos o notificaciones entre los implicados. Horas imputadas por parte del equipo a tareas del proyecto. Impedimentos detectados durante las reuniones de seguimiento. Histrico de entregables. Histrico de incidencias.

SP 1.7 Llevar a cabo revisiones de hitos

Actas de reunin de entrega intermedia, reuniones intermedias de chequeo con el cliente.

Riesgos del proyecto Acta de reunin de final revisados durante la de un Sprint. realizacin del hito. SG 2 Gestionar las acciones correctivas hasta su cierre SP 2.1 Analizar Incidencias registradas y Peticiones de cambio problemas analizadas. asociadas. Planificacin modificada incluyendo las incidencias y su estimacin. Incidencias resueltas. Histrico de cambios de estado de las incidencias Acta de reunin al final del hito en la que se incluye la revisin de las incidencias y las acciones correctivas asociadas.

SP 2.2 Llevar a cabo las acciones correctivas

Documento o registro de acciones correctivas.

SP 2.3 Gestionar las acciones correctivas

Histrico de acciones correctivas, participantes, planes derivados, etc.

8.6

rea de Proceso: Gestin de Configuracin (CM)

Tabla 7. rea de Proceso: Gestin de Configuracin (CM)

SP 1.1 Identificar elementos de configuracin

SP 1.2 Establecer un sistema de gestin de la configuracin

ARTEFACTO ARTEFACTO DIRECTO INDIRECTO SG 1 Establecer lneas base Documento o Tiempo dedicado a su herramienta donde se elaboracin, horas, actas, etc. identifican los elementos de configuracin de las lneas base. Pueden ser productos que se entregan al cliente, herramientas, diseos, planes de pruebas, prototipos, resultados de pruebas, documentos, etc. Herramienta de gestin Histrico de revisiones y de la configuracin (SVN, roles de acceso al sistema de CVS, etc.). gestin de la configuracin. Logs de herramientas de gestin de configuracin. Histrico de entregas formales realizadas.

SP 1.3 Crear o liberar lneas base

SP 2.1 Seguir las peticiones de cambio SP 2.2 Controlar los elementos de configuracin

Descripcin de las entregas formales a realizar durante el proyecto, tanto de productos software como de documentacin, describiendo los elementos que contiene. SG 2 Seguir y controlar los cambios Peticiones de cambio Registro con la aprobacin realizadas durante el o denegacin de un cambio en proyecto. el sistema. Servidor de integracin Logs de ejecuciones del continua que integra servidor de integracin peridicamente el cdigo continua. realizado hasta ese momento, identificando Registros de auditora errores o conflictos. interna o externa. No conformidades identificadas durante las auditoras internas y externas.

SP 3.1 Establecer registros de gestin de la configuracin

SP 3.2 Realizar auditoras de configuracin

SG 3 Establecer la integridad Revisiones de las tareas Incidencias en la gestin de de gestin de configuracin configuracin (ej. establecimiento de ramas, Revisiones de los merges que no funcionan). cambios implementados entre dos versiones de la Histrico de cambios en la lnea base. herramienta de gestin de la configuracin. Informe de auditora No conformidades interna o externa. extradas de la realizacin de la auditora.

8.7

rea de proceso: Medicin y Anlisis (MA)

Tabla 8. rea de proceso: Medicin y Anlisis (MA)

ARTEFACTO ARTEFACTO DIRECTO INDIRECTO SG 1 Alinear las actividades de medicin y anlisis SP 1.1 Establecer los Documento con los Correos de sugerencias de objetivos de medicin objetivos de medicin, indicadores. donde se indican los objetivos de negocio y su Histrico de indicadores. relacin con los indicadores de medicin. SP 1.2 Especificar las Descripcin de los Actas de reunin para la medidas indicadores de medicin: definicin de los indicadores. unidades de medida, mecanismo de recogida, Histrico de resultados de periodicidad de la las mediciones. recoleccin, objetivo de la medicin, etc. Catlogo genrico de mtricas. SP 1.3 Especificar los Descripcin de los Procedimiento de medicin procedimientos de indicadores de medicin: y anlisis desarrollado. recogida y de unidades de medida, almacenamiento de datos mecanismo de recogida, Logs de las herramientas etc. de recoleccin automtica de datos. Seccin en la documentacin donde se indica cmo se almacenan

los datos. Descripcin de los Plantilla de los informes de indicadores de medicin, indicadores. umbrales y anlisis a realizar. SG 2 Proporcionar los resultados de la medicin SP 2.1 Recoger los Informe que contenga Horas imputadas a realizar datos de la medicin los datos extrados de la el informe. medicin. Logs de las herramientas de recoleccin automtica de datos. SP 2.2 Analizar los Informe de anlisis de Acta de reunin de anlisis datos de la medicin los datos obtenidos. de datos. SP 1.4 Especificar los procedimientos de anlisis Acciones correctivas asociadas con el anlisis. Horas imputadas al anlisis y almacenamiento de los resultados. Contestaciones a comunicaciones de resultados. las los

SP 2.3 Almacenamiento de datos y los resultados SP 2.4 Comunicar los resultados

BBDD de indicadores, con los resultados de las mediciones anteriores y actuales. Correo electrnico, acta, etc. donde se evidencie la comunicacin de los resultados

Acciones correctivas identificadas en base a los resultados.

8.8

rea de proceso: Aseguramiento de la Calidad del Proceso y del Producto (PPQA)

Tabla 9. rea de proceso: Aseguramiento de la Calidad del Proceso y del Producto (PPQA)

ARTEFACTO DIRECTO

ARTEFACTO INDIRECTO

SG 1 Evaluar objetivamente los procesos y los productos de trabajo SP 1.1 Evaluar Plan de calidad donde se Actas de reunin de objetivamente los han registrado las diferentes evaluacin de los procesos. procesos auditoras independientes que se realizarn a los Horas imputadas a las proyectos. auditoras.

Informe de auditora interna o externa. No conformidades detectadas durante la auditora. Informes de pruebas de los productos y servicios.

Registro de auditora.

SP 1.2 Evaluar objetivamente los productos y los servicios

Histrico de casos de prueba.

Informes de auditora Horas imputadas a las interna o externa realizada auditoras. al proyecto. SG 2 Proporcionar una visin objetiva SP 2.1 Comunicar y No conformidades Acciones correctivas asegurar la resolucin de detectadas durante la asociadas a las no las no-conformidades auditora comunicadas a los conformidades. proyectos y asignadas al responsable de la resolucin. SP 2.2 Establecer Plan de calidad e Horas imputadas a las registros informes de auditora. auditoras. Almacenamiento de las no conformidades identificadas en las auditoras.

El mtodo de evaluacin

Para que una organizacin pueda alcanzar un cierto nivel de madurez, es necesario que se implementen las reas de proceso que CMMI define para ese nivel de madurez (ver Figura 4 o Anexo). Para que un rea de proceso sea correctamente implementada, deben alcanzarse los objetivos definidos para esa rea de proceso, que a su vez se consiguen mediante la implementacin de las prcticas de cada objetivo (especficas -SP- y genricas GP-).

Fig. 4. Niveles de madurez definidos en CMMI Cuando se va a evaluar la implementacin de las prcticas se comienza desde abajo hasta arriba, esto es, evaluando en primer lugar el cumplimiento de las prcticas, posteriormente los objetivos, luego las reas de proceso y finalmente el nivel de madurez. 9.1 Cumplir con las prcticas genricas (GP) y especficas (SP)

Se ha de comprobar si se cumplen las prcticas definidas para cada una de las reas de proceso definidas en el nivel de madurez. Para comprobar si se cumplen, SCAMPI define una escala que determina si se han implementado completamente, parcialmente o no se han implementado. La escala puede verse en la siguiente tabla:

Tabla 10. Calificacin de las prcticas Calificacin Fully Implemented (FI) Descripcin Artefactos directos presentes y adecuados Artefactos indirectos y/o afirmaciones No se han notado debilidades Largely Implemented (LI) Artefactos directos presentes y adecuados Artefactos indirectos y/o afirmaciones Se han notado una o ms debilidades Partially Implemented (PI) Artefactos directos no encontrados o inadecuados Artefactos indirectos y/o afirmaciones indican que parte de la prctica ha sido implementada Se han notado una o ms debilidades Artefactos directos presentes y adecuados No se encuentra otra evidencia que soporte la prctica Se han notado una o ms debilidades Not Implemented (NI) Artefactos directos no encontrados o inadecuados No se encuentra otra evidencia que soporte la prctica Se han notado una o ms debilidades

El equipo de auditora ir comprobando cada una de las prcticas de las reas de proceso, comprobando el estado de implementacin en el que se encuentra cada una de las prcticas. Para ello, revisa los indicadores de implementacin de la prctica (PII). A cada una de las prcticas se le dar una calificacin, en funcin de las evidencias encontradas, segn la Tabla 10. La Figura 5 muestra un ejemplo de calificacin de las prcticas de las rea de proceso del nivel dos, detallando el Aseguramiento de la calidad de proceso y producto (PPQA), en funcin de las evidencias que un auditor encontr.

Fig. 5. Evaluacin de las prcticas del rea de proceso PPQA

9.2

Cumplir con los objetivos genricos (GG) y especficos (SG)

Una vez que se han evaluado las prcticas, el equipo de auditora evala los objetivos. Los objetivos se evalan como satisfechos (satisfied) y no satisfechos (unsatisfied). Para evaluar si un objetivo ha sido satisfecho, se comprueban sus prcticas. Si todas sus prcticas se evalan como FI o LI, se considera que el objetivo est satisfecho. Tambin es necesario tener en cuenta el conjunto total de debilidades. Si la mayora de las prcticas tienen debilidades, podra considerarse que el objetivo no ha sido satisfecho. La Figura 6 muestra dos ejemplos de evaluacin del rea de proceso PPQA. En el primero de ellos, tres objetivos no se encuentran satisfechos debido a que sus prcticas no se encuentran correctamente implementadas. En el segundo de los casos, todas las prcticas se han evaluado como correctas, por lo que los objetivos si se encuentran satisfechos.

Fig. 6. Ejemplo de evaluacin de los objetivos del rea de proceso PPQA

9.3

Cumplir con el rea de proceso

Una vez que se han evaluado los objetivos, se evala el rea de proceso. Para que el rea de proceso se evale satisfactoriamente, todos los objetivos del rea de proceso (tanto genricos como especficos) han de encontrarse satisfechos. La Figura 7 muestra dos ejemplos de evaluacin del rea de proceso PPQA. En el primero de ellos, el rea de proceso no se ha conseguido implementar completamente al no cumplirse todos los objetivos. Sin embargo, en el segundo el rea de proceso se evala satisfactoriamente al estar todos los objetivos satisfechos.

Fig. 7. Evaluacin del rea de proceso PPQA

9.4

Cumplir con el nivel de madurez

Por ltimo, para poder determinar el nivel de madurez, es necesario que todas las reas de proceso definidas en ese nivel de madurez (ver anexo) se encuentren correctamente implementadas. La Figura 8 muestra dos ejemplos de la determinacin del nivel de madurez de una organizacin. En el primero de ellos, no se ha podido alcanzar el nivel 2 de madurez al no conseguir implementar correctamente todas las reas de proceso definidas en ese nivel de madurez. En el segundo ejemplo, se obtiene el nivel de madurez 2 al estar correctamente implementadas todas las reas de proceso correspondientes a ese nivel.10

Fig. 8. Evaluacin del nivel de madurez

Referencias
1. 2. 3. SEI. CMMI for development, version 1.3. http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm. SEI. CMMI: Gua para la integracin de procesos y la mejora de productos. http://www.sei.cmu.edu/library/abstracts/whitepapers/cmmi-dev-v12-spanish.cfm. SEI. Standard CMMI appraisal method for process improvement (SCAMPI) A, version 1.2: Method definition document. http://www.sei.cmu.edu/library/abstracts/reports/06hb002.cfm. SEI. Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A,

4.

10

Se ha excluido el proceso de Gestin de acuerdos con proveedores (SAM), ya que es optativo en funcin del tipo de organizacin.

5.

Version 1.3: Method Definition http://www.sei.cmu.edu/library/abstracts/reports/11hb001.cfm. SEI. Published appraisal results. http://sas.sei.cmu.edu/pars/pars.aspx.

Document.

Anexo: Las reas de proceso de CMMI

El modelo CMMI-DEV v1.311 establece 22 reas de proceso, divididas en categoras, para guiar a las organizaciones en la mejora de sus procesos. Un rea de proceso, tambin conocido como PA, de sus siglas en ingls Process Area, es un conjunto de prcticas relacionadas que, cuando se implementan de forma colectiva, satisfacen un conjunto de objetivos considerados importantes para alcanzar las mejoras en esa rea. Para que la organizacin alcance un cierto nivel de madurez, ser necesario que cumpla con todas las prcticas para las reas de procesos que ese nivel defina. Estas reas de proceso a cumplir para cada nivel estn ya definidas y son las siguientes: Nivel de madurez 2 Las reas de proceso que se enmarcan en este nivel de madurez son las siguientes: Gestin de requerimientos (REQM) Planificacin de proyecto (PP) Monitorizacin y control del proyecto (PMC) Gestin de acuerdos con proveedores (SAM) Gestin de configuracin (CM) Aseguramiento de la calidad de proceso y producto (PPQA) Medicin y Anlisis (MA) El rea de proceso Gestin de acuerdos con proveedores (SAM) slo ha de ser implementada si las organizaciones externalizan actividades relacionadas con el desarrollo software a otras empresas. Nivel de madurez 3 Para alcanzar el nivel de madurez 3, es necesario implementar todas las reas de proceso relativas al nivel 2, adems de las siguientes reas de proceso: Desarrollo de requerimientos (RD)
11

Aunque en esta gua se trata principalmente la versin 1.2 del mtodo SCAMPI, los procesos aqu descritos corresponden a la versin 1.3 de CMMI, en los que apenas hay cambios respecto a la 1.2.

Solucin tcnica (TS) Integracin de producto (PI) Verificacin (VER) Validacin (VAL) Definicin de procesos de la organizacin (OPD) Enfoque de procesos de la organizacin (OPF) Formacin organizativa (OT) Gestin integrada de proyecto (IPM) Gestin de riesgos (RSKM) Anlisis de decisiones y resolucin (DAR) Nivel de madurez 4 Para alcanzar el nivel de madurez 4, es necesario implementar todas las reas de proceso relativas al nivel 3 de madurez, adems de las siguientes: Gestin cuantitativa de proyecto (QPM) Rendimiento de procesos de la organizacin (OPP) Nivel de madurez 5 Para alcanzar el nivel 5 de madurez, es necesario implementar todas las reas de proceso relativas al nivel de madurez 4, adems de las siguientes: Anlisis causal y resolucin (CAR) Gestin del rendimiento de la organizacin (OPM)