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
- Corre todos los tests de unidad correctamente.
- Expresa cada "idea" del modelo que se necesita expresar (para resolver el problema).
- El código modela cada "idea" una y sola una vez.
- 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
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 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.
Estimado Juan Pablo,
ResponderEliminarAnte 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
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!.
ResponderEliminarRespecto 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
Buenas Juan Pablo, Lorenzo, Walter ....
ResponderEliminarA 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..
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.
ResponderEliminarSaludos y gracias por comentar!