Conforme se evoluciona un producto crece su complejidad y su tamaño, lo que hace que cada vez sean más costosas esas actividades.
Por tanto, el mantenimiento de un producto es inevitable y su coste (como consecuencia de una mayor complejidad) irá creciendo a lo largo del tiempo. De ahí que se considere que el software no se desgasta, pero sí que se deteriora.
Recordemos una conocida cita de Fred Brooks: «La complejidad del software es una propiedad esencial, no accidental».
¿Es posible poner medios? Claro que sí, tanto en las actividades ordinarias de desarrollo (aplicando buenas prácticas y considerando la refactorización como parte del propio proceso de desarrollo) como con actividades extraordinarias (planes de acción para simplificar la arquitectura del sistema, reducir la deuda técnica, etc…). No obstante, debemos tener en cuenta que con independencia de estas actividades sí que es cierto que la complejidad del sistema crece conforme el mismo evoluciona.
El testing puede trabajar sobre la complejidad de un software atendiendo controlando el estado en el que se encuentra a partir de un desgloce inteligente de tareas (WBS) para poder estimar la «batalla» que habrá que darle al mismo a lo largo de ciclos de prueba planificados.
Respecto al mantenimiento, habrá que aplicar constantes pruebas regresivas manuales y automatizadas, además de analizar el código en paralelo para que la aplicación de la calidad sea general, es decir, global.
Fuente:
Leyes de Lehman. Introducción II
