Este documento presenta diferentes métricas para evaluar la calidad de software orientado a objetos y proyectos web. Describe métricas relacionadas con el tamaño de clases, herencia, valores internos y externos de clases. También cubre métricas para casos de uso, proyectos web, y calidad general de software como corrección, facilidad de mantenimiento e integridad. El objetivo es comprender y mejorar la calidad a través de la medición.

1. PROGRAMANACIONAL DE FORMACIÓN
INGENIERÍAEN INFORMÁTICA
GESTIÓN DE PROYECTOS INFORMÁTICOS
Estudiante:
T.S.U Durán Marielis V - 20.348.663
Sección:
IIN4311 - PNFI
Profesor:
Guerrero Luis.
Barquisimeto, Mayo de 2016

2. Métricas Orientadas a Objeto
9.3.- Métricas orientadas a objeto (Lorenz y Kidd)
Cuando se hace referencia a las Métricas Orientadas a Objeto, es importante
resaltar sus objetivos principales; los cuales son los mismos que los existentes
para las métricas surgidas para el software estructurado, tales como:
 Comprender mejor la calidad del producto
 Estimar la efectividad del proceso
 Mejorar la calidad del trabajo realizado en el nivel del proyecto.
Además no proporcionan suficiente granularidad para la planificación y los
ajustes de esfuerzo. Las siguientes son métricas sugeridas para proyectos OO:
 Número de guiones de escenario
 Número de clases clave
 Número de clases de apoyo
 Número promedio de clases de apoyo por clase clave
 Número de subsistemas.
Métricas propuestas por Lorenz y Kidd
En el libro de métricas realizado por Lorenz y Kidd 0.0, dividen las métricas
basadas en clases en cuatro categorías: tamaño, herencia, valores internos y
valores externos.
 Las métricas orientadas a tamaños para una clase 00 se centran en
cálculos de atributos y de operaciones para una clase individual, y
promedian los valores para el sistema 00 en su totalidad.
 Las métricas basadas en herencia se centran en la forma en que se
reutilizan las operaciones a lo largo y ancho de la jerarquía de clases.
 Las métricas para valores internos de clase examinan la cohesión y
asuntos relacionados con el código.
 Las métricas orientadas a valores externos examinan el acoplamiento y
la reutilización.

3. Tamaño de Clase (TC).
El tamaño general de una clase se puede determinar empleando las medidas
siguientes:
 El número total de operaciones (tanto operaciones heredadas como
privadas de la instancia) que están encapsuladas dentro de la clase.
 El número de atributos (tanto atributos heredados como atributos privados
de la Instancia) que están encapsulados en la clase.
Si existen valores grandes de TC éstos mostrarán que una clase puede tener
demasiada responsabilidad, lo cual reducirá la reutilizabilidad de la clase y
complicará la implementación y la comprobación, por otra parte cuanto menor sea
el valor medio para el tamaño, más probable es que las clases existentes dentro
del sistema se puedan reutilizar ampliamente.
Número de Operaciones Invalidadas por unas subclases (NOI).
Existen casos en que una subclase sustituye una operación heredada de su
superclase por una versión especializada para su propio uso, ya esto se le
denomina invalidación. Los grandes valores de NOI suelen indicar un problema de
diseño ya que si
NOI es elevado, entonces el diseñador ha violado la abstracción implicada por la
superclase. Esto da lugar a una jerarquía de clases débil, y a un software 00 que
pueda resultar difícil de comprobar y modificar.
Índice de Especialización (IE).
El índice de especialización proporciona una indicación aproximada del grado
de especialización de cada una de las subclases existentes en un sistema
orientado a objetos.
La especialización se puede alcanzar añadiendo o borrando operaciones, o bien
por invalidación.
IE = [NOI x nivel] M

4. Total en donde niveles el nivel de la jerarquía de clases en que reside la clase, y
Mtotal es el número total de métodos para la clase. Cuanto más elevado sea el
valor de IE es más probable que la jerarquía de clases tenga clases que no se
ajustan a la abstracción de la superclase
9.4.- Métricas orientadas a casos de usos
El caso de uso se define en etapas tempranas del proceso de software, lo que
permite emplearlo en la estimación antes de iniciar las actividades significativas de
modelado construcción
9.5.- Métricas de proyecto webapp.
Métricas de proyectos de ingeniería Web “El objetivo de los proyectos de
ingeniería Web es construir una aplicación Web que proporcione una combinación
de contenido y funcionalidad al usuario final.” Entre las medidas que se recopilan
existen las siguientes:
 Número de páginas web estáticas
 Número de páginas web dinámicas
 Número de vínculos internos de la página
 Número de objetos de datos persistentes
 Número de sistemas externos en interfaz
 Número de objetos de contenido estático
 Número de objetos de contenido dinámico
 Número de funciones ejecutables
Además de que:
 Describen funciones y características visibles al usuario
 Son independiente del lenguaje de programación
 Dependen de la complejidad del problema – no existe un tamaño estándar.
10.- Métricas para calidad de software
Las métricas de calidad de software se enfocan sobre el proceso, el proyecto y
el producto. Estas métricas las podemos dividir en dos grupos; el primer grupo se

5. le recolecta antes de la entrega del producto y las otras luego de haberlo
entregado. Además la meta primordial de la ingeniería del software es producir un
sistema, aplicación o producto de alta calidad dentro de un marco temporal que
satisfaga una necesidad del mercado.
10.1.- Medición de la calidad (Gilb)
Corrección, Facilidad de mantenimiento, Integridad, y Facilidad de uso, son las
medidas de la calidad del software, las mismas ofrecen indicadores útiles para el
equipo del proyecto:
 Corrección: Es el grado en que el software desempeña la función para la que
fue creado, donde los defectos se definen como una falta de concordancia con
los requisitos. Su medida es nº de defectos por KLDC.
 Facilidad de Mantenimiento: es la facilidad para corregir un error, adaptar un
programa a cambios, o mejorarlo si el cliente desea un cambio. Su medida es
TMC (tiempo medio de cambio), es decir es la sencillez con la que un
programa puede corregirse si se cuenta con un error, adaptarse si su entorno
cambia, o mejorar si el cliente desea un cambio en los requisitos esta medida
demanda más esfuerzos dentro de las actividades de la ingeniería de software.
 Integridad: Es la capacidad para resistir ataques, provocados o no, contra su
seguridad, ya sea sobre programas, datos y documentos. Se la puede definir
como:
Integridad = (amenaza x (1 – seguridad))
La medición de la integridad define dos atributos: Amenaza y Seguridad.
Amenaza: es la probabilidad de que un cierto tipo de ataque ocurra en un tiempo
dado,
Seguridad: Es la probabilidad de que se pueda contrarrestar un cierto tipo de
ataque, probabilidad de que se repela la amenaza.
Integridad = 1 – (amenaza x (1 – seguridad))

6. Facilidad de uso: Se refiere a Habilidad intelectual y/o física requerida para
aprender a utilizar el sistema; es decir, “amistad con el usuario”. No es más que un
intento por cuantificar el uso de la aplicación al utilizarla y se puede medir en
términos del Diseño de la Interfaz del Usuario
Eficacia en la eliminación de defectos: Habilidad de filtrar las actividades de la
garantía de calidad; cuando se considera como un proyecto se la define como:
EED = E / (E + D)
Donde, E = Error y D = Defecto; el valor ideal de la EED es 1.
La EED también se puede aplicar al proceso para valorar la habilidad de un
equipo de encontrar errores antes de que pase a la siguiente actividad del marco
de trabajo. En este contexto se la define como:
EEDi = Ei / (Ei + E(i + 1) )
Donde i representa una actividad e i+1 representa la siguiente actividad
luego de i;
10.2.- Eficiencia en la remoción del defecto
Defect Removal Efficiency.: Muestra el número de defectos removidos por hora
en Revisión de diseño, Revisión de código, Compilación y Test.
Defect Removal Leverage (DRL): DRL se encarga de medir la efectividad relativa
de dos etapas de supresión de defectos. Compara la eficiencia en la remoción de

7. defectos, entre Design Review vs. Unit Test, Code Review vs. Unit Test, Compile
vs. Unit Test
Si por ejemplo, el nivel de supresión de defectos para la fase de revisión de
código contra la fase de pruebas unitarias es de 3.06/1.71 = 1.79. Esto quiere
decir que el desarrollador será 1.79 más efectivo en encontrar defectos en la fase
de revisión que en la fase de pruebas unitarias.

8. Referencias Bibliográficas:
Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc.
Graw Hill 2002.
Ingeniería de software. Sommerville, I. Séptima edición. Addison Wesley 2005
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo6.pdf
http://es.slideshare.net/edybest/metricas-de-proceso-y-proyecto-8166786
http://www.authorstream.com/Presentation/yohan333-570994-metricas/
https://adonisnet.files.wordpress.com/.../cap22_metricas-de-proceso-y-
proyecto_a4.do