Cuando estudiaba la carrera de ingeniería informática, recuerdo que había una asignatura, optativa, llamada… “ingeniería de la programación”, que venía a ser “ingeniería del software”. Apenas la cursábamos unos cuantos, por ser optativa, de último año y perdida entre un montón de asignaturas más.
Durante aquella asignatura fue la primera vez que escuche eso de “métricas software”, concepto cuya importancia para mi, por aquellos tiempos, quedo reducía exclusivamente a aprobar el correspondiente examen, sin imaginar, por aquellos entonces, el importante papel que jugaría en mi carrera en la empresa.
Años más tarde, mi primer trabajo en Madrid fue en una consultora. Allí, después de unos años deambulando en “modo body shopping” por varios clientes, y debido a mi afición por aprender “en los ratos libres” buenas prácticas de diseño software, patrones, etc., lo que tantas veces os he contado, pude ser seleccionado para ser “bodyshopeado” en un proyecto de diseño software (me refiero a diseño OO, no diseño de interfaces).
Aquel trabajo, que transcurrió en la que es hoy una de las mayores empresas de tecnología de España, básicamente se basaba en hacer diagramas UML muy cercanos a la codificación. Dicho sea de paso, diagramas que nos pedían altamente detallados (atributos, cardinalidades, tipos de datos, etc.).
Ojo a la foto real que hize ayer a los apuntes
de “ingeniería de la programación” – “ingeniería del software”
Diagramas UML de aquellos que pocas veces que acaban implementando exactamente como se dibujaban, y que cumplían perfectamente con el síndrome aquel de que el software no sigue un proceso de construcción industrial, secuencial, y que la mayoría de las veces debiera ser construido iterativamente. Supongo que de aquello viene mi reiterada insistencia en repetir constantemente que fabricar software no es lo mismo que fabricar coches o construir casas, pero esta es otra historia.
Volviendo al tema, lo importante de aquí de todo aquello es que, por unas u otras, acabamos cogiéndole manía al Rational Rose, la herramienta UML que usábamos, y empezamos a buscar alguna alternativa.
Por aquellos tiempos estaba de moda otra herramienta UML, hoy casi olvidada, llamada Together. Yo supongo que la fama de Together venía de haber inventado un novedoso método de sincronización código – diagrama UML, llamado “round trip”, que actualizaba los diagramas UML cuando se cambiaba el código.
Pero para mí, lo realmente valioso de Together era que en un menú casi escondido la herramienta traía un módulo de métricas, algo que “enchufado” a los fuentes te devolvía un montón de métricas y números: que si métodos muy largos, demasiados parámetros, complejidad ciclomática, complejidad de expresiones booleanas, bloques «catch» vacíos, return en bloques finally, cierres de las conexiones de bd, dependencias cíclicas entre paquetes, copy paste, etc.
Primero comencé a jugar por curiosidad con aquellos números. Al principio eran bastante poco inteligibles para mi, ya que apenas me habían contado algunos de ellos en la carrera y además en plan teórico. Pero después, poco a poco, fui viéndoles sentido, viendo como los fuentes que más problemas daban en desarrollo eran siempre los que peores métricas tenían.
Si no me falla la memoria, por aquellos tiempos cayó en mis manos el libro de refactoring de Fowler. Simplificadamente, el libro hablaba de cómo “limpiar” código, y qué código limpiar (los bad smells). Y muchas de aquellas métricas del Together coincidían, e indicaban y señalaban donde estaba el código no limpio.
En las siguientes empresas en las que trabajé, además de mis tareas en desarrollo, añadía las de chequear lo mas automatizádamente posible el código. Al principio con Together, y después con “plugins” como PMD, CheckStyle, Simian, etc. Estos últimos, a diferencia de Togehter, permitían poder ser ejecutados en batch, lo que facilitaba enormemente el trabajo, ya que podíamos lanzar las métricas sin interacción humana directa, algo que ahora se ve muy normal por la moda de la integración continua, peor que antes no lo era tanto.
Durante aaños incorporé tareas de evaluación de la calidad del software con métricas. En algunos sitios con más éxito, y en otros con menos.
Con el tiempo y la experiencia me fui dando cuenta de varias cosas. Una, que los malos valores en métricas de calidad software se repetían demasiado y en demasiado software. Otra, que para el impacto que estos valores tenían en la mantenibilidad, es decir, el coste que suponían… apenas nadie les prestaba atención y apenas nadie las entendía. Cosas que, por cierto, a día de hoy, ha mejorado, pero aún le queda camino.
Con la experiencia previa, una de las medidas que intenté para resolver el problema de la adopción de métricas de calidad fue crear cuadros resumen, abstracciones, semaforos, colores, que frente a tanto número, y sobre todo para los perfiles de gerencia, mostrase resumidamente la calidad software. Lo que algunos llaman cuadro de mando.
Pero la cosa no era tan fácil, nada, ni estaba este tema tan maduro como lo está ahora, pero os comento cómo lo resolví…
To be continued… aquí el enlace a la segunda parte de este post.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Estoy cursando esa asignatura, la última que me queda, (y si, junto a solo tres personas mas) y durante todo el semestre nos han enseñado a usar RUP, nada de métricas, solo diagramas, un día, después de leer en tu blog que era una metodología anticuada, le comente al profesor que por qué en concreto nos habíamos centrado en esta metodología, y me contesto que por que todas las demás se parecen mucho y al saber utilizar RUP, sabríamos utilizarlas todas. (yo creo que la respuesta es porque la herramienta «visual paradigm» es gratis para la docencia…)
¿Qué opinas al respecto?
Hola Clara,
En mi opinión tu profe tiene razón. RUP es difícil de aplicar y de entender y UML es algo complejo, pero si consigues dominarlos, las demás metodologías son más sencillas y siempre tienen algo de los principios «RUP». Es más, en el mundo real, RUP se sigue aplicando(o alguna metodología prima suya, tipo METRICA V3), especialmente en proyectos grandes, eso sí, con un enfoque menos dogmático y mucho más ligero…RUP no es tan «RUPestre» je,je
Ays el together, yo también lo usé, que buenos recuerdos. Me reventaba el usar el Rational Rose, pasar a codificar y darte cuenta que tenias que hacer algún cambio y que no permitiese actualizar el diagrama.
Y luego el tema de la auditoria de código, yo también lo descubrí con el together, luego me pasé al PMD y Checkstyle, que eran gratis.
Coincido contigo en que hace un tiempo esas preocupaciones por la calidad del código eras vistas como algo raro. Recuerdo un compañero de trabajo que me dijo una vez, que porque me preocupaba tanto por el código, si no lo mira nadie…
En fin, nos quejamos de lo prostituido que está este sector, pero somos un poco todos los que colaboramos a ello.
Apuesto a que lo resolviste con Excel….
Hum…, pruebas funcionales como subcategoría de las de integración… curious…
Casi me vuelvo loco buscando donde puse pruebas funcionales como subcategoría de las de integración, pero ya he visto que no fui yo 😛 está en la foto de los apuntes. Es que eran otros tiempos aquellos..
Al excel no hay nada que se le resista, y si lo hubiese, para eso está el powerpoint
ja,ja, …Integración Funcional…o Funcionalidad Integradora…total que más da, si nuestra profesión no esta ni regulada (ni se le espera)…y somo cuatro morning-singers los que nos fijamos en estas chorradas…