Modelo de Capacidad de Madurez

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

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 al Departamento de Defensa de EE. UU., quien financió la investigación. El término "vencimiento" se relaciona con el grado de formalidad y optimización de los procesos, desde prácticas ad hoc, a pasos formalmente definidos, a 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 capacidad, que ha reemplazado en gran medida al CMM y soluciona algunos de sus inconvenientes.

Resumen

El modelo de madurez de la capacidad se desarrolló originalmente como una herramienta para evaluar objetivamente la capacidad de los contratistas gubernamentales' procesos para implementar un proyecto de software contratado. El modelo se basa en el marco de madurez del proceso descrito por primera vez en IEEE Software y, más tarde, en el libro de 1989 Managing the Software Process de Watts Humphrey. Posteriormente se publicó en un informe en 1993 y como libro de los mismos autores en 1995.

Aunque el modelo proviene del campo del desarrollo de software, también se usa como modelo para ayudar en los procesos comerciales en general, y también se ha usado ampliamente en todo el mundo en oficinas gubernamentales, comercio e industria.

Historia

Necesidad previa de procesos de software

En la década de 1980, el uso de computadoras se hizo más generalizado, 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 estándares o "mejores prácticas" enfoques definidos.

Como resultado, el crecimiento estuvo acompañado de dolores de crecimiento: el fracaso de los proyectos era común, el campo de la informática aún estaba en sus primeros años y las ambiciones de escala y complejidad de los proyectos excedían la capacidad del mercado para entregar productos adecuados dentro de un presupuesto planificado. Individuos como Edward Yourdon, Larry Constantine, Gerald Weinberg, Tom DeMarco 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.

En la década de 1980, varios proyectos militares de EE. UU. que involucraban a 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é ocurría esto, la Fuerza Aérea de los Estados Unidos financió un estudio en el Instituto de Ingeniería de Software (SEI).

Precursora

(feminine)

La primera aplicación de un modelo de madurez por etapas a TI no fue de CMU/SEI, sino de Richard L. Nolan, quien, en 1973, publicó el modelo de etapas de crecimiento para organizaciones de TI.

Watts Humphrey comenzó a desarrollar sus conceptos de madurez de procesos durante las últimas etapas de su carrera de 27 años en IBM.

Desarrollo en el Instituto de Ingeniería de Software

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 jubilarse de IBM. A pedido de la Fuerza Aérea de los EE. UU., comenzó a formalizar su marco de madurez de procesos para ayudar al Departamento de Defensa de los 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 los militares lo utilicen como una evaluación objetiva de los subcontratistas de software' madurez de la capacidad del proceso. Humphrey basó este marco en la Matriz de madurez de gestión de calidad anterior desarrollada por Philip B. Crosby en su libro 'La calidad es gratis'. 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, el CMM ha sido utilizado por diferentes organizaciones 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 y como libro en 1989, en Managing the Software Process.

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 del 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. El CMM se publicó como libro 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 capacidades

La aplicación del modelo CMM en el desarrollo de software a veces ha sido problemática. La aplicación de múltiples modelos que no están integrados dentro y entre una organización podría resultar costosa en actividades de capacitación, evaluación 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 continúa siendo un modelo de capacidad de proceso teórico general utilizado en el dominio publico

Adaptado a otros procesos

El CMM se pensó originalmente como una herramienta para evaluar la capacidad de los contratistas gubernamentales para realizar un proyecto de software contratado. Aunque proviene del área de desarrollo de software, puede ser, ha sido y sigue siendo ampliamente aplicado como un modelo general de madurez de proceso (por ejemplo, procesos de gestión de servicios de TI) en SI/ TI (y otras) organizaciones.

Temas modelo

Modelos de madurez

Un modelo de madurez puede verse como un conjunto de niveles estructurados que describen qué tan bien los comportamientos, las prácticas y los procesos de una organización pueden producir de manera confiable y sostenible los resultados requeridos.

Un modelo de madurez se puede usar 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 usar como base para la comparación. En el caso del CMM, por ejemplo, la base de comparación sería el modelo de organizaciones' procesos de desarrollo de software.

Estructura

El modelo involucra cinco aspectos:

  • Niveles de madurez: a 5 niveles de madurez de proceso continuo - donde el nivel más alto (5o) es un estado ideal nocional donde los procesos se gestionarían sistemáticamente mediante una combinación de optimización de procesos y mejora continua de procesos.
  • Principales áreas de proceso: a Key Process Area identifica un grupo de actividades conexas que, cuando se realizan conjuntamente, alcanzan un conjunto de objetivos considerados importantes.
  • Objetivos: los objetivos de una esfera clave del proceso resumen los estados que deben existir para que esa esfera clave del proceso se haya aplicado de manera eficaz y duradera. La medida en que se han logrado los objetivos es un indicador de la capacidad que la organización ha establecido a ese nivel de madurez. Los objetivos significan el alcance, los límites y la intención de cada área clave del proceso.
  • Características comunes: Las características comunes incluyen prácticas que implementan e institucionalizan un área clave del proceso. Existen cinco tipos de características comunes: compromiso de realizar, capacidad de realizar, actividades realizadas, medición y análisis y verificación de la implementación.
  • Prácticas clave: Las prácticas fundamentales describen los elementos de infraestructura y práctica que contribuyen más eficazmente a la aplicación e institucionalización de la zona.

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 niveles. cinco niveles Si bien no es rigurosa, la evidencia empírica hasta la fecha respalda esta creencia.

  1. Inicial (Kotic, ad hoc, individual heroics) - el punto de partida para el uso de un nuevo o indocumentado proceso de repetición.
  2. Repetible - el proceso se documenta al menos lo suficiente para intentar repetir los mismos pasos.
  3. Definido - el proceso se define/confirma como un proceso de negocio estándar
  4. Capable - el proceso se gestiona cuantitativamente de acuerdo con las métricas acordadas.
  5. 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: objetivos, 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 pasar 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 manera incremental de un nivel al siguiente. Saltarse niveles no está permitido ni es factible.

Nivel 1 - Inicial
Es característica de los procesos a este nivel que son (típicamente) indocumentados y en un estado de cambio dinámico, que tienden a ser impulsados en un ad hoc, de manera incontrolada y reactiva por usuarios o eventos. Esto proporciona un ambiente caótico o inestable para los procesos. (Ejemplo - un cirujano que realiza una nueva operación un pequeño número de veces - los niveles de resultado negativo no se conocen).
Nivel 2 - Repetible
Es característico de este nivel de madurez que algunos procesos son repetibles, posiblemente con resultados consistentes. Es poco probable que la disciplina del proceso sea rigurosa, pero donde exista puede ayudar a asegurar que los procesos existentes se mantengan durante tiempos de estrés.
Nivel 3 - Definido
Es característico de los procesos a este nivel que existen conjuntos de procesos estándar definidos y documentados establecidos y sujetos a algún grado de mejora con el tiempo. Estos procesos estándar están en vigor. Los procesos pueden no haberse utilizado sistemáticamente o repetidamente, suficiente para que los usuarios sean competentes o el proceso que se valide en una serie de situaciones. Esto podría considerarse una etapa de desarrollo - con uso en una gama más amplia de condiciones y desarrollo de la competencia de los usuarios el proceso puede desarrollarse hasta el siguiente nivel de madurez.
Nivel 4 - Gestionado (Capítulo)
Es característico de los procesos a este nivel que, utilizando métricas de procesos, el logro efectivo de los objetivos del proceso puede evidenciarse en una gama de condiciones operacionales. La idoneidad del proceso en múltiples ambientes ha sido probada y el proceso refinado y adaptado. Los usuarios del proceso han experimentado el proceso en múltiples y variadas condiciones, y son capaces de demostrar competencia. La madurez del proceso permite adaptarse a proyectos particulares sin pérdidas mensurables de calidad o desviaciones de especificaciones. La capacidad de 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 aproximan a cero).
Nivel 5 - Optimización (Eficiente)
Es una característica de los procesos a este nivel que se centra en mejorar continuamente el rendimiento de los procesos mediante cambios tecnológicos/mejoras incrementales e innovadores. A nivel de vencimiento 5, los procesos están preocupados por abordar las estadísticas Causas comunes de la variación del proceso y la modificación del 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 mantendría la probabilidad de alcanzar los objetivos cuantitativos establecidos de mejora del proceso.

Entre 2008 y 2019, alrededor del 12 % de las tasaciones realizadas se encontraban en los niveles de madurez 4 y 5.

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 señalaron que la madurez del proceso de acuerdo con el CMM no era necesariamente obligatoria para un desarrollo de software exitoso.

Marco de procesos de software

El marco del proceso de software documentado pretende guiar a aquellos que deseen evaluar la coherencia de una organización o un 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 del KPA recomendados por las áreas clave del proceso.
Estándar Describe el contenido recomendado de determinados productos de trabajo descritos en las áreas clave del proceso.
Proceso Describe el contenido de información de proceso recomendado por las áreas clave del proceso. Estos son refinados en listas de verificación para:
  • Funciones, criterios de entrada, insumos, actividades, productos, criterios de salida, exámenes y auditorías, productos de trabajo gestionados y controlados, mediciones, procedimientos documentados, capacitación e instrumentos
Procedimiento Describe el contenido recomendado de los procedimientos documentados descritos en las áreas clave del proceso.
Nivel superado Proporciona una visión general de todo un nivel de madurez. Estos se perfeccionan aún más en las listas de verificación para:
  • Principales áreas de proceso propósitos, metas, políticas y normas; descripciones de procesos; procedimientos; capacitación; instrumentos; exámenes y auditorías; productos de trabajo; mediciones

Contenido relacionado

Ethernet

Almacén de datos

Aeronáutica

Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save