Ingeniería de Software II

Unidad no. 4

Tema: Métricas Técnicas para Sistemas

Orientados a Objetos

Alumno: Jose Anelfi Lopez Fermín

Matricula 100108750
 Indice
Introducción ........................................................................................................................................ 1
Visión General de los Factores que Afectan a la Calidad .................................................................... 2
¿Porque se aplican las métricas al Software? ..................................................................................... 2
Medida de la calidad ........................................................................................................................... 2
Corrección: ...................................................................................................................................... 2
Facilidad de mantenimiento. .......................................................................................................... 2
Integridad. ....................................................................................................................................... 3
Facilidad de uso. .............................................................................................................................. 3
Calidad del Software. .......................................................................................................................... 3
Factores de calidad de McCall ............................................................................................................. 4
Eficacia de la Eliminación de Defectos ................................................................................................ 5
Métrica para el esquema de puntuación: ........................................................................................... 6
Facilidad de auditoría: ..................................................................................................................... 6
Exactitud:......................................................................................................................................... 6
Estandarización de comunicaciones: .............................................................................................. 6
Compleción: .................................................................................................................................... 6
Concisión: ........................................................................................................................................ 6
Consistencia: ................................................................................................................................... 6
Estandarización de datos: ............................................................................................................... 6
Tolerancia al error: .......................................................................................................................... 6
Eficiencia de ejecución: ................................................................................................................... 6
Capacidad de expansión:................................................................................................................. 6
Generalidad: .................................................................................................................................... 6
Independencia del hardware: ......................................................................................................... 6
Instrumentación: ............................................................................................................................. 6
Modularidad: ................................................................................................................................... 6
Operatividad:................................................................................................................................... 6
Seguridad: ....................................................................................................................................... 6
Auto documentación:...................................................................................................................... 7
Simplicidad: ..................................................................................................................................... 7
Independencia del sistema de software: ........................................................................................ 7
Trazabilidad: .................................................................................................................................... 7
 Formación: ...................................................................................................................................... 7
Métricas del modelo de análisis .......................................................................................................... 7
Métricas basadas en la función ........................................................................................................... 7
La métrica Bang ................................................................................................................................... 8
Métricas de la Calidad de Especificación ............................................................................................ 9
Métrica del modelo del diseño ......................................................................................................... 10
Métricas de cohesión. ....................................................................................................................... 10
Métricas de acoplamiento ................................................................................................................ 10
Métricas de complejidad. .................................................................................................................. 11
Métricas de diseño de interfaz.......................................................................................................... 11
Métricas de código fuente ................................................................................................................ 12
Métricas para pruebas ...................................................................................................................... 12
Métricas de mantenimiento.............................................................................................................. 13
Conclucion ......................................................................................................................................... 14
Bibliografía ........................................................................................................................................ 15
Introducción

El objetivo primordial de la ingeniería del software es producir un sistema, aplicación o

producto de alta calidad. Para lograr este objetivo, los ingenieros de software deben emplear
métodos efectivos junto con herramientas modernas dentro del contexto de un proceso
maduro de desarrollo del software.
Al mismo tiempo, un buen ingeniero del software y buenos administradores de la ingeniería
del software deben medir si la alta calidad se va a llevar a cabo. A continuación, se verá un
conjunto de métricas del software que pueden emplearse a la valoración cuantitativa de la
calidad de software El punto de vista de ¿Qué es calidad? Es diverso, y por lo tanto existen
distintas respuestas, tales como se muestra a continuación:
El American Heritage Dictionary define la calidad como “Una característica o atributo de
algo.” La definición estándar de calidad en ISO-8402 es “La totalidad de rasgos y
características de un producto, proceso o servicio que sostiene la habilidad de satisfacer
estados o necesidades implícitas”. “Concordar explícitamente al estado funcional y a los
requerimientos del funcionamiento, explícitamente a los estándares de documentación de
61 desarrollo, e implícitamente características que son expectativas de todos los
desarrolladores profesionales de software”. La calidad de un sistema, aplicación o producto
es tan buena como los requisitos que detallan el problema, el diseño que modela la solución,
el código que transfiere a un programa ejecutable y las pruebas que ejercita el software para
detectar errores.
Un buen ingeniero del software emplea mediciones que evalúan la calidad del análisis y los
modelos de diseño, así como el código fuente y los casos de prueba que se han establecido al
aplicar la ingeniería del software. Para obtener esta evaluación de calidad, el ingeniero debe
utilizar medidas técnicas, que evalúan la calidad con objetividad, no con subjetividad.
Asimismo, un buen administrador de proyectos debe evaluar la calidad objetivamente y no
subjetivamente. A medida que el proyecto progresa el administrador del proyecto siempre
debe valorar la calidad. Aunque se pueden recopilar muchas medidas de calidad, el primer
objetivo en el proyecto es medir errores y defectos. Las métricas que provienen de estas
medidas proporcionan una indicación de la efectividad de las actividades de control y de la
garantía de calidad en grupos o en particulares.
Por ejemplo, los errores detectados por hora de revisión y los errores detectados por hora de
prueba suministran una visión profunda de la eficacia de cada una de las actividades
envueltas en la métrica. Así los datos de errores se pueden utilizar también para calcular la
eficiencia de eliminación de defectos en cada una de las actividades del marco de trabajo del
proceso.

1
Visión General de los Factores que Afectan a la Calidad

En primer lugar el marco de trabajo proporciona al administrador identificar en el proyecto

lo que considera importante, como: facilidad de mantenimiento y transportabilidad, atributos
del software, además de su corrección y rendimiento funcional teniendo un impacto
significativo en el costo del ciclo de vida. En segundo lugar, proporciona un medio de evaluar
cuantitativamente el progreso en el desarrollo de software teniendo relación con los objetivos
de calidad establecidos. En tercer lugar, proporciona más interacción del personal de calidad,
en el esfuerzo de desarrollo. Por último, el personal de calidad puede utilizar indicaciones de
calidad que se establecieron como ”pobres” para ayudar a identificar estándares “mejores”
para verificar en el futuro. Es importante destacar que casi todos los aspectos del cálculo han
sufrido cambios radicales con el paso de los años desde que McCall y Cavano hicieron su
trabajo, teniendo gran influencia, en 1978. Pero los atributos que proporcionan una indicación
de la calidad del software siguen siendo los mismos.

¿Porque se aplican las métricas al Software?

Se aplica las métricas para valorar la calidad de los productos de ingeniería o los sistemas
que se construyen esto Proporciona una manera sistemática de valorar la calidad basándose
en un conjunto de reglas claramente definidas.
Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales.

Medida de la calidad
Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de
mantenimiento, integridad y facilidad de uso suministran indicadores útiles para el equipo
del proyecto

Corrección: A un programa le corresponde operar correctamente o suministrará poco valor

a sus usuarios. La corrección es el grado en el que el software lleva a cabo una función
requerida. La medida más común de corrección son los defectos por KLDC, en donde un
defecto se define como una falla verificada de conformidad con los requisitos.

Facilidad de mantenimiento. El mantenimiento del software cuenta con más esfuerzo que
cualquier otra actividad de ingeniería del software. La facilidad de mantenimiento es la
habilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar
si su entorno cambia o optimizar si el cliente desea un cambio de requisitos.

No hay forma de medir directamente la facilidad de 64 mantenimiento; por consiguiente, se

deben utilizar medidas indirectas. Una métrica orientada al tiempo simple es el tiempo medio
de cambio (TMC), es decir, el tiempo que se tarda en analizar la petición de cambio, en
diseñar una modificación apropiada, en efectuar el cambio, en probarlo y en distribuir el
cambio a todos los usuarios.

2
En promedio, los programas que son más fáciles de mantener tendrán un TMC más bajo (para
tipos equivalentes de cambios) que los programas que son más difíciles de mantener. Hitachi
ha empleado una métrica orientada al costo (precio) para la capacidad de mantenimiento,
llamada “desperdicios”. El costo estará en corregir defectos hallados después de haber
distribuido el software a sus usuarios finales. Cuando la proporción de desperdicios en el
costo global del proyecto se simboliza como una función del tiempo, es aquí donde el
administrador logra determinar si la facilidad de mantenimiento del software producido por
una organización de desarrollo está mejorando y asimismo se pueden emprender acciones a
partir de las conclusiones obtenidas de esa información.

Integridad. En esta época de intrusos informáticos y de virus, la integridad del software ha

llegado a tener mucha importancia. Este atributo mide la habilidad de un sistema para
soportar ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se
puede ejecutar en cualquiera de los tres componentes del software, ya sea en los programas,
datos o documentos. Para medir la integridad, se tienen que definir dos atributos adicionales:
amenaza y seguridad. La amenaza es la probabilidad (que se logra evaluar o concluir de la
evidencia empírica) de que un ataque de un tipo establecido ocurra en un tiempo establecido.
La seguridad es la probabilidad (que se puede estimar o 65 deducir de la evidencia empírica)
de que se pueda repeler el ataque de un tipo establecido, en donde la integridad del sistema
se puede especificar como: integridad = Ó[1- amenaza x (1- seguridad)]
donde se suman la amenaza y la seguridad para cada tipo de ataque.

Facilidad de uso. El calificativo “amigable con el usuario” se ha transformado

universalmente en disputas sobre productos de software. Si un programa no es “amigable con
el usuario”, prácticamente está próximo al fracaso, incluso aunque las funciones que realice
sean valiosas. La facilidad de uso es un intento de cuantificar “lo amigable que pude ser con
el usuario” y se consigue medir en función de cuatro características:
(1) destreza intelectual y/o física solicitada para aprender el sistema.
(2) el tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del sistema.

(3) aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida
cuando alguien emplea el sistema moderadamente y eficientemente.

(4) valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los

usuarios hacia el sistema. Los cuatro factores anteriores son sólo un ejemplo de todos los que
se han propuesto como medidas de la calidad del software.

Calidad del Software. Los requisitos del Software son la base de las medidas de calidad.
La falta de concordancia con los requisitos es una falta de calidad.

3
Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la
manera en que se hace la ingeniería del Software. Si no se siguen los criterios, habrá
seguramente poca calidad.

Existe un conjunto de requisitos implícitos que ha menudo no se nombran. Si el software

cumple con sus requisitos explícitos pero falla en los implícitos , la calidad del software no
será fiable.

Factores de calidad de McCall. Los factores que afectan la calidad se pueden

categorizar en:

 Factores que se pueden medir directamente, como por ejemplo los defectos por punto
de función.
 Factores que se pueden medir sólo indirectamente, como por ejemplo la facilidad de
uso o mantenimiento.

4
McCall y sus colegas plantearon una categorización de factores que afectan a la calidad de
software, que se muestran en la figura anterior en donde se centralizan con tres aspectos
importantes de un producto de software: sus características operativas, su capacidad de
cambio y su adaptabilidad a nuevos entornos. Refiriéndose a los factores de la figura , McCall
proporciona las siguientes descripciones:

- Corrección: Hasta dónde satisface un programa su especificación y consigue los objetivos

de la misión del cliente.
- Fiabilidad: Hasta dónde puede quedarse un programa que lleve a cabo su función
pretendida con la exactitud solicitada. Cabe hacer notar que se han propuesto otras
definiciones de fiabilidad más completas.

Eficacia de la Eliminación de Defectos

Una métrica de la calidad que proporciona beneficios tanto a nivel del proyecto como del
proceso, es la eficacia de la eliminación de defectos (EED) En particular el EED es una
medida de la habilidad de filtrar las actividades de la 68 garantía de calidad y de control al
aplicarse a todas las actividades del marco de trabajo del proceso. Cuando se toma en
consideración globalmente para un proyecto, EED se define de la forma siguiente:
EED = E / (E + D)
donde E= es el número de errores encontrados antes de la entrega del software al usuario
final y D= es el número de defectos encontrados después de la entrega.
El valor ideal de EED es 1, donde simbolizando que no se han encontrado defectos en el
software. De forma realista, D será mayor que cero, pero el valor de EED todavía se puede
aproximar a 1 cuando E aumenta.
En consecuencia cuando E aumenta es probable que el valor final de D disminuya (los errores
se filtran antes de que se conviertan en defectos) Si se utiliza como una métrica que suministra
un indicador de la destreza de filtrar las actividades de la garantía de la calidad y el control,
el EED alienta a que el equipo del proyecto de software instituya técnicas para encontrar los
errores posibles antes de su entrega. Del mismo modo el EED se puede manipular dentro del
proyecto, para evaluar la habilidad de un equipo en encontrar errores antes de que pasen a la
siguiente actividad, estructura o tarea de ingeniería del software. Por ejemplo, la tarea de
análisis de requerimientos produce un modelo de análisis qué se puede inspeccionar para
encontrar y corregir errores. Esos errores que no se encuentren durante la revisión del modelo
de análisis se pasan a la tareas de diseño (en 69 donde se puede encontrar o no) Cuando se
utilizan en este contexto, el EED se vuelve a definir como: EED = Ei / ( Ei + Ei+1) (4.5)
Donde Ei = es el número de errores encontrados durante la actividad iesima de: ingeniería
del software i, el Ei + 1 = es el número de errores encontrado durante la actividad de
ingeniería del software (i + 1) que se puede seguir para llegar a errores que no se detectaron
en la actividad i. Un objetivo de calidad de un equipo de ingeniería de software es alcanzar
un EED que se aproxime a 1, esto es, los errores se deberían filtrar antes de pasarse a la

5
actividad siguiente. Esto también puede ser utilizado dentro del proyecto para evaluar la
habilidad de un equipo, esto con el objetivo de encontrar deficiencias que harán que se atrase
el proyecto. Existen varias métricas de calidad, pero las más importantes y que engloban a
las demás, son sólo cuatro: corrección, facilidad de mantenimiento, integridad y facilidad de
uso, se explicaron en la sección anterior.

Métrica para el esquema de puntuación:

Facilidad de auditoría: la facilidad con la que se puede comprobar el cumplimiento de los
estándares.
Exactitud: la exactitud de lo cálculos y el control.
Estandarización de comunicaciones: el grado de empleo de estándares de interfaces,
protocolos y anchos de banda.
Compleción: el grado con que se ha logrado la implementación total de una función.
Concisión: Lo compacto que es el programa en términos de líneas de código
Consistencia: El empleo de un diseño uniforme y de técnicas de documentación a lo largo
del proyecto de desarrollo del software.

Estandarización de datos: El empleo de estructuras y tipos de datos estándares a lo largo

del programa.
Tolerancia al error: el daño causado cuando un programa encuentra un error.
Eficiencia de ejecución: El rendimiento del funcionamiento de un programa.

Capacidad de expansión: El grado con que se pueden ampliar el diseño arquitectónico, de

datos o procedimental.
Generalidad: la amplitud de aplicación potencial de los componentes del programa.

Independencia del hardware: El grado con que se desacopla el software del hardware
donde opera.

Instrumentación: El grado con el que el programa vigila su propio funcionamiento e

identifica los errores que ocurren.
Modularidad: La independencia funcional de componentes de programa.
Operatividad: La facilidad de operación de un programa.

Seguridad: La disponibilidad de mecanismos que controlan o protegen los programas y los

datos.

6
Auto documentación: El grado en que el código fuente proporciona documentación
significativa.
Simplicidad: El grado de facilidad con que se puede entender un programa.
Independencia del sistema de software: El grado de independencia de programa respecto
a las características del lenguaje de programación no estándar, características del sistema
operativo y otras restricciones del entorno.

Trazabilidad: La capacidad de seguir una representación del diseño o un componente real

del programa hasta los requisitos.
Formación: El grado en que ayuda el software a manejar el sistema a los nuevos usuarios.

Métricas del modelo de análisis

En esta fase se obtendrán los requisitos y se establecerá el fundamento para el diseño. Y es
por eso que se desea una visión interna a la calidad del modelo de análisis. Sin embargo hay
pocas métricas de análisis y especificación, se sabe que es posible adaptar métricas obtenidas
para la aplicación de un proyecto, en donde las métricas examinan el modelo de análisis con
el fin de predecir el tamaño del sistema resultante, en donde resulte probable que el tamaño
y la complejidad del diseño estén directamente relacionadas. Es por eso que se verán en las
siguientes secciones las métricas orientadas a la función, la métrica bang y las métricas de la
calidad de especificación

Métricas basadas en la función

La métrica de punto de función (PF) se puede usar como medio para predecir el tamaño de
un sistema que se va a obtener de un modelo de análisis. Para instruir el empleo de la métrica
PF, se considerará una
sencilla representación
del modelo de análisis
mostrada por Pressman
en la figura. En donde se
representa un diagrama
de flujo de datos, de una
función de una aplicación
de software llamada
Hogar Seguro. La
función administra la
interacción con el
usurario, aceptando una
contraseña de usuario
para activar/ desactivar el

7
sistema y permitiendo consultas sobre el estado de las zonas de seguridad y varios censores
de seguridad. La función muestra una serie de mensajes de petición y envía señales
apropiadas de control a varios componentes del sistema de seguridad. El diagrama de flujo
de datos se evalúa para determinar las medidas clave necesarias para el cálculo de al métrica
de PF.: - número de entradas de usuario - número de salidas de usuario - número de consultas
del usuario - número de archivos - número de interfaces externas

La métrica Bang
Puede emplearse para desarrollar una indicación del tamaño del software a implementar
como consecuencia del modelo de análisis. Desarrollada por Tom DeMarco [Ejiogo ‘91], la
métrica bang es “ una indicación, independiente de la implementación, del tamaño del
sistema”.

Para calcular la métrica bang, el desarrollador de software debe evaluar primero un conjunto
de primitivas (elementos del modelo de análisis que no se subdividen más en el nivel de
análisis) Las primitivas se determinan evaluando el modelo de análisis y desarrollando
cuentas para los siguientes elementos: - Primitivas funcionales (Pfu) Transformaciones
(burbujas) que aparecen en el nivel inferior de un diagrama de flujo de datos. - Elementos de
datos (ED) Los atributos de un objeto de datos, los elementos de datos no compuestos y
aparecen en el diccionario de datos. - Objetos (OB) Objetos de datos. 79 - Relaciones (RE)
Las conexiones entre objetos de datos. - Transiciones (TR) El número de transacciones de
estado en el diagrama de transición de estado. Además de las seis primitivas nombradas
arriba, se determinan medidas adicionales para: - Primitivas modificadas de función manual
(PMFu) Funciones que caen fuera del límite del sistema y que deben modificarse para
acomodarse al nuevo sistema.

- Elementos de datos de entrada (EDE) Aquellos elementos de datos que se introducen en el

sistema.

- Elementos de datos de salida (EDS) Aquellos elementos de datos que se sacan en el sistema.
- Elementos de datos retenidos (EDR) Aquellos elementos de datos que son retenidos
(almacenados) por el sistema.

8
- Muestras (tokens) de datos (TCi) Las muestras de datos (elementos de datos que no se
subdividen dentro de una primitiva funcional) que existen en el l’imite de la i-ésima primitiva
funcional (evaluada para cada primitiva).

- Conexiones de
relación (Rei)
Las relaciones
que conectan el
i-ésimo objeto
en el modelo de
datos con otros
objetos.

DeMarco
sugiere que la
mayoría del software se puede asignar a uno de los dos dominios siguientes, dominio de
función o dominio de datos, dependiendo de la relación RE/PFu. Las aplicaciones de dominio
de función (encontrados comúnmente en aplicaciones de ingeniería y científicas) hacen 80
hincapié en la transformación de datos y no poseen generalmente estructuras de datos c
omplejas

Métricas de la Calidad de Especificación

Existe una lista de características para poder valorar la calidad del modelo de análisis y la
correspondiente especificación de requisitos: Especificidad, corrección, compleción,
comprensión, capacidad de verificación, consistencia externa e interna, capacidad de logro,
concisión, traza habilidad, capacidad de modificación, exactitud y capacidad de reutilización.
Aunque muchas de las características anteriores pueden ser de naturaleza cuantitativa, Davis
sugiere que todas puedan representarse usando una o más métricas.
Por ejemplo asumimos que hay ni requisitos en una especificación, tal como
ni = nf + nnf
Donde nf es el numero de requisitos funcionales y nnf es el número de requisitos no
funcionales ( por ejemplo, rendimiento). Para determinar la especificidad de los requisitos,
Davis sugiere una métrica basada en la consistencia de la interpretación de los revisores para
cada requisito: Q1 = nui / nr Donde nui es el numero de requisitos para los que todos los
revisores tuvieron interpretaciones idénticas. Cuanto más cerca de uno este el valor de Q1
menor será la ambigüedad de la especificación. La compleción de los requisitos funcionales
pueden terminarse calculando la relación Q2 = nu / (ni * ns) 82 donde nu es el número de
requisitos de función únicos, ni es el número de entradas (estímulos) definidos o implicados

9
por la especificación y ns es el número de estados especificados. La relación Q2 mide
porcentaje de funciones necesarias que se han especificado para un sistema, sin embargo, no
trata los requisitos no funciónales. Para incorporarlos a una métrica global completa,
debemos considerar el grado de validación de los requisitos: Q3 = nc / (nc + nnv) donde nc
es el número de requisitos que se han validados como correctos y nnv el número de requisitos
que no se han validado todavía

Métrica del modelo del diseño

Las métricas para software, como otras métricas, no son perfectas; muchos expertos
argumentan que se necesita más experimentación hasta que se puedan emplear bien las
métricas de diseño. Sin embargo el diseño sin medición es una alternativa inaceptable. A
continuación se mostraran algunas de las métricas de diseño más comunes. Aunque ninguna
es perfecta, pueden proporcionarle al diseñador una mejor visión interna y así el diseño
evolucionara a un mejor nivel de calidad

Métricas de cohesión.
Bieman y Ott [Hamdi ‘99] definen una colección de métricas que proporcionan una
indicación de la cohesión de un módulo. Las métricas se definen con cinco conceptos y
medidas: - Porción de datos. Dicho simplemente, una porción de datos es una marcha atrás a
través de un módulo que busca valores de datos que afectan a la localización del módulo en
el que empezó la marcha atrás. Debería resaltarse que se pueden definir tanto porciones de
programas (que se centran en enunciados y condiciones) como porciones de datos. - Símbolos
léxicos (tokens) de datos. Las variables definidas para un módulo pueden definirse como
señales de datos para el módulo.

- Señales de unión. El conjunto de señales de datos que se encuentran en uno o más porciones
de datos. 89
- Señales de super-unión.
-Las señales de datos comunes a todas las porciones de datos de un módulo.

- Cohesión. La cohesión relativa de una señal de unión es directamente proporcional al

número de porciones de datos que liga. Bieman y Ott desarrollaron métricas para cohesiones
funcionales fuertes (CFF), cohesiones funcionales débiles (CFD), y pegajosidad (el grado
relativo con el que las señales de unión ligan juntas porciones de datos) Estas métricas se
pueden interpretar de la siguiente manera [Hamdi’99] .

Métricas de acoplamiento. El acoplamiento de módulo proporciona una indicación de

la “conectividad” de un módulo con otros módulos, datos globales y entorno exterior. Dhama
10
[Fenton ‘91] ha propuesto una métrica para el acoplamiento del módulo que combina el
acoplamiento de flujo de datos y de control: acoplamiento global y acoplamiento de entorno.
Las medidas necesarias para calcular el acoplamiento de módulo se definen en términos de
cada uno de los tres tipos de acoplamiento apuntados anteriormente.

Métricas de complejidad.
Se pueden calcular una variedad de métricas del software para determinar la complejidad del
flujo de control del programa. Muchas de éstas se basan en una representación denominada
grafo de flujo, un grafo es una representación compuesta de nodos y enlaces (también
denominados filos) Cuando se dirigen los enlaces (aristas), el grafo de flujo es un grafo
dirigido. McCabe identifica un número importante de usos para las métricas de complejidad,
donde pueden emplearse para predecir información sobre la fiabilidad y mantenimiento de
sistemas software, también realimentan la información durante el proyecto de software para
ayudar a controlar la actividad de 93 diseño, en las pruebas y mantenimiento, proporcionan
información sobre los módulos software para ayudar a resaltar las áreas de inestabilidad. La
métrica de complejidad más ampliamente usada (y debatida) para el software es la
complejidad ciclomática, originalmente desarrollada por Thomas McCabe. La métrica de
McCabe proporciona una medida cuantitativa para probar la dificultad y una indicación de
la fiabilidad última. Estudios experimentales indican una fuerte correlación entre la métrica
de McCabe y el número de errores que existen en el código fuente, así como el tiempo
requerido para encontrar y corregir dichos errores. McCabe también defiende que la
complejidad ciclomática puede emplearse para proporcionar una indicación cuantitativa del
tamaño máximo del módulo. Recogiendo datos de varios proyectos de programación reales,
ha averiguado que una complejidad ciclomática de 10 parece ser el límite práctico superior
para el tamaño de un módulo, Cuando la complejidad ciclomática de los módulos excedían
ese valor, resultaba extremadamente difícil probar adecuadamente el módulo.

Métricas de diseño de interfaz

Aunque existe una significativa cantidad de literatura sobre el diseño de interfaces hombre-
máquina, se ha publicado relativamente poca información sobre métricas que proporcionen
una visión interna de la calidad y facilidad de empleo de la interfaz. 94 Sears sugiere la
conveniencia de la representación (CR) como una valiosa métrica de diseño para interfaces
hombre-máquina. Una IGU (Interfaz Gráfica de Usuario) típica usa entidades de
representación, iconos gráficos, texto, menús, ventanas y otras para ayudar al usuario a
completar tareas. Para realizar una tarea dada usando una IGU, el usuario debe moverse de
una entidad de representación a otra. Las posiciones absolutas y relativas de cada entidad de
representación, la frecuencia con que se utilizan y el “costo” de la transición de una entidad
de representación a la siguiente contribuirá a la conveniencia de la interfaz

11
Métricas de código fuente
La teoría de Halstead de la ciencia del software es ‘probablemente la mejor conocida y más
minuciosamente estudiada... medidas compuestas de la 96 complejidad (software)’.

 La ciencia software propuso las primeras ‘leyes’ analíticas para el software de

computadora.
 La ciencia del software asigna leyes cuantitativas al desarrollo del software de
computadora.
La teoría de Halstead se obtiene de un supuesto fundamental: ‘el cerebro humano sigue un
conjunto de reglas más rígido (en el desarrollo de algoritmos) de lo que se imagina...’. La
ciencia del software usa un conjunto de medidas primitivas que pueden obtenerse una vez
que se ha generado o estimado el código después de completar el diseño.

Estas medidas se listan a continuación. n1: el número de operadores diferentes que aparecen
en el programa n2: el número de operandos diferentes que aparecen en el programa

 N1: el número total de veces que aparece el operador

 N2: el número total de veces que aparece el operando
Halstead usa las medidas primitivas para desarrollar expresiones para la longitud global del
programa; volumen mínimo potencial para un algoritmo; el volumen real (número de bits
requeridos para especificar un programa); el nivel del programa (una medida de la
complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras
características tales como esfuerzo de desarrollo, tiempo de desarrollo e incluso el número
esperado de fallos en el software.

Métricas para pruebas

Aunque se ha escrito mucho sobre métricas del software para pruebas, la mayoría de las
métricas propuestas se concentran en el proceso de pruebas, no en las características técnicas
de las pruebas mismas. En general, los responsables de las pruebas deben fiarse del análisis,
diseño y código para que les guíen en el diseño y ejecución los casos de prueba Las métricas
basadas en la función pueden emplearse para predecir el esfuerzo global de las pruebas Se
pueden juntar y correlacionar varias características a nivel de proyecto (p ej.: esfuerzo y
tiempo las pruebas, errores descubiertos, número de casos de prueba producidos) de
proyectos anteriores con el número de Pf producidos por un equipo del proyecto. El equipo
puede después predecir los valores ‘esperados’ de estas características del proyecto actual.
La métrica bang puede proporcionar una indicación del número de casos de prueba necesarios
para examinar las medidas primitivas. El número de primitivas funcionales (Pfu), elementos
de datos, (ED), objetos (0B), relaciones (RE), estados (ES) y transiciones (TR) pueden
emplearse para predecir el número y tipos de pruebas de la caja negra y blanca del software
12
Por ejemplo, el número de pruebas asociadas con la interfaz hombre-máquina se puede
estimar examinando (1) el número de transiciones (TR) contenidas en la representación
estadotransición del IHM y evaluando las pruebas requeridas para ejecutar cada 99
transición, (2) el número de objetos de datos (0B) que se mueven a través de la interfaz y (3)
el número de elementos de datos que se introducen o salen. Las métricas de diseño de alto
nivel proporcionan información sobre facilidad o dificultad asociada con la prueba de
integración y la necesidad de software especializado de prueba (p. ej.: matrices y
controladores) La complejidad ciclomática (una métrica de diseño de componentes) se
encuentra en el núcleo de las pruebas de caminos básicos, un método de diseño de casos de
prueba. Además, la complejidad ciclomática puede usarse para elegir módulos como
candidatos para pruebas más profundas. Los módulos con gran complejidad ciclomática
tienen más probabilidad de tendencia a errores que los módulos con menor complejidad
ciclomática

Métricas de mantenimiento
Se han propuesto métricas diseñadas explícitamente para actividades de mantenimiento. El
estándar IEEE 982.1-1988 sugiere un índice de madurez del software (IMS) que proporciona
una indicación de la estabilidad de un 101 producto de software (basada en los cambios que
ocurren con cada versión del producto)

Se determina la siguiente información: Mr = número de módulos en la versión actual Fc =

número de módulos en la versión actual que se han cambiado Fa = número de módulos en la
versión actual que se han añadido Fd = número de módulos de la versión anterior que se han
borrado en la versión actual El índice de madurez del software se calcula de la siguiente
manera:
IMS = [Mr – (Fa + Fc + Fd)]/ Mr (4.39)
A medida que el IMS se aproxima a 1.0 el producto se empieza a estabilizar. El IMS puede
emplearse también como métrica para la planificación de las actividades de mantenimiento
del software. El tiempo medio para producir una versión de un producto software puede
correlacionarse con el IMS desarrollándose modelos empíricos para el mantenimiento.

13
Conclucion

Al terminar este informe he logrado comprender los procesos que pasa un software diseñado
con altos estándares de calidad, en mi resumen mostre algunos de las métricas utilizadas para
poder disenar en implementar software del mas alto nivel.
Cada una de estas métricas es tomada en cuenta en base al tamaño del proyecto que se haya
de desarrollar y su impacto en el uso dependerá de la finalidad con la que se apliquen dichas
métricas.

Dentro de las métricas tomamos en cuenta cada detalle, desde la idealización del proyecto
hasta los mantenimiento previstos que se le han de realizar a dicho software en su vida útil.

Es sorprendente que cada métrica resumida en este informe tiene formas y formulas para ser
aplicada en mi estudio recomiendo el análisis de cada una para determinar el uso que se les
darán alas mismas.

14
Bibliografía

 https://aulavirtual.uasd.edu.do/pluginfile.php/1787971/mod_resource/content/1/UNIDA
D_4/Metricas_Tecnicas_del_Software.pdf

 https://aulavirtual.uasd.edu.do/pluginfile.php/1787970/mod_resource/content/1/Metric
as_en_el_Desarrollo_de_Software.pdf

 https://calidaddesoftwaresite.wordpress.com/2016/07/05/metricas-de-calidad/

 https://sg.com.mx/content/view/471

15