Upload
hoangkhuong
View
215
Download
0
Embed Size (px)
Citation preview
1
INTRODUCCIÓN
"Lo que no se puede medir, no se puedecontrolar; lo que no se puede controlar no sepuede gestionar; lo que no se puede gestionar,no se puede mejorar" (Peter Drucker)
“No se puede predecir lo que no sepuede medir” (Norman Fenton)”
“Las métricas son un buen medio para entender, monitorizar,controlar, predecir y probar el desarrollo software y los proyectos demantenimiento” (Briand et al., 1996)
En general, la medición persigue tres objetivos fundamentales(Fenton y Pfleeger, 1997):
• entender qué ocurre durante el desarrollo y el mantenimiento• controlar qué es lo que ocurre en nuestros proyectos• mejorar nuestros procesos y nuestros productos
Guía 08. Medición de Software
2
INTRODUCCIÓN
Las métricas pueden ser utilizadas para que losprofesionales e investigadores puedan tomar lasmejores decisiones. (Pfleeger, 1997).
MÉTRICAS COMO MEDIO PARAASEGURAR LA CALIDAD EN LOS
PRODUCTOS / PROCESOS / PROYECTOS SOFTWARE
Guía 08. Medición de Software
3
ONTOLOGÍA DE LA MEDICIÓN
La medición de software es una disciplina
relativamente joven, y no existe consenso general
sobre la definición exacta de los conceptos y
terminología que maneja.
Una ontología ha de comprenderse como un entendimiento común y
compartido de un dominio
Guía 08. Medición de Software
4
ONTOLOGÍA DE LA MEDICIÓN
Sub-Ontología Caracterización y Objetivos de la Medición Software: Glosario de Conceptos
Guía 08. Medición de Software
5
ONTOLOGÍA DE LA MEDICIÓN
Sub-Ontología Caracterización y Objetivos de la Medición Software: Tabla de Interrelaciones
Guía 08. Medición de Software
6
ONTOLOGÍA DE LA MEDICIÓN
• Concepto: MÉTRICA
• Definición. Una forma de medir y una escala, definidas pararealizar mediciones de uno o varios atributos
• Relaciones:
– Una métrica está definida para uno o más atributos
– Una métrica puede expresarse en una unidad (sólo paramétricas cuya escala sea de tipo intervalo o ratio)
• Ejemplos
– “líneas de código” para el “tamaño” de un “módulo en C” o deun “programa en Python”.
Guía 08. Medición de Software
7
ONTOLOGÍA DE LA MEDICIÓN
• Concepto. MEDIDA
• Definición. Resultado de una medición.
• Relaciones: Una medida es el resultado de una medición
• Ejemplos
– 35.000 líneas de código, 200 páginas, 50 clases.
– 5 meses desde el comienzo al fin del proyecto.
– 0,5 fallos por cada 1.000 líneas de código.
Guía 08. Medición de Software
8
Guía 08. Medición de Software
9
ONTOLOGÍA DE LA MEDICIÓN
ESCALAS
NOMINAL. Escala más básica, que sitúa a las entidades en diferentes categoríasasignando al atributo un nombre. Cuando un producto se rotula de acuerdo alcumplimiento de las especificaciones de diseño como "conforme y no conforme".o "crítico, grave, y menor". No se obtienen valores numéricos y no se puederealizar un orden de las observaciones con sentido.
ORDINAL. Los atributos pueden ser ordenados en rangos, pero la distanciaentre los mismos no es significativa.
Suponga que a los clientes se les hace unas preguntas para valorar la calidad delproducto. Los clientes valoran la calidad de acuerdo a las siguientes respuestas:1 (excelente), 2 (bueno), 3 (regular), 3 (malo) 4 (pésimo).
Estos datos son ordinales. Note que una valoración de 1 no indica que el servicioes dos veces mejor que cuando se da una valoración de 2. Sin embargo podemosdecir que la valoración de 1 es preferiblemente mejor que 2, y así en los demáscasos.
Guía 08. Medición de Software
10
ONTOLOGÍA DE LA MEDICIÓN
ESCALAS
INTERVALO. Como la ordinal pero la distancia entre los atributos sí tienesentido.
Si se mide la temperatura en grados celsius, la distancia entre 30º y 40º es lamisma que entre 60º y 70º. Sin embargo, hay que tener en cuenta que en estaescala el cero es arbitrario; por tanto no se puede decir que 50º es el doble detemperatura que 25º (aunque el valor si es el doble).
RATIO. El mas útil en medición del software, ya que preserva el orden , eltamaño de los intervalos y también los ratios entre las entidades. Tiene un puntofijo de referencia: el cero (comienzo de la escala) y se incrementa en pasosiguales. Con estos valores de la escala se pueden hacer operaciones
matemáticas de + , - , * , /
Guía 08. Medición de Software
11
ONTOLOGÍA DE LA MEDICIÓN
• Todo proceso de medición tiene como objetivo fundamentalsatisfacer necesidades de medición detectadas en la empresa en laque se lleva a cabo.
• A partir de esta necesidad se identifican entidades y atributos aser medidos.
• Luego se definen las métricas necesarias (unidad en la que seexpresa, escala a la que pertenece, atributo o atributos para losque se define)
• Primero se definen métricas directas, luego indirectas, yfinalmente criterios de decisión para satisfacer las necesidades deinformación planteadas inicialmente.
Guía 08. Medición de Software
12
ESTÁNDARES
Practical Software Measurement (PSM) (McGarry et al., 2002) se basa en la experiencia obtenida de organizaciones para saber cuál es la mejor manera de implementar un programa de medida software con garantías de éxito.
ISO/IEC 15939. Este estándar internacional (2002) establece las actividades y tareas necesarias
para identificar, definir, seleccionar, aplicar y mejorar de manera exitosa la medición de software dentro deun proyecto general o de la estructura de medición de una empresa.
Guía 08. Medición de Software
13
ESTÁNDARES
MEDICIÓN EN ISO/IEC 12207. Es el estándar para los procesos de ciclo de vida del software. Este
estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. Elestándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software.
Guía 08. Medición de Software
14
DEFINICIÓN DE MÉTRICAS
Basili y Weiss (1984) y Rombach (1990). Autores y refinadores de GQM (Goal-Question-
Metric), un paradigma para desarrollar y mantener un programa de métricas . Proporciona
una manera útil para definir mediciones tanto del proceso como de los resultados de un
proyecto. GQM se puede aplicar a todo el ciclo de vida del producto, procesos, y recursos y se
pude alinear fácilmente con el ambiente organizacional. Tiene como principio básico que la
medición debe ser realizada, siempre, orientada a un objetivo.
Objetivo Objetivo Perseguido
Preguntas Pregunta 1 Pregunta N
Métricas M1 Mn... M1’ Mn’...
Guía 08. Medición de Software
15
PROCESO DE RECOPILACIÓN DE MÉTRICAS
MÉTRICAS DE SOFTWARE
Guía 08. Medición de Software
16
MÉTRICAS DE SOFTWARE
Clasificación de las métricas de software según criterios:
Guía 08. Medición de Software
17
MÉTRICAS DE SOFTWARE
Según el contexto:
Proceso:
Se recopilan de todos los proyectos, y durante un largo periodo de tiempo
Caracterizadas por:
Control y ejecución del proyecto.
Medición de tiempos de las fases.
Proyecto:
Permiten evaluar el estado del proyecto.
Permiten seguir la pista de los riesgos.
Producto:
Se centran en las características del software y no en cómo se fabricó.
También son productos los artefactos, documentos, modelos y componentesque conforman el software.
Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad y elesfuerzo.
Guía 08. Medición de Software
18
EJEMPLO. Supongamos una organización que lleva a cabo un proyecto dedesarrollo de un software X. En un determinado momento el responsable delproyecto necesita saber si la productividad es adecuada, es decir:
La necesidad de información es conocer el nivel de productividad de losprogramadores del proyecto en comparación con lo habitual en otros proyectosen la organización.
Las métricas a utilizar podrían ser:
Directas:
LCF (líneas de código fuente escritas). El método de medición es contar las líneasutilizando como instrumento una herramienta CASE.
HPD (horas-programador diarias). El método de medición es que el responsable delproyecto anota cada día las horas dedicadas por los programadores al proyecto.
CHP (coste por hora-programador, en unidades monetarias). El método de medición esconsultar el plan del proyecto, donde se tuvo que indicar este valor, previa consulta a unresponsable de personal.
Guía 08. Medición de Software
19
EJEMPLO
Indirectas:
HPT (horas-programador totales).
La función de cálculo es una sumatoria de las HPD de cada día: HPT = ∑HPD
[Métrica indirecta definida con base en sólo 1 métrica directa].
LCFH (líneas de código fuente por hora de programador).La función de cálculo es una simple división: LCFH = LCF / HPD[Métrica indirecta definida con base en 2 métricas directas].
CTP (coste total actual del proyecto, en unidades monetarias).La función de cálculo establece que el CTP es el producto del coste unitario decada hora por el total de horas empleadas: CTP = CHP * HPT[Métrica indirecta definida con base en 2 métricas, una directa y otra indirecta].
CLCF (coste por línea de código fuente).La función de cálculo establece que el CLCF es el resultado de dividir el coste totalactual del proyecto -en unidades monetarias- entre la cantidad de líneas decódigo fuente escritas: CLCF = CTP/ LCF.[Métrica indirecta definida con base en 2 métricas, una indirecta y otra directa].
Guía 08. Medición de Software
20
EJEMPLO
Indicadores: PROD (productividad de los programadores).
El modelo de análisis utiliza los valores de las métricas LCF, HPT, LCFH y CTP para establecerun valor cualitativo de la productividad de los programadores en este proyecto.
El modelo se basa en extraer de una base histórica de proyectos de la organización losvalores medios de
LCF , HPT , LCFH (LCFHvm valor medio de líneas de código fuente por hora de programador) y CTP
del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120%).
Y la organización establece el siguiente criterio de decisión:
LCFH / LCFHvm < 0.70 se interpreta como PROD=’muy baja’.0.70 <= LCFH / LCFHvm < 0.90 se interpreta como PROD=’baja’.0.90 <= LCFH / LCFHvm < 1.10 se interpreta como PROD=’normal’.1.10 <= LCFH / LCFHvm < 1.30 se interpreta como PROD=’alta’.1.30 <= LCFH / LCFHvm se interpreta como PROD=’muy alta’.
De modo que cuando se calcule el valor para el indicador (a partir de las métricasmencionadas) se podrá evaluar y entregar un concepto sobre la situación que dicho indicadorpretende reflejar.
Guía 08. Medición de Software
21
OTROS QUE SE PUEDEN UTILIZAR
Número de defectos generados por desarrollador por hora
Número de cambios a los requisitos
Número de versiones con correcciones (patch) realizadas después de
lanzar el producto
Horas disponibles y ejecutadas por programador por semana
Defectos descubiertos durante las pruebas
Número de defectos introducidos al realizar una modificación.
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Los factores que afectan a la calidad del software se puedencategorizar en dos amplios grupos:
(1)Factores que se pueden medir directamente (por ejemplo,defectos por punto de función).
(2)Factores que se pueden medir sólo indirectamente (porejemplo, facilidad de uso o de mantenimiento).
En todos los casos debe aparecer la medición. Debemoscomparar el software (documentos, programas, datos) con unareferencia y llegar a una conclusión sobre la calidad.
22
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
23
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Es difícil, y en algunos casos imposible, desarrollar medidas directas de los factores de calidad anteriores.
Por tanto, se definen y emplean un conjunto de criterios para desarrollar expresiones para todos los factores, de acuerdo con la siguiente relación:
QF = (c1 * m1) + (c2 * m2) + (c3 * m3) + … + (cn * mn)
Donde: QF es un factor de calidad del software, cn son coeficientes de regresión ( c1 + c2 + … + cn = 1.0 ) m, son los valores de los criterios que afectan al factor de calidad.
24
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
El problema es que muchas de los criterios definidas por
McCall pueden medirse solamente de manera subjetiva. Las
métricas pueden ir en forma de lista de comprobación que se
emplea para "puntuar" atributos específicos del software.
El esquema de puntuación propuesto por McCall es una
escala del 0 (bajo) al 10 (alto).
Se emplean las siguientes criterios en el esquema de
puntuación:
25
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Facilidad de auditoría. La facilidad con la que se puede comprobar el cumplimiento de los estándares.
Exactitud. La exactitud de los cálculos y del control.
Estandarización de comunicaciones. El grado de empleo de estándares de interfaces y protocolos.
Compleción. El grado con que se ha logrado la implementación total de una función.
Complejidad. Valoración del grado de complejidad del componente / función.
Concisión. Lo compacto que es el programa en términos de líneas de código.
Consistencia. El empleo de un diseño uniforme y de técnicas de documentación a lo largo del proyecto dedesarrollo del software.
Estandarización de datos. El empleo de estructuras y tipos de datos estándares a lo largo del programa.
Tolerancia al error. El daño causado cuando un programa encuentra un error.
Eficiencia de ejecución. El rendimiento del funcionamiento de un programa.
Capacidad de expansión. El grado con que se pueden ampliar el diseño arquitectónico, de datos oprocedimental.
26
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Generalidad. La amplitud de aplicación potencial de los componentes del programa.
Independencia del hardware. El grado con que se desacopla el software del hardware donde opera.
Instrumentación. El grado con que el programa vigila su propio funcionamiento e identifica los errores queocurren.
Modularidad. La independencia funcional de componentes de programa.
Operatividad. La facilidad de operación de un programa.
Seguridad. La disponibilidad de mecanismos que controlan o protegen los programas y los datos.
Autodocumentación. El grado en que el código fuente proporciona documentación significativa.
Simplicidad. El grado de facilidad con que se puede entender un programa.
Independencia del sistema software. El grado de independencia de programa respecto a lascaracterísticas del lenguaje de programación no estándar, características del sistema operativo y otrasrestricciones del entorno.
Trazabilidad. La capacidad de seguir una representación del diseño o un componente real del programahasta los requisitos.
Formación (Entrenamiento). El grado en que ayuda el software a manejar el sistema a los nuevosusuarios.
27
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
28
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Las relaciones entre los factores de calidad y los criterios son las siguientes:
A. Corrección = (C1 * CM) + (C2 * CS) + (C3 * TZ)
B. Fiabilidad = (C1 * EX) + (C2 * CX) + (C3 * CS) + (C4 * TE) + (C5 * MD) + (C6 * SM)
C. Eficiencia = (C1 * CN) + (C2 * EE) + (C3 * OP)
D. Seguridad (Integridad) = (C1 * FA) + (C2 * IN) + (C3 * SG)
E. Usabilidad (Facilidad de uso) = (C1 * OP) + (C2 * FM)
F. Facilidad de mantenimiento = (C1 * CN) + (C2 * CS) + (C3 * IN) + (C4 * MD) + (C5 * AD) + (C6 * SM)
G. Flexibilidad = (C1 * CX) + (C2 * CN) + (C3 * CS) + (C4 * CE) + (C5 * GE) + (C6 * MD) + (C7 * AD) + (C8 * SM)
H. Facilidad de Pruebas = (C1 * FA) + (C2 * CX) + (C3 * IN) + (C4 * MD) + (C5 * AD) + (C6 * SM)
I. Portabilidad = (C1 * GE) + (C2 * IH) + (C3 * MD) + (C4 * AD) + (C5 * SM)
J. Reusabilidad = (C1 * GE) + (C2 * IH) + (C3 * MD) + (C4 * AD) + (C5 * IS)
K. Interoperatividad = (C1 * EC) + (C2 * ED) + (C3 * GE) + (C4 * MD)
29
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Criterio: Generalidad (GE--Generality)Métrica 1. GE.1: UR Unit ReferencingMétrica 2. GE.2: UI Unit Implementation
Criterio: Independencia de la Aplicación (AP--Application Independence)Métrica 1. AP.3: AS Architecture Standardization
Criterio: Modularidad (MO--Modularity)Métrica 1. MO.1: MI Modular Implementation
Criterio: Auto Descriptividad (SD--Self-Descriptiveness)Métrica 1. SD.2: EC Effectiveness of Comments
Tomadas del Reporte Técnico de la Federal Aviation Administration Technical Center.(página 246 del archivo digital).
Indican cuáles son las métricas a tener en cuenta para valorar los atributos que conforman la reusabilidad.
30
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
A modo de guía se muestran las especificaciones de 2 métricasasociadas a 2 criterios diferentes:
Criterio: Independencia de la AplicaciónMétrica 1. AP.3: Estandarización de la Arquitectura (AS)
REGLA:
Para cada módulo de un CSCI (Computer Software Configuration Item), responda la pregunta:
"Cuántas líneas de código no-HOL (High Order Language) hay en el módulo?” (ejemplo de no-HOL es el lenguaje ensamblador).
"Divida la cantidad de líneas de código no-HOL entre la cantidad total de líneas de código." (Bowen, Wigle y Tsai 1985).
RANGO: Esta métrica genera un número real entre cero y uno.
INTERPRETACIÓN: Los valores “útiles” para este atributo son los que se acerquen más a cero.
cantidad de líneas de código no-HOL en el módulo
cantidad total de líneas de código fuente del móduloAS
31
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Criterio: Independencia de la AplicaciónMétrica 1. AP.3: Estandarización de la Arquitectura (AS)
La razón de fijarse en lenguaje que no sea HOL es que esos lenguajes son
dependientes de la máquina y en la medida que haya una menor cantidad de
esas líneas, esto aumenta la valoración del atributo y por consiguiente podría
incidir en un aumento de la reusabilidad.
Aporte: para ratios como este cuyos valores “buenos” para la reusabilidad
son los que se acercan a cero, habría necesidad de efectuar un cálculo como
este: ASr = 1 – AS. De modo que cuando el valor de AS se acerque más a
cero, el valor de ASr será más cercano a 1 de modo que todas las métricas
se puedan llevar a valores con sentido positivo (o creciente) y se puedan
llevar todas a una expresión general para cuantificar la reusabilidad.
32
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Criterio: Auto DescriptividadMétrica 1. SD.2: Efectividad de los Comentarios (EC)
REGLA:
Para cada módulo de un CSCI, responda la pregunta:
"¿Tiene comentario de encabezado que contenga toda la información acorde conel estándar establecido?” (Bowen, Wigle, and Tsai 1985).
Divida el total de respuestas afirmativas entre el número de módulos que se estén evaluando.
RANGO: Esta métrica genera un número real entre cero y uno.
INTERPRETACIÓN: Los valores “útiles” para este atributo son los que se acerquen más a 1.
cantidad de módulos concomentarios que cumplenestándar
ECcantidaddemódulos evaluados
33
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Criterio: Auto DescriptividadMétrica 1. SD.2: Efectividad de los Comentarios (EC)
La razón de fijarse en que los comentarios cumplan con unestándar establecido es que podrían facilitar la comprensión de loque hace el módulo. Esto aumenta la valoración del atributo ya quesi se puede comprender, se puede evaluar con menos dificultad sise podría re-usar, y por consiguiente podría incidir en un aumentode la reusabilidad.
Aporte: para ratios como este cuyos valores “buenos” para lareusabilidad son los que se acercan a 1, no hay necesidad decalcular una expresión adicional como se hizo con la métricaanterior.
34
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Cuantificación de la Reusabilidad. Aún teniendo en cuenta loexpresado, ahora se plantea una primera aproximación para calcularun valor (o probabilidad) para la reusabilidad, a partir de las 2métricas revisadas:
REUSABILIDAD = (C1 * ASr) + (C2 * EC).
De esta manera el rango de valores resultantes está entre 0 y 1.
Ci son coeficientes de regresión ( C1 + C2 = 1.0 ) que representan laponderación o el “peso” que se le podría asignar a cada métrica si secree que alguna de ellas podría tener una mayor incidencia en lacuantificación de la reusabilidad.
De no ser así, en este ejemplo C1 = C2 = 0.5.
35
Guía 08. Medición de Software
MEDIDA DE LOS FACTORES DE CALIDAD
Ejemplo. Modelo de McCall.
Generalizando, se muestra una expresión que podría cuantificar unavaloración para “Reusabilidad”:
Por lo tanto, se muestran los símbolos originales, ya que no se tieneforma de saber cuáles de ellas tienen “valores buenos” cerca de cero.
REUSABILIDAD = (C1 * UR) + (C2 * UI) + (C3 * ASr) + (C4 * MI) + (C5 * EC)
Ci son coeficientes de regresión ( C1 + C2 + C3 + C4 + C5 = 1.0 )
Si la ponderación es equitativa Ci = 0.2
36
-------------------- FIN DEL DOCUMENTO
Guía 08. Medición de Software