UNIVERSIDAD ESTATAL DE MILAGRO

TRABAJO DE INVESTIGACIN ADMINISTRACIN DE PROYECTOS

TEMA: METODOLOGA EN CASCADA

ALUMNO: GISELLA SERRANO SILVA

DOCENTE: ING. RICHARD RAMREZ A.

9NO. SEMESTRE DE INGENIERA EN SISTEMAS COMPUTACIONALES

PERIODO LECTIVO 2010

Metodologa en Cascada
Tambin conocido como modelo clsico, modelo tradicional o modelo lineal secuencial. El mtodo de la cascada es considerado como el enfoque clsico para el ciclo de vida del desarrollo de sistemas, se puede decir que es un mtodo puro que implica un desarrollo rgido y lineal Un ejemplo de la metodologa en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos Diseo del sistema Diseo del programa Codificacin Pruebas Implantacin Mantenimiento

Se inicia con la especificacin de requerimientos del cliente, continua con la planificacin, el modelado, la construccin y el despliegue para finalizar en el enfoque del software. El modelo est dirigido por documentos y no proporciona resultados tangibles de software hasta el final del ciclo de vida de algunas herramientas. El diseo en cascada es una secuencia definida de los acontecimientos y los resultados finales para proporcionar una estructura para cualquier proyecto que siga el contenido especfico y detallado.Puede ser apropiado para proyectos de software que son estables especialmente cuando sus requisitos no cambian. Este modelo requiere tambin que los implementadores sigan el bien hecho, el diseo completo de precisin, asegurando as la integracin de los ingresos del sistema sin problemas. Es caracterizado por ordenar de manera rigurosa las etapas del ciclo de vida de software, dado que el comienzo de cada etapa debe esperar a la finalizacin de la inmediata anterior. Cuando la revisin determina que el proyecto no est listo para pasar a la siguiente etapa, permanece en la etapa actual hasta que est preparado. Y debido a que el proceso est planeado es ms fcil determinar costos y los plazos. Este modelo puede ser visto como un modelo con forma de cascada de agua con varios saltos, en la que cada salto representa cada una de las fases del ciclo de vida. (Ver anexo 1) Cada una de las tareas se evala por separado y de igual manera el equipo que lo desarrolla es diferente. Para decidir implantar la metodologa en cascada se necesita hacer un anlisis de la situacin, por ejemplo: si el cliente quiere intervenir en el proceso una vez iniciado, este mtodo no sera el indicado, sino un mtodo iterativo. Para proceder al diseo primero hay que determinar la especificacin de requisitos los cuales no pueden ser modificados tras el cierre de sesin. Una modificacin o cambio mediante la ejecucin de alguna de las fases, implicara reiniciar desde el principio todo el ciclo completo, esto implicara mayor inversin de tiempo y desarrollo. Asegurarse en el inicio de que las necesidades y el diseo son los correctos nos ahorrara tiempo y esfuerzo. El modelo en cascada proporciona un enfoque estructurado, progresa linealmente a travs de sus fases por lo que resulta fcil de entender. El proceso de desarrollo en cascada se lo realiza frecuentemente en los proyectos de gobierno y en proyectos que requieran poca innovacin. Algunas de las variantes del modelo en cascada son ms utilizadas debido a su simplicidad y eficacia en software de pequeo y mediano porte.

Estas variantes producen alguna retroalimentacin entre etapas, ofrece la oportunidad de realizar cambios o evoluciones durante el ciclo de vida del software, permitiendo retroceder de una etapa a la anterior o incluso poder saltar a otras anteriores si es requerido. (Ver Anexo 2) En el modelo Cascada y Cascada Realimentado no se tiene en cuenta la naturaleza evolutiva del software, se plantea como esttico con requisitos bien conocidos y definidos desde el inicio. A pesar de que el mtodo prev ciclos de retroalimentacin, la mayora de las organizaciones que aplica este modelo de proceso lo trata como si fuera lineal. La metodologa en cascada es esencialmente: 1. 2. 3. 4. 5. 6. 7. El inicio y el alcance del proyecto La planificacin del proyecto( calendario, recursos necesarios, costo) Definicin de las necesidades del negocio y el anlisis en detalle de la solucin La creacin de la solucin Prueba que la solucin funciona La entrega de la solucin a su pblico objetivo Cierre del proyecto

Ventajas Permite la departamentalizacin y control de gestin. El horario se establece con los plazos normalmente adecuados para cada etapa de desarrollo. Este proceso conduce a entregar el proyecto a tiempo. Es sencilla y facilita la gestin de proyectos. Permite tener bajo control el proyecto. Limita la cantidad de interaccin entre equipos que se produce durante el desarrollo

Desventajas No conocer si la solucin es correcta hasta estar cerca de su lanzamiento Poco tiempo para corregir fallas Depuracin complicada Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos Es necesaria la paciencia del cliente El cliente podra detectar un error El proceso es lento y pesado

Es muy difcil cuando una aplicacin est en fase de prueba y se decide volver atrs y cambiar algo que no se pens en la etapa de concepto. En este caso lo ideal no es aplicar el mtodo de cascada sino las alternativas a este mtodo que incluyen el desarrollo de aplicaciones comunes (JAD), el desarrollo rpido de aplicaciones (RAD), sincronizacin y estabilizar, construir y reparar, y el modelo en espiral. En la prctica el modelo en cascada no cumple las expectativas, ya que en muchos casos el cliente suele realizar cambios una vez iniciado el proceso, adems como el solicitar detalles del avance del desarrollo estos detalles hacen de la las organizaciones denieguen su uso. El fracaso del modelo de cascada Las razones principales son: Los clientes quieren ver el producto a medida que se desarrolla El cliente no puede validar el producto a medida que lo desarrollamos El realizar la pruebas correspondientes en etapas avanzadas del desarrollo

Inseguridad de la calidad del desarrollo de los No poder tomas decisiones por la falta de avances o resultados No poder acceder a repentinos cambios que solicite el cliente Las actividades estn estrictamente ligadas causando as impedir que una actividad empiece antes de terminar totalmente la anterior, provocando invertir algn tiempo de desarrollo innecesariamente Aislar a los especialistas.

En efecto, el modelo de cascada no es del todo compatible con el desarrollo de software, pero en ocasiones en que el modelo de cascada s funciona. Por ejemplo, en proyectos muy cortos (un mes o dos), puede funcionar, aunque es mejor utilizar los mtodos incrementales. Crticas No refleja realmente el proceso de desarrollo del software. Ya que la mayora de los que desarrollan proyectos no cumple con este lineamiento. Se tarda mucho tiempo en pasar por todo el ciclo Dificulta la comunicacin industria del software con el usuario final, debido a que el usuario no puede intervenir en el proceso de desarrollo. Los diseadores no pueden conocer las dificultades de ejecucin en el futuro cuando se escribe un diseo para un producto de software sin aplicarse El mantenimiento se realiza en el cdigo fuente Las revisiones de proyectos de gran complejidad son muy difciles Impone una estructura de administracin de proyectos Para conocer los detalles de los sistemas primero hay que llegar al avance en la aplicacin.

Conclusin La aplicacin de la metodologa en cascada se orienta mejor al desarrollo de proyectos de corto plazo, de poca innovacin y proyectos definitivos y detallados. Para comenzar la aplicacin de la metodologa en cascada se necesita tener el anlisis de los requerimientos bien definidos, el resultado del desarrollo depender de que estos requerimientos sean los adecuados para satisfacer la necesidad del proyecto. Se caracteriza por cumplir un orden secuencial en el desarrollo de sus tareas esto implica retardar el avance del proyecto ya que cada etapa inicia cuando haya finalizado la anterior siempre y cuando se haya realizado la evaluacin respectiva y resuelto los errores en caso de que los hubiera tenido. Los resultados del proyecto solo se pueden conocer a partir de que se llegue a la aplicacin, hasta entonces el cliente deber tener paciencia para esperar los resultados.

Anexos
ANEXO 1

Modelo en cascada puro o secuencial

ANEXO 2

Modelo en cascada realimentado para el ciclo de vida

Bibliografia
http://articles.techrepublic.com.com/5100-10878_11-1046507.html http://en.wikipedia.org/wiki/Waterfall_model http://es.wikipedia.org/wiki/Software http://es.wikipedia.org/wiki/Desarrollo_en_cascada http://www.mariosalexandrou.com/methodologies/waterfall.asp http://business-project-management.suite101.com/article.cfm/project_management_made_easy_for_managers http://metodologiasi.blogspot.com/2009_03_01_archive.html Libro: Ingeniera de software un enfoque practico, Autor: Roger Pressman, sexta edicin