Verificación y validación

Las área de proceso de Verification (VER) y Validation (VAL) son muy similares pero con enfoques diferentes. Mientras que VER revisa que los productos y productos de trabajo del proceso cumplen con los requerimientos mientras que VAL revisa que los productos y componentes del producto que recibe el usuario pueden ser usados por este último. En Requirements Development (RD, SP3.3) el análisis de los requerimientos se realiza utilizando técnicas de verificación mientras que RD, SP3.5 obliga a la validación de los requerimientos para garantizar que el producto puede ser utilizado. Por otra parte Process and Product Quality Assurance (PPQA) puede verse como una especie de verificación y debe cuidarse que no se traslapen. PPQA debe revisar que se cumpla el proceso y sus prácticas permiten identificar inconsistencias en el proceso, mientras que VER identifica defectos en los productos y productos de trabajo. En el caso de VER se requiere realizar peer reviews(SG2) independiente de otros tipos de verificaciones que se puedan considerar. PPQA, SP1.2 que indica la evaluación objetiva de productos de trabajo se puede cubrir en cierta forma con peer reviews si en este caso se considera como elemento de revisión el cumplimiento del proceso. Son funciones que se pueden hacer en conjunto pero cuidando ambos enfoques. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Auditorías

Una auditoría en el modelo CMMI es una revisión objetiva de un producto de trabajo o conjunto de productos de trabajo contra un criterio establecido. Únicamente se menciona directamente en Configuration Management (CM, SP 3.2) en la realización de las auditorías a la configuración, en este caso orientadas a revisar que funcionalmente y físicamente la integridad del producto puede ser garantizada. A diferencia de la función de aseguramiento de calidad que se menciona en Process and Product Quality Assurance (PPQA) donde se menciona la ejecución de las auditorías como una forma de evaluación objetiva para aseguramiento de calidad donde lo importante es la objetividad más que la independencia de la función de auditoría. Otras áreas de proceso donde se menciona la ejecución de auditorías es en:

• Organizational Process Focus (OPF) como auditorías de cumplimiento del proceso para monitorear la implementación de los procesos
• Supplier Agreement Management (SAM) como auditorías a la configuración a los productos proporcionados por el proveedor
• Verification (VER) como ejemplo de método para realizar la verificación

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Toma de decisiones

El área de proceso de Decision Analysis and Resolution (DAR) establece la necesidad de utilizar un proceso formal de evaluación típicamente en casos de evaluación de riesgos, cambios a componentes de configuración, decisiones que provocan retrasos en tiempo, decisiones que afectan los objetivos del proyecto o cuando existan compromisos legales. Es importante establecer las situaciones o casos en los que se requiere el uso del proceso para la toma de decisiones en los proyectos y en la Organización. Independientemente de estas situaciones el proceso es referenciado por otras áreas de proceso para en el caso de:

• Organizational Innovation and Deployment (OID) - evaluación de propuesta de mejora e innovación
• Organizational Process Definition (OPD+IPPD, SP2.1) - toma de decisiones asociadas a cuestiones de equipos integrados
• Organizational Training (OT) - determinación de enfoque para capacitación
• OT,SP1.4 - desarrollo de materiales de capacitación
• Product Integration (PI, SP1.1) - selección de secuencia de integración, decisión de desarrollar o comprar ambientes de integración
• Risk Management (RSKM) – evaluar alternativas de selección y mitigación de riesgos identificados
• Supplier Agreement Management (SAM, SP1.2) - selección de proveedores y selección de alternativas de solución,
• Technical Solution (TS, SP1.1) - definición de criterios de selección
• TS, SP2.3 - identificar alternativas para interfaces
• TS, SP2.4 - decisión de comprar o desarrollar la solución

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Interfaces

Una interfaz es la frontera por la cual se comunican dos sistemas. Puede ser un conector utilizado para conectar otro dispositivo o puede ser un acuerdo utilizado para permitir la comunicación entre dos aplicaciones. Frecuentemente existe un componente intermedio entre los sistemas que permite conectar sus interfaces. En el modelo CMMI el área de proceso de Product Integration (PI) se encarga de administrar las interfaces del producto durante el proyecto. En particular la meta específica SG2 se encarga de Asegurar la compatibilidad de interfaz y SG3 permite Confirmar que el producto cumple con las interfaces establecidas, que puede ser ensamblado y que funciona adecuadamente. Las interfaces deben considerar tanto las interfaces de los componentes del producto como las interfaces con los diferentes ambientes que se requieren para verificación, validación, operación y soporte. En el área de proceso de Requeriments Development (RD, SP2.3) se establecen los requerimientos de interfaz, que serán diseñadas como interfaz para la solución a los requerimientos como parte de Technical Solution (TS, SP2.3). Las prácticas de Verification (VER) permite revisar la interfaz de los productos o componentes. Otras área de proceso que consideran el manejo de elementos relacionados con la interfaz son:

• Configuration Management (CM) Descripción de la interfaz
• Integrated Project Management (IPM) Interfaz entre grupos y riesgos de interfaz entre grupos
• Organizational Innovation and Deployment (OID) Estándares de interfaz
• Organizational Process Definition (OPD) Definición de interfaz del proceso
• Risk Management (RSKM) Administración de riesgos de interfaz
• Project Planning (PP) Complejidad de la interfaz para la estimación y compromisos de interfaz
• Requirements Management (REQM) Rastreabilidad de requerimientos de interfaz
• Supplier Agreement Management (SAM) Interfaz con proveedores
• VER y Validation (VAL) Ambientes de verificación y validación

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Requerimientos

Los requerimientos, según el glosario de CMMI, es la condición o capacidad necesaria por un usuario para resolver un problema o alcanzar un objetivo. También se define como la condición o capacidad que se debe cumplir o cubrir por un producto o componente para satisfacer un contrato, estándar, especificación, u otro documento formal. Es la representación documentada de la condición o capacidad para cubrir los puntos anteriores. Deben considerar que todos los proyectos tienen requerimientos, sino no tendrían sentido de existir. El área de proceso de Requirements Management (REQM) administra los requerimientos del proyecto, tanto técnicos como no técnicos (aquí podemos considerar costo y calendario). Las prácticas definidas aquí no están orientadas a desarrollar los requerimientos, más bien garantizan que todos en el proyecto trabajen con requerimientos autorizados. Por su parte Requirements Development (RD) genera los requerimientos del cliente, producto y componentes y Technical Solution (TS) implementa las soluciones a los requerimientos. Para lograr controlar la interrelación entre todos es imprescindible contar con una matriz de rastreabilidad, la que es un elemento crítico para RD y TS y que es mantenida con las prácticas de REQM. Necesitamos la matriz para cubrir con:

• REQM SP 1.1 Acordar que los requerimientos son de una fuente adecuada y que son los acordados
• RD SP3.3 Analizar los requerimientos para determinar si son necesarios y suficientes. Esta práctica contribuye a REQM SP1.1
• REQM SP1.4 Mantener la rastreabilidad bidireccional de los requerimientos y productos de trabajo. Esto contribuye a determinar si satisface los requerimientos a nivel superior RD SP3.3

La rastreabilidad bidireccional, requerida por REQM SP1.4, es la capacidad de rastrear los requerimientos hacia los productos finales y en sentido inverso. La idea es poder determinar que todos los requerimientos han sido cubiertos y que los productos corresponden a un requerimiento válido. Esto se conoce como rastreabilidad vertical y es suficiente para cubrir la rastreabilidad direccional. Existe otra traceabilidad horizontal que se da entre componentes o grupos de trabajo con el propósito de evitar conflictos potenciales entre las interfaces y que es fundamental para cubrir las prácticas de Product Integration (PI), en particular las prácticas específicas relacionadas con SG2. Las interfaces, internas y externas, de los componentes del producto son compatibles. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Referencias entre áreas de proceso

En el modelo como parte del material informativo se realizan referencias entre áreas de proceso (PA) de manera que un área de proceso complementa sus prácticas con información establecida por otras áreas de proceso. Las PA más referenciadas por otras son Project Planning(PP), Project Monitoring Control(PMC) y Measurement and Analysis (MA), le siguen Risk Management (RSKM) y Verification (VER) y finalmente Organizational Process Definition(OPD) y Requirements Development (RD). Las que menos se referencian son Causal Analysis and Resolution(CAR) y Process and Product Quality Assurance (PPQA), seguida por Organizational Process Performance (OPP). Si consideramos únicamente las referencias en las notas introductorias, la lista cambia. La más referenciada es PP, le sigue RD y finalmente PMC. La que menos se referencia es PPQA que no es referenciada por ninguna otra PA. Las PA que más referencias utilizan son Integrated Project Management (IPM), Product Integration (PI), Quantitative Project Management (QPM) y Supplier Agreement Management (SAM), le siguen Organizational Innovation and Deployment (OID), RD y Technical Solution (TS) y luego MA, PP. Las que menos referencias hacen son Configuration Management (CM) y PPQA. Considerando únicamente las referencias en las notas introductorias, la que más referencias utiliza es PI, le siguen MA, OID, QPM y RD y luego REQM. Las que menos referencias hacen son OPD y Organizational Process Focus (OPF). ¿PPQA es un área muy independiente?¿PP requiere de todos y utiliza a todos? Necesitamos revisar las notas a nivel de prácticas para tener una visión completa de las interrelaciones entre áreas, no sólo podemos quedarnos con las referencias en notas introductorias. En el caso de las practicas genéricas se hace referencia principalmente a PP, PMC e IPM. Las que menos se referencian son las PA de la categoría de ingeniería, además de RSKM, Decision Analysis and Resolution (DAR) y SAM. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Números en CMMI

Capability Maturity Model Integration (CMMI) es un modelo de madurez para la mejora de procesos en el desarrollo de productos y servicios. Consiste de mejores prácticas orientadas a actividades de desarrollo y mantenimiento de software que cubren el ciclo de vida desde la concepción, liberación hasta el mantenimiento. De esta manera inicia el documento que contiene la información del modelo donde en 560 páginas, se revisan 22 áreas de proceso, conteniendo 50 metas específicas con 173 prácticas específicas y 5 metas genéricas con 17 prácticas genéricas, que asociadas a las 22 áreas de procesos, se convierten en 110 metas genéricas con 374 prácticas genéricas a considerar. En resumen la aplicación del modelo requiere cubrir 160 metas a través de la implantación de 547 prácticas que suman 707. Considerando la persistencia del 7 en todos estos números y considerando que su significado esta asociado al éxito, la verdad y la justicia no es de extrañar por qué las empresas que lo adoptan empiezan a obtener el éxito en el logro de sus objetivos, visualizando beneficios verdaderos. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor