E

L enfoque de ingeniería del software descrito en este libro se dirige hacia un solo obje-
tivo: producir software de alta calidad. Pero a muchos lectores les inquietará la pregunta:
es la calidad del software?»
Philip Crosby en su famoso libro sobre calidad, expone esta situación:
El problema de la gestión de la calidad no es lo que la gente no sabe sobre ella. El problema es lo que
creen que saben...
A este respecto, la calidad tiene mucho en común con el sexo. Todo el mundo lo quiere. (Bajo ciertas
condiciones, por supuesto.) Todo el mundo cree que lo conoce. (Incluso aunque no quiera explicarlo.) Todo
el mundo piensa que su ejecución sólo es cuestión de seguir las inclinaciones naturales. (Después de todo,
nos las arreglamos de alguna forma.) Y, por supuesto, la mayoría de la gente piensa que los problemas en
estas áreas están producidos por otra gente. (Como si sólo ellos se tomaran el tiempo para hacer las cosas
bien.)
Algunos desarrolladores de software continúan creyendo que la calidad del software es algo
en lo que empiezan a preocuparse una vez que se ha generado el código. más lejos de la
realidad! La garantía de calidad del software (SQA, Software Quality Assurance GCS, Gestión
de calidad del software) es una actividad de protección (Capítulo 2) que se aplica a lo largo de
todo el proceso del software. La SQA engloba: (1) un enfoque de gestión de calidad; (2) tec-
nología de ingeniería del software efectiva (métodos y herramientas); (3) revisiones técnicas
formales que se aplican durante el proceso del software; (4) una estrategia de prueba
calada; ( 5 ) el control de la documentación del software y de los cambios realizados; (6) un pro-
cedimiento que asegure un ajuste a los estándares de desarrollo del software (cuando sea posible),
y (7) mecanismos de medición y de generación de informes.
En este capítulo nos centraremos en los aspectos de gestión y en las actividades específicas
del proceso que permitan a una organización de software asegurar que hace cosas correc-
tas en el momento justo y de la forma correcta».

definir una estrategia de para el

plan de garantía de calidad del

software debe

do de este modo la

N. del T.: En español, GCS.Se conservan las siglas SQA en inglés por estar muy extendido su uso para jerga infor-
mática. A veces se suelen traducir estas siglas también por de la Calidad del
131
 DEL SOFTWARE. UN ENFOQUE PRACTICO

Se dice que dos copos de nieve no son iguales. Cierta- se aplica esto al software? puede
mente cuando se observa caer la nieve, es difícil ima- una organización de desarrollo de software necesitar
ginar que son totalmente diferentes, por no mencionar controlar la variación? De un proyecto a otro, quere-
que cada copo posee una estructura única. Para obser- mos reducir la diferencia entre los recursos necesa-
var las diferencias entre los copos de nieve, debemos rios planificados para terminar un proyecto y los
examinar los especímenes muy de cerca, y quizá con recursos reales utilizados, entre los que se incluyen
un cristal de aumento. En efecto, cuanto más cerca los personal, equipo y tiempo. En general, nos gustaría
observemos, más diferencias podremos detectar. asegurarnos de que nuestro programa de pruebas abar-
Este fenómeno, variación entre muestras, se aplica ca un porcentaje conocido del software de una entre-
a todos los productos del hombre así como a la creación ga a otra. No sólo queremos reducir el número de
natural. Por ejemplo, si dos tarjetas de circuito «idénti- defectos que se extraen para ese campo, sino también
cas» se examinan muy de cerca, podremos observar que nos gustaría asegurarnos de que los errores ocultos
las líneas de cobre sobre las tarjetas difieren ligeramente también se reducen de una entrego a otra. (Es proba-
en la geometría, colocación y grosor. Además, la loca- ble que nuestros clientes se molesten si la tercera
lización y el diámetro de los orificios de las tarjetas tam- entrega de un producto tiene diez veces más defectos
bién varían. que la anterior.) Nos gustaría reducir las diferencias
en velocidad y precisión de nuestras respuestas de
soporte a los problemas de los clientes. La lista se
podría ampliar más y más.

8.1.1. Calidad
El American Heritage Dictionary, define la calidad como
El control de variación es el centro del control de característica o atributo de algo». Como un atri-
calidad. Un fabricante quiere reducir la variación entre buto de un elemento, la calidad se refiere a las caracte-
los productos que se fabrican, incluso cuando se reali- rísticas mensurables que se pueden comparar
za algo relativamente sencillo como la duplicación de con estándares conocidos como longitud, color, propie-
disquetes. Seguramente, esto puede no ser un problema dades eléctricas, maleabilidad, Sin embargo, el
duplicaciónde disquetes es una operación de software en su gran extensión, como entidad intelectual,
cación trivial y podemos garantizar que se crean dupli- es más difícil de caracterizar que los objetos físicos.
cados exactos de software-. No obstante, sí existen las medidas de característi-
Necesitamos asegurar que las pistas se cas de un programa. Entre estas propiedades se inclu-
sitúen dentro de una tolerancia específica para que la yen complejidad ciclomática, cohesión, número de
gran mayoría de las disqueteras puedan leer los puntos de función, líneas de código y muchas otras estu-
Además, necesitamos asegurar que el flujo mag- diadas en los Capítulos 19y 24. Cuando se examina un
nético para distinguir un cero de un uno sea suficiente elemento según sus características mensurables, se pue-
para que los detecten las cabezas de den encontrar dos tipos de calidad: calidad del diseño
Las máquinas de duplicación de discos aceptan o recha- y calidad de concordancia.
zan la tolerancia. Por consiguiente, incluso un proceso
«simple», como la duplicación, puede encontrarse con
problemas debidos a la variación entre muestras.

Controlar variación es clave de un producto de alta La calidad de diseño se refiere a las características
calidad. En el contexto del software, nos esforzamos que especifican los ingenieros de software para un ele-
en controlar variación en el proceso que aplicamos, mento. El grado de materiales, tolerancias y las especi-
recursosque consumimos y los atributos de calidad ficaciones del rendimiento contribuyen a la calidad del
del producto final. diseño. Cuando se utilizan materiales de alto grado y se

Esta sección, escrita por Michael Ctovcky, se ha adaptado de <(Fun-

damentals of ICO un libro de trabajo desarrollado para
Software Engineering, un curriculum desarrollado por
Inc. autorizada.

132
 DE CALIDAD DEL SOFTWARE

especificantolerancias más estrictas y niveles más altos cificaciones mensurables en las que se puedan com-
de rendimiento, la calidad de diseño de un producto parar los resultados de cada proceso. El bucle de
aumenta, si el producto se fabrica de acuerdo con las limentación es esencial para reducir los defectos
especificaciones. producidos.
La calidad de concordancia es el grado de cumpli-
miento de las especificaciones de diseño durante su rea- 8.1.3. Garantía de calidad
lización. Una vez más, cuanto mayor sea el grado de
cumplimento,más alto será el nivel de calidad de con- La garantia de calidad consiste en la auditoría y las fun-
cordancia. ciones de información de la gestión. El objetivo de la
En el desarrollo del software, la calidad de diseño garantía de calidad es proporcionar la gestión para infor-
comprende los requisitos, especificaciones y el diseño mar de los datos necesarios sobre la calidad del pro-
del sistema. La calidad de concordancia es un aspecto ducto, por lo que se va adquiriendo una visión más
centrado principalmente en la implementación. Si la profunda y segura de que la calidad del producto está
implementación sigue el diseño, y el sistema resultan- cumpliendo sus objetivos. Por supuesto, si los datos pro-
te cumple los objetivos de requisitos y de rendimiento, porcionados mediante la garantía de calidad identifican
la calidad de concordancia es alta. problemas, es responsabilidad de la gestión afrontar los
Pero, la calidad del diseño y la calidad de problemas y aplicar los recursos necesarios para resol-
concordancia los Únicos aspectos que deben consi- ver aspectos de calidad.
derar los ingenieros de software? Robert Glass
establece para ello una relacion más
Referencia
satisfacción del usuario = producto
dad+ entrega dentro de presu- Se puede una gran variedad de recursos de
puesto y del tiempo establecidos calidad del en

En la última Glass que la calidad es impor-

tante,pero si el usuario no queda satisfecho, ninguna otra
cosarealmenteimporta. este 8.1.4. Coste de calidad
punto de vista cuando afirma: «La calidad del producto El coste de calidad incluye todos los costes acarreados
es una función de cuánto cambia el mundo para mejor.» en la búsqueda de la calidad o en las actividades rela-
Esta visión de la calidad establece que si el producto de cionadas en la obtención de la calidad. Se realizan estu-
software proporciona un beneficio sustancial a los dios sobre el coste de calidad para proporcionar una línea
nos finales, pueden estar dispuestos para tolerar proble- base del coste actual de calidad, para identificar oportu-
mas ocasionalesdel rendimiento o de fiabilidad. nidades de reducir este coste, y para proporcionar una
base normalizada de comparación. La base de normali-
zación siempre tiene un precio. Una vez que se han nor-
8.1.2. Control de calidad malizado los costes de calidad sobre un precio base,
El control de cambios puede equipararse al control de tenemos los datos necesarios para evaluar el lugar en
calidad. Pero, se logra el control de calidad? El donde hay oportunidades de mejorar nuestros procesos.
control de calidad es una serie de inspecciones, revi- Es más, podemos evaluar cómo afectan los cambios en
siones y pruebas utilizados a lo largo del proceso del términos de dinero.
software para asegurar que cada producto cumple con Los costes de calidad se pueden dividir en costes
los requisitos que le han sido asignados. El control de asociados con la prevención, la evaluación y los fallos.
calidad incluye un bucle de realimentación (feedback) Entre los costes de prevención se incluyen:
del proceso que creó el producto. La combinación de
medición y realimentación permite afinar el proceso planificación de la calidad,
cuandolos productos de trabajo creados fallan al cum- revisiones técnicas formales,
plir sus especificaciones.Este enfoque ve el control de equipo de pruebas,
calidad como parte del proceso de fabricación. formación. ,

es el control de calidad
del software?
los componentes
del coste de calidad?

Las actividades de control de calidad pueden ser Entre los costes de evaluación se incluyen activida-
manuales, completamente automáticas o una combi- des para tener una visión más profunda de-la condición
nación de herramientas automáticas e interacción del producto primera vez a través cada proce-
humana. Un concepto clave del control de calidad es so. A continuación se incluyen algunos ejemplos de cos-
que se hayan definido todos los productos y las espe- tes de evaluación:
133
 DEL S O FT W A R E . U N E N F O Q U E P R A C T IC O

inspección en el proceso y entre procesos, Se han dedicado 7.053 horas inspeccionando

calibrado y mantenimiento del equipo, neas de código con el resultado de 3.1 12 errores potenciales
Dando por sentado un coste de programador de
pruebas. 40 dólares por hora, el coste de eliminar 3.1 12 defectos ha sido
de 282.120 dólares, o aproximadamente unos 9 dólares por
defecto.
Compare estos números con el coste de eliminación de
tengo miedo de incurrir en costes significativos defectos una vez que el producto se ha enviado al cliente.
de prevención. Esté segura de que su inversión Suponga que no ha habido inspecciones, pero que los progra-
le proporcionaráun beneficio excelente. madores han sido muy cuidadosos y solamente se ha escapa-
do un defecto por de código [significativamente
mejor que la media en industrial] en el producto enviado. Eso
Los costes de fallos son los costes que desapare- que se tendrían que corregir todavía 200 defectos
cerían si no surgieran defectos antes del envío de un en la casa del cliente o después de la entrega. A un coste esti-
producto a los clientes. Estos costes se pueden sub- mado de dólares por reparación de campo, el coste sena
dividir en costes de fallos internos y costes de fallos de millones de dólares, o aproximadamente 18 veces más
externos. Los internos se producen cuando se detec- caro que el coste total del esfuerzo de prevención de defectos.
ta un error en el producto antes de su envío. Entre
estos se incluyen:
40-1
retrabajo (revisión),
reparación,
r veces

análisis de las modalidades de fallos. 30-70

veces
Los costes de fallos externos son los que se asocian 15-40
veces
a los defectos encontrados una vez enviado el produc-
to al cliente. A continuación se incluyen algunos ejem-
plos de costes de fallos externos:
resolución de quejas,
devolución y sustitución de productos,
soporte de línea de ayuda,
trabajo de garantía.
Como es de esperar, los costes relativos para encon-
trar y reparar un defecto aumentan dramáticamente a
Requisitos Diseño Código Prueba Prueba En fase de
medida que se cambia de prevención a detección y des- de de explotación
de el fallo interno al externo. La Figura 8.1, basada en desarrollo sistema
datos recopilados por ilustra este fenó- FIGURA 8.1. Coste relativo de corregir un error.
meno.
Es verdad que IBM produce software utilizado por
cientos de miles de clientes y que sus costes por repa-
las pruebas son necesarias, pero también ración en casa del cliente o después de la entrega pue-
es una forma de errores. den ser más altos que los de organizaciones de software
el tiempo en encontrar errores comienzo del proceso que construyen sistemas personalizados. Esto, de nin-
y reducir los de guna manera, niega los resultados señalados anterior-
y depuración. mente. Aunque la organización media de software tiene
costes de reparación después de la entrega que son el
Kaplan y sus colegas refuerzan las esta- 25 por 100 de los de IBM mayoría no tienen ni idea
dísticas de costes anteriores informando con datos de cuales son sus costes!), se están imponiendo ahorros
dóticos basados en un trabajo realizado en las en el coste asociados con actividades de garantía y con-
instalaciones de desarrollo de IBM en Rochester: trol de calidad.

Hoy en día los responsables expertos de compañías de La tendencia de la calidad comenzó en los años cuarenta
todo el mundo industrializado reconocen que la alta cali- con el influyente trabajo de W. Edwards Deming
dad del producto se traduce en ahorro de coste y en una y se hizo la primera verificación en Japón.
mejora general. Sin embargo, esto no era siempre el caso. Mediante las ideas de Deming como piedra angular, los
134
 DE CA LIDAD DEL S O F TW A RE

japoneses han desarrollado un enfoque sistemático para Mientras que los dos primeros pasos se centran en
la eliminación de las causas raíz de defectos en produc- el proceso, el paso siguiente llamado kansei (traducido
tos. A lo largo de los años setenta y ochenta, su trabajo como cinco sentidos») se centra en el usuario del
emigró al mundo occidental y a veces se llama «gestión producto (en este caso, software). En esencia, exami-
de calidad Aunque la terminología difiere nando la forma en que el usuario aplica el producto,
según los diferentes países y autores, normalmente se kunsei conduce a la mejora en el producto mismo, y
encuentrauna progresión básica de cuatro pasos que cons- potencialmente al proceso que lo creó.
tituye el fundamentode cualquier programa de GTC. Finalmente, un paso llamado miryokuteki hinshitsu
amplía la preocupación de la gestión más allá del pro-
ducto inmediato. Este es un paso orientado a la gestión
que busca la oportunidad en áreas relacionadas que se
CLAVE
pueden identificar observando la utilización del pro-
Se puede aplicar GTC al software de computadora. ducto en el mercado. En el mundo del software,
enfoque GTC se centra en mejora continua
kuteki hinshitsu se podría ver como un intento de
del
detectar productos nuevos y beneficiosos, o aplicacio-
El primer paso se llama kuizen y se refiere a un sis- nes que sean una extensión de un sistema ya existente
tema de mejora continua del proceso. El objetivo de basado en computadora.
zen es desarrollar un proceso (en este caso, proceso del
software) que sea visible, repetible y mensurable.
El segundo paso, invocado sólo una vez que se ha
kuizen, se llama aturimae hinshitsu. Este paso
examina lo intangible que afecta al proceso y trabaja Se puede encontrar una gran variedad de recursos
para optimizar su impacto en el proceso. Por ejemplo, continua del proceso y GTC en
el proceso de software se puede ver afectado por la alta deming.eng.clemsom.edu/
rotación de personal que ya en sí mismo se ve afectado
por reorganizaciones dentro de una compañía. Puede Para la mayoría de las compañías, kuizen debería
ser que una estructura organizativa estable haga mucho ser de preocupación inmediata. Hasta que se haya logra-
para mejorar la calidad del software. do un proceso de software avanzado (Capítulo 2), no
llevaría a la gestión a sugerir cambios en la forma en hay muchos argumentos para seguir con los pasos
que ocurre la reorganización. siguientes.

el desarrollador de software más agobiado ware. Para los propósitos de este libro, la anterior defini-
acuerdo con que el software de alta calidad es una ción sirve para hacer hincapié en tres puntos importantes:
meta importante. Pero, definimosla calidad? Un Los requisitos del software son la base de las medi-
dijo una vez: «Cualquier programa hace algo das de la calidad. La falta de concordancia con los
lo que puede pasar es que no sea lo que nosotros requisitos es una falta de calidad.
queremos que haga». 2. Los estándares especificados definen un conjunto de
se define criterios de desarrollo que guían la forma en que se
del software))? aplica la ingeniería del software. Si no se siguen esos
criterios, casi siempre habrá falta de calidad.
En los libros se han propuesto muchas definiciones 3. Existe un conjunto de requisitos implícitos que a
,&calidad del software. Por lo que a nosotros respecta, menudo no se mencionan (por ejemplo: el deseo por
calidad software se define como: facilitar el uso y un buen mantenimiento). Si el soft-
Concordancia con los requisitos funcionales y de rendi- ware se ajusta a sus requisitos explícitos pero falla
miento establecidos,con los estándaresde desa- en alcanzar los requisitos implícitos, la calidad del
rrollo explícitamente documentados, y con las características software queda en entredicho.
implícitas que se espera de todo software desarrollado
Problemas de fondo
No hay duda de que la anterior definición puede ser La historia de la garantía de calidad en el desarrollo de
o ampliada.De hecho, no tendría fin una dis- software es paralela a la historia de la calidad en la crea-
cusión sobre una definición formal de calidad del soft- ción de hardware. Durante los primeros años de la
Consulte para un estudio más completo del GTC y su
en un contexto de software,y para un estudio sobre el uso
en el mundo del software.

135
 DEL SOFTWARE. UN ENFO QUE PRACTICO

mática (los años cincuenta y sesenta), la calidad era res- des de SQA que se enfrentan con la planificación de garan-
ponsabilidad únicamente del programador. Durante los tía de calidad, supervisión, mantenimiento de registros,
años setenta se introdujeron estándares de garantía de análisis e informes. Éstas son las actividades que realizan
calidad para el software en los contratos militares para (o facilitan) un grupo independiente de SQA:
desarrollo de software y se han extendido rápidamente Establecimiento de un plan de SQA para un proyec-
a los desarrollos de software en el mundo comercial to. El plan se desarrolla durante la planificación del pro-
Ampliando la definición presentada anterior- yecto y es revisado por todas las partes interesadas. Las
mente, la garantía de calidad del software (SQA) es un actividades de garantía de calidad realizadas por el equi-
de acciones planificado y sistemático» po de ingeniería del software y el grupo SQA son gober-
que se requiere para asegurar la calidad del software. El nadas por el plan. El plan identifica:
ámbito de la responsabilidad de la garantía de calidad se
evaluaciones a realizar,
puede caracterizarmejor parafraseandoun popular anun-
cio de coches: «La calidad es la 1 tarea.» La implica- auditorías y revisiones a realizar,
ción para el software es que muchos de los que estándares que se pueden aplicar al proyecto,
constituyen una organización tienen responsabilidad de procedimientos para información y seguimiento de
garantía de calidad del software -ingenierosde soft- errores,
ware, jefes de proyectos, clientes, vendedores, y aque-
documentos producidos por el grupo SQA,
llas personas que trabajan dentro de un grupo de SQA-.
realimentación de información proporcionada al
equipo de proyecto del software.

es el papel
Referencia de un grupo de
Se puede encontrar un profundo y amplios
recursospara gestión de calidad en
www.management.gov
Participación en el desarrollo de la descripción del
proceso de software del proyecto. El equipo de ingenie-
ría del software selecciona un proceso para el trabajo
El grupo de SQA sirve como representación del clien- que se va a realizar. El grupo de SQA revisa la descrip-
te en casa. Es decir, la gente que lleva a cabo'la SQA ción del proceso para ajustarse a la política de la empre-
debe mirar el software desde el punto de vista del clien- sa, los estándares internos del software, los estándares
te. de forma adecuada el software los facto- impuestos externamente (por ejemplo: ya
res de calidad apuntados en el Capítulo 19? ha otras partes del plan de proyecto del software.
realizado el desarrollo del software de acuerdocon están- Revisión de las actividades de ingeniería del soft-
preestablecidos? desempeñado apropiada- ware para su ajuste al proceso de software
mente sus papeles las disciplinas técnicas como parte definido. El grupo de documenta y sigue
de la actividad de SQA? El grupo de SQA intenta res- la pista de las desviaciones desde el proceso y verifica
ponder a estas y otras preguntas para asegurar que se que se han hecho las correcciones.
mantiene la calidad del software. Auditoría de los productos de software designados
para verificar el ajuste con los definidos como parte del
Actividades de SQA proceso del software. El grupo de SQA revisa los pro-
ductos seleccionados; identifica, documenta y sigue la
La garantía de calidad del software comprende una gran
pista de las desviaciones; verifica que se han hecho las
variedad de tareas, asociadas con dos constitutivos dife-
correcciones, e informa periódicamente de los resulta-
rentes ingenieros de software que realizan traba-
dos de su trabajo al gestor del proyecto.
jo técnico y un grupo de SQAque tiene la responsabilidad
Asegurar que las desviaciones del trabajo y los pro-
de la Planificación de garantía de calidad, supervisión,
ductos del software se documentan y se manejan de
mantenimiento de registros, análisis e informes-.
acuerdo con un procedimiento establecido. Las des-
Los ingenieros de software afrontan la calidad (y rea-
viaciones se pueden encontrar en el plan del proyecto,
lizan garantía de calidad) aplicando métodos técnicos
en la descripción del proceso, en los estándares aplica-
sólidos y medidas, realizando revisiones técnicas for-
bles o en los productos técnicos.
males y llevando a cabo pruebas de software bien pla-
Registrar lo que no se ajuste a los requisitos e infor-
nificadas. Solamente las revisiones son tratadas en este mar a sus superiores. Los elementos que no se ajustan
capítulo. Los temas de tecnología se estudian en las Par-
a los requisitos están bajo seguimiento hasta que se
tes Tercera a Quinta de este libro.
resuelven.
Las reglas del grupo de SQA tratan de ayudar al equi-
po de ingeniería del software en la consecución de un pro- Además de estas actividades, el grupo de SQA coor-
ducto final de alta calidad. El Instituto de Ingeniería del dina el control y la gestión de cambios (Capítulo 9) y ayu-
Software recomienda un conjunto de activida- da a recopilar y a analizar las métricas del software.
136
 DE CALIDAD DEL SOFTWARE

revisiones del software son un «filtro» para el pro- defecto como una del producto». La defini-
ceso de ingeniería del software. Esto es, las revisiones ción de en el contexto del hardware se puede
Se aplican en varios momentos del desarrollo del soft- encontrar en IEEE Standard 610. 12-1990:
ware y sirven para detectar errores y defectos que (a) Un defecto en un dispositivo de o componen-
así ser eliminados. Las revisiones del software sirven te: por ejemplo, un corto circuito o un cable roto.
para «purificar» las actividades de ingeniería del soft- (b) Un paso incorrecto, proceso o definición de datos en
ware que suceden como resultado del análisis, el diseño un programa de computadora. Nota: Esta definición
la codificación. Freedman y Weinberg argu- se usa principalmente por la disciplina de tolerancia
mentan de la siguiente forma la necesidad de revisiones: de fallos. En su uso los términos «error» y
«fallo» se utilizan para expresar este significado. Con-
El trabajo técnico necesita ser revisado por la misma razón sulte también: fallo sensible al dato; fallo sensible al
que los lápices necesitan gomas: errar es humano. La segunda programa; fallos equivalentes; enmascaramiento de
razón por la que necesitamos revisiones técnicas es que, aun- fallos; fallo intermitente.
que la gente es buena descubriendo algunos de sus propios
res,algunasclases de errores se le pasan por alto más fácilmente
Dentro del contexto del proceso del software, los tér-
al que los origina que a otras personas. El proceso de revisión minos defecto y fallo son sinónimos. Ambos implican
es, por tanto, la respuesta a la plegaria de Robert Bums: un problema de calidad que es descubierto después de
gran regalo sería poder vemos comonos ven los demás! entregar el software a los usuarios finales (o a otra acti-
Una revisión revisión-es una forma de apro-
vidad del proceso del software). En los primeros capí-
vechar la diversidad de un grupo de personas para: tulos, se utilizó término error para representar un
problema de calidad que es descubierto por los inge-
1. señalar la necesidad de mejoras en el producto de una
sola persona o un equipo; nieros del software (u otros) antes de entregar el soft-
2. confirmarlas partes de un producto en las que no es nece- ware al usuario final (o a otra actividad del proceso del
saria o no es deseable una mejora; y software).
3. conseguir un trabajo técnico de una calidad más unifor-
me, o al menos más que la que puede ser con-
seguida sin revisiones, con el fin de hacer más manejable
el trabajo técnico. Pasode desarrollo
Defectos Detección

Errores
Al que filtros de las tienden o de pasos
retardar el de las actividadesde ingeniería del
Muy pocos y el flujo es Muchos y el
flujo se reducirá o un goteo. Utilice métricos poro
qué revisiones son efectivas y cuáles no.
los que no efectivos fuero del flujo. FIGURA 8.2. Modelo de amplificación de defectos.

Existen muchos tipos diferentes de revisiones que se

pueden llevar adelante como parte de la ingeniería del El objetivo primario de las revisiones técnicas for-
software. Cada una tiene su lugar. Una reunión infor- males es encontrar errores durante el proceso, de forma
mal alrededor de la máquina de café es una forma de que se conviertan en defectos después de la entrega del
revisión, si se discuten problemas técnicos. Una pre- software. El beneficio obvio de estas revisiones técni-
sentación formal de un diseño de software a una audien- cas formales es el descubrimiento de errores al princi-
cia de clientes, ejecutivos y personal técnico es una pio para que no se propaguen al paso siguiente del
forma de revisión. Sin embargo, en este libro nos cen- proceso del software.
traremos en la revisión técnicaformal (RTF)- a veces
denominada Una revisión técnica formal
es el filtro más efectivo desde el punto de vista de
tia de calidad. Llevada a cabo por ingenieros del soft- CLAVE
ware (y otros), la RTF es para ellos un medio efectivo El objetivo principal de una RTF es encontrar errores
para mejorar la calidad del software. antes de pasar a otra actividad de ingeniería
del software o de entregar al cliente.
Impacto de los defectos del software sobre Una serie de estudios (TRW, Nippon Electric y Mitre
el coste entre otros) indican que las actividades del dise-
El Standard Dictionary Electrical and ño introducen entre el 50 al 65 por ciento de todos los
(IEEE Standard 100-1992) define un errores (y en último lugar, todos los defectos) durante
137
 DEL SOFTWARE. UN ENFO QUE

el proceso del software. Sin embargo, se ha demostra- corrige el 50 por de los errores que le llegan, sin intro-
do que las revisiones técnicas formales son efectivas en ducir ningún error nuevo (una suposición muy optimis-
un 75 por 100 a la hora de detectar errores ta). Antes de que comience la prueba, se han amplificado
Con la detección y la eliminación de un gran porcenta- diez errores del diseño preliminar a 94 errores. Al termi-
je de errores, el proceso de revisión reduce nar quedan 12 errores latentes. La Figura 8.4 considera
cialmente el coste de los pasos siguientes en las fases las mismas condiciones, pero llevando a cabo revisiones
de desarrollo y de mantenimiento. del diseño y de la codificación dentro de cada paso del
Para ilustrar el impacto sobre el coste de la detec- desarrollo. En este caso los 10 errores del diseño preli-
ción anticipada de errores, consideremos una serie de minar se amplifican a 24 antes del comienzo de la prue-
costes relativos que se basan en datos de coste realmente ba. Sólo quedan 3 erroreslatentes. Recordandolos costes
recogidos en grandes proyectos de software relativos asociados con el descubrimientoy la corrección
Supongamos que un error descubierto durante el dise- de errores, se puede establecer el coste total (con y sin
ño cuesta corregirlo 1 ,O unidad monetaria. De acuerdo revisiones para nuestro ejemplo hipotético). El número
con este coste, el mismo error descubierto justo antes de errores encontrado durante cada paso mostrado en las
de que comienza la prueba costará 6,5 unidades; duran- figuras 8.3 y 8.4 se multiplica por el coste de eliminar un
te la prueba 15 unidades; y después de la entrega, entre error (1.5 unidades de coste del diseño, 6.5 unidades de
60 y unidades. coste antes de las pruebas, 15 unidades de coste durante
las pruebas, y 67 unidades de coste después de la entre-
ga. Utilizando estos datos, se puede ver que el coste total
8.4.2. Amplificacióny eliminación de defectos para el desarrollo y el mantenimiento cuando se realizan
Se puede usar un modelo de amplificación de defectos revisiones es de 783 unidades. Cuando no hay revisio-
para ilustrar la generación y detección de erro- nes, el coste total es de 2.177 unidades tres veces
res durante los pasos de diseño preliminar, diseño deta- más
llado y codificación del proceso de ingeniería del
software. En la Figura 8.2 se ilustra esquemáticamente
el modelo. Cada cuadro representa un paso en el desa-
rrollo del software. Durante cada paso se pueden gene-
rar errores que se pasan inadvertidos. La revisión puede
fallar en descubrir nuevos errores y errores de pasos
anteriores, produciendo un mayor número de errores
que pasan inadvertidos. En algunos casos, los errores
que pasan inadvertidos desde pasos anteriores se ampli-
fican (factor de amplificación, x) con el trabajo actual.
Las subdivisiones de los cuadros representan cada una Para llevar a cabo revisiones, el equipo de desarrollo
de estas características y el porcentaje de eficiencia para debe dedicar tiempo y esfuerzo, y la organización de
la detección de errores, una función de la profundidad desarrollo debe gastar dinero. Sin embargo, los resulta-
de la revisión. dos del ejemplo anterior no dejan duda de que hemos
La Figura 8.3 un ejemplohipotético de la ampli- encontrado el síndrome de ahora o pague, des-
ficación de defectos en un proceso de desarrollo de soft- pués, mucho Las revisiones técnicas formales (para
ware en el que no se llevan a cabo revisiones. Como el diseño y otras actividades técnicas) producen un bene-
muestra la figura, se asume que cada paso descubre y ficio en coste demostrable. Deben llevarse a cabo.

Una revisión técnica formal (RTF) es una actividad de desarrollado de forma uniforme y (5) hacer que los
garantía de calidad del software llevada a cabo por los proyectos sean más manejables. Además, la RTF sir-
ingenieros del software (y otros). Los objetivos de la ve como campo de entrenamiento, permitiendo que los
RTF son: (1) descubrir errores en la función, la lógi- ingenieros más jóvenes puedan observar los diferen-
ca o la implementación de cualquier representación tes enfoques de análisis, diseño e implementación del
del software; (2) verificar que el software bajo revi- software. La RTF también sirve para promover la segu-
sión alcanza sus requisitos; ( 3 ) garantizar que el soft- ridad y la continuidad, ya que varias personas se fami-
ware ha sido representado de acuerdo con ciertos liarizarán con partes del software que, de otro modo,
estándares predefinidos; (4)conseguir un software no hubieran visto nunca.

Aunque estos datos son de hace más de 20 años, pueden ser apli-
cados en un contexto moderno.

138
 8 DE C A LI D A D DEL S O F T W A R E

La RTF es realmente una clase de revisión que inclu-

ye recorridos, inspecciones, revisiones cíclicas y otro
pequeño grupo de evaluaciones técnicas del software.
RTF se lleva a cabo mediante una reunión y sólo
éxito si es bien planificada, controlada y atendi-
da. En las siguientes secciones se presentan directrices
similares a las de las inspecciones como Con las anteriores limitaciones, debe resultar obvio
representativas para las revisiones técnicas formales. que cada RTF se centra en una parte específica (y
Diseño preliminar pequeña) del software total. Por ejemplo, en lugar de
Diseño detallado
intentar revisar un diseño completo, se hacen ins-
pecciones para cada módulo (componente) o peque-
Prueba de unidad
ño grupo de módulos. Al limitar el centro de atención
Y de la RTF, la probabilidad de descubrir errores es
mayor.
'rueba de integración
El centro de atención de la RTF es un producto de
Prueba de validación
Para la integracion trabajo (por ejemplo, una porción de una especifica-
Prueba del sistema ción de requisitos, un diseño detallado del módulo,
un listado del código fuente de un módulo). El indi-
viduo que ha desarrollado el producto -el produc-
tor- informa al jefe del proyecto de que el producto
está terminado y que se requiere una revisión. El jefe
Errores latentes
del proyecto contacta con un jefe de revisión, que eva-
FIGURA 8.3. Amplificación de defectos, sin revisiones. lúa la disponibilidad del producto, genera copias del
material del producto y las distribuye a dos o tres revi-
sores para que se preparen por adelantado. Cada revi-
sor estará entre una y dos horas revisando el producto,
detallado
tomando notas y también familiarizándose con el tra-
bajo. De forma concurrente, también el jefe de revi-
sión revisa el producto y establece una agenda para
la reunión de revisión que, normalmente, queda con-
24
vocada para el día siguiente.
Prueba de v Para la integracion

Prueba del sistema

C VE
la RTF se centra en una porción relativamente pequeña
de un producto de
Errores latentes
8.4. Amplificación de defectos, llevando a cabo La reunión de revisión es llevada a cabo por el jefe
revisiones. de revisión, los revisores y el productor. Uno de los revi-
sores toma el papel de registrador, o sea, de persona que
registra (de forma escrita) todos los sucesos importan-
tes que se produzcan durante la revisión. La RTF
8.5.1. La reunión de revisión comienza con una explicación de la agenda y una bre-
Independientemente del formato que se elija para la ve introducción a cargo del productor. Entonces el pro-
RTF, cualquierreunión de revisión debe acogerse a las ductor procede con el «recorrido de del
siguientes restricciones: producto, explicando el material, mientras que los revi-
deben convocarse para la revisión (normalmente) sores exponen sus pegas basándose en su preparación
entre tres y cinco personas; previa. Cuando se descubren problemas o errores váli-
se debe preparar por adelantado, pero sin que requiera dos, el registrador los va anotando.
más de dos horas de trabajo a cada persona; y
la duración de la reunión de revisión debe ser menor
de dos horas.
-%-
Puede descargarse el NASA SATC
Cuando realizamos
de
son nuestros
objetivos?

139
 DEL SOFTWARE. UN ENFOQUE PRÁCTICO

Al final de la revisión, todos los participantes en la 1 Revisar el producto, no al productor. Una RTF
RTF deben decidir si (1) aceptan el producto sin poste- lucra gente y egos. Conducida adecuadamente, la
riores modificaciones; (2) rechazan el producto debido RTF debe llevar a todos los participantes a un senti-
a los serios errores encontrados (una vez corregidos, ha miento agradable de estar cumpliendo su deber. Si
de hacerse otra revisión) o (3 )aceptan el producto pro- se lleva a cabo incorrectamente, la RTF puede tomar
visionalmente (se han encontrado errores menores que el aura de inquisición. Se deben señalar los errores
deben ser corregidos, pero sin necesidad de otra poste- educadamente; el tono de la reunión debe ser dis-
rior revisión). Una vez tomada la decisión, todos los tendido y constructivo; no debe intentarse dificultar
participantes terminan firmando, indicando así que han o batallar. El jefe de revisión debe moderar la reu-
participado en la revisión y que están de acuerdo con nión para garantizar que se mantiene un tono y una
las conclusiones del equipo de revisión. actitud adecuados y debe inmediatamente cortar cual-
quier revisión que haya escapado al control.
8.5.2. Registro e informe de la revisión
Durante la RTF,uno de los revisores (el registrador)
procede a registrar todas las pegas que vayan surgien-
do. Al final de la reunión de revisión, resume todas las bruscamente los forma de ser
pegas y genera una lista de sucesos de revisión. Ade- educada es hacer una pregunto que permita al productor
más, prepara un informe sumario de la revisión técnica descubrir su propia errar.
formal. El informe sumario de revisión responde a tres
preguntas: 2. Fijar una agenda y mantenerla. Un mal de las reu-
niones de todo tipo es la deriva. La RTF debe seguir
fue revisado? un plan de trabajo concreto. El jefe de revisión es el
2. lo revisó? que carga con la responsabilidad de mantener el plan
3. se descubrió y cuáles son las conclusiones? de la reunión y no debe tener miedo de cortar a la
El informe sumario de revisión es una página sim- gente cuando se empiece a divagar.
ple (con posibles suplementos). Se adjunta al registro 3. Limitar el debate y las impugnaciones. Cuando un
histórico del proyecto y puede ser enviada al jefe del revisor ponga de manifiesto una pega, podrá no haber
proyecto y a otras partes interesadas. unanimidad sobre su impacto. En lugar de perder el
tiempo debatiendo la cuestión, debe registrarse el
hecho y dejar que la cuestión se lleve a cabo en otro
momento.
4. Enunciar áreas de problemas, pero no intentar resol-
ver cualquier problema que se ponga de manifiesto.
Una revisión no es una sesión de resolución de pro-
blemas. A menudo, la resolución de los problemas
Informe lista de Sucesos de Revisión Técnica
puede ser encargada al productor por sí solo o con
La lista de sucesos de revisión sirve para dos pro- la ayuda de otra persona. La resolución de los pro-
pósitos: (1) identificar áreas problemáticas dentro del blemas debe ser pospuesta para después de la reu-
producto y (2) servir como lista de comprobación de nión de revisión.
puntos de acción que guíe al productor para hacer las
correcciones. Normalmente se adjunta una lista de con-
clusiones al informe sumario.
Es importante establecer un procedimiento de segui- más bonitas
miento que asegure que los puntos de la lista de suce- puede sinceramente
sos son corregidos adecuadamente. A menos que se haga a sí mismo.
así, es posible que las pegas surgidas «caigan en saco
Un enfoque consiste en asignar la responsabili-
dad del seguimiento al revisor jefe 5. Tomar notas escritas. A veces es buena idea que el
registrador tome las notas en una pizarra, de forma
8.5.3. Directrices para la revisión que las declaraciones o la asignación de prioridades
Se deben establecer de antemano directrices para con- pueda ser comprobada por el resto de los revisores,
ducir las revisiones técnicas formales, distribuyéndolas a medida que se va registrando la información.
después entre los revisores, para ser consensuadas y, 6 . Limitar el número de participantes e insistir en lapre-
finalmente, seguidas. A menudo, una revisión paración anticipada. Dos personas son mejores que
trolada puede ser peor que no hacer ningún tipo de revi- una, pero catorce no son necesariamente mejores que
sión. A continuación se muestra un conjunto mínimo de cuatro. Se ha de mantener el número de participantes
directrices para las revisiones técnicas formales: en el mínimo necesario. Además. todos los miembros
140
 8 D E C A LI D A D DEL S O F T W A R E

del equipo de revisión deben prepararse por anticipado. 9. Llevar a cabo un buen entrenamiento de todos los
El jefe de revisión debe solicitar comentarios (que revisores. Por razones de efectividad, todos los par-
muestren que cada revisor ha revisado el material). ticipantes en la revisión deben recibir algún entre-
7. Desarrollar una lista de comprobación para cada namiento formal. El entrenamiento se debe basar en
producto que haya de ser revisado, Una lista de com- los aspectos relacionados con el proceso, así como
probaciones ayuda al jefe de revisión a estructurar las consideraciones de psicología humana que ata-
la reunión de RTF y ayuda a cada revisor a centrarse ñen a la revisión. Freedman y Weinberg
en los asuntos importantes. Se deben desarrollar lis- estiman en un mes la curva de aprendizaje para cada
tas de comprobaciones para los documentos de aná- veinte personas que vayan a participar de forma efec-
lisis, de diseño, de codificación e incluso de prueba. tiva en las revisiones.
10.Repasar las revisiones anteriores. Las sesiones de
información pueden ser beneficiosas para descubrir
problemas en el propio proceso de revisión. El pri-
mer producto que se haya revisado puede estable-
cer las propias directivas de revisión.
Como existen muchas variables (por ejemplo, núme-
listas de comprobación de ro de participantes, tipo de productos de trabajo, tiem-
8. Disponer recursos y una agenda para las RTF. Para po y duración, enfoque de revisión específico) que tienen
que las revisiones sean efectivas, se deben planificar impacto en una revisión satisfactoria, una organización
como una tarea del proceso de ingeniería del soft- de software debería determinar qué método funciona
ware. Además se debe trazar un plan de actuación mejor en un contexto local. y sus colegas
para las modificaciones inevitables que aparecen proporcionan una guía excelente para este tipo
como resultado de una RTF. de experimentos.

La garantía de calidad estadística refleja una ten-

dencia, creciente en toda la industria, a establecer la
calidad más cuantitativamente. Para el software, la
garantía de calidad estadística implica los siguientes
pasos:
1. Se agrupa y se clasifica la información sobre los
defectos del software. Para ilustrar el proceso, supongamos que una orga-
2. Se intenta encontrar la causa subyacente de cada nización de desarrollo de software recoge información
defecto (por ejemplo, no concordancia con la espe- sobre defectos durante un período de un año. Algunos
cificación, error de diseño, incumplimiento de los de los defectos se descubren mientras se desarrolla el
estándares, pobre comunicación con el cliente). software. Otros se encuentran después de que el soft-
ware se haya distribuido al usuario final.Aunque se des-
pasos se requieren cubren cientos de errores diferentes, todos se pueden
para desarrollar una SQA encontrar en una (o más) de las siguientes causas:
estadística? Especificación incompleta o errónea (EIE).
Mala interpretación de la comunicación del cliente
3. Mediante el principio de Pareto (el 80 por de los (MCC).
defectos se pueden encontrar en el 20 por 100 de
todas las posibles causas), se aísla el 20 por 100 (los Desviación deliberada de la especificación (DDE).
vitales»). Incumplimiento de los estándares de programación
(IEP).
4. Una vez que se han identificado los defectos vitales,
se actúa para corregir los problemas que han produ- Error en la representación de los datos (ERD).
cido los defectos. Interfaz de módulo inconsistente (IMI).
Este concepto relativamente sencillo representa un Error en la lógica de diseño (ELD).
paso importantehacia la creación de un proceso de inge- Prueba incompleta o errónea (PIE).
niería del software adaptativo en el cual se realizan cam- Documentación imprecisa o incompleta (DII).
bios para mejorar aquellos elementos del proceso que Error en la traducción del diseño al lenguaje de pro-
introducen errores. gramación (TLP).
141
 DEL S OFT W AR E . U N E N FO Q U E PR A C T I CO

Interfaz hombre-máquina ambigua o inconsistente En cada etapa del proceso de ingeniería del softwa-
(IHM). re se calcula un índice de fase, :
Varios (VAR).
= +
El indice de errores (IE) se obtiene mediante el cálcu-
lo del defecto acumulativo de cada asignando más
Referencia peso a los errores encontrados más tarde en el proceso de
l a Asociación China de Calidad del Software presenta ingeniería del software, que a los que se encuentranen las
uno de los sitios más completos para calidad en primeras etapas:
www.cosq.org
IE = (i x IF,) PS
Para aplicar la SQA estadística se construye la Tabla = (IF, + + + ... PS
8.1. La tabla indica que EIE, MCC y ERD son las cau-
sas vitales que contabilizan el 53 por 100 de todos los
errores. Sin embargo, debe observarse que si sólo se Total Grave Moderado Leve
consideraran errores serios, se seleccionarían las siguien-
tes causas vitales: EIE, ERD, TLP y Una vez deter- Error No. % No. No. No.
minadas las causas vitales, la organización de desarrollo
de software puede comenzar la acción correctiva. Por IEE 205 22% 34 27% 68 18% 103 24%
ejemplo, para corregir la MCC, el equipo de desarrollo
del software podría implementar técnicas que facilita- MCC 156 17% 12 9% 68 18% 76 17%
ran la especificación de la aplicación (Capítulo 11)para
mejorar la calidad de la especificación y la comunica- DDE 48 5% 1 1% 24 6% 23 5%
ción con el cliente. Para mejorar el ERD, el equipo de
desarrollo del software podría adquirir herramientas IEP 25 3% O 15 4% 10 2%
CASE para la modelización de datos y realizar revisio-
nes del diseño de datos más rigurosas. ERD 130 14% 26 20% 68 18% 36 8%
Es importante destacar que la acción correctiva se
IMI 58 6% 9 7% 18 5% 31 7%
centra principalmente en las causas vitales. Cuando éstas
son corregidas, nuevas candidatas saltan al principio de ELD 45 5% 14 11% 12 3% 19 4%
la lista.
Se han mostrado las técnicas de garantía de calidad PIE 95 10% 12 9% 35 9% 48 11%
del software estadísticas para proporcionar una mejora
sustancial en la calidad En algunos casos, las 36 4% 2 2% 20 5% 14 3%
organizaciones de software han conseguido una reduc-
ción anual del 50 por 100 de los errores después de la TLP 60 6% 15 12% 19 5% 26 6%
aplicación de estas técnicas.
Junto con la recopilación de información sobre defec- IHM 28 3% 3 2% 17 4% 8 2%
tos, los equipos de desarrollo del software pueden cal-
cular un indice de errores (IE) para cada etapa principal VAR 56 6% O 15 4% 41 9%
del proceso de ingeniería del software Des-
pués del análisis, el diseño, la codificación, la prueba y Totales 942 100% 128 100% 379 100% 435 100%
la entrega, se recopilan los siguientes datos:
TABLA 8.1. Recolección de datos para la SQA estadística
= número total de defectos descubiertos durante la eta-
pa i-ésima del proceso de ingeniería del software;
= número de defectos graves; Se puede utilizar el índice de errores junto con la
=número de defectos moderados; información recogida en la Tabla 8.1, para desarrollar
= número de defectos leves;
una indicación global de la mejora en la calidad del soft-
ware.
PS =tamaño del producto (LDC, sentencias de diseño, La aplicación de la SQA estadística y el principio de
páginas de documentación) en la etapa i-ésima. Pareto se pueden resumir en una sola frase: j Utilizar el
,W,,, , = factores de peso de errores graves, mode- tiempo para centrarse en cosas que realmente intere-
rados, y leves, en donde los valores recomendados san, pero primero asegurarse que se entiende qué es lo
son = 10, = 3, = 1. Los factores de peso que realmente interesa!
de cada fase deberían agrandarse a medida que el Un estudio exhaustivo de la SQA estadística se sale
desarrollo evoluciona. Esto favorece a la organi- del alcance de este libro. Los lectores interesados debe-
zación que encuentra los errores al principio. rían consultar y
142
 G A R A N TIA DE C A L I D A D DEL S O F TW A R E

No hay duda de que la fiabilidad de un programa de

computadora es un elemento importante de su calidad
general. Si un programa falla frecuente y CLAVE
en su funcionamiento, no importa si el resto de los
Los problemas de fiabilidad del software se deben casi
factores de calidad son aceptables.
siempre a errores en el diseño o en implementación.

Todavía se debate sobre la relación entre los con-

ceptos clave de la fiabilidad del hardware y su
Referencia Web bilidad al software (por ejemplo,
ElCentro de Análisis de Fiabilidad proporciona mucha Aunque aún falta por establecer un nexo irrefutable,
información útil sobre fiabilidad, mantenibilidad, merece la pena considerar unos cuantos conceptos que
soporte y calidad en rac.iitri.org a ambos elementos de los sistemas.
Considerando un sistema basado en computadora,
La fiabilidad del software, a diferencia de otros una sencilla medida de la fiabilidad es el tiempo medio
de calidad, puede ser medida o estimada entre (TMEF), donde;
datos históricos o de desarrollo.
del software se define en términos estadísticos TMEF = TMDF + TMDR
probabilidad de operación libre de fallos de
programa de computadora en un entorno Las siglas TMDF y TMDR corresponden a tiempo
hado y durante un tiempo específico» Por medio de fallo y tiempo medio de reparación, respecti-
un programa X puede tener una fiabilidad vamente.
estimada de durante un intervalo de proceso de
horas. En otras palabras, si se fuera a ejecutar el qué es TMEF
X 100 veces, necesitando ocho horas de una métrica más útil
de proceso (tiempo de ejecución), lo probable que
funcione correctamente (sin fallos) 96 de cada
veces. Muchos investigadores argumentan que el TMDF
Siempreque se habla de fiabilidad del software, sur- es, con mucho, una medida más Útil que los
ge la pregunta fundamental: se entiende por el tér- o Sencillamente, el usuario
mino fallo? En el contexto de cualquier discusión sobre final se enfrenta a los fallos, no al número total de erro-
calidad y fiabilidad del software, el fallo es cualquier res. Como cada error de un programa no tiene la mis-
falta de concordancia con los requisitos del software. ma tasa de fallo, la cuenta total de errores no es una
Incluso en esta definición existen grados. Los fallos pue- buena indicación de la fiabilidad de un sistema. Por
den ser simplemente desconcertantes o ser ejemplo, consideremos un programa que ha estado fun-
Puede que un fallo sea corregido en segundos cionando durante 14 meses. Muchos de los errores del
entras que otro lleve semanas o incluso meses. Para programa pueden pasar desapercibidos durante déca-
más las cosas, la corrección de un fallo pue- das antes de que se detecten. El TMEF de esos erro-
llevar a la introducción de otros errores que, final- res puede ser de 50 e incluso de 100 años. Otros
mente, a más fallos. errores, aunque no se hayan descubierto aún, pueden
tener una tasa de fallo de 18 ó 24 meses. Incluso aun-
que se eliminen todos los errores de la primera cate-
Medidas de fiabilidad y de disponibilidad goría (los que tienen un gran TMEF), el impacto sobre
primeros trabajos sobre fiabilidad intentaron la fiabilidad del software será muy escaso.
las matemáticas de la teoría de fiabilidad del Además de una medida de la fiabilidad debemos
(por ejemplo: a la predicción de la obtener una medida de la disponibilidad. La
fiabilidad del software. La mayoría de los modelos de lidad del es la probabilidad de que un progra-
relativos al hardware van más orientados a ma funcione de acuerdo con los requisitos en un
fallos debidos al desajuste que a los fallos debidos momento dado, y se define como:
fectos de diseño. En el hardware, son más
es los fallos debidos al desgaste físico (por ejemplo: Disponibilidad = + TMDR)] x 100
de la temperatura, de la corrosión y los
os fallos relativos al diseño. Desgraciadamente, La medida de fiabilidad TMEF es igualmente sen-
el softwarelo que ocurre es lo contrario. De hecho, sible al TMDF que al TMDR. La medida de disponi-
os los fallos del software, se producen por bilidad es algo más sensible al TMDR, una medida
de diseño o de implementación; el desajuste (con- indirecta de la facilidad de mantenimiento del
sulte el Capítulo 1) no entra en este panorama. w are.
143
 DEL SOFTWARE. UN ENFO QUE

8.7.2. Seguridad del software

Leveson discute el impacto del software en
sistemas críticos de seguridad, diciendo: Referencia
Antes de que se usara software en sistemas críticos de segu- Se pueden encontrar documentos sobre seguridad
ridad, normalmente éstos se controlaban mediante dispositi- del un glosario que merecen
vos electrónicos y mecánicos convencionales (no peno en
mables). Las técnicas de seguridad de sistemas se diseñaban
para hacer frente a fallos aleatorios en esos dispositivos [no
programables]. Los errores humanos de diseño no se consi-
deraban porque se suponía que todos los defectos producidos vedad y su probabilidad de ocurrencia4. Para que sea
por los errores humanos se podían evitar o eliminar comple- efectivo, se tiene que analizar el software en el contex-
tamente antes de su distribución y funcionamiento. to del sistema completo. Por ejemplo, puede que un sutil
error en la entrada del usuario (las personas son com-
ponentes del sistema) se magnifique por un fallo del
software que producen los datos de control que actúan
de forma inadecuada sobre un dispositivo mecánico. Si
se dan un conjunto de condiciones externas del entor-
no (y sólo si se dan), la situación inadecuada del dis-
positivo mecánico producirá un fallo desastroso. Se
pueden usar técnicas de análisis, como el análisis
Cuando se utiliza el software como parte del siste- árbol de fallos la lógica de tiempo real
ma de control, la complejidad puede aumentar en un o los modelos de redes de Petri para
orden de magnitud o más. Los defectos sutiles de dise- predecir la cadena de sucesos que pueden producir los
ño, producidos por un error humano -algo que se pue- riesgos y la probabilidad de que se dé cada uno de los
de descubrir y eliminar en el control convencional sucesos que componen la cadena.
basado en el hardware-llegan a ser mucho más difí- Una vez que se han identificado y analizado los
gos, se pueden especificar los requisitos relacionados
ciles de descubrir cuando se utiliza el software.
La seguridad del software es una actividad de garan- con la seguridad para el software. Esto es, la especifi-
tía de calidad del software que se centra en la identifi- cación puede contener una lista de eventos no desea-
cación y evaluación de los riesgos potenciales que bles y las respuestas del sistema a estos eventos. El papel
pueden producir un impacto negativo en el software y del software en la gestión de eventos no deseados es
hacer que falle el sistema completo. Si se pueden iden- entonces apropiado.
tificar pronto los riesgos en el proceso de ingeniería del
software podrán especificarse las características del dise- es la diferencia
ño del software que permitan eliminar o controlar los entre fiabilidaddel software
riesgos potenciales. y seguridad del software?
Como parte de la seguridad del software, se puede Aunque la fiabilidad y la seguridad del software
dirigir un proceso de análisis y modelado. Inicialmente, bastante relacionadas, es importante entender la
se identifican los riesgos y se clasifican por su impor- diferencia que existe entre ellas. La fiabilidad del soft-
tancia y su grado de riesgo. Por ejemplo, algunos de ware utiliza el análisis estadístico para determinar la
los riesgos asociados con el control basado en com- probabilidad de que pueda ocurrir un fallo del softwa-
putadora del sistema de conducción de un automóvil re. Sin embargo, la ocurrencia de un fallo no lleva nece-
podrían ser: sariamente a un riesgo o a un accidente. La seguridad
Produce una aceleración incontrolada que no se del software examina los modos según los cuales los
puede detener. fallos producen condiciones que pueden llevar a acci-
No responde a la presión del pedal del freno (dete- dentes. Es decir, los fallos no se consideran en vacío,
niéndose). sino que se evalúan en el contexto de un completo sis-
No responde cuando se activa el contacto. tema basado en computadora.
Un estudio completo sobre seguridad del software y
Pierde o gana velocidad lentamente. análisis del riesgo va más allá del ámbitode este libro. Para
Cuando se han identificado estos riesgos del siste- aquellos lectores que estén más interesados,deberían con-
ma, se utilizan técnicas de análisis para asignar su sultar el libro de Leveson sobre este tema.

Este método es al método de análisis de riesgos descrito

para la gestión del proyecto de software en el capítulo 6 . La
pal diferencia es el énfasis en aspectos de tecnología frente a
relacionados con el proyecto.

144
 G A R A N TIA DE C A LID A D DEL S O F T W A R E

Si William Shakespeare hubiera escrito sobre las con- Para llevar a cabo la entrada adecuada del menú para cada apli-
diciones del ingeniero de software moderno, podría per- cación, un «localizador» (una persona que habla en el idioma
local y con la terminología de ese lugar) traduce los menús de
fectamente haber escrito: es humano, encontrar acuerda con el idioma en uso. El problema es asegurar que (1)
el error rápida y correctamente es divino.» En los años cada entrada de menú (pueden existir cientos de ellas) se
sesenta, un ingeniero industrial japonés, Shigeo cue a los estándares apropiados y que no existan conflictos,
go que trabajaba en Toyota, desarrolló una téc- independientemente del lenguaje que se está utilizando.
nica de garantía de calidad que conducía a la prevención El uso del poka-yoke para la prueba de diversos
a la temprana corrección de errores en el proceso de menús de aplicación desarrollados en diferentes len-
fabricación. Denominado poku-yoke (prueba de guajes, tal y como se ha descrito anteriormente, se dis-
‘res),el concepto de Shingo hacía uso de dispositivos cute en un artículo de Harry Robinson
poku-yoke -mecanismosque conducen (1) a la pre- Nosotros primero decidimos dividir el problema de prue-
vención de un problema de calidad potencial antes de bas de menús en partes que puedan ser resueltas más fácil-
que éste ocurra, o (2) a la rápida detección de proble- mente. Nuestro avance para la resolución del problema
mas de calidad si se han introducido ya-. Nosotros fue el comprender que existían dos aspectos separados para los
encontramos dispositivos poka-yoke en nuestra vida catálogos de mensaje. Había por una parte el aspecto de con-
cotidiana (incluso si nosotros no tenemos conciencia de tenidos: las traducciones de texto muy simples tales como
biar meramente por la palabra Puesto que
este concepto). Por ejemplo, el interruptor de arranque el equipo que realizaba las comprobaciones no hablaba de for-
de un coche no trabaja si está metida una marcha en la ma fluida el lenguaje en el que se pretendía trabajar, teníamos
transmisión automática (un dispositivo de prevención); que dejar estos aspectos a traductores expertos del lenguaje.
un pitido de aviso del coche sonará si los cinturones de El segundo aspecto de los catálogos del mensaje era
seguridadno están bien sujetos (un dispositivo de detec- la estructura, las reglas sintácticas que debía obedecer
ción defallos). un catálogo de objetivos adecuadamente construido. A
Un dispositivo de poku-yoke presenta un conjunto diferencia del contenido, en este caso sí que era posible
de características comunes: para el equipo de comprobación el verificar los aspec-
Es simple y barato -si un dispositivo es demasiado tos estructurales de los catálogos.
complicado y caro, no será efectivo en cuanto a Como un ejemplo de lo que significa estructura, con-
costo-; sideremos las etiquetas y los mnemónicos de un menú
Es parte del proceso - e s t o es, el dispositivo de aplicación. Un menú está constituido por etiquetas
yoke está integrado en una actividad de ingeniería-; y sus mnemónicos (abreviaturas)asociados. Cada menú,
Está localizado cerca de la tarea del proceso donde independientemente de su contenido o su localización,
están ocurriendo los errores -por consiguiente pro- debe obedecer las siguientes reglas listadas en la Guía
porciona una realimentación rápida en cuanto a la de Estilo Motif
corrección de errores se refiere-. Cada nemotécnico debe estar contenido en su eti-
queta asociada;
Cada nemotécnico debe ser único dentro del menú;
Cada nemotécnico debe ser un carácter Único;
Referencia Cada nemotécnico debe estar en ASCII.
Se puede obtener una colección completa de recursos
de en Estas reglas son invariantes a través de las localiza-
ciones, y pueden ser utilizadas para verificar que un menú
está correctamente construidoen la localización objetivo.
Existen varias posibilidades para realizar la prueba
de errores de los mnemónicos del menú:
Aunque el poka-yoke fue originariamente desarro- Dispositivo de prevención. Nosotros podemos escri-
liado para su uso en «control de calidad cero» bir un programa para generar los mnemónicos
para el hardware fabricado, puede ser adaptado para su ticamente, dada una lista de etiquetas en cada menú.
Úso en ingeniería del software. Para ilustrar esto, con- Este enfoque evitaría errores, pero el problema es que
sideremos el problema siguiente escoger un mnemónico adecuado es difícil, y el esfuer-
Una compañía de productos de software vende el software zo requerido para escribir el programa no estaría justi-
de aplicaciónen el mercado internacional. Los menús ficado con el beneficio obtenido.
gablesy todos los códigos asociados proporcionados con cada
aplicacióndeben reflejar el lenguaje que se emplea en el lugar
Dispositivo de prevención. Podríamos escribir un
donde se usa. Por ejemplo, el elemento del del lenguaje programa que prevendría al localizador de elegir unos
inglés tiene el mnemónico «C»asociadocon ello. mnemónicos que no satisfagan el criterio. Este enfoque
Cuando la aplicación se vende en un país de habla francesa, el también errores, pero el beneficio obtenido sería
mismo elemento del menú es con el mnemónico mínimo: los mnemónicos incorrectos son lo
145
 DEL SOFTWARE. UN ENFOQUE

mente fáciles de detectar y corregir después de que apa- estructurales de los menús . Un pequeño
rezcan. yoke leería la tabla, recuperaría los mnemónicos y eti-
Dispositivo de detección. Nosotros podríamos pro- quetas a partir del catálogo de mensajes, y compararía
porcionar un programa para verificar que las etiquetas posteriormente las cadenas recuperadas con el criterio
del menú escogidas y los mnemónicos satisfacen los establecido descrito anteriormente.
criterios anteriores. Nuestros localizadores podrían eje- Los poka-yoke eran pequeños (aproximada-
cutar los programas sobre los catálogos de mensaje tra- mente líneas), fáciles de escribir (algunos de los escri-
ducidos antes de enviarnos a nosotros dichos catálogos. tos estaban en cuanto al tiempo por debajo de una hora)
Este enfoque proporcionaría una realimentación rápida y fáciles de ejecutar. Nosotros ejecutábamos nuestros
sobre los errores y será, probablemente, un paso a dar sobre aplicacionesen la ubicación
en el futuro. en inglés por defecto y en 11ubicaciones extranjeras. Cada
Dispositivo de detección. Nosotros podríamos escri- ubicación contenía 100 menús para un total de 1.200
bir un programa que verificase las etiquetas y menús. Los encontraron 311erro-
del menú, y ejecutara el programa sobre catálogos de res en menús y mnemónicos. Pocos de los problemas que
mensajes después de que nos los hayan devuelto los nosotros descubrimos eran como muy llamativos,pero en
lizadores. Este enfoque es el camino que actualmente total habrían supuesto una gran preocupación en la prue-
estamos tomando. No es tan eficiente como alguno de los ba y ejecución de nuestras aplicacioneslocalizadas.
iétodos anteriormente mencionados y puede requerir El ejemplo descrito antes representa un dispositivo
que se establezca una comunicación fluida hacia delan- poka-yoke que ha sido integrado en la actividad de prue-
te y hacia atrás con los localizadores, pero los errores bas de ingeniería del software. La técnica poka-yoke
detectados son incluso fáciles de corregir en este punto. puede aplicarse a los niveles de diseño, codificación y
Varios textos pequeños de poka-yoke se utilizaron pruebas y proporciona un filtro efectivo de garantía de
como dispositivos poka-yoke para validar los aspectos calidad.

Esta sección contiene varios objetivos, siendo el prin- 9004-2. Quality Management and Quality
cipal describir el cada vez más importante estándar inter- tem Elements 2-. Este documento propor-
nacional 9001. El estándar, que ha sido adoptado ciona las directrices para el servicio de facilidades
por más de 130 países para su uso, se está convirtiendo del software como soporte de usuarios.
en el medio principal con el que los clientes pueden juz- Los requisitos se agrupan bajo 20 títulos:
gar la competencia de un desarrollador de software. Uno
de los problemas con el estándar ISO 9001 está en que Responsabilidad de la gestión.
no es específico de la industria: está expresado en tér- Inspección, medición y equipo de pruebas.
minos generales, y puede ser interpretado por los Sistema de calidad.
rrolladores de diversos productos como cojinetes de Inspección y estado de pruebas.
bolas (rodamientos), secadores de pelo, automóviles, Revisión de contrato.
equipamientos deportivos y televisiones, así como por Acción correctiva.
desarrolladores de software. Se han realizado muchos Control de diseño.
documentos que relacionan el estándar con la industria Control de producto no aceptado.
del software, pero no entran en una gran cantidad de Control de documento.
detalles. El objetivo de esta sección es describir lo que Tratamiento, almacenamiento, empaquetamiento y
significa el ISO 9001 en términos de elementos de cali- entrega.
dad y técnicas de desarrollo. Compras.
Para la industria del software los estándares rele- Producto proporcionado al comprador.
vantes son: Registros de calidad.
9001. Quality Systems-Modelfor Quality Identificación y posibilidad de seguimiento del producto,
Auditorías internas de calidad.
rance in Design, Development, Production,
Formación
llation and Servicing. Este es un estándar que
Control del proceso
describe el sistema de,calidad utilizado para mante-
ner el desarrollo de un producto que implique diseño. Servicios.
9000-3. Guidelinesfor Application 9001 Inspección y estado de prueba.
Técnicas estadísticas.
to the Development, and Maintainance of
Este es un documento específico que Merece la pena ver un pequeño extracto de la ISO
interpreta el ISO 9001 para el desarrollador de soft- 9001. Este le dará al lector una idea del nivel con el que
ware. la ISO 9001 trata la garantía de calidad y el proceso de
146
 G A R A N TIA DE CA LID A D DEL S O F T W A R E

desarrollo. El extracto elegido proviene de la sección ción del párrafo pretendido obviamente por los
1.11: procesos estándar de ingeniería donde equipos tales
4.11. equipo de Inspección, medición y pruebas. como indicadores de calibración y potenciómetros son
habituales-.
El suministradordebe controlar, calibrar y mantenerla ins-
pección, medir y probar el equipo, ya sea el dueño el suminis- Una interpretación del párrafo anterior es que el dis-
trador, prestado o proporcionado por el comprador, para tribuidor debe asegurar que cualquiera de las herramien-
demostrarla conformidaddel producto con los requisitosespe- tas de software utilizadas para las pruebas tiene, por lo
cificados. El equipo debe utilizarse de un modo que asegure menos, la misma calidad que el software a desarrollar, y
que se conoce la incertidumbre de la medición y que es con- que cualquierprueba del equipo produce valores de medi-
sistente con la capacidad de medición requerida.
ción, por ejemplo, los monitores del rendimiento, tienen
Lo primero a destacar es su generalidad; se puede una precisión aceptable cuando se compara con la preci-
aplicar al desarrollador de cualquier producto. Lo sión especificada para el rendimiento en la especificación
segundo a considerar es la dificultad en la interpreta- de los requisitos.

plan de SQA proporciona un mapa para documentos de usuario (por ejemplo: archivos de
la garantía de calidad del software.El plan, desa- ayuda).
rrollado por un grupo de SQA, sirve como plantilla para Además, esta sección define conjunto mínimo de
actividades de SQA instituidas para cada proyecto de productos de trabajo que se pueden aceptar para lograr
software. alta calidad.
Los estándares, prácticas y convenciones muestran
todos los que se aplican durante el
proceso de software (por ejemplo: estándares de docu-
mentos, estándares de codificación y directrices de revi-
sión). Además, se listan todos los proyectos, procesos y
El Plan GCS (en algunos casos) métricas de producto que se van a reco-
ger como parte del de ingeniería del software.
El IEEE ha recomendado un estándar para La sección Revisiones y Auditorías del plan identi-
fica las revisiones y auditorías que se van a llevar a cabo
los planes de SQA. Las secciones iniciales describen el
propósito y el alcance del documento e indican por el equipo de ingeniería del software, el grupo de
actividades del proceso del software cubiertas por SQA y el cliente. Proporciona una visión general del
la garantía de calidad. Se listan todos los documentos enfoque de cada revisión y auditoría.
señalados en el plan de SQA y se destacan todos los La sección Prueba hace referencia al Plan y Procedi-
estándares aplicables. La sección de Gestión del plan miento de Pruebas del (Capítulo 18). También
describe la situación de la SQA dentro de la estructura define requisitos de mantenimiento de registros de prue-
organizativa; las tareas y las actividades de SQA y su bas. La Información sobre problemas y acción
emplazamientoa lo largo del proceso del software; así va define procedimientos para informar, hacer segui-
como los papeles y responsabilidades organizativas rela- miento y resolver errores y defectos, e identifica las res-
tivas a la calidad del producto. ponsabilidades organizativas para estas actividades.
La sección de Documentación describe (por referen- El resto del plan de SQA identifica las herramientas
cia) cada uno de los productos de trabajo producidos como y métodos que soportan actividades y tareas de SQA;
del proceso de software. Entre estos se incluyen: hace referencia a los procedimientos de gestión de con-
figuración del software para controlar el cambio; defi-
documentos del proyecto (por ejemplo: plan del pro- ne un enfoque de gestión de contratos; establece métodos
yecto), para reunir, y mantener todos los registros;
modelos (por ejemplo: jerarquías de clases), identifica la formación que se requiere para cumplir las
documentos técnicos (por ejemplo: especificaciones, necesidades del plan y define métodos para identificar,
planes de prueba), evaluar, supervisar y controlar riesgos.
 DEL SOFTWARE. UN ENFOQUE P R A C TI C O

La garantía de calidad del software es una «actividad mostrado extremadamente efectiva en el descubrimiento
de protección» que se aplica a cada paso del proceso de errores.
del software. La SQA comprende procedimientos para Para llevar a cabo adecuadamente una garantía de
la aplicación efectiva de métodos y herramientas, revi- calidad del software, se deben recopilar, evaluar y dis-
siones técnicas formales, técnicas y estrategias de prue- tribuir todos los datos relacionados con el proceso de
ba, dispositivos poku-yoke, procedimientos de control ingeniería del software. La SQA estadística ayuda a
de cambios, procedimientos de garantía de ajuste a los mejorar la calidad del producto y la del proceso de soft-
estándares y mecanismos de medida e información. ware. Los modelos de fiabilidad del software amplían
La SQA es complicada por la compleja naturaleza de las medidas, permitiendo extrapolar los datos recogidos
la calidad del software -un atributo de los programas sobre los defectos, a predicciones de tasas de fallo y de
de computadora que se define como «concordancia con fiabilidad.
los requisitos definidos explícita e implícitamente»-. Resumiendo,recordemos las palabras de Dunn y
Cuando se considera de forma más general, la calidad del man garantía de calidad del software es
software engloba muchos factores de proceso y de pro- la guía de los preceptos de gestión y de las disciplinas
ducto diferentes con sus métricas asociadas. de diseño de la garantía de calidad para el espacio tec-
Las revisiones del software son una de las activida- nológico y la aplicación de la ingeniería del software.))
des más importantes de la SQA. Las revisiones sirven La capacidad para garantizar la calidad es la medida de
como filtros durante todas las actividades de ingeniería madurez de la disciplina de ingeniería. Cuando se sigue
del software, eliminando defectos mientras que no son de forma adecuada esa guía anteriormente menciona-
relativamente costosos de encontrar y corregir. La revi- da, lo que se obtiene es la madurez de la ingeniería del
sión técnica formal es una revisión específica que se ha software.

von Alvin, W. (ed.), Reliability Engineering, Glass, Quality IEEE

Prentice-Hall, 1964. wure, Mayo 1998, pp. 103-104 y 107.
A3-1987, Quality Systems Iso 9000 Quality Systems Development
logy, 1987. Handbook: A Systems Engineering
Heinimann, 1998.
Arthur, Improving Software Quality: An
Guide to TQM, 1992. Software notas del
curso, IBM Systems Sciences Institute, IBM Corporation,
Arthur, Improvements Softwa- 1981.
re System CACM,vol. 40, 6, Junio 1997, pp.
47-52. Software Quality Model
of Electrical Engineers, 1990.
Boehm, Engineering
tice-Hall, 198 Software Engineering Standards, ed. de 1994, IEEE
Computer Society, 1994
Crosby, Quality Free, 1975. Jahanian, y A. K. Mok, Analysis of
Crosby, Quality Free, 1979. Timing Properties of Real Time IEEE Trans.
Software Engineering, vol. SE-12, 9, Septiembre 1986,
Deming,W. Out the Crisis, MIT Press, 1986.
890-904.
T., Can Make Quality Jones, Productivity,
presentación de Cutter Summit '99, 1986.
ton, MA, 26 de Abril 1999.
Kan, H., Metrics and in Software
Dijkstra, E., A Discipline lity Engineering, Addison Wesley, 1995.
Hall, 1976.
Kaplan, Clark y Tang,
Dunn, y Ullman, Quality re Quality: 40 Innovationsfrom IBM,
1982.
Leveson, N.G., «Software Safety: Why, What, and
Freedman, y G. M. Weinberg, Handbook ACM vol. 18, 2, Junio 1986,
Inspections and Reviews, ed.,
Dorset House, 1990. Leveson,N. G., y Stolzy, Analysis using
T., y Graham, Inspections, IEEE Trans. Software Engineering, vol. SE-13,
son-Wesley, 1993. 3, Marzo 1987, pp. 386-397.

148
 G A R A N TIA DE C A L ID A D DEL S O F TW A R E

N.G., Safeware: and Rook, Reliahility Handhook, Elsevier,

puters, Addison-Wesley, 1995. 1990.
Linger, y Structured Schulmeyer, G. y J.I. (eds.),
Addison-Wesley, 1979. hook Quality Assurance, Prentice-Hall, ed.,
Littlewood, Software 1998.
en Software Reliahility: Modelling and Schmauch, C.H., Software
Bittanti, ed.), Springer-Verlag, 1989, pp. 141-209. ASQC Quality Press, Milwaukee, 1994.
Manns, y M. Coleman, Software Quality Schoonmaker, S.J., Engineers and
Press, 1996. Designers, Hill, 1997.
Musa, A. Iannino y K. Okumoto,
Shigeo Shingo, Zero Control:
ring and Software with Reliahility Measures, pection and the Poka-Yoke Productivity Press,
1987. 1986.
Paulk, M., et al., Model for
Software,Software Engineering Institute, Camegie Mellon Somerville, I., Engineering, ed.,
Pittsburgh, PA, 1993. son-Wesley, 1996.

A. Toman, y G. Votta, «An Tingey, M., Comparing Malcolm

Experiment to Assess the Cost-Benefits of Code dridge y al SEJ CMM para Software, Prentice-Hall, 1996.
Large Scale Software Proc. Tricker, ISO 9000for Bussinesses,
ACM SIGSOFT the Soft- terworth-Heinemann, 1997.
ware Engineering, Washington DC, Octubre 1996, ACM
Press, 92-103. W.E., et al., Fault Handhook,
Nuclear Regulatory Commision, NUREG-0492, Enero
Robinson, H., Poka-Yoke Techniques for 1981.
Early Error Proc.
on Software and Review Wilson, A., 8 stp 9000,
1997, 119-142. bridge Interactive Publications, 1996.

8.1. Al principiodel capítulo se señaló que «el control de varia- 8.10.Algunas personas piensan que una RTF debe evaluar el
está en el centro del control de calidad». Como todos los estilo de programación al igual que la corrección. una bue-
que se crean son diferentes unos de otros, na idea? qué?
son las variaciones que se buscan y cómo se controlan? 8.1 Revise la Tabla 8.1 y seleccione las cuatro causas vita-
8.2. posible evaluar la calidad del software si el clien- les de errores serios y moderados. Sugiera acciones correc-
te. no se pone de acuerdo sobre lo que se supone que ha de toras basándose en la información presentada en otros
hacer? capítulos.
8.3. La calidad y la fiabilidad son conceptos relacionados, 8.12. Una organización utiliza un proceso de ingeniería del
pero son fundamentalmente diferentes en varias formas. Dis- software de cinco pasos en el cual los errores se encuentran
cútalas. de acuerdo a la siguiente distribución de porcentajes:
8.4. un programa ser correcto y aún así no ser fiable?
Expliquepor qué. Paso Porcentaje de errores encontrados
un programa ser correcto aun así no exhibir una 1 20
buena calidad? Explique por qué. 2 15
8.6. qué a menudo existen fricciones entre un grupo de 3 15 %
ingeniería del software y un grupo independiente de garantía
de calidad del software? esto provechoso? 4 40
8.7. Si se le da la responsabilidad de mejorar la calidad del 5 10
software en su organización. es lo primero que haría?
sería lo siguiente? Mediante la información de la Tabla 8.1 y la distribución de
porcentajes anterior, calcule el índice de defectos global para
8.8. Además de los errores, otras características claras dicha organización. Suponga que PS = 100.000.
del software que impliquen calidad? son y cómo se
pueden medir directamente? 8.13. Investigue en los libros sobre fiabilidad del software y
escriba un artículo que explique un modelo de fiabilidad del
8.9. Una revisión técnica formal sólo es efectiva si todo el
software. Asegúrese de incluir un ejemplo.
mundo se la prepara por adelantado. descubriría que
de los participantes no se la ha preparado? haría si 8.14.El concepto de TMEF del software sigue abierto a deba-
fuera el jefe de revisión? te. pensar en algunas razones para ello?
149
 DEL SOFTWARE. UN ENFOQUE

8.15. Considere dos sistemas de seguridad crítica que estén 8.17. Sugiera unos cuantos dispositivos poka-yoke que
controlados por una computadora. al menos tres peligros dan ser usados para detectar prevenir errores que son
para cada uno de ellos que se puedan relacionar directamen- encontrados habitualmente antes de «enviar» un mensaje
te con los fallos del software. por e-mail.
8.16. Utilizando recursos web y de impresión, desarrolle un 8.18. Adquiera una copia de ISO 9001 e ISO 9000-3. Prepa-
tutorial de 20 minutos sobrepoka-yoke y expóngaselo a su cla- re una presentación que trate tres requisitos ISO 9001 y cómo
se. se aplican en el contexto del software.

Los libros de Moriguchi Excellence: A Total Qua- Sanders, Software Quality: A Framework for
lity Guide, Productivity Press, Horch Sofiware Developrnent, Addison-Wesley, 1994.
(Practica1Guide Software Quality Management, Artech Sumner, Software Quality Assurance,
Publishing, 1996) son unas excelentes presentaciones a nivel 1993.
de gestión sobre los beneficios de los programas formales de Wallmuller, E., Software Quality Assurance: A Practical
garantía de calidad para el software de computadora. Los Approach, Prentice-Hall, 1995.
libros de Deming y Crosby aunque no
se centran en el software, ambos libros son de lectura obli- Weinberg, G. M., Quality Software Managenzent, 4
gada para los gestores senior con responsabilidades en el desa- Dorset House, 1992, 1993, 1994 y 1996.
rrollo de software. Gluckman y Roome (Every day Heroes Wilson, Software Rx: Secrets Engineering Qua-
the Quulity Movement, Dorset House, 1993) humaniza los Sofiware, Prentice-Hall, 1997.
aspectos de calidad contando la historia de los participantes Una antología editada por Wheeler, Bryczynsky y Mee-
en el proceso de calidad. Kan and Models Soft- son Inspection: lndustry Best Practice, IEEE Com-
ware Quality Engineering, Addison-Wesley, 1995) presenta puter Society Press, 1996) presenta información útil sobre
una visión cuantitativade la calidad del software. Manns esta importante actividad de GCS. Friedman y Voas (Software
ware Quality Assurance, Macmillan, 1996) es una excelente Assessment, Wiley, 1995) estudian los soportes y métodos
introducción a la garantía de calidad del software. prácticos para asegurar la fiabilidad y la seguridad de pro-
Tingley (Compering 9000, Malcom Baldridge, and gramas de computadora.
the CMMfor Software, Prentice-Hall, 1996) proporciona Musa (Software Reliability Engineering: More
una guía útil para las organizacionesque se esfuerzan en mejo- Software, Faster Development and Testing,
rar sus procesos de gestión de calidad. Oskarsson ISO 1998) ha escrito una guía práctica para aplicar a las técnicas
9000 Approach to Building Quality Software, Prentice-Hall, de fiabilidad del software. Han sido editadas antologías de
1995) estudia cómo se aplica el ISO al software. artículos importantes sobre la fiabilidad del software por Kapur
Durante los últimos años se han escrito docenas de libros y otros (Contrihutions to Hardware and Software
sobre aspectos de garantía de calidad. La lista siguiente es World Scientific Publishing Co., Gritzails
una pequeña muestra de fuentes útiles: (Reliability,Quality and of Systems,
Clapp, et al., Quality Control,Error Analy- Kluwer Academic Publishing, y Lyu (Handbook
and Testing, Noyes Data Park Software Reliahility Engineering, 1996).Sto-
Dunn, H., y Ullman, Computer Softwa- rey (Safety-Critica1 Computer Systems, Addison-Wesley,
re, 1994. 1996) y continúan siendo los estudios más
Fenton, N., Whitty y Y. Iizuka, Quality Assu- completos sobre la seguridad del software publicados hasta
rance and Measurement: Worldwide Industrial Applications, la fecha.
Chapman Hall, 1994. Además de la técnicapoka-yoke para el software
Ferdinand,A. E., Systems, Software, and Quality Enginee- de prueba de errores es estudiada por Shingo (The Pro-
ring,Van Nostrand Reinhold, 1993. duction Management Improving Product Quality by
Preventing Defects, Productivity Press, 1989) y por Shimbun
Ginac, Oriented Software Quality Assu- Improving Product Quulity Preventing Defects,
rance, Prentice-Hall, 1998. Productivity Press, 1989).
Ince, ISO 9001 and Software Quality Assurance, En Intemet están disponibles una gran variedad de fuen-
1994. tes de información sobre la garantía de calidad del software,
Ince, An lntroduction to Software Quality Assurance fiabilidad del software y otros temas relacionados. Se puede
1994. encontrar una lista actualizada con referencias a sitios (pági-
Jarvis, A., y Crandall, to Quality: nas) web que son relevantes para la calidad del software en
Guide and Toolkit, Prentice-Hall, 1997. http://www.pressman5.com.

150