1.
UNIVERSIDAD TECNOLÓGICA DE LA REGIÓN NORTE DE GUERRERO<br />TECNOLOGIAS DE LA INFORMACIÓN Y COMUNICACIÓN<br />INGENIERIA DE SOFTWARE<br />MODELO CASCADA<br />INTEGRANTES:MARIA SILVIA OCAMPO GILES<br /> JOAO IVAN GARDUÑO SALGADO<br /> LAURA BRITO ROMAN<br />MARTHA DE JESUS SERRANO<br /> LUIS ALBERTO MELCHOR HERNANDEZ<br />13 de Septiembre del 2010<br />

2.
Modelo Cascada<br />

3.
DEFINICION<br />Algunas veces llamado ciclo de vida clásico, sugiere un enfoque sistemático secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y continua con la planeación, el modelado, la construcción y despliegue para culminar el soporte del software terminado.<br />

4.
Los principios básicos del modelo de cascada son los siguientes:<br /><ul><li>El proyecto está dividido en fases secuenciales.

5.
Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.

6.
Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una documentación escrita, a través de comentarios y aprobación del usuario y la tecnología de la información de gestión al final de la mayoría de las fases antes de comenzar la próxima fase.</li></li></ul><li>FASES<br />

7.
<ul><li>Existen ocasiones en que los requisitos de un problema se entiende de una manera razonable:

8.
Cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal.

9.
Es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente.

10.
Ejemplo de esto seria: una adaptación a un software contable debido a los cambios en las regulaciones del gobierno.

11.
Esto puede ocurrir solo cuando los requerimientos están bien definidos</li></ul>DEFINICION DEL PROBLEMA<br />

12.
ANÁLISIS DE REQUERIMIENTOS<br /><ul><li>Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir.

13.
De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.</li></li></ul><li>ESPECIFICACIONES<br />(Diseño del sistema)<br /><ul><li>Se organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo.

14.
Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado.

15.
El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones</li></li></ul><li>DISEÑO DEL PROGRAMA<br /><ul><li> Se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario.

16.
Análisis necesarios para saber que herramientas usar en la etapa de Codificación.

17.
Es la fase de programación o implementación propiamente dicha.

18.
Se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.</li></li></ul><li>IMPLEMENTACIÓN<br /><ul><li>El software obtenido se pone en producción.

19.
Se implantan los niveles software y hardware que componen el proyecto.

20.
La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto.

21.
Fase final del proyecto.

22.
Durante la explotación del sistema de software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras.

23.
Todo ello se recoge en los Documentos de Cambios.</li></li></ul><li>

24.
PRUEBAS<br /><ul><li>Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente.

25.
Las pruebas de Software, testing o beta testing es un proceso usado para identificar posibles fallos.

26.
En general, los usuarios distinguen entre errores de programación ( o “bugs” ) y defectos de forma.

27.
En un defecto de forma, el programa no realiza lo que el usuario espera.</li></li></ul><li> OPERACIONES Y MANTENIMIENTO<br /><ul><li>El Software sufrirá cambios después de que se entrega al cliente.

28.
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).

29.
Que el cliente requiera ampliaciones funcionales o del rendimiento.</li></li></ul><li>Desventajas<br />En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.<br />El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera.<br /> Esto es la base para que funcione bien.<br />1. Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.<br />2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.<br /> Ventajas<br />Es bien organizado.<br />Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar.<br />1. Modelo y planificación fácil y sencillos.<br />2. Sus fases son conocidas por los desarrolladores.<br />3. Los usuarios lo pueden comprender fácilmente.<br />

30.

31.
CONCLUSION<br />(General)<br />La metodología de cascada ordena rigurosamente las etapas del ciclo del software, es decir en este modelo se tienen que terminar las fases en un orden, para poder pasar a la siguiente etapa. Este modelo es el mas usado en la actualidad .<br />El modelo de cascada es exitoso cuando se tienen bien específicos los requerimientos del software y se conozcan las herramientas a utilizar.<br />

32.
CONCLUSION<br />(Martha)<br />La metodología de cascada ordena rigurosamente las etapas del ciclo del software, es decir en este modelo se tienen que terminar las fases en un orden, para poder pasar a la siguiente etapa. Este modelo es el mas usado en la actualidad .<br />El modelo de cascada es exitoso cuando se tienen bien específicos los requerimientos del software y se conozcan las herramientas a utilizar.<br />El modelo de cascada tarda mucho tiempo en resolver un software, ya que hasta que no se tenga bien el software ,no se opera el software.<br />

33.
CONCLUSION<br />(Silvia)<br /><ul><li>Lo que puedo mencionar es que el modelo cascada es una de las metodologías que al llevarse a cabo se debe de llevar a cabo fase por fase.

34.
Se debe de tener bien planeado lo que se pretende realizar.

35.
Realizar un análisis detallado.

36.
No empezar la siguiente fase si aun no se termina la anterior</li></li></ul><li>CONCLUSION<br />(Joao)<br /><ul><li>En conclusión el modelo de cascada nos permite realizar una organización más fácil de comprender tratando de no mezclar las diferentes fases del modelo y así nos permite organizar el tipo de proyecto que pretende solucionar es decir donde se conozcan todos los requisitos especificados, esto quiere decir que es necesario que se especifiquen muy bien los requerimientos…

37.
Para esto los proyectos también es necesario conocer las herramientas que se implementaran.</li></li></ul><li>CONCLUSION<br />(Laura)<br />La metodología del modelo de cascada es mas eficiente y creativo, ya que es entendible y cuenta con un proceso de mejoras hacia el proyecto.<br />Es el método mas fácil de realizar ya que cuenta con fases que siguen un orden en especifico, ya que si no se cumple con el orden que lleva el proyecto puede llegar a tener algunos problemas durante su ejecución y puede no ser exitoso.<br />Para que este método sea exitoso en el proyecto requerido se debe seguir un orden en especifico y se deben conocer las herramientas a utilizar, para que se sepa que herramientas vamos a utilizar y saber cual es el tiempo que nos vamos a llevar durante el proceso, así como saber organizarlo tal y como nos pide cada una de sus faces y poder llevar la planeación en un orden y poder terminar con la construcción del proyecto.<br />

38.
CONCLUSION<br />(Luis)<br /> Podríamos considerarlo como el mas sencillo de utilizar, aunque por su alto numero de inconvenientes puede dudarse de su eficacia, siendo el principal el ser un modelo secuencial.<br /> Si este sistema no es bien conocido o difícil de analizar, esta fase puede alargarse demasiado.<br /> Se debe tener completo conocimiento de el proyecto a realizar asi como del sistema, para poder llevar el trabajo a un fin exitoso, y evitar errores en el desarrollo.<br />

39.
BIBLIOGRAFIA<br />http://scruz334.blogspot.es/tags/Cascada/<br />http://www.bsgmexico.com.mx/01-metodologia.html<br />Ingeniería del software un enfoque practico<br />R.Pressman<br />http://www.slideshare.net/masilog/expo-modelocascada<br />