Calidad III : La Relatividad del concepto

En los comentarios del post sobre la Calidad del Desarrollo de Software II tanto Walter Risi comoErnesto Kiszkurno aportaron un par definiciones distintas y muy interesantes de la calidad de software.

El concepto de la calidad de Software, en general, es decir Que hace que un software sea de calidad es uno de los temas que más discusión ha causado dentro de la comunidad de sistemas desde hace décadas.

En los 2 posts anteriores sobre Calidad del desarrollo hemos evitado justamente este tema ateniéndonos nada mas (pero nada menos) que al concepto, bastante más concreto, de que es lo que hace que un desarrollo sea de calidad. Es decir, para usar la metafora-que-odio-de-la-fabricación, que calidad tiene su construcción, su Calidad Interna.

Pero para no esquivar el bulto al problema más general, podemos plantearnos entonces , Que determina que un software sea de calidad?

El Juego

Uno de los sistemas que más utilizamos en nuestra época de estudiantes en Exactas (UBA) fue un juego (como no podía ser de otra manera) de estrategia en tiempo real llamado Dune II. Fue un juego que nos apasionó y en el cual podíamos pasarnos horas jugando hasta terminar las misiones. No obstante ese juego tenia un par de bugs molestos, uno de ellos con la Inteligencia Artificial de la maquina que justamente en determinadas situaciones no respondía bien en la defensa y el otro con el manejo del gusano de arena que ha veces se tildaba y quedaba ciclando en algún loop escondido.

Si nos hubieran preguntado allá en el tiempo pero incluso ahora que opinabamos de la Calidad de ese desarrollo, creo no exagerar en decir que era Sobresaliente, excepcional.

Hubiera agregado algo si la empresa dueña del juego arreglaba esos bugs? Probablemente hubiera sido lindo, quizás un poquito mas interesante pero....eso no hubiera cambiado la percepción de la Calidad del producto que teníamos, era sencillamente de Calidad.

Entonces, que es lo que determina que un producto de software sea de Calidad....y bueno... si no queda otra, ensayemos algunas respuestas habituales:

1) que sea utilizado por mucha gente?

Windows es el caso arquetípico de software utilizado por mucha gente que no obstante....digamos que jamás ha sido famoso por su Calidad (piensen sino en el caso cercano del Vista y ni que hablar de otros...ejem fallidos como ....alguien se acuerda del Milleniun?)

El software de Mac en general tiene asociado una fama de mucha mayor Calidad y es utilizado por muchisima menos gente.

2) que sea fácilmente usable?

El problema para determinar aquí que tal sistema es de Calidad por su usabilidad, más allá de los recientes libros y normas sobre usabilidad de Diseñadores gráficos, es que los usuarios tienden a encariñarse poderosamente con la interfaz de usuario que conocen. Siempre prefieren lo conocido por sobre lo novedoso.

Piensen sino en lo que diría un usuario de WordStar o WordPerfect si tuviera que usar el Word actual o, viceversa, si un usuario de Word tuviera que usar el Wordstar y para ambos la usabilidad de la herramienta que usan/usaban era formidable. Ni que hablar de la pelea entre los amantes de Vi versus Emacs versus editores de linea tradicionales.

Para los amantes de linux cualquier linux es totalmente fácil de usar pero si le damos una consola de comandos a una persona que siempre uso Windows...bueno...inmaginense su juicio.

3) que Tenga cero defectos?

Permitan me una sonrisa irónica, Jeje, no se conocen casos de software que se alegue que sean de Calidad por no tener Defectos sencillamente porque todavía no ha habido un software que no tenga defectos.

4) Que tenga muchísima funcionalidad y features?

Más allá de los casos conocidos como los productos de Office y para que vean que no la tenemos en contra de Microsoft ambos autores de este blog hemos utilizado un par de productos de GIS (Sistemas de Información Geográfica) de una empresa anglosajona que se podrían definir como el paraíso de la acumulación de funcionalidad y features. Uno de ellos se focalizaba en plotear mapas, el otro para hacer carga, procesamiento y consultas en sistemas de información Geográfica.

Cada uno de los productos tenia cientos de features y comandos, muchas veces con funcionalidad superpuesta que creaban una especie de frankestein gordo y pesado, un mamotreto de distintas funcionalidades mezcladas adonde nada se hacia realmente bien o perfomante porque todo era una solución de compromiso para poder hacer muchas cosas que casi nunca se necesitaban.

5) que Sea de bajo Costo y termine dentro de la planificación?

Seguramente son requisitos para el Gerente de un proyecto, el de Marketing o Ventas e incluso los interesados o StakeHolders pero...y los usuarios?

6) Que tenga buena calidad de desarrollo?

Esto justamente es lo que hablamos en el post anterior, y así como creemos profundamente que es un requisito indispensable por el mismo motivo que un edificio sin buenos cimientos se derrumbará, no es suficiente para que todo el producto, el sistema sea de Calidad. Es decir, podemos tener un sistema de una calidad de desarrollo excepcional pero que no sea útil para el o los usuarios en cuestión.

La raíz del problema

Justamente el problema que tiene cada una de las definiciones que intentamos y que han sido intentadas alguna vez, es que la CALIDAD es un término relativo. La calidad que es adecuada para una persona o tipo de persona puede ser totalmente inadecuada para otra.

Jerry Weinberg en su libro "Quality Software Management: System Thinking" habla justamente sobre este tema, y en particular como este concepto de "relatividad" se esconde incluso en

algunas de las definiciones más famosas de Calidad de Software.

Por ejemplo la de Crosby: "Calidad es el cumplimiento y satisfacción de los requerimientos", es decir que un sistema es de calidad si cumple con sus requerimientos.

El tema, o kid de la cuestión y que deberíamos preguntarnos es:

"Requerimientos de Quien o para Quien?", entonces, para ser más precisos deberíamos decir:

"Calidad es el cumplimiento y la satisfacción de los requerimientos de algunas personas"

Para cada persona el mismo producto tendrá distintas "calidades" y de hecho entonces cada sentencia que alguna vez se ha hecho o se hará acerca de la calidad del un sistema es una sentencia acerca de lo que consideran que es la calidad un determinado conjunto de personas.

Por ello, la próxima vez que estés desarrollando software, siempre, siempre preguntate:

"Quien o quienes son las personas detrás del concepto de calidad que están pidiendo para este sistema en particular"

Calidad del desarrollo II - Breve Historia

La definición de Qué es la calidad del desarrollo de software ha ido cambiando, como la moda en ropa y peinados, a lo largo del cortísimo tiempo (si lo medimos en eras geológicas) desde que en este planeta comenzamos a escribir programas para indicarle a ese merengue de transistores (antes) y circuitos (después), llamado Computadora u ordenador, como realizar una determinada tarea llamada cómputo.

Ha ido variando, deciamos, un poco como la moda, en tren de determinada corriente, modificada por los distintos paradigmas de programación, y metodologías en boga en cada momento.

70's - Programación Estructurada

Primero tenemos la definición típica de la Programación Estructura, si bien tuvo posteriormente un "aggiornamiento" durante los 80's con la aparición de la Programación Orientada a Objetos. La misma dice que un sistema tiene una buena calidad de software si todos sus módulos tienen una Alta Cohesión funcional y un bajo acoplamiento. Con la aparición de la POO lo que se hizo fue redefinir como interpretar lo de cohesión y acoplamiento no ya en módulos sino en clases de Objetos.

80's - 90' - Las leyes y patterns de POO

Desde la aparición de la POO en el Mainstream (es decir, como paradigma de desarrollo aceptado masivamente) a lo largo de los 80 y 90's se redifinió como obtener una buena calidad de desarrollo a través de un conjunto de leyes, principios y patrones de diseño que especifican que un diseño de un sistema programado con objetos es bueno (la calidad por lo tanto es "alta") si cumplen con estas leyes, principios y utiliza, cuando se debe, estos patrones. Ya hemos hablado aqui de algunas de estas leyes y principios en la-ley-de-demetrio-y-otras-yerbas-oo y en ejemplos-de-la-ley-de-demeter.

2000's - Visión desde TDD Con la aparición de las metodologías ágiles en general y en particular con la práctica de TDD surge una definición muy interesante de que debe cumplir un código para tener buena calidad, a partir de los tests de unidad:

Un sistema tiene buena calidad de desarrollo si el código de todo el sistema (sean Clases o módulo) es el el más simple posible que ofrezca la solución al problema determinado. Y, cuando un código es el más simple posible? Cuando

1. Corre todos los tests de unidad correctamente.
2. Expresa cada "idea" del modelo que se necesita expresar (para resolver el problema).
3. El código modela cada "idea" una y sola una vez.
4. Tiene el mínimo número de clases y métodos para lograr los puntos anteriores.

Más allá del 2000 y pico - Dos Calidades

En los últimos años, junto en parte a la explosión de aplicaciones web, tanto Kent Beck como Martin Fowler vienen marcando un punto válido (y bastante obvio si uno se para ha pensar) de porque es tan difícil para un equipo de desarrollo hacer entender que la Calidad del desarrollo importa y es fundamental.

Lo que dicen es que los usuarios no entienden la importancia de la Calidad del desarrollo porque hay 2 dimensiones de la calidad, digamos 2 calidades distintas.

La Calidad Interna: Es la calidad del desarrollo propiamente dicha, el como esta construido por dentro, si cumple con la cohesión-acoplamiento, con las leyes de objetos y con la definición de TDD y buena refactorización de código. Es como la conocemos nosotros, la gente de sistemas.

El problema es que esta calidad no es directamente perceptible por los usuarios. Solo ven los efectos. Y por lo tanto, a priori, no les importa.

La calidad Externa: Es la calidad del sistema que puede ser percibida directamente por el usuario. Es cuan agradable y efectivo es el uso del sistema para el usuario, cuan buena es la usabilidad de su interfaz de usuario, de sus reportes, cuan rápido y perfomante responde el sistema ante su uso.

Este concepto bastante obvio, siempre ha existido, desde que los sistemas tuvieron usuarios, pero es interesante notarlo porque ha veces lo hemos pasado por alto o lo olvidamos.

Así, para esta concepción mas completa la calidad de un desarrollo de software es alta si tiene tanto calidad interna como externa.

Calidad Negociable

El punto más interesante aquí, como explica Martin Fowler en este articulo aqui es que la calidad externa de un sistema es algo negociable por tiempo y costo mientras que la calidad interna no.

"Deseas agregar una grilla que muestre a los clientes con fotos, con efecto esfumado y que roten 3D? Perfecto pero eso lleva más tiempo y dinero, si el usuario lo acepta no hay problemas pero mientras tanto, la grilla 2D que tenés (sin fotos) te sirve para comenzar a utilizar el sistema? Fantastico".

No tomen prisioneros

La calidad interna por otro lado no es negociable porque nosotros como programadores tenemos la responsabilidad profesional de preparar el sistema para ser mantenible a lo largo del tiempo y modificable (a los cambios de alcance). De la misma manera si vamos a la metáfora del arquitecto sería lógico que el usuario nos plantee que la construcción que estamos haciendo para que vaya a vivir le demos prioridad a las habitaciones y cocina antes que a la pileta de natación. Pero por otro lado si quieren que vayamos más rápido y eliminemos columnas o cambiemos el material de los cimientos nos negaríamos rotundamente, porque somos profesionales responsables y eso no es sustentable en el tiempo. No es, para cerrar el circulo, mantenible.

Costante universal

Intuitivamente todas sabemos que es la calidad de desarrollo de software y desde este blog hemos machacado una y otra vez con el concepto de que es fundamental toda vez que una buena calidad de desarrollo de sofware permite la màs importantes de las "ilidades" como es la Mantenibilidad, fundamental porque es la actividad que uno mas realiza sobre un sistema. A la vez una buena calidad ayuda tambien a la reusabilidad .

Por último es importante como vimos en el post anterior porque ayuda a aceptar cambios de alcance y de definición del usuario (que como ya explicamos son ineludibles) y permite incorporarlos al sistema de una manera menos costosa y con mucha menos perdida de tiempo que con un sistema de calidad baja.

Por ello, para terminar, como diría Stephen Hawking, la Calidad del desarrollo de software mas que una de las 4 variables del desarrollo debería ser una Constante Universal.