2010-08-28
Existen varios modelos para simplificar el proceso de desarrollo. Cada uno tiene sus pros y sus contras, y le toca al equipo de desarrollo adoptar la más adecuada para el proyecto. A veces una combinación de los modelos pueden ser la más adecuada.
El modelo muestra un proceso de cascada, donde los desarrolladores han de seguir estas fases con el fin de:
En un estricto modelo de cascada, después de que cada fase ha terminado, se procede a la siguiente. Las revisiones pueden producirse antes de pasar a la siguiente fase que permite la posibilidad de cambios (que puede implicar un proceso de cambio de control formal). Los comentarios también pueden ser empleados para garantizar que la fase es de hecho completa y los criterios de finalización de fase se refiere a menudo como una "puerta" que el proyecto debe pasar a través de pasar a la siguiente fase. El Modelos en Cascada no permite revisar cualquiera de las fases anteriores una vez que esté completa. Esta falta de flexibilidad en un modelo de cascada pura ha sido una fuente de la crítica por otros modelos más flexible.
La característica clave de un modelo en espiral es la gestión del riesgo en momentos en el ciclo de desarrollo. En 1988, Barry Boehm publicó un sistema de desarrollo de software formal "modelo en espiral", que combina algunos aspectos clave del modelo de cascada y rápidas metodologías de prototipos, este hacía más hincapié en un área clave que muchos sintían que había sido descuidada por otras metodologías: el análisis de riesgo iterativo particularmente adecuado para los sistemas complejos a gran escala.
La Espiral es visualizada como un proceso que pasa por un cierto número de iteraciones, con el representante diagrama de cuatro cuadrantes de las siguientes actividades:
El modelo en espiral dirigida por riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones a fin de apoyar la reutilización del software, la calidad del software puede ayudar como un objetivo especial de integración en el desarrollo de productos. Sin embargo, el modelo en espiral tiene algunas condiciones restrictivas, a saber:
El desarrollo iterativo establece la construcción de un principio pequeño después cada vez más grandes porciones de un proyecto de software para ayudar a todos los participantes a descubrir cuestiones importantes de forma temprana, antes de que problemas o supuestos defectuoso puedan conducir al desastre. Los procesos iterativos se prefieren por los desarrolladores comerciales, ya que permite un potencial de alcanzar los objetivos de diseño de un cliente que no sabe cómo definir lo que quiere.
El desarrollo ágil de software utiliza el desarrollo iterativo como base, pero sus defensores demandan un punto de vista más claro y más centrado en las personas que los enfoques tradicionales. El modelos ágil, utiliza procesos de retroalimentación, en lugar de planificación, ya que este es su mecanismo primario de control. La reacción es impulsada por las pruebas regulares y las liberaciones de software en constante evolución.
Hay muchas variaciones de los procesos ágiles: