diferencias de métodos ágiles y tradicionales

Metodología Tradicional

El origen de la metodología tradicional del desarrollo del software es la metodología de construcción de productos físicos (barcos, edificios, coches, etc..).

 Esta metodología tradicional del desarrollo del software se caracteriza por:

basarse en un ciclo de vida de desarrollo del software en cascada ya que organiza los proyectos en etapas que se ejecutan secuencial mente. Ejemplo:

Especificación de Requisitos.

-Análisis

-Diseño

-Desarrollo

-Pruebas

-Implantación

-Mantenimiento

Metodología Ágil

El desarrollo del software no tiene las mismas características que la construcción de productos físicos, estas diferencias y la agilidad que requiere

 el negocio actual del software hacen necesario el uso de una metodología ágil que:

*se basa en un ciclo de vida de desarrollo del software iterativo e incrementa. Se repiten las etapas de cada ciclo, se va añadiendo funcionalidad al producto 

y se comprime al máximo el tiempo de las iteraciones, son iteraciones cortas de semanas

*se solapan las etapas. No siempre dentro de cada alternación tiene que haber etapas en cascada, por ejemplo, la etapa de test se fusiona con la etapa de desarrollo 

o la del diseño con la etapa de construcción.

*se cambia la documentación por la interacción cara a cara con el usuario, hay equipos multidisciplinarios sin separación de roles (todos pueden diseñar y programar) y 

se tiende a una gestión de proyecto como equipo auto organizado y colaborativo.

importancia

cual es la diferencia  !

METODOLOGIA CASCADA

 El modelo en cascada, algunas veces llamado el 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 que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos, también cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente. El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están:

1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa.

 2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos.

3. El cliente debe tener paciencia. Una versión que funcione de los programas estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión del programa. En un análisis interesante de proyectos reales, Bradac (1994) concluyó que la naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo.

El estado de bloqueo tiende a ser más común al principio y al final del proceso secuencial. En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de cambios (de características, funciones y contenido de la información). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal. 

PRINCIPALES ETAPAS DE ESTE MODELO

• Análisis y definición de requerimientos. Los servicios, restricciones y

Metas del sistema se definen a partir de las consultas con los usuarios. Se

Define una especificación del sistema.

• Diseño del sistema y del software. El proceso de diseño del sistema

Divide los requerimientos en sistemas hardware o software. Establece una

Arquitectura completa del sistema. El diseño del software identifica y

Describe las abstracciones fundamentales del sistema software y sus

Relaciones.

• Implementación y prueba de unidades. Durante esta etapa, el diseño

Del software se lleva a cabo como un conjunto o unidades de programas.

• Integración y prueba del sistema. Los programas o las unidades

Individuales de programas se integran y prueban como un sistema

Completo para asegurar que se cumplan los requerimientos del software.

• Funcionamiento y mantenimiento. El sistema se instala y se pone en

Funcionamiento práctico. El mantenimiento implica corregir errores no

Descubiertos en las etapas anteriores del ciclo de vida.

.- Modelo en Cascada

modelo de cascada

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo del software , de tal forma que el inicio de cada etapa debe esperar a la fiscalización de la etapa anterior.¹

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Implantación.
7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al re diseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.