Sobre la calidad del software. Qué es y cómo se define

Llevo las últimas semanas enfrascado en entender de forma más profunda en qué consiste eso que llamamos calidad. Y más concretamente en qué consiste la calidad del software y cómo podemos aumentar la calidad de un proyecto software.

Éste es el primero de una serie de posts que he decidido empezar a escribir y dice así:

TL;DR

La calidad se define como el cumplimiento con los requisitos de forma repetida y con la mínima desviación sobre el óptimo

El desarrollo de software se realiza dentro de un contexto volátil, incierto, complejo y ambiguo (VUCA),s en el que intervienen muchos roles diferentes y cada uno de ellos tiene unas especificaciones diferentes para el software.

Las métricas de calidad son únicas para cada proyecto ya que cada proyecto y el conjunto de personas que intervienen en él son únicos.

Podemos agrupar (arbitrariamente) diferentes aspectos de la calidad del software para poder definir un marco de trabajo. Los míos son:

• Calidad funcional
• Calidad estructural
• Calidad de proceso
• Calidad regulatoria

Estos aspectos están relacionados unos con otros y no pueden modificarse unos sin modificar el resto

Calidad como cumplimiento de los requisitos. Calidad NO es sinónimo de mejor

Un producto o servicio de calidad es “aquel que cumple con los requisitos especificados”. De hecho, si vamos un poco más allá, y tal y como se explica en este vídeo, ni siquiera se trata de cumplir con los requisitos especificados, sino de hacerlo con la mínima desviación posible sobre el óptimo. Y añado yo… “y de forma repetida”.

Y es en este concepto de óptimo donde radica la diferencia fundamental entre calidad y “mejor”. Aunque coloquialmente tratemos indistintamente ambos conceptos es importante tener en cuenta el matiz que los separa.

Supongamos un servicio de software que:

• No sufre nunca caídas
• Se actualiza solo
• Escala automáticamente

¿Es mejor que otro que no tiene ninguna de estas características? Definitivamente sí. De la misma forma que un solomillo de Kobe es mejor que un filete de añojo.

Ahora pensemos que este servicio es un NAS para mi casa que vamos a utilizar tan solo mi familia y yo.

¿Es óptimo este servicio? Definitivamente no, de la misma manera que un solomillo de Kobe no es óptimo para hacer albóndigas para un menú del día.

En estos casos concretos esto se debe a una desviación de los requisitos de calidad de proceso por el incremento de coste que conllevan ambos casos… aunque me estoy adelantando. Antes de adentrarnos en esto necesitamos hablar de…

¿En qué consiste el desarrollo de software?

Podemos resumir el desarrollo de software en un proceso parecido al que sigue

1. Un grupo de personas (los llamaremos usuarios) tienen un problema que quieren resolver
2. Un grupo de personas (los llamaremos patrocinadores) se dan cuenta de ello y creen que puede ser una oportunidad resolver dicho problema
3. Estos patrocinadores consiguen financiación (ya sea con sus ahorros, a través de amigos, a través de su empresa o de inversores externos) para poder montar un equipo que se encargue de construir un producto o servicio que resuelva el problema a los usuarios
4. Un grupo de personas (lo llamaremos equipo de producto) construyen la solución para los usuarios a cambio de una contrapartida. Seguramente un sueldo, aunque hay casos en los que también se puede hacer por amor al arte, al prójimo o por mejorar la marca personal (ahí tenemos el software libre, por ejemplo)

Sencillo, ¿verdad?

NO.

No es sencillo porque cuando nos adentramos en los detalles nos damos cuenta de que siempre ocurre lo siguiente:

• El problema que tienen los usuarios nunca está claro de primeras. En serio. NUNCA. Si crees que sabes lo que quieren los usuarios, cuanto antes asumas que estás en un error, mejor que mejor. ¡Si la mayoría de las veces ni siquiera sabemos lo que queremos nosotros mismos!

• El contexto en el que nos movemos es un contexto VUCA: Volátil, incierto, complejo y ambiguo, por lo que la solución que demos hoy, mañana puede dejar de ser válida (por cambios legales, nuevos competidores en escena, nueva tecnolgía que deja obsoleta la nuestra…){: .external-link target=”_blank”}

Es decir, no sólo no sabemos lo que quieren los usuarios, sino que además el contexto hace de todo menos ayudar a averiguarlo. Casi nada. En esta situación, por lo tanto, el éxito no consiste en construir un producto que le solucione un problema a alguien hoy, sino en hacerlo a medida que nos adaptamos a unas condiciones extremadamente cambiantes.

Y para conseguir esto es fundamental:

1. Que las funcionalidades del producto sean las necesarias en cada momento
2. Para ello es necesario aprender rápido. Y no, no he dicho fallar rápido. He dicho aprender, que no es lo mismo. Y para ello necesitamos:
   1. Poder recibir feedback del usuario lo más rápido posible para entender cómo han cambiado sus necesidades
   2. Poder realizar pruebas lo más rápido posible para validar si realmente estamos solucionando un problema
   3. Poder validar lo más rápido posible si esas pruebas / hipótesis han resultado ciertas
3. Y por último, todo el proceso anterior tiene que ser viable: se tienen que pagar sueldos, mientras el proyecto sigue siendo atractivo para los patrocinadores y los usuarios perciben un valor superior al del coste del producto.

Ahora sí, volvamos a los…

Requisitos del software. ¿Quién los define?

Hemos visto que:

• La calidad del software consiste en cumplir con las especificaciones de forma óptima y repetida.
• Los usuarios tienen que poder resolver sus problemas mediante las funcionalidades que aporte el software
• El proceso de desarrollo de software se realiza en un contexto VUCA que requiere un aprendizaje y una adaptación continuas.
• Todo este proceso tiene que ser viable desde el punto de vista económico

Diferentes roles, diferentes especificaciones

Hemos visto también que en un proyecto de software intervienen varios roles diferentes:

• El usuario
• El patrocinador
• El desarrollador de producto

Pero es que dentro de cada rol, seguramente haya diferentes subroles. Por ejemplo:

• Habrá usuarios que utilicen unas funcionalidades u otras (administradores, creadores de contenido, usuarios de pago, usuarios freemium…)
• Habrá patrocinadores con diferentes niveles de implicación y jerarquía: CEOs, Inversores, VCs
• Hay múltiples roles para los desarrolladores de produto: Gestor de proyecto, desarrolladores back, desarrolladores front, diseñadores de UI y UX, QAs, marketing, comunicación, científicos de datos… y así hasta una lista prácticamente interminable

Y si preguntamos a cada uno de estos diferentes roles cuáles son para ellos las especificaciones que tiene que cumplir el software tendremos diferentes respuestas… todas ellas, en su mayoría, fundamentadas y ciertas:

• Un desarrollador dirá que el código tiene que ser testeable
• Un Product Owner dirá que el software tiene que ser fácilmente cambiable
• Un patrocinador dirá que tiene que ser rentable económicamente
• Un usuario dirá que el producto tiene que funcionar
• Un diseñador de UI dirá que tiene que ser intuitivo

Y así hasta crear una lista interminable de especificaciones, lo que nos lleva al…

Teorema de la unicidad de la definición de calidad del software®

Teniendo en cuenta que cada proyecto es único y que el conjunto de personas involucradas en el desarrollo y en el consumo del mismo también lo es, las especificaciones de cada proyecto también lo son y, por lo tanto, la definición de calidad de cada proyecto será también única.

Yo

Vale, me he venido un poco arriba, lo reconozco…

¿Quiere decir esto que no se puede medir la calidad del software? No. Lo que quiere decir esto es que cada proyecto tiene que definir sus propias métricas de calidad y que lo que es válido en un proyecto no lo será en otro.

Sin embargo, aunque las personas y los proyectos sean únicos, el proceso de alto nivel que he descrito más arriba es razonablemente común, por lo que podemos utilizar las diferentes partes de dicho proceso para definir…

Los tres cuatro aspectos de la calidad del software

Nota: Esta agrupación es totalmente arbitraria. De hecho yo me he basado en este vídeo, pero puede haber diferentes agrupaciones. Cada uno debería utilizar la que mejor le funcione y le sirva para poner un poco de orden en todo este caos

Calidad funcional

La calidad funcional englobal los aspectos o requisitos del software orientados a que el producto resuelva el problema que tiene que resolver a sus usuarios. Vaya, que el software haga lo que tiene que hacer. Por ejemplo:

• Cumplir las especificaciones definidas (obvio, no?)
• Minimizar el número de bugs y su impacto… porque no existe el software sin bugs.
• Funcionar con un rendimiento adecuado. ¿Os imagináis un GPS que tardara 15 minutos en recalcular una ruta?
• Facilidad de uso y/o aprendizaje.

Calidad estructural

La calidad estructural engloba los aspectos técnicos del software. Es de este tipo de calidad de software cuando hablamos de:

• Testabilidad del código
• Mantenibilidad del código
• Legibilidad del código
• Eficiencia del código
• Seguridad del código
• Operabilidad del código
• Plasticidad del código
• Simplicidad del código
• Ponga vd. su adjetivo favorito del código

Perdón por alguno de estos palabros pero no encuentro ninguna traducción adecuada para estos conceptos. Aunque podría ser peor: no he dicho ni commitear ni pushear

Calidad de proceso

La calidad de proceso engloba los aspectos relativos a… bueno, pues eso, el proceso . Cuando hablamos de calidad de proceso hablamos de cosas como:

• Cumplir plazos de entrega. Porque sí, amigos: en la vida real hay plazos de entrega y una cosa llamada expectativas, que suele torcer mucho las cosas cuando no se cumplen
• Cumplir con el presupuesto. Porque el mundo real funciona con dinero, y mientras no encontremos otro sistema que lo mejore, tenemos que convivir con ello
• Poder realizar cambios rápidos para poder establecer y validar o refutar hipótesis
• Poder añadir o reemplazar gente involucrada en el proceso con el mínimo coste

Calidad regulatoria

El software tiende a estar cada vez más regulado, y es por eso que tenemos que tener presentes desde el inicio ciertas especificaciones impuestas desde los gobiernos de cada país. Por ejemplo:

• Cumplir con la GPDR si estás operando en Europa
• Cumplir con MIFID II si estás operando en Europa y eres una entidad financiera
• Cumplir con la regulación existente (no me la sé, lo siento) en caso de que almacenes datos médicos

Y todos se relacionan con todos

Cuidado con caer en el error de tratar estos aspectos como grupos aislados, porque cualquier acción que llevemos a cabo para mejorar la calidad de alguno de estos aspectos, puede tener consecuencias en otros.

Por ejemplo:

• Si decidimos mejorar la calidad de proceso, por ejemplo aceptando los valores ágiles, aumentaremos la calidad funcional
• Si decidimos mejorar la calidad estructural, haremos que nuestro software pueda cambiarse de forma más rápida y segura, aumentando por lo tanto la calidad del proceso.
• Si decidimos acortar los tiempos de entrega, estaríamos mejorando un aspecto de la calidad del proceso, pero estaríamos poniendo en riesgo la calidad estructural y la calidad funcional

Y es que… ¿creías que el desarrollo de software era sencillo?

En resumen

La calidad en el software viene dada por las especificaciones de cada uno de los agentes involucrados tanto en la producción como en el consumo del mismo.

Es, por lo tanto, el cumplimiento reiterado y óptimo de dichas especificiaciones lo que nos dice si un software es de calidad o no.

Dichas especificaciones pueden fijarse en diferentes aspectos del software. Unas pueden hacer referencia a aspectos funcionales, otras a aspectos técnicos o estructurales, otras a aspectos del propio proceso…

Dichos aspectos están relacionados unos con otros por lo que, aunque esta agrupación nos sirva para reflexionar sobre ellos, hay que tratarlos como un todo.

To Be Continued…

Y tras esta pequeña introducción, en siguientes artículos iré profundizando sobre este tema:

• Calidad funcional
• Calidad estructural
• Calidad de proceso
• Cómo medir los diferentes aspectos de la calidad
• Qué relación hay entre calidad y fuzzwords como Agile, DevOps o Lean
• Técnicas para asegurar el cumplimiento de la calidad
• etc.