Ingeniería de Software

Unidad III
Gestión de Proyectos de Software

Semana 9

Tema

Métricas en la Calidad de Sw.

Objetivos Generales:
Comprender correcta y eficientemente
los conceptos y principios del espectro
de técnicas de Ingeniería de Software
que puedan ser aplicadas en proyectos
de software.

Desarrollar una cultura de ingeniería

de software.
Objetivos Específicos:
Aplicar correctamente los conceptos y
principios relacionados a la Ingeniería de
Software en la resolución de casos
prácticos para la gestión de proyectos de
software de calidad.

Utilizar herramientas para el modelado y

gestión de proyectos de software.

Utilizar metodologías agiles en el

desarrollo de software.
Objetivos Instruccionales:
Tener una visión mas profunda
proporcionando un mecanismo para
realizar una evaluación objetiva.

Aplicación de la medición al proceso

de software con el intento de mejorarlo
sobre una base continua.
Fundamentos de métricas de gestión Razones para medir los procesos, productos
y recursos
Caracterizar:
Entender el proceso actual, entorno, etc.
Disponer de información de la situación anterior al cambio.

Evaluar:
Determinar la consecución de objetivos
Identificar fortalezas y debilidades del proceso

Predecir:
Entender las relaciones entre procesos y productos
Establecer objetivos alcanzables de calidad, costes y agendas

Mejorar:
Identificar causas y oportunidades de mejora
Seguir el rendimiento de los cambios y compararlo con líneas base
Fundamentos de métricas de gestión Medidas, Métrica, e Indicadores
Medida:
Proporciona una indicación cuantitativa de la extensión, cantidad,
dimensiones, capacidad o tamaño de algunos atributos de un proceso o
producto.

Medición:
Es el acto de obtener una medida.

Métrica:
Es el resultado de efectuar evaluaciones durante un periodo largo de
tiempo sobre algún(os) aspecto(s) que un conjunto de proyectos,
procesos que servirán de línea base.

Indicador:
Permite ajustar el producto, el proyecto o el proceso para que las cosas
salgan mejor.
MEDICIÓN
Los tres objetivos fundamentales de la medición son
(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.
Definiciones generales:
Métrica: medida cuantitativa del grado en que un
sistema, componente o proceso posee un
atributo dado (IEEE, 1993). Incluye el método de
medición.
Medición: proceso por el cual se obtiene una medida.
Medida: valor asignado a un atributo de una entidad
mediante una medición.
CARACTERÍSTICAS
 Berard [Laranjeira ‘90] define cinco características que dan
lugar a unas métricas especializadas:
 Localización: indica la forma en que se concentra la
información dentro de un programa.
 La información se concentra mediante el
encapsulamiento tanto de datos como de procesos dentro
de los límites de una clase u objeto.
 Encapsulamiento: Berard [Pressman ‘07] define el
encapsulamiento como “el empaquetamiento (o enlazado)
de una colección de elementos”. El encapsulamiento
comprende las responsabilidades de una clase, incluyendo
sus atributos (y otras clases para objetos agregados) y
operaciones, y los estados de la clase, según se definen
mediante valores específicos de atributos.
Fundamentos de métricas de gestión El Proceso e Indicadores del Proyecto
• Las métricas deben recopilarse para que los
indicadores del proceso y del producto puedan
ser ciertos.
• Los indicadores del proyecto permiten al gestor
de proyectos del software:
 Evaluar el estado del proyecto en curso.
 Seguir la pista de los riesgos potenciales.
 Detectar las áreas problemas antes de que se conviertan en
criticas.
 Ajustar el flujo y las tareas del trabajo.
 Evaluar la habilidad del equipo del proyecto en controlar la
calidad de los productos de trabajo del software.
Fundamentos de métricas de gestión
Gestión de un proyecto…
Que es:
Es lo primero que hay que hacer antes de empezar la labor técnica
de un proyecto.

Finalidad:
Determinar cuanto va a costar (en tiempo y dinero),
Cuantos recursos son necesarios,
Que tareas se van a realizar.

Que tiempo:
Su actividad se prolonga a lo largo de todo el proyecto corrigiendo
desviaciones y previniendo riesgos
Fundamentos de métricas de gestión
…Gestión de un proyecto…
¿Que se gestiona?

Métricas
•Se mide para mejorar.
•Debemos saber cuanta es nuestra productividad, cuanta
calidad damos, que productos aumentan la productividad, quien
produce mas y quien menos.
• Las métricas están relacionadas con los costes, el tiempo.

Planificación
•Estimar el esfuerzo humano requerido, la duración cronológica del
proyecto y su coste monetario.
•Generalmente se hace en base a experiencias anteriores, de ahí la
importancia de las métricas.
Fundamentos de métricas de gestión
…Gestión de un proyecto…
¿Que se gestiona?

Análisis de riesgos
Localizar todos los problemas que le pueden surgir a nuestro
proyecto, y preparar tácticas para combatirlas:

• Identificación de riesgos
• Calculo de riesgos
• Priorización de riesgos
• Estrategias de control de riesgos
• Resolución de riesgos
• Supervisión de riesgos
Fundamentos de métricas de gestión
…Gestión de un proyecto
¿Que se gestiona?

Planificación temporal
•Se identifican las tareas de ingeniería a realizar
•Se establecen sus interdependencias
•Se estima su coste (esfuerzo, duración, disponibilidad de
recursos)
•Se asignan recursos
•Se establece la red de tareas

Seguimiento y control
El gestor controla el proyecto y corrige desviaciones
Métricas del proceso de software Determinantes de la calidad del software y
de la efectividad de la organización
Producto

Características Condiciones
del cliente del negocio

Proceso

Personas Tecnología

Entorno de
desarrollo
 Métrica del Proceso
(Propósito estratégico)
Métricas del proceso de software

Métricas privadas:
Sólo es conocido por el equipo del proyecto, pero publicas
por todos los miembros del equipo
• Índices de defecto por individuo o módulo
• Líneas de código o puntos de función por modulo y función
• Errores encontrados durante la revisión con técnicas formales

Métricas públicas:
Asimilan información que originalmente era privada de
particulares y equipos permitiendo a las organizaciones
hacer los cambios estratégicos para mejorar el proceso del
software.
• Índice de defectos a nivel de proyecto
 Mejora estadística de proceso del software
Métricas del proceso de software

Utiliza el análisis de fallos del software para recopilar

información de errores y defectos encontrados al
desarrollar y utilizar una aplicación de sistema o producto.
Funciona de la siguiente manera:
•Todos los errores se categorizan
•Se registra tanto el coste de corregir cada error como el del defecto
•El numero de errores y defectos de cada categoría se cuentan y se ordenan
•Se computa l coste global de errores y defectos de cada categoría
•Los datos resultantes se analizan para detectar las categorías que producen
el coste mas alto para la organización
•Se desarrollan planes para modificar el proceso con el intento de eliminar la
clase de errores y defectos que sean mas costosos.

La mejora estadística del proceso de software ayuda a la organización a descubrir

donde ellos son fuertes y donde no
Métricas del proceso de software Causas de defectos y su origen para cuatro
proyectos de software
Lógica (20%)
Manejo de datos (10.9%)

Interfaz de software (6.0%) Estándares (6.9%)

Interfaz hardware (7.7%)

Comprobación de errores
(10.9%) Especificaciones (25.5%)

Interfaz de usuario (11.7%)

Métricas del proceso de software Diagrama de espina para el factor de
calidad: Defectos de especificación (25.5%)
Especificación ambigua
Requisitos perdidos

Defecto de especificación

Cliente equivocado
consultado

Cliente dio información

equivocada

Peticiones inadecuadas

Información «La colección de

anticuada
utilizada métricas del proceso
es el conductor para
la creación del
Requisitos incorrectos Requisitos cambiados diagrama de espina»
 Métrica del Proyecto
(Carácter táctico)
Métricas del proyecto de software

• La métrica del proyecto de software se usa por el

equipo del software para adaptar el flujo de
trabajo del proyecto y las actividades técnicas.
• La utilización de métricas para el proyecto tiene
dos aspectos fundamentales:
 Se utilizan para minimizar la aplicación de desarrollo haciendo
los ajustes necesarios que eviten retrasos y reduzcan
problemas y riesgos potenciales.
 Se utilizan para evaluar la calidad de los productos en el
momento actual y cuando sea necesario.
 …Métrica del Proyecto
Métricas del proyecto de software

Todo proyecto debe medir:

 Entradas:
La dimensión de los recursos (personas, entornos) que se
requiere para realizar el trabajo.

 Salidas:
Medidas de la entrega o productos creados durante el
proceso de ingeniería de software.

 Resultados:
Medidas que indican la efectividad de las entregas.
 Métrica del Software
Métricas del proyecto de software

Medimos para:

•Indicar la calidad del producto

•Evaluar la productividad personal

•Evaluar beneficios

•Tener una línea base de estimación

•Justificar el uso de nuevas herramientas

 Mediciones del software
Categorías básicas de mediciones

Medidas directas:
•Del proceso del software:
Coste, el esfuerzo en horas o personas

•Del producto:
LDC, velocidad de ejecución, tamaño de memoria

Medidas indirectas:
•Funcionalidad
•Calidad
•Complejidad
•Eficiencia
•Fiabilidad
 Clasificación de las métricas de un
Categorías básicas de mediciones

Software
• De productividad: Rendimiento del proceso de la ingeniería del
software

• De calidad: Como se ajusta el software a las especificaciones del

cliente

• Técnicas: La complejidad del software, su facilidad de mantenimiento

• Orientadas al tamaño: Medidas directas del software

• Orientadas a la función: Medidas indirectas

• Orientadas a la persona: Cuanto produce el personal, dependiendo

de las herramientas que usan
 Métricas para la Calidad…
Categorías básicas de mediciones

Miden el número de defectos no descubiertos en la

prueba, la facilidad de mantenimiento del sistema y la
eficiencia de eliminar los defectos.

Factores que afectan a la calidad:

• Operación del producto (uso)

• Revisión del producto (modificación)

• Transporte (modificación para que funcione en otro

entorno)
Categorías básicas de mediciones
…Métricas para la Calidad…
Corrección:
Definición: Grado en que el software realiza la función encomendada.
Medida: Defectos por KLDC (medida mas común), Defectos por PF
Defecto: Carencia verificada de conformidad con los requisitos. Los
comunica el usuario a lo largo de un periodo de tiempo determinado (un
año).

Facilidad de mantenimiento:
Definición: Facilidad con la que se puede corregir un programa si se
encuentra un error, adaptarlo a un cambio de entorno, o mejorarlo ante
una petición del cliente
Medida: No hay. Son indirectas. TMC (Tiempo Medio de Cambio), es el
tiempo que lleva analizar, diseñar, implementar, probar y distribuir un
cambio.
Desperdicio: Coste de corregir los defectos encontrados después de
haber distribuido el software a los usuarios finales
Categorías básicas de mediciones
…Métricas para la Calidad…
Integridad:
Definición: Habilidad de un sistema para resistir ataques (accidentales o
intencionados) contra su seguridad tanto a los programas como a los
datos y documentos
Amenaza: Probabilidad de que un ataque ocurra en un tiempo
determinado
Seguridad: Probabilidad de que se puede repeler el ataque

Integridad = ∑ [(1-amenaza) * (1-seguridad)] para cada tipo de ataque

Facilidad de uso:
Definición: Es una cuantificación de la amigabilidad de uso
Características:
•Habilidad intelectual y/o física para aprender el sistema
•Tiempo necesario para llegar a ser moderadamente eficiente en el
uso del sistema
• Aumento neto en productividad cuando se utiliza eficientemente .
•Valoración subjetiva del usuario hacia el sistema
 Métricas Orientadas al Tamaño…
Categorías básicas de mediciones

• Las métricas del software orientadas al tamaño

provienen de la normalización de las medidas de
calidad y/o productividad, considerando el
“tamaño” del software que se haya producido.
• Para desarrollar métricas que se puedan
comparar entre distintos proyectos, se
seleccionan las líneas de código como valor de
normalización.
 …Métricas Orientadas al Tamaño
Categorías básicas de mediciones

Proceden de la normalización de medidas de calidad y productividad

considerando el tamaño del software.
Ejemplo:

Proyecto KLDC Dinero Esfuerzo Pag. Docs Errores Personas

(personas-mes)

a1 12,1 168 24 365 29 3

b1 27,2 440 62 1224 86 3
c1 20,1 314 43 1050 64 6
Algunas métricas --> Formulas:

(KLDC por persona-mes): Productividad = KLDC / persona-mes

(Errores por KLDC): Calidad = Errores / KLDC
(Coste por KLDC): Coste = Dinero / KLDC
(Pagina de documentación por KLDC): Documentación = Paginas de documentación / KLDC

Todo se basa en la KLDC pero esta medida es un artificio, que depende del lenguaje de
programación utilizado.
Categorías básicas de mediciones
Métricas orientadas a la función…
Puntos de función:
•Funcionalidad o utilidad de la aplicación
•La unidad básica de medida son los Puntos de Función

Calculo de puntos de función

Factor de ponderación

Parámetro de medición Cuenta Simple Medio Complejo Total

Numero de entradas del usuario x 3 4 6 =
Numero de salidas del usuario x 4 5 7 =
Numero de peticiones al usuario x 3 4 6 =
Numero de archivos x 7 10 15 =
Numero de interfaces externos x 5 7 10 =
Cuenta-Total
Categorías básicas de mediciones …Métricas Orientadas a la función…
Formulas:
Puntos de Función = Cuenta-Total * [0,65+0,01 * sum(Fi)]
Donde Fi (i = 1 hasta 14) son unos valores de ajuste de complejidad
De 0 a 5 (0=sin influencia, 5=esencial)

1.¿Requiere el sistema de copias de seguridad y recuperación fiable?

2.¿Se requieren comunicaciones de datos?
3.¿Existen funciones de procesamiento distribuido?
4.¿Es critico el rendimiento?
5.¿Será ejecutado el sistema en un entorno operativo existente y fuertemente utilizado?
6.¿Necesita el sistema entrada de datos interactiva?
7.¿La entrada de datos interactiva requiere que las transacciones de entrada se lleven a
cabo sobre múltiples pantallas o varias operaciones?
8.¿Se actualizan los archivos maestros de forma interactiva?
9.¿Son complejas las entradas, las salidas, los archivos o peticiones?
10.¿Es complejo el procesamiento interno?
11.¿Se ha diseñado código para ser reutilizado?
12.¿Están incluidas en el diseño la conversión y la instalación?
13.¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes
organizaciones?
14.¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada
por el usuario?
Productividad = PF / personas-mes Calidad = Errores / PF
Coste = Dinero / PF Documentación = Paginas documentación / PF
Categorías básicas de mediciones …Métricas Orientadas a la función…
Ventajas:

• Los PF son independientes del lenguaje de

programación

• Se basan en datos que se puedan conocer antes de

empezar el proyecto

Inconvenientes:

• Los datos se basan en juicios subjetivos

• Su valor no es físico. No tiene unidades

Categorías básicas de mediciones …Métricas Orientadas a la función
Ejercicio
Un administrador de software esta a cargo del desarrollo de un
sistema de software de seguridad critico que se diseña para controlar
una maquina de radioterapia para tratar a los pacientes que sufren de
cáncer. Este sistema esta incrustado en la maquina y debe ejecutarse
en un procesador de propósito especial con una cantidad fija de
memoria (32 MB). La máquina se comunica con un sistema de base
de datos de pacientes para obtener los detalles del paciente y,
después del tratamiento automáticamente registra los datos de
radiación suministrada y otros detalles del tratamiento en la base de
datos. La productividad media del equipo de desarrollo es de 6 PF/p-
m.
 
Estime el esfuerzo y el costo total requerido para desarrollar este
sistema en Visual Basic, siendo la tarifa laboral de US$ 3,000 por p-
m. Además se sabe que la LDC/PF (media) del Visual basic es 32 y
que se requieren 8,000 LDC. Los valores de ajuste de la complejidad
suman 53.
Categorías básicas de mediciones …Métricas Orientadas a la función
Solución del ejercicio

DATOS INFORMATIVOS:
Productividad Media (PM) = 6 PF/p-m
La tarifa local es de = US$ 3,000 p-m
 
DETERMINANDO LOS PUNTOS DE FUNCION
PF = (8000/32) x ( 0.65 + 0.01 x 53) = 295
 
ESTIMACIONES:
Coste del PF = 3000 / 6 = US$ 500
Costo total = US$ 500 x 295 = US$ 147,500
Esfuerzo = 295 / 6 = 49.16 = 49 p-m
 Factores que pueden incidir en la
productividad
Factor % Aproximado de variación
Factores humano 90
Factores del problema 40
Factores del proceso 50
Factores del producto 140
Factores de los
40
recursos
•Factores humanos: El tamaño y la experiencia del equipo de desarrollo
•Factores del problema: La complejidad del problema a resolver y el
numero de cambios en el diseño
•Factores del proceso: Técnicas de ingeniería del software utilizadas, y
disponibilidad de herramientas CASE
•Factores del producto: Fiabilidad y rendimiento del sistema basado en
computadora
•Factores de los recursos: De software (herramientas CASE...) y de
hardware
 Métricas de diseño de alto nivel

 Se concentran en las características de la arquitectura del

programa , con énfasis en la estructura arquitectónica y en la
eficiencia de los módulos.
 Estas métricas son de caja negra en el sentido que no requieren
ningún conocimiento del trabajo interno de un módulo en
particular del sistema.

38
 Card y Glass definen las siguientes tres
medidas de complejidad
 La complejidad estructural, S(i), de un módulo i se define de la
siguiente manera: S(i)=fout(i). Donde fout(i) es la expansión
del módulo i. La expansión indica el número de módulos que
son invocados directamente por el módulo i.

39
 Card y Glass definen las siguientes
tres medidas de complejidad
 La complejidad de datos, D(i), proporciona una indicación de la
complejidad en la interfaz interna de un módulo i y se define
como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el número de
variables de entrada y salida que entran y salen del módulo i.

40
 Card y Glass definen las siguientes
tres medidas de complejidad
 La complejidad del sistema, C(i), se define como la suma de las
complejidades estructural y de datos : C(i)= S(i) + D(i)
 A medida que crecen los valores de complejidad , la complejidad
arquitectónica o global del sistema también aumenta. Esto lleva
a una mayor probabilidad de que aumente el esfuerzo necesario
para la integración y las pruebas.

41
 Fenton sugiere varias métricas de morfología simples que
permiten comparar diferentes arquitecturas mediante un conjunto
de dimensiones directas.

42
 Métricas a aplicar
Tamaño= n + a . Donde n es el número
de nodos (módulos) y a es el número de
arcos (líneas de control). Para la
arquitectura mostrada se tiene tamaño=
17+18=35.
Profundidad= camino más largo desde el
nodo raíz a un nodo hoja. Para el
ejemplo Profundidad= 4
Amplitud=número máximo de nodos de
cualquier nivel de la arquitectura. Para el
ejemplo amplitud= 6

43
 Relación arco a nodo, r=a/n, mide la densidad
de conectividad de la arquitectura y
proporciona una indicación sencilla de
acoplamiento de la arquitectura. Para el
ejemplo r=18/17= 1.06

44
 Consejos sobre la línea base

• Los datos deben ser razonablemente precisos, han de

evitarse la suposición sobre proyectos anteriores.

• Los datos deben obtenerse de tantos proyectos como

sea posible.

• Las medidas deben ser consistentes. LDC distintas para

cada lenguaje de programación.

• Las aplicaciones deben ser similares a la que va a ser

estimada.
 LDC / PF (media)
Lenguaje de programación LDC /PF (media)
Ensamblador 320
Cobol 106
Fortran 106
Pascal 90
Ada 53
Lenguajes orientados a objetos 30
Lenguajes de cuarta generación 20
Generadores de código 15
SQL 12
Power Builder 16
C++ 64
Visual Basic 32
 Integración de las métricas dentro del
proceso de ingeniería del software

• Muchos diseñadores del software no coleccionan las

medidas.
• Sin las medidas es imposible determinar si un proceso está
mejorando o no.
• Las líneas base de métricas constan de datos recogidos de
proyectos de software desarrollados anteriormente.
Conseguir estos datos de proyectos históricos es muy difícil,
si los diseñadores anteriores no coleccionaron los datos de
una manera continua.
 Integración de las métricas dentro del
proceso de ingeniería del software
Establecimiento de una Línea Base

Los datos de la Línea Base deben tener los siguiente atributos:

1. Deben ser razonablemente exactos

2. Deben reunirse del mayor numero de proyectos que sea

posible
3. Las medidas deben ser consistentes

4. Las aplicaciones deben ser semejantes para trabajar

con la estimación.
Integración de las métricas dentro del
proceso de ingeniería del software
Colección de métricas, computo y evaluación

Proceso de
ingeniería
de software

Recopilació
Proyecto de
n de datos
software Medidas

Calculo de
Producto de
software métricas Métricas

Evaluación
de métricas Indicador
es
Proceso de recopilación de métricas del software
Establecimiento de un programa de métricas de
software
• Identifique los objetivos del negocio

• Identifique lo que se desea saber o aprender

• Identifique los subobjetivos

• Identificar las entidades y atributos relativos a esos subobjetivos

• Formalizar los objetivos de la medición

• Identificar preguntas que puedan cuantificarse y los indicadores que se

van a usar para ayudar a conseguir los objetivos de medición.
• Identificar los elementos de datos que se van a recoger para construir los
indicadores que ayuden a responder a las preguntas planteadas.
• Definir las medidas a usar y hacer que estas definiciones sean
operativas.
• Identificar las acciones que serán tomadas para mejorar las medidas
indicadas.
• Preparar un plan para implementar estas medidas.
 Apreciación global
• El proceso del software y las métricas del producto
son una medida cuantitativa que permite a la gente
del software tener una visión profunda de la eficacia
del proceso del software y de los proyectos que
Resumen

dirigen utilizando el proceso como marco de trabajo.

• En la dirección de proyecto de software, estamos
principalmente interesados en la evaluación para
determinar las mejoras en la calidad y productividad.
• Hay cuatro razones para medir los procesos del
software y recursos: Caracterizar, Evaluar, Predecir,
y Mejorar.
 Factores de calidad de McCall
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.

52
 Factores de calidad
McCall y colegas (1997)

Facilidad de Portabilidad
mantenimiento Reusabilidad
Interoperatividad
Flexibilidad
Facilidad de prueba
Revisión del Transición del
Producto producto

Operación
del producto

Corrección Fiabilidad Usabilidad Integridad Eficiencia

53
 Operación del Producto
Corrección : Hasta donde satisface un programa su
especificación y logra los objetivos del cliente.
Fiabilidad: Hasta dónde se puede esperar que un
programa lleve a cabo de su función con la exactitud
requerida.
Eficiencia: La cantidad de recursos informáticos y de
código necesarios para que un programa realice su
función.

54
 Integridad: Hasta dónde se puede controlar el acceso al
software o a los datos por personas no autorizadas.
Usabilidad (facilidad de manejo):El esfuerzo
necesario para aprender a operar los datos de entrada e
interpretar las salidas de un programa.

55
 Revisión del producto
Facilidad de mantenimiento: El esfuerzo necesario
para localizar y arreglar un error en un programa.
Flexibilidad: El esfuerzo necesario para modificar un
programa operativo.
Facilidad de prueba: El esfuerzo necesario para probar
un programa para asegurarse de que realiza su función
pretendida.

56
 Transición del producto
Portabilidad: El esfuerzo necesario para transferir el
programa de un entorno de sistema hardware y/o
software a otro entorno diferente.
Reusabilidad ( capacidad de reutilización): Hasta
donde se puede volver a emplear un programa ( o
partes de un programa) en otras aplicaciones.
Interoperatividad: El esfuerzo necesario para acoplar
un sistema con otro.

57
 Es difícil desarrollar medidas directas de los
factores de calidad señalados anteriormente, por
consiguiente se definen un conjunto de métricas
para desarrollar expresiones que utilicen los
factores de acuerdo a la siguiente relación:
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

58
 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)

59
 Métrica para el esquema de
puntuación:
Facilidad de auditoría: la facilidad con la que
se puede comprobar el cumplimiento de los
estándares.
Exactitud: la exactitud de lo cálculos y el
control.
Estandarización de comunicaciones: el grado
de empleo de estándares de interfaces, protocolos
y anchos de banda.
Complección: el grado con que se ha logrado la
implementación total de una función.
Concisión :Lo compacto que es el programa en
términos de líneas de código
60
  Consistencia: El empleo de un diseño uniforme y de
técnicas de documentación a lo largo del proyecto de
desarrollo 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 o
procedimental.
 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.
61
 Instrumentación:El grado con el que el
programa vigila su propio funcionamiento e
identifica los errores que ocurren.
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.

62
 Independencia del sistema de software: El
grado de independencia de programa respecto a
las características del lenguaje de programación
no estándar , características del sistema operativo
y otras restricciones del entorno.
Trazabilidad: La capacidad de seguir una
representación del diseño o un componente real
del programa hasta los requisitos.
Formación : El grado en que ayuda el software a
manejar el sistema a los nuevos usuarios.

63
 FURPS (Funcionality, Usability, Reliability,
Performance, Supportability)
 Hewlett Packard ha desarrollado un conjunto de
factores de calidad del software al que se le ha dado
el acrónimo de FURPS: funcionalidad, facilidad de
empleo, fiabilidad, rendimiento y capacidad de
soporte. Los factores de calidad son cinco y se
definen de acuerdo al siguiente conjunto de atributos:
 Funcionalidad. Se valora evaluando el conjunto de
características y capacidades del programa, la
generalidad de las funciones entregadas y la
seguridad del sistema global.
 Facilidad de uso. Se valora considerando factores
humanos, la estetica, consistencia y documentación
general.
64
  Fiabilidad. Se evalúa midiendo la frecuencia y
gravedad de los fallos, la exactitud de las salidas, el
tiempo medio entre fallos, la capacidad de
recuperación de un fallo y la capacidad de predicción
del programa.
 Rendimiento. Se mide por la velocidad de
procesamiento, el tiempo de respuesta, consumo de
recursos, rendimiento efectivo total y eficacia.
 Capacidad de soporte. Combina la capacidad de
ampliar el programa (extensibilidad), adaptabilidad y
servicios, así como la capacidad de hacer pruebas,
compatibilidad, capacidad de configuración, la
facilidad de instalación de un sistema y la facilidad
con que se pueden localizar los problemas

65
 Factores de Calidad ISO 9126
El estándar identifica seis atributos clave de
calidad:
Funcionalidad: El grado en que el software
satisface las necesidades indicadas por los
siguientes subatributos: idoneidad, corrección,
interoperatividad,conformidad y seguridad.
Confiabilidad: Cantidad de tiempo que el
software está disponible para su uso. Estaá
referido por los siguientes subatributos: madurez,
tolerancia a fallos y facilidad de recuperación.

66
  Usabilidad: Grado en que el software es fácil de
usar. Viene reflejado por los siguientes subatributos:
facilidad de comprensión, facilidad de aprendizaje y
operatividad.
 Eficiencia: Grado en que el software hace óptimo el
uso de los recursos del sistema. Viene reflejado por
los siguientes subatributos: tiempo de uso y recursos
utilizados.
 Facilidad de mantenimiento: La facilidad con que
una modificación puede ser realizada. Está indicada
por los siguientes subatributos: facilidad de análisis ,
facilidad de cambio, estabilidad y facilidad de
prueba.
 Portabilidad: La facilidad con que el software puede
ser llevado de un entorno a otro. Está referido por los
siguientes subatributos: facilidad de instalación,
facilidad de ajuste, facilidad de adaptación al cambio
67
 Paradoja de Jacob Bronkowski
“Año tras año ingeniamos instrumentos más exactos
con los que observar la naturaleza con mas exactitud.
Y cuando miramos las observaciones estamos
desconcertados de ver que todavís son confusas y
tenemos la sensación de que son tan inciertas como
siempre”

68
 Estructura para las métricas del
Software
 La medición asigna números o símbolos a atributos de
entidades en el mundo real. Para conseguirlo es
necesario un modelo de medición que comprenda un
conjunto consistente de reglas.
 Existe la necesidad de medir y controlar la complejidad
del software, es bastante difícil obtener un solo valor
para representar una "métrica de calidad", sin embargo
es posible desarrollar medidas de diferentes atributos
internos del programa como ser: modularidad efectiva,
independencia funcional y otros atributos. Estas
métricas y medidas obtenidas pueden utilizarse como
indicadores independientes de la calidad de los modelos
de análisis y diseño.

69
 Los principios básicos de la medición, sugeridos
por Roche, pueden caracterizarse mediante cinco
actividades:
Formulación. Obtención de medidas y métricas
del software apropiadas para la representación del
software en cuestión.
Colección. Mecanismo empleado para acumular
datos necesarios para obtener las métricas
formuladas.
Análisis. Cálculo de las métricas y la aplicación de
herramientas matemáticas.
Interpretación. Evaluación de los resultados de las
métricas en un esfuerzo por conseguir una visión
interna de la calidad de la representación.
Realimentación. Recomendaciones obtenidas de la
interpretación de métricas técnicas transmitidas al
equipo software.

70
 Ejiogu define un conjunto de atributos que
deberían acompañar a las métricas efectivas del
software. La métrica obtenida y las medidas que
conducen a ello deberían ser:
Simple y fácil de calcular.
Empírica e intuitivamente persuasiva.
Consistente y objetiva.
Consistente en el empleo de unidades y tamaños.
Independiente del lenguaje de programación.
Un eficaz mecanismo para la realimentación de
calidad.

71
 La experiencia indica que una
métrica técnica se usa únicamente
si es intuitiva y fácil de calcular. Si
se requiere docenas de contadores
y se han de utilizar complejos
cálculos, la métrica no será
ampliamente utilizada.

72
 Métricas del Modelo de Análisis
En esta fase es deseable que las métricas técnicas
proporcionen una visión interna a la calidad del
modelo de análisis. Estas métricas examinan el
modelo de análisis con la intención de predecir el
"tamaño" del sistema resultante; es probable que
el tamaño y la complejidad del diseño estén
directamente relacionadas.

73
 Otras Métricas para el Modelo de
Análisis
La Métrica Bang [De Marco]
Puede aplicarse para desarrollar una indicación del
tamaño del software a implementar como consecuencia
del modelo del análisis.
Métricas de la calidad de la especificación:
Davis y colegas proponen una lista de características que
pueden emplearse para valorar la calidad del modelo de
análisis y la correspondiente especificación de requisitos

74
 Métricas del Código Fuente
La teoría de la ciencia del software propuesta por
Halstead es probablemente la medida de complejidad
mejor conocida y minuciosamente estudiada. La
ciencia del software propuso la primera ley analítica y
cuantitativa para el software de computadora.
Utiliza un conjunto de medidas primitivas que pueden
obtenerse una vez que se han generado o estimado el
código después de completar el diseño.

75
 Estas medidas son:
n1: número de operadores diferentes que aparecen en le
programa.
n2: número de operandos diferentes que aparecen en el
programa.
N1: número total de veces que aparece el operador.
N2: número total de veces que aparecen el operando.

76
 Halstead utiliza medidas primitivas para
desarrollar expresiones par la longitud global del
programa; volumen mínimo potencial para un
algoritmo; el volumen real (número de bits
requeridos para especificar un programa); el
nivel del programa (una medida de la
complejidad del software); nivel del lenguaje
(una constante para un lenguaje dado); y otras
características tales como el esfuerzo de
desarrollo,,tiempo de desarrollo e incluso el
número esperado de fallos en el software.

77
 Halstead propone las siguientes métricas:
Longitud N se puede estimar como: N = n1log2n1 +
n2log2n2.
Volumen de programa se define como: V=N
n1log2(n1 + n2). Tomando en cuenta que V variará
con el lenguaje de programación y representa el
volumen de información (en bits) necesarios para
especificar un programa.

78
 Ejemplo:
Programa de ordenación por intercambio
SUBROUTINE SORT(X,N)
 

  DIMENSION X(N)

  IF (N .LT. 2) RETURN

  DO 20 I=2, N

    DO 10 J=1, I

    IF (X(I) .GE. X(J)) GO TO 10

      SAVE = X(I)

      X(I) = X(J)

      X(J) = SAVE

10 CONTINUE

20 CONTINUE

  RETURN

  END
79
   Operador Cuenta

1 Fin de sentencia 7

2 Subíndices de arreglos 6

3 = 5

4 IF() 2

5 DO 2

6 , 2

7 Fin de programa 1

8 .LT. 1

9 .GE. 1

10 GO TO 10 1

Total 28

De esta tabla se desprenden los valores

de n1=10 y N1=28.
80
   Operando Cuenta

1 X 6

2 I 5

3 J 4

4 N 2

5 2 2

6 SAVE 2

7 1 1

Total 22

De esta tabla se desprenden los valores de n2=7 y N2=22.

81
 Métricas para las Pruebas
 La mayoría de las métricas para pruebas se concentran en el
proceso de prueba, no en las características técnicas de las
pruebas mismas. En general, los responsables de las pruebas
deben fiarse en las métricas de análisis, diseño y código para
que sirvan de guía en el diseño y ejecución de los casos de
prueba.
 El esfuerzo de las pruebas también se puede estimar
utilizando métricas obtenidas de las medidas de Halstead.
Usando la definición del volumen de un programa, V, y
nivel de programa, NP, el esfuerzo de la ciencia del software
puede calcularse como:
 NP = 1/[(n1/2) x (N2/n2)] (Ec. 9.1)
 e = V/NP (Ec. 9.2)

82
 El porcentaje del esfuerzo global de pruebas a asignar
a un módulo k se puede estimar utilizando la siguiente
relación:
                Porcentaje de esfuerzo de pruebas(k) =
e(k)/e(i)         (Ec. 9.3)
Donde e(k) se calcula para el módulo k utilizando las
ecuaciones (Ec. 9.1) y (Ec. 9.2), la suma en el
denominador de la ecuación (Ec. 9.3) es la suma del
esfuerzo de la ciencia del software a lo largo de todos
los módulos del sistema.

83
  A medida que se van haciendo las pruebas, tres medidas
diferentes proporcionan una indicación de la compleción de
las pruebas:
 Medida de amplitud de las pruebas. Proporciona una
indicación de cuantos requisitos se han probado del numero
total de ellos. Indica la compleción del plan de pruebas.
 Profundidad de las pruebas. Medida del porcentaje de los
caminos básicos independientes probados con relación al
número total de estos caminos en el programa. Se puede
calcular una estimación razonablemente exacta del número de
caminos básicos sumando la complejidad ciclomática de todos
los módulos del programa.
 Perfiles de fallos. Se emplean para dar prioridad y categorizar
los errores. La prioridad indica la severidad del problema. Las
categorías de los fallos proporcionan una descripción de un
error, de manera que se puedan llevar a cabo análisis
estadístico de errores.

84
 MÉTRICAS DEL
MANTENIMIENTO
 Todas las métricas descritas pueden utilizarse para el
desarrollo de nuevo software y para el mantenimiento del
existente.
 El estándar IEEE 982.1-1988 sugiere el índice de madurez del
software (IMS) que proporciona una indicación de la
estabilidad de un producto software basada en los cambios
que ocurren con cada versión del producto. Con el IMS se
determina la siguiente información:
 MT=  Número de módulos en la versión
 actualFc=  Número de módulos en la versión actual que se
han cambiado
 Fa=  Número de módulos en la versión actual que se han
añadido
 Fe=  Número de módulos en la versión actual que se han
eliminado

85
 El índice de madurez del software se calcula de la
siguiente manera:
             IMS= [MT - (Fc + Fa + Fe)]/MT
A medida que el IMS se aproxima a 1 el producto se
empieza a estabilizar. El IMS puede emplearse
también como métrica para la planificación de las
actividades de mantenimiento del software.

86
 Toma de decisiones administrativas

Proceso de Producto de
Software software

Medidas
de Control Medidas de
predicción

Decisiones
administrativas

Ambas métricas influyen en la toma de

decisiones administrativas
87
 Métricas para predecir la calidad
A menudo es imposible medir los atributos de
calidad del software en forma directa.
Los atributos como la complejidad , la
mantenibilidad y la comprensión se ven
afectados por diversos factores y no existen
métricas directas para ellos.
Más bien es necesario medir un atributo interno
del software ( como el tamaño) y suponer que
existe una relación entre lo que se puede medir y
lo que se quiere saber.
De forma ideal , existe una relación clara válida
entre los atributos de software internos y
externos.
88
 Relación entre los atributos externos e
internos

Número de parámetros
del procedimiento
Mantenibilidad

Complejidad ciclomática
Fiabilidad
Tamaño del programa
Portabilidad en líneas de código

Número de mensajes de
Usabilidad error

Extensión del manual

de usuario
No dice qué relación es
89
 Métricas del producto
Se refiere a las características del software.
En general las organizaciones construyen sus bases de
datos históricas para relacionar las mediciones
obtenidas.
Se dividen en dos clases:
Métricas dinámicas recolectadas por las mediciones
hechas en un programa en ejecución.
Las métricas estáticas recolectadas por las mediciones
hechas en las representaciones del sistema como el
diseño, el programa o la documentación.

90
 Estas diferentes métricas están relacionadas con
diversos atributos de calidad.
Las métricas dinámicas ayudan a a valorar la
eficiencia y la fiabilidad de un programa
mientras que las métricas estáticas ayudan a
valorar la complejidad, la comprensión y la
mantenibilidad de un sistema de software.
Las métricas estáticas , por otro lado, tienen una
relación indirecta con los atributos de calidad.
Las métricas específicas relevantes dependen del
proyecto, de las metas del equipo de
administración de la calidad y del tipo de
software a desarrollar.

91
 Medición del proceso
cap. 25
Son datos cuantitativos de los procesos del software.
Se utilizan para evaluar si la eficiencia de un proceso
ha mejorado. Por ejemplo se puede medir el esfuerzo y
tiempo dedicado a las pruebas. Las mejoras efectivas
para los procesos de prueba reducen el esfuerzo , el
tiempo de prueba o ambos.

92
 Se pueden recolectar tres clases de
métricas del proceso:
1. El tiempo requerido para completar un proceso
particular:
 Tiempo total dedicado al proceso, el tiempo de
calendario, el tiempo invertido en el proceso por
ingenieros particulares, etc.
2. Los recursos requeridos para un proceso en
particular:
 Los recursos pueden ser el esfuerzo total en personas-
días, los costos de viajes, los recursos de cómputo,etc.

93
 3. El número de ocurrencias de un evento en particular:
 Ejemplos de eventos que se pueden supervisar son el
número de defectos descubiertos durante la
inspección del código, el número de peticiones de
cambios en los requerimientos, el número promedio
de líneas de código modificadas en respuesta a un
cambio de requerimientos, etc.

94
 Estimación del Costo del Software
Cap. 23
La estimación y calendarización del proyecto se llevan
a cabo de forma conjunta.
Sin embargo se debe contar con estimaciones previas
para ver los efectos sobre la calendarización y éstas se
actualizan de forma regular.
Permite la utilización efectiva de los recursos y una
adecuada planeación.

95
 Parámetros involucrados en el costo
total de un proyecto:
Costos de hardware y software , incluyendo
mantenimiento.
Costos de viajes y capacitación
Costos de esfuerzo ( pago a los ingenieros de
Software)
Para muchos proyectos , el costo dominante es el costo
de esfuerzo.

96
 Costos de esfuerzo:
Costos de proveer, calentar e iluminar las oficinas.
Costos del personal de apoyo como contadores ,
secretarias, limpiadores y técnicos.
Costos de las redes y las comunicaciones.
Costos de los recursos centralizados como bibliotecas,
los recursos recreativos,etc.
Costos de seguridad social y de beneficio de
empleados como las pensiones y seguros de salud.

97
 Factores que afectan la asignación de
precios al software.
Oportunidad de mercado: penetración de mercado con
cotización de bajos costos al inicio.
Incertidumbre: Si no hay seguridad en el costo
estimado, por alguna contingencia puede incrementar
su precio por encima del beneficio normal.
Términos contractuales: Reducir el costo a partir de
asumir restricciones como por ejemplo entrega del
código fuente y que el desarrollador lo pueda reutilizar
en otros proyectos.

98
 Volatilidad de los requerimientos: Si es probable
que los requerimientos cambien, podría reducirse
los precios para ganar un contrato. Después del
contrato se cargan precios altos a los cambios de
requerimientos.
Salud Financiera: Cuando los desarrolladores
tienen dificultades financieras podrían bajar sus
costos para ganar contratos. Esto es mejor que
quedar fuera del negocio o quebrar

99
 Productividad
Cuando se produce soluciones con diferentes atributos,
no tiene sentido comparar tasas de productividad, sin
embargo las estimaciones son necesarias para las
estimaciones del proyecto y para valorar si los
procesos o las mejoras tecnológicas son efectivas.
Por lo general estas estimaciones se basan en medir
algunos atributos del software y dividir el resultado
entre el esfuerzo total requerido para el desarrollo.

100
 Medidas utilizadas:
Relacionadas con el Tamaño: se relacionan con el
tamaño de alguna salida de una actividad. La medida
más común son las líneas de código fuente entregadas.
También se utiliza el número de instrucciones de
código objeto entregado o el número de páginas de la
documentación del sistema

101
 Medidas utilizadas:
Relacionadas con la función: se relacionan con la
funcionalidad total del software entregado. La
productividad se expresa en términos de la cantidad de
funcionalidad útil producida en un tiempo dado.
Ejemplos de esta medidas son puntos de función y
puntos de objetos .

102
 Técnicas de Estimación
No existe una forma simple de hacer una estimación
precisa del esfuerzo requerido para desarrollar un
sistema de software.
Por lo general, las estimaciones de los costos del
proyecto se cumplen por su propia naturaleza.
A pesar de las dificultades e impresiones las
organizaciones requieren hacer esfuerzos de software
y estimaciones de costos.

103
 Técnicas de estimaciones de costos
Modelado del algoritmo de costos:
 Se desarrolla un modelo utilizando información
histórica de costos que relaciona alguna métrica de
software( por lo general su tamaño) con el costo
del proyecto. Se hace una estimación de ésa
métrica y el modelo predice el esfuerzo requerido.
Opinión de expertos:
Se consultan varios expertos en las técnicas de
desarrollo de software propuestas y en el dominio
de la aplicación. Cada uno de ellos estima el costo
del proyecto. Estas estimaciones se comparan y
discuten. El proceso de estimación se itera hasta
que se acuerda una estimación.

104
 Técnicas de estimaciones de costos
Estimación por analogía:
Esta técnica es aplicable cuando otros proyectos en
el mismo dominio de aplicación se han
completado. Se estima el costo de un nuevo
proyecto por analogía con estos proyectos
completados.
Ley de Parkinson:
Establece que el trabajo se extiende para llenar el
tiempo disponible. El costo se determina por los
recursos disponibles más que por los objetivos
logrados. Si el software se tiene que entregar en 12
meses y se dispone de cinco personas, el esfuerzo
requerido se estima en 60 personas-mes
105
 Técnicas de estimaciones de
costos
 Asignar precios para ganar:
 El costo del software se estima independientemente de lo que
el cliente esté dispuesto a pagar por el proyecto. El esfuerzo
estimado depende del presupuesto del cliente y no de la
funcionalidad del software.

 Cada técnica de estimación tiene sus propias debilidades y

fortalezas.
 Para proyectos grandes se deben aplicar varias técnicas de
estimaciones de costos y comparar sus resultados.
 Estas técnicas de estimación son aplicables cuando existe un
documento de requerimientos para el sistema.

106
 Modelado algorítmico de costos
Se construye analizando los costos y atributos de los
proyectos realizados.
Se utiliza una fórmula matemática para predecir los
costos basados en estimaciones del tamaño del
proyecto, número de programadores y otros factores de
los procesos y productos.
Kitchenham (1990) describe 13 modelos algoritmos
de costos desarrollados a partir de observaciones
empíricas.

107
 Forma mas general para expresar una
estimación algorítmica de costos:

 Esfuerzo = A x TamañoB x M
 A es un factor constante que depende de las prácticas
organizacionales locales y del tipo de software que se
desarrolla.
 Tamaño es una valoración del tamaño del código del
software o una estimación de la funcionalidad expresada en
puntos de función o de objetos.
 El valor del exponente B por lo general se encuentra entre 1
y 1.5 y refleja el esfuerzo requerido para proyectos grandes .
 M es un multiplicador generado al combinar diferentes
procesos , atributos del producto y del desarrollo

108
 Dificultades comunes:
Es difícil estimar Tamaño en una primera etapa de un
proyecto donde solamente esta disponible la
especificación.
Las estimaciones de los factores B y M son subjetivas.
Varía de una persona a otra según su experiencia y
conocimiento.

109