Paradigmas de Ciclo de Vida

1
Fundamentos de Ingeniería del Software

• Tema 6. El proceso software. Paradigmas de Ciclo
  de Vida.
• Paradigmas de Ciclo de Vida

Asignatura Fundamentos de Ingeniería del
Software Titulación Ingeniera Técnica de
Informática de Gestión Curso Académico
2004-2005 Curso 3º Cuatrimetres
Primero Créditos 6(33) Página Web
dis.um.es/lopezquesada Profesor Juan Antonio
López Quesada Departamento Informática y
Sistemas
2
Ciclo de vida

• Sucesión de etapas por las que atraviesa un
  producto software a lo largo de su existencia
  (i.e. durante su desarrollo y explotación).

3
Paradigma clásico

• Paradigma en cascada o paradigma orientado a
  fases
• Primer modelo empleado (1970).
• Ejecución secuencial de una serie de fases.
• Cada fase genera entradas y documentación para la
  siguiente.

4
Paradigma clásico ideal
5
Paradigma clásico
6
Paradigma clásico. Definición alternativa
7
Modelo en cascada. Fases

• Análisis del sistema.
• Qué debe hacer el sistema?
• El software suele formar parte de un sistema
  mayor
• Identificar los requisitos de todos los elementos
  del sistema.
• Asignar un subconjunto de dichos requisitos al
  software.

8
Modelo en cascada. Fases

• Análisis de los requisitos del software.
• El proceso de recopilación de los requisitos se
  centra especialmente en el software.
• Hay que especificar
• Funciones que el software debe realizar.
• Condicionantes existentes rendimiento,
  utilización de recursos, etc.

9
Modelo en cascada. Fases

• Análisis de los requisitos del software (II).
• Los requisitos del software se documentan y se
  revisan con el cliente.
• Se genera la especificación de requisitos del
  software.
• (SRS, Software Requirements Specification).

10
Modelo en cascada. Fases

• Diseño.
• Cómo se ha de construir el sistema?.
• Definir estructura del software para satisfacer
  los requisitos con la calidad necesaria
• Estructura de los datos.
• Arquitectura del software.
• Representaciones de interfaz.
• Determinar los algoritmos.

11
Modelo en cascada. Fases

• Generación de código.
• Se puede realizar de forma automática a partir de
  un diseño detallado.
• Prueba.
• Se ha construido el sistema que se deseaba?
• Prueba interna.
• Prueba externa.

12
Modelo en cascada. Fases

• Mantenimiento.
• El software sufrirá cambios después de que se
  entregue al cliente
• (errores, nuevas funciones, aumentos del
  rendimiento, etc.)
• Volver a aplicar cada una de las fases anteriores
  al programa existente.

13
Modelo clásico

• Críticas al modelo ideal
• Los proyectos reales raramente pueden seguir el
  flujo secuencial que se propone.
• Dificultad para establecer todos los
  requerimientos al principio del proceso.
• El mantenimiento recae sobre el código.

14
Modelo clásico

• Críticas al modelo ideal
• El usuario debe tener paciencia.
• Se tarda mucho tiempo en pasar por todo el ciclo
  (hasta que no termina una fase no empieza la
  siguiente).
• Retrasos innecesarios

15
Paradigma clásico (II)
16
Modelo clásico revisado (con realimentación
anidada)

• Críticas
• El desarrollo es bastante manual.
• Las diferentes fases del ciclo van soportadas, en
  el mejor de los casos, por un conjunto de
  herramientas software en su mayor parte no
  relacionadas ni integradas.
• Los errores de análisis y diseño son caros de
  eliminar, y se propagan a las otras etapas con un
  efecto conocido como bola de nieve.
• En la práctica, el modelo tiende a deformarse, y
  todo el peso de la validación y mantenimiento
  recae, en su mayor parte, sobre el código fuente.
• El software va deteriorándose y resulta cada vez
  más difícil de mantener.

17
Paradigma clásico deformado
18
Paradigma clásico con prototipado(prototipado
como realimentación en el ciclo básico)

• Prototipo
• Primera versión de un nuevo tipo de producto, en
  el que se han incorporado sólo algunas
  características del sistema final, o no se han
  realizado completamente.

19
Paradigma clásico con prototipado (II)

• Características de los prototipos
• Funcionalidad limitada.
• Poca fiabilidad.
• Características de operación pobres.
• Utilidad de los prototipos
• Ayuda al cliente a establecer claramente los
  requerimientos.
• Ayuda a los desarrolladores a
• Verificar corrección de la especificación.
• Aprender sobre problemas que se presentarán
  durante el diseño e implementación del sistema.
• Mejorar el producto.
• Examinar viabilidad y utildiad de la aplicación.

20
Paradigma clásico con prototipado
21
Modelo clásico con prototipado

• Aspectos básicos
• Tras el análisis, se construye el prototipo, que
  ayudará a refinar la especificación de
  requerimientos.
• El desarrollo posterior prosigue en cascada.

22
Modelo clásico con prototipado

• Críticas
• Elimina el efecto bola de nieve pero no el
  mantenimiento sobre el código.
• El cliente ve en funcionamiento una versión
  preliminar, sin asumir que no es robusta ni
  completa.
• Inversión en un producto desechable puede no ser
  rentable.
• Es frecuente arrastrar malas decisiones (de
  diseño, de planificación ...) que sólo eran
  apropiadas para la obtención rápida del
  prototipo.
• El tiempo invertido en la construcción del
  prototipo puede hacer que el producto pierda
  oportunidad.

23
Programación automática (Balzer, 1.983)

• Objetivo Introducir automatización en el proceso
  de desarrollo del software.
• Idea base programación por transformaciones
• Construcción de una primera versión que expresa
  formalmente el comportamiento deseado.
• Transformación en una versión más eficiente,
  preservando la funcionalidad.
• Adaptamos esta idea para hablar, no ya de dos
  versiones, sino de la conversión automática de
  una especificación en un prototipo, y luego en el
  producto definitivo.

24
Prototipado automático
25
Paradigma automático

• Aspectos básicos
• Se utilizan lenguajes de especificación formal.
• El prototipo es la propia especificación (o se
  deriva automáticamente de ella).
• Los requerimientos se perfilan animando la
  especificación.
• La validación y el mantenimiento recaen sobre la
  especificación.
• El mantenimiento consiste en revisar y reemplazar
  la especificación, y rederivar el prototipo.
• El producto final se obtiene a través de un
  proceso mecánico de transformación.

26
Paradigma automático (II)

• Críticas
• Compromiso entre las ventajas obtenidas y el
  nivel al que debe elevarse la especificación.
• La tecnología necesaria para cubrir todo el ciclo
  de vida aún no está a punto.

27
Modelo incremental

• Cada secuencia produce un incremento del
  software.
• Con cada incremento, se entrega un producto
  operacional

28
Modelo en espiral (Boehm 88)

• Más realista que el ciclo de vida clásico
• Relativamente poco probado

29
Modelo de ensamblaje de componentes
Ligado a la OO
Promueve reutilización del software.
? t. desarrollo, costes??
30
Ciclo de vida OO

• Hincapié en la reutilización.
• Notación uniforme en todas las fases de
  desarrollo.

31
Ciclo de vida OO Modelo cluster (agrupamiento)

• Cluster conjunto de clases relacionadas con
  objetivo común
• Cada subciclo de vida Especificación, Diseño y
  Realización, Validación y Generalización

32
Ciclo de vida OOBooch 94 (Macroproceso)
Establecer requisitos básicos (conceptualización)
Desarrollar un modelo del comportamiento deseado
(análisis)
(Prototipo desechable)
Crear una arquitectura (diseño)
Gestionar la evolución tras la entrega
(mantenimiento)
Desplegar la implementación (evolución)
33
Ciclo de vida OOBooch 94 (Microproceso)