archivo

Archivos diarios: junio 26, 2010

Otras métricas de calidad que resultan interesantes de estudiar están relacionadas con el cálculo de acoplamiento aferente (hacia dentro) y eferente (hacia afuera) de un paquete y la relación entre los mismos, dando lugar a una métrica resultado de ellas denominada inestabilidad de un paquete. Estas tres métricas fueron propuestas por Robert Cecil Martin aka “Uncle Bob” (más conocido posteriormente por liderar iniciativas orientadas a metodologías ágiles de desarrollo y programación extrema) en el año 1995.

Desde la perspectiva de un paquete concreto el acoplamiento aferente se produce cuando otro paquete hace uso de atributos y/o métodos de clases de dicho clase o hereda de alguna de ellas y el acoplamiento eferente se produce cuanto dicha clase hace uso de atributos y/o métodos de clases de otro paquete o hereda de clases de dicho paquete.

Por tanto el cálculo del acoplamiento aferente se obtiene mediante la suma de clases de otros paquetes que cumplen las características indicadas en el párrafo anterior y el acoplamiento eferente se obtiene como la suma de clases de otros paquetes de los cuales dependen clases del paquete con el que se está trabajando.

Como su propio nombre indica se trata de métricas de acoplamiento y como hemos estudiado previamente en las métricas de Chidamber y Kemerer, existe relación directa entre el acoplamiento, la complejidad, la mantenibilidad y la selección de clases (o paquetes) donde hay que prestar más atención a la hora de realizar las pruebas unitarias.

Un alto acoplamiento aferente hace referencia a un paquete con un alto grado de responsabilidad. La responsabilidad y la estabilidad son dos conceptos que suelen ir cogidos de la mano, precisamente porque al existir un elevado número de clases que dependen de clases del paquete, se tiene que ser necesariamente más prudente a la hora de realizar modificaciones en clases del paquete por los posibles efectos colaterales que se pueden producir. No obstante la estabilidad de un paquete no es función exclusivamente del acoplamiento aferente como veremos más adelante en la definición de inestabilidad.

Un alto acoplamiento eferente hace referencia a un paquete con un alto grado de dependencia. La dependencia y la inestabilidad son también dos conceptos íntimamente relacionados, ya que el funcionamiento de las clases del paquete dependen del comportamiento de clases externas, lo que las hace susceptibles de efectos colatarales en las modificaciones de las mismas y por tanto su funcionamiento entraña una mayor incertidumbre.

La inestabilidad de un paquete es la métrica que enfrenta entre sí al acoplamiento aferente y eferente a través de la siguiente fórmula:

Inestabilidad = Acoplamiento eferente / (Acoplamiento eferente + Acoplamiento aferente)

Por tanto los valores de inestabilidad se encontrarán dentro del rango de valores entre 0 y 1.

Estudiando los valores extremos podemos afirmar que si la inestabilidad de un paquete es 1 quiere decir que el acoplamiento aferente es 0 o lo que es lo mismo ninguna clase externa al paquete tiene una relación de dependencia respecto a una clase del paquete, por lo que el paquete sólo tiene dependencias hacia clases externas al paquete. El valor 1 indica una inestabilidad “extrema” del paquete (no obstante, habría que valorar también el valor individual del acoplamiento eferente, ya que, es una opinión personal mía, no todas las inestabilidad con valor 1 tendrían por qué ser iguales) ya que por un lado su comportamiento depende de clases externas, lo cual la hace posible víctima de efectos colaterales y por otro el hecho que no haya clases que dependan del paquete, da una mayor libertad a la hora de realizar modificaciones en el mismo ya que no hay que pensar en terceras clases a la hora de realizar modificaciones en el mismo (también habría que matizar esto, ya que puede haber dependencias entre clases del paquete, medibles mediantes distintas métricas, que provoquen que no sea tan ágil o sencillo modificar el paquete).

Si la inestabilidad es 0 quiere decir que el acoplamiento eferente es 0, lo que viene a decir que el paquete solo tiene responsabilidades y por tanto es menos proclive al cambio debido a que modificaciones en el mismo pueden tener repercusiones en clases externas.

Como la inestabilidad puede tomar cualquier valor entre 0 y 1, en función de a qué extremo se acerque más podemos darle una interpretación al resultado.

Existe un cierto tipo de usuarios que aparecen pocas veces al cabo del año pero que cuando lo hacen generan mucho ruido.

Aparecen con una incidencia o con una petición que es lo más urgente que existe, que no pueden trabajar si no se realiza esa tarea y que es posible que el mundo deje de girar si para antes de ayer no la tienen disponible.

Una vez generado el ruido y haber puesto sobre aviso a todas las personas que hayan podido, desaparecen. Trasladan la responsabilidad funcional de la tarea a otra persona (que lo mismo está puesta sobre aviso o no) y no quieren saber nada más de la tarea, solo que se ejecute y cuanto antes.

Generalmente estas incidencias o peticiones no son tan graves y su urgencia es el resultado de la falta de modulación de la misma por parte de estos usuarios, es decir, reciben una queja (que lo mismo es vehemente) y como no quieren que se les vuelva a molestar por lo mismo le dan una urgencia a la misma que no le corresponde y por supuesto eluden cualquier responsabilidad al respecto (lo mismo lo que “falla” no es software sino que la especificación que facilitó en su día no es la adecuada) porque lo suelen tener claro: se quejan del sistema de información, pues nada, que lo corrija el Departamento de Informática que para eso está (de hecho procurarán darle tus datos de contacto al que les remitió la queja para que se pongan en contacto contigo).

¿Qué se hace con este tipo de usuarios? Es complicado porque además suelen tener una posición en la organización superior a la que tienes tú. Mi recomendación es que hagas una evaluación de la petición o incidencia que ha realizado: complejidad de realización de la tarea, recursos disponibles y tu opinión sobre el grado de criticidad (es probable que tu conocimiento del sistema sea mayor que el suyo) poniéndote en contacto, si fuera necesario, con quien reportó la incidencia.

Una vez hecho eso se informa al usuario que te reportó la tarea (aunque sepas que no te vaya a echar cuenta, es importante que quede constancia de que le has avisado), a la persona o personas que designó y al peticionario original y se trata de consensuar cómo y cuándo se le va a dar respuesta a la misma (lo mismo no hay medios y hay que buscar financiación para los mismos). Generalmente se suele llegar a acuerdos ya que una vez puestos los pies en el suelo, lo que era tan urgente no lo suele ser tanto y se coge también conciencia de los recursos reales que están disponibles para la realización de esos trabajos.

El problema no es el ruido, no es que se quejen sino el hecho de que el producto solo exista cuando se les “molesta” a ellos (lo mismo, en medio de todo eso, han existido problemas más importantes en el sistema en los que ni siquiera ha intervenido porque no se ha llegado a enterar o más bien porque nadie les ha “molestado” con ellos) y esa existencia se limita al intervalo de tiempo que tardan en largar la responsabilidad a terceros (y a recordarte cada cierto tiempo (si vuelven a ser “molestados”) con el mismo ruido).