archivo

Archivos Mensuales: febrero 2014

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.

Su enunciado es el siguiente: “Cuando un sistema evoluciona se incrementa su complejidad a menos que se trabaje para mantenerla o reducirla”.

La complejidad crece no solo a nivel de deuda técnica (algo que es razonable por el incremento del tamaño del sistema), sino también a nivel de administración, usabilidad y recursos software y hardware necesarios para su funcionamiento.

Si se tiene cuidado y se aplican buenas prácticas, este incremento de la complejidad puede hacerse más moderado e incluso puede reducirse si se aplican medidas específicamente destinadas a este fin (que se complican cuando a la vez se están incorporando nuevas funcionalidades al sistema).

Lo que viene a decirnos (de la mano de la Primera Ley) es que con el paso del tiempo va a ser necesario evolucionar las aplicaciones y que ese coste será progresivamente mayor conforme se realicen nuevas actividades de mantenimiento en el sistema.

Su enunciado es el siguiente: “Los sistemas deben ser continuamente adaptados o se convierten progresivamente en menos satisfactorios”.

No todos los sistemas requieren el mismo nivel de evolución pero sí que es cierto que el contexto cambia y que tarde o temprano (en algunos casos más pronto que tarde) será necesaria una adaptación al cambio.

Es importante tener en cuenta que la adaptación no implica necesariamente un crecimiento del sistema (si bien en la mayoría de los casos pueden estar ligados), ya que un proceso de adaptación puede estar basado en una nueva forma de enfocar las funcionalidades ya implementadas en el sistema o en una reingeniería del proceso que se ha informatizado.

Es cierto que hay sistemas que no se han tocado en años pero, ¿es realmente porque no es necesario o por el coste que tendría asociado?. El motivo principal de que estas aplicaciones no se toquen es económico a lo que hay que sumar el factor de incertidumbre (o miedo) de retocar un sistema que está funcionando (con más o menos satisfacción para la organización y para los usuarios) y que por dentro se sospecha que está todo cogido con alfileres.

Lo que viene a decir esta ley es que no podemos pensar es que nuestra inversión no termina con la adquisición del producto software o con su desarrollo a medida, sino que tendremos que seguir realizando nuevas inversiones para adaptar el mismo a los cambios en las necesidades de la organización, del mercado, etc…

O lo que es lo mismo, el mantenimiento es inevitable.