10 Curso de MediciÃ N y AnÃ¡lisis

CURSO DE MEDICIN Y
ANLISIS
Laboratorio Nacional de Calidad del

Software
NOTA DE EDICIN
Este curso ha sido desarrollado por el Laboratorio Nacional de Calidad del Software de
INTECO. Esta primera versin ha sido editada en Junio del 2009.
Copyright 2009 Instituto Nacional de Tecnologas de la comunicacin (INTECO)
El presente documento est bajo la licencia Creative Commons Reconocimiento-No comercial-Compartir Igual versin
2.5 Espaa.
Usted es libre de:
copiar, distribuir y comunicar pblicamente la obra
hacer obras derivadas
Bajo las condiciones siguientes:
Reconocimiento. Debe reconocer los crditos de la obra de la manera especificada por el autor o el licenciador
(pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
No comercial. No puede utilizar esta obra para fines comerciales.
Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, slo puede
distribuir la obra generada bajo una licencia idntica a sta.
Al reutilizar o distribuir la obra, tiene que dejar bien claro los trminos de la licencia de esta obra.
Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor
Nada en esta licencia menoscaba o restringe los derechos morales del autor.
Esto es un resumen legible por humanos del texto legal (la licencia completa) disponible
http://creativecommons.org/licenses/by-nc-sa/2.5/es/
en
El presente documento cumple con las condiciones de accesibilidad del formato PDF (Portable Document Format).
Se trata de un documento estructurado y etiquetado, provisto de alternativas a todo elemento no textual, marcado de
idioma y orden de lectura adecuado.
Para ampliar informacin sobre la construccin de documentos PDF accesibles puede consultar la gua disponible en la
seccin Accesibilidad > Formacin > Manuales y Guas de la pgina http://www.inteco.es.
Curso de Medicin y Anlisis
AVISO LEGAL
CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la

Universidad Carnegie Mellon
Las distintas normas ISO mencionadas han sido desarrolladas por la International
Organization for Standardization
Todas las dems marcas registradas que se mencionan, usan o citan en el presente curso
son propiedad de los respectivos titulares.
INTECO cita estas marcas porque se consideran referentes en los temas que se tratan,
buscando nicamente fines puramente divulgativos. En ningn momento INTECO busca con
su mencin el uso interesado de estas marcas ni manifestar cualquier participacin y/o
autora de las mismas.
Nada de lo contenido en este documento debe ser entendido como concesin, por
implicacin o de otra forma, y cualquier licencia o derecho para las Marcas Registradas
deben tener una autorizacin escrita de los terceros propietarios de la marca.
Por otro lado, INTECO renuncia expresamente a asumir cualquier responsabilidad
relacionada con la publicacin de las Marcas Registradas en este documento en cuanto al
uso de ninguna en particular y se eximen de la responsabilidad de la utilizacin de dichas
Marcas por terceros.
El carcter de todos los cursos editados por INTECO es nicamente formativo, buscando en
todo momento facilitar a los lectores la comprensin, adaptacin y divulgacin de las
disciplinas, metodologas, estndares y normas presentes en el mbito de la calidad del
software.
NDICE
1.
ESCENARIO DE APERTURA
2.
INTRODUCCIN
2.1.1.
10
2.3. Conceptos
12
2.3.1.
Mtricas y medidas
12
2.3.2.
Mtricas directas y mtricas indirectas
13
2.3.3.
Otros conceptos
13
2.4. Necesidad e importancia de la medicin
15
Beneficios de la medicin
17
ACTIVIDADES DEL PROCESO DE MEDICIN Y ANLISIS
19
3.1. Identificar necesidades de informacin
19
3.2. Definir objetivos de medicin
21
3.3. Definir mtricas
23
3.3.1.
Plan de medicin
3.4. Recoger, validar y almacenar mtricas
25
27
3.4.1.
Recoger
28
3.4.2.
Validar
29
3.4.3.
Almacenar
30
3.5. Analizar mtricas
4.
2.2. La medicin como parte de las estimaciones
2.4.1.
3.
Contexto de la medicin
31
3.5.1.
Mtodos de anlisis
32
3.5.2.
Aplicacin y ejemplos de los mtodos de anlisis
34
MTRICAS
38
4.1. Mtricas en un proyecto software
38
4.1.1.
Mtricas del progreso de los proyectos
40
4.1.2.
Mtricas de recursos
41
4.2. Mtricas de la calidad de un proceso

4.2.1.
La productividad
4.3. Mtricas de calidad de producto

4.3.1.
Mtricas de calidad de producto final
42
43
45
47
4.3.2.
5.
Mtricas de mantenimiento de software
48
BUENAS PRCTICAS
49
5.1. Lecciones aprendidas
52
ENFOQUE MODELOS
54
6.1. CMMI
54
6.2. ISO/IEC 15504
56
7.
ESCENARIO DE CLAUSURA
59
8.
ENLACES
61
9.
GLOSARIO
62
6.
Escenario de Apertura
Con motivo de la incorporacin de un nuevo director a la empresa COMPASS S.A. va a ver
varios cambios, sobre todo en el rea de medicin y anlisis ya que es un rea bastante
ignorada en el pasado.
Un jefe de proyecto va a iniciar un nuevo proyecto y antes de comenzar tiene una reunin
inicial con el director quien expresa su deseo de priorizar la medicin en los proyectos como
necesidad fundamental.
Figura 1. Escenario de apertura I
Figura 2. Escenario de apertura II
Figura 3. Escenario de apertura III
Introduccin
La medicin es una parte integral de la gestin de proyectos software. Proporciona una
manera cuantificable de conocer dnde estamos y validar la efectividad de las mejoras que
hagamos.
Cuando puedes medir aquello de lo que ests hablando, y expresarlo en

nmeros, sabes algo sobre ello; pero cuando no lo puedes medir, y no lo puedes
expresar en nmeros, tu conocimiento acerca de ello es insatisfactorio- Lord
Kelvin
Figura 4. La necesidad de la medicin en los proyectos
La ingeniera de software est madurando como disciplina de software y es importante darse

cuenta de que la medicin tiene que ser una parte integral del proceso y proyecto de
software, y as ayudar a que la ingeniera de software evolucione en una disciplina que de
confianza a los clientes.
La medicin es un punto crtico en la disciplina de la ingeniera del software.
En general, la medicin persigue los siguientes objetivos fundamentales:
Analizar: entender qu ocurre durante el desarrollo y el mantenimiento (los atributos

de un ente)
Controlar: controlar qu es lo que ocurre en nuestros proyectos (la calidad del

producto)
Predecir: realizar estimaciones (el tiempo y coste de un proyecto)
Mejorar: mejora los procesos y productos (la calidad de un producto, proceso )
Las mtricas son un buen medio para entender, monitorizar, controlar, predecir
y probar el desarrollo software y los proyectos de mantenimiento (Briand et al.,
1996).
Contexto de la medicin
La ingeniera de software todava es una disciplina en evolucin. Los profesionales en este
mbito todava no estn acostumbrados a medir y por esta razn tienden a rechazarlo. En el
campo de la ingeniera de software a menudo se escuchan palabras que muestran cmo las
personas confan en sus opiniones o corazonadas a la hora de establecer compromisos.
Figura 5. Estimaciones sin medicin
Sin embargo no podemos permitirnos ser poco estrictos y relajarnos en el campo de la

ingeniera de software. Necesitamos ser tan cuidadosos como podamos con las mtricas
tanto en esta como en cualquier disciplina.
A menudo las compaas se quejan diciendo que la medicin es algo muy duro, difcil de
llevar a cabo y que consume demasiado tiempo. Pero este no es el enfoque correcto. De
hecho, hay que plantearse que la medicin ayuda a conseguir una exitosa gestin de
proyectos. Incluso a una escala mayor, para implementar un proceso de software exitoso
necesitaremos mtricas.
La medicin como parte de las estimaciones

El rendimiento esperado de un proyecto depende de la capacidad del proceso software
sobre el que se basa la ejecucin del proyecto, y las mtricas pueden ser usadas para
entender las caractersticas de dicho proceso. Por ejemplo, la medicin puede ser til para
entender la productividad y la tasa de defectos que pueden esperarse si se sigue el proceso.
Los productos software son resultados derivados de procesos software. Los datos
relacionados con procesos pueden ser recogidos durante la ejecucin de proyectos para dar
10
una idea de la capacidad del proceso software. Este dato es til para la estimacin. El
anlisis de la causa raz de los datos ayuda a responder a preguntas como las siguientes:
Qu tipo de errores ocurren ms a menudo y por qu?
Por qu la calidad del producto es menor?
Por qu los proyectos siempre van con retraso?
Estos anlisis ayudan a decidir las prioridades para la mejora del proceso software a nivel
organizacional y validar la efectividad de los esfuerzos de mejora.
Los datos obtenidos al medir proyectos pasados dan una idea para predecir lo que puede
esperarse de proyectos futuros, y as ayudar a formular una estimacin ms exacta. Sin
embargo, se deberan tener en cuenta las diferencias entre las caractersticas de los
proyectos del pasado y las del proyecto que se est estimando.
Utilizando datos histricos disponibles pueden establecerse metas conseguibles en cuanto
a presupuesto, cronograma y calidad.
En ocasiones, los datos sobre un proceso software no estn disponibles. Esto puede ocurrir
porque:
la organizacin es nueva
la organizacin no ha trabajado con proyectos de caractersticas similares al

proyecto sobre el que queremos realizar las estimaciones
En ausencia de datos de proyectos anteriores, deberan utilizarse otros datos para realizar
las estimaciones como datos de la industria para proyectos similares. Tambin podemos
utilizar modelos de estimacin disponibles basados en datos relevantes de la industria.
La estimacin, primer paso de la planificacin de proyectos, est basada en:
anlisis de datos histricos
modelos disponibles que se han basado en datos de la industria
otros anlisis
11
Figura 6. Modelos de estimacin
Conceptos
Mtricas y medidas
Una medida proporciona una indicacin cuantitativa sobre un atributo de un producto o
proceso. La medicin puede referirse a la extensin, cuanta, dimensin, capacidad y
tamao.
Una mtrica es calculada utilizando una medicin o una combinacin de mediciones
proporcionando informacin acerca de un producto o proceso. IEEE define una mtrica
como una medida cuantitativa del grado con el que un sistema, proceso o un componente
posee un atributo dado. Una mtrica o un conjunto de mtricas permiten a los jefes de
proyecto ajustar los detalles necesarios de un proceso o un producto y formar la base para
una correcta toma de decisiones.
Necesitamos mtricas para establecer metas y conocer donde estamos respecto a ellas
12
Mtricas directas y mtricas indirectas

Las mtricas pueden clasificarse en dos categoras: Mtricas directas e indirectas.
Una mtrica directa es una mtrica de un atributo que no depende de ninguna mtrica de
otro atributo, es decir una mtrica de la cual se pueden realizar mediciones sin depender de
ninguna otra mtrica y cuya forma de medir es un mtodo de medicin.
Por ejemplo, para conocer el tamao de un programa se pueden contar el

nmero de lneas de cdigo (LOC) que es un atributo del programa que
puede medirse directamente y por lo tanto es una mtrica directa.
Por otra parte, la complejidad de un programa no es algo que pueda medirse directamente.
Para ello, necesitaremos identificar algunos atributos que indiquen dicha complejidad. La
complejidad puede depender del tamao del programa, del nmero de estructuras o ramas
condicionales del programa, y del nmero de estructuras con bucles. Nosotros podemos
medir estos atributos y combinarlos para obtener la complejidad del proyecto. Por lo tanto, la
complejidad es una mtrica indirecta calculada combinando algunas mtricas directas de
una determinada manera.
La satisfaccin del cliente, por ejemplo, no es un atributo que pueda medirse

directamente. Para medirlo, deberan identificarse las medidas directas que
podran indicar la satisfaccin del cliente, como por ejemplo:
- Tiempo que se tarde en proporcionar servicio a los clientes
- Nmero de quejas de los clientes
- Nmero de clientes que se van de la organizacin a otras
Otros conceptos
A continuacin se definen algunos conceptos clave en el proceso de medicin y anlisis:
Necesidad de informacin: Las necesidades de informacin de una organizacin

pueden ser, por ejemplo, la informacin necesaria para gestionar un proyecto, es
decir, sus objetivos, hitos, riesgos y problemas.
Para dar soporte a las necesidades de informacin de una organizacin es
importante desarrollar y establecer una capacidad de medicin que ayude a
13
proporcionar resultados objetivos que sean tiles para la toma de decisiones y

acciones correctivas necesarias.
Entidad: Objeto que va a ser caracterizado mediante una medicin de sus atributos
[ISO- 15939]. En software hay tres clases de entidades cuyos atributos podemos
querer medir:
Procesos: Son actividades software que normalmente conllevan el factor

tiempo.
Productos: Son entregables, artefactos o documentos generados en el ciclo

de vida del software.
Recursos: Son todos aquellos elementos que hacen de entrada a la

produccin software.
Atributo: Propiedad mensurable, fsica o abstracta, que comparten todas las

entidades de una categora de entidad.
Concepto medible: El concepto medible es una percepcin sobre las entidades que
deberan ser medidas con el objetivo de satisfacer una determinada necesidad de
informacin. Por ejemplo, una persona encargada de tomar una decisin relacionada
con la asignacin del presupuesto y recursos a una tarea puede considerar que la
productividad est relacionada con el tipo de tarea que se vaya a ejecutar. Por lo
tanto, la productividad es el concepto medible que dirige la necesidad de informacin
definida.
La siguiente tabla recoge la relacin entre los conceptos anteriormente definidos:

Tabla 1. Relacin conceptos medicin y anlisis
Concepto
Necesidad
informacin
de
Relaciones
Ejemplos
Se asocia a un concepto medible.
Evaluar si un producto SW
Se satisface con uno o ms indicadores.
satisface las expectativas del

cliente.
Entidad
Una entidad puede pertenecer a una o ms
Un programa holamundo
entidades.
Una medicin se realiza sobre los atributos de una
14
entidad.
Categora
entidad
de
Una categora puede incluir a una o varias categoras
Procesos, servicios, proyectos,
de entidades.
recursos, programas en C,
componentes software
Tiene uno o varios atributos

Atributo
Solo puede pertenecer a una categora de entidad.
Tamao de cdigo fuente
Una medicin se realiza sobre los atributos de una
podra
ser
categora
entidad.
atributo
de
de
la
entidad
programas en C.
Est relacionado con uno o ms conceptos medibles.
Concepto
Se
medible
informacin.
asocia
una
varias
necesidades
Puede incluir otros conceptos medibles.
de
Adecuacin
relacin
de
tecnolgica,
productividad
equipo de desarrollo respecto

al objetivo.
Relaciona uno o ms atributos.
Necesidad e importancia de la medicin

El xito de cada organizacin depende de la capacidad de sus empleados de realizar
pronsticos y establecer compromisos claros en cuanto a los productos que desarrollan.
Antes de comenzar viendo la importancia de la medicin vamos a ver qu se entiende por
proyecto exitoso:
Un proyecto software es considerado exitoso si:
15
Completado dentro del

Cronograma
Ejecutado dentro del

Presupuesto
Coste
Cronograma
Calidad
Producto de buena
Calidad
Figura 7. Factores clave en el xito de un proyecto software
Los jefes de proyectos de software se encargan de asegurar:
el xito del proyecto, y para ello ser necesario establecer unas metas alcanzables
en cuanto a costes, agenda y calidad del proyecto.
que el proyecto es controlado y monitorizado para conseguir esos objetivos.
La medicin ayuda a los jefes de proyecto a llevar a cabo estas actividades. De esta forma
pueden identificar las desviaciones y esto es de gran ayuda a la hora de tomar acciones
correctivas a tiempo, como por ejemplo:
Revisar las estimaciones y la agenda del proyecto
Introducir cambios en ciertas actividades tcnicas
Decidir donde focalizar los recursos
Para entender cmo la medicin puede contribuir al xito del proyecto podemos pensar en
cmo el jefe de proyecto y el resto de personas involucradas en el negocio podran
establecer metas y controlar el rendimiento del proyecto.
16
Figura 8. La medicin para monitorizar y controlar los proyectos
Beneficios de la medicin
La medicin es esencial para el xito de la planificacin y ejecucin de los proyectos. La
medicin ayuda:
establecer metas hacia las que trabajar
determinar si el progreso del proyecto es satisfactorio, o si por el contrario, ser

necesario aplicar acciones correctivas para ello.
establecer un mejor control de los costes
reducir los riesgos
mejorar la calidad
asegurar la consecucin de los objetivos de negocio.
detectar tendencias y anticipar problemas
La medicin tambin ayuda a mejorar los procesos. Utilizando mejores procesos, las
organizaciones son capaces de producir productos software de alta calidad.
17
Otros beneficios tpicos resultantes de un buen proceso de medicin y anlisis se recogen

en la siguiente tabla:
Tabla 2. Beneficios proceso medicin y anlisis
A nivel de proyecto
A nivel de organizacin
Reducir las actividades que no aportan valor al

producto que se est desarrollando.
Reducir gastos de desarrollo y mantenimiento de los
productos.
Mejorar la gestin de los recursos.
Mejorar la comunicacin entre los grupos de trabajo y
los departamentos.
Aumentar la eficiencia de los servicios prestados.
Saber a qu nos comprometemos al planificar los
Identificar las oportunidades de mejora. Mejorar el flujo

de trabajo de los procesos.
Fomentar la visin de la empresa.
Aumentar el Retorno de Inversin.
Mejorar la satisfaccin del cliente.
proyectos.
Mejorar la posicin de la empresa en el mercado.
Conocer cul es la probabilidad de alcanzar ese
compromiso.
Saber si hemos mejorado.
Saber si estamos en el camino correcto para

conseguir los compromisos.
Saber si estamos consiguiendo los compromisos de
manera efectiva en costes.
En resumen, los mtodos de medicin y anlisis permiten identificar puntos importantes y

tendencias y, al mismo tiempo, permiten distinguir entre situaciones reales de riesgo de las
que no lo son, lo cual es vital para una adecuada toma de decisiones as como para seguir
un rumbo adecuado en la direccin de la empresa
18
Actividades del proceso de medicin y anlisis

Un proceso de medicin estructurado y repetible define las actividades de medicin del
proyecto. Este proceso debe ser flexible y adaptable para dar soporte a los procesos de
gestin y tcnicos del software existente y a las caractersticas del dominio especfico de la
aplicacin. El proceso de medicin ha de ser iterativo hasta el fin del proyecto, de tal forma
que los esfuerzos de las mtricas se centren en los problemas ms crticos.
Identificar necesidades de informacin

El primer paso del proceso es el de identificar las necesidades de informacin de la
organizacin. Para dar soporte a las necesidades de informacin de una organizacin es
importante desarrollar y establecer una capacidad de medicin que ayude a proporcionar
resultados objetivos que sean tiles para la toma de decisiones y acciones correctivas
necesarias.
Segn PSM (Practical Software Measurement), las necesidades de informacin se pueden
clasificar en siete categoras:
Calendario y progreso: esta categora trata los objetivos de los hitos del proyecto y
completitud de unidades de trabajo individuales. Un proyecto que se sale de la
agenda, normalmente puede cumplir sus objetivos de entrega slo eliminando
funcionalidades o sacrificando la calidad del producto.
Recursos y costes: esta categora hace referencia al equilibrio entre el trabajo a

realizar y los recursos de personal asignado al proyecto. Un proyecto que exceda el
esfuerzo presupuestado normalmente puede recuperarse slo reduciendo la
funcionalidad del software o sacrificando la calidad del producto.
Tamao de producto y estabilidad: esta categora trata la estabilidad de la

funcionalidad o capacidad requerida del software. Tambin relaciona el volumen de
software entregado para proporcionar la capacidad requerida. La estabilidad incluye
cambios en el alcance de la funcionalidad o cantidad. Un aumento en el tamao del
software normalmente requiere aumentar los recursos aplicados o la agenda del
proyecto.
19
Calidad de producto: esta categora trata la habilidad del producto software

entregado para dar soporte a las necesidades del usuario sin fallar. Si se entrega un
producto de baja calidad, la carga de hacerlo funcionar normalmente recae sobre la
organizacin de mantenimiento asignada.
Ejecucin de proceso: esta categora se refiere a la capacidad del proveedor

relativo a las necesidades del proyecto. Un proveedor con un proceso de desarrollo
de software pobre o de baja productividad puede tener dificultad al cumplir los
objetivos de coste y la programacin del proyecto planificada.
Efectividad de la tecnologa: esta categora trata la viabilidad del enfoque tcnico

propuesto. Trata enfoques de ingeniera como reutilizacin de software, utilizacin de
componentes software comerciales, fiabilidad sobre procesos de desarrollo de
software avanzados, e implementacin de arquitecturas de software comn. Si no se
consiguen los elementos clave del enfoque tcnico propuesto puede resultar en
aumentos de costes y retrasos en la agenda.
Satisfaccin del cliente: esta categora se ocupa del grado en que los productos o
servicios entregados por el proyecto cumplen las expectativas del cliente. Los
indicadores de satisfaccin pueden obtenerse de la retroalimentacin del cliente.
Las necesidades de informacin resultan de los esfuerzos de ingenieros y responsables de

la organizacin por mejorar las salidas de los procesos y actividades de software. Las
salidas deseables de estos procesos normalmente son definidas en trminos de objetivos
establecidos por la direccin o de problemas (riesgos, falta de informacin) que dificultan la
consecucin de estos objetivos.
La mayora de los proyectos estn orientados a conseguir ciertos objetivos ya fijados en

trminos de presupuesto, agenda, calidad y funcionalidad, y en consecuencia, las medidas a
nivel de proyecto tienden a centrarse en proporcionar informacin relacionada con estas
reas.
20
El grfico siguiente muestra cmo una necesidad de informacin puede evolucionar en un

plan para generar los productos medibles del proyecto.
Necesidad de
informacin
Concepto
medible
Construccin
mtrica
Procedimiento
medicin
Plan medicin
Figura 9. Evolucin de una necesidad de informacin a un plan de medicin
Definir objetivos de medicin

Una vez que se han definido las necesidades de informacin de la organizacin, se puede
identificar un conjunto de medidas comn que cubra estas necesidades. Una necesidad de
informacin se asocia a un concepto medible, que como se vio en el apartado de
conceptos, es una percepcin sobre las entidades que deberan ser medidas con el objetivo
de satisfacer una determinada necesidad de informacin.
Por ejemplo, una persona encargada de tomar una decisin relacionada con
la asignacin del presupuesto y recursos a una tarea puede considerar que la
productividad est relacionada con el tipo de tarea que se vaya a ejecutar.
Por lo tanto, la productividad es el concepto medible que dirige la necesidad
de informacin definida. (Determinar la productividad requiere que las
entidades, como son el producto o proceso software, sean medidas).
21
Finalmente, el concepto medible ser formalizado como una construccin de medida que
especifica exactamente qu ser medido y cmo los datos sern combinados para producir
resultados que satisfagan la necesidad de informacin. Dos medidas aplicables a este
ejemplo podran ser el tamao del software y el esfuerzo.
El siguiente grfico muestra la estructura bsica de una construccin de medida.
Producto
Indicador
Mtrica
derivada
Mtrica base
Atributo
Figura 10. Niveles de una construccin de medida
Todo lo que puede realmente ser medido incluye atributos especficos de procesos y
productos software, como tamao, esfuerzo y nmero de defectos. La construccin de
medicin describe cmo los atributos de software relevantes son cuantificados y
convertidos en indicadores que proporcionan una base para tomar decisiones.
Uno de los obstculos ms crticos para el xito de la medicin es que los objetivos de
distintos grupos dentro de una organizacin no siempre estn alineados y a veces pueden
resultar contradictorios.
Por ejemplo, todas las organizaciones realizan un seguimiento del calendario de los
proyectos. Sin embargo, los datos que se toman y la importancia de las mediciones del
calendario varan dentro de la organizacin:
22
La mayora de gerentes tcnicos se preocupan por desarrollar un producto que

cumpla los requisitos funcionales y de fiabilidad;
Los objetivos de calendario y costes son, a menudo, determinados por otras partes
como clientes, gerentes de marketing y alta direccin.
A los directivos les preocupa estimar el tiempo para la entrega de un producto.
Al gerente de negocio le interesa conocer el tiempo que llevar comercializar una

nueva funcionalidad y el impacto de un retraso en la cuota de mercado.
Por otro lado, el gerente de procesos estar preocupado por los cambios en el
tiempo de desarrollo del software y su impacto en otros procesos.
Un programa de medicin exitoso debe integrar las necesidades de informacin de todos los
involucrados en tomas de decisiones.
Definir mtricas
El formalizar un concepto medible en una construccin de medicin implica el considerar
los detalles de los procesos y productos del proyecto software y una descripcin detallada
de la necesidad de informacin asociada. Estos detalles ayudarn en la implementacin de
un programa de medicin efectivo y eficiente. Los beneficios ms destacados del uso de
construcciones de medicin bien definidos incluyen:
Reducir la redundancia de mtricas, ayudando a identificar un conjunto de

mtricas base (primitivas) que puedan servir para distintos propsitos.
Aumentar la exactitud, asegurando que todos los aspectos esenciales del enfoque
de medicin estn definidos de una manera adecuada.
Maximizar el valor de las mtricas base creando patrones de mtricas derivadas e

indicadores que puedan ser fcilmente reconocidos, reutilizados y adaptados.
Documentar la relacin entre las necesidades de informacin y cmo se

satisfacen estas necesidades.
El siguiente grfico representa los conceptos clave dentro de la construccin de mtricas:
23
Necesidades de Informacin
Producto de
Informacin
Concepto medible
Diseo de la
construccin de
medicin
Entidades
Atributos
Figura 11. Relacin conceptos medicin III
En definitiva, desarrollar un programa de medicin efectivo requiere un entendimiento

exhaustivo de las necesidades de informacin de software del proyecto, un conjunto de
conceptos medibles bien definidos y relacionados, y un conocimiento total de las entidades
de software disponibles para ser medidas dentro del proyecto.
ltimamente ha aparecido un gran nmero de mtricas para capturar atributos del software
de una forma cuantitativa. Sin embargo, muy pocas mtricas han sobrevivido a la fase de
definicin y, por lo tanto, de utilizacin en la industria. Esto se debe a mltiples problemas,
entre ellos:
Las mtricas no siempre se definen en un contexto apropiado en el que el objetivo de

inters se pueda alcanzar.
Incluso si el objetivo es explcito, las hiptesis experimentales a menudo no se hacen

explcitas.
Las definiciones de mtricas no siempre tienen en cuenta el entorno o contexto en el

que sern aplicadas.
No siempre es posible realizar una validacin terica adecuada de la mtrica porque

el atributo que queremos medir no siempre est bien definido
Un gran nmero de mtricas nunca se han validado empricamente.
Esta situacin ha conducido frecuentemente a cierto grado de ambigedad en las

definiciones, propiedades y asunciones de las mtricas, haciendo que el uso de las mismas
sea difcil, la interpretacin peligrosa y los resultados contradictorios.
24
Se han utilizado diferentes enfoques para implementar mtricas sobre proyectos software
aunque no todos son efectivos. Algunos de estos enfoques se han basado en la definicin
detallada de mtricas que se puedan aplicar de forma ecunime a cada proyecto de la
organizacin. Otros, sin embargo, optan por la compra de herramientas de anlisis y
mtricas automatizadas de un proveedor externo sin conocimiento alguno de los procesos
de la organizacin. Pero, realmente para que una mtrica tenga xito y ayude a cumplir los
objetivos del proyecto en un entorno cambiante, hay que tener muy en cuenta las
necesidades de informacin.
Plan de medicin
En todo proceso de medicin ser necesario un plan de medicin que especifique qu se
va a medir y cmo se va a realizar el proceso. Este plan de medicin ser desarrollado en
esta fase, aunque se ir retroalimentando con la informacin obtenida en la siguiente fase,
es decir, a medida que se vayan tomando y analizando las mtricas y vayan apareciendo
nuevas necesidades de informacin, el plan de medicin se ir modificando.
A continuacin se muestran los puntos o apartados que podra contemplarse en un plan de
medicin:
Propsito: es importante que en el plan de medicin se especifique el propsito del

documento. En este plan se expondrn las mtricas que se utilizarn a lo largo del
proyecto asegurando que las mtricas que se definen estn alineadas con los
objetivos del negocio y del proyecto y que se implementan de forma organizada y
planificada.
Alcance: Documentacin del alcance de las mtricas del proyecto indicando que
etapas del desarrollo y mantenimiento del ciclo de vida se cubren con este plan.
Objetivos: Exposicin de los objetivos del documento. Entre los objetivos de este
plan pueden estar la identificacin de mtricas y la gestin del rendimiento del
proyecto. Este plan detalla los procesos y las herramientas, en el caso en que se
usen, necesarios para recolectar medidas, calcular mtricas, analizar e informar de
los resultados.
25
Roles y responsabilidades: Se har una revisin de los roles y responsabilidades

relacionados con las mtricas de acuerdo con los roles del proyecto. Estos datos se
podran exponer en una tabla para hacerlo ms visual.
Dependencias del plan de medicin: En esta seccin se han de exponer todos los
planes y procesos que estn relacionados con el plan de medicin. Entre ellos
pueden estar plan de proyecto, plan de gestin de la configuracin, plan de gestin
de riesgos, plan de gestin de la calidad. Los cambios que se produzcan en alguno
de estos planes o procesos puede implicar una revisin del que se est definiendo
en este documento.
Objetivos de calidad de proyecto y rendimiento de proceso: Definicin de los

objetivos de calidad y de rendimiento de proceso para el proyecto. Los objetivos han
de ser medible.
Seleccin de mtricas: Descripcin del mtodo de seleccin de mtricas para este

proyecto. Estas mtricas han de estar alineadas con los objetivos de negocio.
Tambin se debera indicar de qu manera pueden estas mtricas ayudar a
conseguir los objetivos de negocio.
Mtricas y medidas del proyecto: este apartado se podra dividir en distintas

partes:
Tabla 3. Mtricas del proyecto en un plan de medicin
Mtricas
Definicin de mtricas
Descripcin
Definicin detallada de las mtricas que se van a usar en el
proyecto indicando por ejemplo:
nombre de la mtrica
descripcin de la mtrica
frmula
prioridad
fuente de los datos
nivel de anlisis
informe de anlisis
26
Captura de datos
Definicin de los mtodos a seguir en la recogida de los datos

usados en las mtricas: de dnde se van a obtener los datos,
dnde almacenarlos de manera que se accesible para su uso
futuro
Gestin y anlisis de datos
Definicin de los procesos que se van a llevar a cabo para el

anlisis de los datos medidos. Especificar los procedimientos
de anlisis por adelantado asegura que el anlisis se va a
realizar conforme a los objetivos de medida.
Comunicacin de resultados
Descripcin del proceso de comunicacin de los datos a todos

los agentes involucrados en un tiempo adecuado para servir
de apoyo a la toma de decisiones y ejecucin de acciones
correctivas.
Formacin
Descripcin de la formacin necesaria para los involucrados

en el proceso relacionado con las mtricas.
Recoger, validar y almacenar mtricas

La recoleccin, validacin y los informes que recogen los datos obtenidos de las mtricas
estn relacionados directamente con las necesidades de informacin de la organizacin.
A medida que el proyecto avanza, las necesidades de informacin cambian, y por lo tanto
tambin lo harn las mtricas aplicadas. En este apartado vamos a ver en qu consisten las
actividades de recogida, validacin y almacenamiento de datos.
27
Recoger
Figura 12. Desarrollo de mecanismos de recoleccin de datos
La especificacin explcita de los mtodos de recogida de datos ayuda a asegurar que se

recogen los datos correctos de forma adecuada.
Es importante formar a las personas involucradas en la recoleccin de datos para asegurar
que entienden por qu los datos son necesarios, cmo van a ser utilizados y cmo sus
acciones contribuyen a la validacin total del proceso de recoleccin.
Para ser efectivas, las mtricas deben implementarse dentro de un proyecto u organizacin
como un proceso de soporte de ingeniera de software. De esta forma, las mtricas deben
incluirse en todas las actividades asociadas con la planificacin, rendimiento y evaluacin de
tareas de la organizacin o del proyecto.
Pero las mtricas no se mantienen por s mismas sino que ser necesario definir qu
informacin es necesario recoger para la toma de decisiones, y de qu manera esta
informacin ser recogida, analizada, presentada y utilizada. El proceso de medicin
combina distintos datos objetivos y subjetivos en productos de informacin integrados que
dirigen directamente las necesidades de informacin del proyecto ya definidas.
28
Validar
En varias disciplinas tradicionales como la fsica, la qumica e ingenieras clsicas, la
evolucin, empleo y validacin de mtricas se ha desarrollado a lo largo de siglos, de modo
que hoy muchas de las mtricas estn incorporadas en la vida cotidiana como medidas de
temperatura, velocidad, distancia, entre otras, sin que nadie dude sobre la validez de las
mismas. Sin embargo, no sucede lo mismo en Ingeniera de Software, donde todava se
debate si existe comprensin suficiente sobre las no demasiadas mtricas existentes y
popularmente empleadas.
Por eso es importante tener un claro conocimiento de las propiedades que deberan tener
las mtricas. Entre las ms importantes estn [Schulmeyer y MacKenzie, 2000]:
Simplicidad: la definicin y uso de la mtrica ha de ser simple.
Objetividad: diferentes personas han de darle valores idnticos. Esto le da

consistencia y evita interpretaciones individuales.
Facilidad de recoleccin: el coste y esfuerzo para obtener la medida ha de ser

razonable.
Robustez: la mtrica ha de ser insensible a cambios irrelevantes. Esto permite

realizar tiles comparaciones.
Validez: la mtrica ha de medir lo que se supone que mide. Esto da fiabilidad a la

medida.
Informalmente se dice que una medida es vlida si caracteriza fielmente el atributo que
pretende medir.
Validar una medida software es el proceso de asegurar que la medida es una

caracterizacin numrica apropiada del atributo que pretende medir. Es decir, hay que
asegurarse de que las medidas que se usan reflejan el comportamiento de las entidades del
mundo real.
Una medida debe ser vista en funcin del contexto en que ser usada. La validacin debe
tener en cuenta el propsito de la medicin. Fenton y Pfleeger dan dos definiciones de
validacin:
29
Validacin en sentido reducido: es el proceso riguroso de asegurar que la medida

representa adecuadamente el atributo software que se quiere medir. Es decir,
verificar que la medida es razonable tericamente (internamente vlida).
Validacin en sentido amplio: es la utilizacin de una medida internamente vlida

como un componente de un sistema de prediccin vlido.
[Kitchenham et al, 96] asumen que para que una medida sea vlida se deben cumplir dos
condiciones:
Que la medida no viole ninguna propiedad de sus elementos.
Cada modelo usado en el proceso de medicin debe ser vlido.
Adems, de acuerdo al marco conceptual para validacin de mtricas propuesto, para

decidir si una mtrica es vlida, es necesario confirmar al menos:
La validez del atributo: si el atributo en cuestin es realmente exhibido por el ente

que se desea evaluar.
La validez de la unidad: si la unidad de medicin a ser usada es apropiada para

medir al atributo.
La validez del instrumento: si el modelo que subyace al instrumento de medicin es

vlido y el mismo est propiamente calibrado.
La validez del protocolo: si se ha adoptado un protocolo aceptable para la medicin

de modo que sea repetible y replicable.
Almacenar
Tal y como se especific con anterioridad, en el plan de medicin organizacional quedar
recogido una descripcin del repositorio donde se almacenarn los datos y el proceso a
seguir por cada proyecto para incorporar los datos a este repositorio. Este conjunto de
medidas ser requerido para cada proyecto, pudiendo realizarse adaptaciones para
proyectos especficos.
El repositorio es una herramienta muy til para facilitar el acceso a la informacin de cada
proyecto, en este caso a las mtricas de cada proyecto, de tal forma que la reutilizacin de
mtricas ya definidas y validadas se pueda hacer de manera efectiva. Es decir, gestionar y
30
almacenar los datos medidos, especificaciones de medida y resultados del anlisis permite
un uso futuro de los datos histricos efectivo en tiempo y coste. Esta informacin
tambin es necesaria para proporcionar un contexto en el que interpretar los datos, los
criterios de la medicin y resultados del anlisis.
En un principio, los proyectos pueden almacenar sus datos y resultados en un repositorio
especfico de su proyecto, pero cuando los datos sean compartidos o consolidados por toda
la organizacin, deben residir en el repositorio de medicin de la organizacin.
En definitiva, la especificacin de los procedimientos de almacenamiento de datos ayuda a
asegurar que los datos estn disponibles y accesibles para su uso futuro.
Analizar mtricas
Una vez que se han recogido los datos, stos son tratados para realimentar los proyectos en
una accin correctiva. La recoleccin de datos sera un proceso intil si no se hiciera nada
con esa informacin. Si el anlisis de los datos slo se utiliza para mostrar lo que se ha
conseguido podran servir de manera informativa pero con esto no se consigue ningn
objetivo.
Las mtricas deben ser analizadas inmediatamente despus de calcularlas, comparndolas

con los objetivos fijados.
Si hay una desviacin sobre los objetivos o no se alcanza la meta, se deben iniciar
acciones correctivas y preventivas. Posibles acciones en este sentido son:
Actualizar la documentacin del proceso
Utilizar distintos mtodos o ciclos de vida en los proyectos
Introducir controles adicionales mediante la verificacin y validacin
Utilizar distintas tecnologas o herramientas
Actualizar la infraestructura o sistema de medicin
Automatizar algunas actividades del proyecto
Actualizar las habilidades del personal
31
Por todo ello, ser necesario definir en un plan de anlisis:
cmo se van a organizar los datos
qu mtricas o datos se van a analizar
los mtodos que se van a utilizar para analizarlos
qu objetivos se pretenden satisfacer con el anlisis o qu informacin se pretende

obtener del anlisis
a quin se va a presentar los resultados del anlisis y de qu manera
Mtodos de anlisis
Especificar los procedimientos de anlisis, indicando cmo se va a analizar y se va a
informar sobre los datos medidos, por adelantado asegura que el anlisis se va a realizar
conforme a los objetivos de medida (y, por tanto, conforme a las necesidades de informacin
y objetivos en que stos se basan). Esto supone tambin una comprobacin de que se van
a recoger los datos necesarios.
Existen distintos mtodos de anlisis. Las herramientas estadsticas promovidas por
Ishikawa para el control de la calidad son ampliamente utilizadas y se han convertido en una
parte importante dentro del control de la calidad. Se las conoce como las siete
herramientas bsicas de Ishikawa y se suelen utilizar para analizar las mtricas de
software.
Estas herramientas estadsticas se pueden aplicar a nivel de proyecto y de organizacin, por
lo tanto, son tiles tanto para jefes de proyecto como para expertos en procesos pero no van
a proporcionar informacin especfica a los desarrolladores de software sobre cmo mejorar
la calidad de sus diseos o sus implementaciones. Adems, los beneficios de estas
estadsticas puede que no se alcancen en el caso de proyectos pequeos, donde los
patrones estadsticos de los parmetros de un proceso de desarrollo son poco obvios.
Las siete herramientas bsicas de Ishikawa son:
Checklist (o check sheet)
Diagrama de Pareto
Histograma
32
Diagrama de dispersin
Grfico de ejecucin
Grfico de control
Diagrama de causa-efecto
Tabla 4.Las siete herramientas bsicas de Ishikawa
Herramienta
Checklist
Diagrama de Pareto
Histograma
Grfico de ejecucin
Propsito
Ayudar en la recogida y
organizacin de datos
para facilitar su consulta
en el futuro.
Ayuda a identificar las

reas que producen la
mayora de los problemas
Mostrar las caractersticas

de distribucin de un
parmetro
(tendencia
central,
dispersin
y
asimetra)
Identificar
potencial
variables
Ejemplos
aplicaciones
Caractersticas
una relacin
entre
dos
Registra el rendimiento de
un parmetro de inters a
lo largo del tiempo
No son largas
Basadas en la experiencia
revisadas y actualizadas de
forma peridica
Eje X es la causa del defecto

Eje Y es el nmero de
defectos
Eje X lista los intervalos de

unidades de un parmetro
ordenados
de
forma
ascendente de izquierda a
derecha
Eje Y contiene nmeros de
frecuencias
En una relacin causa-efecto
Eje X se utiliza para la
variable independiente
Eje Y para
dependiente
la
variable
Eje X es el tiempo
Eje Y es
parmetro
el
valor
del
lista de errores
frecuentes que
podra utilizarse
como parte de un
proceso de
prevencin de
defectos
Centrarse en los
tipos de defectos
ms frecuentes.
Identificar
las
principales
causas
de los cambios de
requisitos
el perfil de
satisfaccin del
cliente con un
producto software en
trminos de muy
satisfecho,
satisfecho, neutro,
insatisfecho, y muy
insatisfecho
Para presentar el
coeficiente
de
correlacin entre dos
variables
registrar el
porcentaje de
correcciones en el
software que
superan el tiempo de
respuesta, segn el
criterio
correspondiente
33
Tipo avanzado de grfico

de ejecucin en
situaciones donde se
puede definir la capacidad
de un proceso.
Grfico de control
Permite ver patrones de

comportamiento en el
tiempo y proporciona una
base para predecir el
futuro.
Consiste en:
-una lnea central (media:
valor medio de todos los
datos)
Son tiles en la
mejora de procesos
software.
-un par de lmites de control

(a veces tambin un par de
lmites de peligro dentro de
los lmites de control)
Se pueden utilizar
como herramientas
para
mejorar
la
consistencia
y
estabilidad.
-valores del parmetro de

inters trazados en el
grfico, que representan el
estado de un proceso
Fin Eje horizontal (espina
central): asunto a analizar
Anlisis de las diferentes

causas que ocasionan los
problemas facilitando los
Diagrama de causa-efecto
estudios
posteriores
de
evaluacin del grado de
Lneas o flechas inclinadas

que llegan al eje principal:
grupos de causas primarias
en que se clasifican las
causas del problema.
aporte de cada una de
las
flechas
inclinadas
estas causas.
llegan otras menores que
Concentrar
el
esfuerzo del equipo

en la resolucin de
problemas
complejos.
representan las causas que

afectan a cada una de las
causas primarias
Aplicacin y ejemplos de los mtodos de anlisis

La mayora de las herramientas bsicas se pueden implementar fcilmente tanto en equipos
pequeos como en grandes organizaciones.
Para equipos pequeos que comienzan un programa de mtricas, se recomienda enfocarse
en la checklist, diagrama de Pareto, y diagrama causa-efecto.
La checklist sirve para guiar y reforzar la implementacin de un proceso.
El diagrama de Pareto es til para parmetros cuantitativos relativos a la calidad de

producto (defectos, quejas de clientes, correcciones defectuosas)
El diagrama causa-efecto es una herramienta para resolver problemas orientada al

equipo.
34
Con un uso efectivo de estas herramientas, un equipo estar preparado para la mejora de
procesos y de la calidad. En cambio, para estos equipos pequeos que comienzan un
programa de mtricas no se recomienda utilizar un grfico de control, ya que es una
herramienta ms adecuada para entornos que cuentan con un control de los sistemas y
datos histricos bien establecido. Respecto a la implementacin de diagramas de dispersin
y grficos de control, se requiere que alguien del equipo tenga una base estadstica.
A continuacin se muestran algunos grficos a modo de ejemplo de algunos mtodos de
anlisis:
Checklist (o check sheet)
Figura 13. Ejemplo checklist cumplimiento prcticas de CMMI
Diagrama de Pareto
35
Figura 14. Ejemplo Diagrama de Pareto para errores
Histograma
% Defectos
Distribucin de defectos por nivel de severidad

100
90
80
70
60
50
40
30
20
10
0
Severidad 1
Severidad 2 1
Severidad3Severidad4
Figura 15. Ejemplo histograma
36
Plataforma 2
Plataforma 1
Figura 16. Ejemplo diagrama de dispersin
Grfico de ejecucin
% Correcciones que superan

tiempo de respuesta
Semanas
Figura 17. Ejemplo grfico de ejecucin
37
Mtricas
Existen distintas clasificaciones de las mtricas del software. A ms alto nivel las mtricas
del software se pueden clasificar a 3 niveles: mtricas de producto y servicio, mtricas de
proceso y mtricas de proyecto.
Las mtricas de proyecto describen las caractersticas propias del proyecto y de su
ejecucin. Algn ejemplo puede ser el nmero de desarrolladores de software que trabajan
en el proyecto, la dotacin de recursos a lo largo del ciclo de vida del software, el coste,
calendario del proyecto.
Las mtricas de proceso se pueden utilizar para mejorar el desarrollo y el mantenimiento
del software. Las mtricas del proceso dependen esencialmente del entorno de desarrollo.
Un ejemplo de este tipo de mtricas es el tiempo empleado para desarrollar un elemento
software que dependa de factores externos tales como la capacidad del personal, la
metodologa empleada
Las mtricas de producto y del servicio describen las caractersticas del producto, como
tamao, complejidad, caractersticas de diseo o rendimiento, y el nivel de calidad del
servicio prestado.
Vamos a entrar en cada uno de estos niveles en ms profundidad clasificando distintos tipos
de mtricas en cada uno de dichos niveles:
Mtricas en un proyecto software

Las mtricas a nivel de proyecto son mtricas tcticas. Estas mtricas van a facilitar a los
responsables de los proyectos el adaptar el flujo de trabajo del proyecto y las actividades
tcnicas a los resultados obtenidos, pudiendo hacer un seguimiento del estado del proyecto,
y de los cambios que vaya sufriendo.
En definitiva, las mtricas del proyecto permiten al gestor de proyectos del software
[Pressman]:
Evaluar el estado del proyecto en curso
Seguir la pista de riesgos potenciales
38
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.
Tabla 5. Ejemplo de mtricas durante la gestin de proyectos
Gestin de proyectos
Planificacin
Calidad del plan de proyecto

Progreso adecuado
Cumplimiento de tiempos
Cumplimiento de hitos
Ejecucin
Cumplimiento de esfuerzos
Cumplimiento de costes
Cumplimiento de alcance
Cumplimiento de RR.HH.
Existencia de seguimiento
Seguimiento
Continuidad de seguimiento
Complecin del seguimiento
Productividad
Porcentaje de re trabajo (rework)
En realidad, las medidas que recopila un equipo de proyecto y las convierte en mtricas
para utilizarse durante un proyecto tambin pueden transmitirse a los que tienen la
responsabilidad de mejorar el proceso del software. Por esta razn, se utilizan muchas
mtricas similares tanto en el domino del proceso como en el del proyecto.
39
Mtricas del progreso de los proyectos

Adems de asegurar que un proyecto est dentro del presupuesto, la medicin ayuda a
asegurar que las actividades del proyecto son realizadas tal y como se plane y el progreso
que siguen es el que se planific.
Los jefes de proyecto necesitan validar el estado de las actividades planeadas y comparar
los datos reales con los planificados para identificar desviaciones. Esto ayudar a tomar
acciones correctivas a tiempo de tal forma que el proyecto vuelva al camino marcado por el
plan establecido. Los datos necesarios son recogidos normalmente mediante partes de
horas, informes semanales y reuniones de seguimiento.
Los jefes de proyecto a menudo utilizan software de gestin de proyecto que ayude a
almacenar los datos del plan del proyecto y a generar informes que plasmen las
desviaciones. La desviacin entre el plan y los datos reales son normalmente representados
utilizando grficos y grficos visuales fciles de entender como por ejemplo los grficos de
Gantt.
Figura 18. Ejemplo visualizacin del progreso del proyecto
El progreso es a menudo seguido utilizando grficos que visualmente describen completitud

planificado versus real de las actividades del proyecto.
Evaluar el progreso del proyecto
No es suficiente establecer objetivos alcanzables, sino que tambin es necesario monitorizar
el progreso contra estos objetivos. Conociendo el estado de trabajo, se pueden identificar
las acciones correctivas oportunas.
Para entender la necesidad de monitorizar el progreso de un proyecto vamos a ver un
ejemplo. Supongamos que tenemos un sistema en proceso de desarrollo. Se ejecutan una
40
serie de pruebas y se encuentran varios defectos. Se corrigen dichos defectos y desde ese
momento se presta ms atencin a las reas que contenan la mayora de dichos defectos.
Despus de un tiempo se vuelven a ejecutar las pruebas y en funcin del resultado se
decidir si continuar centrndose en esas reas de riesgos o si han aparecido nuevas reas
de riesgo en la que centrarse. Es esencial que se vuelvan a ejecutar pruebas para tomar
acciones correctivas en caso de que sea necesario.
En este caso la medicin se ha utilizado para evaluar el estado del proyecto e identificar si
seran necesarias acciones correctivas.
Mtricas de recursos
Los recursos son usados en los proyectos para construir productos. Un proyecto debe
realizarse con un presupuesto definido y esto significa que los recursos disponibles son
limitados.
La planificacin determina el nmero de recursos necesarios para llevar a cabo un proyecto,
mientras que la monitorizacin y control asegura que la utilizacin de recursos est dentro
del presupuesto.
El esfuerzo requerido para llevar a cabo un proyecto software constituye la mayora de su
coste. Por lo tanto, la estimacin y la monitorizacin del esfuerzo invertido en un proyecto es
un rea importante en proyectos software.
La estimacin es llevada a cabo utilizando
modelos de estimacin y datos de proyectos pasados. Y la monitorizacin y el control

mediante la recogida de datos acerca del esfuerzo real invertido y compararlo con el
planificado.
Tabla 6. Ejemplo de parte de horas
Parte de horas semanal
ID Proyecto
Miembros del equipo
Fecha
Descripcin de tarea
Horas
Estado
41
Cdigo de estado
C - Completo
Firmas
E - En-progreso
S - Suspendido
Fecha de entrega
Los proyectos normalmente utilizan partes de horas, como el que se muestra en la tabla
anterior, como una entrada para medir el esfuerzo real.
Mtricas de la calidad de un proceso

Las mtricas del proceso de software se utilizan para propsitos estratgicos, a diferencia
de las orientadas al proyecto, que como se vio en el apartado anterior eran tcticas.
Un jefe de proyecto tambin debera medir la calidad del proceso destinado al desarrollo
del producto software. La medicin permite al jefe de proyecto validar si el proceso que se
est utilizando es efectivo a la hora de conseguir los objetivos establecidos para el proyecto.
Acorde a esto, se podrn tomar las acciones correctivas oportunas.
La nica forma de mejorar cualquier proceso es:
Medir sus atributos
Desarrollar un conjunto de mtricas significativas en funcin de estos atributos
Finalmente, utilizar estas mtricas para proporcionar indicadores que conducirn a

una estrategia de mejora.
Un producto es de buena calidad si tiene pocos defectos. Por lo tanto, la medicin de la

calidad de un producto a menudo mide el nmero de defectos que tiene dicho producto. A
menudo, los procesos son medidos para determinar su efectividad en la deteccin y
eliminacin de defectos, y el coste que supone.
Una mtrica simple, pero muy til, para medir la efectividad de un proceso de deteccin de
errores en la deteccin de los errores en un producto es la eficiencia de eliminacin de
defectos (DRE). Otras mtricas del proceso de pruebas ms comunes son:
Porcentaje de trabajo realizado en la preparacin de los casos de prueba (o

porcentaje de casos de prueba planificados que han sido preparados).
42
Porcentaje de trabajo realizado en la preparacin del entorno de pruebas.
Ejecucin de casos de pruebas (p.ej.: nmero de casos de prueba ejecutados/no

ejecutados, y casos de prueba pasados/fallados).
Informacin de defectos (p.ej.: densidad de defectos, defectos encontrados y

corregidos, ndice de fallos y resultados de repetir las pruebas).
Cobertura de pruebas de requisitos, riesgos o cdigo.
Fechas de hitos en las pruebas.
Costes de las pruebas.
La productividad
La productividad es una mtrica que proporciona informacin acerca de la eficiencia con la
que un proceso software convierte la entrada en salida.
Una baja productividad significa que se necesitan ms recursos para producir la salida
requerida. Esto afecta tanto al coste (necesitamos ms esfuerzo) como a la agenda (se
necesita ms tiempo) del proyecto, que recordemos son dos aspectos claves del xito de los
proyectos. Por lo tanto, los jefes de los proyectos trabajan por conseguir una alta
productividad de tal forma que puedan acabar el proyecto al menor coste y dentro de la
agenda.
43
Figura 19. La medicin en la estimacin de la productividad de un proyecto
Muchos factores diferentes afectan a la productividad de un individuo, equipo de proyecto,

grupo y una organizacin entera. Por ejemplo:
Personal sin experiencia tendrn un impacto significante en la productividad y

calidad del proyecto.
Horarios insensatos fuerzan a que la gente cometa errores, a hacer su trabajo de

una manera poco productiva, incluso aunque en teora lo que se pretenda es intentar
adaptarse a la planificacin de la agenda establecida.
Responsables del proyecto sin experiencia son una fuente de problemas (requisitos
mal definidos, clientes no satisfechos, baja productividad del proyecto.)
Bajo uso de mtodos de ingeniera de software
La no realizacin de inspecciones o walkthroughs formales, pruebas en profundidad

y la falta de mtricas y medicin, diseo pobre y la no utilizacin de cdigo
reutilizable crearn problemas en cuanto a la productividad. [Capers Jones]
44
En resumen, durante la planificacin de un proyecto, los jefes de proyecto necesitan conocer

la productividad para estimar los recursos necesarios para el correcto desarrollo del mismo y
para planificar los hitos del proyecto.
Mtricas de calidad de producto
Figura 20. Nivel de satisfaccin del cliente frente a los defectos y los retrasos.
Como se vio en apartados anteriores, una de las claves del xito de los proyectos es la
calidad y por lo tanto ser necesario su planificacin, monitorizacin y control de una
manera exhaustiva. La calidad del producto es el determinante esencial del xito de un
proyecto desde el punto de vista del cliente.
Si un proyecto es completado a tiempo y dentro del presupuesto estimado pero el producto
desarrollado no satisface las necesidades del cliente, es decir, no es lo que el cliente quera,
que se hayan cumplido agenda y presupuesto no ha merecido la pena.
Algunos responsables piensan que los clientes estn ms interesados en tiempo y
desarrollo del producto dentro del presupuesto. Pero realmente esto no es cierto. Los
clientes pueden olvidar un proyecto que est ligeramente fuera de la agenda, incluso que el
45
coste final del proyecto se haya incrementado respecto al proyectado, pero ningn cliente
podr olvidar un producto de poca calidad con el que est trabajando a diario por ejemplo.
Si los jefes de proyecto solo se centran en la productividad, la calidad puede sufrir. A menos
que el equipo de proyecto se centre en desarrollar productos de calidad alta, habr ms
defectos y estos resultarn en un aumento de costes al corregirlos y tambin afectar a la
agenda.
Tabla 7. Ejemplos de mtricas a nivel de producto y servicio
Producto fsico
Nmero de componentes
Lneas de cdigo
Tamao
Puntos funcin
Volumen de software
Nmero de componentes llamados ms de n veces
Nmero de llamadas
Reutilizacin
Volumen de reutilizacin
Ratio de reutilizacin
Desarrollo de productos
Calidad de documentacin de proyecto
Documentacin
Calidad de documentacin de soporte
Porcentaje de cdigo comentado
Calidad de cdigo
Complejidad ciclomtica
Cdigo muerto
Cobertura de pruebas
Calidad de pruebas
Densidad de defectos
46
Servicios
Disponibilidad del sistema
Calidad de explotacin
Eficacia del sistema

Seguridad del sistema
Satisfaccin del cliente

Reparos en explotacin
Grado de satisfaccin
Grado de satisfaccin del cliente
Mtricas de calidad de producto final

Ahora vamos a describir algunas de las mtricas que se podran tomar en este nivel durante
el desarrollo de un producto:
La calidad de producto se mide normalmente por:
la densidad de defectos: mide los defectos relativos al tamao del software (lneas
de cdigo, puntos funcin, etc.)
el tiempo medio de fallo: mide el tiempo que trascurre entre la deteccin de fallos
Otras mtricas importantes son:
El ndice de defectos de un producto o el nmero esperado de defectos en un

determinado periodo de tiempo es importante para estimar el coste y recursos de la
fase de mantenimiento del ciclo de vida del software.
Problemas encontrados por el cliente al utilizar el producto y que por lo tanto

refleja el grado de satisfaccin que tienen.
La satisfaccin del cliente, normalmente, se mide mediante encuestas realizadas al

cliente. Algunos de los parmetros que se evalan en las encuestas de satisfaccin
del cliente son: capacidad, funcionalidad, usabilidad, rendimiento, fiabilidad,
mantenibilidad, documentacin/informacin y servicio.
47
Mtricas de mantenimiento de software

Todas las mtricas que se mencionaron en el apartado anterior estn relacionadas con el
producto final, pero cuando finaliza el desarrollo de un producto software y se lanza al
mercado, comienza la fase de mantenimiento dentro del ciclo de vida del producto.
Existen mtricas como la llegada de defectos por intervalo de tiempo o las incidencias
del cliente (que pueden ser defectos o no) por intervalo de tiempo que se toman en un
momento en el que ya no se puede hacer mucho para alterar la calidad del producto en esa
fase. Por tanto, estas dos mtricas, aunque son importantes, no reflejan la calidad del
mantenimiento del software.
Lo que se debe hacer en esta fase de mantenimiento es corregir los defectos lo antes
posible y hacerlo con buena calidad. Estas acciones, aunque no pueden mejorar el ndice
de defectos de un producto, pueden mejorar en gran medida la satisfaccin del cliente.
En este sentido, las siguientes mtricas de mantenimiento son muy importantes.
Tiempo de respuesta en las correcciones: En muchas organizaciones de

desarrollo de software, se establecen guas sobre el tiempo lmite en el que las
correcciones de los defectos registrados deben estar disponibles. La mtrica de
tiempo de respuesta en las correcciones se calcula para todos los problemas, segn
su nivel de severidad, como el tiempo medio desde que se registra un problema
hasta que se cierra.
Porcentaje de correcciones atrasadas: Una correccin se clasifica como atrasada

si el tiempo empleado en ella supera el tiempo de respuesta requerido.
Calidad de las correcciones: La calidad de las correcciones o el nmero de

correcciones defectuosas es otra mtrica importante de calidad para la fase de
mantenimiento. Desde la perspectiva del cliente, es malo encontrar defectos
funcionales en el software pero es peor an si las correcciones de estos defectos no
solucionan el problema registrado, o lo solucionan pero introducen un nuevo defecto.
La mtrica del porcentaje de correcciones defectuosas es simplemente el porcentaje de

todas las correcciones en un intervalo de tiempo que son defectuosas.
48
Buenas prcticas
En un mercado en continuo cambio como es el de TI, las organizaciones necesitan tomar las
decisiones adecuadas y a tiempo para tener xito en los proyectos y sistemas de la
organizacin. Con este panorama, la informacin objetiva es un requisito para la toma de
decisiones crticas y basadas en hechos.
La implementacin de un buen proceso de medicin y anlisis apoyado por una herramienta
que lo automatice permitir a la organizacin tomar decisiones rpidas y adecuadas en
reas competitivas.
A continuacin, se exponen algunas guas para obtener beneficios de la implementacin de
un sistema de medicin exitoso:
Utilizar los resultados: la informacin medida debe ayudar a los encargados de la

toma de decisiones a entender los problemas de los proyectos y de la organizacin,
evaluarlos y actuar en consecuencia.
Empezar poco a poco: no intentar hacer demasiado en poco tiempo. Empezar con
un conjunto de mediciones pequeo, evaluar estas mediciones y el proceso, e
intentar evolucionar el programa con el tiempo. Como los procesos de TI estn
bastante interrelacionados, a veces, un nmero pequeo de mediciones puede
solventar un amplio conjunto de necesidades de informacin.
Proporcionar formacin adecuada: todos los usuarios deben entender lo que

representan los datos medidos y cmo interpretar los resultados. Se recomienda
ofrecer formacin tanto en la metodologa como en las herramientas para obtener un
resultado efectivo.
Minimizar costes: un proceso de medicin debe ser efectivo en costes para

considerarse exitoso. Recoger slo los datos necesarios, de acuerdo a los objetivos
de medida y necesidades clave de informacin. Automatizar el proceso siempre que
sea posible.
Adoptar una orientacin a la accin: en las primeras fases de planificacin de la

medicin, seleccionar medidas alineadas con las necesidades clave de informacin
tanto a nivel de la organizacin como a nivel de proyectos. La informacin se debe
49
obtener de forma temprana para reducir riesgos y poder corregir posibles problemas
a tiempo. El programa de medicin debe estar integrado en las prcticas del negocio
de la organizacin, no debe ser tratado como un proceso aadido y aislado del resto.
Comunicar: la buena comunicacin mejora la comprensin por todas las partes

involucradas y conduce a una situacin exitosa. La comunicacin es esencial y la
actualidad de los datos es crtica.
Otro punto importante a recordar es que las mtricas consumen tiempo y esfuerzo e intentar
medir demasiadas cosas puede ser algo contraproducente. Para organizaciones que se
inician en la prctica de toma de mtricas, se recomienda seguir pasos como los siguientes:
Identificar pocas mtricas y simples que ayuden al trabajo de la gestin de proyectos.
Recoger mtricas identificadas de una forma disciplinada.
Calcular mtricas que faciliten el entendimiento del producto, proyecto y del proceso
y usar estas mtricas para una gestin de proyectos efectiva, como por ejemplo la
densidad de defectos.
Almacenar todas las mtricas en una base de datos de histrico.
Adems, dentro del proceso de medicin y anlisis, los siguientes puntos son clave:
Tabla 8. Buenas prcticas durante el proceso de medicin y anlisis
Fases del proceso de
Buenas prcticas
medicin y anlisis
Alinear todas las perspectivas de las necesidades de informacin.

Identificar necesidades de
informacin
Disear el proceso de medicin de tal manera que reaccione a cambios.

Un programa de medicin exitoso debe integrar las necesidades de
informacin de todos los involucrados en tomas de decisiones.
Definir
objetivos
medicin
de
Asegurarse que los objetivos de distintos grupos dentro de una organizacin

estn siempre alineados de tal forma que no resulten contradictorios.
Asegurarse de que las mtricas:
Definir mtricas
Estn conectadas con las metas y objetivos
Estn conectadas con los procesos que impactan a las metas y objetivos
50
No son ambiguas y estn claramente definidas. Para asegurar consistencia

proporcionar mtricas base bien definidas.
Con una definicin operativa para las mediciones/datos
Sencillas de entender e implementar
Presentar la informacin en un formato que es fcil de entender por el que ha
de tomar decisin. En general, la gente que hace la medicin no es la que
toma las decisiones. Es importante presentar la informacin de forma clara y
concisa.
Establecer medidas requiere entre 6 y 9 meses:
El enfoque inicial est sobre la provisin de datos
Luego sobre problemas con los datos
Cuando estos estn resueltos, el enfoque se mueve sobre temas de
rendimiento
No hay que olvidar que lo que se pretende es conseguir mtricas tiles y
prcticas.
Recoger,
validar
almacenar mtricas
Comprobar la validez de los datos recogidos: que son correctos, precisos,

ntegros, consistentes y completos.
Analizar las mtricas inmediatamente despus de calcularlas y compararlas
con las metas u objetivos fijados. El anlisis de los datos es ms fructfero
cuando conduce a un proceso de mejora continua. Las medidas deben mostrar
Analizar mtricas
un aumento en la estabilidad, una reduccin en la desviacin, una mejora en la

media del rendimiento. Si el anlisis de los datos slo se utiliza para mostrar lo
que hemos hecho, puede ser informativo, pero no ser ms til que leer el
peridico del da anterior.
Utilizar resultados
Utilizar los resultados de la medicin para tomar acciones correctivas y preventivas. Si hay alguna desviacin
sobre la meta o la meta no se alcanza, se deben iniciar acciones correctivas y preventivas.
La medicin y anlisis es un proceso iterativo. Tanto el proceso como las medidas deben ser revisados y
mejorados peridicamente. Las medidas se deben refinar cuando cambien las necesidades de informacin y la
organizacin implemente acciones de mejora.
51
Lecciones aprendidas
Al comenzar a medir los procesos y productos software y sistemas de ingeniera, obtener
unos resultados de medicin tiles puede ser un desafo. La parte positiva es que la mayora
de programas de medicin exitosos estn basados en pocos conceptos bsicos que forman
la base de un programa de medicin efectivo y un enfoque efectivo en costes y flexible para
alcanzar las necesidades de informacin identificadas, incluso en los entornos ms
complejos.
A continuacin, se exponen unas lecciones aprendidas de programas de medicin
llevados a cabo con xito:
La medicin es un proceso consecuente pero flexible que debe ser adaptado a

las necesidades de informacin y caractersticas de un proyecto particular u
organizacin. Las mediciones deben cambiar a medida que el entorno y las
necesidades de informacin cambian. La medicin no es una lista de medidas a
tomar sino un proceso para refinar los datos que nos proporcionan informacin
relativa a las necesidades de informacin cambiantes.
Se debe permitir ajustar las definiciones de las mtricas a las necesidades de
informacin. En caso de modificar las definiciones originales de las mtricas, se ha
de especificar cmo se van a agregar los datos y los resultados de anlisis.
Los responsables de la toma de decisiones deben comprender lo que se est

midiendo. La comunicacin adecuada de los resultados de las mediciones a los
gerentes, tanto de negocio como tcnicos, fomenta la toma de decisiones en el
momento adecuado.
Las mediciones se deben utilizar para que sean efectivas. El programa de

medicin debe jugar un papel importante a la hora de ayudar a los responsables de
la toma de decisiones a optimizar el rendimiento, a gestionar su negocio. Las
organizaciones con xito utilizan los resultados de las mediciones de forma regular
para la toma de decisiones.
Los datos hay que proporcionarlos suficientemente pronto para que los gerentes puedan
definir acciones. No hay que esperar a obtener datos perfectos para tomar decisiones pero
52
hay que basarse en datos correctos, acompaados de una gestin de riesgos e informacin
contextual.
Como la mayora de organizaciones se componen de una cartera de diversos proyectos, la
informacin obtenida a nivel de proyecto debe ser agrupada en los niveles apropiados de la
organizacin para poder ser utilizada de forma efectiva.
53
Enfoque modelos
Existen diferentes modelos que contemplan la medicin y anlisis. En este apartado vamos
a ver el enfoque que dos importantes modelos de mejora de procesos como son CMMI y
SPICE dan al proceso de medicin y anlisis.
CMMI
CMMI es un modelo de madurez de mejora de procesos para el desarrollo y
mantenimiento de productos y servicios. Consiste en una serie de mejores prcticas que
dirigen las actividades de desarrollo y mantenimiento que cubren el ciclo de vida del
producto. CMMI est estructurado en tres constelaciones.
El objetivo principal del rea de proceso Medicin y Anlisis (MA) en el modelo CMMI-DEV
es desarrollar y poner en marcha el sistema de medicin de la organizacin de manera que
pueda satisfacer sus propias necesidades de informacin. Esto implica:
La especificacin de los objetivos de MA de forma que estn alineados a las metas y

necesidades de informacin.
La especificacin de mtricas, tcnicas de anlisis y mecanismos para la

recoleccin, almacenaje, reporte y retroalimentacin de la informacin para su
posterior implementacin.
Dar resultados objetivos que puedan ser utilizados para tomar decisiones informadas
y tomar acciones correctivas.
El rea de proceso MA es de la categora Soporte, es decir, las prcticas de MA se utilizan

para satisfacer las necesidades de informacin de los proyectos, de los productos, de la
organizacin y las relacionadas con el desempeo de los procesos.
El rea de proceso tiene dos metas especficas y prcticas especficas asociadas a cada
una de las metas:
54
Tabla 9. rea de proceso MA

Meta especfica
Prcticas especficas
SP1.1 Establecer objetivos de medicin
SP1.2 Especificar mediciones
SG1 Alinear las Actividades de Medicin y Anlisis

Los objetivos y actividades de medicin estn alineados
con las metas y necesidades de informacin identificadas.
SP1.3
Especificar
procedimientos
de
recogida y almacenamiento de datos

SP1.4
Especificar
procedimientos
de
anlisis
SP2.1
Recolectar
datos
para
las
mediciones
SG2 Proporcionar Resultados de la Medicin
SP2.2 Analizar datos de las mediciones
Los resultados de las mediciones, las cuales soportan las
metas y necesidades de informacin, son proporcionados.
SP2.3 Almacenar datos y resultados

SP2.4 Comunicar resultados
Las relaciones entre las prcticas especficas estn demostradas en el siguiente grfico:
Alinear las Actividades de Medicin y Anlisis
Establecer
Objetivos de
Medicin
Objetivos de
Medicin
Especificar
Mediciones
Resultados de
Medicin
Especificar
Procedimientos de
Recogida y
Almacenamiento
de Datos
Repositorio de
Mediciones
Especificar
Procedimientos de
Anlisis
Procedimientos
& Herramientas
Proporcionar Resultados de Medicin
Comunicar
Resultados
Almacenar
Datos y
Resultados
Analizar
Datos de
Mediciones
Recoger Datos de
Mediciones
Figura 21. Diagrama de contexto de MA
55
Adems de las metas y prcticas especficas, el rea de proceso MA contiene tambin

metas y prcticas genricas que representan diferentes niveles de institucionalizacin del
proceso en una organizacin.
ISO/IEC 15504
El estndar internacional ISO/IEC 15504 (SPICE) describe los procesos que una
organizacin debe ejecutar para adquirir, proveer, desarrollar, operar, evolucionar y dar
soporte al software, y las prcticas genricas que caracterizan la capacidad de esos
procesos.
Cada proceso del modelo se describe en trminos de prcticas bsicas, que son las
actividades esenciales de un proceso especfico. El modelo clasifica los procesos en cinco
categoras que son:
Cliente-Proveedor
Ingeniera
Gestin de Proyectos
Soporte
Organizacin
Dentro de la categora Gestin de Proyectos entra el proceso relacionado con la medicin.

El propsito de este proceso, que se representa como MA.6, es recoger y analizar datos
relacionados con los productos desarrollados y los procesos implementados en la
organizacin y sus proyectos. Su objetivo principal es gestionar de forma efectiva los
procesos y demostrar de forma objetiva la calidad de los productos.
Las prcticas del proceso se presentan a continuacin:
BP1: Establecer el compromiso de la organizacin para medicin.

El compromiso de la Direccin y del personal se establece, mantiene y comunica a
la organizacin.
BP2: Desarrollar una estrategia de medicin.
56
Definir una estrategia apropiada para identificar, realizar y evaluar las actividades y
los resultados de medicin, basndose en las necesidades de informacin de la
organizacin.
BP3: Identificar las necesidades de informacin a medir.

Identificar las necesidades de los procesos organizacionales de informacin a medir.
BP4: Especificar medidas.

Identificar y desarrollar un conjunto de mtricas que correspondan a las necesidades
de informacin.
BP5: Recoger y almacenar datos de medicin.

Identificar, recoger y almacenar datos, incluyendo informacin contextual necesaria
para verificar, entender o evaluar los datos.
BP6: Analizar los datos medidos.

Analizar e interpretar los datos medidos y desarrollar productos informativos.
BP7: Utilizar los productos de informacin medida para tomar decisiones.

Hacer los productos informativos accesibles para todos los procesos de toma de
decisiones para los que la informacin sea relevante.
BP8: Comunicar los resultados de medicin.

Difundir los productos informativos a todas las personas que los van a utilizar y
recoger comentarios para evaluar si estn adecuados para su uso previsto.
BP9: Evaluar y comunicar los productos informativos y las actividades de medicin a

los propietarios de los procesos.
Evaluar los productos informativos y las actividades de medicin contra las necesidades de
informacin y la estrategia de medicin, identificar mejoras potenciales en las mediciones y
comunicar cualquier mejora potencial de los procesos a sus propietarios.
La medicin es una actividad que est presente en las prcticas genricas que determinan
el nivel de capacidad de un proceso. As, tenemos que:
57
En el nivel 2 de capacidad: Planificado y Controlado, dentro de la caracterstica comn 2.4:

Control de la ejecucin, se encuentra la prctica genrica:
Control con mediciones, cuyo propsito es controlar el estado del progreso contra el
plan usando mediciones. El uso de mediciones implica que stas han sido definidas
y seleccionadas y que los datos han sido recogidos.
En el nivel 4 de capacidad: Controlado Cuantitativamente, dentro de la caracterstica comn

4.1: Establecer unas metas de calidad medibles, se encuentra la prctica genrica:
Establecer metas de calidad, cuyo propsito es establecer unas metas de calidad

medibles para los productos/entregables generados por los procesos estndar de la
organizacin. Estas metas de calidad deben estar alineadas con las metas
estratgicas de calidad de la organizacin, las necesidades particulares y prioridades
del cliente y las necesidades tcticas del proyecto.
En el nivel 5 de capacidad: Mejora Continua, dentro de la caracterstica comn 5.1: Mejorar

la capacidad de la organizacin, se encuentra la prctica genrica:
Establecer metas de efectividad de proceso, cuyo propsito es establecer metas

cuantitativas para mejorar la efectividad de los procesos estndar de la organizacin,
basadas en las metas de negocio de la organizacin y la capacidad actual de los
procesos.
58
Escenario de clausura
El director se rene con el jefe de proyecto antes de que ste comience con el proyecto.
Figura 22. Escenario de clausura I
El jefe de proyecto informa al director sobre lo que ha planificado para conocer su opinin.
Le dice que ha pensado que, al ser un proyecto pequeo y al no estar avanzados en el
campo de la medicin, seleccionar un nmero limitado de mtricas tiles en su proyecto.
59
Figura 23. Escenario de clausura II
Figura 24. Escenario de clausura III
60
Enlaces
Pgina
oficial
de
PSM
(Practical
Software
and
Systems
Measurement):
http://www.psmsc.com/
Pasos para implementar un programa exitoso de medicin, Implementing a Successful
Measurement
Program:
Tried
and
True
Practices
and
Tools:
http://www.psmsc.com/Downloads/Other/Implementing_a_SuccessfulMeasurementProgram.
pdf
Tcnicas de mtricas de software: http://www.softwaremetrics.com/
61
Glosario
Atributo: Propiedad mensurable, fsica o abstracta que comparten todas las

entidades de una categora de entidad.
Concepto medible: El concepto medible es una percepcin sobre las entidades que
deberan ser medidas con el objetivo de satisfacer una determinada necesidad de
informacin.
Construccin de medicin: La construccin de medicin describe cmo los

atributos de software relevantes son cuantificados y convertidos en indicadores que
proporcionan una base para tomar decisiones.
Entidad: Objeto que va a ser caracterizado mediante una medicin de sus atributos
[ISO- 15939].
Mtrica: Una forma de medir y una escala, definidas para realizar mediciones de uno
o varios atributos.
Mtrica directa: Mtrica de la cual se pueden realizar mediciones sin depender de

ninguna otra mtrica.
Mtrica indirecta: Mtrica cuya forma de medir es una funcin de clculo, es decir,
las mediciones de dicha mtrica utilizan las medidas obtenidas en mediciones de
otras mtricas directas o indirectas.
Medida: Resultado de una medicin.
Necesidad de informacin: Las necesidades de informacin de una organizacin

pueden ser, por ejemplo, la informacin necesaria para gestionar un proyecto, es
decir, sus objetivos, hitos, riesgos y problemas.
Plan de medicin: Documento que recoge todas las necesidades de informacin,

las construcciones y los procedimientos de medicin.
Proceso de medicin: Un proceso de medicin combina distintos datos objetivos y

subjetivos en productos de informacin integrados que dirigen directamente las
necesidades de informacin del proyecto ya definidas.
62
Productos de informacin: Los productos de informacin son un conjunto de

indicadores, interpretaciones y recomendaciones proporcionadas a la persona
encargada de tomar la decisin como salida del proceso de medicin.
63

10 Curso de MediciÃ N y AnÃ¡lisis

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

10 Curso de MediciÃ N y AnÃ¡lisis

Cargado por

Copyright:

Formatos disponibles

CURSO DE MEDICIN Y

Laboratorio Nacional de Calidad del

Copyright 2009 Instituto Nacional de Tecnologas de la comunicacin (INTECO)

Curso de Medicin y Anlisis

CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la

Curso de Medicin y Anlisis

Mtricas directas y mtricas indirectas

2.4. Necesidad e importancia de la medicin

ACTIVIDADES DEL PROCESO DE MEDICIN Y ANLISIS

3.1. Identificar necesidades de informacin

3.2. Definir objetivos de medicin

3.3. Definir mtricas

3.4. Recoger, validar y almacenar mtricas

3.5. Analizar mtricas

2.2. La medicin como parte de las estimaciones

Aplicacin y ejemplos de los mtodos de anlisis

4.1. Mtricas en un proyecto software

Mtricas del progreso de los proyectos

4.2. Mtricas de la calidad de un proceso

4.3. Mtricas de calidad de producto

Curso de Medicin y Anlisis

Mtricas de calidad de producto final

Mtricas de mantenimiento de software

5.1. Lecciones aprendidas

6.2. ISO/IEC 15504

Curso de Medicin y Anlisis

Figura 1. Escenario de apertura I

Curso de Medicin y Anlisis

Figura 2. Escenario de apertura II

Figura 3. Escenario de apertura III

Curso de Medicin y Anlisis

Cuando puedes medir aquello de lo que ests hablando, y expresarlo en

Figura 4. La necesidad de la medicin en los proyectos

La ingeniera de software est madurando como disciplina de software y es importante darse

La medicin es un punto crtico en la disciplina de la ingeniera del software.

Curso de Medicin y Anlisis

En general, la medicin persigue los siguientes objetivos fundamentales:

Analizar: entender qu ocurre durante el desarrollo y el mantenimiento (los atributos

Controlar: controlar qu es lo que ocurre en nuestros proyectos (la calidad del

Predecir: realizar estimaciones (el tiempo y coste de un proyecto)

Mejorar: mejora los procesos y productos (la calidad de un producto, proceso )

Curso de Medicin y Anlisis

Figura 5. Estimaciones sin medicin

Sin embargo no podemos permitirnos ser poco estrictos y relajarnos en el campo de la

La medicin como parte de las estimaciones

Curso de Medicin y Anlisis

Qu tipo de errores ocurren ms a menudo y por qu?

Por qu la calidad del producto es menor?

Por qu los proyectos siempre van con retraso?

la organizacin no ha trabajado con proyectos de caractersticas similares al

anlisis de datos histricos

modelos disponibles que se han basado en datos de la industria

Curso de Medicin y Anlisis

Figura 6. Modelos de estimacin

Curso de Medicin y Anlisis

Mtricas directas y mtricas indirectas

Por ejemplo, para conocer el tamao de un programa se pueden contar el

La satisfaccin del cliente, por ejemplo, no es un atributo que pueda medirse

Necesidad de informacin: Las necesidades de informacin de una organizacin

Curso de Medicin y Anlisis

proporcionar resultados objetivos que sean tiles para la toma de decisiones y

Procesos: Son actividades software que normalmente conllevan el factor

Productos: Son entregables, artefactos o documentos generados en el ciclo