El documento describe el modelo en cascada para el desarrollo de software. Explica que consiste en dividir el proceso de desarrollo en etapas secuenciales como análisis de requerimientos, diseño, implementación, pruebas e integración, y mantenimiento. También señala que es difícil que los proyectos sigan este flujo de forma estricta y que los requerimientos suelen cambiar, haciendo el modelo poco flexible.

1. 03-23-05
Ingeniería de
Software
Modelo en Cascada

2. PEMO-2015
Modelo en Cascada
Definición
• Muy utilizado para adaptaciones o mejoras de sistemas
existentes.
• Útil cuando los requisitos están fijos.
• Es raro que los proyectos reales sigan el flujo secuencial.
• Es difícil que el cliente sepa de manera explícita todos los
requisitos de manera explícita.
• El cliente debe tener paciencia.
• Es inflexible y no motiva al cambio.
• Poco apropiado para aplicaciones para la toma de
decisiones.
• Los usuarios tienen una participación limitada.

3. PEMO-2015
Modelo en Cascada
Definición
Modelo en cascada a partir del modelo secuencial

4. PEMO-2015
Modelo en Cascada
Definición
Modelo en cascada a partir del modelo secuencial

5. PEMO-2015
Modelo en Cascada
Etapas
1.-Análisis y Definición De Requerimientos:
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.
Los requerimientos se pueden dividir en funcionales y no
funcionales
2.-Diseño del Sistema y del Software.-
El Diseño del software “Identifica” y “Describe” las
abstracciones fundamentales del sistema software y sus
relaciones.

6. PEMO-2015
Modelo en Cascada
Etapas
3.-Implementación y Prueba de Unidades:
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.
4.-Integración y Prueba del Sistema:
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.

7. PEMO-2015
Modelo en Cascada
Etapas
5.-Funcionamiento y Mantenimiento:
El Sistema se “instala” y se pone en Funcionamiento
Práctico.
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 descubren
nuevos requerimientos.

8. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
• Entender los requerimientos de una solución basada en
software es una de las tareas mas difíciles del proceso.
Como otras actividades esta tarea debe adaptarse a las
necesidades del proceso, proyecto, producto y las personas
del equipo de desarrollo.
• Durante esta etapa se debe proveer un mecanismo
apropiado para entender que quiere el consumidor, analizar
sus necesidades, valorar la factibilidad de construcción,
negociar una solución razonable, especificar de manera no
ambigua una solución, validar la especificación y administrar
los requerimientos conforme se transforman.

9. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Dentro de esta etapa podemos destacar las siguientes
tareas principales:
• Iniciación (Inception)
• Obtención (Elicitation)
• Elaboración
• Negociación
• Especificación
• Validación (Validation)
• Administración
Algunas de estas funciones pueden ocurrir en paralelo y
ajustarse a las necesidades del proyecto

10. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Iniciación (Inception)
• ¿Cómo se empieza un proyecto? Algunas veces inicia por
conversaciones informales, otras de manera mas formal;
normalmente como resultado de una necesidad importante
• En esta parte, los ingenieros de software realizan preguntas
“libres de contexto” (generales), para establecer un
entendimiento básico del problema, determinar las personas
que quieren una solución, la naturaleza de la solución, y la
efectividad de las colaboraciones y comunicaciones
preeliminares que se generan entre el consumidor y el
desarrollador

11. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Obtención (Elicitation)
• Se refiere a definir formalmente los requerimientos de la
solución. Es difícil porque como ya se ha visto:
– Hay problemas de definición de alcances
– Hay problemas de entendimiento entre los involucrados
– Hay problemas de volatilidad (los requerimientos
cambian con el tiempo)

12. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Obtención (Elicitation)
• Las prácticas de ER incluyen entrevistas, cuestionarios,
observación a la labor del usuario, talleres, lluvia de ideas,
casos de uso, juegos de rol y la creación de prototipos;
aunque existen muchas otras características diferentes en
los proyectos reales.

13. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Elaboración
• Esta actividad expande y refina la información obtenida en
la tarea de iniciación
• Se enfoca en realizar modelos técnicos refinados de las
funciones del software, características y limitantes.
• Es básicamente una función de modelado. Se conduce a
través de la definición de escenarios del usuario que
describen la interacción del usuario final con el sistema
• Se define el dominio del problema desde varios puntos de
vista: información, funciones y comportamiento

14. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Elaboración
Apoyo con
Casos de uso

15. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Elaboración
Especificación
de Casos de uso

16. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Especificación
• Los usuarios y consumidores normalmente piden mas de lo
que se puede hacer con los recursos con que se cuenta.
• Casi siempre diferentes involucrados (stakeholders) piden
cosas diferentes, por lo que hay que conciliar intereses a
través de negociaciones.
• Hay varias maneras para negociar, y depende de la cultura
de la organización y tamaño del proyecto

17. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Especificación
• Especificación significa diferentes cosas para diferentes
personas en el área de Ing. de software.
• Este es el producto de trabajo final de la ingeniería de
requerimientos.
• Sirve como base para actividades subsecuentes.
• Describe la función y desempeño de un sistema y las
restricción que tiene.
• Hay muchas técnicas para escribir especificaciones:
diagramas, narraciones en prosa, modelos matemáticos,
dibujos, etc.

18. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Validación (Validation)
• El producto generado por la ingeniería de requerimientos
debe ser evaluado en términos de congruencia y calidad. Se
debe asegurar que la especificación concuerda con las
expectativas del usuario y que no es ambigua.
• Deben detectarse y corregirse errores, omisiones e
inconsistencias con respecto a los estándares establecidos
en el proyecto.
• El mecanismo común de validación es la revisión técnica
formal.

19. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Administración
• Actividades que ayudan al equipo de trabajo a identificar,
controlar y seguir los requerimientos y cambios que ocurren
en ellos a través de todo el proceso de desarrollo.
• La administración empieza con la identificación de cada
requerimiento. Posteriormente se generan tablas que
permitirán darles seguimiento. Algunas de éstas son:
– Tablas de características
– Tablas de fuentes
– Tablas de dependencias
– Tablas de subsistemas
– Tablas de interfaces

20. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Roles
Analista de Requerimientos
Patrocinador del Proyecto Administrador del Proyecto
Desarrolladores
PruebasOtros interesados
en el sistema
Cliente y
Usuarios
requerimientos
del negocio
requerimientos
del cliente/usuario
restricciones y
requerimientos
requerimientos funcionales
y no-funcionales
requerimientos funcionales
y no-funcionales
Factibilidad,
Tiempos y costos
Analista de Requerimientos
Patrocinador del Proyecto Administrador del Proyecto
Desarrolladores
PruebasOtros interesados
en el sistema
Cliente y
Usuarios
requerimientos
del negocio
requerimientos
del cliente/usuario
restricciones y
requerimientos
requerimientos funcionales
y no-funcionales
requerimientos funcionales
y no-funcionales
Factibilidad,
Tiempos y costos

21. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Funciones del analista de requerimientos:
• Definir los objetivos del proyecto y los beneficios al negocio.
• Identificar el problema a resolver y obtener los
requerimientos.
• Identificar a los involucrados en el desarrollo del proyecto
así como a las clases de clientes y usuarios.
• Identificar el ambiente del dominio a desarrollar y estar
preparado para desarrollar el sistema requerido.
• Administrar los requerimientos utilizando un proceso y un
plan de requerimientos.
• Modelar los requerimientos.
• Realizar control de cambios en los requerimientos.

22. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Actividades y responsabilidades del Cliente:
• Educar al analista de requerimientos acerca del negocio y sus
objetivos.
• Ser claro y preciso acerca del problema que se quiere resolver.
• Colaborar con el analista en la definición de los requerimientos.
• Revisar los documentos de requerimientos y el avance del
proyecto.
• Comunicar a los analistas sobre cambios en los requerimientos.
• Plantear costos y tiempos esperados de desarrollo y estar abierto a
discutir cambios en los costos y tiempos de entrega.
• Estar siempre dispuesto a reunirse con los desarrolladores para
discutir distintos aspectos del proyecto.
• Respetar los procesos que implementarán los desarrolladores para
implementar el producto.

23. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Aportes del Usuario:
• La frecuencia con la que usan el sistema.
• Las funciones que usan del sistema y su frecuencia.
• La experiencia en el dominio de la aplicación y su experiencia con
otros sistemas similares.
• El tipo de uso que le dan al sistema (operación, administración,
mantenimiento, supervisión).
• Las tareas que desempeñan en soporte de los procesos de la
organización.
• Sus privilegios de acceso o niveles de seguridad (tales como
usuario invitado, administrador o usuario de nivel interno).
• Tipo de usuarios necesarios para operar el sistema (persona, grupo
de personas, robot, u otra computadora).

24. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Documentación.
• Es la declaración oficial de lo que es requerido para que el
sistema sea desarrollado, incluye la definición y
especificación de requerimientos.
• El documento debiera considerar a los menos los siguientes
aspectos:
– Especificación del comportamiento externa del sistema.
– Especificar las restricciones de la implementación.
– Fácil de cambiar.
– Sirve como una herramienta de referencia para el
mantenimiento.
– Registro del ciclo de vida del sistema, con el fin de predecir
cambios.
– Caracterizar las respuestas a eventos inesperados.

25. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Obtención de requisitos
• Incluye juntas colaborativas de definición, despliegue de funciones
y descripción de escenarios
• Los productos que genera son:
– Una declaración de necesidades y factibilidades
– Una declaración delimitada del alcance del sistema o producto
– Una lista de consumidores, usuarios y otros involucrados
(stakeholders) que participaron en la definición del documento
– Una descripción del medio ambiente técnico del sistema
– Una lista de requerimientos, de preferencia organizados por
función, y las restricciones de dominio que los afectan
– Un conjunto de escenarios de uso que dan idea del uso del
producto en diferentes condiciones operativas
– Prototipos desarrollados

26. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Validación de los requerimientos
• Demostración de que los requerimientos que definen el
sistema son lo que el cliente realmente quiere.
• Los costos de errores en los requerimientos son altos, por lo
cual, la validación es muy importante.
– Fijar un error de requerimiento después del desarrollo puede
resultar en un costo 100 veces mayor que fijar un error en la
implementación.
• El Prototipado es una técnica importante en la validación de
requerimientos.

27. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
Artefactos
• En la actualidad los casos de uso son utilizados para apoyar las
tareas de definición de los requerimientos,
• Es una técnica para especificar el comportamiento de un sistema:
“Un caso de uso es una secuencia de interacciones entre un
sistema y alguien o algo que usa alguno de sus servicios.”
• Un caso de uso es una forma de expresar cómo alguien o algo
externo a un sistema lo usa. Cuando decimos “alguien o algo”
hacemos referencia a que los sistemas son usados no sólo por
personas, sino también por otros sistemas de hardware y software.
Por ejemplo, un sistema de ventas, si pretende tener éxito, debe
ofrecer un servicio para ingresar un nuevo pedido de un cliente.
Cuando un usuario accede a este servicio, podemos decir que está
“ejecutando” el caso de uso ingresando pedido.

28. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
¿Está claro lo que se desea que haga el sistema?

29. PEMO-2015
Modelo en Cascada
1.-Análisis y definición de requerimientos
En resumen
• Es muy difícil formular una especificación de requerimientos
completa y consistente.
• Una definición de requerimientos, una especificación de
requerimientos y una especificación de Software son una manera
de especificar el Software para diferentes tipos de lectores.
• El Documento de Requerimientos es una descripción para clientes
y desarrolladores.
• Los errores en los requerimientos son usualmente muy caros de
corregir una vez desarrollado el sistema.
• La revisión debe involucrar al cliente y al staff de contratistas para
validar los requerimientos del sistema.
• El establecer requerimientos está relacionado con las actividades
del cliente para el Software.
• Los requerimientos volátiles dependen del contexto en que se use
el sistema.

30. PEMO-2015
Modelo en Cascada
2.-Diseño del Software.-
Según Taylor: “Proceso de aplicar distintas técnicas y
principios con el propósito de definir un dispositivo, proceso o
sistema con los suficientes detalles como para permitir su
realización física”
El diseño de software, al igual que los métodos de diseño de
todas las ingenierías, cambian continuamente al aparecer
nuevos métodos, mejores análisis y ampliar los
conocimientos.
El problema es que el diseño de software se encuentra en una
etapa relativamente temprana en su evolución. La idea de
realizar diseño de software en lugar de “programar”, surgió a
principios de los años 60, por lo que a las metodologías de
diseño les falta la profundidad y la flexibilidad que tiene el
diseño en otras ingenierías..

31. PEMO-2015
Modelo en Cascada
2.-Diseño del Software.-
El diseño del software es un proceso mediante el que se
traducen los requisitos en una representación del software,
que se acerca mucho al código fuente.
Desde el punto de vista de la gestión del proyecto, el diseño
del software se realiza en dos etapas: el diseño preliminar y el
diseño detallado. ƒ
• El diseño preliminar se centra en la transformación de los
requisitos en los datos y la arquitectura del software. ƒ
• El diseño detallado se ocupa del refinamiento y de la
representación arquitectónica que lleva a una estructura de
datos refinada y a las representaciones algorítimicas del
software.

32. PEMO-2015
Modelo en Cascada
2.-Diseño del Software.-
Una vez que se han establecido los requisitos del software, el
diseño es la primera de tres actividades técnicas: diseño,
codificación y prueba. ese momento, se decidirá la estructura
general del programa (subdivisión en partes y relaciones
entre ellas), cada una de las partes se seguirá recursivamente
un proceso similar, hasta que tengamos totalmente definido el
programa y estemos listos para pasar a la fase de codificación
Cada actividad transforma la información de manera que al
final se obtiene un software validado. El diseño es
técnicamente la parte central de la ingeniería del software.
Durante el diseño se desarrollan, revisan y se documentan los
refinamientos progresivos de las estructuras de datos, de la
estructura del programa y de los detalles procedimentales.
El diseño da como resultado representaciones cuya calidad
puede ser evaluada.

33. PEMO-2015
Modelo en Cascada
2.-Diseño del Software.-
En el análisis de cada una de las partes nos encontraremos
normalmente con que hay varias soluciones posibles, la elección de
una de ellas suele realizarse de una forma más o menos intuitiva: no
hay metodologías efectivas que nos ayuden en esta decisión. Como
puede deducirse de lo dicho hasta aquí, la descomposición en niveles
de abstracción también será útil en esta fase. Cada etapa del
proceso recursivo descrito puede constituir un nivel de abstracción.
Si además, utilizamos las posibilidades de ocultación de información
que nos permite esta metodología, podremos descomponer nuestro
programa en pequeños módulos fáciles de modificar.
El producto final de la etapa de diseño puede ser un organigrama,
unas líneas de pseudocódigo, etc. Algunos lenguajes de
programación (como Ada) permiten hasta cierto punto realizar el
diseño en el propio lenguaje, y compilarlo posteriormente. Así
pueden detectarse incoherencias y ambigüedades de una forma
automática. Además se favorece en gran medida la integración con
la etapa de codificación.

34. PEMO-2015
Modelo en Cascada
2.-Diseño del Software.-
En la actualidad está siendo utilizado el paradigma de
orientación a objeto el que es soportado por UML como
herramienta de diseño a través de su lenguaje estándar de
facto en el tema.
UML provee una serie de diagramas que permiten representar
los requerimientos en forma gráfica a través de diferentes
niveles de abstracción.

35. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
En un proyecto grande ésta es la etapa más sencilla. Si el
diseño es adecuado y suficientemente detallado la codificación
de cada módulo es algo casi automático.
Una de las principales decisiones a tomar en esta fase es la
del lenguaje a emplear, aunque a veces en el diseño ya está
de alguna forma implícito. Desde hace tiempo la tendencia es
a utilizar lenguajes de más alto nivel, esto ayuda a los
programadores a pensar más cerca de su propio nivel que del
de la máquina, y la productividad suele mejorarse.
Como contrapartida este tipo de lenguajes son más difíciles de
aprender. Y además hay que tener en cuenta que los
programadores suelen ser conservadores y reacios a aprender
nuevos lenguajes: prefieren usar los que ya conocen.

36. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
Evaluar la calidad de la codificación no es una tarea fácil. Para
un mismo diseño son posibles muchas implementaciones
diferentes. Y no hay criterios claros que permitan decidir cuál
es la mejor. En este punto, las métricas del software pueden
ser utilizadas en nuestra ayuda.
Cuando intervienen varias personas, pueden aparecer
problemas a la hora de realizar modificaciones, debido a que
cada uno tiene su propio estilo. Por eso se hace necesario
definir estándares de estilo para facilitar la legibilidad y
claridad del software producido.

37. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
De acuerdo con McGlaughlin, “Hay tres características que
sirven como parámetros generales para la evaluación de un
buen diseño”
1. El diseño debe implementar todos los requisitos explícitos
obtenidos en la etapa de análisis
2. El diseño debe ser una guía que pueda leer y entender los
que construyen el código y los que prueban y mantienen
el software
3. El diseño debe proporcionar una idea completa de los que
es el software

38. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
El diseño del software desarrolla un modelo de
instrumentación o implantación basado en los modelos
conceptuales desarrollados durante el análisis, existen :
• El Diseño de los datos
• El Diseño Arquitectónico
• El Diseño de la Interfaz
• El Diseño de procedimientos

39. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
• El Diseño de los datos
– Trasforma el modelo de dominio de la información, creado
durante el análisis, las estructuras de datos necesarios para
implementar el Software.
• El Diseño Arquitectónico
– Define la relación entre cada uno de los elementos
estructurales del programa.
• El Diseño de la Interfaz
– Describe como se comunica el Software , con los sistemas que
operan junto con el y con los operadores y usuarios que lo
emplean.

40. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
• El Diseño de procedimientos
– Transforma elementos estructurales de la arquitectura del
programa. La importancia del Diseño del Software se puede
definir en una sola palabra Calidad, dentro del diseño es
donde se fomenta la calidad del Proyecto. El Diseño es la única
manera de materializar con precisión los requerimientos del
cliente.

41. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
Caso aplicado

42. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
Solución del Diseño en el Enfoque Estructurado
• Diseño de la Arquitectura de Soporte (DSI 2), que incluye el
diseño detallado de los subsistemas de soporte, el
establecimiento de las normas y requisitos propios del
diseño y construcción, así como la identificación y definición
de los mecanismos genéricos de diseño y construcción.
• Diseño de la Arquitectura de Módulos del Sistema (DSI 5),
dónde se realiza el diseño de detalle de los subsistemas
específicos del sistema de información y la revisión de la
interfaz de usuario.
• Diseño Físico de Datos (DSI 6), que incluye el diseño y
optimización de las estructuras de datos del sistema, así
como su localización en los nodos de la arquitectura
propuesta.

43. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
En caso de Diseño Orientado a Objetos,
• Conviene señalar que el diseño de la persistencia de los
objetos se lleva a cabo sobre bases de datos relacionales, y
que el diseño detallado del sistema de información se realiza
en paralelo con la actividad de Diseño de la Arquitectura de
Soporte (DSI 2), y corresponde con las siguientes
actividades:
– Diseño de Casos de Uso Reales (DSI 3), con el diseño
detallado del comportamiento del sistema de información para
los casos de uso, el diseño de la interfaz de usuario y la
validación de la división en subsistemas.
– Diseño de Clases (DSI 4), con el diseño detallado de cada una
de las clases que forman parte del sistema, sus atributos,
operaciones, relaciones y métodos, y la estructura jerárquica
del mismo. En el caso de que sea necesario, se realiza la
definición de un plan de migración y carga inicial de datos

44. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
La verificación y validación (V & V)
• Se utiliza para mostrar que un sistema está acorde a su
especificación y que cumple los requerimientos del cliente que
comprará el sistema.
• Incluye procesos de comprobación y revisión y pruebas del
sistema.
• La prueba del sistema implica ejecutar el sistema con casos de
prueba que se derivan de la especificación de datos reales para
ser procesados en el sistema.
• La verificación busca comprobar que el sistema cumple con
los requerimientos especificados (funcionales y no funcionales),
o sea, si el software está de acuerdo con su especificación.
• La validación busca comprobar que el software hace lo que el
usuario espera, o sea, si el software cumple las expectativas
del cliente.

45. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
Etapas de las Pruebas
• Prueba de unidades o componentes
– se prueban los componentes independientemente;
– Los componentes pueden ser funciones u objetos o grupos
coherentes de estas entidades.
• Prueba del sistema
– Probar el sistema en sí. La prueba de propiedades emergentes
es particularmente importante.
• Prueba de aceptación
– Comprobar con los datos proporcionados por el cliente que el
sistema cumple las necesidades del mismo.

46. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
Etapas de las Pruebas

47. PEMO-2015
Modelo en Cascada
3.-Implementación y Prueba de Unidades:
Fases de Pruebas

48. PEMO-2015
Modelo en Cascada
4.-Integración y Prueba del Sistema:
Una vez que tenemos los módulos codificados, hay que
ensamblarlos. Desgraciadamente el proceso no consiste
simplemente en unir piezas. Suelen aparecer problemas con
las interfaces entre los módulos, con la comunicación de
datos compartidos, con el encadenamiento de flujos de
ejecución, etc.
Pruebas integrales o pruebas de integración son aquellas que
se realizan en el ámbito del desarrollo de software una vez
que se han aprobado las pruebas unitarias. Únicamente se
refieren a la prueba o pruebas de todos los elementos
unitarios que componen un proceso, hecha en conjunto, de
una sola vez.

49. PEMO-2015
Modelo en Cascada
4.-Integración y Prueba del Sistema:
Objetivo
El objetivo de las pruebas de integración es verificar el
correcto ensamblaje entre los distintos componentes una
vez que han sido probados unitariamente con el fin de
comprobar que interactúan correctamente a través de sus
interfaces, tanto internas como externas, cubren la
funcionalidad establecida y se ajustan a los requisitos no
funcionales especificados en las verificaciones
correspondientes

50. PEMO-2015
Modelo en Cascada
4.-Integración y Prueba del Sistema:
Integración Incremental. Este consiste en agregar uno por
uno los modulo y probar su funcionalidad, es decir, se
prueban dos módulos una vez aprobados se agrega un
modulo mas a los dos que ya están verificados, así asta estar
integrado todo proyecto.
 Integración descendente (top – Down). Es una estrategia de
integración incremental a la construcción de la estructura de
programas, en cual se integran los módulos moviéndose en
dirección hacia abajo por la jerarquía de control comenzando con el
módulo principal.
– Primero en profundidad, completando ramas del árbol.
– Primero en Anchura, completado niveles de jerarquía.

51. PEMO-2015
Modelo en Cascada
4.-Integración y Prueba del Sistema:
Incremental Ascendente (Bottom-Up)
• Unitarias de E, F, G y D
• Integración de (B con E), (C con F) y (C con G)
• Integración de (A con B), (A con C) y (A con D

52. PEMO-2015
Modelo en Cascada
4.-Integración y Prueba del Sistema:
Incremental Descendente (Top-Down)
• Primero en profundidad, completando ramas del árbol (A, B,
E, C, F, G, D)
• Primero en anchura, completando niveles de jerarquía (A, B,
C, D, E, F, G)

53. PEMO-2015
Modelo en Cascada
5.-Funcionamiento y Mantenimiento:
5.-Funcionamiento y Mantenimiento:
El Sistema se “instala” y se pone en Funcionamiento
Práctico.
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 descubren
nuevos requerimientos.

54. PEMO-2015
Modelo en Cascada
Variantes del modelo en cascada

55. PEMO-2015
Modelo en Cascada
Variantes del modelo en cascada

56. PEMO-2015
Modelo en Cascada
Variantes del modelo en cascada

57. PEMO-2015
Modelo en Cascada
Modelo en cascada en la realidad

58. PEMO-2015
Modelo en Cascada
Resumen
Cada una de las etapas del ciclo de vida genera algún tipo de
producto. A menudo los llamamos ’’productos intermedios’’ y
constituyen la base del trabajo de la siguiente etapa.
Por ejemplo, a partir del pseudocódigo obtenido en la fase de diseño, los
codificadores escribirán el programa. Y este programa (resultado de la etapa
de codificación) será la base para la integración.

59. PEMO-2015
Modelo en Cascada
Resumen
Según Grady [Grady, 1990], una correcta utilización de los
productos intermedios ayuda a producir software de calidad,
ya que:
• Cada producto intermedio suele seguir alguna forma de
representación estándar que garantiza un cierto grado de
terminología común.
• Existen herramientas que pueden aplicarse a estos productos, para
hacer comprobaciones sobre ellos, aportando así realimentación
inmediata a los ingenieros de desarrollo.
• La terminología común simplifica las inspecciones por parte de
otros equipos de trabajo. Así se facilita la detección de errores que
las herramientas automáticas no son capaces de detectar.
• También pueden utilizarse herramientas que calculen ciertas
métricas sobre diversos aspectos de la complejidad de los
productos intermedios. Así se pueden detectar zonas con mayor
probabilidad de que presenten errores, o que tengan un difícil
mantenimiento.