Ciclos de vida
Qué es una metodología, qué es un ciclo de vida, el modelo en cascada y sus alternativas evolutivas, la clasificación por enfoque y el Proceso Unificado.
Qué es una metodología de desarrollo
Una metodología de desarrollo es el conjunto de reglas, actividades, técnicas y documentos que ordenan la construcción de un sistema de información. Responde a tres preguntas: qué hay que hacer, en qué orden y quién lo hace. Sin ella, cada proyecto se organizaría de cero y el resultado dependería de la costumbre de quien lo dirigiera.
Conviene distinguirla del ciclo de vida. El ciclo de vida es la sucesión de etapas por las que pasa un producto software desde que se detecta la necesidad hasta que se retira: análisis de requisitos, diseño, construcción, pruebas, implantación y mantenimiento. La metodología es la forma concreta de recorrer ese ciclo, con sus plantillas, sus roles y sus criterios de salida de cada etapa.
El ciclo de vida dice por qué etapas se pasa; la metodología dice cómo se recorren. Un mismo ciclo de vida admite metodologías muy distintas.
El mantenimiento no es una fase menor: en la vida completa de una aplicación se lleva la mayor parte del esfuerzo, porque los sistemas viven años y cambian de requisitos por el camino. Se clasifica en correctivo (arreglar defectos), evolutivo o perfectivo (añadir y mejorar funcionalidad), adaptativo (ajustarse a un cambio del entorno, por ejemplo una nueva versión del sistema operativo) y preventivo (mejorar el código para que se pueda mantener mañana).
Para el examen
Ciclo de vida: por qué etapas se pasa
Metodología: cómo se recorren esas etapas
Relación: un mismo ciclo de vida admite metodologías muy distintas
El modelo en cascada y las alternativas evolutivas
El modelo en cascada es el ciclo de vida clásico: las etapas se recorren una vez, en orden, y cada una no arranca hasta que la anterior está cerrada y documentada. Nació en los años setenta y sigue siendo la referencia contra la que se comparan todos los demás modelos.
Su virtud es la previsibilidad: se sabe desde el principio qué se va a entregar, cuánto cuesta y cuándo. Su defecto es que apuesta todo a acertar los requisitos al principio. Si el cliente cambia de idea a mitad de proyecto, o si un error de análisis solo se descubre al probar, hay que retroceder etapas enteras, y el coste de arreglar un fallo crece a medida que se avanza. Además, el cliente no ve nada funcionando hasta el final.
| Modelo | Cómo avanza | Cuándo conviene |
|---|---|---|
| Cascada | Una sola pasada por las etapas, en secuencia y sin volver atrás | Requisitos estables y bien conocidos, y proyectos con exigencia contractual o normativa fuerte |
| Cascada con realimentación | Igual, pero se admite volver a la etapa anterior si se detecta un error | Lo mismo, aceptando que el análisis nunca sale perfecto |
| Incremental | El sistema se trocea en incrementos y cada uno se entrega funcionando | Se conoce el conjunto, pero interesa que el cliente tenga valor antes del final |
| Iterativo o evolutivo | Se construye una versión completa y se refina en sucesivas pasadas | Los requisitos se van a aclarar usando el producto |
| Prototipos | Se construye una maqueta desechable para validar requisitos, y luego se desarrolla | El cliente no sabe explicar lo que quiere hasta que lo ve |
| Espiral | Ciclos repetidos de objetivos, análisis de riesgos, desarrollo y evaluación | Proyectos grandes y con riesgo alto, donde el riesgo dirige el orden del trabajo |
El modelo en espiral es el que pone el análisis de riesgos en el centro: en cada vuelta se identifican los riesgos y se ataca primero el más peligroso. Es de Barry Boehm y es la respuesta clásica en cuanto un enunciado hable de riesgos.
Para el examen
Modelo en espiral: de Barry Boehm
Qué pone en el centro: el análisis de RIESGOS
Regla de examen: si el enunciado habla de riesgos, la respuesta es espiral
Clasificación de las metodologías clásicas por enfoque
Las metodologías anteriores al movimiento ágil se agrupan según qué toman como pieza básica para describir el sistema. Es una clasificación de examen y se pregunta emparejando cada metodología con su familia.
| Enfoque | Qué modela primero | Ejemplos |
|---|---|---|
| Estructurado y orientado a proceso | Las funciones que el sistema realiza y el flujo de datos entre ellas; los datos van aparte | SSADM (británica), Merise (francesa) y Métrica versión 3 (española) |
| Orientado a objetos | Objetos que reúnen datos y comportamiento, y los mensajes entre ellos | Método de Booch, OMT y OOSE |
De las tres metodologías orientadas a objetos conviene retener por dónde destacaba cada una, porque es lo que se pregunta: el método de Booch estaba especialmente desarrollado en la fase de diseño, OMT (de James Rumbaugh) en la fase de análisis, y OOSE (de Ivar Jacobson) aportó los casos de uso como forma de capturar requisitos. La unificación de los tres es el origen de UML y del Proceso Unificado.
Para el examen
Booch: destacaba en diseño
OMT (Rumbaugh): destacaba en análisis
OOSE (Jacobson): aportó los casos de uso
Su unificación: UML y el Proceso Unificado
RUP y el Proceso Unificado
RUP (Rational Unified Process) es un proceso de desarrollo iterativo e incremental, no en cascada, dirigido por los casos de uso y centrado en la arquitectura. En cada iteración se escoge un grupo de casos de uso y se recorren con ellos todas las actividades: análisis, diseño, implementación y pruebas. Al terminar la iteración hay algo que funciona, aunque sea un poco de todo.
«Centrado en la arquitectura» significa que la arquitectura se fija al principio del proyecto, en las primeras iteraciones, y el resto de los casos de uso se implementan encima de ella. Es la decisión más cara de cambiar, así que se toma pronto y con poco código escrito.
- Inicio o incepción: se delimita el alcance, se identifican los casos de uso principales y se estima si el proyecto es viable.
- Elaboración: se fija la arquitectura y se atacan los riesgos importantes.
- Construcción: se desarrolla el grueso de la funcionalidad sobre la arquitectura ya establecida.
- Transición: se pasa el sistema a los usuarios, con formación, migración de datos y estabilización.
Las cuatro fases de RUP son inicio, elaboración, construcción y transición, y no son etapas de cascada: dentro de cada una hay varias iteraciones y en todas se analiza, se diseña, se programa y se prueba.
RUP era un producto comercial de Rational, después de IBM. Para tener una versión libre del mismo proceso se creó el Unified Process, del que salen OpenUP y Agile Unified Process, variantes más ligeras del mismo esquema.
Para el examen
Las cuatro fases: inicio, elaboración, construcción y transición
Lo que NO son: etapas de cascada
Qué hay dentro de cada una: iteraciones en las que se analiza, diseña, programa y prueba