Your SlideShare is downloading. ×
0
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Modelo
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Modelo

1,477

Published on

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,477
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
60
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. INGENIERIA DE SOFTWARE<br />TEMA: MODELO DE<br /> CASCADA<br />
  • 2. INTRODUCCION<br />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.<br />
  • 3. Ingeniería y Análisis del Sistema<br />Análisis de los Requisitos<br />Diseño<br />Codificación<br />Prueba<br />Mantenimiento<br />DESARROLLO EN CASCADA<br />
  • 4. INGENIERIA Y ANALISIS DEL SISTEMA <br />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<br />
  • 5. ANALISIS DE REQUISITOS<br />el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. <br />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.<br />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.<br />
  • 6. ANÁLISIS<br />Contrato con<br />el Cliente<br />Guía para los<br />desarrolladores<br />Utilidad de la Especificación<br />Requisitos<br />del Software<br />Documento<br />de Especificación<br />de Requisitos<br />
  • 7. Cualidades y Principios<br />La especificación de requisitos debe tener las siguientes cualidades:<br />comprensible,<br />precisa, completa y consistente,<br />no ambigua.<br />Los principales principios a aplicar:<br />separación de intereses <br />distintos puntos de vista,<br />abstracción <br />de lo general a los detalles,<br />modularización <br />datos, funciones y control<br />
  • 8. DISEÑO<br />Como resultado surge el SDD(Documento de Diseño de Software)<br />El diseño describe cómo hará el sistema para satisfacer sus requisitos.<br />Es la descomposición del sistema en componentes.<br />Arquitectura del sistema:<br />¿qué hacen las componentes?<br />¿cómo interactúan?<br />Las componentes más grandes son divididas iterativamente en sub-componentes:<br />diseño de alto nivel,<br />diseño detallado.<br />
  • 9. CODIFICACION<br />El diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. <br />Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.<br />Se crean librerías ,componentes y bibliotecas.<br />
  • 10. PRUEBA<br />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.<br />
  • 11. Las empresas pueden establecer estándares de pruebas:<br />definición de un plan de pruebas,<br />criterios de pruebas (caja negra, caja blanca),<br />criterios de fin de las pruebas,<br />administración de los casos de prueba.<br />La depuración (“debugging”) es parte de esta etapa.<br />Es el control de calidad llevado a cabo en esta etapa.<br />Inspecciones para comprobar adhesión a los estándares.<br />
  • 12. <ul><li>Existen varios tipos de Pruebas: </li></ul>Pruebas de unidad<br />Pruebas de integración<br />Pruebas de sistema.<br />Pruebas de aceptación<br />
  • 13. MANTENIMIENTO<br />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. <br />
  • 14. Tipos de mantenimientos:<br />Mantenimiento Preventivo y Perfectivo<br />Mantenimiento Correctivo <br />Mantenimiento Evolutivo <br />El análisis de requisitos es una fuente de problemas, especialmente para los usuarios finales:<br />los requisitos son difíciles de especificar,<br />los requisitos cambian con el tiempo.<br />Muchos errores no son resueltos hasta después de instalar el software en el cliente:<br />es más caro corregir errores cuanto más tarde se detectan.<br />Los cambios son (casi) siempre posibles pero también (casi) siempre muy difíciles<br />
  • 15. VENTAJAS<br />Se tiene todo bien organizado y no se mezclan las fases.<br />Es perfecto para proyectos rígidos y además donde se especifiquen bien los requerimientos y conozca muy bien las herramientas a utilizar.<br />
  • 16. Críticas al Modelo de Cascada<br />El modelo de Cascada tiene dos grandes aportes:<br />debe aplicarse disciplina, planificación y administración al proceso de desarrollo de software,<br />la construcción del sistema en sí se pospone hasta que los objetivos del sistema sean suficientemente comprendidos.<br />Pero tiene también serias desventajas:<br />lineal<br />rígido<br />

×