SlideShare una empresa de Scribd logo
1 de 16
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.
DESARROLLO EN CASCADA

Ingeniería y Análisis
    del Sistema

                        Análisis de los
                         Requisitos


                                          Diseño

                                                   Codificación

                                                                  Prueba

                                                                           Mantenimiento
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
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.
Utilidad de la Especificación

       Requisitos
      del Software




                        Contrato con
                         el Cliente
       Documento
    de Especificación
     de Requisitos       Guía para los
                        desarrolladores
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
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.
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.
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.
   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.
• Existen varios tipos de
Pruebas:

1. Pruebas de unidad
2. Pruebas de integración
3. Pruebas de sistema.
4. Pruebas de aceptación
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.
    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
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.
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

Más contenido relacionado

La actualidad más candente

Modelo cascada
Modelo cascadaModelo cascada
Modelo cascada
masilog
 
DiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del SoftwareDiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del Software
lcastillo110
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmi
Sandrea Rodriguez
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de software
sergio
 

La actualidad más candente (20)

Modelo cascada
Modelo cascadaModelo cascada
Modelo cascada
 
Modelos o Ciclos de vida de software
Modelos o Ciclos de vida de softwareModelos o Ciclos de vida de software
Modelos o Ciclos de vida de software
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrente
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Metodologia Incremental
Metodologia IncrementalMetodologia Incremental
Metodologia Incremental
 
Cuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de softwareCuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de software
 
Modelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiralModelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiral
 
10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes
 
DiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del SoftwareDiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del Software
 
Pruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionPruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacion
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmi
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de software
 
Entrega por etapas
Entrega por etapasEntrega por etapas
Entrega por etapas
 
Modelo de prototipo
Modelo de prototipoModelo de prototipo
Modelo de prototipo
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Metodologías para el desarrollo de aplicaciones móviles
Metodologías para el desarrollo de aplicaciones móvilesMetodologías para el desarrollo de aplicaciones móviles
Metodologías para el desarrollo de aplicaciones móviles
 
Iso 25000
Iso 25000Iso 25000
Iso 25000
 
Herramientas case
Herramientas caseHerramientas case
Herramientas case
 

Similar a Modelo cascada

Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
mendez45
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
Evelin Oña
 
02 unidad i proceso
02 unidad i   proceso02 unidad i   proceso
02 unidad i proceso
victdiazm
 

Similar a Modelo cascada (20)

Modelo
ModeloModelo
Modelo
 
Trabajo espoch
Trabajo espochTrabajo espoch
Trabajo espoch
 
Modelos de procesos de software(completo)
Modelos de procesos de software(completo)Modelos de procesos de software(completo)
Modelos de procesos de software(completo)
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
 
Análisis del Proyecto de Software
Análisis del Proyecto de SoftwareAnálisis del Proyecto de Software
Análisis del Proyecto de Software
 
Inf 162
Inf 162Inf 162
Inf 162
 
MODELO DE CASCADA quipo 3 inovadores.pptx
MODELO DE  CASCADA quipo 3 inovadores.pptxMODELO DE  CASCADA quipo 3 inovadores.pptx
MODELO DE CASCADA quipo 3 inovadores.pptx
 
Unidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareUnidad 1 Ingenieria de software
Unidad 1 Ingenieria de software
 
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
 
02 unidad i proceso
02 unidad i   proceso02 unidad i   proceso
02 unidad i proceso
 
Presentaciondefundamentosdesoftware
PresentaciondefundamentosdesoftwarePresentaciondefundamentosdesoftware
Presentaciondefundamentosdesoftware
 
Tecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwareTecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.software
 
Sqm
SqmSqm
Sqm
 
Cascadas
CascadasCascadas
Cascadas
 
Analisis requerimientos jose_fernandez
Analisis requerimientos jose_fernandezAnalisis requerimientos jose_fernandez
Analisis requerimientos jose_fernandez
 
Adrian adrianza
Adrian adrianzaAdrian adrianza
Adrian adrianza
 
Unidad 4
Unidad 4Unidad 4
Unidad 4
 
Etapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del SoftwareEtapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del Software
 
2017.10.16-senati-powerpoint sesion8.pptx
2017.10.16-senati-powerpoint sesion8.pptx2017.10.16-senati-powerpoint sesion8.pptx
2017.10.16-senati-powerpoint sesion8.pptx
 

Más de Avelino Felipe Policarpio (15)

Psp
PspPsp
Psp
 
Proceso de desarrollo unificado
Proceso de desarrollo unificadoProceso de desarrollo unificado
Proceso de desarrollo unificado
 
Modelo incremental
Modelo incrementalModelo incremental
Modelo incremental
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativo
 
Preguntas del examen
Preguntas del examenPreguntas del examen
Preguntas del examen
 
Reseña sobre las características del software
Reseña sobre las características del softwareReseña sobre las características del software
Reseña sobre las características del software
 
El ciclo de vida del desarrollo de sistemas
El ciclo de vida del desarrollo de sistemasEl ciclo de vida del desarrollo de sistemas
El ciclo de vida del desarrollo de sistemas
 
Sistema informacion
Sistema informacionSistema informacion
Sistema informacion
 
Sintesis
SintesisSintesis
Sintesis
 
Protoboard
ProtoboardProtoboard
Protoboard
 
Instituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepecInstituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepec
 
Protoboard
ProtoboardProtoboard
Protoboard
 
Instituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepecInstituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepec
 
Instituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepecInstituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepec
 
Instituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepecInstituto tecnologico de tuxtepec
Instituto tecnologico de tuxtepec
 

Modelo cascada

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