LABORATORIO N° 13

Escuela Profesional: Ingeniería de Sistemas. Asignatura: Ingeniería Software.

Ciclo y Turno: Quinto – Mañana, Tarde y Noche Semestre Académico: 2022 -1
Docente: Ing. Fecha: 27/06/22 al 02/07/22

Sesión 13: Métricas medidas e indicadores

INTRODUCCION
El desarrollo de sistemas hoy en día ha tomado gran importancia en el mundo. Aunque esta importancia tienda a aumentar, no todo
tiene una buena perspectiva, existen inconvenientes en el desarrollo de los sistemas grandes retrasos en la programación,
inconsistencia en su funcionamiento, etc.; pero lo más importante es la falta de calidad, punto de gran interés e importancia para el
logro de eficiencia y productividad de los sistemas.

Es claro que si un sistema presenta errores al momento de ser utilizado, ese producto pierde confiabilidad a los ojos del usuario hasta
el nivel que podría ser desechado como un producto defectuoso. Por esta razón los proyectos de sistemas presentan fallas que impiden
que el sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por ello, es necesario definir e impulsar líneas de
acción tendientes a mejorar el sistema producido. Dentro de estas líneas de acción está la relacionada con el proceso mismo del
desarrollo del sistema, y como necesidad primordial, la de realizar una investigación que permita conocer de primera mano el estado
en que se encuentra su proceso de desarrollo.
.
I. OBJETIVOS
Conocer las metricas e indicadores en el software

II. EQUIPOS Y MATERIALES

 Computadora personal.
 Programa Racional Rose correctamente instalado
 Cuaderno de clases, donde están los modelos resueltos en clase

III. METODOLOGIA Y ACTIVIDADES

a) Diseño de los ejercicios desarrollados en el aula.

b) Presentar avances y ejecución de cada uno de los ejercicios al docente o jefe de práctica encargado para la
calificación correspondiente.
c) Guardar la carpeta de sus archivos a sus memorias.
d) Apagar el computador y dejarla en buen estado al retirarse del laboratorio dejar todo en orden.

IV. IMPORTANTE

Importancia de las metricas e indicadores de software.

V. MANEJO DEL SOFTWARE

Métricas y Técnicas del Proceso de Software

TEMA

Métricas Técnicas de Software

OBJETIVOS ESPECÍFICOS
 Definir los conceptos básicos asociados a los temas de métricas de software
  Presentar enfoques de clasificación de las métricas de software

CONTENIDOS
 Introducción
 Conceptos Básicos de Métricas

ACTIVIDADES
 Identificar el enfoque adecuado de aplicación de una métrica para su proyecto de
Diseño de Aplicaciones Web
1. INTRODUCCION
Se sabe (o conoce) que algunas de las actividades de desarrollo
del proyecto de software comprenden medición y métricas,
estimación, análisis de riesgo, planificación del programa,
seguimiento y control. El recopilar datos (investigación histórica),
calcular métricas (LDC, PF, métricas de calidad, orientadas a
objetos, etc.) y evaluar métricas, son algunos de los pasos que se
deben realizarse al comenzar un producto.

Hoy día es cada vez más frecuente la consideración de métricas

de software, es por eso que sé están implantando en la actualidad,
llevando consigo puntos débiles (aumento de esfuerzo...) y fuertes
(alta calidad, reusabilidad, madurez...) que están experimentado
los ingenieros y administradores de software. El uso de éstas se
ha adoptado con éxito en el amplio mercado de desarrollo de
software introduciendo reconocimientos y consideraciones por
parte de administradores y usuarios, y estableciendo la necesidad
de un enfoque más disciplinado y de una alta calidad. Así muchos
particulares y compañías desarrolladoras de software, están
reconociendo la importancia del uso de las métricas, aunque de
igual modo siguen sin conocer el alcance de madurez y calidad del
producto final y la disciplina de ingeniería madura que llega a
alcanzar con la aplicación de los distintos métodos y técnicas y la
interpretación de los resultados que proyecta el uso de las
métricas; provocando con esto un cambio cultural en los
desarrolladores mexicanos de software, puesto que la mayoría de
estos no cuentan con una educación formal sobre la medición. Es
por eso que a continuación se dará a conocer el propósito esencial
de la investigación de las distintas métricas existentes (públicas) y
el uso de las mismas, y también se dirá del porque se decidió
realizar un manual y un tutorial accesible en Web.

Se sabe que las métricas de software pueden desempeñar una de

las cuatro siguientes funciones:

1. Las métricas pueden ayudarnos a entender más acerca de nuestros

productos, procesos y servicios de software.
2. Las métricas pueden ser empleadas para evaluar el software de nuestros
productos, procesos y servicios con respecto a los estándares y metas
establecidas.
3. Las métricas pueden proveer la información que nosotros necesitamos para
controlar recursos y procesos utilizados en la producción de nuestro
software.
4. Las métricas pueden ser usadas para predecir los atributos de las entidades
de software en el futuro.
Cada métrica elegida cuenta con un objetivo claro, para contestar
una o más preguntas que necesitan ser contestadas, para medir
nosotros mismos en comparación con nuestras metas. Esto nos
guía a patrones básicos de acuerdo con el objetivo de la métrica,
tales como:
 Asegurar una métrica bien definida basándose en las metas del cliente.
 Eliminar malentendidos.
 Comunicar necesidades.
 Proveer un informe de requerimiento.

Contando con un objetivo claramente definido y documentado el

informe para cada métrica se puede tener los siguientes
beneficios:
 Provee una disciplina sólida que asegure una métrica bien definida
basándose en las metas del cliente
 Eliminar malentendidos acerca de la intención del empleo de la métrica.
  Comunicar la necesidad de la métrica, la cual puede ayudar en la obtención
de recursos para la implantación de los mecanismos de colección y reporte
de datos.
 Provee la base para el informe de requerimientos, para realizar un diseño
eficiente de la métrica

2. CONCEPTOS BÁ SICOS DE MÉ TRICAS

Empezaremos por definir los posibles términos que se encuentran
encerrados en la palabra métrica, porque es muy común asociarla
con las palabras medición y medida, aunque estas tres son
distintas. La medición “ es el proceso por el cual los números o
símbolos son asignados a atributos o entidades en el mundo real
tal como son descritos de acuerdo a reglas claramente definidas”
[Fenton ´91]. Una medida “proporciona una indicación cuantitativa
de extensión, cantidad, dimensiones, capacidad y tamaño de
algunos atributos de un proceso o producto” [Pressman´98]. El
IEEE “Standard Glosary of Software Engering Terms” define como
métrica como “una medida cuantitativa del grado en que un
sistema, componente o proceso posee un atributo dado” [Len O.
Ejiogo ´91].

Muchos investigadores han intentado desarrollar una sola métrica

que proporcione una medida completa de la complejidad del
software. Aunque se han propuesto docenas de métricas o
medidas, cada una de éstas tienen un punto de vista diferente; y
por otro lado, aunque bien se sabe que existe la necesidad de
medir y controlar la complejidad del software, es difícil de obtener
un solo valor de estas métricas de calidad. Aun así debería ser
posible desarrollar medidas de diferentes atributos internos del
programa.

Aunque todos estos obstáculos son motivo de preocupación, no

son motivo de desprecio hacia las métricas. Es por eso que se
dice que la medición es esencial, si es que se desea realmente
conseguir la calidad en software. Es por eso que existen distintos
tipos de métricas para poder evaluar, mejorar y clasificar al
software final, en donde serán manejadas dependiendo del
entorno de desarrollo del software al cual pretendan orientarse.

¿Qué son las Mé tricas de Software?

Michael [‘99] define las métricas de software como “La aplicación continua
de mediciones basadas en técnicas para el proceso de desarrollo del
software y sus productos para suministrar información relevante a tiempo,
así el administrador junto con el empleo de estás técnicas mejorará el
proceso y sus productos”. Las métricas de software proveen la información
necesaria para la toma de decisiones técnicas. En la figura se ilustra una
extensión de esta definición para incluir los servicios relacionados al
software como la respuesta a los resultados del cliente:
Las métricas son la maduración de una disciplina, que, según Pressman
[’98] van a ayudar a la (1) evaluación de los modelos de análisis y de
diseño, (2) en donde proporcionarán una indicación de la complejidad de
diseños procedimentales y de código fuente, y (3) ayudaran en el diseño
de pruebas más efectivas; Es por eso que propone un proceso de
medición, el cual se puede caracterizar por cinco actividades:
1. Formulación:
La obtención de medidas y métricas del software apropiadas para la
representación de software en cuestión.
2. Colección:
El mecanismo empleado para acumular datos necesarios para obtener
las métricas formuladas.
3. Análisis:
El cálculo de las métricas y la aplicación de herramientas matemáticas.
4. Interpretación:
La evaluación de los resultados de las métricas en un esfuerzo por
conseguir una visión interna de la calidad de la representación.
5. Realimentación:
Recomendaciones obtenidas de la interpretación de métricas técnicas
trasmitidas al equipo de software.

Se conoce que no existe un cuerpo de principios en conjunto, puedan

dirigir al desarrollo de métricas de software a que sean independientes del
lenguaje, a ambientes y a metodologías de programación.
Matemáticamente, estos principios son teorías e implementaciones críticas
ya que una métrica, tiene ciertas propiedades matemáticas y atributos de
ingeniería, así como también ciertas realimentaciones de productividad. Es
por eso que alcanzamos a responder tres preguntas fundamentales
deseadas de una métrica [Fenton ‘91].
1. ¿Cuánto mide? - la complejidad en la medida
Una propuesta habitual para medir la complejidad es la entropía informativa de
Shannon: H[p]=−∑xip(xi)log(p(xi))H[p]=−∑xip(xi)log(p(xi)). Esta medida se anula cuando el
sistema es regular (es decir, hay un solo evento probbale), lo que concuerda con nuestra intuición
de que la complejidad es baja cuando no pasa nada, y sin embargo, es máxima para una dinámica
completamente al azar.
2. ¿ Qué tan bien mide? - la calidad en la medida
La calidad en el servicio es una métrica dentro las organizaciones que buscan la diferenciación y
competitividad en el mercado. El objetivo principal es identificar los atributos de calidad en el
servicio y evaluar la relación entre la calidad percibida y la satisfacción del cliente
3. ¿ Qué tanto tiempo mide? - la predicción

Las métricas de software incluyen otras varias actividades, tales como:

 Estimación de costo y el esfuerzo
 Medición de la productividad
 Acumulación de datos
 Realización de modelos y mediciones de la calidad
 Elaboración de modelos de seguridad
 Evaluación y modelos de desempeño
 Valoración de las capacidades y de la madurez
 Administración por métricas
 Evaluación del método y herramientas

Clasificació n de las Métricas

La clasificación de una métrica de software refleja o describe la conducta
del software. A continuación se muestra una breve clasificación de
métricas de software, descritas por Lem O. Ejiogu [‘91]:

1. Métricas de complejidad:
Son todas las métricas de software que definen de una u otra forma la
medición de la complejidad; Tales como volumen, tamaño, anidaciones,
costo (estimación), agregación, configuración, y flujo. Estas son los
puntos críticos de la concepción, viabilidad, análisis, y diseño de
software.
2. Métricas de calidad:
Son todas las métricas de software que definen de una u otra forma la
calidad del software; Tales como exactitud, estructuración o
modularidad, pruebas, mantenimiento, reusabilidad, cohesión del
módulo, acoplamiento del módulo, etc. Estas son los puntos críticos en
el diseño, codificación, pruebas y mantenimiento.
3. Métricas de competencia:
Son todas las métricas que intentan valorar o medir las actividades de
productividad de los programadores o practicantes con respecto a su
certeza, rapidez, eficiencia y competencia. No se ha alcanzado mucho
en esta área, a pesar de la intensa investigación académica.
4. Métricas de desempeño:
Corresponden a las métricas que miden la conducta de módulos y
sistemas de un software, bajo la supervisión del sistema operativo o
hardware. Generalmente tienen que ver con la eficiencia de ejecución,
tiempo, almacenamiento, complejidad de algoritmos computacionales,
etc.
5. Métricas estilizadas:
Son las métricas de experimentación y de preferencia; Por ejemplo:
estilo de código, identación, las convenciones denominando de datos,
las limitaciones, etc. Pero estas no se deben confundir con las métricas
de calidad o complejidad.
6. Variedad de métricas:
Tales como portabilidad, facilidad de localización, consistencia. Existen
pocas investigaciones dentro del área.

Estas clasificaciones de métricas fortalecen la idea, de que más de una

métrica puede ser deseable para valorar la complejidad y la calidad del
software.
Diferentes Enfoques de Mé tricas
Se han propuesto cientos de métricas para el software, pero no todas
proporcionan suficiente soporte práctico para su desarrollo. Algunas
demandan mediciones que son demasiado complejas, otras son tan
esotéricas que pocos profesionales tienen la esperanza de entenderlas, y
otras violan las nociones básicas intuitivas de lo que realmente es el
software de alta calidad. Es por eso que se han definido una serie de
 CALIDAD DE SOFTWARE
11

atributos que deben acompañar a las métricas efectivas de software, por lo

tanto la métrica obtenida y las medidas que conducen a ello deben cumplir
con las siguientes características fundamentales:
1. Simple y fácil de calcular:
Debería ser relativamente fácil de aprender a obtener la métrica y su
cálculo no obligara a un esfuerzo o a una cantidad de tiempo inusuales.
2. Empírica e intuitivamente persuasiva:
La métrica debería satisfacer las nociones intuitivas del ingeniero de
software sobre el atributo del producto en cuestión (por ejemplo: una
métrica que mide la cohesión de un módulo debería aumentar su valor
a medida que crece el nivel de cohesión).
3. Consistente en el empleo de unidades y tamaños:
El cálculo matemático de la métrica debería utilizar medidas que no
lleven a extrañas combinaciones de unidades. Por ejemplo,
multiplicando el número de personas de un equipo por las variables del
lenguaje de programación en el programa resulta una sospechosa
mezcla de unidades que no son intuitivamente concluyentes.
4. Independiente del lenguaje de programación:
Las métricas deberían apoyarse en el modelo de análisis, modelo de
diseño o en la propia estructura del programa. No deberían depender
de los caprichos de la sintaxis o semántica del lenguaje de
programación.
5. Un mecanismo eficaz para la realimentación de calidad:
La métrica debería suministrar al desarrollador de software información
que le lleve a un producto final de superior calidad.

No obstante que la mayoría de las métricas de software compensan las

características anteriores, algunas de las métricas usualmente empleadas
no cumplen una o dos características. Un ejemplo son los Puntos de
Función, en donde se consigue argumentar que el atributo es consistente
y objetivo pero falla por que un equipo ajeno independiente puede no ser
capaz de conseguir el mismo valor de PF que otro equipo que emplee la
misma información del software. En tal caso la siguiente pregunta se
manifiesta, ¿Debería entonces rechazar la medida PF?. La respuesta es
por supuesto que No!., la PF aporta una visión interna útil y por lo tanto
provee de un valor claro, incluso si no satisface un atributo perfectamente.
Este es un ejemplo en donde el uso de las métricas dependen de los
factores individuales del desarrollador o desarrolladores del software.

Las Métricas en el Proceso y Dominio del Proyecto

Las métricas de proceso de software se emplean para fines estratégicos, y
las métricas del proyecto de software son tácticas, éstas últimas van a
permitir proporcionar al desarrollador de proyectos del software una
evaluación al proyecto que sigue en continuo desarrollo, equivalentemente
podrá ver los defectos que logren provocar riesgos a largo plazo (áreas
problema); y observar si el área de trabajo (equipo) y las distintas tareas
se ajustarán.
 CALIDAD DE SOFTWARE
11
Existe una preocupación en la unificación de las métricas dentro del
proceso del software, dado que los desarrolladores mexicanos de software
no tienen la cultura de la medición. Es por eso que el uso de métricas
demanda un cambio cultural, tanto en el recopilado de datos (investigación
histórica), como en el cálculo de métricas (LDC, PF,
 CALIDAD DE SOFTWARE
11

métricas de calidad y orientadas a objetos) y asimismo en la evaluación

(resultados obtenido), para poder comenzar un programa de bases de
métricas y justamente obtener una guía, asimismo una base de datos
tanto de los procesos como de los productos y de este modo adquirir una
visión más profunda de lo que se está elaborando.

Las métricas de software nos aportan una manera de estimar la calidad de

los atributos internos del producto, permitiendo así al ingeniero de software
valorar la calidad antes de construir el producto, así el tiempo invertido
será identificando, examinando y administrando el riesgo, este esfuerzo
merece la pena por muchas razones ya que habrá disminución de
disturbios durante el proyecto, asimismo se podrá desarrollar una habilidad
de seguir y controlar el proyecto y se alcanzará la seguridad que da
planificar los problemas antes de que ocurran, además conseguiremos
absorber una cantidad significativa del esfuerzo en la planificación del
proyecto.

Del mismo modo existen diferentes tipos de métricas para poder evaluar,
mejorar y clasificar al software desde sus inicios hasta el producto final, de
las cuales se verán en los siguientes capítulos.

Autoevaluación
 ¿Qué funciones desempeñan las métricas de software?. Explique
Las métricas de calidad de software 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.
 ¿Cuáles son las actividades que deben estar presentes en un proceso de
medición?

Definir lo que debemos medir

Definir lo que es posible medir
Recopilación de datos
Análisis de los datos
Presentación y uso de la información

 ¿Qué características deben cumplir los diferentes enfoques de métricas?. Explique

Se han definido una serie de atributos que deben acompañar a las métricas efectivas de
software, por lo tanto, la métrica obtenida y las medidas que conducen a ello deben cumplir
con las siguientes características fundamentales:

- Simple y fácil de calcular

- Empírica e intuitivamente persuasive
- Consistente en el empleo de unidades y tamaños
- Independiente del lenguaje de programación
CALIDAD DE SOFTWARE
11
- Un mecanismo eficaz para la realimentación de calidad
 CALIDAD DE SOFTWARE
11

Atributos de Calidad de Software

TEMA

Métricas Técnicas

OBJETIVOS ESPECÍFICOS
 Definir la importancia de la medición de los atributos externos e internos del
software
 Sustentar un panorama de las técnicas de medición a lo largo del ciclo de vida
del software

CONTENIDOS
 Introducción
 Atributos Internos y Atributos Externos
 Métricas Orientadas al tamaño
 Métricas Orientadas a la Función
 Medidas de Complejidad de Halstead
 Paradigma Meta / Pregunta / Métrica
 Ciclo del Tiempo
 Diferentes Enfoques de Métricas

ACTIVIDADES
 Medir el tamaño del producto software de su proyecto del curso de Diseño de
Aplicaciones Web
CALIDAD DE SOFTWARE
11

1. INTRODUCCION
Cualquier cosa que queramos medir o predecir en un software es
un atributo de cualquier entidad de un producto, proceso o recurso
asociado a éste.

Cada entidad de software tiene varios atributos que pueden ser

medidos. Es por eso que se necesita hacer una distinción entre
atributos que son internos o externos y medidas directas e
indirectas.

2. ATRIBUTOS INTERNOS Y ATRIBUTOS EXTERNOS

Los atributos internos de un producto, proceso o recurso son
aquellos que podemos medir puramente en términos del producto,
proceso o recurso del mismo. Pueden ser medidos directamente.
Por ejemplo: la longitud de un programa o el tiempo transcurrido
de cualquier documento de software [Fenton‘91].

Los atributos externos de un producto, proceso o recurso son

aquellos que solamente pueden ser medidos con respecto al cómo
el producto, proceso o recurso se relacionan a su ambiente. Estos
tienden a ser los que el administrador y el usuario del software
comúnmente gustan de medir y predecir. Por ejemplo el
administrador de software le gustaría saber el costo de eficacia de
algunos procesos o de la productividad de su personal, mientras
los usuarios les gustaría saber la usabilidad, fiabilidad, o
portabilidad de un sistema que ellos observan para comprar.
Desgraciadamente los atributos externos son los más difíciles de
medir, porque estos no pueden ser medidos directamente [ Fenton
’91]. En la tabla siguiente se describe la estructura, y se dan
ejemplos de varios tipos de atributos.

Medidas Directas y Medidas Indirectas

La medida directa de un atributo es aquella, en donde no se
depende de cualquier otro atributo. [ Fenton´91].

La medida Indirecta de un atributo es aquella en la que se involucra

la medición de uno o más atributos [Fenton´91].

El Reto de las Métricas Técnicas

Muchos investigadores han intentado desarrollar una sola
métrica que facilite una medida completa de la complejidad
del software. Aunque se han presentado docenas de
medidas de complejidad, cada una tiene un punto de vista
distinto de lo que es la complejidad y de qué atributos de un
sistema llevan a la complejidad. Comparemos con una
CALIDAD DE SOFTWARE
11
métrica para evaluar un automóvil. Algunos observadores
podrían hacer énfasis en el diseño de la cabina, otros
podrían hacer hincapié en las características mecánicas,
otros podrían considerar el precio, o el rendimiento, o la
economía de consumo o la capacidad de reutilizarlo cuando
se vaya a desechar. Como cualquiera de estas
características puede competir con las otras, es difícil
obtener un solo valor del ‘atractivo’ del automóvil. Lo mismo
sucede con el software
CALIDAD DE SOFTWARE
11

Se ha producido una gran cantidad de literatura sobre las

métricas del software y es común la crítica de algunas
métricas (incluyendo algunas de las presentadas en este
documento). Sin embargo, muchas de las críticas se
centralizan en aspectos esotéricos y pierden el objetivo
primario de la medición en el mundo real, que es: el ayudar
al ingeniero a establecer una manera sistemática y objetiva
de conseguir una visión interna de su trabajo y mejorar la
calidad del producto como resultado.

Sin embargo sigue existiendo la necesidad de medir y controlar la complejidad

del software, y aunque es difícil de adquirir un solo valor de esta “métrica de
calidad”, sí debería ser posible desarrollar medidas de diferentes atributos
internos del programa (por ejemplo: modularidad efectiva, independencia
funcional y otros atributos). Las métricas y las medidas conseguidas de ellas
pueden usarse como guías independientes de la calidad de los modelos de
análisis y de diseño. Pero también surgen problemas aquí. Fenton [‘91] lo
advierte cuando dice: “El peligro de intentar encontrar medidas que
caractericen tantos atributos diferentes es que inevitablemente las medidas
tienen que satisfacer objetivos incompatibles. Esto es contrario a la teoría de
representación de la medición”.
CALIDAD DE SOFTWARE
11
Aunque la declaración de Fenton es correcta, mucha gente
cuestiona que la medición técnica llevada a cabo en las
primeras fases del proceso del software les proporcione a
los desarrolladores de software un mecanismo consistente y
objetivo para valorar la calidad. No obstante conviene
CALIDAD DE SOFTWARE
11

preguntarse, ¿Qué validez tienen las métricas técnicas?. Es

decir, ¿Cómo están relacionadas las métricas técnicas con
la fiabilidad y la calidad a largo plazo de un sistema basado
en computadora.

Fenton[‘9l] comenta que, a pesar de las conexiones

intuitivas entre la estructura interna de los productos de
software (métricas técnicas), sus productos externos y los
atributos del proceso, ha habido de hecho, muy pocos
intentos científicos para establecer relaciones específicas

Identificació n del Usuario

En el desarrollo de métricas se requiere identificar
claramente al usuario. Lo primero que debemos hacer para
identificar a un usuario es preguntarnos:
 ¿Quién necesita la información?
Los requerimientos del usuario determinan el programa de
métricas. Si el programa de métricas no tiene a un usuario se
recomienda no establecer dicho programa.

 ¿Quién va a emplear la métrica?

 Si la métrica no tiene un usuario – no utilizarla?

En las preguntas anteriores podemos observar que la

selección de una métrica empieza con la identificación de
los programas que el usuario quiere medir.

¿Quién necesita la información? Los requerimientos del

usuario determinan el programa de métricas. Si el programa
de métricas no tiene a un usuario se recomienda no
establecer dicho programa.

Diseñ o de Métricas
Enseguida se planearan los pasos para diseñar métricas: [Lem Ejiogo
‘91]

Paso 1: Definiciones claras

El primer paso en el diseño de una métrica es el dar una
definición estándar para las entidades y sus atributos a ser
medidos.

Cuando nosotros empleamos términos como “errores”,

“defectos”, “problema reportado”, “tamaño” y aún “proyecto”,
otra gente podría interpretar estas palabras en su propio
CALIDAD DE SOFTWARE
12
contexto con significados que pueden variar de nuestra
intención al definirlos. Estas interpretaciones aumentan sus
diferencias cuando se emplean términos más ambiguos
como: Calidad, mantenible, amigable al usuario y otros más.

Los ingenieros, administradores u otras personas

involucradas en el proyecto pueden emplear diferentes
términos para la misma cosa. Por ejemplo, el término
defecto reportado, problema reportado, incidente reportado,
falla reportada, o reporte de llamada del cliente pueden ser
empleados por varias organizaciones para dar significado a
la misma cosa. Pero desgraciadamente, pueden también
referirse a distintas entidades. Para evitar estos problemas
se sugiere:
 Adoptar definiciones estándares y escribirlas
 Aplicarlas con consistencia
 Usar las sugerencias de la industria
 Escoger definiciones que cumplan los objetivos organizacionales

Desafortunadamente, hay muy pocos estándares en la

industria para la mayoría de las definiciones de los atributos
del software. Cada uno cuenta con una opinión y este
debate podría continuar por muchos años.
CALIDAD DE SOFTWARE
12

Al abordar este problema se sugieren adoptar definiciones

estándares hacia dentro de la organización y aplicarlos
consistentemente. Se pueden usar sugerencias de la
industria como base para empezar, seleccionar las
definiciones que cumplan con los objetivos de la
organización y emplearlos para la creación de definiciones
propias.

Paso 2: Definir el modelo

El siguiente paso es definir un modelo para la métrica. En
términos sencillos, el modelo define el cómo calcular la
métrica. Por ejemplo, para la Inspección del código de las
métricas primitivas, se puede usar los siguientes modelos
[Fenton‘91]:
 Líneas de código inspeccionadas = loc
 Horas empleadas en la preparación = hrs-prep
 Medida de preparación = loc / hrs-prep

La mayoría de los modelos incluyen un elemento de simplificación.

Cuando
nosotros creamos un modelo de medición de software
necesitamos ser pragmáticos. Si tratamos de incluir todos
los elementos que afectan al atributo que caracterizan a la
entidad el modelo utilizado llegará a ser demasiado
complicado. Ser pragmático significa no tratar de crear un
modelo perfecto. Tomar los aspectos más importantes.
Recordar que el modelo puede ser siempre modificado para
incluir mas niveles de detalle en el futuro.

Hay dos métodos para la selección de un modelo:

En muchos casos no es necesario "re-inventar la rueda".

Hay muchos modelos de métricas de software que son
empleados exitosamente por otras organizaciones. Pero
desdichadamente no se saben a puertas abiertas por la
“privacidad” que estas requieren.

El segundo método es crear un modelo propio.- El mejor

consejo es hablar
con la gente quien actualmente es responsable del producto,
de los recursos o con quienes están involucrados en el
proceso. Ellos son los expertos y por lo tanto conocen que
factores son importantes
CALIDAD DE SOFTWARE
12
Para ilustrar la selección de un modelo, vamos a considerar
una métrica para la duración de caídas no planeadas de los
sistemas. Si estamos evaluando un sistema de software
instalado en un solo servidor, un modelo sencillo tal como
los minutos de caída por mes pueden ser suficiente. Si el
objetivo es comparar diferentes versiones del software
instalado en varios servidores, se puede seleccionar un
modelo como minutos de caída por 100 meses de
operación. Si queremos enfocarnos en el impacto del
cliente, se debe seleccionar minutos de caída al año por
"servidor". Se presenta detalladamente, el ejemplo dado de
la selección de un modelo [Michael Mah ‘99].

Duración de caídas no planeadas de sistemas

 Minutos de caídas por mes
 Minutos de caídas / 100 meses de operación
 Minutos de caída por “servidor”' por año
CALIDAD DE SOFTWARE
12

Paso 3: Establecer un criterio de conteo

El siguiente paso en el diseño de una métrica es dividir al
modelo en sus métricas primitivas (cuantificables en forma
directa) y la definición del criterio de conteo para medir cada
primitiva. En este paso se definirá el sistema de mapeo para
la medición de cada métrica primitiva.

Las métricas primitivas y su criterio de conteo definen el

primer nivel de los datos que necesitan ser recolectados
para implantar la métrica. Para ejemplificar esto se va usar
el modelo de minutos de caída por servidor por año. Una de
las métricas primitivas para este modelo es el número de
servidores. Al principio, el conteo de esta primitiva parece
sencillo. Pero cuando consideramos la dinámica de añadir
nuevos servidores o la instalación de software nuevo en
servidores existentes, el criterio de conteo se vuelve más
complejo. Así que si empleamos el número de servidores del
último día del periodo o ¿calcular un número promedio de
servidores para el periodo? De cualquier forma, necesitamos
recolectar datos como la fecha en que el sistema fue
instalado en el servidor y si queremos comparar diferentes
versiones del software, se necesita recolectar la información
de las versiones que fueron instaladas en cada servidor y
cuando cada una fue instalado. Se presenta detalladamente,
el ejemplo dado de criterio de conteo [Michael Mah ‘99].
 Número de "servidores" al final de un periodo
 Número de "servidores" al inicio + Número de "servidores" al
final/("servidor" en cada día) / número de días

Paso 4: Decidir ¿Qué es bueno?

El cuarto paso en el diseño de una métrica es definir “¿Qué
es bueno?”. Una vez que se a decidido que medir y como
medir, se tiene que decidir que hacer con el resultado. ¿Es
10 demasiado poco o 100 es mucho? .
¿La tendencia debería ser hacia arriba o hacia abajo?

Uno de los primero lugares para empezar a ver "¿Qué es

bueno?", es con los clientes. Muchas veces, los
requerimientos del usuario determinan ciertos valores de
algunas métricas. Otra fuente de información es la literatura
de métricas. Varias investigaciones y estudios han ayudado
al establecimiento de normas aceptadas por la industria para
mediciones estándares. Si no están disponibles datos
históricos, se recomienda esperar hasta recolectar suficiente
información para el establecimiento de valores actuales. Una
vez que se ha decidido “¿Qué es bueno?", se pueden
determinar en todo caso que acciones son necesarias. Si se
CALIDAD DE SOFTWARE
12
está “excediendo” los valores deseados, o si las acciones
correctivas no son necesarias. Para establecer el manejo y
monitoreo de actividades de mejoramiento, se determinará
en las métricas un ambiente en donde se deberá tener
presente cuatro metas:
 La meta debe ser razonable; Es correcto el establecer metas que se
extienden, pero si ésta es irreal, esta se ignorará.
 La meta debe estar asociada a un marco de tiempo.
 La meta debe fundamentarse en acciones sustentadas. Por ejemplo
podría ser razonable establecer una meta de un incremento del 50%
en la solución de errores encontrados, si se crea un equipo especial
que tendrá como actividad la solución de errores detectados.
 La meta debe ser dividida en partes. Por ejemplo si se emplea un
año para alcanzar el mejoramiento, no seria más fácil si la misma
meta se divide en 12 pequeñas metas que se establezcan por mes; y
así las acciones serán más probables a ser realizadas.
CALIDAD DE SOFTWARE
12

Paso 5: Reporte de la mé trica

El siguiente paso es decidir como reportar la métrica. Esto
incluye la definición del formato del reporte, la obtención de
los datos, mecanismos de reporte de distribución y
disponibilidad. El formato del reporte se diseña de acuerdo a
lo que se quiera dar a conocer, es por eso que se debe
preguntar lo siguiente, ¿Está la métrica incluida en una tabla
con otras métricas para un periodo?, ¿Se añade como
último valor en una gráfica de tendencia que muestran los
valores de la métrica para varios periodos?. Esta gráfica de
tendencia ¿Puede ser de barra, línea o de área?, ¿Es mejor
comparar valores empleando barras apiladas o gráficas de
pastel?. ¿Es mejor hacer tablas y gráficas solas o se agrega
texto detallado de análisis y se incluye en el reporte?, ¿Son
metas o valores de control los que se incluyen en el
reporte?.

En el reporte de métricas, se deberá realizar cuatro pasos:

ciclo de obtención de datos, ciclo de reporte de datos,
mecanismos de reporte, distribución y disponibilidad que se
describen a continuación:
1. El ciclo de obtención de datos
Define que a menudo la métrica requiere de snap-shot(s)
de los datos y en que momento los elementos de los
datos están disponibles para el cálculo de la métrica.
2. El ciclo de reporte
Define con que frecuencia el reporte es generado y
cuando se prepara para su distribución. Por ejemplo la
razón principal de un estudio de métricas puede ser por
algún evento, como la terminación de una fase en el
proceso de desarrollo del software; Otras métricas como
el promedio de defectos reportados pueden obtenerse y
reportarse diariamente durante las pruebas del sistema,
la obtención mensual de datos y el reporte mensual
después de la liberación del software.
3. Los mecanismos de reporte
Proyectan los mecanismos de entrega de las métricas.
4. Al definir la distribución
Determina quienes reciben copias del reporte o tienen
acceso a la métrica. También aquí se define cualquier
restricción al acceso de la métrica, mecanismos de
aprobación para añadir y eliminar accesos y cambios en
la distribución normal.
CALIDAD DE SOFTWARE
12
Paso 6: Calificadores Adicionales
El paso final en el diseño de una métrica es el determinar
calificadores adicionales. Una buena métrica es una métrica
genérica. Esto significa que la métrica es válida para todos
los niveles de calificadores que se puedan adicionar.

Los calificadores añadidos proveen la información

estadística necesaria para varios puntos de vista de la
métrica. Un ejemplo de calificadores adicionales. [Norman E.
Fenton ‘91] podría ser la duración de caídas no planeadas
del sistema, tales como:
 Liberación del producto/ Líneas de productos / Producto final
 Clientes / Segmento de negocios
 Tipo de caída / Causa

En el diseño de las métricas para la duración de caídas no

planeadas del sistema pueden emplearse calificadores
adicionales para observar toda la
CALIDAD DE SOFTWARE
12

información, tanto de las líneas de un producto como, las de

productos individualmente o la liberación del producto,
también se pueden percibir las caídas desde el cliente o
desde el segmento de negocios, o las podríamos observar
por el tipo o causa.

La razón principal de los calificadores adicionales necesitan

ser definidos como parte del diseño de las métricas ya que
estos determinan el segundo nivel de los requerimientos de
la recolección de datos. Ninguna discusión de selección y
diseño de métricas de software sería completa sin tener en
cuenta el cómo las mediciones afectan a la gente y cómo la
gente afecta a las mediciones.

El simple hecho de medir afectara el ambiente de los

individuos a ser medidos. Cuando alguien es empezado a
ser medido automáticamente asume que tiene importancia.
La gente quiere ser vista bien, por lo que van a querer que
las mediciones sean buenas. Cuando se crea una métrica
siempre se decide que ambientes se desea estimular.
Entonces se debe tomar el tiempo necesario de que otros
ambientes pueden resultar del empleo o no empleo de
métricas.

La mejor manera de prevenir problemas con el factor

humano al trabajar con métricas es seguir algunas de las
siguientes reglas básicas: [Annelise ‘91]:
1. No hacer mediciones del individuo:
Las mediciones de productividad individual son los
ejemplos clásicos de estos errores. Si se midiera la
productividad en líneas de código por hora producidas, la
gente se concentraría en su propio trabajo y excluiría al
equipo de trabajo, o se enfocaría en realizar
programación con líneas extras de código. Es por eso
que se recomienda enfocarse en el proceso y en el
producto, no en la gente.
2. No ignorar los datos:
Un camino seguro para acabar un programa de métricas
es olvidar los datos cuando se toman las decisiones, ya
que estos "dan sustento a la gente cuando sus reportes
emplean información útil a la organización". Si las metas
que se establecen y se comunican no son respaldadas
con acciones entonces la gente en la organización se
desempeñará basándose en el ambiente y no en las
metas.
3. Nunca emplear únicamente una sola métrica:
CALIDAD DE SOFTWARE
12
El software es complejo y multifacético es por eso que el
enfocarse en una sola métrica puede causar que el
atributo medido mejore a expensas de otros atributos. Lo
que debería realizarse, es:
4. Seleccionar las métricas basándose en objetivos:
Para tener métricas que cumplan con nuestra necesidad
de información, se debe seleccionar métricas que
proporcionen información que den respuesta a las
preguntas.
5. Proveer retroalimentación:
El proveer retroalimentación con regularidad tiene algunos beneficios:
 El mantener enfocada la necesidad de la recolección de los
datos, hará que el equipo vea que los datos actuales son
empleados y por lo tanto se volverán consientes de la
importancia de la recolección.
 Si los miembros de los equipos son mantenidos con la
información de como los datos son usados, ellos serán cada vez
menos escépticos de la utilidad de estos.
CALIDAD DE SOFTWARE
12

 Al involucrar a los miembros del equipo en el análisis de los datos

y en los esfuerzos de mejoramiento del proceso, el proceso se
beneficiara de sus conocimientos y experiencia.
 La retroalimentación en la recolección de datos y en el resultado
íntegro ayudará en la responsabilidad de la recolección de los
datos, dando como resultado datos más exactos, consistentes y
a tiempo.
6. Obtener "buy-in":
Para tener compromiso en las metas como en las
métricas, los miembros del equipo necesitan tener un
sentimiento de propiedad, es por eso que el participar en
la definición de las métricas acrecentara este sentimiento
de propiedad. La gente quien trabaja con un proceso a
diario tiene un conocimiento intimo del proceso, esto da
una perspectiva valiosa de como el proceso se puede
medir mejor y como se pueden interpretar los resultados
de las mediciones para maximizar su utilización.

Mediciones del Software

Para medir algo se necesita saber que entidades serán
medidas y tener una idea de los atributos (propiedades) de
la entidad. Primero se debe identificar un atributo y su
significado de medición, podemos empezar acumulando
datos.

Analizando los resultados de estos procesos normalmente

permite la clarificación y la re-valuación de los atributos.

3. METRICAS ORIENTADAS AL TAMAÑ O

Las métricas del software orientadas al tamaño provienen de la
normalización de las medidas de calidad y/o productividad
considerando el “tamaño” del software que se haya producido. Si
una organización de software mantiene registros sencillos, se
puede crear una tabla de datos orientados al tamaño, como la que
muestra la figura, (Pressman ´98) que lista cada proyecto de
desarrollo de software y las medidas correspondientes de cada
proyecto. Refiriéndonos a la entrada de la figura del proyecto alfa:
se desarrollaron 12,100 líneas de código(LDC) con 24 personas-
mes y con un costo de $168,000 dólares. Debe tenerse en cuenta
que el esfuerzo y el costo registrados en la tabla incluyen todas las
actividades de ingeniería del software (análisis, diseño,
codificación y prueba) y no sólo la codificación. Otra información
sobre el proyecto alfa indica que se desarrollaron 365 páginas de
documentación, se registraron 134 errores antes de que el
software se entregara al cliente y se encontraron 29 errores
CALIDAD DE SOFTWARE
12
después de entregárselo al cliente dentro del primer año de
utilización. También sabemos que trabajaron tres personas en el
desarrollo del proyecto alfa.
CALIDAD DE SOFTWARE
12

Para desarrollar métricas que se puedan comparar entre distintos

proyectos, se seleccionan las líneas de código como valor de
normalización. Con los elementales datos contenidos en la tabla
se puede desarrollar para cada proyecto un conjunto de métricas
simples orientadas al tamaño, tales como:
 errores por KLDC (miles de líneas de código, KiloLDC)
 defectos por KLDC
 $ por LDC
 páginas de documentación por KLDC

Además, se pueden calcular otras métricas interesantes:

 Productividad = KLDC/ persona-mes
 Calidad = errores / KLDC
 Documentación = páginas de documentación / KLDC

Las métricas orientadas al tamaño no están aceptadas

universalmente como el mejor modo de medir el proceso de
desarrollo del software La mayor parte de la discusión gira en
torno al uso de las líneas de código mostradas en la tabla
siguiente (LDC) como medida clave. Los defensores de la medida
LDC afirman que la LDC es un “artificio” que se puede calcular
fácilmente para todos los proyectos de desarrollo de software, que
muchos modelos de estimación del software existente utilizan LDC
o KLDC como clave de entrada. En el lado opuesto los ofensores
defienden que las medidas en LDC son dependientes del lenguaje
de programación, que perjudican a los programas más cortos,
pero bien diseñados, que no pueden acomodar fácilmente
lenguajes procedimentales, y que
su uso en estimación requiere un nivel de detalle que pude
resultar difícil de alcanzar (es decir, el planificador debe estimar
las LDC a producirse mucho antes de que se complete el análisis
y el diseño)
CALIDAD DE SOFTWARE
12

4. METRICAS ORIENTADAS A LA FUNCIÓ N

Utilizan una medida de la funcionalidad; ésta no se puede medir
directamente, se debe derivar indirectamente por medio de
medidas directas. Las primeras fueron propuestas por Albrecht,
que sugirió una medida llamada “Punto de Función” para un
sistema de software, la idea es que examinemos una
especificación del sistema, estas se derivan con una relación
empírica según las medidas contables
CALIDAD DE SOFTWARE
12

(directas) del dominio de información del software y las

evaluaciones de la complejidad de software. [Charles R. Symons,
‘98]

El tamaño de la tarea de diseño y desarrollo de un sistema de

computo es determinado por el producto de tres factores
mostrados en la figura siguiente:

 El tamaño de información procesada:

Este es una medida de la información procesada y
proporcionada por el sistema.
 Factor técnico de complejidad:
En éste toma en cuenta la medida de varias técnicas y otros
factores implicados en el desarrollo y en el implemento de la
información procesada requerida.
 Factores de entorno (o medio):
Este es el grupo de factores que surge del entorno del proyecto
típicamente valorado en proyectos con riesgo de medidas.
Incluye habilidades, experiencia y motivaciones del personal
involucrado y de los métodos, lenguajes y herramientas usadas
por el equipo del proyecto.

Nótese que los primeros dos de éstos tres factores son intrínsecos
al tamaño del sistema en el sentido que éstos resultan
directamente de los requerimientos del sistema que serán
entregados al usuario.

El método de Punto de Función ha ganado aceptación en el

negocio de sistemas de información, para la evaluación del
tamaño del sistema como un componente de la medida de
productividad. Cuando están disponibles datos históricos de
productividad este método puede también utilizarse como una
ayuda a estimar horas-persona. Para estimar propósitos, el tercer
grupo de factores del entorno tiene que ser tenido en cuenta
también.
CALIDAD DE SOFTWARE
12
El método de Punto de Función de Allan Albrecht consiste en
componentes de un sistema que se clasifican en cinco tipos:
entradas externas (o lógicas), salidas, preguntas, interfaces
externas a otras sistemas, y los archivos lógicos internos.
Dependiendo del número de elementos de datos estos se
denominan como “simple”, “promedio” o “complejo”. Cada
componente es el número dado de puntos dependiendo en tipo y
complejidad y la suma para todos los componentes es expresado
en “Puntos funcionales sin ajustar”. Los factores técnicos de
complejidad se determinan, estimando el grado de influencia de
algunos componentes “características generales de aplicación”. El
grado de influencia en la escala recorre de cero (no presente o no
influenciada) hasta 5 (influencia fuerte).

La suma de las 14 características, que es el Grado Total de Influencia (DI), se convierte

al Factor Técnico de Complejidad (TCF) calculándose:
CALIDAD DE SOFTWARE
12

TCF = 0.65 + 0.01 * _Di (3.1)

El valor de Di, donde los valores de ajuste de complejidad i va de

1 a 14 según las respuestas de las preguntas

Valores de Di
No presente o no influencia = 0
Influencia insignificante o incidental = 1
Influencia moderada = 2
Influencia promedio o medio = 3
Influencia significante = 4
Influencia esencial o fuerte, a través de = 5

Los valores constantes de la ecuación anterior y los pesos que se

aplican a las cuentas de los dominios de información se
determinan empíricamente.

El tamaño intrínseco relativo del sistema en Puntos Funcionales

(FP´s) se calcula con ayuda de la tabla 3.4, utilizando la siguiente
fórmula:
CALIDAD DE SOFTWARE
12

FP´s = UFP´s * TCF

CALIDAD DE SOFTWARE
13

Podemos notar que los Puntos Funcionales son por lo tanto

números dimensiónales en una escala arbitraria.

Los valores de la información mostrados se definen a continuación:

1. Entradas Externas (o número de entradas de usuario).
Se suma cada entrada dada por el usuario, donde nos
proporcione distintos datos orientados a la aplicación. Estas se
diferencian de las peticiones.
2. Salidas Externas (o número de salidas de usuario).
Se suma cada salida que le proporcionará al usuario
información orientada a la aplicación (informes, pantallas,
mensajes de error, etc.). Los elementos de datos particulares
de un informe no se cuentan de forma separada.
3. Archivos Internos Lógicos o Número de archivos.
Se suma cada archivo maestro lógico (grupo lógico de datos
que sean parte de una base de datos o un archivo
independiente).
4. Archivos de Interfaz Externa o Número de interfaces externas.
Se suman todas las interfaces legibles por la máquina (archivos
de datos de cinta o discos, etc.) que se utilizan para transmitir
información a otro sistema.
5. Indagaciones externas o Número de peticiones de usuario.
La petición es una entrada dada que nos va a producir una
respuesta inmediata del software en forma de salida. Las
peticiones se cuentan por separado.
6. Total de Puntos funcionales sin ajustar o Cuenta-Total.
Es la suma de todas las entradas obtenidas.

Cuando se calculan los puntos de función, éstos se utilizan de

forma análoga a las LDC (Líneas de Código) para normalizar
medidas de productividad, calidad y otros ámbitos de software,
como por ejemplo:
 Errores por Puntos de Función.
 Defectos por Puntos de Función.
 Costo (dinero) por Puntos de Función.
 Página de documentación por Puntos de Función.
CALIDAD DE SOFTWARE
13
 Puntos de Función por persona-mes.

Las razones de Albrecht para proponer los Puntos Funcionales

como medidas de tamaño de un sistema son: [Pressman ‘98]:
 Estas medidas aíslan el tamaño intrínseco del sistema de los factores del
medio, facilitando el estudio de factores que influyen en la producción.
 Estas medidas están basadas; en las observaciones de los usuarios
externos del sistema, y es tecnología independiente.
 Estas medidas pueden determinarse al inicio del ciclo de desarrollo lo que
permite utilizar los Puntos Funcionales en la estimación de procesos.
 Los Puntos Funcionales pueden ser entendidos y evaluados por usuarios
que no son técnicos
CALIDAD DE SOFTWARE
13

5. MEDIDAS DE COMPLEJIDAD DE HALSTEAD

Las medidas fueron desarrolladas por Maurice Halstead para
determinar una medida cuantitativa de la complejidad directa de
los operarios y operandos en el módulo. Entre las métricas de
software más avanzadas, éstos son indicadores fuertes de
complejidad de código; se basa ampliamente en la evidencia
empírica encontrada en el trabajo del “Maintainability Index Work”,
pero existen la evidencia de que las medidas de Halstead son
también útiles durante el desarrollo, para valorar la calidad de
código en aplicaciones computablemente- densas.

Las medidas de Halstead se basan en cuatro números de

escalar, que serán derivados directamente del código de fuente
del programa, tales como:

n1 = el número de distintos
operador n2 = el número de
distintos operandos N1 = el
número total de operandos
N2 = el número total de operador

De estos números, cinco medidas se derivan:

6. PARADIGMA META / PREGUNTA / MÉ TRICA

El Paradigma Meta/Pregunta/Métrica (Goal-Question–Metric),
provee un mecanismo excelente para la definición de un programa
de medición basado en metas. Funciona de la siguiente manera
[Marty A. ‘90]:

1. El primer paso es definir una o más metas medibles. Éstas pueden ser
metas estratégicas de un alto nivel, como minimizar el costo o maximizar la
satisfacción del usuario. Se puede especificar metas como la evaluación de
la efectividad de procesos nuevos o determinar si un producto está listo para
CALIDAD DE SOFTWARE
13
ser liberado al usuario.
2. El segundo paso es definir las preguntas necesarias para ser contestadas, y
determinar si la meta es cumplida.
3. El paso final es determinar que métricas son necesarias para contestar cada
pregunta.

7. CICLO DEL TIEMPO

El ciclo de tiempo es una medida que nos proporciona el tiempo
se emplea para llevar a cabo un proceso. Hay dos medidas de
tiempo: [John A. ‘91]
1. Ciclo de tiempo estático se utiliza el tiempo promedio actual que se emplea
para ejecutar el proceso. Por ejemplo que tiempo emplea un módulo en
corregir una falla y ejecutar un caso de prueba.
CALIDAD DE SOFTWARE
13

2. Ciclo de tiempo dinámico es calculado al dividir el número de elementos en

progreso (elementos que únicamente han completado el proceso
parcialmente) entre los nuevos elementos comenzados y nuevos elementos
terminados durante el periodo.

Conociendo el ciclo del tiempo para los subprocesos en el proceso

de desarrollo de software se podrá hacer una mejor estimación del
plan y de los recursos requeridos, también nos permite monitorear
el impacto de las actividades del proceso en el mejoramiento del
ciclo de tiempo para este proceso.

El siguiente ejemplo ilustra el cálculo de métricas del ciclo de

tiempo estático y del ciclo de tiempo dinámico:

Ciclo del tiempo estático:

Calendario de tiempo para completar el
proceso: Módulo A: 5 días
Módulo B: 10 días
Módulo C: 7 días
Módulo D: 8 días
(5+10+7+8)/4 = 7.5
días

Ciclo de tiempo dinámico:

Total de elementos en progreso / (elementos
iniciados + elementos completados)/ 2
52 módulos iniciados en este
mes 68 módulos terminados
en este mes
12 módulos en progreso en este mes
(12/ ( ( 52+68) /2 ) ) * 30 días en el mes = 6 días

8. DIFERENTES ENFOQUES DE METRICAS

La relación entre las líneas de código y los puntos de función
depende del lenguaje de programación que se utilice para
implementar el software y de la calidad del diseño. Las medidas
LDC y PF se utilizan a menudo para extraer métricas de
productividad. Esta invariabilidad conduce a la discusión sobre el
uso de tales datos. Se debe comparar la relación LDC/personas-
mes (o PF/PM) de un grupo con los datos similares de otro
grupo?, ¿Deben los administradores evaluar el rendimiento de las
personas usando estas medidas? La respuesta a estas preguntas
es un terminante “No”. La razón para esta respuesta es que hay
muchos factores que influyen en la productividad, haciendo que la
CALIDAD DE SOFTWARE
13
comparación de “peras y manzanas” sea mal interpretada con
facilidad. Basili y Zelkowitz definen cinco factores importantes que
inciden en la productividad del software [Charles R.
Symons´91]:

1. Factores humanos.
El tamaño y la experiencia de la organización de desarrollo.
2. Factores del problema.
La complejidad del problema que se debe resolver y el número
de cambios en las restricciones o los requisitos del diseño.
3. Factores del Proceso.
Técnicas del análisis y diseño que se utilizan, lenguajes y
herramientas CASE y técnicas de revisión.
4. Factores del producto.
Fiabilidad y rendimiento del sistema basado en computadora.
5. Factores del recurso.
CALIDAD DE SOFTWARE
13

Disponibilidad de herramientas CASE, y recursos de hardware y software.

Si uno de los factores de productividad está por encima de la

media (altamente favorable) para un proyecto dado, la
productividad de desarrollo del software será significativamente
más alta que el mismo factor por debajo de la media
(desfavorable).

Recursos, Procesos y Productos

La primera obligación en cualquier actividad de medición de
software es el identificar las entidades y atributos de interés
que deseamos medir.
Sabiendo de antemano que una entidad es un objeto o un
evento y un atributo son las características o propiedades
del software a medir. En el software hay tres clases de
entidades cuyos atributos vamos a medir y se muestra en la
figura [Anneliese von M. ’91].

Recursos: son los artículos que corresponde a las entradas a procesos.

Procesos: es cualquier software relacionado con las

actividades, teniendo éstos normalmente un factor de
tiempo.

Productos: cualquier artefacto; liberados o documentos en

el cuál surja fuera de los procesos.
CALIDAD DE SOFTWARE
13

Autoevaluación
 Calcular el número de Puntos de Función del Sistema en estudio de tipo Medio
descrito en la tabla adjunta descrito en la tabla adjunta.

Parámetros del Sistema en estudio para el cálculo de la Métrica de Puntos de

Función:

Nº Entradas de Usuario 10
Nº de Salidas de Usuario 5
Nº de Peticiones al 7
usuario
Nº de Archivos 4
Nº de Interfaces externos 10

P1 2 P8 3
P2 3 P9 5
P3 1 P10 2
P4 5 P11 1
P5 3 P12 0
P6 0 P13 5
P7 0 P14 2

Parámetros de la Métrica Puntos de Función:

Parámetro Simple Medio Complejo

Nº Entradas de Usuario 3 4 6
Nº de Salidas de Usuario 4 5 7
Nº de Peticiones al usuario 3 4 6
Nº de Archivos 7 10 15
Nº de Interfaes externos 5 7 10
CALIDAD DE SOFTWARE
13