Calidad Interna

El tema de la calidad ha llenado páginas y páginas de la literatura informática en todos los idiomas. Es tal la necesidad de la búsqueda de la calidad, que hay estudios, técnicas y departamentos dentro de empresas, e incluso empresas, que se dedican en cuerpo y alma a establecer parámetros de calidad a los productos y proyectos que se realizan en las empresas de desarrollo de software.

Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.

¿Qué es la calidad interna?

Cuando se desarrolla un software, se desarrolla con una calidad medida según sus requisitos que pueden determinar su alto grado de calidad, midiendo una serie de parámetros. Pero estos parámetros no reflejan ni tienen en cuenta la calidad del proceso de creación del software en sí, ni la calidad del software escrito, solo la calidad externa, es decir, la función que realiza el software.

La calidad interna, sin embargo, mide y tiene presente la forma en la que se ha desarrollado el código de modo que pueda mantenerse (corregirse, ampliarse y adaptarse) de forma rápida y sencilla, gracias a un diseño e implementación limpia, simple y clara.

La importancia que tiene este tipo de calidad se muestra de manifiesto en varios textos como Scrum y XP desde las trincheras (de Henrik Kniberg) y algunos blogs como el de José Manuel Beas, Joseba Enjuto, una entrada de Diego Gómez en la web Dos Ideas, o incluso en el propio estándar ISO/IEC 9126.

¿Por qué es tan importante?

Para un desarrollador, la calidad interna es tan o más importante que la calidad externa, puesto que si un software hace lo que debe, pero una de cada 1000 veces no funciona, puede deberse a un fallo interno difícil de detectar que, pueda incluso verse agravado por la mala calidad con la que se ha desarrollado (diseñado o implementado) el sistema en sí.

En base a tiempo, un software desarrollado con una calidad baja o nula, puede ser desarrollado en un tiempo muy pequeño, ya que no se tiene en consideración muchos aspectos necesarios y útiles, como por ejemplo, una buena orientación a objetos, modularización del código, reutilización, algoritmos excesivamente complejos u ofuscados, etc.

Cuando, por un fallo (mantenimiento correctivo) hay que volver al código para corregir un defecto, y se detecta un error de diseño, modificar un código mal oliente, es más complicado que corregir un defecto en un código que está mejor desarrollado en base a patrones y reglas básicas de análisis, diseño o codificación.

En otras palabras: un programa con calidad interna baja es un programa que generará deuda técnica.