El documento presenta el Modelo de Madurez de Capacidades (CMM), desarrollado por el Software Engineering Institute (SEI) en respuesta a la crisis de calidad del software en los años 80. Describe sus niveles de madurez, áreas clave de proceso y los principios que guían la mejora continua en organizaciones que desarrollan software. Además, se menciona la calibración del modelo para diversas áreas y su aplicación global en distintos tipos de organizaciones.

1. REPÙBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DE EDUCACIÒN SUPERIOR
UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÈCNICA DE
MARACAIBO
INSTITUO UNIVERSITARIO DE TECNOLOGÌA DE MARACAIBO
MARACAIBO, ESTADO ZULIA.
Modelo de Madurez de Capacidades (CMM).
Integrantes:
Cátedra: GESTIÒN DE PROYECTOS INFORMÀTICOS
Amín Rodríguez. C.I.: 17.294.586
Profesor: ALONSO HUERTA
rodriguezamin@hotmail.com
Gerardo Redondo C.I.: 16.546.673
gerardoredondo85@hotmail.com
Ruben Suárez. C.I.: 14.833.963
suarezmolina_r@hotmail.com
Maracaibo, Junio 2012

2. HISTORIA DEL CMM
Debido a la crisis que experimentaba el software a principios de los
ochenta el gobierno de los Estados Unidos decidió financiar un proyecto que
mejorara la calidad de los productos software.
1984: El Congreso del Gobierno Americano aprobó la creación de un
organismo de investigación para el desarrollo de modelos de mejora para los
problemas en el desarrollo de los sistemas de software, y evaluar la capacidad
de respuesta y fiabilidad de las compañías que suministran software al
Departamento de Defensa. Creación del SEI (Instituto de Ingeniería del
Software), fundado por el Departamento de Defensa Americano y la
Universidad Carnegie Mellon.
1985: SEI empieza a trabajar en un marco de madurez de procesos que
permita evaluar a las empresas productoras de software. La investigación
evoluciona hacia el “Modelo de Madurez de las Capacidades (CMM)”.
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de
los Estados Unidos de América, desarrolló una primera definición de un modelo
de madurez de procesos en el desarrollo de software, que se publicó en
septiembre de 1987.
1991: En agosto SEI publica la versión 1.0 del Modelo de Madurez de las
Capacidades para el Software (SW-CMM, Capability Maturity Model for
Software).
1993: SEI publica la versión 1.1 de SW-CMM 1997 Publicación de la versión
1.2
2000: SW-CMM fue integrado y relevado por el nuevo modelo CMMI.
¿QUÉ ES CMM?
El Modelo de Madurez de Capacidades o CMM (Capability Maturity
Model), es un modelo de evaluación de los procesos de una organización.
Estos niveles sirven para conocer la madurez de los procesos que se realizan
para producir software.
Este modelo establece un conjunto de prácticas o procesos clave
agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada
área de proceso define un conjunto de buenas prácticas que habrán de ser:
Definidas en un procedimiento documentado.
Provistas (la organización) de los medios y formación necesarios.
Ejecutadas de un modo sistemático, universal y uniforme
(institucionalizadas).
Medidas.
Verificadas.

3. ORGANISMO RESPONSABLE.
Ha sido desarrollado en el SEI (Software Engineering Institute)
relacionado con Carnegie Mellon University, en Pittsburgh. El CMM se
desarrolló como reacción a la crisis del software a principios de los ochenta y
financiado por el Departamento de Defensa de los Estados Unidos.
El SEI es un centro de investigación y desarrollo patrocinado por el
Departamento de Defensa de los Estados Unidos de América y gestionado por
la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI.
Las organizaciones que utilizan CMM para mejorar sus procesos
disponen de una guía útil para orientar sus esfuerzos. Además, el SEI
proporciona formación a evaluadores certificados (Lead Assesors) capacitados
para evaluar y certificar el nivel CMM en el que se encuentra una organización.
Esta certificación es requerida por el Departamento de Defensa de los Estados
Unidos, pero también es utilizada por multitud de organizaciones de todo el
mundo para valorar a sus subcontratistas de software.
AREAS CLAVES DE PROCESO (KPAs)
Este modelo establece un conjunto de prácticas o procesos clave
agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada
área de proceso define un conjunto de buenas prácticas que habrán de ser:
• Definidas en un procedimiento documentado
• Provistas (la organización) de los medios y formación necesarios
• Ejecutadas de un modo sistemático, universal y uniforme
(institucionalizadas)
• Medidas
• Verificadas
Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está
compuesto por un cierto número de Áreas Claves de Proceso, conocidas a
través de la documentación del CMM por su sigla inglesa: KPA. Cada KPA
identifica una agrupación de actividades y prácticas relacionadas, las cuales
cuando son realizadas en forma colectiva permiten lograr alcanzar las metas
fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de
proceso: Gestión, Organizacional e Ingeniería
Nivel 2
• Gestión de Requisitos
• Planificación del proyecto de software
• Seguimiento y Supervisión del proyecto

4. • Gestión de subcontratos de software
• Garantía de calidad de software
• Gestión de la configuración del software
Nivel 3
• Enfoque en el proceso de la organización
• Definición del proceso de la organización
• Programa de formación
• Gestión integrada del software
• Ingeniería de software del producto
• Coordinación entre grupos
• Revisión de pares
Nivel 4
• Gestión cuantitativa del proceso
• Gestión de la calidad del software
Nivel 5
• Prevención de defectos
• Gestión del cambio de tecnología
• Gestión del cambio del proceso
Así es como el modelo CMM establece una medida del progreso, conforme
al avance en niveles de madurez. Cada nivel a su vez cuenta con un número
de áreas de proceso que deben lograrse. El alcanzar estas áreas o estadios se
detecta mediante la satisfacción o insatisfacción de varias metas claras y
cuantificables. Con la excepción del primer nivel, cada uno de los restantes

5. Niveles de Madurez está compuesto por un cierto número de Áreas Claves de
Proceso, conocidas a través de la documentación del CMM por su sigla
inglesa: KPA.
Cada KPA identifica un conjunto de actividades y prácticas
interrelacionadas, las cuales cuando son realizadas en forma colectiva
permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden
clasificarse en 3 tipos de proceso: Gestión, Organizacional e Ingeniería.
PRINCIPIOS DE LAS KPAs.
Las prácticas que deben ser realizadas por cada Área Clave de Proceso
están organizadas en 5 Características Comunes, las cuales constituyen
propiedades que indican si la implementación y la
institucionalización de un proceso clave es efectivo, repetible y duradero.
Estas 5 características son:
• Compromiso de la realización.
• La capacidad de realización.
• Las actividades realizadas
• Las mediciones y el análisis
• La verificación de la implementación.
El modelo CMM se formula de una manera genérica. Es independiente
de cualquier método (o metodología) y de cualquier ambiente de tecnología
(software o hardware). Los métodos específicos usados por una compañía o
agencia no impone restricciones específicas en la utilización del SW-CMM,
debido a que sus prácticas se formulan de forma general para que pueda
fácilmente adaptarse de manera de satisfacer las necesidades de ambientes
particulares.
Este modelo debe interpretarse de acuerdo al tamaño de las compañías
o agencias, pero es aplicable en el contexto global. Cualquier entidad que
desarrolla o mantiene software, independientemente de su tamaño se
beneficiará mejorando su proceso de software aplicando el CMM.
Uno de los métodos de evaluación basados en el modelo CMM para el
mejoramiento interno de procesos, generalmente conocido como CBA-IPI
("CMM -Based Appraisal for Internal Process Improvement"): su principal
objetivo es permitir a la empresa la determinación de sus puntos fuertes y
necesidades de mejoramiento, también permite revisar las prácticas de los
proveedores externos, a objeto de que puedan derivar un plan de
mejoramiento adecuado a su organización.

6. OTROS MODELOS CMM
Hay toda una familia de modelos de madurez (CMM’s), aplicables a
otros dominios relacionados con el software.
SW-CMM: El modelo CMM lo aplicamos específicamente al ámbito del
software.
SE- CMM: Que significa Systems Engineering, el cual cubre el ámbito de la
Ingeniería de Sistemas.
P-CMM: Que significa Personal CMM, el cual cubre la administración de
personal.
SA-CMM: que significa Software Acquisition, el cual cubre las prácticas de la
adquisición de productos de software.
IPD-CMM: que significa Integrated Product Development, el cual cubre el
desarrollo de la integración del producto.
SSE-CMM
El System Security Engineering Capability Maturity Model o Modelo
de Madurez de Capacidades en la Ingeniería de Seguridad de Sistemas es un
modelo derivado del CMM y que describe las características esenciales de los
procesos que deben existir en una organización para asegurar una buena
seguridad de sistemas.
Ha sido desarrollado por la "International Systems Security
Engineering Association (ISSEA)", organización sin ánimo de lucro
patrocinada por un buen número de compañías dedicadas a la seguridad de
sistemas.
Nació a partir de 1993 bajo los auspicios de la Agencia Nacional de
Seguridad (NSA) de los E.U.A., con la participación de numerosas compañías
de los sectores de tecnologías de la información, seguridad y defensa. La
primera versión data de 1997 y la actual (v3.0) fue publicada en junio de 2003.
Pretende servir como:
• Herramienta para que las organizaciones evalúen las prácticas de
ingeniería de seguridad y definan mejoras a las mismas.
• Mecanismo estándar para que los clientes puedan evaluar la capacidad
de los proveedores de ingeniería de seguridad.
• Base para la organización de un mecanismo de evaluación y
certificación.

7. A diferencia del CMM original, las áreas de proceso no están agrupadas en
función de los niveles de madurez, sino que define 22 áreas para cada una de
las cuales se puede alcanzar un nivel en función del cumplimiento de unas
nivel
"características comunes".
Existen 11 áreas de procesos de ingeniería y otras 11 dedicadas a la gestión
de proyectos y organización.
El método de evaluación se denomina SSAM (SSE-CMM Appraisal Method).
CMM
ESTRUCTURA DEL MODELO SW-CMM

8. NIVELES DE MADURACION CMM
Nivel 1: En el nivel inicial el resultado de los procesos suele ser impredecible
tal como lo muestra el grafico, No existen áreas o funciones formalmente
definidas así como tampoco puntos de control en el proceso, solo se puede
tener una visión clara de las cosas cuando se empieza el proyecto y cuando se
logra acabar, pero no es posible conocer de manera adecuada el estado del
proyecto en sus procesos intermedios. Es por eso que en esas circunstancias
surgen personas que se suben al hombro el proyecto y lo logran sacar
adelante, aunque generalmente este tipo de proyectos sufrirá demoras y
probablemente no se culminará.
Nivel 2: Según nuestro grafico ya es posible ver una gran diferencia entre el
nivel inicial y el repetible, en este segundo nivel se puede observar que se
definen claramente puntos de control en cada etapa principal del proyecto, esto
obviamente permite tener un mayor control del proyecto. Lo importante a
resaltar del grafico es que cada etapa es aún una caja negra es decir no
podemos saber con precisión como se desenvuelve el proyecto dentro de cada
etapa.
Nivel 3: Los procesos comunes para desarrollo y mantenimiento del software
están documentados de manera suficiente en una biblioteca accesible a los
equipos de desarrollo. Las personas han recibido la formación necesaria para
comprender los procesos. En conclusión cada proceso se hace transparente
para todos
Nivel 4: Tal como lo muestra el grafico, la principal diferencia con el nivel
anterior es la medición y control de los procesos (métricas). Estas métricas no
son subjetivas si no que se establecen con criterios cuantitativos formalmente
definidos. Con el tiempo estos controles nos brindaran mejor información sobre
la calidad y estado del proyecto permitiéndonos compararlo con otros proyectos
similares y notar cualquier desviación tempranamente para poder corregirlo.
Nivel 5: En este nivel cada proceso es analizado y controlado
permanentemente con la intención de que sea mejorado en todo momento, los
controles permiten la mejora continua y se tienen implementadas todas las
áreas clave de proceso recomendadas por el modelo.
SEI Y EL CONCEPTO DE MADUREZ
El Software Engineering Institute, de la Universidad de Carnegie Mellon
de Pittsburgh ha desarrollado el concepto de “madurez” en el desarrollo de
software. Por madurez se entiende la capacidad que tiene la organización para
asegurar la calidad de sus proyectos (en fecha, coste y funcionalidad), la
homogeneidad y repetitividad y la capacidad de aprendizaje de su propia
experiencia para la mejora continua.

10. Un proceso puede considerarse maduro si cumple
con los siguientes criterios:
El proceso es claro, sistemático y suficientemente detallado. Además
Está definido existe acuerdo entre el personal, la gerencia y los proyectos respecto al
proceso que se va a utilizar.
Esta escrito en un procedimiento publicado, aprobado y fácilmente
Esta documentado accesible. Una de las mejores maneras es a través de una Intranet para
apoyar los proyectos de desarrollo (ver página detallada)
El personal ha sido Los ingenieros de software y la gerencia han recibido cursos y
entrenado en el entrenamiento en cada proceso que aplica a su trabajo
proceso
El proceso definido debe ser usado en las tareas habituales llevadas a
Es practicado cabo por los proyectos. El entrenamiento y la adaptación del proceso a la
realidad de la empresa debieran garantizar su aplicación en la vida real
La gerencia no sólo debe firmar y promover los procesos definidos, sino
Es apoyado que además debe asignar responsabilidad al personal y al los jefes de
proyecto por su cumplimiento
El proceso es revisado regularmente, para asegurarse que está adaptado
Es mantenido para satisfacer las necesidades reales de los proyectos
Los cambios y puestas al día del proceso son revisados, aprobados y
Está controlado comunicados oportunamente a todos los usuarios
La gerencia mantiene mecanismos para asegurarse que todos los
Se verifica proyectos siguen el proceso vigente
Se asegura que el proceso mantiene concordancia con los requerimientos
Se valida y estándares aplicables
La utilización, los beneficios y el rendimiento resultante del proceso se
Se mide miden regularmente
Existen mecanismos y apoyo de la gerencia para revisar e introducir
Puede mejorarse cambios en el proceso, de manera de mejorar su eficacia e incorporar
nuevas metodologías

11. BIBLIOGRAFIA
http://www.reocities.com/SiliconValley/lab/3629/nivel1.htm
http://proactivanet.com/metodologia-cmmi
http://www.ingenierosoftware.com/calidad/cmm-cmmi.php
http://es.wikipedia.org/wiki/Modelo_de_Capacidad_y_Madurez
http://es.scribd.com/doc/77792963/CalidadDeSW-CMM
http://www.rcgsas.com/Documentos/Seminario/SRI-UN_s11.pdf
http://es.scribd.com/doc/58146118/Informacion-General-CMMI
http://www.navegapolis.net/files/articulos/sinopsis_cmm.pdf
www.upv.es/
users.dsic.upv.es/asignaturas/facultad/lsi/trabajos/082000.doc