Tema 2: El Proceso del Software

📝 Resumen Ejecutivo

Esta sesión explora la evolución histórica de la Ingeniería del Software a través de sus modelos de proceso, desde los enfoques primitivos hasta las metodologías ágiles actuales. Se analiza cómo la complejidad creciente de los problemas y la tecnología forzaron el paso de modelos secuenciales (Cascada) a iterativos (Espiral, UP) y finalmente adaptativos (Ágiles). El objetivo no es buscar el "mejor" proceso absoluto, sino entender cuál fue adecuado en su contexto histórico y cuál aplica hoy en día.

🔑 Conceptos Clave

Proceso Software: Conjunto de fases y pasos necesarios para desarrollar un producto software.
Código Espagueti: Código pobremente estructurado resultante de modelos de prueba y error sin diseño previo.
Requisito Oculto: Necesidad del cliente que no expresa inicialmente porque asume que está incluida o no sabe que la quiere hasta que la ve (ejemplo del prototipado).
Análisis de Riesgo: Fase crítica introducida por el Modelo en Espiral para evaluar la viabilidad antes de avanzar.
Time-boxing: Bloques de tiempo fijos (cajas de tiempo) utilizados en metodologías ágiles para asegurar entregas frecuentes.

📚 Desarrollo del Temario

1. Contexto y Clasificación

El profesor enfatiza que este tema es una historia de la informática. Los modelos no son "buenos" o "malos" per se, sino que respondían a la capacidad computacional de su época.

Modelos Tradicionales: No consideraban la evolución del software (Enfoque "hacer y entregar").
Modelos Evolutivos: Se adaptan al cambio de requisitos en el tiempo.
Modelos Orientados a Objetos (OO): Surgen con el cambio de paradigma de programación (C++ a Java, etc.), permitiendo solapamiento de fases.
Procesos Ágiles: Centrados en la rapidez y adaptación al cambio, no en la documentación exhaustiva.

2. Modelos Tradicionales

A. Modelo Primitivo (Codificar y Corregir)

Es el modelo de "prueba y error" típico de las primeras prácticas de programación. * Funcionamiento: Iteración de codificación y prueba sin planificación ni diseño. * Contexto Histórico: Válido en los años 50-60 para problemas matemáticos o físicos simples (ej. resolver \(ax^2 + bx + c = 0\)) donde los requisitos eran fórmulas inmutables. * Inconvenientes: En sistemas complejos genera "código espagueti", es caro de mantener y difícil de depurar.

B. Modelo en Cascada (Clásico)

¡OJO AL DATO!: Es el primer proceso fundamental de la historia de la Ingeniería del Software.

Origen: Adaptado de la ingeniería civil e industrial (construcción de puentes/túneles).
Estructura: Secuencial pura. No se pasa a la siguiente fase hasta acabar la anterior (Análisis Diseño Codificación Prueba).
Problema Crítico: Es un modelo monolítico. El cliente define requisitos al inicio y no ve el producto hasta el final (meses después). Si hubo un error de entendimiento al principio, el proyecto fracasa.
Variante con Realimentación: Permite volver a una fase anterior para corregir, pero se penaliza en tiempo y coste.

3. Modelos Basados en Prototipos

Surgen para solucionar la incertidumbre en los requisitos.

Ejemplo del Profesor (El Arquitecto): El profesor contó cómo al diseñar su casa, el arquitecto le presentó 12 diseños diferentes, incluyendo cosas que él no pidió. Esto sirvió para validar lo que quería y descubrir "requisitos ocultos" (cosas que le gustaron al verlas pero no se le habrían ocurrido).

Tipos de Prototipado:
1. Desechable: Se construye rápido para validar requisitos y luego se tira (como el modelo en arcilla de un coche). Riesgo: Que el cliente quiera quedarse con el prototipo mal hecho "porque ya funciona".
2. Evolutivo: Se construye con calidad desde el inicio para que evolucione hasta ser el sistema final.

4. Modelos Evolutivos: El Modelo en Espiral

¡OJO AL DATO!: Es el segundo proceso fundamental. Creado por Boehm.

Innovación Principal: Introduce el Análisis de Riesgo explícito en cada iteración. Antes de construir, se evalúa si es viable tecnológicamente o funcionalmente.
Funcionamiento: Se divide en 4 cuadrantes (Planificación, Análisis de Riesgo, Ingeniería, Evaluación del Cliente). El proyecto avanza en espiral, pasando repetidamente por estas fases.
Ventaja: Es un "meta-modelo" muy flexible y más realista que la cascada, ya que incorpora el mantenimiento como una vuelta más de la espiral.

5. Modelos para Sistemas OO: Proceso Unificado (UP)

¡OJO AL DATO!: Es el tercer proceso fundamental. Definido por los "Tres Amigos" (Jacobson, Booch, Rumbaugh) de Rational Software.

Características:
- Iterativo e Incremental: El trabajo se divide en mini-proyectos.
- Conducido por Casos de Uso: Los requisitos funcionales guían el desarrollo.
- Centrado en la Arquitectura: Prioriza la estructura robusta del sistema.
Fases del UP: Inicio, Elaboración, Construcción, Transición. Las barras de colores en el gráfico muestran cómo la carga de trabajo de cada disciplina (ej. requisitos vs. testeo) varía según la fase.

6. Modelos Ágiles

Surgen en los 90 como reacción a la rigidez del Proceso Unificado, donde se asumía (erróneamente) que los requisitos podían congelarse.

Filosofía: "Abrazar el cambio". El cambio es bueno porque significa que el cliente ha detectado una mejora de valor.
XP (Extreme Programming): Enfocado en buenas prácticas de ingeniería.
- 5 Valores: Simplicity (Simplicidad), Communication (Comunicación), Feedback (Retroalimentación), Courage (Valentía/Proactividad) y Respect (Respeto) .
- Práctica: "KISS" (Keep It Simple, Stupid) y cambios incrementales pequeños.

SCRUM

¡OJO AL DATO!: Es el cuarto proceso fundamental y el más utilizado hoy en día.

Metáfora: Basado en la formación de melé del Rugby (equipo empujando juntos) [Img: Rugby scrum].
Funcionamiento:
1. Product Backlog: Lista de todo lo que se quiere hacer (priorizado por valor de negocio).
2. Sprint Backlog: Selección de tareas para realizar en un ciclo corto (2-4 semanas).
3. Sprint: Ejecución del trabajo.
4. Daily Scrum: Reunión diaria de sincronización.
5. Entregable: Un incremento de producto "potencialmente entregable" al final de cada sprint.
Rol Clave: El Product Owner (representante del cliente) es quien prioriza las tareas según el valor que aportan al negocio.

🧠 Preguntas de Autoevaluación

¿Por qué el modelo en cascada se considera "monolítico" y cuál es su mayor riesgo en proyectos actuales?
- Respuesta: Es monolítico porque entrega el producto de una sola vez al final del ciclo. Su riesgo es que si los requisitos no eran correctos al inicio (hace meses), el error se detecta demasiado tarde, haciendo el proyecto muy costoso o fallido.
Diferencia principal entre un prototipo desechable y uno evolutivo.
- Respuesta: El desechable se construye rápido (a veces con "mala praxis") solo para validar requisitos y luego se elimina. El evolutivo se construye con calidad desde el inicio para ser refinado y convertirse en el producto final.
¿Cuál es la gran aportación del Modelo en Espiral de Boehm respecto a los modelos anteriores?
- Respuesta: La incorporación explícita del Análisis de Riesgo antes de proceder a la fase de ingeniería en cada iteración.
En el contexto de SCRUM, ¿quién decide qué tareas entran en el Sprint Backlog y en base a qué criterio?
- Respuesta: El equipo selecciona cuánto trabajo puede asumir, pero es el Product Owner quien prioriza las tareas del Product Backlog basándose en el valor que aportan al negocio/cliente.