GESTION DE LA CALIDAD

(METRICAS DE CALIDAD)

CRISTIAN MANUEL LUNA FLOREZ

16132016

PROFESOR: EDGAR ROLON CAMARGO

UNIVERSIDAD DE SANTANDER
(CUCUTA)
13/10/2020

Definición
Son un conjunto de reglas generadas para la creación de productos de
software con calidad, que si se siguen correctamente pueden garantizar
que el proyecto dará como resultado la satisfacción del cliente.
Se usan para poder medir en términos contables la calidad de los procesos
en que se realiza dicho producto y evita errores comunes.

Usos

• Estimación de costo y esfuerzo.

• Medición de la productividad.
• Acumulación de datos.
• Realización de modelos y mediciones de calidad.
• Elaboración de modelos de seguridad.
• Evaluación y modelos de desempeño.
• Valoración de las capacidades y madurez.
• Administración por métricas.
 • Evaluación del método y herramientas.

Clasificación

La clasificación de una métrica de software refleja o describe la conducta

del software.
Variedad de métricas: tales como portabilidad, facilidad de localización
consistencia, existen pocas investigaciones dentro del área.
Las siguientes clasificaciones de métricas fortalecen la idea de que más de
una métrica puede ser deseable para valorar la complejidad y la calidad de
software.

Métricas de complejidad: Son todas las métricas de software que definen

de una u otra forma la medición de la complejidad; Tales como volumen,
tamaño, anidaciones, costo (estimación), agregación, configuración, y flujo.
Estas son los puntos críticos de la concepción, viabilidad, análisis, y diseño
de software.

Métricas de calidad: Son todas las métricas de software que definen de

una u otra forma la calidad del software; Tales como exactitud,
estructuración o modularidad, pruebas, mantenimiento, reusabilidad,
cohesión del módulo, acoplamiento del módulo, etc. Estas son los puntos
críticos en el diseño, codificación, pruebas y mantenimiento.

Métricas de competencia: Son todas las métricas que intentan valorar o

medir las actividades de productividad de los programadores o
practicantes con respecto a su certeza, rapidez, eficiencia y competencia.
No se ha alcanzado mucho en esta área, a pesar de la intensa
investigación académica.

Métricas de desempeño: Corresponden a las métricas que miden la

conducta de módulos y sistemas de un software, bajo la supervisión del
sistema operativo o hardware. Generalmente tienen que ver con la
eficiencia de ejecución, tiempo, almacenamiento, complejidad de
algoritmos computacionales, etc.
Métricas estilizadas: Son las métricas de experimentación y de
preferencia; Por ejemplo: estilo de código, identificación, las convenciones
denominando de datos, las limitaciones, etc. Pero estas no se deben
confundir con las métricas de calidad o complejidad.

MÉTRICAS DE CALIDAD DE SOFTWARE

La calidad es un concepto relativo y multidimensional, referido a las

expectativas y cualidades solicitados por el cliente, a su vez, está ligada a
restricciones y compromisos (presupuesto y tiempo de desarrollo, entre
otros). Sin embargo, existe algo que nadie puede negar, cuando algo
es de calidad suele pasar desapercibido, pero, por el contrario, la
mala calidad es algo que destaca negativamente.

Durante el proceso de desarrollo de una aplicación, es muy probable

la aparición de bugs causados por fallos humanos. A su vez, las
exigencias del usuario cada vez se incrementan, exigiendo una mejor
performance de las aplicaciones que creamos. Pero, ¿cómo podemos
entonces mejorar la calidad de nuestras aplicaciones? Justamente, para
producir software de calidad y cumplir con la expectativas de
nuestros usuarios es que existen diferentes métricas de calidad de
software. Métricas de calidad de software es un conjunto de medidas
utilizadas para estimar la calidad de un proyecto a desarrollar, entre
otros conceptos, y que permiten comparar o planificar estas
aplicaciones.

Es una propiedad de la aplicación compleja, ya que no existe una

precisión absoluta para determinar cuáles son los elementos o
procedimientos relevantes que deben ser aplicados a la hora de
escribir código. También, es necesario definir las acciones a tomar
dependiendo de los resultados de estas métricas.

Existen diferentes herramientas que nos ayudan en la tarea de

mejorar el desarrollo de nuestras aplicaciones. En Ruby, Rubocop,
Rubicritic, Bullet son algunas que pueden salvarnos el día y
ayudarnos a optimizar nuestro código. Pero lo que hacen estas
herramientas no es magia.
A continuación describiremos algunas de las principales métricas utilizadas
por estas herramientas para determinar la calidad del código producido.

Acoplamiento
«Hay dos formas de diseñar software: la primera es hacerlo tan
simple que obviamente no hay deficiencias y la segunda es hacerlo
tan complicado que no hay deficiencias obvias. La primera forma es
mucho más difícil.» C.A.R. Hoare

Acoplamiento (Coupling) se refiere al nivel de «conectividad» de un

módulo con otros módulos, datos globales y entorno exterior. Durante el
desarrollo de la aplicación, uno de los objetivos es mantener una
baja dependencia o acoplamiento, esto quiere decir que, un módulo debe
ser capaz de interactuar con otro a través de una interfaz estable y sin
depender de otros, para su correcta implementación. Por el contrario, un
sistema con un nivel de acoplamiento alto tendrá módulos que se
encontrarán inter ligados entre sí y se comunicarán directamente unos con
otros sin ningún tipo de barrera, por lo que el código será difícil de
comprender, reutilizar, y al no estar aislados, se deben considerar
todas sus dependencias.

Un problema común con este tipo de aplicaciones es que, en caso de un

cambio en algún módulo, puede desencadenar un efecto dominó en
otros módulos, por lo que será necesario rehacer código en el resto de
los módulos dependientes.

Un código acoplado va directamente en contra del principio «Tell, Don’t

Ask» (TDA), que promueve el encapsulado conjunto de los datos y de las
funciones que operan sobre estos datos.

Cohesión
Cohesión (Cohesion) define el grado de relación que existe entre los
elementos de un módulo.

Un módulo que siga el Principio de Responsabilidad Única o SRP

por sus siglas en ingles debe realizar una única cosa. Es muy habitual,
si no prestamos atención a esto, que acabemos teniendo clases que tienen
varias responsabilidades lógicas a la vez.

Cuando se tienen clases con baja cohesión implica, entre otras cosas:

Falta de comprensibilidad
Difícil mantención
Difícil reutilización de código
Complejidad
“Cualquier tonto puede escribir código que un ordenador
entiende. Los buenos programadores escriben código que los
humanos pueden entender.» Martin Fowler

Una de las métricas más importantes con la que contamos en el

desarrollo es la complejidad ciclomática, que puede ser usada en las
fases de desarrollo o mantenimiento entre otras.

Esta métrica, propuesta por Thomas McCabe en 1976, se basa en el

diagrama de flujo determinado por las estructuras de control de un
determinado código. Del análisis de esta estructura se obtendrán las
medidas cuantitativas que nos facilitarán la comprensión y mejora de las
mismas.

La complejidad ciclomática está fuertemente relacionada a un

algoritmo claro y eficaz, que, a su vez, se relaciona a otro tipo de
complejidad, la complejidad cognitiva.

Existen diferentes prácticas que ayudan a bajar esta complejidad

cognitiva, la que más agradecemos, como desarrolladores, son los
comentarios en el código.

La Complejidad Cognitiva mide que tan difícil es entender

intuitivamente un bloque de código, a diferencia de la Complejidad
Ciclomática, que determina qué dificultad tiene probar el código.

Algunos estudios han probado una correlación directa entre la

complejidad ciclomática y la cantidad de bugs de un trozo de código, o el
numero de líneas de este. Por esto podemos concluir que, a mayor
complejidad y dimensión, se presentan mayores problemas y fallos
en nuestro código.

Code Churn
Es la frecuencia con la que se añade, quita o altera el código a
través del tiempo. En palabras simples, es la cantidad de veces en la
que el fichero ha sido modificado.

Esta métrica presenta una relación directa con código defectuoso. esto
quiere decir, mientras más modificaciones sufra un código, mayor es la
posibilidad de introducir un bug.

Esta métrica es fácil de calcular usando un sistema de control de

versiones (git, mercurial). Basta contabilizar el numero de commits que
modificaron un dato, fichero, o toda una clase.

Code Coverage
Mide el porcentaje de código que se encuentra testeado. Tener test de
calidad en nuestro proyecto, ayudará a incrementar el valor de esta
métrica y, a su vez, será menos probable que el código contenga
bugs.

Código Muerto
El código muerto (Dead code) es código que no es ejecutado. Es
difícil de identificar ya que, no siempre sabemos si cierto extracto de
código se está ejecutando en producción o no. Esta métrica es útil para
verificar la calidad del código, sin embargo, no existe ningún método que
detecte este código muerto y sea infalible.
Por ejemplo, puede haber código que solo es ejecutado por
herramientas o servicios externos, y que se encuentran fuera del control
de herramientas que determinan si el código es utilizado o no. De ese
modo se pueden gatillar falsos positivos.

Algunos desarrolladores tiene la técnica «borrar, cerrar y cruzar» y

que no es más que borrar el código sospechoso, cerrar los ojos y
cruzar los dedos para que nada se caiga… Claramente esta no es una
técnica recomendable.

Tener pruebas automatizadas nos ayudarán a detectar potenciales errores

al borrar código.

Duplicación de Código
«Medir el progreso de la programación por líneas de código es como medir
el progreso en la construcción de aviones por el peso.» Bill Gates.

Código duplicado (Code duplication) es el término utilizado para una

estructura de código que se declara más de una vez dentro de una
aplicación. La existencia del código duplicado ocurre frecuentemente
cuando el programador no está familiarizado con el código, lo que lo
lleva a replicar trozos de código. Es importante entender que código
duplicado no es exactamente código exáctamente igual, sino que puede
ser código con ligeras adaptaciones.

Probablemente, el mayor enemigo del código limpio es el código

duplicado. El principio DRY (Don’t Repeat Yourself) viene a nuestro
rescate.

La existencia de código duplicado afecta a los costos del proceso,

ya que provocará una mayor complejidad ciclomática, un mayor
número de pruebas unitarias, aumenta innecesariamente el tamaño del
proyecto, y es mas difícil de modificar, ya que hacerlo implica cambiar
todas las copias, lo que podría inducir al error ya que el programador
podría olvidar realizar las modificaciones correspondientes donde se
encuentra el código duplicado (shit happens).
¿Cuáles son los beneficios de aplicar métricas?
Una organización que aplica métricas en sus procesos busca
incrementar el retorno de la inversión, identificar las áreas a mejorar,
optimizar el tiempo invertido en el proceso, y reducir los costos de
operación.

Al aplicar estas métricas, mejoraremos la comunicación, ya que

sabremos el real estado de nuestros proyectos, ayudándonos a
mejorar la estimación de tiempos de desarrollo, prevenir posibles
fallos, reducir costos y mejorar el manejo del proceso priorizando los
puntos realmente importantes.

Tal como se indica en un principio de este artículo, cada vez es

más común utilizar herramientas,con métricas mucho mas exactas, que
nos permiten optimizar nuestro código.

Lamentablemente, ni siquiera las mejores métricas garantizarán una

aplicación exitosa. Sin embargo, la combinación de estas métricas, un
buen proceso de trabajo, la aplicación de buenas prácticas al
programar, y pasión por nuestro proyecto, nos ayudará a entregar
una aplicación de calidad al usuario final, dándole un valor adicional a
nuestro trabajo.

«Si deseas empezar y desarrollar algo grandioso, no necesitas

millones de dólares de capitalización. Necesitas suficiente pizza y Diet
Coke en la nevera, una PC barata y trabajo y dedicación para realizar
tu idea.» John Carmack
Beneficios y ejemplos del uso de métricas de calidad de software
La mala calidad de la información y de software impacta negativamente en
el negocio a diferentes niveles:

Disminuye ingresos y aumenta el gasto.

Incrementa el riesgo.
Provoca una reducción de la confianza, tanto dentro como fuera de la
organización.
Un enfoque proactivo tanto del gobierno de la información como del data
quality permite la identificación temprana de errores o defectos que pueden
ser corregidos a tiempo, eliminando de raíz problemas mayores. Los
efectos positivos empiezan a notarse y sus beneficios aumentan en un
ciclo de mejora continua propiciado por el control de las métricas de
calidad de software.

Esta monitorización facilita el evaluar:

La calidad del producto.

El rendimiento del equipo de desarrollo.
La justificación del uso de nuevas herramientas o soluciones.
Los resultados obtenidos a partir de la incorporación del software a los
procesos y operaciones.
Para conseguir llegar al nivel de evaluación, es preciso contar con datos
relevantes, precisos y actualizados sobre diferentes áreas, que faciliten
una perspectiva global de la solución. Así, las métricas de calidad de
software pueden aplicarse a diferentes contextos, como:

El proyecto: son las que facilitan la gestión del riesgo permitiendo tomar el
pulso a la iniciativa de desarrollo desde su inicio.
El producto: están enfocadas a medir las características del software y
todos los entregables que lo acompañan, fruto del proyecto de desarrollo,
como modelos, componentes adicionales y documentación.
El proceso: tienen por objeto identificar mejores prácticas para su
exportación a futuros proyectos y, para conseguirlo, recopilan datos de
distintas iniciativas a lo largo de un periodo de tiempo determinado.
Sin embargo, a la hora de centrarse en la solución en sí, existen algunas
métricas de calidad de software imprescindibles, como las que tienen que
ver con los cinco siguientes criterios:

A/ Métricas de exactitud: intentan aportar información sobre la validez y

precisión del software y su estructura, incluyendo la etapa de despliegue,
pero también la de pruebas y la función de mantenimiento.
B/ Métricas de rendimiento: a través de ellas se consigue medir el
desempeño del software, tanto de cada uno de sus módulos, como del
sistema al completo.

C/ Métricas de usabilidad: hay que descartar la complejidad y buscar una

solución intuitiva y user-friendly. este tipo de métricas de calidad de
software ayudan a determinar si la solución cumple con dichos requisitos.

D/ Métricas de configuración: las limitaciones, el estilo de código y todos

los datos relativos al desarrollo y cualidades del producto se verán
evaluados en base a estas métricas.

E/ Métricas de eficiencia: minimización de latencias, velocidad de

respuesta, capacidad, es un enfoque similar al de la productividad pero
con un matiz un poco distinto, que añadido a aquél, aporta una visión
mucho más completa de la solución.

De esta forma, evaluando el software a través de diferentes ópticas y en

base a continuas mediciones, se puede ganar en alineación con el objetivo
de calidad que, poco a poco, se irá sofisticando y para lograr alcanzar
cotas superiores.

Conclusión

Una métrica de un de un atributo o producto se deriva de una o que se

deriva de un análisis tanto interno como externo de los componentes del
producto que dependen de la calidad, funcionalidad, y usabilidad del
producto o software para hacer una conclusión del alcance y aceptación de
la misma.
Basándose en la calidad la teoría y de modelos de métricas nos puede
ayudar a facilitar si el producto tiene viabilidad o no por medio de
indicadores que sirven de base para la evaluación de lo tangible, en caso
de la métrica pueda medirlo es aplicable.