Tomamos medidas, principalmente, para controlar un proyecto y, por lo tanto, poder gestionarlo. También tomamos medidas
para evaluar la distancia que nos separa de los objetivos establecidos en el plan en términos de completitud, calidad,
satisfacción de requisitos, etc.
Otro de los motivos es poder calcular mejor el esfuerzo, el coste y la calidad de proyectos nuevos, basándonos en la
experiencia previa. Por último, medimos para evaluar nuestra mejora en varios aspectos clave de rendimiento del proceso
a lo largo del tiempo, para ver cuáles son los efectos de los cambios.
La medida de algunos aspectos clave de un proyecto supone un coste significativo, por lo que no debemos medir todo de
manera indiscriminada. Debemos establecer objetivos muy precisos para este esfuerzo y recopilar únicamente la métrica
que nos permita satisfacer estos objetivos.
Hay dos clases de objetivos:
-
Objetivos de conocimiento: se expresan mediante el uso de verbos como evaluar, predecir, supervisar. Es
recomendable conocer mejor el proceso de desarrollo. Por ejemplo, es aconsejable evaluar la calidad del producto,
obtener datos para predecir el esfuerzo de prueba, supervisar la cobertura de la prueba o realizar un seguimiento
de los cambios de requisitos.
-
Objetivos de cambio o logro: se expresan mediante la utilización de verbos como aumentar, reducir, mejorar o
conseguir. Por lo general, su interés es ver cómo cambian o mejoran las cosas a lo largo del tiempo, de una
iteración a otra, de un proyecto a otro.
Ejemplos
-
Supervisar el progreso en relación con el plan
-
Aumentar la satisfacción del cliente
-
Aumentar la productividad
-
Aumentar la previsibilidad
-
Aumentar la reutilización
Estos objetivos de gestión generales no se convierten inmediatamente en métrica. Debemos convertirlos en subobjetivos
más pequeños (u objetivos de acción) que identifiquen las acciones que deben emprender los miembros del proyecto
para alcanzar el objetivo. Y debemos asegurarnos de que las personas implicadas conocen sus ventajas.
Ejemplos
El objetivo de "aumentar la satisfacción del cliente" se puede descomponer en:
-
Definir la satisfacción del cliente
-
Medir la satisfacción del cliente, en varios releases
-
Verificar que aumenta la satisfacción
El objetivo de "aumentar la productividad" se puede descomponer en:
-
Medir el esfuerzo
-
Medir el progreso
-
Calcular la productividad en varias iteraciones o proyectos.
-
Comparar los resultados
A continuación, algunos de los subobjetivos (pero no todos) requieren que se recopilen algunas medidas.
Ejemplo
"Medir la satisfacción del cliente" se puede derivar de
-
Encuestas a clientes (en las que los clientes puntúan diferentes aspectos)
-
Cantidad de llamadas, y su gravedad, a una línea directa de soporte al cliente.
Para obtener más información, consulte [AMI95].
Una manera útil de categorizar los objetivos es por necesidad de la empresa, del proyecto y técnica. Esto nos
proporciona una infraestructura para el perfeccionamiento que se explica más arriba.
Una empresa debe conocer, y quizás mejorar, el coste por 'artículo', reducir el tiempo de compilación (tiempo de salida
al mercado), y entregar un producto de calidad conocida (objetivo y subjetivo) y demandas de mantenimiento adecuadas.
Es posible que una empresa, de vez en cuando (o incluso continuamente), deba mejorar su rendimiento para seguir siendo
competitiva. Para reducir el riesgo, un empresa debe conocer el nivel de habilidad y de experiencia de sus empleados y
asegurarse de que tiene los demás recursos y la capacidad para competir en la esfera escogida. Una empresa debe poder
introducir tecnología nueva y determinar el coste-beneficio de dicha tecnología. En la tabla siguiente se listan
algunos ejemplos de las clases de métrica que son relevantes para estas necesidades de una empresa de desarrollo de
software.
Asunto
|
Métrica
|
Coste del artículo
|
Coste por línea de código, coste por punto de función, coste por guión de uso. Esfuerzo normalizado (en una
porción definida del ciclo vital, lenguaje de programación, categoría del personal, etc.) por línea de
código, punto de función o guión de uso. Tenga en cuenta que estas medidas no suelen ser simples números,
dependen del tamaño del sistema que se va a entregar y de si la planificación está condensada.
|
Tiempo de construcción
|
Tiempo transcurrido por línea de código o por punto de función. Tenga en cuenta que esto también dependerá
del tamaño del sistema. La planificación se puede reducir añadiendo personal, aunque sólo hasta cierto
punto. Una capacidad de gestión de la empresa deteminará dónde está el límite exactamente.
|
Densidad de defectos en el producto entregado
|
Defectos (descubiertos después de la entrega) por línea de código o por punto de función.
|
Calidad subjetiva
|
Facilidad de uso, facilidad de operación, aceptación del cliente. A pesar de que estos parámetros son un
poco difusos, se han ideado maneras de realizar la cuantificación.
|
Facilidad de mantenimiento
|
Coste por línea de código o punto de función al año.
|
Perfil de habilidades, perfil de experiencia
|
El grupo de recursos humanos mantendrá algún tipo de base de datos de habilidades y de experiencia.
|
Capacidad tecnológica
|
-
Herramientas: una empresa debe saber cuáles se utilizan generalmente y el grado de especialidad de
las que no se utilizan con frecuencia.
-
Madurez del proceso: ¿Qué nivel tiene la empresa en la escala SEI CMM, por ejemplo?
-
Capacidad de dominio: ¿En qué dominios de la aplicación puede actuar la empresa?
|
Medidas de mejora de procesos
|
-
Tiempo y esfuerzo de ejecución del proceso.
-
Índices de defectos, estadísticas de análisis causal, índices de arreglos, desperdicios y revisión.
|
Antes de la entrega, debe cumplir los siguientes criterios:
-
capacidades funcionales y no funcionales necesarias
-
diferentes restricciones técnicas
-
restricciones de presupuesto y planificación
-
determinadas características de mantenimiento, funcionamiento y transición
El gestor de proyectos debe poder ver si se dirige hacia esos objetivos, ampliados en la tabla siguiente para
proporcionar una idea de los aspectos que hay que tener en cuenta de las medidas del proyecto:
Asunto
|
Presupuesto y esfuerzo del proyecto
-
¿El coste y el esfuerzo invertidos en el proyecto son los planeados?
|
Planificación del proyecto
-
¿El proyecto está cumpliendo los objetivos?
|
Transición/Instalación
-
¿Son aceptables los requisitos de habilidades, coste y esfuerzo previstos?
|
Operación
-
¿El cliente puede soportar los requisitos de habilidades y esfuerzo previstos?
|
Mantenimiento/Capacidad de soporte
-
¿Son aceptables para el cliente los requisitos de habilidades y esfuerzo previstos?
|
Requisitos funcionales
-
¿Los requisitos son válidos y completos?
-
¿Se han asignado los requisitos a una iteración?
-
¿Los requisitos se están realizando de acuerdo con lo planificado?
|
Requisitos no funcionales
-
Rendimiento
-
¿El sistema cumple los requisitos de responsabilidad, rendimiento y tiempo de recuperación?
-
Capacidad
-
¿El sistema puede manejar el número necesario de usuarios simultáneos? ¿El sitio web puede
manejar el número necesario de coincidencias por segundo? ¿La capacidad de almacenamiento
es suficiente para el número necesario de registros del cliente?
-
Factores de calidad
-
Fiabilidad: ¿Con qué frecuencia se admiten anomalías del sistema y qué constituye una
anomalía del sistema?
-
Utilización: ¿El uso del sistema es fácil y cómodo? ¿Cuánto se tarda en aprender a
utilizarlo y qué habilidades son necesarias?
-
Tolerancia a errores/ fuerza/ resistencia/ capacidad de supervivencia: ¿El sistema puede
seguir funcionando si se produce una anomalía? ¿El sistema puede manejar entradas erróneas?
¿El sistema puede recuperarse automáticamente después de una anomalía?
-
Requisitos de ingeniería de especialidad
-
Seguridad: ¿El sistema puede funcionar sin riesgo para la vida o la propiedad (tangible e
intangible)?
-
Seguridad/privacidad: ¿El sistema protege los datos sensibles del acceso no autorizado? ¿El
sistema está protegido contra el acceso malintencionado?
-
Impacto medioambiental: ¿El sistema satisface los requisitos medioambientales?
-
Otros requisitos legales o reguladores
-
Restricciones
-
Entorno externo: ¿El sistema puede funcionar en el entorno prescrito?
-
Recursos, sistema principal, destino: ¿El sistema cumple las restricciones de entorno de
hardware/software, lenguaje, memoria, CPU?
-
Utilización de software comercial de distribución general (COTS) u otro software existente:
¿El sistema cumple las restricciones de reutilización?
-
Disponibilidad y habilidades del personal: ¿El sistema se puede construir con el número y
el tipo de personal disponible?
-
Compatibilidad/ soporte de la interfaz: ¿El sistema puede soportar el acceso necesario de y
a otros sistemas?
-
Reutilización: ¿Qué previsiones se han hecho para que el sistema sea reutilizable?
-
Estándares impuestos: ¿El sistema y el método de desarrollo son acordes?
-
Otras restricciones de diseño (arquitectónicas, algorítmicas, etc?: ¿El sistema
utiliza el estilo de arquitectura necesario? ¿Se están utilizando los algoritmos
prescritos?
|
Esta es una lista amplia, aunque no exhaustiva, de los asuntos del gestor de proyectos. Muchos de estos asuntos
requieren la recopilación y el análisis de la métrica y otros también requieren el desarrollo de pruebas específicas
(para derivar las medidas) para responder a las preguntas planteadas.
Muchas de las necesidades del proyecto no tienen medidas directas y, cuando las tienen, es posible que no resulte obvio
lo que hay que hacer o cambiar para mejorarlas. Los atributos portadores de una calidad de nivel inferior se pueden
utilizar para construir calidad en comparación con varios atributos de calidad de nivel superior como los que se
identifican en el estándar ISO 9126 (Métrica y características de calidad de software) y los mencionados previamente en
las necesidades del proyecto. Estas medidas técnicas son de los efectos y las características (incluidos el proceso y
el producto) de ingeniería (estructural y de comportamiento), que contribuyen a las necesidades de métrica del nivel
del proyecto. Los atributos de la tabla siguiente se han utilizado para derivar un conjunto de ejemplo de métrica para
el proceso y los productos de trabajo de Rational Unified Process. Esto puede encontrarse en el apartado Directriz de producto de trabajo: Métrica.
Calidad
|
Atributos
|
Viabilidad de los requisitos
|
-
Volatilidad: frecuencia de cambio, índice de introducción de requisitos nuevos
-
Validez: ¿estos son los requisitos adecuados?
-
Completitud: ¿falta algún requisito?
-
Corrección de expresión: ¿los requisitos están expresados correctamente?
-
Claridad: ¿las descripciones son comprensibles y claras?
|
Viabilidad del diseño
|
-
Acoplamiento: ¿qué alcance tienen las conexiones entre los elementos del sistema?
-
Cohesión: ¿todos los componentes tienen un solo objetivo bien definido?
-
Calidad de primitivo: ¿los métodos y las operaciones de una clase se pueden construir a partir de
otros métodos y operaciones de la clase? Si es así, no son primitivos (una característica
deseable).
-
Completitud: ¿el diseño cumple totalmente los requisitos?
-
Volatilidad: frecuencia del cambio arquitectónico.
|
Viabilidad de la implementación
|
-
Tamaño: ¿cuánto le falta a la implementación para llegar al tamaño mínimo (para resolver el
problema)? ¿La implementación satisfará las restricciones?
-
Complejidad: ¿el código es difícil o complicado desde el punto de vista algorítmico? ¿Es difícil de
comprender y modificar?
-
Completitud: ¿la implementación es fiel a todo el diseño?
|
Viabilidad de la prueba
|
-
Cobertura: ¿la prueba ejecuta bien el software? ¿Todas las instrucciones se ejecutan mediante un
conjunto de pruebas? ¿La prueba ejercita muchas vías de acceso mediante el código?
-
Validez: ¿las pruebas son un reflejo correcto de los requisitos?
|
Viabilidad del proceso (en el nivel inferior)
|
-
Índice de defectos, causa de defectos: ¿cuál es la incidencia de los defectos en una tarea y cuáles
son las causas?
-
Esfuerzo y duración: ¿qué duración y cuánto esfuerzo humano requiere una actividad?
-
Productividad: por unidad de esfuerzo humano, ¿qué produce una actividad?
-
Viabilidad de los productos de trabajo: ¿cuál es el nivel de defectos en las salidas de una tarea?
|
Eficacia del proceso/ Cambio de herramientas
|
(igual que Viabilidad del proceso, pero cambia el porcentaje en vez de los valores totales):
-
Índice de defectos, causa de defectos
-
Esfuerzo y duración
-
Productividad
-
Viabilidad de los productos de trabajo
|
Si desea profundizar en el concepto de métrica, consulte [WHIT97].
Distinguimos dos clases de métrica:
-
Una medida es un atributo de una entidad que se puede medir. Por ejemplo, el esfuerzo del proyecto es una
medida del tamaño del proyecto. Para calcular esta medida debe sumar todas las reservas de la ficha de control del
proyecto.
-
Una medida primitiva es un artículo de datos brutos que se utiliza para calcular una medida. En el ejemplo
anterior, las reservas de la ficha de control son medidas primitivas. Una medida primitiva suele ser una medida que
existe en una base de datos, pero que no se interpreta aisladamente.
Cada medida se compone de una o varias medidas recopiladas. Consecuentemente, las medidas primitivas deben
identificarse claramente y debe definirse su procedimiento de recopilación.
La métrica que da soporte a los objetivos de cambio o logro suele ser una "primera derivada" a lo largo del tiempo (o
iteraciones del proyecto). Estamos interesados en una tendencia, no en el valor absoluto. Para "aumentar la calidad"
debemos comprobar que el nivel residual de defectos conocidos disminuye a lo largo del tiempo.
Plantilla de una medida
Nombre
|
Nombre de la medida y sinónimos conocidos.
|
Definición
|
Los atributos de las entidades que se miden utilizando esta medida, cómo se calcula esta medida y a partir
de qué medidas primitivas se calcula.
|
Objetivos
|
Lista de objetivos y preguntas relacionados con esta métrica. Explicación de por qué se recopilan las
medidas.
|
Procedimiento de análisis
|
Cómo se debe utilizar la métrica. Condiciones previas para la interpretación de la métrica (p.ej.,
intervalo válido de otras medidas). Tendencias o valores de destino. Modelos de herramientas y técnicas de
análisis que se deben utilizar. Suposiciones implícitas (por ejemplo, del entorno o los modelos).
Procedimientos de calibración. Almacenamiento.
|
Responsabilidades
|
Quién recopilará y agregará los datos de medición, preparará los informes y analizará los datos.
|
Plantilla de una medida primitiva
Nombre
|
Nombre de la métrica primitiva
|
Definición
|
Descripción clara de la medida en términos del entorno del proyecto
|
Procedimiento de recopilación
|
Descripción del procedimiento de recopilación. Formato y herramienta de recopilación de datos que se debe
utilizar. Puntos del ciclo vital donde se recopilan datos. Procedimiento de verificación que se debe
utilizar. Dónde se almacenarán los datos, formato, precisión.
|
Responsabilidades
|
Quién es el responsable de recopilar los datos. Quién es el responsable de verificar los datos.
|
Hay dos tareas:
-
Definir un plan de medidas
-
Recopilar medidas
La definición del plan de medidas se realiza una vez por ciclo de desarrollo; en la fase inicial, como parte de la
actividad de planificación general o, a veces, como parte de la configuración del proceso en el guión de desarrollo. Se
puede volver al plan de medidas, al igual que a otra sección del plan de desarrollo de software, durante el curso del
proyecto.
La recopilación de medidas se realiza de manera repetitiva, como mínimo una vez por iteración y, a veces, más a menudo;
por ejemplo, semanalmente en una iteración que abarca muchos meses.
Las medidas que se recopilan forman parte del documento Valoración de estado, y se utilizarán en la valoración del
progreso y la salud del proyecto. También se pueden acumular para su uso posterior en las tendencias y los cálculos del
proyecto en la empresa.
Cálculo
El gestor de proyectos en particular debe tener un plan de asignación de recursos a tareas con presupuestos y
planificaciones. El esfuerzo o la planificación se calculan a partir de un criterio de lo que se debe producir, o a la
inversa: hay una planificación y recursos arreglados y es necesario un cálculo de lo que se puede producir.
Normalmente, el cálculo está relacionado con el cálculo de las necesidades de recursos en base a otros factores,
normalmente el tamaño y la productividad, para la planificación.
Predicción
La predicción es un poco diferente del cálculo; normalmente, consiste en el cálculo del valor futuro de algún factor
basado en el valor actual de dicho factor y otros factores influyentes. Por ejemplo, dado un ejemplo de datos de
rendimiento, es útil saber (predecir) a partir de él cómo funcionará el sistema a carga completa, o en una
configuración degrada o restringida de recursos. Los modelos de predicción de la fiabilidad utilizan datos del índice
de defectos para predecir cuándo alcanzará el sistema determinados niveles de fiabilidad. Si ha planeado una actividad,
el gestor de proyectos necesitará datos para poder predecir las fechas de terminación y el esfuerzo total.
Valoración
La valoración se utiliza para establecer la posición actual para compararla con un umbral, por ejemplo, la
identificación de tendencias, para comparar alternativas o como base para el cálculo o la predicción.
Para obtener más información sobre la métrica en la gestión de proyectos, consulte [ROY98].
|