METODO DE CASCADA PURA En un modelo en cascada, un proyecto progresa a través de una secuencia ordenada de pasos partiendo de la especificación de requerimientos

hasta el mantenimiento del mismo. El método realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente etapa, por ejemplo, desde el análisis de requerimientos hasta el diseño. Cuando la revisión 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 planificación porque permite realizarla sin planificación 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 inútil. En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rápido. 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 ningún trabajo de diseño y antes de escribir ningún código. No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, métodos y actividades que abarcan varias etapas de la cascada; estas actividades son difíciles de ajustar en las etapas discontinuas del modelo para un proyecto de desarrollo rápido, el modelo en cascada puede suponer una cantidad excesiva de documentación. El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos serán 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 ingeniería. Es el primero de los propuestos y el más 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 diseño, lo

por ejemplo. es decir. con el consiguiente gasto inútil de recursos. El resultado de las pruebas es el producto final listo para entregar.  No se tiene el producto hasta el final.  No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%). Inconvenientes  Lo peor es la necesidad de tener todos los requisitos al principio.D.  Si se han cometido errores en una fase es difícil volver atrás. Ventajas  La planificación es sencilla.1  Es comparativamente más lento que los demás y el coste es mayor también. Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente. Produce el S. En esta fase se hacen también pruebas de unidad.  Diseño: Su entrada es el S. con lo que puede impacientarse . si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.R. produce módulos. los de reingeniería. Produce el S. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema. (Software Design Document)  Codificación: A partir del S.D.D. Trabaja en base a documentos. Los documentos son:  Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Idealmente.R. Tipos de proyectos para los que es adecuado  Aquellos para los que se dispone de todas las especificaciones desde el principio. .  Proyectos complejos que se entienden bien desde el principio. o El cliente no verá resultados hasta el final. 1.D. (Software Requirements Document).D. cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases.  La calidad del producto resultante es alta.  Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema.  Se está desarrollando un tipo de producto que no es novedoso. esto quiere decir que: o Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega.  Permite trabajar con personal poco cualificado.D. o puede ser que surjan necesidades imprevistas.cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas. la entrada y la salida de cada fase es un tipo de documento específico. es decir.

y a continuación se establece una aproximación a la siguiente interacción. Cada interacción en el método espiral lleva consigo los seis pasos que a continuación se nombran: Determinar objetivos. se genera un plan para manejar los riesgos. Generar las entregas de esa iteración. la culminación del análisis de riesgo resulta una decisión de “seguir” o “no seguir”. En el modelo en espiral. se localizan los riesgos. y también es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseño. En cada bucle alrededor del espiral. alternativas y límites. y elaboración del plan de desarrollo para el ciclo actual. Evaluar alternativas. Método Desarrollo en Espiral Funcionamiento: Se parte de una escala pequeña en medio de la espiral. identificación y resolución de riesgos. restricciones.METODO ESPIRAL Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en miniproyectos. las primeras iteraciones son las menos costosas. alternativas. Se avanza un nivel en el Espiral. Se decide si se sigue o no con el proyecto . y comprobar que son correctas. el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada. Identificar y resolver riesgos. En cada Cuadrante del Método espiral se realiza las siguientes actividades: Planificación: Determinación de objetivos. y después se comienza a trabajar en el siguiente nivel: Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas. Análisis de Riesgos: Evaluación de las alternativas. se comprueba que se tiene lo que se desea. Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos. Cada iteración supone que el proyecto pasa a una escala superior. Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estén controlados. la implementación del producto y la prueba del mismo. Después de controlar todos los riesgos más importantes.

La Ingeniería de software. modelos de estimación de esfuerzo y tiempo que se consume en hacer productos software. autor de diversos artículos de ingeniería del software. etc. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software se suceden de forma lineal. 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. Las actividades de este modelo se conforman en una espiral. pero no necesariamente debe ser así. [editar]En cada vuelta o iteración hay que tener en cuenta Los Objetivos: Qué necesidad debe cubrir el producto. Para ello. requisitos a cumplir. se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral. desde su concepción inicial. Valoración de resultados. Desarrollar y Verificar: Programar y probar el software. etc. Formas de gestión del sistema. Si el cliente quiere seguir haciendo mejoras en el software. Este modelo fue propuesto por Boehm en 1988. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada. Básicamente consiste en una serie de ciclos que se repiten en forma de espiral. Riesgo asumido con cada alternativa. comenzando desde el centro. sino que las siguientes se eligen en función del análisis de riesgo. puesta en marcha y posterior mantenimiento. El primer modelo concebido fue el de Royce. Las actividades no están fijadas a priori.Ingeniería: Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada. . Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. El Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. y Modelos de Ciclo de Vida. prototipo. Evaluación por el cliente. con el agregado de gestión de riegos. Boehm. comenzando por el bucle interior. hasta la retirada del producto. desde diferentes puntos de vista como pueden ser: Características: experiencia del personal. A estos modelos se les denomina «modelos de ciclo de vida del software». Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa. se comienza mirando las posibles alternativas de desarrollo. más comúnmente conocido como desarrollo en cascada o desarrollo lineal secuencial. utilizado generalmente en la Ingeniería de software. así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo. pasando por su desarrollo. en la que cada bucle o iteración representa un conjunto de actividades. se opta por la de riesgo más asumible y se hace un ciclo de la espiral. El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988. ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral.

Tareas Para cada ciclo habrá cuatro actividades: . Al ser un modelo de Ciclo de Vida orientado a la gestión 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. evolutivo. como formal. verificar y validar(probar) Tareas de la actividad propia y de prueba. Radial: Indica el aumento del coste del proyecto.Determinar Objetivos .[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. el que puede ser cualquiera de los otros existentes. la radial y la angular: Angular: Indica el avance del proyecto del software dentro de un ciclo. Dependiendo del resultado de la evaluación de los riesgos. Así si por . La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones. Hay una cosa que solo se hace una vez: planificación inicial o previa. cascada. especificación. Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. Fijar las restricciones.Desarrollar y probar Determinar o fijar objetivos Fijar también los productos definidos a obtener: requerimientos. ya que con cada nueva iteración se pasa más tiempo desarrollando. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser. etc. por ejemplo. la creación de un Sistema Operativo. Análisis del riesgo Desarrollar.Planificación . Análisis de alternativas e identificación resolución de riesgos. manual de usuario.Análisis del riesgo . se elige un modelo para el desarrollo.

ejemplo si los riesgos en la interfaz de usuario son dominantes. En este contexto la evaluación de riesgos es de la mayor importancia y. etc. Modelo en espiral WIN WIN. para grandes proyectos. ya que este ciclo de vida no es rígido ni estático. Planificar Revisamos todo lo hecho. y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. Une los mejores elementos de los restantes modelos. un desarrollo basado en transformaciones formales podría ser el más apropiado. un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV . Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento. La dimensión angular mide el grado de avance del proyecto. Si lo riesgos de protección son la principal consideración. Desventajas Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificación de riesgos Inconvenientes: Planificar un proyecto con esta metodología es a menudo imposible. Mecanismos de control La dimensión radial mide el coste. Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología. Variaciones del Modelo En Espiral Modelo en Espiral Típico de seis regiones. debido a la incertidumbre en el número de iteraciones que serán necesarias. dicha evaluación requiere la intervención de profesionales de gran experiencia. evaluándolo. Ventajas El análisis del riesgo se hace de forma explícita y clara.

Sign up to vote on this title
UsefulNot useful