Documentos de Académico
Documentos de Profesional
Documentos de Cultura
aplicacin o producto de alta calidad. Para lograr este objetivo, los ingenieros de
60
desarrollo, e implcitamente caractersticas 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 evalan
la calidad del anlisis y los modelos de diseo, as como el cdigo fuente y los
casos de prueba que se han establecido al aplicar la ingeniera del software. Para
Por ejemplo los errores detectados por hora de revisin y los errores detectados
por hora de prueba suministran una visin profunda de la eficacia de cada una de
61
4.1.1 Visin General de los Factores que Afectan a la Calidad
calidad como los primeros pasos hacia el desarrollo de mtricas de la calidad del
software. Estos factores evalan el software desde tres puntos de vista distintos:
(1) operacin del producto (utilizndolo), (2) revisin del producto (cambindolo) y
diferente, por ejemplo: portndolo) Los autores describen la relacin 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 clculo han sufrido
cambios radicales con el paso de los aos desde que McCall y Cavano hicieron su
trabajo, teniendo gran influencia, en 1978. Pero los atributos que proporcionan una
62
organizacin de software adopta un juego de factores de calidad como una lista
software construido hoy siga exhibiendo la buena calidad dentro de las primeras
dcadas del siglo XXI. Incluso, cuando las arquitecturas del clculo sufrn
tiles para el equipo del proyecto. Gilb [Len O. Ejiogo 90] sugiere definiciones y
cabo una funcin requerida. La medida ms comn de correccin son los defectos
63
mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una
mantener tendrn un TMC ms bajo (para tipos equivalentes de cambios) que los
como una funcin del tiempo, es aqu donde el administrador logra determinar si la
64
deducir de la evidencia emprica) de que se pueda repeler el ataque de un tipo
funcin de cuatro caractersticas: (1) destreza intelectual y/o fsica solicitada para
Los cuatro factores anteriores son slo 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 diseo, ya
temperatura, del deterioro, y los golpes) que los fallos relativos al diseo.
66
detecten. El TMEF de esos errores puede ser de 50 e incluso de 100 aos. Otros
errores, aunque no se hayan descubierto an, pueden tener una tasa de fallo de
categora (los que tienen un gran TMEF), el impacto sobre la fiabilidad del
como:
67
garanta 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 deberan filtrar antes de
pasarse a la actividad siguiente. Esto tambin puede ser utilizado dentro del
dos grandes grupos: (1) factores que se pueden medir directamente (por ejemplo:
defectos por puntos de funcin) y (2) factores que se pueden medir slo
69
McCall y sus colegas plantearon una categorizacin de factores que afectan
funcin pretendida con la exactitud solicitada. Cabe hacer notar que se han
Portabilidad
Facilidad de mantenimiento Reusabilidad
Flexibilidad (capacidad de reutilizacin)
Facilidad de Prueba Interoperatividad
70
- Usabilidad (facilidad de manejo): El esfuerzo necesario para aprender, operar,
programa.
error en un programa.
de mtricas para desarrollar expresiones para todos los factores de acuerdo con la
siguiente relacin:
Fq = c1 * m1 + c2 * m2 + + cn * mn (4.6)
regresin y mn son las mtricas que afectan al factor de calidad. Lo malo es que
las mtricas definidas por McCall slo pueden medirse de manera subjetiva. Las
71
mtricas van en lista de comprobacin que se emplean para apuntar atributos
esquema de puntuacin:
funcin.
cdigo.
error.
programa.
72
- Independencia del hardware: El grado con que se desacopla el software del
Mtrica de la
calidad del
Reusabilidad (capacidad de
software
Usabilidad (facilidad de
Capacidad de pruebas
Interoperabilidad
Mantenimiento
reutilizacin)
Portabilidad
Flexibilidad
Correccin
Integridad
Eficiencia
Fiabilidad
Factor de
manejo
calidad
Facilidad de auditoria * *
Exactitud *
Estandarizacin de *
comunicaciones
Complecin * * *
Complejidad *
Concisin * * * *
Consistencia * * *
Estandarizacin de datos * * * * *
Tolerancia a errores *
Eficiencia de ejecucin *
Capacidad de expansin *
Generalidad * * * *
Independencia del hardware * *
Instrumentacin * * *
Modularidad * * * * * *
Operatividad * *
Seguridad *
Autodocumentacin *
Simplicidad * * * * *
Independencia del sistema * * * *
Trazabilidad * *
Facilidad de formacin
Figura 4.2 Relacin entre Factores de calidad y mtricas de la calidad de software
[Fenton91]
73
- Trazabilidad: La capacidad de alcanzar una representacin del diseo o un
sistema.
La relacin entre los factores de calidad del software y las mtricas de la lista
anterior se muestra en la figura 4.2. Convendra 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 diseo. Y es por eso que se desea una visin interna a la calidad del
representacin del modelo de anlisis mostrada por Pressman [98]en la figura 4.3
75
En donde se representa un diagrama de flujo de datos, de una funcin de una
de seguridad.
- nmero de archivos
Datos de configuracin
del sistema
76
Hay tres entradas del usuario: contrasea, interruptor de emergencias y
ecuacin:
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
Basndose en el valor previsto de PF obtenido del modelo de anlisis, el equipo
de Hogar Seguro. Asuma que los datos de los que se disponen indican que un PF
preliminares.
Puede emplearse para desarrollar una indicacin del tamao del software a
implementacin, del tamao del sistema [Ejiogo 91]. Para calcular la mtrica
78
- Relaciones (RE) Las conexiones entre objetos de datos.
transicin de estado.
adicionales para:
fuera del lmite 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 mayora del software se puede asignar a
79
hincapi en la transformacin 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 tamao. DeMarco sugiere que las
80
4.2.3 Mtricas de la Calidad de Especificacin
Existe una lista de caractersticas para poder valorar la calidad del modelo
98] sugiere que todas puedan representarse usando una o ms mtricas. 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
relacin
Q2 = nu / (ni * ns ) (4.10)
81
donde nu es el nmero de requisitos de funcin nicos, ni es el nmero de
que se han especificado para un sistema, sin embargo, no trata los requisitos no
Las mtricas para software, como otras mtricas, no son perfectas; muchos
emplear bien las mtricas de diseo. Sin embargo el diseo sin medicin es una
calidad.
82
Estas mtricas son de caja negra, en el sentido de que no se requiere ningn
manera.
C(i)=S(i)+D(i) (4.14)
global del sistema tambin aumenta. Esto lleva a una mayor probabilidad de que
83
donde la longitud (i) es el nmero de sentencias en lenguaje de programacin en
el mdulo (i) y fin (i) es la concentracin del mdulo i. Henry y Kafura amplan la
Tamao = n +a (4.16)
tamao = 17 + 18 = 35
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 nmero total de mdulos definidos en la arquitectura del programa
formaran parte de S 2.
objetos individuales)
86
Tamao 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 diseo a nivel de
componentes.
requieren conocimiento del trabajo interno del mdulo en cuestin. Las mtricas
cdigo fuente.
Bieman y Ott [Hamdi 99] definen una coleccin de mtricas que proporcionan
conceptos y medidas:
ms porciones de datos.
88
Seales de super-unin. Las seales de datos comunes a todas las porciones
de datos de un mdulo.
cohesiones funcionales dbiles (CFD), y pegajosidad (el grado relativo con el que
las seales de unin ligan juntas porciones de datos) Estas mtricas se pueden
porciones de datos, no tiene una cohesin funcional fuerte (no hay seales de
datos que contribuyan a todas las salidas) Un procedimiento sin seales de unin,
89
CFF(i) = SU(SA(i))/seales (i) (4.26)
tambin aumenta 1.
mdulo con otros mdulos, datos globales y entorno exterior. Dhama [Fenton 91]
anteriormente.
90
gd = nmero de variables globales usadas como datos
de la siguiente manera:
m c = k/M (4.27)
donde:
a=b=c=2
91
datos, un nmero igual de parmetros 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 nmero importante de usos para las mtricas
92
diseo, en las pruebas y mantenimiento, proporcionan informacin sobre los
cuantitativa del tamao mximo del mdulo. Recogiendo datos de varios proyectos
de la interfaz.
93
Sears [Pressman 98] sugiere la conveniencia de la representacin (CR)
como una valiosa mtrica de diseo para interfaces hombre-mquina. Una IGU
grficos, texto, mens, 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 especfica. Esta suma se da con todas las
trminos de tiempo, retraso del proceso o cualquier otro valor razonable, tal como
94
donde CR = para una representacin ptima.
guiarse con mtricas tales como CR, pero el rbitro final debera 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
listan a continuacin.
Halstead usa las medidas primitivas para desarrollar expresiones para la longitud
global del programa; volumen mnimo potencial para un algoritmo; el volumen real
(una medida de la complejidad del software); nivel del lenguaje (una constante
96
Se debera tener en cuenta que V variar con el lenguaje de programacin
L = 2/n1*n2/N2 (4.35)
Halstead propuso que todos los lenguajes pueden categorizarse por nivel de
lenguaje, I, que variar segn los lenguajes. Halslead cre una teora que supona
que el nivel de lenguaje es constante para un lenguaje dado, pero otro trabajo
[Pressman 98] indica que el nivel de lenguaje es funcin tanto del lenguaje como
tabla 4.2.
Lenguaje Media/.I
97
especificacin del cdigo a un nivel ms alto de abstraccin que el lenguaje
responsables de las pruebas deben fiarse del anlisis, diseo y cdigo para que
tipos de pruebas de la caja negra y blanca del software Por ejemplo, el nmero de
transicin del IHM y evaluando las pruebas requeridas para ejecutar cada
98
transicin, (2) el nmero de objetos de datos (0B) que se mueven a travs de la
Por esta razn, el analista debera invertir un esfuerzo extra para descubrir
e = V / NP (4.37)
99
donde e(k) se calcula para el mdulo k usando las ecuaciones (4.35 y 4.36) y
amplitud de las pruebas proporciona una indicacin de cuantos (del nmero total
todos los mdulos 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
estadsticos de errores.
100
producto de software (basada en los cambios que ocurren con cada versin del
versin actual
101