1

Métricas en el desarrollo de calidad de

Software.
(25 abril de 2022)
Joan Vladimir Ramirez, Ingrid Lorena Estupiñán Delgado


El siguiente documento trata de explicar y analizar las métricas II. METRICAS DE REVISIÓN
que utilizamos en la calidad del software, estas permiten
monitorizar un producto para determinar su nivel de calidad,
aunque, el seguimiento que este tipo de medidas permiten llevar a Estas métricas pueden mejorarse, asociando el tipo de producto
cabo unas pautas para su buen uso, también brinda la oportunidad del trabajo que se revisó con las métricas obtenidas.
de conocer muchas más cosas de una solución.
Las revisiones técnicas son una de las muchas acciones que se
requieren como parte de las buenas prácticas de la ingeniería de
I. INTRODUCCION software. Cada acción requiere un esfuerzo humano dirigido.
Como el esfuerzo disponible para el proyecto es finito, es
P ara empezar, podemos decir que la calidad del software se
importante que una organización de software comprenda la
eficacia de cada acción, definiendo un conjunto de métricas que
encuentra relacionado con las expectativas y cualidades puedan utilizarse para evaluar esa eficacia.
requeridas por el cliente, ligado a restricciones y compromisos,
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 y es muy
notorio ya que no cumple con las expectativas del usuario o
suele verse de manera disgustaste por que el producto que
nosotros creamos como se explicó anteriormente debe ser
acorde con la visión que tenga el cliente en mente.

Justamente, para producir software de calidad y cumplir con las

expectativas de nuestros usuarios es que existen diferentes
métricas de calidad de software.
Con lo anterior es primordial cumplir este objetivo y la
ingeniería de software nos ofrece bastante ayuda y soportes para
producir o crear los sistemas, con ellos empleamos métodos
eficaces al mismo tiempo medimos la calidad que se va a llevar
a cabo, aunque se han definido muchas métricas para las
revisiones técnicas [1],” un conjunto relativamente pequeño da
una perspectiva útil”. Las siguientes métricas para la revisión
pueden obtenerse conforme se efectúe ésta:
• Esfuerzo de preparación, Ep: esfuerzo (en horas-hombre)
requerido para revisar un producto del trabajo antes de la
reunión de revisión real.
• Esfuerzo de evaluación, Ea: esfuerzo requerido (en horas-
hombre) que se dedica a la revisión real.
• Esfuerzo de la repetición, Er: esfuerzo (en horas-hombre)
que se dedica a la corrección de los errores descubiertos durante
la revisión.
Planeacion del producto Fig[1]
III. ANALISIS DE LAS METRICAS
Por ejemplo, si se revisa un modelo de requerimientos con
objeto de encontrar errores, inconsistencias y omisiones, es
posible calcular la densidad del error en varias formas
diferentes. La densidad del error es 1.2 errores por diagrama
UML o 0.68 errores por página del modelo de requerimientos.
Si las revisiones se llevan a cabo para varios tipos distintos de
productos del trabajo, el porcentaje de errores no descubiertos
por cada revisión se confronta con el número total de errores
detectados en todas las revisiones. Por ejemplo, si la densidad
promedio de error para un modelo de requerimientos es de 0.6
errores por página, y un nuevo modelo de requerimientos tiene
una longitud de 32 páginas, una estimación gruesa sugiere que
el equipo de software encontrará alrededor de 19 o 20 errores
durante la revisión del documento. Si sólo encuentra 6 errores,
habrá hecho un trabajo extremadamente bueno al desarrollar el
modelo de requerimientos o su enfoque de la revisión no fue tan
 2

profundo, usted tendrá mayor control sobre la apariencia de sus

figuras si usted puede preparar los archivos electrónicos de
imagen. Si usted no tiene las habilidades de computación
requeridas, sólo envíe las impresiones de papel como se
describió anteriormente y salte esta sección.

Esfuerzo realizado, con y sin revisiones Fig[2]

Con los puntos que acabamos de abarcar, Las cosas pueden

hacerse bien o pueden volverse a hacer. Si un equipo de
software pone el énfasis en la calidad en todas las actividades Metas atributos y métricas del software Fig[3]
de la ingeniería de software, se reduce la cantidad de
repeticiones que debe hacer. Eso da como resultado costos más
bajos y, lo que es más importante, un mejor tiempo para llegar
al mercado. IV. PRUEBAS DE SOFTWARE

No basta para decir que la calidad del software es importante.
Tiene que:
1) definirse explícitamente lo que quiere decir “calidad
del software”.
2) crearse un conjunto de actividades que ayuden a
garantizar que todo producto de la ingeniería de software
tenga alta calidad
Puesto que el software orientado a objeto no tiene una estructura
de control jerárquico obvia, las estrategias tradicionales
descendente y ascendente (sección 17.3.2) tienen poco
significado. Además, con frecuencia es imposible integrar las
operaciones una a la vez en una clase (el enfoque de integración
incremental convencional) debido a las “interacciones directa e
indirecta de los componentes que constituyen la clase” [Ber93].

3) desarrollarse el control de calidad y las actividades

para asegurar ésta en todo proyecto de software,

4) usarse métricas para desarrollar estrategias a fin de

mejorar el proceso del software y, en consecuencia, la
calidad del producto final.

Ilustración 4 Pruebas de software

prueba que se enfocan en entradas y salidas, aunque también

pueden usarse técnicas que ejercitan rutas de programa
específicas para asegurar la cobertura de las principales rutas de
control. Después de integrar (construir) el software, se realiza
una serie de pruebas de orden superior. Deben evaluarse
criterios de validación (establecidos durante el análisis de
requerimientos). La prueba de validación proporciona la
garantía final de que el software cumple con todos los
requerimientos informativos, funcionales, de comportamiento y

de rendimiento. El último paso de la prueba de orden superior
cae fuera de las fronteras de la ingeniería de software y en el
contexto más amplio de la ingeniería de sistemas de cómputo.
El software, una vez validado, debe combinarse con otros
elementos del sistema (por ejemplo, hardware, personal, bases
de datos). La prueba del sistema verifica que todos los
elementos se mezclan de manera adecuada y que se logra el
funcionamiento/rendimiento global del sistema.
V. TIPOS DE METRICAS
A. Métrica basada en funciones
La métrica de punto de función (PF) puede usarse de manera
efectiva como medio para medir la funcionalidad que entra a un
sistema.4 Al usar datos históricos, la métrica PF puede entonces
usarse para:
1) estimar el costo o esfuerzo requerido para diseñar, codificar
y probar el software acerca de las métricas PF se han escrito
cientos de libros, ensayos y artículos
2) predecir el número de errores que se encontrarán durante las
pruebas, y 3) prever el número
de componentes y/o de líneas fuente proyectadas en el sistema
implementado.
Los puntos de función se derivan usando una relación empírica
basada en medidas contables (directas) del dominio de
información del software y en valoraciones cualitativas de la
complejidad del software.
Ilustración 5 Cálculo de puntos
B. Métricas para calidad de la especificación
Davis et al. [Dav93] proponen una lista de características que
pueden usarse para valorar la calidad del modelo de
requerimientos y la correspondiente especificación de
requerimientos: especificidad (falta de ambigüedad),
completitud, corrección, comprensibilidad, verificabilidad,
consistencia interna y externa, factibilidad, concisión,
rastreabilidad, modificabilidad, precisión y reusabilidad.
Además, los autores observan que las especificaciones de alta
calidad se almacenan electrónicamente, son ejecutables o al
menos interpretables, se anotan mediante importancia relativa,
son estables, tienen versión, se organizan, cuentan con
3
referencia cruzada y se especifican en el nivel correcto de
detalle. Aunque muchas de estas características parecen ser
cualitativas por naturaleza, Davis et al. [Dav93] sugieren que
cada una puede representarse usando una o más métricas. Por
ejemplo, se supone que existen n requerimientos en una
especificación, tales que:
donde nf es el número de requerimientos funcionales y nnf es
el número de requerimientos no funcionales (por ejemplo,
rendimiento).
C. Métricas de diseño en el nivel de componente
Las métricas de diseño en el nivel de componente para
componentes de software convencional se enfocan en las
características internas de un componente de software e
incluyen medidas de cohesión de módulo, acoplamiento y
complejidad.
Dichas medidas pueden ayudarlo a juzgar la calidad de un
diseño en el nivel de componente. Las métricas de diseño en el
nivel de componente pueden aplicarse una vez desarrollado el
diseño procedural y son “cajas de cristal” en tanto requieren
conocimiento del funcionamiento interior del módulo en el que
se está trabajando. Alternativamente, pueden demorarse hasta
que el código fuente esté disponible.
D. Métricas de diseño de interfaz de usuario
Para las interfaces hombre/computadora. Una GUI típica usa
entidades de plantilla (íconos gráficos, texto, menús, ventanas
y similares) para auxiliar al usuario a completar tareas. Para
lograr una tarea dada usando una GUI, el usuario debe moverse
de una entidad de plantilla a la siguiente. La posición absoluta
y relativa de cada entidad de plantilla, la frecuencia con la que
se usa y el “costo” de la transición desde una entidad de plantilla
a la siguiente contribuirán a la corrección de la interfaz.
VI. RAZONES PARA MEDIR UN PRODUCTO.
Como observamos anteriormente, la ingeniería es una
disciplina cuantitativa. Las métricas de producto ayudan a los
ingenieros de software a obtener comprensión acerca del diseño
y la construcción del software que elaboran, al enfocarse en
atributos específicos de los productos de trabajo de la ingeniería
del software.
Se debe establecer los objetivos a partir de los datos
recolectados de los modelos de requerimientos y de diseño,
código fuente y casos de prueba, con ello la medición
comenzara la recolección de datos en donde debe definir cada
métrica de producto sin duplicar la información después
definimos sólo algunas métricas y luego las usamos para
obtener una mayor comprensión acerca de la calidad del
 4

producto el cual estamos trabajando y realizar la respectiva IX. REFERENCIAS

retroalimentación con nuestro equipo de desarrollo.
[1] P. Roger S. Pressman, Ingeniería del software UN
ENFOQUE PRÁCTICO, buenos aires: Mc Grar Hill,
VII. RELACIÓN ENTRE EL ESTABLECIMIENTO DE MÉTRICAS
2010.
Y LA CALIDAD DEL PRODUCTO FINAL.
[2] P. Pressman, «METRICAS,» de INGENIERÍA DEL
SOFTWARE. UN ENFOQUE PRÁCTICO, BUENOS
Como relación entre métricas y la calidad del producto final, es
AIRES, MC GRALL HILL, 2010, pp. 50-52.
que son aplicadas en un proceso de desarrollo del software y
brindan una información que permite a los desarrolladores
mejorar el proceso y los productos. Las métricas son propiedad X. BIBLIOGRAFÍA
en cada modelo de calidad y están creadas para medir los
criterios, en este proceso se recogen las métricas y se realiza [1] P. Roger S. Pressman, Ingeniería del software UN ENFOQUE PRÁCTICO, buenos
mediante la obtención de datos en los procesos de ingeniería de aires: mc grar hill, 2010.

software como también los proyectos y productos del mismo.
Ya que para la calidad del producto final debe ajustarse a los
requerimientos que el cliente desea en el software y así poder
medir el cumplimiento que tienen los softwares de las
características de calidad, ayudando a los directivos a la toma
de decisiones y a mejorar la calidad del proceso de pruebas y
del producto final.
[2] P. Pressman, «METRICAS,» de INGENIERÍA DEL SOFTWARE. UN ENFOQUE
PRÁCTICO, BUENOS AIRES, MC GRALL HILL, 2010, pp. 50-52.
[3] gonzalez_d_h, «catarina.udlap.m,» 1 3 2018. [En línea]. Available:
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo4.pdf.
[4] D. barrietos, «blog.desafiolatam.com,» 11 10 2011. [En línea]. Available:
https://blog.desafiolatam.com/metricas-de-calidad-de-software/. [Último acceso: 24
04 2022].

VIII. CONCLUSION

P ara concluir podemos decir que la calidad de software la

encontramos en una relación que el cliente tiene como son las
expectativas y cualidades, así para poder producir un software
de calidad se debe cumplir con todas las expectativas de
nuestros clientes dicho lo anterior debemos cumplir este
objetivo por cuanto la ingeniera del software nos brinda ayudas
y soportes.

En cuanto al análisis de las métricas debemos de revisar los

requerimientos para poder encontrar los errores, ahora bien, si
un equipo de software coloca énfasis en la calidad podemos
reducir las repeticiones y eso nos da como resultado que
podemos lograr unos costos más rebajados y así podremos
llegar al mercado más rápidamente.

También vimos los diferentes tipos de métricas como lo son:

métricas basadas en funciones, métrica para la calidad de la
especificación, métrica de diseño en el componente y métrica
de diseño de interfaz de usuarios.

Las razones para medir un producto es una disciplina

cuantitativa como se observó anteriormente; como nos
podemos dar de cuenta la relación existente entre el
establecimiento de métricas y la calidad del producto final es
que se pueden aplicar a un producto de desarrollo de software
la cual nos brinda mayor información y permite a los
desarrolladores mejorar el proceso y los productos.
 5

Actividad sopa de letras fecha 19 de abril

Sopa de Ingrid E

Activada de Joan R.