Você está na página 1de 6

METODO DE CASCADA PURA En un modelo en cascada, un proyecto progresa a travs de una secuencia ordenada de pasos partiendo de la especificacin de requerimientos

hasta el mantenimiento del mismo. El mtodo realiza una revisin al final de cada etapa para determinar si est preparado para pasar a la siguiente etapa, por ejemplo, desde el anlisis de requerimientos hasta el diseo. Cuando la revisin determina que el proyecto no est listo pasar a la siguiente, permanece en la etapa actual hasta que est preparado. El modelo en cascada est dirigido por documentos. Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo. Ayuda a minimizar los gastos de la planificacin porque permite realizarla sin planificacin porque permite realizarla sin problemas. Funciona especialmente bien si se dispone de personal poco cualificado o dispone de personal poco cualificado o inexperto, porque presenta el proyecto inexperto, porque presenta el proyecto con una estructura que ayuda a minimizar con una estructura el esfuerzo intil. En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rpido. Incluso en los casos en los que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada (con retroceso) pueden funcionar mejor. Las desventajas del modelo se centran en las dificultades para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningn trabajo de diseo y antes de escribir ningn cdigo. No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, mtodos y actividades que abarcan varias etapas de la cascada; estas actividades son difciles de ajustar en las etapas discontinuas del modelo para un proyecto de desarrollo rpido, el modelo en cascada puede suponer una cantidad excesiva de documentacin. El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresin de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos sern entregados a tiempo.

Ciclo de vida en Cascada El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniera. Es el primero de los propuestos y el ms ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados as). Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseo, lo

cual significa que se harn los cambios necesarios en la codificacin y se tendrn que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Despus de cada etapa se realiza una revisin para comprobar si se puede pasar a la siguiente. Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento especfico. Idealmente, cada fase podra hacerla un equipo diferente gracias a la documentacin generada entre las fases. Los documentos son: Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document). Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document) Codificacin: A partir del S.D.D. produce mdulos. En esta fase se hacen tambin pruebas de unidad. Pruebas: A partir de los mdulos probados se realiza la integracin y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar. Ventajas La planificacin es sencilla. La calidad del producto resultante es alta. Permite trabajar con personal poco cualificado. Inconvenientes Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas. Si se han cometido errores en una fase es difcil volver atrs. No se tiene el producto hasta el final, esto quiere decir que: o Si se comete un error en la fase de anlisis no lo descubrimos hasta la entrega, con el consiguiente gasto intil de recursos. o El cliente no ver resultados hasta el final, con lo que puede impacientarse . No se tienen indicadores fiables del progreso del trabajo (sndrome del 90%). 1.1 Es comparativamente ms lento que los dems y el coste es mayor tambin. Tipos de proyectos para los que es adecuado Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniera. Se est desarrollando un tipo de producto que no es novedoso. Proyectos complejos que se entienden bien desde el principio.

METODO ESPIRAL Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en miniproyectos. Cada mini proyecto se centra en uno o ms riesgos importantes hasta que todos estn controlados. Despus de controlar todos los riesgos ms importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada. Mtodo Desarrollo en Espiral Funcionamiento: Se parte de una escala pequea en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuacin se establece una aproximacin a la siguiente interaccin. Cada iteracin supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y despus se comienza a trabajar en el siguiente nivel: Con cada iteracin a travs del espiral se construye sucesivas versiones de software cada vez ms completas. En cada bucle alrededor del espiral, la culminacin del anlisis de riesgo resulta una decisin de seguir o no seguir. Cada interaccin en el mtodo espiral lleva consigo los seis pasos que a continuacin se nombran: Determinar objetivos, alternativas y lmites, Identificar y resolver riesgos, Evaluar alternativas, Generar las entregas de esa iteracin, y comprobar que son correctas. En el modelo en espiral, las primeras iteraciones son las menos costosas. Supone menos gasto desarrollar el concepto de operacin que realizar el desarrollo de los requerimientos, y tambin es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseo, la implementacin del producto y la prueba del mismo. En cada Cuadrante del Mtodo espiral se realiza las siguientes actividades: Planificacin: Determinacin de objetivos, alternativas, restricciones, y elaboracin del plan de desarrollo para el ciclo actual.

Anlisis de Riesgos: Evaluacin de las alternativas, identificacin y resolucin de riesgos. Se decide si se sigue o no con el proyecto

Ingeniera: Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc. Evaluacin por el cliente, Valoracin de resultados. El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniera de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior. La Ingeniera de software, se vale y establece a partir de una serie de modelos que establecen y muestran las distintas etapas y estados por los que pasa un producto software, desde su concepcin inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina modelos de ciclo de vida del software. El primer modelo concebido fue el de Royce, ms comnmente conocido como desarrollo en cascada o desarrollo lineal secuencial. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software se suceden de forma lineal. Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de esfuerzo y tiempo que se consume en hacer productos software; y Modelos de Ciclo de Vida; ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo ms asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorndose con otro nuevo ciclo. Este modelo fue propuesto por Boehm en 1988. Bsicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser as. El Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemticos del Modelo Cascada, con el agregado de gestin de riegos. [editar]En cada vuelta o iteracin hay que tener en cuenta Los Objetivos: Qu necesidad debe cubrir el producto. Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: Caractersticas: experiencia del personal, requisitos a cumplir, etc. Formas de gestin del sistema. Riesgo asumido con cada alternativa. Desarrollar y Verificar: Programar y probar el software.

[editar]Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular: Angular: Indica el avance del proyecto del software dentro de un ciclo. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin se pasa ms tiempo desarrollando. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un Sistema Operativo. Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos. Tareas Para cada ciclo habr cuatro actividades: - Determinar Objetivos - Anlisis del riesgo - Planificacin - Desarrollar y probar Determinar o fijar objetivos Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario. Fijar las restricciones. Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificacin inicial o previa. Anlisis del riesgo Desarrollar, verificar y validar(probar) Tareas de la actividad propia y de prueba. Anlisis de alternativas e identificacin resolucin de riesgos. Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As si por

ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal consideracin, un desarrollo basado en transformaciones formales podra ser el ms apropiado. Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. Mecanismos de control La dimensin radial mide el coste. La dimensin angular mide el grado de avance del proyecto. Variaciones del Modelo En Espiral Modelo en Espiral Tpico de seis regiones. Modelo en espiral WIN WIN. Ventajas El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc. Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico. Desventajas Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos Inconvenientes: Planificar un proyecto con esta metodologa es a menudo imposible, debido a la incertidumbre en el nmero de iteraciones que sern necesarias. En este contexto la evaluacin de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluacin requiere la intervencin de profesionales de gran experiencia. El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV

Você também pode gostar