La SP 2.2 en RD establece la necesidad de asociar los componentes del producto con los requisitos que los definen. De manera que los componentes que se van derivando tienen un requisito asociado que los define.
Por su parte en REQM, en la SP 1.4 se establece la trazabilidad bidireccional de los requisitos hacia las entidades que se obtienen. Lo cual constituye una herramienta fundamental en la evaluación de impacto de los cambios a requisitos.
¿Cuál es el sentido de cada práctica, si aparentemente ambas llevan una relación de requisitos a componentes?
Asociación de requisitos en RD
Las prácticas de RD tienen que ver con la ingeniería de requisitos. Los requisitos se: identifican, documentan, descomponen, revisan y validan. Desde esta perspectiva la necesidad de asociar los componentes a los requisitos, justifica la existencia del componente en si. Si estamos desarrollando un componente que no tiene una razón de ser no se tendría que trabajar en él.
La asociación de requisitos permite, a partir de la arquitectura establecida para el producto, determinar qué características de desempeño del producto, restricciones de diseño, forma y función cumple un componente. Esto ya sea de manera compartida, donde cada componente contribuye con una parte de ese requisito en específico, o en su conjunto con todos los componentes. También es importante identificar las dependencias entre asociaciones, de manera que si existe un cambio se puedan identificar todos los componentes que son afectados.
Esta práctica es fundamental en desarrollos que integran componentes no necesariamente de ingeniería de software, donde componentes físicos de ingeniería de sistema cumplen con los requisitos definidos.
Trazabilidad de requisitos en REQM
La trazabilidad de requisitos permite evaluar el impacto de un cambio en los requisitos que están comprometidos. Esta práctica tiene más función de gestión, que de ingeniería, ya que ayuda a la adecuada gestión de los cambios. Permite establecer una asociación de los requisitos fuente a los requisitos de bajo nivel y viceversa. De manera que se pueda identificar si todos los requisitos fuente han sido considerados y si todos los requisitos de bajo nivel están relacionadas con un requisito fuente.
Esta trazabilidad puede considerar también las entidades derivadas de los requisitos como productos de trabajo, componentes, funciones, objetos, interfaces, procesos o individuos. En ciertos casos es importante conocer las dependencias entre entidades al mismo nivel, que podrían ser las interfaces, en este caso se habla de una trazabilidad horizontal. Este tipo de información es fundamental para garantizar las prácticas de PI.
Las herramientas de trazabilidad de requisitos pueden ayudar a cumplimentar ambas prácticas, pero es importante entender la intención de cada una para un adecuado uso de la información.
Hablemos de las mejores prácticas de la industria para el desarrollo, mantenimiento, adquisición y operación de productos y servicios.
Asignación de requisitos a componentes
Etiquetas:
administracion,
analisis,
CMMI,
cmmi sei,
cmmi v1.3,
compromisos,
definicion,
development,
modelo,
requerimientos,
requisitos,
revision,
tecnicas
Suscribirse a:
Enviar comentarios (Atom)
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...
-
En diversas situaciones se hace uso indistinto de los términos requerimientos y requisitos. En CMMI se usa en diversas prácticas el términ...
-
En el proceso de identificación, análisis y definición de un proceso se deben identificar claramente las necesidades, requisitos y result...
-
La solución de problemas es parte fundamental de la mejora continua, para eliminar el origen de los problemas y evitar que se presenten nu...
No hay comentarios:
Publicar un comentario