Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Capitulo4 PDF
Capitulo4 PDF
aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros de
60
desarrollo, e implícitamente características que son expectativas de todos
que transfiere a un programa ejecutable y las pruebas que ejercita el software para
detectar errores. Un buen ingeniero del software emplea mediciones que evalúan
la calidad del análisis y los modelos de diseño, así como el código fuente y los
casos de prueba que se han establecido al aplicar la ingeniería del software. Para
Por ejemplo los errores detectados por hora de revisión y los errores detectados
por hora de prueba suministran una visión profunda de la eficacia de cada una de
las actividades envueltas en la métrica. Así los datos de errores se pueden utilizar
61
4.1.1 Visión General de los Factores que Afectan a la Calidad
calidad como los primeros pasos hacia el desarrollo de métricas de la calidad del
software. Estos factores evalúan el software desde tres puntos de vista distintos:
(1) operación del producto (utilizándolo), (2) revisión del producto (cambiándolo) y
diferente, por ejemplo: “portándolo”) Los autores describen la relación entre estos
factores de calidad (lo que llaman un ‘marco de trabajo’) y otros aspectos del
Es importante destacar que casi todos los aspectos del cálculo han sufrido
cambios radicales con el paso de los años desde que McCall y Cavano hicieron su
trabajo, teniendo gran influencia, en 1978. Pero los atributos que proporcionan una
62
organización de software adopta un juego de factores de calidad como una “lista
software construido hoy siga exhibiendo la buena calidad dentro de las primeras
décadas del siglo XXI. Incluso, cuando las arquitecturas del cálculo sufrán
útiles para el equipo del proyecto. Gilb [Len O. Ejiogo ‘90] sugiere definiciones y
cabo una función requerida. La medida más común de corrección son los defectos
63
mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una
a todos los usuarios. En promedio, los programas que son más fáciles de
mantener tendrán un TMC más bajo (para tipos equivalentes de cambios) que los
como una función del tiempo, es aquí donde el administrador logra determinar si la
64
deducir de la evidencia empírica) de que se pueda repeler el ataque de un tipo
cuantificar “lo amigable que pude ser con el usuario” y se consigue medir en
función de cuatro características: (1) destreza intelectual y/o física solicitada para
Los cuatro factores anteriores son sólo un ejemplo de todos los que se han
65
4.1.3 Medidas de fiabilidad y de disponibilidad.
a los fallos debidos al desajuste, que a los fallos debidos a defectos de diseño, ya
que son más probables debido al desgaste físico (p. ej.: el efecto de la
temperatura, del deterioro, y los golpes) que los fallos relativos al diseño.
medida más útil que los defectos/KLDC, simplemente porque el usuario final se
66
detecten. El TMEF de esos errores puede ser de 50 e incluso de 100 años. Otros
errores, aunque no se hayan descubierto aún, pueden tener una tasa de fallo de
categoría (los que tienen un gran TMEF), el impacto sobre la fiabilidad del
como:
67
garantía de calidad y de control al aplicarse a todas las actividades del marco de
de la forma siguiente:
EED = E / (E + D) (4.4)
defectos en el software. De forma realista, D será mayor que cero, pero el valor de
Del mismo modo el EED se puede manipular dentro del proyecto, para
68
donde se puede encontrar o no) Cuando se utilizan en este contexto, el EED se
un EED que se aproxime a 1, esto es, los errores se deberían filtrar antes de
pasarse a la actividad siguiente. Esto también puede ser utilizado dentro del
dos grandes grupos: (1) factores que se pueden medir directamente (por ejemplo:
defectos por puntos de función) y (2) factores que se pueden medir sólo
69
McCall y sus colegas plantearon una categorización de factores que afectan
función pretendida con la exactitud solicitada. Cabe hacer notar que se han
Portabilidad
Facilidad de mantenimiento Reusabilidad
Flexibilidad (capacidad de reutilización)
Facilidad de Prueba Interoperatividad
70
- Usabilidad (facilidad de manejo): El esfuerzo necesario para aprender, operar,
programa.
error en un programa.
de métricas para desarrollar expresiones para todos los factores de acuerdo con la
siguiente relación:
Fq = c1 * m1 + c2 * m2 + …+ cn * mn (4.6)
regresión y mn son las métricas que afectan al factor de calidad. Lo malo es que
las métricas definidas por McCall sólo pueden medirse de manera subjetiva. Las
71
métricas van en lista de comprobación que se emplean para ‘apuntar’ atributos
esquema de puntuación:
función.
código.
error.
programa.
72
- Independencia del hardware: El grado con que se desacopla el software del
Métrica de la
calidad del
Reusabilidad (capacidad de
software
Usabilidad (facilidad de
Capacidad de pruebas
Interoperabilidad
Mantenimiento
reutilización)
Portabilidad
Flexibilidad
Corrección
Integridad
Eficiencia
Fiabilidad
Factor de
manejo
calidad
Facilidad de auditoria * *
Exactitud *
Estandarización de *
comunicaciones
Compleción * * *
Complejidad *
Concisión * * * *
Consistencia * * *
Estandarización de datos * * * * *
Tolerancia a errores *
Eficiencia de ejecución *
Capacidad de expansión *
Generalidad * * * *
Independencia del hardware * *
Instrumentación * * *
Modularidad * * * * * *
Operatividad * *
Seguridad *
Autodocumentación *
Simplicidad * * * * *
Independencia del sistema * * * *
Trazabilidad * *
Facilidad de formación
Figura 4.2 Relación entre Factores de calidad y métricas de la calidad de software
[Fenton’91]
73
- Trazabilidad: La capacidad de alcanzar una representación del diseño o un
sistema.
La relación entre los factores de calidad del software y las métricas de la lista
anterior se muestra en la figura 4.2. Convendría decirse que el peso que se asigna
4.1.6 FURPS
programa.
74
- Capacidad de soporte. Combina la capacidad de ampliar el programa
para el diseño. Y es por eso que se desea una visión interna a la calidad del
representación del modelo de análisis mostrada por Pressman [‘98]en la figura 4.3
75
En donde se representa un diagrama de flujo de datos, de una función de una
de seguridad.
- número de archivos
Datos de configuración
del sistema
76
Hay tres entradas del usuario: contraseña, interruptor de emergencias y
ecuación:
figura 4.6.1 b y Fi( i=1 a 14) son “valores de ajuste de complejidad”. Para el
PF = 50* [0.65+(0.01*46)]=56
77
Basándose en el valor previsto de PF obtenido del modelo de análisis, el equipo
de Hogar Seguro. Asuma que los datos de los que se disponen indican que un PF
preliminares.
Puede emplearse para desarrollar una indicación del tamaño del software a
implementación, del tamaño del sistema” [Ejiogo ‘91]. Para calcular la métrica
78
- Relaciones (RE) Las conexiones entre objetos de datos.
transición de estado.
adicionales para:
fuera del límite del sistema y que deben modificarse para acomodarse al
nuevo sistema.
introducen en el sistema.
sacan en el sistema.
DeMarco [Ejiogo ‘91] sugiere que la mayoría del software se puede asignar a
79
hincapié en la transformación de datos y no poseen generalmente estructuras de
con mayor o menor grado de refinamiento, DeMarco sugiere que se emplee una
anterior para asociarla con el esfuerzo y el tamaño. DeMarco sugiere que las
80
4.2.3 Métricas de la Calidad de Especificación
Existe una lista de características para poder valorar la calidad del modelo
‘98] sugiere que todas puedan representarse usando una o más métricas. Por
ni = nf + nnf (4.8)
Q1 = nui / nr (4.9)
Donde nui es el numero de requisitos para los que todos los revisores tuvieron
relación
Q2 = nu / (ni * ns ) (4.10)
81
donde nu es el número de requisitos de función únicos, ni es el número de
que se han especificado para un sistema, sin embargo, no trata los requisitos no
Las métricas para software, como otras métricas, no son perfectas; muchos
emplear bien las métricas de diseño. Sin embargo el diseño sin medición es una
diseñador una mejor visión interna y así el diseño evolucionara a un mejor nivel de
calidad.
82
Estas métricas son de caja negra, en el sentido de que no se requiere ningún
manera.
C(i)=S(i)+D(i) (4.14)
global del sistema también aumenta. Esto lleva a una mayor probabilidad de que
83
donde la longitud (i) es el número de sentencias en lenguaje de programación en
el módulo (i) y fin (i) es la concentración del módulo i. Henry y Kafura amplían la
Tamaño = n +a (4.16)
tamaño = 17 + 18 = 35
profundidad = el camino más largo desde el nodo raíz (parte más alta) a un nodo
hoja. (4.17)
profundidad =4.
84
Nodo
a
b c d e
Profundidad Arco
f g i j k l
h m n p q r
Figura 4.4 Arquitectura de Software [Fenton ‘91]
anchura = 6.
r = 18/17 = 1,06.
85
SI = el número total de módulos definidos en la arquitectura del programa
formarían parte de S 2.
objetos individuales)
86
Tamaño de la base de datos: D4=1 – (S5/S4) (4.22)
manera:
ICED= Wi Di (4.25)
Wi=0.167).
87
ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de
componentes.
requieren conocimiento del trabajo interno del módulo en cuestión. Las métricas
código fuente.
Bieman y Ott [Hamdi ‘99] definen una colección de métricas que proporcionan
conceptos y medidas:
88
− Señales de super-unión. Las señales de datos comunes a todas las porciones
de datos de un módulo.
cohesiones funcionales débiles (CFD), y pegajosidad (el grado relativo con el que
las señales de unión ligan juntas porciones de datos) Estas métricas se pueden
porciones de datos, no tiene una cohesión funcional fuerte (no hay señales de
datos que contribuyan a todas las salidas) Un procedimiento sin señales de unión,
es decir, sin señales comunes a más de una porción de datos (en procedimientos
con más de una porción de datos), no muestra una cohesión funcional débil y
ninguna adhesividad (no hay señales de datos que contribuyan a más de una
89
CFF(i) = SU(SA(i))/señales (i) (4.26)
también aumenta 1.
módulo con otros módulos, datos globales y entorno exterior. Dhama [Fenton ‘91]
anteriormente.
90
gd = número de variables globales usadas como datos
de la siguiente manera:
m c = k/M (4.27)
donde:
a=b=c=2
91
datos, un número igual de parámetros de control, accede a 10 elementos de datos
C= 1-mc (4.29)
la complejidad del flujo de control del programa. Muchas de éstas se basan en una
McCabe [Pressman ‘93] identifica un número importante de usos para las métricas
92
diseño, en las pruebas y mantenimiento, proporcionan información sobre los
que existen en el código fuente, así como el tiempo requerido para encontrar y
cuantitativa del tamaño máximo del módulo. Recogiendo datos de varios proyectos
de la interfaz.
93
Sears [Pressman ´98] sugiere la conveniencia de la representación (CR)
como una valiosa métrica de diseño para interfaces hombre-máquina. Una IGU
gráficos, texto, menús, ventanas y otras para ayudar al usuario a completar tareas.
Para realizar una tarea dada usando una IGU, el usuario debe moverse de una
conveniencia de la interfaz.
siguiente cuando se realiza una tarea específica. Esta suma se da con todas las
términos de tiempo, retraso del proceso o cualquier otro valor razonable, tal como
94
donde CR = para una representación óptima.
guiarse con métricas tales como CR, pero el árbitro final debería ser la respuesta
del usuario basada en prototipos de IGU. Nielsen Levy [Pressman ‘98] informa;
95
complejidad (software)’ [Ejiogo ‘91]. La ciencia software propuso las primeras
[Pressman ‘98]: ‘el cerebro humano sigue un conjunto de reglas más rígido (en el
listan a continuación.
Halstead usa las medidas primitivas para desarrollar expresiones para la longitud
global del programa; volumen mínimo potencial para un algoritmo; el volumen real
(una medida de la complejidad del software); nivel del lenguaje (una constante
96
Se debería tener en cuenta que V variará con el lenguaje de programación
L = 2/n1*n2/N2 (4.35)
Halstead propuso que todos los lenguajes pueden categorizarse por nivel de
lenguaje, I, que variará según los lenguajes. Halslead creó una teoría que suponía
que el nivel de lenguaje es constante para un lenguaje dado, pero otro trabajo
[Pressman ‘98] indica que el nivel de lenguaje es función tanto del lenguaje como
tabla 4.2.
Lenguaje Media/.I
97
especificación del código a un nivel más alto de abstracción que el lenguaje
responsables de las pruebas deben fiarse del análisis, diseño y código para que
tipos de pruebas de la caja negra y blanca del software Por ejemplo, el número de
transición del IHM y evaluando las pruebas requeridas para ejecutar cada
98
transición, (2) el número de objetos de datos (0B) que se mueven a través de la
candidatos para pruebas más profundas. Los módulos con gran complejidad
ciclomática tienen más probabilidad de tendencia a errores que los módulos con
Por esta razón, el analista debería invertir un esfuerzo extra para descubrir
e = V / NP (4.37)
99
donde e(k) se calcula para el módulo k usando las ecuaciones (4.35 y 4.36) y
amplitud de las pruebas proporciona una indicación de cuantos (del número total
todos los módulos del programa. Finalmente, a medida que se van haciendo las
pruebas y se recogen los datos de los errores, se pueden emplear los perfiles de
fallos para dar prioridad y categorizar los errores descubiertos. La prioridad indica
estadísticos de errores.
100
producto de software (basada en los cambios que ocurren con cada versión del
versión actual
101