Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Peit-Spicmmi 01.00
Peit-Spicmmi 01.00
SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM
Informe Técnico
Mejora del Proceso Software
El modelo CMMISM
SPI-INSS
Versión 01.00
29 de enero de 2004
CONTROL DE VERSIONES
ÍNDICE
3. EL MODELO CMMI...................................................................................................................................................9
3.1. INTRODUCCIÓN.....................................................................................................................................................9
3.2. REPRESENTACIONES...........................................................................................................................................9
3.2.1. CONTINUA...........................................................................................................................................................9
3.4.3. INGENIERÍA......................................................................................................................................................17
3.4.4. SOPORTE............................................................................................................................................................18
“La calidad de un producto está determinada en gran medida por la calidad del
proceso usado para desarrollarlo y mantenerlo” -Principios de TQM-
El Proceso Software
Podemos definir un proceso como un método para hacer o producir algo. Si extendemos esta
definición al caso del software, podemos decir que el proceso software es un método para
producir o desarrollar software. Esto parece una obviedad, después de todo el software siempre
ha sido desarrollado usando algún método. Por ejemplo, “Prueba y error” es un proceso
perfectamente válido.
Este tipo de procesos, independientemente de la profesionalidad con que se hayan ejecutado,
dependían fuertemente del desarrollador individual. Esto puede derivar en tres problemas:
Primero, ese software es difícil de mantener. Supongamos que el desarrollador abandona la
empresa por la causa que sea, y alguien tiene que retomar su trabajo inconcluso. Puede ocurrir
que exista una documentación exhaustiva del estado actual del trabajo. Puede que incluso
haya un plan, con las tareas individuales completadas marcadas, o puede que el plan exista
únicamente en la cabeza del desarrollador. En cualquier caso el sustituto probablemente
acabará empezando de nuevo, porque no tiene ninguna pista de por donde empezar. El
proceso puede ser excelente, pero es un proceso ad-hoc, no un proceso definido.
Segundo, es difícil medir con precisión la calidad del producto terminado con una evaluación
independiente. Si tenemos dos desarrolladores, siguiendo cada uno su propio proceso,
definiendo sus propias pruebas sobre la marcha, no tenemos un método objetivo de comparar
el trabajo de uno con el del otro, o con un criterio de calidad del cliente.
Tercero, hay un gran esfuerzo duplicado debido a que cada individuo elabora su propia manera
de hacer las cosas aisladamente. Para evitar esto, debemos encontrar algún modo de aprender
de la experiencia de otros, no volver a inventar la rueda.
Por esto es importante que cada organización defina el proceso para un proyecto. En su forma
más simple, esto significa simplemente ponerlo por escrito. Esto especifica los diversos ítems
que deben ser producidos, y el orden en que deben ser producidos: De los planes a los
requisitos, a la documentación y hasta el código fuente final. Debe decir dónde se deben
almacenar, cómo se deben comprobar, y qué se debe hacer con ellos cuando el proyecto
finalice. Una vez puesto por escrito es un proceso definido.
emplear la mejor tecnología posible, pero incluso las personas más capacitadas no producen lo
mejor sin un proceso de alto nivel. Por esto han surgido iniciativas tendentes a la mejora de la
capacidad de los procesos software.
Los programas exitosos de mejora del proceso software han conseguido:
Reducir en un 95% el número de defectos entregados.
Reducir los tiempos de desarrollo de software en 71%.
Incrementar la productividad (medida en LOC o Puntos Función por día ) en un 222%.
Se ha obtenido un ROI medio de 5:1.
Un proceso se define como un conjunto de prácticas realizadas para obtener un propósito.
Pueden incluir herramientas, métodos, materiales y/o personas. Mientras que el proceso se
describe como uno de los lados del triángulo proceso-personas-tecnología, se puede considerar
como el “pegamento” que unifica los otros aspectos.
Un Modelo de Proceso es una colección estructurada de elementos que describen
características de procesos efectivos. Proporciona una referencia para fijar objetivos y
prioridades de mejora de procesos, y una guía para asegurar procesos estables, capaces y
maduros.
Hay que distinguir entre Capacidad del Proceso y Rendimiento del Proceso. El primer concepto
apunta al rango de resultados esperados por seguir un proceso, establecido inicialmente al
nivel organizativo. Puede predecir el futuro resultado del proceso. El Rendimiento del proceso
es una medida de los resultados actuales conseguidos por la ejecución de un proceso. Se
refiere a un proyecto particular en la organización.
Un modelo de proceso proporciona:
Un punto de partida
El beneficio de experiencias anteriores de la comunidad
Un lenguaje y una visión común
Un marco para priorizar acciones.
Fig. 1. Los diferentes marcos de calidad y mejora de procesos, y las relaciones entre ellos.
Como vemos en la Fig. 1, existe un número considerable de marcos estándar relacionados con
la calidad y los procesos de software:
Los modelos de madurez de capacidad de la familia CMM.
Las series de normas ISO
Modelos de procesos relacionados con el DOD.
Etc.
3. EL MODELO CMMI
3.1. Introducción
El modelo CMMI constituye un marco de referencia de la capacidad de las organizaciones de
software en el desempeño de sus diferentes procesos, proporcionando una base para la
evaluación de la madurez de las mismas y una guía para implementar una estrategia para la
mejora continua de los mismos. Proporciona una vista estructurada de la mejora de procesos en
una organización. Puede ayudar a:
Fijar metas y prioridades de mejora
Proporcionar orientación en los procesos de calidad
Proporcionar criterios para evaluar las prácticas
Servicio de Desarrollo Informático Página 8 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM
Existen una serie de conceptos que constituyen la estructura del marco de referencia:
Niveles de madurez.
Áreas de proceso.
Metas genéricas.
Metas específicas.
Prácticas genéricas.
Practicas específicas.
3.2. Representaciones
Existen dos representaciones del modelo CMMI atendiendo a las diferentes necesidades de las
organizaciones que quieren realizar la mejora de sus procesos. La representación por etapas
hace especial énfasis en el grado de madurez de los procesos, mientras que la representación
continua hace hincapié en la capacidad de ciertas áreas para realizar adecuadamente sus
actividades.
3.2.1. Continua
En la representación continua los niveles de madurez no existen como tales. En cambio los
niveles de capacidad se designan para cada área de proceso, proporcionando un orden
recomendando para acercarse a la mejora dentro de cada área de proceso. Esta representación
favorece la flexibilidad en el orden en que se introducen las mejoras. Aquellas organizaciones
que escojan la representación continua podrán:
Seleccionar adecuadamente las mejoras que hay que realizar para conseguir los
objetivos del negocio definidos por la organización.
Permitir un análisis comparativo dentro de la organización y entre diferentes
organizaciones al tener por punto de referencia las diferentes áreas de proceso.
Facilita la realización de evaluaciones con el modelo SPICE (ISO/IEC TR 15504), ya que la
organización de sus áreas de proceso es similar.
definidas para toda la organización a nivel global, de modo que cada proyecto puede adaptar
sus procesos a partir del proceso definido para la organización. Para esto es conveniente
disponer de una Biblioteca de Activos de Proceso (PAL) donde residan las descripciones de los
procesos, plantillas y otros materiales para su utilización en cada proyecto individual. El nivel 4
enfoca en la gestión cuantitativa de los proyectos con los cual incorpora prácticas para
recopilar datos cuantitativos y métricas para ayudar a una toma de decisiones informada. El
nivel 5 tiene como objetivo la mejora continua estudiando las fortalezas y debilidades de los
procesos y la implementación de innovaciones tecnológicas.
Nivel de Madurez
Caracteristicas Comunes
Prácticas Prácticas
Genericas Especificas
Niveles de Madurez
Optimizado
5 Enfoque en la mejora del
proceso
Gestionado
4 El proceso es controlado Cuantitativamente
cuantitativamente
La disciplina de proceso reflejada por el nivel de madurez 2 ayuda a asegurar que las prácticas
existentes se retienen en tiempos de stress. Cuando esas prácticas están presentes, los
proyectos se realizan y gestionan conforme a sus planes documentados.
En el nivel de madurez 2, los requisitos, procesos, productos y servicios se gestionan. El status
de los productos y la prestación de servicios son visibles para la gestión en puntos definidos
(por ejemplo en hitos mayores y al completar tareas mayores)
Se establecen compromisos entre los participantes relevantes, y se revisan según sea
necesario. Loa productos de trabajo se revisan con los participantes, y se controlan. Los
productos y servicios satisfacen sus propios requisitos, estándares y objetivos.
El área de proceso de Gestión Integrada del Proyecto, establece y mantiene el proceso definido
del proyecto, adaptado desde el conjunto de procesos estándar de la organización. El proceso
se gestiona usando el proceso definido del proyecto. El proyecto usa y contribuye a los activos
de proceso de la organización.
El proyecto se asegura que los participantes relevantes asociados con el proyecto coordinan
sus esfuerzos oportunamente. Para esto proporciona para la gestión de la implicación de
participantes; la identificación, negociación y seguimiento de dependencias críticas; y la
resolución de incidencias de coordinación con los participantes.
La Gestión del Riesgo toma una aproximación más continua y por anticipado para gestionar
riesgos con actividades que incluyen identificación de los parámetros del riesgo, evaluaciones
de riesgos y manejo de riesgos.
La Gestión Cuantitativa de Proyectos aplica técnicas cuantitativas y estadísticas para gestionar
el rendimiento del proceso y la calidad del producto. Los objetivos de calidad y de rendimiento
del proceso para el proyecto se basan en los establecidos para la organización. El proceso
definido del proyecto comprende, en parte, elementos de proceso y subprocesos cuyo
rendimiento se puede predecir. Como mínimo, se comprende la variación de proceso
experimentada por los subprocesos crítica para alcanzar los objetivos de calidad y rendimiento.
Se toman acciones correctivas cuando se detectan causas especiales de variación.
3.4.3. Ingeniería
El área de proceso Desarrollo de Requisitos identifica las necesidades del cliente y las traduce
en requisitos del producto. El conjunto de requisitos del producto se analiza para producir una
El área de proceso de Gestión de Requisitos mantiene los requisitos. describe actividades para
obtener y controlar los cambios de requisitos, y asegurar que otros planes relevantes y datos se
mantienen actualizados. Esto proporciona trazabilidad de los requisitos del cliente al producto,
y a los componentes del producto.
La Gestión de Requisitos asegura que los cambios de requisitos se reflejan en los planes de
proyecto, actividades y productos de trabajo. El ciclo de cambios puede impactar en otras áreas
de proceso de ingeniería; por tanto, la gestión de requisitos es una secuencia de eventos
dinámica y con frecuencia recursiva. El establecimiento y mantenimiento de la Gestión de
Requisitos es fundamental para un proceso de diseño de ingeniería controlado y disciplinado.
El área de proceso Solución Técnica desarrolla paquetes de trabajo técnico para los
componentes del producto que serán usados por el área de proceso Integración de Producto. Se
espera el examen de soluciones alternativas, con el intento de seleccionar el diseño óptimo en
base a criterios establecidos. Esos criterios pueden ser diferentes entre productos, dependiendo
del tipo de producto, entorno operativo, requisitos de rendimiento, y coste y planificación de
entregas. la tarea de seleccionar la solución final hace uso de prácticas específicas del área de
proceso Análisis y Resolución de decisiones.
La Solución Técnica recae en prácticas específicas en el Área de proceso Verificación para
realizar verificaciones del diseño y revisiones entre iguales durante el diseño y antes de la
construcción final.
El área de proceso Integración del Producto establece las prácticas específicas asociadas con la
generación de la mejor secuencia de integración posible, integrando los componentes del
producto y entregando el producto al cliente.
El área de proceso Verificación asegura que los productos de trabajo seleccionado cubren los
requisitos especificados. El área proceso Verificación selecciona productos de trabajo y métodos
de verificación que serán usados para verificar los productos de trabajo contra los requisitos
especificados. Verificación es generalmente un proceso incremental, comenzando con la
verificación de componentes de producto y normalmente concluye con la verificación de
productos completamente ensamblados.
Verificación también aborda revisiones entre iguales. Las revisiones entre iguales son un
método probado para eliminación temprana de defectos y proporciona una valiosa perspectiva
de los productos de trabajo y componentes que se están desarrollando y manteniendo.
El área de proceso Validación valida incrementalmente los productos contra las necesidades del
cliente. La validación se puede realizar en el entorno operativo o en un entorno operativo
simulado. La coordinación con el cliente en los requisitos de validación es uno de los elementos
más esenciales en este área de proceso.
3.4.4. Soporte
Las áreas de proceso de soporte cubren las actividades que soportan el desarrollo y
mantenimiento del producto. . Las áreas de proceso de Soporte comprenden procesos usados
en el contexto de realización de otros procesos. En general abordan procesos que siguen el
curso a lo largo del proyecto, y pueden abordar procesos que aplican más generalmente a la
organización. Por ejemplo, el Aseguramiento de calidad del Producto y el Proceso se puede usar
en todas las áreas de proceso para proporcionar una evaluación objetiva de los procesos y
productos de trabajo descritos en todas las áreas de proceso.
El área de proceso Aseguramiento de Calidad del Producto y el Proceso da soporte a todas las
áreas de proceso proporcionando prácticas específicas para evaluar objetivamente los procesos
realizados, los productos de trabajo, y los servicios contra las descripciones de proceso
aplicables, estándares, y procedimientos, y asegura que se abordará cualquier incidencia
detectada en esas revisiones. El Aseguramiento de Calidad del Producto y el Proceso da soporte
a la entrega de productos y servicios de alta calidad proporcionando al personal del proyecto y
todos los niveles de dirección la visibilidad y el feedback apropiados, en los procesos y los
productos de trabajo asociados a lo largo de la vida del proyecto.
El área de proceso Medición y Análisis da soporte a todas las áreas de proceso proporcionando
prácticas específicas que guían a los proyectos y organizaciones para alinear las necesidades y
objetivos de medición con un enfoque de medición que proveerá resultados objetivos. Esos
resultados pueden usarse para tomar decisiones informadas y aplicar las acciones correctivas
apropiadas.
El área de proceso Análisis y Resolución de Decisiones da soporte a todas las áreas de proceso
proporcionando un proceso formal de evaluación que asegura que las alternativas se
comparan y que se elige la mejor para cumplir con las metas del área de proceso.
El área de proceso Análisis y Resolución Causal, hace que el proyecto que la usa comprenda las
causas comunes de variación inherentes en los procesos y las elimina de los procesos del
proyecto, así como usar este conocimiento para mejorar continuamente los procesos de la
organización. Tanto los procesos definidos como el conjunto de procesos estándar de la
organización son los objetivos de esas actividades de mejora.
GG2
Institucionalizar un proceso Gestionado
GG3
Institucionalizar un proceso Definido
Las características comunes son un modo de organizar las prácticas genéricas de cada área de
proceso. En la representación por etapas, existen 4 características comunes:
Compromiso para la Realización (CO)
Habilidad para la Realización (AB)
Implementación Dirigida (DI)
Implementación Verificada (VE)
Planificación
Toma de decisiones
Comunicaciones
Coordinación
Revisiones
Evaluaciones
Definición de requisitos
Resolución de problemas/incidencias
Consultar el Área de Proceso Planificación de Proyectos para información en la
planificación de proyectos para implicación de los participantes.
El objetivo de planificar la implicación de los participantes es asegurar que se
consigan las interacciones necesarias, mientras que no se permite que un
excesivo número de grupos e individuos afectados impidan la ejecución del
proceso.
Subprácticas
Identificar participantes relevantes para el proceso y decidir que tipo de
implicación se debería practicar.
Compartir dichas identificaciones con planificadores de proyectos u otros
planificadores según sea apropiado.
Implicar a los participantes relevantes según lo planeado.
GP 2.8. Monitorizar y Controlar el Proceso
Subprácticas
Almacenar medidas del proceso y de producto en el repositorio de la
organización.
Submitir información para incluir en la biblioteca de activos de proceso.
Documentar las lecciones aprendidas
Proponer mejoras a los activos de proceso de la organización.