Requisitos del cliente, producto, componentes del producto e interfaz

En el modelo CMMI las prácticas de RD consideran básicamente tres niveles de requisitos, del cliente, producto y componentes del producto. Adicionalmente a estos se menciona la identificación de requisitos de interfaz, igualmente importantes. 
Los diferentes niveles de requisitos cubren, durante todo el desarrollo del producto, las diferentes etapas de refinamiento de las necesidades iniciales del cliente que son diseñadas en la solución a nivel de requisitos del producto y a un nivel más bajo de instanciación como requisitos de componentes del producto. Estos niveles de requisitos se van obteniendo a través de diferentes iteraciones y refinamientos donde se detallan, derivan y asignan las dependencias de requisitos de alto nivel hacia los requisitos obtenidos a niveles más bajos. 

Requerimientos vs. requisitos

En diversas situaciones se hace uso indistinto de los términos requerimientos y requisitos. En CMMI se usa en diversas prácticas el término "requirement", pero ¿cúal sería el término correcto a emplear?.
En término generales el requerimiento se refiere a la petición que se hace de algo, se requiere o solicita. Esto estaría más relacionado en inglés con la palabra "request". El requisito es la condición que debe cumplir algo, en general el requisito cumple con lo que se requiere o el requerimiento (la solicitud). La traducción del término "requirement" está asociado con la necesidad por lo que sería más adecuado traducirlo como requisito.
En general se acostumbra usar ambos términos de manera indistinta pero entendiendo un poco el significado y desligándolo del uso de un anglisismo, tendría más sentido en español el uso de requisito para referirse a las prácticas descritas principalmente en RD y REQM. Mientras que el requerimiento quedaría básicamente como la petición que se hace de algo.
Incluso en wikipedia hay dos entradas diferentes para este concepto, existe requerimientos e ingeniería de requisitos. En México se usa más el término requerimientos mientras que en otros países de habla hispana se utiliza más requisitos.

Evaluación de la efectividad de la formación

Un lector, en un artículo anterior, plantea como comentario: "... actualmente hemos iniciado recién a implementar el CMMI para Servicios Nivel 3, dado que estamos iniciando, hemos tenido un poco de dudas respecto a como evaluar la efectividad de los entrenamientos. Me gustaría saber si me pueden apoyar con algún método o procedimiento para realizar esta actividad."
La duda se refiere a la práctica específica 2.3 de OT que plantea la necesidad de evaluar la eficacia del programa de formación en la organización. El propósito principal de esta práctica es realizar una evaluación del plan de formación y determinar acciones y lecciones aprendidas al respecto que permitan mantener una formación efectiva para cubrir las necesidades que se identificaron.

Análisis de causas

El análisis de causas de problemas es una herramienta utilizada en la mejora de procesos. En el modelo CMMI se considera como una práctica altamente efectiva para identificar e implantar iniciativas de mejora en los procesos. Se puede encontrar a diferentes niveles desde subprácticas en IPM, prácticas en QPM y área de proceso en CAR, lo que implica que la práctica va madurando en la medida que se tiene mayor conocimiento del proceso.

Como parte de las actividades de gestión de proyectos se identifican problemas sobre los cuales se requiere buscar una solución. Una herramienta efectiva que ayuda a identificar las causas de los problemas es el diagrama causa-efecto. Las acciones resultantes pueden aplicarse en el proyecto con el fin de eliminar los problemas o evitar que se puedan presentar nuevamente en el futuro. 

InformIT: Introduction to CMMI for Development: Guidelines for Process Integration and Product Improvement, 3rd Edition About Process Improvement

InformIT: Introduction to CMMI for Development: Guidelines for Process Integration and Product Improvement, 3rd Edition About Process Improvement

Herramientas de apoyo a los procesos

Las prácticas establecidas en el modelo CMMI no están asociadas a herramientas en particular, sin embargo es bueno apoyarse en ciertas herramientas para facilitar el proceso. Como parte de los ejemplos en la práctica genérica 2.3 se sugieren las herramientas que pueden apoyar las prácticas requeridas. Aunque es importante tener bien definido el proceso antes de pensar en automatizarlo, esto sólo es efectivo cuando se aplica a una operación eficiente, cuando se tiene una operación ineficiente la tecnología solo ampliará la ineficiencia de manera automatizada. 
Las prácticas en el modelo se pueden clasificar, en términos generales, como actividades de planificación, ejecución o de control.

Estrategia para gestión de riesgos

El área de gestión de riesgos RSKM requiere en su primera meta específica el establecimiento de la estrategia que sirve como base para la ejecución de la disciplina en el proyecto u organización. La estrategia define la forma en que se identifican, analizan y mitigan los riesgos a partir de las fuentes de riesgo, categorías y parámetros establecidos, los métodos, técnicas y herramientas definidos y las métricas y periodicidad para evaluar el estado de los riesgos. 


Una adecuada gestión de riesgos permite incrementar la probabilidad de éxito de un proyecto y reduce los resultados negativos de los riesgos que no pueden ser evitados o al menos llevar su efecto a límites aceptables. En un artículo publicado por Karl E. Wiegers en Software Development Magazine, 1998 “Know your enemy: Software Risk Management” plantea elementos de interés que se pueden considerar como parte de la estrategia de gestión de riesgos. 

El nivel de madurez para el Cliente

Recientemente se presentó el webinar “Why I don’t care that you had a CMMI level 5 rating!” por Todd Schrubb a través de CAI University. En el mismo se abordó el tema del uso del resultado de una evaluación por un cliente que contrata una organización con un determinado nivel de madurez y las interpretaciones y usos adecuados que debe realizarse del proceso de evaluación SCAMPI. 
En principio se establece que una evaluación es derivada del análisis y resultados de proyectos pasados y que no representa un indicador del desempeño futuro, aunque la infraestructura de procesos creada permite mantener resultados similares posteriormente. El modelo CMMI se creó para establecer resultados exitosos y repetibles en la organización orientados a los proyectos a futuro, a partir de las experiencias y rendimiento actual. Pero no debe tomarse el nivel de madurez, o capacidad, obtenido como una certeza, sino considerar lo que se está haciendo actualmente para mejorar esos resultados. 

CMMI v2, cinco puntos para entender la nueva versión del modelo

El mes de marzo del 2018 fue el lanzamiento de la versión 2.0 del modelo CMMI (Capability Maturity Model for Integration) por el CMMI Ins...