-
La métrica debe ser simple, objetiva, fácil de recopilar e interpretar, y difícil de confundir.
-
La recopilación de métricas debe estar automatizada y no debe ser intrusiva, es decir, no debe interferir con las
actividades de los desarrolladores.
-
La métrica deben contribuir en la valoración de la calidad en un estadio temprano del ciclo de vida, cuando los
esfuerzos para mejorar la calidad del software son eficaces.
-
El personal de gestión y el personal de ingeniería debe utilizar de forma activa los valores absolutos y las
tendencias de las métricas para comunicar el progreso y la calidad en un formato coherente.
-
La sección de un conjunto de métrica mínimo o más amplio depende del contexto y las características del proyecto:
si es grande o tiene requisitos de fiabilidad o seguridad rigurosos y los equipos de valoración y desarrollo tienen
amplios conocimientos sobre métrica, es posible que resulte útil recopilar y analizar la métrica técnica. El
contrato puede requerir que se recopile métrica concreta, o bien, es posible que la organización intente mejorar
sus habilidades y procesos en áreas determinadas. No existe una respuesta sencilla que se adapte a todas las
circunstancias. El gestor de proyectos debe seleccionar lo más adecuado al crear el Plan de medidas. No obstante,
cuando se presenta un programa de métrica por primera vez, lo más razonable es pecar por exceso de simplicidad.
Las métricas para ciertos aspectos del proyecto incluyen:
-
Progreso en términos de tamaño y complejidad.
-
Estabilidad en términos de velocidad de cambio en los requisitos o la implementación, tamaño o complejidad.
-
Modularidad en términos de ámbito del cambio.
-
Calidad en términos del número y el tipo de errores.
-
Madurez en términos de frecuencia de errores.
-
Recursos en términos de gastos de proyecto frente a gastos planificados
Las Tendencias son importantes, y algo más importantes de supervisar que cualquier valor absoluto en el tiempo.
Métrica
|
Objetivo
|
Medidas de muestra/perspectivas
|
Progreso
|
Planificación de la iteración
Completado
|
-
Número de clases
-
SLOC
-
Puntos de función
-
Casos de ejemplo
-
Casos de prueba
Estas medidas también se pueden recopilar por clase y por paquete
-
Cantidad de revisión por iteración (número de clases)
|
Estabilidad
|
Convergencia
|
-
Número y tipo de cambios (errores y mejoras; interfaz e implementación)
Esta medida también se puede recopilar por iteración y por paquete
-
Cantidad de revisión por iteración
|
Capacidad de adaptación
|
Convergencia
"Actualización" de software
|
-
Media de horas por persona/cambio
Esta medida también se puede recopilar por iteración y por paquete
|
Modularidad
|
Convergencia
"Trozo" de software
|
-
Número de clases/categorías modificadas por cambio
Esta medida también se puede recopilar por iteración
|
Calidad
|
Planificación de la iteración
Indicador de revisión
Criterio de release
|
-
Número de errores
-
Índice de descubrimiento de defectos
-
Densidad de defectos
-
Nivel de herencia
-
Acoplamiento de clases
-
Tamaño de la interfaz (número de operaciones)
-
Número de métodos alterados temporalmente
-
Tamaño del método
Estas medidas también se pueden recopilar por clase y por paquete
|
Madurez
|
Cobertura de la prueba/adecuación
Fuerza para utilizar
|
-
Anomalía/horas de prueba y tipo de anomalía
Esta medida también se puede recopilar por iteración y por paquete
|
Perfil de gastos
|
Perspectiva financiera
Planificada contra real
|
-
Clase/días persona
-
Personal a tiempo completo por mes
-
% presupuesto gastado
|
Incluso en los proyectos más pequeños se desea hacer un seguimiento del progreso a fin de determinar si el proyecto se
encuentra dentro de la planificación y el presupuesto y, si no es así, volver a calcular y determinar de nuevo si deben
realizarse cambios de ámbito. Por tanto, este conjunto de métrica mínimo se centra en la métrica de progreso.
-
Valor acumulado. Se utiliza para volver a calcular la planificación y el presupuesto para el resto del proyecto, y
para identificar los cambios de ámbito necesarios.
-
Tendencias de defectos. Se utiliza como ayuda al proyecto para el esfuerzo necesario para deshacerse de los
defectos.
-
Tendencia de progreso de la prueba. Se utiliza para determinar la funcionalidad que se ha completado realmente.
Se describen con detalle más abajo.
Valor acumulado
El método que se utiliza más comúnmente ([PMI96]) para medir el
progreso es el Análisis del valor acumulado.
El proceso más sencillo para medir el valor acumulado consiste en sumar el esfuerzo calculado original de todas las
tareas completadas. Un "porcentaje completo" para el proyecto se puede calcular como valor acumulado dividido por el
esfuerzo calculado original total para el proyecto. La productividad (o índice de rendimiento) es el valor acumulado
dividido por el esfuerzo real dedicado a las tareas completas.
Por ejemplo, suponga que se divide el esfuerzo de codificación en varias tareas, muchas de las cuales ahora ya se han
completado. El cálculo original para las tareas completadas era de 30 días de esfuerzo. El esfuerzo calculado total
para el proyecto era de 100 días, por lo que se puede deducir se ha completado, aproximadamente, el 30 % del proyecto.
Suponga que las tareas se han completado bajo presupuesto, y que necesita sólo 25 días para completarlas. El índice de
rendimiento es 30 / 25 = 1,2 ó 120 %.
Se puede proyectar que el proyecto se va a completar al 20 % bajo presupuesto y reducir los cálculos de acuerdo con
esto.
Consideraciones
-
El índice de rendimiento sólo se debe utilizar para ajustar cálculos para tareas similares. La terminación temprana
de las tareas de recogida de requisitos no sugiere que se complete la codificación más rápidamente. Por ello,
calcule el índice de rendimiento sólo para tipos de tareas similares y adapte los cálculos sólo para tareas
similares.
-
Tenga en cuenta otros factores. ¿Realizará las futuras tareas personal con formación similar bajo condiciones
parecidas? ¿Han contaminado los datos los "extremos", es decir, tareas que se han sobrevalorado o infravalorado en
gran medida? ¿Se informa del tiempo de modo coherente (por ejemplo, las horas extra de trabajo se deben incluir,
aunque no se paguen)?
-
¿Se tienen en cuenta los cálculos de las tareas más recientes para el índice de rendimiento? Si es así, los
cálculos de las tareas más recientes tendirán a acercarse más al destino, elevando el índice de rendimiento próximo
al 100 %. Debe volver a calcular de modo coherente todas las tareas incompletas, o bien, adoptar la práctica
siguiente de XP (Extreme Programming)[JEF01]. Haga
referencia a los cálculos originales como "puntos" y mida las nuevas tareas en términos de estos mismos "puntos",
sin ajustar el rendimiento real. La ventaja de los "puntos" es que se puede hacer un seguimiento de los aumentos (o
reducciones) del rendimiento ("velocidad de proyecto" en la terminología de XP).
Si las tareas son largas (más de 5 días), o hay un gran número de tareas completas parcialmente, es posible que desee
descomponerlas en factores en el análisis. Aplique un "porcentaje de terminación" subjetivo, multiplíquelo por el
cálculo de esfuerzo de la tarea e inclúyalo en el valor acumulado. Se obtiene mayor coherencia en los resultados si
existen reglas claras para asignar el porcentaje completo. Por ejemplo, una regla podría ser que no se asigna más del
80 % completada a una tarea de codificación hasta que el código haya pasado una revisión de código.
El valor acumulado se trata más adelante, en la sección Un conjunto de métrica completo: Plan
del proyecto.
Tendencia de defectos
Con frecuencia, resulta útil hacer un seguimiento de la tendencia de los defectos abiertos y cerrados. Ofrece una
indicación aproximada sobre si existe una acumulación importante de trabajo de arreglo de defectos que completar y con
qué rapidez se cierran.
Las tendencias de defectos sólo son una de las métricas que proporciona Rational ProjectConsole.
Consideraciones
-
Todas las solicitudes de cambio no deben tener igual peso, si afectan a una línea de código o provocan un rediseño
más importante. Se puede tratar por medio de algunas de las técnicas siguientes:
-
Conozca los extremos. Las solicitudes de cambio que requieren un trabajo considerable se deben identificar
como tales y hacer un seguimiento de las mismas como tareas separadas, no empaquetar en un depósito de
arreglo de errores general. Si un gran número de arreglos minúsculos domina la tendencia, considere la
posibilidad de agruparlos de modo que cada Solicitud de cambio represente una unidad de trabajo más
coherente.
-
Puede registrar más información como, por ejemplo, una "categoría de esfuerzo" subjetivo de "menor de 1
día" "1 día" "menos de 5 días" o "más de 5 días".
-
Puede registrar SLOC calculados y SLOC reales para cada solicitud de cambio. Consulte el apartado Un pequeño conjunto de métrica, que encontrará más abajo.
-
La falta de defectos registrados puede implicar una falta de prueba. Conozca el nivel de esfuerzo de prueba que se
produce al examinar tendencias de defectos.
Tendencia de progreso de la prueba
La última medida de completitud es la funcionalidad integrada.
Si cada una de las tareas de desarrollo representa un conjunto de funciones integradas, un gráfico de tendencia de
valor acumulado puede ser suficiente.
Un procedimiento muy sencillo para comunicar el progreso es con una Tendencia de progreso de la prueba.
Consideraciones
Algunos casos de prueba pueden representar considerablemente más valor o esfuerzo que otros. No le atribuya una
excesiva importancia a este gráfico, sólo proporciona algún tipo de garantía de que se progresa hacia la funcionalidad
completa.
Para muchos proyectos, el conjunto de métrica mínimo descrito previamente no es suficiente.
Software Project Management, a Unified framework [ROY98], recomienda el
conjunto de métrica siguiente para todos los proyectos. Tenga en cuenta que esta métrica requiere cifras reales y
estimadas de SLOC (Líneas de código fuente) para cada solicitud de cambio, cuya recogida requiere algo de esfuerzo
adicional.
Métrica y métrica primitiva
SLOC total
|
SLOCt = Tamaño total calculado del código. Puede cambiar considerablemente a medida que se comprenden
mejor los requisitos y se maduran las soluciones de diseño. Incluye software reutilizado que está
sujeto a cambios por parte del equipo.
|
SLOC en un control
de configuración
|
SLOCc = Línea base actual
|
Defectos críticos
|
SCO0 = número de tipo SCO 0 (donde SCO es un Pedido de cambio de software - otro término para Solicitud
de cambio)
|
Defectos normales
|
SCO1 = número de tipo SCO 1
|
Solicitudes de mejora
|
SCO2 = número de tipo SCO 2
|
Nuevas características
|
SCO3 = número de tipo SCO 3
|
Número de SCO
|
N = SCO0 + SCO1 + SCO2
|
Revisión abierta (rotura)
|
B = SLOC rota acumulativa debido a SCO1 y SCO2
|
Revisión cerrada (arreglos)
|
F = SLOC arreglada acumulativa
|
Esfuerzo de revisión
|
E = esfuerzo acumulativo gastado arreglando tipo SCO 0/1/2
|
Tiempo de uso
|
UT = horas que ha funcionado una línea base determinada en casos de ejemplo de uso realistas
|
Métrica de calidad para el producto final
De este pequeño conjunto de métrica se pueden derivar métricas más interesantes:
Proporción de trozos
|
B/SLOCt, porcentaje de producto descartado
|
Porcentaje de revisión
|
E/esfuerzo total, porcentaje de esfuerzo de revisión
|
Modularidad
|
B/N, rotura promedio por SCO
|
Capacidad de adaptación
|
E/N, esfuerzo promedio por SCO
|
Madurez
|
UT/(SCO0 + SCO1), Tiempo medio entre defectos
|
Mantenimiento
|
(proporción de trozos)/(proporción de revisión), productividad de mantenimiento
|
Indicadores en curso
Estabilidad de las revisiones
|
B - F, rotura en contraposición a arreglos en el tiempo
|
Acumulación de revisiones
|
(B-F)/SLOCc, revisión abierta actualmente
|
Tendencia de modularidad
|
Modularidad, en el tiempo
|
Tendencia de adaptabilidad
|
Adaptabilidad, en el tiempo
|
Tendencia de madurez
|
Madurez, en el tiempo
|
Se debe medir lo siguiente:
-
el Proceso - la secuencia de tareas invocadas para producir el producto de software (y otros productos
de trabajo);
-
el Producto - los productos de trabajo del proceso, incluido el software, los documentos y los modelos;
-
el Proyecto - la totalidad de los productos de trabajo, las tareas y los recursos del proyecto;
-
los Recursos - las personas, los métodos y las herramientas, el tiempo, el esfuerzo y el presupuesto,
disponibles para el proyecto.
Para caracterizar por completo el proceso, se deben tomar medidas en el nivel inferior de la tarea planificada
formalmente. El gestor de proyectos planifica las tareas gracias a un conjunto de cálculos inicial. A continuación, se
debe mantener un registro de los valores reales en el tiempo y de todos los cálculos actualizados que se realizan.
Métrica
|
Comentarios
|
Duración
|
Tiempo transcurrido para la tarea
|
Esfuerzo
|
Unidades de esfuerzo de personal (horas del personal, días del personal, ...)
|
Salida
|
Productos de trabajo y su tamaño y cantidad (tenga en cuenta que incluye los defectos como una salida
de las actividades de la prueba)
|
Uso del entorno de desarrollo de software
|
CPU, almacenamiento, herramientas de software, equipo (estaciones de trabajo, PC), disponibles. Tenga
en cuenta que la autoridad de entorno de ingeniería de software (SEEA) los puede recopilar para un
proyecto.
|
Defectos, índice de descubrimiento, índice de corrección.
|
También se debe medir el tiempo/esfuerzo total de reparación y revisión/descarte total (siempre que se
pueda medir); probablemente procedan de la información recopilada comparada con los defectos
(considerados como productos de trabajo).
|
Solicitudes de cambio, índice de imposición, índice de desechos.
|
Comentarios como más arriba para tiempo/esfuerzo.
|
Otros incidentes que pueden tener una relación con estas métricas (texto de formato libre)
|
Es una métrica en la que hay un registro de un suceso que ha afectado al proceso.
|
Personal, perfil (en el tiempo) y características
|
|
Rotación del personal
|
Una métrica útil que puede explicar en una revisión posmortem porqué un proceso se ha desarrollado
especialmente bien, o mal.
|
Aplicación de esfuerzo
|
El modo en el que se gasta el esfuerzo durante el rendimiento de las actividades planeadas (contra el
que se debería registrar formalmente el tiempo para la gestión de cuentas de costes) puede ayudar a
explicar las variaciones en la productividad: algunas subclases de la aplicación de esfuerzo son, por
ejemplo:
-
formación
-
familiarización
-
gestión (por iniciativa de equipo, por ejemplo)
-
administración
-
investigación
-
trabajo productivo. Resulta útil registrarlo por producto de trabajo e intentar separar el
tiempo de "ideas" y el tiempo de captura, en especial para los documentos. De este modo, se
indica al gestor de proyectos cuál es el nivel de imposición del proceso de documentación en el
tiempo de ingeniero.
-
tiempo perdido
-
reuniones
-
inspecciones, ensayos, revisiones - preparación y esfuerzo de reunión (algunas
serán actividades separadas y el tiempo y el esfuerzo dedicados se registran para una tarea de
revisión específica)
|
Inspecciones, ensayos, revisiones (durante una tarea, no revisiones planificadas por separado)
|
Registrar los números de estas y su duración, así como los números de las cuestiones planteadas.
|
Desviaciones del proceso (planteadas como incumplimientos y que requieren cambio de proyecto)
|
Registrar los números y la gravedad de las mismas. Es un indicador de que es posible que se requiera
más educación, de que el proceso no se aplica adecuadamente, o bien, de que el modo en el que se ha
configurado el proceso no era correcto
|
Problemas del proceso (planteadas como defectos de proceso y que requieren cambio de proceso)
|
Registrar el número y la gravedad de las mismas. Esta información puede ser de gran utilidad en las
revisiones posmortem y es una información de retorno esencial para la autoridad de proceso de
ingeniería de programas (SEPA).
|
Los productos de Rational Unified Process (RUP) son los Productos
de trabajo, que son documentos, modelos o elementos de modelo. Los modelos son recopilaciones de cosas parecidas
(los elementos de modelo), por lo que aquí se listan las métricas recomendadas con los modelos a los que se aplican:
normalmente, resulta obvio si una métrica se aplica al modelo en conjunto, o a un elemento. En aquellos casos en los
que no está claro, se facilita texto explicativo.
Características del producto de trabajo
Por lo general, las características que interesa medir son las siguientes:
-
Tamaño - medida del número de cosas en un modelo, la longitud de algo, el alcance o la masa de algo
-
Calidad
-
Defectos - indicaciones de que un producto de trabajo no funciona según se ha especificado, de
que no cumple con su especificación, o bien, de que tiene otras características no recomendables.
-
Complejidad - medida de lo intrincado de una estructura o algoritmo: cuanto mayor sea la
complejidad, más difícil será comprender y modificar una estructura, y es un hecho que las estructuras
complejas tienen más probabilidades de dar error
-
Acoplamiento - medida de hasta qué punto están interconectados los elementos de un sistema
-
Cohesión - medida del nivel de cumplimiento del requisito de tener un objetivo único y bien
definido por parte de un elemento o componente
-
Calidad de primitivo - grado hasta el que las operaciones o los métodos de una clase puede
constar de otros que ofrece la clase
-
Completitud - medida del nivel de cumplimiento de todos los requisitos por parte de un producto
de trabajo (especificado e implícito-el gestor de proyectos debe esforzarse a fin de explicitar lo
máximo posible con el objeto de limitar el riesgo de expectativas no satisfechas). En este punto no se ha
optado por diferenciar entre suficiente y completa.
-
Rastreabilidad - indicación de que los productos de trabajo han satisfecho los requisitos en un nivel,
en un nivel inferior y, por otra parte, que un producto de trabajo de cualquier nivel tiene un motivo para
existir
-
Volatilidad - nivel de cambio o carácter inconcluyente de un producto de trabajo debido a defectos o
requisitos cambiantes
-
Esfuerzo - medida del trabajo (unidades de tiempo del personal) que se necesita para producir un
producto de trabajo
No todas estas características se aplican a todos los productos de trabajo: las más importantes se elaboran con el
producto de trabajo concreto en las tablas siguientes. Donde se listan numerosas métricas para una característica,
todas pueden ser de interés, puesto que ofrecen una descripción completa de la característica desde varios puntos de
vista. Por ejemplo, cuando se considera la rastreabilidad de los casos de uso, finalmente, todos se tienen que poder
rastrear hasta un modelo de implementación (probado): entretanto, el gestor de proyectos sigue interesado en saber
cuántos casos de uso se pueden rastrear para el modelo de análisis, como medida de progreso.
Documentos
La métrica recomendada se aplica a todos los documentos de RUP.
Característica
|
Métrica
|
Tamaño
|
Recuento de páginas
|
Esfuerzo
|
Unidades de tiempo del personal para producción, cambios y reparaciones
|
Volatilidad
|
Número de cambios, defectos, abiertos, cerrados: cambiar páginas
|
Calidad
|
Medida directamente a través del recuento de defectos
|
Completitud
|
No se mide directamente: se juzga a través de la revisión
|
Rastreabilidad
|
No se mide directamente: se juzga a través de la revisión
|
Modelos
Requisitos
Atributos de requisitos
En realidad, es un elemento de modelo.
Característica
|
Métrica
|
Tamaño
|
-
número de requisitos en total (= Nu+Nd+Ni+Nt)
-
número a rastrear para casos de uso ( = Nu)
-
número a rastrear sólo para diseño, implementación, prueba ( = Nd)
-
número a rastrear sólo para implementación, prueba ( = Ni)
-
número a rastrear sólo para prueba ( = Nt)
Recuerde que esto particiona los requisitos entre los que van a modelar los casos de uso y los
que no. La expectativa es que la rastreabilidad de los casos de uso tenga en cuenta los
requisitos asignados a casos de uso, para hacer un seguimiento del diseño, la implementación y
la prueba.
|
Esfuerzo
|
-
Unidades de tiempo del personal (producción, cambios y reparaciones)
|
Volatilidad
|
-
Número de defectos y solicitudes de cambio
|
Calidad
|
-
Número de defectos, por gravedad
|
Rastreabilidad
|
|
modelo de caso de uso
Característica
|
Métrica
|
Tamaño
|
-
Número de casos de uso
-
Número de paquetes de casos de uso
-
Nivel de caso de uso notificado (consulte la documentación, "The Estimation of
Effort and Size based on Use Cases" del sitio web de IBM)
-
Número de casos de ejemplo, total y por caso de uso
-
Número de actores
-
Longitud del caso de uso (por ejemplo, páginas de flujo de sucesos)
|
Esfuerzo
|
-
Unidades de tiempo del personal con producción, cambios y reparaciones
|
Volatilidad
|
-
Número de defectos y solicitudes de cambio
|
Calidad
|
-
Complejidad notificada (0-5, por analogía con COCOMO [BOE81], a nivel de clase; el rango de complejidad es más
reducido cuanto mayores son los niveles de abstracción - consulte la documentación, "The
Estimation of Effort and Size based on Use Cases" del sitio web de IBM)
-
Defectos - número de defectos, por gravedad, abiertos, cerrados
|
Completado
|
-
Guiones de uso completados (revisados y bajo gestión de la configuración sin defectos
pendientes)/casos de uso identificados (o número de casos de uso calculados)
-
Rastreabilidad de los requisitos para UC
(de atributos de requisitos)
|
Rastreabilidad
|
-
Análisis
-
Casos de ejemplo realizados en casos de ejemplo totales/modelo de análisis
-
Diseño
-
Casos de ejemplo realizados en casos de ejemplo totales/modelo de diseño
-
Implementación
-
Casos de ejemplo realizados en casos de ejemplo totales/modelo de implementación
-
Prueba
-
Casos de ejemplo realizados en casos de ejemplo totales/modelo de prueba (casos de
prueba)
|
Diseño
Modelo de análisis
Característica
|
Métrica
|
Tamaño
|
-
Número de clases
-
Número de subsistemas
-
Número de subsistemas de subsistemas ...
-
Número de paquetes
-
Métodos por clase, internos, externos
-
Atributos por clase, internos, externos
-
Nivel de árbol de herencia
-
Número de hijos
|
Esfuerzo
|
-
Unidades de tiempo del personal para producción, cambios y reparaciones
|
Volatilidad
|
-
Número de defectos y solicitudes de cambio
|
Calidad
|
Complejidad
|
-
Respuesta para una clase (RFC): puede resultar difícil calcularlo, puesto que se necesita
un conjunto completo de diagramas de interacción.
|
Acoplamiento
|
-
Número de hijos
-
Acoplamiento entre objetos (ramificación de clases)
|
Cohesión
|
|
Defectos
|
-
Número de defectos, por gravedad, abiertos, cerrados
|
Completado
|
|
Rastreabilidad
|
No aplicable-el modelo de análisis se convierte en el modelo de diseño.
|
Aquí se muestra métrica técnica específica de OO con la que es posible que no esté familiarizado-nivel de árbol
de herencia, número de hijos, respuesta para una clase o acoplamiento entre objetos, entre otras. Consulte [HEND96] para obtener información detallada sobre el significado y la historia de
dicha métrica. Originalmente, Chidamber and Kemerer sugirieron gran parte de esta métrica (consulte "A metrics suite
for object oriented design", IEEE Transactions on Software Engineering, 20(6), 1994), pero aquí se ha aplicado tal como
se sugiere en [HEND96], y se preferido la definición de LCOM (falta de cohesión en los métodos) que
se presenta en dicho trabajo.
Modelo de diseño
Característica
|
Métrica
|
Tamaño
|
-
Número de clases
-
Número de subsistemas de diseño
-
Número de subsistemas de subsistemas ...
-
Número de paquetes
-
Métodos por clase, internos, externos
-
Atributos por clase, internos, externos
-
Nivel de árbol de herencia
-
Número de hijos
|
Esfuerzo
|
-
Unidades de tiempo del personal (para producción, cambios y reparaciones)
|
Volatilidad
|
-
Número de defectos y solicitudes de cambio
|
Calidad
|
Complejidad
|
-
Respuesta para una clase (RFC): puede resultar difícil calcularlo, puesto que se necesita
un conjunto completo de diagramas de interacción.
|
Acoplamiento
|
-
Número de hijos
-
Acoplamiento entre objetos (ramificación de clases)
|
Cohesión
|
|
Defectos
|
-
Número de defectos, por gravedad
|
Completado
|
|
Rastreabilidad
|
Número de clases en modelo de implementación/número de clases
|
Implementación
Modelo de implementación
Característica
|
Métrica
|
Tamaño
|
-
Número de clases
-
Número de archivos
-
Número de subsistemas de implementación
-
Número de subsistemas de subsistemas ...
-
Número de paquetes
-
Métodos por clase, internos, externos
-
Atributos por clase, internos, externos
-
Tamaño de métodos*
-
Tamaño de atributos*
-
Nivel de árbol de herencia
-
Número de hijos
-
Tamaño calculado* al terminar
|
Esfuerzo
|
-
Unidades de tiempo del personal (con producción, cambios y reparaciones separados)
|
Volatilidad
|
-
Número de defectos y solicitudes de cambio
-
Ruptura* para cada cambio correctivo o perfectivo, calculado (antes del arreglo) y real (al
concluir)
|
Calidad
|
Complejidad
|
-
Respuesta para una clase (RFC)
-
Complejidad ciclomática de los métodos**
|
Acoplamiento
|
-
Número de hijos
-
Acoplamiento entre objetos (ramificación de clases)
-
Mensaje pasando acoplamiento (MPC)***
|
Cohesión
|
-
Número de hijos
-
LCOM (falta de cohesión en los métodos)
|
Defectos
|
-
Número de defectos, por gravedad, abiertos, cerrados
|
Completado
|
|
* Se debe elegir y aplicar de modo coherente algún método para medir el tamaño de código, por ejemplo, sin comentarios,
sin espacios vacíos. Consulte [ROY98], donde se
tratan los méritos y la aplicación de "líneas de código" como una métrica. En la misma referencia, consulte la
definición de "ruptura".
** El uso de la complejidad ciclomática no se acepta universalmente, en especial, cuando se aplica a los métodos de una
clase. Consulte [HEND96], donde se trata esta métrica.
*** Originalmente, de Li and Henry, "Object-oriented metrics that predict maintainability", J. Systems and Software,
23(2), 1993, y también descrito en [HEND96].
Prueba
Modelo de prueba
Característica
|
Métrica
|
Tamaño
|
-
Número de casos de prueba, procedimientos de prueba, scripts de prueba
|
Esfuerzo
|
-
Unidad de tiempo del personal (con producción, cambios y reparaciones separados) para
producción de casos de prueba, entre otros
|
Volatilidad
|
-
Número de defectos y solicitudes de cambio emitidos contra el modelo de prueba
|
Calidad
|
-
Defectos - número de defectos por gravedad, abiertos, cerrados (son defectos
planteados en comparación con el modelo de prueba en sí mismo, no defectos que plantea el
equipo de prueba en comparación con otro software)
|
Completitud
|
|
Rastreabilidad
|
-
Número de casos de prueba sobre los que se ha informado como satisfactorios en el Resumen
de evaluación de prueba de casos de uso
|
Gestión
Modelo de cambio -modelo nocional para la coherencia en la presentación- la métrica que se recopila
del sistema se utiliza para gestionar solicitudes de cambio.
Característica
|
Métrica
|
Tamaño
|
-
Número de defectos, solicitudes de cambio por gravedad y estado, también clasificados por
categorías como número de cambios perfectivos, número de cambios de adaptación y número de
cambios correctivos.
|
Esfuerzo
|
-
Esfuerzo de reparación de defectos, esfuerzo de implementación de cambios en unidades de
tiempo del personal
|
Volatilidad
|
-
Ruptura (calculada, real) para el subconjunto del modelo de implementación
|
Completado
|
-
Número de defectos descubiertos/número de defectos pronosticados (si se utiliza un modelo
de fiabilidad)
|
Plan del proyecto (sección 4.2 del Plan de desarrollo de
software)
Son medidas que proceden de la aplicación de Técnica de aplicación para la gestión de proyectos: juntas se
denominan Cost/Schedule Control Systems Criteria (C/SCSC). Una técnica de valor acumulado descrita más arriba como
parte de Un conjunto de métrica mínimo. Se pueden llevar a cabo
análisis más detallados utilizando métrica relacionada, incluidas:
-
BCWS, Budgeted Cost for Work Scheduled
-
BCWP, Budgeted Cost for Work Performed
-
ACWP, Actual Cost of Work Performed
-
BAC, Budget at Completion
-
EAC, Estimate at Completion
-
CBB, Contract Budget Base
-
LRE, Latest Revised Estimate (EAC)
factores derivados para la variación de coste y planificación. Consulte [ROY98], donde se
trata la aplicación de una propuesta de valor acumulado a la gestión de proyectos de software.
El proyecto se debe caracterizar en términos de tipo, tamaño, complejidad y formalidad (aunque, por lo general, el
tipo, el tamaño y la complejidad determinan la formalidad), puesto que estos aspectos condicionan las expectativas
sobre distintos umbrales para medidas de nivel inferior. Se deben capturar otras restricciones en el contrato (o
especificaciones). La métrica derivada del proceso, el producto y los recursos captura el resto de la métrica a nivel
del proyecto. El dominio y el tipo de proyecto se pueden registrar por medio de una descripción de texto, asegurándose
de que se detalla lo suficiente para caracterizar con precisión el proyecto. Registre el tamaño del proyecto por el
coste, el esfuerzo, la duración, el tamaño del código que desarrollar y los puntos de función que entregar. La
complejidad del proyecto se puede describir -algo subjetivamente-situando el proyecto en un gráfico en el que se
muestre la complejidad técnica y de gestión con respecto a otros proyectos completados. [ROY98], la Figura 14-1 muestra un diagrama.
La métrica derivada descrita en [ROY98], que son los
indicadores principales del gestor de proyectos, se puede obtener de la métrica recogida para el producto y el proceso.
Son las siguientes:
-
Modularidad = ruptura promedio (NCNB*) por cambio correctivo o perfectivo en el modelo de implementación
-
Adaptabilidad = esfuerzo promedio por cambio correctivo o perfectivo en el modelo de implementación
-
Madurez = número/tiempo prueba activa de cambios correctivos
-
Mantenimiento = Productividad de mantenimiento/productividad de desarrollo = [arreglos acumulativos
reales/esfuerzo acumulativo por cambios correctivos y perfectivos]/[número calculado de NCNB al terminar/esfuerzo
de producción calculado al terminar]
-
Estabilidad de revisión = ruptura acumulativa-arreglos acumulativos
-
Acumulación de revisiones = [ruptura acumulativa-arreglos acumulativos]/unidad NCNB probada
* NCNB es tamaño de código sin comentarios y sin espacios vacíos.
Se debe informar del progreso desde el plan del proyecto utilizando la métrica de terminación del producto de trabajo -
con peso concreto (desde una perspectiva de valor acumulado) que proporciona la producción del software de trabajo.
Si se utiliza un modelo de cálculo como, por ejemplo, COCOMO (consulte [BOE81], se deben
registrar los distintos factores de escala y controladores de costes. En realidad, forman una caracterización bastante
detallada del proyecto.
Los elementos que medir incluyen personal (experiencia, formación, coste, rendimiento), métodos y herramientas (en
términos de efecto en la productividad, la calidad y el coste), tiempo, esfuerzo, presupuesto (recursos consumidos,
recursos restantes).
El perfil del personal se debe registrar a lo largo del tiempo, mostrando el tipo (analista o diseñador, por ejemplo),
el grado (que implica el coste) y el equipo al que se ha asignado. Se deben registrar tanto las cifras reales como las
planeadas.
El modelo COCOMO requiere la caracterización del entorno de desarrollo de software, así como la posibilidad y
experiencia personales, para que se constituya una infraestructura adecuada en la que mantener esta métrica.
La información sobre gastos, presupuesto y planificación proceden del plan del proyecto.
|