Diferencia entre revisiones de «Capability Maturity Model»
Contenido eliminado Contenido añadido
m Revertidos los cambios de 201.82.229.161 (disc.) a la última edición de Martingala |
m Revertidos los cambios de 201.82.229.161 (disc.) a la última edición de Juan.palacio |
||
| Línea 1: | Línea 1: | ||
{{fusionar | |
{{fusionar | Modelo_de_Capacidad_y_Madurez}} |
||
{{fusionar | CMMI}} |
|||
El '''Modelo de Capacidad y Madurez''' o '''CMM''' (''Capability Maturity Model''), es un modelo de evaluación de los [[proceso | procesos]] de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la [[Universidad Carnegie-Mellon]] para el SEI ([[Software Engineering Institute]]). |
|||
El '''Modelo de Madurez de la Capacidad para el desarrollo de Software''' (''Capability Maturity Model for Software'', '''SW-CMM''') es un modelo de procesos para el desarrollo y mantenimiento de sistemas de software, diseñado sobre los criterios: |
|||
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. |
|||
== El modelo CMM == |
|||
* La calidad de un producto o sistema es consecuencia directa de los procesos empleados en su desarrollo. |
|||
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa, DoD), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o [[SW-CMM]] (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993. |
|||
* Las organizaciones que desarrollan software presentan un atributo denominado madurez, cuya medida es proporcional a los niveles de capacidad e institucionalización de los procesos que emplean en su trabajo. |
|||
== Origen == |
|||
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: |
|||
Fue diseñado a finales de los ochenta por [[Software Engineering Institute]] (SEI) a instancias del Congreso Norteamericano, como medio para evaluar a las empresas suministradoras de software para el Departamento de Defensa Norteamericano. |
|||
:*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 |
|||
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez. |
|||
CMM (como se le denomina abreviadamente) define 5 niveles de madurez para las organizaciones, en función de cuáles son los procesos que emplean en el desarrollo y mantenimiento de software y los grados de capacidad e institucionalización de cada uno; y puede emplearse con dos finalidades: |
|||
Los niveles son: |
|||
* Criterio para la evaluación de la madurez de la organización. |
|||
:'''1 - Inicial.''' Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible. |
|||
* Guía para la mejora de sus procesos. |
|||
==Evolución== |
|||
:'''2 - Repetible.''' En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente. |
|||
Tras su creación en 1984 SEI comenzó la investigación para desarrollar un marco de mejora y evaluación de la previsibilidad y calidad de las empresas y el resultado se denominó "Capability Maturity Model for Software" SW-CMM o abreviadamente CMM, cuya versión 1.0 se publicó en Agosto de 1991. |
|||
Posteriormente se publicaron las revisiones 1.1 en 1993 y 1.2 en 1997. |
|||
Hoy es un modelo obsoleto, que SEI ya no mantiene desde que en 2000 fue relevado e integrado en el nuevo [[CMMI]]. |
|||
:'''3 - Definido.''' Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de [[revisión por pares]] (''peer reviews''). |
|||
==Niveles de madurez definidos en SW-CMM== |
|||
:'''4 - Gestionado.''' Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad. |
|||
===Nivel 1: Inicial=== |
|||
Los resultados de calidad obtenidos son consecuencia de las personas y de las herramientas que emplean. No de los procesos, porque o no los hay o no se emplean. |
|||
:'''5 - Optimizado.''' La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación. |
|||
===Nivel 2: Repetible=== |
|||
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 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. |
|||
Se considera un Nivel 2 de madurez cuando se llevan a cabo prácticas básicas de gestión de proyectos, de gestión de requisitos, control de versiones y de los trabajos realizados por subcontratistas. Los equipos de los proyectos pueden aprovechar las prácticas realizadas para aplicarlas en nuevos proyectos. |
|||
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. |
|||
Las prácticas que deben ser realizadas por cada Area 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: '''i)'''Compromiso de la realización, '''ii)''' La capacidad de realización, '''iii)''' Las actividades realizadas, '''iv)''' Las mediciones y el análisis, '''v)''' La verificación de la implementación. |
|||
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. |
|||
Se considera típico que una organización dedique unos 18 meses para progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso intenso de la dirección. |
|||
Como consecuencia, muchas organizaciones que realizan funciones de factoría de software o, en general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de los países en el que más organizaciones certificadas exista sea [[India]], donde han florecido las factorías de software que trabajan para clientes estadounidenses y europeos. |
|||
A partir de 2001, en que se presentó el modelo [[CMMI]], el SEI ha dejado de desarrollar el SW-CMM, cesando la formación de los evaluadores en diciembre de 2003, quienes dispondrán hasta fin de 2005 para reciclarse al CMMI. Las organizaciones que sigan el modelo SW-CMM podrán continuar haciéndolo, pero ya no podrán ser certificadas a partir de fin de 2005. |
|||
== Otros modelos == |
|||
''' [[CMMI]] ''' |
|||
Integración de modelos (CMM-SW, SE-CMM, IPD-CMM) |
|||
''' SE-CMM ''' |
|||
El '''Modelo de Capacidad y Madurez en la Ingeniería de Sistemas''' fue publicado por el SEI en noviembre de 1995. Está dedicado a las actividades de ingeniería de sistemas. |
|||
Define 18 áreas de proceso divididas en tres grupos: |
|||
*Ingeniería (7) |
|||
*Proyectos (5) |
|||
*Organizativas (6) |
|||
No utiliza niveles de madurez generales sino que en cada área de proceso una organización puede alcanzar un determinado nivel de madurez. |
|||
Al igual que el SW-CMM, ha sido integrado en el CMMI. |
|||
''' IPD-CMM ''' |
|||
El '''Modelo de Capacidad y Madurez para el Desarrollo Integrado de Productos''' fue propuesto como un borrador por el SEI en 1997, pero quedó integrado en el CMMI al publicarse este en el año 2000. |
|||
''' P-CMM ''' |
|||
'''Modelo de Capacidad y Madurez para Recursos Humanos''' |
|||
''' SA-CMM ''' |
|||
'''Modelo de Capacidad y Madurez para la Adquisición de Software''' |
|||
''' S3M ''' |
|||
'''Modelo de Capacidad y Madurez para la mantenimiento del software''' |
|||
== Otros modelos CMM == |
|||
=== SSE-CMM === |
|||
El '''System Security Engineering Capability Maturity Model''' o Modelo de Capacidad y Madurez 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. |
|||
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 "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). |
|||
=== Incapability Inmaturity Model === |
|||
Con mucho sentido del humor, y bastante conocimiento de causa, Anthony Finkelstein describió que hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM (en el que aunque sea de modo heroico se llega a producir software), proponiendo que existen niveles negativos o de inmadurez. Este «Modelo de Incapacidad e Inmadurez», que fue refinado posteriormente por Tom Schorsch, incluye tres niveles de idiotez: |
|||
*0 -Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito. Su gran preocupación es la reutilización del software. |
|||
*-1 -Organizaciones obstructivas. Imponen procesos contra-productivos para impedir cualquier avance. Se concentran en desarrollar entornos de desarrollo y repositorios. |
|||
*-2 -Organizaciones desdeñosas. Desprecian cualquier institucionalización de buenas prácticas. Su gran objetivo es la programación automática. |
|||
== Crítica == |
|||
Frecuentemente se critica al modelo CMM por no ser más específico en la definición de los procesos. Para guiar a las organizaciones a definir y mejorar sus procesos indica qué actividades han de realizar, pero nada sobre cómo hacerlo. Esto es así tanto en lo referente a la ingeniería como a las herramientas o técnicas de gestión, aunque hace una curiosa excepción en las [[Revisión por pares|revisiones por pares]] (''peer reviews''). |
|||
Del mismo modo, aunque insiste continuamente en la necesidad de las métricas, no da ninguna guía concreta del tipo de métricas que son aceptables para una correcta práctica profesional. |
|||
Los técnicos se quejan a menudo de la enorme carga de "papeleo" que impone el modelo, viéndolo más como un mecanismo de control por la dirección que una herramienta que les ayude en su trabajo. |
|||
También resulta muy complejo, más todavía el CMMI, lo que hace que durante algún tiempo resulte para mucha gente algo esotérico. |
|||
===Nivel 3: Definido=== |
|||
== Referencias == |
|||
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. |
|||
===Nivel 4: Gestionado=== |
|||
'''Gonzalo Cuevas Agustín:''' |
|||
La organización mide la calidad del producto y del proceso de forma cuantitativa con base a métricas establecidas. |
|||
''Una Guía del CMM. Para Comprender el Modelo de Madurez de Capacidad del Software. |
|||
Traducción del Inglés "A Guide to the CMM" de Kenneth M. Dymond. |
|||
1998.'' |
|||
La capacidad de los procesos empleados es previsible, y el sistema de medición permite detectar si las variaciones de capacidad exceden los rangos aceptables para adoptar medidas correctivas. |
|||
'''Mary Beth Chrissis:''' |
|||
''Libro con la descripción de las Areas de Procesos del Modelo CMMI. |
|||
"CMMI : Guidelines for Process Integration and Product Improvement de SEI.'' |
|||
===Nivel 5: Optimizado=== |
|||
La mejora continua de los procesos afecta a toda la organización, que cuenta con medios para identificar las debilidades y reforzar la prevención de defectos. Se analizan de forma sistemática datos relativos a la eficacia de los procesos de software para analizar el coste y el beneficio de las adaptaciones y las mejoras. |
|||
Se analizan los defectos de los proyectos para determinar las causas, y su mapeado sobre los procesos. Es el nivel más alto de CMM por el momento. |
|||
== Enlaces externos == |
|||
==Véase también== |
|||
* [http://www.sei.cmu.edu/ SEI - Software Engeniering Institute] |
|||
* [[CMMI]] |
|||
* [http://www.s3m.ca/ para el mantenimiento de software](en inglés) |
|||
* [[Modelo de Capacidad y Madurez]] (CMM) |
|||
* [http://www.sse-cmm.org System Security Engineering CMM] |
|||
* [http://www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/immaturity.pdf Finkelstein's Capability Immaturity Model paper (PDF file)] |
|||
* [http://www.stsc.hill.af.mil/crosstalk/1996/11/xt96d11h.asp Capt. Tom Schorsch's Capability Immaturity Model study] |
|||
* [http://www.ingenierosoftware.com/calidad/cmm-cmmi.php Introducción a los niveles CMM CMMI] |
|||
* [http://survey.cmmi.hu/ mini CMMI-survey](en inglés) |
|||
* [http://www.navegapolis.net/content/view/346/77/ Herramientas para auto-evaluación CMM y CMMI] |
|||
* [http://www.borland.com/us/services/cmmi.html Consulta en línea del modelo CMMI] (en inglés) |
|||
==Enlaces externos== |
|||
* [http://www.sei.cmu.edu/cmm/ Página oficial CMM. Acceso a descarga de los modelos] |
|||
* [http://www.navegapolis.net/index.php?option=com_content&task=view&id=330&Itemid=84 Sinopsis de los modelos CMM y CMMI] |
|||
[[Categoría:Programación]] |
|||
[[Categoría:Metodologías de desarrollo de software]] |
[[Categoría:Metodologías de desarrollo de software]] |
||
[[sk:SW-CMM]] |
|||
[[da:Capability Maturity Model]] |
|||
[[de:Capability Maturity Model]] |
|||
[[en:Capability Maturity Model]] |
|||
[[fi:CMM]] |
|||
[[fr:Capability Maturity Model]] |
|||
[[id:CMM]] |
|||
[[it:Capability Maturity Model]] |
|||
[[nl:Capability Maturity Model]] |
|||
[[no:Capability Maturity Model]] |
|||
[[pl:Capability Maturity Model]] |
|||
[[pt:Capability Maturity Model]] |
|||
[[ru:CMM]] |
|||
[[sk:Capability Maturity Model]] |
|||
[[sv:Capability Maturity Model]] |
|||
[[zh:能力成熟度模型]] |
|||
Revisión del 22:16 23 abr 2009
El Modelo de Madurez de la Capacidad para el desarrollo de Software (Capability Maturity Model for Software, SW-CMM) es un modelo de procesos para el desarrollo y mantenimiento de sistemas de software, diseñado sobre los criterios:
- La calidad de un producto o sistema es consecuencia directa de los procesos empleados en su desarrollo.
- Las organizaciones que desarrollan software presentan un atributo denominado madurez, cuya medida es proporcional a los niveles de capacidad e institucionalización de los procesos que emplean en su trabajo.
Origen
Fue diseñado a finales de los ochenta por Software Engineering Institute (SEI) a instancias del Congreso Norteamericano, como medio para evaluar a las empresas suministradoras de software para el Departamento de Defensa Norteamericano.
CMM (como se le denomina abreviadamente) define 5 niveles de madurez para las organizaciones, en función de cuáles son los procesos que emplean en el desarrollo y mantenimiento de software y los grados de capacidad e institucionalización de cada uno; y puede emplearse con dos finalidades:
- Criterio para la evaluación de la madurez de la organización.
- Guía para la mejora de sus procesos.
Evolución
Tras su creación en 1984 SEI comenzó la investigación para desarrollar un marco de mejora y evaluación de la previsibilidad y calidad de las empresas y el resultado se denominó "Capability Maturity Model for Software" SW-CMM o abreviadamente CMM, cuya versión 1.0 se publicó en Agosto de 1991. Posteriormente se publicaron las revisiones 1.1 en 1993 y 1.2 en 1997.
Hoy es un modelo obsoleto, que SEI ya no mantiene desde que en 2000 fue relevado e integrado en el nuevo CMMI.
Niveles de madurez definidos en SW-CMM
Nivel 1: Inicial
Los resultados de calidad obtenidos son consecuencia de las personas y de las herramientas que emplean. No de los procesos, porque o no los hay o no se emplean.
Nivel 2: Repetible
Se considera un Nivel 2 de madurez cuando se llevan a cabo prácticas básicas de gestión de proyectos, de gestión de requisitos, control de versiones y de los trabajos realizados por subcontratistas. Los equipos de los proyectos pueden aprovechar las prácticas realizadas para aplicarlas en nuevos proyectos.
Nivel 3: Definido
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.
Nivel 4: Gestionado
La organización mide la calidad del producto y del proceso de forma cuantitativa con base a métricas establecidas.
La capacidad de los procesos empleados es previsible, y el sistema de medición permite detectar si las variaciones de capacidad exceden los rangos aceptables para adoptar medidas correctivas.
Nivel 5: Optimizado
La mejora continua de los procesos afecta a toda la organización, que cuenta con medios para identificar las debilidades y reforzar la prevención de defectos. Se analizan de forma sistemática datos relativos a la eficacia de los procesos de software para analizar el coste y el beneficio de las adaptaciones y las mejoras.
Se analizan los defectos de los proyectos para determinar las causas, y su mapeado sobre los procesos. Es el nivel más alto de CMM por el momento.