LAS MÉTRICAS

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

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

. así el administrador junto con el empleo de estas técnicas mejorará el proceso y sus productos”.1. Las métricas de software proveen la información necesaria para la toma de decisiones técnicas.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.

que. 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. • 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. • Realimentación: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software. • 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. según Pressman [‟98] van a ayudar a la (1) evaluación de los modelos de análisis y de diseño. y (3) ayudaran en el diseño de pruebas más efectivas. (2) en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente.Las métricas son la maduración de una disciplina.

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 .

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

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

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. pero no todas proporcionan suficiente soporte práctico para su desarrollo. Algunas demandan mediciones que son demasiado complejas.1. otras son tan esotéricas que pocos profesionales tienen la esperanza de entenderlas.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.

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

1 Las Métricas y la Calidad de Software • El objetivo primordial de la ingeniería del software es producir un sistema. 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.CAPÍTULO 3 MÉTRICAS EN EL DESARROLLO DEL SOFTWARE 3. 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. los ingenieros de software deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software. aplicación o producto de alta calidad.

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.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. Sin embargo hay pocas métricas de análisis y especificación. . en donde resulte probable que el tamaño y la complejidad del diseño estén directamente relacionadas. Y es por eso que se desea una visión interna a la calidad del modelo de análisis. • La métrica bang. • 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.

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

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

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

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

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

0 el producto se empieza a estabilizar. 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.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 IMS puede emplearse también como métrica para la planificación de las actividades de mantenimiento del software.3. El estándar IEEE 982.6 MÉTRICAS DE MANTENIMIENTO • Se han propuesto métricas diseñadas explícitamente para actividades de mantenimiento. .

Sign up to vote on this title
UsefulNot useful