You are on page 1of 44

2.1. Calidad en los sistemas de informacin.

2.2. Defectos y errores de calidad en los sistemas de informacin.


2.2.1. El cuaderno de registro de defectos.
2.2.2. Contabilizacin de defectos y errores.
2.2.3. Formas de encontrar y corregir defectos.
2.2.4. El costo de encontrar y corregir defectos.
2.3. Listas de comprobacin.
2.4. Gestin del tiempo para el desarrollo de sistemas de informacin.
2.5. Obtener calidad en los sistemas de informacin (mtodos, mtricas,
metodologas, estndares).
2.6. Controlar la calidad del sistema de informacin.
2.7. Costo de calidad de los sistemas de informacin.
2.7.1. Clculo del costo de la calidad
Presentaremos tres definiciones relacionadas con calidad en sistemas y sobre ella
basaremos la definicin de calidad de los sistemas de informacin.

W. E. Perry: Calidad se define en el diccionario como un atributo o caracterstica
asociada a algo, as pues, calidad no puede ser definida de manera universal, sino
que, por el contrario, debe ser definida para ese algo en cuestin. Calidad viene a
ser una lista que expresa una serie de caractersticas y atributos. Calidad en el
ambiente de procesamiento de datos debe ser definida por la organizacin. La
definicin de calidad hecha por una organizacin puede ser diferente a la hecha por
otra. Para una organizacin, un FORD MODELO T bien construido es calidad.
Mientras que, para otra, calidad es un CADILLAC FULL EQUIPO. La calidad no
puede ser incorporada a un producto o ser medida hasta tanto no se defina. La gran
mayora de las instalaciones de procesamiento de datos apenas han comenzado a
definir lo que es calidad en las aplicaciones computarizadas.
La definicin de Perry nos dice, principalmente, que la calidad no debe ser
concebida en trminos generales o abstractos y que cada organizacin debe
identificar lo que para ella significa un sistema de calidad, con el fin de establecer
los patrones y las vas necesarias para lograrla.
IEEE Computer Society Estndar P730: Software Quality Assurance
(SQA) es un patrn planeado y sistmico de todas las acciones necesarias,
para proveer suficiente confianza de que el software se construye conforme
a los requerimientos tcnicos preestablecidos.

A pesar de la definicin de IEEE Computer Society est orientada hacia la
funcin de calidad en sistemas, al definir las responsabilidades de SQA
describe varios aspectos importantes relacionados con la calidad de los
sistemas:
La calidad de un sistema requiere de la participacin de todos, no es algo
que atae exclusivamente a un grupo de SQA, incluye <<todas las acciones
necesarias>>
La calidad de un sistema es fruto de una cuidadosa planificacin; no es algo
que se logra de manera fortuita o improvisada.
La nocin de calidad es relativa a especificaciones tcnicas preestablecidas.
El propsito de SQA no es el de garantizar 100% de confiabilidad, es
aumentar la confianza de que se han dado todos los pasos necesarios para
limpiar errores del software que se desarrolla.
G. J. Myers: La confiabilidad del software es la probabilidad de que este se
ejecute por un cierto perodo de tiempo sin fallas, ponderada por el costo que
representa para el usuario cada falla encontrada.
La definicin de Myers tiene dos elementos importantes:
1. Probabilidad de que se presente una falla; esto es, nunca existe la absoluta
certeza de que un software est totalmente limpio de errores.
2. El costo que genera para los usuarios por cada falla generada


DEFECTOS

El termino defecto se refiere a algo que est equivocado en un programa, tal
como un error sintctico , una falta tipogrfica, un error de puntuacin, o una
sentencia incorrecta del programa.
Los defectos pueden estar en los programas, en los diseos o incluso en los
requisitos.
Las especificaciones o en otra documentacin. Los defectos pueden ser
sentencias extra o redundantes, sentencias incorrectas o secciones del programa
omitidas. Un defecto, es cualquier cosa que reduce la capacidad de los
programas para cumplir completa y efectivamente las necesidades de los
usuarios. Un defecto es una cosa objetiva. Es algo que puedes identificar,
describir y contabilizar.
Es importante separar la cuestin de encontrar o identificar los defectos de la
determinacin de sus causas. La simple contabilizacin y registros de los
defectos en los productos software no es la especificacin de las causas ni la
asignacin de culpas. Los defectos cometidos. Sin embargo, tienen sus causas.
Puede haber cometido un error al escribir el nombre de un parmetro, omitido
un signo de puntuacin o llamado incorrectamente un procedimiento. Todos
estos errores causan defectos.
Todos los defectos por consiguiente, proviene de errores humanos y muchos
de los que los ingenieros del software cometen, causa defectos en los
programas.

ERRORES

Los errores son cosas incorrectas que cometen las personas y sin tener en
cuenta cuando y quien los comete, los defectos son elementos defectuosos de
los programas. As las personas cometen errores o equivocaciones mientras
que los programas tienen defectos. Cuando los ingenieros cometen errores que
conducen a defectos, nosotros nos referimos a esto como la introduccin de
defectos.
Esto significa que para reducir el nmero de defectos que introduces en tus
productos, debes cambiar la forma de hacer cosas para eliminar los defectos en
tus productos. Sin embargo, sencillamente tienes que encontrarlos. La
eliminacin de defectos es, por lo tanto, un proceso ms sencillo que la
prevencin de defectos. La prevencin de defectos es un aspecto importante y
prioritario que requiere un estudio comprensivo de todo el proceso de
desarrollo del software.
Los defectos deberan ser importantes para cada ingeniero del software no
solo porque afectan a los usuarios, sino tambin porque ms de la mitad del
esfuerzo de las organizaciones de software est dedicado a encontrar y
corregir los defectos. Puesto que el tiempo de pruebas es difcil de predecir,
los defectos son, a menudo, la causa principal de los problemas de costes y
programaciones.

Nmero del
tipo
Nombre del tipo Descripcin
10 Documentacin Comentarios y mensajes
20 Sintaxis Ortografa, puntuacin, erratas, formato
de las instrucciones
30 Construir, paquetes Llamadas a procedimientos y referencias,
E/S, formato de usuario
40 Asignacin Declaracin, nombres duplicados, mbito,
limites
50 interfaz Llamadas a procedimientos y referencias,
E/S, formatos de usuario
60 Chequeo Mensajes de error, chequeos inadecuados
70 Datos Estructura, contenido
80 Funcin Lgica, punteros, bucles, recursin,
computacin, defectos de la funcin
90 Sistema Configuracin, temporizacin y memoria
100 Entorno Diseo, compilacin, pruebas y otros
problemas que soporta el sistema
El primer paso para gestionar los defectos es entenderlos. Para hacer eso, debes
reunir los datos de defectos. Entonces, podr entender estos errores y
comprender como evitarlos. Puedes tambin comprender como encontrarlos
mejor, corregirlos o prevenir el defecto que todava introduces.
Para reunir datos de defectos de tus programas, haz lo siguiente:

1. Registra cada defecto que encuentres en un programa.
2. Registra la informacin suficiente sobre cada defecto para que puedas
entenderlo
3. Analiza estos datos para ver qu tipos de defectos causan los mayores
problemas.

Los defectos que introduces y encuentras en tus propios programas, son
solamente parte de la historia. Algn da, necesitaras aprender sobre los defectos
que otras personas encuentran en tus programas. Puesto que estos defectos se
escaparan a todos los esfuerzos de deteccin y prevencin de defectos, sern ms
importantes para entender y tratar debilidades de tus procesos personales. Estos
defectos se denominan escapes, porque han escapado a todos tus esfuerzos de
eliminacin de defectos. Conforme mejore tu proceso personal, los defectos que
se escapan sern la ultima fuente principal de datos para tu mejora personal.
Muchos usuarios suelen referirse a los defectos como bugs. Esto parece
trivializar y restar importancia al problema. Pero lo cierto es que un
defecto puede llegar a ser una autentica bomba de relojera. Existen
registros histricos donde un defecto aparentemente trivial, caus
problemas graves (ej: un desbordamiento de buffer caus prdidas de
datos en el sistema de control de ferrocarril, lo que oblig a mantener
parado trenes de millas durante varias horas, hasta que se introdujeron
los datos.)
Quien ms capacitado esta para corregir los defectos de un programa , es
aquella o aquellas personas que lo desarrollaron.

Hay que remarcar siempre la importancia de eliminar todos los defectos
de un producto.
Sirve para reunir datos anteriormente citados. Este cuaderno facilitara el
anlisis de defectos para corregirlos.
Cuando se encuentre un defecto por primera vez, hay que anotar su
nmero, pero el resto de datos deben esperar a tenerlo corregido. Nunca
hay que agrupar defectos idnticos en una sola lnea; siempre hay que
registrarlos en distintas lneas. As mismo hay que registrar las fechas en las
que se localiz cada efecto. (si hay varios defectos con la misma fecha,
puede anotarse en el primero y el resto dejarlo en blanco).

Una vez un defecto est corregido, hay que anotar su tipo (usar el mejor
criterio posible). Tambin se debe anotar la fase del proyecto en la que se
introdujo el defecto (en programas grandes esto puede ser algo ms
costoso). De la misma forma, hay que anotar la fase en la que se elimin.
Otro punto que hay que anotar es el tiempo transcurrido desde la
localizacin del defecto hasta su eliminacin. Un error en la compilacin es
rpido de resolver, pero uno en las pruebas lleva ms tiempo.
Existen defectos que se corrigen al corregir otros defectos (valga la
redundancia). Cada registro de defecto debe ir acompaado de una breve
descripcin que sea clara.

Estos son algunos de los objetivos de usar el cuaderno:

Mejorar la programacin: entender los defectos es algo importante para
aprender a gestionarlos y mejorar as la forma de programar.

Reducir su aparicin: aprender a gestionar defectos implica reducir su
aparicin en los programas.

Ahorrar tiempo: la sangre llama a la sangre. Los errores tienden a provocar
ms errores (un error de diseo causar uno o ms errores en
implementacin). Eliminarlos a tiempo implicar no tener que corregir los
nuevos.

Ahorrar dinero: encontrar y corregir un defecto es, por lo general, caro.
Minimizar los defectos supone un ahorro econmico
PROPOSITO Utiliza la tabla para mantener los datos de cada defecto que encuentres y
corrijas.
Utiliza estos datos para completar el Resumen del plan de proyecto.
METODO Anota todas las revisiones, compilaciones y pruebas de defectos en este
cuaderno.
Anota cada defecto de forma separada y completa, si necesitas espacio
adicional, utiliza otra copia de la tabla.
CABECERA Introduce los siguientes datos:
Tu nombre
Fecha actual
Nombre del profesor
Numero de programa
FECHA Anota la fecha en que se encontr el defecto
NUMERO Nmero de cada defecto
Para cada programa utiliza una numeracin, secuencia, comenzando por el 1
(001, etc.)
TIPO Anota el tipo de defecto, tambin resumida en la parte superior izquierda
del cuaderno de defectos.
Utiliza tu criterio para seleccionar que tipo aplicar.
INTRODUCIDO Anota la fase en la que se introdujo el defecto.
Generalmente, esta sera la fase durante la cual encontraste y corregiste
el defecto.
Utiliza tu criterio
ELIMINADO Anota la fecha en que se elimino el defecto.
Generalmente, esta sera la fase durante la cual encontraste y corregiste
el defecto.
TIEMPO DE
CORRECCIN
Estima o mide el tiempo necesario para encontrar y corregir defectos.
Puede utilizar un cronometro si lo desea.
DEFECTO
CORREGIDO
Puede ignorar la casilla por primera vez.
Si introduces este defecto mientras estas arreglando otro, anota el
nmero de defectos incorrectamente corregido.
Si no puedes identificar el nmero de defecto, anota una X en la casilla
de Defecto corregido.
DESCRIPCIN Escribe una breve descripcin del defecto.
Haz la descripcin lo suficientemente clara para que recuerdes
posteriormente, el error que causo el defecto y porque lo hiciste.
Las anotaciones en el cuaderno deben basarse slo en las correcciones que se
hacen (un solo despiste, p. eje. Un punto y coma) puede provocar varios
errores, pero la correccin es slo una.
Por otro lado, el diseo puede sufrir cambios durante el desarrollo debido a
la aparicin de ideas mejores u optimizaciones (o, simplemente, cambios en
el parecer del cliente que tambin ocurre con ms frecuencia de la deseada).
Esto no se consideran defectos (otra cosa sera cometer un error en los
requisitos, con lo que sera un defecto de requisitos).
Recurdese que se considera defecto aquellos que aparecen tras la
codificacin (si se nota algo mientras se est codificando y se corrige antes de
terminar, no se considera defecto).
Conviene contabilizar los defectos cuando se termine cada fase (diseo,
codificacin). Sin embargo, dentro de una misma fase (por ejemplo,
codificacin), si se hace un mdulo y luego un segundo, y a mitad del
segundo mdulo se descubre un defecto en el primero, s es un defecto.
Para aprender a reunir datos de defectos, conviene comenzar por
contabilizar slo los de compilacin y pruebas hasta que se tome soltura.
Aunque no hay forma de acabar con la introduccin de defectos, es posible
encontrar y eliminar casi todos los defectos al principio del desarrollo.
Siempre estn implicados estos mtodos:
Identificar los sntomas del defecto.
Deducir de estos sntomas la localizacin del defecto.
Entender lo que es errneo en el programa.
Decidir cmo corregir el defecto
Hacer la correccin.
Verificar que el arreglo ha resuelto el programa.

Con el compilador.
Pero no detecta los errores semnticos.
Mediante pruebas.
Las pruebas de unidad encuentra sobre el 50% de los defectos lgicos.
Las de sistema entre un 30% y un 40%. Pero no podemos probar todos los casos.
La ms comn de todas: Que los detecten los usuarios.
Durante un ao, IBM gast 250 millones de dlares en reparar y reinstalar
correcciones de 13,000 errores encontrados por los usuarios: 20,000 dlares por
defecto.
La calidad de las pruebas por el grado en que estos escenarios cubren todas las
funciones importantes del programa.

Aunque las pruebas pueden utilizarse para comprobar casi cualquier funcin
del programa, tiene varias desventajas. Primero como con los compiladores, las
pruebas solo suponen el primer paso de correccin de defectos. Otro problema,
es que cada prueba verifica solamente un conjunto de condiciones del
programa.

Segn Humphrey, la forma ms rpida y eficiente es revisando personalmente
el cdigo fuente.
As se ven los problemas, no los sntomas.
Sin embargo, con experiencia encontrar una media del 75% al 80% de los
defectos.
Se necesitan, al menos, 30 minutos para revisar 100 LOC ( lines of code ).

Otra forma de encontrar los defectos es la mas comn de todas, consiste en
entregar programas defectuosos y esperar que los usuarios identifique e
informen de los defectos. Esta es la estrategia ms costosa.
Por ltimo, indicar que la forma ms efectiva de encontrar y corregir defectos
es revisar personalmente el cdigo fuente del programa. Aunque esto puede
parecer una forma difcil de limpiar un programa defectuoso. Se trata de la
forma ms rpida y eficiente.

La causa de que la revisin de cdigo sea tan eficiente, es porque cuando haces
revisiones, ves los problemas no los sntomas. Es decir, mientras revisas el
cdigo, piensas sobre lo que el programa debe hacer.

Las revisiones tambin tienen desventajas. Las dos desventajas principales son
que las revisiones de cdigo consumen tiempo y es difcil hacerlas
correctamente.


El costo medio de encontrar y corregir un defecto crece unas 10 veces en cada
paso del proceso de desarrollo.
Aunque el tiempo de corregir los defectos vara enormemente, estos valores
medios muestran, a pesar de todo, los tipos de defectos.
El tiempo de encontrar los defectos en las pruebas de integracin, de
componentes o del sistema, tambin variar con el tamao y la complejidad del
sistema.

Una vez que los productos son entregados a los clientes, el coste de encontrar y
corregir los defectos puede ser mucho mayor, dependiendo de la clase de
productos y de los tipos y nmero de clientes.

Adems del coste, una razn de igual importancia para encontrar los defectos al
principio es que la compilacin, depuracin y las pruebas tienen una efectividad
reducida.

As, si se requiere producir un producto de alta calidad, tendrs que producir un
programa sin defectos al principio o esperar dedicarle mucho tiempo en las
pruebas.
Un estudio marca que:

Durante la revisin, se encuentra 1 error cada 1 2 minutos.
Durante las pruebas de unidad, 1 error cada 10 20 minutos.
En las pruebas de integracin, 10 a 40 horas.

Datos reales:
Una pequea empresa:
Con PSP, las pruebas de integracin duraron 2 semanas.
Con el mdulo desarrollado sin PSP, las pruebas duraron varias semanas, con
300 horas por defecto.
Un sistema aeroespacial necesit:
una media de 40 horas por defecto en las pruebas del sistema de navegacin
area.
En Digital Equipment Corporation,
para un sistema, el tiempo mnimo para encontrar y corregir cada defecto
informado por el cliente fue de 88 horas.
Una lista de comprobacin contiene una serie de pasos que t quieres seguir de
forma rigurosa. Cuando utilizas una lista de comprobacin desarrollada a partir
de tus propios defectos., har revisiones ms eficientes.
La lista de comprobacin no solamente ayuda a encontrar ms defectos, tambin
ayuda a encontrarlos ms rpidamente. Para construir una lista de comprobacin
para la revisin de cdigo, adptala al lenguaje que utilices, disala a partir de
tus propios defectos y ajstalas a tus habilidades y experiencias cambiantes.
Algunas orientaciones para utilizar la lista de comprobacin son: haz de las
revisiones paso a paso, completa cada programa o procedimiento antes de iniciar
el siguiente, examina cada apartado de la lista de comprobacin cuando lo
completes. Cuando encuentres defectos, anota el numero encontrado en cada
apartado de la lista de comprobacin. Cuando lo hagas, completa las columnas
hasta la fecha y % hasta la fecha. Despus de acabar cada programa, revisa los
datos y la lista de comprobacin para ver cmo la puedes mejorar.

Las listas de comprobacin tambin pueden ser una fuente de ideas. Cuando
sigues una lista de comprobacin personal. Sabes cmo revisar tu cdigo. Si
utilizas la lista correctamente, tambin sabes cuantos defectos encuentras en cada
paso de dicha lista.

La clave para realizar una revisin de cdigo efectiva es tener un
procedimiento de revisin eficiente.
Una lista de comprobacin contiene una serie de pasos de procedimiento que
quieres seguir de forma precisa.
Un ejemplo de lista de comprobacin completa y compleja es la que realiza la
NASA en la cuenta atrs de un lanzamiento, que dura varios das.
La lista de comprobacin encapsula la experiencia personal.
Utilizndola con regularidad y mejorndola, mejorar la deteccin de los
defectos de los programas.
El principal peligro es que generalmente encuentra lo que busca.
Si solamente hace las pruebas de la lista de comprobacin, solamente
encontrar lo que est en dicha lista.
Haga al menos una revisin general del programa para buscar lo inesperado,
desde la perspectiva del sistema o del usuario.


CMO EVALUAR TU DISTRIBUCIN DEL TIEMPO

Ahora que puedes saber cmo utilizas tu tiempo, pregntate a ti mismo si
ests utilizando el tiempo de la forma que quieres.
Decide qu actividades son ms importantes y considera si ests dedicndole
el tiempo suficiente. a algunas tareas, le dedicas ms tiempo que a otras que
son ms importantes? Ests dejando suficiente tiempo para leer libros de
texto?haces el trabajo? Y cules son tus compromisos
personales?Comienzas los ejercicios a tiempo para acabarlos, o los terminas
en el ltimo momento?

Esta es una decisin muy personal que debes equilibrar entre el trabajo
acadmico, las tareas, el descanso y la vida social. Algunos de estos
componentes son cuestiones personales que implican complejas elecciones,
particularmente si tienes un trabajo y responsabilidades familiares.
Despus de haber revisado la estimacin de tiempo, puedes necesitar aumentar
la cantidad total de tiempo. Cmo puedes hacer esto? Tienes varias opciones.
Primero, si tu agenda no esta muy ocupada, sers capaz de encontrar un poco
de tiempo extra, pero desafortunadamente, pocas personas estn bendecidas
con el tiempo libre. Es ms probable que ests sper comprometido. En este
caso, haz un amplio estudio de todos tus compromisos. Despus revisa el
tiempo que utilizas tanto en las actividades de ocio.
Para gestionar bien tu tiempo analiza tus propios datos histricos de tiempos.
Establece una estimacin para utilizar el tiempo y registra tu tiempo real frente
al estimado. Para hacer una estimacin de tiempo decide como quieres utilizar
el tiempo. Haz una programacin que refleje tu eleccin y que muestre los
tiempos cada da; puedes necesitar diferentes estimaciones para distintas
semanas.

Las reglas bsicas para estimar el tiempo pueden ser tiles:

Identifica tus compromisos fijos y variables
Divide tu tiempo variable en tareas que son exigidas y aquellas que son
discrecionales
Analiza como divides ahora t tiempo en estas categoras. Recuerda que tu
tiempo total es fijo: si necesitas ms tiempo para algunas actividades debes
dedicar menos tiempo a otras.
Finalmente, revisa el rendimiento frente al tiempo estimado:
contina reuniendo datos de tiempos.
Revisa el tiempo estimado frente a tu experiencia real. Revisa la estimacin
basndote en tus necesidades y experiencias.
Haz los cambios de forma gradual cuando cambies tu estimacin de tiempo.
Guarda las versiones anteriores.
Conforme los programas son ms grandes, es ms costoso encontrar y
corregir los defectos. El proceso de eliminacin de defectos es tambin menos
efectivo. La estrategia para producir grandes programas de gran calidad es,
en primer lugar, eliminar todos los defectos de los mdulos que forman estos
grandes programas. La eliminacin de defectos es un proceso filtrado: ve
cada fase de eliminacin de defectos como un filtro. Cuantos ms defectos se
pongan en el filtro ms se encontrarn. Tambin, cuantos ms defectos se
pongan en el filtro, ms se pasarn por alto. El rendimiento de muchas fases
de pruebas es menor del 50%. As, para obtener un producto de alta calidad
al final de una prueba, debes poner un producto de alta calidad al comienzo
de la prueba.

Un trabajo concienzudo en cada paso de tu proceso ser rentable y ahorrar
tiempo. Si haces un programa mal, se encontrarn muchos defectos en la
compilacin y en cada subsiguiente fase de pruebas. El rendimiento mide la
calidad de la eliminacin de defectos. El rendimiento del proceso se refiere a la
tasa de defectos en el producto que son eliminados antes de la primera
compilacin. El rendimiento puede medir tambin la tase de defectos en un
producto que son eliminados en la fase de eliminacin de defectos. Tu objetivo
sera lograr el 100% de rendimiento del proceso.

Recuerda: no sers capaz de hacer grandes programas de calidad hasta que no
puedas hacer de forma constante pequeos programas de gran calidad. Esto
supone una dedicacin constante a la calidad, disciplina personal y mucha
prctica. Para lograr la mxima calidad en un programa, haz pequeos
prototipos para probar cada suposicin antes de incorporarla al producto.
Aprende a reconocer la diferencia entre lo que crees que sabes y lo que
realmente sabes. Cada vez que hagas una suposicin, es probable que
introduzcas un defecto.
El proceso de medida del rendimiento tiene que ver con la tasa de eliminacin
de defectos antes de la primera compilacin. La medida del rendimiento, sin
embargo, puede ser aplicada a cualquier paso de la eliminacin de defectos.
As, el rendimiento de cada fase puede calcularse de la siguiente forma:
Rendimiento de la Fase: 100* (nmero defectos eliminados durante la
fase)/(nmero de defectos en el producto al inicio de la fase).

Desafortunadamente, los datos sobre los rendimientos de compilacin y
pruebas no son tranquilizadores, como se muestra en la siguiente tabla las
revisiones de cdigo e inspecciones tienen mejores rendimientos, mientras la
compilacin, pruebas de unidad y otras formas de pruebas son menos efectivas
(Humphrey 891). Estas cifras estn basadas en datos limitados y puede que no
se apliquen a tu situacin particular, pero estos son todos los datos que
tenemos. La mejor respuesta para ti, naturalmente, sera reunir los datos los
datos de rendimiento de tus propios mtodos de eliminacin de defectos y
sacar tus propias conclusiones. Es interesante observar que el mtodo de mayor
rendimiento de la tabla es para los ingenieros que hacen una revisin de cdigo.
El siguiente mayor rendimiento es para las inspecciones, donde varios
ingenieros revisan entre si el diseo y el cdigo.
Mtodo Rendimiento aproximado (%)
Revisin del cdigo 70-80
Inspeccin del cdigo 50-70
Compilacin 50
Prueba de unidad 40-50
Prueba de integracin 45
Prueba de requisitos 45
Prueba de algoritmo 8
Los mtodos que tienen los mayores rendimientos son manuales no implican
ninguna herramienta automatizada. La razn de que sean mejores que otros
mtodos es que la mente humana es el instrumento de deteccin de defectos
ms poderosos que cualquier herramienta de software actual.

La conclusin lgica de estos datos es que, para hacer programas de alta
calidad, debes tener el menor nmero de defectos posibles al comenzar las
pruebas. Comenzar las pruebas con el menor nmero de defectos, significa salir
de la fase de compilacin con el menor nmero de defectos.

Finalmente, para salir de la fase de compilacin con el menor nmero de
defectos, debes eliminar los defectos antes de comenzar a compilar.
Naturalmente, para hacer productos de mxima calidad, deberas medir,
analizar y mejorar cada fase de eliminacin de defectos.


El logro del control de la calidad es un fin en s mismo. Se espera que se
contribuya al perfeccionamiento global de la calidad; el ingeniero que
evita los errores del diseo, el obrero de produccin que localiza los
defectos el representante de ventas presenta el producto
adecuadamente a los clientes potenciales.

Los sistemas de informacin pueden ayudar a las empresas a lograr sus
metas de calidad ayudndoles a simplificar productos o procesos, a
cumplir estndares de benchmarking (pruebas corporativas), hacer
mejoras con base en las demandas del cliente, reducir el tiempo de ciclo
y aumentar la calidad y precisin de diseo y produccin.


En los sistemas de informacin, el control de calidad incluye un
conjunto de acciones de ingeniera de software que ayudan a asegurar
que todo producto del trabajo cumpla sus metas de calidad. Los
modelos se revisan para garantizar que estn completos y que son
consistentes.

El cdigo se inspecciona con objeto de descubrir y corregir errores antes
de que comiencen las pruebas. Se aplica una serie de etapas de prueba
para detectar los errores en procesamiento lgico, manipulacin de
datos y comunicacin con la interfaz.

La combinacin de mediciones con retroalimentacin permite que el
equipo de software sintonice el proceso cuando cualquiera de estos
productos del trabajo falla en el cumplimiento de las metas de calidad.
Las actividades de control de calidad se describirn en la siguientes
unidades.
El argumento es algo parecido a esto: sabemos que la calidad es importante, pero
cuesta tiempo y dinero - demasiado tiempo y dinero- lograr el nivel de calidad en el
software que en realidad queremos.
Visto as, este argumento parece razonable. No hay duda de que la calidad tiene
un costo, pero la mala calidad tambin lo tiene -no slo para los usuarios finales
que deban vivir con el software defectuoso, sino tambin para la organizacin
del software que lo elabor y que debe darle mantenimiento-.

La pregunta real es sta: por cul costo debemos preocupamos? Para responder a esta
pregunta debe entenderse tanto el costo de tener calidad como el del software de
mala calidad.

El costo de la calidad incluye todos los costos en los que se incurre al buscar la calidad o
al realizar actividades relacionadas con ella y los costos posteriores de la falta
de calidad. Para entender estos costos, una organizacin debe contar con
unidades de medicin que provean el fundamento del costo actual de la
calidad, que identifiquen las oportunidades para reducir dichos costos y que
den una base normalizada de comparacin. El costo de la calidad puede
dividirse en los costos que estn asociados con la prevencin, la evaluacin y la
falla.
Los costos de prevencin incluyen lo siguiente:
1)el costo de las actividades de administracin requeridas para planear y coordinar
todas las actividades de control y aseguramiento de la calidad,
2) el costo de las actividades tcnicas agregadas para desarrollar modelos
completos de los requerimientos y del diseo,
3) los costos de planear las pruebas y
4) el costo de toda la capacitacin asociada con estas actividades.
Los costos de evaluacin incluyen las actividades de investigacin de la condicin del
producto la "primera vez" que pasa por cada proceso. Algunos ejemplos de costos
de evaluacin incluyen los siguientes:
El costo de efectuar revisiones tcnicas de los productos del trabajo de la
ingeniera de software.
El costo de recabar datos y unidades de medida para la evaluacin.
El costo de hacer las pruebas y depurar.
Los costos de falla son aquellos que se eliminaran si no hubiera errores antes o despus de
enviar el producto a los consumidores. Los costos de falla se subdividen en
internos y externos.
Se incurre en costos internos detalla cuando se detecta un error en un producto antes del
envo.

Los costos internos de falla incluyen los siguientes:

El costo requerido por efectuar repeticiones (reparaciones para corregir un
error).
El costo en el que se incurre cuando una repeticin genera inadvertidamente
efectos colaterales que deban mitigarse.
Los costos asociados con la coleccin de las unidades de medida de la calidad
que permitan que una organizacin evale los modos de la falla.

Los costos externos de falla se asocian con defectos encontrados despus de que el
producto se envi a los consumidores. Algunos ejemplos de costos externos de falla son
los de solucin de quejas, devolucin y sustitucin del producto, ayuda en lnea y
trabajo asociado con la garanta.


La mala reputacin y la prdida resultante de negocios es otro costo externo de
falla que resulta difcil de cuantificar y que, sin embargo, es real. Cuando se
produce software de mala calidad, suceden cosas malas.
En lo que constituye una acusacin contra los desarrolladores de software que
se rehsan a considerar los costos de falla externos, Cem Kaner [Kan95] afirma
lo siguiente:
Muchos de los costos de falla externos, tales como los fondos de
comercializacin, son difciles de cuantificar, por lo que muchas compaas
los ignoran cuando calculan sus relaciones costo-beneficio.
Otros costos externos de falla pueden reducirse (al dar un apoyo barato
debido a la mala calidad despus de hacer la venta, o al cobrar el apoyo a los
consumidores) sin que se incremente la satisfaccin del cliente. Al ignorar los
costos que los malos productos generan a nuestros compradores, los
ingenieros de la calidad estimulan una toma de decisiones que los hace
vctimas en lugar de satisfacerlos.

Como es de esperar, los costos relacionados con la deteccin y la correccin de
errores o defectos se incrementan en forma abrupta cuando se pasa de la
prevencin a la deteccin, a la falla interna y a la externa. La figura siguiente,
basada en datos obtenidos por Boehm y Basili [BoeO1b] Y elaborada por Cigital,
Inc. [Cig07J, ilustra este fenmeno.
Costo relativo de corregir errores y defectos (Cifras en dlares estadounidense)
Fuente: Adoptado de [BoeO1b]
El costo promedio de la industria por corregir un defecto durante la
generacin de cdigo es aproximadamente de US$977 por error. El
promedio del costo en el que incurre la industria por corregir el mismo error
si se descubre durante las pruebas del sistema es de US$7,136. Cigital, lnc.
[Cig07] tome en cuenta que una aplicacin grande contiene 200 errores
introducidos durante la codificacin.

De acuerdo con datos promedio, el costo de encontrar y corregir defectos
durante la fase de codificacin es de US$977 por defecto. Entonces, el costo
total por corregir los 200 errores "crticos" durante esta fase es de (200 x
US$977) US$195 400, aproximadamente.

Los datos promedio de la industria indican que el costo de encontrar y corregir
defectos durante la fase de pruebas del sistema es de US$7 136por cada uno. En
este caso, si se supone que en dicha fase se descubren aproximadamente 50
defectos crticos (tan slo 25%de los descubiertos por Cigital en la fase de
codificacin), el costo de encontrarlos y corregirlos (50 x US$7 136)sera
aproximadamente de US$356 800. Esto tambin habra resultado en 150 errores
crticos no detectados ni corregidos.

El costo de encontrar y corregir estos 150defectos en la fase de mantenimiento
(150 x US$14 102)habra sido de US$2 115 300. Entonces, el costo total de
encontrar y corregir los 200 defectos (US$2 I 15300 + US$356 800) despus de la
fase de codificacin habra sido de US$2 472 100.

Aun si la organizacin de software tuviera costos que fueran la mitad del
promedio de la industria (la mayor parte de compaas no tiene idea de cules
son sus costos), los ahorros asociados con el control de calidad temprano y las
actividades para su aseguramiento (efectuadas durante el anlisis de los
requerimientos y el diseo) seran notables.

You might also like