Ingeniería de Software | Modelo de madurez de capacidad (CMM)

CMM fue desarrollado por el Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon en 1987. 

  • No es un modelo de proceso de software. Es un marco que se utiliza para analizar el enfoque y las técnicas seguidas por cualquier organización para desarrollar productos de software.
  • También proporciona pautas para mejorar aún más la madurez del proceso utilizado para desarrollar esos productos de software.
  • Se basa en una profunda retroalimentación y prácticas de desarrollo adoptadas por las organizaciones más exitosas del mundo.
  • Este modelo describe una estrategia para la mejora del proceso de software que debe seguirse moviéndose a través de 5 niveles diferentes.
  • Cada nivel de madurez muestra un nivel de capacidad del proceso. Todos los niveles, excepto el nivel 1, se describen con más detalle en las Áreas clave de proceso (KPA).

Deficiencias de SEI/CMM:

  • Fomenta el logro de un mayor nivel de madurez en algunos casos al desplazar la verdadera misión, que es mejorar el proceso y la calidad general del software.
  • Solo ayuda si se implementa al principio del proceso de desarrollo de software.
  • No tiene una base teórica formal y, de hecho, se basa en la experiencia de personas muy capacitadas.
  • No tiene un buen soporte empírico y este mismo soporte empírico también podría construirse para soportar otros modelos.

Áreas de proceso clave (KPA): 
cada una de estas KPA define los requisitos básicos que debe cumplir un proceso de software para satisfacer la KPA y alcanzar ese nivel de madurez. 

Conceptualmente, las áreas de proceso clave forman la base para el control de gestión del proyecto de software y establecen un contexto en el que se aplican métodos técnicos, se producen productos de trabajo como modelos, documentos, datos, informes, etc., se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. 

Los 5 niveles de CMM son los siguientes: 

Nivel-1: Inicial – 

  • No hay KPA definidos.
  • Los procesos seguidos son Adhoc e inmaduros y no están bien definidos.
  • Entorno inestable para el desarrollo de software.
  • No hay base para predecir la calidad del producto, el tiempo de finalización, etc.

Nivel-2: Repetible – 

  • Se enfoca en establecer políticas básicas de gestión de proyectos.
  • La experiencia con proyectos anteriores se utiliza para gestionar nuevos proyectos de naturaleza similar.
  • Planificación del proyecto : incluye la definición de los recursos necesarios, objetivos, restricciones, etc. para el proyecto. Presenta un plan detallado que debe seguirse sistemáticamente para completar con éxito un software de buena calidad.
  • Gestión de la configuración : la atención se centra en mantener el rendimiento del producto de software, incluidos todos sus componentes, durante todo el ciclo de vida.
  • Gestión de requisitos : incluye la gestión de las revisiones y comentarios de los clientes que dan como resultado algunos cambios en el conjunto de requisitos. También consiste en la acomodación de aquellos requisitos modificados.
  • Gestión de subcontratos: se centra en la gestión eficaz de contratistas de software cualificados, es decir, gestiona las partes del software que son desarrolladas por terceros.
  • Garantía de calidad del software: garantiza un producto de software de buena calidad siguiendo ciertas reglas y pautas estándar de calidad durante el desarrollo.

Nivel 3: Definido – 

  • En este nivel, se lleva a cabo la documentación de las directrices y procedimientos estándar.
  • Es un conjunto integrado bien definido de procesos de gestión e ingeniería de software específicos del proyecto.
  • Revisiones por pares : en este método, los defectos se eliminan mediante el uso de una serie de métodos de revisión, como recorridos, inspecciones, verificaciones de amigos, etc.
  • Coordinación intergrupal: consiste en interacciones planificadas entre diferentes equipos de desarrollo para garantizar el cumplimiento eficiente y adecuado de las necesidades del cliente.
  • Definición de proceso de organización : su enfoque clave está en el desarrollo y mantenimiento de los procesos de desarrollo estándar.
  • Enfoque en el proceso de la organización : incluye actividades y prácticas que deben seguirse para mejorar las capacidades de proceso de una organización.
  • Programas de capacitación: se enfoca en la mejora del conocimiento y las habilidades de los miembros del equipo, incluidos los desarrolladores, y garantiza un aumento en la eficiencia del trabajo.

Nivel 4: Administrado – 

  • En esta etapa, se establecen metas de calidad cuantitativas para la organización para los productos de software, así como para los procesos de software.
  • Las mediciones realizadas ayudan a la organización a predecir la calidad del producto y del proceso dentro de unos límites definidos cuantitativamente.
  • Gestión de la Calidad del Software- Comprende el establecimiento de planes y estrategias para desarrollar el análisis cuantitativo y la comprensión de la calidad del producto.
  • Gestión cuantitativa : se enfoca en controlar el desempeño del proyecto de manera cuantitativa.

Nivel 5: Optimización – 

  • Este es el nivel más alto de madurez de procesos en CMM y se enfoca en la mejora continua de procesos en la organización utilizando retroalimentación cuantitativa.
  • El uso de nuevas herramientas, técnicas y la evaluación de procesos de software se realiza para evitar la recurrencia de defectos conocidos.
  • Gestión de cambios de procesos : se centra en la mejora continua de los procesos de software de la organización para mejorar la productividad, la calidad y el tiempo de ciclo del producto de software.
  • Gestión del Cambio Tecnológico- Consiste en la identificación y uso de nuevas tecnologías para mejorar la calidad del producto y disminuir el tiempo de desarrollo del producto.
  • Prevención de defectos : se centra en la identificación de las causas de los defectos y evita que se repitan en proyectos futuros mediante la mejora de los procesos definidos por el proyecto.

Publicación traducida automáticamente

Artículo escrito por 02DCE y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *