Metricas SW

INGENIERIA DE SOFTWARE II
MÉTRICAS DE SOFTWARE
El término “Métricas del Software” comprende muchas actividades, todas ellas

relacionadas de alguna manera con la idea de mejorar la calidad del software.
Siendo una métrica una medida estadística, estas medidas son aplicables a todo el,
ciclo de vida del desarrollo desde la iniciación, cuando debemos estimar los costos,
al seguimiento y control de la fiabilidad de los productos finales, y a la forma en que
los productos cambian a través del tiempo debido a la aplicación de mejoras. Un
ingeniero del Software recopila medidas y desarrolla métricas para obtener
indicadores.
Conceptos básicos
La teoría de la representación de la medición establece tanto los principios
generales de la medición como su validez. Esta teoría trata de expresar:
• Mundo formal de forma numérica
• las entidades del mundo real (o mundo empírico)
• la correspondencia entre ambos mundos
Las entidades en la Ingeniería del Software son los procesos, los recursos
(personal, oficinas, etc.)
Conceptos básicos
El estándar ISO/IEC 15939 define:
Entidad: objeto que va a ser caracterizado mediante una medición de sus atributos
Atributo : característica medible de una entidad, ejemplo: atributos del código fuente
pueden ser las líneas de código o su complejidad
Medición : es el proceso por el que se asignan números o símbolos a atributos de entidades
del mundo real para describirlos según unas reglas definidas de antemano
Medida : es la evaluación cuantitativa del grado en el cual un producto o proceso software
posee un atributo determinado, por ejemplo: a la entidad Código fuente de XY
componente
Líneas de código Complejidad

1500 Alta
Conceptos básicos
El estándar ISO/IEC 15939 define:
Entidad: objeto que va a ser caracterizado mediante una medición de sus atributos
Atributo : característica medible de una entidad, ejemplo: atributos del código fuente
pueden ser las líneas de código o su complejidad
Medición : es el proceso por el que se asignan números o símbolos a atributos de entidades
del mundo real para describirlos según unas reglas definidas de antemano
Medida : es la evaluación cuantitativa del grado en el cual un producto o proceso software
posee un atributo determinado, por ejemplo: a la entidad Código fuente de XY
componente.
Líneas de código Complejidad
1500 Alta
Escala: conjunto de valores que permite establecer relaciones
entre medidas. Con frecuencia dicho conjunto es continuo, está ordenado y viene
delimitado por un punto inicial y otro final
Tipos de escalas de medición

Escala nominal: Aquella formada por categorías entre las cuales no existe ningún orden, por
lo que la única relación que se puede aplicar es la de igualdad, ejemplo sexo: {masculino,
femenino}, clasificación de los módulos según su lenguaje de programación: {laya,
C++, Phyton, COBOL, Ruby...}.
Escala ordinal: Aquella en la que se definen categorías, pero, a diferencia de la escala
nominal, existe una relación de orden «es menor que» entre ellas, ejemplo: El tipo de error
en un programa, que podría clasificarse como {Leve, Moderado o Grave}.
Escala intervalo: En este tipo de escala la distancia entre intervalos es conocida y siempre la
misma, si bien no tienen un valor inicial de referencia o cero absoluto, ejemplo: es el de la
escala centígrada o Celsius para la temperatura.
Tipos de escalas de medición
Escala de ratio : Este tipo de escalas es el que más información proporciona y por tanto el
que permite llevar a cabo análisis más interesantes y completos. Tienen un valor inicial de
referencia o cero absoluto, y permiten definir ratios coherentes con los valores de la escala,
por lo que se pueden comparar los valores estableciendo proporciones. El ejemplo clásico
es el de la escala Kelvin de medición de temperaturas. En la Ingeniería del Software, un
ejemplo de este tipo de escalas es la longitud de un programa en líneas de código, que
permite decir que un programa es el doble de largo o la mitad de largo que otro.
Escala absoluta : Escalas con las características de las escalas anteriores, si bien consisten
simplemente en la cuenta sin transformación del número de entidades. El número de
programadores involucrado en un desarrollo, algo que sólo se puede medir contando, es un
ejemplo de escala absoluta.
Clasificación de las medidas

Una clasificación habitual consiste en dividir las medidas de un atributo en dos tipos,
directas e indirectas:
Medidas directas: las medidas directas de un atributo son aquellas que pueden ser
obtenidas directamente de la entidad sin necesidad de ningún otro atributo. Ejemplos de
medidas directas en la Ingeniería del Software serían la longitud del código, el número de
defectos durante los 6 primeros meses del sistema en producción o las horas de trabajo de
un programador en un proyecto, costos, números de personas…velocidad de ejecución…
Medidas indirectas: son aquellas que se derivan de una o más medidas de otros atributos.
Se definen y calculan, por tanto, a partir de otras medidas. Un ejemplo de medida indirecta
es la densidad de defectos de un módulo, que se define como el número de defectos del
módulo dividido por su tamaño.
Clasificación de las medidas

Otra clasificación diferencia entre medidas objetivas y subjetivas, pues dependiendo de uno
u otro tipo éstas se emplean como base de muy diferentes estudios:
Medidas objetivas: una medida cuyo valor no depende del observador. Ejemplo tamaño del
producto por numero de líneas de código.
Medidas subjetivas: son aquellas en las que la persona que realiza la medición puede
introducir factores de juicio en el resultado. No obstante, el interés de estas medidas está
en que incluyen percepciones, opiniones y juicios que en ciertos casos resultan valiosos.
Ejemplo: nivel de experticia de un desarrollador
¿Qué medir en la Ingeniería del Software?

Productos. Cualquier artefacto, entregable o documento que resulta de cualquiera de las
actividades (procesos) del ciclo de vida del software. El código fuente, las especificaciones
de requisitos, los diseños, el plan de pruebas y los manuales de usuario son algunos
ejemplos de productos.
Producto Atributos internos Atributos externos
Especificaciones Diseño Tamaño, reutilización, etc. Calidad, legibilidad
Tamaño,acoplamiento,cohe- Calidad, complejidad
Código sión, complejidad, etc. Facilidad de mantenimiento,
fiabilidad
Casos de prueba ... Tamaño, complejidad... Calidad
...
Número de casos,
%cobertura... ...

Procesos. Todas las actividades del ciclo de vida del software: requisitos, diseño,
construcción, pruebas, mantenimiento, etc. Las mediciones en los procesos van en
caminadas, en primer lugar, a conocer el estado de los procesos y cómo se llevan a cabo,
para después mejorarlos. Algunas de las métricas relacionadas con los procesos son el
tiempo invertido en las actividades o el tiempo para reparar un defecto.
Attributos internos Atributos Externos
Proceso .
Tiempo, esfuerzo, numero de Calidad, coste, estabilidad

Requisitos
requisitos Tiempo, esfuerzo, numero Calidad, coste, estabilidad
Diseno
de errores, etc. Tiempo, esfuerzo,
Pruebas ...
numero de errores, etc. ...
...

Recursos. Cualquier entrada de una actividad. Por ejemplo, el número de personas por
actividad o proyecto, las herramientas utilizadas (herramientas para requisitos,
compiladores, etc.), oficinas, computadoras, etc.
Recursos Atributos internos Atributos externos

Personal Edad, salario, Productividad,
Equipos experiencia
No de personas, estructura del
equipo Coste
Productividad,
No de de licencias, etc experiencia Usabilidad,
Software
Hardware ... Marca, coste, especificaciones
tecnicas, etc. ... fiabilidad Usabilidad,
fiabilidad
...
Atributos internos. Los atributos internos de un producto, proceso o recurso son aquellos
que se pueden medir directamente a partir de dicho producto, proceso o recurso. En un
modulo software, por ejemplo, podemos medir directamente el numero de defectos que se
han encontrado en el mismo.
Atributos externos. Los atributos externos de productos, procesos o recursos son aquellos
que los relacionan con el entorno. Se miden por medio de métricas indirectas y se deducen
en función de atributos internos. Como atributos externos se suelen considerar los
relacionados con la calidad.
Medidas del producto: atributos internos

Los atributos internos describen los productos de software de forma que dependen
únicamente del producto mismo.
• El producto puede ser descrito en función de su tamaño. Se pueden definir un conjunto
de atributos para medir el tamaño del software:
• Longitud: tamaño físico del producto.
• Funcionalidad: funciones que proporciona el producto al usuario.
• Complejidad (de tiempo o espacio): recursos necesarios (de tiempo o memoria de
ordenador) para implementar una solución particular.
• Las propiedades estructurales del software son atributos internos relacionados con la
calidad del producto. Los tipos de medidas estructurales son
• Flujo de control: secuencia en que se ejecutan las instrucciones.
• Flujo de datos: seguimiento de cómo los datos se crean y se manejan por un
programa.
• Estructura de los datos: organización de los datos independiente del programa.
• Los principales productos que resulta útil medir son la especificación, el diseño y el
código.

Longitud
Se han realizado muchas propuestas para contarlas. La más extendida es la de HP que no
contabiliza las líneas comentadas ni en blanco. La abreviatura que se usa para estas líneas es
NCLOC o ELOC (Effective lines of code).
Es útil medir por separado las líneas comentadas (CLOC) para calcular esfuerzo,
productividad, etc. La longitud total será:
LOC = NCLOC + CLOC
También puede se útil calcular la densidad de comentarios:
CLOC/LOC
Para propósitos tales como la prueba es importante conocer cuanto código ejecutable se
produce, para ello se mide el número de sentencias ejecutables (ES), ignorando los
comentarios, declaraciones de datos y cabeceras.
Otra propuesta consiste en contabilizar únicamente el código entregado al cliente. Se

cuenta el número de DSI ( delivered source instruction ) que incluye las declaraciones de
datos, las cabeceras y las instrucciones fuente

Longitud
Métricas de Halstead (1977): Considera un programa P como un conjunto de tokens
(unidad sintáctica más elemental distinguible por un compilador) que se pueden clasificar
como operandos y operadores.
Las métricas básicas para los tokens son:
n1: número de operadores únicos
n2: número de operandos únicos
N1: número total de ocurrencias de operadores
N2: número total de ocurrencias de operandos
Métricas compuestas para un programa:
El tamaño (N) o longitud de un programa: N = N1 + N2
Vocabulario (n) de un programa: n = n1 + n2
Longitud estimada: L = N1 log2 n1 + N2 log2 n2
Volumen: V = N log2 n donde N = N1 + N2 y n = n1 + n2
Esfuerzo de implementación: E = (n1 N2 N log2 n ) / (2 n2)
Tiempo de desarrollo de un programa: T = E / B en donde B : nº de discriminaciones
mentales por segundo. Lo fija en 18.

Referentes al código- Código
• Número de métodos estáticos.

• Afferent Coupling: Número de clases fuera del paquete que dependen de clases dentro
del paquete.
• Efferent Coupling: Número de clases dentro del paquete que dependen de clases fuera
del paquete.
• Nested Block Depth: profundidad en bloques anidados.
• Lack of Cohesion in Methods (LCOM), Falta de cohesión en métodos: Si es cerca de 1
quiere decir que se nos aconseja que dividamos la clase en varias subclases. LCOM3
alias LCOM*
Definitions used for LCOM2 and LCOM3
m number of procedures (methods) in class
a number of variables (attributes) in class
mA number of methods that access a variable (attribute)
sum(mA) sum of mA over attributes of a class
LCOM3 = (m - sum(mA)/a) / (m-1)

Longitud-Especificaciones y diseño
• Los documentos de especificación de requisitos y de diseño tienen representaciones de

muchos tipos (texto, gráficos, símbolos...)
• La medición del atributo longitud exige la identificación de elementos atómicos que
puedan contarse. Ejemplo:
• Diagramas de flujo de datos: procesos, entidades externas, almacenes de datos y

flujo de datos.
• Especificaciones algebraicas: salidas, funciones y operaciones
Se pueden definir páginas de documentación

como objetos atómicos.

funcionalidad
• Puntos de función (PF)
• Medida de la funcionalidad propuesta por Albrecht. Es una medida del producto y
del proceso que se sigue para desarrollarlo. Está centrado en la “funcionalidad” o
“utilidad” del producto
• Los PF se obtienen utilizando una relación empírica basada en items del producto y
valoraciones subjetivas de la complejidad del mismo.
• El paso previo al cálculo de los PF, es el cálculo de PFS ( unadjusted function point
count ), puntos de función sin ajustar:
• Se determinan los siguientes elementos de alguna representación del
software:
• Entradas externas :entradas de usuario que proporcionan datos a la
aplicación.Ej: ingreso de clientes. Modificación de clientes…
• Salidas externas :Salidas que proporcionan información al usuario.
• Consultas externas :peticiones interactivas que requieren una
respuesta.
• Ficheros externos :interfaces con otros sistemas legibles por la
máquina.
• Ficheros internos :ficheros maestros lógicos del sistema. Tablas….

Funcionalidad
• Puntos de función (PF)
• Medida de la funcionalidad propuesta por Albrecht. Es una medida del producto y
del proceso que se sigue para desarrollarlo. Está centrado en la “funcionalidad” o
“utilidad” del producto
• Los PF se obtienen utilizando una relación empírica basada en items del producto y
valoraciones subjetivas de la complejidad del mismo.
• El paso previo al cálculo de los PF, es el cálculo de PFS ( unadjusted function point
count ), puntos de función sin ajustar:
• Se determinan los siguientes elementos de alguna representación del
software:
• Entradas externas :entradas de usuario que proporcionan datos a la
aplicación.Ej: ingreso de clientes. Modificación de clientes…
• Salidas externas :Salidas que proporcionan información al usuario.
• Consultas externas :peticiones interactivas que requieren una
respuesta.
• Ficheros externos :interfaces con otros sistemas legibles por la
máquina.
• Ficheros internos :ficheros maestros lógicos del sistema. Tablas….

Medidas estructurales

• Complejidad ciclomática de McCabe:

La complejidad de un programa se mide mediante el número ciclomático ( v ) de su grafo de
flujo (F):
v (F) = e –n + 2
siendo e el número de aristas y n el número de nodos de F.
El número ciclomático:
• Mide el número de caminos linealmente independientes.
• Es un indicador útil de la dificultad de prueba y mantenimiento de un programa o
módulo.
• Para valores superiores a 10 en un determinado módulo, éste puede ser
problemático.
Complejidad ciclomática de McCabe:
• Determina en número de caminos a través de un programa.
• Sirve para predecir los módulos que son más propensos a errores.
• Determina el número de casos de prueba para asegurarse que todas las sentencia
de un componente han sido ejecutadas al menos una vez.

Complejidad ciclomática de McCabe:

• Determina en número de caminos a través de un programa.
• Sirve para predecir los módulos que son más propensos a errores.
• Determina el número de casos de prueba para asegurarse que todas las sentencia
de un componente han sido ejecutadas al menos una vez.
Herramientas: SonarQube
Medidas del producto: atributos Externos

Los atributos externos de un producto son aquellos que pueden medirse únicamente con
respecto a cómo el producto se relaciona con su entorno.
• Los atributos externos sólo son medibles cuando el producto está completo.
• La mayoría están relacionados con algún aspecto de la calidad
• Los modelos de calidad recogen atributos denominados factores de
calidad(atributos de alto nivel)
• Los factores de calidad puede descomponerse en atributos de bajo nivel
denominados criterios de calidad.
• Los criterios de calidad pueden asociarse con un conjunto de atributos de bajo
nivel medibles directamente obteniendo las métricas de calidad.

El modelo de calidad estándar ISO 9126
En el estándar denominado Evaluación de Productos Software: Características de calidad y
guías para su uso la calidad se descompone en 6 factores:
• Funcionalidad
• Fiabilidad
• Eficiencia
• Usabilidad
• Mantenibilidad
• Portabilidad

Medición de la portabilidad
• Se entiende por portabilidad la facilidad de mover una aplicación de un entorno a otro.
• La portabilidad se puede expresar como:
portabilidad = 1 - (ET/ER)
ET: medida de los recursos necesarios para mover el sistema a otro entorno ( Target
Environment ).
ER: medida de los recursos necesarios para crear el sistema en el entorno residente ( Re
sident Environment )
Medición de la densidad de defectos
• Para cualquier producto software se pueden considerar dos tipos de defectos

• Defectos conocidos
• Defectos latentes
• La densidad de defectos se puede definir en función de los primeros:
Densidad de defectos = número de defectos conocidos/tamaño del producto


Medida de la calidad basada en defectos
Se entiende por portabilidad la facilidad de mover una aplicación de un entorno a otro.
• Se puede medir la calidad en función de la relación
Tiempo empleado en la corrección de defectos “post-release” / Tiempo total de desarrollo

del sistema

Medidas de usabilidad
Boehm define usabilidad como el grado en que un producto se puede usar de forma
apropiada y práctica
• La buena usabilidad incluye:
• Manuales bien estructurados
• Buen uso de menús y gráficos
• Mensajes de error informativos
• Funciones de ayuda
• Interfaces consistentes
• La usabilidad se puede descomponer en atributos medibles de los siguientes tipos:

• Nivel de entrada
• Nivel de aprendizaje
• Facilidad de manejo

Medidas de usabilidad
Las medidas de usabilidad se suelen expresar en función del rendimiento del usuario. Se
han propuesto varias medidas de ese tipo:
• Efectividad de las tareas :

% de efectividad = (cantidad * calidad)/100
• Eficiencia temporal
eficiencia = efectividad/tiempo de tarea
• Periodo de tiempo productivo

periodo productivo = (tiempo de tarea - tiempo no productivo/tiempo de tarea) x
100
• Eficiencia relativa del usuario
eficiencia relativa = (eficiencia del usuario/eficiencia del experto) x 100
Medición de recursos
Los recursos son las entidades que se requieren en las actividades de proceso. Los recursos
incluyen cualquier entrada en la producción de software: personal, materiales,
herramientas, métodos, coste, productividad, .....
• El coste generalmente se mide, a partir del resto de los recursos, pudiéndose ver como
el coste de las entradas afecta al coste de las salidas
• La productividad es otro atributo externo importante que depende del proceso de
desarrollo. Normalmente se mide de la forma:
cantidad de salida/ cantidad de entrada
• La productividad de un recurso de software se mide en función de la proporción entre lo
que entra y sale de un proceso de producción de software.
• Ecuación de productividad: tamaño de software/ esfuerzo
• Unidades más utilizadas:
• Tamaño: líneas de código, PF,....
• Esfuerzo: personas-mes, persona-día,....
Productividad
• La medición de la productividad en función del número de líneas de código puede
presentar problemas:
• Dependencia de la técnica de contar
• Dependencia del lenguaje de programación
• Penalización del buen estilo de programación ...
• Para solventar esos problemas algunos autores han propuesto medir la productividad a
partir de la funcionalidad
• Ventajas de los puntos de función:
• Reflejan mejor el valor de la salida
• Pueden usarse en cualquier momento del ciclo de vida
• Se pueden utilizar para medir el progreso comparando los puntos de función
completados frente a los incompletos
Equipos
• La estructura del equipo del proyecto es un factor clave en la productividad.
• El factor particular que afecta a la productividad es la complejidad de las
comunicaciones: complejidad causada por el número de individuos implicados y el
método de comunicación requerido entre los miembros de un proyecto (Grady/Caswell).
• La experiencia del equipo se calcula hallando la media de las medidas de experiencia
individual.
• Algunos métodos como COCOMO utilizan escalas de medida ordinales (muy baja, baja,
nominal, alta y muy alta) para cada uno de los atributos de personal: experiencia en la
aplicación, en el lenguaje, en el uso de herramientas, ...
• La productividad del equipo no sólo depende de las productividades individuales de
sus miembros, sino también de la comunicación entre ellos.
Métodos y herramientas
• El modelo COCOMO incluye dos guías de coste: uso de herramientas y uso de técnicas
modernas de programación con escalas de medida (muy baja, baja, nominal, alta, muy
alta)
• Fenton propone la siguiente escala para evaluar el uso de herramientas por cada
diseñador:
0 No se usan herramientas.
1 Las herramientas sirven de ayuda en el 20% de la documentación.
2 Las herramientas se usan para documentar al menos el 50% del diseño de alto nivel.
3 Las herramientas se usan para documentar al menos el 50% del diseño de alto nivel
y diseño detallado.
4 Las herramientas se usan para el diseño y la generación automática de código de al
menos el 50% del sistema.
5 Las herramientas se usan para el diseño y la generación automática de código de al
menos el 90% del sistema.
Puntos de Función(FPA)
• La técnica del análisis de Puntos de Función (FPA) nos permite :

• Estimar el esfuerzo en un proyecto de software(HH)
• Estimar la duración de un proyecto de software (en meses)
• Estimar el costo de un proyecto de software
• La técnica del análisis de Puntos de Función (FPA) es considerada la principal

herramienta para la medición funcional de productos de software y de los
procesos involucrados en su desarrollo.
• Método estándar ISO/IEC 20926 de medición de software que cuantifica los
requisitos funcionales del sistema.
• Es una métrica aceptada como estándar en el mercado.
• IFPUG (International Function Point Users Group).
• Es una métrica que se puede aplicar en las primeras fases de desarrollo.
• Se basa en características fundamentalmente “Externas” de la aplicación a
desarrollar.
• Mide dos tipos de características:
• Los elementos de función (entradas, salidas, ficheros, etc.)
• Los factores de Complejidad.
• Antes de existir FPA la métrica que se utilizaba para la estimación de tamaños

de software era atreves de líneas de código.
• Antes de existir FPA, otra métrica de comparación de proyectos era la
medición de la cantidad de pantallas, informes o archivos que presenta un
software.
• Objetivos de FPA
• Ser una medida consistente
• Debe ser simple para minimizar el esfuerzo de la medición.
¿Como realizar la medición?
El análisis divide la especificación funcional en :

• Iteración ( con el usuario)
• Almacenamiento (función de datos)
• Componentes
• Entrada Externa (EI-> External input)
(pantallas donde el usuario ingresa datos)
• Salida Externa (EO-> External output)
(informes, gráficos, listados de datos)
• Consulta Externa (EQ->External query)
(recuperar y mostrar datos al usuario)(buscar)
• Archivo lógico interno (ILF-> Internal Logical File)
(pueden ser tablas en la base de datos)
• Archivo de Interfaz Externo(EIF->External Interface File)
(datos referenciados a otros sistemas)
(datos mantenidos por otros sistemas pero usados por el sistema actual)
¿Resumen Tips?
• Actualizar(EI)
• Insertar(EI)
• Eliminar(EI)
• Listar(EO)
• Informes o reportes(EO)
• Buscar(EQ)
• Tablas de DB (ILF)
Tabla de ponderaciones para EI, EQ y EO
Una vez obtenidos los diferentes elementos del sistema se utilizan las
siguientes tablas para asignar pesos en función del número de atributos que
tengan y el número de archivos a los que afecte.
Tabla de ponderaciones para ILF y EIF
Valores estándar (IFPUG) International Function Point User Group
Puntos de Función(FPA)- Proceso de Estimación Mediante PF

Puntos de Función(FPA)-Cálculo de los Puntos de Función Sin Ajustar

Por tanto los PFSA (Puntos de Función Sin Ajustar) se calculan como la suma de
los productos de cada componente por su peso determinado en la tabla
correspondiente.
PFSA = PFTe + PFTo + PFTq + PFTif + PFTef
Componente Bajo Medio Alto Total
EI Eb * 3 = _ Em * 4 = _ Ea * 6 = _ PFTe
EO Ob * 4 = _ Om * 5 = _ Oa * 7 = _ PFTo
EQ Qb * 3 = _ Qm * 4 = _ Qa * 6 = _ PFTq
ILF IFb * 7 = _ IFm * 10 = _ IFa * 15 = _ PFTif
EIF EFb * 5 = _ EFm * 7 = _ EFa * 10 = _ PFTef
PFSA
Puntos de Función(FPA)-Descripción de Totales por componente

PFTe : Total Puntos de Función para las entradas del sistema.
PFTo : Total Puntos de Función para las salidas del sistema.
PFTq: Total Puntos de Función para las consultas del sistema.
PFTif: Total Puntos de Función para los archivos internos del sistema.
PFTef: Total Puntos de Función para los archivos externos del sistema.
Puntos de Función(FPA)-Ejemplo
El sistema requerido es:

• Ingreso de clientes
• Modificación del cliente
• Eliminación de clientes
• Listado de clientes
• Reportes de Clientes por ciudad
• Tabla de clientes
El sistema requerido es:

• Ingreso de clientes(EI)
• Modificación del cliente(EI)
• Listado de clientes(EQ)
• Reportes de Clientes por ciudad(EO)
• Tabla de clientes(ILF)
Supongamos que luego de evaluar los factores, los niveles de complejidad fueron
los siguientes:
Calculo de PFSA –Puntos de función sin ajustar
Componente Tipo de Componente Nivel de Complejidad
Ingreso de clientes EI Bajo
Modificación del EI Medio
cliente
Listado de clientes EQ Bajo
Reportes de EO Medio
Clientes por ciudad
Tabla de clientes ILF Medio
Asignar los puntos de función no ajustados a cada uno:
Componente Tipo de Nivel de Puntos de
Componente Complejidad Función
Ingreso de EI Bajo 3
clientes
Modificación EI Medio 4
del cliente
Listado de EQ Bajo 3
clientes
Reportes de EO Medio 5
Clientes por
ciudad
Tabla de ILF Medio 10
clientes
Entonces el número de puntos de función no ajustado es de PFSA 25
Calculo de Puntos de función Ajustados PFA
Podemos aplicar un factor de ajuste, basado en 14 características generales de
sistema definidas por el IFPUG-FPA.
PFA=PFSA* [0.65+[0.01*ACT]]
La obtención de ACT se realiza a través de la siguiente tabla:
Estos valores se obtienen de un

documento estándar definido por
IFPUG-FPA documento
DETERMINACIÓN DE LOS NIVELES DE
INFLUENCIA adjunto documento
Calculo de Puntos de función Ajustados PFA
PFSA=25
PFA=25* [0.65+[0.01*32]]
PFA=25* 0,97=24,25
Estimar horas hombre (o días hombre) a partir de los puntos de función
Con los puntos de función puedes calcular las horas hombre aplicando un factor
de conversión, pues no necesariamente un punto función equivale a una hora
hombre.
HH=PFA*Horas PF promedio
Por ejemplo supongamos que hemos determinado que nuestra organización
toma 3 horas en producir 1 punto de función, entonces:
HH=24,25*3=72,75 o 9 días si se consideran 8 horas de trabajo diarias.

Metricas SW

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metricas SW

Cargado por

Copyright:

Formatos disponibles

INGENIERIA DE SOFTWARE II

El término “Métricas del Software” comprende muchas actividades, todas ellas

Líneas de código Complejidad

Tipos de escalas de medición

Tipos de escalas de medición

Clasificación de las medidas

Clasificación de las medidas

¿Qué medir en la Ingeniería del Software?

¿Qué medir en la Ingeniería del Software?

Tiempo, esfuerzo, numero de Calidad, coste, estabilidad

¿Qué medir en la Ingeniería del Software?

Recursos Atributos internos Atributos externos

¿Qué medir en la Ingeniería del Software?

Medidas del producto: atributos internos

Medidas del producto: atributos internos

Otra propuesta consiste en contabilizar únicamente el código entregado al cliente. Se

Medidas del producto: atributos internos

Medidas del producto: atributos internos

• Número de métodos estáticos.

Medidas del producto: atributos internos

• Los documentos de especificación de requisitos y de diseño tienen representaciones de

• Diagramas de flujo de datos: procesos, entidades externas, almacenes de datos y

Se pueden definir páginas de documentación

Medidas del producto: atributos internos

Medidas del producto: atributos internos

Medidas del producto: atributos internos

Medidas del producto: atributos internos

• Complejidad ciclomática de McCabe:

Medidas del producto: atributos internos

Complejidad ciclomática de McCabe:

Medidas del producto: atributos Externos

Medidas del producto: atributos Externos

Medidas del producto: atributos Externos

Medición de la densidad de defectos

• Para cualquier producto software se pueden considerar dos tipos de defectos

Densidad de defectos = número de defectos conocidos/tamaño del producto

Medidas del producto: atributos Externos

Tiempo empleado en la corrección de defectos “post-release” / Tiempo total de desarrollo

Medidas del producto: atributos Externos

• La usabilidad se puede descomponer en atributos medibles de los siguientes tipos:

Medidas del producto: atributos Externos

• Efectividad de las tareas :

• Periodo de tiempo productivo

• La técnica del análisis de Puntos de Función (FPA) nos permite :

• La técnica del análisis de Puntos de Función (FPA) es considerada la principal

• Antes de existir FPA la métrica que se utilizaba para la estimación de tamaños

El análisis divide la especificación funcional en :

Puntos de Función(FPA)- Proceso de Estimación Mediante PF

Puntos de Función(FPA)-Cálculo de los Puntos de Función Sin Ajustar

EIF EFb * 5 = _ EFm * 7 = _ EFa * 10 = _ PFTef

Puntos de Función(FPA)-Descripción de Totales por componente

PFTo : Total Puntos de Función para las salidas del sistema.

PFTq: Total Puntos de Función para las consultas del sistema.

El sistema requerido es:

El sistema requerido es:

Estos valores se obtienen de un

También podría gustarte