archivo

Archivo de la etiqueta: mantenimiento adaptativo

Su enunciado es el siguiente: “La calidad de los sistemas comienza a disminuir a menos que se mantengan de forma rigurosa y se adapten a los cambios en su entorno de funcionamiento (operacional)”.

En esta ley, Lehman trata el problema de la disminución de la calidad desde diferentes puntos de vista:

– El usuario tiende a ser más exigente conforme mayor sea la inversión dedicada a la evolución del producto y conforme se den cuenta (independientemente de que sepan interpretar su complejidad o no) de la maleabilidad del software.

– La calidad del software se ve afectada por en incremento de la complejidad del sistema conforme se va evolucionando y eso afecta a diferentes escalas: codificación/arquitectura (deuda técnica), usabilidad, etc…

– Por otro la propia convivencia del sistema con su entorno tecnológico (software y hardware), el cual evoluciona de la misma forma que los sistemas y en muchos casos con características muy similares. En esa evolución se tratan de corregir fallos de seguridad, se trata de dar una mayor estabilidad, a la par de incluir nuevas funcionalidades que puedan resultar de utilidad (y distinguirla de otras opciones del mercado).

Si un sistema no se adapta a esos cambios y las características de los nuevos entornos operacionales que se estén montando no son compatibles, estamos acotando el sistema a seguir subsistiendo con versiones en muchos casos sin soporte de los mismos y que además, se irá quedando marginada porque el esfuerzo central del Departamento de Sistemas se centrará en los entornos en los que se encuentre el grueso de los sistemas de información de la organización, además de aquellos que sean considerados críticos.

El alcance de esta séptima ley se puede extender al propio framework de desarrollo del producto y al conjunto de librerías dependientes que utilice, de manera que surgen nuevas versiones de las mismas que mejoran las anteriores a la vez que corrigen defectos en las mismas.

También puede ser extensible a una menor calidad como consecuencia de no aplicar medidas conforme se incrementa la complejidad del producto (en este caso se asimilaría a la segunda ley de Lehman).

Jim Horning lleva más de cuarenta años en este negocio dedicándose principalmente al campo de la investigación. Doctorado en Stanford, desarrolló los primeros años de su carrera laboral en la Universidad de Toronto, pasando después siete años en el Xerox Parc (entre 1977 y 1984), tras esa etapa siguió desarrollando su labor investigadora en otras entidades y centros.

Hay una cita de Horning, que refleja en gran medida la complejidad del trabajo que realizamos, ya sea cuando realizamos el mantenimiento evolutivo o adaptativo de un sistema o realizamos un desarrollo siguiendo un enfoque iterativo e incremental donde en cada iteración se pasan a producción partes funcionales del software: “La ciencia informática es la única disciplina en la que nosotros consideramos la construcción de una nueva ala a un edificio como si fuera un mantenimiento”.

Y es así, podemos cometer errores de gran impacto cuando se realizan modificaciones sobre un sistema en producción: funcionalidad mal implementada o mal especificada que puede afectar a una función de negocio importante, efectos colaterales, etc… y que después pueden obligar a tener que actuar con urgencia lo que a la vez puede traer consigo nuevos problemas.

El desarrollo de software es así, tal vez por eso nos gusta tanto a la par de que nos trae muchísimos (demasiados) problemas.

En el anterior artículo comencé con el análisis del primero de los cuatro principios o valores que componen el manifiesto ágil. Ahora le toca el turno al segundo principio:

Principio 2: Valorar el software que funciona, por encima de la documentación exhaustiva.

La finalidad última de todo desarrollo de software es obtener un producto que satisfaga las necesidades de quienes los vayan a utilizar. Todo lo demás está uno o varios escalones por debajo.

Por tanto si una aplicación funciona tal y como quería el cliente, de manera que pueda realizar su trabajo de manera eficiente y productiva se habrá conseguido un éxito…¿o no?.

Es un éxito hoy, pero mañana puede suponer una fuente de problemas.

Entregar un software sin errores es muy complicado (no digo que sea imposible), de hecho es tal el esfuerzo que habría que hacer por parte de los que lo revisan y tal el esfuerzo que tendría que hacer por parte del desarrollador para que un software se entregue sin errores, que no resulta rentable llegar a ese extremo (salvo que se trate de un software que por sus características específicas y criticidad requiera la realización de ese esfuerzo, el cual, para que sea efectivo debe ser tenido en cuenta en el presupuesto del proyecto), esto requerirá tareas de mantenimiento correctivo, que no deberían ser muchas ni complicadas, porque si así fuera no deberíamos considerar que el software que se ha entregado funciona.

Los requisitos cambian y el software se tiene que adaptar a esos cambios, lo que hace que los sistemas de información requieran de tareas de mantenimiento evolutivo.

La realización de tareas de mantenimiento correctivo y evolutivo (como también ocurriría con el mantenimiento adaptativo y perfectivo) implica trabajar con el código fuente de la aplicación. Si la codificación no es buena: dificultad en la legibilidad y comprensión del código, alto acoplamiento, baja cohesión, el mantenimiento del sistema se puede convertir en una tortura, cuyo coste será proporcional a la deuda técnica existente.

No basta solo con que el software que se entregue funcione, la calidad del código es importante de cara a futuros mantenimientos.

En este principio se pone en una balanza el funcionamiento del sofware sobre la existencia de una documentación exhaustiva y es algo en lo que estoy totalmente de acuerdo.

El software cambia, por lo que si la documentación no cambia con él (y no me estoy refiriendo solo a la que se encuentra recogida en ficheros ofimáticos, herramientas CASE o la compuesta por los propios comentarios que aparecen en el código), tenemos documentación que cada vez servirá para menos, hasta que llegue a un punto de que más que ayudar a la comprensión del sistema, le perjudique.

Mi visión sobre la documentación (salvo las actas que se quieran elaborar de reuniones o documentación adicional que se quiera elaborar, como por ejemplo, esquemas de interfaz de usuario, etc….) es que se realice sobre herramientas CASE, ya que facilita la trazabilidad de los diferentes componentes documentales y que sea la justa y necesaria para el proyecto en el que se está trabajando, es decir, ni más, ni menos.

La documentación debe servir para que los programadores sepan qué funcionalidad es la que tienen que desarrollar, por lo que la misma debe ser concisa y sin ambigüedades. Todo lo que sea ambiguo tenderá a ser rellenado en la mayoría de los casos por la interpretación que del problema haga el programador, la cual además será errónea en la mayor parte de los casos y no porque el programador sea bueno o malo sino porque lo más habitual es que el contacto entre usuario y programador haya sido escaso o nulo, y por tanto difícilmente ha podido captar sus necesidades y sensaciones.

Por tanto, documentación, la necesaria, de calidad y actualizada (debiéndose mantener actualizada toda aquella que no se pueda obtener por ingeniería inversa). Si además a partir de ella se puede generar código pues mucho mejor.

¿Tiene la documentación alguna misión más que la de servir de apoyo al proceso de desarrollo? Si tenemos un sistema de información grande en el cual hemos podido tener diferentes proveedores trabajando y se quiere sustituir un proveedor por otro, lo mejor es que haya un soporte documental técnico que facilite la compresión del nuevo proveedor lo antes posible (también lo podría hacer interpretándolo a partir del código, pero puede resultar complejo si el mismo no es muy bueno y si el sistema es de gran tamaño).

Además, si desarrollas un producto tener ciertas partes documentadas vende (y no es ya cuestión de lo que puedas pensar como desarrollador de la utilidad de la documentación) sino de lo que pueda pensar quien te va a comprar la aplicación.

En resumen, lo primordial es que el sistema de información que se ha desarrollado se ajuste lo máximo posible a las necesidades del usuario con el menor número de errores posible pero sin olvidar que también debe ser desarrollado con un código de calidad y se ha debido generar una documentación que debe ser la mínima necesaria para la realización y comprensión del sistema, que también debe ser de calidad y actualizarse, salvo aquellas partes que se puedan obtener de forma rápida y sencilla mediante ingeniería inversa.

Continuemos con el análisis de los principios del manifiesto ágil.

Además de la separación entre el mundo físico y el lógico, el hecho de que el software no se desgaste es a mi juicio una de las dos principales diferencias que tiene con el hardware, sobre todo teniendo en cuenta las tendencias actuales en el mundo del desarrollo orientadas a su industrialización, la reutilización de componentes, la delegación de funcionalidades en otros sistemas, etc… Si bien es cierto que el software tiene un componente de desarrollo a medida que es inherente a él mismo, ocurriendo esto incluso en la orientación al producto, donde en muchos casos hay que hacer adaptaciones para clientes concretos.

La otra diferencia es el propio proceso de obtención de un nuevo componente físico donde no es posible conseguir nada si no se disponen de los materiales necesarios, si se dispone de la materia prima la cadena de montaje empieza a funcionar hasta que se obtiene el producto. Es decir, la obtención de un nuevo producto idéntico a otro tiene un coste. Con el software no pasa eso, una vez construido obtener una copia es algo inmediato y sin coste. Lo mismo pasa con otros productos lógicos digitales como la música o el vídeo.

El software una vez desarrollado no se desgasta, no se estropea. Puedes dejar un programa diez mil años en un dispositivo y sobrevivirá tanto tiempo como el dispositivo que lo contiene y si antes lo has copiado garantizará su continuidad en otro (otra cosa distinta es que se pueda ejecutar o interpretar, este tema lo trato en el artículo: “La oscura era digital”).

Pero el software sí se deteriora, sufre mucho con los mantenimientos, ya sean correctivos, evolutivos, adaptativos o perfectivos (depende de lo que se quiera perfeccionar). El deterioro no tiene por qué ser idéntico en todos los sistemas. Dependerá de muchos factores: la calidad del producto final (a nivel de arquitectura y codificación), su tamaño, de si el equipo de mantenimiento es distinto del de desarrollo y ha existido un período de transición suficiente para poder hacerse cargo de la herramienta, de la urgencia con que sea necesario realizar los mantenimientos y de la cantidad de los mismos (si todo es prioritario y para ya, hay un problema) y de la metodología utilizada (si la misma hace hincapié en la refactorización del código con el objeto de controlar su nivel de calidad y simplicidad el deterioro será sensiblemente menor).

De manera objetiva pudimos comprobar esto en mi organización tras los primeros meses de implantación de Sonar.

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.

Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos:

– Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”

– Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.

Con las definiciones por delante resulta bastante sencillo discernir un tipo de mantenimiento de otro, ya que el primero está centrado en un cambio en las necesidades del usuario o lo que es lo mismo, en una modificación de los requisitos funcionales de la aplicación (por muy pequeños o grandes que sean) y el segundo se basa en los cambios en cualquiera de los elementos que conforman el entorno sobre el que funciona el programa, a los ejemplos que indica Métrica V.3, yo añadiría los servidores de aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si una aplicación se comunica con otra por servicios web y ésta modifica la interfaz el cambio a realizar en la aplicación es de carácter adaptativo ya que el requisito funcional (que es comunicarse con ese tercer sistema) no ha variado.

A lo largo de mi todavía corta experiencia profesional he tenido la oportunidad de vivir diversas migraciones, algunas de mayor y otras de menor calado. Entre las migraciones importantes destaco tres, por el impacto que tenían sobre el conjunto de sistemas de información de la casa, la migración de Oracle 8 a 9i, la migración de Oracle 9i a 10g y la subida de versión del sistema de autenticación y firma electrónica que utiliza mi organización.

De estas tres (y en general de todas las demás) puedo extraer las siguientes conclusiones:

1) La migración no es algo que se realiza en un día o en varios, sino que de por sí es un proyecto, por lo que debe tener una planificación, uno o varios responsables y un equipo que participe en ella.

2) Las migraciones afectan a varios departamentos dentro de informática, por lo que la comunicación entre todas las partes resulta esencial, así como la existencia de más de una persona que tenga una visión completa y general sobre lo que se está haciendo.

3) Las migraciones deben haberse simulado previamente en otros entornos y verificar el correcto funcionamiento de los sistemas de información en los mismos, es decir, previamente se deberán haber modificado todos aquellos sistemas de información que requieran un mantenimiento adaptativo al nuevo entorno y comprobar que tanto estos, como aquellos que no requieran cambio funcionan de manera adecuada. Todas las pruebas y modificaciones que se realicen sobre los sistemas deben estar perfectamente documentados.

4) Estos otros entornos deben ser idénticos al entorno de producción. Cuanto menos parecidos sean, más problemas nos encontraremos el día de la migración. La realización de la migración en estos entornos debe documentarse de manera detallada, destancándose todos aquellos problemas que se produjeron en el proceso de migración (ya que podrían aparecer el día de la migración).

5) Durante todo el proyecto de la migración es muy recomendable contar con el soporte de empresas expertas en los productos que se migran. Si ya es importante el soporte a lo largo del proyecto, es esencial que mientras se realice la migración, éste se encuentre presencialmente en la oficina en la que se realice la migración. Además de estos expertos, es importante contar con soporte sobre los sistemas de información más críticos afectados por la migración, valorándose si basta con que estén localizables o si es necesaria su asistencia presencial.

6) El proyecto de migración puede ser un proyecto de muy larga duración y eso es importante tenerlo presente, para evitar en precipitaciones que podrían dar lugar probablemente al fracaso de sucesivas intentonas de migración. Por tanto, sólo es recomendable migrar cuando se tenga muy clara la posibilidad de éxito de la misma.

7) Antes de realizar la migración, hay que tener claro que sistemas de información se van a ver afectados por la misma y por tanto no estarán disponibles una vez realizada la misma, ya que será necesario preparar los equipos de trabajo necesarios, para que una vez realizada la migración se pongan manos a la obra y adapten el sistema al nuevo entorno. Evidentemente dichos sistemas de información no deben ser críticos, y por tanto asumir una perdida de disponibilidad total o parcial sobre un conjunto de funcionalidades durante unos cuantos días. También como es lógico si hay algún sistema crítico que no va a funcionar tras la migración no es recomendable migrar hasta que este sistema se haya adaptado.

8) Si se espera a que todo esté perfectamente adaptado antes de realizar la migración, probablemente esta no se realice nunca. Por tanto, es esencial que los sistemas críticos estén adaptados y que la mayoría de los no críticos también lo estén, pero es necesario establecer un umbral a partir del cual la migración es realizable.

9) Es necesario documentar con detalle los diversos pasos que se van a dar el día o días de la migración y quiénes son las personas encargadas de realizar cada tarea. También es necesario que esté perfectamente documentada la posible vuelta a atrás. Dado que las migraciones cuentan con una ventana de tiempo para poder hacerse, con el objeto de disponer del mayor tiempo posible, es necesario que todas aquellas operaciones relacionadas con la migración que se puedan realizar previamente a la misma, se adelanten (siempre y cuando no afecten a los sistemas actualmente en producción).

10) Por muy bien que se haya realizado el proyecto de migración y se hayan tenido en cuenta buenas prácticas, del estilo de las que estoy comentando en mi artículo, probablemente se producirán imprevistos durante el proceso de migración, por lo que es importante saber de antemano que no va a ser un camino de rosas.

11) Desde mi punto de vista, la vuelta atrás debe ser siempre la última opción y sólo aplicarse cuando se tenga constancia de que la migración no se va a realizar con éxito. Esto no tiene por qué ser necesariamente tras horas y horas de intentar que todo quede perfectamente ajustado, sino incluso puede ser al principio de la misma. Por tanto, si surgen problemas que pueden intentar solventarse o al menos investigarse, hay que esforzarse por corregirlos y sólo volver atrás si dichos problemas son importantes y/o afectan a sistemas críticos y se llega a la conclusión de que no se van a resolver en la ventana del tiempo disponible para la migración.

12) Si hay que volver atrás o interrumpir el proceso de migración, no hay que venirse abajo, son cosas que pasan y por tanto, que no haya salido a la primera o a la segunda, no quiere decir que no salga bien más adelante. Además se habrá ganado en conocimiento que permitirá incrementar la garantía de éxito de los siguientes intentos.

13) Es muy difícil que una migración salga limpia, por lo que además de los flecos previstos, surgirán flecos imprevistos que se tendrán que corregir los días siguientes a la migración.

14) Es en las migraciones cuando uno se da cuenta más de lo importante que resulta que las aplicaciones estén diseñadas con una tecnología y arquitectura homogénea, que estén bien organizadas en los diferentes servidores de aplicaciones y que tengan una documentación de calidad. Cuanto más de estos ingredientes se tengan más sencillo será el proyecto y el proceso de migración y, por tanto, se reducirán las posibilidades de imprevistos.