[ez-toc]<\/p>\n
Las conversaciones que hablan de calidad del software<\/strong><\/a> son una fuente inagotable de t\u00e9rminos ambiguos: el desarrollo debe ser correcto, el rendimiento adecuado, la seguridad alta, debe ser usable, mantenible y, en general, la calidad debe ser buena. Es complicado evaluar en base a estos t\u00e9rminos si un software tiene o no una calidad adecuada\u2026<\/p>\n Esta ambig\u00fcedad ha generado hist\u00f3ricamente discusiones sobre la calidad del software<\/strong> que frecuentemente han acabado generando acuerdos a posteriori pero nos estamos moviendo hacia situaciones en las que queremos que la decisi\u00f3n de puesta en producci\u00f3n sea tomada por una m\u00e1quina. Eso pasa, entre otras cosas, por aportar criterios objetivos que puedan ser programados de forma precisa.<\/p>\n Necesitamos establecer, pues:<\/p>\n Vamos a ver cada punto:<\/p>\n Lo que queremos medir suele tener que ver con la b\u00fasqueda del cumplimiento de objetivos: queremos ver si estamos siguiendo adecuadamente los procedimientos de trabajo, si un proyecto va bien, si hay riesgo en el cumplimiento de fechas o en que el software est\u00e9 plagado de errores, si el software que nos han entregado es de buena calidad\u2026<\/p>\n No tiene sentido medir si no sabemos para qu\u00e9 queremos medir, as\u00ed que lo primero que tenemos que tener claro es el \u201cpara qu\u00e9\u201d queremos medir y a partir de ah\u00ed nos vamos al qu\u00e9.<\/em><\/strong><\/p>\n Si hablamos de calidad del software<\/strong><\/a> (calidad de producto), una buena fuente para identificar criterios es la ISO 25000 (la evoluci\u00f3n de la ISO 9126). En esta norma se presenta un modelo de calidad del software<\/strong> para el que se identifica un conjunto de \u201ccaracter\u00edsticas\u201d de calidad: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad, seguridad y compatibilidad. Para cada caracter\u00edstica se definen subcaracter\u00edsticas (disponibilidad, interoperabilidad, reusabilidad, correcci\u00f3n funcional\u2026). Esta puede ser una buena fuente de \u201cqu\u00e9s\u201d. En cualquier caso, es necesario considerar, como indic\u00e1bamos previamente, los objetivos del Negocio y, en ese sentido, la participaci\u00f3n de las \u00e1reas de Negocio es particularmente importante.<\/p>\n \u00bfC\u00f3mo medimos el criterio? Tenemos dos posibilidades: hacerlo de forma subjetiva o de forma objetiva. La opci\u00f3n subjetiva suele estar asociada a la opini\u00f3n del usuario, del responsable t\u00e9cnico\u2026 suele basarse en encuestas y, siendo importante, es dif\u00edcil integrarla en un escenario proactivo en tiempo real: necesitamos frecuentemente informaci\u00f3n antes de la puesta en producci\u00f3n y, si nos limitamos a la opci\u00f3n subjetiva, tendremos la limitaci\u00f3n del momento. As\u00ed, por ejemplo, el usuario va a poder dar su calificaci\u00f3n una vez haya usado la aplicaci\u00f3n en producci\u00f3n real. Lo mismo pasa con los departamentos responsables de la explotaci\u00f3n.<\/p>\n As\u00ed pues, ya sea en exclusiva o compartida con la opci\u00f3n subjetiva, es necesario utilizar mediciones objetivas. La fuente m\u00e1s frecuente de informaci\u00f3n para la medici\u00f3n de la calidad del producto son los resultados de las pruebas (est\u00e1ticas o din\u00e1micas) y, concretamente, los defectos localizados durante dichas pruebas.<\/p>\n No basta, sin embargo, con contabilizar los errores detectados. Debemos considerar factores de ponderaci\u00f3n: \u00bfcu\u00e1ntas pruebas hemos hecho? \u00bfqu\u00e9 tan grande es el c\u00f3digo? \u00bfqu\u00e9 tan complejo?… La combinaci\u00f3n de defectos y factor de ponderaci\u00f3n junto con un filtro que nos permita centrarnos en la caracter\u00edstica o subcaracter\u00edstica cuya calidad queremos controlar es lo que nos va a dar la f\u00f3rmula que nos permitir\u00e1 calcular el indicador.<\/p>\n Otra posible fuente a la hora de medir la calidad del software<\/strong> es ver hasta qu\u00e9 punto el trabajo realizado es suficiente: \u00bfCu\u00e1ntos comentarios hemos generado en nuestro c\u00f3digo?<\/p>\n Parece sencillo, pero no lo es\u2026. A medida que vamos haciendo \u201czoom\u201d van apareciendo m\u00e1s y m\u00e1s indicadores \u00bfCu\u00e1ntos defectos ha generado una entrega? \u00bfCu\u00e1ntos de esos eran funcionales? \u00bfCu\u00e1les se esos estaban asociados a operativa cr\u00edtica? \u00bfCu\u00e1ntos de esos asociados a cada m\u00f3dulo… Una herramienta de an\u00e1lisis de c\u00f3digo<\/a> puede llegar a generar varios cientos de indicadores asociados a la mantenibilidad. \u00bfLos obtenemos y consideramos todos? Debemos evitar que los \u00e1rboles nos impidan ver el bosque. Necesitamos un conjunto de informaci\u00f3n manejable que nos permita tomar decisiones a la hora de medir la calidad del software<\/strong>.<\/p>\n En el caso de que la decisi\u00f3n la tome una m\u00e1quina, el n\u00famero de indicadores puede no ser tan problem\u00e1tico pero agrava un segundo factor de riesgo: la disponibilidad de los datos asociados a los par\u00e1metros (primitivas) que componen la f\u00f3rmula del indicador:<\/p>\n \u00bfHasta qu\u00e9 punto una entrega es suficientemente buena? Es el \u201csuficientemente\u201d el factor que m\u00e1s frecuentemente genera ambig\u00fcedad: podemos, sin demasiado esfuerzo, identificar factores cr\u00edticos en una organizaci\u00f3n (funcionalidad de la interfaz de usuario, de un m\u00f3dulo de backend, la seguridad, el rendimiento, la usabilidad\u2026), pero es m\u00e1s complicado establecer donde est\u00e1 el l\u00edmite de lo admisible.<\/p>\n \u00bfQui\u00e9n decide d\u00f3nde deber\u00eda estar el l\u00edmite? Frecuentemente ser\u00e1 el usuario, en ocasiones el responsable de definir y asegurar el cumplimiento de buenas pr\u00e1cticas (ej: Arquitectura)… Este responsable debe definir el criterio a seguir a la hora de establecer los umbrales de calidad (los \u201cquality gates\u201d). El objetivo \u201ccero errores\u201d es una petici\u00f3n (y, a veces, una oferta) relativamente frecuente pero es ligeramente menos realista que plantear un tiempo de respuesta cero o infinitos usuarios concurrentes\u2026 Hay que identificar objetivos viables y suele haber dos fuentes en las que basarse:<\/p>\n Hemos empezado hablando de decisiones que toma una m\u00e1quina (un programa, m\u00e1s bien). Los pasos que hemos dado nos van a permitir proporcionar instrucciones para que la decisi\u00f3n se ajuste a nuestras necesidades; sin embargo, todos los pasos descritos tambi\u00e9n son aplicables a una toma de decisiones \u201ctradicional\u201d llevada a cabo por una persona o conjunto de personas.<\/p>\n Aun en aquellos casos en los que la opci\u00f3n IA est\u00e1 disponible para la toma de decisiones, suele haber situaciones en las que la \u00faltima palabra la toma una persona. En esos casos nos encontramos con que tenemos que aplicar distintos criterios o, al menos, matizarlos:<\/p>\n La idea es tener clara la situaci\u00f3n \u201cde un vistazo\u201d y para ello es particularmente importante el uso de cuadros de mando<\/a> <\/strong>espec\u00edficamente dise\u00f1ados para la toma de decisiones.<\/p>\n\n
Criterios<\/strong><\/h2>\n
Indicadores<\/strong><\/h2>\n
\n
Umbrales de calidad del software<\/strong><\/h2>\n
\n
Y ahora, la valoraci\u00f3n<\/strong><\/h2>\n
\n