ENSAYO SOBRE LAS METRICAS

ENSAYO SOBRE LA IMPORTANCIA DE LAS MÉTRICAS EN

Métricas técnicas

Cualquier cosa que queramos medir o predecir en un software es un

atributo de cualquier entidad de un producto, proceso o recurso asociado a éste.

Cada entidad de software tiene varios atributos que pueden ser medidos. Es por

eso que se necesita hacer una distinción entre atributos que son internos o

externos y medidas directas e indirectas:

El Reto de las Métricas Técnicas

Muchos investigadores han intentado desarrollar una sola métrica que

facilite una medida completa de la complejidad del software. Aunque se han

presentado docenas de medidas de complejidad, cada una tiene un punto de vista

distinto de lo que es la complejidad y de qué atributos de un sistema llevan a la

complejidad. Comparemos con una métrica para evaluar un automóvil. Algunos

observadores podrían hacer énfasis en el diseño de la cabina, otros podrían hacer

hincapié en las características mecánicas, otros podrían considerar el precio, o el

rendimiento, o la economía de consumo o la capacidad de reutilizarlo cuando se

vaya a desechar. Como cualquiera de estas características puede competir con

las otras, es difícil obtener un solo valor del ‘atractivo’ del automóvil. Lo mismo

sucede con el software.

Reporte de la métrica

El siguiente paso es decidir como reportar la métrica. Esto incluye la definición del

formato del reporte, la obtención de los datos, mecanismos de reporte de

distribución y disponibilidad. El formato del reporte se diseña de acuerdo a lo que

se quiera dar a conocer, es por eso que se debe preguntar lo siguiente, ¿Está la

métrica incluida en una tabla con otras métricas para un periodo?, ¿Se añade

como último valor en una gráfica de tendencia que muestran los valores de la

métrica para varios periodos?. Esta gráfica de tendencia ¿Puede ser de barra,

línea o de área?, ¿Es mejor comparar valores empleando barras apiladas o

gráficas de pastel?. ¿Es mejor hacer tablas y gráficas solas o se agrega texto

detallado de análisis y se incluye en el reporte?, ¿Son metas o valores de control

los que se incluyen en el reporte?.

En el reporte de métricas, se deberá realizar cuatro pasos: ciclo de

obtención de datos, ciclo de reporte de datos, mecanismos de reporte, distribución

y disponibilidad que se describen a continuación:

El ciclo de obtención de datos define que a menudo la métrica requiere de

snap-shot(s) de los datos y en que momento los elementos de los datos están

disponibles para el cálculo de la métrica.

El ciclo de reporte define con que frecuencia el reporte es generado y

cuando se prepara para su distribución. Por ejemplo la razón principal de un

estudio de métricas puede ser por algún evento, como la terminación de una fase

en el proceso de desarrollo del software; Otras métricas como el promedio de

defectos reportados pueden obtenerse y reportarse diariamente durante las

26

pruebas del sistema, la obtención mensual de datos y el reporte mensual después

de la liberación del software.

Los mecanismos de reporte proyectan los mecanismos de entrega de las

métricas.

Al definir la distribución determina quienes reciben copias del reporte o

tienen acceso a la métrica. También aquí se define cualquier restricción al acceso

de la métrica, mecanismos de aprobación para añadir y eliminar accesos y

cambios en la distribución normal.

Mediciones del software

Para medir algo se necesita saber que entidades serán medidas y tener

una idea de los atributos (propiedades) de la entidad. Primero se debe identificar

un atributo y su significado de medición, podemos empezar acumulando datos.

Analizando los resultados de estos procesos normalmente permite la clarificación

y la re-valuación de los atributos.

Métricas Orientadas al Tamaño

Las métricas del software orientadas al tamaño provienen de la

normalización de las medidas de calidad y/o productividad considerando el

“tamaño” del software que se haya producido. Si una organización de software

mantiene registros sencillos, se puede crear una tabla de datos orientados al

tamaño, como la que muestra la figura 3.1, (Pressman ´98) que lista cada proyecto

de desarrollo de software y las medidas correspondientes de cada proyecto.

Refiriéndonos a la entrada de la figura 3.1 del proyecto alfa: se desarrollaron

12,100 líneas de código(LDC) con 24 personas-mes y con un costo de $168,000

dólares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla

incluyen todas las actividades de ingeniería del software (análisis, diseño,

codificación y prueba) y no sólo la codificación. Otra información sobre el proyecto

alfa indica que se desarrollaron 365 páginas de documentación, se registraron 134

errores antes de que el software se entregara al cliente y se encontraron 29

errores después de entregárselo al cliente dentro del primer año de utilización.

También sabemos que trabajaron tres personas en el desarrollo del proyecto alfa.

Figura 3.1 Tabla de datos orientados al tamaño [Pressman ‘98]

31

Para desarrollar métricas que se puedan comparar entre distintos proyectos, se

seleccionan las líneas de código como valor de normalización. Con los

elementales datos contenidos en la tabla se puede desarrollar para cada proyecto

un conjunto de métricas simples orientadas al tamaño, tales como:

•errores por KLDC (miles de líneas de código, KiloLDC)

•defectos por KLDC

•$ por LDC

•páginas de documentación por KLDC

Además, se pueden calcular otras métricas interesantes:

•Productividad = KLDC/ persona-mes

•Calidad = errores / KLDC

•Documentación = páginas de documentación / KLDC

Las métricas orientadas al tamaño no están aceptadas universalmente

como el mejor modo de medir el proceso de desarrollo del software La mayor

parte de la discusión gira en torno al uso de las líneas de código mostradas en la

tabla 3.2 (LDC) como medida clave. Los defensores de la medida LDC afirman

que la LDC es un “artificio” que se puede calcular fácilmente para todos los

proyectos de desarrollo de software, que muchos modelos de estimación del

software existente utilizan LDC o KLDC como clave de entrada. En el lado opuesto

los ofensores defienden que las medidas en LDC son dependientes del lenguaje

de programación, que perjudican a los programas más cortos, pero bien

32

diseñados, que no pueden acomodar fácilmente lenguajes procedimentales, y que

su uso en estimación requiere un nivel de detalle que pude resultar difícil de

alcanzar (es decir, el planificador debe estimar las LDC a producirse mucho antes

de que se complete el análisis y el diseño)

*ya que la teconología continuamente esta cambiando necesitamos establecer parámetros o técnicas q como desarrolladores de software nos ayuden a tener un orden y una estimación de cuanto tiempo, recursos, personal y costos son necesarios para realizar un proyecto con éxito

*espero q te sirva

3.6.2 Métricas Orientadas a la Función

Utilizan una medida de la funcionalidad; ésta no se puede medir

directamente, se debe derivar indirectamente por medio de medidas directas. Las

primeras fueron propuestas por Albrecht, que sugirió una medida llamada “Punto

de Función” para un sistema de software, la idea es que examinemos una

especificación del sistema, estas se derivan con una relación empírica según las

medidas contables (directas) del dominio de información del software y las

evaluaciones de la complejidad de software. [Charles R. Symons, ‘98]

El tamaño de la tarea de diseño y desarrollo de un sistema de computo es

determinado por el producto de tres factores mostrados en la figura 3.2.

PUNTOS POR FUNCION

Una métrica estándar para establecer el tamaño de software

La sociedad moderna cada vez se ha tornado más dependiente del software, pues se ha convertido en el bien de nuestra era; un bien al que cada vez se le invierte más en las empresas o instituciones, en su búsqueda por ofrecer más y mejores servicios, o simplemente por reducir costos operativos y se hace muy importante poder controlarlo. Es un bien intangible que se ha tornado difícil medir, el medir el software no es un tema académico, sino un tema de valor, de inversión, de negocio y que las organizaciones necesitan controlar en dichos temas.

Lo más importante es la funcionalidad. Como en cualquier inversión, a las empresas lo que les interesa es la capacidad de hacer algo con lo que compran al adquirir un paquete o al desarrollar una aplicación, lo primero que debe evaluarse es qué nuevas capacidades estoy adquiriendo. Estas capacidades o funcionalidad estarán en términos de qué transacciones puedo realizar de forma automatizada y qué grupos de datos puedo guardar.

Para

...