Ciclos De Vida En Ingeniería De Software

Lineal Secuencial (Cascada)

Es un modelo clásico, modelo tradicional o modelo lineal secuencial. Él método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas. Está es una secuencia de actividades(o etapas) que consisten en el análisis de requerimientos, diseño, implementación, la integración y las pruebas.

Es caracterizado por ordenar de manera rigurosa las etapas del ciclo de vida de software, dado que el comienzo de cada etapa debe esperar a la finalización de la inmediata anterior.  Y debido a que el proceso está planeado es más fácil determinar costos y los plazos. Esté modelo puede ser visto como un modelo con forma de cascada de agua con varios saltos, en la que cada salto representa cada una de las fases del ciclo de vida.

Ventajas:

1.    Permite la departamentalización y control de gestión.

2.    El horario se establece con los plazos normalmente adecuados para cada etapa de desarrollo.

3.    Este proceso conduce a entregar el proyecto a tiempo.

4.    Es sencilla y facilita la gestión de proyectos.

5.    Permite tener bajo control el proyecto.

6.    Limita la cantidad de interacción entre equipos que se produce durante el desarrollo.

Desventajas:

1.    No refleja realmente el proceso de desarrollo del software. Ya que la mayoría de los que desarrollan proyectos no cumple con este lineamiento.

2.    Se tarda mucho tiempo en pasar por todo el ciclo

3.    La aplicación de la metodología en cascada se orienta mejor al desarrollo de proyectos de corto plazo, de poca innovación y proyectos definitivos y detallados.

4.    Metodología pueden confundir al equipo profesional en las etapas tempranas del   proyecto.

5.    No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos.

Modelo En V

El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. La letra V en este ciclo de vida significa Verificación y Validación.

El lado izquierdo de la V representa la descomposición de las necesidades y creación de las especificaciones del sistema.

El modelo en V es muy similar al modelo en cascada clásico ya que es muy rígido y contiene gran cantidad de iteraciones.

 

Ventajas:

1.    La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
2.    Es un modelo sencillo y de fácil aprendizaje
3.    Hace explícito parte de la iteración y trabajo que hay que revisar
4.    Especifica bien los roles de los distintos tipos de pruebas a realizar
5.    Involucra al usuario en las pruebas

Desventajas:

1.    Es difícil que el cliente exponga explícitamente todos los requisitos
2.    El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
3.    Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
4.    El producto final obtenido puede que no refleje todos los requisitos del usuario

Construcción de Prototipos

El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo.

El paradigma de construcción de prototipos tiene tres pasos:

• Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las áreas donde es obligatorio más definición.
• Construir y revisar la maqueta (prototipo).
• El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software.

Etapas para la elaboración del Modelo de Prototipo.

Ventajas:

 

1.    Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

2.    Ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

Desventajas:

1.    Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional.

2.    Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que esté escrito en un lenguaje de programación inadecuado.

3.    El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido y puede desilusionarse al decirle que el sistema aún no ha sido construido.

4.    El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

DRA (Desarrollo Rapido de Aplicaciones)

Es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. Es una adaptación de «alta velocidad» del modelo de cascada. El proceso de DRA permite que un equipo de desarrollo cree un sistema completamente funcional dentro de un periodo muy corto de 60 a 90 días.

DRA es una adaptación de»Alta velocidad» en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema completamente funcional» dentro de periodos cortos de tiempo.

DRA enfatiza el desarrollo de componentes de programas reutilizables. Esto permite que los proyectos se desarrollen con mayor velocidad, debido a que estos componentes ya fueron probados en proyectos anteriores.

Ventajas:

1.    Si se entiende bien los requisitos y se limita el ámbito del proyecto, va a permitir que un equipo de desarrollo cree un sistema totalmente funcional dentro de un periodo de tiempo muy corto.
2.    Es ideal para una aplicación de negocios que se puede modular en forma que cada gran función pueda completarse en menos de tres meses

Desventajas:

1.    Si los requisitos y las tareas no son claras, las divisiones de las mismas dificultaría el trabajo en paralelo provocando una demora en dicho proceso.
2.    Si el proyecto es grande, se necesita suficientes recursos humanos para poder crear el número correcto de equipos DRA.
3.    Sería inapropiado cuando los riesgos técnicos son altos.

Modelo Evolutivo (Incremental)

En este modelo se desarrolla el sistema para satisfacer un subconjunto de requisitos especificados y en posteriores versiones se incrementa el sistema con nuevas funcionalidades que satisfagan más requisitos.

Ventajas:

1.   Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
2.   Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
3.   Si un error importante es realizado, sólo la última iteración necesita ser descartada y utilizar el incremento previo.

Desventajas:

1.    Se presupone que todos los requisitos se han definido al inicio.
2.    Se requiere de una experiencia importante para definir los incrementos de forma de distribuir en ellos las tareas en forma proporcional.
3.    Si el sistema a desarrollar es de gran magnitud y se cuenta con un único grupo para construirlo se corre el riesgo que el desarrollo se prolongue demasiado en tiempo.

Modelo Evolutivo (Espiral)

Es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro.

Ventajas:

1.   No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.
2.   En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.
3.  Sufrir retrasos corre un riesgo menor, por que se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.

Desventajas:

1.    Existe complicación cuando se evalúa los riesgos.
2.    Se requiere la participación continua por parte del cliente.
3.    Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software.