Modelo en Cascada

El método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo desistemas, se puede decir que es un método puro que implica un desarrollo rígido y lineal

El modelo consta de las siguientes etapas:

• Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios para los que va destinado el sistema. Se busca hacer esta definición lo más detallado posible. se definen los requisitos y requerimientos del sistema software a partir de consultas con los clientes y los usuarios del futuro sistema software.
• Diseño de software: Se establece la arquitectura total del sistema. Se identifican, se describen las abstracciones y relaciones de los componentes del sistema.
• Implementación: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.
• Integración y pruebas del sistema: Se integran todas las unidades.
• 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.

Este modelo puede ser visto como un modelo con forma de cascada de agua con varios saltos, en la que cadasalto representa cada una de las fases del ciclo de vida.

• Permite la departamentalización y control de gestión.
• El horario se establece con los plazos normalmente adecuados para cada etapa de desarrollo.
• Este proceso conduce a entregar el proyecto a tiempo.
• Es sencilla y facilita la gestión de proyectos.

• No conocer si la solución es correcta hasta estar cerca de su lanzamiento
• Poco tiempo para corregir fallas
• Cuando el cliente no especifica todos los requisitos de manera explicita, que el modelo requiere, el proyecto al inicio enfrenta dificultades al incorporar la incertidumbre natural.
• El cliente podría detectar un error
• El proceso es lento y pesado

INCONVENIENTES

• Los clientes quieren ver el producto a medida que se desarrolla, e incluso poder comprobar que es lo que esperan, sin esperar que pase por una secuencia de fases “opacas” de análisis, diseño e implementación.
• Los clientes pretenden que seamos flexibles a los cambios que ellos quieran o se vean obligados a introducir, y esto resulta muy complejo una vez que pasamos la fase de análisis del modelo de cascada.
• Al separar tanto las actividades en fases, cada especialista trabaja aislado de los demás. Como consecuencia, cuando los analistas terminan el análisis, dejan el proyecto y pasan a otro, entrando los diseñadores. Lo mismo pasa entre diseñadores y programadores, y entre programadores y testers. Por lo tanto, no hay un “equipo” de proyecto, que pueda hacer frente a cambios provenientes de nuevos requisitos o de fallas.

 

Este modelo es el más básico y de fácil comprensión para desarrolladores inexpertos y clientes, comprende cada una de las etapas esenciales del ciclo de vida del software además es  la guía para el desarrollo de otros modelos más flexibles

Este modelo aunque sea un recurso didáctico sigue siendo empleado en la actualidad como la base de proyectos importantes en la industria principalmente en software de control de plantas, controladores de tráfico aéreo, sistemas automotrices, principalmente en software donde conocemos detalladamente cada requisito y tenemos claro las especificaciones desde el principio.

El modelo en cascada  es útil para proyectos de menor tamaño o en pequeños módulos, donde los riesgos son mínimos  y si se han cometido errores en una etapa no cueste mucho tiempo y recursos corregirlos

Un gestor de ventas no sería adecuado para el modelo en cascada donde los requerimientos tienen un importante grado de volatilidad, donde se descubren  omisiones en los requerimientos originales del software en la etapa de pruebas, bien por que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas por tanto se necesita mayor comunicación con el cliente y los usuarios.

Modelo Incremental

Propuesto por Mills en 1980.

Sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema.

El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. Aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario.

Es decir, bajo este modelo se entrega software “por partes funcionales más pequeñas”, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.

VENTAJAS

• Los clientes no tienen que esperar hasta que el sistema se entregue completamente para comenzar a hacer uso de él.

• Los clientes pueden usar los incrementos iniciales como prototipo para precisarlos requerimientos posteriores del sistema.

• Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente.

• El resultado puede ser muy positivo.

DESVENTAJAS

• Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo.

• Riesgos largos y complejos.

• Pueden aumentar el coste debido a las pruebas.

• Los errores en los requisitos se detectan tarde.

Ejemplo:

1. Un procesador de texto que sea desarrollado bajo el paradigma Incremental podría aportar, en principio, funciones básicas de edición de archivos y producción de documentos (algo como un editor simple).
2. En un segundo incremento se le podría agregar edición más sofisticada, generación y mezcla de documentos.
3. En un tercer incremento podría considerarse el agregado de funciones de corrección ortográfica, esquemas de paginado y plantillas.
4. En un cuarto capacidades de dibujo propias y ecuaciones matemáticas.
5. Así sucesivamente hasta llegar al procesador final requerido. Así, el producto va creciendo, acercándose a su meta final, pero desde la entrega del primer incremento ya es útil y funcional para el cliente, el cual observa una respuesta rápida en cuanto a entrega temprana, sin notar que la fecha límite del proyecto puede no estar acotada ni tan definida, lo que da margen de operación y alivia presiones al equipo de desarrollo.

Modelo en Función de Prototipo

Los prototipos de Software son implementaciones realizadas con técnicas de programación del sistema interactivo propuesto que reproducen el funcionamiento de una parte importante de las funcionalidades con el objetivo de probar determinados aspectos del sistema final. Habitualmente se realizan con el lenguaje o la técnica de programación escogida para desarrollar la aplicación, aunque pueden utilizarse otras alternativas.

Este modelo no secuencial, basado en la construcción de simulaciones o modelos ejecutables de aplicaciones más extensos, persigue un objetivo principal: la participación directa del cliente en la construcción del software requerido. Las fases son similares a las del modelo en cascada: es necesario un análisis previo de los requisitos tanto del sistema como del cliente, se concibe la arquitectura del sistema y se realiza el diseño del software. Sin embargo, se incluye un elemento hasta ahora no utilizado, que consiste en el diseño rápido de un prototipo que se mostrará al cliente para que evalúe el trabajo realizado.

El prototipo es una versión reducida del programa completo; es una “fachada virtual” que mostramos al cliente (que carece de la posibilidad de ser utilizada de la forma en que lo haríamos con el software final. Tras recoger los requisitos tanto del cliente como del sistema, se comienza con el diseño rápido del prototipo; el diseño completo obedece al previo diseño de pequeños prototipos específicos para funciones individuales. Más tarde, estos diseños serán unidos en uno sólo.

Normalmente se implementa un prototipo software después de varias iteraciones de Prototipado-Evaluación y se tiene la intención de empezar a ver realmente cómo responde el sistema.

Ventajas de los prototipos software.

• Habitualmente, la fidelidad o semejanza de un prototipo software con el sistema final es alta.
• El usuario tiene la sensación de estar trabajando con un sistema real.

Inconvenientes de los prototipos software.

• Este método requiere habilidades de desarrollo de software, aunque cada vez en menos grado.
• Aunque rápido, el método consume mucho más tiempo que otros tipos de prototipos (de papel, por ejemplo).
• Se requieren mayores recursos debido a la necesidad de emplear software y hardware específicos.
• Debido a la mayor inversión en cuanto a habilidades y tiempo necesarios suele renunciarse a «tirar» un prototipo, quedando el mismo como una versión preliminar del sistema. Este factor, a la larga, resulta ser un lastre.
• Frecuentemente la última de las ventajas mencionadas se convierte en un grave inconveniente, pues los directivos responsables y los propios usuarios creen que el sistema está casi terminado y tendrán prisa por verlo finalizado.

Ejemplo:

1. Comunmente este modelo se usa para el diseño de sitios web primero se entrevista a un cliente y se especifica el giro de su negocio.
2. Se muestran diferentes plantillas, en base al gusto del cliente se trabaja sobre un boceto antes de empezar a proporcionar las divisiones del sitio.
3. Se diseña un mapa del sitio y se empieza a codificar.
4. El cliente da su punto de vista se corrigen posibles errores y se moldean los requisitos
5. Se validan los campos se hace una retroalimentacion con los usuarios y el cliente para afinar detalles

Para este caso se incluye al cliente como parte del grupo de trabajo y es menos probable que fracase el producto final, ademas en el proceso de desarrollo se pueden agregar funciones que no se tenian previstas sin invertir mucho tiempo en las modificaciones para tener un cliente satisfecho.

Referencias

[1] http://es.kioskea.net/contents/223-ciclo-de-vida-del-software

[2] http://www.infor.uva.es/~mlaguna/is1/apuntes/1-intro.pdf

[3] http://www.grihohcitools.udl.cat/mpiua/fases/tecnicasdeprototipado.html

[4]BIBLIOGRAFÍAPRESSMAN, Roger S. Ingeniería del software: un enfoque práctico. 6 ed. McGraw-hil