metricas del producto para el software

7
Sistemas de Información II – Año 2014 Medidas del producto para el Software Walter C. Tejerina 1 (1)Sistemas de Información II, Facultad de Ingeniería, Universidad Nacional de Jujuy [email protected] RESUMEN: En los tiempos actuales, gracias a los avances de la Informática, el software se utiliza en casi todos los campos de la actividad humana: la industria, el comercio, las finanzas, el gobierno, la salud, la educación, las artes. Existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad. Para ello, se avanza en la definición e implementación de estándares que fijan los atributos deseables del software de calidad, a la vez que surgen modelos y metodologías para la evaluación de la calidad. Para lograr este objetivo, los ingenieros de software deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software. 1 INTRODUCCION Las métricas del software permiten medir de forma cuantitativa la calidad de sus atributos internos del producto, esto permite al ingeniero evaluar la calidad antes de su construcción. Es importante establecer ¿qué es la calidad del software?, ¿Quién lo hace?, ¿Por qué es importante?, ¿Cuáles son los pasos? Para determinar la calidad, ¿Cuál es el producto obtenido?, ¿Cómo estar seguro de hacerlo correctamente?. Todas estas interrogantes se determinarán a lo largo del desarrollo del presente informe. Aspectos a considerar tales como hacer una distinción entre medida, métrica e indicador, qué factores de calidad se toman. 1.1 Calidad del software Es el cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, los estándares de desarrollo explícitamente documentados y las características implícitas que se esperan de todo software desarrollado profesionalmente. La calidad del software es una compleja mezcla de factores que variarán a través de diferentes aplicaciones y según los clientes que las pidan [1]. Con esta definición se destacan tres puntos importantes: Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con estos requisitos es una falta de calidad. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la ingeniería del software. Si no se siguen los criterios, el resultado será, casi seguramente, la falta de calidad. A menudo se soslaya un conjunto de requisitos implícitos. Si el software cumple con sus requisitos explícitos pero no con los implícitos, la calidad del software estará en duda. . 1.1.1 Factores de Calidad de McCall Estos factores se dividen en dos grupos muy importantes: Los que se miden directamente. Los que solo se miden indirectamente. McCall, Richards y Walters propusieron unos factores los cuales se concentran en tres aspectos importantes de un producto de software: sus características operativas, su capacidad para experimentar cambios y su capacidad para adaptarse a nuevos entornos. En la siguiente figura se observan los factores que afectan la calidad del software.

Upload: walter-tejerina

Post on 20-Jun-2015

681 views

Category:

Education


1 download

DESCRIPTION

RESUMEN: En los tiempos actuales, gracias a los avances de la Informática, el software se utiliza en casi todos los campos de la actividad humana: la industria, el comercio, las finanzas, el gobierno, la salud, la educación, las artes. Existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad. Para ello, se avanza en la definición e implementación de estándares que fijan los atributos deseables del software de calidad, a la vez que surgen modelos y metodologías para la evaluación de la calidad. Para lograr este objetivo, los ingenieros de software deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software.

TRANSCRIPT

Page 1: Metricas del producto para el Software

Sistemas de Información II – Año 2014

Medidas del producto para el Software

Walter C. Tejerina1

(1)Sistemas de Información II, Facultad de Ingeniería, Universidad Nacional de Jujuy

[email protected]

RESUMEN: En los tiempos actuales, gracias a los avances de la Informática, el software se utiliza en casi

todos los campos de la actividad humana: la industria, el comercio, las finanzas, el gobierno, la salud, la

educación, las artes. Existe una creciente preocupación por lograr que los productos software cumplan

con ciertos criterios de calidad. Para ello, se avanza en la definición e implementación de estándares que

fijan los atributos deseables del software de calidad, a la vez que surgen modelos y metodologías para la

evaluación de la calidad. Para lograr este objetivo, los ingenieros de software deben emplear métodos

efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del

software.

1 INTRODUCCION

Las métricas del software permiten medir de

forma cuantitativa la calidad de sus atributos

internos del producto, esto permite al ingeniero

evaluar la calidad antes de su construcción. Es

importante establecer ¿qué es la calidad del

software?, ¿Quién lo hace?, ¿Por qué es

importante?, ¿Cuáles son los pasos? Para

determinar la calidad, ¿Cuál es el producto

obtenido?, ¿Cómo estar seguro de hacerlo

correctamente?. Todas estas interrogantes se

determinarán a lo largo del desarrollo del presente

informe. Aspectos a considerar tales como hacer

una distinción entre medida, métrica e indicador,

qué factores de calidad se toman.

1.1 Calidad del software

Es el cumplimiento de los requisitos de

funcionalidad y desempeño explícitamente

establecidos, los estándares de desarrollo

explícitamente documentados y las características

implícitas que se esperan de todo software

desarrollado profesionalmente.

La calidad del software es una compleja mezcla

de factores que variarán a través de diferentes

aplicaciones y según los clientes que las pidan

[1].

Con esta definición se destacan tres puntos

importantes:

Los requisitos del software son la base

de las medidas de calidad. La falta de

concordancia con estos requisitos es una

falta de calidad.

Los estándares especificados definen un

conjunto de criterios de desarrollo que

guían la ingeniería del software. Si no se

siguen los criterios, el resultado será,

casi seguramente, la falta de calidad.

A menudo se soslaya un conjunto de

requisitos implícitos. Si el software

cumple con sus requisitos explícitos pero

no con los implícitos, la calidad del

software estará en duda.

. 1.1.1 Factores de Calidad de McCall

Estos factores se dividen en dos grupos muy

importantes:

Los que se miden directamente.

Los que solo se miden indirectamente.

McCall, Richards y Walters propusieron unos

factores los cuales se concentran en tres aspectos

importantes de un producto de software: sus

características operativas, su capacidad para

experimentar cambios y su capacidad para

adaptarse a nuevos entornos. En la siguiente

figura se observan los factores que afectan la

calidad del software.

Page 2: Metricas del producto para el Software

Sistemas de Información II – Año 2014

Figura 1. Factores de calidad de McCall

1.1.2 Factores de calidad del estándar ISO

9126

Se desarrolló un intento por identificar los

atributos de calidad para el software de

computadora. El estándar identifica 6 puntos:

Funcionalidad

Confiabilidad

Facilidad de uso

Eficiencia

Facilidad de mantenimiento

Portabilidad

1.2 Métricas, medición e indicadores

La medición es un elemento clave en cualquier

proceso de ingeniería. Las medidas se emplean

para comprender mejor los atributos de los

modelos que se crean y evaluar la calidad de los

productos de la ingeniería. Por las características

inherentes al software, sus medidas y métricas

son indirectas y, por lo tanto, expuestas al debate.

Una medida proporciona una indicación

cuantitativa de la extensión, cantidad, dimensión

capacidad o tamaño de algún atributo de un

producto o proceso [2].

Una métrica es una evaluación del grado en que

un sistema, componente o proceso posee un

atributo determinado (extensión, cantidad,

dimensiones, capacidad o tamaño).

Un ingeniero de software recopila medidas y

desarrolla métricas para obtener los indicadores.

Un indicador es una métrica o combinación de

métricas que proporcionan conocimientos. Estos

conocimientos le permiten al jefe de proyecto o a

los ingenieros de software ajustar el proceso, el

proyecto o el producto para que las cosas

mejoren.

2 MARCO CONCEPTUAL PARA LAS

METRICAS DEL PRODUCTO

El peligro de tratar de encontrar medidas que

caractericen tantos atributos diferentes es que

inevitablemente las medidas tienen que satisfacer

objetivos que entran en conflicto entre sí. Esto se

opone a la teoría de que cada medición debe ser

representativa. Muchas personas argumentan que

la medición del producto realizada durante las

primeras etapas del proceso de software

proporciona a los ingenieros un mecanismo

consistente y objetivo para evaluar la calidad.

2.1 Principios de medición

Roche sugiere un proceso de medición al que

caracterizan cinco actividades:

Formulación. Derivación de medidas y

métricas apropiadas para la

representación del software que se

considera.

Recolección. Mecanismo con que se

acumulan los datos necesarios para

derivar 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 las

métricas en un esfuerzo por conocer

mejor la calidad de la representación.

Retroalimentación. Recomendaciones

derivadas de la interpretación de las

métricas del producto transmitidas al

equipo del software.

Existen principios que son representativos de

muchos otros que podrían proponerse para

caracterizar y validar las métricas:

Una métrica debe tener propiedades

matemáticas deseables.

Cuando una métrica representa una

característica de software que aumenta

cuando se presentan rasgos positivos o

que disminuye al encontrar rasgos

indeseables, el valor de la métrica debe

aumentar o disminuir en el mismo

sentido.

Cada métrica debe validarse

empíricamente en una amplia variedad

de contextos antes de publicarse o

aplicarse a la toma de decisiones.

Page 3: Metricas del producto para el Software

Sistemas de Información II – Año 2014

2.2 Métricas del modelo de análisis

En esta fase se obtendrán los requisitos y se

establecerá el fundamento para el diseño. Y es

por eso que se desea una visión interna a la

calidad del modelo de análisis. Sin embargo hay

pocas métricas de análisis y especificación, se

sabe que es posible adaptar métricas obtenidas

para la aplicación de un proyecto, en donde las

métricas examinan el modelo de análisis con el

fin de predecir el tamaño del sistema resultante,

en donde resulte probable que el tamaño y la

complejidad del diseño estén directamente

relacionados. Es por eso que se verán en las

siguientes secciones las métricas de puntos de

función y de calidad de especificación [3].

2.2.1 Puntos de función

El Punto Función es “un método para medir el

tamaño y la complejidad software basándose en la

cantidad de funcionalidad”, o una herramienta

para “medir el tamaño funcional del software”.

Permite a los clientes disponer de un método

común para estimar el trabajo de sus proveedores.

Normalmente, además el método del cálculo del

punto función es conocido por el proveedor. Y en

cualquier caso se evitan las estimaciones “ad hoc”

para cada desarrollo / proveedor. Se consigue así

tener unas “tablas estándar” de estimación de los

trabajos, y métricas derivadas, como el número de

horas de desarrolladores por Puntos Función,

Número total de horas por Puntos Función, Coste

por Puntos Función, etc.

Pero una de las dificultades de implantar el punto

función es que hay muchos métodos, y

“familias”, para calcular los Puntos Función. Y

que algunos son más ligeros y otros enormemente

más pesados.

Con el objetivo de hacer más llevadera la tarea de

seleccionar un método para el cálculo del punto

función, dos de los métodos más prácticos y

ligeros para implantar la estimación con punto

función son los siguientes:

FP Lite: Este método es una derivación

del método el IFPUG (International

Function Point Users Group), ya que el

método tradicional del IFPUG es

bastante complejo de implantar. El FP

Lite lo que hace es reducir y simplificar

las fases del IFPUG.

Puntos Casos de Uso (Use Case Points):

Se basa en casos de uso. Y es de gran

aplicabilidad al mundo real. El método

es del 93, y de manera similar al FP Lite,

simplifica y reduce considerablemente

los pasos necesarios para estimar.

Ambos métodos permiten definir un conjunto de

tablas estándar, por las que todos los proveedores

deben guiarse a la hora de realizar una

estimación. El FP Lite trabaja con requisitos más

tradicionales, y el Puntos Casos de Uso con casos

de uso como entrada. Ambos son ligeros, y

existen experiencias reales de su implantación

[4].

2.2.2 Métricas de la calidad de la especificación

Propuesta por Pressman, mide la calidad del

análisis y de los requisitos capturados. A pesar de

medir factores cualitativos, propone métricas

como por ejemplo el número de requisitos donde

los revisores han interpretado lo mismo.

Al medir características de la especificación es

posible obtener un conocimiento cuantitativo de

la especificidad y el grado de avance 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:

especificidad (ausencia de ambigüedad),

compleción, corrección, comprensión, capacidad

de verificación, consistencia interna y externa,

capacidad de logro, concisión, trazabilidad,

capacidad de modificación, exactitud y capacidad

de reutilización. Además, los autores apuntan que

las especificaciones de alta calidad deben estar

almacenadas electrónicamente, ser ejecutables o

al menos interpretables, anotadas por importancia

y estabilidad relativas, con su versión

correspondiente, organizadas, con referencias

cruzadas y especificadas al nivel correcto de

detalle.

2.3 Métricas del modelo de diseño

Las métricas de diseño para el software, como

otras métricas del software, no son perfectas.

Continúa el debate sobre la eficacia y cómo

deberían aplicarse. Muchos expertos argumentan

que se necesita más experimentación hasta que se

puedan emplear las métricas de diseño. Y sin

embargo, el diseño sin medición es una

alternativa inaceptable.

2.3.1 Métricas del diseño arquitectónico

Consideradas métricas de caja negra ya que

no requieren ningún conocimiento del

funcionamiento interno de un componente de

software en particular. Se centran en la

arquitectura del programa y la eficiencia de los

módulos. Son de caja negra en el sentido que no

Page 4: Metricas del producto para el Software

Sistemas de Información II – Año 2014

requieren ningún conocimiento del trabajo interno

de un módulo en particular del sistema.

Card y Glass definen tres medidas de la

complejidad del diseño del software: complejidad

estructural, complejidad de datos y complejidad

del sistema.

La complejidad de datos D(i) proporciona una

indicación de la complejidad en la interfaz interna

de un módulo i.

La complejidad del sistema C(i) se define como

la suma de las complejidades estructural y de

datos.

2.3.2 Métricas del diseño a nivel de

componentes

Las métricas de diseño a nivel de

componentes se concentran en las características

internas de los componentes del software e

incluyen medidas de las “3Cs” -la cohesión,

acoplamiento y complejidad del módulo-.

Estas tres medidas pueden ayudar al desarrollador

de software a juzgar la calidad de un diseño a

nivel de los componentes.

Las métricas presentadas en esta sección son de

caja blanca en el sentido de que requieren

conocimiento del trabajo interno del módulo en

cuestión. Las métricas de diseño de los

componentes se pueden aplicar una vez que se ha

desarrollado un diseño procedimental. También

se pueden retrasar hasta tener disponible el

código fuente [2].

2.3.2.1 Métricas de cohesión

Bieman y Ott definen una colección de

métricas que proporcionan una indicación de la

cohesión de un módulo. Las métricas se definen

con cinco conceptos y medidas:

Porción de datos: es un recorrido hacia atrás por

un módulo que busca valores de datos que afectan

el estado del módulo cuando comienza el

recorrido.

Muestras de datos: las variables detenidas para

un módulo se definen como muestras de datos

para el módulo.

Señales de unión: este conjunto de muestras de

datos cae en una o más porciones de datos.

Señales de superunión: estas muestras de daos

son comunes a todas las porciones de datos de un

módulo.

Capacidad de unión: la capacidad de unión

relativa de una señal de unión es directamente

proporcional al número de porciones de datos que

une.

Cohesión funcional fuerte: un procedimiento sin

señales de superunión tiene 0 (cero) cohesión

funcional fuerte, es decir que no hay muestras de

datos que contribuyen a todas las salidas.

Cohesión funcional débil: un procedimiento sin

señales de unión tiene 0 (cero) cohesión funcional

débil, es decir que no hay muestras de datos que

contribuyen a todas las salidas.

Adhesividad: un procedimiento sin señales de

unión tiene 0 (cero) adhesividad, es decir que no

hay muestras de datos que contribuyen a más de

una salida.

2.3.2.2 Métricas de acoplamiento

El acoplamiento de módulo proporciona

una indicación de la conectividad de un módulo

con otros módulos, datos globales y el entorno

exterior. Se ha propuesto una métrica para el

acoplamiento del módulo que combina el

acoplamiento de flujo de datos y de control,

acoplamiento global y acoplamiento de

entorno. Las medidas necesarias para calcular

el acoplamiento de módulo se definen en

términos de cada uno de los tres tipos de

acoplamiento apuntados anteriormente.

Para el acoplamiento de flujo de datos y de

control:

Di = número de parámetros de datos de entrada

Ci = número de parámetros de control de entrada

Do = número de parámetros de datos de salida

Co = número de parámetros de control de salida

Para el acoplamiento global:

Gd = número de variables globales usadas como datos

Gc = número de variables globales usadas como control

Para el acoplamiento de entorno:

W = número de módulos llamados (expansión)

R = número de módulos que llaman al módulo en

cuestión

Usando estas medidas, se define un indicador

de acoplamiento de módulo M de la siguiente

manera: M=K/m

Donde

K = L es una constante de proporcionalidad y

m = Di + a x Ci + Do + b x Co + Gd + c x Gc + W + R

Page 5: Metricas del producto para el Software

Sistemas de Información II – Año 2014

Los valores de k, a, b y c deben derivarse

empíricamente. A medida que M aumenta, el

acoplamiento general del módulo disminuye.

Para que la métrica suba a medida que aumenta el

grado de acoplamiento se define una métrica

revisada:

C = 1 - M

2.3.3 Métricas del diseño orientado a objetos

Las métricas orientadas a objetos se centran

en métricas que se pueden aplicar a las

características de encapsulamiento, ocultamiento

de información, herencia y técnicas de

abstracción de objetos que hagan única a esa

clase.

Se proponen una familia de medidas para

desarrollos orientados a objetos:

Métodos ponderados por clase (MPC):

Tamaño y complejidad

Profundidad árbol de herencia (PAH):

Tamaño

Número de descendientes (NDD):

Tamaño, acoplamiento y cohesión

Acoplamiento entre clases (ACO):

Acoplamiento

Respuesta para una clase (RPC):

Comunicación y complejidad

Carencia de cohesión en los métodos

(CCM): Cohesión interna.

Estas métricas, en líneas generales, permiten

averiguar cuán bien están definidas las clases y el

sistema, lo cual tiene un impacto directo en la

mantenibilidad del mismo, tanto por la

comprensión de lo desarrollado como por la

dificultad de modificarlo con éxito.

2.3.4 Métricas orientadas a clases

La clase es la unidad fundamental de un

sistema orientado a objetos. Por tanto las medidas

y metricas de una clase individual seran

invaluables para un ingeniero de software que

debe valorar la calidad de diseño. La clase es el

predecesor de las subclases que heredan sus

atributos y operaciones

Se basa en la idea de que el número de métodos y

su complejidad es un indicador razonable de la

cantidad de esfuerzo necesaria para implementar

y comprobar una clase.

Mide la complejidad de una clase asignándole

una complejidad a cada método. Resulta ambigua

dado que no ofrece ninguna definición asociada a

la complejidad.

2.4 Métricas del modelo del código fuente

La teoría de Halstead de la ciencia del

software es «probablemente la mejor conocida y

más minuciosamente estudiada de las medidas

compuestas de la complejidad (software). La

ciencia del software propone las primeras «leyes»

analíticas para el software de computadora.

La ciencia del software asigna leyes cuantitativas

al desarrollo del software de computadora,

usando un conjunto de medidas primitivas que

pueden obtenerse una vez que se ha generado o

estimado el código después de completar el

diseño. Estas medidas se listan a continuación.

Figura 2. Medidas de Diseño

Halstead usa las medidas primitivas para

desarrollar expresiones para 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 esfuerzo de desarrollo, tiempo de desarrollo

e incluso el número esperado de fallos en el

software.

Halstead expone que la longitud N se puede

estimar como:

N = N1 + N2.

Es una simple medida del tamaño de un

programa. Cuanto más grande sea el tamaño de

N, mayor será la dificultad para comprender el

programa y mayor el esfuerzo para mantenerlo.

El volumen de programa se puede definir como

un “peso extra” al número de operadores y

operandos únicos.

Por ejemplo, si dos programas tienen la misma

longitud N pero uno tiene mayor número de

operadores y operandos únicos, que naturalmente

Page 6: Metricas del producto para el Software

Sistemas de Información II – Año 2014

lo hacen más difícil de entender y mantener, este

tendrá un mayor volumen

Se calcula como

V = N x log2(n) donde n = n1 + n2

Se debería tener 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.

Teóricamente, debe existir un volumen mínimo

para un algoritmo. Halstead define una relación

de volumen L como la relación de volumen de la

forma más compacta de un programa con

respecto al volumen real del programa. Por tanto,

L debe ser siempre menor de uno.

En la métrica de Halstead también se define el

esfuerzo, esta ofrece una medida del trabajo

requerido para desarrollar un programa.

Desde el punto de vista del mantenimiento, el

esfuerzo se puede interpretar como una medida

del trabajo requerido para comprender un

software ya desarrollado. Se calcula como

E = V/L

Donde L (lenguaje) indica si se está utilizando un

lenguaje de alto o bajo nivel. Aumenta

proporcionalmente con el volumen, pero decrece

con la utilización de lenguajes de alto nivel.

Por ejemplo, una simple llamada a un

procedimiento podría tener un valor L de

1; en COBOL podría tener 0,1 y el ensamblador

podría tener un L de 0,01[5].

2.5 Métricas para mantenimiento

Todas las métricas del software pueden usarse

para el desarrollo de nuevo software y para el

mantenimiento del existente. Sin embargo, se han

propuesto métricas diseñadas explícitamente para

actividades de mantenimiento.

El estándar EEE 982.1-1988 sugiere un í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). Se determina la

siguiente información:

Figura 3. Medidas para índice de madurez

El índice de madurez del software se calcula de la

siguiente manera:

IMS = [Mt – (Fa + Fc + Fd)] / Mt]

Donde:

Mt es el número de módulos en la versión actual

Fa es el número de módulos añadidos a la versión

actual

Fc es el número de módulos cambiados en la

versión actual

Fd es el número de módulos de la versión anterior

que se eliminaron en la actual

A medida que el IMS se acerca a 1,0 el producto

comienza a estabilizarse

3 CONCLUSION

A lo largo de nuestra investigación vimos

como las métricas proporcionan los

conocimientos necesarios para crear modelos

efectivos de análisis y diseño, un código sólido y

pruebas exhaustivas. Estas métricas se enfocan al

proceso de software en varios aspectos tales como

métricas del producto, para el modelo de análisis,

para el modelo de diseño, para el código fuente,

para pruebas y para mantenimiento, las cuales

permiten el control de calidad en cada uno de

estos procesos.

Otras como las métricas del modelo de análisis se

concentran en la función, los datos y el

comportamiento (los tres componentes del

modelo de análisis). El punto de función

proporciona medidas cuantitativas para evaluar el

modelo de análisis. Las métricas del diseño

consideran aspectos de alto nivel, del nivel de

componentes y de diseño de interfaz. Las

métricas de diseño de alto nivel consideran los

aspectos arquitectónicos y estructurales del

modelo de diseño. Las métricas de diseño de

nivel de componentes proporcionan una

indicación de la calidad del módulo estableciendo

medidas indirectas de la cohesión, acoplamiento y

complejidad.

Page 7: Metricas del producto para el Software

Sistemas de Información II – Año 2014

4 BIBLIOGRAFIA

[1] Calidad en el Software. Mayela Delgado.

Marzo. Disponible en:

http://www.entornoempresarial.com/articulo/106/

calidad-en-el-software-i

Fecha: 13 de febrero de 2014

[2] Pressman, R. S. (2006) “Ingeniería de

Software. Un enfoque práctico”. MCGRAW-

HILL. México. 2006

[3] Métricas en el desarrollo del Software

Heidi González Doria.

Disponible en:

http://catarina.udlap.mx/u_dl_a/tales/documentos/

lis/gonzalez_d_h/capitulo4.pdf

Fecha: 13 de febrero de 2014

[4]Dos métodos prácticos para implantar la

estimación con puntos de función. Javier Garzas.

Disponible en:

http://www.javiergarzas.com/2012/03/puntos-

funcion.html

Fecha: 13 de febrero de 2014

[5]Métricas del código fuente Ingeniería del

software II. Yajaira Pallares Echavez.

Disponible en:

http://ing-

software3.blogspot.com.ar/2013/01/metricas-del-

codigo-fuente.html

Fecha: 13 de febrero de 2014