Aide Arcia Polanco Marcela Escobar Monroy Keilyn Gisela Echeverry Tatiana Lemus Melary Julieth Rivas Reyes Gloria Docente 10*2 INSTITUCION EDUCATIVA GABRIEL GARCIA MARQUEZ 2014

 Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos  Este modelo se encarga de considerar las actividades fundamentales del proceso de: Especificación, desarrollo, validación.

 Es importante porque Modelo o Desarrollo en Cascada En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inme

 Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se definen en detalles y sirve como una especificación del sistema.

 El proceso del diseño del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El Sistema del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.

 El diseño del software se lleva a cabo como un conjunto o unidades de programas. Implica verificar que cada una cumpla su especificación

 Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software

 El Sistema se instala y se pone en funcionamiento practico. El mantenimiento implica a corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y saltar los servicios del sistema una vez que descubran nuevos requerimientos

 La documentación se produce en cada fase y que este cuadra con otros modelos del proceso de ingeniería. Su Principal problema es su inflexibilidad al dividir el proyecto en distintas etapas

 El Modelo cascada solo se debe utilizar cuando los requerimientos se comprendan bien y sea improbable que cambien radicalmente durante el desarrollo

 Fácil entendimiento e implementación  Ampliamente utilizado y conocido ( En teoría )  Refuerza buenos hábitos: definir antes que diseñar, diseñar antes que codificar  Identifica entregables e hitos  Orientado a documentos  Funciona bien en productos maduros y equipos débiles

 No aprovecha la iteración, ni el desarrollo exploratorio  Espera requerimientos definidos completamente al inicio del proyecto -IREAL  Dificultar para integrar administración del riesgo  El software es entregado tarde en el proyecto Esto hace que se detecten errores graves muy tarde.  Hacer cambios es difícil y costoso