1 - Calidad del producto software no es lo mismo que testing
Que el software “funcione” (lo que normalmente intentas saber con el testing) no significa que por ello… ¡el producto este bien hecho! Y si está mal hecho no te vas a dar cuenta si no lo miras por dentro (miras sus fuentes, código, diseño, cómo de mal o bien está programado, si está muy acoplado, etc.), es decir, si no miras lo que se llama calidad del producto software.
2 - La calidad del proceso no garantiza la calidad del producto
En el desarrollo software, de entre las diferentes perspectivas con que se puede observar la calidad, hay dos especial y tradicionalmente importantes: la calidad del producto en sí y la calidad del proceso para obtenerlo (o actividades, tareas, etc., para desarrollar y mantener software). Dos dimensiones esenciales, estudiadas desde hace tiempo por los grandes “padres” de los modelos y teorías de calidad en general y también aplicables a la construcción de software, y que giran e interactúan en torno a la idea de que, como comenta Humphrey, “padre” del modelo CMMI, “la calidad del producto está determinada por la calidad del proceso usado para desarrollarlo”.
Aunque en el área del desarrollo software, que siempre ha ido un poco más atrás en temas de calidad, y en España, que en los últimos años se ha empezado a tratar en las empresas este tipo de aspectos, la popularidad e importancia a nivel industrial ha recaído casi por completo en los modelos de calidad de procesos, destacando el conocido modelo CMMI, que en los últimos años se ha extendido considerablemente.
Si bien modelos como CMMI han gozado de mucha popularidad, no por ello los modelos o estándares de calidad de producto tienen menos madurez, destacando el menos popular pero igualmente importante ISO 9126, o la nueva serie ISO 25000, que especifica diferentes dimensiones de la calidad de producto.
En nuestra experiencia nos hemos encontrado bastante frustración en ciertas empresas debido a las esperanzas depositadas en los modelos de calidad de procesos que ofrecían sus proveedores y que finalmente no han servido como garantía de calidad de los productos que recibían.
Tener un “sello” de CMMI no siempre asegura un producto software de calidad. Así es. El “sello” es una evidencia “indirecta” de calidad, la calidad del producto software es evidencia “directa”.
3 - La mala calidad del producto siempre tiene un coste
Porque la mala calidad del producto software (es decir, código espagueti, código repetido, diseño acoplado, etc.) siempre, siempre, alguien la paga (euros), tiene un coste (lo que llamamos deuda técnica). Y solo pueden pagarla uno de dos: el cliente o la empresa que desarrolló el software.
4 - El cliente puede detectar la mala calidad del producto software
Si el cliente detecta mala calidad del producto software será el proveedor quien acabe pagando el trabajo mal hecho, aunque lo normal es que el cliente no se dé cuenta del mal desarrollo software por el que acaba de pagar y acabe pagando él mismo la mala calidad del desarrollador… que normalmente la paga en sobre exceso de horas y horas de mantenimiento.
5 - Las buenas prácticas no aseguran calidad del producto
Las buenas prácticas de ITIL, ISO 20000, son muy buenas para detectar que los usuarios están teniendo problemas con en el software, las incidencias que los usuarios tienen con él, para organizar los pasos a producción de los parches, controlar cuantas veces “se ha caído” el software en producción, su disponibilidad, etc. Pero por muchos y muy buenos indicadores que tenga “tu coche” sobre si se está “calentando el motor”, “el aceite que queda”, etc., los problemas se reparan en “el motor” (el desarrollo software) no poniendo indicadores del nivel de servicio. Y el motor se arregla trabajando la calidad del producto software.
Comentarios
Publicar un comentario