El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería [8]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.
2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.
3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.
5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.
La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario.
Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.
Figura 5: Modelo de desarrollo en cascada.
En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son:
· Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.
· Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.
· Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.
· Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.
· Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.
Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.
Características del modelo:
Primer modelo empleado (Royce, 1970), también denominado ciclo de vida clásico
y modelo lineal secuencial.
Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que
da nombre al modelo.
Cada fase genera documentación para la siguiente. Esta documentación debe ser
aprobada.
Una fase no comienza hasta que la anterior ha terminado.
Requiere disponer de unos requisitos completos y precisos al principio del
desarrollo.
Presenta una serie de ventajas:
Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es
mejor que ninguno.
Facilita la gestión del desarrollo.
Así como una serie de inconvenientes:
En general, establecer todos los requisitos al principio del proceso de desarrollo es
un mito inalcanzable: Los usuarios no pueden imaginarse lo que quieren hasta que
no ven un sistema funcionando.
Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado
cambia, todo cambia.
El usuario debe esperar mucho tiempo hasta ver los resultados: Se tarda mucho
tiempo en pasar por todo el ciclo (hasta que no termina una fase no empieza la
siguiente) y el sistema en funcionamiento no estará disponible hasta el final del
proceso, eso sí, será el sistema completo.
Los errores de análisis y diseño son costosos de eliminar, y se propagan a las
fases siguientes con un efecto conocido como bola de nieve.
Se genera mucho mantenimiento inicial debido al período de congelación de
requisitos y éste recae, en su mayor parte, sobre el código fuente, que en
consecuencia se va deteriorando y resultando cada vez más difícil de mantener.
Las características del proyecto que hacen adecuado el uso de este modelo son
que:
Se disponga de unos requisitos completos y consistentes al principio del
desarrollo.
Sea un proyectos pequeño, en el que el período de congelación de los requisitos
es corto, o un proyecto con unos requisitos bastante estables.
Primer modelo empleado (Royce, 1970), también denominado ciclo de vida clásico
y modelo lineal secuencial.
Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que
da nombre al modelo.
Cada fase genera documentación para la siguiente. Esta documentación debe ser
aprobada.
Una fase no comienza hasta que la anterior ha terminado.
Requiere disponer de unos requisitos completos y precisos al principio del
desarrollo.
Presenta una serie de ventajas:
Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es
mejor que ninguno.
Facilita la gestión del desarrollo.
Así como una serie de inconvenientes:
En general, establecer todos los requisitos al principio del proceso de desarrollo es
un mito inalcanzable: Los usuarios no pueden imaginarse lo que quieren hasta que
no ven un sistema funcionando.
Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado
cambia, todo cambia.
El usuario debe esperar mucho tiempo hasta ver los resultados: Se tarda mucho
tiempo en pasar por todo el ciclo (hasta que no termina una fase no empieza la
siguiente) y el sistema en funcionamiento no estará disponible hasta el final del
proceso, eso sí, será el sistema completo.
Los errores de análisis y diseño son costosos de eliminar, y se propagan a las
fases siguientes con un efecto conocido como bola de nieve.
Se genera mucho mantenimiento inicial debido al período de congelación de
requisitos y éste recae, en su mayor parte, sobre el código fuente, que en
consecuencia se va deteriorando y resultando cada vez más difícil de mantener.
Las características del proyecto que hacen adecuado el uso de este modelo son
que:
Se disponga de unos requisitos completos y consistentes al principio del
desarrollo.
Sea un proyectos pequeño, en el que el período de congelación de los requisitos
es corto, o un proyecto con unos requisitos bastante estables.
No hay comentarios:
Publicar un comentario