viernes, 18 de marzo de 2011

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.

4 comentarios:

  1. Estimado Juan Pablo,

    Ante todo, creo que este blog que escriben con Lorenzo (viejo compañero de trabajo) es muy interesante ... máxime cuando ya tienen unos cuántos meses de vida!

    Me resulta interesante el tema de las diferentes visiones de la calidad, y te invito a volver a una de las definiciones más clásicas, la del mismo Joseph Juran, padre de la gestión de la calidad. Juran hablaba de calidad como "fitness for use", es decir, algo como "adecuación al uso". Es decir, algo tiene calidad si es adecuado para el uso que se le va a dar. Esta definición contrastaba con otras definiciones de calidad que tenían que ver con "compliance" con la especificación. Si especifico un producto que al usuario final no le sirve, y el producto que construyo cumple 100% la especificación, sigue siendo malo según la definición de Juran. También, un producto espectacular que se entrega lejos de la fecha en la cual lo necesitaba su usuario ... es malo, siempre según esta definición.

    Ahora, a diferencia de un clavo, una cafetera o incluso un auto, un producto de software normalmente "muta" a lo largo del tiempo, y eso es parte de su "uso". Parte del "uso" del producto de software es el adaptarse a cambios ya sea derivados de cambios en el negocio, en la infraestructura subyacente, etc.

    Supongamos que construimos un producto que es espectacular para el momento "0" del release, pero a los pocos meses empiezan los cambios y el producto es inmantenible, inmodificable, inadaptable... ¿podemos decir que es "adecuado al uso"? En mi opinión, no. Las "ilities" terminan impactando en el usuario final, incluso aquellas visibles en "tiempo de desarrollo".

    Entonces, cuando aplicamos esta definición tan simple, la calidad "interna y externa" empiezan a ser igualmente importantes y en el mediano plazo visibles para el usuario !

    En fin, un aporte de mi parte.

    Espero que sigan con este blog!

    Saludos,
    Walter.
    www.walterarielrisi.com

    ResponderEliminar
  2. Hola Walter!! gracias por el comentario y por las amables palabras. Como decís ya llevamos unos meses, es más, si no me equivoco está por cumplir un año!.

    Respecto al tema, estoy de acuerdo contigo, y me gusta la definición de Juran (la verdad es que la conocía pero no sabia que era de el).

    Justamente el gran cambio de visión que se produjo en nuestra industria (o metier;) desde la aparición de ágil para acá es el foco en satisfacer las necesidades del usuario y este "adaptarse al cambio". Y es así, podemos cumplir con el tiempo, con el costo, incluso con la calidad pero si no le sirve al usuario no habremos hecho mas que ...basura que va a ser usada muy poco o nunca.

    Gracias de nuevo, saludos!

    Juan Pablo

    ResponderEliminar
  3. Buenas Juan Pablo, Lorenzo, Walter ....

    A mi me gusta una definición de calidad que, aparentemente, le pertenece a Aristoteles que dice que "la calidad es un hábito".

    La idea detrás de esto es que en todo momento estamos detrás de un software de calidad.

    Me gustó el post y me gustó MUCHO el tema.

    Saludos y espero que sigan escribiendo..

    ResponderEliminar
  4. Hola!! que tal Ernesto!, Es verdad lo que comentas, si no es incorporado como un habito la calidad se deja de lado ante la menor presión o problema.

    Saludos y gracias por comentar!

    ResponderEliminar