THE GOAL QUESTION METRIC APPROACH - METRICAS

La medició n es un mecanismo para la creació n de una memoria corporativa y una ayuda para
responder a una variedad de cuestiones asociadas con la ejecució n de cualquier proceso de
software. Es de ayuda para soportar planificaciones de proyectos, nos permite:

1. Determinar las fortalezas y debilidades de los procesos y productos actuales (por

ejemplo con cuá nta frecuencia se cometen cierto tipo de errores)
2. Adoptar o refinar técnicas (por ejemplo, cuá l es el impacto de cierta técnica en la
productividad de un proyecto).
3. Evaluar la calidad de un proceso o producto

La medició n también contribuye, durante el transcurso de un proyecto, para evaluar su

progreso, para tomar acciones correctivas en base a esta evaluació n, y para evaluar el impacto
de dicha acció n.

Para que las mediciones sean efectivas, deben:

1. Centrarse en objetivos específicos

2. Aplicase a todos los ciclo de vida de productos, procesos y recursos;
3. Interpretarse en base a la comprensió n del contexto de la organizació n y los objetivos.

Las mediciones deben definirse de manera top-down, un enfoque de bottom-up no va a

funcionar porque hay muchas características observables en el software.

Es importante dejar en claro, qué necesidades de informació n tiene la organizació n, y si estas

necesidades de informació n pueden ser cuantificadas, y la informació n cuantificada se puede
analizar para verificar si se alcanzan o no los objetivos.

El resultado de la aplicació n de GQM es un sistema de medidas orientadas a un conjunto

particular de cuestiones y reglas para la interpretació n de los resultados de las medidas.

El modelo resultante tiene 3 niveles:

1. Nivel conceptual(objetivo): el objetivo se define para medir un objeto, puede ser:

 Producto: entregable o documentació n producida durante el ciclo de vida
 Proceso: relevamiento, diseñ o, testing o cualquier actividad relacionada con software.
 Recurso: personas, hard soft o cualquier elemento utilizado en los procesos.
2. Nivel operacional (Preguntas): Las preguntas tratan de caracterizar el objeto de medició n
(producto, proceso, recurso) con respecto a un problema de calidad seleccionado.  Son
aquellas preguntas cuyas respuestas permiten definir el cumplimiento de las metas.  
2. Nivel cuantitativo (métricas): conjunto de datos que responden cuantitativamente las
preguntas. Los datos pueden ser objetivos o subjetivos.
GQM es un modelo jerá rquico:

Comenzando con un objetivo (especificando el propó sito de la medida, el objeto a medir, la

cuestió n a medir y el punto de vista desde el cual se toma la medida). El objetivo se
perfecciona en varias preguntas, cada pregunta se refina en métricas, algunas de ellas
objetivas como la del ejemplo, otras má s subjetivas. La misma métrica se puede utilizar para
responder a diferentes preguntas bajo el mismo objetivo.

Con el fin de dar un ejemplo de aplicació n de este enfoque, vamos a suponer que queremos
mejorar el proceso de solicitud de cambio durante la fase de mantenimiento del ciclo de vida
de un sistema. El objetivo resultante especificará un propó sito (mejorar), un proceso
(procesamiento de solicitud de cambio), un punto de vista (gerente de proyecto) y un
problema de calidad (puntualidad). Esta meta puede ser refinada a una serie de preguntas,
sobre, por ejemplo, tiempo de respuesta y recursos utilizados. Estas preguntas pueden ser
respondidas por métricas que comparan tiempos de resolució n específicos con los medios.
1. Objetivo: Mejorar la puntualidad del proceso de solicitud de cambio desde el punto de
vista del administrador del proyecto
2. Preguntas
A. ¿Cuá l es la velocidad de procesamiento de solicitud de cambio actual?
B. ¿Está mejorando el desempeñ o del proceso?
3. Métricas:
A. Tiempo medio de ciclo, Desviació n está ndar y % De casos fuera del límite superior
B. (Tiempo medio de ciclo actual/Tiempo prom del ciclo de referencia) *100

Un modelo GQM se desarrolla identificando un conjunto de objetivos de calidad y / o

productividad, a nivel corporativo, de divisió n o de proyecto. A partir de esos objetivos y
basados en modelos del objeto de medició n, derivamos preguntas que definen esos objetivos
lo má s completamente posible. El siguiente paso consiste en especificar las medidas que
deben ser recolectadas para responder a esas preguntas, y para rastrear la conformidad de los
productos y procesos con las metas. Una vez especificadas las medidas, es necesario
desarrollar los mecanismos de recopilació n de datos, incluidos los mecanismos de validació n
y aná lisis.

Un objetivo tiene 3 coordenadas:

1. Incidente: tiempo limite

2. Objeto (proceso) Procesamiento de solicitud de cambio
3. Punto de vista Director de proyecto y un propó sito: resolver

El desarrollo de un objetivo se basa en tres fuentes bá sicas de informació n.

1) La política y la estrategia de la organizació n
2) La descripció n del proceso y de los productos de la organizació n, o, al menos,
los que está n dentro del alcance de la medida que queremos llevar a cabo.
3) El punto de vista de la meta. Obviamente, no todos los asuntos y procesos son
relevantes para todos los puntos de vista de una organizació n, por lo tanto, hay
que realizar una etapa de aná lisis de relevancia antes de completar nuestra
lista de objetivos, con el fin de asegurarse de que los objetivos que hemos
definido tienen la relevancia necesaria.
A partir de la especificació n de cada objetivo podemos derivar preguntas significativas, vamos
a pedir al menos tres grupos de preguntas:
1) caracterizar el objeto (producto, proceso o recurso) con respecto al objetivo.
(ejemplo: ¿Cuá l es la velocidad de procesamiento de solicitud de cambio actual?)
2) caracterizar los atributos del objeto que son relevantes respecto al issue. (ejemplo,
¿Cuá l es la desviació n del tiempo de procesamiento de solicitud de cambio real con
respecto a la estimada?)
 3) evaluar las características del objeto que son relevantes respecto al issue. (Ejemplo,
¿Está mejorando el rendimiento visiblemente?).
Una vez que las preguntas se han desarrollado, procedemos a asociar la pregunta con
Métricas apropiadas, Los factores que consideramos al hacer esto son muchos; entre ellos:
1) Cantidad y calidad de datos existentes
2) Madurez de los objetos de medida: aplicaremos medidas objetivas a objetos de
medició n má s maduros y má s subjetivas cuando tratamos objetos informales o
inestables
3) Proceso de aprendizaje: Los modelos GQM necesitan siempre refinamiento y
adaptació n, por lo tanto las medidas que definimos deben ayudarnos a evaluar no só lo
el objeto de medició n sino también la fiabilidad del modelo utilizado para evaluarlo.

But_I_Only_Changed_One_Line_of_Code
(Theron R. Leishman y Dr. David A. Cook) - SCM

El software que creamos se mantiene de diversas formas, con diferentes herramientas, por
distintas organizaciones, durante las etapas de desarrollo, uso, mantenimiento y operació n. Si
se pierde el control, de alguno de los componentes del software, será necesario recrearlo,
aunque si se pierde el control de alguna de las herramientas, se espera que se pueda adquirir
una nueva.
Software Configuration Management (SCM) se ha definido como el arte de identificar,
organizar y controlar las modificaciones de software.
SCM es un proceso que se debe realizar a través de todo el ciclo de vida de desarrollo de
software y mantenimiento. La configuració n de los sistemas de software es por su naturaleza
compleja.
SCM puede ser descrito como una disposició n bien definida de componentes de software y las
herramientas  y procedimientos para la construcció n del producto de estos componentes, esto
también debe incluir procedimientos para la reconstrucció n de varias versiones y
lanzamientos
Típicamente SMC se define por, y desglosan en las siguientes cuatro á reas funcionales:
• Identificació n de Configuració n.
• Control de Configuració n.
• Configuració n de Status y Accounting.
• Auditoría de Configuració n.
SCM trata de identificar cuá les son los ítems del software importantes para la organizació n e
incluye el control de cambios de estos para garantizar su integridad. Lo que representa el
estado de estos ítems es importante para el éxito continuo de la organizació n. Para asegurar
que el software está siendo debidamente contabilizado, deben llevarse a cabo auditorías
perió dicas de configuració n.

El control de configuració n de software es el proceso de controlar y limitar los cambios

realizados en el software. Consiste en la evaluació n, coordinació n, aprobació n o
desaprobació n y la implementació n de cambios en los ítems de configuració n después del
establecimiento formal de su identificació n de configuració n
La contabilidad de estado es la actividad de SCM responsable de rastrear y mantener los datos
relativos a cada uno de estos SCI. Incluye el seguimiento de los cambios en las SCI y
proporciona la capacidad de determinar el estado de cada elemento en cualquier fase del
proceso de desarrollo o mantenimiento de software
Debe realizarse una auditoría de configuración de software periódicamente para asegurar que las
prácticas y procedimientos de SCM se sigan rigurosamente. Se acepta generalmente que seguir
buenas prácticas de desarrollo de software contribuirá a la entrega consistente de productos de
software de calidad (activos).

Los problemas de software más frustrantes generalmente son causados por la mala gestión de la
configuración. Los problemas son frustrantes porque toman tiempo para arreglar, generalmente
suceden en el peor momento, y son totalmente evitables.
En resumen, no hay tal cosa como un cambio de una línea, la identificación apropiada de todos los
ítems críticos es esencial para satisfacer los cambiantes requerimientos. Requiere revisión y
aprobación por individuos que conocen y entienden la aplicación y pueden determinar el impacto
extendido del cambio solicitado.
También se supone que alguien está observando el proceso, que se están realizando auditorías
que aseguran que se está siguiendo el proceso aprobado para realizar cambios (auditoria de
proceso) y que el producto de software coincide con la documentación (funcional y técnica).
Siguiendo todos estos pasos la probabilidad de que los cambios de software sencillos afecten
enormemente a los proyectos se reducirán considerablemente.

When Two Eyes Aren't Enough (Karl Wiegers) - SQA

A menudo estás demasiado cerca de tu propio trabajo para detectar cualquier error. Al estudiar el
código, su cerebro recita lo que creó anteriormente (o lo que pensó crear) porque está siguiendo
el mismo razonamiento que utilizó cuando cometió el error. Necesitas un par de ojos que no
hayan visto el código antes, y un cerebro que piensa de una manera diferente.
La Figura 1 coloca varios métodos de revisión comunes en un espectro de formalidad:

Usted debe reconocer las fortalezas y limitaciones de los diversos enfoques para que pueda
seleccionar un proceso de revisión que se ajuste a su cultura, limitaciones de tiempo y objetivos de
negocio.
Inspection:
Tiene varias características:
• Objetivos definidos
• Participación de un equipo capacitado
• Liderazgo de un moderador capacitado
• Funciones y responsabilidades específicas
• Un procedimiento documentado de revisión
• Comunicación de resultados a la dirección
• Criterios explícitos de entrada y salida para cada producto de trabajo
• Seguimiento de los defectos hasta el cierre
• Proceso de registro y datos de calidad para mejorar los procesos de desarrollo y revisión.
Una inspección es el tipo más sistemático y riguroso de revisión. Sigue un proceso bien definido y
de múltiples etapas, con roles específicos asignados a cada participante.
Las inspecciones se basan en listas de verificación de defectos comunes que se encuentran en
diferentes tipos de software y varias técnicas analíticas para buscar errores.
Un aspecto fundamental de la inspección es que los participantes presentan el material al equipo
de inspección (lector) y anotan las cuestiones a medida que se publican. Los participantes se
preparan para la inspección examinando el material por su cuenta para comprenderlo y encontrar
problemas. Durante la reunión, el lector presenta el material una pequeña porción a la vez a los
otros inspectores, que plantean problemas y señalan posibles defectos.

Team review
Son planificadas y estructuradas, pero un poco menos formal e integral.
Los participantes reciben los materiales de revisión varios días antes de la reunión y se espera que
estudien los materiales por su cuenta. El equipo recoge datos sobre la revisión y el número de
defectos encontrados. Sin embargo, las etapas de inspección general y de seguimiento son
simplificadas u omitidas, y algunos roles de los participantes pueden combinarse. El autor puede
dirigir la revisión del equipo, y en contraste con la mayoría de las inspecciones, el papel del lector
se omite.

Walkthrough (Tutorial)
Un tutorial es una revisión informal en la que el autor de un producto de trabajo lo describe a un
grupo de compañeros y solicita sus comentarios. Los walkthroughs difieren significativamente de
las inspecciones porque el autor toma el papel dominante, no hay otros papeles específicos del
revisor.
Los tutoriales por lo general no siguen un procedimiento definido, no requieren informes de
gestión y no generan métricas.

Pair Programming
Dos desarrolladores trabajan en el mismo producto simultáneamente en una sola estación de
trabajo. Esto facilita la comunicación y ofrece una oportunidad para una revisión continua,
incremental e informal de las ideas de cada persona. Cada línea de código está escrita por dos
cerebros que conducen una sola mano.
Es un tipo de revisión informal porque es desestructurada y no implica ningún proceso,
preparación o documentación.
Peer Deskcheck (Chequeo de compañero)
Un chequeo de compañero depende enteramente del conocimiento, habilidad y autodisciplina del
revisor, por lo que espera una amplia variabilidad en los resultados. Pueden ser bastante formales
si el revisor emplea listas de verificación de defectos, métodos de análisis específicos y formularios
estándar para llevar registros. Al finalizar, el revisor puede entregar una lista de defectos al autor o
simplemente entregar al autor su producto de trabajo marcado.

Passaround (Pasar alrededor)

Un passaround es un múltiple peer deskcheck, en el que se entrega una copia del producto a
varias personas y se recopilan sus comentarios. Mitiga dos riesgos principales de un peer
deskcheck: el revisor no proporciona información oportuna y el revisor está haciendo un trabajo
deficiente.

Revisión Ad Hoc
Son una manera rápida de obtener otra perspectiva que a menudo encuentra problemas que
simplemente no podemos ver nosotros mismos. Las revisiones ad hoc son el tipo de revisión más
informal, podrían resolver el problema inmediato, pero tienen poco impacto más allá de eso.

Elegir una revisión

Una forma de seleccionar el método de revisión más apropiado para una situación dada se basa en
el riesgo, la probabilidad de que un producto de trabajo contenga defectos y el potencial de daño
si lo hace. Utilice las inspecciones para los productos de trabajo de alto riesgo y confíe en técnicas
más baratas para los componentes que tienen un riesgo más bajo.