Complejidad ciclomática: Diseño Social. (6)

Introducción.

Hace años , Lord Kelvin reflexionaba: «Cuando se puede medir aquello de lo que se habla y se puede expresar en números, se conoce algo  sobre el tema; pero cuando no se puede medir, cuando no se puede expresar en números, el conocimiento es pobre e insatisfactorio”.

Más próximo a nosotros, DeMarco –1982- dice “No se puede controlar lo que no se puede medir” y  añade que “No se puede predecir acerca de lo que no se puede controlar, es decir, de lo que no se puede medir”. Resumiendo: si no se puede medir no se puede ni controlar ni predecir.

Nuestra propia naturaleza nos dota de la capacidad perceptiva de la medida de una magnitud, como por ej, la velocidad; y esa percepción natural la utilizamos para conducir. Podemos no saber exactamente a que velocidad va el otro vehículo, pero calculamos que nos da tiempo a realizar la maniobra…si todo sigue igual. Tenemos, de fabrica, un velocímetro sencillo de utilizar y complejo de fabricar.

La creación de software es lo  más parecido a nosotros mismos, que somos capaces de diseñar  (ha de considerarse que en el proceso de reproducción, ni el hombre ni la mujer tienen que efectuar labor de diseño alguna).

Por otra parte y desde el punto de vista organizativo, seguimos sin tener una herramienta clara y fácilmente utilizable, que nos lleve a adoptar un determinado modelo con preferencia clara sobre otros. Esta deficiencia se observa en la estructuración social y, como muestra, podemos fijarnos en la organización de las Áreas metropolitanas; ¿existe alguna razón por la que sea preferible un Ayuntamiento Metropolitano a 45 Ayuntamientos (uno por cada Municipio miembro de la citada Área??.

Software.

Teoría de la medición del software.

1. Medir implica relacionar dos mundos: el empírico o real  y el matemático o formal.

2. Necesitamos saber que queremos medir –conocer claramente la entidad  , la propiedad o propiedades  a medir y el o los atributos -. A las propiedades se le asigna una unidad de medida o magnitud que variará según una escala.

3. Por supuesto, científicos, creadores y empresarios de software aceptan la necesidad de medir en la creación de Aplicaciones Informáticas . En un primer instante, podemos desear medir una entidad que denominamos “complejidad del software”: habrá aplicaciones más simples que otras!!!; pero pronto descubriremos que dicha entidad tiene un significado genérico e impreciso; es preciso definir y especificar propiedades. En el terreno de las escalas, debemos considerar que al menos hay cuatro tipos, a saber: Nominal , ordinal , de intervalo  –admite suma y resta-, de ratio – admite todas las operaciones aritméticas-.   Las escalas nominal y ordinal , suelen denominarse categóricas, reservando el nombre de variables de escala para las de intervalo y ratio.

Después de innumerables esfuerzos para desarrollar una métrica, esta puede verse afectada por limitaciones de base, que no la invalidan pero que efectivamente la “limitan”; así, en general, los puntos de función entran dentro de la escala categórica: podemos hablar de Mayor o Menor que, pero no podemos realizar operaciones aritméticas con los valores asignados.

Deseo transmitirles que, mientras que muchas mentes van pensando sobre la medición, desde una perspectiva básica, otras personas como integrantes de una industria tiene que dar respuestas prácticas para responder concretamente a preguntas aparentemente simples y cotidianas:

1. Cuanto me cuesta?

2. Cuando  lo acaba?

3. Como puedo saber algo acerca de su calidad?

4. Que hay del mantenimiento? ( “fácil” o “difícil” de modificar?). Gestión de proyectos de Software.

Llevar adelante un proyecto de construcción de software es complicado; como en todo proyecto, se deben de cumplir requisitos, tiempo, coste, utilización de recursos y personas, limitados. Se inserta una breve clasificación de algunas de las complejidades que habría que tener en cuenta en una métrica de un proyecto, siguiendo las etapas de su desarrollo.

Complejidad de los requisitos (Núm de entidades y funciones descritas)

Complejidad del diseño (Núm módulos, Complejidad de McCabe)

Complejidad del código (Núm de módulos, Complejidad de McCabe)

Complejidad de las pruebas (Núm caminos de prueba)

En vez de “Complejidad del software”, hemos citado cuatro complejidades y posibles propiedades para dar idea de que la tarea emprendida no es sencilla.

El “Sistema de valor conseguido” originario del Departamento de defensa de EEUU –1.996- es un método que supera la información de PERT y GANTT; como utilidades destacadas, sirve para seguir la ejecución de un proyecto de software, facilitando:

1. Indicación del progreso del trabajo realizado

2. Relación entre coste, plazos y compromisos

3. Posibilidad de ser auditado 4. Suministro a los gestores de información asequible.

También se utilizan  modelos de sistemas dinámicos para la simulación del desarrollo de los proyectos de software. Ramos y Ruiz (1998)  han elaborado el Modelo Dinámico Básico, útil en aquellas situaciones en que la información es escasa (por ej, en los primeros contactos con el cliente).

No obstante lo anterior, podemos citar tres métodos ampliamente utilizados para Contestar a ¿Cuánto me cuesta?:

1. Algorítmico. Utiliza información histórica acerca de tamaños y costes. Puede citarse COCOMO,

2. Analogía y juicio de expertos. Se basan en su experiencia y por tanto en la estimación de construcciones similares.

3. La mejor oferta. Viene a adaptarse a las disponibilidades del cliente o –al revés- a confiar en la competencia de suministradores para decantarse por la mejor oferta.

Referente a la complejidad ciclomática.

Por complejidad ciclomática, se entiende el número de caminos lógicos individuales que un programa debe evaluar hasta obtener un resultado. Thomas J McCabe  utilizó la teoría de grafos para determinar el grado de complejidad ciclomática de un algoritmo; cada porción de código a evaluar representa un grafo independiente donde cada instrucción se identifica con un nodo y cada posible vía de ejecución una arista.

Para calcular la complejidad ciclomática podemos aplicar la formula siguiente: V(G) = e – n + r+ 1

Donde:

• e es el número de posibles ramificaciones que el programa puede adoptar (aristas)

• n es el número de nodos

• r es el número de puntos de salida de la función (return, End), procedimiento.

Consultar en Wikipedia 1  2

Medición y aseguramiento de la calidad del software.

Se trata de ver cuando la aplicación o sistema creado responde a las necesidades del cliente. A primera vista son básicos los requerimientos y los registros de medición. Las métricas aplicadas deben de respetar los siguientes principios:

1. Claridad de descripción

2. La relación del valor de la métrica y la calidad del producto debe estar justificada y ha de ser comprendida con facilidad

3. Se debe comprender como evoluciona la métrica con el incremento de calidad y al revés.

4. Se tiene que describir las métricas que permiten comparar proyectos y proveedores.

Factores/criterios/métricas (FCM) es un modelo muy elaborado y que debe tenerse en cuenta, al menos,  como fuente de ideas. Los valores de defectos permiten una clasificación de la calidad del software; se propone la siguiente clasificación, producto de estudios en cientos de empresas.

Muy elevado:  Más de 10 por mil líneas de código

Ajustado: 2 ó 3 defectos por 1.000 líneas de código

Muy bueno: 3 ó 4 defectos por cada millón de líneas de código.

Mantenimiento del software desde una perspectiva del proceso.

Tipos y en %, los recursos consumidos.

Perfectivo > 60%

Correctivo>17%

Adaptativo>18%

Preventivo>5%

Hoy, como hace 20 años, se sigue efectuando mantenimiento usando la “técnica” QF ( Rápida reparación) que sigue inexorablemente la segunda ley de Lehman (1980): progresiva degradación con cada nuevo cambio; tengo la percepción de que es el envés de las pymes de fabricación de software. Es posible que la segunda ley de Lehman también pueda aplicarse a las organizaciones, al Diseño Social.

Se ve como preciso:

1. Mejora de la comunicación entre usuarios y grupos de mantenimiento: utilización de herramientas consistentes que mejoren la comunicación

2. Uso de herramientas de ingeniería inversa y reingeniería que ayuden al programador de mantenimiento a comprender el sistema

3. Utilización de repositorio para aprender

4. Formalización del proceso de mantenimiento 5. Implementación de medición (lineas de código añadidas, borradas. Modificadas; esfuerzo en horas-programador; satisfaccion del usuario con mantenimiento; núm de problemas sin resolver; tiempo medio de resolución;…)

Organización.

Organización Requerida

En la obra del mismo título , Elliott Jacques plantea la distinción  entre organización entre iguales y las organizaciones empresariales o ejecutivas que construimos los humanos; en ambos tipos de organizaciones hay al menos  tres elementos básicos:

1. La estructura.

2. Las personas.

3. La interacción de las personas entre sí, asumiendo cada una su cometido organizativo.

Un postulado básico de la OR es que se puede y se debe estudiar a las organizaciones con independencia de las personas que contingentemente ocupan los roles . No obstante lo anterior, entiendo que no podremos avanzar en el conocimiento acerca de cómo puede evolucionar una organización concreta sin considerar las personas que están en ella y la interacción de esas personas o de la organización con el entorno.

Los humanos creamos este tipo de organizaciones (JGR), pues permiten en distinto grado:

1. Resolver problemas  mediante aportaciones de ciertos insumos (trabajo, capital) y mediante la toma de decisiones .

2. Lograr los fines propuestos como organización consiguiendo una compatibilización con las metas personales  y niveles crecientes de eficacia y eficiencia.

3. Aplicar el liderazgo .

4. Manejar  la complejidad , que es creciente .

En el desarrollo de la obra trata aspectos como:

1. Definiciones básicas

2. Acerca de los procesos mentales y la intencionalidad (personas).

3. Intervalo temporal (roles).

4. Peso del puesto de trabajo. Estratos de trabajo. Niveles de estructura

5. Desarrollo personal. Remuneración salarial: paga sentida como justa.

6. Respondibilidad [“accountability”] gerencial .

7. Alineamiento funcional.

8. Control.

9. Relaciones no jerárquicas.

Este tipo de organizaciones, que presentan notables logros, los consiguen aún a pesar de acumular graves defectos, algunos de los cuales señala el mismo autor, quizás de forma algo vehemente,  en el debate ya citado y publicado en Human Relations:

“Estos sistemas de roles dominan hoy a nuestras sociedades democráticas de libre empresa. El noventa por ciento de las personas que se ganan la vida lo hacen por un sueldo o salario en un rol dentro de un sistema de este tipo. Estos sistemas tienen un enorme impacto sobre todo el mundo: de ellos depende la experiencia cotidiana de confianza o de suspicacia en las relaciones entre la gente, la seguridad o ansiedad económica, la oportunidad –o la falta de ella– de ejercer a pleno nuestra capacidad, el desarrollo o estancamiento de las carreras, las diferencias en la condición económica de las familias dentro de un mismo país, la paz o el conflicto en la industria. La forma en que diseñamos estos sistemas en y por sí mismos se ha trasformado en una cuestión de importancia central para la salud de la sociedad. Las jerarquías de empleo que dominan nuestras sociedades democráticas de libre empresa son en su mayor parte conventillos y pantanos, y ejercen un efecto pernicioso generalizado que amenaza a la sana democracia. Los empleados, desde los altos ejecutivos hasta los trabajadores rasos están empaquetados como sardinas en lata, agolpados unos contra otros en estructuras con un exceso de niveles. Los gerentes respiran en el cuello de sus subordinados, y tienen poco para elegir entre ellos en cuanto a capacidad diferencial. En estas condiciones, el liderazgo gerencial efectivo es un artículo escaso. El pleno empleo, crucial para la salud social, nunca ha sido establecido como un derecho político. Los sistemas de remuneraciones son un absoluto desmadre, las posibilidades de tener un trabajo adecuado a la propia capacidad son leves y espasmódicas, los sistemas de carreras y de desarrollo de la reserva de talentos son primitivos en el mejor de los casos, y así siguiendo: la lista es interminable. Y nuestros “gurúes” organizacionales no hacen otro cosa que aumentar el desbarajuste con un flujo de modas aparentemente infinito, todas las cuales empeoran las cosas más aún”

Lo que E.Jaques denomina  organización requerida es fruto de los diferentes trabajos de investigación y de la experiencia acumulada en 50 años de ejercicio profesional; en absoluto  es un  invento esperanzado, una idea feliz. Esta “organización requerida”,  en armonía con la naturaleza humana, tiene como notas fundamentales las siguientes:

1. La organización debe estar estructurada, como máximo, en 7-8 niveles ; la persona que se encuentra en el nivel último -8º- tiene un “lapso temporal”  de 50 años y su remuneración puede ser hasta 32 veces superior a la de un gerente de nivel uno –que tiene un “lapso temporal” de un año-. Seguimos esta nomenclatura de niveles: nivel primero, el más simple, para la persona-; nivel octavo, el más complejo, el de mayor lapso temporal/Corporación multinacional.

2. En base a centenares de estudios de tipo salarial, es posible dibujar un   diagrama de progreso potencial. No obstante, si esos diagramas fueran correctos, implicaría que la evolución profesional futura viene marcada por tres importantes consecuencias:

a. Todos podemos mejorar (salarial y potencialmente), si bien no en la misma medida.

b. La mejora está limitada.

c. Progresa más rápidamente quien progresó más rápidamente.

3. Toda organización precisa de  una  alineación funcional requerida: Se trata de colocar en cada estrato las funciones correctas. Entendiendo por función un conjunto de responsabilidades (ventas, desarrollo, producción…) . Dice: “permítame insistir: el tema no es la centralización frente a la descentralización, sino la asignación de las tareas adecuadas al nivel adecuado de la organización” . Las funciones / aspectos pueden delegarse en todo o en parte.

4. Responde de forma gráfica a  preguntas cruciales en una organización: ¿Quién responde por qué cosas? ¿Quién puede impedir a quién que haga qué?¿ Quién puede tomar la iniciativa para asesorar a quién? ¿Quién puede cambiar los procedimientos? ¿Quién puede exigir qué clase de información?¿Quién puede solicitar servicios?¿Quién debe informar sobre quién y sobre qué?

5. Referente al flujo de trabajo interfuncional , descarta las comisiones, los equipos interfuncionales y plantea una estructura base, en la cual se incluyen las Relaciones RRIT  / RRAT .

En el epilogo de la obra citada, E. Jaques plantea la  conveniencia de distinguir entre:

Entidades: se cuentan de una en una; las personas, las  bombillas, pymes, comunidades autónomas, pueden contarse. Toda entidad tiene propiedades y atributos.

Propiedades: características de las Entidades que se miden en unidades específicas (amperios, dioptrías). De la entidad “bombilla” se mide el voltaje, la intensidad de corriente, la luminosidad. De las personas puede medirse la altura, el peso, la agudeza visual, el colesterol.

Atributos: Opiniones  sobre las entidades, por ejemplo, de la entidad “bombilla” se piensa que este modelo es más bonito que este otro,  de la entidad “persona” se opina que A es más amable, tolerante, violenta, hermosa que B. Si se les asignan números es para expresar que son “más que” o “menos que”,  que pueden calificarse .

En esta parte final dice: “Si alguna vez tenemos éxito en echar los cimientos científicos de nuestra comprensión de la Naturaleza Humana y de las instituciones sociales, tendremos que lograr un cambio  fundamental en nuestra concepción del mundo, pasando  del mundo material de cuatro dimensiones- tres espaciales entretejidas con una temporal- a un mundo de cinco dimensiones, tres espaciales entretejidas con dos temporales.” Esta quinta dimensión es la derivada de la intencionalidad humana.

Medir la Complejidad  ciclomática de la organización.

Las organizaciones pueden describirse utilizando organigramas, informes psicológicos, diagramas de flujo, cuadros de mando integral, la normativa contable en vigor… Varios de esos medios  descriptivos son cuantitativos (por ejemplo, la contabilidad).

1. Dado que las organizaciones del tipo JGR en general y las Administraciones Públicas en particular, disponen de un alto grado de mecanización de procesos y de utilización de aplicativos informáticos que interaccionan con los funcionarios y/o trabajadores en general, para la realización de una parte cada vez más importante de su trabajo,

2. Dado que los procedimientos de las AAPP están regulados, de forma que la mecanización se hace sobre la Ley vigente,

3. Dado que en al artículo e referencia, TJ McCabe dice: “In general, the complexity of a collection C of control graphs with k connected components is equal to the summation of their complexities”. V(G) es una variable de escala tipo ratio, por lo que, al poder realizar todas las operaciones aritméticas, puede demostrarlo.

4. Dado que las personas operamos con unos procedimientos interiorizados, susceptibles también de modelización por software; su V(G) será mayor de 1 y podemos asociar a incertidumbre las posibles desviaciones procedimentales “oscuras” y/o delictivas.

Planteo la conveniencia de calcular la complejidad ciclomática de las AAPP (tipo específico de organizaciones JGR) como criterio orientador para la estructuración o diseño social.

Al respecto se recuerda que:

Complejidad Ciclomática/ Riesgo

1-10/ Poco riesgo

11-20/ Riesgo moderado

21-50/ Alto riesgo

>50/ Programa no testeable, muy alto riesgo.

Si puedo medir la complejidad y acepto que para lograr un objetivo concreto, es preferible la estructura menos compleja, más eficiente y más eficaz : puedo diseñar organizaciones (con un alto grado de procedimientos mecanizados), basándome en la complejidad ciclomática.