Ha pasado un buen tiempo desde que Ivar Jacobson "inventara" los casos de uso, de la creación de UML y RUP junto a Grady Booch y James Rambaugh para la Rational Software, de la adopción como estándar del modelo CMMI y de la aparición de las Metodologías Ágiles, y sin embargo hoy en día sigue existiendo mucha confusión al momento de elegir el conjunto de prácticas más idóneas para capturar requisitos de software y traducirlos en el producto prometido al inicio del proyecto.
Los problemas más frecuentes:
- No consensuar con el cliente la definición completa a alto nivel del alcance del proyecto. Elaborar la definición del proyecto es una práctica ineludible para darle un marco general que guíe las actividades.
- No realizar el modelado del negocio antes de desarrollar el software. El sistema se desarrolla con el objetivo de dar soporte a los procesos de la organización, si el analista (o desarrollador) no se involucra en su problemática corre un alto riesgo confiando en la posibilidad de que los requisitos de software identificados respondan a las necesidades para las que el producto fue creado.
Seguir leyendo en: http://maypun.blogspot.com/2010/01/requerimientos-de-software-un-abordaje.html
Los problemas más frecuentes:
- No consensuar con el cliente la definición completa a alto nivel del alcance del proyecto. Elaborar la definición del proyecto es una práctica ineludible para darle un marco general que guíe las actividades.
- No realizar el modelado del negocio antes de desarrollar el software. El sistema se desarrolla con el objetivo de dar soporte a los procesos de la organización, si el analista (o desarrollador) no se involucra en su problemática corre un alto riesgo confiando en la posibilidad de que los requisitos de software identificados respondan a las necesidades para las que el producto fue creado.
Seguir leyendo en: http://maypun.blogspot.com/2010/01/requerimientos-de-software-un-abordaje.html