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.