La trazabilidad de requisitos es una subdisciplina de la gestión de requisitos dentro del desarrollo de software y la ingeniería de sistemas . La trazabilidad como término general está definida por el Vocabulario de Ingeniería de Software y Sistemas de IEEE [1] como (1) el grado en que se puede establecer una relación entre dos o más productos del proceso de desarrollo, especialmente productos que tienen un predecesor-sucesor o maestro. -relación subordinada entre sí; [2] (2) la identificación y documentación de rutas de derivación (hacia arriba) y rutas de asignación o flujo descendente (hacia abajo) de productos de trabajo en la jerarquía de productos de trabajo; [3](3) el grado en que cada elemento de un producto de desarrollo de software establece su razón de ser; y (4) asociación discernible entre dos o más entidades lógicas, tales como requisitos, elementos del sistema, verificaciones o tareas.
En particular, la trazabilidad de requisitos se define como "la capacidad de describir y seguir la vida de un requisito tanto hacia adelante como hacia atrás (es decir, desde sus orígenes, pasando por su desarrollo y especificación, hasta su posterior despliegue y uso, y a través de períodos). de perfeccionamiento e iteración en curso en cualquiera de estas fases) ". [4] [5] En el campo de la ingeniería de requisitos, la trazabilidad consiste en comprender cómo los requisitos de alto nivel (objetivos, metas, propósitos, aspiraciones, expectativas, necesidades) se transforman en requisitos de bajo nivel. Por lo tanto, se ocupa principalmente de las relaciones de satisfacción entre capas de información (también conocidas como artefactos). [6] Sin embargo, la trazabilidad puede documentar las relaciones entre muchos tipos de artefactos de desarrollo, como requisitos, declaraciones de especificaciones, diseños, pruebas, modelos y componentes desarrollados. [7] Por ejemplo, es una práctica común capturar las relaciones de verificación para demostrar que un requisito es verificado por un determinado artefacto de prueba.
La trazabilidad es especialmente relevante cuando se desarrollan sistemas críticos para la seguridad y, por lo tanto, está prescrita por directrices de seguridad , como DO178C , ISO 26262 e IEC61508 . Un requisito común de estas directrices es que se deben verificar los requisitos críticos y que esta verificación se debe demostrar mediante la trazabilidad. [8]
Seguimiento hacia y más allá de los requisitos
Trazabilidad de requisitos previos . [4] Los requisitos provienen de diferentes fuentes, como la persona de negocios que ordena el producto, el gerente de marketing y el usuario real. Todas estas personas tienen diferentes requisitos del producto. Utilizando la trazabilidad de los requisitos, una característica implementada se puede rastrear hasta la persona o grupo que la deseaba durante la obtención de los requisitos . Esto se puede utilizar durante el proceso de desarrollo para priorizar el requisito, determinando qué tan valioso es el requisito para un usuario específico. También se puede usar después de la implementación para ver por qué ciertas características no utilizadas que se encontraron durante los estudios de usuarios fueron necesarias en primer lugar.
Trazabilidad posterior a los requisitos . [4] No solo se deben rastrear los requisitos en sí mismos, sino también la relación de requisitos con todos los artefactos asociados con él, como modelos, resultados de análisis, casos de prueba, procedimientos de prueba, resultados de prueba y documentación de todo tipo. Incluso las personas y los grupos de usuarios asociados con los requisitos deben ser rastreables. Los requisitos se materializan en artefactos de diseño, implementación y, finalmente, se verifican. Los artefactos vinculados a las últimas etapas también deben rastrearse hasta los requisitos. Por lo general, esto se realiza mediante una matriz de trazabilidad de requisitos .
Establecer la trazabilidad más allá de los requisitos en los artefactos de diseño, implementación y verificación puede resultar difícil. [9] Al implementar requisitos de software, por ejemplo, los requisitos pueden estar en una herramienta de gestión de requisitos , mientras que los artefactos de diseño pueden estar en una herramienta como MagicDraw , Mathworks Simulink , Rational Rhapsody y Microsoft Visio . Además, los artefactos de implementación probablemente estarán en forma de archivos fuente, enlaces a los cuales se pueden establecer de varias formas en varios ámbitos. Artefactos de verificación como los generados por pruebas internas o herramientas de verificación formales (por ejemplo, LDRA Testbed suite , Parasoft DTP y SCADE )
La integración del repositorio o la pila de herramientas puede representar un desafío importante para mantener la trazabilidad en un sistema dinámico.
Uso de información de trazabilidad
El uso de la rastreabilidad, especialmente cuando se rastrea más allá de los requisitos a todos los artefactos ubicados en la cadena de herramientas, puede traer varios beneficios: [10] [11]
- Análisis de impacto de cambios : si un requisito está cambiando, los enlaces de seguimiento informan sobre artefactos relacionados y dependientes. Estos artefactos pueden verificarse fácilmente y, si es necesario, ajustarse. Se reduce la probabilidad de pasar por alto artefactos relacionados.
- Análisis de cobertura: la trazabilidad garantiza que no se pasen por alto los requisitos . Especialmente al certificar productos críticos para la seguridad, es necesario demostrar que se cumplen todos los requisitos.
- Análisis del estado del proyecto: es posible realizar un seguimiento del estado del proyecto: el análisis de los datos de trazabilidad permite ver el estado de finalización de los requisitos. Los requisitos sin enlaces o con una cadena de seguimiento incompleta (por ejemplo, requisitos con implementación pero sin pruebas) indican que es necesario seguir trabajando. Los enlaces perdidos muestran qué artefactos concretos faltan y deben realizarse.
- Reutilización de los componentes del producto: es posible estructurar los requisitos y sus artefactos vinculados en paquetes. Estos paquetes se pueden utilizar para diferentes productos.
- Relaciones persistentes: a menudo, el conocimiento de un proyecto o producto está en la cabeza de personas específicas. Mediante el uso de la trazabilidad, este conocimiento se guarda al visualizar la relación entre los diferentes artefactos. Este conocimiento permanece incluso si una persona abandona el proyecto.
- Optimización de pruebas: al vincular los requisitos, el código fuente , los casos de prueba y los resultados de las pruebas, es fácil identificar las partes afectadas del código fuente si las pruebas fallan. Además, se pueden identificar y eliminar casos de prueba redundantes.
En [12] se ofrece una descripción más completa de las actividades de desarrollo respaldadas por la rastreabilidad y su relevancia. [12]
Uso práctico de la información de trazabilidad
Amplios estudios documentan la efectividad, pero también las dificultades de capturar información de trazabilidad:
- La trazabilidad acelera y mejora las actividades de desarrollo: un estudio con 71 sujetos que realizaron cambios en el código fuente con y sin soporte de trazabilidad mostró los beneficios de la trazabilidad. Los desarrolladores completaron las tareas con soporte de trazabilidad un 24% más rápido y un 50% más correcto. [13]
- Una trazabilidad más completa ayuda a evitar defectos de software: en un análisis de datos de desarrollo de 24 proyectos de código abierto de tamaño mediano y grande, se encontró una relación estadísticamente significativa entre la integridad de la información de trazabilidad capturada y la tasa de defectos del código fuente desarrollado. Los componentes con una trazabilidad más completa mostraron un menor número de defectos (también conocidos como errores). [14]
- Lograr una trazabilidad compatible es difícil: un análisis de las pruebas previas a la comercialización de software en dispositivos médicos en la Administración de Drogas y Alimentos de los EE. UU. (FDA) en 2013 identificó brechas significativas entre la información de trazabilidad prescrita y archivada. [8] La búsqueda hacia una trazabilidad conforme a los estándares a menudo resulta en una "Gran Congelación". Gran congelación, ya que las empresas tienen como objetivo evitar un mayor desarrollo porque la recertificación está asociada con un enorme esfuerzo. [15]
Visualización de información de trazabilidad
Uno de los objetivos de la trazabilidad es visualizar la relación entre los artefactos. A medida que aumenta el número y la complejidad de los enlaces de seguimiento, se necesitan técnicas para la visualización de la trazabilidad. Una visualización puede incluir información sobre los artefactos (por ejemplo, tipo de artefacto, metadatos, atributos) y enlaces (por ejemplo, tipo de enlace, metadatos, fuerza del enlace). [dieciséis]
Las visualizaciones comunes para la información de trazabilidad son matrices , gráficos , listas e hipervínculos .
- Matriz de trazabilidad : una matriz de trazabilidad es una representación en forma de tabla que mapea artefactos de un tipo (p. Ej., Requisitos) representados en columnas con artefactos de otro tipo (p. Ej., Código fuente) representados en filas. Las celdas visualizan un rastro entre dos artefactos si están llenas o un no rastro si se dejan vacías. [16] La ventaja de las matrices de trazabilidad es que todos los vínculos entre los artefactos son visibles de un vistazo. Los filtros ayudan a reducir la cantidad de información mostrada. Las matrices de trazabilidad son adecuadas para tareas de gestión. [16] Sin embargo, en la industria, los proyectos a menudo consisten en miles de artefactos: las tablas pueden volverse muy grandes y confusas. [17]
- Gráfico de trazabilidad : en un gráfico de trazabilidad, los artefactos se representan como nodos. Los nodos están conectados por bordes, si existe un vínculo de seguimiento entre los artefactos. Los gráficos son especialmente adecuados para tareas de desarrollo. Permiten obtener una visión general de los enlaces de forma exploratoria y se caracterizan por una alta tasa de comprensión de la información. [16] Al navegar por el gráfico, es fácil identificar los enlaces que faltan como una pista para crear los artefactos necesarios.
- Lista : las listas representan enlaces de trazabilidad en una entrada. Esta entrada podría incluir información sobre el artefacto y los atributos de origen y destino. Son especialmente adecuados cuando se deben ejecutar operaciones masivas para varios artefactos diferentes. Los filtros y mecanismos de clasificación permiten manejar la información mostrada. Sin embargo, en comparación con las visualizaciones descritas anteriormente, las listas son menos adecuadas para ejecutar tareas de gestión, desarrollo y prueba de proyectos. [dieciséis]
- Hipervínculo : los hipervínculos conectan artefactos vinculados y permiten "saltar" de un artefacto de origen a un artefacto vinculado. Esta visualización es adecuada si se necesita información detallada sobre un artefacto, ya que permite la navegación a los artefactos en su entorno nativo. [16] El uso de hipervínculos únicamente tiene la desventaja de que es necesario un gran esfuerzo de navegación para obtener una descripción general del estado del enlace, ya que los artefactos vinculados no se visualizan de forma compacta.
Las visualizaciones se pueden combinar para superar sus limitaciones específicas.
Realización técnica
Trazabilidad manual
La trazabilidad se realiza mediante la captura de trazas, ya sea de forma totalmente manual o compatible con herramientas, por ejemplo, como hoja de cálculo en Microsoft Excel . Aunque se aplica ampliamente, este proceso es engorroso, propenso a errores y, a menudo, conduce a información de trazabilidad que es de calidad insuficiente debido a las diversas herramientas de desarrollo involucradas y al número típicamente muy alto de artefactos a rastrear. [18]
Trazabilidad con soporte de herramientas
La trazabilidad respaldada por herramientas requiere que la información de desarrollo que se distribuye a través de una cadena completa de herramientas de desarrollo sea homogeneizada y agregada. Existen los siguientes enfoques para alcanzar este estado:
La homogeneización del medio ambiente a través de una herramienta de ALM herramienta - ALM cadenas de herramientas cubre todo el ciclo de vida de un sistema y gestionar todos los artefactos del proceso de desarrollo de un enfoque holístico. Los rastreadores de problemas que implementan la plantilla de requisitos de Volere se han utilizado con éxito en entornos distribuidos. La ventaja de este enfoque es que la homogeneización de artefactos permite administrarlos y analizarlos fácilmente con herramientas dedicadas de la herramienta ALM . La desventaja es que es necesario implementar toda la cadena de herramientas de ALM . Si se introducen, es difícil reemplazar herramientas específicas en la cadena de herramientas.
Homogeneización de datos a través de requisitos sustitutos : las herramientas de gestión de requisitos (RM) permiten almacenar, organizar y gestionar todos los requisitos de las especificaciones de un sistema y, por lo general, los organizan en un árbol de especificaciones que vincula cada requisito con su requisito principal en la especificación superior. Las funciones de análisis típicas basadas en la información de trazabilidad registrada son, por ejemplo, verificaciones de integridad, es decir, si todos los requisitos del nivel del sistema bajan al nivel del equipo (con o sin modificación), evaluación de las desviaciones de los requisitos en todos los niveles y presentación del estado de calificación. Para garantizar la trazabilidad de los tipos de artefactos más allá de los requisitos, las herramientas de RM a menudo permiten importar otros artefactos como requisitos sustitutos que luego se pueden rastrear con los métodos de rastreo de requisitos de la herramienta. La desventaja de este enfoque es que se necesitan diferentes adaptadores o convertidores para los diferentes tipos de artefactos que deben tener una versión y un formato de datos coherentes. A diferencia de las herramientas ALM, esta coherencia debe realizarse uno mismo.
Homogeneización de datos a través de una herramienta de trazabilidad dedicada : el concepto básico de herramientas de trazabilidad dedicadas consta de tres pasos esenciales:
- La definición de un modelo de datos también conocido como modelo de información de trazabilidad (TIM). Este modelo especifica qué tipos de artefactos (por ejemplo, requisitos de las partes interesadas, requisitos de software, pruebas de integración, elementos del modelo del sistema) y cómo están vinculados.
- La definición de asignaciones a partir de todos los datos relevantes de todas las herramientas que forman parte de su cadena de herramientas de desarrollo y cómo estos datos se asignan al TIM.
- Las funciones de métricas y análisis se definen en el TIM, no en los datos que residen en una herramienta específica.
El enfoque une las ventajas de los enfoques antes mencionados: cubre todas las herramientas y artefactos en un enfoque holístico, homogeneiza los datos y evita el riesgo de inconsistencias causadas por sustitutos obsoletos. La desventaja es que este enfoque implica la extensión de una cadena de herramientas por otra herramienta (trazabilidad).
Ver también
- Lista de herramientas de gestión de requisitos
- Requisitos
- Análisis de requerimientos
- Gestión de requerimientos
Referencias
- ^ Ingeniería de sistemas y software - Vocabulario . Iso / Iec / IEEE 24765: 2010 (E) . 2010-12-01. págs. 1–418. doi : 10.1109 / IEEESTD.2010.5733835 . ISBN 978-0-7381-6205-8.
- ^ Guía IEEE para desarrollar especificaciones de requisitos del sistema . 1998 Edición IEEE STD 1233 . 1998-12-01. págs. 1-36. doi : 10.1109 / IEEESTD.1998.88826 . ISBN 978-0-7381-1723-2.
- ^ Guía IEEE para tecnologías de la información - Definición del sistema - Documento sobre el concepto de operaciones (ConOps) . IEEE STD 1362-1998 . 1998-12-01. págs. 1–24. doi : 10.1109 / IEEESTD.1998.89424 . ISBN 978-0-7381-1407-1.
- ^ a b c Gotel, OCZ; Finkelstein, CW (abril de 1994). Un análisis del problema de trazabilidad de requisitos . Actas de la Conferencia Internacional IEEE sobre Ingeniería de Requisitos . págs. 94-101. CiteSeerX 10.1.1.201.7137 . doi : 10.1109 / icre.1994.292398 . ISBN 978-0-8186-5480-0. S2CID 5870868 .
- ^ Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (1 de enero de 2012). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Trazabilidad de software y sistemas . Springer London. págs. 3 –22. doi : 10.1007 / 978-1-4471-2239-5_1 . ISBN 9781447122388.
- ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick (2005). Ingeniería de Requisitos (Segunda ed.). Saltador. págs. 9-13, 131-151. ISBN 978-1-85233-879-4.
- ^ Pinheiro FAC y Goguen JA, "Una herramienta orientada a objetos para rastrear requisitos", IEEE Software 1996, 13 (2), pp. 52-64
- ^ a b Mäder, P .; Jones, PL; Zhang, Y .; Cleland-Huang, J. (1 de mayo de 2013). "Trazabilidad estratégica para proyectos críticos para la seguridad". Software IEEE . 30 (3): 58–66. doi : 10.1109 / MS.2013.60 . ISSN 0740-7459 . S2CID 16905456 .
- ^ Li, Yin; Juan Li; Ye Yang; Mingshu Li (2008). Trazabilidad centrada en los requisitos para el análisis del impacto del cambio: un estudio de caso . Springer Berlín / Heidelberg. págs. 100-111. ISBN 978-3-540-79587-2.
- ^ Wiegers, Karl (2013). "Trazabilidad de requisitos: vínculos en la cadena de requisitos, parte 1" . jama . Consultado el 14 de diciembre de 2016 .
- ^ Wiegers, K .; Beatty, J. (2013). Requisitos de software . Microsoft Press.
- ^ Caldo, Elke; Mäder, Patrick; Philippow, Ilka (8 de abril de 2013). Doerr, Joerg; Opdahl, Andreas L. (eds.). Ingeniería de Requisitos: Base para la Calidad del Software . Apuntes de conferencias en Ciencias de la Computación. Springer Berlín Heidelberg. pp. 158 -173. CiteSeerX 10.1.1.659.3972 . doi : 10.1007 / 978-3-642-37422-7_12 . ISBN 9783642374210.
- ^ Mäder, Patrick; Egyed, Alexander (1 de abril de 2015). "¿Los desarrolladores se benefician de la trazabilidad de requisitos al desarrollar y mantener un sistema de software?". Ingeniería de software empírica . 20 (2): 413–441. doi : 10.1007 / s10664-014-9314-z . ISSN 1382-3256 . S2CID 2514618 .
- ^ Rempel, Patrick; Mäder, Patrick (1 de enero de 2016). "Prevención de defectos: el impacto de la integridad de la trazabilidad de los requisitos en la calidad del software" . Transacciones IEEE sobre ingeniería de software . PP (99): 777–797. doi : 10.1109 / TSE.2016.2622264 . ISSN 0098-5589 . S2CID 1959772 .
- ^ "open-DO | Hacia un marco cooperativo y abierto para el desarrollo de software certificable" . www.open-do.org . Consultado el 15 de abril de 2017 .
- ^ a b c d e f Li, Y .; Maalej, W. (2012). ¿Qué visualización de trazabilidad es adecuada en este contexto? Un estudio comparativo . Saltador. págs. 194–210.
- ^ Lerche, Felix (2019). "5 RAZONES POR LAS QUE UNA MATRIZ DE TRAZABILIDAD DE REQUISITOS NO ES SUFICIENTE" .
- ^ Kannenberg, Andrew; Saiedian, Hossein (2009). "Por qué la trazabilidad de los requisitos de software sigue siendo un desafío" (PDF) . Revista CrossTalk: la revista Journal of Defense Software Engineering .