El mantenimiento de la trazabilidad hasta al día como evoluciona el proyecto [cerrada]

Question

Durante varios proyectos, que necesitaba para asegurarse de que el modelo de casos de uso que se desarrolló durante la fase de análisis está cubriendo las necesidades del proyecto. Por eso, yo era capaz de tener algún grado de trazabilidad entre las declaraciones de requisitos (identificación única) y casos de uso (también identificado de forma única). En algunos casos, lo que permite la trazabilidad implica un esfuerzo adicional que consideraba (y más tarde se demostró) a ser una buena inversión.

Ahora, el mayor problema que tuvimos fue mantener esta trazabilidad más tarde, cuando las cosas empezaron a cambiar (como resultado de las solicitudes de cambio, o como resultado de los cambios de casos de uso).

¿Alguna idea de las mejores prácticas para el mantenimiento de la trazabilidad?

(Se puede aplicar a otros artículos en el proyecto - por ejemplo, casos de uso y casos de prueba, o los requisitos y casos de prueba de aceptación)

Más tarde editar Herramientas podrían ayudar, pero no pueden detectar vacíos o errores en la trazabilidad. Navegación ... tal vez, pero no garantiza que la trazabilidad está al día o correcta después de aplicar los cambios.

Answer 1

Creo que la trazabilidad es una de las cosas más difíciles de manejar en los requisitos, segundo para garantizar que los requisitos son correctos en el primer lugar. En mi experiencia, la mejor herramienta de trazabilidad es un ser humano .

No tenemos ninguna panacea; sólo algunos consejos para lo que me ha ayudado en el pasado.

• Guarde los documentos en una zona central donde todo el mundo puede llegar a ellos fácilmente. No me importa si se trata de Sharepoint, un wiki, o una unidad de red (aunque como algo que proporciona control de versiones, si es posible). Guardarlo en un lugar y de mercado a los diablos de la misma manera todo el mundo sabe que ir allí en busca de respuestas en lugar de utilizar copias antiguas o interrumpir los desarrolladores.
• Si usted tiene un punto central de contacto para la gestión de los artefactos o agrupaciones funcionales de los mismos, que ayuda mucho. Alguien que los comprende y los problemas sabrán dónde ir, qué actualización y si existen dependencias que deben llevarse adelante.
• El custodio de los artefactos tiene que estar comprometido con ellos y mantenerlos al día. Un año después de que he creado algunos documentos de los requisitos de un sitio, todavía los mantiene hasta la fecha. Sé que la mayoría de los desarrolladores se temen tener que hacer eso, pero un año después de eso, todavía estoy benefician de mirar hacia atrás en los que para ver cómo cambia un requisito funcional con el tiempo.
• No es necesario, pero es útil para identificar rápidamente los cambios en el tiempo: utilizar el seguimiento de la versión del procesador de documentos si lo tiene. Si no es así, me gustaría incluir al menos un registro de cambios para el documento o simplemente marcar un nuevo texto con una referencia al número de versión.
• Me han tratado de poner referencias de dependencia en mis artefactos en el pasado, como referencias a otros documentos o artefactos, pero se encontró que, o bien se convirtieron en obsoletos o eran difíciles de perder de vista y, por tanto, a menudo no se han actualizado. La disciplina puede superar esto, pero la mayoría de nosotros tenemos mucho que hacer, eh? Así que creo que la construcción en las referencias cruzadas entre documentos / artefactos es donde me gustaría una herramienta o alguna utilidad de gestión de requisitos libres aún no se ha lanzado a hacer el trabajo:)

Answer 2

Hemos utilizado hace tres años una herramienta racional para la escritura de los requisitos. En esas herramientas, muchas características preocupación trazabilidad.

Se ha encontrado que la capacidad de uso de estas herramientas no es perfecto. A pesar de que no proporcionan las funcionalidades básicas que necesitábamos, hemos perdido una gran cantidad de tiempo que va alrededor de sus limitaciones.

---

Asumo que no está pidiendo sobre la trazabilidad hasta el código, por lo excluyo esto desde mi respuesta.

---

Como usted menciona los identificadores únicos para sus estados de cuenta y casos de uso, es posible que ya usar una herramienta para su gestión.

En esencia, un modelo relacional sencilla (posiblemente en una base de datos) podría cubrir las relaciones entre sus piezas identificadas de forma única .

Me gustaría buscar una herramienta sencilla que hace eso. Si sólo una persona puede modificarlo, podría ser simplemente una hoja de Excel!

---

Tenga en cuenta que la vinculación de dos tipos de documentos probablemente no es suficiente.
Usted ha hablado de 5 tipos:. Estados, casos de uso, casos de prueba, los requisitos y casos de prueba de aceptación
Constantemente se necesita transitividad (en el mundo relacional, para unir tablas), para tener una visión que incluye varios pasos.

Answer 3

Hay muchos tipos de traceabilities para mantener los requisitos del sistema: a requisitos de subsistemas, los requisitos para el diseño, la exigencia de verificación (más importante), requisito de código, los requisitos a los problemas, etc.

Word, Excel y un sistema de seguimiento de problemas bien va un largo camino. Pero pueden ser dolorosas cuando se le requiere para demostrar la trazabilidad. mantener manualmente la trazabilidad es propenso a errores y mano de obra intensiva. IBM System Puertas es la mejor herramienta que he utilizado hasta ahora. Pero son caros. Hemos encontrado recientemente un sistema última traza que funciona bastante bien.

Answer 4

Si desea añadir una versión # para la declaración de los requisitos y para cada caso de uso - la mayoría de los de arriba-hasta la fecha su comunicación a todas y almacenados en algún lugar de fácil acceso (físico y / o informática / web). Usted tendrá que añadir un documento de cambio que incluye lo que fue la declaración requisito previo y / o caso de uso, cuando fue cambiado, por quién y quién aprobado.

Así que cuando se mira a los requisitos de uso que usted casos de especificaciones y / todas tienen la última vista y si hay una pregunta a un cambio, usted tiene el documento para referirse a un cambio (no sobrecargar los requisitos o especificaciones de casos de uso con información histórica, pero mantener la información histórica alrededor como referencia en una forma fácilmente accesible, significativo)

Answer 5

Yo diría que la mejor manera es utilizar un gestor de fallos. Cada requisito es rastreado como un error, modificaciones de desarrollo están asociados con ella, y los cambios se pueden mantener con bugnotes.

Muchas de control de errores le permiten asociar múltiples errores juntos (por ejemplo como duplicados) por lo que este puede ser utilizado para mantener los requisitos combinados discretos y todavía distintos para el seguimiento individual.

Si usted almacena todos sus otros artefactos en un SMC (es decir, documentos de diseño, etc), entonces se puede rastrear a través de éstos también asociándolos con el requisito.

Existen herramientas para ayudar con todo esto, ut he encontrado estas herramientas "completa del ciclo de vida" son realmente inservible, ya que tratar de hacer demasiado en una sola aplicación, o como relacionada aplicaciones que "integran" juntos, y están increíblemente caro.