SlideShare una empresa de Scribd logo

Modelo en cascada pemo

Modelo cascada detallado

1 de 59
Descargar para leer sin conexión
03-23-05
Ingeniería de
Software
Modelo en Cascada
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.
PEMO-2015
Modelo en Cascada
Definición
Modelo en cascada a partir del modelo secuencial
PEMO-2015
Modelo en Cascada
Definición
Modelo en cascada a partir del modelo secuencial
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.
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.

Recomendados

Ingenieria de requisitos y requerimientos
Ingenieria de requisitos y requerimientosIngenieria de requisitos y requerimientos
Ingenieria de requisitos y requerimientosIsidro Gonzalez
 
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?Software Guru
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientosTensor
 
Modelo de prototipos
Modelo de prototiposModelo de prototipos
Modelo de prototiposjuriberuiz
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de softwareYaskelly Yedra
 

Más contenido relacionado

La actualidad más candente

Modelos y capas de la ingenieria de software
Modelos y capas  de la ingenieria de softwareModelos y capas  de la ingenieria de software
Modelos y capas de la ingenieria de softwarejhonatanalex
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosFranklin Parrales Bravo
 
MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMicky Jerzy
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosFranklin Parrales Bravo
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmiSandrea Rodriguez
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del softwareJohan Prevot R
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareDaniel Guaycha
 
Metodologias para el desarrollo del software
Metodologias para el desarrollo del softwareMetodologias para el desarrollo del software
Metodologias para el desarrollo del softwareyeltsintorres18
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareLorena Quiñónez
 
54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-softwarecristina_devargas
 
Validación de Requerimientos
Validación de RequerimientosValidación de Requerimientos
Validación de RequerimientosUTPL UTPL
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSLenin Acosta Mata
 
Modelo Cascada y Espiral
Modelo Cascada y EspiralModelo Cascada y Espiral
Modelo Cascada y Espiraljuanksi28
 

La actualidad más candente (20)

Modelos y capas de la ingenieria de software
Modelos y capas  de la ingenieria de softwareModelos y capas  de la ingenieria de software
Modelos y capas de la ingenieria de software
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitos
 
Rup disciplinas
Rup disciplinasRup disciplinas
Rup disciplinas
 
MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWARE
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientos
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmi
 
Ingeniería de software modelo incremental
Ingeniería de software  modelo incrementalIngeniería de software  modelo incremental
Ingeniería de software modelo incremental
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del software
 
Diseño de Software
Diseño de SoftwareDiseño de Software
Diseño de Software
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
 
Metodología Rup
Metodología RupMetodología Rup
Metodología Rup
 
Metodologias para el desarrollo del software
Metodologias para el desarrollo del softwareMetodologias para el desarrollo del software
Metodologias para el desarrollo del software
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de software
 
54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software
 
Modelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiralModelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiral
 
Validación de Requerimientos
Validación de RequerimientosValidación de Requerimientos
Validación de Requerimientos
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
Modelo Cascada y Espiral
Modelo Cascada y EspiralModelo Cascada y Espiral
Modelo Cascada y Espiral
 
Ingenieria requerimientos
Ingenieria requerimientosIngenieria requerimientos
Ingenieria requerimientos
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 

Similar a Modelo en cascada pemo

Similar a Modelo en cascada pemo (20)

Taller ingernieria de requerimientos
Taller ingernieria de requerimientosTaller ingernieria de requerimientos
Taller ingernieria de requerimientos
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
Ingenieria de Requisitos
Ingenieria de RequisitosIngenieria de Requisitos
Ingenieria de Requisitos
 
RUP.pdf
RUP.pdfRUP.pdf
RUP.pdf
 
Ingenieria de softwrae vol1 v4 2
Ingenieria de softwrae vol1 v4 2Ingenieria de softwrae vol1 v4 2
Ingenieria de softwrae vol1 v4 2
 
Ingenieria de softwrae vol1 v4 2
Ingenieria de softwrae vol1 v4 2Ingenieria de softwrae vol1 v4 2
Ingenieria de softwrae vol1 v4 2
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Procesos de Software EGEL-UNITEC
Procesos de Software EGEL-UNITECProcesos de Software EGEL-UNITEC
Procesos de Software EGEL-UNITEC
 
Tipos de ciclo de vida
Tipos de ciclo de vidaTipos de ciclo de vida
Tipos de ciclo de vida
 
Ppt de ingenieria de requerimiento
Ppt de ingenieria de requerimientoPpt de ingenieria de requerimiento
Ppt de ingenieria de requerimiento
 
Carlos leon
Carlos leonCarlos leon
Carlos leon
 
03 cicloprocesodesoftware isi
03 cicloprocesodesoftware isi03 cicloprocesodesoftware isi
03 cicloprocesodesoftware isi
 
Copia de carlos leon
Copia de carlos leonCopia de carlos leon
Copia de carlos leon
 
Prototipado rapido de interfaces
Prototipado rapido de interfacesPrototipado rapido de interfaces
Prototipado rapido de interfaces
 
Gestion de proyectos informaticos 2013 2
Gestion de proyectos informaticos 2013 2Gestion de proyectos informaticos 2013 2
Gestion de proyectos informaticos 2013 2
 
SOTFWARE
SOTFWARESOTFWARE
SOTFWARE
 
02 captura de requisitos
02 captura de requisitos02 captura de requisitos
02 captura de requisitos
 
Ingeniería y gestión de requerimientos
Ingeniería y gestión de requerimientosIngeniería y gestión de requerimientos
Ingeniería y gestión de requerimientos
 
Especificaciones de Requerimientos SRS
Especificaciones de Requerimientos SRSEspecificaciones de Requerimientos SRS
Especificaciones de Requerimientos SRS
 
Rup
RupRup
Rup
 

Más de Pedro Montecinos Gaete (8)

Mod control algoritmo 2017
Mod control algoritmo 2017Mod control algoritmo 2017
Mod control algoritmo 2017
 
Mod 6.2 introducción al análisis
Mod 6.2 introducción al análisisMod 6.2 introducción al análisis
Mod 6.2 introducción al análisis
 
Mod 2017 2 si
Mod 2017 2 siMod 2017 2 si
Mod 2017 2 si
 
Mod 6 1 introducción a uml
Mod 6 1 introducción a umlMod 6 1 introducción a uml
Mod 6 1 introducción a uml
 
3_Orientación a objeto
3_Orientación a objeto3_Orientación a objeto
3_Orientación a objeto
 
Mod 1 introducción a la programación
Mod 1 introducción a la programaciónMod 1 introducción a la programación
Mod 1 introducción a la programación
 
Mod 2 algoritmos
Mod 2 algoritmosMod 2 algoritmos
Mod 2 algoritmos
 
Nomenclatura manual bpmn 2.0
Nomenclatura manual bpmn 2.0Nomenclatura manual bpmn 2.0
Nomenclatura manual bpmn 2.0
 

Último

Índice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWord
Índice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWordÍndice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWord
Índice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWordTelefónica
 
Carta Word y excel: Primer trabajo tecnología
Carta Word y excel: Primer trabajo tecnologíaCarta Word y excel: Primer trabajo tecnología
Carta Word y excel: Primer trabajo tecnologíaSofiaDiaz692624
 
Operadores de Kubernetes: El poder de la automatización
Operadores de Kubernetes: El poder de la automatizaciónOperadores de Kubernetes: El poder de la automatización
Operadores de Kubernetes: El poder de la automatizaciónEdith Puclla
 
VIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHARE
VIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHAREVIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHARE
VIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHAREaljitagallego
 
Combinación de correspondencia Sebastián Pérez
Combinación de correspondencia Sebastián PérezCombinación de correspondencia Sebastián Pérez
Combinación de correspondencia Sebastián PérezSebastinPrez67
 
Certificado de Web Design - Projeto web.
Certificado de Web Design - Projeto web.Certificado de Web Design - Projeto web.
Certificado de Web Design - Projeto web.AntnioOliveira749106
 
VIDEOS DE APOYO-como subir un documento de slideshare.docx
VIDEOS DE APOYO-como subir un documento de slideshare.docxVIDEOS DE APOYO-como subir un documento de slideshare.docx
VIDEOS DE APOYO-como subir un documento de slideshare.docxsamuelvideos
 
Manual de usuario Dongle Zigbee 3.0 Sonoff
Manual de usuario Dongle Zigbee 3.0 SonoffManual de usuario Dongle Zigbee 3.0 Sonoff
Manual de usuario Dongle Zigbee 3.0 SonoffDomotica daVinci
 
Carta de trabajo para los empleados.docx.pdf
Carta de trabajo para los empleados.docx.pdfCarta de trabajo para los empleados.docx.pdf
Carta de trabajo para los empleados.docx.pdfEmanuelminotta
 
Ley de Delitos Informaticos y su aplicación en el sector privado.pptx
Ley de Delitos Informaticos y su aplicación en el sector privado.pptxLey de Delitos Informaticos y su aplicación en el sector privado.pptx
Ley de Delitos Informaticos y su aplicación en el sector privado.pptxBasile
 
Taller 1 sobre operadores tecnologicos.pdf
Taller 1 sobre operadores tecnologicos.pdfTaller 1 sobre operadores tecnologicos.pdf
Taller 1 sobre operadores tecnologicos.pdfAna Lucía Tellez Lugo
 
Silicon_Valley_RSA_2024_Latam_Immersion.pdf
Silicon_Valley_RSA_2024_Latam_Immersion.pdfSilicon_Valley_RSA_2024_Latam_Immersion.pdf
Silicon_Valley_RSA_2024_Latam_Immersion.pdfOBr.global
 
presentacion de una computadora modelo uncs
presentacion de una computadora modelo uncspresentacion de una computadora modelo uncs
presentacion de una computadora modelo uncscarlocarrillocacc
 
VIDEOS DE APOYO PARA TECNOLOGIA LICEO DEP
VIDEOS DE APOYO PARA TECNOLOGIA LICEO DEPVIDEOS DE APOYO PARA TECNOLOGIA LICEO DEP
VIDEOS DE APOYO PARA TECNOLOGIA LICEO DEPAlejandraCasallas7
 
Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...
Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...
Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...Telefónica
 
Situación comparativa de los Ferrocarriles en el mundo y en Colombia
Situación comparativa de los Ferrocarriles en el mundo y en ColombiaSituación comparativa de los Ferrocarriles en el mundo y en Colombia
Situación comparativa de los Ferrocarriles en el mundo y en ColombiaEnrique Posada
 
VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG 9-5
VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG  9-5VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG  9-5
VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG 9-5sarayibanez16
 
Taller crear carta de correspondencia.docx.pdf
Taller crear carta de correspondencia.docx.pdfTaller crear carta de correspondencia.docx.pdf
Taller crear carta de correspondencia.docx.pdfSEBASTIANMICOLTA
 

Último (20)

Índice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWord
Índice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWordÍndice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWord
Índice de libro "Historias Cortas sobre Fondo Azul" de Willy en 0xWord
 
Carta Word y excel: Primer trabajo tecnología
Carta Word y excel: Primer trabajo tecnologíaCarta Word y excel: Primer trabajo tecnología
Carta Word y excel: Primer trabajo tecnología
 
Operadores de Kubernetes: El poder de la automatización
Operadores de Kubernetes: El poder de la automatizaciónOperadores de Kubernetes: El poder de la automatización
Operadores de Kubernetes: El poder de la automatización
 
La píldora de los jueves: Las claves del BREEAM - Leticia Galdos
La píldora de los jueves: Las claves del BREEAM - Leticia GaldosLa píldora de los jueves: Las claves del BREEAM - Leticia Galdos
La píldora de los jueves: Las claves del BREEAM - Leticia Galdos
 
VIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHARE
VIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHAREVIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHARE
VIDEOS DE APOYO PARA CREAR UN BLOG Y COMO SUBIR COSAS A EL DESDE SLIDESHARE
 
Combinación de correspondencia Sebastián Pérez
Combinación de correspondencia Sebastián PérezCombinación de correspondencia Sebastián Pérez
Combinación de correspondencia Sebastián Pérez
 
Certificado de Web Design - Projeto web.
Certificado de Web Design - Projeto web.Certificado de Web Design - Projeto web.
Certificado de Web Design - Projeto web.
 
VIDEOS DE APOYO-como subir un documento de slideshare.docx
VIDEOS DE APOYO-como subir un documento de slideshare.docxVIDEOS DE APOYO-como subir un documento de slideshare.docx
VIDEOS DE APOYO-como subir un documento de slideshare.docx
 
Manual de usuario Dongle Zigbee 3.0 Sonoff
Manual de usuario Dongle Zigbee 3.0 SonoffManual de usuario Dongle Zigbee 3.0 Sonoff
Manual de usuario Dongle Zigbee 3.0 Sonoff
 
Carta de trabajo para los empleados.docx.pdf
Carta de trabajo para los empleados.docx.pdfCarta de trabajo para los empleados.docx.pdf
Carta de trabajo para los empleados.docx.pdf
 
Ley de Delitos Informaticos y su aplicación en el sector privado.pptx
Ley de Delitos Informaticos y su aplicación en el sector privado.pptxLey de Delitos Informaticos y su aplicación en el sector privado.pptx
Ley de Delitos Informaticos y su aplicación en el sector privado.pptx
 
Taller 1 sobre operadores tecnologicos.pdf
Taller 1 sobre operadores tecnologicos.pdfTaller 1 sobre operadores tecnologicos.pdf
Taller 1 sobre operadores tecnologicos.pdf
 
Herramientas tecnologicas para los abogados.pptx
Herramientas tecnologicas para los abogados.pptxHerramientas tecnologicas para los abogados.pptx
Herramientas tecnologicas para los abogados.pptx
 
Silicon_Valley_RSA_2024_Latam_Immersion.pdf
Silicon_Valley_RSA_2024_Latam_Immersion.pdfSilicon_Valley_RSA_2024_Latam_Immersion.pdf
Silicon_Valley_RSA_2024_Latam_Immersion.pdf
 
presentacion de una computadora modelo uncs
presentacion de una computadora modelo uncspresentacion de una computadora modelo uncs
presentacion de una computadora modelo uncs
 
VIDEOS DE APOYO PARA TECNOLOGIA LICEO DEP
VIDEOS DE APOYO PARA TECNOLOGIA LICEO DEPVIDEOS DE APOYO PARA TECNOLOGIA LICEO DEP
VIDEOS DE APOYO PARA TECNOLOGIA LICEO DEP
 
Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...
Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...
Índice del libro: Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición ...
 
Situación comparativa de los Ferrocarriles en el mundo y en Colombia
Situación comparativa de los Ferrocarriles en el mundo y en ColombiaSituación comparativa de los Ferrocarriles en el mundo y en Colombia
Situación comparativa de los Ferrocarriles en el mundo y en Colombia
 
VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG 9-5
VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG  9-5VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG  9-5
VIDEOS DE APOYO, RESUMENES PARA CREAR UN BLOG 9-5
 
Taller crear carta de correspondencia.docx.pdf
Taller crear carta de correspondencia.docx.pdfTaller crear carta de correspondencia.docx.pdf
Taller crear carta de correspondencia.docx.pdf
 

Modelo en cascada pemo

  • 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.