Metricas De Procesos Y Proyecto

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 [email protected]/ [email protected]

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* $

P1 P2 P3

12100 27200 20200

24 62 43

120 314 224

Paginas doc. 365 1224 1050

Errores

Defectos

Personas

134 321 256

29 86 64

3 5 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

1 2 3 4 5

¿Requiere el sistema copias de seguridad y recuperación fiables? ¿Se requiere comunicación de datos? ¿Existen funciones de procesamiento distribuidas? ¿Es crítico el rendimiento? ¿Será ejecutado el sistema en un entorno operativo existente y frecuentemente utilizado? ¿Requiere el sistema entrada de datos interactivo? ¿Requiere la entrada de datos interactivo que las transiciones de entrada se lleven a cabo sobre múltiples a variadas operaciones? ¿Se actualizan los archivos maestros en forma interactiva? ¿Son complejos las entradas, las salidas, los archivos o peticiones? ¿Es complejo el procesamiento interno? ¿Se ha diseñado el código para ser reutilizable? ¿Están incluidas en el diseño la conversión y la instalación? ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? ¿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

6 7 8 9 10 11 12 13 14

Valor asignado de acuerdo a la respuesta (0 - 5)

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 No oculta ficheros No hace backup amenaza Seguridad ……………………… Borrado BD Aplicación …………………

0,7

0

Proyecto 2 Oculta ficheros Hace backup Amenaza Integridad 0,2

0,8

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) siguientes pasos:

y define los

1. 2. 3. 4. 5. 6.

Identificar los objetivos de la empresa. Identificar los que se quiere conocer o aprender. Identificar los sub objetivos Identificar las entidades y atributos relacionados con los objetivos secundarios Formalizar os objetivos de la medición 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-may2009/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