Mtricas Apropiadas
Indique cules son las mtricas apropiadas para el proceso y para
el producto; y elabore un ejemplo donde se empleen ambas
En la mayora de los desafos tcnicos, las mtricas nos ayudan a
entender tanto el proceso tcnico que se utiliza para desarrollar un
producto, como el propio producto. El proceso para intentar
mejorarlo, el producto se mide para intentar aumentar su
calidad.
El principio, podra parecer que la necesidad de la medicin es
algo evidente. Despus de todo es lo que nos permite cuantificar y
por consiguiente gestionar de forma ms efectiva. Pero la realidad
puede ser muy diferente. Frecuentemente la medicin conlleva una
gran controversia y discusin.
Cules son las mtricas apropiadas para el proceso y para el
producto?
Respuesta: Hay varias razones para medir un producto:
1. Para indicar la calidad del producto.2. Para evaluar la
productividad de la gente que desarrolla el producto.3. Par evaluar
los beneficios en trminos de productividad y de calidad, derivados
del uso de nuevos mtodos y herramientas de la ingeniera de
software.4. Para establecer una lnea de base para la estimacin5.
Para ayudar a justificar el uso de nuevas herramientas o de
formacin adicional.
Las mediciones del mundo fsico pueden englobarse en dos
categoras: medidas directas y medidas indirectas.
Medidas Directas: En el proceso de ingeniera se encuentran el
costo, y el esfuerzo aplicado, las lneas de cdigo producidas,
velocidad de ejecucin, el tamao de memoria y los defectos
observados en un determinado periodo de tiempo.
Medidas Indirectas: Se encuentra la funcionalidad, calidad,
complejidad, eficiencia, fiabilidad, facilidad de mantenimiento,
etc.
A. MTRICAS DEL SOFTWARE: Son las que estn relacionadas con el
desarrollo del software como funcionalidad, complejidad,
eficiencia.
B. MTRICAS TCNICAS: Se centran en las caractersticas de software
por ejemplo: la complejidad lgica, el grado de modularidad. Mide la
estructura del sistema, el cmo est hecho.
C. MTRICAS DE CALIDAD: proporcionan una indicacin de cmo se
ajusta el software a los requisitos implcitos y explcitos del
cliente. Es decir cmo voy a medir para que mi sistema se adapte a
los requisitos que me pide el cliente.
D. MTRICAS DE PRODUCTIVIDAD: Se centran en el rendimiento del
proceso de la ingeniera del software. Es decir que tan productivo
va a ser el software que voy a disear.
E. MTRICAS ORIENTADAS A LA PERSONA: Proporcionan medidas e
informacin sobre la forma que la gente desarrolla el software de
computadoras y sobre todo el punto de vista humano de la
efectividad de las herramientas y mtodos. Son las medidas que voy a
hacer de mi personal que va har el sistema.
F. MTRICAS ORIENTADAS AL TAMAO: Es para saber en qu tiempo voy a
terminar el software y cuantas personas voy a necesitar. Son
medidas directas al software y el proceso por el cual se
desarrolla, si una organizacin de software mantiene registros
sencillos, se puede crear una tabla de datos orientados al
tamao.
Qu es un programa de mtricas?
Un programa de mtricas bien diseado ayudar al management en la
toma de decisiones y mejorar el retorno de la inversin en los
proyectos, pero existen montones de aspectos de un proyecto que
pueden ser medidos y se deben identificar en cada caso los que
realmente sern de utilidad y no producirn un esfuerzo intil.
Para implementar un nuevo programa de mtricas o mejorar el que
est actualmente en funcionamiento en una empresa se deben seguir
los siguientes pasos:
1. Identificar los objetivos del negocio 2. Seleccionar las
mtricas3. Obtener datos histricos4. Automatizar los procedimientos
de medicin5. Utilizar las mtricas en la toma de decisiones
Modelo de evaluacin para software que emplean indicadores
mtricos en la vigilancia cientfico-tecnolgica
Este modelo puede servir como herramienta a los analistas de
informacin u otros usuarios de este tipo de sistemas. Ofrece
elementos y criterios de seleccin para el uso, a nivel de usuario,
del software de VC-T, mientras que para los diseadores y
programadores de software, les posibilita conocer los
requerimientos de los usuarios.
Este software constituye un factor clave a la hora de traducir
la informacin del entorno en resultados que se puedan involucrar en
los procesos de toma de decisiones. Establecer su calidad se
traduce en un ahorro de costos y en una mejora general para el
proceso.
A. MTODOS
Para realizar la propuesta del modelo, se desarrollaron bsquedas
sobre validacin y evaluacin de software, normas o estndares,
criterios para la evaluacin, indicadores, etctera. Se trabaj con la
norma AENOR UNE166.0061, el estndar para el aseguramiento de planes
de calidad del IEEE 730:1989, las normas de la Organizacin
Internacional de Normalizacin (ISO en sus siglas en ingls), en
especial la familia de normas ISO 9000 (especficamente la ISO 9001,
la ISO 9003-2 y la ISO 9126).
Para la seleccin del software que se utilizara para el
levantamiento de los indicadores, se cre una lista con los
siguientes aspectos:
a) Debe haberse aplicado en algn estudio vinculado a la VC-T.b)
debe permitir al usuario la aplicacin de al menos un indicador
mtrico.c) permitir realizar representaciones visuales de los
resultados proveniente de la aplicacin de indicadores mtricos, d.)
que sean software conocido y tratados en la literatura de la
especialidad.
El estndar 9126 establece que cualquier componente de la calidad
del software puede ser descrito en trminos de una o ms de seis
caractersticas bsicas, las cuales son: funcionalidad,
confiabilidad, usabilidad, eficiencia, capacidad de mantenimiento y
portabilidad; cada una de las cuales se detalla por medio de un
conjunto de sub-caractersticas que permiten profundizar en la
evaluacin de la calidad de productos de software.
Esta norma consta de cuatro secciones: modelo de la calidad,
mtricas externas, mtricas internas y calidad en las mtricas de uso.
Adems cuenta con cuatro anexos: A, B, C y D. Para este trabajo se
seleccion como marco de referencia al primero (ISO/IEC 9126-1) por
ser el que cuenta con el modelo de calidad que ms se ajusta a los
objetivos propuestos.
En este sentido, se utilizaron como referencias para el diseo
del modelo las seis caractersticas de la calidad interna y externa,
as como las cuatro referidas a la calidad en uso (de la ya
mencionada 9126-1), y a partir de estas se definieron las
sub-caractersticas que respondan con ms precisin al software de
VC-T. Las seis caractersticas seleccionadas fueron: funcionalidad,
confiabilidad, utilidad, eficiencia, capacidad de mantenimiento y
portabilidad. Otras de las caractersticas incluidas en el modelo
fueron aquellas enfocadas al uso, como: eficacia, productividad,
seguridad y satisfaccin.
Para establecer las medidas de evaluacin, se propone una tabla
con la asignacin de las mtricas necesarias para cada caracterstica
o atributo del software. Estas mtricas son estimaciones
consideradas a partir de las pruebas, la operacin y la observacin
operativa del programa. En la norma aparecen varias mtricas, sin
embargo, a los efectos de esta contribucin, se tomarn las mtricas
externas que se consideren como apropiadas para cuantificar
diferentes criterios como son el nivel de satisfaccin de las
necesidades de los usuarios del programa y otros.
Considerando todas estas partes y los aspectos aqu tratados, se
procedi a disear la propuesta de modelo para la evaluacin del
software utilizado en la VC-T.
B. RESULTADOS Y DISCUSIN
El modelo se inicia con una ficha que contiene algunos atributos
del producto. Esto permitir obtener una idea general de sus
caractersticas. La ficha incluye 4 atributos (cuadro 1):
a) Descripcin general de la herramienta y sus principales
caractersticas.b) Apoyo al ciclo de la VC-Tc) Sistema: define la
capacidad y los requerimientos de la computadora para poder usar la
herramienta d) Licenciamiento y pgina de descarga (URL donde se
puede acceder al sistema).
El modelo contiene una serie de tareas a realizar para la
evaluacin, estructuradas en niveles jerrquicos (de variables
generales a otras ms especficas y derivadas de las primeras).
MTRICAS DE ACEPTACIN DE REQUERIMIENTO
La frmula para el clculo de la misma es:Mtrica de Aceptacin de
Requerimiento =(A/B)*100
Donde A es la cantidad de requerimientos aceptados por el
cliente y B es el nmero total de requerimientos relevados.
En la grfica 1 podemos observar el resultado que se obtuvo
referente a las mtricas de aceptacin de requerimientos, de los 10
grupos en que se analiz y extrajo de la documentacin entregada; slo
en uno de ellos no se pudo obtener dicha informacin.
Como podemos observar los valores obtenidos estn por encima de
0,7 (tomando como referente la norma ISO 9126 las medidas se
valoran entre 0 y 1 cuanto ms cercano a 1 fue mejor el
relevamiento) por lo cual se considera que el relevamiento de los
requerimientos fue bueno, o por lo menos el alcance reflejo lo que
el cliente quera.
Grfica 1 Mtricas de Aceptacin de Requerimientos
MTRICAS DE PRUEBAS CUBIERTAS
La frmula para el clculo de la misma es:Mtrica de Pruebas
Cubiertas=(A/B)*100
Donde A es el nmero de pruebas realizadas en la verificacin
unitaria, del sistema y de integracin. Siendo B es el nmero total
de pruebas realizadas incluidas las del cliente.
Grfica 2 Mtricas de pruebas cubiertas
En la grfica 2 se observa el resultado de las mtricas de pruebas
cubiertas, esto nos da una idea de la cantidad de pruebas que se
realizaron de acuerdo a las planificadas y darnos cierta garanta de
que antes de poner en produccin el aplicativo se contar con menores
probabilidades de errores en la ejecucin del mismo.
En este caso todos los valores dieron por encima de la media por
lo cual se considera que el producto est por encima del 50%
probado, cuanto ms cerca de 1 de cmo resultado la mtrica, menores
probabilidades de error se obtendrn en produccin.
MTRICAS DE PRODUCTIVIDAD ORIENTADA AL TAMAO
Mtrica de Productividad=A/B, siendo A el puntos de funcin o
miles de lneas de cdigo sin comentarios y B el total de horas
hombre.
En la tabla 6 se muestra para todos los grupos los valores de la
Mtrica de productividad orientado al tamao del producto que es el
cociente entre la cantidad en miles de lneas de cdigo sobre el
total de horas del grupo. En dicha tabla 6 aparecen todos los
grupos juntos independiente de en qu lenguaje se desarrolla, luego
en la Grfica 3 se muestran los resultados de la mtrica de
productividad con respecto al tamao, para los grupos de orientados
a objetos, que estn formados por siete grupos de Java y uno de
punto .Net y la Grfica 4 para los dos grupos de genexus.
GrupoMtrica de productividad orientado al tamao del
productoMediciones de tamaoTotal de Horas
1 Java8.24400904865
2 Java9.60413714310
3 Java12.12427983530.44
4 Java9.52288483029.9
5 Java8.83384014348
6 Java2.1493743471.87
7 Java4.87181713735
8 .Net2.1187224138.65
9 Genexus0.3915123860.85
10Genexus0.371223.83283
Tabla 4 Mtrica de productividad orientado al tamao del
producto
Los dos grupos de Genexus obtuvieron valores de productividad
similares 0.39 para el grupo 9 ya que realizaron 1512 Gxpoint
empleando 3860 horas mientras que el grupo 10 obtuvo 0.37 como
consecuencia de desarrollar 1223.8 Gxpoint en 3283 horas.
En los grupos orientados a objetos se distinguen dos intervalos
de valores bien diferenciados, uno donde estn los primeros cinco
grupos con valores que oscilan entre los 8 y 12 y otro con los
ltimos 3 (Grupos 6,7 y 8) que obtienen valores entre 2,11 y 4,87.
Podemos destacar que el grupo ms productivo fue el 3 y los menos
productivos fueron los grupos 6 y 8.
Grfica 3 Mtrica de productividad orientado al tamao del producto
OO
0,390,370,360,370,370,380,380,390,390,4012Mtrica de
productividad orientado al tamao del producto Grupos Genexus Grupo
9Grupo 10
Grfica 4: Mtrica de productividad orientado al tamao del
producto GENEXUS
MTRICAS DE EFECTIVIDAD DE LAS PRUEBAS
Grfica 5 Mtrica de efectividad de las pruebas
Esta mtrica mide la efectividad para encontrar errores y la
frmula para calcularla es:
Errores encontrados =Errores encontrados durante las pruebas/
Total de errores encontrados (los de las pruebas + los de
aceptacin)
Del total de errores encontrados, se contabilizan los
encontrados en las pruebas realizadas como los encontrados por el
usuario en las pruebas de aceptacin.
Cuanto ms aproximado a uno del resultado de esta mtrica
maximizar el nmero de errores encontrado durante las pruebas. Los
resultados obtenidos en los diferentes grupos estuvieron en todos
los casos por encima de 0,77 y la mayora estuvo por encima de 0,85
por lo cual se considera que las pruebas fueron efectivas.
En la grfica 5 referente a la mtrica de efectividad de las
pruebas, podemos observar que los 10 grupos estuvieron muy parejos,
siendo ms detallistas los grupos que obtuvieron valores inferiores
fueron los grupos de genexus el 9 con 0.77 y el 10 con 0.83. En la
grfica 5 podemos ver claramente la gran paridad entre los
diferentes grupos
CONSIDERACIONES FINALES
El apoyo tecnolgico es fundamental en el servicio de VC-T para
determinar las tendencias del mercado y gestionar los ejes o la
cartera de proyectos. Sin embargo, los software necesitan
identificarse y evaluarse para contribuir a tres importantes metas:
los analistas deben tener informacin sobre el software disponible
en el mercado; estos deben entrenarse en las funciones de seleccin,
revisin y evaluacin de programas y, al mismo tiempo, ellos deben
recibir una formacin sobre la integracin curricular de estos
sistemas con sus profesiones.
Se seleccion despus de revisar las normas existentes en la
literatura a la ISO 9126 como marco de referencia en la elaboracin
del modelo, por ser un estndar oficial, aprobado y validado.
El modelo de evaluacin de software propuesto en este documento
es una herramienta vlida para caracterizar la tecnologa de software
y facilitar su introduccin en el servicio de VC-T, en la medida que
los analistas disponen de un criterio para identificar aquellos
programas que se corresponden con sus necesidades y, sobre todo;
con la solucin de los problemas que surgen dentro del mismo proceso
de anlisis.
La aplicacin del modelo permite identificar deficiencias y
requerimientos necesarios para el diseo de este tipo de
programas.
La propuesta de modelo realizada requiere de su validacin y
aplicacin por varios especialistas, as como la valorar de los
indicadores desde la perspectiva de la ingeniera de software. Esto
enriquecer y mejorar la propuesta desde el punto de vista tcnico y
de diseo.
