Diferentes niveles de pruebas

Una situación recurrente que se presenta, sobre todo en empresas con pocas o nulas prácticas de ejecución de pruebas, es que se realizan "diferentes" niveles de pruebas pero en todos los casos se repiten los mismos escenarios de pruebas.

No se hace un adecuado plan de pruebas para diferenciar entre los tipos y niveles de pruebas, de manera que sea efectivo en la detección e identificación de los defectos que corresponde a cada uno. Es importante diferenciar entre las pruebas estáticas y dinámicas, caja blanca y caja negra. Distinguir entre el objetivo de las pruebas unitarias, sistema o funcionales, pruebas integrales y de aceptación.

En las pruebas unitarias se hacen pruebas a nivel bajo a diferencia de las otras pruebas que deben revisar cuestiones a otro nivel. Es importante garantizar el resultado de las pruebas unitarias, no sólo es pasar la compilación sin errores, para no tener problemas de bajo nivel en otras pruebas.

Las prácticas en las áreas de proceso de VER y VAL ayudan a mejorar esos resultados.

Asignación de roles y funciones

La asignación de roles es un tema que siempre es un problema, sobre todo para organizaciones pequeñas. Uno de los roles que causa más conflicto es el de QA (Quality Assurance) porque normalmente no existe esa función o proceso en la organización y no es claro de donde sacarlo. 

CCB: Configuration Control Board o Change Control Board

En el modelo CMMI, en el área de proceso de Configuration Management (CM), se establece la existencia del CCB como parte de las prácticas y funciones para el control de los componentes de configuración. Este acrónimo que viene de Configuration Control Board o Change Control Board se refiere al Comité de control de la configuración o Comité de control de cambios.

Funciones y estructura del CCB El comité de control de cambios tiene la autoridad para aceptar o rechazar las propuestas de cambio a componentes de configuración. Como estos cambios tienen sentido controlarlos una vez que se crean las líneas base, el comité de control de cambios tiene la autoridad para gestionar las líneas base del producto y asegurar que los cambios son adecuadamente considerados y coordinados. De acuerdo con el tamaño de la organización, proyecto y complejidad del producto se pueden requerir diferentes niveles de control. En proyectos pequeños es una responsabilidad del líder o persona asignada en lugar de un grupo de personas. Pueden existir múltiples niveles de autoridad de acuerdo con la criticidad de los cambios, la naturaleza respecto al impacto en presupuesto y calendario o la etapa del ciclo de vida.

Composición del CCB La composición del comité varia dependiendo de los niveles de autoridad requeridos, siempre existe un representante de gestión de la configuración y los representantes de los involucrados al nivel que corresponda. El comité de control de cambios puede incluir como miembros al personal de:

• Desarrollo
• Aseguramiento de calidad
• Gestión de la configuración
• Pruebas y control de calidad
• Documentación
• Mantenimiento
• Liberación del producto
• Gerente de proyecto/programa
• Ingeniería de sistema o hardware
• Representantes del cliente
• Áreas administrativas: Comercial, financiero o ventas

Las actividades del comité de control de cambios están sujetas a revisiones de aseguramiento de calidad y auditorías a la configuración, para evaluar el cumplimiento de sus actividades.

Resumen de Verificación

El área de proceso de Verification (VER) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito asegurar que los productos de trabajo seleccionados cumplen sus requerimientos especificados. 
Las prácticas de VER permiten identificar defectos en etapas tempranas de la creación del producto y reducir los altos costos asociados a la identificación y corrección de defectos que se pueden presentar más adelante. En conjunto con VAL permite dar certeza al cliente o usuario que el producto cumple sus necesidades y que por otra parte puede ser utilizado. En su estructura de prácticas es muy similar a VAL pero con un enfoque diferente. 
Verificación
Las técnicas de VER son muy similares a las utilizadas por PPQA y se debe evitar duplicar esfuerzos al ejecutar esas actividades que tienen propósitos diferentes pero ocurren sobre los mismos productos de trabajo. Mientras que la primera encuentra defectos asociados al incumplimiento de los requerimientos, en la segunda se encuentran hallazgos o desviaciones al proceso que se debe utilizar. Lo ideal es que con una actividad se puedan cubrir ambos enfoques, muchas veces integrando el punto de vista de aseguramiento de calidad como parte de las actividades de verificación. 
En particular VER hace énfasis, en la meta específica 2, en el uso de la técnica de Peer Reviews o Revisiones entre pares. Esto obliga al uso de esta técnica adicionalmente a otras que pueden ser aplicables para cumplir la meta específica 3. Al definir la estrategia de verificación, como parte de las prácticas de la meta específica 1, se deben identificar los productos de trabajo a revisar y las técnicas de verificación que se utilizarán, ya sean Peer Reviews u otro tipo de revisiones, inspecciones, demostraciones y pruebas. 
Establecer la estrategia de verificación 
SG1 La preparación para la verificación es llevada a cabo.

• SP1.1 Seleccionar los productos de trabajo a verificar y los métodos de verificación que serán usados para cada uno.
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la verificación.
• SP1.3 Establecer y mantener los procedimientos y los criterios de verificación para los productos de trabajo seleccionados.

Ejecutar las revisiones entre pares

SG2 Las revisiones entre pares son realizadas sobre los productos de trabajo seleccionados

• SP2.1 Preparar las revisiones entre pares de los productos de trabajo seleccionados.
• SP2.2 Llevar a cabo las revisiones entre pares sobre los productos de trabajo seleccionados, e identificar los problemas resultantes de la revisión entre pares.
• SP2.3 Analizar los datos sobre la preparación, la realización y los resultados de las revisiones entre pares.

Ejecutar la verificaciones 
SG3 Los productos de trabajo seleccionados son verificados frente a sus requerimientos especificados.

• SP3.1 Realizar la verificación sobre los productos de trabajo seleccionados.
• SP2.2 Analizar los resultados de las actividades de verificación.

Resumen de Validación

El área de proceso de Validation (VAL) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito demostrar que un producto o componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno previsto. Las prácticas definidas en el área de proceso de VAL, en conjunto con VER, tienen elementos muy similares pero desde diferentes perspectivas. En su aplicación pueden coincidir utilizando las mismas técnicas, pero cuidando que se demuestren ambos enfoques. Mientras que en VER se busca demostrar que los productos de trabajo cumplen con los requerimientos que los definen en VAL se demuestra que el producto generado puede ser utilizado. Una diferencia entre VER y VAL está en que el primero puede ser aplicado a productos internos, no necesariamente dirigidos al cliente, mientras que el segundo está orientado a los productos que serán entregados y utilizados por el cliente o usuarios finales. Una pequeña diferencia que se aprecia al leer detenidamente el propósito y entender la diferencia entre productos de trabajo y componentes del producto, en el glosario del modelo. Lo cual no quiere decir que se aplique hasta el final del desarrollo, sino que por principio son prácticas que se aplican en todas las fases del desarrollo del producto utilizando las diferentes perspectivas que se van obteniendo del producto final. Otro elemento diferente en el momento de aplicar las validaciones es el entorno de operación. Las prácticas de validación deben aplicarse en un ambiente similar, o lo más cercano posible, al ambiente real de operación del producto, que permita ubicar al usuario en el contexto de uso y determinar cualquier problema que se pueda presentar. La creación de este ambiente de validación es un elemento fundamental en la preparación, sobre todo por la cuestión de presupuesto y tiempos para su preparación. La identificación, investigación, exploración y definición adecuada de los requerimientos en RD puede reducir las diferencias de perspectivas entre VER y VAL. Al final cuando los requerimientos implícitos, muchas veces relacionados con el uso y operación, son establecidos de manera explícita la diferencia entre VER y VAL son reducidas considerablemente.

La aplicación de VER y VAL se da en conjunto con otras áreas de proceso de ingeniería como RD y TS, pero son fundamentales para cumplir la meta específica 3 de PI que tiene que ver con la integración de los componentes y liberación del producto.

VAL requiere por una meta establecer la estrategia de validación y por la otra ejecutar las validaciones definidas en la estrategia y analizar los resultados. Estrategia de validación SG1 La preparación para la validación es llevada a cabo.

• SP1.1 Seleccionar los productos y los componentes de producto a validar y los métodos de validación que serán usados para cada uno.
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la validación.
• SP1.3 Establecer y mantener los procedimientos y los criterios de validación

Ejecutar las validaciones

SG2 El producto o los componentes de producto son validados para asegurar que sean adecuados para usar en su entorno operacional previsto.

• SP2.1 Realizar la validación sobre los productos y los componentes de producto seleccionados.
• SP2.2 Analizar los resultados de las actividades de validación.

Resumen de Integración del producto

El área de proceso de Product Integration (PI) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito ensamblar el producto a partir de sus componentes, asegurar que el producto, una vez integrado, funciona correctamente, y entregar el producto. 

Aunque PI maneja como propósito el ensamblado de componentes y comprobación del funcionamiento del producto ensamblado antes de la entrega, eso solamente hace referencia a la meta específica 3 del área de proceso. Para cubrir las otras dos metas específicas se requiere definir y establecer la infraestructura para la integración del producto y gestionar las interfaces durante todo el ciclo de desarrollo del producto para garantizar, en el momento de la integración, que no se presenten problemas. Por ello, aunque el resultado de PI es el producto integrado, para poder llegar hasta ahí es fundamental una efectiva gestión de las interfaces. 

Las interfaces se identifican como requerimientos en RD, se diseñan en TS y finalmente se gestionan para facilitar la integración en PI. 

Establecer la infraestructura para la integración 
SG1 La preparación para la integración del producto es llevada a cabo.

• SP1.1 Determinar la secuencia de integración del componente de producto
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la integración de los componentes del producto.
• SP1.3 Establecer y mantener los procedimientos y los criterios para integración de los componentes del producto

Gestionar las interfaces entre componentes

SG2 Las interfaces del componente de producto, tanto internas como externas, son compatibles.

• SP2.1 Revisar las descripciones de la interfaz en cuanto a cobertura y completitud.
• SP2.2 Gestionar las definiciones, diseños y cambios de las interfaces internas y externas para los productos y los componentes de producto.

Ensamblar los componentes para liberar el producto

SG3 Los componentes de producto verificados son ensamblados, y el producto integrado es verificado y validado antes de ser entregado.

• SP3.1 Confirmar, antes de ensamblar, que cada componente de producto requerido para ensamblar el producto ha sido identificado correctamente, funciona de acuerdo con su descripción y que las interfaces de componente de producto cumplen con las descripciones de la interfaz.
• SP3.2 Ensamblar los componentes de producto de acuerdo a la secuencia de integración de producto y a los procedimientos disponibles.
• SP3.3 Evaluar los componentes de producto ensamblados para la compatibilidad de la interfaz.
• SP3.4 Empaquetar el producto o componente de producto ensamblado y entregar al cliente apropiado.

Resumen de Solución técnica

El área de proceso de Technical Solution (TS) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito diseñar, desarrollar e implementar soluciones para los requerimientos. Las soluciones, los diseños y las implementaciones engloban productos, componentes de producto y procesos del ciclo de vida asociados al producto, de manera individual o en combinación, según sea apropiado. TS es el centro del desarrollo y mantenimiento del producto, depende de los requerimientos definidos en RD para generar el producto y que se mantienen actualizados a través de REQM. Como parte de las prácticas definidas se desarrolla, de manera iterativa, las diferentes soluciones a los requerimientos del cliente, productos y componentes del producto. Esas soluciones son diseñadas y finalmente construidas para crear el producto o servicio y los procesos asociados durante todo el ciclo de vida. Las metas definidas en TS interactúan en diferentes etapas del desarrollo y en diferentes instancias del producto y sus componentes. El establecimiento de soluciones, el desarrollo del diseño y la implementación del diseño se ejecutan de manera iterativa de acuerdo con las necesidades del desarrollo. Establecer soluciones SG1 Las soluciones de producto o de componentes de producto son seleccionadas a partir de soluciones alternativas.

• SP1.1 Desarrollar las soluciones alternativas y los criterios de selección.
• SP1.2 Seleccionar las soluciones de componentes de producto que mejor satisfacen los criterios establecidos.

Desarrollar el diseño a las soluciones

SG2 Los diseños de producto o de los componentes de producto son desarrollados.

• SP2.1 Desarrollar un diseño para el producto o el componente de producto.
• SP2.2 Establecer y mantener un paquete de datos técnicos.
• SP2.3 Diseñar las interfaces de componentes de producto usando los criterios establecidos.
• SP2.4 Evaluar si los componentes de producto se deberían desarrollar, comprar o reutilizar en base a los criterios establecidos.

Implementar el diseño

SG3 Los componentes de producto y la documentación de soporte asociada son implementadas a partir de sus diseños.

• SP3.1 Implementar los diseños de los componentes de producto.
• SP3.2 Desarrollar y mantener la documentación de uso final

Resumen de Desarrollo de requerimientos

El área de proceso de Requirements Development (RD) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito producir y analizar los requerimientos del cliente, del producto y de los componentes del producto. Las prácticas definidas en esta área de proceso permiten determinar todos los requerimientos del proyecto, ya sea para el desarrollo o mantenimiento. Parte de los requerimientos del cliente que son derivados en requerimientos del producto hasta refinarlos al nivel de requerimientos de los componentes del producto, todo esto durante el ciclo de vida del producto. El proceso de obtención y refinamiento de los requerimientos va estrechamente vinculado con el diseño del producto por lo que estas prácticas están relacionadas, de manera recursiva, con las establecidas en el área de proceso de Technical Solution (TS). Los cambios que se requieran a los requerimientos establecidos en RD son gestionados por REQM, por lo que RD, TS y REQM están estrechamente relacionados y operan de manera concurrente. La razón por la que REQM está en un nivel de madurez inferior a RD puede estar relacionado con el principio que establece que primero hay que establecer un control y orden en las actividades que se realizan, esto se logra con REQM, para después especializar la forma en que se realizan las actividades, en este caso las prácticas de RD. RD establece en las primeras metas específicas la definición de los requerimientos del cliente y los requerimientos del producto y componentes. Con la meta tres complementa las dos anteriores para garantizar que todos los requerimientos obtenidos son adecuadamente analizados y validados durante las diferentes etapas del desarrollo del producto. Definir los requerimientos del cliente

SG1 Las necesidades, expectativas, restricciones e interfaces de los interesados son recogidas y traducidas a requerimientos de cliente.

• SP1.1 Obtener las necesidades, las expectativas, las restricciones, y las interfaces de los interesados para todas las fases del ciclo de vida del producto.
• SP1.2 Transformar las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas en requerimientos del cliente.

Derivar los requerimientos del producto y componentes del producto

SG2 Los requerimientos del cliente son refinados y elaborados para desarrollar los requerimientos del producto y de componentes del producto.

• SP2.1 Establecer y mantener los requerimientos del producto y de componentes del producto, los cuáles están basados en los requerimientos del cliente.
• SP2.2 Asignar los requerimientos para cada componente del producto.
• SP2.3 Identificar los requerimientos de la interfaz.

Analizar y validar los requerimientos definidos

SG3 Los requerimientos son analizados y validados, y una definición de la funcionalidad requerida es desarrollada.

• SP3.1 Establecer y mantener los conceptos operativos y los escenarios asociados.
• SP3.2 Establecer y mantener una definición de la funcionalidad requerida.
• SP3.3 Analizar los requerimientos para asegurarse de que son necesarios y suficientes.
• SP3.4 Analizar los requerimientos para equilibrar las necesidades y las restricciones de los interesados.
• SP3.5 Validar los requerimientos para asegurar que el producto resultante se ejecutará según lo previsto en el entorno del usuario.

Resumen de Gestión de acuerdos con proveedores

El área de proceso de Supplier Agreement Management (SAM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito gestionar la adquisición de productos, y servicios, del proveedor. SAM puede ser considerada como no aplicable para efectos de una organización, en el sentido que las prácticas de adquisición que establece no tienen sentido en el contexto del negocio o no representan un riesgo para el proyecto. En principio cubre la adquisición de productos o servicios que serán entregados al cliente o que se requieren para su desarrollo o mantenimiento. No considera, directamente, la adquisición de proveedores que forman parte de los equipos de desarrollo y que siguen los mismos procesos y mecanismos de reporte que el resto de la organización. Las prácticas del área de proceso van orientadas a la selección y establecimiento de acuerdos con proveedores y por otra parte a revisar el cumplimiento de los acuerdos tanto por el proveedor como por la organización. Establecer acuerdos con proveedores

SG1 Se establecen y mantienen los acuerdos con los proveedores.

• SP1.1 Determinar el tipo de compra para cada producto o componente del producto o requerirse.
• SP1.2 Seleccionar los proveedores en base a una evaluación de su capacidad para cumplir los requerimientos especificados y los criterios establecidos.
• SP1.3 Establecer y mantener los acuerdos formales con el proveedor.

Cumplir los acuerdos establecidos

SG2 Los acuerdos con los proveedores deben satisfacerse tanto por el proyecto como por el proveedor.

• SP2.1 Desarrollar las actividades tal y como se especifican en el acuerdo suscrito con el proveedor.
• SP2.2 Seleccionar, monitorizar y analizar los procesos del proveedor que son aplicables en la colaboración establecida.
• SP2.3 Seleccionar y evaluar los productos hechos a medida por el proveedor.
• SP2.4 Asegurar que el acuerdo establecido con el proveedor se cumple antes de aceptar el producto adquirido.
• SP2.5 Transferir los productos adquiridos del proveedor al proyecto.

Resumen de Gestión de riesgos

El área de proceso de Risk Management (RSKM) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito identificar los problemas potenciales antes de que ocurran para que las actividades de gestión de riesgos puedan ser planificadas y utilizadas según sea necesario a lo largo de la vida del producto o del proyecto para mitigar los impactos adversos para alcanzar los objetivos. RSKM es fundamental en las actividades de gestión de proyectos durante toda su ejecución. Amplia las prácticas iniciales definidas en PP y PMC al establecer principios que permiten planificar, anticipar y mitigar de manera sistemática y proactiva los riesgos que se puedan presentar en un proyecto u organización. El mayor riesgo para un proyecto sería considerar que no existen riesgos, porque existe una alta probabilidad de que existan y, muchas veces, con impactos fuertes para el proyecto. Las actividades de mitigación incluyen tanto las actividades para controlar la ocurrencia del riesgo como para minimizar el efecto en caso de que se presente, frecuentemente identificado como planes de contingencia. Establecer la estrategia para gestionar los riesgos

SG1 La preparación de la gestión de los riesgos es llevada a cabo

• SP1.1 Determinar las fuentes y las categorías de los riesgos.
• SP1.2 Definir los parámetros usados para analizar y categorizar los riesgos, y los parámetros usados para controlar el esfuerzo de la gestión de riesgos.
• SP1.3 Establecer y mantener la estrategia que se usará para la gestión de riesgos.

Identificar y analizar los posibles riesgos

SG2 Los riesgos son identificados y analizados para determinar su importancia relativa.

• SP2.1 Identificar y documentar los riesgos
• SP2.2 Evaluar y categorizar cada riesgo identificado usando las categorías y los parámetros definidos de riesgo, y determinar su prioridad relativa.

Controlar los riesgos

SG3 Los riesgos son tratados y mitigados, donde sea apropiado, para reducir los impactos adversos para alcanzar los objetivos.

• SP3.1 Desarrollar un plan de mitigación de riesgos para los riesgos más importantes del proyecto según fue definido en la estrategia de gestión de riesgos.
• SP3.2 Monitorizar el estado de cada riesgo periódicamente e implementar el plan de mitigación de riesgos según sea apropiado.

Gestión de la configuración o configuration management

Gestión de la configuración o configuration management

Resumen de Gestión de requerimientos

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito gestionar los requerimientos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requerimientos y los planes y productos de trabajo del proyecto. Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Básicamente aquí se garantiza que los requerimientos son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los requerimientos hacia las diferentes entidades del producto y a la inversa. Cuando se presentan cambios a requerimientos, y es algo que sucederá en la gran mayoría de las ocasiones, pueden presentarse inconsistencias particularmente por problemas de comunicación dentro del equipo que desconoce los cambios que han sido aprobados. REQM debe identificar esas situaciones y tomar acciones correctivas para garantizar su solución. Gestionar los requerimientos SG1 Los requerimientos son gestionados y las inconsistencias con los planes y productos de trabajo del proyecto son identificadas.

• SP1.1 Desarrollar una comprensión del significado de los requerimientos con los proveedores de los requerimientos.
• SP1.2 Obtener el compromiso de los participantes de proyecto sobre los requerimientos.
• SP1.3 Gestionar los cambios a los requerimientos a medida que evolucionan durante el proyecto
• SP1.4 Mantener la trazabilidad bidireccional entre los requerimientos y los productos de trabajo
• SP1.5 Identificar las inconsistencias entre los planes del proyecto, los productos de trabajo y los requerimientos.

Resumen de Gestión cuantitativa del proyecto

El área de proceso de Quantitative Project Management (QPM) corresponde al nivel 4 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito gestionar cuantitativamente el proceso definido del proyecto para alcanzar los objetivos establecidos de calidad y de rendimiento del proceso del proyecto.

Resumen de Aseguramiento de la calidad del proceso y producto

El área de proceso de Process and Product Quality Assurance (PPQA) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Soporte para la representación continua. 
Tiene como propósito proporcionar al personal y a la gerencia una visión objetiva de los procesos y de los productos de trabajo asociados. La función de aseguramiento de calidad es vital para lograr el cumplimiento de las prácticas y el establecimiento de la cultura de procesos en la organización. 
Es importante lograr la objetividad en la revisión, particularmente en el uso de un criterio definido y garantizando, eventualmente, la independencia de las actividades que son revisadas. Las actividades de aseguramiento de calidad deben ser adecuadamente planificadas y realizadas de forma sistemática. Las metas del área de proceso garantizan que las desviaciones, o no conformidades, sean identificadas y comunicadas adecuadamente para garantizar su corrección y ajuste a los procesos planificados. 

Actualización sobre cambios en la versión 1.3 de CMMI

Recientemente el SEI publicó internamente la versión draft de lo que será el CMMI v1.3. Revisando la documentación, además de los cambios que ya se habían anunciado, hay algunas modificaciones que destacan en una primera ojeada.