Ciclo de vida tipo sashimi

 Ciclo de vida tipo sashimi

La estructura de este ciclo es muy similar al ciclo en cascada que como
vimos anteriormente este se caracteriza que una nueva fase solo puede empezar cuando ha
terminado la anterior. En este caso sin embargo, se permite un solapamiento
entre fases, es decir, que por cada fase se puede interrumpir la misma para
corregir o arreglar algo en ese momento, sin necesidad de terminarla o sin
finalizar todo el diseño del ciclo ya se puede comenzar la etapa implementación.
El nombre ``sashimi'' deriva de una comida oriental que viene representado en
rodajas de pescado crudo en Japón.

Representación grafica del ciclo de vida tipo sashimi









Ventajas
-La ganancia de calidad en lo
que respecta al producto final, la falta de necesidad de una documentación
detallada (el ahorro proviene por el soplado de las etapas).
-Otra ventaja de este modelo es
que no necesita generar tanta documentación como el ciclo de vida en cascada
debido a la continuidad del mismo personal entre fases.

Desventajas
-También se refieren al
soplamiento de las etapas: es muy difícil gestionar el comienzo y fin de cada
etapa y los problemas de la comunicación, si aparecen, generan inconsistencias
en el proyecto.
-Más difícil controlar el
progreso del proyecto debido a que los finales de fase ya no son un punto de
referencia claro.
-Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir inconsistencias.

Ciclo de vida en V

Ciclo de vida en V

            El modelo de ciclo en V es una variación más del modelo original de cascada en donde se muestran las relaciones de  las fases de prueba con el análisis y diseño, y en donde la codificación es el vértice de la V con el análisis y diseño a la izquierda y pruebas y mantenimiento a la derecha.

            Fue propuesto por Alan Davis con el propósito de mejorar el ciclo en cascada, para ello considero cada fase con su nivel abstracto, es decir una fase además de utilizarse como entrada a la siguiente nos sirve para validar o verificar la información de las otras fases.

Ventajas:

·       Es un modelo sencillo y de fácil aprendizaje.

·       Involucra al usuario en las pruebas

·       La relación que se lleva entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos

Desventajas:

·       Es difícil que el cliente nos exponga todos los requisitos

·       El producto resultante no estará listo sino es hasta el término del proceso del este ciclo.

·       Pruebas caras y, a veces, no lo suficientemente efectivas.

·       El producto final obtenido puede que no refleje todos los requisitos del usuario

Ciclo d en espiral

Ciclo de vida en espiral

            El ciclo en espiral es un poco más complejo que los demás ciclos, lo propuso Boehm en el año de 1988 y consiste en una serie de ciclos consecutivos en donde cada uno tiene exactamente las mismas fases, cuando termina un ciclo ya se tiene un prototipo que se va ampliando conforme a cada ciclo, de esta forma el producto resultante tiene una calidad muy alta y es un ciclo donde se tiene muy en cuenta el concepto de riesgo en el producto final, es por esta razón que este ciclo es muy utilizado en software que no permiten errores

Ventajas

·       El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).

·       El producto resultante es de muy alta calidad y muy seguro.

·       Su orientación a prevenir el riesgo evita muchas dificultades

·       El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

Desventajas

·       Es difícil evaluar los riesgos.

·       Las etapas y sus entradas y salidas no están muy bien definidas.

·       Necesita de la participación continua por parte del cliente.

·       Es complicado y consume muchos recursos.

Tipos de proyectos en los que se utiliza

·       Sistemas de gran tamaño.

·       Proyectos donde sea importante el factor riesgo o donde sea muy importante este factor como por ejemplo aplicaciones de gobiernos para seguridad o en proyectos militares de gran tamaño.

·       Cuando no sea posible definir al principio todos los requisitos.