compendio de ingeniería del softwarecotana.informatica.edu.bo/downloads/metricas-1-2012.pdf ·...
TRANSCRIPT
3.8 METRICAS DE PROCESO Y PROYECTO
MODULO III
Ingeniería de Software INF - 163
Resumen preparado por Miguel Cotaña 1
18/06/2012
La medición permite obtener una visión
del proceso y el proyecto pues
proporciona un mecanismo para lograr
una evaluación objetiva.
La medición se aplica al proceso de
software con la finalidad de mejorarlo de
manera continua. La medición se utiliza
a lo largo de un proyecto de software
como apoyo en la estimación, el control
de calidad, la valoración de la
productividad y el control del proyecto. 2
3
Medición es una operación de asignar un valor a algo que es una medida.
Métrica es una interpretación de la medida. Grado en que un sistema, componente posee un atributo dado
Indicador provee una visión en cuanto al logro de objetivos.
4
¿ Qué control de calidad aplicarías, por ejemplo, para comprar un par de zapatos deportivos (tennis)?
5
“Cuando se puede medir y cuantificar aquello sobre lo que
uno habla y expresarlo en números, se sabe algo acerca de
eso; cuando no puede ser expresado en números el conocimiento es escaso e
insatisfactorio...”
Lord Kelvin
6
Clasificación 1: Métricas de producto. Métricas de proceso. Clasificación 2:
Métricas basadas en atributos internos del producto:
–Medidas de estructuración de un programa. –Métricas de complejidad. –Métricas de cobertura de pruebas. –Métricas de calidad del diseño.
Métricas basadas en atributos externos del producto:
–Métricas de portabilidad. –Métricas de defectos. –Métricas de usabilidad. –Métricas de mantenibilidad. –Métricas de fiabilidad.
Clasificación
7
Métricas basadas en código fuente: Nº de líneas de código. Nº de líneas de comentario. Nº de instrucciones. Densidad de documentación. Métricas basadas en estructura de diseño: Relacionadas con el control intramodular. Relacionadas con el acoplamiento entre clases.
Métricas para sistemas orientados a objetos: Acoplamiento. Herencia. Cohesión.
Se aplica las métricas para valorar la calidad de los productos.
Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas. Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales.
8
Los requisitos del Software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.
Los productos de los requerimientos, pueden ser evaluados por el número de requerimientos. De manera similar, se puede medir la cantidad de cambios introducidos a los requerimientos.
9
Medición de los requisitos
Es conveniente registrar las medidas del tamaño de los requerimientos por tipo de requerimientos. De esta manera tenemos una idea si el cambio o la incertidumbre de los requerimientos se extiende a todo el producto o reside sólo en ciertos tipos de requerimiento.
10
Se pueden utilizar medidas que reflejen cuando los requerimientos están preparados para ser derivados a los ingenieros de diseño:
1. Significa que comprende por completo;
2. Existen algunos elementos nuevos, pero no son diferentes significativamente;
3. Hay elementos nuevos, pero los comprende y piensa que a partir de ellos puede realizar el diseño;
4. Existe partes que no entiende y no está seguro de hacer un buen diseño;
5. No comprende y no está en condiciones de desarrollar un buen diseño.
11
Los factores que afectan la calidad se pueden categorizar en:
Factores que se pueden medir directamente, como por ejemplo los defectos por punto de función.
Factores que se pueden medir sólo indirectamente, como por ejemplo la facilidad de uso o mantenimiento.
En todos los casos debe aparecer la medición. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad.
12
Factores de calidad de McCall
13
Revisión del
Producto
Transición del
producto
Operación
del producto
Corrección Fiabilidad Usabilidad Integridad Eficiencia
Facilidad de mantenimiento
Flexibilidad
Facilidad de prueba
Portabilidad
Reusabilidad
Interoperatividad
14
• Corrección ¿ HACE LO QUE QUIERO?
Hasta donde satisface un programa una especificación y logra los objetivos del cliente.
• Fiabilidad ¿ Lo hace de forma fiable todo el
tiempo? Hasta donde se puede esperar que
un programa lleve a cabo su función pretendida con la exactitud requerida
15
• Eficiencia ¿ Se ejecutará en mi HW lo mejor
que se pueda? La cantidad de recursos informáticos
y código necesario para que un programa realice su función.
• Seguridad ¿ Es seguro?
Hasta donde se puede controlar el acceso al software o a los datos por personas no autorizadas.
16
• Usabilidad ¿ Es fácil de manejar?
El esfuerzo necesario para aprender, operar , preparar datos de entrada e interpretar salidas (resultados) de un programa.
• Facilidad de mantenimiento ¿Puedo corregirlo?
El esfuerzo necesario para localizar y arreglar un error en un programa.
17
• Flexibilidad ¿Puedo cambiarlo?
El esfuerzo necesario para modificar un programa operativo.
• Facilidad de prueba ¿Puedo probarlo?
El esfuerzo necesario para probar un programa y asegurarse de que realiza la función pretendida.
18
• Portabilidad ¿Podré usarlo en otra máquina?
El esfuerzo necesario para transferir el programa de un entorno de sistema de HW y/o SW a otro;
• Reusabilidad ¿Podré reutilizar alguna parte del SW?
Hasta donde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones;
• Interoperabilidad ¿Podré hacerlo interactuar con otro sistema?
El esfuerzo necesario para acoplar un sistema con otro.
19
Ejemplo: el factor de calidad “Corrección” tiene asociadas las métricas:
Compleción (Completitud);
Trazabilidad;
Consistencia.
Para evaluar la compleción es necesario dar respuesta a la siguiente lista de comprobación:
20
1. No hay referencias ambiguas [R,D,I]
2. Todas las referencias a datos definidas son calculadas u obtenidas de una fuente externa [R,D,I]
3. Todas las funciones definidas son utilizadas [R,D,I]
4. Todas las referencias a funciones están definidas [R,D,I]
5. Se han definido todas las condiciones y procesamientos para cada punto de decisión [R,D,I]
6. Concuerdan todos los parámetros de llamada a funciones definidos y referenciados [D,I]
7. Todos los informes de problemas se han resuelto [R,D,I]
8. El diseño concuerda con los requisitos [D]
9. El código concuerda con el diseño [I]
21
Se contesta con un SI o NO, y luego se aplica la que da como resultado el grado o nivel de calidad:
C= (# SI para R/6)+(# SI para D/8)+(# SI para I/8)
3
De esta forma, la medida para la compleción es un número entre 0 y 1.
La medida para la corrección, por ejemplo, se calculará (x+y+z)/3
Donde: x es la medida para la compleción, y para la trazabilidad y z para la consistencia.
22
Facilidad de mantenimiento = 1 - 0.1 (número medio de días-hombre por corrección)
Portabilidad = 1 - (esfuerzo para portar / esfuerzo para implementar)
Flexibilidad = 1 - 0.05 (número medio de días-hombre por cambio)
Fiabilidad = 1 - (número de errores/ número de líneas de código)
23
Algunas métricas
La fiabilidad emplea varias medidas, la primera de ellas es la probabilidad F de que aparezca un error en un tiempo determinado t, donde t > 0. La fiabilidad R es la probabilidad de que no ocurra un error en ese intervalo de tiempo:
R(t) = 1 - F(t)
esto supone que se estudia la fiabilidad a lo largo de un espacio continuo de tiempo
24
Pero, es más realista ajustarse al número de veces n que se ejecuta el programa:
R(n) = 1 - dn /n
donde dn es el número de fallo hallados en n ejecuciones.
Si f(t) es la función de densidad de probabilidad:
f(t) = dF(t) / dt
y f(tt) es la probabilidad de que el software falle en el intervalo (t, t + d t).
25
La tasa de riesgo h(t) es la probabilidad de que el software falle en (t, t + d t) si no ha fallado antes:
h(t) = f(t) / ( 1 - F(t) )
de donde podemos obtener una nueva expresión para la fiabilidad del software: h(t) = f(t) / ( 1 - F(t) )= - d( ln (1 - F(t) ) ) / dt = - d ln R(t) / dt
26
La fiabilidad R(t) de un componente en un determinado medio durante un periodo t se define como la probabilidad de que su tiempo para fallar excede a t:
R(t) = ℮- λ*t
donde: R(t)=funcionalidad de un componente; λ = tasa constante de fallo t = intervalo de tiempo
RT(t)=1-[1-R1(t)][1-R2(t)]...[1-Rn(t)]
27
Es difícil desarrollar medidas directas de los factores de calidad señalados anteriormente, se definen un conjunto de métricas para desarrollar expresiones que utilicen los factores:
Fq = c1 x m1 + c2 x m2 +….+cn x mn
Fq es factor de calidad
cn son coeficientes de regresión
mn son las métricas que afectan al factor calidad.
28
Lamentablemente muchas de las métricas definidas por McCall solamente pueden medirse de manera subjetiva.
Las métricas se acomodan en una lista de comprobación que se emplea para puntuar atributos específicos del software. El esquema de puntuación que se propone es una escala del 0 (bajo) al 10 (alto)
29
30
Modelo de calidad ISO 9126
calidad externa
e interna
funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad
adecuación
exactitud
interoperabilidad
seguridad de
acceso
cumplimiento de
la funcionalidad
madurez
tolerancia a
fallos
capacidad de
recuperación
cumplimiento de
la fiabilidad
capacidad para
ser entendido
capacidad para
ser aprendido
capacidad para
ser operado
capacidad de
atracción
cumplimiento de
la usabilidad
comportamiento
temporal
utilización de
recursos
cumplimiento de
la eficiencia
capacidad para
ser analizado
capacidad para
ser cambiado
estabilidad
capacidad para
ser probado
cumplimiento de
la mantenibilidad
adaptabilidad
instalabilidad
coexistencia
capacidad para
ser reemplazado
cumplimiento de
la portabilidad
31
ISO 9126
CALIDAD
Usabilidad
Eficiencia
Fiabilidad
Mantenibilidad
Funcionalidad Transportabilidad
32
Factores de calidad de Boehm
Métricas en los dominios del proceso y el proyecto
Las métricas del proceso se
recopilan en el curso de todos los
proyectos y durante largos periodos.
Su objetivo es proporcionar un
conjunto de indicadores de proceso
que conduzcan a la mejora de los
procesos de software a largo plazo
33
Las métricas del proyecto permiten
que un gestor de proyecto de
software:
1) Valore el estado de un proyecto en
curso;
2) Rastree los riesgos potenciales;
3) Descubra las áreas problema antes
de que se vuelvan “críticas”;
4) Ajuste el flujo de trabajo o las
tareas;
5) Evalué la habilidad del equipo. 34
La única forma racional de mejorar
cualquier proceso es medir sus
atributos específicos, desarrollar un
conjunto de métricas significativas con
base en dichos atributos y luego
emplear las métricas para ofrecer
indicadores que conducirán a una
estrategia de mejora.
Métricas del proceso y mejora del proceso Sw
35
proceso
Características
del cliente
Condiciones
del negocio
Entorno
de desarrollo
Personal Tecnología
Producto
36
Algunas métricas de proceso son
privadas para el equipo del proyecto
de software, pero públicas para todos
los miembros del equipo.
Las métricas públicas por lo general
asimilan información que
originalmente era privada para los
individuos y equipo
37
La métricas de proceso de software
ofrecen beneficios significativos
conforme una organización trabaja en
mejor grado global de madurez del
proceso. Sin embargo, como todas las
métricas, éstas pueden emplearse mal
y crear más problemas de los que
solucionan
38
Grady, sugiere las siguientes reglas:
Aplique sentido común y
sensibilidad organizativa cuando
interprete datos métricos;
Ofrezca retroalimentación
regular a los individuos y
equipos que recopilan medidas y
métricas;
No utilice las métricas para
evaluar a los individuos; 39
Trabaje con los profesionales y
equipos para establecer metas
claras y las métricas que se
emplearán para conseguirlas;
Nunca use métricas para amenazar
a los individuos o equipos;
Los datos métricos que indican un
área problema no deben
considerarse negativos;
No obsesionarse con una sola
métrica. 40
A diferencia de las métricas del
proceso de software que se utilizan
con propósitos estratégicos, las
métricas del proyecto de software son
tácticas. Es decir, un gerente de
proyecto y un equipo de software
emplean las métricas del proyecto y
los indicadores que se deducen de
ellas para adaptar el flujo de trabajo
del proyecto y las actividades técnicas
Métricas del proyecto
41
La primera aplicación de las métricas
del proyecto ocurre durante la
estimación. Las métricas recopiladas
de los proyectos previos se
aprovechan como base desde la cual
se realizan estimaciones de esfuerzo y
tiempo.
Conforme el proyecto avanza, las
medidas de esfuerzo y tiempo
utilizados se comparan con originales 42
Mientras comienza el trabajo técnico,
las otras métricas comienzan a tener
significado. Se miden los índices de
producción representados en términos
de modelos creados, hora de revisión,
puntos de función y líneas fuente
entregadas.
Además, se les da seguimiento a los
errores descubiertos durante cada
tarea de IS. 43
Conforme el software evoluciona
desde los requisitos hasta el diseño,
se recopilan métricas técnicas para
valorar la calidad del diseño y mejorar
los indicadores que influirán en el
enfoque que se adopte para la
generación y prueba del código.
44
Medición del software
Se clasifican en 2 categorías:
1. Medidas indirectas del producto que
influyen funcionalidad, calidad,
complejidad, eficiencia,
confiabilidad, facilidad de
mantenimiento, etc.
2. Medidas directas del proceso de
software (costo, esfuerzo aplicados)
y del producto (líneas de código,
rapidez de ejecución y defectos
reportados);
45
Supongamos una empresa de software que lleva a cabo un proyecto de desarrollo de un sistema “X”. En un determinado momento el líder del proyecto necesita conocer el nivel de productividad de los programadores del proyecto en comparación con lo habitual en otros proyectos:
46
Ejemplo
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 una herramienta CASE.
HPD (horas-programador diarias). El método de medición es que el líder 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.
47
Indirectas:
HPT (horas-programador totales). La función de cálculo es un sumatorio de las HPD de cada día: [métrica indirecta definida en base a 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 / HPT [métrica indirecta definida en base a 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 en base a 2 métricas, una directa y otra indirecta].
CLCF (coste por línea de código fuente). CLCF = LCF/CTP. 48
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) y CTP del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120% ). Los criterios de decisión establecidos son:
LCFH/LCFHvm < 70% => PROD=’muy baja’.
70% LCFH/LCFHvm < 90% => PROD=’baja’.
90% LCFH/LCFHvm < 110% => PROD=’normal’.
110% LCFH/LCFHvm < 130% => PROD=’alta’.
130% LCFH/LCFHvm => PROD=’muy alta’. 49
Las métricas del software orientadas
al tamaño preceden de la
normalización de las medidas de
calidad o productividad considerando
el tamaño de software que se ha
producido.
Si una organización de software
mantiene registros simples es factible
crear una tabla de medidas orientadas
al tamaño.
Métricas orientadas al tamaño
50
Proyecto LDC esfuerzo $ Pag.doc errores defectos
personal
Beta Alfa
Gamma . . . . .
12100 27200 20200
.
.
.
.
.
.
14 52 33 . . . . . .
150 240 314
.
.
.
.
.
500 1480 1000
.
.
.
.
.
.
139 350 200
.
.
.
.
.
.
19 76 54 . . . . . .
3 5 6 . . . . . .
El desarrollo de métricas que se
asimilen con métricas similares
procedentes de otros proyectos
requiere elegir líneas de código con
valor de normalización 51
A partir de los datos rudimentarios de
la tabla se desarrolla un conjunto de
métricas simples orientadas al tamaño
para cada proyecto.
La métricas orientadas al tamaño no
se aceptan universalmente como la
forma de medir el proceso del
software
52
Las métricas del software orientadas a
la función emplean como un valor de
normalización una medida de la
funcionalidad que entrega la
aplicación.
La métrica orientada a la función
utilizada con mayor amplitud es el
punto de función (PF). El cálculo del
PF se basa en características del
dominio de información y la
complejidad del software
Métricas orientadas a la función
53
54
La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evalua para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función:
55
Número de entradas del usuario; Número de salidas del usuario; Número de consultas del usuario; Número de archivos; Número de interfaces externas.
56
Entradas: Pantallas o formularios a través de los cuales usuarios humanos de una aplicación u otros programas agregan nuevos datos o actualizan datos existentes. Si una pantalla de entrada es muy grande para ser desplegada de una vez (asumiendo 80 columnas y 25 líneas) y requiere de una segunda pantalla, el conjunto cuenta como una (1) sola entrada. Se deben considerar entradas que requieren procesamiento único.
57
Salidas: Pantallas o informes que la aplicación produce para uso humano o para otros programas. Las salidas que requieren procesamiento separado deben ser contabilizadas: en una aplicación de remuneraciones una función de salida que genere 100 cheques contaría como una sola salida.
Ej: pantallas, informes impresos, archivos en disco, sets de cheques, facturas impresas.
58
Las consultas se dividen en dos partes: la porción de entrada y la porción de salida. Ejemplos de consultas: consulta de un usuario sin actualizar un archivo, mensajes de ayuda, mensajes de selección. Una consulta típica sería una relacionada con una reservación aérea.
Pantallas que le permiten a los usuarios interrogar una aplicación y solicitar asistencia o información, tal como pantallas de ayuda (HELP).
59
Archivos internos lógicos: Colección lógica de registro que la aplicación modifica o actualiza una tabla de una base de datos.
Archivos externos de interfaz: bases de datos compartidas, archivos lógicos direccionables desde o hacia otra aplicación. Es un conjunto de datos definidos por el usuario, que están relacionados lógicamente y que sólo son usados para propósitos de referencia.
FI.1 comunicación de datos
FI.2 funciones distribuidas
FI.3 objetivos de performance
FI.4 configuración usada fuertemente
FI.5 tasa de transacciones
FI.6 entrada de datos en línea
FI.7 eficiencia del usuario final
FI.8 actualización en línea
FI.9 procesamiento complejo
FI.10 reusabilidad
FI.11 facilidad de instalación
FI.12 facilidad operacional
FI.13 sitios múltiples
FI.14 facilitamiento del cambio
CGS… Factores de influencia
60
0 factor no presente o sin influencia
1 influencia insignificante
2 influencia moderada
3 influencia promedio
4 influencia significativa
5 influencia fuerte
Escala de evaluación
61
62
Comunicación de datos: implica que datos y/o información de control son enviadas o recibidas. La evaluación es un 0 para aplicaciones batch, y un 5 para aplicaciones en que predomina el teleproceso;
Funciones distribuidas: analiza si una aplicación es monolítica y opera en un solo procesador o si es distribuida. 0 para aplicaciones monolíticas y un 5 para aplicaciones que se ejecutan dinámicamente en varios procesadores;
63
Objetivos de performance: la evaluación sería un 0 si no hay establecido ningún criterio especial de performance, y un 5 si los usuarios insisten en objetivos de performance muy rigurosos que requieren un esfuerzo;
Configuración usada fuertemente: la evaluación sería un 0 si la aplicación no tiene restricciones especiales de uso, y un 5 si el uso anticipado requiere especial esfuerzo para ser logrado;
64
Tasa de transacciones: la evaluación sería un 0 si el volumen de transacciones no es significativo, y un 5 si el volumen es lo suficientemente significativo como para producir stress en la aplicación y requerir un esfuerzo especial para alcanzar throughputs deseados;
Entrada de datos en línea: la evaluación sería un 0 si menos del 15% de las transacciones son interactivas, y un 5 si más del 50% de las transacciones son interactivas
65
Eficiencia del usuario final: la evaluación sería un 0 si no hay usuarios finales o no hay requerimientos especiales para los usuarios finales, y un 5 si los requerimientos de eficiencia de usuarios finales son lo suficientemente rígidos como para requerir un esfuerzo;
Actualización en línea: la evaluación sería 0 si no hay, y un 5 si las actualizaciones son obligatorias y especialmente difíciles;
66
Procesamiento complejo: la evaluación sería 0 si no hay, y un 5 en casos que requieren decisiones lógicas extensas, matemática compleja, procesamiento de excepciones;
Reusabilidad: la evaluación sería un 0 si la funcionalidad se planifica, y un 5 si mucha de la funcionalidad y los artefactos del proyecto se pretende que sean usados ampliamente por otras aplicaciones;
67
Facilidad de instalación: la evaluación sería un 0 si este factor es insignificante, y un 5 si la instalación es importante y tan restrictiva que requiere un esfuerzo especial para cumplirla satisfactoriamente;
Facilidad operacional: la evaluación sería un 0 si este factor es insignificante, y un 5 si la facilidad operacional es tan restrictiva que requiere un esfuerzo especial para alcanzarla;
68
Sitios múltiples: la evaluación sería un 0 si hay solo un sitio planificado de uso, y un 5 si el proyecto y sus artefactos se pretenden sean usados en muchos lugares;
Facilitamiento del cambio: la evaluación sería un 0 si el cambio no ocurre, y un 5 si la aplicación se desarrolla específicamente para permitir a los usuarios finales el hacer cambios rápidos para controlar datos o tablas que ellos mantienen con la ayuda de la aplicación.
69
La cuenta total debe ajustarse utilizando la siguiente ecuación:
PF = c-total x (0,65 + 0,01 x Fi)
Donde c-total es la suma de todas las entradas PF obtenidas y Fi (i=1 a 14) son los "valores de ajuste de complejidad".
70
Factor de ponderación
Parámetro de medición Cuenta Simple Media Compl.
Número de entradas del usuario
3 X 3 4 6 = 9
Número de salidas del usuario 2 X 4 5 7 = 8
Número de consultas del usuario
2 X 3 4 6 = 6
Número de archivos 1 X 7 10 15 = 7
Número de interfaces externas 4 X 5 7 10 = 20
Cuenta total 50
Cálculo de puntos de función
Se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56
Las métricas de proyectos de software
convencionales (LDC o PF) se aplican
en la estimación de proyectos de
software OO. Sin embargo, estas
métricas no proporcionan suficiente
granularidad para la planificación y los
ajustes de esfuerzo que se requieren
conforme se itera a lo largo de un
proceso evolutivo o incremental.
Métricas orientadas a objetos
71
Lorenz y Kidd, sugieren el siguiente
conjunto de métricas OO:
Número de guiones de escenario.
Es una secuencia detallada de pasos
que describen la interacción entre el
usuario y la aplicación;
Número de clases clave. Son los
componentes enormemente
independientes definidos con
antelación en análisis OO; 72
Número de clases de apoyo. Es un
indicio de la cantidad de esfuerzo
indispensable para desarrollar el
software, así como un indicio de la
cantidad de reutilización;
Número promedio de clases de
apoyo por clase clave. Las clases
clave se conocen en etapas iníciales.
Las clases de apoyo se definen a lo
largo del curso de éste;
Número de subsistemas. 73
Los casos de uso se define en etapas
tempranas del proceso de software, lo
que permite emplearlo en la
estimación antes de iniciar las
actividades significativas de modelado
y construcción.
Los casos de uso describen (al menos
indirectamente) funciones y
características visibles al usuario que
son requisitos básicos para un sistema
Métricas orientadas a casos de uso
74
El caso de uso es independiente del
lenguaje de programación. Además, el
número de casos de uso es
directamente proporcional al tamaño
de la aplicación en LDC, así como al
número de casos de prueba que
tendrán que diseñarse para ejercitar
completamente la aplicación.
75
Entre las medidas que se pueden
recopilar son:
Número de páginas web
estáticas;
Número de páginas web
dinámicas;
Número de vínculos internos de
página;
Número de objetos de datos
persistentes;
Métricas de proyectos de IWeb
76
Número de sistemas externos en
interfaz;
Número de objetos de contenido
estático;
Número de objetos de contenido
dinámico;
Número de funciones
ejecutables.
77
Métricas para calidad del software
La meta primordial de la IS es
producir un sistema, aplicación o
producto de alta calidad dentro de un
marco temporal que satisfaga una
necesidad del mercado.
El logro de esta meta requiere que los
IS apliquen métodos eficaces
acoplados con herramientas
modernas. Además se debe medir si
se logrará la alta calidad.
78
Se pueden utilizar muchas medidas de
calidad, el impulso primario, es medir
los errores y defectos. Las métricas
derivadas de estas medidas
proporcionan un indicio de la
efectividad de la garantía de la calidad
del software y de las actividades de
control tanto de los individuos como
del grupo.
79
Las métricas como los errores en el
producto de trabajo por punto de
función, errores descubiertos por hora
de revisión de la eficacia de cada una
de las actividades implicadas en la
métrica. Los datos de error también
se pueden emplear en el cálculo de la
eficacia en la eliminación de defectos
(EED)
80
Los indicadores útiles para el equipo de
proyecto son:
Corrección. La medida más común para
la corrección es defectos por KLDC,
donde un defecto se define como una
falta comprobada de concordancia con
los requisitos. Cuando se considera la
calidad global de un producto, los
defectos son los problemas que reporta
el usuario después que se liberó.
Medición de la calidad
81
Facilidad de mantenimiento. Es la
sencillez con la que un programa puede
corregirse si se encuentra un error,
adaptarse si su entorno cambia, o
mejorar si el cliente desea un cambio en
los requisitos. No existe forma de medir
directamente, por lo que se emplean
medidas indirectas. Una simple medida
orientada al tiempo es el tiempo medio
de cambio (TMC) 82
Integridad. Mide la habilidad de un
sistema para resistir ataques a su
seguridad.
La medición de la integridad requiere
definir: amenaza y seguridad.
La integridad de un sistema se define:
Integridad = 1- (amenaza x (1-seguridad))
Si la probabilidad de amenaza es 0.50 y
la posibilidad de repeler un ataque es
sólo 0.25, la integridad es 0.63
(inaceptablemente baja). 83
Facilidad de uso. Con frecuencia, un
programa que no es fácil de usar está
condenado al fracaso, incluso si las
funciones que realiza son valiosas.
Es un intento por cuantificar la sencillez
de la aplicación al utilizarla y se puede
medir en términos de características
84
Una métrica de calidad que ofrece
beneficios tanto en ámbito del proyecto
como en el proceso es la eficacia en la
eliminación de defectos (EED). En
esencia, la EED es la medida de la
habilidad de filtrar las actividades de la
garantía de cualidad y de control
conforme se aplica a través de las
actividades del marco de trabajo.
Eficacia en la eliminación de defectos
85
Cuando se considera un proyecto como
un todo, la EED se define:
EED = E/(E+D)
E es el número de errores encontrados
antes de entregar el software.
D es el número de defectos encontrados
después de la carga.
El valor ideal de la EED es 1
86
La EED también se puede aplicar en el
proyecto para valorar la habilidad de un
equipo de encontrar errores antes de
que pasen a la siguiente actividad.
Por ejemplo, la tarea de análisis de
requisitos produce un modelo de análisis
que se revisa para encontrar y corregir
errores. Si no se encuentran errores
pasan al diseño.
87
Cuando se aplica en este contexto la
EED se redefine como:
EEDi = Ei/(Ei+Di+1)
Ei es el número de errores encontrados durante la actividad i de la IS.
Ei+1 es el número de errores encontrados durante la actividad i+1 de IS que se puede seguir para llegar a errores que no fueron descubiertos en la actividad i de IS
88
Integración de las métricas dentro del proceso de Sw
La mayoría de los desarrolladores de
software todavía no miden y,
lamentablemente, muchos tienen
poco deseo de comenzar.
El problema es cultural !!!
89
Si no se mide, no existe una forma real
de determinar si se está mejorando. Y si
no se mejora, se está perdido.
Si se emplea la medición para establecer
una línea base del proyecto, cada uno de
los temas: desarrollar estimaciones de
proyecto significativas, producir
sistemas de calidad, tener el producto a
tiempo, se vuelven más manejables.
Argumentos para las métricas del software
90
Los datos de la línea base deben tener
los siguientes atributos:
Los datos deben ser razonablemente
precisos;
Los datos deben recopilarse para
tantos proyectos como sea posible;
Las medidas deben ser consistentes;
Las aplicaciones deben ser similares
al trabajo que se estimará.
Establecimiento de una línea base
91
La recopilación de datos requiere una
investigación histórica de los proyectos
previos para reconstruir los datos
requeridos
Recopilación, cálculo y evaluación de métricas
Proceso
de IS
Proyecto
de SW
Producto
de SW
Recopilacion
de datos Cálculo de
métricas Evaluación
Métricas
medidas
métricas
indicadores 92