Estado del arte ingenieria de requerimientos

En la siguiente tabla se realiza una análisis comparativo de las mejores prácticas en ingeniería de requerimientos:

Aunque el concepto de requerimientos no ha cambiado, los modelos utilizados para realizar ingeniería de requerimientos han ido evolucionando; en los años 70, una época en que el desarrollo de software se opacó por los costos del hardware se utilizó el modelo secuencial o en cascada nombrado así debido a la cascada de una fase a otra (Sommerville, 2005), en este modelo la realización la documentación y la definición de requisitos se realizan en la etapa inicial del proceso, esto quiere decir que los requerimientos ya no serán modificados en ninguna de las próximas etapas.

En los años 90, se comienza a utilizar el modelo de desarrollo iterativo, este modelo contrario al modelo en cascada, permite identificar en fases más tempranas cambios en los requerimientos en función de las necesidades de los stakeholders, este método se enfoca en construir software en varias iteraciones, estas iteraciones son pequeños proyectos, el objetivo es entregar una parte del sistema completo, probado y estable.
En 2001, Kent Beck y otros 16 notables desarrolladores (grupo conocido como la “Alianza Ágil”) firmaron el manifiesto del desarrollo ágil del software (Beck, y otros, 2001), en el que se establecía lo siguiente:
“Estamos descubriendo formas mejores de desarrollar software, por medio de hacerlo y de dar ayuda a otros para que lo que hagan. Ese trabajo nos ha hecho valorar:
* Los individuos y sus interacciones sobre los procesos valorar:
* El software que funciona, más que la documentación exhaustiva
* La colaboración con el cliente, y no tanto la negociación del contrato
* Responder al cambio, mejor que apegarse a un plan.
Según (Pressman, 2010) los métodos agiles combinan una filosofía con un conjunto de lineamientos para el desarrollo. La filosofía pone el énfasis en: la satisfacción del cliente y en la entrega rápida de software incremental, los equipos pequeños y muy motivados para efectuar el proyecto, los métodos informales, los productos del trabajo con mínima ingeniería de software y la sencillez general en el desarrollo.
El método ágil más adoptado ha sido XP, cuya mayor premisa técnica es la incorporación del cliente en todo el desarrollo, incrementos cortos de desarrollo, diseños simples, programación por pares y la integración continua, estos disminuyen los costos de cambio frente a los tiempos, sin embargo, los datos reportado hasta el momento indican que esta disminución no tiene lugar para proyectos de mayor envergadura. Un buen ejemplo fue proporcionado por un sistema de dirección de una fábrica de arrendamiento, presentado en CISE 2002,
cuando el tamaño del proyecto alcanzó más de 1000 historias, 500.000 líneas de código, y 50 personas, con algunos cambios donde se tocaron más de 100 objetos, el coste del cambio aumentó inevitablemente. Esto requirió añadir al proyecto planes un poco más explícitos, controles y representaciones de arquitectura de alto nivel (Boehm, 2006).