UNIDAD 3 METODOLOGÍAS DEL DESARROLLO

3.1 Metodologías clásicas

Hay una serie de metodologías que solemos llamar tradicionales o clásicas
propuestas casi todas ellas con anterioridad a los años 90 que pretendían ayudar a
los profesionales indicando pautas para realizar y documentar cada una de las tareas
del desarrollo del software. Sin embargo, tienen casi todas ellas un gran problema:
asumen que un proyecto informático es casi una extensión de un proyecto burocrático
tradicional.

3.1.1. Cascada
El desarrollo en cascada, también llamado modelo en cascada, es el enfoque
metodológico que ordena rigurosamente las etapas del proceso del desarrollo del
software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la
etapa anterior.
Los pasos 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 rediseño y nueva programación del código afectado, aumentando
los costos del desarrollo.
Fases del modelo:
Análisis de requisitos
El proceso de recopilación de los requisitos se centra e intensifica especialmente en
el software.
Diseño del Sistema
Descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo.
Diseño del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los
requerimientos del usuario.
Codificación
Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así
como de pruebas y ensayos para corregir errores.
Pruebas
Los elementos programados se ensamblan para componer el sistema y se comprueba
que funciona correctamente.
Verificación
Es la fase en donde el usuario final ejecuta el sistema, para ello, el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no
falle.
Mantenimiento
Al utilizarlo como usuario final puede ser que no cumpla con todas nuestras
expectativas.
Ventajas:
• Es un modelo sencillo y disciplinado
• Es fácil aprender a utilizarlo y comprender su funcionamiento
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al
final de cada etapa
• Ha sido muy usado y, por tanto, está ampliamente contrastado
• Ayuda a detectar errores en las primeras etapas a bajo costo
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas

Desventajas:
• Los proyectos raramente siguen el proceso lineal tal como se definía
originalmente el ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• No refleja exactamente cómo se programa realmente el sistema, en el que suele
haber un gran componente iterativo
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para
realizar correcciones
• El producto final obtenido puede que no refleje todos los requisitos del usuario

3.1.2. Incremental

El modelo incremental es una evolución del modelo de cascada; viene a suplir el problema
de no poder retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no
secuencial. El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el
cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la
introducción de iteraciones para dividir diseños.

Este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc. del
software, que de no convencer al cliente (o al propio programador) es rechaza-do y se
comienza con una segunda iteración. Todo esto, sin la necesidad de realizar un nuevo análisis
de requisitos.Pueden realizarse tantas iteraciones como sean necesarias. Es decir, que cada
incremento es un paso más en el desarrollo del software final.

Para la producción del Software, se usa el principio de trabajo encadena o ³Pipeline´. Con
esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada
incremento. Así, es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se
repite hasta que se elabore el producto completo.

Ventajas:
**Reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
** Provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes
operativas del Software.
** Reduce las desventajas del método de cascada.
**Permite entregar al cliente un producto más rápido en comparación del modelo de Cascada.
**Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos
Desventajas

Requiere de mucha planeación

Requiere de metas mas claras

No es recomendable para casos de sistema de tiempo real, alto nivel de seguridad, etc.

3.1.3. Evolutivo

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se
va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o
del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de
separarse.

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para
explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes
del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos
propuestos por el cliente.

2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es

comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de
los requerimientos para el sistema. El prototipo se centra en experimentar con los
requerimientos del cliente que no se comprenden del todo.

3.1.4. Espiral

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera
vez por Barry Boehm en 1986, utilizado generalmente en la ingeniería de software. Las
actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración
representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad,
sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle
interior.
3.1.5. Prototipo

Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar y

analizar una aplicación que representa el sistema que sería implementado (McCracken y
Jackson, 1982). Dicha aplicación, llamada prototipo, está compuesta por los componentes
que se desean evaluar (i.e. las funciones principales). Las etapas del modelo son:
- Investigación preliminar.
- Colecta y refinamiento de los requerimientos y proyecto rápido:

- Análisis y especificación del prototipo.

- Diseño y construcción del prototipo.
- Evaluación del prototipo por el cliente.
- Renacimiento del prototipo.

- Diseño técnico.
- Programación y test.
- Operación y mantenimiento.
3.1.6. Desarrollo basados en componentes

3.2. Otras metodologías

3.2.1.

3.2.2.

3.2.3.

3.2.4.

3.2.5.

3.3. Reingeniería