Repositorio de dominio para gestión de requisitos: ¿crear o comprar?

Question

En mi organización, tenemos algunos procesos muy ineficientes en torno a la gestión de requisitos, el seguimiento de lo que realmente se entregó en qué versiones, etc., las versiones posteriores rompen la funcionalidad anterior, etc. Actualmente, todo se gestiona manualmente. Los requisitos se distribuyen en varios documentos y rastreadores de problemas, y los detalles de implementación están en el código en subversión, Jira, TestLink. Estoy tratando de armar un sistema que consolide la información de requisitos, de modo que se obtenga de una sola fuente autorizada, se pueda acceder a través de interfaces estándares (servicios web, navegadores, etc.) y se pueda validar automáticamente. El conocimiento real del dominio no es tan complicado, pero es altamente patentado y no estándar (es decir, no solo clientes con direcciones, correos electrónicos, etc.), y es relacional: los clientes tienen ciertas funcionalidades, características activadas/desactivadas, fuentes de datos específicas conectadas - todo en versiones específicas. Entonces modelar esto debería ser sencillo.

¿Alguien puede aconsejar el mejor enfoque para esto? Estoy seguro de que puedo desarrollar un sistema desde cero que coincida exactamente con los requisitos, por ejemplo Ruby on Rails, Grails o algún framework RAD. Pero estoy teniendo dificultades para obtener la aceptación de la administración, se sentirían más seguros con una solución estándar.

¿Alguien puede recomendar tal sistema? ¿O es mejor construirlo desde cero, como creo que lo estoy? Me temo que un sistema comprado tardaría tanto en desplegarse y no cumpliría con nuestros requisitos.

Gracias por cualquier consejo.

Answer 1

{descargo de responsabilidad - mencionando producto de mi empleador}

Las breves experimentos que he hecho con una herramienta comercial RequisitePro parecía bastante bueno conmigo. Permitió uno anotar documentos de Word existentes y crear una base de datos enlazada en tiempo real de los requistos identificados a continuación, realizar un montón de análisis y seguimiento de ellos.

A veces, cuando veo un producto comercial, pienso: "Oh, buenos fragmentos brillantes, pero los fundamentos que pude tocar en Perl en un fin de semana". Ese no es el caso con estas cosas. Ciertamente miraría los productos comerciales en este espacio y el rendimiento con un par (ReqPro tiene una versión de prueba gratuita, supongo que también la competencia) antes de pasar tiempo en mi propio desarrollo.

Answer 2

Gracias a un molino por la respuesta. Voy a echar un vistazo a RequisitePro, al menos seguiré la estrategia "Nadie fue despedido por comprar IBM";) tienes razón, y lo sabía, en estas situaciones, comprar es mejor. Es tentador cuando puedo visualizar lanzarlo rápidamente, pero con ese enfoque hay otras ventajas y riesgos.

Gracias, Justin

Answer 3

creo que usted está describiendo dos problemas diferentes. El primero es lograr que todos estandaricen y el segundo es seleccionar una buena herramienta para la gestión de requisitos. No me preocuparía tanto por la herramienta como lo haría con el proceso y la gente. Tener la mejor herramienta en el mundo no ayudará si sus diversos gerentes de proyecto no quieren compartir.

Por lo tanto, mi sugerencia es comenzar simple. Agarre Redmine o Trac y asuma el desafío de lograr que todos se estandaricen. Una vez que tenga a todos en la mentalidad correcta, podrá mejorar las herramientas que usa para el almacenamiento.

Answer 4

Si bien Requisite Pro impone un estándar y eso sin duda puede ayudarlo en su tarea, sin duda la segunda Mark en tratar de estandarizar la entrada de acuerdo con el personal y utilizando una herramienta más flexible como Trac, Redmine (que ambos tienen tiempos de instalación y configuración increíblemente rápidos, especialmente si los aloja desde una VM) o incluso uno personalizado si puede lograr que la administración apruebe su proyecto.