metricas, gestion de proyecto,

1. PNF EN INFORMATICA
Métricas Orientadas Objetos
“M.O.O.”
AUTOR:
Mayo 2016
Ricardo Terán
Profesor
Ing. Luis Raúl Guerrero

2. Página 2 de 7
MMééttrriiccaass oorriieennttaaddaass aa ooppeerraacciióónn ((LLoorreennzz yy KKiidddd))
MMééttrriiccaass ssoobbrree eell ddiisseeññoo ddee llaa iinntteerrffaazz ddee uussuuaarriioo ((SSeeaarrss))
MMééttrriiccaass ddee ddiisseeññoo ppaarraa WWeebbAAppppss
UNIVERSIDAD POLITÉCNICA TERRITORIAL ANDRÉS ELOY BLANCO
“UPTAEB”
PNF EN INFORMATICA
Barquisimeto, Lara, Mayo de 2016

3. Página 3 de 7
Las Métricas Orientas a Objetos:
Aparecieron por la necesidad de poder cuantificar la calidad del software no tradicional.
El software orientado a objetos posee características conceptuales que al no respetarlas pueden afectar la
calidad del producto.
Hay distintos tipos de MOO, como por ejemplo:
-Métricas orientadas a clases.
-Métricas orientadas a operaciones.
-Métricas para pruebas orientadas a objetos.
-Métricas para proyectos orientados a objetos.
En este informe se desarrollara lo relacionado a las Métricas orientadas a operaciones.
Existen menor cantidad de métricas de este tipo por el hecho de que son las clases las que preponderan en
el software OO.
-Tamaño medio de operación
-Complejidad de operación
-Número Medio de Parámetros por operación
Tamaño medio de operación (Lorenz y Kidd)
La cantidad de líneas de código no son una buena unidad de medida para determinar la calidad de una
operación, por lo tanto para determinar ésta se persigue la contabilización de mensajes. Muchos mensajes
evidencian un alto grado de responsabilidad por parte de la operación lo cual no es aconsejable.
Complejidad de operación (Lorenz y Kidd)
En este caso puede utilizarse cualquier métrica existente para el software tradicional debido a que esta
medición no se ve relacionada con el paradigma de la POO.
Número Medio de Parámetros por operación
Tan largo como sea el número de parámetros de operación, más compleja será la colaboración entre
objetos.

4. Página 4 de 7
Métricas orientadas a operaciones.
Dado que la clase es la unidad dominante en los sistemas 00, se han planteado menos métricas
para las operaciones de clases. Churcher y Shepperd
[Presmman’98] describen esto cuando afirman:
Sin embargo, Existen algunas ideas que pueden llegar a estimarse, se indican a continuación tres
métricas sencillas propuestas por Lorenz y Kidd [Pressman ‘98]:
Tamaño medio de operación (TOavg).
Aunque se lograría utilizar las líneas de código como indicador para el tamaño de operación, la
medida LOC padece de considerables problemas. Por esta razón, el número de mensajes
enviados por la operación proporciona una alternativa para el tamaño de la operación. A medida
que asciende el número de mensajes enviados por una única operación, es posible que las
responsabilidades no hayan sido bien estipuladas dentro de la clase.
Complejidad de operación (CO).
La complejidad de una operación se consigue calcular empleando cualquiera de las métricas de
complejidad propuestas para el software convencional Sabiendo que las operaciones
convendrían limitarlas a una responsabilidad específica, en donde el diseñador debería
esforzarse por mantener el valor de CO tan bajo como sea posible.
Número Medio de Parámetros por operación (NPavg).
En cuanto sea más grande el número de parámetros de la operación, será más compleja la
colaboración entre objetos. En general, NPavg debería de mantenerse tan bajo como sea posible.
Métricas sobre el diseño de la interfaz de usuario (Sears):
Sears propone:
Corrección de la distribución (plantilla):
Los resultados de los últimos estudios indican que los métodos
tienden a ser pequeños, tanto en términos del número de
sentencias como en términos de su complejidad lógica [WIL92], lo
cual sugiere que la estructura de conectividad de un sistema
pueda resultar más importante que el contenido de los módulos
individuales.

5. Página 5 de 7
 Posición de las entidades (gráficos, íconos, textos, menues, ventanas, etc.) en la
distribución de la pantalla.
 Frecuencia con la que se usa.
 La dificultad para moverse de una entidad a otra.
Usa las medidas, por ejemplo para:
A nivel de código:
 Expresiones de longitud del programa.
 Volumen de información.
 Nivel del programa, nivel del lenguaje, etc.
Para las Pruebas:
 La mayor parte se enfoca en el proceso de las pruebas, no en las características técnicas
de las pruebas en sí.
 Estimar esfuerzo de prueba.
 Métricas para pruebas orientadas a objetos.
Para el mantenimiento:
 Pueden usarse todas las ya definidas.
 Se proponen métricas nuevas, diseñadas explícitamente para actividades de
mantenimiento.
 Ejemplo: Índice de madurez de software.
Métricas de diseño para WebApps:
Las métricas deben ofrecer respuestas cuantitativas a las siguientes preguntas:
 ¿La interfaz de usuario promueve la facilidad de uso?
 ¿La estética de la WebApp es apropiada para el dominio de la aplicación y confortable al
uso?
 ¿El contenido está diseñado en una forma que proporciona mayor información con el
menor esfuerzo?
 ¿la navegación es eficiente y directa?
 ¿La arquitectura de la WebApp se ha diseñado para acomodar las metas y objetivos
especiales de los usuarios de la WebApp la estructura de contenido y funcionalidad y el
flujo de navegación requerido para usar el sistema de manera efectiva?
 ¿Los componentes están diseñados en una forma que reduce la complejidad y aumenta
la exactitud, la confiabilidad y el desempeño?
Por el momento cada una de estas respuestas puede aplicarse solo de manera cualitativa,
porque todavía no existe una suite valida de métricas que proporcione respuestas cuantitativas.

6. Página 6 de 7
A continuación se presenta una muestra respectiva de métricas de diseño para webapps, es
importante observar que muchas de ellas todavía no se valida, por lo que deben usarse
juiciosamente.
El diseño web abarca actividades técnicas y otras que no lo son. La visión y el sentido del
contenido se desarrollan como parte del diseño gráfico, la plantilla estética de la interfaz de
usuario se crea como parte de diseño de la interfaz y la estructura técnica de la webapp se
modela como parte del diseño arquitectónico y de navegación.
La webapps abarca seis diferentes tipos de diseño cada uno contribuye a la calidad global de la
web esto se puede ver por medio de la pirámide siguiente:
Métricas de interfaz:
Para webapps pueden considerarse la siguiente medida:
 Corrección de plantilla.
 Complejidad de plantilla.
 Tiempo de reconocimiento.
 Esfuerzo de escritura.
 Complejidad de selección.
 Tiempo de adquisición de contenido...Etc.
 Carga de memoria , entre otras mas.
Los principios y directrices esenciales del diseño de una WebApp se pueden mencionar:

7. Página 7 de 7
 Uso equitativo.
 Flexibilidad en el uso.
 Uso sencillo e intuitivo.
 Información perceptible.
 Tolerancia al error.
 Esfuerzo físico reducido.
 Tamaño y espacio para acercarse y usar.
Métricas de estética:
El diseño estético se apoya en el juicio cuantitativo y no es sensible a medición ni a métricas.
IVORY ET AL .Propone un conjunto de medidas que pueden ser útiles para valorar el impacto de
diseño estético .EJEMPLO
 Conteo de palabra
 Conteo de vinculo
 Tamaño de pagina
 Conteo de color
 Conteo de fuente, entre otras.
Métricas de contenido:
Se enfocan en la complejidad de contenido y en los grupos de objetos que se organiza en
páginas ejemplo.
 Espera de página.
 Complejidad de página.
 complejidad de gráfico, etc.
Métricas de navegación:
Abordan la complejidad del flujo de navegación, en realidad son útiles para aplicaciones web que
no incluyan vínculos y páginas de manera dinámica. Ejemplo
 Complejidad de vinculación de página.
 Conectividad.
 Densidad de conectividad
Las métricas sugeridas pueden servir para derivar relaciones empíricas que permite a un equipo
de desarrollo webapps valorar la calidad técnica.