Métricas Técnicas

del Software

1
Introducción
 Se aplica las métricas para valorar la
calidad de los productos de ingeniería o los
sistemas que se construyen.
 Proporcionan una manera sistemática de
valorar la calidad basándose en un conjunto
de reglas claramente definidas.
 Se aplican a todo el ciclo de vida
permitiendo descubrir y corregir problemas
potenciales.

2
Calidad del Software
 Los requisitos del Software son la base de las
medidas de calidad. La falta de concordancia
con los requisitos es una falta de calidad.
 Unos estándares específicos definen un
conjunto de criterios de desarrollo que guían la
manera en que se hace la ingeniería del
Software. Si no se siguen los criterios , habrá
seguramente poca calidad.
 Existe un conjunto de requisitos implícitos que
ha menudo no se nombran. Si el software
cumple con sus requisitos explícitos pero falla
en los implícitos , la calidad del software no
será fiable.
3
Factores de calidad de
McCall
 Los factores que afectan la calidad se
pueden categorizar en:
 Factores que se pueden medir directamente,
como por ejemplo los defectos por punto de
función.
 Factores que se pueden medir sólo
indirectamente, como por ejemplo la
facilidad de uso o mantenimiento.
 En todos los casos debe aparecer la
medición. Debe ser posible comparar el
software (documentos, programas, datos)
con una referencia y llegar a una conclusión
sobre la calidad.
4
 Factores de calidad
McCall y colegas (1997)
Facilidad de Portabilidad
mantenimiento Reusabilidad
Interoperatividad
Flexibilidad
Facilidad de prueba
Revisión del Transición del
Producto producto

Operación
del producto

Corrección Fiabilidad Usabilidad Integridad Eficiencia

5
Operación del Producto
 Corrección : Hasta donde satisface un
programa su especificación y logra los
objetivos del cliente.
 Fiabilidad: Hasta dónde se puede esperar
que un programa lleve a cabo de su función
con la exactitud requerida.
 Eficiencia: La cantidad de recursos
informáticos y de código necesarios para
que un programa realice su función.

6
 Integridad: Hasta dónde se puede
controlar el acceso al software o a los
datos por personas no autorizadas.
 Usabilidad (facilidad de manejo):El
esfuerzo necesario para aprender a
operar los datos de entrada e
interpretar las salidas de un
programa.

7
Revisión del producto
 Facilidad de mantenimiento: El
esfuerzo necesario para localizar y
arreglar un error en un programa.
 Flexibilidad: El esfuerzo necesario
para modificar un programa operativo.
 Facilidad de prueba: El esfuerzo
necesario para probar un programa
para asegurarse de que realiza su
función pretendida.
8
Transición del producto
 Portabilidad: El esfuerzo necesario para
transferir el programa de un entorno de
sistema hardware y/o software a otro
entorno diferente.
 Reusabilidad ( capacidad de reutilización):
Hasta donde se puede volver a emplear un
programa ( o partes de un programa) en
otras aplicaciones.
 Interoperatividad: El esfuerzo necesario
para acoplar un sistema con otro.

9
 Es difícil desarrollar medidas directas de los
factores de calidad señalados
anteriormente, por consiguiente se definen
un conjunto de métricas para desarrollar
expresiones que utilicen los factores de
acuerdo a la siguiente relación:
Fq = c1 x m1 + c2 x m2 +….+cn x mn

Fq es factor de calidad
Cn son coeficientes de regresión
Mn son las métricas que afectan al factor
calidad
10
 Lamentablemente muchas de las métricas
definidas por McCall solamente pueden
medirse de manera subjetiva.
 Las métricas se acomodan en una lista de
comprobación que se emplea para puntuar
atributos específicos del software.
 El esquema de puntuación que se propone
es una escala del 0 (bajo) al 10 (alto)

11
Métrica para el esquema de
puntuación:
 Facilidad de auditoría: la facilidad con la
que se puede comprobar el cumplimiento
de los estándares.
 Exactitud: la exactitud de lo cálculos y el
control.
 Estandarización de comunicaciones: el
grado de empleo de estándares de
interfaces, protocolos y anchos de banda.
 Complección: el grado con que se ha
logrado la implementación total de una
función.
 Concisión :Lo compacto que es el
12
programa en términos de líneas de código
 Consistencia: El empleo de un diseño
uniforme y de técnicas de documentación a lo
largo del proyecto de desarrollo del software.
 Estandarización de datos: El empleo de
estructuras y tipos de datos estándares a lo
largo del programa.
 Tolerancia al error : el daño causado cuando
un programa encuentra un error.
 Eficiencia de ejecución: El rendimiento del
funcionamiento de un programa.
 Capacidad de expansión: El grado con que se
pueden ampliar el diseño arquitectónico, de
datos o procedimental.
 Generalidad: la amplitud de aplicación
potencial de los componentes del programa.
 Independencia del hardware: El grado con
13
que se desacopla el software del hardware
donde opera.
 Instrumentación:El grado con el que el
programa vigila su propio funcionamiento e
identifica los errores que ocurren.
 Modularidad: La independencia funcional
de componentes de programa.
 Operatividad: La facilidad de operación de
un programa.
 Seguridad: La disponibilidad de
mecanismos que controlan o protegen los
programas y los datos.
 Autodocumentación: El grado en que el
código fuente proporciona documentación
significativa.
 Simplicidad: El grado de facilidad con que
se puede entender un programa.

14
 Independencia del sistema de software:
El grado de independencia de programa
respecto a las características del lenguaje
de programación no estándar ,
características del sistema operativo y otras
restricciones del entorno.
 Trazabilidad: La capacidad de seguir una
representación del diseño o un componente
real del programa hasta los requisitos.
 Formación : El grado en que ayuda el
software a manejar el sistema a los nuevos
usuarios.

15
FURPS (Funcionality, Usability,
Reliability, Performance, Supportability)
 Hewlett Packard ha desarrollado un conjunto
de factores de calidad del software al que se le
ha dado el acrónimo de FURPS: funcionalidad,
facilidad de empleo, fiabilidad, rendimiento y
capacidad de soporte. Los factores de calidad
son cinco y se definen de acuerdo al siguiente
conjunto de atributos:
 Funcionalidad. Se valora evaluando el
conjunto de características y capacidades del
programa, la generalidad de las funciones
entregadas y la seguridad del sistema global.
 Facilidad de uso. Se valora considerando
factores humanos, la estetica, consistencia y
documentación general.
16
 Fiabilidad. Se evalúa midiendo la frecuencia y
gravedad de los fallos, la exactitud de las
salidas, el tiempo medio entre fallos, la
capacidad de recuperación de un fallo y la
capacidad de predicción del programa.
 Rendimiento. Se mide por la velocidad de
procesamiento, el tiempo de respuesta,
consumo de recursos, rendimiento efectivo total
y eficacia.
 Capacidad de soporte. Combina la capacidad
de ampliar el programa (extensibilidad),
adaptabilidad y servicios, así como la
capacidad de hacer pruebas, compatibilidad,
capacidad de configuración, la facilidad de
instalación de un sistema y la facilidad con que
se pueden localizar los problemas
17
Factores de Calidad ISO
9126
 El estándar identifica seis atributos clave de
calidad:
 Funcionalidad: El grado en que el software
satisface las necesidades indicadas por los
siguientes subatributos: idoneidad,
corrección, interoperatividad,conformidad y
seguridad.
 Confiabilidad: Cantidad de tiempo que el
software está disponible para su uso. Estaá
referido por los siguientes subatributos:
madurez, tolerancia a fallos y facilidad de
recuperación.
18
 Usabilidad: Grado en que el software es fácil
de usar. Viene reflejado por los siguientes
subatributos: facilidad de comprensión,
facilidad de aprendizaje y operatividad.
 Eficiencia: Grado en que el software hace
óptimo el uso de los recursos del sistema.
Viene reflejado por los siguientes subatributos:
tiempo de uso y recursos utilizados.
 Facilidad de mantenimiento: La facilidad con
que una modificación puede ser realizada. Está
indicada por los siguientes subatributos:
facilidad de análisis , facilidad de cambio,
estabilidad y facilidad de prueba.
 Portabilidad: La facilidad con que el software
puede ser llevado de un entorno a otro. Está
referido por los siguientes subatributos:
facilidad de instalación, facilidad de ajuste,
19 facilidad de adaptación al cambio
Paradoja de Jacob
Bronkowski
 “Año tras año ingeniamos
instrumentos más exactos con los que
observar la naturaleza con mas
exactitud. Y cuando miramos las
observaciones estamos
desconcertados de ver que todavís
son confusas y tenemos la sensación
de que son tan inciertas como
siempre”

20
Estructura para las métricas
del Software
 La medición asigna números o símbolos a
atributos de entidades en el mundo real. Para
conseguirlo es necesario un modelo de medición
que comprenda un conjunto consistente de reglas.
 Existe la necesidad de medir y controlar la
complejidad del software, es bastante difícil
obtener un solo valor para representar una
"métrica de calidad", sin embargo es posible
desarrollar medidas de diferentes atributos
internos del programa como ser: modularidad
efectiva, independencia funcional y otros atributos.
Estas métricas y medidas obtenidas pueden
utilizarse como indicadores independientes de la
calidad de los modelos de análisis y diseño.
21
 Los principios básicos de la medición,
sugeridos por Roche, pueden caracterizarse
mediante cinco actividades:
 Formulación. Obtención de medidas y
métricas del software apropiadas para la
representación del software en cuestión.
 Colección. Mecanismo empleado para
acumular datos necesarios para obtener las
métricas formuladas.
 Análisis. Cálculo de las métricas y la
aplicación de herramientas matemáticas.
 Interpretación. 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.
 Realimentación. Recomendaciones
obtenidas de la interpretación de métricas
técnicas transmitidas al equipo software.
22
 Ejiogu define un conjunto de atributos
que deberían acompañar a las
métricas efectivas del software. La
métrica obtenida y las medidas que
conducen a ello deberían ser:
 Simple y fácil de calcular.
 Empírica e intuitivamente persuasiva.
 Consistente y objetiva.
 Consistente en el empleo de unidades
y tamaños.
 Independiente del lenguaje de
programación.
 Un eficaz mecanismo para la
23 realimentación de calidad.
 La experiencia indica que una
métrica técnica se usa
únicamente si es intuitiva y fácil
de calcular. Si se requiere
docenas de contadores y se
han de utilizar complejos
cálculos, la métrica no será
ampliamente utilizada.

24
Métricas del Modelo de
Análisis
 En esta fase es deseable que las
métricas técnicas proporcionen una
visión interna a la calidad del modelo
de análisis. Estas métricas examinan
el modelo de análisis con la intención
de predecir el "tamaño" del sistema
resultante; es probable que el tamaño
y la complejidad del diseño estén
directamente relacionadas.
25
Métricas basadas en la
Función
 La métrica del punto de función (PF) se
puede utilizar como medio para predecir el
tamaño de un sistema obtenido a partir de
un modelo de análisis. Para visualizar esta
métrica se utiliza un diagrama de flujo de
datos, el cual se evaluar para determinar
las siguientes medidas clave que son
necesarias para el cálculo de la métrica de
punto de función:
 Número de entradas del usuario
 Número de salidas del usuario
 Número de consultas del usuario
 Número de archivos

26 Número de interfaces externas
 La cuenta total debe ajustarse
utilizando la siguiente ecuación:
 PF = cuenta-total x (0,65 + 0,01
x ∑Fi)
 Donde cuenta-total es la suma de todas
las entradas PF obtenidas de la figura
9.2 y Fi (i=1 a 14) son los "valores de
ajuste de complejidad".

27
  Para el ejemplo descrito en la figura 9.2 se asume que
la ∑Fi es 46 (un producto moderadamente complejo),
por consiguiente:
PF = 50 x (0,65 + 0,01 x 46) = 56

  Factor de ponderación   

Parámetro de medición Cuenta   Simple Media Compl.      

Número de entradas del usuario  3  X  3  4  6  =  9 

Número de salidas del usuario  2  X  4  5  7  =  8 

Número de consultas del usuario  2  X  3  4  6  =  6 

Número de archivos  1  X  7  10  15  =  7 

Número de interfaces externas  4  X  5  7  10  =  20 

Cuenta total 50 

28 Fig. 9.2 Cálculo de puntos de función 
 Basándose en el valor previsto del PF
obtenido del modelo de análisis, el equipo
del proyecto puede estimar el tamaño global
de implementación de las funciones de
interacción. Asuma que los datos de los que
se dispone indican que un PF supone 60
líneas de código (se utilizará un lenguaje
orientado a objetos) y que en un esfuerzo de
un mes-persona se producen 12 PF. Estos
datos históricos proporcionan al gestor del
proyecto una importante información de
planificación basada en el modelo de análisis
en lugar de estimaciones preliminares

29
Otras Métricas para el
Modelo de Análisis
 La Métrica Bang [De Marco]
 Puede aplicarse para desarrollar una
indicación del tamaño del software a
implementar como consecuencia del modelo
del análisis.
 Métricas de la calidad de la especificación:
 Davis y colegas proponen una lista de
características que pueden emplearse para
valorar la calidad del modelo de análisis y la
correspondiente especificación de requisitos

30
Métricas del modelo de
Diseño
 La gran ironía de las métricas de diseño
para el software es que las mismas están
disponibles, pero la gran mayoría de los
desarrolladores de software continúan sin
saber que existen.
 No son perfectas y continúa el debate sobre
su eficacia y como deberían aplicarse.
 Algunos expertos señalan que es necesario
mayor experimentación hasta que se
puedan emplear adecuadamente. Sin
embargo el diseño sin medición es una
alternativa inaceptable.
31
Métricas de diseño de alto nivel

 Se concentran en las características

de la arquitectura del programa , con
énfasis en la estructura arquitectónica
y en la eficiencia de los módulos.
 Estas métricas son de caja negra en
el sentido que no requieren ningún
conocimiento del trabajo interno de un
módulo en particular del sistema.

32
Card y Glass definen las siguientes
tres medidas de complejidad

 La complejidad estructural, S(i), de un

módulo i se define de la siguiente
manera: S(i)=f2out(i). Donde fout(i) es
la expansión del módulo i.La
expansión indica el número de
módulos que son invocados
directamente por el módulo i.

33
 La complejidad de datos, D(i),
proporciona una indicación de la
complejidad en la interfaz interna de
un módulo i y se define como:
D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el
número de variables de entrada y
salida que entran y salen del módulo
i.

34
 La complejidad del sistema, C(i), se define
como la suma de las complejidades
estructural y de datos : C(i)= S(i) + D(i)
 A medida que crecen los valores de
complejidad , la complejidad arquitectónica
o global del sistema también aumenta. Esto
lleva a una mayor probabilidad de que
aumente el esfuerzo necesario para la
integración y las pruebas.

35
Fenton sugiere varias métricas de morfología
simples que permiten comparar diferentes
arquitecturas mediante un conjunto de
dimensiones directas.

36
 Métricas a aplicar
 Tamaño= n + a . Donde n es el
número de nodos (módulos) y a es el
número de arcos (líneas de control).
Para la arquitectura mostrada se tiene
tamaño= 17+18=35.
 Profundidad= camino más largo
desde el nodo raíz a un nodo hoja.
Para el ejemplo Profundidad= 4
 Amplitud=número máximo de nodos
de cualquier nivel de la arquitectura.
Para el ejemplo amplitud= 6

37
 Relación arco a nodo, r=a/n, mide la
densidad de conectividad de la
arquitectura y proporciona una
indicación sencilla de acoplamiento
de la arquitectura. Para el ejemplo
r=18/17= 1.06

38
Métricas del Código Fuente
 La teoría de la ciencia del software
propuesta por Halstead es probablemente
la medida de complejidad mejor conocida y
minuciosamente estudiada. La ciencia del
software propuso la primera ley analítica y
cuantitativa para el software de
computadora.
 Utiliza un conjunto de medidas primitivas
que pueden obtenerse una vez que se han
generado o estimado el código después de
completar el diseño.
39
Estas medidas son:

 n1: número de operadores diferentes

que aparecen en le programa.
 n : número de operandos diferentes
2
que aparecen en el programa.
 N : número total de veces que
1
aparece el operador.
 N : número total de veces que
2
aparecen el operando.
40
 Halstead utiliza medidas primitivas para
desarrollar expresiones par la longitud
global del programa; volumen mínimo
potencial para un algoritmo; el volumen real
(número de bits requeridos para especificar
un programa); el nivel del programa (una
medida de la complejidad del software);
nivel del lenguaje (una constante para un
lenguaje dado); y otras características tales
como el esfuerzo de desarrollo,,tiempo de
desarrollo e incluso el número esperado de
fallos en el software.

41
  Halstead propone las siguientes métricas:
 Longitud N se puede estimar como: N =
n1log2n1 + n2log2n2.
 Volumen de programa se define como:
V = N n1log2(n1 + n2). Tomando en cuenta
que V variará con el lenguaje de
programación y representa el volumen de
información (en bits) necesarios para
especificar un programa.

42
Ejemplo:
Programa de ordenación por intercambio
SUBROUTINE SORT(X,N) 
  

   DIMENSION X(N) 

   IF (N .LT. 2) RETURN 

   DO 20 I=2, N 

      DO 10 J=1, I 

      IF (X(I) .GE. X(J)) GO TO 10 

         SAVE = X(I) 

         X(I) = X(J) 

         X(J) = SAVE 

10  CONTINUE 

20  CONTINUE 

   RETURN 

   END 
43
    Operador Cuenta

1  Fin de sentencia  7 

2  Subíndices de arreglos  6 

3  =  5 

4  IF()  2 

5  DO  2 

6  ,  2 

7  Fin de programa  1 

8  .LT.  1 

9  .GE.  1 

10  GO  TO 10  1 

Total  28 

De esta tabla se desprenden los valores

de n1=10 y N1=28.
44
    Operando Cuenta

1  X  6 

2  I  5 

3  J  4 

4  N  2 

5  2  2 

6  SAVE  2 

7  1  1 

Total  22 

De esta tabla se desprenden los valores de n2=7 y N2=22.

45
Métricas para las Pruebas
 La mayoría de las métricas para pruebas se
concentran en el proceso de prueba, no en las
características técnicas de las pruebas mismas. En
general, los responsables de las pruebas deben fiarse
en las métricas de análisis, diseño y código para que
sirvan de guía en el diseño y ejecución de los casos
de prueba.
 El esfuerzo de las pruebas también se puede estimar
utilizando métricas obtenidas de las medidas de
Halstead. Usando la definición del volumen de un
programa, V, y nivel de programa, NP, el esfuerzo de
la ciencia del software puede calcularse como:
 NP = 1/[(n1/2) x (N2/n2)] (Ec. 9.1)
 e = V/NP (Ec. 9.2)

46
 El porcentaje del esfuerzo global de
pruebas a asignar a un módulo k se puede
estimar utilizando la siguiente relación:
Porcentaje de esfuerzo de
pruebas(k) = e(k)/∑e(i) (Ec. 9.3)
 Donde e(k) se calcula para el módulo k
utilizando las ecuaciones (Ec. 9.1) y (Ec.
9.2), la suma en el denominador de la
ecuación (Ec. 9.3) es la suma del esfuerzo
de la ciencia del software a lo largo de
todos los módulos del sistema.
47
 A medida que se van haciendo las pruebas, tres
medidas diferentes proporcionan una indicación de la
compleción de las pruebas:
 Medida de amplitud de las pruebas. Proporciona una
indicación de cuantos requisitos se han probado del
numero total de ellos. Indica la compleción del plan de
pruebas.
 Profundidad de las pruebas. Medida del porcentaje de
los caminos básicos independientes probados con
relación al número total de estos caminos en el
programa. Se puede calcular una estimación
razonablemente exacta del número de caminos
básicos sumando la complejidad ciclomática de todos
los módulos del programa.
 Perfiles de fallos. Se emplean para dar prioridad y
categorizar los errores. La prioridad indica la severidad
del problema. Las categorías de los fallos
proporcionan una descripción de un error, de manera
que se puedan llevar a cabo análisis estadístico de
errores.
48
 MÉTRICAS DEL
MANTENIMIENTO
 Todas las métricas descritas pueden utilizarse para el
desarrollo de nuevo software y para el mantenimiento
del existente.
 El estándar IEEE 982.1-1988 sugiere el índice de
madurez del software (IMS) que proporciona una
indicación de la estabilidad de un producto software
basada en los cambios que ocurren con cada versión
del producto. Con el IMS se determina la siguiente
información:
 MT= Número de módulos en la versión
 actualFc= Número de módulos en la versión actual
que se han cambiado
 Fa= Número de módulos en la versión actual que se
han añadido
 Fe= Número de módulos en la versión actual que se
han eliminado
49
 El índice de madurez del software se
calcula de la siguiente manera:
• IMS= [MT - (Fc + Fa + Fe)]/MT
 A medida que el IMS se aproxima a 1
el producto se empieza a estabilizar.
El IMS puede emplearse también
como métrica para la planificación de
las actividades de mantenimiento del
software.

50
Medición y métricas de
Software [Sommerville]cap.24
 La medición del software se refiere a derivar
a un valor numérico para algún atributo de
un producto de software o un proceso de
software.
 Comparando estos valores entre ellos y con
los estándares aplicados en la organización,
es posible sacar conclusiones de la calidad
del software o de los procesos del software.
 Sin embargo , aún es poco común la
utilización de medidas y métricas
sistemáticas de software. La reticencia al
51
uso es debido a que los beneficios noson
claros.
 Por otra parte no existen estándares para
las métricas y, por lo tanto existe ayuda
limitada para la recolección y análisis de
datos.
 Las métricas son de control o de predicción:
 Control: por lo general se asocian con los
procesos del software. Ejemplo, el esfuerzo
y el tiempo promedio requerido para reparar
los defectos reportados.
 Predicción : se asocian con los productos
del software. Ejemplo, la complejidad
ciclomática de un módulo, la longitud
promedio de los indicadores en un programa
y el número de atributos y operaciones
asociadas con los objetos de un diseño.

52
Toma de decisiones
administrativas

Proceso de Producto de
Software software

Medidas
de Control Medidas de
predicción

Decisiones
administrativas

Ambas métricas influyen en la toma de

decisiones administrativas
53
Métricas para predecir la
calidad
 A menudo es imposible medir los atributos
de calidad del software en forma directa.
 Los atributos como la complejidad , la
mantenibilidad y la comprensión se ven
afectados por diversos factores y no existen
métricas directas para ellos.
 Más bien es necesario medir un atributo
interno del software ( como el tamaño) y
suponer que existe una relación entre lo
que se puede medir y lo que se quiere
saber.
 De forma ideal , existe una relación clara
válida entre los atributos de software
54 internos y externos.
 Relación entre los atributos
externos e internos
Número de parámetros
del procedimiento
Mantenibilidad

Complejidad ciclomática
Fiabilidad
Tamaño del programa
Portabilidad en líneas de código

Número de mensajes de
Usabilidad error

Extensión del manual

de usuario
No dice qué relación es
55
Métricas del producto
 Se refiere a las características del software.
 En general las organizaciones construyen
sus bases de datos históricas para
relacionar las mediciones obtenidas.
 Se dividen en dos clases:
 Métricas dinámicas recolectadas por las
mediciones hechas en un programa en
ejecución.
 Las métricas estáticas recolectadas por las
mediciones hechas en las representaciones
del sistema como el diseño, el programa o la
documentación.

56
 Estas diferentes métricas están
relacionadas con diversos atributos de
calidad.
 Las métricas dinámicas ayudan a a valorar
la eficiencia y la fiabilidad de un programa
mientras que las métricas estáticas ayudan
a valorar la complejidad, la comprensión y
la mantenibilidad de un sistema de
software.
 Las métricas estáticas , por otro lado,
tienen una relación indirecta con los
atributos de calidad.
 Las métricas específicas relevantes
dependen del proyecto, de las metas del
equipo de administración de la calidad y del
tipo de software a desarrollar.

57
Medición del proceso
cap. 25
 Son datos cuantitativos de los
procesos del software.
 Se utilizan para evaluar si la eficiencia
de un proceso ha mejorado. Por
ejemplo se puede medir el esfuerzo y
tiempo dedicado a las pruebas. Las
mejoras efectivas para los procesos
de prueba reducen el esfuerzo , el
tiempo de prueba o ambos.

58
Se pueden recolectar tres
clases de métricas del proceso:
1. El tiempo requerido para completar un
proceso particular:
 Tiempo total dedicado al proceso, el
tiempo de calendario, el tiempo invertido en
el proceso por ingenieros particulares, etc.
2. Los recursos requeridos para un proceso
en particular:
 Los recursos pueden ser el esfuerzo total
en personas-días, los costos de viajes, los
recursos de cómputo,etc.
59
1. El número de ocurrencias de un evento en
particular:
 Ejemplos de eventos que se pueden
supervisar son el número de defectos
descubiertos durante la inspección del
código, el número de peticiones de
cambios en los requerimientos, el número
promedio de líneas de código modificadas
en respuesta a un cambio de
requerimientos, etc.

60
Estimación del Costo del
Software Cap. 23
 La estimación y calendarización del
proyecto se llevan a cabo de forma
conjunta.
 Sin embargo se debe contar con
estimaciones previas para ver los
efectos sobre la calendarización y
éstas se actualizan de forma regular.
 Permite la utilización efectiva de los
recursos y una adecuada planeación.
61
Parámetros involucrados en
el costo total de un proyecto:
 Costos de hardware y software ,
incluyendo mantenimiento.
 Costos de viajes y capacitación

 Costos de esfuerzo ( pago a los

ingenieros de Software)
Para muchos proyectos , el costo
dominante es el costo de esfuerzo.

62
Costos de esfuerzo:
 Costos de proveer, calentar e iluminar las
oficinas.
 Costos del personal de apoyo como
contadores , secretarias, limpiadores y
técnicos.
 Costos de las redes y las comunicaciones.
 Costos de los recursos centralizados como
bibliotecas, los recursos recreativos,etc.
 Costos de seguridad social y de beneficio
de empleados como las pensiones y
seguros de salud.

63
Factores que afectan la
asignación de precios al software.
 Oportunidad de mercado: penetración de
mercado con cotización de bajos costos al
inicio.
 Incertidumbre: Si no hay seguridad en el
costo estimado, por alguna contingencia
puede incrementar su precio por encima del
beneficio normal.
 Términos contractuales: Reducir el costo a
partir de asumir restricciones como por
ejemplo entrega del código fuente y que el
desarrollador lo pueda reutilizar en otros
proyectos.
64
 Volatilidad de los requerimientos: Si es
probable que los requerimientos cambien,
podría reducirse los precios para ganar un
contrato. Después del contrato se cargan
precios altos a los cambios de
requerimientos.
 Salud Financiera: Cuando los
desarrolladores tienen dificultades
financieras podrían bajar sus costos para
ganar contratos. Esto es mejor que quedar
fuera del negocio o quebrar

65
Productividad
 Cuando se produce soluciones con
diferentes atributos, no tiene sentido
comparar tasas de productividad, sin
embargo las estimaciones son necesarias
para las estimaciones del proyecto y para
valorar si los procesos o las mejoras
tecnológicas son efectivas.
 Por lo general estas estimaciones se basan
en medir algunos atributos del software y
dividir el resultado entre el esfuerzo total
requerido para el desarrollo.
66
Medidas utilizadas:
 Relacionadas con el Tamaño: se
relacionan con el tamaño de alguna
salida de una actividad. La medida
más común son las líneas de código
fuente entregadas. También se utiliza
el número de instrucciones de código
objeto entregado o el número de
páginas de la documentación del
sistema

67
Medidas utilizadas:

 Relacionadas con la función: se

relacionan con la funcionalidad total
del software entregado. La
productividad se expresa en términos
de la cantidad de funcionalidad útil
producida en un tiempo dado.
Ejemplos de esta medidas son puntos
de función y puntos de objetos .

68
 (Un paréntesis )
 Puntos de objetos : el número de puntos de objeto
en un programa es una estimación de peso ( no son
clases de objetos que se producen cuan se considera
orientación objeto para el desarrollo del software):
 El número de pantallas independientes que se
despliegan. Las pantallas sencillas cuentan como 1
punto de objeto, las moderadamente complejas
cuentan como 2 y las muy complejas cuentan como 3
puntos de objeto.
 El número de informes que se producen, simples son
2 puntos de objeto, moderadamente complejos son 5
puntos de objeto y para informes que son difíciles de
producir 8 puntos de objetos.
 El número de módulos 3GL que deben desarrollarse
para complementar el código 4GL. Cada módulo 3GL
cuenta como 10 puntos objetos
69
Técnicas de Estimación
 No existe una forma simple de hacer una
estimación precisa del esfuerzo requerido
para desarrollar un sistema de software.
 Por lo general, las estimaciones de los
costos del proyecto se cumplen por su
propia naturaleza.
 A pesar de las dificultades e impresiones
las organizaciones requieren hacer
esfuerzos de software y estimaciones de
costos.

70
Técnicas de estimaciones de
costos
 Modelado del algoritmo de costos:
 Se desarrolla un modelo utilizando
información histórica de costos que
relaciona alguna métrica de software( por lo
general su tamaño) con el costo del
proyecto. Se hace una estimación de ésa
métrica y el modelo predice el esfuerzo
requerido.
 Opinión de expertos:
 Se consultan varios expertos en las técnicas
de desarrollo de software propuestas y en el
dominio de la aplicación. Cada uno de ellos
estima el costo del proyecto. Estas
estimaciones se comparan y discuten. El
proceso de estimación se itera hasta que se
71 acuerda una estimación.
Técnicas de estimaciones de
costos
 Estimación por analogía:
 Esta técnica es aplicable cuando otros
proyectos en el mismo dominio de aplicación
se han completado. Se estima el costo de
un nuevo proyecto por analogía con estos
proyectos completados.
 Ley de Parkinson:
 Establece que el trabajo se extiende para
llenar el tiempo disponible. El costo se
determina por los recursos disponibles más
que por los objetivos logrados. Si el software
se tiene que entregar en 12 meses y se
dispone de cinco personas, el esfuerzo
requerido se estima en 60 personas-mes
72
Técnicas de estimaciones
de costos
 Asignar precios para ganar:
 El costo del software se estima independientemente
de lo que el cliente esté dispuesto a pagar por el
proyecto. El esfuerzo estimado depende del
presupuesto del cliente y no de la funcionalidad del
software.

 Cada técnica de estimación tiene sus propias

debilidades y fortalezas.
 Para proyectos grandes se deben aplicar varias
técnicas de estimaciones de costos y comparar sus
resultados.
 Estas técnicas de estimación son aplicables cuando
existe un documento de requerimientos para el
sistema.
73
Modelado algorítmico de costos

 Se construye analizando los costos y

atributos de los proyectos realizados.
 Se utiliza una fórmula matemática para
predecir los costos basados en
estimaciones del tamaño del proyecto,
número de programadores y otros factores
de los procesos y productos.
 Kitchenham (1990) describe 13 modelos
algoritmos de costos desarrollados a partir
de observaciones empíricas.

74
Forma mas general para expresar
una estimación algorítmica de
costos:
 Esfuerzo = A x TamañoB x M
 A es un factor constante que depende de las prácticas
organizacionales locales y del tipo de software que se
desarrolla.
 Tamaño es una valoración del tamaño del código del
software o una estimación de la funcionalidad
expresada en puntos de función o de objetos.
 El valor del exponente B por lo general se encuentra
entre 1 y 1.5 y refleja el esfuerzo requerido para
proyectos grandes .
 M es un multiplicador generado al combinar
diferentes procesos , atributos del producto y del
desarrollo

75
Dificultades comunes:

 Es difícil estimar Tamaño en una

primera etapa de un proyecto donde
solamente esta disponible la
especificación.
 Las estimaciones de los factores B y
M son subjetivas. Varía de una
persona a otra según su experiencia y
conocimiento.

76
Modelo COCOMO
 Modelo empírico
 Se obtuvo recolectando datos de varios
proyectos de software grandes, y después
analizando esos datos para descubrir
fórmulas que se ajustarán mejor a las
observaciones.
 Esta bien documentado, es de dominio
público y lo apoyan herramientas
comerciales.
 Se ha utilizado y evaluado ampliamente.
 Ha evolucionado del COCOMO 81( 1981) al
COCOMO 2 (1995)
77
 COCOMO Básico

Complejidad Fórmula Descripción

del proyecto
Simple PM = 2.4 (KDSI)1.05 x M Aplicaciones bien comprendidas
desarrolladas por equipos pequeños

Moderada PM = 3.0 (KDSI)1.12 x M Proyectos más complejos donde los

miembros del equipo tienen
experiencia limitada en sistemas
relacionados

Incrustada PM = 3.6 (KDSI)1.20 x M Proyectos complejos donde el software

es parte de un complejo fuertemente
acoplado de hardware, software, reglas
y procedimientos operacionales.

78
 El COCOMO 81 , primera versión del
modelo COCOMO , fue un modelo de tres
niveles donde éstos reflejaban el detalle del
análisis de la estimación del costo.
 El primer nivel básico provee una
estimación inicial burda.
 El segundo nivel la modifica utilizando
varios multiplicadores del proyecto y del
proceso, y
 El nivel más detallado produce
estimaciones para las diferentes fases del
79 proyecto
Evolución COCOMO
 COCOMO 81 supone que el software se desarrolla
acorde a un proceso en cascada y que la mayoría del
software se construye desde cero.
 Lo anterior hoy no es válido pues existe creación de
software a partir de el ensamblado de componentes
reutilizables vinculándolos a través de script
(secuencia de comandos).
 Los modelos de procesos mas comúnmente utilizados
hoy son el de prototipos y el incremental.
 Se utiliza la reingeniería para crear nuevos procesos
 La utilización de mejores herramientas como las
CASE hacen mas dinámico el proceso de
construcción.
 Todo lo anterior hace evolucionar al COCOMO 81 al
actual modelo COCOMO 2
80
COCOMO 2
 Considera diferentes enfoques para el
desarrollo del software.
 Los niveles del modelo no reflejan
simplemente estimaciones detallas con
complejidad creciente.
 Los niveles se asocian a las actividades del
proceso por lo que las estimaciones
iniciales se llevan cabo al inicio del proceso
y las estimaciones detalladas se llevan a
cabo después del que se definió la
81 arquitectura del sistema.
Niveles del COCOMO 2
 Nivel de construcción de prototipo inicial:
• Las estimaciones de tamaño se basan en puntos de
objeto y se utiliza un fórmula sencilla
tamaño/productividad para estimar el esfuerzo
requerido.
 Nivel de diseño inicial:
• Corresponde a la terminación de requerimientos del
sistema con algún diseño inicial.. Las estimaciones se
basan en puntos de función que se convierten a
número de líneas de código fuente.
 Nivel postarquitectónico:
• Una vez que se diseña la arquitectura del sistema se
hace una estimación razonablemente precisa del
tamaño del software. En este nivel se utiliza un conjunto
mas grande de multiplicadores que reflejan la
capacidad del personal, el producto y las características
del proyecto.
82
Nivel de construcción de
prototipo inicial
 Permite la estimación del esfuerzo requerido en
construcción de prototipos y para proyectos donde el
software se desarrolla utilizando componentes
existentes.
 Se basa en una estimación de los puntos de objetos
de peso, la cual se divide en una cifra estándar de
productividad estimada.
 La productividad del programador depende de la
experiencia y capacidad del desarrollador y las
características de las herramientas CASE.
 La reutilización es común , por lo que el número de
puntos de objeto utilizados en la estimación del tiempo
se ajusta para tomar en cuenta el porcentaje de
reutilización que se espera.
83
Formula
• PM = ( NOP x (1 - %reutilización/100)) / PROD

PM es el esfuerzo en personas-mes
NOP es el número de puntos de objeto y
PROD es la productividad

Productividad de los Puntos de objeto

Experiencia y Muy Baja Nominal Alta Muy Alta
capacidad de los Baja
desarrolladores
Madurez y Muy Baja Nominal Alta Muy Alta
capacidad CASE Baja

PROD (NOP/mes) 4 7 13 25 50

84
El nivel de Diseño Inicial
 Las estimaciones se basan en fórmula
estándar para modelos algorítmicos:

 Esfuerzo = A x TamañoB x M

A según Boehm (experimentación) es de 2.5

para las estimaciones hechas a este nivel.
 Tamaño se expresa en KSLOC, es decir, el
número de miles de líneas de código fuente.
• KSLOC se calcula estimando el número de
puntos de función en el software y convirtiendolo
éste a KSLOC utilizando la tabla estándar que
relacionan el tamaño del software a puntos de
función para diferentes lenguajes de
programación
85
  El exponente B refleja el esfuerzo creciente
requerido al incrementarse el tamaño del
proyecto. Puede variar de 1.1 a 1.24
dependiendo de la novedad del proyecto, la
flexibilidad del desarrollo , los procesos
utilizados de resolución de riesgos, la
cohesión del equipo de desarrollo y en nivel
de madurez.
 M se basa en un conjunto de simplificado de 7
conductores de proyectos y procesos en los
que se incluye la fiabilidad y complejidad del
producto (RCPX), la reutilización requerida
(RUSE), la dificultad de la plataforma (PDIF),
la capacidad del personal (PERS), la
experiencia del personal (PREX), la
calendarización (SCED) y los recursos de
apoyo (FCIL). Estos pueden estimarse en una
escala de 1 a 6, 1 corresponde a un valor muy
bajo y 6 a valores muy altos.
86
Formula del esfuerzo según los
multiplicadores señalados:
 P = A x TamañoB x M + PMm donde
 M= PERS x RCPX x RUSE x PDIF x FCIL x
SCED.
 PMm es un factor que se utiliza cunado un
porcentaje importante del código se genera
de forma automática.
 PMm = (ASLOC x (AT / 100)) / ATPROD
 ASLOC número de líneas generadas
automáticamente de código fuente.
 ATPROD es el nivel de productividad para
este tipo de producción de código.
 AT porcentaje del código total del sistema
que se genera automáticamente
87
El nivel postarquitectónico
 Las estimaciones se basan en la misma
fórmula básica que se utiliza en las
estimaciones iniciales del diseño.
 La estimación del tamaño para el software
es mas precisa utilizando 17 atributos en
lugar de 7 para refinar el cálculo del
esfuerzo inicial.
 La estimación del número total de líneas de
código fuente se ajusta para tomar en
cuenta dos factores importantes del
proyecto:

88
 La volatilidad de los requerimientos:
 Se realiza un estimación de la revisión, que
puede ser requerida para acomodar
cambios en los requerimientos del sistema.
Se expresa como el número de líneas de
código fuente que se deben modificar y este
número se suma a la estimación inicial del
tamaño.
 Amplitud de la posible reutilización:
 Una reutilización amplia significa que se
deben modificar el número de líneas de
código fuente que realmente se
desarrollarán. El costo no es lineal pues
debido al esfuerzo inicial requerido para
descubrir y seleccionar los componentes y
debido al esfuerzo requerido para modificar
y comprender los componentes reutilizables
89 y sus interfaces.
 Efecto de la reutilización en
COCOMO 2
 Se ajusta el tamaño del esfuerzo de acuerdo con la siguiente
fórmula:
 ESLOC = ASLOC x ( AA+SU+0.4DM+ 0.3IM + 0,3CM)/100
• ESLOC es el número equivalente de líneas de código nuevo.
• ASLOC es el número de líneas de código reutilizable que deben
definirse.
• DM es el % de modificación del diseño
• CM es el % de código que se modifica
• IM es el % del esfuerzo original requerido para integrar el
software reutilizado.
• SU es un factor que se basa en el costo de comprensión del
software que varía desde 50 para código complejo no
estructurado hasta 10 para código orientado al objeto bien
escrito
• AA es un factor que refleja los costos de valoración inicial de la
posible reutilización del software. Va desde 0 a 8. Depende de
90 la cantidad de pruebas y evaluaciones requeridas.
Estimación del Exponente de la
fórmula del Esfuerzo (B)
Considera 5 factores de escala
valorados desde muy bajo hasta
extraalto(5 a0).
 Los valores resultantes se suman ,
se dividen entre 100 y al resultado se
le suma 1.01 par dar ese exponente

91
 Factores de escala utilizados en el
cálculo del exponente del COCOMO 2

Refleja la experiencia previa de la organización con

Precedentes este tipo de proyectos. Muy bajo significa sin
experiencia previa; Extraalto significa que la
organización está completamente familiarizada con
este dominio de aplicación
Refleja el grado de flexibilidad en el proceso de
Flexibilidad desarrollo. Muy bajo significa que se utiliza un proceso
prescrito; Extraalto significa que el cliente establece
sólo metas generales
Refleja la amplitud del análisis de riesgo que se lleva a
Resolución de la cabo . Muy bajo significa poco análisis; Extraalto
arquitectura/riesgo significa un análisis de riesgo completo y detallado.

92
 Refleja qué tan bien se conocen entre ellos los
Cohesión del miembros del equipo de desarrollo y qué tan bien
equipo trabajan juntos. Muy bajo significa interacciones muy
difíciles; Extraalto significa un equipo integrado y
efectivo sin problemas de comunicación .

Refleja la madurez del proceso de la organización. El

Madurez del cálculo de este valor depende del Cuestionario de
Proceso Madurez del CMM pero se puede alcanzar una
estimación sustrayendo el nivel de madurez del proceso
CMM de 5.

93
Atributos que se utilizan para ajustar las
estimaciones iniciales en el modelo
postarquitectónico (4) :
1. Atributos del producto:
 RELY Fiabilidad requerida del sistema
 CPLX Complejidad de los módulos del sistema
 DOCU Amplitud de la documentación requerida
 DATA Tamaño de la base de datos utilizada
 RUSE Porcentaje requerido de componentes
reutilizables
2. Atributos de la computadora:
 TIME Restricciones del tiempo de ejecución
 PVOL Volatilidad de la plataforma de desarrollo
 STOR Restricciones de memoria.

94
Atributos que se utilizan para ajustar las
estimaciones iniciales en el modelo
postarquitectónico (4) :
1. Atributos personales:
 ACAP Capacidad de análisis del proyecto.
 PCON continuidad del personal
 PEXP Experiencia del programador en el dominio
del proyecto
 PCAP Capacidad del programador
 AEXP Experiencia del analista en el dominio del
proyecto
 LTEX Experiencia en el lenguaje y las
herramientas
2. Atributos del proyecto:
 TOOL Utilización de las herramientas de software
 SCED Comprensión de los tiempos de desarrollo
95
 SITE Amplitud del trabajo en sitios múltiples y
calidad de las comunicaciones del sitio.
Ejemplo
 Una organización trabaja un proyecto en el
que se tiene poca experiencia en el
dominio. El cliente del proyecto no ha
definido el proceso a utilizar y no
proporciona suficiente tiempo en la
calendarización del proyecto para que se
haga un análisis de riesgos. Se tiene que
formar un nuevo equipo de desarrollo para
implementar este sistema. La organización
ha puesto en proceso un programa de
mejoramiento y ha obtenido en Nivel 2 del
modelo CMM.

96
Posibles valores de los factores de
escala utilizados en el cálculo del
exponente son:
1. Precedentes : Este es un proyecto nuevo para la
organización valor Bajo (4)
2. Flexibilidad de desarrollo: No se involucra el cliente
valor Muy alto (1)
3. Resolución de la arquitectura/riesgo: No se lleva a
cabo un análisis de riesgos valor Muy Bajo (5)
4. Cohesión del equipo: Creación de un nuevo equipo
por lo que no existe información Valor Nominal (3)
5. Madurez del Proceso: Algún control del proceso en
el lugar Valor Nominal (3)
La suma de estos valores es 16 por lo que el exponente
toma un valor de 1.17

97
Si además se supone que los conductores de
costos clave en el proyecto son RELY,
CPLX,STOR,TOOL y SCED:
Valor del Exponente 1.17
Tamaño del Sistema (incluyendo factores para 128.000 DSI
reutilización y los requerimientos de volatilidad)
Estimación inicial de COCOMO sin conductores de 730 personas-mes
costo

Fiabilidad Muy alta , multiplicador = 1.39

Complejidad Muy alta, multiplicador = 1.3

Restricciones de memoria Alta, multiplicador = 1.21

Utilización de herramientas Baja, multiplicador = 1.12

Calendarización Acelerada, multiplicador = 1.29

Estimación ajustada de COCOMO 2306 personas-mes

98
Fiabilidad Muy baja, multiplicador = 0.75

Complejidad Muy baja, multiplicador = 0.75

Restricciones de memoria Ninguna, multiplicador = 1

Utilización de herramientas Muy alta, multiplicador = 0.72

Calendarización Normal, multiplicador = 1

Estimación ajustada de COCOMO 295 personas-mes

En los ejemplos se consideraron valores extremos

para ver como influye en la estimación

99
 Modelos algorítmicos de costos en
la planeación del proyecto
A. Utilizar el hardware existente, sistema
de desarrollo y equipo de desarrollo

B. Actualización del Procesador y de la C.Sólo actualización de la D.Personal más

memoria memoria experimentado

Los costos de hardware se Los costos de hardware se

incrementan , la experiencia decrece incrementan

A. Nuevo sistema de desarrollo F. Personal con experiencia

en hardware
Los costos de hardware se
incrementan . La experiencia
decrece

100
Costo del software SC se
calcula:
 SC = Esfuerzo esyimado x RELY x
TIME x STOR x TOOL x EXP x CP
 CP = costo promedio de una persona
mes de esfuerzo

101
Duración y personal del
proyecto
 La relación entre el número de personas
que trabajan en un proyecto, el esfuerzo
total requerido y el tiempo de desarrollo no
es lineal.
 Formula para estimar el tiempo calendario
requerido para completar un proyecto
TDEV:
 TDVE = 3 x (PM) (0.33+0.2x(B-1.01))
 PM es el cálculo del esfuerzo
 B es el exponente que refleja el esfuerzo
creciente requerido al incrementarse el
tamaño del proyecto
 Este cálculo predice la duración nominal del
102 proyecto
 La duración prevista del proyecto y la
requerida por el plan del proyecto no
son necesariamente lo mismo. La
duración planeada es más corta o más
larga que la duración prevista original.
 Sin embargo existe un límite obvio para
los cambios de duración, el cual se
predice en COCOMO 2 como:
 TDVE = 3 x (PM) (0.33+0.2x(B-1.01)) x SCEDpercentage/100
 SCEDpercentagees el porcentaje de
crecimiento o decrecimiento en la
duración nominal.

103
 Un crecimiento muy rápido del
personal del proyecto a menudo está
correlacionado con retrasos en la
duración del proyecto.
 Si se reduce el tiempo de desarrollo ,
siendo un factor clave, el esfuerzo
requerido para desarrollar el sistema
crece exponencialmente.

104