El modelo de madurez de capacidad ( CMM ) es un modelo de desarrollo creado en 1986 después de un estudio de datos recopilados de organizaciones que contrataron con el Departamento de Defensa de EE. UU. , Que financió la investigación. El término "madurez" se refiere al grado de formalidad y optimización de los procesos, desde las prácticas ad hoc , a los pasos formalmente definidos, a las métricas de resultados gestionados, a la optimización activa de los procesos.
El objetivo del modelo es mejorar los procesos de desarrollo de software existentes , pero también se puede aplicar a otros procesos.
En 2006, el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon desarrolló la Integración del Modelo de Madurez de Capacidades , que ha reemplazado en gran medida al CMM y resuelve algunos de sus inconvenientes. [1]
Descripción general
El modelo de madurez de la capacidad se desarrolló originalmente como una herramienta para evaluar objetivamente la capacidad de los procesos de los contratistas gubernamentales para implementar un proyecto de software contratado. El modelo se basa en el marco de madurez de procesos descrito por primera vez en IEEE Software [2] y, más tarde, en el libro de 1989 Managing the Software Process de Watts Humphrey . Posteriormente se publicó en un informe en 1993 [3] y como libro de los mismos autores en 1995.
Aunque el modelo proviene del campo del desarrollo de software , también se utiliza como modelo para ayudar en los procesos comerciales en general, y también se ha utilizado ampliamente en todo el mundo en oficinas gubernamentales, comercio e industria. [4] [5]
Historia
Necesidad previa de procesos de software
En la década de 1980, el uso de computadoras se generalizó, se volvió más flexible y menos costoso. Las organizaciones comenzaron a adoptar sistemas de información computarizados y la demanda de desarrollo de software creció significativamente. Muchos procesos para el desarrollo de software estaban en su infancia, con pocos enfoques estándar o de " mejores prácticas " definidos.
Como resultado, el crecimiento estuvo acompañado de dolores de crecimiento: el fracaso del proyecto era común, el campo de la informática aún estaba en sus primeros años y las ambiciones de escala y complejidad del proyecto excedían la capacidad del mercado para ofrecer productos adecuados dentro de un presupuesto planificado. Individuos como Edward Yourdon , [6] Larry Constantine , Gerald Weinberg , [7] Tom DeMarco , [8] y David Parnas comenzaron a publicar artículos y libros con resultados de investigación en un intento de profesionalizar los procesos de desarrollo de software. [4] [9]
En la década de 1980, varios proyectos militares estadounidenses en los que participaban subcontratistas de software superaron el presupuesto y se completaron mucho más tarde de lo planeado, si es que se completaron. En un esfuerzo por determinar por qué estaba ocurriendo esto, la Fuerza Aérea de los Estados Unidos financió un estudio en el Instituto de Ingeniería de Software (SEI).
Precursor
La primera aplicación de un modelo de madurez por etapas a TI no fue por CMU / SEI, sino por Richard L. Nolan , quien, en 1973, publicó el modelo de etapas de crecimiento para organizaciones de TI. [10]
Watts Humphrey comenzó a desarrollar sus conceptos de madurez de procesos durante las últimas etapas de su carrera de 27 años en IBM. [11]
Desarrollo en Software Engineering Institute
El desarrollo activo del modelo por parte del Instituto de Ingeniería de Software (SEI) del Departamento de Defensa de EE. UU. Comenzó en 1986 cuando Humphrey se unió al Instituto de Ingeniería de Software ubicado en la Universidad Carnegie Mellon en Pittsburgh, Pensilvania, después de retirarse de IBM. A pedido de la Fuerza Aérea de EE. UU., Comenzó a formalizar su Marco de Madurez de Procesos para ayudar al Departamento de Defensa de EE. UU. A evaluar la capacidad de los contratistas de software como parte de la adjudicación de contratos.
El resultado del estudio de la Fuerza Aérea fue un modelo para que el ejército lo usara como una evaluación objetiva de la madurez de la capacidad de proceso de los subcontratistas de software. Humphrey basó este marco en la anterior cuadrícula de madurez de gestión de calidad desarrollada por Philip B. Crosby en su libro "Quality is Free". [12] El enfoque de Humphrey difería debido a su visión única de que las organizaciones maduran sus procesos en etapas basadas en la resolución de problemas de procesos en un orden específico. Humphrey basó su enfoque en la evolución por etapas de un sistema de prácticas de desarrollo de software dentro de una organización, en lugar de medir la madurez de cada proceso de desarrollo por separado de forma independiente. Por lo tanto, diferentes organizaciones han utilizado el CMM como una herramienta general y poderosa para comprender y luego mejorar el rendimiento general de los procesos comerciales.
El modelo de madurez de capacidad (CMM) de Watts Humphrey se publicó en 1988 [13] y como libro en 1989, en Managing the Software Process . [14]
Las organizaciones se evaluaron originalmente mediante un cuestionario de madurez de procesos y un método de evaluación de capacidad de software ideado por Humphrey y sus colegas en el Instituto de Ingeniería de Software.
La representación completa del modelo de madurez de la capacidad como un conjunto de áreas de proceso y prácticas definidas en cada uno de los cinco niveles de madurez se inició en 1991, y la versión 1.1 se completó en enero de 1993. [3] El CMM se publicó como un libro [15 ] en 1995 por sus autores principales, Mark C. Paulk, Charles V. Weber, Bill Curtis y Mary Beth Chrissis. Estados Unidos de América Nueva York, Estados Unidos.
Integración del modelo de madurez de capacidad
La aplicación del modelo CMM en el desarrollo de software a veces ha sido problemática. La aplicación de varios modelos que no están integrados dentro y en toda una organización podría resultar costosa en actividades de capacitación, evaluaciones y mejora. El proyecto Capability Maturity Model Integration (CMMI) se formó para resolver el problema del uso de múltiples modelos para los procesos de desarrollo de software, por lo que el modelo CMMI ha reemplazado al modelo CMM, aunque el modelo CMM sigue siendo un modelo de capacidad de proceso teórico general utilizado en el dominio público. [16] [ cita requerida ] [17]
Adaptado a otros procesos
El CMM fue pensado originalmente como una herramienta para evaluar la capacidad de los contratistas del gobierno para realizar un proyecto de software contratado. Aunque proviene del área de desarrollo de software, puede ser, ha sido y continúa siendo ampliamente aplicado como un modelo general de madurez de procesos (por ejemplo, procesos de gestión de servicios de TI ) en organizaciones de SI / TI (y otras).
Temas modelo
Modelos de madurez
Un modelo de madurez puede verse como un conjunto de niveles estructurados que describen qué tan bien los comportamientos, prácticas y procesos de una organización pueden producir de manera confiable y sostenible los resultados requeridos.
Un modelo de madurez se puede utilizar como punto de referencia para la comparación y como ayuda para la comprensión, por ejemplo, para la evaluación comparativa de diferentes organizaciones donde hay algo en común que se puede utilizar como base para la comparación. En el caso del CMM, por ejemplo, la base de comparación serían los procesos de desarrollo de software de las organizaciones.
Estructura
El modelo involucra cinco aspectos:
- Niveles de madurez: un proceso continuo de madurez de 5 niveles, donde el nivel superior (quinto) es un estado ideal teórico donde los procesos se gestionarían sistemáticamente mediante una combinación de optimización de procesos y mejora continua de procesos.
- Áreas de proceso clave: un área de proceso clave identifica un grupo de actividades relacionadas que, cuando se realizan juntas, logran un conjunto de metas consideradas importantes.
- Metas: las metas de un área de proceso clave resumen los estados que deben existir para que esa área de proceso clave se haya implementado de manera efectiva y duradera. La medida en que se han logrado las metas es un indicador de cuánta capacidad ha establecido la organización en ese nivel de madurez. Los objetivos significan el alcance, los límites y la intención de cada área de proceso clave.
- Características comunes : las características comunes incluyen prácticas que implementan e institucionalizan un área de proceso clave. Hay cinco tipos de características comunes: compromiso de desempeño, capacidad de desempeño, actividades realizadas, medición y análisis y verificación de la implementación.
- Prácticas clave: Las prácticas clave describen los elementos de infraestructura y práctica que contribuyen de manera más efectiva a la implementación e institucionalización del área.
Niveles
Hay cinco niveles definidos a lo largo del continuo del modelo y, según el SEI: "Se cree que la previsibilidad, la eficacia y el control de los procesos de software de una organización mejoran a medida que la organización asciende en estos cinco niveles. Aunque no es rigurosa, la evidencia empírica hasta la fecha apoya esta creencia ". [18]
- Inicial (heroísmo caótico, ad hoc, individual): el punto de partida para el uso de un proceso de repetición nuevo o indocumentado.
- Repetible : el proceso está al menos suficientemente documentado como para intentar repetir los mismos pasos.
- Definido : el proceso se define / confirma como un proceso comercial estándar.
- Capaz : el proceso se gestiona cuantitativamente de acuerdo con las métricas acordadas.
- Eficiente : la gestión de procesos incluye la optimización / mejora deliberada del proceso.
Dentro de cada uno de estos niveles de madurez hay áreas de proceso clave que caracterizan ese nivel, y para cada área hay cinco factores: metas, compromiso, capacidad, medición y verificación. Estos no son necesariamente exclusivos de CMM, ya que representan, como lo hacen, las etapas por las que las organizaciones deben atravesar en el camino hacia la madurez.
El modelo proporciona un continuo teórico a lo largo del cual la madurez del proceso se puede desarrollar de forma incremental de un nivel al siguiente. Saltarse niveles no está permitido / es factible.
- Nivel 1 - Inicial
- Es característico de los procesos de este nivel que están (típicamente) indocumentados y en un estado de cambio dinámico, y tienden a ser impulsados de manera ad hoc , descontrolada y reactiva por usuarios o eventos. Esto proporciona un entorno caótico o inestable para los procesos. (Ejemplo: un cirujano que realiza una nueva operación una pequeña cantidad de veces; se desconocen los niveles de resultado negativo).
- Nivel 2 - Repetible
- Es característico de este nivel de madurez que algunos procesos sean repetibles, posiblemente con resultados consistentes. Es poco probable que la disciplina de procesos sea rigurosa, pero cuando existe, puede ayudar a garantizar que los procesos existentes se mantengan en momentos de estrés.
- Nivel 3 - Definido
- Es característico de los procesos en este nivel que existen conjuntos de procesos estándar definidos y documentados establecidos y sujetos a cierto grado de mejora con el tiempo. Estos procesos estándar están en su lugar. Es posible que los procesos no se hayan utilizado de manera sistemática o repetida, lo suficiente para que los usuarios se vuelvan competentes o para que el proceso se valide en una variedad de situaciones. Esto podría considerarse una etapa de desarrollo: con el uso en una gama más amplia de condiciones y el desarrollo de la competencia del usuario, el proceso puede desarrollarse hasta el siguiente nivel de madurez.
- Nivel 4: administrado (capaz)
- Es característico de los procesos en este nivel que, utilizando métricas de proceso, el logro efectivo de los objetivos del proceso se puede evidenciar en una variedad de condiciones operativas. Se ha probado la idoneidad del proceso en múltiples entornos y se ha perfeccionado y adaptado el proceso. Los usuarios del proceso han experimentado el proceso en múltiples y variadas condiciones y pueden demostrar su competencia. La madurez del proceso permite adaptaciones a proyectos particulares sin pérdidas medibles de calidad o desviaciones de las especificaciones. La capacidad del proceso se establece a partir de este nivel. (Ejemplo: cirujano que realiza una operación cientos de veces con niveles de resultado negativo que se acercan a cero).
- Nivel 5 - Optimización (eficiente)
- Una característica de los procesos en este nivel es que el enfoque está en mejorar continuamente el desempeño del proceso a través de cambios / mejoras tecnológicos tanto incrementales como innovadores. En el nivel de madurez 5, los procesos se preocupan por abordar las causas estadísticas comunes de la variación del proceso y cambiar el proceso (por ejemplo, para cambiar la media del rendimiento del proceso) para mejorar el rendimiento del proceso. Esto se haría al mismo tiempo que se mantiene la probabilidad de lograr los objetivos cuantitativos de mejora de procesos establecidos.
Entre 2008 y 2019, alrededor del 12% de las tasaciones otorgadas se encontraban en los niveles de madurez 4 y 5. [19] [20]
Crítica
Originalmente, el modelo estaba destinado a evaluar la capacidad de los contratistas gubernamentales para realizar un proyecto de software. Se ha utilizado y puede ser adecuado para ese propósito, pero los críticos [ ¿quién? ] señaló que la madurez del proceso de acuerdo con el CMM no era necesariamente obligatoria para el desarrollo de software exitoso.
Marco de proceso de software
El marco del proceso de software documentado está destinado a guiar a quienes deseen evaluar la coherencia de una organización o proyecto con las áreas clave del proceso. Para cada nivel de madurez hay cinco tipos de listas de verificación:
Tipo Descripción Política Describe el contenido de la política y los objetivos de KPA recomendados por las áreas de proceso clave. Estándar Describe el contenido recomendado de productos de trabajo seleccionados descritos en las Áreas de proceso clave. Proceso Describe el contenido de la información del proceso recomendado por las áreas clave del proceso. Estos se refinan en listas de verificación para: - Funciones, criterios de entrada, entradas, actividades, salidas, criterios de salida, revisiones y auditorías, productos de trabajo gestionados y controlados, mediciones, procedimientos documentados, formación y herramientas.
Procedimiento Describe el contenido recomendado de los procedimientos documentados descritos en las Áreas de proceso clave. Resumen de niveles Proporciona una descripción general de todo el nivel de madurez. Estos se refinan aún más en listas de verificación para: - Propósitos, metas, políticas y estándares de las áreas clave de proceso; descripciones de procesos; procedimientos; capacitación; herramientas; revisiones y auditorías; productos del trabajo; mediciones
Ver también
- Modelo de inmadurez de capacidad
- Integración del modelo de madurez de capacidad
- Modelo de madurez de capacidades de las personas
- Prueba del modelo de madurez
Referencias
- ↑ Nayab, N. (27 de abril de 2010). "La diferencia entre CMMI vs CMM" . Bright Hub PM . Consultado el 15 de febrero de 2020 .
- ^ Humphrey, WS (marzo de 1988). "Caracterización del proceso de software: un marco de madurez". Software IEEE . 5 (2): 73–79. doi : 10.1109 / 52.2014 . ISSN 0740-7459 . S2CID 1008347 .
- ^ a b Paulk, Mark C .; Weber, Carlos V; Curtis, Bill ; Chrissis, Mary Beth (febrero de 1993). "Modelo de madurez de capacidad para software (versión 1.1)" (PDF) . Informe técnico . Pittsburgh, PA: Instituto de Ingeniería de Software, Universidad Carnegie Mellon. CMU / SEI-93-TR-024 ESC-TR-93-177.
- ^ a b McKay, Vivienne. "¿Qué es el modelo de madurez de la capacidad? (CMM) | Madurez del proceso | Preguntas frecuentes" . www.selectbs.com . Consultado el 20 de marzo de 2017 .
- ^ White, Sarah K. (16 de marzo de 2018). "¿Qué es CMMI? Un modelo para optimizar los procesos de desarrollo" . CIO . Consultado el 4 de junio de 2020 .
- ^ Yourdon, E. (1989). 1989. Análisis estructurado moderno . Nueva York: Prentice Hall. ISBN 978-0135986240.
- ^ Weinberg, GM (1992). Gestión de software de calidad: anticipar el cambio. Vol. 1: Pensamiento sistémico . Nueva York: Dorset House Pub. ISBN 978-0-932633-72-9.
- ^ DeMarco, T .; Lister, T. (1997). Bailando con osos: gestión de riesgos en proyectos de software . Nueva York: Dorset House Pub. ISBN 978-0-932633-60-6.
- ^ "CMMI-Six Sigma, sus raíces" . Proceso de mejora de Partners, Inc . 2011-01-23 . Consultado el 11 de mayo de 2018 .
- ^ Nolan, RL (julio de 1973). "Gestión del recurso informático: una hipótesis de etapa". Comm. ACM . 16 (7): 399–405. doi : 10.1145 / 362280.362284 . S2CID 14053595 .
- ^ "Modelo de madurez de la capacidad de las personas (P-CMM) versión 2.0" . resources.sei.cmu.edu . Consultado el 17 de enero de 2017 .
- ^ Crosby, PB (1979). La calidad es gratis . Nueva York: New American Library . ISBN 0-451-62247-2.
- ^ Humphrey, WS (marzo de 1988). "Caracterización del proceso de software: un marco de madurez" (PDF) . Software IEEE . 5 (2): 73–79. doi : 10.1109 / 52.2014 . S2CID 1008347 .
- ^ Humphrey, WS (1989). Gestión del proceso de software . Serie SEI en ingeniería de software. Reading, Mass .: Addison-Wesley . ISBN 0-201-18095-2.
- ^ Paulk, Mark C .; Weber, Carlos V; Curtis, Bill ; Chrissis, Mary Beth (1995). El modelo de madurez de la capacidad: directrices para mejorar el proceso de software . Serie SEI en ingeniería de software. Reading, Mass .: Addison-Wesley . ISBN 0-201-54664-7.
- ^ Juran (26 de agosto de 2010). Calidad de Juran Hb 6E . McGraw-Hill Education (India) Pvt Limited. ISBN 9780071070898.
- ^ Natarajan, R (2015). Actas de la Conferencia Internacional sobre Transformaciones en la Educación en Ingeniería . Saltador.
- ^ Apéndice del SDLC del estado de Michigan sobre CMM Atestigua el uso del texto en 2001, por lo que no podría haber venido de aquí.
- ^ "Tendencias de adopción de CMMI - Actualización de mitad de año de 2019" . Instituto CMMI . 2019-10-21.
- ^ Fishman, Charles (31 de diciembre de 1996). "Escriben las cosas correctas" . Empresa rápida . Consultado el 15 de febrero de 2020 .
enlaces externos
- Instituto CMMI
- Modelo de madurez de capacidad en Curlie
- Modelos de madurez de la arquitectura en The Open Group