El documento describe el ciclo de vida del software, presentando diferentes modelos y enfoques como el modelo tradicional, incremental y espiral, así como el proceso desde la definición de requisitos hasta el mantenimiento. Destaca la importancia de la comunicación entre analistas y usuarios, así como los desafíos inherentes a cada modelo, como la gestión de riesgos y la integración de requisitos. Además, menciona la relevancia de la reutilización y la síntesis automática de software en el desarrollo.

1. CICLO DE VIDA DEL
SOFTWARE.

2. INTRODUCCIÓN
 “Una aproximación lógica a la adquisición, el suministro, el
desarrollo, la explotación y el mantenimiento del software”
IEEE 1074
 “Un marco de referencia que contiene los procesos, las
actividades y las tareas involucradas en el desarrollo, la
explotación y el mantenimiento de un producto de software,
abarcando la vida del sistema desde la definición de los
requisitos hasta la finalización de su uso”
ISO 12207-1

3. PROCESOS DEL CICLO DE VIDA SOFTWARE

4. FABREGAS:
1- Requerimientos
2- Análisis/Diseño
3- Construcción
4- Pruebas
5- Producción/Mantenimiento
SENN:
1- Investigación Preliminar
2- Determ. de Requerimientos.
3- Diseño del Sistema
4- Desarrollo del Software
5- Prueba del Sistema
6- Implantación y Evaluación
PRESSMAN:
1- Análisis
2- Diseño
3- Codificación
4- Prueba
5- Mantenimiento
EN GENERAL USAREMOS:
1- Análisis
2- Diseño
3- Implementación
4- Mantenimiento
EL CICLO DE VIDA SEGÚN BIBLIOGRAFÍA

5. CICLO DE VIDA TRADICIONAL

6. • Implantación Ascendente
• Las fases deben sucederse de manera Secuencial
• El usuario no ve resultados, sino hasta el final
• El usuario o el ambiente pueden cambiar las
especificaciones originales del sistema.
• Presenta numerosos problemas Analista-Usuario
• Manejable como proyecto
CARACTERISTICAS DEL CICLO DE VIDA
CLASICO

7. EL USUARIO:
FASE 1
FASE 2
FASE 3
FASE N
FASE N + 1
EL CICLO TRADICIONAL DE LOS S.I.

8. Su
sistema
definitivo
?
El usuario
y
su
Sistema
Definitivo.
Su
sistema
definitivo
Y AL FINAL DEL CICLO DE
DESARROLLO DEL SISTEMA.....

9. Su
sistema
definitivo
Esto no es lo
que yo
esperaba...
Y AL FINAL DEL CICLO DE DESARROLLO
DEL SISTEMA.....

10. Su
sistema
definitivo
Y al final del ciclo de Desarrollo del
sistema.....
¿ Será que no supe
explicarles mis
requerimientos ?
Su
sistema
definitivo
Y AL FINAL DEL CICLO DE DESARROLLO
DEL SISTEMA.....

11. Su
sistema
definitivo
Y al final del ciclo de Desarrollo del
sistema.....
Tal vez ellos
no me
entendieron...
Su
sistema
definitivo
Y AL FINAL DEL CICLO DE DESARROLLO DEL
SISTEMA.....

12. Su
sistema
definitivo
?
Y al final del ciclo de Desarrollo del
sistema.....
Su
sistema
definitivo
Y AL FINAL DEL CICLO DE DESARROLLO
DEL SISTEMA.....

13. No siempre se definen los requerimientos
en forma:
Completa
Correcta y
Consistente
Los requerimientos
son:
LA EXPERIENCIA DEMUESTRA QUE

14. Sr. Usuario:
Tiene que leerse
esto, esto, esto...
A veces resulta difícil para
el usuario, revisar todas las
especificaciones
Especificaciones
detalladas de
requerimientos
TOMO 1
TOMO
2
Analista
EL MODELAJE DE REQUERIMIENTOS

15. Sistemas II.
ANALISIS
IMPLEMENTACION
DISEÑO
MANTENIMIENTO
CICLO DE VIDA TRADICIONAL
LOS SISTEMAS DE INFORMACIÓN

16. Sistemas II.
1. ANALISIS:
1.1. Estudio Preliminar
1.2. Levantamiento de Información
1.3. Definición del Problema
1.4. Elaboración del Modelo Funcional del Sistema actual
1.5. Determinación de Requerimientos
1.6. Descripción y Evaluación de Alternativas
1.7. Aprobación de alternativas
CICLO DE VIDA

17. Sistemas II.
2.DISEÑO
2.1. Elaborar Modelo Funcional del Sistema
Propuesto
2.2. Diseño Lógico
2.3. Elaboración y Presentación del prototipo del
Sistema
2.4. Aprobación del Sistema Propuesto
CICLO DE VIDA

18. Sistemas II.
3. IMPLEMENTACION
3.1. Desarrollo del Software
3.2. Prueba del Sistema
3.3. Puesta en Marcha
¿ Qué significa poner en
Marcha un Sistema ?
CICLO DE VIDA

19. Sistemas II.
PUESTA EN MARCHA:
Actividad de traslado de una aplicación probada a un ambiente de
producción
- Acondicionamiento de locales
- Organización del Cliente
- Entregar aplicación probada
- Elaborar datos en Vivo
- Adiestramiento
- Carga de datos en vivo
- Entrega de documentación
- Asignar Responsabilidades
- Determinar FIN de la instalación
CICLO DE VIDA

20. MODELOS DEL CICLO DE
VIDA

21. MODELO CASCADA
Este, aunque es más comúnmente conocido
como modelo en cascada es también llamado
«modelo clásico», «modelo tradicional» o
«modelo lineal secuencial».

22. MODELO CASCADA
 CRITICAS
 No refleja realmente el proceso de desarrollo del software
 Se tarda mucho tiempo en pasar por todo el ciclo
 Perpetua el fracaso de la industria del software en su
comunicación con el usuario final
 El mantenimiento se realiza en el código fuente
 Las revisiones de proyectos de gran complejidad son muy
difíciles
 Impone una estructura de gestión de proyectos

23. MODELO INCREMENTAL
Los procesos iterativos pueden ayudar a
desvelar metas del diseño en el caso de
clientes que no saben cómo definir lo que
quieren.

24. MODELO INCREMENTAL
 Observaciones:
 Se evitan proyectos largos y se entrega “Algo de valor” a los
usuarios con cierta frecuencia
 El usuario se involucra más
 Difícil de evaluar el coste total
 Difícil de aplicar a sistemas transaccionales que tienden a ser
integrados y a operar como un todo
 Requiere gestores experimentados
 Los errores en los requisitos se detectan tarde.
 El resultado puede ser muy positivo.

25. MODELO DE PROTOTIPO
 Consiste en iterar en la fase de análisis tantas veces
como sea necesario, mostrando prototipos al usuario
para que pueda indicarnos de forma mas eficiente los
requisitos del sistema.

26. MODELO DE PROTOTIPO
 Observaciones:
 No modifica el flujo del ciclo de vida
 Reduce el riesgo de construir productos que no satisfagan las
necesidades de los usuarios
 Reduce costos y aumenta la probabilidad de éxito
 Exige disponer de las herramientas adecuadas
 No presenta calidad ni robustez
 Una vez identificados todos los requisitos mediante el prototipo, se
construye el producto de ingeniería.

27. MODELO DE PROTOTIPO
 PARA QUE SEA EFECTIVO:
 Debe ser un sistema con el que se pueda experimentar
 Debe ser comparativamente barato (< 10%)
 Debe desarrollarse rápidamente
 Énfasis en la interfaz de usuario
 Equipo de desarrollo reducido
 Herramientas y lenguajes adecuados
“El prototipado es un medio excelente para
recoger el ‘feedback’ (realimentación) del
usuario final”

28. MODELO DE PROTOTIPO
 PELIGROS DEL PROTOTIPO
 El cliente ve funcionando lo que para él es la primera versión del
prototipo que ha sido construido con “plastilina y alambres”, y
puede desilusionarse al decirle que el sistema aun no ha sido
construido.
 El desarrollador puede caer en la tentación de ampliar el prototipo
para construir el sistema final sin tener en cuenta los
compromisos de calidad y de mantenimiento que tiene con el
cliente.

29. MODELO ESPIRAL
 Proporciona potencial para desarrollo rápido de
versiones incrementales. En el modelo Espiral el
software se construye en una serie de versiones
incrementales. En las primeras iteraciones la versión
incremental podría ser un modelo en papel o bien un
prototipo.

30. MODELO ESPIRAL
En cada vuelta o iteración hay que tener en cuenta:
 Los Objetivos: qué necesidad debe cubrir el producto.
 Alternativas: las diferentes formas de conseguir los
objetivos de forma exitosa, desde diferentes puntos de
vista como pueden ser:
 Características: experiencia del personal, requisitos a
cumplir, etc.
 Formas de gestión del sistema.
 Riesgo asumido con cada alternativa.
 Desarrollar y Verificar: Programar y probar el
software.

31. MODELO ESPIRAL
 Observaciones
 Trata de mejorar los ciclos de vida clásicos y prototipos.
 Permite acomodar otros modelos
 Incorpora objetivos de calidad y gestión de riesgos
 Elimina errores y alternativas no atractivas al comienzo
 Permite iteraciones, vuelta atrás y finalizaciones rápidas
 Cada ciclo empieza identificando:
 Los objetivos de la porción correspondiente
 Las alternativas
 Restricciones
 Cada ciclo se completa con una revisión que incluye todo el ciclo
anterior y el plan para el siguiente.

32. DIFERENCIAS ENTRE MODELO EN ESPIRAL Y MODELOS
TRADICIONALES
 Reconocimiento explícito de las diferentes alternativas.
 Identificación de riesgos para cada alternativa desde el comienzo.
 Al dividir el proyecto en ciclos, al final de cada uno existe un
acuerdo para los cambios que hay que realizar en el sistema.
 El modelo se adapta a cualquier tipo de actividad adicional.

33. LA REUTILIZACIÓN EN EL CICLO DE VIDA

34. LA REUTILIZACIÓN EN EL CICLO
DE VIDA
 Principios
 Existen similitudes entre distintos sistemas de un mismo
dominio de aplicación
 El software puede representarse como una combinación de
módulos
 Diseñar aplicaciones = especificar módulos + interrelaciones
 Los sistemas nuevos se pueden caracterizar por diferencias
respecto a los antiguos
 Reduce tiempos y costes de desarrollo
 Aumenta la fiabilidad
 Dificultad para reconocer los componentes potencialmente
reutilizables
 Dificultad de catalogación y recuperación
 Problemas de motivación


35. SÍNTESIS AUTOMÁTICA DE SOFTWARE

36. SÍNTESIS AUTOMÁTICA DE
SOFTWARE
 Se define el sistema utilizando un lenguaje formal.
 La implementación es automática, asistida por el ordenador.
 La documentación se genera de forma automática.
 El mantenimiento se realiza “por sustitución” no
mediante “parches”.
 Dificultad en la participación del usuario.
 Diseños poco optimizados.