Trabajo Investigativo 03

Ingeniera de software

Presenta
David Camilo Snchez Mora 20132578060
Hector Felipe Hurtado Acosta 20131078401
Yojhan Rodrguez 20131078023
Sebastian Espitia 20131078050

Docente
Juan Carlos Guevara B.

Universidad Distrital Francisco Jos de Caldas

Sistematizacin de datos
Facultad tecnolgica
Bogot D.C Colombia 02 de marzo de 2016

2. Introduccin
En el presenta trabajo lo que se pretende realizar es investigar los diferentes
elementos importantes que hay que tener en cuenta para seleccionar y aplicar
mtricas en los proyectos de software. Siendo una de las herramientas necesarias
para mejorar la calidad del proyecto que se est elaborando.
Las mtricas adems, primeramente hay que conocerlas porque ese es uno de los
problemas que se ven a diario ya que no se ve la necesidad de trabajarla en
muchos proyectos que realmente no saben la importancia de las mtricas para
poder cumplir con el buen trabajo en el desarrollo de cada proyecto.
Por otro parte, se debe conocer los diferentes tipos de mtricas que existen, para
lo cual utilizaremos un ejemplo en cada uno de estos tipos para poder entender
con mayor facilidad lo que se pretende resaltar de estas herramientas
fundamentales en los proyectos.
3. Mtricas de software
3.1. Definicin de medida, mtrica e indicadores
Dentro del contexto de la ingeniera del software, una medida proporciona una
indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o
tamao de algunos atributos de un proceso o producto. La medicin es el acto de
determinar una medida.
Un indicador es una mtrica o una combinacin de mtricas que proporcionan una
visin profunda del proceso del software, del proyecto de software o del producto
en s.
Un indicador proporciona una visin profunda que permite al gestor de proyectos o
a los ingenieros de software ajustar el producto, el proyecto o el proceso para que
las cosas salgan mejor. Los indicadores de proceso permiten a una organizacin
de ingeniera del software tener una visin profunda de la eficacia de un proceso
ya existente (por ejemplo: el paradigma, las tareas de ingeniera del software,
productos de trabajo e hitos).
3.2. Importancia de las mtricas
El trmino de mtrica est relacionado con muchos casos de medicin
necesarios para conocer la calidad del producto. Esta medida se trabaja de
forma estadstica para tener en cuenta los aspectos principales en la

calidad del software entre ellos estn: anlisis, construccin, funcional,

documentacin, mtodos, proceso, usuario.
Adems, con las mtricas se puede determinar el costo y esfuerzo humano
requerido con la utilidad de los softwares que ya han sido diseados y que
implementan esta herramienta fundamental para conocer la calidad del
producto que se encuentre en proceso para intentar mejorarlo cada vez
ms.

3.3. Caractersticas
La medida del producto la podemos determinar con las siguientes caractersticas:

Indicar la calidad del producto

Evaluar la productividad de la gente que desarrolla el producto

Evaluar los beneficios en trminos de productividad y de calidad, con las
nuevas herramientas referentes a la ingeniera de software
Establecer una lnea de base para la estimacin
Ayudar a justificar el uso de nuevas herramientas o de formacin adicional.
Contando con los objetivos en la medicin del producto anteriormente
nombrados, las caractersticas principales de la mtrica son las siguientes:
o Ayudan a evaluar los modelos de anlisis y diseo.
o Ofrecen una indicacin de la complejidad de los diseos
procedimentales y el cdigo fuente.
o Facilitan el diseo de pruebas ms efectivas.

3.4. Factores crticos de xito

Una mtrica debe tener las propiedades matemticas y deseables, es decir,
el rango significativo en que debe estar el valor de la mtrica, por ejemplo,
el rango de 1 a 5 siendo cinco el valor mximo, uno el valor mnimo y 2.5 el
punto medio. Por lo que cada uno de los componentes se debe medir en
una escala racional, para poder determinar la comparacin con los dems
componentes.
De tal modo, el valor de la mtrica aumentar o disminuir dependiendo de
las caractersticas del software, es decir, cuando uno de los rasgos es
positivo, la mtrica aumenta y cuando uno de los rasgos es negativo la
mtrica disminuye.

Antes de publicarse o aplicarse en la toma de decisiones, cada mtrica

debe validarse empricamente en una amplia variedad de contextos y debe
medir el factor de inters, sin importar los dems factores. Debe crecer
para aplicarse en sistemas grandes y funcionar en varios lenguajes de
programacin y dominios de sistemas.
Para identificar los atributos de calidad del software que se desarrolla en un
computador se cre el estndar ISO 9126. Este estndar es el que
describe seis atributos clave de la calidad:

Funcionalidad: El grado en que el software cumple con las

necesidades que indican los subatributos: idoneidad, exactitud,
interoperabilidad, cumplimiento y seguridad.

Confiabilidad: Es la cantidad en que se puede dar uso el software

teniendo en cuenta los subatributos: madurez, tolerancia a fallas,
facilidad de recuperacin.

Facilidad de uso: Depende de la facilidad en que pueda dar uso del

software teniendo en cuenta los subatributos: facilidad de
comprensin, facilidad de aprendizaje y operabilidad.

Eficiencia: El grado en que el software trabaja de buena forma los

recursos del sistema, teniendo en cuenta los subatributos:
comportamiento en el tiempo, comportamiento de los recursos.

Facilidad de mantenimiento: La facilidad con que se repara el

software para el mantenimiento teniendo en cuenta los subatributos:
facilidad de anlisis, facilidad de cambio, estabilidad y facilidad de
prueba.

Portabilidad: La facilidad para llevar el software de un entorno a otro

teniendo en cuenta los siguientes subatributos: adaptabilidad,
facilidad para instalarse, cumplimiento, facilidad para reemplazarse.

4. Mtricas de proceso

4.1. Nombre
Las mtricas de proceso se realizan en todo el desarrollo del proyecto con un
tiempo determinado, normalmente extenso y son los que permiten al gestor:
Evaluar qu es lo que funciona y lo que no funciona.
Obtener un conjunto de indicadores de proceso para llevar a cabo el
mejoramiento en el proceso.
Y a la organizacin:
Adoptar una visin estratgica.
El proceso es uno de los varios factores controlables para la calidad del software y
el buen desempeo organizacional.
En las mtricas del software al medir el proceso, existen usos privados y pblicos
que los explicaremos a continuacin:
Mtricas privadas
Mtricas pblicas

Medida
Medicin
Mtrica
Indicador

4.2. Funcionamiento
o Mtricas privadas: Para el uso de cada persona, con las siguientes
caractersticas:

ndices de defectos.
Errores encontrados durante el desarrollo.

o Mtricas pblicas: A diferencia de la anterior, esta mtrica se

caracteriza por el uso de todo el equipo y cuenta con las siguientes
caractersticas:

ndices de defectos.
Errores encontrados en revisiones tcnicas del proyecto.
LDC (Lneas de cdigo producidas).

Puntos de fusin por mdulo y funcin.

4.3. Ejemplo de aplicacin

Medida: Valor asignado a un atributo de una entidad mediante una

medicin.
Ejemplo: 35.000 lneas de cdigo

Medicin: Es el acto de determinar una medida.

Ejemplo: Ana ser la encargada de medir las LDC de cada mdulo
del sistema.
Mtrica: Medida cuantitativa del grado en que un sistema,
componente o proceso posee un atributo dado. Incluye el mtodo de
medicin.
Ejemplo: La productividad de este proyecto fue de 500 lneas
(LDC/persona-mes)
Indicador: Es una mtrica o combinacin de mtricas que
proporcionan una visin profunda del proceso de software.
Ejemplo: La productividad media de nuestra empresa es de 500
(LDC/pm)

5. Mtricas de proyecto
5.1. Nombre
Las mtricas del proyecto proporcionan una visin del proceso y los avances
detallados acerca del proyecto que se lleva a cabo, y pue den usarse en todo tipo
de proyectos.
Estas mtricas son efectuadas para conocer el avance o los desvos al plan
original. Pueden ser usadas para medir el estado, efectividad o progreso de las
actividades de un proyecto y as contribuir a tomar decisiones estratgicas ante los
desvos, incidentes o diferentes problemas que surgen en la ejecucin.
Adems, sirven para conocer los resultados de un equipo de trabajo y aumentar la
productividad.
5.2. Funcionamiento
En el contexto de un proyecto en particular, las mtricas describen las
expectativas sobre un determinado entregable o sobre las tareas que se

ejecutarn para producirlo. Por ejemplo, si el entregable del proyecto es Datos

convertidos al nuevo sistema y validados por el cliente interno, un grupo de
mtricas podra ser:
Cuntas tablas de los sistemas legacy fueron migradas al nuevo sistema hasta
hoy? Cuntas tablas del nuevo sistema fueron validadas por el cliente interno
hasta hoy? En qu pantallas del sistema se encuentran las tablas convertidas y
cuntas de ellas han sido validadas por el cliente interno?
Este conjunto de tres mtricas se medira cada semana durante el proceso de
conversin, para tener una idea acerca del avance y los desvos.
5.3. Ejemplo de aplicacin
Identifican eventos y tendencias importantes en los proyectos y otorgan a la
organizacin la informacin necesaria para la toma de decisiones.
Sirven como vocabulario comn entre el grupo de personas que participa

de la implementacin de los proyectos, y el grupo que los patrocina

(Sponsors, Stakeholders).
Sirven como motivacin para el equipo, porque relacionan en esfuerzo
personal de los miembros con los resultados generales del proyecto.

6. Mtricas de producto
6.1. Nombre
Las mtricas de producto permiten medir de forma cuantitativa la calidad de los
atributos internos de un producto. Permite evaluar la calidad antes de la
construccin y conocer, por ejemplo: la calidad del software, quin lo hace, por
qu es importante, cules son los pasos, cul es el producto obtenido, cmo estar
seguro de hacerlo correctamente, entre otros.

6.2. Funcionamiento

Estas medidas se utilizan adems para comprender los atributos de los modelos
que se crean y evaluar la calidad de los productos de la ingeniera o de los
sistemas que se construyen.
6.3. Ejemplo de aplicacin
Por ejemplo, se puede medir la extensin, la cantidad, la dimensin, la capacidad
o el tamao de algn atributo del producto o proceso.
Medir la funcionalidad entregada y tamao del sistema.

7. Mtricas de calidad
7.1. Nombre
Para llegar a la definicin de mtricas de calidad, es necesario primero definir que
es calidad, llegar a un significado o definicin global de este trmino es una
cuestin compleja, debido a la pluralidad de definiciones que puede llegar a tener,
a continuacin se mostraran algunas:
La calidad es el conjunto de propiedades y caractersticas de un producto o
servicio que le confieren su aptitud para satisfacer unas necesidades
explicitas o implcitas [ISO 8402].
La calidad del software es el grado con el que cumple los requerimientos
especificados y las necesidades o expectativas del cliente o usuario [IEEE
Std 610].
La concordancia con los requisitos funcionales y de rendimientos
explcitamente documentados y caractersticas implcitas que se espera de
todo software desarrollado profesionalmente [Pressman].

Analizando estas definiciones es posible establecer una general: Es el grado de

respuesta del conjunto de caractersticas o propiedades de un objeto, que se le da
a los requerimientos establecidos.
Con esto es posible definir lo es mtricas de calidad es la medida cuantitativa del
grado en que un sistema, componente o proceso evala su calidad.
7.2. Funcionamiento
Puntos importantes de la calidad de software (Pressman Quinta edicion)

Los requisitos del software son la base de las medidas de la calidad. La

falta de concordancia con los requisitos es una falta de calidad.
Unos estndares especficos definen un conjunto de criterios de desarrollo
que guan la manera en que se hace la ingeniera del software. Si no se
siguen los criterios, habr seguramente poca calidad.
Existe un conjunto de requisitos implcitos que a menudo no se nombran. Si
el software cumple con sus requisitos explcitos pero falla en los implcitos,
la calidad del software no ser fiable.

Medicin de la calidad
Existen muchas medidas de calidad del software en las que se encuentran [Gilb]:
Exactitud
Un programa debe operar correctamente o proporcionara poco
valor a sus usuarios.
Es el grado en el cual el software realiza la funcin requerida.
La medida ms comn son los defectos (falta verificada de
acuerdo con los requerimientos) por KLOC.
Los defectos son aquellos problemas reportados por un usuario
de programa.
Capacidad de mantenimiento
El mantenimiento y soporte del software representan ms
esfuerzo que cualquiera otra actividad de ingeniera de software.
La capacidad de mantenimiento es la facilidad con la que un
programa puede corregirse si se encuentra un error, se adapta a
un entorno cambiante o cambio en requerimientos.
Integridad
Mide la habilidad de un sistema para resistir ataques a su
seguridad.

Los ataques pueden hacer a programas, datos y documentacin.

Tiene dos atributos adicionales: amenaza y seguridad.
Amenaza es la probabilidad de que un ataque de un tipo
especfico ocurrir dentro de un tiempo dado.
Seguridad es la probabilidad de que el ataque de un tipo
especfico se repeler.
Integridad = Sumatoria [1( amenaza(1seguridad))]

Usabilidad
Si el programa no es fcil de usar, con frecuencia est condenado
al fracaso.
La usabilidad es un intento por cuantificar la facilidad de uso.
Para las otras medidas existentes McCall en 1977, los agrupo en conjuntos
llamados factores de calidad, entre los cuales existen tres factores:
Revisin del producto.
Transicin del producto.
Operacin del producto.
Factores de calidad de McCall:

A continuacin se podr observar una tabla interrelacionada entre las mtricas de

calidad existentes y una serie de factores de calidad, en la que se muestra
factores que son usados por la mtrica de calidad y que nos permiten escoger
ms especficamente que mtricas son las adecuadas para evaluar ciertos
aspectos de nuestro producto.

Eficiencia en la remocin del defecto (ERD)

Es una medida de la habilidad de filtrado de las acciones de aseguramiento y
control de la calidad segn se aplican a lo largo de todas las actividades del marco
conceptual del proceso.
La ERD se puede ver como un todo y evaluar de la siguiente manera:
E
ERD=
E+ D
Donde
E: Numero de errores (antes de entregar el software).
D: Numero de defectos que se encontraron (despus de la entrega).
El valor ideal para la ERD es 1. Es decir, no se encuentran defectos en el
software. En realidad, D ser mayor que 0, pero el valor de la ERD todava puede
tender a 1 conforme E aumenta para un valor dado de D. De hecho, conforme E
aumenta, es probable que el valor final de D disminuir (los errores se filtran antes
de convertirse en defectos).
La ERD tambin puede usarse dentro del proyecto a fin de valorar la habilidad de
un equipo para encontrar errores antes de que pasen a la siguiente actividad de
marco conceptual o accin de ingeniera de software. Cuando se usa en este
contexto, la ERD se redefine como
Ei
ERDi =
Ei + E i+1
Donde

Ei

, es el nmero de errores encontrados durante la accin i de ingeniera

del software y

Ei+1

es el nmero de errores encontrados durante la accin i +1

de ingeniera del software que son rastreables por errores que no se descubrieron
en la accin i de ingeniera del software.
7.3. Ejemplo de aplicacin
Se mostrar un ejemplo de los pasos y caractersticas de la evaluacin de calidad,
que se le podr realizar a cualquier proyecto de tipo software al cual se quiera
estudiar el grado de calidad con el cual cuenta.

Modelo de Medicin de la Calidad:

A continuacin se mencionaran las fases que debe tener un diseo de software

establecido en 8 actividades y dependiendo de los diferentes elementos que debe
tener un software dentro de su proceso.
Actividad Activid Activi Activid Activi
1
ad 2 dad 3
ad 4
dad 5
Fase

Referen
cia
modelo
9126

Activi
dad 6

Activi
dad 7

Activi
dad 8

Anlisis de Diseo Dise

requisitos de
o
arquite detalla
ctura
do de
softwa
re

Codifica
cin y
pruebas
de
softwar
e

Integra
cin y
prueba
s de
softwar
e

Integra Instala Acepta

cin y cin
cin y
prueba
apoyo
s de
sistem
a

Calidad
requerida
por el
usuario
Calidad
interna
requerida
Calidad
externa
requerida

Calidad
en uso
predich
a
Calidad
externa
medida
Calidad
externa
predich
a
Calidad
interna
medida

Calida
d en
uso
predich
a
Calida
d
extern
a
medida
Calida
d
extern
a
predich
a
Calida
d
interna
medida

Calida
d en
uso
predich
a
Calida
d
extern
a
medida
Calida
d
interna
medida

Calidad
en uso
predich
a
Calidad
externa
predich
a
Calidad
interna
medida

Calida
d en
uso
predic
ha
Calida
d
extern
a
predic
ha
Calida
d
intern
a
medid
a

Calida
d en
uso
predic
ha
Calida
d
extern
a
medid
a
Calida
d
interna
medid
a

Calida
d en
uso
medida
Calida
d
extern
a
medida
Calida
d
interna
medida

Entrega Requisitos Diseo

bles de calidad de
clave del usuario arquite
Requisitos ctura
de calidad
externa
Requisitos
de calidad
interna
Mtrica
s
utilizad
as

Dise
o
detalla
do de
softwa
re

Internas
Interna Intern
(externas s
as
pueden
validar
especificac
iones)

Cdigo
y
resultad
os de
pruebas

Produc
to y
resulta
dos de
prueba
s

Sistem
a
intgrad
oy
resulta
dos de
prueba
s

Sistem
a
instala
do

Produc
to
entreg
ado

Internas
y
externa
s

Interna
sy
extern
as

Interna
sy
extern
as

Interna
sy
extern
as

Calida
d en el
uso,
interna
sy
extern
as

Pasos Sugeridos:

1. Identificacin de requisitos de calidad

2. Especificacin de la evaluacin
3. Diseo de la evaluacin
4. Ejecucin de la evaluacin
5. Retroalimentacin a la organizacin

Identificacin de requisitos de calidad

Caracterstica

Funcionalidad

Fiabilidad

Subcaracterstica

Peso

Adecuidad

Exactitud

Interoperabilidad

Seguridad

Conformidad

Madurez

Tolerancia a fallos

Recuperabilidad

Tolerancia a fallos

...

...

...

Especificacin de la evaluacin
Caracterstica Subcaracterstica Mtrica Nivel Requerido Nivel Obtenido
Funcionalidad

Adecuidad
Exactitud
Interoperabilidad
Seguridad
Conformidad

Fiabilidad

Madurez
Tolerancia a fallos
Recuperabilidad
Tolerancia a fallos

...

...

Diseo de la evaluacin
Caracterstic Subcaracterstic Entregable
a
a
s a Evaluar

Mtricas
Internas
a Aplicar

Mtricas Mtrica
Externas
s de
a Aplicar Calidad
en el
Uso

Funcionalidad Adecuidad
1.

1.

1.

2.

2.

2.

3.

3.

3.

1.

1.

2.

2.

3.

3.

Exactitud

Interoperabilidad

...

...

(no
aplica)

(no aplica) (no

aplica)

...

...

8. Software de mtricas 01
8.1 PMD
PMD es una herramienta que comprueba que nuestra aplicacin cumpla una serie
de reglas que nos ayudan a obtener un cdigo ms elegante, sencillo y
mantenible. Estas reglas se agrupan por conjuntos y pueden ser reglas de
complejidad, como que la complejidad ciclomtica no sea demasiado alta; de
diseo, como no usar interfaces como meros contenedores de constantes; de
optimizacin, como procurar usar ArrayList en lugar de Vector; etc.
PMD se puede utilizar desde linea de comandos, o puede integrarse con multitud
de IDEs y herramientas, como Eclipse, NetBeans, Maven o JEdit. Y aunque
algunos de los casos que comprueba PMD ya se tengan en cuenta en Eclipse,
sigue siendo una utilidad muy interesante para aadir a nuestra caja de
herramientas.
8.2 Requerimientos tecnolgicos

Netbeans 7.4
Internet
Windows 7

8.3 Funcionalidades

Detectar duplicacin de cdigo.

Detectar cdigo muerto (variables, parmetros o mtodos sin usar).
Detectar complejidad de mtodos.
NPathComplexity: es el nmero de rutas de ejecucin a cclicos a travs de
ese mtodo.
ExcessiveMethodLength: el mtodo est haciendo demasiado.
ExcessiveParameterList: listas de parmetros largos pueden indicar que un
nuevo objeto debe ser creado para envolver los numerosos parmetros.
ExcessiveClassLength: archivos de clase largos son indicios de que la
clase puede estar tratando de hacer demasiado.
Complejidad ciclomtica: complejidad se determina por el nmero de
puntos de decisin en un mtodo ms uno para la entrada mtodo.
ExcessivePublicCount: puede necesitar un gran nmero de mtodos y
atributos declarados en una clase puede indicar la clase de pblicos para
romperse como se requerir un mayor esfuerzo para poner a prueba a tope.
TooManyFields: las clases que tienen demasiados campos podra ser
rediseado con pocos campos, posiblemente a travs de algn objeto
agrupacin anidada de parte de la informacin.

NcssMethodCount: esta regla utiliza el algoritmo NCSS (No Comentando

Declaraciones Fuente) para determinar el nmero de lneas de cdigo para
un mtodo dado. NCSS ignora los comentarios, y cuenta las declaraciones
reales.
NcssTypeCount: Esta regla utiliza el algoritmo NCSS (No Comentando
Declaraciones Fuente) para determinar el nmero de lneas de cdigo para
un tipo dado. NCSS ignora los comentarios, y cuenta las declaraciones
reales.
NcssConstructorCount: esta regla utiliza el algoritmo NCSS (No
Comentando Declaraciones Fuente) para determinar el nmero de lneas
de cdigo para un constructor determinado. NCSS ignora los comentarios, y
cuenta las declaraciones reales.
TooManyMethods: una clase con demasiados mtodos es probablemente
un buen objetivo para la refactorizacin, con el fin de reducir su complejidad
y encontrar una manera de tener objetos de grano ms fino.

9. Software de mtricas 02
9.1 CheckStyle
Checkstyle es una herramienta de desarrollo que ayudar a los programadores a
escribir cdigo Java para que se adhiera a un estndar de codificacin. Automatiza
el proceso de comprobacin de cdigo Java. Esto lo hace ideal para los proyectos
a los que se desea aplicar un estndar de codificacin.
Checkstyle es altamente configurable y se puede hacer para apoyar casi cualquier
estndar de codificacin. De tal manera que se puedan suministrar diferentes
estndares de cdigo para su posterior comprobacin mediante la herramienta.
9.2 Requerimientos tecnolgicos

Netbeans 7.4 / ecplise

Internet
Windows 7

9.3 Funcionalidades

Comentarios Javadoc: Te permite, por ejemplo, obligar a comentar los

nombres de clases, todos los mtodos menos los get/set y los atributos
pblicos.

Convenciones de nombres: puedes definir una expresin regular para el

nombre de todo.

Cabeceras: expresiones regulares para la cabecera de los ficheros.

Imports: reglas para los import, como no usar *, imports sin usar, etc.

Violaciones de tamao: define un mximo para el tamao de tus clases,

mtodos, lneas y nmero de parmetros de un mtodo.

Espacios en blanco: un montn de reglas para definir donde se ponen

espacios en blanco y tabuladores en el cdigo.

Modificadores: establece un orden para los modificadores y evita

modificadores innecesarios.

Bloques: reglas para los bloques de cdigo y sus llaves.

Problemas en la codificacin: Ac hay de todo, desde malas prcticas

tipo asignaciones internas y posibles fuentes de bugs como definir un
mtodo equals que no es el equals(Object), a cosas ms estticas o poco
prolijas, como que el default sea el ltimo elemento en
un switch o parntesis innecesarios.

Diseo de clases: varias reglas sobre el diseo de interfaces y clases, con

especial atencin en las excepciones.

Duplicados: te permite definir un

buscar cdigo duplicado en tus clases.

Mtricas: define mximos para mtricas como complejidad ciclomtica,

complejidad de expresiones lgicas, npath, lneas de cdigo seguidas sin
comentar y dependencia de clases.

Miscelneo: variables final, indentacin, un buscador de expresiones

regulares y varias cosas ms.

J2EE: reglas para EJBs.

Otros: internos a CheckStyle y activados por defecto.

Filtros: para eventos de auditoria del propio CheckStyle, no hace falta

mirarlos.

mnimo

de

lneas

para

10. Software de mtricas 03

10.1. COCOMO II
(Constructive Cost Model) surge como una alternativa para incluir componentes
de incerteza en las estimacins conforme al nivel de informacin disponible. Este

es un modelo paramtrico que establece ecuaciones matemticas para describir

las relaciones entre el tamao del software - factor primario de costo usualmente
representado en trminos de puntos de funcin - y otros factores secundarios que
buscan capturar particularidades de producto, proceso, personas y plataforma.
Esos factores son denominados Cost Drivers, siendo algunos de efecto
proporcional y otros de efecto exponencial.
El modelo ofrece un framework completo para determinar factores de
productividad locales (Constantes de productividad) a partir de datos como el
plazo y el esfuerzo de proyectos pasados. Una de las principales virtudes de
COCOMO II es ofrecer una estimacin de plazo y esfuerzo, y a partir de estos
sugerir el tamao del equipo y no lo opuesto; como sucede generalmente.
10.2. Requerimientos tecnolgicos

10.3 Funcionalidades

Hacer que la inversin u otras decisiones financieras que implican un esfuerzo de

desarrollo de software
Configuracin de los presupuestos y programas de proyectos como base para la

planificacin y el control
Decidir o negociar compensaciones entre los factores de costos de software,

programacin, funcionalidad, rendimiento o calidad

Hacer costo de software y las decisiones de gestin de riesgos horario
Decidir qu partes de un sistema de software para desarrollar, reutilizacin,

arrendamiento o compra
Decisiones de inventario de software legado Hacer: qu partes de modificar,

eliminar gradualmente, externalizar, etc

Establecer estrategias de inversin mixtos para mejorar la capacidad del software
de organizacin , a travs de la reutilizacin, las herramientas, la madurez del
proceso, la subcontratacin, etc

Decidir cmo implementar una estrategia de mejora de procesos, como la prevista

en el SEI CMM

10.4. Ejemplo de aplicacin

www.youtube.com/watch?v=nRchCHu4tL011

11. Software de mtricas 04

11.1 Costar
Es una herramienta basada en COCOMO y que es usada en el desarrollo de
software para hace estimaciones tales como:

Duracin del proyecto

Personal requerido
Esfuerzo requerido para la realizacin del proyecto
Costo del proyecto

Con este software se puede trabajar con:

COCOMO (Tradicional)
COCOMO 8.1 (Tradicional)
COCOMO Incremental
REVIC
COCOMO (Usuario Definido)
COCOMO II
11.2. Requerimientos tecnolgicos
Operating Systems (Win 95, Win 98, Win NT, Win 2000, Win XP)

11.3. Funcionalidades
La mayora de sus interacciones con Costar implicar la creacin y modificacin
componentes. Vas a definir subcomponentes, asignar valores de controlador de
costos, estimar el tamao de cada componente, etc.
Uno de los componentes siempre se distingui como "el componente de
corriente". El nombre del componente actual, los factores de coste que ha
asignado a la misma, y otros datos que describen el componente actual se
muestran en la ventana principal de Costar.
Un componente dado puede estar compuesto de cualquier nmero de
subcomponentes. Cuando se crea un nuevo subcomponente, se convierte en un
subcomponente del componente actual.Hereda los valores para cada uno de sus
atributos de su componente principal. Los siguientes atributos son heredados:
Ajustes de los parmetros de costes
Costo por persona-Mes ajustes
Configuracin de mantenimiento, adaptacin y conversin
Costar hace que sea fcil de realizar "what-if" anlisis y la comparacin de los
diferentes planes de proyecto. Usted puede desarrollar una nueva estimacin
sobre la base de una ms antigua y, a continuacin, utilizar Costar para comparar
los dos.
Una estimacin Costar consiste en:
Un nombre
Un ID
Un comentario de una lnea

5 conductores Scale (COCOMO modelos II) o un modo de desarrollo (COCOMO

81 modelos)
Una base de datos asociada (por ejemplo, COCOMO II.2000)
Ajustes de APM
Nombres y costes de mano de obra de las clases
Uno o ms componentes
Segn una estimacin, siempre se distingui como "la estimacin actual". Todos
los comandos Costar operan en la estimacin actual.
Cuando no hay ms que un solo componente de una estimacin, el valor SLOC
para el componente es idntico al valor total SLOC para la estimacin. Pero
cuando un componente tiene subcomponentes, el valor SLOC se deriva de los
valores SLOC de sus subcomponentes.
Costar permite especificar valores SLOC de tres maneras diferentes:
Puede introducir explcitamente un valor SLOC como 3000.
Puede utilizar la ficha reutilizacin para calcular el SLOC.
Puede utilizar la ficha Punto Funcin para calcular el SLOC.
11.4. Ejemplo de aplicacin
https://www.youtube.com/watch?v=y4SlF6lowJc

12. Cuadro comparativo de mtricas de software

Clasificacin

De complejidad

De calidad

De competencia

De desempeo

Estilizadas

Caracterstica

Factor a evaluar

Mtricas que definen la medicin

Volumen, tamao, anidaciones,

de la complejidad:

y configuracin

Mtricas que definen la calidad

del software:

Exactitud, estructuracin o
modularidad, pruebas

Mtricas que intentan valorar o

mantenimiento
Productividad de los

medir las actividades de

programadores con respecto a

productividad de los

su certeza, rapidez, eficiencia y

programadores.
Mtricas que miden la conducta

competencia.
Sistemas de un software, bajo

de mdulos y sistemas de un

la supervisin del SO o

software.
Mtricas de experimentacin y de

hardware.

preferencia: estilo de cdigo,

convenios, limitaciones.

Estilo de cdigo, convenios,

limitaciones.

13. Conclusiones

Se investig los diferentes elementos importantes que hay que tener en cuenta
para seleccionar y aplicar mtricas en los proyectos de software. Siendo una de
las herramientas necesarias para mejorar la calidad del proyecto que se est
elaborando.
Las mtricas adems, primeramente hay que conocerlas porque ese es uno de los
problemas que se ven a diario ya que no se ve la necesidad de trabajarla en
muchos proyectos que realmente no saben la importancia de las mtricas para
poder cumplir con el buen trabajo en el desarrollo de cada proyecto.
Por otro parte, se conoci los diferentes tipos de mtricas que existen, para lo cual
se utilizo un ejemplo en cada uno de estos tipos para poder entender con mayor
facilidad lo que se pretende resaltar de estas herramientas fundamentales en los
proyectos.

14. Bibliografa
Mara Esther Ruivola (2008) Informe ejecutivo. Mtricas del producto para el
software.
SALAZAR, Enma E., SALAZAR, Manuel F. MTRICAS DE PROCESO Y
PROYECTO, Universidad Tcnica Particular de Loja, Escuela de Ciencias en
Computacin
PRESSMAN, Roger, (2005) Ingeniera del Software. Un enfoque prctico. Sexta
edicin. McGrawHill Interamericana Mexico, 2005.
CABRERA, Armando, (2006) Ingeniera del Software. Primera Edicin,
Universidad Tcnica Particular de Loja. Loja Ecuador.
GILB, T, (1988) Principles of software Project managagement.
Estandares ISO 8402
Estandares IEEE
Pginas web
http://www.javiergarzas.com/2012/03/herramientas-de-calidad-software.html
https://ivanator.wordpress.com/2009/03/05/metricas-de-calidad-connetbeans-y-hudson/
http://java-white-box.blogspot.com/2012/12/checkstyle-que-es-el-checkstylereglas.html
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo4.
pdf
http://uptaprocesodepruebasycalidadymetricas.blogspot.com/2012/12/ejempl
os-de-metricas.html
http://sedici.unlp.edu.ar/bitstream/handle/10915/19762/2397Estayno_UNNE_UTN.pdf?sequence=1
http://eprints.ucm.es/11487/1/Proyecto_Fin_de_M%C3%A1ster.pdf
http://www.uv.mx/personal/asumano/files/2012/08/MetricasTecnicas.pdf