unidad ii- calidad enfocada al desarrollo de sistemas de información.pptx

5/19/2018 Unidad II- Calidad enfocada al desarrollo de sistemas de informaci n.pptx

1/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


2/44

Presentaremos tres definiciones relacionadas con calidad en sistemas y sobre ellabasaremos la definicin de calidad de los sistemas de informacin.

W. E. Perry: Calidad se define en el diccionario como un atributo o caractersticaasociada a algo, as pues, calidad no puede ser definida de manera universal, sinoque, 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 elambiente de procesamiento de datos debe ser definida por la organizacin. Ladefinicin de calidad hecha por una organizacin puede ser diferente a la hecha porotra. Para una organizacin, un FORD MODELO T bien construido es calidad.Mientras que, para otra, calidad es un CADILLAC FULL EQUIPO. La calidad nopuede ser incorporada a un producto o ser medida hasta tanto no se defina. La granmayora de las instalaciones de procesamiento de datos apenas han comenzado adefinir lo que es calidad en las aplicaciones computarizadas.La definicin de Perry nos dice, principalmente, que la calidad no debe serconcebida en trminos generales o abstractos y que cada organizacin debeidentificar lo que para ella significa un sistema de calidad, con el fin de establecerlos patrones y las vas necesarias para lograrla.


3/44

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 lafuncin de calidad en sistemas, al definir las responsabilidades de SQAdescribe varios aspectos importantes relacionados con la calidad de lossistemas:

La calidad de un sistema requiere de la participacin de todos, no es algoque atae exclusivamente a un grupo de SQA, incluye La calidad de un sistema es fruto de una cuidadosa planificacin; no es algoque 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, esaumentar la confianza de que se han dado todos los pasos necesarios paralimpiar errores del software que se desarrolla.


4/44

G. J. Myers: La confiabilidad del software es la probabilidad de que este seejecute por un cierto perodo de tiempo sin fallas, ponderada por el costo querepresenta 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 absolutacerteza de que un software est totalmente limpio de errores.2. El costo que genera para los usuarios por cada falla generada


5/44

DEFECTOS

El termino defecto se refiere a algo que est equivocado en un programa, talcomo un error sintctico , una falta tipogrfica, un error de puntuacin, o unasentencia incorrecta del programa.Los defectos pueden estar en los programas, en los diseos o incluso en losrequisitos.Las especificaciones o en otra documentacin. Los defectos pueden sersentencias extra o redundantes, sentencias incorrectas o secciones del programaomitidas. Un defecto, es cualquier cosa que reduce la capacidad de losprogramas 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/44

Es importante separar la cuestin de encontrar o identificar los defectos de ladeterminacin de sus causas. La simple contabilizacin y registros de losdefectos en los productos software no es la especificacin de las causas ni laasignacin de culpas. Los defectos cometidos. Sin embargo, tienen sus causas.Puede haber cometido un error al escribir el nombre de un parmetro, omitidoun signo de puntuacin o llamado incorrectamente un procedimiento. Todosestos errores causan defectos.

Todos los defectos por consiguiente, proviene de errores humanos y muchosde los que los ingenieros del software cometen, causa defectos en losprogramas.


7/44

ERRORES

Los errores son cosas incorrectas que cometen las personas y sin tener encuenta cuando y quien los comete, los defectos son elementos defectuosos de

los programas. As las personas cometen errores o equivocaciones mientrasque los programas tienen defectos. Cuando los ingenieros cometen errores queconducen a defectos, nosotros nos referimos a esto como la introduccin dedefectos.Esto significa que para reducir el nmero de defectos que introduces en tusproductos, debes cambiar la forma de hacer cosas para eliminar los defectos en

tus productos. Sin embargo, sencillamente tienes que encontrarlos. Laeliminacin de defectos es, por lo tanto, un proceso ms sencillo que laprevencin de defectos. La prevencin de defectos es un aspecto importante yprioritario que requiere un estudio comprensivo de todo el proceso dedesarrollo del software.


8/44

Los defectos deberan ser importantes para cada ingeniero del software nosolo porque afectan a los usuarios, sino tambin porque ms de la mitad del

esfuerzo de las organizaciones de software est dedicado a encontrar ycorregir 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 yprogramaciones.


9/44

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


10/44

El primer paso para gestionar los defectos es entenderlos. Para hacer eso, debes

reunir los datos de defectos. Entonces, podr entender estos errores ycomprender como evitarlos. Puedes tambin comprender como encontrarlosmejor, 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 puedasentenderlo3. Analiza estos datos para ver qu tipos de defectos causan los mayoresproblemas.

Los defectos que introduces y encuentras en tus propios programas, son

solamente parte de la historia. Algn da, necesitaras aprender sobre los defectosque otras personas encuentran en tus programas. Puesto que estos defectos seescaparan a todos los esfuerzos de deteccin y prevencin de defectos, sern msimportantes para entender y tratar debilidades de tus procesos personales. Estosdefectos se denominan escapes, porque han escapado a todos tus esfuerzos deeliminacin de defectos. Conforme mejore tu proceso personal, los defectos quese escapan sern la ultima fuente principal de datos para tu mejora personal.


11/44

Muchos usuarios suelen referirse a los defectos como bugs. Esto parecetrivializar y restar importancia al problema. Pero lo cierto es que undefecto puede llegar a ser una autentica bomba de relojera. Existenregistros histricos donde un defecto aparentemente trivial, causproblemas graves (ej: un desbordamiento de buffer caus prdidas de

datos en el sistema de control de ferrocarril, lo que oblig a mantenerparado trenes de millas durante varias horas, hasta que se introdujeronlos datos.)Quien ms capacitado esta para corregir los defectos de un programa , esaquella o aquellas personas que lo desarrollaron.

Hay que remarcar siempre la importancia de eliminar todos los defectosde un producto.


12/44

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 sunmero, pero el resto de datos deben esperar a tenerlo corregido. Nuncahay que agrupar defectos idnticos en una sola lnea; siempre hay queregistrarlos en distintas lneas. As mismo hay que registrar las fechas en lasque 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 mejorcriterio posible). Tambin se debe anotar la fase del proyecto en la que seintrodujo el defecto (en programas grandes esto puede ser algo mscostoso). 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 lalocalizacin del defecto hasta su eliminacin. Un error en la compilacin esrpido de resolver, pero uno en las pruebas lleva ms tiempo.Existen defectos que se corrigen al corregir otros defectos (valga laredundancia). Cada registro de defecto debe ir acompaado de una brevedescripcin que sea clara.


13/44

Estos son algunos de los objetivos de usar el cuaderno:

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

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

Ahorrar tiempo: la sangre llama a la sangre. Los errores tienden a provocarms errores (un error de diseo causar uno o ms errores enimplementacin). 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


14/44


15/44

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.


16/44

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 DECORRECCIN

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 casillade 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.


17/44


18/44

Las anotaciones en el cuaderno deben basarse slo en las correcciones que sehacen (un solo despiste, p. eje. Un punto y coma) puede provocar varioserrores, pero la correccin es slo una.Por otro lado, el diseo puede sufrir cambios durante el desarrollo debido ala aparicin de ideas mejores u optimizaciones (o, simplemente, cambios enel parecer del cliente que tambin ocurre con ms frecuencia de la deseada).

Esto no se consideran defectos (otra cosa sera cometer un error en losrequisitos, con lo que sera un defecto de requisitos).Recurdese que se considera defecto aquellos que aparecen tras lacodificacin (si se nota algo mientras se est codificando y se corrige antes determinar, 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 delsegundo mdulo se descubre un defecto en el primero, s es un defecto.Para aprender a reunir datos de defectos, conviene comenzar porcontabilizar slo los de compilacin y pruebas hasta que se tome soltura.


19/44

Aunque no hay forma de acabar con la introduccin de defectos, es posibleencontrar 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 defectoHacer 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.


20/44

La calidad de las pruebas por el grado en que estos escenarios cubren todas lasfunciones importantes del programa.

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

Segn Humphrey, la forma ms rpida y eficiente es revisando personalmenteel 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 enentregar programas defectuosos y esperar que los usuarios identifique einformen de los defectos. Esta es la estrategia ms costosa.


21/44

Por ltimo, indicar que la forma ms efectiva de encontrar y corregir defectoses revisar personalmente el cdigo fuente del programa. Aunque esto puede

parecer una forma difcil de limpiar un programa defectuoso. Se trata de laforma ms rpida y eficiente.

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

Las revisiones tambin tienen desventajas. Las dos desventajas principales sonque las revisiones de cdigo consumen tiempo y es difcil hacerlascorrectamente.


22/44

El costo medio de encontrar y corregir un defecto crece unas 10 veces en cadapaso del proceso de desarrollo.Aunque el tiempo de corregir los defectos vara enormemente, estos valoresmedios muestran, a pesar de todo, los tipos de defectos.El tiempo de encontrar los defectos en las pruebas de integracin, decomponentes 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 ycorregir los defectos puede ser mucho mayor, dependiendo de la clase deproductos y de los tipos y nmero de clientes.

Adems del coste, una razn de igual importancia para encontrar los defectos alprincipio es que la compilacin, depuracin y las pruebas tienen una efectividadreducida.

As, si se requiere producir un producto de alta calidad, tendrs que producir unprograma sin defectos al principio o esperar dedicarle mucho tiempo en las

pruebas.


23/44

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, con300 horas por defecto.

Un sistema aeroespacial necesit:una media de 40 horas por defecto en las pruebas del sistema de navegacinarea.

En Digital Equipment Corporation,para un sistema, el tiempo mnimo para encontrar y corregir cada defectoinformado por el cliente fue de 88 horas.


24/44

Una lista de comprobacin contiene una serie de pasos que t quieres seguir deforma rigurosa. Cuando utilizas una lista de comprobacin desarrollada a partirde tus propios defectos., har revisiones ms eficientes.La lista de comprobacin no solamente ayuda a encontrar ms defectos, tambinayuda a encontrarlos ms rpidamente. Para construir una lista de comprobacinpara la revisin de cdigo, adptala al lenguaje que utilices, disala a partir detus propios defectos y ajstalas a tus habilidades y experiencias cambiantes.Algunas orientaciones para utilizar la lista de comprobacin son: haz de lasrevisiones paso a paso, completa cada programa o procedimiento antes de iniciarel siguiente, examina cada apartado de la lista de comprobacin cuando locompletes. Cuando encuentres defectos, anota el numero encontrado en cadaapartado de la lista de comprobacin. Cuando lo hagas, completa las columnashasta 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. Cuandosigues una lista de comprobacin personal. Sabes cmo revisar tu cdigo. Siutilizas la lista correctamente, tambin sabes cuantos defectos encuentras en cadapaso de dicha lista.


25/44

La clave para realizar una revisin de cdigo efectiva es tener unprocedimiento 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 losdefectos 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.


26/44


27/44


28/44

CMO EVALUAR TU DISTRIBUCIN DEL TIEMPO

Ahora que puedes saber cmo utilizas tu tiempo, pregntate a ti mismo siests 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 queson ms importantes? Ests dejando suficiente tiempo para leer libros detexto?haces el trabajo? Y cules son tus compromisospersonales?Comienzas los ejercicios a tiempo para acabarlos, o los terminasen el ltimo momento?

Esta es una decisin muy personal que debes equilibrar entre el trabajoacadmico, las tareas, el descanso y la vida social. Algunos de estoscomponentes son cuestiones personales que implican complejas elecciones,particularmente si tienes un trabajo y responsabilidades familiares.


29/44

Despus de haber revisado la estimacin de tiempo, puedes necesitar aumentarla cantidad total de tiempo. Cmo puedes hacer esto? Tienes varias opciones.Primero, si tu agenda no esta muy ocupada, sers capaz de encontrar un pocode tiempo extra, pero desafortunadamente, pocas personas estn bendecidascon el tiempo libre. Es ms probable que ests sper comprometido. En estecaso, 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 frenteal estimado. Para hacer una estimacin de tiempo decide como quieres utilizarel tiempo. Haz una programacin que refleje tu eleccin y que muestre lostiempos cada da; puedes necesitar diferentes estimaciones para distintassemanas.


30/44

Las reglas bsicas para estimar el tiempo pueden ser tiles:

Identifica tus compromisos fijos y variablesDivide tu tiempo variable en tareas que son exigidas y aquellas que sondiscrecionalesAnaliza como divides ahora t tiempo en estas categoras. Recuerda que tutiempo total es fijo: si necesitas ms tiempo para algunas actividades debesdedicar 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 estimacinbasndote en tus necesidades y experiencias.Haz los cambios de forma gradual cuando cambies tu estimacin de tiempo.Guarda las versiones anteriores.


31/44

Conforme los programas son ms grandes, es ms costoso encontrar ycorregir los defectos. El proceso de eliminacin de defectos es tambin menosefectivo. 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: vecada fase de eliminacin de defectos como un filtro. Cuantos ms defectos sepongan en el filtro ms se encontrarn. Tambin, cuantos ms defectos sepongan en el filtro, ms se pasarn por alto. El rendimiento de muchas fasesde pruebas es menor del 50%. As, para obtener un producto de alta calidadal final de una prueba, debes poner un producto de alta calidad al comienzo

de la prueba.


32/44

Un trabajo concienzudo en cada paso de tu proceso ser rentable y ahorrartiempo. Si haces un programa mal, se encontrarn muchos defectos en lacompilacin y en cada subsiguiente fase de pruebas. El rendimiento mide lacalidad de la eliminacin de defectos. El rendimiento del proceso se refiere a latasa de defectos en el producto que son eliminados antes de la primeracompilacin. El rendimiento puede medir tambin la tase de defectos en unproducto que son eliminados en la fase de eliminacin de defectos. Tu objetivosera lograr el 100% de rendimiento del proceso.

Recuerda:no sers capaz de hacer grandes programas de calidad hasta que nopuedas hacer de forma constante pequeos programas de gran calidad. Estosupone una dedicacin constante a la calidad, disciplina personal y muchaprctica. Para lograr la mxima calidad en un programa, haz pequeosprototipos 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 queintroduzcas un defecto.


33/44

El proceso de medida del rendimiento tiene que ver con la tasa de eliminacinde defectos antes de la primera compilacin. La medida del rendimiento, sinembargo, 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 lafase)/(nmero de defectos en el producto al inicio de la fase).

Desafortunadamente, los datos sobre los rendimientos de compilacin ypruebas no son tranquilizadores, como se muestra en la siguiente tabla lasrevisiones de cdigo e inspecciones tienen mejores rendimientos, mientras lacompilacin, pruebas de unidad y otras formas de pruebas son menos efectivas(Humphrey 891). Estas cifras estn basadas en datos limitados y puede que nose apliquen a tu situacin particular, pero estos son todos los datos quetenemos. La mejor respuesta para ti, naturalmente, sera reunir los datos losdatos de rendimiento de tus propios mtodos de eliminacin de defectos ysacar tus propias conclusiones. Es interesante observar que el mtodo de mayorrendimiento de la tabla es para los ingenieros que hacen una revisin de cdigo.El siguiente mayor rendimiento es para las inspecciones, donde variosingenieros revisan entre si el diseo y el cdigo.


34/44

Mtodo Rendimiento aproximado (%)

Revisin del cdigo 70-80

Inspeccin del cdigo 50-70

Compilacin 50

Prueba de unidad 40-50Prueba de integracin 45

Prueba de requisitos 45

Prueba de algoritmo 8


35/44

Los mtodos que tienen los mayores rendimientos son manuales no implicanninguna herramienta automatizada. La razn de que sean mejores que otrosmtodos es que la mente humana es el instrumento de deteccin de defectosms poderosos que cualquier herramienta de software actual.

La conclusin lgica de estos datos es que, para hacer programas de altacalidad, debes tener el menor nmero de defectos posibles al comenzar laspruebas. 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 dedefectos, 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.


36/44

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 queevita los errores del diseo, el obrero de produccin que localiza losdefectos el representante de ventas presenta el productoadecuadamente a los clientes potenciales.

Los sistemas de informacin pueden ayudar a las empresas a lograr susmetas de calidad ayudndoles a simplificar productos o procesos, acumplir estndares de benchmarking (pruebas corporativas), hacermejoras con base en las demandas del cliente, reducir el tiempo de cicloy aumentar la calidad y precisin de diseo y produccin.


37/44

En los sistemas de informacin, el control de calidad incluye unconjunto de acciones de ingeniera de software que ayudan a asegurar

que todo producto del trabajo cumpla sus metas de calidad. Losmodelos se revisan para garantizar que estn completos y que sonconsistentes.

El cdigo se inspecciona con objeto de descubrir y corregir errores antes

de que comiencen las pruebas. Se aplica una serie de etapas de pruebapara detectar los errores en procesamiento lgico, manipulacin dedatos y comunicacin con la interfaz.

La combinacin de mediciones con retroalimentacin permite que el

equipo de software sintonice el proceso cuando cualquiera de estosproductos del trabajo falla en el cumplimiento de las metas de calidad.Las actividades de control de calidad se describirn en la siguientesunidades.


38/44

El argumento es algo parecido a esto: sabemos que la calidad es importante, perocuesta tiempo y dinero - demasiado tiempo y dinero- lograr el nivel de calidad en elsoftware que en realidad queremos.Visto as, este argumento parece razonable. No hay duda de que la calidad tieneun costo, pero la mala calidad tambin lo tiene -no slo para los usuarios finalesque deban vivir con el software defectuoso, sino tambin para la organizacindel software que lo elabor y que debe darle mantenimiento-.

La pregunta real es sta: por cul costo debemos preocupamos? Para responder a estapregunta debe entenderse tanto el costo de tener calidad como el del software demala 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 faltade calidad. Para entender estos costos, una organizacin debe contar conunidades de medicin que provean el fundamento del costo actual de lacalidad, que identifiquen las oportunidades para reducir dichos costos y queden una base normalizada de comparacin. El costo de la calidad puededividirse en los costos que estn asociados con la prevencin, la evaluacin y la

falla.


39/44

Los costos de prevencin incluyen lo siguiente:1)el costo de las actividades de administracin requeridas para planear y coordinartodas las actividades de control y aseguramiento de la calidad,

2) el costo de las actividades tcnicas agregadas para desarrollar modeloscompletos de los requerimientos y del diseo,3) los costos de planear las pruebas y4) el costo de toda la capacitacin asociada con estas actividades.Los costos de evaluacin incluyen las actividades de investigacin de la condicin delproducto 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 laingeniera 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 eninternos y externos.Se incurre en costos internos detalla cuando se detecta un error en un producto antes delenvo.


40/44

Los costos internos de falla incluyen los siguientes:

El costo requerido por efectuar repeticiones (reparaciones para corregir unerror).El costo en el que se incurre cuando una repeticin genera inadvertidamenteefectos 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 elproducto se envi a los consumidores. Algunos ejemplos de costos externos de falla sonlos de solucin de quejas, devolucin y sustitucin del producto, ayuda en lnea ytrabajo asociado con la garanta.


41/44

La mala reputacin y la prdida resultante de negocios es otro costo externo defalla que resulta difcil de cuantificar y que, sin embargo, es real. Cuando seproduce 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] afirmalo siguiente:Muchos de los costos de falla externos, tales como los fondos decomercializacin, son difciles de cuantificar, por lo que muchas compaaslos 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 losconsumidores) sin que se incremente la satisfaccin del cliente. Al ignorar loscostos que los malos productos generan a nuestros compradores, losingenieros de la calidad estimulan una toma de decisiones que los hacevctimas en lugar de satisfacerlos.


42/44

Como es de esperar, los costos relacionados con la deteccin y la correccin deerrores o defectos se incrementan en forma abrupta cuando se pasa de laprevencin 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]


43/44

El costo promedio de la industria por corregir un defecto durante lageneracin de cdigo es aproximadamente de US$977 por error. Elpromedio del costo en el que incurre la industria por corregir el mismo errorsi se descubre durante las pruebas del sistema es de US$7,136. Cigital, lnc.[Cig07] tome en cuenta que una aplicacin grande contiene 200 erroresintroducidos durante la codificacin.

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


44/44

Los datos promedio de la industria indican que el costo de encontrar y corregirdefectos durante la fase de pruebas del sistema es de US$7 136por cada uno. Eneste 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 decodificacin), el costo de encontrarlos y corregirlos (50 x US$7 136)seraaproximadamente de US$356 800. Esto tambin habra resultado en 150 errorescrticos 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 deencontrar y corregir los 200 defectos (US$2 I 15300 + US$356 800) despus de lafase de codificacin habra sido de US$2 472 100.

Aun si la organizacin de software tuviera costos que fueran la mitad delpromedio de la industria (la mayor parte de compaas no tiene idea de culesson sus costos), los ahorros asociados con el control de calidad temprano y lasactividades para su aseguramiento (efectuadas durante el anlisis de losrequerimientos y el diseo) seran notables.

unidad ii- calidad enfocada al desarrollo de sistemas de información.pptx

Documents