1. Modelos tradicionales de desarrollo de software

Antes de estudiar modelos específicos conviene comprender qué hace que un enfoque de desarrollo se considere tradicional, en qué contexto surgió y cuáles son los supuestos que lo sostienen. Esta base conceptual permite evaluar cuándo aplicar cada modelo y anticipar sus limitaciones.

1. Introducción a los modelos tradicionales

Los modelos tradicionales, también llamados predictivos, agrupan las prácticas que buscan planificar el desarrollo de software de principio a fin. Se apoyan en la idea de que el producto final puede especificarse con detalle antes de iniciar la construcción y que, a partir de esa definición, es posible coordinar equipos numerosos y controlar el avance mediante hitos documentados.

Esta familia de modelos prevaleció durante varias décadas, especialmente en organizaciones donde la trazabilidad, la documentación formal y el cumplimiento de normativas resultaban obligatorios. Comprender su lógica ayuda a dialogar con clientes acostumbrados a procesos lineales y a combinar elementos predictivos con enfoques iterativos cuando el contexto lo requiere.

1.1 Qué se entiende por «modelo tradicional» o «predictivo»

Un modelo tradicional o predictivo describe una secuencia de fases claramente delimitadas que se ejecutan en un orden preestablecido. Cada fase produce entregables concretos (documentos de requisitos, diseños técnicos, casos de prueba) y habilita la siguiente etapa cuando se aprueba formalmente. El plan se concibe como un contrato que reduce la incertidumbre y permite estimar costos, plazos y recursos con antelación.

1.2 Origen histórico: enfoque ingenieril aplicado al desarrollo de software

El enfoque tradicional se gestó en la segunda mitad del siglo XX, cuando el software comenzó a incorporarse en proyectos aeroespaciales y militares. Las organizaciones trasladaron las prácticas de la ingeniería clásica, basadas en planos detallados y procesos de aprobación secuenciales, a la recién nacida disciplina del software engineering. El objetivo era garantizar la confiabilidad del producto y evitar sobrecostos en proyectos de gran escala.

1.3 Supuestos clave: requisitos estables y planificación completa antes de codificar

  • Requisitos estables: se asume que los interesados pueden expresar lo que necesitan con claridad y que esos requerimientos no cambiarán significativamente.
  • Planificación exhaustiva: el equipo define tareas, esfuerzos y dependencias antes de comenzar a programar, confiando en que el plan inicial seguirá vigente.
  • Especialización de roles: cada fase involucra perfiles distintos (analistas, diseñadores, programadores, testers) que participan cuando les corresponde.
  • Control centralizado: existe una figura responsable de aprobar entregables, gestionar cambios y asegurar que el proceso se mantenga alineado con el plan.

Cuando alguno de estos supuestos se rompe, el modelo pierde eficiencia: los planes deben rehacerse, aumentan los retrabajos y se vuelve necesario incorporar mecanismos iterativos de ajuste.

1.4 Características principales: linealidad, documentación formal y control centralizado

  • Linealidad visible: las etapas suceden una tras otra con puntos de control que marcan el cierre de cada fase.
  • Documentación formal: se generan artefactos detallados que sirven como soporte para auditorías, licitaciones o futuras tareas de mantenimiento.
  • Control centralizado: la dirección del proyecto coordina decisiones y autoriza cambios, manteniendo un enfoque jerárquico.
  • Entregas al final: el producto completo suele estar disponible recién en las etapas finales, por lo que la validación del usuario se produce tardíamente.

Estas características permiten gestionar proyectos donde la predictibilidad es prioritaria, aunque también explican por qué los modelos tradicionales son menos flexibles frente a cambios frecuentes.