MTRICAS TCNICAS DEL SOFTWARE.

METRICAS DE UN PROYECTO.

Uno de los elementos que permite dar garanta acerca de la calidad del software es la aplicacin de
mtricas, estas son medidas estadsticas aplicadas a un software determinado, garantizando calidad
as como lo afirma Pressman: La garanta de calidad del software, es una Actividad de proteccin
que se aplica a lo largo de todo el proceso de ingeniera del software.

Existen tres conceptos fundamentales que debemos tomar en cuenta en la medicin de un proyecto:
medida, medicin y mtrica.

Aunque estos tres trminos con frecuencia se usan de modo intercambiable, es importante observar
las sutiles diferencias entre ellos.

1. Medida: Proporciona una indicacin cuantitativa de la extensin, cantidad, dimensin,

capacidad o tamao de algn atributo de un producto o proceso.
2. Medicin: es el acto de determinar una medida. Es el proceso mediante el cual se asignan
nmeros o smbolos a los atributos de las entidades en el mundo real, de manera que se les
define de acuerdo con reglas claramente determinadas.
3. Mtrica: Es una medida cuantitativa del grado en que un sistema, componente o proceso
posee un atributo dado.

Un indicador es una mtrica o combinacin de mtricas que proporcionan comprensin acerca del
proceso de software, el proyecto de software o el producto en s. Un indicador proporciona
comprensin que permite al gerente de proyecto o a los ingenieros de software ajustar el proceso, el
proyecto o el producto para hacer mejor las cosas.

4.1 FACTORES DE CALIDAD DEL SOFTWARE

Concepto de Calidad:

Conjunto de propiedades y de caractersticas de un producto o servicio, que le confieren aptitud para

satisfacer una necesidad explcita o implcita (ISO 8402).

51
Calidad del Software:

Es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y
las necesidades o expectativas del cliente o usuario.

Factores que determinan la calidad del software:

Se pueden clasificar en dos grandes grupos (Pressman):

1. Medidas Directas: La medida o medicin decimos que es directa, cuando disponemos de un

instrumento de medida que nos muestra un resultado (generalmente numrico).
2. Medidas Indirectas: Cuando hablamos de sistemas informticos no siempre es posible
realizar una medida directa, porque no disponemos del instrumento adecuado que nos permita
realizar esa medicin.

MTRICAS DEL SOFTWARE.

Son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad,
eficiencia.

Entre las mtricas del software tenemos las siguientes:

1. Mtricas tcnicas: Se centran en las caractersticas del software. Aqu medimos la

complejidad lgica y el grado de modularidad del sistema. Mide la estructura del sistema, el
cmo est hecho.

2. Mtricas de calidad: Son todas las mtricas de software que definen de una u otra forma la
calidad del software; tales como correccin, exactitud, integridad, facilidad de uso,
estructuracin o modularidad, pruebas, facilidad de mantenimiento, reusabilidad, cohesin del
mdulo, acoplamiento del mdulo, etc. Estas son los puntos crticos en el diseo, codificacin,
pruebas y mantenimiento.
Proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y
explcitos del cliente. Es decir cmo voy a medir para que mi sistema se adapte a los requisitos
que me pide el cliente.
Correccin: es el grado en que el software desempea la funcin para la que fue creado y se
mide en defectos por KLDC.
Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si se
encuentra un error, al adaptarse si su entorno cambio 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 definicin de
amenaza y seguridad y se calcula: integridad = 1 (amenaza * (1 seguridad)).
Por ejemplo, dados los siguientes valores de un paquete de base de datos en dos proyectos,
podemos calcular la integridad:

52
 Integridad para el proyecto 1:
Integridad = 1 0.7 * (1 0) = 0.3
Integridad para el proyecto 2:
Integridad = 1 0.2 * (1 - 0.8) = 0.96
Si la amenaza (probabilidad de que un ataque ocurrir) es 0.25, y la seguridad (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 fuera 0.5 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 aplicacin al utilizarla.

3. Mtricas de Productividad: Se centran en el rendimiento del proceso de la ingeniera del

software. Es decir qu tan productivo va a ser el software que voy a disear. Se refiere a las
caractersticas del software.

4. Mtricas de costo: se centra en el costo total del sistema informtico.

5. Mtricas orientadas al tamao: Esta nos permite conocer el tiempo en el que se terminar el
software y cuntas personas se necesitan para su desarrollo, aqu medimos las variables con las
que desarrollamos el software.

Si una organizacin de software mantiene registros sencillos, se puede crear una tabla de datos
orientados al tamao, como la que muestra la figura, que lista cada proyecto de desarrollo de software y
las medidas correspondientes de cada proyecto.

Refirindonos a la entrada de la figura del proyecto alfa: se desarrollaron 12,100 lneas de cdigo
(LDC) con 24 personas-mes y con un costo de $168,000 dlares. Debe tenerse en cuenta que el esfuerzo
y el costo registrados en la tabla incluyen todas las actividades de ingeniera del software (anlisis,
diseo, codificacin y prueba) y no slo la codificacin. Otra informacin sobre el proyecto alfa indica
que se desarrollaron 365 pginas de documentacin, se registraron 134 errores antes de que el
software se entregara al cliente y se encontraron 29 errores despus de entregrselo al cliente dentro del
primer ao de utilizacin.
Tambin sabemos que trabajaron tres personas en el desarrollo del proyecto alfa.
LDC: Nmero de lneas de cdigo.
Esfuerzo: Nmero de horas invertidas en la realizacin del sistema.
$(000): Costo total del sistema informtico
Pp.doc.: El nmero de pginas de los manuales de documentacin del sistema.
Errores: Errores detectados antes de la entrega del sistema.
Defectos: Errores detectados despus de la entrega del sistema.
Personas: Personal que realiz el proyecto.

53
Con los datos registrados durante la elaboracin del proyecto podemos generar al final de dicho proyecto
el siguiente conjunto de mtricas:
Productividad = KLDC /Esfuerzo
Calidad = Errores / LDC
Documentacin = Pp.doc./LDC
Costo = $(000)/LDC

6. Mtricas orientadas a la funcin o puntos de funcin:

Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de
calcular las lneas de cdigo LDC, las mtricas de funcin se centran en la funcionalidad o
utilidad del programa. Los puntos de funcin nos indican la medida de la productividad.

Los puntos de funcin se obtienen utilizando una funcin emprica basado en medidas cuantitativas del
dominio de informacin del software y valoraciones subjetivas de la complejidad del software.
Se calculan los puntos de funcin en base a la siguiente tabla:

Factor de ponderacin
Parmetros de medicin Cuenta Simple Media Compleja
Nmero de entradas del usuario X 3 4 6 =
Nmero de salidas del usuario X 4 5 7 =
Nmero de consultas del usuario X 3 4 6 =
Nmero de archivos X 7 10 15 =
Nmero de interfaces externas X 5 7 10 =
Total puntos de funcin sin ajustar
TABLA 1

Valor con peso de complejidad = Suma del nmero de apariciones del elemento i (por ejemplo salidas)
para cada nivel de complejidad (bajo, medio, alto).

Sentencias
semnticas TABLA 2
1 -5 6 - 10 11 - +
pasos
del proceso
1 10 BAJO BAJO MEDIO
11 20 BAJO MEDIO ALTO
21 - + MEDIO ALTO ALTO

Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin

apropiada de la tabla. Los valores del mbito de informacin estn definidos de la siguiente manera:

1. Nmeros de entradas de usuario: se cuenta cada entrada del usuario que proporcione al
software diferentes datos orientados a la aplicacin. Las entradas deben ser distinguidas de las
peticiones que se contabilizan por separado. El flujo de datos deber tener una sola direccin,
del exterior al interior. Como consecuencia de una entrada siempre deber actualizarse un
archivo lgico interno. Ej. Pantallas de entrada de datos, lector de cdigos de barras, lector de
tarjetas magnticas y electrnicas, captura de imgenes, voz, etc.

54
 Clasificacin de las entradas:

2. Nmero de salidas del usuario: se encuentra cada salida que proporciona al usuario informacin
orientada a la aplicacin. En este contexto las salidas se refieren a informes, pantallas de salida de datos,
grabacin de bandas magnticas, listados, mensajes de error, Transferencia de datos a otras aplicaciones, ya
sea mediante archivos o transmisin de datos. Los elementos de datos individuales dentro de un informe se
encuentran por separado. Son todos aquellos procesos que hacen llegar datos desde la aplicacin hacia el
exterior, a un usuario o a otra aplicacin. El flujo de datos deber tener una sola direccin, del interior al
exterior.

Clasificacin de las salidas:

3. Nmeros de consultas al usuario: una peticin o consulta est definida como una entrada interactiva
que resulta de la generacin de algn tipo de respuesta en forma de salida interactiva (en lnea). Se
cuenta cada peticin por separado. Son todos aquellos procesos que estn formados por una combinacin de
entradas y salidas, produciendo una consulta a los datos. El flujo de datos deber tener dos direcciones.
Como consecuencia de una consulta no se modifican los datos del sistema. (Igual a tabla de entradas)

4. Numero de archivos lgicos internos: Es un grupo de datos relacionados, tal como los percibe el usuario
y que son mantenidos por la aplicacin. Se cuenta cada archivo maestro lgico, o sea una agrupacin lgica
de datos que puede ser una parte en una gran base de datos o un archivo independiente. Los archivos se
cuentan una sola vez, independientemente del nmero de procesos que los acceden. Ejemplos: Clientes,
Socios, Artculos, Proveedores.

55
 Clasificacin de los archivos lgicos internos:

5. Nmero de interfaces externas: agrupamiento lgico de datos que reside fuera de la

aplicacin, pero que proporciona informacin que puede usar la aplicacin. Se cuentan todas
las interfaces legibles por la mquina por ejemplo: archivos de datos, en cinta o discos que son
utilizados para transmitir informacin a otro sistema. Son archivos internos de otra aplicacin.

Clasificacin de los archivos de interfaz:

En base a las tablas anteriores, se coloca el nmero de elementos de las caractersticas de nuestro
sistema en el peso correspondiente a la tabla de valores de pesos y puntos de funcin sin ajustar.

BAJA MEDIA ALTA TOTAL

CARACTERISTICA
CANT PESO RESUL CANT PESO RESUL CANT PESO RESUL

Entradas 3 4 6

Salidas 4 5 7

Consultas 3 4 6

Archivos 7 10 15

Interfaces externas 5 7 10

Total caractersticas PFSA

TABLA 3 (Tabla de valores de pesos y puntos de funcin sin ajustar)

56
Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las
organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para determinar si una
entrada es denominada simple, media o compleja. No obstante la determinacin de la complejidad es
algo subjetivo.
Para calcular los puntos de funcin se utiliza la siguiente relacin.
PFA = Puntos de Funcin Ajustados = PFSA * [0.65 + 0.01 * (fi)]
Donde PFSA es la suma de todas las entradas de puntos de funcin sin ajustar obtenidas de la tabla
anterior.
Los valores 0.65 y 0.01 son valores establecidos por Albrecht obtenidos a partir de datos procedentes
de diferentes proyectos referentes al nivel de error producidos en un promedio de 5000 proyectos.
Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las respuestas a
las cuestiones sealadas en la siguiente tabla (Tabla 4).
Fi = total de factores de correccin.
Los valores constantes de la ecuacin anterior y los factores de peso aplicados en las encuestas de los
mbitos de informacin han sido determinados empricamente.

Evaluar cada factor de complejidad en escala 0 a 5.

TABLA 4

57
Le asignamos una puntuacin a cada factor de correccin FC:

TABLA 5

INVESTIGACIN INDIVIDUAL
Investigar sobre la importancia del uso de las mtricas del software y la
oposicin que presentan algunos desarrolladores.
Elabore un ensayo que tenga como mximo 5 pginas (sin incluir la
portada) para justificar su punto de vista al respecto.

4.2 MTRICAS PARA CADA FASE DEL CICLO DE VIDA DEL DESARROLLO DE
SISTEMAS.

4.2.1 MTRICAS PARA ANLISIS

En esta fase es deseable que las mtricas tcnicas proporcionen una visin interna a la calidad del
modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el
tamao del sistema resultante; es probable que el tamao y la complejidad del diseo estn
directamente relacionados.

Entre las Mtricas para el modelo de anlisis tenemos:

LA MTRICA BANG puede aplicarse para desarrollar una indicacin del tamao del software a
implementar como consecuencia del modelo del anlisis.

MTRICAS PARA CALIDAD DE LA ESPECIFICACIN: En estas mtricas se emplea una lista de

caractersticas que pueden emplearse para valorar la calidad del modelo de anlisis y la
correspondiente especificacin de requerimientos: especificidad (falta de ambigedad), completitud,
correccin, comprensibilidad, verificabilidad, consistencia interna y externa, factibilidad, concisin,
rastreabilidad, modificabilidad, precisin y reusabilidad.

58
MTRICAS BASADAS EN LA FUNCIN
La mtrica de punto de funcin (PF) puede usarse de manera efectiva como medio para medir la
funcionalidad que entra a un sistema. Esta mtrica puede usarse para: 1) estimar el costo o esfuerzo
requerido para disear, codificar y probar el software; 2) predecir el nmero de errores que se
encontrarn durante las pruebas, y 3) prever el nmero de componentes y/o de lneas fuente
proyectadas en el sistema implementado.

4.2.2 MTRICAS PARA EL MODELO DE DISEO

En este se genera la definicin de la arquitectura del sistema y del entorno tecnolgico que le va a dar
soporte, junto con la especificacin detallada de los componentes del Sistema de Informacin.
METRICAS DE ALTO NIVEL:
Las mtricas de alto nivel nos ayudan a localizar los mdulos ms complejos y, por lo tanto, aquellos
en los que debemos poner especial atencin. Tambin es utilizada para saber el nmero de mdulos
asignados a cada trabajador.
METRICAS DE BAJO NIVEL:
Las mtricas de bajo nivel tambin llamadas mtricas de caja blanca son las que nos ayudan a conocer
las interioridades del sistema. Hay tres tipos de mtricas de bajo nivel:
De cohesin
De acoplamiento
De complejidad

MTRICAS DEL DISEO ARQUITECTNICO.

Se enfocan en caractersticas de la arquitectura del programa con nfasis en la estructura
arquitectnica y en la efectividad de los mdulos o componentes dentro de la arquitectura. Dichas
mtricas son caja negra en tanto no requieren conocimiento alguno del funcionamiento interior de un
componente de software particular.
Card y Glass definen tres medidas de complejidad del diseo de software: complejidad estructural,
complejidad de datos y complejidad del sistema.

MTRICAS PARA DISEO ORIENTADO A OBJETOS

Whitmire describe nueve caractersticas distintas y mensurables de un diseo OO:
Tamao. El tamao se define en funcin de poblacin, volumen, longitud y funcionalidad.
Complejidad. Whitmire ve la complejidad en trminos de caractersticas estructurales al
examinar cmo se relacionan mutuamente las clases de un diseo OO.
Acoplamiento. Las conexiones fsicas entre elementos del diseo OO representan el
acoplamiento dentro de un sistema OO.
Suficiencia. Whitmire define suficiencia como el grado en el que una abstraccin posee las
caractersticas requeridas de l o en el que un componente de diseo posee caractersticas en
su abstraccin, desde el punto de vista de la aplicacin actual.
Completitud. La nica diferencia entre completitud y suficiencia es el conjunto de
caractersticas contra las cuales se compara la abstraccin o el componente de diseo.
Cohesin. La cohesividad de una clase se determina al examinar el grado en el que el conjunto
de propiedades que posee es parte del problema o dominio de diseo.
Primitivismo. Una caracterstica que es similar a la simplicidad, es el grado en el que una
operacin es atmica, es decir, la operacin no puede construirse a partir de una secuencia de
otras operaciones contenidas dentro de una clase. Una clase que muestra un grado de
primitivismo encapsula slo operaciones primitivas.
Similitud. El grado en el que dos o ms clases son similares en trminos de su estructura,
funcin, comportamiento o propsito se indica mediante esta medida.
Volatilidad. La volatilidad de un componente de diseo OO mide la probabilidad de que ocurrir
un cambio.

59
MTRICAS ORIENTADAS A LA CLASE.
Las medidas y mtricas para una clase individual, la jerarqua de clase y las colaboraciones de clase
sern invaluables cuando se requiera valorar la calidad del diseo OO.
Chidamber y Kemerer propusieron uno de los conjuntos de mtricas de software OO, en ocasiones
llamada suite de mtricas CK que incluyen 6 mtricas de diseo basadas en clase para sistemas OO:
1. Mtodos ponderados por clase (MPC)
2. Profundidad del rbol de herencia (PAH)
3. Nmero de hijos (NDH)
4. Acoplamiento entre clases de objetos (ACO)
5. Respuesta para una clase (RPC)
6. Falta de cohesin en mtodos (FCOM)

4.2.3 MTRICAS PARA CDIGO FUENTE

La teora de Halstead de la ciencia del software, propuso las primeras leyes analticas para el software
de computadora.
Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o
estimado el cdigo despus de completar el diseo. Las medidas son:
n1: nmero de operadores diferentes que aparecen en el programa.
n2: nmero de operandos diferentes que aparecen en el programa.
N1: nmero total de veces que aparece el operador.

N2: nmero total de veces que aparece el operando .

4.2.4 MTRICAS PARA PRUEBAS
La mayora de las mtricas para pruebas se concentran en el proceso de prueba, no en las
caractersticas tcnicas de las pruebas mismas. En general, los responsables de las pruebas deben
fiarse en las mtricas de anlisis, diseo y cdigo para que sirvan de gua en el diseo y ejecucin de
los casos de prueba.
El esfuerzo de las pruebas tambin se puede estimar utilizando mtricas obtenidas de las medidas de
Halstead. Usando la definicin 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)]
n1: no de operadores diferentes
n2: no de operandos diferentes
N2: no total de Operandos

4.2.5 MTRICAS PARA MANTENIMIENTO.

IEEE Std. Sugiere un ndice de madurez de software (IMS) que proporcione un indicio de la estabilidad
de un producto de software (con base en cambios que ocurran para cada liberacin del producto). Para
ello, se determina la siguiente informacin:
MT= nmero de mdulos en la liberacin actual
Fc= nmero de mdulos en la liberacin actual que cambiaron
Fa = nmero de mdulos en la liberacin actual que se agregaron
Fd = nmero de mdulos de la liberacin anterior que se borraron en la liberacin actual.

El ndice de madurez del software se calcula de la forma siguiente:

IMS = MT (Fa + Fc+ Fd)
MT

Conforme el IMS tiende a 1.0, el producto comienza a estabilizarse. El IMS tambin puede usarse
como una mtrica para planificar actividades de mantenimiento de software.

60
 EJEMPLO
El siguiente ejercicio se basa en un sistema de facturacin. Aplicar mtricas
orientadas a la funcin y al tamao.

Actividades observadas.
1. El cliente pide informacin sobre los productos
2. El vendedor da la informacin de los productos
3. El cliente realiza un pedido
4. El vendedor atiende el pedido
5. El vendedor llena el encabezado de la factura
1. Cada factura tiene un nmero impreso y el logo de la empresa
2. Llena el cdigo del vendedor
3. Selecciona el tipo de factura (crdito fiscal o consumidor final)
4. Llena los datos del cliente
1. Nombre
2. Direccin
3. Telfono
6. El vendedor llena el detalle de la factura
1. Cantidad del producto
2. Nombre del producto
3. Precio unitario del producto
4. Total producto
7. El vendedor suma los totales de los productos de la factura y lo escribe en el campo Sub-total
8. Se le aplica al Sub-total + el IVA y lo escribe en el campo Total
9. Se suma el Sub-total + el IVA y lo escribe en el campo Total
10. Se le entrega una factura al cliente para que la cancele
11. El cliente cancela la factura
12. Finalmente los productos son entregados al cliente.
DIAGRAMA ENTIDAD RELACIN:

Se obtienen 6 tablas normalizadas:

62
DIAGRAMA DE CASOS DE USO:

63
FACTIBILIDAD ECONMICA

De la factibilidad econmica determinamos los costos directos e indirectos del

nuevo sistema.

INVERSIN PERMANENTE
CONCEPTO Inversin Precio/ Proy. Gasto Anual
Inicial Hora Horas/ao
Recurso Humano.
Analista $10.00 120 $1,200.00
Programador $6.00 120 $ 720.00
Tipo de Equipo
Cantidad Hardware
2 Computadoras $ 1,400.00
1 Servidor $ 900.00
1 Impresora de red $ 94.00
1 Cable de red $ 7.00
1 Switch de 8 puertos $ 18.00
Cantidad Software
2 Sistema Operativo $ 1,000.00
Windows XP
2 Office 2010 $ 1,000.00
4 Antivirus Nod 32 $ 120.00
Cantidad Materiales
10 Resmas de Papel 500 $ 40.00
hojas
3 Cartuchos de tinta $ 500.00
Total
Total Inversin Inicial $ 4,539.00 $2,460.00
anualidad

FACTORES DE CORRECCIN (TABLA 5)

Factor Puntuacin
1. Comunicacin de los datos 3
2. Proceso distribuido 1
3. Objetivos de rendimiento 4
4. Configuracin de produccin usada por otros 2
5. Tasa de transacciones 3
6. Entrada de datos en lnea 4
7. Eficiencia con el usuario final 4
8. Actualizacin en lnea 4
9. Lgica de proceso interno compleja 3
10. Reutilizacin de cdigo 2
11. Contempla la conversin e instalacin 3
12. Facilidad de operacin 4
13. Instalaciones mltiples 2
14. Facilidad de cambios 3
total de factores de correccin 42
 MTRICAS ORIENTADAS AL TAMAO (TABLA 6)

Esfuerzo
Entorno y lenguaje Lneas de cdigo por Punto Horas por Punto de
de Funcin (LPF) Funcin (HPF)
Lenguajes de 2GL (Ensamblador) 300 20 - 30
Lenguajes de 3GL (Cobol) 100 10 - 20
Lenguajes de 4GL (Visual) 20 5 - 10

EVALUACIN DEL TEMA

El Despacho Contable Arrisgate conmigo, desea crear un sistema para el
control de clientes, que dispondr de la siguiente informacin. Aplicar las
mtricas de puntos de funcin y orientadas al tamao.

Pantallas de entrada para:

1. capturar informacin del cliente (20 campos)
2. Detalle de factura (4 campos)

Consulta y Reportes de:

1. Informacin del cliente (16 campos)
2. Factura (9 campos)
3. Datos del cliente que genera alrededor de 15 peticiones al usuario.
El sistema consta de 5 tablas en el DER, 3 de ellas constan de 3 12 campos y el resto tienen ms de
21 campos; adems de estar conectado a un fax y una impresora (cada una genera de 4 a 17
registros).
El sistema ser diseado en el lenguaje Visual Basic.Net.
El proyecto ser desarrollado por un analista (salario $7 por hora), un programador (salario $5 por
hora) y un diseador de base de datos (salario $8 por hora), quienes estarn trabajando 8 horas
diarias.
Se tiene una inversin inicial de $14,700 y una anualidad total de $12,300 para el proyecto.
Se estiman 7 horas de esfuerzo por punto de funcin (HPF), 275 pginas por documento, 9 errores y 2
defectos.

Calcular:
Mtricas de Puntos de Funcin:
1. Tabla de valores y pesos y Puntos de funcin sin ajustar PFSA.
2. Puntos de funcin ajustados PFA.
Mtricas orientadas al tamao:
a. Lneas de cdigo para el sistema, Esfuerzo horas persona, Duracin del proyecto, Costo del
proyecto, hacer la tabla.
b. Productividad, calidad, documentacin, costo por lneas de cdigo.
Se tomarn las tablas 5 y 6 como informacin por defecto.

BIBLIOGRAFA
Ingeniera de software. Un enfoque prctico. Roger S. Pressman - V Edicin.
Blanchard, B.S., System Engineering Management 2.da. 1997.

66