Metodologías de Desarrollo Tradicionales: Cascada, Modelo en V y Espiral.
INTRODUCCIÓN
Las metodologías tradicionales o rígidas en el desarrollo del software, son aquellas que establecen una disciplina de trabajo sobre el proceso de desarrollo del software, con el propósito de alcanzar un software más eficiente.
Se caracterizan por definir y establecer total y rígidamente todos y cada uno de los requisitos al inicio de los proyectos de ingeniería de software. Estas metodologías son poco flexibles y no permiten realizar cambios.
El método tradicional funciona aplicando un enfoque lineal donde las etapas del transcurso de desarrollo del software deben complementarse secuencialmente. Es decir, una etapa debe completarse antes de que comience la siguiente, dichas etapas reúnen la recopilación de requisitos y documentación.
Modelo en cascada
El término “waterfall model” hace referencia a un procedimiento secuencial que permite representar un proyecto en base a unas fases que se suceden entre sí.
¿Qué es el modelo en cascada?
El desarrollo en cascada (en inglés, waterfall model) es un procedimiento lineal que se caracteriza por dividir los procesos de desarrollo en sucesivas fases de proyecto. Al contrario que en los modelos iterativos, cada una de estas fases se ejecuta tan solo una vez. Los resultados de cada una de las fases sirven como hipótesis de partida para la siguiente. El waterfall model se utiliza, especialmente, en el desarrollo de software.
¿Cómo funciona el modelo en cascada?
El desarrollo del modelo se atribuye al teórico de la informática Winston W. Royce. Sin embargo, Royce no es el inventor de este modelo. Muy al contrario, en su ensayo de 1970 titulado Managing the Development of Large Software Systems, el teórico presenta una reflexión crítica acerca de los procedimientos lineales. A modo de alternativa, Royce presenta un modelo iterativo incremental en el que cada una de las fases se basa en la anterior y verifica los resultados de esta.
Royce propone un modelo compuesto por siete fases que se ha de ejecutar en diversas vueltas (iteraciones):
Requisitos de sistema
Requisitos de software
Análisis
Diseño
Implementación
Prueba
Servicio
El procedimiento popularmente conocido como waterfall model se basa en las fases definidas por Royce, pero solo prevé una iteración.
El modelo en cascada en el desarrollo de software - IONOS
En la práctica, se aplican diversas versiones del modelo. Los más habituales son los modelos que dividen los procesos de desarrollo en cinco fases. En ocasiones, las fases 1, 2 y 3 definidas por Royce se integran en una sola fase de proyecto a modo de análisis de los requisitos.
Análisis: planificación, análisis y especificación de los requisitos.
Diseño: diseño y especificación del sistema.
Implementación: programación y pruebas unitarias.
Verificación: integración de sistemas, pruebas de sistema y de integración.
Mantenimiento: entrega, mantenimiento y mejora.
La siguiente imagen explica por qué el procedimiento lineal se denomina metodología en cascada.
El modelo en cascada en el desarrollo de software - IONOS
Las Fases del Desarrollo de Cascada
En este modelo, las diferentes fases de un proceso de desarrollo se suceden una detrás de otra como en una cascada. Cada una de las fases concluye con un resultado provisional (hito) como, por ejemplo, un catálogo de requisitos en forma de pliego de condiciones, la especificación de una arquitectura de software o una aplicación a nivel alfa o beta.
Análisis
Todo proyecto de software comienza con una fase de análisis que incluye un estudio de viabilidad y una definición de los requisitos. En el estudio de viabilidad se evalúan los costes, la rentabilidad y la factibilidad del proyecto de software. El estudio de viabilidad da como resultado un pliego de condiciones (una descripción general de los requisitos), un plan y una estimación financiera del proyecto, así como una propuesta para el cliente, si fuera necesario.
A continuación, se realiza una definición detallada de los requisitos, incluyendo un análisis de la situación de salida y un concepto. Mientras que los análisis de salida se encargan de describir la problemática en sí, el concepto ha de definir qué funciones y características debe ofrecer el producto de software para cumplir con las correspondientes exigencias. La definición de los requisitos da como resultado un pliego de condiciones, una descripción detallada de cómo se han de cumplir los requisitos del proyecto, así como un plan para la prueba de aceptación, entre otros.
Por último, la primera fase del waterfall model incluye un análisis de la definición de los requisitos en el que los problemas complejos se dividen en pequeñas tareas secundarias y se elaboran las correspondientes estrategias de resolución.
Diseño
La fase de diseño sirve para formular una solución específica en base a las exigencias, tareas y estrategias definidas en la fase anterior. En esta fase, los desarrolladores de software se encargan de diseñar la arquitectura de software, así como un plan de diseño detallado del mismo, centrándose en componentes concretos, como interfaces, entornos de trabajo o bibliotecas. La fase de diseño da como resultado un borrador preliminar con el plan de diseño del software, así como planes de prueba para los diferentes componentes.
El modelo en cascada en el desarrollo de software - IONOS
Implementación
La arquitectura de software concebida en la fase de diseño se ejecuta en la fase de implementación, en la que se incluye la programación del software, la búsqueda de errores y las pruebas unitarias. En la fase de implementación, el proyecto de software se traduce al correspondiente lenguaje de programación. Los diversos componentes se desarrollan por separado, se comprueban a través de las pruebas unitarias y se integran poco a poco en el producto final. La fase de implementación da como resultado un producto de software que se comprueba por primera vez como producto final en la siguiente fase (prueba alfa).
Prueba
La fase de prueba incluye la integración del software en el entorno seleccionado. Por norma general, los productos de software se envían en primer lugar a los usuarios finales seleccionados en versión beta (pruebas beta). Las pruebas de aceptación desarrolladas en la fase de análisis permiten determinar si el software cumple con las exigencias definidas con anterioridad. Aquellos productos de software que superan con éxito las pruebas beta están listos para su lanzamiento.
Servicio
Una vez que la fase de prueba ha concluido con éxito, se autoriza la aplicación productiva del software. La última fase del modelo en cascada incluye la entrega, el mantenimiento y la mejora del software.
Pros y contras del modelo en cascada
Esta metodología permite estructurar la organización de forma clara en aquellos proyectos de desarrollo en los que las diversas fases de proyecto se diferencian claramente entre sí. Como cada una de las fases concluye con un hito, el proceso de desarrollo es muy fácil de comprender. El punto clave del modelo reside en la documentación de todos y cada uno de los pasos de proceso. Los conocimientos adquiridos se registran en pliegos de requisitos o borradores preliminares.
El modelo en cascada en el desarrollo de software - IONOS
Modelo en V
¿Qué es el modelo V?
El modelo V o modelo en cuatro niveles es un modelo empleado en diversos procesos de desarrollo, por ejemplo, en el desarrollo de software. En los años 90 apareció su primera versión, pero con el tiempo se ha ido perfeccionando y adaptando a los métodos modernos de desarrollo. La idea básica, sin embargo, se remonta a los años 70 y fue concebida como una especie de desarrollo posterior del modelo de cascada.
Además de las fases de desarrollo de un proyecto, el modelo V también define los procedimientos de gestión de la calidad que lo acompañan y describe cómo pueden interactuar estas fases individuales entre sí. Su nombre se debe a su estructura, que se asemeja a la letra V.
Las fases del modelo V
En primer lugar, el modelo V define el curso de un proyecto en fases individuales cada vez más detalladas:
Al principio del proyecto, el modelo prevé un análisis de las especificaciones del sistema planificado (fase de especificaciones).
El proyecto se completa después con requisitos funcionales y no funcionales para la arquitectura del sistema (fase funcional).
A esta fase le sigue el diseño del sistema, en el que se planifican los componentes y las interfaces de este (fase de diseño).
Una vez completadas estas fases, se puede diseñar en detalle la arquitectura del software (codificación).
Es ahora cuando, de acuerdo con estos planes, comienza el desarrollo en sí del software. A continuación, tendrán lugar las fases de control de la calidad, también llamadas de verificación o validación, que siempre están relacionadas con cada una de las fases de desarrollo. El método V abarca las siguientes tareas:
Pruebas de unidad
Pruebas de integración
Integración del sistema
Validación
Modelo V: definición, ventajas y áreas de aplicación - IONOS
Interacción entre el desarrollo y la verificación
La “V” del nombre del modelo hace referencia a la forma como el modelo compara las fases de desarrollo con las fases de control de la calidad correspondientes. El brazo izquierdo de la letra V contiene las tareas de diseño y desarrollo del sistema, y el derecho las medidas de control de calidad de cada fase. En la unión entre los dos brazos, se sitúa la implementación del producto. En los proyectos de software, esto se refiere a la programación del software.
La implementación correcta de la arquitectura de software planificada se comprueba mediante pruebas de unidad. Aquí se verifica en detalle si los módulos individuales del software cumplen exactamente las funciones requeridas y proporcionan realmente los resultados que se esperan. Para evitar errores, se recomienda realizar estas pruebas en paralelo al desarrollo.
Las pruebas de integración examinan el diseño del sistema. Aquí se verifica si cada uno de los componentes interactúa con el resto según lo planificado –por ejemplo, si todos los procesos proporcionan los resultados esperados. En este punto, un resultado incorrecto podría indicar un problema de interfaz.
Modelo V XT: desarrollo posterior del modelo V
En 2006, se revisó el modelo V para que reflejara nuevos principios como el desarrollo ágil. El resultado fue el modelo V XT. XT se refiere a Extreme Tailoring y describe la nueva posibilidad de adaptar el modelo a los requisitos de cada proyecto.
Una idea fundamental detrás de esta revisión era proporcionar un modelo que pudiera adaptarse de forma versátil a proyectos de diferentes tamaños. En los proyectos más pequeños, en particular, el método antiguo era a menudo demasiado costoso y, por lo tanto, ineficiente, pero con el Modelo V XT es posible eliminar ciertas fases que requerirían esfuerzo extra.
Gestión de proyectos: ¿qué es el ciclo en V? (appvizer.es)
Modelo V: definición, ventajas y áreas de aplicación - IONOS
Ámbitos de aplicación del modelo V
El modelo V XT es un modelo muy arraigado en la industria ya que está disponible públicamente. En la mayoría de las ofertas de nuevos proyectos de software de las autoridades públicas, el uso del modelo V es incluso obligatorio y, por lo tanto, es un pilar esencial, especialmente en las empresas que desarrollan software para las autoridades públicas y los ministerios. Se puede implementar en proyectos de software de cualquier tamaño, ya sea en empresas, en el sector militar o en el sector público. Es una herramienta que facilita la organización e implementación del desarrollo, mantenimiento y desarrollo de una amplia variedad de sistemas de TIC.
Ventajas y desventajas del modelo V
El motivo principal de la popularidad del modelo V es que garantiza un alto grado de transparencia y propone unos procesos claramente definidos y comprensibles. A continuación, te damos un resumen de las principales ventajas y puntos mejorables.
Las ventajas del modelo V
Optimización de la comunicación entre las partes involucradas a través de términos y responsabilidades claramente definidos.
Minimización de riesgos y mejor planificación a través de roles, estructuras y resultados fijos y predeterminados.
Mejora de la calidad del producto gracias a medidas de control de la calidad firmemente integradas.
Ahorro de costes gracias al procesamiento transparente a lo largo de todo el ciclo de vida del producto.
En general, el modelo puede ayudar a evitar malentendidos y trabajo innecesario. También garantiza que todas las tareas se completen en el plazo y orden adecuado y mantiene los periodos de inactividad al mínimo.
Las desventajas del modelo V
El modelo en cuatro niveles puede ser demasiado simple para mapear todo el proceso de desarrollo desde el punto de vista de los desarrolladores. Está sobre todo centrado en la gestión de proyectos. Además, su estructura relativamente rígida permite una respuesta poco flexible a los cambios durante el desarrollo, y, por lo tanto, promueve un curso lineal del proyecto. Sin embargo, si el modelo se entiende y se utiliza correctamente, es posible utilizar el modelo V para el desarrollo ágil.
Modelo V: definición, ventajas y áreas de aplicación - IONOS
Modelo en espiral: el modelo para la gestión de riesgos en el desarrollo de software
El desarrollo de un nuevo software presenta grandes retos para todas las partes implicadas. Cuanto más compleja sea la aplicación que se desea desarrollar, más difícil resultará organizar de forma clara el proceso de desarrollo y controlarlodentro de su complejidad. Por esta razón, normalmente nos apoyamos en planes especialmente diseñados paso a paso, denominados también modelos de procedimiento. Estos dividen el proceso de desarrollo completo en varias fases abarcables determinadas por el tiempo y el contenido. Uno de los modelos más conocidos, especialmente dirigido a la reducción de riesgos, es el denominado modelo en espiral, del año 1986.
Modelo en espiral: modelo de reducción de riesgos para proyectos de software - IONOS
¿Qué es el modelo en espiral?
Barry W. Boehm presentó su enfoque para el desarrollo de aplicaciones complejas en 1986 y en 1988 el ingeniero de software americano publicó su modelo en la publicación A Spiral Model of Software Development and Enhancement también en un contexto más general. En esta publicación, describía el modelo en espiral como una posible alternativa al modelo establecido hasta entonces, el modelo en cascada, que al mismo tiempo servía como base empírica. A diferencia del modelo en cascada, en el modelo en espiral no se parte de la base de que las tareas del desarrollo del software se organizan de forma lineal, sino que se entienden como tareas iterativas. Las fases no se realizan de forma única paso a paso, sino varias veces en forma de espiral. Mediante esta repetición cíclica, el proyecto se va acercando al objetivo de forma relativamente lenta, pero se minimiza de forma decisiva el riesgo de fracaso del proceso de desarrollo gracias a los controles regulares.
¿cómo funciona el modelo en espiral?
Los problemas en el proceso de desarrollo pueden tener efectos muy diversos sobre el proyecto general. En cualquier caso, se debe contar con aumentos de costes, gastos adicionales y retrasos en el lanzamiento; factores que, especialmente para empresas pequeñas, pueden suponer un problema existencial. Con su enfoque incremental e iterativo, que también contempla el análisis de riesgos periódico mediantediseños de prototipo, análisis o simulaciones, el modelo en espiral evita estos escenarios o al menos suaviza sus consecuencias negativas. El proyecto de software transcurre de forma continua hasta finalizar el ciclo del modelo en espiral, que principalmente abarca los cuatro pasos que aparecen a continuación.
Fase 1: definición de objetivos y alternativas y descripción de las condiciones generales
Un ciclo típico del modelo espiral comienza con la valoración de qué objetivos deben vincularse a cada uno de los pasos del desarrollo de software. Se puede tratar, por ejemplo, de la mejora del rendimiento o de la ampliación de la funcionalidad. Al mismo tiempo, es el momento de definir las alternativas para la implementación (por ejemplo, diseño A vs. diseño B) y determinar las condiciones generales como los costes o la inversión de tiempo.
Fase 2: valoración de las alternativas
En el siguiente paso, es hora de evaluar las alternativas, momento en el que los objetivos y las condiciones generales serán valores de referencia decisivos. En esta fase del ciclo del desarrollo en espiral, deberán identificarse los ámbitos de inseguridad que presenten un riesgo significativo para el progreso del proyecto de software. Después debe seguir la elaboración de las estrategias que presenten menos riesgo y que sean más rentables, para lo cual se podrán utilizar métodos como el modelo de prototipos, simulaciones, estudios comparativos, modelos de análisis y encuestas a usuarios.
Modelo en espiral: modelo de reducción de riesgos para proyectos de software - IONOS
Fase 3: desarrollo y revisión del resultado intermedio
Al finalizar el análisis de riesgos, se prosigue con el desarrollo real del software, así que esta fase siempre está caracterizada por los riesgos relativos restantes. Si el proceso de desarrollo está dominado por riesgos de rendimiento o de interfaz de usuario, o riesgos del control interno de la interfaz, se ofrece primero una estrategia de desarrollo evolutiva, donde se especifica el proyecto con más precisión y se optimizan los prototipos. El código real se escribe y se prueba varias veces hasta alcanzar el resultado deseado, que puede servir entonces como base de bajo riesgo para otros pasos de desarrollo.
Fase 4: planificación del siguiente ciclo
Una vez concluido un ciclo ya se empieza a planificar el siguiente ciclo. Por una parte, en forma de avance normal del proyecto, si los objetivos de un ciclo se han podido cumplir y se debe definir el siguiente objetivo. Por otra parte, también se puede tratar de encontrar soluciones, en caso de que la etapa de desarrollo anterior haya fracasado. En este caso, la estrategia seguida hasta entonces se puede sustituir, por ejemplo, con las alternativas definidas anteriormente o con una nueva alternativa. De esta forma, se puede intentar conseguir de nuevo el objetivo marcado.
Representación gráfica del modelo espiral según Boehm
Una parte de la publicación del año 1988 es una representación gráfica del modelo en espiral que ejemplifica el aspecto del proceso de desarrollo web en forma espiral, basado en ciclos. Cada vuelta de la espiral representa en este esquema un ciclo completo, por lo que la hilera debe ajustarse siempre a cuatro cuadrantes distintos que, en este caso, se adaptan a las cuatro fases posibles del modelo.
Modelo en espiral: modelo de reducción de riesgos para proyectos de software - IONOS
Modelo en espiral: modelo de reducción de riesgos para proyectos de software - IONOS
Comentarios
Publicar un comentario