Métricas de Proceso y Proyecto

Gabriela Noemí Puglla Remache, Lorena del Cisne León Quiñonez

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
Ingeniería en Sistemas Informáticos y Computación
Loja, Ecuador

gnpuglla@utpl.edu.ec/ lcleon@utpl.edu.ec




RESUMEN

Las métricas dentro del proceso de gestión de un proyecto son aquellas que nos ayudan a comprender el
proceso técnico (mediante indicadores) que se utiliza para desarrollar un producto, se utiliza durante todo
el proceso del proyecto de manera continua y así mejorar la calidad del producto. Las métricas del
proceso se recopilan en el curso de todos los proyectos y durante largos periodos que conduzcan a la
mejora de los procesos de software de largo plazo.

PALABRAS CLAVE

Métricas, proceso, proyecto, indicadores, calidad, producto

1. INTRODUCCIÓN

Las métricas son medidas cuantitativas que permiten obtener una visión de la eficacia del proceso de
software y los proyectos que se llevan a cabo utilizando ese proceso como marco de trabajo

La gestión de un proyecto de software es el primer nivel del proceso de ingeniería de software, este
permite cubrir todo el proceso de desarrollo. Dentro de esta gestión se define el ámbito de trabajo a
realizar, los riesgos que puede suscitarse, las actividades, los hitos que se reconocen tanto al inicio como
durante el desarrollo, el esfuerzo tiempo y costos del proyecto.

¿Quién lo hace?: los ingenieros de software: son los que recopilan la información, los gestores de
software quienes analizan y evalúan la información recopilada.

¿Porqué es importante?: las métricas permiten destacar las tendencias y hacer mejores estimaciones.

¿Cuáles son los pasos?:

• Definir un conjunto limitado de medidas.
• Las medidas se normalizan usando métricas.
• Se analizan los resultados y se comparan con promedios anteriores.

¿Cuál es el producto obtenido?: obtener un conjunto de métricas del software.





 


 
  








 

  



 
 

 
  

Medición del Software: Se debe medir el software para:

• Indicar la calidad del producto.

• Evaluar la productividad del agente que desarrolla el producto.
• Evaluar los beneficios en términos de productividad y calidad mediante el uso de nuevos
métodos y herramientas de ingeniería de software.
• Establecer una línea de base para la estimación.
• Ayudar a justificar el uso de nuevas herramientas o de formación adicional.

1
 2. METRICAS DE PROCESO Y DE PROYECTO

Las métricas del proceso permiten obtener un conjunto de indicadores de proceso que conduzcan a la
mejora de los procesos de software a largo plazo, las cuales se usan con fines estratégicos.

Las métricas del proyecto permiten valorar el estado de un proyecto en curso, así como también rastrear
los riesgos potenciales y descubrir las aéreas problema antes que se vuelvan “criticas”, también permite
ajustar el flujo de trabajo o las tareas y evaluar la habilidad del equipo del proyecto. Las métricas del
proyecto se usan con fines tácticos.

2.1 MEJORA DEL PROCESO

Fig.1. Determinantes para la calidad del software y la eficacia organizacional. [PAU 941]

Está influenciada por tres factores:

• La destreza y motivación del personal

• Complejidad del producto y la
• Tecnología

Y está reflejada en condiciones ambientales:

• Entorno de Desarrollo
• Condiciones de Riesgo
• Características del cliente

Las métricas del proceso mejoran la calidad de una operación o un proceso mediante la medición de sus
atributos y descubrir errores antes de liberar el software desarrollado. En el proceso de mejoramiento de
procesos se detectan y reportan defectos emitidos por los usuarios finales

Al desarrollar un conjunto de métricas para mejorar los procesos se desarrollan un conjunto de métricas
clasificadas como privadas y públicas.

• Métricas privadas: denominadas como defectos por individuos por componente durante el
desarrollo del proyecto.
• Métricas públicas: denominadas como índices a nivel de proyecto, esfuerzo, planificación, etc.

Las métricas hacia la mejora de los procesos ofrecen indicadores que conducen a estrategias aun más
específicas.

1
[PAU 94] factores controlables en la mejora de la calidad del software y el desempeño organizacional.

2
Para que las métricas no creen problemas se debe aplicar sentido común y sensibilidad para interpretarlas
y así ofrecer retroalimentación a quienes lo recopilan teniendo en cuenta que no se deben utilizar para
realizar evaluaciones o amenazar a los individuos que también forman parte del proyecto.

Así también establecer metas claras y métricas que se utilizaran para conseguirlas y no considerar
negativos los datos que identifiquen aéreas problemas y no obsesionarse solo con una métrica.

Las métricas del proyecto tienen doble finalidad:

• Minimizar el tiempo de desarrollo: se las aplica por primera vez durante la estimación.
• Valorar la calidad del producto

Fig 2. Costo global del proyecto [ENUN1 2]

3. MEDICIÓN DEL SOFTWARE

Se debe medir el software para indicar la calidad del producto, evaluar la productividad de la gente que
desarrolla el proyecto, evaluar los beneficios (en términos de productividad y de calidad) derivados del
uso de nuevos métodos y herramientas de ingeniería del software, establecer una línea base para la
estimación, ayudar a justificar el uso de nuevas herramientas o de formación adicional.

En la medición del software se han definidos dos tipos de medidas:

Medidas Directas: como el coste y el esfuerzo aplicado.

Medidas Indirectas: definidas como la funcionalidad, calidad, complejidad, eficiencia, fiabilidad,

facilidad de mantenimiento.

Dentro de las métricas más importantes del desarrollo de un proyecto de software se han considerado de
alta importancia las siguientes, tales como:

3.1 Las métricas de productividad se centran en el rendimiento del proceso de la ingeniería de

software.

3.2 Las métricas de calidad proporcionan una indicación de como se ajusta el software a los
requisitos implícitos y explícitos del cliente.

3.3 Las métricas orientadas al tamaño se utilizan para obtener medidas directas del resultado y
de la ingeniería del software.

3.4 Las métricas orientadas a la función Son medidas indirectas del software y del proceso por
el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se

2
[ENUN 1] recursos del proyecto gestión de proyectos, Pressman, Sexta Edición

3
 centran en la funcionalidad o utilidad del programa, fueron propuestas por Albercht quien
sugirió un acercamiento a la medida de la productividad denominado método del punto de
función.

3.5 Las métricas orientadas a la persona proporcionan información sobre la forma en que la
gente desarrolla software de computadora y sobre el punto de vista humano de la efectividad
de las herramientas y métodos.

3.6 Las métricas técnicas se centran en las características del software, complejidad lógica
grado de modularidad.

4. MÉTRICAS ORIENTADAS AL TAMAÑO

Son medidas directas del software y del proceso por el cual se desarrolla. Se obtiene considerando las
medidas de productividad y normalizándolas por el tamaño del código, es decir las líneas de código LDC.

Se lista cada proyecto de desarrollo de software de los últimos años y los correspondientes datos
orientados al tamaño de cada uno, se basan en a utilización de registros sencillos para las medidas más
relevantes al desarrollo de nuestro proyecto.

Tabla 1. Actividades de Ingeniería de software IS (análisis, diseño, codificación y prueba)3

Proyecto LDC Esfuerzo* Coste* $ Paginas Errores Defectos Personas

doc.
P1 12100 24 120 365 134 29 3
P2 27200 62 314 1224 321 86 5
P3 20200 43 224 1050 256 64 6

4.1 EL ESFUERZO: 

 

 !

























 
 



(


,

+ -'



,
*
-



"
,
*"-)
















 










 


'




(



1. 





#




*
























 
,
 -

.)
'(




























 




 


 '



'



'


'



"'


#





 



 
#







#)



*&)



 
(





 




 

















,$








-)







































 























)






 $
"

 !








(





#







#


 





















 '



'


'











/


*




 

#

#



(














)














 
















3
Autoras: Gabriela Puglla, Lorena León.

4
 
  
 

 *


 
  
 
 
  *

  





 
   *
  !   *

+

5
  
0
1
 

= 1 

0
5
  

= 3
  

0
3
  
= 5
  - ,



 
 
 


  
 


 

  

  *



  

 
  


  
  
 ,

4.3 LÍNEAS DE CÓDIGO





 

 
 

 
  


 

Las líneas de código de programa de prueba tan solo se contabilizan se desarrollan con el nivel de calidad
exigido al entregar el producto. Es la  
!
 
 
   

  %


 

!
 

 ,

 *


  
   

 
  

   
 '
 
    

 

  


 &

" ,


 &
   
 
!
  +



• +
# 

&,


!

 

 ,



   
 *


*



 

 


"
  

  %




&


 
 


 

 
 *

 


 


!


 &*



 

. ! 

  
  /


 

# 




 *

 
   *
 
   
" 
   

  %*

 

# 

&*

" 
   


&*




&*


  
 
"
!
   ,




• +
 

# 

&,


 

 

 

 #

 

!

 &

 


  &


 
!,



• +
  
# 

&
  *
 


 


 

2
 



 

 

&


 
 
# 

&
  

 
 



!  



  &*
*

!
 


 *


 


 
 
&
 
 
  


  &

 


 



 



 

 


*
 


 

 
!


,






 

 
 
 


 
 


   
   


  &4

 


 




#*
 !


#  

 
# 

&
 



  
*
 *


 


 


 *







 


   
  
 
  


 &,

4
Estimación de costes de un proyecto informático. Métricas de productividad y modelos de estimación
de costes, Miquel Barceló García
5
Fuente: C.T. Jones, 1986.

5
Las LDC no están comúnmente aceptadas pero al utilizar estas LDC existen ventajas como desventajas
entre estas tenemos:

Ventajas:
• Son fáciles de calcular
• Existen muchos modelos de estimación basados en LDC
• Existen muchas medidas de LDC

Desventajas:
• Dependientes de los lenguajes de programacion
• Perjudican a los programas cortos, pero bien diseñados
• Difícil uso en estimación debido al nivel de detalle.

5. MÉTRICAS ORIENTADAS A LA FUNCIÓN

Son medidas indirectas del software y del proceso por el cual se desarrolla. Se centran en la funcionalidad
o utilidad del programa. Las métricas orientadas a la función fueron el principio propuestas por Albercht
quien sugirió un acercamiento a la medida de la productividad del desarrollo de un proyecto de software
denominado método del punto de función. Los puntos de función que obtienen utilizando una función
empírica basando en medidas cuantitativas del dominio de información del software y valoraciones
subjetivos de la complejidad del software.

5.1 Los PUNTOS DE FUNCIÓN se calculan rellenando números de entrada del usuario se cuenta cada
entrada de usuario que proporciona al software diferentes datos orientados a la aplicación. Se obtienen
utilizando una función empírica basando en medidas cuantitativas del dominio de información del
software y valoraciones subjetivos de la complejidad del software.

Un Punto de Función (PF) representa la funcionalidad de un programa que se deriva de las medidas del
software, se calculan rellenando la tabla como se muestra en la siguiente tabla:

5.2 Calculo de métricas de punto de función:

PF = cuenta - total x [0,65+0,01 *
( f cuenta)i]

Tabla 3. Factor de ponderación según Albrecht6

En la tabla de factor de ponderación se han considerado 5 características principales dentro del ámbito de
la información denominados también como factores de escala según Albrecht, y los cálculos aparecen en
la posición apropiada de la tabla. Los valores del ámbito de la información están definidos como:

6
Allan Albrecht, de IBM, en 1979 definió la métrica del punto función como un método utilizado en
ingeniería del software para medir el tamaño del software.

6
 • El número de entradas de usuario deben ser distinguidas de las peticiones, que se contabilizan
por separado.

• El número de salidas de usuario se cuenta cada salida que proporciona el usuario dentro de la
información orientada a la aplicación.

• El número de peticiones al usuario una entrada interactiva que resulta de la generación de algún
tipo de respuesta en forma de salida interactiva.

• El número de archivos se cuenta cada archivo maestro lógico, o sea una agrupación lógica de
datos que puede ser una parte en una gran base de datos o un archivo independiente.

• El numero de interfaces externas todas las interfaces legibles por la maquina que son utilizadas
para transmitir información a otro sistema.

Una vez calculados los datos de la tabla de ponderación se asocian dichos valores, donde
CUENTA_TOTAL es la suma de todas las entradas.

Los valores 0,65 y 0,01 son valores establecidos por Albrecht obtenidos 



















 


!



















 
























!











 



 


    

 


 






!

Las 14 cuestiones señaladas son las siguientes:

Tabla4. Preguntas establecidas por Albrecht7 para el cálculo de los puntos de función

Nº Preguntas Valor asignado

de acuerdo a la
respuesta (0 - 5)
1 ¿Requiere el sistema copias de seguridad y recuperación fiables?
2 ¿Se requiere comunicación de datos?
3 ¿Existen funciones de procesamiento distribuidas?
4 ¿Es crítico el rendimiento?
5 ¿Será ejecutado el sistema en un entorno operativo existente y
frecuentemente utilizado?
6 ¿Requiere el sistema entrada de datos interactivo?
7 ¿Requiere la entrada de datos interactivo que las transiciones de entrada se
lleven a cabo sobre múltiples a variadas operaciones?
8 ¿Se actualizan los archivos maestros en forma interactiva?
9 ¿Son complejos las entradas, las salidas, los archivos o peticiones?
10 ¿Es complejo el procesamiento interno?
11 ¿Se ha diseñado el código para ser reutilizable?
12 ¿Están incluidas en el diseño la conversión y la instalación?
13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones en
diferentes organizaciones?
14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser
fácilmente utilizada por el usuario?
Suma total de los valores asignados a las preguntas

7
Allan Albrecht, de IBM, en 1979 definió la métrica del punto función como un método utilizado en
ingeniería del software para medir el tamaño del software.

7

(f cuenta)i : la suma total de los valores que se han asignado a cada de una de las preguntas
establecidas por Albrecht dentro de las métricas orientadas a la función para el desarrollo de un proyecto
específicamente en la programacion.

Una vez obtenidos los valores de cada uno de las variables procedemos a encontrar el valor del punto de
función dentro del desarrollo de un proyecto.

En las métricas orientadas a la función una vez calculado los puntos de función se usan de forma
analógica a las LDC como medida de la productividad, calidad y otros productos del software.

• productividad = pf / personas - mes

• calidad = errores / pf
• coste = dólares / pf
• documentación = págs. de documentación./pf

Ejercicio: para poder calcular las expresiones mencionadas lo realizaremos por medio de un
ejemplo:

• productividad = pf / personas - mes

productividad = 12100 / 5
productividad = 2420 pf / personas – mes

El promedio de la productividad es el resultado de tomar los valores de las KLDC (líneas de código)
sobre gente, el cual nos da un resultado de 2420 líneas de código producida por cada persona en el
mes

• calidad = errores / pf
calidad = 29 / 12100
calidad = 0.002 errores / pf

El promedio de la calidad es el resultado de tomar los valores errores sobre las KLDC (líneas de
código), el cual nos da un resultado de 0.002 errores de código por cada 12100 líneas de código
producidas, especificando que el proyecto se encuentra en etapa de pruebas del usuario final.

• coste = dólares / pf
coste = 168500 / 12100
coste = 13.92 dólares / pf

El promedio del costo total del proyecto es el resultado de tomar los valores del coste sobre KLDC
(líneas de código) el cual nos da un resultado de 13.92 dólares por cada línea de código.

• documentación=págs. de documentación./pf
documentación = 378 / 12100
documentación = 0.03 págs. de documentación / pf

El promedio de la documentación es el resultado de tomar los valores de las páginas de

documentación sobre KLDC (líneas de código) el cual nos da un resultado de 0,03 páginas de
documentación por cada punto de función .

8
 6. MÉTRICAS PARA LA CALIDAD DEL SOFTWARE

Existen medidas de la calidad del software como: la corrección, la facilidad de mantenimiento, la

integridad y la facilidad de uso ofrecen indicadores utilices para el equipo del proyecto, Gilb[GIL88]
sugiere definiciones y mediciones para cada una de ellas:

Corrección: es el grado en que el software desempeña la funcionara la que fue creado y se mide en
defectos por KLOC.

Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si se encuentra un

error; al adaptarse si su entorno cambia o mejorar si el cliente cambia los requisitos y se mide en forma
indirecta en TMC (tiempo medio de cambio).

Integridad: es la habilidad de un sistema para resistir ataques que requiere la definición de amenaza y
seguridad y se calcula:

integridad = 1 – (amenaza x (1 - seguridad))

Por ejemplo dado los siguientes valore podemos calcular la integridad:

Tabla 5. Ejemplo para calcular la integridad de un paquete de base de datos en dos proyectos 8

Proyecto 1 Proyecto 2
No oculta ficheros Oculta ficheros
No hace backup Hace backup
amenaza Seguridad Amenaza Integridad
………………………
Borrado BD 0,7 0 0,2 0,8
Aplicación
…………………

integridadP1borrado = 1 – 0,7 * (1 – 0) = 0,3

integridadP2borrado = 1 – 0,2 * (1 – 0,8) = 0,96

• Si la amenaza (la probabilidad de que un ataque ocurrirá) es 0,25 y la seguridad (la posibilidad de
repeler un ataque) es 0,95, la integridad del sistema es 0,99 (muy elevada).

• Si por otra parte, la probabilidad de amenaza es 0,50 y la posibilidad de repeler un ataque es solo
0,25, la integridad del sistema es 0,63(inaceptablemente baja).

Facilidad de Uso: es el intento por cuantificar la sencillez de una aplicación al utilizarla.

LA INTEGRACIÓN DE LAS MÉTRICAS DENTRO DEL PROCESO DE SOFTWARE

“El establecimiento de métricas en el ámbito de la compañía es un trabajo duro se debe esperar al menos
tres años antes de que estén disponibles tendencias organizacionales amplias…”(Grady y Caswell, 1987)

7. ESTABLECIMIENTO DE UNA LÍNEA BASE

Una línea base en este caso enfocado a las métricas de proceso y de proyecto son la recopilación de
métricas que sirven para establecer indicadores en el desarrollo de un proyecto de software. La
recolección requiere una investigación histórica de proyectos pasados para reconstruir los datos
requeridos, el cálculo de métricas que pueden abarcar una amplio rango de medidas y la evaluación de los
datos se centra en razones intrínsecas de datos obtenidos.

8
Autores Gabriela Puglla, Lorena León.

9
El establecimiento de una línea base ayuda a los gestores de proyecto como desarrollar estimaciones de
proyecto significativas, producir sistemas de alta calidad, liberar el producto a tiempo, etc. Una línea base
permite controlar los cambios sin impedir seriamente los cambios justificados, además consiste en la
obtención de datos recopilados en proyectos previos de desarrollo de software.

Para ser eficaz:

• Los datos deben ser razonablemente precisos.

• Los datos deben recopilarse de todos los proyectos que sean posibles.
• Las medidas deben ser consistentes.
• Las aplicaciones deben ser similares al trabajo que se estimará.

En el desarrollo de proyectos de software se han considerado como básicas las siguientes métricas para
determinar los factores de calidad
• Facilidad de auditoria
• Exactitud
• Normalización de las comunicaciones
• Completitud
• Concisión
• Consistencia
• Estandarización de los datos
• Tolerancia de errores
• Eficiencia de la ejecución
• Facilidad de expansión
• Generalidad
• Independencia del hardware
• Instrumentación
• Modularidad
• Facilidad de operación
• Seguridad
• Auto documentación
• Simplicidad
• Independencia del sistema software
• Facilidad de traza
• Formación

“Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un
acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse
solamente a través de procedimientos formales de control de cambios.”(IEEE) 610.12/1990

8. RECOPILACIÓN DE MÉTRICAS DE SOFTWARE

Fig. 3. Proceso de recopilación de métricas de software [PRESS9]

9
[PRESS] Ingeniería del Software, Métricas de Proceso y Proyecto.

10
Primeramente recopilamos los datos de proyectos previos, así obtenemos las medidas, las cuales
utilizamos para calcular las métricas. Dichas métricas deben evaluarse y aplicarse durante la estimación
del trabajo técnico, produciendo así un conjunto de indicadores que guían el proceso o proyecto.

8.1 Medidas que se pueden recopilar fácilmente:

• Tiempo que transcurre desde que se hace una solicitud hasta que la evaluación esté completa.
• Esfuerzo necesario para hacer la evaluación.
• Tiempo que transcurre desde que se completa la evaluación hasta que se asigna el pedido de
cambio al personal.
• Esfuerzo requerido para hacer el cambio.
• Tiempo requerido para hacer el cambio
• Errores descubiertos mientras se hacía el cambio
• Defectos descubiertos después de que el cambio es liberado a los clientes

Una vez recopiladas las medidas de varios cambios solicitados es posible calcular promedios y
porcentajes que permitan mejorar el proceso para reducir los tiempos.

También podremos calcular la EED así:

EED = E cambio/ (E cambio+ D cambio)

E cambio: Errores descubiertos mientras se hacía el cambio y D cambio: Defectos descubiertos después de
que el cambio es liberado a los clientes.

El valor ideal de EED es 1

9. MÉTRICAS PARA ORGANIZACIONES PEQUEÑAS

Sugerencia: centrarse en los resultados, no en las mediciones. Por ejemplo: “Reducir el tiempo para
evaluar e implementar los cambios solicitados”.
Una organización pequeña puede seleccionar el siguiente conjunto de medidas:
• Tiempo transcurrido desde el momento en que se hizo una solicitud hasta que la evaluación esta
completa.
• Esfuerzo para realizar la evaluación.
• Tiempo transcurrido desde que se completa la evaluación hasta la asignación del pedido de
cambio del personal.
• Esfuerzo requerido para hacer el cambio.
• Tiempo requerido para hacer el cambio.
• Errores descubiertos durante el trabajo para hacer el cambio.
• Defectos descubiertos después de que el cambio es liberado a la base de clientes.

10. ESTABLECIMIENTO DE UN PROGRAMA DE MÉTRICAS DE SOFTWARE

Esta dirigido por metas según el SEI(SOFTWARE ENGINEERING INSTITUTE) y define los
siguientes pasos:

1. Identificar los objetivos de la empresa.

2. Identificar los que se quiere conocer o aprender.
3. Identificar los sub objetivos
4. Identificar las entidades y atributos relacionados con los objetivos secundarios
5. Formalizar os objetivos de la medición
6. Identificar preguntas cuantificables y los indicadores relacionados que se emplearan como apoyo
para lograr los objetivos de sus mediciones
7. Identificar los elementos de datos que se recopilaran para construir los indicadores que ayudaran
a responder las preguntas
8. Definir las medidas que se e emplearan y hacer que estas definiciones sean operativas
9. Identificar las acciones que se tomaran para implementar las medidas
10. Prepara un plan para implementar las medidas

11
Al trabajar como equipo, la ingeniería del software y los gestores del negocio pueden confeccionar una
lista de metas priorizadas del negocio:

• Mejorar la satisfacción de los clientes con los productos.

• Hacer que los productos sean mas fáciles de usar.
• Reducir el tiempo que toma poner un producto en el mercado
• Simplificar el soporte para los productos
• Mejora la obtención global de utilidades

11. CONCLUSIONES:

• El uso de métricas en la mayoría de empresas es ocasional y depende mucho del estado y avance
del proyecto, ya que al experimentar retrasos la actividad de recopilación de datos para la
formación de métricas se suspende, debido principalmente a que la documentación del proyecto
se posterga o no se realiza.
• Mejora las estadísticas del proceso de desarrollo de software.
• Si no medimos, no podemos saber si estamos mejorando. Si no mejoramos, estamos perdidos.
• Las métricas del proyecto guían los ajustes necesarios para evitar riesgos, retrasos y mitigar
problemas.
• Las métricas del proyecto permiten evaluar la calidad actual de los productos y modificar el
enfoque técnico para mejorarla.
• En el desarrollo de un proyecto de software los conocimientos adquiridos representan una ruta
potencial en las metas de calidad del producto mientras que las debilidades deben ser
neutralizadas y asociadas a acciones preventivas para evitar su crecimiento.

12. REFERENCIAS:

[1] R. S. Pressman. Ingeniería del software. Un enfoque práctico. 6ª Edición. McGrawHill (1993)

[2] Guide to the Software Engineering Body of Knowledge, 2004 Version, SWEBOK® A project of the
IEEE Computer Society Professional Practices Committee, CHAPTER 9 SOFTWARE ENGINEERING
PROCESS.

[3] Revista de Procesos y Métricas de las tecnologías de la informaciónVolumen1 número 1, abril 2004.

[4] Proceso de software y Métricas de proyectos

http://www.fdi.ucm.es/profesor/anavarro/4._Proceso_de_software_y_metricas_de_proyectos.pd
f

[5] Métricas de Proceso y Proyecto Sistemas de Información II –2009 Facultad de Ingeniería –

UNJU
http://www.fi.unju.edu.ar/materias/materia/SI2/document/Clase_20-may-
2009/SIII2009_-_Metricas_de_Proceso_y_Proyecto.pdf?cidReq=SI2

[6] Métricas, Estimación y Planificación en Proyectos de Software

http://www.willydev.net/descargas/willydev_planeasoftware.pdf

[7] Métricas del Software, Por Alejandro De coss

http://www.gdl-mexcomp.com/Documents/metricas%20de%20software.pdf

[8] Medición y Métricas del Software

http://trevinca.ei.uvigo.es/~ebalonso/asignaturas/esx/guiones/esxClase26.pdf

12