Desarrollo Dirigido por Pruebas
El Desarrollo Dirigido por Pruebas (TDD) es una práctica de ingeniería de software propuesta por Kent Beck en la que las pruebas se escriben antes que el código de producción. El ciclo de desarrollo queda invertido respecto al modelo clásico: primero se define el comportamiento esperado mediante un test automatizado, y después se escribe únicamente el código suficiente para satisfacerlo.
TDD no es solo una técnica de pruebas; es una disciplina de diseño. Al obligar al desarrollador a pensar en el uso del código antes de implementarlo, favorece interfaces limpias, bajo acoplamiento y alta cohesión. El resultado es un sistema que crece de forma incremental respaldado en todo momento por una batería de tests de regresión.
Diseño emergente
El diseño surge naturalmente de los tests. Se evita la sobreingeniería porque solo se implementa lo que el test exige en cada iteración.
Red de seguridad
Cada cambio es validado automáticamente contra la suite de tests acumulada, detectando regresiones de forma inmediata.
Documentación viva
Los tests actúan como especificaciones ejecutables que describen el comportamiento esperado del sistema en todo momento.
Variantes de TDD: el ATDD (Acceptance TDD) extiende el ciclo al nivel de requisitos de negocio, con tests escritos conjuntamente por desarrolladores, testers y clientes. El BDD (Behaviour-Driven Development) usa un lenguaje natural estructurado (Given / When / Then) para escribir los tests, facilitando la colaboración con stakeholders no técnicos.
Instalación y Cambio: Estrategias de Sustitución
Cuando un nuevo sistema de información va a reemplazar a uno existente, la organización debe decidir cómo gestionar la transición operativa. Esta decisión es crítica: afecta al riesgo asumido, al coste del proceso, a la disponibilidad del servicio y al impacto sobre los usuarios.
La elección de la estrategia depende de factores como la criticidad del sistema, el presupuesto disponible, el número de usuarios afectados y la tolerancia al riesgo de la organización.
(Big Bang)
El sistema antiguo se desconecta y el nuevo entra en producción en un único momento.
Es la estrategia más rápida y económica en infraestructura, ya que no hay que mantener dos sistemas en paralelo. Sin embargo, es la más arriesgada: si el nuevo sistema falla, no hay vuelta atrás inmediata. Solo es recomendable para sistemas de baja criticidad o con una fase de pruebas exhaustiva previa.
Ambos sistemas conviven durante un período hasta que el nuevo demuestra su fiabilidad.
Las mismas operaciones se registran en ambos sistemas y los resultados se comparan. Cuando el nuevo sistema genera salidas coherentes y correctas durante el período acordado, el antiguo se desconecta. Es la estrategia más segura, pero también la más costosa en tiempo y recursos humanos: los usuarios deben operar dos sistemas simultáneamente.
El nuevo sistema se introduce de forma gradual: por módulos, departamentos o ubicaciones geográficas.
En cada fase se validan funcionalidades o áreas concretas antes de extender el despliegue. Si se detectan problemas, el impacto queda acotado a la fase en curso. Requiere una planificación cuidadosa de la secuencia de fases y la gestión de la coexistencia de distintas versiones del sistema en diferentes partes de la organización.
El sistema nuevo se despliega completamente en un único sitio o grupo reducido antes del lanzamiento general.
Proporciona experiencia real de uso con un subconjunto de usuarios representativo. Los problemas detectados se corrigen antes de la implantación en el resto de la organización. Es habitual en empresas con múltiples sedes o en el despliegue de sistemas de gran escala como ERPs.
Recepción y Puesta en Producción
La recepción formal del sistema es el proceso por el que el cliente o los usuarios finales verifican y aceptan que el software entregado cumple los requisitos acordados. Es la última barrera de calidad antes de que el sistema entre en operación real, y tiene implicaciones contractuales en muchos proyectos.
La puesta en producción (go-live) es el conjunto de actividades técnicas y organizativas necesarias para que el sistema nuevo comience a operar en el entorno real de la empresa, con datos reales y usuarios reales.
Criterios de aceptación
Deben estar definidos antes de comenzar el proyecto: umbrales de rendimiento, funcionalidades obligatorias, porcentaje de defectos críticos aceptado. Sin criterios objetivos, la aceptación se convierte en una negociación subjetiva.
Plan de contingencia (rollback)
Procedimiento detallado para revertir al sistema anterior si el go-live fracasa. Debe estar preparado, probado y disponible antes del día del corte. Incluye la restauración de datos y la comunicación a los usuarios.
Evaluación Post-Implementación
La evaluación post-implementación (PIR, Post-Implementation Review) es una revisión formal que se realiza entre 3 y 6 meses después de la puesta en producción. Su objetivo es determinar si el sistema ha alcanzado los beneficios esperados y si el proceso de desarrollo e implantación puede mejorarse en proyectos futuros.
No es una auditoría de fallos, sino una actividad de aprendizaje organizacional. Involucra a todos los agentes del proyecto: patrocinadores, usuarios, equipo técnico y dirección. Sus conclusiones alimentan la mejora continua de los procesos de la organización.
| Área | Métricas clave | Fuente de datos | Tipo |
|---|---|---|---|
| Calidad técnica | Nº de defectos en producción, tiempo medio de resolución (MTTR), disponibilidad del sistema | Sistema de tickets, logs de monitorización | Cuantitativa |
| Rendimiento | Tiempos de respuesta, throughput, uso de recursos (CPU/memoria) | Herramientas de APM (New Relic, Datadog) | Cuantitativa |
| Adopción de usuarios | Tasa de uso por módulo, incidencias de formación, satisfacción (encuestas) | Analytics, encuestas NPS, helpdesk | Mixta |
| Valor de negocio | ROI, reducción de costes operativos, mejora de KPIs de negocio, tiempo ahorrado en procesos | Contabilidad, informes de gestión | Estratégica |
| Gestión del proyecto | Desviación en plazo y coste, gestión de riesgos, control de cambios | Plan de proyecto, actas de seguimiento | Cuantitativa |
| Lecciones aprendidas | Problemas recurrentes, buenas prácticas, mejoras de proceso identificadas | Retrospectivas, entrevistas con el equipo | Cualitativa |
El resultado de la evaluación se recoge en un informe de revisión post-implementación que incluye: resumen ejecutivo para los patrocinadores, análisis comparativo entre los objetivos iniciales y los resultados obtenidos, lista de incidencias pendientes, valoración del proceso seguido y recomendaciones de mejora para proyectos futuros.
Mantenimiento del Software
El mantenimiento del software comprende todas las actividades realizadas sobre un sistema después de su puesta en producción. Según estudios del sector, el mantenimiento representa entre el 60% y el 80% del coste total de un sistema a lo largo de su ciclo de vida, superando con creces el coste del desarrollo inicial.
El estándar ISO/IEC 14764 define el mantenimiento como la modificación de un sistema software, una vez entregado, para corregir fallos, mejorar el rendimiento u otros atributos, o adaptarlo a un entorno cambiante. Distingue cuatro tipos fundamentales.
Corrección de defectos
Elimina errores (bugs) descubiertos después de la entrega. Incluye tanto fallos que impiden el funcionamiento (errores críticos) como comportamientos incorrectos que no bloquean el sistema pero producen resultados erróneos. Es reactivo: se activa cuando se detecta un problema.
Adaptación al entorno
Modifica el sistema para que siga funcionando correctamente ante cambios en su entorno tecnológico u organizativo: nuevas versiones del sistema operativo, cambios en normativa legal, integración con nuevos sistemas externos, actualización de hardware o migración a la nube.
Mejora y nuevas funcionalidades
Introduce mejoras en el sistema que no son necesarias para su funcionamiento correcto, sino que responden a nuevas necesidades o deseos de los usuarios: nuevos informes, mejoras en la interfaz, optimización de consultas, nuevas integraciones o funcionalidades adicionales solicitadas por el negocio.
Mejora de la mantenibilidad
Reestructura y mejora el código (refactoring) para facilitar el mantenimiento futuro, sin cambiar el comportamiento externo. Incluye la actualización de documentación técnica, la mejora de la cobertura de tests, la reducción de deuda técnica y la eliminación de código obsoleto.
Gestión de solicitudes de cambio (CRs): todas las peticiones de modificación del sistema deben seguir un proceso formal de gestión del cambio. Una solicitud de cambio (Change Request) pasa por las fases de recepción, análisis de impacto, priorización, aprobación, implementación, pruebas de regresión y despliegue. Este proceso evita que los cambios informales introduzcan defectos o comprometan la integridad del sistema.
Deuda técnica: cuando la presión por tiempo lleva a soluciones subóptimas, se acumula deuda técnica. Si no se gestiona activamente (mediante mantenimiento preventivo), la deuda crece hasta hacer inviable el mantenimiento evolutivo del sistema y aumentar exponencialmente el coste de cada cambio.
SLA y niveles de servicio
Los acuerdos de nivel de servicio definen tiempos de respuesta y resolución para cada severidad de incidencia: crítica (horas), alta (días), media (semana) y baja (sprint).
Gestión de versiones
Cada modificación debe gestionarse mediante control de versiones (Git). Las releases de mantenimiento siguen el esquema semántico: MAJOR.MINOR.PATCH.
Retirada del sistema
Cuando el mantenimiento resulta inviable o el sistema ya no aporta valor, se planifica su retirada: migración de datos, comunicación a usuarios y baja de servicios.