14.1 Métricas del software
El grado de la calidad del software se establece a través de una evaluación numérica de sus atributos. Para estar seguros de que se ha construido un software de mejor calidad que la versión anterior, es necesario determinar medidas que permitan su comparación, evitando así que juicios subjetivos en relación a la calidad del producto. El software no puede establecer una sola métrica para determinar si la calidad es mejor o peor, es necesario formular un grupo de medidas desde la planeación. De acuerdo con Pressman (2010), medir al software tiene dos principales objetivos: entender mejor el proceso de diseño y la construcción del software, y segundo, enfocarse en los atributos que dan valor al software.
“La medición es esencial si debe lograrse la calidad” (Pressman, 2010).
Establecer métricas de producto permite lo siguiente:
- Auxiliar la evaluación de los modelos de análisis y diseño.
- Proporcionan un indicio de la complejidad del diseño de los procesos y del código fuente.
- Permiten diseñar pruebas más efectivas.
El principal reto que tiene la industria del software al establecer cualquier métrica, es que las medidas no absolutas utilizadas como las que existen en otras industrias, por ejemplo, la velocidad, el voltaje y la temperatura, sino que tienen un cierto grado de subjetividad que puede prestarse al debate. Sommervile (2011) y Pressman (2010) coinciden en los siguientes pasos que conforman el proceso de medición:
- Elegir mediciones a realizar: se seleccionan las mediciones y métricas del software más adecuadas para el software que se está construyendo.
- Seleccionar los componentes a valorar: se deberá tomar una muestra representativa de los componentes cuando el tamaño del software no permita utilizarlos todos. Con los resultados obtenidos se puede inferir la calidad total del software.
- Medir las características de los componentes: se recolectan los datos para derivar las métricas formuladas.
- Identificar mediciones anómalas: se comparan los resultados con una base, que puede ser un estándar en la industria o en relación a datos históricos.
- Analizar componentes anómalos: se determina si los resultados obtenidos pueden o no comprometer la calidad del software. Un registro fuera del estándar o del umbral preestablecido no siempre significa que se ha perdido la calidad del software.
Principios asociados con las métricas:
- Antes de medir cualquier proceso, es necesario establecer los objetivos que se buscan alcanzar y el mecanismo que será utilizado para recopilar datos.
- Cada métrica debe ser descrita de forma clara y sin ambigüedades, para que pueda ser entendida tanto por las personas que participan en la recopilación de datos como por las personas involucradas en el proceso a analizar.
- Se deben elegir las métricas más adecuadas según el proceso que se quiere medir.
- Debe buscarse automatizar el proceso de medición del software con el fin de mantener la consistencia.
- Utilizar unas pocas métricas que ofrezcan un valor a la calidad que recibe el cliente.
- Cada métrica debe pasar por un proceso de validación en una gran variedad de contextos a fin de determinar su idoneidad.
- Las mediciones de un proceso deben conducir a un plan de mejora continua.
Atributos de las métricas efectivas:
Al establecer las métricas del software es importante que consideres los siguientes atributos que evitan confusiones o ambigüedades.
De acuerdo con Pressman (2010), una métrica efectiva debe tener las siguientes características:
- Simple y calculable: tan simple que para su cálculo no se requiere una especialización o experiencia, debe ser fácil de calcular.
- Empírica e intuitivamente convincente: debe estar basada en la práctica o experiencia del ingeniero. Tiene que tener sentido.
- Congruente y objetiva: se puede llegar al mismo resultado independientemente de la persona que la genere.
- Constante en su uso de unidades y dimensiones: para fines de comparación a través del tiempo, tanto el método de cálculo como las unidades utilizadas deben ser las mismas.
- Independiente del lenguaje de programación: es frecuente que los proyectos de desarrollo de software utilicen plataformas de programación diferentes, por lo que las métricas no deben depender del lenguaje utilizado en la construcción del sistema.
- Un mecanismo efectivo para retroalimentación de alta calidad: establecer métricas adecuadas podrán ser una base sólida para generar productos de software con mejor calidad.
14.2 Tipos de métricas del software
De acuerdo con Sommerville (2011), existen dos tipos de métricas, las de control y las de predicción.
- Métricas de control: permiten establecer umbrales en los que el atributo del software debe mantenerse para asegurar un nivel adecuado de calidad. Estas métricas deben ser revisadas de manera periódica y generalmente se encuentran asociadas a un proceso específico del desarrollo, por ejemplo, esfuerzo promedio y tiempo requerido para detectar defectos.
Las métricas de control ofrecen información para ayudar a los administradores para realizar los cambios a un proceso.
- Métricas de predicción: ofrecen estimar el nivel de calidad que tendrá alguna característica del producto del software. La complejidad ciclomática de un módulo, la longitud promedio de los identificadores de un programa, cantidad de atributos y operaciones con las clases de objetos de un diseño, son ejemplos de métricas de predicción.
Según Sommerville (2011) estas métricas permiten estimar el esfuerzo requerido para hacer cambios al software.
Imagen tomada del libro de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación.
Métricas del producto de software
Sommerville (2011) propone dos clases esencialmente de métricas del producto de software.
Métricas dinámicas: son las que se pueden realizar cuando el producto del software se está ejecutando, por ejemplo, el número de reportes de defectos o el tiempo requerido para completar un cálculo.
Métricas estáticas: esta clase precisa de mediciones a elementos que representan el software, por ejemplo, al diseño, a la documentación o a los programas. Permiten valorar la complejidad, comprensibilidad y mantenibilidad. Entre las mediciones estáticas se encuentran el tamaño del código y la longitud de los identificadores que se utilizaron.
Métrica de software |
Descripción
|
Fan-in/Fan-out |
Fan-in (abanico de entrada) es una medida del número de funciones o métodos que llaman a otra función o método (por ejemplo, X). Fan-out (abanico de salida) es el número de funciones a las que llama la función X. Un valor alto para fan-in significa que X está estrechamente acoplado con el resto del diseño y que los cambios a X tendrán extensos efectos dominó. Un valor alto de fan-out sugiere que la complejidad global de X puede ser alta debido a la complejidad de la lógica de control necesaria para coordinar los componentes llamados. |
Longitud de código |
Es una medida del tamaño de un programa. Por lo general, cuanto más grande sea el tamaño del código de un componente, será más probable que el componente sea complejo y proclive a errores. Se ha demostrado que la longitud del código es una de las métricas más fiables para predecir la proclividad al error en los componentes. |
Complejidad ciclomática |
Es una medida de la complejidad del control de un programa. Tal complejidad del control puede relacionarse con la comprensibilidad del programa. |
Longitud de identificadores |
Es una medida de la longitud promedio de los identificadores (nombres para variables, clases, métodos, etcétera) en un programa. Cuanto más largos sean los identificadores, es más probable que sean significativos y, por ende, más comprensible será el programa. |
| Profundidad de anidado condicional |
Es una medida de la profundidad de anidado de los enunciados “if” en un programa. Los enunciados “if” profundamente anidados son difíciles de entender y proclives potencialmente a errores. |
| Índice Fog |
Es una medida de la longitud promedio de las palabras y oraciones en los documentos. Cuanto más alto sea el valor del índice Fog de un documento, más difícil será entender el documento. |
Recuperado de de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación.
Ambigüedad del software
El análisis de las métricas e indicadores de un software requiere la consideración del contexto en donde se generan, ya que podrían conducir a conclusiones erróneas si no se toman en cuenta. Por ejemplo, considerar que la cantidad de cambios solicitados por el cliente a una versión del software entregada es una medida de la usabilidad del software, puede ser un error, ya que no todos los cambios están relacionados a defectos de usabilidad, sino también incluyen cambios en las necesidades del cliente o cambios que se tienen que realizar para cumplir con una norma externa; en ambos escenarios, los cambios no tienen que ver con la usabilidad que percibe el cliente. De igual manera, el hecho de que no se registren cambios a un software entregado puede deberse a que el usuario sigue utilizando herramientas antiguas en lugar de una nueva versión.
14.3 Técnicas de optimización
La optimización del software es el proceso de modificar aspectos del software con el fin de mejorar su eficiencia, ya sea a nivel del diseño, del código fuente o a nivel del tiempo de ejecución. Según El-Haik y Shaout (2010), en este mismo proceso de optimización se debe tener en cuenta que existirá la posibilidad de afectar algún otro atributo. Por ejemplo, enfocar el esfuerzo por optimizar la seguridad del software podría afectar el tiempo de respuesta del software.
El paradigma GQM (Goal-Question-Metric)
Para mejorar un proceso es posible hacer uso del paradigma GQM o Meta-Pregunta-Métrica, propuesto por Basili y Rombach en 1988 y ha sido ampliamente utilizado en procesos de mejora en la NASA.
Según Sommerville (2011), la ventaja de seguir este enfoque de mejora es la separación que existe entre las preocupaciones de la organización (expresadas en las metas) con las preocupaciones específicas del proceso, además busca obtener datos que ayuden a mejorar un aspecto particular del proceso y no sólo generar la métrica para medir algo.
El paradigma es utilizado para ayudar a responder a las siguientes preguntas:
- ¿Por qué se introduce la mejora de procesos?
- ¿Qué información se requiere para identificar y valorar las mejoras?
- ¿Qué mediciones de proceso y producto se requieren para obtener esta información?
Metas: es un objetivo al que se desea llegar. Es posible que la organización desee terminar sus proyectos de desarrollo en menos tiempo, aumentar la confiabilidad del software, mejorar la seguridad de la información.
Preguntas: para cada una de las metas se proponen algunas preguntas a resolver. ¿Cómo se reduce el tiempo dedicado a la documentación de requerimientos? ¿Cuántos casos de prueba deben diseñarse como parte del aseguramiento de la calidad? ¿En qué parte del proceso existe mayor consumo de tiempo?
Métricas: se establecen las métricas que responderán a cada una de las preguntas. Estas métricas pueden confirmar si el desempeño de un proceso ha mejorado.
En el siguiente diagrama puedes observar cómo una meta genera varias preguntas y algunas métricas pueden responder a una o varias preguntas.
El paradigma GQM.
Recuperado de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación.
Ejemplos de métricas según las metas
Pressman (2010) ofrece el siguiente listado de métricas para poder alcanzar metas que permitan mejorar la calidad del software:
Meta |
Atributo
| Métrica
|
| Calidad de los requerimientos |
Ambigüedad |
Número de modificadores ambiguos (por ejemplo: muchos, grande, amigable, etc.) |
| Completitud |
Número de TBA (To Be Announced), TBD (To Be Determined). TBC (To Be Confirmed) |
| Comprensibilidad |
Número de secciones y subsecciones |
| Volatilidad |
Número de cambios por requerimientos
Tiempo (por actividad) cuando se solicita un cambio |
| Trazabilidad |
Número de requerimientos no trazables hasta el diseño o código |
| Claridad del modelo |
Número de modelos UML
Número de páginas descriptivas por modelo
Número de errores de UML |
| Calidad del diseño |
Integridad arquitectónica |
Existencia del modelo arquitectónico |
| Completitud de los componentes |
Número de componentes que se siguen hasta el modelo arquitectónico
Complejidad del diseño del procedimiento |
| Complejidad de la interfaz |
Número promedio de pasos para llegar a una función o contenido normal
Distribución apropiada |
| Patrones |
Número de patrones utilizados |
| Calidad del código |
Complejidad |
Complejidad ciclomática |
| Facilidad de mantenimiento |
Factores del diseño (abstracción, modularidad, independencia funcional, cohesión) |
| Comprensibilidad |
Porcentaje de comentarios internos
Convenciones, variables de nomenclatura |
| Reusabilidad |
Porcentaje de componentes reutilizados |
| Documentación |
Índice de legibilidad |
| Eficacia del control de calidad |
Asignación de recursos |
Porcentaje del personal por hora y por actividad |
| Tasa de finalización |
Tiempo de terminación real contra lo planeado |
| Eficacia de la revisión |
Esfuerzo total de revisión, numero de errores descubiertos, densidad del error, esfuerzo ahorrado por error |
| Eficacia de las pruebas |
Número de errores de importancia crítica encontrados
Esfuerzo requerido para corregir un error
Origen del error |
Recuperado de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. (7a. Ed). México: McGraw Hill
Proceso de cambios al proceso
Cuando se determina que un proceso debe cambiar, ya sea introduciendo nuevas herramientas, alterar la secuencia de tareas, introducir nuevas tareas, eliminar pasos redundantes o incorporar nuevos roles o responsabilidades, el mejor camino para establecer el cambio es a través de los siguientes pasos, según Sommerville (2011).
Haz clic para conocer más detalle
El equipo técnico de desarrollo debe buscar áreas de oportunidad para mejorar el proceso de construcción del software, esto implica analizar métricas e indicadores de forma periódica y tratar de encontrar las causas relacionadas a un pobre desempeño y que seguramente están afectando el costo del proyecto y a la calidad del producto.
De la lista de posibles mejoras que se pueden implementar se deben elegir las que generen mejores resultados en relación al costo-beneficio de implementarlas. Es muy importante evitar introducir demasiados cambios a la vez, ya que el esfuerzo estará disperso y habrá confusión sobre cuál de ellos ha producido mejores resultados.
Cada cambio debe realizarse de forma planeada, deben existir los procedimientos documentados, métodos, herramientas, métricas e indicadores. Considera que cada cambio requiere tiempo de implementación.
El cambio en un proceso de software debe ser implementado por los miembros del equipo de desarrollo. Si se desea que el cambio genere los resultados esperados será necesario que quienes lo ejecuten entiendan la razón del cambio. Es muy probable que se requieran varias revisiones para asegurar que se ha aplicado el cambio.
“Los cambios del proceso propuesto nunca serán complemente efectivos al momento de introducirlos” (Sommerville, 2011). Es muy probable que durante la implementación de un cambio puedan aparecer problemas menores que impliquen realizar ajustes al cambio propuesto. El equipo de desarrollo debe determinar si los ajustes sugeridos pertenecen al cambio o son cambios mayores que deben analizarse en otro momento.
Es muy frecuente que durante este proceso de introducir nuevos cambios existan otras sugerencias de cambios, estas sugerencias deben ser analizadas y priorizadas antes de implementarlas. Considera, además, que la introducción de cualquier cambio provoca una respuesta de los involucrados, por lo que es necesario que consideres estrategias para administrar la resistencia al cambio.
