Se implementó un programa de medición utilizando el método GQM para evaluar el proceso de mantenimiento de software. Se definieron tres objetivos de mejora de proceso y se estableció un equipo de medición. Sin embargo, debido a limitaciones presupuestarias y de interrupción del proceso, solo se pudieron obtener métricas parciales que permitieron evaluar parcialmente los objetivos. Se recomienda comenzar con un conjunto básico de métricas y evolucionarlas gradualmente.

1. Liliana M, Johanna L, Tatiana M, Juan L.
Evaluación de Proyectos
Universidad Politécnica Salesiana

2. Todo el proceso
que conlleva
Definir e
implantar
Resultado de
iniciativas
organizadas
Relativa al
software
De una
información
determinada
Obtención y el
tratamiento

3. Implantación deprogramasdemedición
Aparentemente la definición e
implementación parece sencilla.
La idea de medir el software se acepta
como útil e incluso necesaria para
algunas organizaciones.
Pero al momento de la aplicación
exiten varios problemas

4. 20%
80%
Primer año
Éxito
Fracaso

5. 50%50%
Primer año
Éxito
Fracaso

6. Fracaso Éxito Fracaso

7. Cifras poco alentadoras.
Resulta fácil incluso para
los expertos fallar a la
hora de implementación.

8. Implementación
con Éxito
Factores Críticos
de Éxito
Consejos
Prácticos
Factores Técnicos
Factores
Organizativos
Método de
Implantación
Personas
Metodología
Obstáculos

10. El valor que aporta a la organización respecto a
un determinado problema
Se pueden obtener beneficios efectivos
respecto a un problema a partir de la
información proporcionada

11. Limitación de recursos y tiempo
Cuando el tiempo y los recursos de los proyectos
son ajustados.
Dudosa fiabilidad de las actividades de
medición
En muchos casos los procesos de recolección de
datos, análisis, interpretación, comunicación de
resultados son insuficientes, mal organizado y poco
fiables lo que provoca desconfianza

12. Escasa formación:
Si existe limitaciones de presupuesto no se suele
formar al personal en el área de medición del
software.
Poco conocimiento en el área de la medición del
software:
La cultura de la medición es pobre
Coste
Los beneficios que se obtienen de este no son
claros respecto a su coste

14. Clasificación
Factores Técnicos
Factores Organizativos
Los factores técnicos facilitan la captura y análisis de las métricas
por lo que animan al personal a usarlas. Los factores organizativos
son críticos para impulsar el uso de las métricas y la mejora de
procesos.

15. Disponer de un sistema para la captura de
métricas, que haga que los jefes del proyecto
tengan una visión más clara sobre el programa
de medición
Emplear herramientas automatizadas para
facilitar el uso de las métricas.
Optimizar los procesos de captura para mejorar
la precisión
Utilizar métricas precisas y relevantes en el
contexto
Emplear en la medición del software

16. Acuerdo del personal con los objetivos de
medición
Asignación de los recursos suficientes para el
desarrollo de las actividades de medición
Apoyo de la dirección, para que se establezcan y
perduren las iniciativas de medición
Suficiente nivel de madurez de la organización
Cultura de la compañía
Implementar el programa de medición
gradualmente

17. Disponer de un marco de medición bien
planificado donde se asegure el adecuado flujo
de información
Reutilizar en la medida de lo posible, el material
de medición que se tenga y a disponible
Hacer que el proceso de medición sea
transparente para los desarrolladores
Mejorar el programa de medición
constantemente

19. El verdadero significado de la medición de
percibe cuando surge de la cultura de la
organización , por lo que la implementación de
un programa de medición es similar a un
modelo de calidad.
Se encuentran algunos consejos que surgen de
los factores críticos de éxito:
Consejos Estratégicos
Consejos Prácticos

22. Definir programas de medición generales para
todos los proyectos o productos:
Facilita la aplicación de un programa de medición
en la organización y posteriormente el control de
los procesos.
Se puede realizar ciertas modificaciones para
adaptar el programa general a un proyecto
especifico.
Si se necesita información particular, se realizará un
pequeño programa de medición específico.

23. Los programas de medición deben ser
integrados a los procesos de desarrollo:
El programa de medición debe adaptarse a las
limitaciones de los procesos de desarrollo
Ejemplo: Si un proceso de desarrollo no contempla
establecer de manera formal y con un criterio
establecido la fiabilidad de un producto, el
programa de medición no debería poder evaluar
formalmente la fiabilidad de esta.

24. Una organización poco madura no puede
plantearse:
Obtener del programa de medición resultados
empíricos de estimación.
Podría dar lugar a resultados falsos, inesperados,
difíciles de interpretar

25. Proceso de medición estable:
Permite desarrollas programas de medición para
determinados objetivos de negocio.
Organización no es suficientemente madura:
Es complicado desarrollarlos y la probabilidad de
fracaso seria alta es igual a su coste.

26. Principalmente: empresas poco maduras y en las primeras fases de la
medición del software.
La propuesta consistiría en:
Grupo de analistas de medición: desarrollar un borrador del programa
de medición junto a un grupo de personas de alto cargo, promotores y
que conozcan bien los procesos, proyectos de software.
Desarrolladores claves y jefes de proyectos: que vayan a hacer uso del
programa de medición revisan el borrados.
Grupo de analistas: actualizan y formalizan el programa de medición.
Con esta propuesta se espera que le programa de medición se
defina de manera más dinámica:
No todos los involucrados están desde las primeras fases y si no se tiene
mucha experiencia, la información que se obtiene al principio puede no
ser útil

27. Considerar como una tarea más a realizar.
Establecer la cultura de medición:
Se percibe su utilidad
Se realiza la toma de decisiones de manera efectiva
Se realiza las mejoras oportunas en los procesos de
software

29. Recomendable:
Utilizar herramientas de desarrollo, gestión de
configuración, de incidencias, de recursos, etc. Que
se tenga la organización.
Evitar
Re compilación de información complicada.
Puede llevar a inexactitudes o esfuerzos extras para los
desarrolladores y jefes de proyecto.

30. Preferible:
Utilizar herramientas específicas y sencillas(hojas de cálculo
o base de datos) antes que herramientas complejas.
Ya que el personal debe conocer el proceso de medición,
sus objetivos y los pasos necesarios a seguir.
A veces el uso de las herramientas complejas
pueden confundir a los usuarios.
Una vez que el proceso de medición este
establecido, se podrá utilizar otras herramientas
más complejas

31. No es recomendable implantar el programa de medición, hasta
que no se haya probado en un proyecto piloto.
El programa de medición debe ser verificado por el jefe del
proyecto piloto, el grupo de analistas de medición y jefes del
proyecto que cuenten con gran experiencia.
Se pretende:
Utilizar el programa de medición en el proyecto.
Obtener los resultados y realizar los análisis necesarios para comprobar
que es coherente, se ajusta al propósito, la información que se obtiene
es útil, las herramientas de soporte están bien implementadas y son
convenientes.
Si la prueba piloto resulta ser satisfactoria para el grupo de validación se
incluirá dentro del proceso de medición de la organización y se usaran en los
siguientes proyectos.
Con los programas de medición enfocados en el proceso o en el producto se
harán también una prueba piloto haciendo un análisis previa al uso formal
del programa de medición

33. Grupo de definición
Analistas medición
Interesados en el programa de medición
Empresas Pequeñas
• Un solo analista
• Una sola persona como interesada

34. Grupo de revisores
Resto de Interesados
Jefes del Proyecto
• Si el programa cumple con los objetivos.
• Análisis de presupuestos
• Indicadores definidos cubren los objetivos
Desarrolladores
Involucrados en el proceso de medición

35. Identificar los objetivos de mejora del proceso
Empresa es madura, se podría desarrollar
directamente un programa de medición partiendo
de los objetivos de negocio.
Se recomienda utilizar plantillas de Medición
Software impulsado por metas.

36. Formalizar los objetivos de medición
Soporte al objetivo de mejora del proceso
Propósito
Enfoque
El punto de vista
Entorno

37. Definición de indicadores
Objetivo se detalla su indicador
Preguntas que se pretenden resolver
Representaciones graficas del indicador
Entradas para generar el indicador
Personas
Generen
Analizar
Interpretar el indicador
Posibles salidas del indicador
Posibles análisis e interpretaciones

38. Definición de indicadores derivados.
Indicadores principales necesite otros indicadores
Objetivos de medición derivados.

39. Definición de medidas y especificación de las
necesidades para implementarlas.
Detalle de la especificación de la medida a
recolectar (Datos se incluyen y cuales no)
Como se obtendrán los datos
Analiza si es posible obtener estos datos.
Si no es posible obtenerlos se modifica el indicador y
se analiza el impacto en el objetivo de medición final
O bien se busca la manera de obtenerlos

40. Integración del programa de medición
Integración en el proceso de desarrollo.
Plantillas de informes de seguimiento
Indicadores de monitorización definidos en el
proyecto
Plantillas del cierre de proyecto
Indicadores de calidad el desarrollo

41. Verificación de un programa de medición
Grupo de revisión
Analista reúna al grupo para exponer el programa
de medición definido.
Revisión
Reunión para proponer los cambios necesarios.

42. Automatización del programa de medición.
Automatizar ciertas consultas
Captura de datos
Reunir información
Análisis Globales

43. Se utiliza el programa de medición en un plan
piloto, proceso o producto
Los resultados se presentan a los interesados para
la evaluación.
Si es afirmativo el programa de medición se
establece en la organización o unidad de negocio

45. Se utilizo GQM(1998, 1984), y se creó un grupo (MWG Metrics
Working Group), eran responsables de clarificar la definición de
las métricas y las interpretaciones, dar consultoría, automatizar
la recopilación de datos, la organización en cada unidad de las
personas encargadas de la medición. Además de este grupo se
formó otro llamado Grupo de Usuarios de la medición (MUG)
para transmitir su experiencia en el uso de métricas.
Se establecieron objetivos cuantitativos de calidad para el
proceso de software y los productos según el concepto six-sigma
de Motorola.

46. Las métricas de mejora de proceso fueron muy útiles ya que se
detectaba la fase donde se introducían los defectos y su causa.
Las métricas relativas a la estimación fueron útiles para mejorar
las técnicas de estimación.
Las métricas relativas a los problemas detectados ayudaron a
conocer el tiempo de respuesta ante un problema.
Se recomienda comenzar por un conjunto de métricas y
evolucionar éstas en vez d encontrar la métrica perfecta.
Las iniciativas de medición conllevan un coste considerable.
50% de la reducción de la densidad de defectos en 3.5 años.
La gente en Motorola comenzó a pensar más seriamente sobre
el proceso de software y calidad.

48. Se definió un programa de medición con el
método GQM. Los objetivos de mejora de
proceso eran los siguientes.
Objetivo 1: analizar la facilidad de mantenimiento
del proceso.
Objetivo 2: analizar el proceso de mantenimiento.
Objetivo 3: analizar los recursos empleados en el
proceso de mantenimiento.

49. El equipo de medición tenía que proporcionar
resultados en tres meses.
El presupuesto para la recogida de datos era
bastante limitado.
El proceso de medición debía interrumpir lo
menos posible la actividad diaria de
mantenimiento.

50. Las herramientas empleadas para las
actividades de mantenimiento fueron
explotadas para obtener datos automáticos.
La información subjetiva que no requería
mucho esfuerzo se obtenía mediante
entrevistas a uno de los directivos

51. No se tenían los datos con grado de detalle
esperado.
Algunas métricas subjetivas no se pudieron
obtener.

52. El nivel de detalle y de precisión no pudo ser el
deseado.
El objetivo 1 quedaba satisfecho. Respecto al
objetivo 2, no se pudo obtener la información
del esfuerzo en resolver una petición de cambio
y su dificultad. Respecto al objetivo 3, la falta de
datos no permitió evaluar la coherencia entre la
duración estimada y real, y los costes.

53. Objetivo 1: el proceso de mantenimiento
parecía ser efectivo y los productos de buena
calidad. Los cambios rechazados y los defectos
que bloquean la ejecución del producto son
pocos y la calidad del producto no disminuía
con los cambios.
Objetivo 2: la duración de las actividades de
mantenimiento parecía adecuada respecto a la
prioridad.
Objetivo 3: los recursos por lo general parecían
apropiados para satisfacer las peticiones y
prevenir la creación de tareas pendientes.