Este documento describe el modelo en cascada para el desarrollo de software. El modelo incluye las siguientes fases: especificación de requisitos, diseño del sistema, diseño del software, implementación del software, integración, pruebas y mantenimiento. El modelo en cascada ha sido criticado por su inflexibilidad ante cambios en los requisitos.
2. Este Modelo se derivo de Procesos de Ingeniería
de Sistemas mas generales por Royce en
1970.Este se encarga de considerar las
actividades fundamentales del Proceso de:
Especificación. Desarrollo. Validación.
Sus etapas principales son las siguientes:
4. Los servicios, Restricciones y Metas del
Sistema se definen a partir de las consultas
con Los usuarios. Se definen en detalle y
sirven como una especificación del
Sistema.
5. El Proceso del Diseño del Sistema divide los
Requerimientos en sistemas Hardware o
Software. Establece una Arquitectura
completa del sistema. El Diseño del
software “Identifica” y “Describe” las
abstracciones fundamentales del sistema
software y sus relaciones.
6. El Diseño del Software se lleva a cabo
como un “Conjunto” o “Unidades” de
Programas. La “Prueba de unidades”
implica verificar que cada una cumpla
su especificación.
7. Los “Programas” o Las “Unidades“
individuales de programas se integran y
prueban como un sistema completo para
asegurarque se cumplan los
requerimientos del Software.El “Sistema
Software” se entrega al cliente.
8. El Sistema se “instala” y se pone en
Funcionamiento Práctico. El
“Mantenimiento” implica a corregir
errores no descubiertosen las etapas
anteriores del ciclode vida, mejorar la
implementación de las unidades del
sistema y saltar los servicios del sistema
una vez que descubren nuevos
requerimientos.
9. Ventajas:
1) La Documentación se va produciendo en cada
fase.
2) El Modelo cuadra con otros modelos del
proceso de ingeniería.
Desventajas:
1) Inflexibilidad : al dividir el proyecto en distintas
etapas.
2) Es difícil responder a cambios en los
requerimientos del cliente.
11. Incluye fases similares a las del modelo en cascada
pero de forma jerárquica. En horizontal se
representa el avance en el desarrollo y en vertical
el nivel de detalle.
VERIFICACIÓN, comprobación de que una parte
del sistema cumple con sus especificaciones.
VALIDACIÓN, comprobación de que un elemento
satisface las necesidades del usuario identificadas
durante el análisis.
12. Modelo iterativo y creciente (o incremental)
es un proceso de desarrollo de software, creado en
respuesta a las debilidades del modelo tradicional de
cascada.Para apoyar el desarrollo de proyectos por
medio de este modelo se han creado frameworks
(entornos de trabajo), de los cuales los dos más
famosos son el Rational Unified Process y el Dynamic
Systems Development Method. El desarrollo
incremental e iterativo es también una parte esencial
de un tipo de programación conocido como Extreme
Programming y los demás frameworks de desarrollo
rápido de software.
13. Los riesgos son identificados y mitigados
Los principales riesgos que ayuda a mitigar:
Construir el sistema equivocado
Problemas en Integración
Arquitectura
Permite planificar el cambio en la próxima iteración
Alto nivel de reutilización
Se identifican partes comunes ya implementadas
14. Desarrollo evolutivo
• Desarrollo exploratorio
– El objetivo es trabajar con los clientes y evolucionar hacia
un sistema final desde una especificación inicial. Debería
partir con requerimientos bien conocidos.
• Prototipos desechables
– El objetivo es entender los requerimientos del sistema.
Debería comenzar con requerimientos pobremente
conocidos.
15. Desarrollo evolutivo
Actividades
concurrentes
Especificación Versión inicial
Bosquejo de la Desarrollo Versiones
descripción intermedias
Validación Versión final
16. Desarrollo evolutivo
• Problemas
– Los sistemas a menudo resultan pobremente estructurados.
– Puede ser necesario contar con habilidades especiales (por
ejemplo, lenguajes para prototipos rápidos).
• Aplicabilidad
– Para sistemas interactivos pequeños o de mediano tamaño.
– Para partes de sistemas grandes (por ejemplo, la interfaz del usuario).
– Para sistemas de corta vida útil.
17. El Modelo Espiral
El Modelo Espiral mejora el Modelo de
Cascada enfatizando la naturaleza iterativa del
proceso de diseño. Eso introduce un ciclo de
prototipo iterativo. En cada iteración, las
nuevas expresiones que son obtenidas
transformando otras dadas son examinadas
para ver si representan progresos hacia el
objetivo.
18. Características:
En cada giro se construye un nuevo modelo del sistema
completo.
Este modelo puede combinarse con otros modelos de proceso
de desarrollo (cascada, evolutivo).
Mejor modelo para el desarrollo de grandes sistemas.
El análisis de riesgo requiere la participación de personal
altamente calificado.
19. Desventajas:
Resulta difícil convencer a grandes clientes de que el
enfoque evolutivo es controlable.
Es nuevo (1988) y no se ha utilizado tanto como
otros modelos de ciclo de vida.
Debido a su elevada complejidad no se aconseja
utilizarlo en pequeños sistemas.
20. Ventajas:
El modelo en espiral puede adaptarse y aplicarse a lo
largo de la vida del software de computadora.
Como el software evoluciona a medida que progresa el
proceso, el desarrollador y el cliente comprenden y
reaccionan mejor ante riesgos en cada uno de los nivele
evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar
el enfoque de construcción de prototipos en cualquier
etapa de evolución del producto.
21. incremental
El modelo incremental combina elementos del
modelo lineal secuencial (aplicados
repetidamente) con la filosofía interactiva de
construcción de prototipos. El modelo
incremental aplica secuencias lineales de
forma escalonada mientras progresa el tiempo
en el calendario. Cada secuencia lineal
produce un «incremento» del software
[MDE93]. Por ejemplo, el software de
tratamiento de textos desarrollado con el
paradigma incremental podría extraer
funciones de gestión de archivos básicos y de
producción de documentos en el primer
incremento; funciones de edición más
sofisticadas y de producción de documentos
en el segundo incremento; corrección
ortográfica y gramatical en el tercero; y una
función avanzada de esquema de página en el
22. VENTAJAS El usuario se involucra más. Los usuarios no tiene que
esperar. Se evitan proyectos largos y se entrega “Algo de valor” a
los usuarios con cierta frecuencia Se puede financiar el proyecto
por partes. No se necesita tanto personal al principio como para
una implementación completa. INGENIERIA DE SOFTWARE
12. DESVENTAJAS Difícil de evaluar el costo total. Difícil de aplicar
a sistemas transaccionales que tienden a ser integrados y a
funcionar como un todo. Requiere gestores experimentados. Los
errores en los requisitos se detectan tarde. INGENIERIA DE
SOFTWARE
13. DESVENTAJAS Prioriza los requisitos del usuario y los
requisitos de más alta prioridad se incluyen en los incrementos
más tempranos. Las primeras versiones son incompletas pero
proporcionan al usuario la funcionalidad que precisa y una
plataforma para la evaluación. Se necesitan pruebas de regresión.
Pueden aumentar el coste debido a las pruebas. INGENIERIA DE
SOFTWARE
23. Construccion de prototipo
Los prototipos son una visión preliminar del
sistema futuro que se implantara.La
elaboración de prototipos de un sistema de
información es una técnica valiosa para la
recopilación rápida de información especifica a
cerca de los requerimientos de información de
los usuarios.Los prototipos efectivos deben
hacerse tempranamente en el ciclo de vida del
desarrollo de sistemas, durante la fase de
determinación de requerimientos.
24. Ventajas : reducción de la incertidumbre y del
riesgo, reducción de tiempo y de
costos, incrementos en la aceptación del
nuevo sistema, mejoras en la administración
de proyectos, mejoras en la comunicación
entre desarrolladores y clientes, etc.
Desventajas : la dependencia de las
herramientas de software para el éxito ya que
la necesidad de disminución de incertidumbre
depende de las iteraciones del prototipo, entre
más iteraciones existan mejor y esto último se
logra mediante el uso de mejores herramientas
lo que hace a este proceso dependiente de las
mismas. También, no es posible aplicar la
metodología a todos los proyectos de software
y, finalmente, la mala interpretación que
pueden hacer los usuarios del prototipo, al
cual pueden confundir con el sistema
terminado.
25. Modelo basado en componentes
Creo que estamos en el clasico "Reuso del conocimiento", ya que comoantes
soliamos hacer en el colegio, cuando teniamos alguna funcion oproceso ya
hecho, lo podiamos usar para un programa nuevo.
Creo que basicamente de eso es lo que se trata este modelo, ya que reutilizam
componentes como :Prototipos, código o diseño.
Entonces, tranquilamente podremos usar piezas de codigo preelaborado.
Para facilitarnos la cosas y no tener problemas con el tiempo delproyecto, o lo
recursos, tranquilamente podremos Comprar el componentenecesitado, y no
tener que construir uno propio.
Entonces, aqui hay que saber donde tendremos que comprar los
componentes, convertirnos en buenos compradores.
Usar las habilidades que tienen algun@s para ir de shopping, y encaminarlas p
conseguir buenos componentes.
26. Las ventajas parecen ser claras de este
modelo:
- Reutilización del Software.
- Simplificación de pruebas, simplificacion del
mantenimiento del sistema.
(ambas significan menos tiempo)
- Mayor calidad. (Aunque esta depende de sin
somos o no buenos compradores)
y cuando compramos a terceros:
- Ciclos de desarrollo se hacen mas cortos.
- El dinero invertido regresa en menos
tiempo.
- Hay mejor funcionalidad
(aunque, insisto, depende si sabemos comprar
bien).