El software es un producto vivo

Un lanzamiento es un hito importante, pero no el final de un producto de software útil. Los usuarios, los entornos operativos, las dependencias, los riesgos de seguridad, la regulación y las prioridades empresariales pueden cambiar. La pregunta práctica no es si el software llega a estar terminado en términos absolutos, sino qué responsabilidades de ciclo de vida conserva, quién las asume y qué evidencia justifica la siguiente inversión.

La norma vigente ISO/IEC/IEEE 12207:2026 sobre el ciclo de vida del software abarca concepción, desarrollo, operación, soporte, mantenimiento y retirada. También indica que los procesos pueden aplicarse de forma concurrente, iterativa, recursiva e incremental. Es un modelo más sólido que una única secuencia rígida por la que cada funcionalidad deba pasar sin cambios.

Este artículo convierte el ciclo de vida en una lista práctica para productos. Es una guía, no una afirmación de que una metodología sirva para todos los equipos.

La analogía con un edificio ayuda, pero tiene límites

Tanto el software como los edificios se benefician de una intención clara, restricciones conocidas, diseño, verificación, integración, operación y mantenimiento. La analogía resulta útil cuando impulsa al equipo a hacer explícitas sus decisiones. Resulta engañosa cuando da a entender que los requisitos siempre pueden cerrarse antes de implementar o que cada cambio debe seguir una secuencia rígida.

Un producto puede volver a la fase de descubrimiento tras investigar a los usuarios, cambiar su arquitectura después de pruebas de carga o revisar una versión cuando los datos operativos cuestionan una suposición. Es mejor entender el ciclo de vida como un conjunto de responsabilidades con bucles de feedback que como una cinta transportadora.

Para cada cambio relevante, decide qué evidencia necesitas antes de invertir más. Un cambio de texto de bajo riesgo puede requerir poca formalidad. Una función de pagos, identidad, salud o seguridad puede justificar requisitos formales, modelado de amenazas, revisión independiente y un despliegue controlado.

Siete responsabilidades del ciclo de vida que conviene hacer visibles

1. Definir un resultado y sus restricciones

La planificación debe identificar el problema del usuario, el resultado deseado, quién decide, las restricciones relevantes y la evidencia que permitiría continuar, cambiar de rumbo o detenerse. También debe hacer visibles las suposiciones sobre presupuesto, plazos, datos, integraciones, cumplimiento y responsabilidad operativa.

La entrega ágil no elimina la planificación. Los principios del Manifiesto Ágil combinan la entrega frecuente y la adaptación a requisitos cambiantes con desarrollo sostenible, excelencia técnica y reflexión periódica. El plan puede cambiar mientras su propósito sigue siendo explícito.

2. Refinar los requisitos según el riesgo

Los requisitos traducen un resultado en comportamientos, restricciones y evidencia de aceptación. Un equipo no tiene que predecir cada detalle futuro, pero sí resolver las decisiones cuyo aplazamiento sería costoso o peligroso. Algunos ejemplos son los límites de autorización, la retención de datos, los objetivos de disponibilidad, las reglas de migración y qué ocurre si falla un servicio externo.

Mantén visibles las suposiciones no resueltas. Un prototipo puede comprobar si los usuarios entienden un flujo. Una prueba técnica puede validar una integración. Una entrega pequeña puede poner a prueba la demanda. Cada experimento debe tener una persona responsable y una decisión concreta que pretenda informar.

3. Diseñar la experiencia y el sistema

El diseño de experiencia cubre cómo las personas descubren, entienden y recuperan un flujo. El diseño de software cubre responsabilidades entre componentes, límites de datos, interfaces, comportamiento ante fallos y restricciones operativas. Ambos deben tener suficiente detalle para revisar las decisiones importantes antes de que queden ocultas en la implementación.

Arquitectura no significa añadir servicios. Para un producto, un monolito modular puede encajar mejor que servicios distribuidos. Otro puede necesitar mayor aislamiento o escalado independiente. Elige la estructura más sencilla que satisfaga las restricciones actuales y conserve vías creíbles para cambios conocidos. Registra las decisiones importantes y la evidencia que las sustenta.

4. Entregar incrementos que puedan revisarse

La implementación debe producir incrementos lo bastante pequeños para que las partes interesadas y el equipo técnico puedan inspeccionarlos. La Guía Scrum oficial de 2020, para los equipos que eligen Scrum, describe un Product Backlog ordenado, un Sprint Goal, un Sprint Backlog, una Definition of Done y ciclos de inspección y adaptación. No prescribe un modelo contractual ni de precios, y tampoco es el único marco de entrega válido.

Un informe útil se centra en decisiones y evidencia: qué resultado avanzó, qué cambió, qué sigue siendo incierto, qué riesgos aumentaron y qué recomienda el equipo a continuación. Los recuentos de actividad no demuestran por sí solos el valor del producto.

Para profundizar en estructura comercial e incertidumbre, consulta nuestra guía para evaluar proveedores de desarrollo.

5. Verificar comportamiento, seguridad e integraciones

Las pruebas deben elegirse a partir de los riesgos del producto. Las pruebas unitarias pueden proteger el comportamiento local. Las pruebas de integración, contrato, extremo a extremo, rendimiento, accesibilidad, seguridad, recuperación y migración responden a preguntas distintas. Ningún conjunto finito de pruebas demuestra que un sistema no trivial carece de defectos.

El Secure Software Development Framework 1.1 definitivo de NIST recomienda integrar prácticas de desarrollo seguro en el ciclo de vida elegido. Sus grupos de prácticas abarcan preparar la organización, proteger el software, producir versiones bien protegidas y responder a vulnerabilidades. Por tanto, la seguridad exige trabajo en diseño, implementación, verificación, lanzamiento y respuesta, no una única prueba cerca del lanzamiento.

Las integraciones también necesitan evidencia sobre las rutas de fallo. Cuando sea relevante, prueba autenticación caducada, límites de solicitudes, respuestas malformadas, fallos parciales, reintentos, eventos duplicados y recuperación. En sistemas de smart contracts, incluye las testnets apropiadas y comprobaciones en producción cuidadosamente controladas, porque un entorno de prueba no puede reproducir cada dependencia o condición económica de mainnet.

6. Operar y observar el producto

Una versión necesita responsables después del despliegue. Define indicadores de servicio, alertas, canales de soporte, funciones durante incidentes, procedimientos de rollback o mitigación, expectativas de copias de seguridad y recuperación, y cómo llega el feedback de usuarios al backlog. La observabilidad debe responder a preguntas de producto y fiabilidad sin recoger más datos personales o sensibles de los necesarios.

La evidencia operativa puede contradecir las suposiciones de diseño. Trata los incidentes, las solicitudes de soporte, las trazas de rendimiento y los datos de adopción como entradas para la planificación, no como asuntos separados que se delegan indefinidamente en otro equipo.

7. Mantener, evolucionar o retirar de forma deliberada

El mantenimiento puede incluir corregir defectos, actualizar dependencias, responder a vulnerabilidades, adaptarse a cambios de plataforma, mejorar la operabilidad y modificar el comportamiento conforme evolucionan las necesidades. No todos los productos necesitan desarrollo continuo de funciones, pero un producto en operación sí requiere una decisión explícita sobre responsabilidad y riesgo aceptable.

Un acuerdo de mantenimiento debe concretar el alcance: entornos compatibles, expectativas de respuesta, gestión de actualizaciones de seguridad, responsabilidad sobre dependencias, monitorización, copias de seguridad, exportación de datos y ayuda en la salida. Si el producto ya no justifica su operación, la retirada también forma parte del ciclo. Planifica notificaciones, migración, conservación o eliminación de datos, retirada de accesos y desmantelamiento.

Una lista práctica de gobernanza

• Resultado: ¿Están claros el resultado para usuarios o negocio y quién decide?
• Evidencia: ¿Qué justificaría continuar, cambiar de rumbo o detenerse?
• Riesgo: ¿Qué fallos requieren requisitos, revisiones o pruebas más estrictos?
• Calidad: ¿El umbral de lanzamiento es explícito y observable?
• Operación: ¿Quién asume despliegues, incidentes, soporte y recuperación?
• Mantenimiento: ¿Quién asume dependencias, vulnerabilidades, cambios de plataforma y deuda técnica?
• Salida: ¿Pueden migrarse usuarios y datos de forma segura si cambia el producto o el proveedor?

Mantener un producto de software vivo puede requerir liderazgo técnico continuo. Si esa responsabilidad todavía no justifica un puesto ejecutivo a tiempo completo, consulta nuestro servicio de Fractional CTO en Austria.