INSTITUTO DE INFORMÁTICA Y TECOMUNICACIONES

UNIVERSIDAD NACIONAL JORGE BASADRE GROHOMANN

MÉTRICAS DEL SOFTWARE

REALIZADO POR: APAZA CUTIPA YESICA YANETH

CURSO: INGENIERIA DE SOFTWARE

DOCENTE: VANESSA NAQUIRA ACERO

Tacna-Perú

2018
 INDICE
INDICE.................................................................................................................................................. 1
Concepto ......................................................................................................................................... 2
Características ............................................................................................................................ 2
Clasificación ................................................................................................................................. 2
Según los criterios ......................................................................................................................... 2
Según el contexto ........................................................................................................................... 3
Métrica de diseño arquitectónico ...................................................................................... 3
Métrica de diseño a nivel de componentes .................................................................. 4
Control ........................................................................................................................................... 4
Dominio del problema................................................................................................................... 4
Infraestructura .............................................................................................................................. 4
Métrica de cohesión .................................................................................................................. 4
Métrica de Acoplamiento ...................................................................................................... 5
Métrica del diseño de interfaz ............................................................................................ 5
Métrica de código Fuente ....................................................................................................... 5
Métricas de Prueba................................................................................................................... 6
Métrica de mantenimiento .................................................................................................. 6
Métricas de calidad .................................................................................................................. 6
Corrección...................................................................................................................................... 7
Integridad....................................................................................................................................... 7
Amenaza ......................................................................................................................................... 7
Facilidad de mantenimiento ......................................................................................................... 7
Facilidad de uso ............................................................................................................................. 7
Factores que determinan la calidad del software .................................................... 7
Modelos conocidos .................................................................................................................... 8
Modelo de MCCALL (1977)......................................................................................................... 8
Modelo de FURPS (1987) ............................................................................................................. 8
Modelo de DROMEY (1996) ........................................................................................................ 8
Iso 9000 -ISO/IEC 9126 .............................................................................................................. 9
Métrica Bang ................................................................................................................................ 9
Primitivas funcionales ................................................................................................................... 9
Primitivas modificadas ................................................................................................................. 9
 MÉTRICAS DEL SOFTWARE

Concepto
Conjunto de medidas que dan a conocer o estimar el tamaño u otra característica de
un software o sistema de información para realizar comparativas, planificación de proyectos
de desarrollo.

Características
o Complejidad lógica,
o El grado de modularidad.
o Mide la estructura del sistema
o Simple y fácil de calcular
o Cuantificables, se basan en hechos, no en opiniones.
o Independientes, los recursos no deben poder ser alterados por los miembros que las apliquen
o utilicen.
o Explicable, debe documentarse información acerca de la métrica y de su uso.
o Precisas, debe de conocerse un nivel de tolerancia permitido cuando se mide
o Un mecanismo eficaz para la realimentación de calidad

Clasificación

o Directas
Incluyen el costo y esfuerzo aplicados, las incluyen el costo y esfuerzo aplicados, las líneas
de c neas de código (LDC) producidas, velocidad de digo (LDC) producidas, velocidad de
ejecución, el tamaño de memoria, y los defectos o de memoria, y los defectos observados
en determinado tiempo. Observados en determinado tiempo
o Indirectas
Se refieren a la funcionalidad, calidad, se refieren a la funcionalidad, calidad, complejidad,
eficiencia, fiabilidad, facilidad de complejidad, eficiencia, fiabilidad, facilidad de
mantenimiento, etc

Según los criterios

 Complejidad
Métricas que definen la medición de la complejidad: volumen, tamaño, anidaciones, y
configuración.
  Calidad
Métricas que definen la calidad del software: exactitud, estructuración o modularidad,
pruebas, mantenimiento.
 Competencia
Métricas que intentan valorar o medir las actividades de productividad de los
programadores con respecto a su certeza, rapidez, eficiencia y competencia
 Desempeño
Métricas que miden la conducta de módulos y sistemas de un software, bajo la
supervisión del SO o hardware.
 Estilizadas
Métricas de experimentación y de preferencia: estilo de código, convenciones,
limitaciones.

Según el contexto

 Métricas de proceso
‣ Se recopilan de todos los proyectos, y durante un largo periodo de tiempo
‣ Caracterizados por: Control y ejecución del proyecto.
‣Medición de tiempos de las fases.
 Métricas de proyecto

‣ Permiten evaluar el estado del proyecto.

‣ Permiten seguir la pista de los riesgos.
 Métricas de producto
‣ Se centran en las características del software y no en cómo fue producido
‣ También son productos los artefactos, documentos, modelos, y componentes
que conforman el software.
‣ Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad, y el
esfuerzo.

Métrica de diseño arquitectónico

Se centran en la arquitectura del programa y la eficiencia de los módulos. Son de caja negra

en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en

particular del sistema.

Card y Glas definen tres medidas de la complejidad del diseño del software:
 complejidad estructural,
 complejidad de datos
 complejidad del sistema.

Métrica de diseño a nivel de componentes

Define las estructuras de datos, los algoritmos, las características de la interfaz y los
mecanismos de comunicación asignados a cada componente de software. Esta fase permite
revisar si los detalles de diseño son correctos y consistentes con las representaciones iniciales
de diseño
Caja blanca: En el sentido de que requieren conocimiento del Trabajo interno del módulo en
cuestión. Las métricas de diseño de los componentes se pueden aplicar una vez que se ha
desarrollado un diseño procedimental. También se pueden retrasar hasta tener disponible el
código fuente.
Control
Coordina la invocación de todos los demás componentes del dominio del problema.

Dominio del problema

Implementa una función parcial o completa requerida por el cliente.

Infraestructura
Responsable de funciones que soportan el procesamiento requerido en el dominio del problema.

Métrica de cohesión

Bieman y Ott 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 de
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.

 Muestras (tokens) de datos. Las variables definidas para un módulo pueden

definirse como muestras de datos para el módulo.

 Señales de unión. El conjunto de muestras de datos que se encuentran en una o más

porciones de datos.
  Señales de superunión. La muestras de datos comunes a todas las porciones de datos
de un módulo.

 Pegajosidad. La pegajosidad relativa de una muestra de unión es directamente

proporcional al número de porciones de datos que liga.

Métrica de Acoplamiento
Es una medida cualitativa del grado al que las clases se conectan entre sí a medida que las
clases se vuelven más interdependientes el acoplamiento aumenta El acoplamiento de
módulo proporciona una indicación de la conectividad» de un módulo con otros módulos,
datos globales y el entorno exterior.
 Acoplamiento común  Acoplamiento de llamada a rutina
 Acoplamiento del contenido  Acoplamiento de uso de tipo
 Acoplamiento de control  Acoplamiento de incursión o
 Acoplamiento de estampa aportación
 Acoplamiento de dato  Acoplamiento externo

Métrica del diseño de interfaz

Métricas que proporcionen un visón interna de la calidad y facilidad de empleo de la interfaz.

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 «coste» de la transición de una
entidad de representación a la siguiente contribuirán a la conveniencia de la interfaz.

Métrica de código Fuente

 Se tendrá en cuenta:
- El número de operadores diferentes que aparecen en el sistema.
- El número de operando diferentes que aparecen en el programa.
- El número total de veces que aparece el operador.
- El número total de veces que aparece el operando.
 De allí se calcula:
- Longitud de programa.
- Volumen de información (en bits) necesarios para escribir un programa.
- Nivel del programa (complejidad del sw).
- Tiempo de desarrollo.
- Costo de desarrollo.
- Numero esperado de fallos en el sw.

Métricas de Prueba
Ayudan a diseñar casos de prueba efectivos y evaluar pruebas.
A medida que avanzan las pruebas, hay métricas que indican la completitud de las mismas.

 Amplitud de las pruebas (cuantos requisitos se han probado).

 Profundidad de las pruebas (% de los caminos básicos probados).
 Perfiles de fallo (para dar prioridad y categorizar los errores encontrados).

Métrica de mantenimiento
Pueden utilizarse todas las métricas anteriores.
El estándar IEEE982.1-1998, sugiere un índice de madurez, que proporcionan una
indicación de la estabilidad del sw (basadas en los cambios constantes).
Se tendrá en cuenta:
 Numero de módulos en la versión actual.
 Numero de módulos en la versión actual que han cambiado.
 Numero de módulos en la versión actual que se han añadido.
 Numero de módulos en la versión anterior que se han borrado.

Métricas de calidad
Permiten monitorizar un producto para determinar su nivel de calidad aunque, el
seguimiento que este tipo de medidas permiten llevar a cabo brinda la oportunidad de
conocer muchas más cosas de una solución.
 Proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y
explícitos del cliente:
Corrección
Es el grado en el que el software lleva a cabo su función requerida
Integridad
Se mide la capacidad del sistema a resistir ataques contra su seguridad
Amenaza
Probabilidades de que un ataque ocurra en cierto tiempo Seguridad: prob de repeler el
ataque Integridad = ∑ [ (1-amenaza)*(1-seguridad) ]
Facilidad de mantenimiento
Facilidad de corregir, adaptar, mejorar

Facilidad de uso
Mide lo “amigable del software” + habilidad requerida para aprender el sistema +
tiempo requerido para llegar a ser eficiente en el uso del sistema + valoración subjetiva
de la disposición de los usuarios al sistema

Factores que determinan la calidad del software

Son muchos pero sin lugar a duda los más importantes son:

 Operaciones del Producto  Facilidad de Uso

 Corrección  Transición de Producto
 Fiabilidad  Portabilidad
 Eficiencia  Reusabilidad
 Integridad  Interoperabilidad
Modelos conocidos

Modelo de MCCALL (1977)

Describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre

factores de calidad, en base a criterios
 Los factores de calidad se concentran en tres aspectos importantes de un producto
de software: características operativas, capacidad de cambios y adaptabilidad a
nuevos entornos.
 Identifica una serie de criterios, tales como rastreabilidad, simplicidad, capacidad
de expansión, etc.
 Las métricas desarrolladas están relacionadas con los factores de calidad y la
relación que se establece se mide en función del grado de cumplimiento de los
criterios.

Modelo de FURPS (1987)

Modelo desarrollado por Hewlett-Packard (HP) en 1987, desarrollando un conjunto de

factores de calidad de software y sus respectivos atributos.
 Funcionalidad, usabilidad confiabilidad, desempeño (Performance) y capacidad
de soporte.
 Basado en el modelo de MCCALL.
 Se utilizan para establecer métricas de la calidad para todas las actividades del
proceso de desarrollo de un software, inclusive de un sistema de información
Modelo de DROMEY (1996)

Resalta el hecho de que la calidad del producto es altamente determinada por los
componentes del mismo (incluyendo documentos de requerimientos, guías de usuarios,
diseños, y código)
Sugiere el uso de cuatro categorías que implican propiedades de calidad, que son:
 correctitud
 internas
 contextuales
 descriptivas.
Iso 9000 -ISO/IEC 9126

ISO es reconocida mundialmente como el organismo certificador de calidad por

excelencia, y días bajo el estándar 9126 que define los siguientes atributos claves de la
calidad del software:
 Funcionalidad: satisface necesidades
 Confiabilidad: cantidad de tiempo disponible
 Usabilidad: grado de facilidad de uso.
 Eficiencia: grado en que optimiza los recurso de computo
 Facilidad de mantenimiento: facilidad de corregir errores.
 Portabilidad: facilidad de cambiar de entorno.
Al igual que en otros casos los atributos definidos por la ISO 9126 son medidas indirectas
y una excelente guía para determinar la calidad del software.

Métrica Bang
Utilizada para medir el tamaño del sistema a construir.
Se calcula el número de primitivas:
Primitivas funcionales
Son transformaciones (burbujas) que aparecen en el nivel inferior de un diagrama de
flujo de datos
 Elementos de datos: los atributos de un objeto de datos
 Objetos: objeto de datos (entidad)
 Relaciones: las conexiones entre objetos de datos
 Estados: el número de estados observables para el usuario en el diagrama de
transición de estados
 Transiciones: el número de transiciones de estado en el diagrama de transición
de estados.
Primitivas modificadas
(Funciones externas adoptadas), ED
 Entrada,
 Salida
 Grabados.