CENTRO DE ESTUDIOS DE POST-GRADOMAESTRÍA EN GERENCI INFORMÁTICA CON ÉNFASIS EN

SEGURIDAD COMPUTACIONAL

UNIVERSIDAD LATINA DE PANAMÁ

Integrantes:Laura Rosas

Emilio Batista David Ortega

Roberto Quiroz

Auditoria al Ciclo de Vida de Desarrollo de SistemasEl modelo en Cascada Tradicional y sus modificaciones

1

MODELOS DE CICLO DE VIDA

“Modelos de ciclo de vida del software”. El primer modelo concebido fue el de Royce, más comúnmente conocido como

Cascada o “Lineal Secuencial”.

Los modelos de ciclo de vida del software describen las fases del ciclo de software y el orden en que se ejecutan las fases.

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas

involucradas y los criterios de transición asociados entre estas etapas.

2

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software.

Define las fases primarias esperadas de ser ejecutadas durante esas fases.

Ayuda a administrar el progreso del desarrollo.

Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo de software.

En cada una de las etapas de un modelo de ciclo de vida, se puedenestablecer una serie de objetivos, tareas y actividades que lo caracterizan.Existen distintos modelos de ciclo de vida, y la elección de un modelo paraun determinado tipo de proyecto es realmente importante.

3

Modelo en Cascada

El modelo en cascada es un proceso de desarrollo secuencial,en el que el desarrollo se ve fluyendo hacia abajo (como unacascada) sobre las fases que componen el ciclo de vida.

Se cree que el modelo en cascada fue el primer modelo de procesointroducido y seguido ampliamente en la ingeniería el software

La primera descripción formal del modelo en cascada se cree que fueen un artículo publicado en 1970 por Winston W. Royce.

4

En el modelo original de Royce, existían las siguientes fases:

1. Especificación de requisitos

2. Diseño

3. Construcción (Implementación o codificación)

4. Integración

5. Pruebas

6. Instalación

7. Mantenimiento

5

Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma puramente secuencial

6

Ventajas

Es apropiado para proyectos estables (especialmente con requisitos nocambiantes) y donde es posible y probable que los diseñadores predigantotalmente áreas de problema del sistema y produzcan un diseño correcto antesde que empiece la implementación. Funciona bien para proyectos pequeñosdonde los requisitos están bien entendidos.

Es un modelo en el que todo está bien organizado y no se mezclan las fases. Essimple y fácil de usar.

Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tieneentregables específicos y un proceso de revisión. Las fases son procesadas ycompletadas de una vez.

7

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala

implementación del modelo, lo cual hace que lo lleve al fracaso.

Difícilmente un cliente va a establecer al principio todos los requisitos necesarios,por lo que provoca un gran atraso trabajando en este modelo, ya que este es muyrestrictivo y no permite movilizarse entre fases.

Los resultados y/o mejoras no son visibles progresivamente, el producto se vecuando ya está finalizado. Esto también implica el tener que tratar con requisitosque no se habían tomado en cuenta desde el principio, y que surgieron al momentode la implementación, lo cual provocará que haya que volver de nuevo a la fase derequisitos.

Inconvenientes

8

Variantes

Existen muchas variantes de este modelo. En respuesta a los problemaspercibidos con el modelo en cascada puro, se introdujeron muchosmodelos de cascada modificados. Estos modelos pueden solventaralgunas o todas las críticas del modelo en cascada puro.

De hecho muchos de los modelos utilizados tienen su base en el modeloen cascada.

Tipos de Ciclos de Vida en Cascada:

9

Modelo Sashimi

El modelo sashimi (El nombre “Sashimi'” deriva del modo del estilo de presentaciónde rodajas de pescado crudo en Japón.) fue creado originalmente por PeterDeGrace.

A veces se hace referencia a él como el modelo en cascada con fasessuperpuestas o el modelo en cascada con retroalimentación. Ya que las fases en elmodelo sashimi se superponen, lo que implica que se puede actuar durante lasetapas anteriores.

Por ejemplo, ya que las fases de diseño e implementación se superpondrán en elmodelo sashimi, los problemas de implementación se pueden descubrir durante lasfases de diseño e implementación del proceso de desarrollo. Esto ayuda a aliviarmuchos de los problemas asociadas con la filosofía del modelo en cascada.

10

11

Ciclo de Vida: Sashimi

Ventajas:

No requiere tanta documentación como el ciclo de vida de cascada ya quees continuo.

Su planificación es sencilla.

Desventajas:

Más difícil controlar el progreso del proyecto debido a que los finales defase ya no son un punto de referencia claro.

La dificultad de reconocer todos los requerimientos desde un inicio.

Dificultad para identificar el inicio y fin de cada etapa.

12

Ciclo Cascada con Subproyectos

Si una vez que se ha llegado al diseño arquitectónico, se compruebaque el sistema se divide en varios subsistemas independientes entresí, sería razonable suponer que a partir de ese punto cada uno sepuede desarrollar por separado y en consecuencia en paralelo conlos demás. Cada uno tendrá seguramente fechas de terminacióndistintas. Una vez que han terminado todos se integran y se pruebael sistema en su conjunto.

Requiere planeación.

Plantea Organización y planeación de un gran proyecto.

Se pueden realizar varias partes del proyecto al mismo tiempo por diferentes desarrolladores.

Adecuada para el desarrollo de proyectos complejos que estiman de 1 a 3 años de desarrollo.

13

14

Ciclo de Vida: Cascada Subproyectos

Ciclo de vida en cascada con reducción de riesgos

Uno de los problemas del ciclo de vida en cascada es que si se entienden mal los requisitos esto sólo se descubrirá cuando se entregue el producto.

Para evitar este problema se puede hacer un desarrollo iterativo durante las fases de análisis y diseño global. Esto consistiría en: Preguntar al usuario.Hacer el diseño global que se desprende del punto 1.Hacer un prototipo de interfaz de usuario, entrevistas con

los usuarios, etc y volver con ello al punto 1 para identificar más requisitos o corregir malentendidos.

15

Gracias

16