Este documento habla sobre las métricas y medidas de software. Explica que las métricas miden atributos específicos del producto de software y se recopilan durante las etapas técnicas para mejorar la calidad. También describe diferentes tipos de métricas como índice de productividad y tasa de defectos. Luego, distingue conceptualmente entre medidas, métricas e indicadores. Finalmente, presenta el modelo GQM (Meta-Pregunta-Métrica) para medir software orientado a objetivos específicos.

1. RicardoRodríguez
C.I:12.433.111
Introducción a las métricas de producto de software:
Las medidas y métricas de software suelen ser indirectas, las métricas se concentran en
atributos específicos de los productos de trabajo de ingeniería del software y se recopilan a
medida que realizan las etapas técnicas, para conseguir software de mayor calidad, nos permite
no solovalorarde forma cualitativasinocuantitativa, se debe partir de identificar las respectivas
métricasapropiadasparael producto,luegolarecolecciónde datos,se analizan para interpretar y
calificar el software, esto se comprueba llegando a culminar los objetivos de las mediciones, en
todo esto se proporciona una prevención de errores y corregirlos.
El software esunproducto como cualquier otro, y por tanto podemos hablar de software
de buena calidad y software de mala calidad. La calidad del software comprende distintos
aspectos como estética (que sea agradable a la vista), funcionalidad (que sea fácil de usar),
eficiencia (que ejecute con rapidez y precisión los procesos), etc.
MÉTRICA
Históricamente se hablóde métricaenreferenciaa los sistemas que existían para escribir
versos diferenciados en base al número de sílabas que contenía cada verso, así como en
referencia al estudio y “medición” de la cantidad de sílabas y estrofas que contenían los versos.
En informática, el término métrica hace referencia a la medición del software en base a
parámetrospredeterminados, como puede ser el número de líneas de código de que consta o el
volumen de documentación asociada. A veces en vez de hablar de métrica se usa el término
“Indicadores” del software. Algunos ingenieros lo usan como sinónimos mientras que otros les
atribuyen significados distintos.
Algunas métricas o indicadores pueden ser:
a) Índice de productividad = tamaño / esfuerzo = líneas de código generado / horas trabajadas.
b) Tasa de defectos = defectos / tamaño = número de errores / líneas de código generadas.
Diferencia conceptuales entre medidas, métricas e indicadores:
Medida: Proporciona una indicación cuantitativa de la cantidad, dimensiones o tamaño de
algunos atributos de un producto.
Métrica: Es una medida del grado en que un sistema, componente o proceso posee un atributo
dado.
Indicador: esuna métricao una combinaciónde métricasque proporcionanconocimientos acerca
del proceso del desarrollo de software, un proyecto de software o el propio producto. Un
indicador proporciona conocimientos que permiten a los ingenieros de software ajustar el
proceso, el proyecto o el producto para que las cosas mejoren.

2. Reto de la métrica orientada al producto:
El peligrode tratar de encontrar medidas que caractericen tantos atributos diferentes es
que inevitablemente lasmedidastienenque satisfacer objetivos que entran en conflicto entre sí.
Esto se opone a la teoría de que cada medicióndebe ser representativa. Aunque la afirmación de
Fentonescorrecta,muchas personasargumentanque lamedicióndel producto realizada durante
las primeras etapas del proceso de software proporciona a los ingenieros un mecanismo
consistente y objetivo para evaluar la calidad.
Indicar los principios de medición (Roche):
•Formulación: La obtención de medidas y métricas del software apropiadas para la
representación del 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.
•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.
•Realimentación (feedback): Recomendaciones obtenidas de la interpretación de
métricas técnicas transmitidas al equipo que construye el software.
Medición de software orientado a meta (Basili y Weiss):
Goal Question Metric (GQM), o Meta-Pregunta-Métrica, es un enfoque presentado por
Víctor Basili de la Universidad de Maryland (1984) que da respuesta a esta necesidad. Este
enfoque parte de la suposición de que una organización para medir adecuadamente, debe
identificarlasmetasque desea,derivarobjetivosamedirde maneracuantificable y establecer un
marco que permita interpretar la información respecto a los objetivos.
El modelo GQM es una estructura jerárquica que especifica a partir de un objetivo los
efectos de la medición, el objetivo a medir, la cuestión que debe medirse y el punto de vista de
donde se toma la medida. Cada objetivo se descompone en varias preguntas para entender los
componentesdel objetivoyfinalmentese obtienenmétricas que dan respuesta a cada una de las
preguntas.Todoeste procesose descompone atresniveles:Conceptual,OperativoyCuantitativo.
Nivel conceptual (Meta): Se establece un objetivo para cada elemento de medición,
considerando el producto, proceso y los recursos, desde diferentes puntos de vista.
Nivel operativo(Pregunta):Con base en las metas definidas se establece un conjunto de
preguntas que permiten caracterizar la evaluación / logro de un objetivo específico.
Nivel cuantitativo (Métrica): A cada pregunta se le asocian datos que permitan dar
respuesta cuantitativa a los objetivos, de manera objetiva o subjetiva.
Un modelo GQM puede compartir las mismas preguntas y métricas para diferentes
objetivos, aunque se obtienen valores diferentes según el punto de vista. El modelo obtenido
requiere ser aplicado, recolectados los datos, interpretados y evaluados para determinar el
cumplimientode losobjetivos iníciales. Con esto se complementan todos los pasos para cubrir el
enfoque de GQM.

3. Las bases del área de proceso de MA, en el modelo CMMI, se fundamentan en buena
medidaenlasprácticas que establece el enfoque de GQM. Incluso en los ejemplos de formación
que se indican en la práctica genérica 2.5 se hace referencia a esto.