Estimación de Tiempos y Costes

Estimar con precisión el tiempo y el presupuesto de un proyecto de software es uno de los mayores desafíos de la ingeniería de software. A diferencia de tareas repetitivas, el desarrollo de software implica resolver problemas nuevos con tecnologías en continua evolución.

Para mitigar la incertidumbre, existen metodologías formales tanto en la gestión predictiva (tradicional) como en la gestión adaptativa (ágil).

1. Técnicas de Estimación Predictiva (Tradicional) #

1┌─────────────────────────────────────────────────────────────────────────────┐
2│                      MÉTODOS TRADICIONALES DE ESTIMACIÓN                    │
3├─────────────────┬───────────────────────────────────────────────────────────┤
4│ 1. ANÁLOGA      │ Basada en proyectos pasados similares (Rápida / Poco exacta)│
5├─────────────────┼───────────────────────────────────────────────────────────┤
6│ 2. PARAMÉTRICA  │ Regresión matemática: Horas = Unidades × Ratio histórico  │
7├─────────────────┼───────────────────────────────────────────────────────────┤
8│ 3. BOTTOM-UP    │ Estimar cada paquete de la EDT y sumar hacia arriba       │
9├─────────────────┼───────────────────────────────────────────────────────────┤
10│ 4. PERT (3 PTS) │ Promedio ponderado: E = (Optimista + 4×Probable + Pesim.) / 6│
11└─────────────────┴───────────────────────────────────────────────────────────┘

La Técnica PERT (Distribución Beta de Tres Valores) #

Frente a tareas con alta incertidumbre técnica (ej. integrar una API externa no documentada), el método PERT calcula un valor esperado ponderando tres escenarios:

$E = \frac{O + 4M + P}{6}$

• $O$ (Optimista): Todo sale perfecto sin ningún bloqueo técnico.
• $M$ (Más Probable): Duración habitual considerando imprevistos menores.
• $P$ (Pesimista): Escenario de máxima dificultad o fallos técnicos imprevistos.

Ejemplo: Para desarrollar un módulo de sincronización: $O=2\text{ días}$, $M=4\text{ días}$, $P=12\text{ días}$.
$E = \frac{2 + 4(4) + 12}{6} = \frac{30}{6} = \mathbf{5\text{ días}}$

2. Técnicas de Estimación Ágil: Puntos de Historia y Planning Poker #

En entornos ágiles (Scrum/Kanban), no se estiman horas absolutas en las fases tempranas, sino el esfuerzo relativo y la complejidad mediante Puntos de Historia (Story Points).

1SERIE DE FIBONACCI MODIFICADA (PUNTOS DE HISTORIA)
2               ┌───┬───┬───┬───┬───┬────┬────┬────┬─────┐
3               │ 1 │ 2 │ 3 │ 5 │ 8 │ 13 │ 20 │ 40 │ 100 │
4               └───┴───┴───┴───┴───┴────┴────┴────┴─────┘
5               Baja complejidad  ◄────────────────►  Incertidumbre masiva

• Planning Poker: Técnica de estimación grupal donde cada desarrollador vota en secreto una carta con un valor de Fibonacci para una historia de usuario. Revelar las cartas simultáneamente evita el sesgo de anclaje cognitivo y fomenta el debate entre la estimación más alta y la más baja.
• T-Shirt Sizing: Clasificación rápida en tallas (XS, S, M, L, XL) para estimaciones de alto nivel en etapas iniciales de producto.

3. Estimación de Costes: Directos e Indirectos #

El presupuesto global del software se divide en dos categorías financieras:

• Costes Directos: Vinculados directamente al desarrollo (sueldos del equipo de ingenieros y diseñadores, licencias de software por usuario, consumo de servidores cloud AWS/Azure/GCP, hardware específico).
• Costes Indirectos: Gastos operativos compartidos (alquiler de oficinas, suministros, soporte administrativo y legal).

$\text{Presupuesto Total} = \sum (\text{Costes Directos} + \text{Costes Indirectos}) + \text{Reserva de Contingencia (10-15\%)}$

4. Diagrama de Gantt y la Ruta Crítica (CPM) #

El Diagrama de Gantt #

Es una representación gráfica que sitúa las tareas en barras horizontales a lo largo de una línea temporal, visualizando sus fechas de inicio, fin y dependencias lógicas:

• Fin a Inicio (FS): La tarea B no puede empezar hasta que termine la tarea A (ej. No se puede desplegar sin antes compilar y pasar tests).

El Método de la Ruta Crítica (Critical Path Method - CPM) #

La Ruta Crítica es la secuencia de actividades dependientes más larga del proyecto. Su duración total determina la fecha mínima posible de finalización del proyecto.

1┌──────────────────────┐          ┌──────────────────────┐
2    │ Diseño DB (4 días)   ├─────────►│ Backend API (8 días) ├───┐
3    └──────────────────────┘          └──────────────────────┘   │
4                                                                 ▼
5    ┌──────────────────────┐          ┌──────────────────────┐  ┌──────────────────────┐
6    │ Wireframes (2 días)  ├─────────►│ Frontend Web (5 días) ├─►│ Integración (3 días) │
7    └──────────────────────┘          └──────────────────────┘  └──────────────────────┘
8
9    • Camino 1: Diseño DB (4) + Backend (8) + Integración (3) = 15 días  ◄─── RUTA CRÍTICA (Holgura = 0)
10    • Camino 2: Wireframes (2) + Frontend (5) + Integración (3) = 10 días ◄─── Tiene 5 días de Holgura

• Holgura (Float / Slack): Tiempo que una tarea no crítica puede retrasarse sin afectar a la fecha final del proyecto.
• Tareas en la Ruta Crítica: Tienen holgura cero ($0$). Cualquier retraso de 1 día en una tarea crítica retrasa 1 día la entrega final del proyecto.

5. Caso Práctico de Estimación #

Una empresa de software debe desarrollar una pasarela de pago:

1. Aplica la fórmula PERT sabiendo que: Optimista = 3 días, Más Probable = 5 días, Pesimista = 13 días: $E = \frac{3 + 4(5) + 13}{6} = \frac{36}{6} = \mathbf{6\text{ días}}$
2. Si el coste/hora del desarrollador senior es de 35€ y trabaja 8 horas/día: $\text{Coste Directo} = 6\text{ días} \times 8\text{ h/día} \times 35\text{ €/h} = \mathbf{1.680\text{ €}}$