Mantenimiento correctivo y mantenimiento evolutivo

Una de las pesadillas de las empresas de desarrollo de software es la confusión (queriendo o sin querer) que existe en muchas casos entre los conceptos de mantenimiento correctivo y evolutivo. ¿Por qué pesadilla? Porque la garantía de los desarrollos afecta sólo a los mantenimientos correctivos y por tanto no se facturan y en muchas ocasiones se “cuelan” evolutivos como mantenimientos correctivos y se convierte en trabajo adicional para las empresas, no previsto y que en muchas ocasiones requiere un notable esfuerzo y que, por supuesto, no se cobra.
Un mantenimiento correctivo es aquel que tiene como objetivo solventar una deficiencia en un componente del sistema de información (puede ser software o documental). Entiéndase deficiencia como algo que debería funcionar o estar correcto y que no lo está.
Un mantenimiento evolutivo es aquel que pretende modificar algo que funcionaba o estaba correcto, con el objeto de aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario o por otras causas como pueden ser, por ejemplo, cambios normativos.
El problema está en la definición de qué es lo que debería funcionar o estar correcto en el sistema de información, es decir la delimitación clara de la frontera entre el correctivo y evolutivo. Y no es algo que esté nada claro en muchos casos, ya que por ejemplo, eso que esa funcionalidad que dice el cliente que debería estar y no contempla el programa, ¿es algo que se ha sacado ahora de la chistera o realmente se contempló en la definición y análisis del sistema de información?, ¿es algo que no se ha interpretado correctamente en el análisis?, ¿es algo que se suponía que se podía extrapolar del análisis aunque no aparezca explícitamente?.
Es cierto que hay muchos casos que las incidencias son de cajón y son correctivos y en la mayoría de las situaciones no dan problemas ni para el cliente, ni para el proveedor, que será consciente que son fallos suyos y los solucionará. También es cierto que hay evolutivos que son muy complicados de colar como correctivos, ya que una cosa es que la pared tenga que estar pintada de blanco o de color crema, que el pomo de la puerta sea plateado o dorado o que incluso el suelo sea de marmol o porcelánico y otra que te intenten comprar un piso de cuatro dormitorios por el precio de uno de un dormitorio. Sin embargo entre un caso (correctivos claros) y otros (evolutivos claros) hay todo un abanico de posibilidades que la mayoría de las veces dan lugar a conflicto (estos serán menos si el presupuesto del proyecto es holgado, el cliente es bueno, el proyecto se trata de una inversión para intentar conseguir más negocio con el cliente o a través del producto que se ha desarrollado, etc…).
Como ya he comentado en algún artículo en caso de conflicto casi siempre tiene las de perder el proveedor y lo más importante es tener asumida esa circunstancia. Eso no quiere decir que se deba decir a todo que sí, pero es más fácil negociar si no se pierde el tiempo en intentar remar a contracorriente.
Habrá negociación porque en los proyectos de desarrollo de software suelen cometer fallos las dos partes cliente y proveedor. Por esta razón siempre digo que las dos partes deben ser flexibles, ya que todos cometemos errores y además la naturaleza de los procesos de desarrollo de software no es rígida, sino en sí, un proceso evolutivo.

http://jummp.wordpress.com/2009/12/25/mantenimiento-correctivo-y-mantenimiento-evolutivo/