Falla de san andres y el gran cañon : enfoque integral
Modelos del ciclo de vida del software
1.
2.
3. Porque se les llama prescriptivos:
Porque prescriben un conjunto de elementos de proceso:
actividades del marco de trabajo,
acciones de ingeniería del software,
tareas,
productos del trabajo,
aseguramiento de calidad y
mecanismos de control de cambio para cada proyecto.
También prescribe un flujo de trabajo
4. Cualquier organización de Ingeniería del software debe
describir un conjunto único de actividades dentro del
marco de trabajo.
6. CUANDO SE UTILIZA:
Existen ocasiones en que los requisitos de un problema
se entienden de manera razonable: cuando el trabajo
fluye desde la comunicación a través del despliegue de
una manera casi lineal. Ejemplo: adaptaciones o
mejoras a un sistema de contabilidad existente debido
a los cambios en las regulaciones del Gobierno.
En un número limitado de proyectos de nuevos
desarrollos, cuando los requerimientos están bien
definidos y son estables de forma razonable.
7. MODELO EN CASCADA
Algunas veces llamado “Ciclo de vida clásico” sugiere:
Un enfoque sistemático secuencial hacia el desarrollo
del software.
Es el paradigma mas antiguo para la ingeniería del
software.
8. MODELO EN CASCADA
Comunicación
Inicio del proyecto
Recopilación de
requisitos
Planeación
Estimación
Itinerario
Seguimiento
Modelado
Análisis
Diseño
Despliegue
Entrada
Soporte
retroalimentación
Construcción
Código
Prueba
9. MODELO EN CASCADA
Problemas al aplicar el modelo:
Es muy raro que los proyectos reales sigan el flujo
secuencial que propone el modelo.
Es difícil para el cliente establecer los requisitos de
manera explicita. El modelo en cascada lo requiere.
El cliente debe tener paciencia. Debe esperar que el
proyecto esté bien avanzado para poder probar una
versión que funcione del programa.
10. MODELO EN CASCADA
Resultados de aplicar el modelo
Los cambios confunden mientras el equipo del
proyecto actúa.
Incorporan la incertidumbre natural.
Un error grave será desastroso si no se detecta
antes de la revisión del programa.
11. MODELO EN CASCADA
Conclusión de análisis a un proyecto real.
Conduce a estados de bloqueo
El estado de bloqueo tiende a ser mas común al
principio y al final del proceso
Puede servir como modelo en situaciones donde los
requerimientos están fijos, y donde el trabajo se
realiza hasta su conclusión de una manera lineal.
13. En muchas situaciones los requisitos iniciales del
Software están bien definidos en forma razonable,
pero el enfoque global excluye un proceso
puramente lineal.
Quizá haya necesidad de proporcionar un conjunto
limitado de funcionalidad para el usuario y después
refinarla y expandirla en las entregas posteriores
del Software.
14. MODELO INCREMENTAL
Se da cuando:
Los requisitos iniciales del software están bien definidos en forma razonable.
Hay una necesidad imperiosa de proporcionar un conjunto de funcionalidad al
usuario y después refinarla y expandirla.
A menudo, al utilizar un modelo incremental el primer incremento es un
producto esencial
15. MODELO INCREMENTAL
Características:
Este modelo combina elementos del modelo en cascada
aplicada en forma iterativa.
Aplica secuencias lineales de manera escalonada
conforme avanza el tiempo en el calendario.
Cada secuencia lineal produce incrementos de software
16. MODELO INCREMENTAL
Ejemplo de un software procesador de texto:
Primer incremento:
Realiza funciones básicas de administración de archivos, edición y
producción de documentos
Segundo incremento:
Ediciones mas sofisticadas y tendría funciones mas complejas de
producción de documentos.
Tercer incremento:
Funciones de corrección ortográfica y gramatical
Cuarto incremento:
Capacidades avanzadas de configuración de pagina.
17. MODELO INCREMENTAL
En este modelo el primer incremento es un productos esencial.
Es iterativo por naturaleza.
Se enfoca en la entrega de un productos funcional con cada
incremento.
Es útil cuando el personal necesario para una implementación
completa no esta disponible.
Los primeros incrementos se pueden implementar con menos gente.
18. MODELO INCREMENTAL
Análisis Diseño Código Prueba
Análisis Diseño Código Prueba
Análisis Diseño Código Prueba
Entrega de primer
incremento
Entrega de
segundo
incremento
Entrega de
tercer
incremento
Tiempo calendario
20. Desarrollo Rápido de Aplicaciones
(DRA)
Objetivo: Desarrollo de sistemas en poco tiempo
Adaptación a “alta velocidad” del modelo en cascada.
Equipos trabajando en paralelo
Aplicando tecnología de componentes
Del inglés Rapid Application Development (RAD)
21. Fases del Módelo DRA
Comunicación
Planificación
Modelado
•Gestión
•Datos
•Proceso
Construcción
• Reutilización de
componentes
• Creación de nuevos
componentes
• Pruebas
Modelado
•Gestión
•Datos
•Proceso
Construcción
• Reutilización de
componentes
• Creación de nuevos
componentes
• Pruebas
Equipo 1
Equipo n
Despliegue
•Pruebas
•Entrega
•Retroalimentación
60 – 90 días
22. Ventajas y Desventajas del DRA
Ventajas
Rapidez(Enfatiza ciclos de desarrollo extremadamente cortos)
Válido para aplicaciones modularizables
Reutilización
Desventajas
Exige conocer bien los requisitos y delimitar el ámbito del
proyecto
Número de personas
Clientes y desarrolladores comprometidos
Gestión riesgos técnicos altos
○ Uso de nueva tecnología
○ Alto grado de interoperabilidad con sistemas existentes
○ Cuando los riesgo son altos DRA no es apropiado
24. - Los modelos evolutivos son iterativos, los caracteriza la
forma en que permiten que los ingenieros de software
desarrollen versiones cada vez más completas del
Software.
- Las estrictas fechas tope del mercado imposibilitan la
conclusión de un producto completo, por lo que se
debe presentar una versión limitada para liberar la
presión competitiva y de negocios.
25. 1. CONSTRUCCIÓN DE PROTOTIPOS
A menudo un cliente define un conjunto de objetivos
generales para el software pero no identifica los requisitos
detallados de entrada, procesamiento o salida.
26. Desventajas
El cliente ve lo que parece una versión en
funcionamiento del software, sin saber que el
prototipo está unido con chicle, que por la prisa
de hacerlo funcionar no se ha considerado la
calidad del software.
Cuando se informa que el producto debe
construirse otra vez para mantener los altos
niveles de calidad, el cliente no lo entiende, es
frecuente que la gestión sea muy lenta.
A menudo, el desarrollador establece
compromisos de implementación para lograr que
el prototipo funcione con rapidez. Tal vez se
utilice un sistema operativo o lenguaje de
programación inadecuado solo porque está
disponible y es conocido.
28. 2. MODELO EN ESPIRAL
Historia
El creador del modelo en espiral fue Barry Boehm
Sirvió dentro del departamento de ESTADOS UNIDOS de la
defensa (DoD) como director de la oficina de las ciencias y de
la tecnología de la información de DARPA
Sus contribuciones al campo incluyen el modelo constructivo
del coste (COCOMO), el modelo espiral del proceso del
software propuesto originalmente por BOEHM en 1976
29.
30. Cuando se aplica el modelo en espiral, el software se
desarrolla en una serie de entregas evolutivas. Durante
las primeras iteraciones, la entrega tal vez sea un
documento del modelo o un prototipo. Durante las
últimas iteraciones se producen versiones cada vez más
complejas del sistema desarrollado.
31. A diferencia de otros modelos de proceso que
terminan cuando se entrega el software, el modelo
en espiral puede adaptarse y aplicarse a lo largo de
la vida del Software de computadora.
El modelo en espiral es un enfoque realista para el
desarrollo de software y de sistemas a gran escala.
Es difícil convencer a los clientes de que el enfoque
evolutivo es controlable.
32. A medida que el software evoluciona, el desarrollador
y el cliente comprenden y reaccionan mejor ante los
riesgos en cada uno de los niveles evolutivos.
Mantiene el enfoque sistemático de los pasos del ciclo
de vida clásico, pero lo incorpora al marco de trabajo
iterativo.
33. Principios Básicos
Decidir qué problema se quiere resolver antes de viajar
a resolverlo.
Examinar tus múltiples alternativas de acción y elegir
una de las más convenientes.
No ser tan ingenuo para pensar que el sistema que
estás construyendo será "EL" sistema que el cliente
necesita.
Conocer (comprender) los niveles de riesgo, que
tendrás que tolerar.
34. Como Elegir el Modelo
Puntos a tomar en cuenta para elegir el modelo.
Hay Cambio significativo a medida que avance el proyecto.
(Evolutivo)
Se Comprende bien toda la arquitectura del sistema al
comenzar el proyecto. (Lineales)
Fiabilidad. (Formales)
Que tiempo extra se necesita para planificar y diseñar durante
el proyecto para posibles versiones futuras. (DRA)
Existe una Planificación predefinida. (Espiral)
Se tendrá que Realizar modificaciones a medio camino.
35. Analizar el siguiente problema, luego dar su
respuesta de cual modelo utilizaría para este caso y
explicar la razón por la cual eligió dicho modelo:
Se supone que se va desarrollar una aplicación
relativa a la gestión de pedidos de una empresa. En
este caso el cliente ya tiene claro qué es lo que
quiere. El personal informático va a utilizar una
tecnología que le resulta completamente nueva.
Indique qué tipo de ciclo de vida es más apropiado
y qué procesos se deberían utilizar para desarrollar
esta aplicación. Explique su respuesta
