El software no aparece de golpe ni termina su historia cuando se publica una primera versión. Normalmente atraviesa una serie de momentos: surge una necesidad, se analiza, se diseña una solución, se construye, se prueba, se entrega, se usa, se mantiene, evoluciona y, en algún momento, puede ser reemplazado o retirado.
A ese recorrido se lo conoce como ciclo de vida del software. Comprenderlo permite ver el desarrollo como un proceso completo, no como una actividad limitada a escribir código.
En este tema veremos una introducción general. El objetivo es entender las etapas principales y por qué cada una aporta valor. En el próximo tema compararemos modelos de proceso que organizan estas etapas de distintas maneras.
El ciclo de vida del software es el conjunto de etapas por las que pasa un sistema desde que se identifica una necesidad hasta que deja de usarse. Incluye actividades técnicas, decisiones de negocio, coordinación de personas, gestión de cambios y mantenimiento continuo.
Una forma simple de resumirlo es:
En proyectos reales, estas etapas no siempre ocurren de forma estrictamente lineal. A veces se repiten, se superponen o se realizan en ciclos. Por ejemplo, después de entregar una versión pueden aparecer nuevos requisitos que vuelven a iniciar parte del análisis y del diseño.
Conocer el ciclo de vida ayuda a evitar una visión incompleta del desarrollo. Si solo pensamos en programar, podemos ignorar decisiones importantes que ocurren antes y después de escribir código.
El ciclo de vida permite:
Todo ciclo de vida comienza con una necesidad, problema u oportunidad. Puede ser una dificultad operativa, una oportunidad comercial, una obligación legal, una mejora de servicio o la modernización de un sistema existente.
En esta etapa se busca responder preguntas iniciales:
Una necesidad mal entendida puede llevar a construir un sistema que no aporta valor, aunque esté bien programado.
Antes de iniciar un desarrollo completo, muchas organizaciones realizan un estudio de viabilidad. Su objetivo es analizar si la solución propuesta tiene sentido desde distintos puntos de vista.
| Tipo de viabilidad | Pregunta principal | Ejemplo |
|---|---|---|
| Técnica | ¿Tenemos tecnología y conocimiento para construirlo? | Verificar si una integración externa es posible. |
| Económica | ¿El beneficio justifica el costo? | Comparar costo de desarrollo con ahorro operativo esperado. |
| Operativa | ¿La organización podrá usar y sostener el sistema? | Evaluar capacitación, soporte y cambios de proceso. |
| Legal o regulatoria | ¿Respeta normas aplicables? | Analizar protección de datos personales o trazabilidad obligatoria. |
| Temporal | ¿Puede lograrse en el plazo requerido? | Definir si una primera versión es viable antes de una fecha límite. |
La viabilidad no elimina todos los riesgos, pero ayuda a decidir si conviene avanzar, ajustar el alcance o descartar una iniciativa.
Después de identificar la necesidad, se deben comprender y definir requisitos. Esta etapa busca transformar ideas generales en acuerdos más precisos sobre lo que el sistema debe cumplir.
Incluye actividades como:
Los requisitos no siempre quedan cerrados para siempre. En muchos proyectos evolucionan a medida que se aprende más sobre el problema y la solución.
El diseño define cómo se organizará la solución. La arquitectura establece decisiones estructurales de mayor impacto: componentes principales, tecnologías, estilos de comunicación, almacenamiento, seguridad, despliegue y atributos de calidad.
En esta etapa se toman decisiones como:
Un buen diseño no busca complicar el proyecto. Busca dar estructura para que la construcción, las pruebas y los cambios futuros sean más manejables.
La construcción es la etapa en la que se implementa el software. Incluye código, configuración, base de datos, interfaces, integraciones, scripts, automatizaciones y ajustes técnicos.
Durante la construcción se debe cuidar:
La construcción no debería aislarse del resto del ciclo de vida. Debe responder a requisitos, respetar decisiones de diseño y generar una base mantenible.
Las pruebas permiten obtener información sobre el comportamiento del sistema. Ayudan a detectar defectos, validar requisitos y reducir riesgos antes de entregar una versión.
La evaluación de calidad puede incluir:
La calidad no debe evaluarse solo al final. Cuanto antes se revisa una decisión, un requisito o un componente, menor suele ser el costo de corregir problemas.
La entrega consiste en poner una versión del software a disposición de usuarios, clientes o evaluadores. El despliegue es la acción técnica y operativa de instalar o publicar esa versión en un ambiente.
Una entrega puede requerir:
Un sistema no está realmente entregado si nadie puede usarlo de manera adecuada o si no existe una forma responsable de operarlo.
Durante la operación, el software se usa en condiciones reales. Esta etapa permite observar problemas que no siempre aparecen en ambientes de desarrollo o prueba: carga real, datos reales, comportamiento de usuarios, integraciones inestables y errores de configuración.
La operación incluye tareas como:
Cuando el software funciona como servicio, la operación es una parte central de su valor.
El mantenimiento es la etapa en la que se corrige, adapta y mejora el sistema después de su entrega. No debe verse como un trabajo menor: muchos sistemas pasan más tiempo siendo mantenidos que siendo desarrollados inicialmente.
El mantenimiento puede ser:
| Tipo | Objetivo | Ejemplo |
|---|---|---|
| Correctivo | Corregir defectos. | Arreglar un error en el cálculo de intereses. |
| Adaptativo | Ajustar el sistema a cambios del entorno. | Actualizar una integración porque cambió una API externa. |
| Perfectivo | Mejorar funcionalidades o experiencia. | Agregar nuevos filtros a un reporte. |
| Preventivo | Reducir riesgos futuros. | Refactorizar un módulo antes de que sea más difícil modificarlo. |
La evolución es el conjunto de cambios que permiten que el software siga siendo útil a lo largo del tiempo. Puede incluir nuevas funciones, adaptación a nuevos mercados, integración con otros sistemas, rediseño de interfaces o cambios de arquitectura.
Un sistema evoluciona porque su entorno cambia:
La evolución debe gestionarse. Si cada cambio se hace sin cuidar diseño, pruebas y documentación, el sistema puede acumular deuda técnica y volverse cada vez más difícil de modificar.
En algún momento, un sistema puede dejar de ser conveniente. Tal vez la tecnología queda obsoleta, el costo de mantenimiento es demasiado alto, el negocio cambió, existe una solución mejor o el sistema ya no cumple requisitos de seguridad.
Retirar o reemplazar software también requiere planificación. No se trata simplemente de apagarlo. Puede ser necesario:
El retiro responsable forma parte del ciclo de vida porque protege datos, continuidad operativa y conocimiento organizacional.
Las etapas del ciclo de vida están conectadas. Una mala definición de requisitos afecta el diseño. Un diseño confuso complica la construcción. Una construcción sin pruebas dificulta la entrega. Una entrega sin monitoreo complica la operación. Un mantenimiento sin refactorización puede aumentar la deuda técnica.
La siguiente tabla muestra algunas relaciones importantes:
| Decisión temprana | Impacto posterior |
|---|---|
| Requisitos poco claros | Retrabajo, cambios tardíos y discusiones sobre alcance. |
| Diseño demasiado acoplado | Mantenimiento difícil y alto riesgo al modificar funcionalidades. |
| Pruebas insuficientes | Defectos en producción y miedo a cambiar el sistema. |
| Despliegue manual sin control | Errores de configuración y versiones inconsistentes. |
| Documentación inexistente | Pérdida de conocimiento y dependencia de personas específicas. |
Hablar de ciclo de vida no significa que todos los proyectos deban seguir una secuencia fija y pesada. Algunos proyectos requieren más análisis previo; otros avanzan mediante versiones pequeñas e incrementales. Algunos tienen requisitos muy estables; otros cambian con frecuencia.
Lo importante es que el equipo reconozca las actividades necesarias y las adapte al contexto. Un sistema crítico de salud no debería gestionarse igual que un prototipo experimental. Un producto masivo en línea no tiene las mismas necesidades que una herramienta interna usada por pocas personas.
El ciclo de vida es una guía para no olvidar dimensiones importantes del software, no una receta única.
Imaginemos una aplicación para que clientes hagan pedidos a un restaurante.
Este ejemplo muestra cómo el ciclo de vida acompaña toda la historia del sistema, no solo su construcción inicial.
Al no considerar el ciclo de vida completo, suelen aparecer errores como:
El ciclo de vida del software permite comprender el recorrido completo de un sistema. Ayuda a mirar más allá de la programación y a considerar decisiones que afectan valor, calidad, operación, mantenimiento y evolución.
Para quien comienza, la idea principal es esta: un sistema de software vive antes, durante y después de su primera entrega; por eso debe pensarse como algo que nace, cambia, se mantiene y eventualmente se reemplaza.
En el próximo tema estudiaremos modelos de proceso como cascada, iterativo, incremental y ágil, que son distintas formas de organizar las actividades del ciclo de vida.