Inconsistencia con los requisitos, una práctica poco valorada o entendida

Zeedonk by sannse

La gestión de requisitos considera diferentes tareas desde el acuerdo sobre lo que se va a hacer, el control de las modificaciones a lo que se acordó y la revisión de que se está haciendo lo correcto. Cuando las dos primeras se realizan correctamente se podría pensar que la última está de más, pero sería como pensar que porque el proyecto va bien no existen riesgos.

El modelo CMMI establece en el área de proceso de REQM las prácticas necesarias para la gestión de los requisitos. Su propósito es gestionar los requisitos de productos y componentes y asegurar que se mantienen alineados con los planes y productos de trabajo. La segunda parte de ese propósito es el foco principal de este artículo.

Categorias de requisitos no funcionales

Mientras que los requisitos funcionales describen lo que debe hacer un producto, los requisitos no funcionales son propiedades o cualidades que el producto debe tener. Estos últimos pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptación.

El modelo CMMI no considera expresamente una diferencia entre requisitos funcionales y no funcionales. Éstos se identifican básicamente en las prácticas de RD mezclados o derivados entre los requisitos del cliente, productos y componentes y asociados con los atributos de calidad del producto. En el proceso de definición de los requisitos se tienen prácticas que ayudan a identificar no solamente lo que se espera del producto sino también las expectativas de comportamiento o cualidades que se esperan.

Atributos y medidas de calidad del software

Una atributo es una propiedad del producto, que cuando es asociada con la calidad se relaciona con los elementos que considera el cliente para aceptar o rechazar el producto. Estos atributos de calidad deben ser medidos para poder ser comparados. 

Es importante entenderlos desde la concepción de la idea a partir de las necesidades del cliente o mercado, considerarlos como parte de la solución y creación del producto para finalmente demostrar que han sido adecuadamente integrados en el producto final. Aquí se presentan diferentes atributos y medidas considerados en los entornos de desarrollo, instalación y operación que pueden ser útiles identificar en cada caso.

Herramientas de apoyo a requisitos

El modelo CMMI no establece como condición el uso de herramientas específicas para la implementación de las prácticas en las áreas de proceso. Aunque la herramienta no hace el proceso, es útil apoyarse en ellas para facilitar las tareas que se requieren. En particular las áreas de proceso de REQM y RD se benefician mucho si el proceso se refuerza con alguna herramienta.
IRQA es una herramienta desarrollada por Visure que permite identificar, analizar y gestionar los requisitos. Una solución completa e integral para el proceso de definición y gestión de requisitos.

Biblioteca de procesos en CMMI

El área de procesos de OPD establece la necesidad de establecer una biblioteca de activos de procesos (PAL por sus siglas en inglés) como base para el establecimiento del proceso definido y gestionar el conocimiento de la organización. Constituye un repositorio de información que permite almacenar y publicar activos del proceso útiles para los que tienen que definir, implementar o gestionar los procesos en la Organización.  

Resumen de Solución técnica en CMMI DEV v1.3

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.


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. 


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 con base en los criterios de selección.

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

Elementos a considerar en los Peer reviews

Peer reviews o revisiones entre colegas es una técnica de revisión estructurada, que puede utilizar diferentes enfoques, donde participan los “colegas” del autor de los productos de trabajo para identificar defectos y cambios que se requieren. 
Son una parte fundamental de las verificaciones, una meta específica en el área de proceso VER “obliga” a ejecutar peer reviews además de otras técnicas que se puedan considerar, por constituir un mecanismo efectivo en la eliminación de defectos. Permite desarrollar un mayor entendimiento del proceso y de los productos de trabajo que puede ayudar a prevenir los defectos e identificar mejoras al proceso.

Sobre el tipo y contenido de las líneas base

En días recientes publiqué un artículo sobre las líneas base para el control de la configuración. Un colega me hizo llegar la siguiente pregunta, que reproduzco completamente.


"Acerca de las líneas base, comentas que formalmente se establecen cuatro, si bien esas líneas base están a su vez relacionadas entre sí, es decir, existe una correspondencia entre líneas base funcionales, de definición, de desarrollo y de producto. En proyectos de desarrollo que siguen metodologías clásicas es más o menos habitual recibir las peticiones de cambio al final de los desarrollos, durante la fase de pruebas del producto, lo que afectaría a todas las líneas base, teniendo, por ejemplo que la línea base 1 Funcional corresponde con la línea base 3 de desarrollo, y tras la petición de cambio la línea base 2 Funcional corresponde con la línea base 4 de desarrollo, una relación entre las diferentes líneas base. 


Comentas que cada organización o proyecto determina el contenido y tipo de líneas base. ¿Sería válido establecer líneas base globales del proyecto definidas como un conjunto completo de entregables del proyecto, y que las líneas base cambien siempre debido a una petición de cambio (bien interna o bien del cliente) y que se lleve por control de configuración las versiones de los diferentes productos (Plan de Proyecto, Planificación, Análisis Funcional, Matrices de trazabilidad, software, manuales,....) que incluye cada línea base? "


Líneas base y control de configuración
Sobre este punto es conveniente puntualizar algunas cuestiones en principio para poder aclarar el planteamiento. Cuando menciono que son “líneas bases formales” es porque en cualquier literatura sobre el tema es muy común encontrar la referencia a ellas, pero no implica que el modelo o la práctica obligue a cubrir el número y contenido de las líneas base que se plantearon. 


Por otra parte se pueden implementar diferentes niveles de control según las necesidades del proyecto u organización. En ciertos componentes es necesario un control y gestión de la configuración que cumpla con todos los elementos definidos por CM, que sería un nivel alto de control, y por otro lado podemos tener componentes donde es suficiente conocer su ubicación y la última versión aprobada con un nivel más bajo de control asociado con documentos y productos del proceso (Planes, registros, acuerdos, matrices y demás). Esto se puede encontrar explicado en las notas que acompañan a la práctica genérica 2.6 en el modelo CMMI, al inicio de la parte II. 


Definición de las líneas base
El sentido de definir una línea base es más con el objetivo de permitir la comunicación adecuada entre los grupos que participan en un proyecto, de manera que si esa línea base se modifica sea fácil identificar la afectación que pueden tener los grupos que están haciendo uso de ellas. 


Por poner un ejemplo, cuando un arquitecto realiza los planos de una construcción y son aprobados, el maestro albañil toma esos planos para comenzar el trabajo. Durante la obra considera adecuado que se requiere modificar una pared para crear un ventanal, primero debe revisar con el arquitecto la cuestión estructural para decidir el impacto que puede tener en la construcción y la afectación que puede tener con instalaciones eléctricas, hidráulicas o de seguridad que él no visualiza al querer dejar el espacio para la ventana. En este caso los resultados se deben reflejar nuevamente en los planos y permitir que todos estén informados de esas adecuaciones. En este caso el plano y los documentos asociados es una línea base, y quizás la siguiente pueda ser la obra ya terminada.


Las líneas base deben funcionar en el mismo sentido y tener sentido para el proyecto y los grupos que participan. Si tengo un ciclo de cascada y un solo equipo de trabajo que contribuye a la solución, posiblemente la línea base de producto sea suficiente para garantizar mantenimientos posteriores. Pero si en ese mismo ciclo de vida tengo grupos independientes, tal vez el escenario cambia y necesite definir líneas base que permitan entregar los elementos que el otro grupo requiere. Por así decirlo, la documentación de análisis para el diseño, los resultados del diseño para el desarrollo y los productos del desarrollo para probar y liberar el producto, marcarían las líneas base que se necesitan. 


Las líneas base tienen sentido para el proyecto y el desarrollo del producto
La decisión de las líneas base y contenido se pueden establecer al inicio del proyecto como parte del Plan de gestión de la configuración. Pueden ser modificadas y ajustadas en la medida que avanza el proyecto. Pero en cualquier caso se debe considerar la estructura de los equipos de trabajo y la comunicación que se requiere entre ellos, las fases y secuencia del ciclo de vida y que ayude a gestionar la evolución de los componentes. Si en algún momento sentimos que no son apropiadas o no es práctico ejecutarlas como se planteó, debemos hacer las modificaciones para permitir un uso adecuado. 


Sólo los proyectos y la organización determinan el tipo y contenido de las líneas base. El principio a tener en cuenta es, partiendo del concepto de línea base, primero debe ser aprobado el contenido de alguna manera para garantizar el resultado de las etapas posteriores, luego el contenido debe ser útil para las siguientes etapas y por eso tiene sentido controlarlo y finalmente cualquier cambio debe hacerse de manera controlada (el nivel de control lo determina el proyecto) de manera que no se afecten los grupos que están haciendo uso de ese contenido. 


Sobre la pregunta inicial es completamente adecuado si así funciona para el proyecto. Se puede tener un identificador de esa línea base con todas las versiones de los diferentes componentes que la integran y en caso de cambio ajustar el identificador de la línea base con las nuevas versiones de los componentes modificados. El tema puede dar para mucha discusión pero queda abierto por si aún no es claro, poder ampliarlo en trabajos posteriores. Al fin de cuentas esto nos sirve de línea base. ;-)

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 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.

Auditorías físicas a la configuración (PCA)

Son auditorías que permiten verificar que los elementos de configuración integrados cumplen con la especificación técnica que los define. Esto implica que todos los componentes requeridos están presentes, que corresponden con la versión correcta y con la información contenida en los reportes de estado de la línea base. Es una evaluación independiente para demostrar que el código es adecuadamente descrito en la documentación que se entrega y que tanto el código como la documentación están listos para la entrega. De igual forma contribuye a evaluar el cumplimiento de acuerdos legales y requisitos establecidos para el producto. Típicamente se realiza en conjunción con la auditoría funcional (FCA) o una vez que los hallazgos de la FCA han sido resueltos. En esencia la PCA revisa la información de los reportes de estado a la configuración para asegurar que los productos y la documentación asociada son adecuadamente integradas en la línea base antes de liberar el producto. Lista de elementos a verificar Puede considerar como base para la verificación:

• ¿Los hallazgos de FCA han sido resueltos adecuadamente?
• ¿Todos los componentes de configuración identificados están integrados en la línea base?
• ¿Todos los componentes de configuración cumplen con los estándares que los definen?
• ¿El producto ha sido integrado a partir de los componentes de configuración correctos de acuerdo con la especificación que los define?
• ¿La documentación que se entrega está completa?
• ¿El medio en el que se entrega el producto cumple con los requisitos especificados? ¿Está adecuadamente identificado y etiquetado el producto?
• ¿Los entregables cubren con la lista de entregables requeridos?
• ¿Se cumplen los requisitos para la licencia del producto por terceros?
• ¿Se cubren los requisitos de exportación del producto?

Al igual que en FCA, la revisión se hace sobre muestreo de los productos y documentación considerando los elementos más críticos o problemáticos en el pasado. Referencia. Westfall, Linda. Software Configuration Management audits. www.westfallteam.com

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