CMM

Modelo de Madurez
de la Capacidad
Presenta:
Jess Cruz Ahuactzi

Indice:
1. Antecedentes.

7. Grupos.

2. Capacidad y Madurez

8. Notas de Inters.

3. Estructura.

9. Criticas a CMM.

4. Niveles

10.Conclusiones

5. KPAs

11.Bibliografa

6. Roles

Antecedentes :
60s y 70s - Crisis del SW (Tiempos, Costos y Calidad):
30% se Cancelaban, 54% excedan Tiempos y Costos estimados, 16% Exitosos

1984 Se crea el SEI operado por la Carnegie Mellon University.

Creado por el Departamento de Defensa de los E.U.A.

1984 se desarrolla el Modelo de Madurez del Proceso del Software.

1986 Surge el proyecto de Evaluacin de la Capacidad del Software

basado en TQM (Administracin de la Calidad Total).

Cinco etapas evolutivas hacia una implementacin de prcticas de calidad.

1991 el SEI Produce el CMM.

Capacidad y Madurez:
Capacidad: Es la habilidad inherente de un proceso para producir los
resultados planeados.

Madurez: Es el crecimiento alcanzado en la capacidad del proceso de

Software (Actividad a Largo Plazo)

Estructura:
MEJORA CONTINUA

Optimizado
PREDECIBLE

Administrado
ESTANDAR Y CONSISTENTE

Definido
DISCIPLINA

Repetible
Inicial

Nivel 1 (INICIAL)
El proceso es improvisado y a veces catico. Es un punto Base sin
valor.
La organizacin generalmente opera sin procesos formalizados,
estimaciones de costo o planes de proyecto.
Aunque existan algunos procesos formalizados, no existen
mecanismos que permitan asegurar que se cumplan.
El xito que se
pueda obtener depende de las habilidades,
conocimientos y motivaciones del personal.
Conclusiones:
La capacidad es una cualidad de las personas, no de la organizacin, se
alcanza el propsito de manera inconsistente, no es planeado ni lleva un
seguimiento.

Nivel 2 (REPETIDO)
Procesos bsicos de gestin para manejar costos, cronogramas y
funcionalidad establecidos.
La disciplina del proceso permite la repeticin de xitos anteriores en
proyectos similares.
La fuerza de la organizacin est dada por la existencia de experiencia
en desarrollo de procesos similares pero existen riesgos al presentarse
nuevos desafos
Conclusiones:
El proceso tiene disciplina por que existe planeacin y seguimiento, es
Documentado, es estable pero aun as no hay mtricas para servicio, solo
para productos.

Nivel 3 (DEFINIDO)
El proceso para gerentes e ingenieros est documentado e integrado en
un proceso estndar para la organizacin.
Todos los proyectos usan una versin aprobada y adaptada del proceso
estndar de la organizacin.
Un grupo de proceso de ingeniera de software ha sido establecido para
focalizar y liderar esfuerzos de mejora.
Conclusiones:
Este nivel es Estndar y Consistente gracias a las practicas de Ingeniera
de Software y Administracin de Proyectos, el proceso es Estable y
Repetible. La capacidad se logra basndose en las actividades, roles y
responsabilidades del proceso.

Nivel 4 (ADMINISTRADO)
Existen mediciones detalladas del proceso y calidad del producto.
El producto y el proceso son cuantitativamente conocidos y controlados.

Conclusiones:
Este nivel es Cuantificable y predecible. Todo gracias a que el proceso, a
la par que el producto y los servicios es medido y opera dentro del limite
cuantificable.

Nivel 5 (OPTIMIZADO)
La organizacin busca identificar aquellos elementos ms dbiles del
proceso y optimizarlos sobre la base de un anlisis defecto-causa y
prevencin de defectos.
Existen datos que justifican la aplicacin de nuevas ideas o tecnologas
a determinadas tareas crticas y la evidencia cuantitativa permite conocer
el grado de eficacia alcanzado al implementarlas en proyectos piloto.
Conclusiones:
El mejoramiento se da gracias al uso o implementacin de nuevas
tecnologas o mtodos, se obtiene un cumplimiento total de objetivos de
calidad.

KPAs:
Son las mejoras claves requeridas por cada nivel, para acceder al
siguiente:

NIVEL 2 - REPETIBLE
Se concentran en establecer controles bsicos de gestin de proyectos:
Administracin de requerimientos
Planificacin de proyectos de software
Control y supervisin de proyectos
Supervisin de subcontratos de software
Afirmacin de calidad del software
Supervisin de la configuracin del software

KPAs
NIVEL 3 - DEFINIDO
Direccionan aspectos organizacionales y del proyecto, lo que establece
una infraestructura que institucionaliza procesos de ingeniera de
software y gestin, a lo largo de todos los proyectos:
Focalizacin orgnica en el proceso
Definicin de proceso organizacional
Programa de entrenamiento
Administracin integrada del software
Ingeniera de producto
Coordinacin intergrupal
Revisiones por pares

KPAs
NIVEL 4 - ADMINISTRADO
Se concentran en establecer una comprensin cuantitativa y cualitativa
del proceso y de los productos:
Administracin cuantitativa del proceso
Administracin de la calidad del software
NIVEL 5 - OPTIMIZADO
Cubren los aspectos de la organizacin y de los proyectos que deben
atenderse para implementar una mejora continua y medible del proceso
de software:

Prevencin de defectos
Administracin del cambio del proceso
Administracin del cambio tecnolgico

Roles :
Gerentes: Planear, organizar, dirigir y controlar el trabajo dentro de su
rea.
Lderes del Proyecto: Dirigir y controlar proyectos para construccin de
Sistemas de SW o HW/SW. Responsable ante el cliente.
Lder de Proyectos de SW: Controlara actividades y recursos de proyectos
de SW de un proyecto.
Lder de SW de Primera Lnea: Responsable del Staff y actividades de un
departamento de ingenieros de SW y Staff relacionado.
Lder de Tareas de SW: Lder de un equillo tcnico para una tarea
especifica.
Staff (no Gerentes): Responsable de realizar una funcin asignada como
desarrollo de SW o Administracin de configuracin de SW.
Staff de Ingeniera de SW: Personas tcnicas de SW: analistas,
programadores e ingenieros, desarrollan SW y realizan actividades de
mantenimiento del proyecto.

Grupos :
Ingeniera de SW (Gerentes y Staff Tcnico): Actividades de desarrollo y
manutencin de SW.
Ingeniera de Procesos de SW (Especialistas): Facilitar la definicin,
mantenimiento y mejoramiento del proceso del SW usado por la organizacin.
Ingeniera de Sistema (Gerentes y Staff Tcnico): Especificar requerimientos
del sistema, definir interfases de recursos necesarios, monitorear el diseo y
desarrollo de componentes.
Pruebas de Sistemas (Gerentes y Staff Tcnico): Planear y realizar pruebas de
SW y determinar si el producto satisface los requerimientos de la organizacin.
Aseguramiento de Calidad de SW (Gerentes y Staff Tcnico): Planear e
implementar proyectos para asegurar los pasos del proceso del SW y los
estndares sean seguidos.
Administracin de Configuracin de SW (Gerentes y Staff Tcnico): Planear,
coordinar e implementar actividades de configuracin para los proyectos de SW.
Grupo de Entrenamiento (Gerentes y Staff Tcnico): Coordinar y arreglar
actividades de entrenamiento de una organizacin y coordinacin de otras vas de
entrenamiento.

Notas de Inters:
Certificar o no Certificar?
Beneficios?

Sencillo?
Quienes lo adoptaron?
Grado de Madurez de las Empresas?

Cambios?
Tiempos?
Inversin?

Observaciones al utilizarlo.

Notas de Inters
Grado de Madurez

Cambios al utilizar CMM

68.80%
70.00%
60.00%

Permanecio
igual
18%

50.00%
40.00%
30.00%

Bajo el nivel
11%

18%

20.00%

11.30%
1.50%

10.00%

0.40%

0.00%
Nivel 1

Nivel 2

Nivel 3

Nivel 4

Nivel 5

Marzo de 1996

Elevo el nivel
71%

Notas de Inters
Algunos datos promedio de un estudio realizado sobre los primeros 3
niveles son los siguientes:
Tiempo requerido para pasar del nivel 1 al 2: 26 meses
Tiempo requerido para pasar del nivel 2 al 3: 24 meses
Inversin aproximada requerida: US$ 1400 por ao por ingeniero de
software
Reduccin de defectos post-release alcanzada: 39% por ao
Relacin costo/beneficio lograda: 1 a 5
Algunas observaciones del estudio realizado sobre los primeros 3 niveles
son las siguientes:
Mejora en la capacidad para alcanzar:
Cronogramas y presupuestos previstos
Calidad del producto requerida
Mejora de la moral del equipo de desarrollo
Baja la satisfaccin del cliente en nivel 2 y sube considerablemente en el
nivel 3

Criticas a CMM:
A continuacin se listan las principales crticas que se le suelen hacer al
CMM:
1) Las preguntas utilizadas en la evaluacin son binarias (Si - No), lo
que no permite registrar los matices de la realidad.
2) El modelo es slo aplicable a grandes organizaciones que
desarrollan grandes proyectos.
3) El modelo permite comparar procesos de software de grandes
organizaciones con los de pequeas organizaciones, favoreciendo
a las primeras.
4) La aplicacin del modelo requiere una inversin importante.
5) Los niveles de madurez no garantizan el xito. Existen proyectos
exitosos en el nivel 1 y fracasos en niveles superiores.

Bibliografa:
http://www.itba.edu.ar/capis/webcapis/proyectodetesisdemagister/pera
lta-anteproyecto.pdf#search='que es el cmm'
http://www.kanav.com/cmm.htm
http://www.udlap.mx/~tesis/lis/garcia_r_ci/
http://www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/D
IEZ-CMM.pdf#search='cmm en ingenieria de software'
http://www.profit.es/41artdet.asp?NoticiaID=23
El modelo CMM por Carlos Javier Prez Escobar Avantare 2000