Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las
cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado
para sus necesidades. En ocasiones puede que una combinación de varios modelos
sea apropiado.
Modelo de cascada
El modelo de cascada muestra un proceso donde los desarrolladores han de
seguir las siguientes fases de forma sucesiva:
- Especificación de requisitos
- Diseño del software
- Construcción
o Implementación del software
- Integración
- Pruebas (o validación)
- Despliegue (o instalación)
- Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza
una fase, comienza la otra. En ocasiones se realiza una revisión antes de
iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que
puede incluir un proceso de control formal de cambio). Las revisiones también
se utilizan para asegurar que la fase anterior ha sido totalmente finalizada;
los criterios para completar una fase se conocen frecuentemente con el término
inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar
fases que ya se han completado. Esta falta de flexibilidad en un modelo de
cascada puro ha sido fuente de crítica de los defensores de modelos más
flexibles.
Modelo de espiral
La principal características del modelo en espiral es la gestión de riesgos
de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988
por
Barry
Boehm, combinando algunos aspectos clave de las metodologías del
modelo de cascada y del desarrollo rápido de
aplicaciones, pero dando énfasis en un área que para muchos no jugó
el papel que requiere en otros modelos: un análisis iterativo y concienzudo de
los riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a través de algunas
iteraciones con el diagrama de los cuatro cuadrantes representativos de las
siguientes actividades:
- crear
planes con el propósito de identificar los objetivos del software,seleccionados
para implementar el programa y clarificar las restricciones en el
desarrollo del software;
- Análisis
de riesgos: una evaluación analítica de programas seleccionados, para
evaluar como identificar y eliminar el riesgo;
- la
implementación del proyecto: implementación del desarrollo del software y
su pertinente verificación;
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las
condiciones de las opciones y limitaciones para facilitar la reutilización de
software, la calidad del software puede ayudar como una meta propia en la
integración en el desarrollo del producto. Sin embargo, el modelo en espiral
tiene algunas limitaciones, entre las que destacan:
- El
énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes
que acepten este análisis y actúen en consecuencia. Para ello es necesaria
confianza en los desarrolladores así como la predisposición a gastar más
para solventar los temas, por lo cual este modelo se utiliza
frecuentemente en desarrollo interno de software a gran escala.
- Si la
implementación del riesgo de análisis afectará de forma esencial los
beneficios del proyecto, no debería utilizarse este modelo.
- Los
desarrolladores de software han de buscar de forma explícita riesgos y
analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la búsqueda de un plan para conseguir los objetivos con
las limitaciones del proyecto para así buscar y eliminar todos los riesgos
potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo
la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el
cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante
ignorando los riesgos. Por último, se evalúan los resultados y se inicia el
diseño de la siguiente fase.
Desarrollo iterativo e incremental
El desarrollo iterativo recomienda la construcción de secciones reducidas de
software que irán ganando en tamaño para facilitar así la detección de
problemas de importancia antes de que sea demasiado tarde. Los procesos
iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes que
no saben cómo definir lo que quieren.
Desarrollo ágil
El desarrollo ágil de software utiliza un desarrollo iterativo como base
para abogar por un punto de vista más ligero y más centrado en las personas que
en el caso de las soluciones tradicionales. Los procesos ágiles utilizan
retroalimentación en lugar de planificación, como principal mecanismo de
control. La retroalimentación se canaliza por medio de pruebas periódicas y
frecuentes versiones del software.
Hay muchas variantes de los procesos ágiles:
- En el
caso de la programación extrema (XP), las fases se
realizan en pasos muy cortos (o "continuos") con respecto al
anterior. El primer paso (intencionalmente incompleto) por los pasos puede
ocurrir en un día o en una semana, en lugar de los meses o años de cada
paso completo en el modelo en cascada. En primer lugar, se crean pruebas
automatizadas para proveer metas concretas al desarrollo. Después se
programa el código, que será completo cuando todas las pruebas se superan
sin errores, y los desarrolladores ya no sabrían como mejorar el conjunto de
pruebas necesario. El diseño y la arquitectura emergen a partir de la refactorización del código, y se da después de
programar. El diseño lo realizan los propios desarrolladores del código.
El sistema, incompleto, pero funcional se despliega para su demostración a
los usuarios (al menos uno de los cuales pertenece al equipo de
desarrollo). Llegado este punto, los profesionales comienzan a escribir
las pruebas para la siguiente parte del sistema de más importancia.
Codificación y corrección
El desarrollo de codificación y corrección (en inglés "Code and
fix") es, más que una estrategia predeterminada, el resultado de una falta
de experiencia o presión que se ejerce sobre los desarrolladores para cumplir
con una fecha de entrega. Sin dedicar tiempo de forma explícita para el diseño, los programadores
comienzan de forma inmediata a producir código.
Antes o después comienza la fase de pruebas de software (a menudo
de forma tardía) y los inevitables errores
que se encuentran han de eliminarse antes de poder entregar el software.
