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/ 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.
en
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. 2. ESCENARIO DE APERTURA INTRODUCCIN
2.1.1.
6 8
Contexto de la medicin
2.2. La medicin como parte de las estimaciones 2.3. Conceptos

2.3.1. 2.3.2. 2.3.3.
10 12
12 13 13
Mtricas y medidas Mtricas directas y mtricas indirectas Otros conceptos
2.4. Necesidad e importancia de la medicin

2.4.1.
15
17
Beneficios de la medicin
3.
ACTIVIDADES DEL PROCESO DE MEDICIN Y ANLISIS

3.1. Identificar necesidades de informacin 3.2. Definir objetivos de medicin 3.3. Definir mtricas
3.3.1.
19 19 21 23
25
Plan de medicin
3.4. Recoger, validar y almacenar mtricas

3.4.1. 3.4.2. 3.4.3.
27
28 29 30
Recoger Validar Almacenar
3.5. Analizar mtricas

3.5.1. 3.5.2.
31
32 34
Mtodos de anlisis Aplicacin y ejemplos de los mtodos de anlisis
4.
MTRICAS
4.1. Mtricas en un proyecto software
4.1.1. 4.1.2.
38 38
40 41 Mtricas del progreso de los proyectos Mtricas de recursos
4.2. Mtricas de la calidad de un proceso

4.2.1.
42
43
La productividad
4.3. Mtricas de calidad de producto

4.3.1.
45
47
Mtricas de calidad de producto final
4.3.2.
Mtricas de mantenimiento de software
48
5.
BUENAS PRCTICAS
5.1. Lecciones aprendidas
49 52 54 54 56 59 61 62
6.
ENFOQUE MODELOS
6.1. CMMI 6.2. ISO/IEC 15504
7. 8. 9.
ESCENARIO DE CLAUSURA ENLACES GLOSARIO
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 Se asocia a un concepto medible. Se satisface con uno o ms indicadores. Ejemplos Evaluar si un producto SW satisface las expectativas del cliente. Entidad Una entidad puede pertenecer a una o ms entidades. Una medicin se realiza sobre los atributos de una Un programa holamundo
14
entidad. Categora entidad de Una categora puede incluir a una o varias categoras de entidades. Tiene uno o varios atributos Atributo Solo puede pertenecer a una categora de entidad. Una medicin se realiza sobre los atributos de una entidad. Est relacionado con uno o ms conceptos medibles. Concepto medible Se asocia a una o varias necesidades de Adecuacin relacin de tecnolgica, productividad Procesos, servicios, proyectos, recursos, programas en C, componentes software
Tamao de cdigo fuente podra ser atributo de de la
categora
entidad
programas en C.
informacin. Puede incluir otros conceptos medibles. Relaciona uno o ms atributos.
equipo de desarrollo respecto al objetivo.
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
Ejecutado dentro del Presupuesto
Completado dentro del Cronograma
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 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 proyectos. Mejorar la posicin de la empresa en el mercado. Conocer cul es la probabilidad de alcanzar ese compromiso. Saber si estamos en el camino correcto para conseguir los compromisos. Saber si estamos consiguiendo los compromisos de manera efectiva en costes. Saber si hemos mejorado. 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. A nivel de organizacin
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 Ejemplos aplicaciones 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 o
Herramienta
Propsito
Caractersticas
Checklist
Ayudar en la recogida y organizacin de datos para facilitar su consulta en el futuro.
No son largas Basadas en la experiencia revisadas y actualizadas de forma peridica
Diagrama de Pareto
Ayuda a identificar las reas que producen la mayora de los problemas
Eje X es la causa del defecto Eje Y es el nmero de defectos
Histograma
Mostrar las caractersticas de distribucin de un parmetro (tendencia central, dispersin y asimetra)
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
Diagrama de dispersin
Identificar potencial variables
una relacin entre dos
Para presentar el coeficiente de correlacin entre dos variables
Grfico de ejecucin
Registra el rendimiento de un parmetro de inters a lo largo del tiempo
Eje X es el tiempo Eje Y es parmetro el valor del
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) -un par de lmites de control (a veces tambin un par de lmites de peligro dentro de los lmites de control) -valores del parmetro de inters trazados en el grfico, que representan el estado de un proceso Fin Eje horizontal (espina central): asunto a analizar Son tiles en la mejora de procesos software. Se pueden utilizar como herramientas para mejorar la consistencia y estabilidad.
Anlisis de las diferentes causas que ocasionan los problemas facilitando los Diagrama de causa-efecto estudios posteriores de
Lneas o flechas inclinadas que llegan al eje principal: grupos de causas primarias en que se clasifican las causas del problema. A las flechas inclinadas Concentrar el
esfuerzo del equipo en la resolucin de problemas complejos.
evaluacin del grado de aporte de cada una de estas causas.
llegan otras menores que 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
Distribucin de defectos por nivel de severidad

100 90 80 70 60 50 40 30 20 10 0
Severidad 1 Severidad 2 1
% Defectos
Severidad3Severidad4
Figura 15. Ejemplo histograma
Diagrama de dispersin
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 Firmas
C - Completo
E - En-progreso Fecha de entrega
S - Suspendido
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 medicin y anlisis
Buenas prcticas
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 medicin objetivos 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
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
almacenar mtricas
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 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.2 Especificar mediciones SP1.3 Especificar procedimientos de
recogida y almacenamiento de datos SP1.4 anlisis SP2.1 Recolectar datos para las Especificar procedimientos de
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 Especificar Procedimientos de Recogida y Almacenamiento de Datos
Establecer Objetivos de Medicin
Especificar Mediciones
Especificar Procedimientos de Anlisis
Objetivos de Medicin
Resultados de Medicin
Repositorio de Mediciones
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

Curso de Medición y Análisis

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Curso de Medición y Análisis

Transféré par

Droits d'auteur :

Formats disponibles

CURSO DE MEDICIN Y ANLISIS

Laboratorio Nacional de Calidad del Software

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

Curso de Medicin y Anlisis

Curso de Medicin y Anlisis

2.2. La medicin como parte de las estimaciones 2.3. Conceptos

Mtricas y medidas Mtricas directas y mtricas indirectas Otros conceptos

2.4. Necesidad e importancia de la medicin

ACTIVIDADES DEL PROCESO DE MEDICIN Y ANLISIS

3.4. Recoger, validar y almacenar mtricas

Recoger Validar Almacenar

3.5. Analizar mtricas

Mtodos de anlisis Aplicacin y ejemplos de los mtodos de anlisis

4.2. Mtricas de la calidad de un proceso

4.3. Mtricas de calidad de producto

Mtricas de calidad de producto final

Curso de Medicin y Anlisis

Mtricas de mantenimiento de software

ESCENARIO DE CLAUSURA ENLACES GLOSARIO

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

Figura 4. La necesidad de la medicin en los proyectos

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 de un ente)

Curso de Medicin y Anlisis

Figura 5. Estimaciones sin medicin

La medicin como parte de las estimaciones

Curso de Medicin y Anlisis

Curso de Medicin y Anlisis

Figura 6. Modelos de estimacin

Curso de Medicin y Anlisis

Mtricas directas y mtricas indirectas

Curso de Medicin y Anlisis

La siguiente tabla recoge la relacin entre los conceptos anteriormente definidos:

Curso de Medicin y Anlisis

Tamao de cdigo fuente podra ser atributo de de la

informacin. Puede incluir otros conceptos medibles. Relaciona uno o ms atributos.

equipo de desarrollo respecto al objetivo.

Necesidad e importancia de la medicin

Curso de Medicin y Anlisis

Ejecutado dentro del Presupuesto

Completado dentro del Cronograma

Figura 7. Factores clave en el xito de un proyecto software

Los jefes de proyectos de software se encargan de asegurar:

que el proyecto es controlado y monitorizado para conseguir esos objetivos.

Curso de Medicin y Anlisis

Figura 8. La medicin para monitorizar y controlar los proyectos

Curso de Medicin y Anlisis

Curso de Medicin y Anlisis

Actividades del proceso de medicin y anlisis

Identificar necesidades de informacin

Curso de Medicin y Anlisis

Curso de Medicin y Anlisis

Definir objetivos de medicin

Curso de Medicin y Anlisis

Figura 10. Niveles de una construccin de medida

Curso de Medicin y Anlisis

El siguiente grfico representa los conceptos clave dentro de la construccin de mtricas: