En el tema anterior vimos que el software atraviesa un ciclo de vida: necesidad, análisis, diseño, construcción, pruebas, entrega, operación, mantenimiento y evolución. Un modelo de proceso define cómo se organizan esas actividades en un proyecto.
No todos los proyectos se desarrollan de la misma manera. Algunos necesitan mucha definición previa porque el riesgo de error es alto. Otros necesitan aprender rápido con usuarios reales. Algunos entregan una versión completa al final, mientras que otros entregan partes funcionales en ciclos cortos.
En este tema veremos cuatro enfoques importantes: cascada, iterativo, incremental y ágil. El objetivo no es elegir un único modelo como "el mejor", sino comprender cuándo cada enfoque puede ser útil y qué riesgos tiene.
Un modelo de proceso es una forma de organizar las actividades del desarrollo de software. Define el orden aproximado de trabajo, los puntos de revisión, la forma de entregar resultados y la manera de manejar cambios.
Un modelo puede ayudar a responder preguntas como:
El modelo en cascada organiza el desarrollo en etapas secuenciales. Primero se analizan requisitos, luego se diseña, después se implementa, se prueba y finalmente se entrega. La idea general es avanzar de una etapa a la siguiente cuando la anterior está suficientemente completada.
Una secuencia típica sería:
Este modelo es fácil de entender y puede ser útil cuando los requisitos son estables, el dominio es conocido y se necesita documentación formal. También puede aparecer en contextos regulados donde cada etapa requiere aprobación.
| Ventajas | Límites o riesgos |
|---|---|
| Es simple de explicar y planificar inicialmente. | Funciona mal si los requisitos cambian con frecuencia. |
| Favorece documentación y aprobaciones por etapa. | El usuario puede ver resultados tarde. |
| Permite definir entregables claros en cada fase. | Los errores de requisitos pueden descubrirse demasiado tarde. |
| Puede servir en proyectos con alcance muy estable. | Puede generar mucha rigidez ante cambios necesarios. |
El problema no es que el modelo en cascada sea siempre incorrecto. El problema aparece cuando se usa en proyectos con alta incertidumbre, usuarios poco disponibles o requisitos que se descubren durante el desarrollo.
El modelo iterativo organiza el trabajo en ciclos repetidos. En cada ciclo se analiza, diseña, construye y evalúa una parte o versión del sistema. Luego se aprende de los resultados y se realiza una nueva iteración.
Una iteración puede servir para mejorar una funcionalidad, corregir decisiones, validar supuestos o aumentar detalle. Lo importante es que el equipo no espera al final del proyecto para revisar si va en la dirección correcta.
En un enfoque iterativo, el aprendizaje es parte del proceso:
| Ventajas | Límites o riesgos |
|---|---|
| Permite aprender y corregir el rumbo temprano. | Requiere disponibilidad de usuarios o referentes para validar. |
| Reduce el riesgo de descubrir problemas al final. | Puede volverse desordenado si no hay objetivos claros por iteración. |
| Ayuda cuando los requisitos no están completamente claros. | Puede generar retrabajo si se construye sin criterios técnicos. |
| Favorece mejora progresiva del producto. | Necesita control de alcance para evitar cambios infinitos. |
El modelo incremental consiste en entregar el sistema por partes funcionales. Cada incremento agrega capacidades nuevas al producto. A diferencia de una entrega única al final, el usuario puede comenzar a usar partes del sistema mientras otras siguen en desarrollo.
Por ejemplo, en un sistema de biblioteca, los incrementos podrían ser:
Cada incremento debe aportar valor y estar integrado con lo anterior. No se trata de entregar piezas técnicas aisladas que el usuario no puede aprovechar.
| Ventajas | Límites o riesgos |
|---|---|
| Entrega valor antes de completar todo el sistema. | Requiere definir incrementos útiles y coherentes. |
| Permite priorizar funcionalidades importantes. | La arquitectura debe soportar crecimiento gradual. |
| Facilita recibir comentarios sobre versiones reales. | Puede generar deuda técnica si se agregan partes sin diseño común. |
| Reduce el riesgo de una gran entrega final fallida. | Necesita buena gestión de versiones y despliegues. |
Los términos iterativo e incremental suelen confundirse porque muchas veces se combinan. Sin embargo, no significan exactamente lo mismo.
| Enfoque | Idea central | Ejemplo |
|---|---|---|
| Iterativo | Mejorar o ajustar la solución mediante ciclos de aprendizaje. | Construir un prototipo de búsqueda, validarlo y mejorarlo en la siguiente iteración. |
| Incremental | Agregar nuevas partes funcionales al producto. | Primero entregar búsqueda, luego carrito, luego pagos y luego reportes. |
Un proyecto puede ser iterativo e incremental al mismo tiempo: entrega partes funcionales y mejora cada una mediante ciclos de retroalimentación.
El enfoque ágil agrupa principios y prácticas orientadas a entregar valor de manera frecuente, adaptarse al cambio, colaborar con usuarios y mejorar continuamente. No es un único método, sino una familia de enfoques que incluye prácticas como Scrum, Kanban, integración continua, entregas frecuentes y retrospectivas.
Un equipo ágil suele trabajar con ciclos cortos, prioridades visibles, comunicación frecuente y entregas pequeñas. La intención es aprender rápido y ajustar el producto según necesidades reales.
El enfoque ágil valora especialmente:
| Ventajas | Límites o riesgos |
|---|---|
| Permite adaptarse a cambios y aprendizaje continuo. | Puede confundirse con improvisación si no hay disciplina técnica. |
| Entrega valor con frecuencia. | Requiere participación activa de negocio o usuarios. |
| Hace visibles prioridades, avances y bloqueos. | Puede fallar si no se gestionan arquitectura, calidad y deuda técnica. |
| Favorece mejora continua del equipo. | No elimina la necesidad de planificación, pruebas ni documentación útil. |
Ser ágil no significa trabajar sin requisitos, sin diseño o sin documentación. Significa hacerlos de forma proporcional, colaborativa y adaptable.
| Modelo | Forma de trabajo | Útil cuando... | Riesgo principal |
|---|---|---|---|
| Cascada | Etapas secuenciales. | Los requisitos son estables y se requiere control formal. | Descubrir tarde que la solución no era adecuada. |
| Iterativo | Ciclos de revisión y mejora. | Hay incertidumbre y se necesita aprender. | Iterar sin objetivos claros. |
| Incremental | Entregas parciales funcionales. | Se puede dividir el producto en partes valiosas. | Agregar partes sin una arquitectura coherente. |
| Ágil | Entregas frecuentes, colaboración y adaptación. | El contexto cambia y se requiere retroalimentación continua. | Confundir agilidad con falta de disciplina. |
No conviene elegir un modelo por moda. La elección debe considerar el contexto del proyecto.
Algunos criterios útiles son:
Imaginemos una institución que necesita un sistema de inscripción a cursos.
Con un enfoque en cascada, el equipo podría definir todos los requisitos, diseñar el sistema completo, construirlo, probarlo y entregarlo al final. Esto podría funcionar si el proceso de inscripción es estable y conocido.
Con un enfoque iterativo, el equipo podría crear prototipos de la inscripción, mostrarlos a usuarios y ajustar reglas antes de construir la versión final.
Con un enfoque incremental, se podría entregar primero la carga de cursos, luego la inscripción de alumnos, después pagos y finalmente reportes.
Con un enfoque ágil, el equipo podría trabajar en ciclos cortos, mantener un backlog priorizado, entregar versiones funcionales y ajustar prioridades según retroalimentación de administración, docentes y alumnos.
El mismo problema puede abordarse de diferentes maneras. La decisión depende del contexto, los riesgos y las necesidades de entrega.
En la práctica, muchos equipos usan enfoques híbridos. Por ejemplo, pueden tener una etapa inicial de análisis y arquitectura, luego trabajar de manera incremental, y al mismo tiempo usar prácticas ágiles para gestionar tareas y retroalimentación.
También puede ocurrir que una organización requiera documentación formal, pero el equipo construya el producto mediante iteraciones internas. Esto no es necesariamente contradictorio si las prácticas se combinan con criterio.
Lo importante es evitar dos extremos:
Un buen proceso debe servir al proyecto, no al revés.
Al elegir o aplicar modelos de proceso suelen aparecer errores como:
Los modelos de proceso ayudan a ordenar el trabajo de desarrollo. Cascada, iterativo, incremental y ágil representan distintas formas de organizar actividades, manejar cambios, entregar valor y controlar riesgos.
Para quien comienza, la idea principal es esta: elegir un modelo de proceso significa decidir cómo aprenderemos, construiremos, validaremos y entregaremos software en un contexto determinado.
En el próximo tema veremos la planificación inicial de un proyecto de software, donde estudiaremos cómo definir objetivos, alcance, restricciones, riesgos y primeras decisiones de organización.