Metricas y analisis de software
En este capítulo, presentamos medidas que se pueden utilizar para evaluar la calidad del
producto durante su diseño. También presentamos medidas que se pueden utilizar para
ayudar a gestionar proyectos de software. Estas medidas le proporcionan una indicación en
tiempo real de la eficacia de sus procesos de software (análisis, diseño, pruebas) y la
calidad general del software durante su desarrollo.
Medición de software
La ciencia de datos se ocupa de la medición, el aprendizaje automático y la predicción de
eventos futuros en función de estas medidas. La medición asigna números o símbolos a los
atributos de las entidades en el mundo real. Para lograr esto, se requiere un modelo de
medición que abarque un conjunto consistente de reglas.
Medidas, métricas e indicadores
Informalmente se usan para hacer referencia a lo mismo pero no es así y es importante ver
las sutiles diferencias que hay entre ellas.
Si se recopiló un solo punto de datos estamos hablando de medida, por ejemplo errores
descubiertos en un solo componente.
Si se recopiló uno o más puntos de datos estamos hablando de medición, por ejemplo
errores descubiertos en varios componentes y varias pruebas unitarias para recopilar
medidas.
Un indicador es una métrica o una combinación de métricas que proporciona información
sobre el proceso de software, un proyecto de software o el producto en sí.
El IS recopila medidas y desarrolla métricas para la obtención de indicadores.
Atributos de las métricas de software eficaces
Las métricas deben ser fáciles de usar y tienen que tener un apoyo práctico para el IS, es
decir, deben ser fáciles de calcular, estas además son las que se usan en la actualidad. Por
otra parte, si se utilizan muchos cálculos en las métricas es difícil que se usen y algunos
pocos profesionales tienen esperanza de entenderlas y esto claramente no escala.
La métrica siempre debería producir resultados que sean correctos y exactos.
Las métricas deben basarse en el modelo de requisitos, el modelo de diseño o la estructura
del programa en sí. No deben depender de la sintaxis o la semántica del lenguaje de
programación. Por último, la métrica debe proporcionar información que pueda conducir a
un producto final de mayor calidad.
Análisis de software
Las métricas de software sirven simplemente para medir la calidad o rendimiento del
producto o proceso. Mientras que el análisis de software sirve para proporcionar información
que sirve para gerentes e ingenieros del proyecto en cuestión y que tomen mejores
decisiones. Por ejemplo, es mejor saber hoy en día que la cantidad de defectos es un 5%
menos que el mes pasado a saber cuantos defectos hay porque esto ya no te sirve de
mucho. En base a los análisis permite crear cronogramas incrementales que se utilizan para
determinar los tiempos de finalización esperados.
Además pueden ayudar a los desarrolladores a tomar decisiones como:
_ Pruebas dirigidas: Pruebas de regresión y pruebas de integración.
_ Refactorización dirigida: Estrategias sobre como evitar grandes costos de deuda técnica.
_ Planificación de lanzamiento: Tener en cuenta las necesidades del mercado.
_ Comprensión de los clientes: Entender el uso del producto por parte de los clientes.
_ Evaluación de la estabilidad: Monitoreo del estado del prototipo y anticipo de las
necesidades del mismo
_ Inspección dirigida: Determinar el valor de las actividades de las inspecciones
individuales, la frecuencia y alcance.
Métricas de producto
Durante los últimos años, muchos desarrolladores han intentado desarrollar una única
métrica que proporcione una medida exhaustiva de la complejidad del software, sin
embargo esto es muy complicado ya que cada uno tiene una visión distinta de lo que es la
complejidad. Consideremos el hecho de evaluar un auto por lo lindo que es, algunas
personas podrían tener el foco en la carrocería, otros en las características mecánicas,
algunos en el coste del auto, en el rendimiento, etc. Esto mismo sucede con el software.
Como es de gran dificultad derivar un único valor de la métrica de calidad, entonces debería
ser posible desarrollar medidas de diferentes atributos internos del programa. Estas
medidas y las métricas derivadas de ellas pueden utilizarse como indicadores
independientes de la calidad.
Métricas para el modelo de requisitos
En esta temprana etapa es deseable disponer de métricas de producto que permitan
conocer la calidad del modelo de análisis.
Estas métricas de estimación examinan el modelo de requisitos con la intención de predecir
el tamaño del sistema resultante. El tamaño es a veces (pero no siempre) un indicador de la
complejidad del diseño y es casi siempre un indicador de un mayor esfuerzo de codificación,
integración y pruebas.
Software convencional. Características que pueden utilizarse para evaluar la calidad del
modelo de requisitos: especificidad, integridad, corrección, compresibilidad, verificabilidad,
coherencia interna y externa, alcanzabilidad, concisión, trazabilidad, modificabilidad,
precisión y reutilizabilidad.
Software de celulares. Las medidas y métricas utilizadas en los proyectos tradicionales
son difíciles de trasladar directamente a las aplicaciones móviles. Sin embargo, se pueden
desarrollar medidas que pueden servir de base para crear métricas de aplicaciones móviles.
Entre las medidas se encuentran las siguientes:
● Número de pantallas estáticas. Estas páginas representan una complejidad y
esfuerzo relativamente bajos. Proporciona una indicación del tamaño global de la
aplicación y del esfuerzo necesario para desarrollarla.
● Número de pantallas dinámicas. Estas páginas representan una mayor complejidad
y esfuerzo para construirlas que las páginas estáticas. Proporciona una indicación
del tamaño global de la aplicación y del esfuerzo necesario para desarrollarla.
● Número de objetos de datos persistentes. A medida que aumenta el número de
objetos de datos persistentes (por ejemplo una base de datos), aumenta la
complejidad y el esfuerzo para implementar la aplicación móvil.
● Número de sistemas externos conectados. A medida que aumentan los requisitos de
interconexión, también aumenta la complejidad del sistema y el esfuerzo de
desarrollo.
● Número de objetos de contenido estático. Estos objetos representan una
complejidad relativa baja y su construcción requiere menos esfuerzo que la de las
páginas dinámicas.
● Número de objetos de contenido dinámico. Estos objetos representan una mayor
complejidad relativa y requieren más esfuerzo para construirlos que las páginas
estáticas.
● Número de funciones ejecutables. A medida que aumenta el número de funciones
ejecutables también aumentan los esfuerzos de modelado y construcción.
Métricas de diseño para software convencional
Las métricas de diseño arquitectónico se centran en las características de la arquitectura del
programa, haciendo hincapié en la estructura arquitectónica y la eficacia de los módulos o
componentes dentro de la arquitectura. Estas métricas son de caja negra en el sentido de
que no requieren ningún conocimiento del funcionamiento interno de un componente de
software concreto.
Métricas de diseño para software orientado a objetos
Se proponen 6 métricas de diseño basadas en clases para sistemas OO:
● Métodos ponderados por clase: Dada una clase y la complejidad de cada método de
esa misma clase, sumamos la complejidad de cada método. A medida que aumenta
el número de métodos, más complejo es el árbol de herencia, además también limita
su posible reutilización.
● Profundidad del árbol hereditario: Es la longitud máxima desde el nodo hasta la raíz
del árbol. Mientras más crece este valor es probable que las clases de nivel inferior
hereden muchos métodos lo cual hace más complicado el predecir el
comportamiento de una clase. Sin embargo, esto implica que a su vez también hay
una gran cantidad de métodos los cuales pueden ser reutilizados.
● Número de hijos: Hace referencia a las subclases inmediatamente subordinadas a
una clase. A medida que aumenta el número de hijos, aumenta la reutilización, pero
también la abstracción que representa la clase padre puede verse en conflicto si
alguno de los hijos no es miembro de la clase padre. A mayor número de hijos
también aumenta la cantidad de pruebas.
● Acoplamiento entre clases objeto: Es el número de colaboraciones que aparecen
para una clase. A medida que aumenta este número es probable que disminuya la
utilidad de la clase.
● Conjunto de respuesta de una clase: Es un conjunto de métodos que potencialmente
pueden ser ejecutados en respuesta a un mensaje recibido por un objeto de esa
clase. A medida que este número aumenta también aumenta el esfuerzo necesario
para realizar pruebas y la complejidad general del diseño de la clase.
● Falta de cohesion en los métodos: Es el número de métodos que acceden a uno o
más de los mismos atributos. Si este número es alto, los métodos pueden estar
acoplados entre sí a través de atributos, lo cual aumenta la complejidad del diseño
de la clase.
Métricas de diseño de la interfaz de usuario
Las métricas de la interfaz de usuario pueden ser útiles en algunos casos, el árbitro final
debería ser la información proporcionada por el usuario en función de los prototipos de
GUI(graphical user interface).
En lo que sigue se ve métricas de diseño que pueden tener aplicación para sitios web,
aplicaciones basadas en navegador y aplicaciones móviles. Estas métricas son aplicables a
todas las interfaces de usuario. Por otra parte hay que decir que varias de estas métricas no
han sido validadas aún, por eso hay que usarlas sabiendo las consecuencias.
Métricas para el código fuente
Halstead asignó leyes cuantitativas al desarrollo del software de computadoras, utilizando
un conjunto de medidas primitivas que pueden derivarse después de que se genera el
código o estimarse una vez que se completa el diseño.
Las medidas son:
n1 = número de operadores distintos que aparecen en un programa
n2 = número de operandos distintos que aparecen en un programa
N1 = número total de ocurrencias de operadores
N2 = número total de ocurrencias de operandos
Halstead usa estas medidas primitivas para desarrollar expresiones para la longitud total del
programa, el volumen mínimo potencial para un algoritmo, el volumen real (número de bits
necesarios para especificar un programa), el nivel del programa (una medida de la
complejidad del software), el nivel del lenguaje (una constante para un lenguaje
determinado) y otras características como el esfuerzo de desarrollo, el tiempo de desarrollo
e incluso el número proyectado de fallos en el software.
Métricas para pruebas
Se dividen en 2 categorías:
1) Métricas que intentan predecir la cantidad de pruebas necesarias en varios niveles
de prueba
2) Métricas que se centran en la cobertura de pruebas para un componente elegido.
En general los analistas deben confiar en las métricas de análisis, diseño y código para una
guía para el diseño y la ejecución de los casos de prueba.
La complejidad ciclomática es una métrica a nivel de componente se usa para identificar
módulos como candidatos para pruebas unitarias largas. Obviamente los módulos con alta
complejidad ciclomática tienden a tener más errores que los que tienen baja, por esto hay
más esfuerzo en los de complejidad ciclomática alta, antes de hacer test de integración.
Las pruebas orientadas a objetos pueden ser difíciles. Las métricas de diseño orientadas a
objetos que se indican en la Sección 23.3.3 proporcionan una indicación de la calidad del
diseño. También proporcionan una indicación general de la cantidad de esfuerzo de prueba
necesario para poner a prueba un sistema orientado a objetos. Las métricas consideran
aspectos de encapsulación y herencia.
Acceso público a miembros de datos (PAD). APD en el teórico. Esta métrica indica la
cantidad de clases (o métodos) que pueden acceder a los atributos de otra clase, una
violación de la encapsulación. Los valores altos de PAD conducen al potencial de efectos
secundarios entre clases. Las pruebas deben diseñarse para garantizar que se descubran
dichos efectos secundarios. Hay más métricas de encapsulamiento.
Número de clases raíz (NOR). Esta métrica es un recuento de las distintas jerarquías de
clases que se describen en el modelo de diseño. Se deben desarrollar conjuntos de pruebas
para cada clase raíz y la jerarquía de clases correspondiente. A medida que aumenta el
NOR, también aumenta el esfuerzo de prueba.
Fan-in (FIN) sería el NPD en el teórico. fan-in en la jerarquía de herencia es una indicación
de herencia múltiple. FIN > 1 indica que una clase hereda sus atributos y operaciones de
más de una clase raíz. FIN > 1 debe evitarse siempre que sea posible.
Métricas para el mantenimiento
Todas las métricas de software presentadas en este capítulo se pueden utilizar para el
desarrollo de software nuevo y el mantenimiento del software existente. Sin embargo, se
han propuesto métricas diseñadas explícitamente para actividades de mantenimiento como
el SMI (Índice de madurez del software) qué da una indicación de la estabilidad de un
producto de software basado en los cambios de cada una de sus versiones.
MT = número de módulos en la versión actual
Fc = número de módulos en la versión actual que se han modificado
Fa = número de módulos en la versión actual que se han añadido
Fd = número de módulos de la versión anterior que se han eliminado en la versión actual
A medida que el SMI se acerca a 1, el producto comienza a estabilizarse.
Métricas de procesos y proyectos
Las medidas que recopila un equipo de proyecto y convierte en métricas para su uso
durante un proyecto también se pueden transmitir a aquellos con responsabilidad por la
mejora de procesos de software. Por esta razón, muchas de las mismas métricas se utilizan
tanto en el dominio de procesos como en el de proyectos.
Métricas de procesos: Las métricas de procesos se recopilan en todos los proyectos y
durante largos períodos de tiempo. Su intención es proporcionar un conjunto de indicadores
de proceso que conduzcan a una mejora de procesos de software a largo plazo.
Métricas de proyectos: Las métricas de proyectos permiten a un gerente de proyectos
de software (1) evaluar el estado de un proyecto en curso, (2) realizar un seguimiento de los
riesgos potenciales, (3) descubrir áreas problemáticas antes de que se vuelvan "críticas",
(4) ajustar el flujo de trabajo o las tareas y (5) evaluar la capacidad del equipo de proyecto
para controlar la calidad de los productos de trabajo de software.
A diferencia de las métricas de procesos de software que se utilizan con fines estratégicos,
las métricas de proyectos de software son tácticas. Es decir, las métricas de proyectos y los
indicadores derivados de ellas son utilizados por un gerente de proyectos y un equipo de
software para adaptar el flujo de trabajo del proyecto y las actividades técnicas.
Antes de analizar las métricas de software y su impacto en la mejora de procesos de
software, es importante señalar que el proceso es solo uno de varios factores controlables.
En referencia a la Figura, el proceso se encuentra en el centro de un triángulo que conecta
tres factores que tienen una profunda influencia en la calidad del software y el desempeño
organizacional.
- Se ha demostrado que la habilidad y la motivación de las personas son los factores
más influyentes en la calidad y el desempeño.
- La complejidad del producto puede tener un impacto sustancial en la calidad y el
desempeño del equipo.
- La tecnología (es decir, los métodos y herramientas de ingeniería de software) que
puebla el proceso también tiene un impacto.
Además, el triángulo del proceso existe dentro de un círculo de condiciones ambientales
que incluyen el entorno de desarrollo, condiciones comerciales y características del cliente.
Solo se puede medir la eficacia de un proceso de software indirectamente. Es decir, se
deriva un conjunto de métricas basadas en los resultados que se pueden derivar del
proceso.
Aplicación de las métricas
La primera aplicación de métricas de proyecto en la mayoría de los proyectos de software
ocurre durante la estimación. Las métricas recopiladas de proyectos anteriores se utilizan
como base a partir de la cual se realizan estimaciones de esfuerzo y tiempo para el trabajo
de software actual. A medida que avanza un proyecto, las medidas de esfuerzo y tiempo de
calendario invertido se comparan con las estimaciones originales. El gerente de proyecto
utiliza estos datos para monitorear y controlar el progreso.
A medida que comienza el trabajo técnico, otras métricas del proyecto comienzan a tener
importancia.
Además, se realiza un seguimiento de los errores descubiertos durante cada tarea de
ingeniería de software.
Cuando el software evoluciona, desde los requisitos hasta el diseño, se recopilan métricas
técnicas para evaluar la calidad del diseño y para proporcionar indicadores qué influyen en
el enfoque adoptado para la generación y prueba de código.
¿Por qué utilizar métricas?
El propósito de las métricas del proyecto es doble.
- Primero, estas métricas se utilizan para minimizar el cronograma de desarrollo
haciendo los ajustes necesarios para evitar demoras y mitigar posibles problemas y
riesgos.
- Segundo, las métricas del proyecto se utilizan para evaluar la calidad del producto
de manera continua y, cuando es necesario, modificar el enfoque técnico para
mejorar la calidad.
A medida que mejora la calidad, se minimizan los defectos y también se reduce la cantidad
de retrabajo necesario durante el proyecto. Esto conduce a una reducción del costo general
del proyecto.
Las métricas de procesos de software pueden brindar beneficios significativos a medida que
una organización trabaja para mejorar su nivel general de madurez de procesos. Sin
embargo, como todas las métricas, pueden utilizarse incorrectamente, creando más
problemas de los que resuelven.
A medida que una organización se familiariza con la recopilación y el uso de métricas de
procesos, la derivación de indicadores simples da paso a un enfoque más riguroso
denominado mejora estadística de procesos de software (SSPI, por sus siglas en inglés). La
SSPI utiliza el análisis de fallas de software para recopilar información sobre todos los
errores y defectos encontrados a medida que se desarrolla y utiliza una aplicación, un
sistema o un producto.
Medición de software
Las mediciones en el mundo físico se pueden clasificar de dos maneras: mediciones
directas y mediciones indirectas. Las métricas de software se pueden clasificar de la misma
manera:
Medidas directas: El costo y el esfuerzo necesarios para crear software, la cantidad de
líneas de código producidas (LOC) y otras medidas directas son relativamente fáciles de
recopilar, siempre que se establezcan de antemano convenciones específicas para la
medición.
Medidas indirectas: La calidad y la funcionalidad del software o su eficiencia o
capacidad de mantenimiento son más difíciles de evaluar y solo se pueden medir de
manera indirecta.
Hemos dividido el dominio de las métricas de software en métricas de proceso, proyecto y
producto, y hemos observado que las métricas de producto que son privadas para un
individuo a menudo se combinan para desarrollar métricas de proyecto que son públicas
para un equipo de software.
Las métricas de proyecto luego se consolidan para crear métricas de proceso que son
públicas para la organización de software en su conjunto. Pero, ¿cómo combina una
organización las métricas que provienen de diferentes individuos o proyectos?
- Los individuos registran y categorizan sus métricas.
- Se combinan las medidas individuales para desarrollar medidas de equipo.
- Se comparan y luego normalizan las medidas para crear las métricas.
Métricas orientadas al tamaño (LOC):
Las métricas de software orientadas al tamaño se derivan normalizando las medidas de
calidad y/o productividad al considerar el tamaño del software que se ha producido.
Las métricas orientadas al tamaño no son universalmente aceptadas como la mejor manera
de medir el proceso de software. La mayor parte de la controversia gira en torno al uso de
líneas de código como una medida clave.
- Los defensores de la medida LOC afirman que LOC es un "artefacto" de todos los
proyectos de desarrollo de software que se puede contar fácilmente, que muchos
modelos de estimación de software existentes usan LOC o KLOC como una entrada
clave y que ya existe una gran cantidad de literatura y datos basados en LOC.
- Los opositores argumentan que las medidas LOC dependen del lenguaje de
programación, que cuando se considera la productividad, penalizan a los programas
bien diseñados pero más cortos; que no pueden adaptarse fácilmente a lenguajes no
procedimentales; y que su uso en la estimación requiere un nivel de detalle que
puede ser difícil de lograr (es decir, el planificador debe estimar el LOC que se
producirá mucho antes de que se hayan completado el análisis y el diseño).
Métricas orientadas a funciones (Puntos de función):
Las métricas de software orientadas a funciones utilizan una medida de la funcionalidad
entregada por la aplicación como un valor de normalización. El cálculo de una métrica
orientada a funciones se basa en características del dominio de información y la
complejidad del software.
El punto de función, al igual que la medida LOC, es controvertido.
- Los defensores afirman qué el PF es independiente del lenguaje de programación, lo
que la hace ideal para aplicaciones que utilizan lenguajes convencionales y no
procedimentales, y que se basa en datos que es más probable que se conozcan al
principio de la evolución de un proyecto.
- Los oponentes afirman que el método requiere algo de “juego de manos” ya que el
cálculo se basa en datos subjetivos en lugar de objetivos, que los recuentos del
dominio de información (y otras dimensiones) pueden ser difíciles de recopilar
después del hecho, y que el PF no tiene un significado físico directo: es solo un
número.
Se ha descubierto que los puntos de función y las métricas basadas en LOC son predictores
relativamente precisos del esfuerzo y el costo del desarrollo de software. Sin embargo, para
utilizar LOC y PF para la estimación, se debe establecer una línea base histórica de
información. Son estos datos históricos los que, con el tiempo, le permitirán juzgar el valor
de una métrica particular en proyectos futuros.
Métricas para la calidad de software
El software es una entidad compleja. Por lo tanto, se espera que haya errores a medida que
se desarrollan los productos de trabajo. Las métricas de proceso tienen como objetivo
mejorar el proceso de software para que los errores se descubran de la manera más eficaz.
Puede utilizar la medición para evaluar la calidad de los requisitos y modelos de diseño, el
código fuente y los casos de prueba que se han creado a medida que se diseña el software.
Las métricas privadas recopiladas por ingenieros de software individuales se combinan para
proporcionar resultados a nivel de proyecto. Aunque se pueden recopilar muchas medidas
de calidad, el objetivo principal a nivel de proyecto es medir errores y defectos. Las métricas
derivadas de estas medidas proporcionan una indicación de la eficacia de las actividades de
control y garantía de calidad de software individuales y grupales.
Métricas como errores de producto de trabajo por punto de función, errores descubiertos por
hora de revisión y errores descubiertos por hora de prueba brindan información sobre la
eficacia de cada una de las actividades implicadas por la métrica. Los datos de error
también se pueden utilizar para calcular la eficiencia de eliminación de defectos (DRE) para
cada actividad del marco de proceso.
Corrección: La corrección es el grado en el que el software realiza su función requerida.
La medida más común para la corrección son los defectos por KLOC, donde un defecto se
define como una falta verificada de conformidad con los requisitos.
Mantenibilidad: La mantenibilidad es la facilidad con la que un programa puede ser
corregido si se encuentra un error, adaptado si su entorno cambia o mejorado si el cliente
desea un cambio en los requisitos. No hay forma de medir la mantenibilidad directamente;
por lo tanto, debemos utilizar medidas indirectas.
Integridad: Este atributo mide la capacidad de un sistema para resistir ataques (tanto
accidentales como intencionales) a su seguridad. Para medir la integridad, se deben definir
dos atributos adicionales: amenaza y seguridad. La amenaza es la probabilidad (que puede
estimarse o derivarse de evidencia empírica) de que un ataque de un tipo específico ocurra
dentro de un tiempo determinado. La seguridad es la probabilidad (que puede estimarse o
derivarse de evidencia empírica) de que el ataque de un tipo específico sea repelido. La
integridad de un sistema puede entonces definirse como:
Integridad = Σ[1 − (amenaza × (1 − seguridad))]
Usabilidad: La usabilidad es un intento de cuantificar la facilidad de uso.
Una métrica de calidad que proporciona beneficios tanto a nivel de proyecto como de
proceso es la eficiencia de eliminación de defectos (DRE). En esencia, la DRE es una
medida de la capacidad de filtrado de las acciones de control y garantía de calidad tal como
se aplican en todas las actividades del marco de procesos.
Cuando se considera un proyecto en su conjunto, la DRE se define de la siguiente manera:
donde E es el número de errores encontrados antes de la entrega del software al usuario
final y D es el número de defectos encontrados después de la entrega.
El valor ideal para la DRE es 1. Es decir, no se encuentran defectos en el software. De
manera realista, D será mayor que 0, pero el valor de DRE puede acercarse a 1. A medida
que E aumenta (para un valor dado de D), el valor general de DRE comienza a acercarse a
1. De hecho, a medida que E aumenta, es probable que el valor final de D disminuya (los
errores se filtran antes de que se conviertan en defectos).
Por ejemplo, el análisis de requisitos produce un modelo de requisitos que puede revisarse
para encontrar y corregir errores. Los errores que no se encuentran durante la revisión del
modelo de requisitos se pasan al diseño (donde pueden o no encontrarse). Cuando se
utiliza en este contexto, redefinimos DRE como
donde Ei es el número de errores encontrados durante la acción de ingeniería de software i
y Ei+1 es el número de errores encontrados durante la acción de ingeniería de software i +
1 que son atribuibles a errores que no se descubrieron en la acción de ingeniería de
software i.
Un objetivo de calidad para un equipo de software (o un ingeniero de software individual) es
lograr un DREi que se acerque a 1.
Establecimiento de programas de métricas de software
La guía sugiere los siguientes pasos: (1) identificar sus objetivos de negocio, (2) identificar
lo qué quiere saber o aprender, (3) identificar sus subobjetivos, (4) identificar las entidades y
atributos relacionados con sus subobjetivos, (5) formalizar sus objetivos de medición, (6)
identificar preguntas cuantificables y los indicadores relacionados que utilizará para
ayudarlo a alcanzar sus objetivos de medición, (7) identificar los elementos de datos que
recopilará para construir los indicadores, (8) identificar las medidas que se utilizarán y hacer
que estas definiciones sean operativas, (9) identificar las acciones que tomará para
implementar las medidas y (10) preparar un plan para implementar las medidas. Es mejor
dejar una discusión detallada de estos pasos en la guía del SEI. Sin embargo, una breve
descripción general de los puntos clave se ilustra con el siguiente ejemplo.
Debido a que el software respalda las funciones empresariales, diferencia los sistemas o
productos informáticos o actúa como un producto en sí mismo, los objetivos definidos para
la empresa casi siempre se pueden rastrear hacia abajo hasta objetivos específicos en el
nivel de ingeniería de software.
La gran mayoría de las organizaciones de desarrollo de software tienen menos de 20
personas de software. Es irrazonable, y en la mayoría de los casos poco realista, esperar
que dichas organizaciones desarrollen programas integrales de métricas de software. Sin
embargo, es razonable sugerir que las organizaciones de software de todos los tamaños
midan y luego utilicen las métricas resultantes para ayudar a mejorar su proceso de
software local y la calidad y puntualidad de los productos que producen.
Una organización pequeña puede comenzar centrándose no en la medición sino en los
resultados. Se realiza una encuesta al grupo de software para definir un único objetivo que
requiere una mejora. Por ejemplo, “reducir el tiempo para evaluar e implementar solicitudes
de cambio”. Una pequeña organización podría seleccionar el siguiente conjunto de medidas
que se recopilan fácilmente:
∙ Tiempo (horas o días) transcurrido desde el momento en que se realiza una solicitud hasta
que se completa la evaluación, tqueue.
∙ Esfuerzo (horas-persona) para realizar la evaluación, Weval.
∙ Tiempo (horas o días) transcurrido desde la finalización de la evaluación hasta la
asignación de la orden de cambio al personal, teval.
∙ Esfuerzo (horas-persona) necesario para realizar el cambio, Wchange.
∙ Tiempo necesario (horas o días) para realizar el cambio, tchange.
∙ Errores descubiertos durante el trabajo para realizar el cambio, Echange.
∙ Defectos descubiertos después de que el cambio se lanza a la base de clientes, Dchange.
Una vez que se han recopilado estas medidas para una serie de solicitudes de cambio, es
posible calcular el tiempo total transcurrido desde la solicitud de cambio hasta la
implementación del cambio y el porcentaje de tiempo transcurrido absorbido por la puesta
en cola inicial, la evaluación y la asignación de cambios, y la implementación del cambio. De
manera similar, se puede determinar el porcentaje de esfuerzo requerido para la evaluación
y la implementación. Estas métricas se pueden evaluar en el contexto de los datos de
calidad, Echange y Dchange. Los porcentajes brindan una idea de dónde se ralentiza el
proceso de solicitud de cambio y pueden conducir a pasos de mejora del proceso para
reducir tqueue, Weval, teval, Wchange y/o Echange. Además, la eficiencia de eliminación
de defectos se puede calcular como
DRE se puede comparar con el tiempo transcurrido y el esfuerzo total para determinar el
impacto de las actividades de control de calidad en el tiempo y el esfuerzo necesarios para
realizar un cambio. La mayoría de los desarrolladores de software aún no miden y,
lamentablemente, la mayoría tiene poco deseo de comenzar.
Intentar recopilar medidas cuando no se han recopilado en el pasado suele generar
resistencia. “¿Por qué necesitamos hacer esto?”, pregunta un director de proyectos
agobiado. “No le veo el sentido”, se queja un profesional sobrecargado de trabajo. ¿Por qué
es tan importante medir el proceso de ingeniería de software y el producto (software) qué
produce? La respuesta es relativamente obvia. Si no mides, no hay forma real de
determinar si estás mejorando. Y si no estás mejorando, estás perdido.
