¿Qué soluciones de software libre están disponibles para administrar los requisitos de software?

8

En la compañía donde trabajo, estamos comenzando a planear cumplir con el ciclo de vida de desarrollo de software. Ya tenemos un sistema wiki, vcs, sistema de seguimiento de errores y un sistema de integración continua.

El siguiente paso que queremos tener es comenzar a administrar, de manera estructurada, los requisitos de software. No queremos usar un wiki o documentación compartida porque tenemos muchos aportes (desarrollador, gerente, comercial, analista de seguridad y otros) y no queremos manejar la proliferación de .doc alrededor del recurso compartido de red. Estamos tratando de buscar y esperamos poder encontrar y usar un software FOSS para administrar todo esto.

Tenemos alrededor de 30 personas y no tenemos un presupuesto para software comercial. Necesitamos una solución gratuita para la gestión de requisitos.

Lo que queremos es un software que pueda administrar:

Características requeridas:

  • Requisitos de software divididos de forma estructurada y configurable
  • Versiones de los requisitos (historial, diff, etc., como código fuente)
  • Interdependencia de requisitos (hijo de, padre de, relacionado con)
  • Control de acceso basado en reglas para el manejo de datos
  • Multiusuario, multiproyecto
  • Carga de archivos (para gráficos, documentos relacionados, etc.)
  • Funciones de informe y extracción.

Características opcionales:

  • Basado en la web
  • Caso de prueba
  • Gestión basada en el tiempo (línea de tiempo, datos exceptuados, datos de resultados)
  • Asignación de personas, etc.
  • Cosas relacionadas con el negocio
  • Manejo de asignación de hardware

Ya he jugado con testlink y ahora estoy jugando con RTH, el siguiente que intento es redmine.

project-management tools requirements abucheos
fuente

Respuestas:

3

Utilizo mi rastreador de casos, FogBugz, para esto. La mayoría de las cosas que notas ya están incorporadas:

  • Dividido de forma estructurada configurable

No estoy exactamente seguro de lo que quiere decir aquí, pero cada requisito es un caso específico, con un nivel de prioridad.

  • Versiones de los requisitos.

Siempre hay disponible un historial completo del caso, aunque no difiere, simplemente 'agrega' ediciones

  • Interdependencia de requisitos

Incorporado

  • Control de acceso basado en reglas para el manejo de datos.

No estoy exactamente seguro de lo que quiere decir aquí, pero hay funciones de administración de usuarios para que solo puedan ver ciertos tipos de casos.

  • Multiusuario, multiproyecto
  • Subir archivo
  • Basado en la web
  • Gestión basada en el tiempo.

Todo incorporado

  • Asignación de personas, etc.

Incorporado (use 'corresponsales')

  • Cosas relacionadas con el negocio

uhm ... hay todo tipo de 'cosas'

  • Manejo de asignación de hardware

No estoy seguro.

Bonificaciones: si usa Kiln, puede integrar el cumplimiento de los requisitos con los registros de código fuente (Kiln no es necesario, pero es Mercurial, que es un IMO más, es fácil de usar, y obviamente funciona felizmente con FogBugz).

Steven Evers
fuente
3

Hice esta pregunta en Stack Overflow hace aproximadamente 2 años . He estado observando y no parece que las cosas hayan cambiado mucho desde entonces.

Thomas Owens
fuente
Ah, sí, todo el software es el mismo, rth, rth-turbo, testlink, no he intentado redmine, y nuestro administrador del sistema ha intentado con salome-tmf pero todo lo que no se ajusta a nuestras necesidades. ¿Qué software usaste en este momento?
abucheos
1
No utilizo ningún software especializado: Word, Excel y una herramienta de modelado UML (Dia) son todo lo que uso para capturar los requisitos de forma estática. Un wiki puede reemplazar Word y Excel.
Thomas Owens
1

No estoy seguro de lo que está utilizando para un rastreador de errores, pero he utilizado con éxito tipos de problemas especiales para los requisitos con bastante éxito. Esencialmente, muchos programas de gestión de problemas (o seguimiento de errores) le permiten vincular problemas. También tienen el concepto de un requisito maestro con tareas o subregistros. Eso se encarga de la mayoría de lo que estás viendo.

La forma en que se maneja el control de versiones con dicho sistema es asignando el requisito a una versión. O es un campo personalizado o algo incorporado. Como tiene un nuevo requisito que reemplaza al anterior, lo vincula y cancela el anterior. Ahora tiene un rastro a través de las versiones de su software.

Una de esas herramientas de código abierto que he usado se llama Redmine: http://www.redmine.org/ Verás cierta superposición con algunas de las otras herramientas que ya tienes. Estoy pensando que un poco de creatividad con su conjunto de herramientas producirá algo lo suficientemente parecido a lo que desea sin tener que recurrir a los conjuntos de herramientas DOORS o (ir) Rational.

Berin Loritsch
fuente
A diferencia de los errores, los requisitos son "en vivo" y "evolucionan" a través del proceso de desarrollo. Pueden parecer versiones diferentes de un archivo en un sistema VCS. Una versión determinada de una aplicación estará compuesta por archivos en una versión determinada, y de la misma manera que se realizará una versión determinada a partir de una versión determinada de los requisitos (la línea de base). Tenga en cuenta que pueden ser los mismos requisitos (mismo ID), solo que en versiones diferentes. Un rastreador de errores generalmente carece de estas características, podrían imitarse, pero generalmente requieren mucho trabajo manual. Además, muchos rastreadores de errores no tienen una verdadera vista jerárquica de las entradas.
ldsandon