2.1. Calidad en los sistemas de información. 2.2. Defectos y errores de calidad en los sistemas de información. 2.2.1. El cuaderno de registro de defectos.

Presentación del tema: "2.1. Calidad en los sistemas de información. 2.2. Defectos y errores de calidad en los sistemas de información. 2.2.1. El cuaderno de registro de defectos."— Transcripción de la presentación:

1 2.1. Calidad en los sistemas de información. 2.2. Defectos y errores de calidad en los sistemas de información. 2.2.1. El cuaderno de registro de defectos. 2.2.2. Contabilización 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 comprobación. 2.4. Gestión del tiempo para el desarrollo de sistemas de información. 2.5. Obtener calidad en los sistemas de información (métodos, métricas, metodologías, estándares). 2.6. Controlar la calidad del sistema de información. 2.7. Costo de calidad de los sistemas de información. 2.7.1. Cálculo del costo de la calidad

2 Presentaremos tres definiciones relacionadas con calidad en sistemas y sobre ella basaremos la definición de calidad de los sistemas de información. W. E. Perry: Calidad se define en el diccionario como un atributo o característica 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 cuestión. Calidad viene a ser una lista que expresa una serie de características y atributos. Calidad en el ambiente de procesamiento de datos debe ser definida por la organización. La definición de calidad hecha por una organización puede ser diferente a la hecha por otra. Para una organización, 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 mayoría de las instalaciones de procesamiento de datos apenas han comenzado a definir lo que es calidad en las aplicaciones computarizadas. La definición de Perry nos dice, principalmente, que la calidad no debe ser concebida en términos generales o abstractos y que cada organización debe identificar lo que para ella significa un sistema de calidad, con el fin de establecer los patrones y las vías necesarias para lograrla.

3 IEEE Computer Society – Estándar P730: Software Quality Assurance (SQA) es un patrón planeado y sistémico de todas las acciones necesarias, para proveer suficiente confianza de que el software se construye conforme a los requerimientos técnicos preestablecidos. A pesar de la definición de IEEE – Computer Society está orientada hacia la función 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 participación de todos, no es algo que atañe exclusivamente a un grupo de SQA, incluye > La calidad de un sistema es fruto de una cuidadosa planificación; no es algo que se logra de manera fortuita o improvisada. La noción de calidad es relativa a especificaciones técnicas preestablecidas. El propósito 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.

4 G. J. Myers: La confiabilidad del software es la probabilidad de que este se ejecute por un cierto período de tiempo sin fallas, ponderada por el costo que representa para el usuario cada falla encontrada. La definición 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

5 DEFECTOS El termino defecto se refiere a algo que está equivocado en un programa, tal como un error sintáctico, una falta tipográfica, un error de puntuación, o una sentencia incorrecta del programa. Los defectos pueden estar en los programas, en los diseños o incluso en los requisitos. Las especificaciones o en otra documentación. 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.

6 Es importante separar la cuestión de encontrar o identificar los defectos de la determinación de sus causas. La simple contabilización y registros de los defectos en los productos software no es la especificación de las causas ni la asignación de culpas. Los defectos cometidos. Sin embargo, tienen sus causas. Puede haber cometido un error al escribir el nombre de un parámetro, omitido un signo de puntuación 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.

7 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 introducción de defectos. Esto significa que para reducir el número 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 eliminación de defectos es, por lo tanto, un proceso más sencillo que la prevención de defectos. La prevención de defectos es un aspecto importante y prioritario que requiere un estudio comprensivo de todo el proceso de desarrollo del software.

8 Los defectos deberían ser importantes para cada ingeniero del software no solo porque afectan a los usuarios, sino también porque más 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 difícil de predecir, los defectos son, a menudo, la causa principal de los problemas de costes y programaciones.

9 Número del tipo Nombre del tipoDescripción 10DocumentaciónComentarios y mensajes 20Sintaxis Ortografía, puntuación, erratas, formato de las instrucciones 30Construir, paquetes Llamadas a procedimientos y referencias, E/S, formato de usuario 40Asignación Declaración, nombres duplicados, ámbito, limites 50interfaz Llamadas a procedimientos y referencias, E/S, formatos de usuario 60ChequeoMensajes de error, chequeos inadecuados 70DatosEstructura, contenido 80Función Lógica, punteros, bucles, recursión, computación, defectos de la función 90SistemaConfiguración, temporización y memoria 100EntornoDiseño, compilación, pruebas y otros problemas que soporta el sistema

10 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 también comprender como encontrarlos mejor, corregirlos o prevenir el defecto que todavía introduces. Para reunir datos de defectos de tus programas, haz lo siguiente: 1. Registra cada defecto que encuentres en un programa. 2. Registra la información 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. Algún día, necesitaras aprender sobre los defectos que otras personas encuentran en tus programas. Puesto que estos defectos se escaparan a todos los esfuerzos de detección y prevención de defectos, serán más importantes para entender y tratar debilidades de tus procesos personales. Estos defectos se denominan escapes, porque han escapado a todos tus esfuerzos de eliminación de defectos. Conforme mejore tu proceso personal, los defectos que se escapan serán la ultima fuente principal de datos para tu mejora personal.

11 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 relojería. Existen registros históricos donde un defecto aparentemente trivial, causó problemas graves (ej: un desbordamiento de buffer causó pérdidas 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 más 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.

12 Sirve para reunir datos anteriormente citados. Este cuaderno facilitara el análisis de defectos para corregirlos. Cuando se encuentre un defecto por primera vez, hay que anotar su número, pero el resto de datos deben esperar a tenerlo corregido. Nunca hay que agrupar defectos idénticos en una sola línea; siempre hay que registrarlos en distintas líneas. 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). También se debe anotar la fase del proyecto en la que se introdujo el defecto (en programas grandes esto puede ser algo más 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 localización del defecto hasta su eliminación. Un error en la compilación es rápido de resolver, pero uno en las pruebas lleva más tiempo. Existen defectos que se corrigen al corregir otros defectos (valga la redundancia). Cada registro de defecto debe ir acompañado de una breve descripción que sea clara.

13 Estos son algunos de los objetivos de usar el cuaderno: Mejorar la programación: entender los defectos es algo importante para aprender a gestionarlos y mejorar así la forma de programar. Reducir su aparición: aprender a gestionar defectos implica reducir su aparición en los programas. Ahorrar tiempo: la sangre llama a la sangre. Los errores tienden a provocar más errores (un error de diseño causará uno o más errores en implementación). 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 económico

14

15 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 FECHAAnota la fecha en que se encontró el defecto NUMERO Número de cada defecto Para cada programa utiliza una numeración, secuencia, comenzando por el 1 (001, etc.) TIPOAnota el tipo de defecto, también resumida en la parte superior izquierda del cuaderno de defectos. Utiliza tu criterio para seleccionar que tipo aplicar.

16 INTRODUCIDO Anota la fase en la que se introdujo el defecto. Generalmente, esta sería 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 sería la fase durante la cual encontraste y corregiste el defecto. TIEMPO DE CORRECCIÓN 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 número de defectos incorrectamente corregido. Si no puedes identificar el número de defecto, anota una X en la casilla de Defecto corregido. DESCRIPCIÓNEscribe una breve descripción del defecto. Haz la descripción lo suficientemente clara para que recuerdes posteriormente, el error que causo el defecto y porque lo hiciste.

17

18 Las anotaciones en el cuaderno deben basarse sólo en las correcciones que se hacen (un solo despiste, p. eje. Un punto y coma) puede provocar varios errores, pero la corrección es sólo una. Por otro lado, el diseño puede sufrir cambios durante el desarrollo debido a la aparición de ideas mejores u optimizaciones (o, simplemente, cambios en el parecer del cliente que también ocurre con más frecuencia de la deseada). Esto no se consideran defectos (otra cosa sería cometer un error en los requisitos, con lo que sería un defecto de requisitos). Recuérdese que se considera defecto aquellos que aparecen tras la codificación (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 (diseño, codificación…). Sin embargo, dentro de una misma fase (por ejemplo, codificación), si se hace un módulo y luego un segundo, y a mitad del segundo módulo se descubre un defecto en el primero, sí es un defecto. Para aprender a reunir datos de defectos, conviene comenzar por contabilizar sólo los de compilación y pruebas hasta que se tome soltura.

19 Aunque no hay forma de acabar con la introducción de defectos, es posible encontrar y eliminar casi todos los defectos al principio del desarrollo. Siempre están implicados estos métodos: Identificar los síntomas del defecto. Deducir de estos síntomas la localización del defecto. Entender lo que es erróneo en el programa. Decidir cómo corregir el defecto Hacer la corrección. Verificar que el arreglo ha resuelto el programa. Con el compilador. Pero no detecta los errores semánticos. Mediante pruebas. Las pruebas de unidad encuentra sobre el 50% de los defectos lógicos. Las de sistema entre un 30% y un 40%. Pero no podemos probar todos los casos. La más común de todas: Que los detecten los usuarios. Durante un año, IBM gastó 250 millones de dólares en reparar y reinstalar correcciones de 13,000 errores encontrados por los usuarios: 20,000 dólares por defecto.

20 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 función del programa, tiene varias desventajas. Primero como con los compiladores, las pruebas solo suponen el primer paso de corrección de defectos. Otro problema, es que cada prueba verifica solamente un conjunto de condiciones del programa. Según Humphrey, la forma más rápida y eficiente es revisando personalmente el código fuente. Así se ven los problemas, no los síntomas. 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 común de todas, consiste en entregar programas defectuosos y esperar que los usuarios identifique e informen de los defectos. Esta es la estrategia más costosa.

21 Por último, indicar que la forma más efectiva de encontrar y corregir defectos es revisar personalmente el código fuente del programa. Aunque esto puede parecer una forma difícil de limpiar un programa defectuoso. Se trata de la forma más rápida y eficiente. La causa de que la revisión de código sea tan eficiente, es porque cuando haces revisiones, ves los problemas no los síntomas. Es decir, mientras revisas el código, piensas sobre lo que el programa debe hacer. Las revisiones también tienen desventajas. Las dos desventajas principales son que las revisiones de código consumen tiempo y es difícil hacerlas correctamente.

22 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 varía enormemente, estos valores medios muestran, a pesar de todo, los tipos de defectos. El tiempo de encontrar los defectos en las pruebas de integración, de componentes o del sistema, también variará con el tamaño 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 número de clientes. Además del coste, una razón de igual importancia para encontrar los defectos al principio es que la compilación, depuración y las pruebas tienen una efectividad reducida. Así, si se requiere producir un producto de alta calidad, tendrás que producir un programa sin defectos al principio o esperar dedicarle mucho tiempo en las pruebas.

23 Un estudio marca que: Durante la revisión, se encuentra 1 error cada 1 ó 2 minutos. Durante las pruebas de unidad, 1 error cada 10 ó 20 minutos. En las pruebas de integración, 10 a 40 horas. Datos reales: Una pequeña empresa: Con PSP, las pruebas de integración duraron 2 semanas. Con el módulo 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 navegación aérea. En Digital Equipment Corporation, para un sistema, el tiempo mínimo para encontrar y corregir cada defecto informado por el cliente fue de 88 horas.

24 Una lista de comprobación contiene una serie de pasos que tú quieres seguir de forma rigurosa. Cuando utilizas una lista de comprobación desarrollada a partir de tus propios defectos., hará revisiones más eficientes. La lista de comprobación no solamente ayuda a encontrar más defectos, también ayuda a encontrarlos más rápidamente. Para construir una lista de comprobación para la revisión de código, adáptala al lenguaje que utilices, diséñala a partir de tus propios defectos y ajústalas a tus habilidades y experiencias cambiantes. Algunas orientaciones para utilizar la lista de comprobación 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 comprobación cuando lo completes. Cuando encuentres defectos, anota el numero encontrado en cada apartado de la lista de comprobación. Cuando lo hagas, completa las columnas hasta la fecha y % hasta la fecha. Después de acabar cada programa, revisa los datos y la lista de comprobación para ver cómo la puedes mejorar. Las listas de comprobación también pueden ser una fuente de ideas. Cuando sigues una lista de comprobación personal. Sabes cómo revisar tu código. Si utilizas la lista correctamente, también sabes cuantos defectos encuentras en cada paso de dicha lista.

25 La clave para realizar una revisión de código efectiva es tener un procedimiento de revisión eficiente. Una lista de comprobación contiene una serie de pasos de procedimiento que quieres seguir de forma precisa. Un ejemplo de lista de comprobación completa y compleja es la que realiza la NASA en la cuenta atrás de un lanzamiento, que dura varios días. La lista de comprobación encapsula la experiencia personal. Utilizándola con regularidad y mejorándola, mejorará la detección 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 comprobación, solamente encontrará lo que está en dicha lista. Haga al menos una revisión general del programa para buscar lo inesperado, desde la perspectiva del sistema o del usuario.

26

27

28 CÓMO EVALUAR TU DISTRIBUCIÓN DEL TIEMPO Ahora que puedes saber cómo utilizas tu tiempo, pregúntate a ti mismo si estás utilizando el tiempo de la forma que quieres. Decide qué actividades son más importantes y considera si estás dedicándole el tiempo suficiente. ¿a algunas tareas, le dedicas más tiempo que a otras que son más importantes? ¿Estás dejando suficiente tiempo para leer libros de texto?¿haces el trabajo? Y ¿cuáles son tus compromisos personales?¿Comienzas los ejercicios a tiempo para acabarlos, o los terminas en el último momento? Esta es una decisión muy personal que debes equilibrar entre el trabajo académico, 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.

29 Después de haber revisado la estimación de tiempo, puedes necesitar aumentar la cantidad total de tiempo. ¿Cómo puedes hacer esto? Tienes varias opciones. Primero, si tu agenda no esta muy ocupada, serás capaz de encontrar un poco de tiempo extra, pero desafortunadamente, pocas personas están bendecidas con el tiempo libre. Es más probable que estés súper comprometido. En este caso, haz un amplio estudio de todos tus compromisos. Después revisa el tiempo que utilizas tanto en las actividades de ocio. Para gestionar bien tu tiempo analiza tus propios datos históricos de tiempos. Establece una estimación para utilizar el tiempo y registra tu tiempo real frente al estimado. Para hacer una estimación de tiempo decide como quieres utilizar el tiempo. Haz una programación que refleje tu elección y que muestre los tiempos cada día; puedes necesitar diferentes estimaciones para distintas semanas.

30 Las reglas básicas 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 categorías. Recuerda que tu tiempo total es fijo: si necesitas más tiempo para algunas actividades debes dedicar menos tiempo a otras. Finalmente, revisa el rendimiento frente al tiempo estimado: continúa reuniendo datos de tiempos. Revisa el tiempo estimado frente a tu experiencia real. Revisa la estimación basándote en tus necesidades y experiencias. Haz los cambios de forma gradual cuando cambies tu estimación de tiempo. Guarda las versiones anteriores.

31 Conforme los programas son más grandes, es más costoso encontrar y corregir los defectos. El proceso de eliminación de defectos es también menos efectivo. La estrategia para producir grandes programas de gran calidad es, en primer lugar, eliminar todos los defectos de los módulos que forman estos grandes programas. La eliminación de defectos es un proceso filtrado: ve cada fase de eliminación de defectos como un filtro. Cuantos más defectos se pongan en el filtro más se encontrarán. También, cuantos más defectos se pongan en el filtro, más se pasarán 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.

32 Un trabajo concienzudo en cada paso de tu proceso será rentable y ahorrará tiempo. Si haces un programa mal, se encontrarán muchos defectos en la compilación y en cada subsiguiente fase de pruebas. El rendimiento mide la calidad de la eliminación de defectos. El rendimiento del proceso se refiere a la tasa de defectos en el producto que son eliminados antes de la primera compilación. El rendimiento puede medir también la tase de defectos en un producto que son eliminados en la fase de eliminación de defectos. Tu objetivo sería lograr el 100% de rendimiento del proceso. Recuerda: no serás capaz de hacer grandes programas de calidad hasta que no puedas hacer de forma constante pequeños programas de gran calidad. Esto supone una dedicación constante a la calidad, disciplina personal y mucha práctica. Para lograr la máxima calidad en un programa, haz pequeños prototipos para probar cada suposición 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 suposición, es probable que introduzcas un defecto.

33 El proceso de medida del rendimiento tiene que ver con la tasa de eliminación de defectos antes de la primera compilación. La medida del rendimiento, sin embargo, puede ser aplicada a cualquier paso de la eliminación de defectos. Así, el rendimiento de cada fase puede calcularse de la siguiente forma: Rendimiento de la Fase: 100* (número defectos eliminados durante la fase)/(número de defectos en el producto al inicio de la fase). Desafortunadamente, los datos sobre los rendimientos de compilación y pruebas no son tranquilizadores, como se muestra en la siguiente tabla las revisiones de código e inspecciones tienen mejores rendimientos, mientras la compilación, pruebas de unidad y otras formas de pruebas son menos efectivas (Humphrey 891). Estas cifras están basadas en datos limitados y puede que no se apliquen a tu situación particular, pero estos son todos los datos que tenemos. La mejor respuesta para ti, naturalmente, sería reunir los datos los datos de rendimiento de tus propios métodos de eliminación de defectos y sacar tus propias conclusiones. Es interesante observar que el método de mayor rendimiento de la tabla es para los ingenieros que hacen una revisión de código. El siguiente mayor rendimiento es para las inspecciones, donde varios ingenieros revisan entre si el diseño y el código.

34 MétodoRendimiento aproximado (%) Revisión del código70-80 Inspección del código50-70 Compilación50 Prueba de unidad40-50 Prueba de integración45 Prueba de requisitos45 Prueba de algoritmo8

35 Los métodos que tienen los mayores rendimientos son manuales no implican ninguna herramienta automatizada. La razón de que sean mejores que otros métodos es que la mente humana es el instrumento de detección de defectos más poderosos que cualquier herramienta de software actual. La conclusión lógica de estos datos es que, para hacer programas de alta calidad, debes tener el menor número de defectos posibles al comenzar las pruebas. Comenzar las pruebas con el menor número de defectos, significa salir de la fase de compilación con el menor número de defectos. Finalmente, para salir de la fase de compilación con el menor número de defectos, debes eliminar los defectos antes de comenzar a compilar. Naturalmente, para hacer productos de máxima calidad, deberías medir, analizar y mejorar cada fase de eliminación de defectos.

36 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 diseño, el obrero de producción que localiza los defectos el representante de ventas presenta el producto adecuadamente a los clientes potenciales. Los sistemas de información pueden ayudar a las empresas a lograr sus metas de calidad ayudándoles a simplificar productos o procesos, a cumplir estándares de benchmarking (pruebas corporativas), hacer mejoras con base en las demandas del cliente, reducir el tiempo de ciclo y aumentar la calidad y precisión de diseño y producción.

37 En los sistemas de información, el control de calidad incluye un conjunto de acciones de ingeniería de software que ayudan a asegurar que todo producto del trabajo cumpla sus metas de calidad. Los modelos se revisan para garantizar que están completos y que son consistentes. El código 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 lógico, manipulación de datos y comunicación con la interfaz. La combinación de mediciones con retroalimentación 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 describirán en la siguientes unidades.

38 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 también lo tiene -no sólo para los usuarios finales que deban vivir con el software defectuoso, sino también para la organización del software que lo elaboró y que debe darle mantenimiento-. La pregunta real es ésta: ¿por cuál 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 organización debe contar con unidades de medición 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 comparación. El costo de la calidad puede dividirse en los costos que están asociados con la prevención, la evaluación y la falla.

39 Los costos de prevención incluyen lo siguiente: 1)el costo de las actividades de administración requeridas para planear y coordinar todas las actividades de control y aseguramiento de la calidad, 2) el costo de las actividades técnicas agregadas para desarrollar modelos completos de los requerimientos y del diseño, 3) los costos de planear las pruebas y 4) el costo de toda la capacitación asociada con estas actividades. Los costos de evaluación incluyen las actividades de investigación de la condición del producto la "primera vez" que pasa por cada proceso. Algunos ejemplos de costos de evaluación incluyen los siguientes: El costo de efectuar revisiones técnicas de los productos del trabajo de la ingeniería de software. El costo de recabar datos y unidades de medida para la evaluación. El costo de hacer las pruebas y depurar. Los costos de falla son aquellos que se eliminarían si no hubiera errores antes o después 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 envío.

40 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 repetición genera inadvertidamente efectos colaterales que deban mitigarse. Los costos asociados con la colección de las unidades de medida de la calidad que permitan que una organización evalúe los modos de la falla. Los costos externos de falla se asocian con defectos encontrados después de que el producto se envió a los consumidores. Algunos ejemplos de costos externos de falla son los de solución de quejas, devolución y sustitución del producto, ayuda en línea y trabajo asociado con la garantía.

41 La mala reputación y la pérdida resultante de negocios es otro costo externo de falla que resulta difícil de cuantificar y que, sin embargo, es real. Cuando se produce software de mala calidad, suceden cosas malas. En lo que constituye una acusación contra los desarrolladores de software que se rehúsan 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 comercialización, son difíciles de cuantificar, por lo que muchas compañías 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 después de hacer la venta, o al cobrar el apoyo a los consumidores) sin que se incremente la satisfacción 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 víctimas en lugar de satisfacerlos.

42 Como es de esperar, los costos relacionados con la detección y la corrección de errores o defectos se incrementan en forma abrupta cuando se pasa de la prevención a la detección, 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 fenómeno. Costo relativo de corregir errores y defectos (Cifras en dólares estadounidense) Fuente: Adoptado de [BoeO1b]

43 El costo promedio de la industria por corregir un defecto durante la generación de código 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 aplicación grande contiene 200 errores introducidos durante la codificación. De acuerdo con datos promedio, el costo de encontrar y corregir defectos durante la fase de codificación es de US$977 por defecto. Entonces, el costo total por corregir los 200 errores "críticos" durante esta fase es de (200 x US$977) US$195 400, aproximadamente.

44 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 críticos (tan sólo 25%de los descubiertos por Cigital en la fase de codificación), el costo de encontrarlos y corregirlos (50 x US$7 136)sería aproximadamente de US$356 800. Esto también habría resultado en 150 errores críticos no detectados ni corregidos. El costo de encontrar y corregir estos 150defectos en la fase de mantenimiento (150 x US$14 102)habría sido de US$2 115 300. Entonces, el costo total de encontrar y corregir los 200 defectos (US$2 I 15300 + US$356 800) después de la fase de codificación habría sido de US$2 472 100. Aun si la organización de software tuviera costos que fueran la mitad del promedio de la industria (la mayor parte de compañías no tiene idea de cuáles son sus costos), los ahorros asociados con el control de calidad temprano y las actividades para su aseguramiento (efectuadas durante el análisis de los requerimientos y el diseño) serían notables.