Hemos visto la semana pasada los diferentes niveles de madurez en la calidad del software y como la medición de la deuda técnica nos ayuda a progresar a través de estos diferentes niveles, para una gestión proactiva e optimizada de la calidad de las aplicaciones.

En esta ocasión, hablé de utilizar la deuda técnica en la presentación de un portafolio de aplicaciones. Entonces me pregunté como sería una representación 3D de una cartera de este tipo, con el plugin ‘3D City Model’ de eXcentia (1).

Ya lo he presentado en unos artículos anteriores: City Model, City Model – Nueva versión, Ciudad crítica, donde vimos cómo crear nuestras propias fórmulas para jugar con el modelo 3D, y finalmente La métrica ABC para investigar la métrica del mismo nombre. Sigue leyendo →

Creo que todos vosotros conocéis CMMI. Este modelo desarrollado por el Software Engineering Institute ofrece cinco niveles de madurez con el fin de medir la calidad de los servicios de TI y mejores prácticas asociadas con esta escala de niveles.

No voy a escribir un post entero sobre este modelo, ya que no es el objetivo de este artículo, sino que simplemente lo presentaré como yo pudiera resumirlo a alguien que no sabe nada acerca de la gestión de proyectos y del desarrollo de aplicaciones. Sigue leyendo →

Nos preguntemos en el post anterior, ¿por qué los desarrolladores generalmente no tienen conocimiento de los Puntos de Función? Y si esta medida podría serlos útil.

Nuestra respuesta es más bien negativa, sobre todo si tenemos en cuenta que tal estimación se realiza manualmente por consultores y con un proceso a veces bastante complejo. Hay muchas certificaciones cuyo objetivo es validar que un consultor domina estos conceptos y sepa ponerlos en práctica de manera operacional. Sigue leyendo →

El título de este post parafrasea el título de una novela de ciencia ficción que tal vez conoces: « ¿Sueñan los androides con ovejas eléctricas? ».

Esta novela de Philip K. Dick ha sido la base para la película « Blade Runner » de Ridley Scott, en la que un detective del futuro debe encontrar y neutralizar a unos androides que nada puede diferenciar de los humanos. Sigue leyendo →

Hemos visto en el post anterior cómo iniciar una reingeniería con SonarQube empezando con una redistribución funcional y un nuevo diseño de nuestra aplicación.

Ahora podemos ir un poco más profundo en el código para identificar a los flujos de tratamientos candidatos para la reestructuración. Sigue leyendo →

Hemos definido nuestro proyecto de reingeniería como la reescritura de nuestra aplicación Legacy con un nuevo lenguaje o su migración a una nueva tecnología, a diferencia de una refactorización que implica la reorganización del código y la corrección de ciertos defectos con el fin de hacerlo más mantenible y reducir la deuda técnica.

También vimos, con SonarQube y el plugin SQALE diferentes planes de refactorización más o menos ambiciosos, desde la resolución de los defectos más críticos hasta reducir la deuda técnica para llevarla a un nivel (rating SQALE) ‘A’.

Sin embargo, ¿qué es lo más interesante y productivo entre un proyecto de reingeniería y una refactorización? Sigue leyendo →

Una reingeniería no siempre significa la reescritura de nuestra aplicación Legacy en un lenguaje generalmente más reciente, pero, sin embargo, es la opción que hemos elegidos.

Cuando se trata ‘simplemente’ de reorganizar el código para que sea más fácil de mantener, pero sin portarlo en una nueva plataforma de software o de hardware – migración de Mainframe-Cobol a una arquitectura Unix por ejemplo – yo prefiero hablar de refactorización.

Os recuerdo que este blog no tiene pretensiones académicas, así que no voy a preocuparme de definiciones meticulosamente exactas, que conducen con mayor frecuencia en discusiones quadripelotectomias (1) entre especialistas que no tienen nada más que hacer que glosar sobre cada palabra. Sigue leyendo →

Cuando se trata de retorno de inversión (ROI), no me complico la vida: mi hipótesis es que los costes de mantenimiento se reducen en una proporción igual a la reducción de la deuda técnica.

Es una hipótesis que puedes encontrar simplista y por lo tanto discutible, pero nuestra ambición no es de conseguir una precisión absoluta – sería pretencioso y poco realista – pero proporcionar los elementos que facilitan la decisión.
Y creo que el management prefiere una hipótesis simple y clara en lugar de una fórmula compleja que no es necesariamente más realista.
Sigue leyendo →

Como le hemos visto en el post anterior, no he personalizado el Quality Profile de SonarQube ni el modelo SQALE, para nuestra aplicación Legacy,  según nuestro contexto y  la orientación que queremos para la evaluación du su deuda técnica.

De hecho, hemos utilizado los resultados ‘out of the box’ para ilustrar un posible enfoque en la valoración del coste de refactorización, y presentar al equipo del proyecto y a los managers algunas ideas y áreas de mejora.

En otras palabras, nos interesa más el proceso que los resultados, por lo menos en el contexto de estos artículos.

Veamos ahora unas propuestas de plan de acción. Sigue leyendo →

Para hacer una estimación del coste de refactorización de nuestra aplicación Legacy, voy a utilizar el plugin SQALE de SonarQube, utilizado más a menudo con el fin de medir la deuda técnica.

Ya hemos presentado este plugin con una aplicación Legacy PL/SQL. Así que recordaremos solamente que el plugin SQALE se basa en el modelo de calidad SQALE, y también en un método para adaptar este modelo según diversos objetivos de negocio, la tecnología utilizada o el contexto de la aplicación. Sigue leyendo →