archivo

Archivo de la etiqueta: sistema de información

Decía Aristóteles que: “El cambio en todas las cosas es dulce”.

Es dulce si se asimila el cambio, si se entiende que es inevitable porque cada día el mundo sigue girando.

Si no se asimila y se entiende que la situación actual es la adecuada y no va a cambiar es cuando llegan los problemas. Tal vez la situación sea adecuada, confortable, positiva, dulce incluso, y es bueno disfrutarla y sacarle todo el provecho posible, pero se debe estar dispuesto y, sobre todo, preparado, para el cambio.

La tecnología está en continua evolución, las personas también. Las organizaciones deben ser conscientes de eso, quien antes era un competidor insignificante tal vez sea hoy quien te esté quitando el mercado y lo peor no es eso, cada día surge nueva competencia más adaptada al contexto actual.

Los sistemas de información no son ajenos a los cambios, teniendo en cuenta que soportan procesos organizativos y que estos se van a ir modificando. El software tiene sentido si existe un usuario, si el usuario y/o su contexto, cambia, evoluciona y sabemos que es una característica inherente, podemos decir que la necesidad de cambio es también inherente al software.

Otro aporte de Lehman consistió en el hecho de que 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.

Más controvertidas resultan otras afirmaciones de Lehman, en las cuales considera que determinados atributos relacionados con el desarrollo de software (tamaño, número de defectos, tasa de crecimiento), etc…, se mantienen más o menos constantes o siguen una tendencia (una proporcionalidad) a lo largo del proceso de evolución del software.

Estas afirmaciones, personalmente me parecen más discutibles (no quiero decir que no esté de acuerdo en todas), si bien, pese a que me base en mi propia experiencia, no he analizado datos empíricos para verificar si efectivamente se cumplen o no.

En los próximos días se van a publicar una serie de artículos sobre las 8 leyes de Lehman de evolución de los sistemas.

Lo más significativo de ellas es que trata de establecer una serie de pautas relacionadas con la evolución de los sistemas, tratando de generalizar ese comportamiento al conjunto de los mismos.

No es necesario estar de acuerdo con las mismas, de hecho, hay alguna que os parecerá más que discutible o que aplicando el enfoque adecuado se puede resolver o atenuar el problema que describe.

Me parece especialmente interesante el hecho de que Lehman considere la evolución de los sistemas (su mantenimiento) como algo inevitable, por mucho que te esfuerces en desarrollar una versión del producto que trate de ser definitiva.

Uno de los problemas que nos encontramos los desarrolladores de software es que el área usuaria no entiende que un producto requiera de un mantenimiento posterior, pese a que sean ellos mismos los que sugieran o provoquen esos cambios (pese a que entiendan que deberían haber sido tenidos en cuenta en el proceso de desarrollo). Y eso que tienen todos los ejemplos que quieran en el mundo real, más allá del desarrollo de software, para entender la necesidad de una evolución, una adaptación o un mantenimiento del software.

Es cierto que el software es un elemento lógico y que como tal no se desgasta (de ahí la diferencia con el mantenimiento de un elemento físico) pero también lo es que las necesidades de los usuarios, de la organización o del negocio varían, así como su capacidad de inversión (lo mismo hay funcionalidades que no se abordaron por su coste que ahora sí que interesa llevar a cabo) y no se puede pretender, por irreal, que una primera versión finalista del software tenga en cuenta no solo las necesidades presentes sino las futuras (algo que por otra parte sería temerario salvo que se tuviera muy claro cuál es la línea de evolución del producto, algo que en muchos casos depende de muchos factores y variables externas).

La evolución del sistema no solo va a ser motivada por cambios originados por los usuarios y/o por el contexto (puede ser necesario modificar la aplicación para poder dar una respuesta a un determinado movimiento de un competidor en el mercado o para adelantarse a él), sino por la propia infraestructura que lo sustenta o incluso por los propios componentes, librerías, artefactos o backends que utiliza.

Esos elementos que pueden ser físicos o lógicos también evolucionan y la organización responde a esos cambios actualizando las diferentes versiones que utilizan de los mismos o sustituyéndolos por otros, ya que generalmente resuelven problemas de seguridad, robustez, rendimiento y eficiencia. Además estos cambios de versiones llevan aparejados una pérdida de soporte por parte del fabricante, por lo que por un motivo o por otro no tenemos más remedio que terminar evolucionándolos.

Este cambio, a su vez provoca una evolución de los propios sistemas (tareas en este caso de mantenimiento adaptativo), con el objeto de que puedan seguir funcionando en ese nuevo contexto tecnológico.

Lo mismo sucedería, por ejemplo, con las propias librerías que utiliza la aplicación, ¿no cambiaríamos de versión de determinadas librerías (siempre y cuando tengamos la oportunidad de hacerlo) si las nuevas versiones mejoran, por ejemplo, el rendimiento del sistema?.

¿Cuántas veces hemos diseñado un sistema que aparentemente era simple y que por el hecho de querer contemplar una casuística que se produce en raras ocasiones se ha complicado casi exponencialmente?.

Demasiadas, ¿verdad?.

En el caso de que ese uno por ciento (o similar) se produzca y no esté contemplado en el sistema de información, ¿se pone en peligro la vida de alguien?, ¿puede suponer un perjuicio económico (tangible o intangible) que ponga en cuestión la supervivencia de la organización? Si la respuesta es que sí, ese uno por ciento debería estar, de manera indudable contemplado, cueste lo que cueste.

Ahora bien, ¿y en el resto de los casos? En mi opinión, si merece la pena se puede diseñar una “puerta trasera” o “desván” para estos casos, en los que de alguna manera se registre su información en el sistema y así, por lo menos, tenemos almacenada su información, pero yo no complicaría el sistema más allá de eso por contemplarlos.

Es cierto que casuísticas puede haber muchas y que incluso en sistemas no críticos interese contemplar esos casos. Como siempre digo, cada aplicación es un mundo y requiere ser analizada y los responsables técnicos y del área funcional son los que deben tomar las decisiones sobre la dirección que debe tomar el sistema.

Si el área usuaria para en la definición del sistema lo mejor es parar el proyecto hasta que la situación se reconduzca. Esto tiene muchos inconvenientes, entre otras cosas porque puede deshacer al equipo de desarrollo y dar al traste con planificaciones generales de parte del Departamento de Informática y con las expectativas de los responsables funcionales cuyas necesidades dieron lugar a este trabajo.

Pero por mucho inconveniente que nos encontremos ninguno será superior a desarrollar un sistema de espaldas al usuario por mucho que hayan sido los propios usuarios designados para definirlo los que se hayan puesto de espaldas al mismo.

La tentación de liarnos la manta a la cabeza y continuar es muy grande porque probablemente encontremos presiones que nos empujen a ello (si somos un proveedor de servicios de desarrollo de software tendremos a los responsables de turno protestando porque el taxímetro se ha parado, si eres el responsable técnico del cliente tendrás al proveedor protestando por el motivo anterior, etc…), sin embargo la solución no debe pasar por ahí, sino por intentar reconducir la situación y si no se consigue, negociar una salida digna para todas las partes.

En muchas organizaciones hay sistemas de información o herramientas (más de uno, más de dos y más de tres) que tras una inversión importante en tiempo y esfuerzo se quedan en una simple url o en un icono de escritorio accesible por sus potenciales usuarios pero olvidada y abandonada por estos.

Otras veces nos encontraremos con sistemas y herramientas que ni siquiera llegaron a terminar de construirse, quedando en simples ruinas cuyos vestigios puedan ser consultados, con suerte, en un sistema de control de versiones o en alguna máquina de un entorno de desarrollo o de un programador.

¿Qué nos lleva a esto? Generalmente el hecho de que se haya desarrollo o adquirido un sistema que no cumple con las expectativas del usuario a nivel funcional y/o de experiencia de usuario o bien que no cubra una necesidad real en la organización.

Hay aplicaciones que de un número potencial alto de usuarios y de uso, nos encontramos con que están infrautilizadas, para mi son tan ciudades fantasma como las anteriores, solo que en este caso hay unos cuantos héroes que de manera voluntaria u obligada hacen uso de las mismas.

Hay ciudades fantasmas recuperables pero para ello se requiere un esfuerzo importante y un compromiso de todas las partes: desarrolladores y área usuaria. Los primeros para tratar de ir mejorando de manera progresiva las condiciones de habitabilidad y los segundos para ir priorizando sus necesidades y soportar durante un tiempo unas condiciones de vida duras dentro de la ciudad.

Habrá veces donde lo mejor será buscar otro emplazamiento para la ciudad. Esta decisión es muy complicada de tomar ya que hay una inversión importante detrás y otra inversión importante que se tendrá que hacer de nuevo. No obstante si hay una necesidad que cubrir cuanto antes se tome la decisión mejor porque se corre el riesgo de seguir invirtiendo en algo que tarde o temprano se terminará convirtiendo en un montón de escombro.

Lo he vivido ya en más de una ocasión y lo he sufrido no durante semanas, sino meses y en algún caso hasta años.

Poner en marcha un sistema de información en su totalidad o en gran parte sin que ningún usuario lo haya utilizado en un entorno o contexto real es una condena para el propio sistema de información y para quienes lo gestionan.

Llegarán peticiones de mejora e incidencias superiores a la capacidad que se tendrá para dar respuesta (si es que dispones de esa capacidad, ya que pocas veces se prevé que lo que se desarrolla hay que mantenerlo, de hecho los responsables o directores funcionales del sistema es lo que pensarán si no se les explica de manera adecuada y con carácter previo qué es un desarrollo de software y qué consecuencias tiene los cambios en las especificaciones sobre el coste del proyecto) y la puesta en marcha del sistema se convertirá en una cuesta arriba que no parece tener fin a la vez que no termina de aflojar su pendiente.

Es la consecuencia de la aplicación de metodologías clásicas y del efecto bola de cristal donde se piensa que todo lo definido hace meses (cuando no años) por personas que lo mismo ya no trabajan en la organización o están en otro departamento sigue siendo válido cuando se pone en marcha el sistema. Esto sucederá en la mayoría de los casos incluso habiendo realizado un análisis muy riguroso (en todo caso, la calidad del análisis reducirá los problemas, algo que, sin duda, se agradece, pero que no resuelve el problema de fondo).