En ingeniería del software, el mantenimiento de software es la modificación de un producto de software después de la entrega, para corregir errores, mejorar el rendimiento, u otros atributos. El mantenimiento del software es una de las actividades más comunes en la ingeniería de software.
Una percepción común del mantenimiento es que se trata meramente de la corrección de defectos. Sin embargo, un estudio indicó que la mayoría, más del 80%, del esfuerzo de mantenimiento es usado para acciones no correctivas ( Pigosky 1997). Esta percepción es perpetuada por usuarios enviando informes de problemas que en realidad son mejoras de funcionalidad al sistema.[wikipedia]
La mayoría de los programadores dedicamos gran parte de nuestro tiempo a mantener software, agregando, quitando o cambiando funcionalidad. Solo en el caso que tu empresa sea un monopolio, o tu negocio realmente no necesite automatización te librarías de mantener software y ambos realmente serian escenarios extraños.
Por lo general, y más en la actualidad, las empresas compiten entre sí en escenarios globalizados, por lo que tienen que innovar continuamente para poder atraer y mantener a sus clientes, activos e interesados. Todo ese movimiento comercial desemboca en necesidades, que de una forma o otra se van a suplir mediante software. [Regla N°1 de la Ingeniería de Software: Va a cambiar]
Una empresa que no pueda adaptar su software en el tiempo requerido para suplir las necesidades de su mercado, es una empresa que será reemplazada por otra que si pueda hacerlo.
El tiempo es, como vemos, un factor importante en al adaptabilidad del software. Un producto (sistema) será más mantenible en cuanto podamos modificarlo en el menor tiempo posible sin introducir fallos en el. [Regla N°3 de la Ingeniería de Software: Se va a mantener]
Así un sistema, ofrece siempre dos valores:
-
El valor operativo: esto es que tanto resuelve la necesidad que se supone que debe resolver, la funcionalidad para lo que fue creado. Esto es el valor inmediatamente presente, lo urgente.
-
El valor relativo al mantenimiento: Es la facilidad con el que software puede ser mantenido, este es el valor a mediano plazo, es lo importante.
¿Cuál crees que es el valor más relevante? La mayoría de las personas (sobre todo las que se han enfrentado superficialmente al desarrollo de software o por primera vez), piensan que es el valor operativo (el que ofrece la funcionalidad), pero eso es un error, evidentemente necesitamos tener un software operativo, pero no hay que sacrificar en ningún caso el mantenimiento por la operación. [Acerca de lo urgente y lo importante en el desarrollo de software]
Si tenemos un software operativo, pero no mantenible, su posibles (y muy seguros), cambios futuros serán complicados, llevándonos al caso, en menos tiempo del que pensamos, a tener un software inoperante. Sin embargo si tenemos un software mantenible pero no operativo, eventualmente y en corto plazo, será operativo de una forma sencilla.
Una de las partes más difíciles de mi trabajo siempre ha sido convencer a las partes todas implicadas en el desarrollo de un sistema, sobre la importancia del segundo valor. Una visión corta y segada sobre el negocio, nos puede llevar a enfocarnos en la operación, y posiblemente genere beneficios a corto plazo, pero en un plazo mediado (ni siquiera a largo plazo), el costo del mantenimiento superara con creces al ahorro por un enfoque basado únicamente en lo operativo.
Existen creencias (algunas implementadas fuertemente hasta en programadores experimentados) que son dañinas con respecto a la calidad y las posibilidades de mantenimiento de un software, como por ejemplo:
-
Lo importante es que funcione: El funcionamiento es solo una parte del valor, pero como comentábamos el costo de enfocarnos exclusivamente en que “funcione”, nos deja con un sistema poco mantenible, y eso nos lleva a un costo elevado a mediano plazo, además con la, muy real, posibilidad que deje de funcionar en mediado plazo. [El problema de "No somos una empresa de software"]
-
Si funciona no lo toques: Esto es uno de los grandes errores de la ingeniería de software. El momento para “tocar” un sistema es precisamente cuando esta funcionado, porque tenemos la tranquilidad de que está funcionando, y por lo tanto los cambios se pueden enfocar en mejorar el proceso y establecer nuevas requisitos. Los cambios en un software que “no funciona”, se enfocan en que funcionen, y se hacen a la razón de la urgencia no de lo importancia, no es el momento de plantearse “mejorar” un código hacia el futuro, si no cambiarlo para que funcione en el presente. [Regla N°12 de la Ingeniería de Software: “Hay que prepararse para la lluvia cuando hace sol” (olvídate de “Si funciona no lo toques”)]
Me gusta más las siguientes frases:
-
Es mejor tener algo que funcione que no tener nada: Viene a decir que es mejor tener algo productivo, aunque no cumpla todas las necesidades, que tener un software perfecto que solucione todas las necesidades y que no salga nunca a producción, porque su construcción es eterna.
Como anécdota, una vez estuve casi dos años construyendo un software, cuyo requisitos parecían que nunca se acababan (había “un problema para cada solución). Se veían casos rocambolescos de pruebas y situaciones inverosímiles. Cuando al final el sistema salió a producción, exploto por todo los lados.
Esto es porque nunca se pueden comprender un problema hasta que está resuelto. La resolución de un problema, nos da claridad sobre este. Es imposible asumir que se comprende antes, si lo hacemos realmente sobre estamos creando situaciones irreales, y descuidamos las importantes. [Regla N°17 de la Ingeniería de Software: Primero el camino principal luego las excepciones]
-
Arbol torcido nunca se endereza: básicamente viene a decir que los errores y fallos en la arquitectura se acumulan y crecen exponencialmente, por eso importante “cuidar” el código. Hay que asegurarse que el código siga “creciendo” de forma adecuada, es incluso necesario comenzar a desenredar código antes de que sea demasiado complicarlo para hacerlo.
Por eso el enfoque ágil es el mejor para solucionar un problema, mediante soluciones concretas, pequeñas e incrementales que se pueden poner en forma productiva en cortos tiempos. así el resultado se va ajustando a la necesidad real del negocio. Para que esto sea posible es necesario que sea mantenible (mantenimiento por encima de funcionalidad). [Acerca de la mantenibilidad del software]
Si te ha gustado la entrada, ¡Compártela! ;-)
