TRABAJO INVESTIGATIVO 03

METRICAS DE SOFTWARE

Presenta
Camilo Andrs Frontado Escobar
Erik Alexis Valderrama
Alejandro Jimnez Mateus
Harold Jhovany Lpez Medina

Docente
Juan Carlos Guevara B.

Asignatura
Ingeniera de Software

Universidad Distrital Francisco Jos de Caldas

Tecnologa en Sistematizacin de datos
Facultad Tecnolgica
Bogot D.C Colombia - 03 de Marzo de 2016

CONTENIDO

2. Introduccin....2
3. Mtricas de Software............3
3.1. Definicin de medida, mtricas e indicadores.......3
3.2. Importancia....................4
3.3. Caractersticas....4
3.4. Factores crticos de xito......5
4. Mtricas de proceso.....5
5. Mtricas de proyecto...........7
6. Mtricas de producto...........8
7. Mtricas de calidad...........10
8. Software de Mtricas 01............18
9. Software de Mtricas 02............23
10. Software de Mtricas 03.................28
11. Software de Mtricas 04.............32
12. Cuadro comparativo de mtricas...........34
13. Conclusiones.........34
14. Bibliografa..35

2. Introduccin
Para el proceso de desarrollo de un proyecto de software, se den realizar una
serie de pasos y actividades para que su ejecucin sea ejecutada de una
manera correcta, dentro de estas actividades tenemos, la estimacin, la
planificacin del programa, el anlisis de riesgos, la medicin y las mtricas.
Antes de comenzar con la ejecucin de un proyecto de software, se deben
recopilar datos, calcular mtricas y evaluarlas, estos pasos son muy
importantes para que el producto sea ejecutado de manera correcta siguiendo
unos estndares mnimos.
El objetivo de la consideracin de mtricas de software es llevar a cabo anlisis
de puntos dbiles y fuertes dentro de la ejecucin del proyecto, dbiles como el
aumento de esfuerzo y fuertes como la calidad, reusabilidad y madurez, en los
que se ven involucrados los ingenieros y administradores de software, el uso

de las mtricas se est adoptando con xito en el amplio mercado de desarrollo

de software introduciendo nuevas investigaciones y consideraciones por parte
de administradores y usuarios, en pro de la necesidad de un enfoque ms
disciplinado y de la calidad.
En el presente documento, se establecer el concepto de mtrica y medida, la
importancia de las mtricas y sus caractersticas, los diferentes tipos de
mtricas a introducir en un proyecto de software para que sea realizado
correctamente, ejemplos de herramientas de software para la evaluacin de
mtricas, funcionamiento y caractersticas.

3. Mtricas de software
3.1. Definicin de medida, mtrica e indicadores
Medida: Es un elemento el cual proporciona una indicacin cuantitativa de la
extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de
un proceso o producto.
Mtrica: Este trmino 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.
Segn lo anterior podemos definir las Mtricas de Software o Medidas de
Software como la aplicacin continua de tcnicas basadas en las medidas de
los procesos de desarrollo de Software y sus productos, para producir una
informacin de gestin significativa y a tiempo. Esta informacin se utilizar
para mejorar esos procesos y los productos que se obtienen de ellos.
Indicador: es una mtrica o una combinacin de mtricas que proporcionan
una visin profunda del proceso del software 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.
Los indicadores de proyectos permiten:

Evaluar el estado del proyecto en curso.

Seguir la pista de los riesgos potenciales.
Detectar las reas de problemas antes de que se conviertan en crticas.
Ajustar el flujo y las tareas del trabajo.

Evaluar la habilidad del equipo del proyecto en controlar la calidad de los

productos de trabajo del software.

3.2. Importancia de las mtricas

Las mtricas de software se utilizan para propsitos estratgicos y son
utilizadas en el proyecto para minimizar la planificacin de desarrollo haciendo
los ajustes necesarios que eviten retrasos y reduzcan problemas y riesgos
potenciales, son utilizadas tambin para evaluar la calidad de los productos en
el momento actual y cuando sea necesario, modificando el enfoque tcnico que
mejore la calidad.
Para establecer objetivos de mejora durante el proceso de desarrollo de
software, se debe comprender el estado actual del desarrollo del software. Si
no se mide, no hay una forma real de determinar si se est mejorando y si no
se est mejorando, se est perdido.

3.3. Caractersticas
Objetivos de la medicin:

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.

Las caractersticas principales de la mtrica son:

Ayudan a evaluar los modelos de anlisis y diseo.

Ofrecen una indicacin de la complejidad
procedimentales y el cdigo fuente.
Facilitan el diseo de pruebas ms efectivas.

de

los

diseos

Adems, 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.

3.4. Factores crticos de xito

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 operatividad.

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
Las mtricas de proceso son medidas cuantitativas que permiten obtener un
conjunto de indicadores que lleven a la mejora de los procesos de software, se
recopilan datos bsicos de calidad y productividad, se analizan y se
proporcionan bases, con el fin de proporcionar un conjunto de indicadores para
los proceso de software.
Para mejorar cualquier proceso se debe:

Medir atributos del proceso

Definir y desarrollar un juego de mtricas para esos atributos

Utilizar las mtricas para encontrar indicadores para la estrategia de

mejora

INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/
producto.jpg"
\*
MERGEFORMATINET
INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/

producto.jpg"
\*
MERGEFORMATINET
INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/
producto.jpg"
\*
MERGEFORMATINET
INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/
producto.jpg"
\*
MERGEFORMATINET
INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/
producto.jpg"
\*
MERGEFORMATINET
INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/
producto.jpg"
\*
MERGEFORMATINET
INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/
producto.jpg"
\*
MERGEFORMATINET
INCLUDEPICTURE
"http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/
producto.jpg"
\*
MERGEFORMATINET

Las mtricas de proceso proporcionan de manera indirecta la eficacia que

puede tener, calculan los procesos alternos que pueden llevar los
procedimientos en el desarrollo de la gestin del proyecto. Los resultados se
miden en la cantidad de pautas de trabajo entre los empleados, miden el
progreso, estado y productividad en la toma de decisiones, las estrategias
organizacionales calculan factores de riesgo minimizando procesos
ineficientes.
Para identificar y organizar las mtricas en el proceso de software existen
varias subdivisiones que le imponen caractersticas. Los indicadores del
proceso permiten al gestor, evaluar lo que funciona y lo que no ya a su vez dar
a la organizacin, una visin profunda de la eficacia de un proceso ya
existente.
Mtricas privadas: Identifican defectos de cada individuo por cada
componente en el que interviene sus habilidades de desarrollo.
Mtricas pblicas: Para este caso se verifican ngulos en el que el trabajo en
equipo que no tiene comportamientos colaborativos, indicios de proyecto,
esfuerzo y planificacin.
La mejora de procesos se influencian a partir de la destreza de y motivacin del
personal, analizar la complejidad del producto y verificar la tecnologa existente.

El producto y la tecnologa, utilizadas por los individuos que intervienen de

manera directa e indirecta en la gestin de un proyecto determinado, las
condiciones del entorno de intervencin de las personas miden el desarrollo
que tendr, estas condiciones permiten definir las reglas iniciales del proceso
de software y permitir la informacin que proporcionara una contribucin de la
calidad de software.
Los resultados deben poseer como mnimo ciertas pautas y deben ser
considerados los siguientes:
Medida de errores detectados antes de la entrega del software
Defectos detectados
Productos de trabajo entregados
Esfuerzo humano y tiempo consumido
Ajuste con la planificacin
Existen cuatro razones para medir: Caracterizar, Evaluar, Predecir y Mejorar
Medida: Valor asignado a un atributo de una entidad mediante una
medicin.
o Ejemplo: 35.000 lneas de cdigo
Medicin: Es el acto de determinar una medida.
o 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.
o 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.
o Ejemplo: La productividad media de nuestra empresa es de 500
(LDC/pm)
5. Mtricas de proyecto
Las mtricas del proyecto proporcionan una visin del proceso y los avances
detallados acerca del proyecto que se lleva a cabo, y pueden 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.
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.
Para qu sirven las Mtricas?
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
Se centran en las caractersticas del software y no en cmo fue producido.
Tambin son productos los artefactos, documentos, modelos, y componentes
que conforman el software.
Se miden cosas como el tamao, la calidad, la totalidad, la volatilidad, y el
esfuerzo.
6.2 Funcionamiento
Mtricas para el modelo de anlisis: Estas mtricas atienden varios aspectos
del modelo de anlisis e incluyen:

Funcionalidad

entregada:

Proporciona

una

medida

indirecta

de

la

funcionalidad que se empaqueta con el software.

Tamao del sistema: Mide el tamao del sistema, definido desde el punto de
vista de la informacin disponible como parte del modelo de anlisis.
Calidad de la especificacin: Proporciona una indicacin de la especificidad o
el grado en que se ha completado la especificacin de los requisitos.
Mtricas para el modelo de diseo: Estas mtricas cuantifican los atributos
del diseo de manera tal que le permiten al ingeniero de software evaluar la
calidad del diseo.
Mtricas al nivel de componente: Miden la complejidad de los componentes
del software y otras caractersticas que impactan la calidad.
Mtricas arquitectnicas: proporcionan un indicio de la calidad del diseo
arquitectnico.
Mtricas de diseo de la interfaz: se concentran principalmente en la
facilidad de uso.
Mtricas

especializadas

en

diseo

orientado

objetos:

miden

caractersticas, referentes a comunicacin y colaboracin.

Mtricas para el cdigo fuente: Estas mtricas miden el cdigo fuente y se
usan para evaluar su complejidad, adems de la facilidad con que se mantiene
y prueban.
Mtricas de Halstead: controversiales pero fascinantes, estas mtricas
proporcionan medidas nicas de un programa de cmputo.
Mtricas de complejidad: miden la complejidad lgica del cdigo fuente,
tambin se consideran mtricas de diseo al nivel de componentes.
Mtricas de longitud: proporcionan un indicio del tamao del software.

Mtricas para pruebas: Estas mtricas ayudan a disear casos de prueba

efectivos y a evaluar la eficacia de las pruebas.
Mtricas de cobertura de instrucciones y ramas: lleva al diseo de casos de
prueba que proporcionan cobertura del programa.
Mtricas relacionadas con los defectos: se concentran en encontrar
defectos y no en las propias pruebas.
Efectividad de la prueba: proporcionan un indicio en tiempo real de la
efectividad de las pruebas aplicadas.
Mtricas en el proceso: mtricas relacionadas con el proceso que se
determinan a medida que se aplican las pruebas.

6.3 Ejemplo aplicado

Una empresa lleva a cabo un proyecto de desarrollo de software x, el gerente
de proyectos desea saber si la productividad es adecuada y evaluar el nivel de
productividad de los programadores del proyecto en comparacin con lo
habitual en otros proyectos de la organizacin.

7. Mtricas de Calidad
El software es un producto como cualquier otro, y por tanto podemos hablar de
software de buena calidad y software de mala calidad. La calidad del software
comprende distintos aspectos como esttica (que sea agradable a la vista),
funcionalidad (que sea fcil de usar), eficiencia (que ejecute con rapidez y
precisin los procesos), etc.
Lo que distingue al software de otros productos industriales es que no es de
una estructura material, es decir que no se puede tocar. Por tanto, no resulta
viable hacer una valoracin del mismo en base a una impresin rpida o
anlisis del aspecto ni en base al coste de materiales componentes, las
Mtricas de Calidad proporcionan una indicacin de cmo se ajusta el software,
a los requerimientos implcitos y explcitos del cliente.
El mayor objetivo de la ingeniera del software es producir un producto de alta
calidad. Para lograr este objetivo, los ingenieros del software deben utilizar
mediciones que evalen la calidad del anlisis y los modelos de desafo, el
cdigo fuente, y los casos de prueba que se han creado al aplicar la ingeniera
del software. Para lograr esta evaluacin de la calidad en tiempo real, el
ingeniero debe utilizar medidas tcnicas que evalan la calidad con objetividad,
no con subjetividad.
Existen diferentes tipos de modelos de Mtricas de calidad, la aplicacin
depende del proyecto que se est ejecutando y se debe realizar un anlisis
para saber cul es el modelo de mtrica de calidad ms acorde a lo que se
requiere en cuanto a la calidad del software que se est desarrollando.
Entre los modelos ms destacados tenemos:
-

Modelo MCCALL
Modelo FURPS
Modelo DROMEY
Norma ISO/IEC 9126
Modelo MOSCA

7.2 Funcionamiento

Modelo MCCALL
Describe la calidad como un concepto elaborado mediante relaciones
jerrquicas entre factores de calidad, en base a criterios, Las mtricas
desarrolladas estn relacionadas con los factores de calidad y la relacin que
se establece se mide en funcin del grado de cumplimiento de los criterios.
El modelo de McCall se centra en tres aspectos importantes de un producto de
software:

Sus caractersticas operativas/Operacin del Producto

Su capacidad para soportar los cambios/Revisin del Producto
Su adaptabilidad a nuevos entornos/Transicin del producto

Lista de factores:
Operacin del Producto
-

Correccin: mide el grado en que un programa satisface sus

especificaciones y consigue los objetivos del usuario.

Fiabilidad: mide el grado en que se puede esperar que un programa

lleve a cabo sus funciones esperada con la precisin requerida.

Eficiencia: mide la cantidad de recursos de computadora y de cdigo
requerido por un programa para que lleve a cabo las funciones

especificadas.
Integridad: es el grado en que puede controlarse el acceso al software o

a los datos por personal no autorizado.

Facilidad de Uso: es el esfuerzo requerido para aprender un programa e
interpretar la informacin de entrada y de salida.

Revisin del Producto

-

Facilidad de Mantenimiento: es el esfuerzo requerido para localizar y

arreglar programas.
Facilidad de Prueba: es el esfuerzo requerido para probar un programa.
Flexibilidad: es el esfuerzo requerido para modificar un sistema
operativo.

Transicin del Producto

Portabilidad: es el esfuerzo requerido para transferir un software de un

hardware o un entorno de sistemas a otro.

Reusabilidad: es el grado en que un programa (o partes de un

programa) se puede reutilizar en otro.

Facilidad de Interoperacin: es el esfuerzo requerido para asociar un
programa a otro.

Modelo FURPS
El modelo FURPS+ establece cinco caractersticas como factores de calidad
que son los que le dan nombre:

Functionality (Funcionalidad).
Usability (Usabilidad).
Reliability (Confiabilidad).
Perfomance (Prestacin).
Supportability (Soporte).

El modelo FURPS incluye, adems de los factores de calidad y los atributos,

restricciones de diseo y requerimientos de implementacin, fsicos y de
interfaz.
Una limitacin de este modelo de calidad es que no tiene en cuenta la
portabilidad de los productos software que se estn considerando, factor digno
de consideracin en funcin de las exigencias actuales que recaen sobre el
proceso de desarrollo del software.

Se utiliza para establecer mtricas de la calidad para todas las actividades del
proceso de desarrollo de un software, inclusive de un sistema de informacin.

Modelo DROMEY
Resalta el hecho de que la calidad del producto es altamente determinada por
los componentes del mismo (incluyendo documentos de requerimientos, guas
de usuarios, diseos, y cdigo),
Sugiere el uso de cuatro categoras que implican propiedades de calidad, que
son: correctitud, internas, contextuales y descriptivas.

Norma ISO/IEC 9126

La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software
desde

diferentes

criterios

asociados

con

adquisicin,

requerimientos,

desarrollo, uso, evaluacin, soporte, mantenimiento, aseguramiento de la

calidad y auditoria de software. Los modelos de calidad para el software se
describen as:
-

Calidad interna y externa: Especifica 6 caractersticas para calidad

interna y externa, las cuales, estn subdivididas. Estas divisiones se
manifiestan externamente cuando el software es usado como parte de
un sistema Informtico, y son el resultado de atributos internos de

software.
Calidad en uso: Calidad en uso es el efecto combinado para el usuario
final de las 6 caractersticas de la calidad interna y externa del software.
Especifica 4 caractersticas para la calidad en uso.

Al unir la calidad interna y externa con la calidad en uso se define un modelo de

evaluacin ms completo, se puede pensar que la usabilidad del modelo de
calidad externa e interna pueda ser igual al modelo de calidad en uso, pero no,
la usabilidad es la forma como los profesionales interpretan o asimilan la
funcionabilidad del software y la calidad en uso se puede asumir como la forma
que lo asimila o maneja el usuario final.
Si se unen los dos modelos, se puede definir que los seis indicadores del
primer modelo tienen sus atributos y el modelo de calidad en uso sus 4
indicadores pasaran hacer sus atributos, mirndolo grficamente quedara as:

Modelo MOSCA
Es un modelo que integra los modelos de calidad nombrados anteriormente,
considerndolos como sub-modelos de ste. Fundamentalmente, la calidad del
proceso garantiza la calidad del producto y consecuentemente no se pueden
desligar estas dos calidades; tener modelos separados capaces de medir
individualmente la calidad de un producto o de un proceso de software no
garantiza la relacin sistmica que debe estar presente entre ellos.
Esto se debe a que la naturaleza de los sistemas no puede ser divida en
partes, sino que debe existir una interdependencia y colaboracin entre las
partes (proceso y producto) para que el mismo sea visto como un todo, La
estructura de MOSCA Consta de 4 niveles: dimensiones, categoras,
caractersticas y las mtricas. En base de tres ramas: el producto, el proceso y
la humana.

Nivel 0: Dimensiones. Eficiencia del proceso, Efectividad del proceso,

Eficiencia del producto y Efectividad del producto son las cuatro
dimensiones propuestas en el prototipo de modelo. Slo un balance y
una buena interrelacin entre ellas garantizan la calidad Sistmica global

de una organizacin.
Nivel 1: Categoras.

Se

contemplan

11

categoras:

Producto:

Funcionalidad (FUN), Fiabilidad (FIA), Usabilidad (USA), Eficiencia (EFI),

Mantenibilidad (MAB) y Portabilidad (POR) Proceso: Cliente-Proveedor
(CUS),

Ingeniera

(ENG),

Soporte

(SUP),

Gestin

(MAN)

Organizacional (ORG). Esta divisin no implica un desligamiento entre

ellas, simplemente se realiza para identificar a que sector o submodelo
-

pertenecen.
Nivel 2: Caractersticas. Cada categora tiene asociado un conjunto de
caractersticas (56 asociadas al producto y 27 al proceso de desarrollo),
las cuales definen las reas claves a satisfacer para lograr, asegurar y
controlar la calidad tanto en el producto como en el proceso. Entre las
caractersticas asociadas a cada categora del producto, se proponen en
el modelo MOSCA, una serie de caractersticas del proceso, esto se

debe, a que algunas caractersticas de la calidad del proceso, impactan

directamente en las categoras del producto al igual que ciertas
caractersticas de la calidad del producto definen categoras del proceso.
Esto ayuda a precisar que si una vez medidas las caractersticas
asociadas a una categora en particular del producto, arroja resultados
no deseados, se pueden analizar las caractersticas de la calidad del
proceso asociadas a esa categora del producto para encontrar las
-

posibles causas.
Nivel 3: Mtricas. Para cada caracterstica se propone una serie de
mtricas utilizadas para medir la calidad sistmica. Dada la cantidad de
mtricas asociadas a cada una de las caractersticas que conforman
MOSCA (587 en total).

7.3 Ejemplo de Aplicacin

Las Mtricas a utilizar podran ser:

La forma de obtenerlas est dada por:

8. Software de mtricas 01
8.1. SONAR
8.2. Requerimientos tecnolgicos
El nico requisito previo para ejecutar Sonar es tener Java (Oracle JRE 7 en
adelante o OpenJDK 7 en adelante) instalado en su mquina. Requisitos de
hardware
1. El servidor Sonar requiere al menos 1 GB de RAM para ejecutar de manera
eficiente.
2. La cantidad de espacio en disco que usted necesita depender de la
cantidad de cdigo que analizar con Sonar.
3. Sonar debe estar instalado en los discos duros que tienen un excelente
rendimiento de lectura y escritura. Lo ms importante, la carpeta "data" alberga
los ndices Elastic search en el que se har una enorme cantidad de E / S
cuando el servidor est en funcionamiento. Por lo tanto, gran parte de la
lectura, escritura y rendimiento del disco duro tendr un gran impacto en el
rendimiento general del servidor Sonar.

8.3 Funcionalidades
Una herramienta de software libre y gratuito que permite gestionar la calidad
del cdigo fuente. Al instalarla podremos recopilar, analizar, y visualizar
mtricas del cdigo fuente. Sonar es bsicamente la fusin de las siguientes
herramientas Checkstyle y PMD. Tambin realiza un histrico de todas las
mtricas del proyecto.
Adems tiene la posibilidad de navegar y descender en los proyectos,
obteniendo las mismas mtricas agrupadas por paquetes y clases, siendo
posible visualizar el cdigo fuente con la deteccin de los avisos y los
comentarios asociados.
8.4 Ejemplo Prctico
Abrimos un terminal, navegamos hasta SONAR_HOME/bin/sistema_operativo
y ejecutamos el fichero llamado sonar dependiendo de nuestro sistema
operativo, en Ubuntu sera de esta forma:
1 ./sonar.sh start
Para pararlo utilizaramos el mismo archivo pero con el comando stop. Esto
hace que se arranque el producto con sus parmetros por defecto, esto es,
utilizando una base de datos Derby y el puerto 9000. Podemos comprobar el
arranque visualizando el fichero SONAR_HOME/logs/sonar.log. Una vez haya
arrancado podemos acceder a la URL http://localhost:9000 para ver la pantalla
de bienvenida del producto, que tiene este aspecto:

Analizar proyecto Java

Para analizar un proyecto con Sonar este tiene que estar creado con Maven2.
Entonces lo nico que tenemos que hacer es ejecutar:
1 mvn sonar:sonar
Haciendo esto dentro del proyecto que queramos analizar, veremos que nos
crea una nueva entrada en la pantalla principal de la aplicacin a la que,
recordemos, podemos acceder desde la URL http://localhost:9000. En caso de
haber cambiado las condiciones por defecto, tenemos que configurar Maven
para que sea capaz de encontrar la instalacin de Sonar. Para ello, editamos el
fichero .m2/settings.xml y creamos un perfil para sonar de esta manera:

Pero veamos un ejemplo prctico. Imaginemos que en nuestro entorno de

desarrollo hemos creado un proyecto con Maven2 llamado prueba-sonar cuya
clase principal presenta el siguiente cdigo.

Si ahora ejecutamos el goal de sonar con este proyecto, veremos que en la

pantalla principal de la aplicacin ya aparece una entrada con nuestro proyecto.

Ahora si pinchamos en la entrada del proyecto accederemos al panel de control

del mismo donde de primeras recibiremos toda esta informacin:

9. Software de mtricas 02 COCOMO (Constructive Cost Model)

Es un mtodo algortmico desarrollado para la estimacin de costes (tiempos y
costes) creado por el profesor Barry W. Bohem, el cual incluye tres submodelos
de diferente complejidad cada uno, se basa en modelos de estimaciones
matemticas, que van orientadas al producto final y no a fases intermedias.
Es un modelo constructivo de costes, es una herramienta que ha tenido una
gran aceptacin en la gestin de proyectos debido a que su utilizacin se basa
en datos de entrada muy claros y donde sus resultados son muy concisos y
altamente cercanos al resultado aproximado final, su proceso se relaciona en la
estimacin de costes en el diseo y construccin de programas y de la
documentacin asociada necesaria para su desarrollo, operacin y
mantenimiento y es prctica y bien aplicada para la Ingeniera de software.
Se basan en la cantidad de lneas de cdigo, en la cual se utilizan medidas de
longitud, dificultad y cantidad de informacin, su principal problema es que la
suposicin de estimacin se basa en otra estimacin o aproximacin, que
puede dar como resultado unos clculos no muy buenos de eso depende el
mejor uso del cocomo.
Sus ecuaciones son varias y se rigen por modelos:
Ecuaciones de esfuerzo
Esfuerzo=

. Donde:

KLDC= tamao en miles de lneas de cdigo

El esfuerzo se mede en personas por mes

A y B son parmetros de ajuste segn el tipo o modo del desarrollo del

proyecto

Tipos de desarrollo del proyecto

Modelo orgnico
Se caracteriza por el desarrollo de un proyecto por un grupo de programadores
experimentados en el desarrollo de software en un entorno familiar
No posee una innovacin tcnica radical y las presiones en el tiempo casi
nunca se presentan
La estimacin referente hacia las lneas de cdigo no superan las 50KLFC
(50000 LDC).
Modelo empotrado
El proyecto tiene ciertas restricciones, que pueden relacionarse con el
procesador y la interface hardware.
Participa una variedad de personas y el nico problema es la parte base en la
experiencia.
Posee una perspectiva de innovacin tcnica bastante compleja por su gran
volatilidad de requisitos
Modelo semi-libre
Es un modelo intermedio entre las dos anteriores.
La estimacin referente hacia las lneas de cdigo no superan las 300KLFC
(50000 LDC).
Puede incluir una mezcla de personas experimentadas y no experimentadas.
Sus frmulas son:
PM =

(Para conocer las personas/mes)

TD=a*PM^b (Para conocer el tiempo de desarrollo en meses).

Modelos segn el ciclo de vida

Modelo Bsico
Este modelo trata de estimar de manera rpida y sin muchos detalles la
mayora de proyectos pequeos y medianos

Modelo intermedio
Identifica los principales componentes del sistema, se utiliza para estimar el
coste de dichos componentes, aplicando la ecuacin bsica para obtener el
esfuerzo o el tiempo nominal de desarrollo.
Su precisin viene dada por la incorporacin de 15 factores que reflejan la
influencia de ciertos elementos en el desarrollo de software y que implican el
costo nominal del software.

Aqu es donde se ven los 15 factores que implican en el desarrollo de software

Tabla de factores de coste

Modelo desarrollado
En este modelo se pueden procesar todas las caractersticas del proyecto para
la estimacin del coste. Los factores correspondientes a los atributos sensibles
poseen una migracin y gestionan una mayor influencia en las fases ms
software unas que otras.
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv
9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv
9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv
9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv
9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv
9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv
9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv
9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET
INCLUDEPICTURE
"http://4.bp.blogspot.com/__9QzGeEnTH0/Siihgmf3G9I/AAAAAAAAAHw/glQv

9KGVh3E/s1600/Figura+3Ingreso+al+programa.bmp" \* MERGEFORMATINET

Requerimientos tecnolgicos
Es un programa que no necesita muchos recursos tecnolgicas solo se tiene
que almacenar soluciones matemticas, ya que los clculos no son muy
complejos pero tiene un tiempo de respuesta dependiendo de las variables de
inicio.
Funcionalidades

Permite la construccin de unas bases de parmetros bien definidos

para los procesos de costo tiempo vs persona

COCOMO es transparente, se puede ver cmo trabaja con otros

modelos tal como SLIM (Software Life Cycle Management).

Manejadores de costo ayudan particularmente al estimador a

comprender el impacto de diferentes factores que afectan en el costo del
proyecto.

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.
Ejemplo de aplicacin

Enunciado: Estimar el esfuerzo de desarrollo de un sistema de comunicacin

de 30KLDC, de alta complejidad, personal de muy alta cualificacin u alta
experiencia en el lenguaje de programacin. El coste del salario mensual de
cada persona es de 1350 /mes.
Solucin y Clculo:
Se puede observar dos cosas que es que pertenecen a un modelo orgnico por
que lleva menos de 50KLDC y de tipo intermedio por la intervencin de
factores.
Lo primero que hacemos es usar la formula nominal de tipo orgnico intermedio
PM= 3.2*(KLDC) ^ (1.05)
TD=2.5*(PM) ^ (0.38)
PM Nominal= Esfuerzo Nominal= 3.2 x (30) ^1.05= 113,79 Personas/Mes
Para calcular el ajuste del esfuerzo deberemos fijarnos en la tabla de factores
de coste y lo contrastamos contra el enunciado.

Alta complejidad: 1,15

Personal de muy alta cualificacin: 0,70

Alta experiencia: 0,91

PM= Esfuerzo Ajustado = 113,79 x 1,15 (Complejidad) x 0,70 (Personal) x 0,91

(Experiencia) =85,35 Personas/Mes
Coste = 83,35 x 1350 = 112.522,5
Tiempo = 2,5 x (83,35) ^ (0,38)=13,42 Meses
N Medio de Personas= 83,35 / 13,42 = 6,2 Personas
Esto puede desvariar referente a si el tiempo del proyecto se debe reducir o
aumentar dependiendo de las pautas empresariales.
El ejemplo esta aplicado esta mejor explicado en este enlace evaluando las
mtricas
https://www.youtube.com/watch?v=E4VLesi0Tj4

10. Software de mtricas 03 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
Requerimientos Tecnolgicos
Para el funcionamiento adecuado del programa Costar, se requieren
plataformas con las siguientes caractersticas, Sistemas operativos tales como
Win 95, Win 98, Win NT, Win 2000, Win XP, Win 7, Win 8, Win 8.1 y Win 10.
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:
1. Puede introducir explcitamente un valor SLOC como 3000.
2. Puede utilizar la ficha reutilizacin para calcular el SLOC.
3. Puede utilizar la ficha Punto Funcin para calcular el SLOC.

Ejemplo de aplicacin
Costar es un software perteneciente a la familia de Software de estimacin de
Softstar Systems, entre los que se destacan Cosysmo, Cocomo y Calico.
Se puede descargar de la siguiente URL.

El siguiente es un ejemplo de la aplicacin ya instalada donde se pueden

evidenciar, los diferentes componentes que nos permiten realizar las
estimaciones que queramos realizar a nuestro proyecto, como la aplicacin
est basada en cocomo, se deben tener en cuenta los algoritmos establecidos
para cocomo y as poder realizar las estimaciones basados en los mtodos,
ecuaciones y variables del algoritmo estndar.

Interfaz de Usuario

11. Software de mtricas 04

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.
Requerimientos tecnolgicos:

Netbeans 7.4
Internet
Windows 7

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.
Ejemplo de aplicacin
PMD es una herramienta muy til para verificar la calidad del cdigo fuente
entregado. Existen varias alternativas para su uso:
Desde Maven: se debe utilizar el plugin de PMD para Maven, para lo que se
debe incluir el siguiente fragmento en el fichero pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<linkXref>true</linkXref>
<sourceEncoding>UTF-8</sourceEncoding>
<minimumTokens>100</minimumTokens>
<targetJdk>1.5</targetJdk>
</configuration>

</plugin>
Por defecto se aplican todas las reglas PMD, pero se pueden excluir o cambiar
la severidad de las que se considere. Para ello se deben modificar los ficheros
xml de definicin y excluir o cambiar el nivel de cada prueba. En ese caso al
fichero pom.xml se debe hacer referencia expresa al conjunto de ruleset que
debe aplicar.
12. Cuadro comparativo de mtricas de software

13. Conclusiones
En el momento en el que las mtricas toman parte de nuestra gestin
en los proyectos, al evaluar y hacer una buena medicin podemos
mantener un mejor anlisis de los flujos alternos que poseen los
procesos, en donde los programas imponen una evaluacin para hacer
la mejor medicin en todos los aspectos para la estimacin en el
desarrollo de software.

 Las mtricas de proyecto, que permiten evaluar el estado del proyecto,

adems de identificar los puntos crticos.
Las mtricas pueden ayudarnos a entender ms acerca de nuestros
productos, procesos y servicios de software.
Las mtricas pueden ser empleadas para evaluar el software de
nuestros productos, procesos y servicios con respecto a los estndares
y metas establecidas.
Las mtricas pueden proveer la informacin que nosotros necesitamos
para controlar recursos y procesos utilizados en la produccin de
nuestro software.
Las mtricas pueden ser usadas para predecir los atributos de las
entidades de software en el futuro.
Las mtricas de Proceso se caracterizan por el control y ejecucin del
proyecto, midiendo los tiempos en cada fase.
Las mtricas Del Producto, se centran en las caractersticas del
Software y no como fue producido.
Las mtricas De Calidad, el objetivo general de la Ingeniera De
Software, es desarrollar herramientas que satisfagan la solucin de
problemas de manera ptima, bajo las normas de entes reguladores.

14. Bibliografa
Mtricas de software
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capit
ulo4.pdf
http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ANA
LISIS_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD
%20II/2.3.HTM
http://es.slideshare.net/1richard1/metricas-ingenieria-de-software
http://www.ecured.cu/Metricas_para_la_calidad_del_software
Mtricas de proceso
https://es.scribd.com/doc/17727554/Metricas-de-Procesos-y-Proyecto
http://uptaprocesodepruebasycalidadymetricas.blogspot.com.co/2012/12/
ejemplos-de-metricas.html
Mtricas de proyecto

 http://es.slideshare.net/jose_macias/mtricas-de-procesos-y-proyectos
https://prezi.com/zqmelpthcq5x/metricas-de-proceso-y-de-proyecto/
Mtricas de producto
https://docs.google.com/document/d/1qtxCIYqQDaYaHJ2RjSd_VcCqAIL
-k1UHIYyLVSoQbOM/edit
Definicin de mtricas de calidad:
http://ldc.usb.ve/~abianc/materias/ci4712/metricas.pdf
http://www.ecured.cu/Metricas_para_la_calidad_del_software
Modelo MCCALL
http://vanevargas.jimdo.com/m%C3%B3dulos/modelos/modelo-demccall/
Modelo FURPS
http://clases3gingsof.wikifoundry.com/page/FURPS
Modelo DROMEY
https://prezi.com/u0es3ti5uekp/modelo-de-calidad-dromey/
Modelo MOSCA
http://www.lisi.usb.ve/publicaciones/02%20calidad
%20sistemica/calidad_21.pdf

Software de mtricas 01 COCOMBO

https://es.wikipedia.org/wiki/COCOMO
http://es.slideshare.net/techi322/cocomo
https://acevedodelacru.wordpress.com/ejemplo-3/
http://www.forosdelweb.com/f14/ventajas-cocomo-ii-sobre-cocomo-i323079/
Software de mtricas 03 Costar
http://www2.dc.uba.ar/materias/isoft2/2006_02/clases/Software_Metrics_20061030.
pdf
https://www.youtube.com/watch?v=y4SlF6lowJc
Software de mtricas 04 PMD
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/374

 http://www.javiergarzas.com/2012/03/herramientas-de-calidadsoftware.html
Sonar

http://javierac.biz/sonarqube-instalacion-y-configuracion/

Cuadro comparativo de mtricas

secyt.unpa.edu.ar/journal/index.php/ICTUNPA/article/download/.../79
http://es.slideshare.net/galo_priva/mtricas-del-proceso-y-proyectoprocesos-de-ingeniera-de-software-372897
http://es.slideshare.net/jose_macias/mtricas-de-procesos-y-proyectos
https://prezi.com/zqmelpthcq5x/metricas-de-proceso-y-de-proyecto/
http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLin
ea/leccin_21__mtricas_en_el_proceso_y_dominios_del_proyecto.html