Informe Ejecutivo

Carlos Fernando Agustin López

José Luis De León Monteagudo
Luis Alfonso Hernández Moreno
Henry Eduardo Méndez Álvarez
Josué Noel Xet Pérez
Josué David Estrada Rubio
José Víctor Zamudio Cifuentes

METRICAS DE PROCESO Y PROYECTO

1. Introducción
Las métricas nos ayudan tener una visión cuantitativa de algún aspecto especifico del proceso o
del proyecto.
Las métricas del proyecto permiten:
 Valorar el estado de un proyecto en curso
 Rastrear riesgos potenciales
 Descubrir áreas de problemas antes que se vuelvan criticas
 Ajustar el flujo de trabajo o tareas
 Evaluar la habilidad del equipo para controlar la calidad del producto de trabajo de software

2. Desarrollo del Tema

La recolección, interpretación y medición de los procesos tiene que tener un criterio simple y
además tiene que ser de utilidad, esto último quiere decir que si una organización se toma el trabajo
de recolectar, interpretar y medir los procesos, entonces seguramente es porque piensa hacer algo
con el resultado de ello, o no?

Hay veces que los datos que recolectamos no son de utilidad en la actualidad, aunque la
organización tendría que tener claro como las piensa utilizar en el futuro y esto tendría que ser claro
y detallado.

Con esto, podemos explicar entonces que todo lo que recolectemos, interpretemos y midamos sin
tener una utilidad, implica un riesgo para la organización. Aquí podemos deducir entonces, que las
métricas que las organizaciones tienen que tener para sus procesos (por ejemplo el proceso de
desarrollo de software) son aquellas que les sean de utilidad para tomar decisiones y nada mas que
aquellas que vaya a utilizar en la actualidad o que ya tenga la expectativa de utilización en el futuro
cercano y con un grade de detalle muy avanzado.

En las organizaciones -por lo general- a la pregunta del objetivo que tiene la misma para el año o
para los próximos 5 años, muchas veces la única respuesta que se escucha es 'ganar dinero'. Y si,
todos sabemos que la rentabilidad es muy importante. Ahora siendo los que llevamos adelante los
proyectos de software en la organización, podemos tener problemas en los proyectos por distintas
razones.
Mala estimación
Cambios de Requerimientos
Retrasos en el calendario
Etc.
Luego de un tiempo de llevar adelante los proyectos de la misma manera (enfocados en el tiempo
y coste), nos hemos dado cuenta en mi grupo de trabajo que estábamos llevando adelante los
proyectos con un único objetivo, y este era el mas importante para el grupo de
Diseñadores/Desarrolladores ya que nosotros solo nos enfocabamos en ello, y eso era TIEMPO y
COSTE.

Cuando entendimos eso (nos llevo mas de dos años entenderlo) comenzamos a seguir los proyectos
de una manera diferente.

Hasta este momento, hacíamos los proyectos con TDD y corríamos los proyectos en nuestra
herramienta de Integración Contínua (Hudson), generando los informes de Test (Unitarios,
Componentes, Integración), CheckStyle, PMD, Cobertura, cada noche, todos los días de la semana.
La herramienta de Integración Contínua generaba además de los informes, el envío de mails a los
participantes del proyecto si los mismos no pasaban la compilación y test.

Entonces, porque decimos que solo nos interesaba el TIEMPO y COSTE en nuestros proyectos?
Simplemente porque nadie tenía ningún nivel de servicio que cumplir, ni se guardaba ninguna
métrica sobre el checkeo de código o sobre la cobertura de los mismos.

Luego, despúes de razonar un tiempo sobre este punto, logramos llegar a derivar en un conjunto de
SLA's con los que nos sentimos cómodos en el seguimiento de los proyectos, generando una calidad
muy alta en los mismos.

Cantidad de errores detectados por las herramientas de inspección automática, como PMD,
Checkstyles, Macker.
Cobertura de código por los test (Unitarios, Componentes e Integración): en los entornos que
desarrollamos (JEE), asociado al proceso de integración continua, se mide el porcentaje de código
cubierto por las pruebas unitarias, de componentes y de integración.
Como cierre de esto, hemos implementado Scrum, como proceso para la Gestión de los Proyectos,
y aquí teminamos adicionando el concepto de 'Terminado' que nos ha dado muy buenos resultados
en conjuntos con Scrum.
Con Scrum, también agregamos a nuestras métricas, la velocidad del equipo y el factor de foco en
los diferentes Sprints de los diferentes proyectos y los imprevistos e impedimentos sucedidos.

Y como cierre, podemos nombrar algunas métricas que se pueden tener en general en las
organizaciones, y que solo deberían llevarse si se piensa hacer algo con ellas (nosotros no las
tenemos, por ahora).

Cantidad de defectos, desagrupados por etapa del proyecto y tipo de entregable (defecto en
software, en especificación funcional, en especificación técnica, o en el proceso mismo).
Tiempo promedio de solución de un defecto.
Sobreesfuerzo generado por defectos, es decir, el esfuerzo necesario para corregir los defectos,
desagregado por actividad.
Cantidad de cambios a los requerimientos, también desagrupados por etapa del proyecto y cantidad
de cambios aceptados y rechazados.
Velocidad de avance del equipo, medida por la cantidad de historias del usuario o de requerimientos
implementados por unidad de tiempo y como avance ganado, definido como tiempo insumido /
(tiempo insumido + tiempo estimado para completar).
Miles tones cumplidos en tiempo, demorados y demora promedio.
Cantidad de cambios al plan del proyecto, y el motivo de los mismos (cambios a los requerimientos,
cambios a la dotación del equipo de trabajo, errores en la estimación).
Desvío de la estimación original, por componente y actividad, para lo cual el sistema de registración
de horas está alineado con la forma de estimar: se imputan horas con el mismo concepto y
granularidad con que se estima el proyecto.

Como resumen, tenemos que recordar el concepto que ha originado la nota, que es el esfuerzo de
recolectar una métrica sirve si ésta puede servir de base para una toma de decisión. Y, por cierto, el
objetivo de estas métricas (o de cualquier otras) no es cumplir con CMMI, signifique esto lo que
signifique, sino dar información útil, que sirva para tomar decisiones, sobre la performance del
proceso y el estado del proyecto.

3. Conclusiones
Las métricas proporcionan los conocimientos necesarios para crear modelos efectivos de análisis y
diseño, un código sólido y pruebas exhaustivas. Las métricas se enfocan al proceso de software en
varios aspectos tales como métricas del producto, para el modelo de análisis, para el modelo de
diseño, para el c digo fuente, para pruebas y para mantenimiento, las cuales permiten el control de
calidad en cada uno de estos procesos.

1. Bibliografía

e-grafía:
https://umg.blackboard.com/webapps/assignment/uploadAssignment?content_id=_35991_1&co
urse_id=_2172_1&group_id=&mode=view

Documentos de Clase
 MAPA CONCEPTUAL

Lik: https://www.lucidchart.com/invitations/accept/6be184c6-6fc0-46af-8fc3-5b7d262900b9
 CONTROL DE VERSIONES
Versión Hecha por Revisada por Aprobada por Fecha Motivo

1.0 CH AV AV 22-04-18 Versión original

PLANTILLA DE MÉTRICA DE CALIDAD

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

• Servifiestas de Antigua SDA

MÉTRICA DE:

PRODUCTO PROYECTO X

FACTOR DE CALIDAD RELEVANTE: ESPECIFICAR CUÁL ES EL FACTOR DE CALIDAD RELEVANTE QUE DA ORIGEN
A LA MÉTRICA

Performance del Proyecto

DEFINICIÓN DEL FACTOR DE CALIDAD: DEFINIR EL FACTOR DE CALIDAD INVOLUCRADO EN LA MÉTRICA Y

ESPECIFICAR PORQUÉ ES RELEVANTE

La Perfomance del Proyecto se define como el cumplimiento del schedule y del presupuesto del proyecto.
Este factor de calidad es relevante pues permitirá al equipo de proyecto lograr el margen de utilidad que
ha sido calculado para el proyecto, caso contrario el proyecto podría no generar utilidades o más aún,
podría generar pérdidas.
Por otro lado el atraso en la entrega de los productos que espera el cliente nos puede ocasionar problemas
contractuales.

PROPÓSITO DE LA MÉTRICA: ESPECIFICAR PARA QUÉ SE DESARROLLA LA MÉTRICA?

La métrica se desarrolla para monitorear la perfomance del proyecto en cuanto a cumplimiento de schedule
y presupuesto, y poder tomar las acciones correctas en forma oportuna.

DEFINICIÓN OPERACIONAL: DEFINIR COMO OPERARÁ LA MÉTRICA, ESPECIFICANDO EL QUIÉN, QUÉ, CUÁNDO, DÓNDE,
CÓMO?

El Project Manager actualizará el sistema EVM en el MS Project, en la mañana de los lunes de cada
semana, y calculara el CPI (Cost Perfomance Index) y el SPI (Schedule Perfomanec Index), en las
oficinas de Dharma Consulting, obteniendo de esta forma los ratios de perfomance del proyecto, los
cuales se tendrán disponibles los lunes en la tarde.

MÉTODO DE MEDICIÓN: DEFINIR LOS PASOS Y CONSIDERACIONES PARA EFECTUAR LA MEDICIÓN

 1. Se recabará información de avances reales, valor ganado, fechas de inicio y fin real, trabajo real,
y costo real, los cuales se ingresarán en el MS Project.
2. El MS Project calculará los índices de CPI y SPI.
3. Estos índices se trasladarán al Informe Semanal de Proyecto.
4. Se revisará el informe con el Sponsor y se tomarán las acciones correctivas y/o preventivas
pertinentes.
5. Se informará al cliente de dichas acciones de ser el caso.

RESULTADO DESEADO: ESPECIFICAR CUÁL ES EL OBJETIVO DE CALIDAD O RESULTADO DESEADO PARA LA MÉTRICA

1. Para el CPI se desea un valor acumulado no menor de 0.95

2. Para el SPI se desea una valor acumulado no menor de 0.95

ENLACE CON OBJETIVOS ORGANIZACIONALES: ESPECIFICAR CÓMO SE ENLAZA LA MÉTRICA Y EL FACTOR

DE CALIDAD RELEVANTE CON LOS OBJETIVOS DE LA ORGANIZACIÓN

Contacto: informes@dharma-consulting.com, Página Web: www.dharmacon.net

The PMI Registered Education Provider logotipo es una marca registrada del Project Management Institute, Inc.
Dharma Consulting como un Registered Education Provider (R.E.P.) ha sido revisada y aprobada por el Project Management
Institute (PMI) para otorgar unidades de desarrollo profesional (PDUs) por sus cursos. Dharma Consulting ha aceptado
regirse por los criterios establecidos de aseguramiento de calidad del PMI.

El cumplimiento de éstas métricas es indispensable para poder obtener la utilidad deseada de los
proyectos de consultoría y capacitación de la empresa, lo cual a su vez posibilitará el crecimiento de la
empresa y la mejora general de sus productos y servicios.

RESPONSABLE DEL FACTOR DE CALIDAD: DEFINIR QUIÉN ES LA PERSONA RESPONSABLE DE VIGILAR EL

FACTOR DE CALIDAD, LOS RESULTADOS DE LA MÉTRICA, Y DE PROMOVER LAS MEJORAS DE PROCESOS QUE SEAN
NECESARIAS

La persona operativamente responsable de vigilar el factor de calidad, los resultados de la métrica, y de

promover las mejoras de procesos que sean necesarias para lograr los objetivos de calidad planteados,
es el Project Manager en primera instancia, pero la responsabilidad última de lograr la rentabilidad del
proyecto y el cumplimiento de los plazos recae en forma ejecutiva en el Sponsor del Proyecto.