Generalidades – Ontología de la Medición

Cápsula 9. Medición de Software
INTRODUCCIÓN
"Lo que no se puede medir, no se puede
controlar; lo que no se puede controlar no se
puede gestionar; lo que no se puede gestionar,
no se puede mejorar" (Peter Drucker)
“No se puede predecir lo que no se
puede medir” (Norman Fenton)”
“Las métricas son un buen medio para entender, monitorizar,
controlar, predecir y probar el desarrollo software y los proyectos de
mantenimiento” (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
Cápsula 9. Medición de Software
1
Cápsula 9. Medición de Software
INTRODUCCIÓN
Las métricas pueden ser utilizadas para que los
profesionales e investigadores puedan tomar las
mejores decisiones. (Pfleeger, 1997).
MÉTRICAS COMO MEDIO PARA
ASEGURAR LA CALIDAD EN LOS
PRODUCTOS / PROCESOS / PROYECTOS
SOFTWARE
Cápsula 9. Medición de Software
2
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
Una ontología ha de comprenderse
como un entendimiento común y
compartido de un dominio
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.
Cápsula 9. Medición de Software
3
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
Cápsula 9. Medición de Software
4
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
Sub-Ontología Caracterización y Objetivos de la Medición Software: Glosario de Conceptos
Cápsula 9. Medición de Software
5
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
Sub-Ontología Caracterización y Objetivos de la Medición Software: Tabla de Interrelaciones
Cápsula 9. Medición de Software
6
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
• Concepto: MÉTRICA
• Definición. Una forma de medir y una escala, definidas
para realizar 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 para
mé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 de un “programa en Python”.
Cápsula 9. Medición de Software
7
Cápsula 9. Medición de Software
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.
Cápsula 9. Medición de Software
8
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
Cápsula 9. Medición de Software
9
Cápsula 9. Medición de Software
Cápsula 9. Medición de Software
10
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
ESCALAS
NOMINAL. Escala más básica, que sitúa a las entidades en diferentes categorías
asignando al atributo un nombre. Cuando un producto se rotula de acuerdo al
cumplimiento 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 puede
realizar un orden de las observaciones con sentido.
ORDINAL. Los atributos pueden ser ordenados en rangos,
entre los mismos no es significativa.
pero la distancia
Suponga que a los clientes se les hace unas preguntas para valorar la calidad del
producto. 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 servicio
es dos veces mejor que cuando se da una valoración de 2. Sin embargo podemos
decir que la valoración de 1 es preferiblemente mejor que 2, y así en los demás
casos.
Cápsula 9. Medición de Software
11
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
ESCALAS
INTERVALO. Como la ordinal pero la distancia entre los atributos sí tiene
sentido.
Si se mide la temperatura en grados celsius, la distancia entre 30º y 40º es la
misma que entre 60º y 70º. Sin embargo, hay que tener en cuenta que en esta
escala el cero es arbitrario; por tanto no se puede decir que 50º es el doble de
temperatura que 25º (aunque el valor si es el doble).
RATIO. El mas útil en medición del software, ya que preserva el orden , el
tamaño de los intervalos y también los ratios entre las entidades. Tiene un punto
fijo de referencia: el cero (comienzo de la escala) y se incrementa en pasos
iguales.
Con estos valores de la escala se pueden hacer operaciones
matemáticas de + , - , * , /
Cápsula 9. Medición de Software
12
Cápsula 9. Medición de Software
ONTOLOGÍA DE LA MEDICIÓN
• Todo proceso de medición tiene como objetivo fundamental
satisfacer necesidades de medición detectadas en la empresa en la
que se lleva a cabo.
• A partir de esta necesidad se identifican entidades y atributos a
ser medidos.
• Luego se definen las métricas necesarias (unidad en la que se
expresa, escala a la que pertenece, atributo o atributos para los
que se define)
• Primero se definen métricas directas, luego indirectas, y
finalmente criterios de decisión para satisfacer las necesidades de
información planteadas inicialmente.
Cápsula 9. Medición de Software
13
Cápsula 9. Medición de Software
ESTÁNDARES
Área Clave “Medición y Análisis” de CMMI
Cápsula 9. Medición de Software
14
Cápsula 9. Medición de Software
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.
Cápsula 9. Medición de Software
15
Cápsula 9. Medición de Software
ESTÁNDARES
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 de
un proyecto general o de la estructura de medición de una empresa.
Cápsula 9. Medición de Software
16
Cápsula 9. Medición de Software
ESTÁNDARES
ISO/IEC 15939
Cápsula 9. Medición de Software
17
Cápsula 9. Medición de Software
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. El
estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software.
Cápsula 9. Medición de Software
18
Cápsula 9. Medición de Software
ESTÁNDARES
MEDICIÓN EN ISO/IEC 12207.
El propósito del Proceso de medición es recolectar y analizar los datos relacionados con los
productos desarrollados y procesos implementados al interior de la organización y sus
proyectos, para apoyar la gestión efectiva de los procesos y demostrar objetivamente la
calidad de los productos.
Cápsula 9. Medición de Software
19
Cápsula 9. Medición de Software
DEFINICIÓN DE MÉTRICAS
Basili y Weiss (1984) y Rombach (1990). Autores y refinadores de GQM (Goal-QuestionMetric), 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
Preguntas
Métricas
Cápsula 9. Medición de Software
Objetivo Perseguido
Pregunta N
Pregunta 1
M1
...
Mn
M1’
... Mn’
20
Cápsula 9. Medición de Software
DEFINICIÓN DE MÉTRICAS
Proceso GQM (aporte de van Soligen y Berghout, 1999)
Cápsula 9. Medición de Software
21
Cápsula 9. Medición de Software
MÉTRICAS DE SOFTWARE
PROCESO DE RECOPILACIÓN DE MÉTRICAS
Cápsula 9. Medición de Software
22
Cápsula 9. Medición de Software
MÉTRICAS DE SOFTWARE
Clasificación de las métricas de software según criterios:
Cápsula 9. Medición de Software
23
Cápsula 9. Medición de Software
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 componentes
que conforman el software.
Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad y el
esfuerzo.
Cápsula 9. Medición de Software
24
Cápsula 9. Medición de Software
EJEMPLO. Supongamos una organización que lleva a cabo un proyecto de
desarrollo de un software X. En un determinado momento el responsable del
proyecto necesita saber si la productividad es adecuada, es decir:
La necesidad de información es conocer el nivel de productividad de los
programadores del proyecto en comparación con lo habitual en otros proyectos
en 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íneas
utilizando como instrumento una herramienta CASE.
HPD (horas-programador diarias). El método de medición es que el responsable del
proyecto 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 es
consultar el plan del proyecto, donde se tuvo que indicar este valor, previa consulta a un
responsable de personal.
Cápsula 9. Medición de Software
25
Cápsula 9. Medición de Software
EJEMPLO
Indirectas:
HPT (horas-programador totales).
La función de cálculo es una sumatoria de las HPD de cada día:
[Métrica indirecta definida con base en sólo 1 métrica directa].
HPT =
∑HPD
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 de
cada 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 total
actual del proyecto -en unidades monetarias- entre la cantidad de líneas de
código fuente escritas: CLCF = CTP/ LCF.
[Métrica indirecta definida con base en 2 métricas, una indirecta y otra directa].
Cápsula 9. Medición de Software
26
Cápsula 9. Medición de Software
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 establecer
un 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 los
valores 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:
0.70
0.90
1.10
1.30
<=
<=
<=
<=
LCFH / LCFHvm < 0.70
LCFH / LCFHvm < 0.90
LCFH / LCFHvm < 1.10
LCFH / LCFHvm < 1.30
LCFH / LCFHvm
se
se
se
se
se
interpreta
interpreta
interpreta
interpreta
interpreta
como
como
como
como
como
PROD=’muy baja’.
PROD=’baja’.
PROD=’normal’.
PROD=’alta’.
PROD=’muy alta’.
De modo que cuando se calcule el valor para el indicador (a partir de las métricas
mencionadas) se podrá evaluar y entregar un concepto sobre la situación que dicho indicador
pretende reflejar.
Cápsula 9. Medición de Software
27
Cápsula 9. Medición de Software
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.
-------------------- FIN DEL DOCUMENTO
Cápsula 9. Medición de Software
28

Download Report