LAS MÉTRICAS

provocando con esto un cambio cultural en los desarrolladores mexicanos de software.. 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. y estableciendo la necesidad de un enfoque más disciplinado y de una alta calidad. reusabilidad. puesto que la mayoría de estos no cuentan con una educación formal sobre la medición. llevando consigo puntos débiles (aumento de esfuerzo. es por eso que sé están implantando en la actualidad. estimación. PF.. y también se dirá del porque se decidió realizar un manual y un tutorial accesible en Web..INTRODUCCIÓN • Se sabe (o conoce) que algunas de las actividades de desarrollo del proyecto de software comprenden medición y métricas.) que están experimentado los ingenieros y administradores de software. El recopilar datos (investigación histórica). . seguimiento y control. planificación del programa. 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. madurez. análisis de riesgo. calcular métricas (LDC.) y evaluar métricas.) y fuertes (alta calidad. están reconociendo la importancia del uso de las métricas. • Hoy día es cada vez más frecuente la consideración de métricas de software. orientadas a objetos.. métricas de calidad. 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. Así muchos particulares y compañías desarrolladoras de software. son algunos de los pasos que se deben realizarse al comenzar un producto. etc.

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. mejorar y clasificar al software final. . aunque estas tres son distintas. componente o proceso posee un atributo dado”. en donde serán manejadas dependiendo del entorno de desarrollo del software al cual pretendan orientarse. porque es muy común asociarla con las palabras medición y medida. dimensiones. capacidad y tamaño de algunos atributos de un proceso o producto”. cantidad. existen distintos tipos de métricas para poder evaluar. 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.

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.1. 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”. .

y (3) ayudaran en el diseño de pruebas más efectivas. Es por eso que propone un proceso de medición. que. . (2) en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente. según Pressman [‟98] van a ayudar a la (1) evaluación de los modelos de análisis y de diseño.Las métricas son la maduración de una disciplina. • Colección: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. • Análisis: El cálculo de las métricas y la aplicación de herramientas matemáticas. • 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. 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. • Realimentación: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software.

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 .

tamaño. acoplamiento del módulo. • 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. análisis. configuración. Tales como volumen. etc. reusabilidad. A continuación se muestra una breve clasificación de métricas de software. a pesar de la intensa investigación académica. estructuración o modularidad. viabilidad.1. descritas por Lem O. Tales como exactitud. . No se ha alcanzado mucho en esta área. codificación. Estas son los puntos críticos en el diseño. cohesión del módulo. pruebas y mantenimiento.2 CLASIFICACIÓN DE MÉTRICAS • La clasificación de una métrica de software refleja o describe la conducta del software. anidaciones. rapidez. costo (estimación). y flujo. agregación. • Métricas de calidad: Son todas las métricas de software que definen de una u otra forma la calidad del software. mantenimiento. eficiencia y competencia. Estas son los puntos críticos de la concepción. 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. pruebas.

bajo la supervisión del sistema operativo o hardware. Existen pocas investigaciones dentro del área. etc. las limitaciones. facilidad de localización. identación. complejidad de algoritmos computacionales. • Variedad de métricas: tales como portabilidad. etc. consistencia. Pero estas no se deben confundir con las métricas de calidad o complejidad. • Métricas estilizadas: Son las métricas de experimentación y de preferencia. Generalmente tienen que ver con la eficiencia de ejecución. Estas clasificaciones de métricas fortalecen la idea. las convenciones denominando de datos. de que más de una métrica puede ser deseable para valorar la complejidad y la calidad del software. tiempo. Por ejemplo: estilo de código. almacenamiento.1.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. .

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

• 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. modelo de diseño o en la propia estructura del programa. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación. • 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). 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. . • Independiente del lenguaje de programación: las métricas deberían apoyarse en el modelo de análisis. • 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.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.

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. 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 . 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. Al mismo tiempo. Para lograr este objetivo.

• La métrica bang. Estas métricas son las siguientes: • Las métricas orientadas a la función.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. Y es por eso que se desea una visión interna a la calidad del modelo de análisis. • Las métricas de la calidad de especificación. 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.3. Sin embargo hay pocas métricas de análisis y especificación. .

no son perfectas.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. Aunque ninguna es perfecta.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.3. . como otras métricas. acoplamiento y complejidad del módulo. pueden proporcionarle al diseñador una mejor visión interna y así el diseño evolucionará a un mejor nivel de calidad.3 MÉTRICA DEL MODELO DEL DISEÑO (I) Las métricas para software. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de componentes. Sin embargo el diseño sin medición es una alternativa inaceptable.3. A continuación se mencionan algunas de las métricas de diseño más comunes.3. 3. 3. muchos expertos argumentan que se necesita más experimentación hasta que se puedan emplear bien las métricas de diseño.

ventanas y otras para ayudar al usuario a completar tareas. texto. 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. 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. Las posiciones absolutas y relativas de cada entidad de representación. .3 MÉTRICA DEL MODELO DEL DISEÑO (II) 3. el usuario debe moverse de una entidad de representación a otra. Sears sugiere la conveniencia de la representación (CR) como una valiosa métrica de diseño para interfaces hombre-máquina.3 Métricas de diseño de interfaz Aunque existe una significativa cantidad de literatura sobre el diseño de interfaces hombre-máquina.3. Una IGU (Interfaz Gráfica de Usuario) típica usa entidades de representación. Para realizar una tarea dada usando una IGU. iconos gráficos.

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.. • 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 ciencia software propuso las primeras „leyes‟ analíticas para el software de computadora. • La ciencia del software asigna leyes cuantitativas al desarrollo del software de computadora..3.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]. 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. Estas medidas se listan a continuación..

tiempo de desarrollo e incluso el número esperado de fallos en el software. . nivel del lenguaje (una constante para un lenguaje dado). el nivel del programa (una medida de la complejidad del software). y otras características tales como esfuerzo de desarrollo.3.4 MÉTRICAS DE CÓDIGO FUENTE (II) • Halstead usa las medidas primitivas para desarrollar expresiones para la longitud global del programa. 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 volumen real (número de bits requeridos para especificar un programa).

Usando la definición del volumen de un programa V. diseño y código para que les guíen en el diseño y ejecución los casos de prueba.3. el esfuerzo de la ciencia del software. El esfuerzo de las pruebas también se puede estimar usando métricas obtenidas de medidas de Halstead.5 MÉTRICAS PARA PRUEBAS Aunque se ha escrito mucho sobre métricas del software para pruebas. la mayoría de las métricas propuestas se concentran en el proceso de pruebas. En general. el analista debería invertir un esfuerzo extra para descubrir errores en el módulo antes de integrarlo en un sistema. y nivel de programa. los responsables de las pruebas deben fiarse del análisis. 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) . • Por esta razón. puede calcularse como. no en las características técnicas de las pruebas mismas. NP.

El estándar IEEE 982.0 el producto se empieza a estabilizar. .3.6 MÉTRICAS DE MANTENIMIENTO • Se han propuesto métricas diseñadas explícitamente para actividades de 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. 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.

Sign up to vote on this title
UsefulNot useful