LAS MÉTRICAS

provocando con esto un cambio cultural en los desarrolladores mexicanos de software.. madurez. están reconociendo la importancia del uso de las métricas. PF. estimación. orientadas a objetos. y también se dirá del porque se decidió realizar un manual y un tutorial accesible en Web. El uso de éstas se ha adoptado con éxito en el amplio mercado de desarrollo de software introduciendo reconocimientos y consideraciones por parte de administradores y usuarios. planificación del programa.. análisis de riesgo. puesto que la mayoría de estos no cuentan con una educación formal sobre la medición.) que están experimentado los ingenieros y administradores de software. métricas de calidad. • Hoy día es cada vez más frecuente la consideración de métricas de software. aunque de igual modo siguen sin conocer el alcance de madurez y calidad del producto final y la disciplina de ingeniería madura que llega a alcanzar con la aplicación de los distintos métodos y técnicas y la interpretación de los resultados que proyecta el uso de las métricas. etc.) y evaluar métricas. . Es por eso que a continuación se dará a conocer el propósito esencial de la investigación de las distintas métricas existentes (públicas) y el uso de las mismas... calcular métricas (LDC. y estableciendo la necesidad de un enfoque más disciplinado y de una alta calidad.INTRODUCCIÓN • Se sabe (o conoce) que algunas de las actividades de desarrollo del proyecto de software comprenden medición y métricas. Así muchos particulares y compañías desarrolladoras de software. llevando consigo puntos débiles (aumento de esfuerzo. reusabilidad. El recopilar datos (investigación histórica). seguimiento y control.) y fuertes (alta calidad. son algunos de los pasos que se deben realizarse al comenzar un producto. es por eso que sé están implantando en la actualidad.

existen distintos tipos de métricas para poder evaluar. mejorar y clasificar al software final. . cantidad. componente o proceso posee un atributo dado”. capacidad y tamaño de algunos atributos de un proceso o producto”.CAPITULO I CONCEPTOS BÁSICOS DE MÉTRICAS • Empezaremos por definir los posibles términos que se encuentran encerrados en la palabra métrica. • El IEEE “Standard Glosary of Software Engering Terms” define métrica como “una medida cuantitativa del grado en que un sistema. aunque estas tres son distintas. porque es muy común asociarla con las palabras medición y medida. La medición “es el proceso por el cual los números o símbolos son asignados a atributos o entidades en el mundo real tal como son descritos de acuerdo a reglas claramente definidas” Una medida “proporciona una indicación cuantitativa de extensión. en donde serán manejadas dependiendo del entorno de desarrollo del software al cual pretendan orientarse. dimensiones.

1. .1 ¿QUÉ SON LAS MÉTRICAS DE SOFTWARE? Michael [„99] define las métricas de software como “La aplicación continua de mediciones basadas en técnicas para el proceso de desarrollo del software y sus productos para suministrar información relevante a tiempo. Las métricas de software proveen la información necesaria para la toma de decisiones técnicas. así el administrador junto con el empleo de estas técnicas mejorará el proceso y sus productos”.

• Realimentación: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software. y (3) ayudaran en el diseño de pruebas más efectivas. según Pressman [‟98] van a ayudar a la (1) evaluación de los modelos de análisis y de diseño. (2) en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente. • Interpretación: La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación. • Colección: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. Es por eso que propone un proceso de medición. el cual se puede caracterizar por cinco actividades: • Formulación: La obtención de medidas y métricas del software apropiadas para la representación de software en cuestión. . • Análisis: El cálculo de las métricas y la aplicación de herramientas matemáticas.Las métricas son la maduración de una disciplina. que.

Las métricas de software incluyen otras varias actividades. tales como: • Estimación de costo y el esfuerzo • Medición de la productividad • Acumulación de datos • Realización de modelos y mediciones de la calidad • Elaboración de modelos de seguridad • Evaluación y modelos de desempeño • Valoración de las capacidades y de la madurez • Administración por métricas • Evaluación del método y herramientas .

costo (estimación). Tales como exactitud. Estas son los puntos críticos de la concepción. etc. pruebas y mantenimiento. análisis. reusabilidad. rapidez. No se ha alcanzado mucho en esta área. codificación. Estas son los puntos críticos en el diseño. • Métricas de competencia: Son todas las métricas que intentan valorar o medir las actividades de productividad de los programadores o practicantes con respecto a su certeza. y flujo. a pesar de la intensa investigación académica. eficiencia y competencia. Ejiogu [„91]: • Métricas de complejidad: Son todas las métricas de software que definen de una u otra forma la medición de la complejidad. y diseño de software.1. • Métricas de calidad: Son todas las métricas de software que definen de una u otra forma la calidad del software. agregación. pruebas.2 CLASIFICACIÓN DE MÉTRICAS • La clasificación de una métrica de software refleja o describe la conducta del software. estructuración o modularidad. . Tales como volumen. acoplamiento del módulo. anidaciones. configuración. tamaño. mantenimiento. cohesión del módulo. viabilidad. A continuación se muestra una breve clasificación de métricas de software. descritas por Lem O.

Generalmente tienen que ver con la eficiencia de ejecución. de que más de una métrica puede ser deseable para valorar la complejidad y la calidad del software.2 CLASIFICACIÓN DE MÉTRICAS • Métricas de desempeño: Corresponden a las métricas que miden la conducta de módulos y sistemas de un software. Por ejemplo: estilo de código. tiempo. Pero estas no se deben confundir con las métricas de calidad o complejidad. facilidad de localización. consistencia. Estas clasificaciones de métricas fortalecen la idea. bajo la supervisión del sistema operativo o hardware. etc. identación. etc. • Variedad de métricas: tales como portabilidad.1. . almacenamiento. • Métricas estilizadas: Son las métricas de experimentación y de preferencia. las convenciones denominando de datos. las limitaciones. Existen pocas investigaciones dentro del área. complejidad de algoritmos computacionales.

Algunas demandan mediciones que son demasiado complejas.1. otras son tan esotéricas que pocos profesionales tienen la esperanza de entenderlas. pero no todas proporcionan suficiente soporte práctico para su desarrollo. por lo tanto la métrica obtenida y las medidas que conducen a ello deben cumplir con las siguientes características fundamentales: . y otras violan las nociones básicas intuitivas de lo que realmente es el software de alta calidad.3 DIFERENTES ENFOQUES DE MÉTRICAS Se han propuesto cientos de métricas para el software. Es por eso que se han definido una serie de atributos que deben acompañar a las métricas efectivas de software.

• Empírica e intuitivamente persuasiva: la métrica debería satisfacer las nociones intuitivas del ingeniero de software sobre el atributo del producto en cuestión (por ejemplo: una métrica que mide la cohesión de un módulo debería aumentar su valor a medida que crece el nivel de cohesión). • Consistente en el empleo de unidades y tamaños: el cálculo matemático de la métrica debería utilizar medidas que no lleven a extrañas combinaciones de unidades. multiplicando el número de personas de un equipo por las variables del lenguaje de programación en el programa resulta una sospechosa mezcla de unidades que no son intuitivamente concluyentes. modelo de diseño o en la propia estructura del programa.CARACTERÍSTICAS FUNDAMENTALES DE LAS MÉTRICAS • Simple y fácil de calcular: debería ser relativamente fácil de aprender a obtener la métrica y su cálculo no obligara a un esfuerzo o a una cantidad de tiempo inusuales. . • Un mecanismo eficaz para la realimentación de calidad: la métrica debería suministrar al desarrollador de software información que le lleve a un producto final de superior calidad. Por ejemplo. • Independiente del lenguaje de programación: las métricas deberían apoyarse en el modelo de análisis. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación.

A continuación se verá un conjunto de métricas del software que pueden emplearse a la valoración cuantitativa de la calidad de software . Para lograr este objetivo. Al mismo tiempo.1 Las Métricas y la Calidad de Software • El objetivo primordial de la ingeniería del software es producir un sistema.CAPÍTULO 3 MÉTRICAS EN EL DESARROLLO DEL SOFTWARE 3. un buen ingeniero del software y buenos administradores de la ingeniería del software deben medir si la alta calidad se va a llevar a cabo. aplicación o producto de alta calidad. los ingenieros de software deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software.

en donde las métricas examinan el modelo de análisis con el fin de predecir el tamaño del sistema resultante. . en donde resulte probable que el tamaño y la complejidad del diseño estén directamente relacionadas. • Las métricas de la calidad de especificación. Y es por eso que se desea una visión interna a la calidad del modelo de análisis. Sin embargo hay pocas métricas de análisis y especificación.3. • La métrica bang.2 MÉTRICAS DEL MODELO DE ANÁLISIS En esta fase se obtendrán los requisitos y se establecerá el fundamento para el diseño. se sabe que es posible adaptar métricas obtenidas para la aplicación de un proyecto. Estas métricas son las siguientes: • Las métricas orientadas a la función.

3. Aunque ninguna es perfecta. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de componentes. como otras métricas.3. muchos expertos argumentan que se necesita más experimentación hasta que se puedan emplear bien las métricas de diseño.1 Métricas de diseño de alto nivel Éstas se concentran en las características de la estructura del programa dándole énfasis a la estructura arquitectónica y en la eficiencia de los módulos. Sin embargo el diseño sin medición es una alternativa inaceptable. acoplamiento y complejidad del módulo. . A continuación se mencionan algunas de las métricas de diseño más comunes.3 MÉTRICA DEL MODELO DEL DISEÑO (I) Las métricas para software. 3. pueden proporcionarle al diseñador una mejor visión interna y así el diseño evolucionará a un mejor nivel de calidad. 3.2 Métricas de diseño en los componentes Las métricas de diseño a nivel de componentes se concentran en las características internas de los componentes del software e incluyen medidas de la cohesión. no son perfectas.3.

. Una IGU (Interfaz Gráfica de Usuario) típica usa entidades de representación. Sears sugiere la conveniencia de la representación (CR) como una valiosa métrica de diseño para interfaces hombre-máquina. la frecuencia con que se utilizan y el “costo” de la transición de una entidad de representación a la siguiente contribuirán a la conveniencia de la interfaz. ventanas y otras para ayudar al usuario a completar tareas. Para realizar una tarea dada usando una IGU. texto. Las posiciones absolutas y relativas de cada entidad de representación.3.3 Métricas de diseño de interfaz Aunque existe una significativa cantidad de literatura sobre el diseño de interfaces hombre-máquina. se ha publicado relativamente poca información sobre métricas que proporcionen una visión interna de la calidad y facilidad de empleo de la interfaz. menús.3 MÉTRICA DEL MODELO DEL DISEÑO (II) 3. iconos gráficos. el usuario debe moverse de una entidad de representación a otra.3.

.. • n1: el número de operadores diferentes que aparecen en el programa n2: el número de operandos diferentes que aparecen en el programa • N1: el número total de veces que aparece el operador • N2: el número total de veces que aparece el operando . La teoría de Halstead se obtiene de un supuesto fundamental: „el cerebro humano sigue un conjunto de reglas más rígido (en el desarrollo de algoritmos) de lo que se imagina. • La ciencia del software asigna leyes cuantitativas al desarrollo del software de computadora. Estas medidas se listan a continuación.‟.3. La ciencia software propuso las primeras „leyes‟ analíticas para el software de computadora. La ciencia del software usa un conjunto de medidas primitivas que pueden obtenerse una vez que se ha generado o estimado el código después de completar el diseño.4 MÉTRICAS DE CÓDIGO FUENTE (I) • La teoría de Halstead de la ciencia del software es „probablemente la mejor conocida y más minuciosamente estudiada. medidas compuestas de la complejidad (software)‟ [Ejiogo „91]...

nivel del lenguaje (una constante para un lenguaje dado). volumen mínimo potencial para un algoritmo. Halstead expone que la longitud N se puede estimar como: N = n1 log2 n1 + n2 log2 n2 y el volumen de programa se puede definir como: V = N log2 (n1 + n2) Se debería tener en cuenta que V variará con el lenguaje de programación y representa el volumen de información. el nivel del programa (una medida de la complejidad del software).3. el volumen real (número de bits requeridos para especificar un programa).4 MÉTRICAS DE CÓDIGO FUENTE (II) • Halstead usa las medidas primitivas para desarrollar expresiones para la longitud global del programa. y otras características tales como esfuerzo de desarrollo. . tiempo de desarrollo e incluso el número esperado de fallos en el software.

3. el analista debería invertir un esfuerzo extra para descubrir errores en el módulo antes de integrarlo en un sistema. NP=1 / [(n1 / 2) * (N2 / n2)] e = V / NP El porcentaje del esfuerzo global de pruebas a asignar un módulo k para estimar usando la siguiente relación: porcentaje de esfuerzo de pruebas (k) = e(k)/ Óe(i) . puede calcularse como. En general. Usando la definición del volumen de un programa V. y nivel de programa. • Por esta razón. no en las características técnicas de las pruebas mismas. los responsables de las pruebas deben fiarse del análisis. diseño y código para que les guíen en el diseño y ejecución los casos de prueba. NP. el esfuerzo de la ciencia del software.5 MÉTRICAS PARA PRUEBAS Aunque se ha escrito mucho sobre métricas del software para pruebas. El esfuerzo de las pruebas también se puede estimar usando métricas obtenidas de medidas de Halstead. la mayoría de las métricas propuestas se concentran en el proceso de pruebas.

3.6 MÉTRICAS DE MANTENIMIENTO • Se han propuesto métricas diseñadas explícitamente para actividades de mantenimiento. .0 el producto se empieza a estabilizar. El estándar IEEE 982. El tiempo medio para producir una versión de un producto software puede correlacionarse con el IMS desarrollándose modelos empíricos para el mantenimiento. El IMS puede emplearse también como métrica para la planificación de las actividades de mantenimiento del software.1-1988 sugiere un índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto de software (basada en los cambios que ocurren con cada versión del producto) Se determina la siguiente información: • Mr = número de módulos en la versión actual • Fc = número de módulos en la versión actual que se han cambiado • Fa = número de módulos en la versión actual que se han añadido • Fd = número de módulos de la versión anterior que se han borrado en la versión actual El índice de madurez del software se calcula de la siguiente manera: IMS = [Mr – (Fa + Fc + Fd)]/ Mr ( • A medida que el IMS se aproxima a 1.