archivo

Archivo de la etiqueta: Mantenimiento del sistema de información

Comenta Bertrand Meyer que: “El único gran enemigo de fiabilidad (y tal vez de la calidad del software en general) es la complejidad”, y tiene gran parte de razón.

La complejidad en sus dos vertientes: incluir funcionalidades no necesarias (o hacer más complejas funcionalidades que sí son necesarias) y descuidar la arquitectura y construcción del software haciendo el software mucho más complicado de evolucionar (mayor esfuerzo y mayor probabilidad de errores).

Tenemos que aprender a ser pragmáticos, a dejar de construir la casa por el tejado, a querer rizar el rizo sin ni siquiera tener el producto funcionando y todo ello sin olvidar que si no se construye software de calidad estamos poniendo resistencia y frenos a la capacidad de adaptación y evolución del sistema.

Una solución más compleja no tiene por qué ser mejor, una solución con más funcionalidades no tiene por qué ser mejor y una solución que esté a lo último en tecnología no tiene por qué ser mejor. Lo de menos es más, no es tampoco ciencia exacta, pero la verdad es que funciona más veces de lo que creemos.

Si desarrollas una solución demasiado compleja, al final pasa como con los mandos a distancia, muchos botones, muchas funciones, pero al final no utilizas ni el 10% de ellas.

Por otro lado, añadir complejidad de manera sistemática sin tener el producto en producción supone prácticamente comprar toda la taquilla para un más que probable fracaso y con poco margen de maniobra posterior, ya que tendremos un software mucho más voluminoso que mantener (y con una mayor deuda técnica ) y habrá menos recursos económicos para hacerlo.

Su enunciado es el siguiente: “El proceso de evolución del sistema es consecuencia de un proceso de realimentación (feedback) a diferentes niveles, de manera iterativa y por diferentes actores, y debe ser considerado como tal para conseguir mejoras significativas sobre cualquier base razonable”.

El carácter evolutivo del desarrollo de software lo caracteriza durante todo su ciclo de vida. Es continuo, aunque se materializa mediante incrementos o iteraciones, que pueden ser mediante ciclos más o menos regulares o de forma más discontinua.

En cada evolución se tiene la posibilidad de recabar feedback a diferentes niveles, por ejemplo, calidad estática del código (utilizando algún analizador tipo Sonar), número de defectos que presente al producto, grado de satisfacción del usuario, mejoras o nuevas funcionalidades que quieran incorporar una vez que se han analizado las de la versión que se ha entregado, etc…

Con la información obtenida se pueden plantear diferentes acciones que debidamente priorizadas pueden mejorar la calidad del sistema y que darán lugar a nuevas actuaciones (nuevas evoluciones) sobre el mismo.

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).

Su enunciado es el siguiente: “Las funcionalidades del sistema tienen que crecer constantemente para mantener la satisfacción del usuario a lo largo de su ciclo de vida”.

Se trata de una particularización de la primera ley de Lehman, solo que en este caso no se habla de adaptación y sí de crecimiento (que como ya hemos visto son conceptos que pueden ser complementarios pero que son diferentes).

Los dos principales fundamentos de esta ley se encuentran:

– En que en el proceso de desarrollo de la aplicación, con el objeto de adecuar el alcance a las posibilidades del proyecto (tiempo, presupuesto, etc…), hay funcionalidades que se descartaron o se postergaron, bien por no considerarse esenciales en ese momento o por no poderse acometer su versión.

– Cuando un sistema presenta problemas a la hora de ponerse en marcha en el conjunto de usuarios, en lugar de ponernos a analizar los motivos por los cuales no cumplen las expectativas, se tiende a pensar que la solución se encuentra en la incorporación de nuevas funcionalidades (que tiendan a tapar o a restar protagonismo a las deficiencias que presente la aplicación).

Con respecto a este segundo fundamento, hoy en día se tratan de racionalizar mucho más los desarrollos, de manera que se trata de buscar la solución más simple que trate de satisfacer las expectativas de los usuarios, lo que hace que solo se tenga en cuenta el desarrollo de nuevas funcionalidades si resulta estrictamente necesario.

Su enunciado es el siguiente: “Cuando un sistema evoluciona, todos aquellos que están asociados a él: desarrolladores, personal de ventas, usuarios, deben mantener un conocimiento de su contenido y comportamiento para tratar de conseguir que la evolución sea satisfactoria. Un crecimiento excesivo disminuye ese conocimiento. De ahí que el crecimiento incremental promedio permanezca invariante”.

O lo que es lo mismo, la única manera de que las personas vinculadas al sistema no pierdan el control sobre los cambios que se realizan es que su crecimiento se realice de forma sostenida, de manera que la combinación entre el número, complejidad e impacto de las funcionalidades que se añadan o modifican en cada evolución del sistema se mantenga constante.

También es importante tener en cuenta que cuando un conjunto de personas se acostumbran a una determinada dinámica de funcionamiento del sistema, les resulta más complicado encajar cambios sensibles sobre el mismo. La costumbre se termina imponiendo a nuevas ideas o por lo menos a aquellas que puedan interpretarse como disruptivas.

Su enunciado es el siguiente: “La velocidad (y efectividad) de desarrollo de un sistema en evolución permanece invariante durante su ciclo de vida”.

En cierto modo está relacionada con la anterior ley, porque no deja de ser un atributo más que se autorregula por el propio contexto en que se desarrolla el sistema y por sus propias características.

Según esta ley (con la que se podrá estar más o menos de acuerdo), es complicado que se den todas las condiciones adecuadas para que la velocidad de desarrollo de un determinado sistema aumente, porque cuando se tenga un buen equipo de trabajo lo mismo son los responsables funcionales o el personal directivo los que se muestran indecisos, toman decisiones erróneas, tienen que reducir o cambiar el equipo por motivos económicos u optan por ralentizar la evolución o cuando estas circunstancias sean favorables, lo mismo es el equipo el que no responde.

A lo anterior hay que sumar otros factores como son el incremento de la complejidad que compensaría (en negativo) un mejor funcionamiento de la organización o el hecho de que haya algunos atributos que según la tercera ley de Lehman se mantienen constantes como, por ejemplo, la tasa de errores (que también afectan a la velocidad de desarrollo).

Haciendo medias de esas situaciones se entenderá que la efectividad de la evolución se mantiene más o menos constante durante su desarrollo.

Su enunciado es el siguiente: “El proceso de evolución de un sistema es autorregulado con una distribución de las medidas del producto y del proceso cercana a la normal”.

¿Qué quiere decir eso? Que el propio contexto en el que se evoluciona el sistema (junto al propio sistema) generan unas condiciones que provocan que haya una serie de características del producto que sigan una tendencia o se mantengan invariantes, de manera que por ejemplo, atributos tales como el tiempo entre entregas, el número de defectos detectados o el tamaño, sigan una determinada línea.

Esas condiciones surgen por las propias características del sistema o por las propias características de la organización, ya que no hay que olvidar que los desarrolladores hacen su trabajo bien para un cliente o bien dentro de una organización más grande que tendrá implantados otros sistemas y que tiene unas prioridades que van variando en función de las propias necesidades de la organización.

La propia complejidad del software interviene como un elemento más de este proceso autorregulador, de esta forma podemos asociar esta ley con la segunda de la siguiente manera:

– Podemos hacer actuaciones para reducir la complejidad o realizar mejoras en nuestras prácticas de trabajo, que siempre se encontrarán limitadas por las propias características del sistema y su contexto, es decir, se puede mejorar, pero siempre habrá una “carga extra” que tendremos que soportar.

– En el caso de que evolucionemos el sistema (aún sin la realización de medidas específicas para mantener o reducir la complejidad, sin que eso quiera decir que no se apliquen buenas prácticas), habrá una serie de atributos que permanecerán constantes, como podría ser la tasa de errores, o que crecerán proporcionalmente (siguen una tendencia) como el tamaño del sistema.