2. INTRODUCCION
 En ingeniería de software el desarrollo
en cascada también llamado modelo en
cascada es el enfoque metodológico
que ordena rigurosamente la etapas del
ciclo de vida del software.

3. DESARROLLO EN CASCADA
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento

4. INGENIERIA Y ANALISIS DEL
SISTEMA
 Debido a que el software es siempre
parte de un sistema mayor el trabajo
comienza estableciendo los requisitos
de todos los elementos del sistema y
luego asignando algún subconjunto de
estos requisitos al software

5. ANALISIS DE REQUISITOS
 el proceso de recopilación de los requisitos
se centra e intensifica especialmente en el
software.
 De esta fase surge una memoria llamada
SRD(Documento de especificación de
requisitos ) contiene especificación
completa de lo que debe hacer el sistema.
 El ingeniero de software (Analistas) debe
comprender el ámbito de la información del
software, así como la función, el
rendimiento y las interfaces requeridas.

6. Utilidad de la Especificación
Requisitos
del Software
Contrato con
el Cliente
Documento
de Especificación
de Requisitos Guía para los
desarrolladores

7. Cualidades y Principios
 La especificación de  Los principales
requisitos debe principios a aplicar:
tener las siguientes  separación de intereses
○ distintos puntos de
cualidades: vista,
 comprensible,  abstracción
 precisa, completa y ○ de lo general a los
consistente, detalles,
 no ambigua.  modularización
○ datos, funciones y
control

8. DISEÑO
 Como resultado surge el SDD(Documento de Diseño
de Software)
 El diseño describe cómo hará el sistema para
satisfacer sus requisitos.
 Es la descomposición del sistema en componentes.
 Arquitectura del sistema:
 ¿qué hacen las componentes?
 ¿cómo interactúan?
 Las componentes más grandes son divididas
iterativamente en sub-componentes:
 diseño de alto nivel,
 diseño detallado.

9. CODIFICACION
 El diseño debe traducirse en una forma
legible para la maquina. El paso de
codificación realiza esta tarea.
 Si el diseño se realiza de una manera
detallada la codificación puede
realizarse mecánicamente.
 Se crean librerías ,componentes y
bibliotecas.

10. PRUEBA
 una vez que se ha generado el código
comienza la prueba del programa. La
prueba se centra en la lógica interna del
software, y en las funciones
externas, realizando pruebas que
aseguren que la entrada definida
produce los resultados que realmente
se requieren.

11.  Las empresas pueden establecer
estándares de pruebas:
 definición de un plan de pruebas,
 criterios de pruebas (caja negra, caja blanca),
 criterios de fin de las pruebas,
 administración de los casos de prueba.
 La depuración (“debugging”) es parte de
esta etapa.
 Es el control de calidad llevado a cabo en
esta etapa.
 Inspecciones para comprobar adhesión a
los estándares.

12. • Existen varios tipos de
Pruebas:
1. Pruebas de unidad
2. Pruebas de integración
3. Pruebas de sistema.
4. Pruebas de aceptación

13. MANTENIMIENTO
 el software sufrirá cambios después de
que se entrega al cliente. Los cambios
ocurrirán debido a que hayan
encontrado errores, a que el software
deba adaptarse a cambios del entorno
externo (sistema operativo o
dispositivos periféricos), o debido a que
el cliente requiera ampliaciones
funcionales o del rendimiento.

14.  Tipos de mantenimientos:
 Mantenimiento Preventivo y Perfectivo
 Mantenimiento Correctivo
 Mantenimiento Evolutivo
 El análisis de requisitos es una fuente de
problemas, especialmente para los usuarios
finales:
 los requisitos son difíciles de especificar,
 los requisitos cambian con el tiempo.
 Muchos errores no son resueltos hasta
después de instalar el software en el cliente:
 es más caro corregir errores cuanto más tarde se
detectan.
 Los cambios son (casi) siempre posibles pero
también (casi) siempre muy difíciles

15. VENTAJAS
 Se tiene todo bien organizado y no se
mezclan las fases.
 Es perfecto para proyectos rígidos y
además donde se especifiquen bien los
requerimientos y conozca muy bien las
herramientas a utilizar.

16. Críticas al Modelo de
Cascada
 El modelo de Cascada tiene dos grandes
aportes:
 debe aplicarse disciplina, planificación y
administración al proceso de desarrollo de
software,
 la construcción del sistema en sí se pospone
hasta que los objetivos del sistema sean
suficientemente comprendidos.
 Pero tiene también serias desventajas:
 lineal
 rígido