Você está na página 1de 21
www.elsalucionaria.net CAPITULO GARANTIA DE CALIDAD DEL SOFTWARE (SQA/GCS)* tivo: producir software de alta calidad Pero amuchos lectoreslesinquietaréle pregunta « caleda, (5)el control de le documentacién del software y de los cambios realizedos, (6) mn pro: cedimientoque asegure un ajuste alos esténdares de desarrollo del softwere (cuando seapositle), ¥ @) mecenismos de medicién y de generacién de informes. En este capitulo nos centraremos enlos aspectos de gestion y en les actividades especifica del proceso que permitan a una organizacién de software asegurar que hace «las cosas correc: tas en el momentojusto y de la forma correcta» E L enfoque de ingenierie del software descrito en este libro se dirige hacia un solo obje- VISTAZO RAPIDO repeti Si un equipo de software. 4Cuél os ol producto obtenide? Pars ay celatalidad «todas las actividades definir una ertrateginde SQApara.l B importante tenes que:())de- dela ingenieria del software, reduci- equipo de software se ha creado un [flair expliciomente lo que significa rélacantidad detrabajorepetidoque _phinde gueatiade calidad del soit: |) scilldeddelsoftwaze:Cicear uncon: deba realizar Esto eupondré costes ware. Durante] andlisi, disefo junto de cctividades que ayuden Pgarantioar que todo producto de linge aera dl software presenta alta cali- ad; (9) lovar « cabo actividades de J garanta de calidad en coda proyecto de Py aottware: 4 lisa métiogs pera desc nollarestrategias que mejoren el pro- ‘e00 del altware como consecuncia, ‘mojren a calidad del producto final ro hetco? Todo ol quo ostérela- ‘donado con el proceso de Ingenieria Ls et software os responsable de lacali- da, _gPor qué ox importante? Lo puedes ‘hacer correctamente o lo puedes mda bajosy, lo que es més importan- te, mejoraré el tempo de llegada al mercado, Cader som los pasos? Antos de que '9e puedan iniciar las actividades do ‘garantia de calidad del software, es {importante defini a wealidad dol slt- ‘wares a un nimero diferente de nive les do abstraceidn. Una vez que ‘comprendes lo que es la calidad, un ‘equipo de softwaredebeidentticar un ‘conjunto do actividades do garantia de calidad del software que eliminarén Jos errores de los productos realizadios ‘antes de que ccurran, codificacién, el producto principal de ‘SQAes un breve informe de a revision ‘éenicaformel. Durentelas prucbas, realizan los planes y procedimientos de prueba, También se pueden gene- ar otros productos de trabajo relacio- ratios con la mejora del proceso. ACémo puedo asogurar que le he ‘hecho correckamente? Encontarloe ‘errors antes que pasen a ser defactos! Estoc, trabajar para mojorartweficien- aon la eliminacién de eroces (Capl- tuloe 4 7, reduclenda de entesodo la ccantdad do trabajo repetido que tiene ‘que haver tu equipo de sotware TWEET: Brespaiol, GCS. Se comervan ls sigh: $QA en inglés por estar muy extedido su uso para [a jerga infor anitica. A vacer se suelen traducirestarsighe tambien por «Accgltamiento dela Caliad del Sotware= sat www.elsalucionaria.net (WORNIERIR DEL SOFTWARE. UX _ ‘Se dice que dos copos de nieve no son iguales. Cierta- mente cuando se observa caer la nieve, es dificil ima- ginar que son totalmente diferentes, por no mencioner que cada copo posee una estructura tinica. Para obser vvar las diferencias entre los copos de nieve, debemos examiner los especimenes muy de cerca, y quizé con un cistel de aumento. En efecto, cuanto més cerce los observemos, més diferencias podremos detecter. Este fenomeno, variacion entre muestras, se aplica todos los productos del hombre asi como ala creacién, natural, Por ejemplo, si dos tarjetas de circuito «idénti- cas» se exeminanmuy de cerca, pockemos observer que las lineas de cobre sobrelas tej etas dfierenligeramente enla geometsia, colocaciény grosor. Ademés, Ia loca- lzaciony el diametro de los auficios de las tasjetastam- ‘bien varien. ‘lage aid io dep ice un rab apetonic El control de vartacién es el centro del control de calidad Un fabricente quiere reducir la variacion entre los productos que se febricen, incluso cuando se reali- za algo reletivamente sencillo como le duplicacion de isquetes. Seguramente, esto puede no ser un problema —la duplicaciénde disqueteses una operacién defubri- cacién trivial y podemos gerantizar que se crean dupli- cados exactos de softwere— {Podemos?. Necesitamos asegurar que las pistes se sitien dentro de una tolerancia especifica para que le gen mayoria de las disqueteras puedan leer los dis- quetes. Ademés, necesitem osasegurer que el flujomag- nético para distinguir un cero de un uno sea suficiente pera que los detecten las cabezas de lectura/escritura, Lasmaquinasde duplicacionde discosaceptanoreche- zen le tolerancia. Por consiguiente, incluso un proceso simple», como le duplicacién, puede encontrarse con problemas debidos @ le veriacion entre muestras. "Cave Contr aviasines ade de unpodcoe ats caida, Enel ortega de sot, rsestramnos encore ces ue splenos, recussque cosuninesy loans dead (el ada ‘Bit rec, eserita por Miclael Covey, ze I adaptado de <(Fun- Adamentals of CO 9900. sin Hiro de trabajo desanolado para Essen tal Softvane Engineering, un video cunicuhimdesanollado pork S Pressman Asociados, ne. Reimpresion autonzada, 12 {Como se aplice esto al softwere? Como puede uns orgenizacién de deserrollo de software necesiter controlar 1a vesiacién? De un proyecto a otro, quere- mos reducir le diferencia entre los recursos necese- ios planificados para terminer un proyecto y los recursos reales utilizados, entre los que se incluyen personal, equipo y tiempo. En general, nos gustaria aseguramos de que nuestro programa de pruebas bar- catm porcentaje conocido del software de una entre- gaa otra. No sélo queremos reducir el mimero de defectos que se extraen para ese campo, sino también nos gustaria asegurarnos de que los errores ocultos también se reducen de una entrego a otra. (Es probe- ble que nuestros clientes se molesten sila tercere entrega de un producto tiene diez veces més defectos que Ie anterior) Nos gusterie reducir les diferencias en velocidad y precision de nuestras respuestas de soporte a los problemas de los clientes. La lista se podria amplier més y més 844. Calidad El Americans Heritage Dictionary, define la calidad como Como se define «calidad el software)? En los libros se han propuesto muchas definiciones \Sécelidad del software. Por lo que a nosotros respecta, Tacaicad del software se define como Concondancia con los requis funcionales y de vedi arian expicitamenteestablevicos conlo estanderesde dese- nol expliiemente documentados, y con las craceristicas -mpicths que se espera de todo softare desanollad profe- sionalmente No hay duda de que le enterior definicién puede ser ‘modificada o ampliada. De hecho, no tendria fin ma dis- cuiin solre una definicionformal de calidad del soft- ‘Tere a2) paza um estudio mas completodel G1 y su uso fenun contri de software (kAP95) pura Ub estucio sobre eluso tertenobabridge awardee uid oft 136 wore, Para los propésitosde este libro, la anterior defini. cin sirvepara hacer hincepié entres puntosimportentes: 1, Los requisitos del softwere son la base delasmeci- das de la calidad Le falta de concordancia con los sequisitos es una falta de calidad, Los esténdares especificados definenun conjunto de criterios de desarrollo que guien le forma en que se aplicela ingenieria del software. Sino se siguenesos ctiterios, casi siempre habré falta de calidad. . Existe un conjunto de requisitos implicitos que a ‘menudo no se mencionen (por ejemplo: el deseo por facilites el uso y un buen mantenimiente). Si el soft. ware se ajusta a sus requisitos explicitos pero fella en alcanzar los requisitos implicitos, la calidad del software queda en entredicho 8.3.1. Problemas de fondo La historia de le gerantia de calidad en el desarrollo de software es paralele a lahhistoria dee celidadenla cree- cidn de harchwere, Durante los primeros aiios de le infor- www.elsalucionaria.net IWOENIERIA DEL SOFTWARE. Us eatwyva raacrice mética (los afios cincuentey sesents),la calidaderares ponsabilidad tinicemente del program edor. Durante los adios setenta se introdujeron estandares de garantie de calidad pera el software en los contratos militares para desarrollo de softwarey se han extendidorépidamente ‘alos deserrollos de software en el mundo comercial [IBE94], Ampliando le definicién presented enterior- mente, la garantia de calidad del software (SQA) es un «patron de accionesplenificadoy sisteméticon[SCH97] (que se requiere para asegurerla calidaddel softwere El ‘ambito de laresponsabilidad dela garantia de calidad se ‘puede ceracterizermejor parafraseandoun popular enun- cio de coches: «Le calidad es le 1.* tarea» La implice- cién pare el software es que muchos de los que constituyentna organizacién tienen responsabilidadde gorentia de celided del software — ingenierosde soft- wore, jefes de proyectos, clientes, vendedores, y aque- las personas que trabajan dentro de un grupo de SQA— Referencia jue encotarun loin y anpios recsospuralagesin cali en \wewumenagerent gov El grupo de SQA sirve comorepresentacién del clien- te en casa. Es decir, la gente que lleva a cabole SQA debemirar el software desde el punto de vista del clien- te, (Satisface de forma adecuada el software los facto- ses de calidad apuntados en el Capitulo 19 ;Se he redlizado el deserrollodel softwarede acuerdoconestén- dares preestablecidos? ;Han desempefiado apropiada- mente sus papeles las disciplinas técnices como parte de la actividad cle SQA? El grupo de SQA intenta res- ponder a estas y ottas preguntas para asegurar que se mantiene le calidad del software 8.3.2, Actividades de SQA La gerentia de calidad del softwere comprendeuna gran variedad de tereas,asociadas con dos consitutivosdife- rentes —los ingenierosde software que realizen trabe- jotécnicoy un grupo de SQA que tiene laresponsabilidad, de Ie Plasuficacion de gerentia de calidad, supervision, mantenimientode registros, anéisise infames— Losingenierosde software afrontante calidad (ys2e- lizen garantia de calidad) aplicando métodos tecnicos solidos y medidas, ealizendo revisiones técnicas for- males y levando a cabo pruebas de software bien pla- nificadas, Solemente lessevisiones sontratadas en este capitulo, Los temas de tecnologia se estudienen lasPer- tes Tercera @ Quinta de este libro Lesreglas del grupo de SQA tretan de eyuder al equi- po de ingenieria del softwere ena consecucion de Un pro- ducto final de alta calidad. El Instituto de Ingenieria del Software [PAU93] recomienda un conjunto de ectivide- des deSQA que se enftentanconla plenificacién de garen- tia de calidad, supervision, mantenimiento de registros, anilisise informes Estas sonlas actividades queredlizen, (0faciliten) un grupo independiente de SQA Establectmiento de unplan de SQApara unproyec- to Elplan se deserrolla durante laplanaficacién del pro yectoy esrevisado por todas les partesinteresadas Las ‘actividades de garantia de celidadrealizedas por el equ pode ingenieria del softwarey el grupoSQA son gober- ‘nadas por el plan. El plan identifica + evaluaciones arealizer, + auditoriasy revisiones arealizer, + esténdares que se pueden aplicar al proyecto, «+ procedimientosparainformaciony seguimiento de exrores, + documentos producidos por el grupo SQA, + realimentacion de informacién proporcionada equipo de proyecto del software Perticipactén en el desarrotio de ta descripetén det ‘proceso de software del proyecto. El equipo de ingenie- sia del software selecctona tm proceso para el trabajo (que se-va realizar. El grupo de SQArevisala descnp- cion del proceso para ajustarse elapolitica de le empre- sa, los esténdares ntemnos del software, los esténdares impuestos externamente (por ejemplo: ISO 9001), ya otras pastes del plan de proyecto del software Revision de las actividades de ingenteria del soft ware para verificar su ajuste al proceso de sofware definido El grupo de SQA identifica, documentay gue la pista de las desviaciones desde el proceso y venifica (que se han hecho les correcciones, Auditoria de ios productos de software designados ‘para vertficar el ajuste con ios definides comoparte del ‘proceso del software. El grupo de SQArevisa los pro- ‘ductos seleccionados; identifice, documenta y siguela piste de las desviaciones, verifica que se han hecho les correcciones, € informa periddicamente de los resulte- dos de su trabajo al gestor del proyecto. Asegurar que las desviactones del trabajoy lospro. ductos del sofware se documentan y se manejain de acuerdo con unprocedimtento establectdo. Las des- “iaciones se pueden encontrar en el plan del proyecto, ena descripcién del proceso, en los esténdares eplice. bles o en los productos técnicos Registrar lo que no se ajuste a ios requisites e tfor- mar a sus supertores. Los elementos que no se ajusten alos requisitos estén bajo seguimiento hasta que s= sesuelven, Ademés de estas actividades, el grupo de SQA coo dina el controly Le gestiénde cembios(Ceapitulod)y ays da arecopilery a anelizerlasmétrices del software Cuil es elpapel ie ungrupo de SQA? 6 www.elsalucionaria.net TIA DE CALIDAD DEL SOFTWARE Las revisiones del software son un «filtro» para el pro- 280 de ingenieria del software Esto es, las revisiones + aplicen en varios momentos del desarrollo del soft- ‘wae y sirven para detectar erroresy defectos que pue- idan ad ser eliminados Lesrevisiones del software sirven, para «punificam les actividades de ingenieria del soft- ‘are cue sucedencomo resultado del anslisis, el disefio yla cotificecién Freedmany Weinberg[FRE90] ergu- ‘marta de le siguiente forma le necesidadde revisiones: Elbe ticniconecesite ser neviado pr la misma razon qu bslapcesnecestangomas ener eshimano.Laseguada ein pola que necesfomosevisionestcnicas es qe, an qu hen esbuena desetbnendoalgwos de sw pops eno 2s algasrlases de eres ee pase pr alo mas feliente ‘le bs ongina que a ots peanes proceso de evsi0n 1, portato, la espuestaa la plegana de Robert Bus (Qué oranegalosevinpoder vemos como ros ven eden! Une vision — aociadoconello Guano apicaciSnce verde entunpais de habla ancesa,el ‘mem elemendodel meni es «Ferme» conel mneneico <> 45 Parallevaracabo laentada adecuadadel men paracadaapli- cacion,un docalizador (una persona que habla enel dioma localy conla temninologiade ee hagas) aduce lor mers de acuerdacone] idioma enuso.Elproblemaes asegurarque (1) Cala entada de meri (piedenenastrciento de ella.) e.le- cue a les estindares aropiados y que no existan conflicts, independientementedel lenguaje que se e:téutizando. El uso del poka-yoke para la prueba de diversos memtis de aplicacion desarrollados en diferentes len- guajes, tal y como se ha descnto anteriormente, se dis- cute en wn articulo de Harry Robinson [ROB97]. ‘Nosoto: primero deciimos didi el problema de proe- ‘bas de mets en partes que puedan ser revues mas facil mente Nuesto primer avance pra laesokiciondel problema fueel comprenderque exstand: a:pectoreparades paalos catdlogos de mensaje. Habia poruna parte el aspecto de com- femdor'las taduccones de exto may simples tales comocam ‘biarmeramente «Close» por la palabra «Fermer>, Pesto que clequipoque ralizabalas comprobaciones no bablabadefor- sa fla el lenguaje eel que se petendia taba, feniamos (que dejar ester aspects a taductores experts del lenguaje EI segundo aspecto de os catélogos del mensaje era la estructura, las reglas sintacticas que debia obedecer ‘un catalogo de objetivos adecuadamente construido. A. diferencia del contenido, en este caso si que era posible para el equipo de comprobacion el venificar los aspec- tos estructurales de los catélogos. Como un ejemplo delo que significa estructura, con- sideremos las etiquetas y los mneménicos de un ment de aplicacién. Un ment esta constituido por etiquetas y susmneménicos (abreviaturas)asociados. Cada ment, independientemente de su contenido o su localizacién, debe obedecer las siguientes reglas listadas en la Guia de Estilo Motif Cada nemotécnico debe estar contenido en su eti- queta asociada, Cada nemotécnico debe ser tinico dentro del ment; Cada nemotécnico debe serum caracter Unico, Cada nemotécnico debe estar en ASCII Estas reglas son invariantesa través de las localiza- ciones, y pueden ser utilizadaspara verificar que un mentt esta correctamente construidoen la Locatizacon objetivo Existen varias posibilidades para realizar la prueba de exrores de los mnemonicos del ment: Disposttivo de prevencién. Nosotros podemos escri bir un programa para generar los mnemonicos autom: ticamente, dada una lista de etiquetas en cada ment. Este enfoque evitaria errores, pero el problema es que escoger un mneménico adecuado es dificil,y el esfuer- 220 requerido para escribir el programa no estaria justi- ficado con el beneficio obtenido. Dispositivo de prevencién. Podriamos escribir un programa que prevendria al localizador de elegir unos ‘mneménicos que no satisfagan el cnterio. Este enfoque también evitaria errores, pero el beneficio obtenido seria ‘minimo: los mnemonicos incorrectos sono suficiente- www.elsal mente faciles de detectary corregir después de queapa- rezcan. Dispositivo de deteccion. Nosotros podriamos pro- porcionar un programa para verificar que las etiquetas del ments escogidas y los mneménicos satisfacen los enteriosanteriores. Nuestros ocalizadorespodtrian &je- cutar los programas sobre os catélogos de mensaje tra- ducidos antes de enviamosa nosotros dichos catélogos Este enfoque proporcionaria una realimentacidn rapida sobre los errores y sera, probablemente, un paso a dar ene! futuro Dispositivo de deteccién. Nosotros podriamos escri- bir un programa que verificase las etiquetasy mnemoni cos del ment, y ejecutara el programa sobre catélogos de ‘mensajes despues de quenos loshayan devuelto los loca- lizadores, Este enfoque es el camino que actualmente estamostomando, No estan eficente comoalgunadelos rictodos anteriomente mencionados y puede requenir que se establezca una comunicacidn fluida hada delan- tey hacia atras con los localizadares, pero los errores detectados son incluso faciles de corregir en este punto, Varios textos pequefios de poka-yoke se utilizaron como dispositivos poka-yoke para validar los aspectos lucionario.net estructurales de1os memis .Un pequetio «script» poka- yoke leeria la tabla, recuperaria los mneménicos y et- quetas a partir del catélogo de mensajes, y compararia posteniormente las cadenas recuperadas con el cnteno establecido descnito anterionmente Los «scripts» poka-yoke eran pequefios (aproximada- ‘mente 100 lineas), ficilesde escribir algunosde los esn- tos estaban en cuanto al tiempo por debajo de una hora) y faciles de ejecutar Nosotros ejecutabamos nuestros “scripts» poka-yoke sobre [6 aplicacionesen a ubicaciin eningléspor defectoy en Il ubicacionesextranyeras. Cate ubicacién contenia 100 ments para un total de 1.200 ‘emis. Los dispositivos poka-yoke encontraron 31 en: res enmentisy mnemdnicos, Pocos delos problemasque nosotros descubnimos eran como muy llamativas, pero a total habrian supuesto una gran preocupacion en iaprue- bay ejecucion de nuestras aplicacioneslocalizadas, El gemplo descnto antes representa un dispostivo poka-yoke que ha sido integrado en la actividad de pris. bas de ingenieria del software. La técnica poka-yoke puede aplicarse a los niveles de disefio, codificacony pruebas y proporciona un filtro efectivo de garantiade calidad Esta seccidn contiene varios objetivos, siendo el prin- cipal desontbir el cada vez mas importante estandar inter- nacional ISO 9001. El estandar, que ha sido adoptado por mas de 130paises para suuso, se esta convirtienda en el medio principal con el que los clientes pueden juz- garla competencia den desarrollador de software. Uno de los problemas con el estandar ISO 9001 esta en que no es especifico de la industria: esta expresado en ter- minos generales, y puede serinterpretado por losdesa- rrolladores de diversos productos como cojinetes de bolas (rodamientos), secadores de pelo, automéviles, equipamientos deportivos y televisiones, asi como por desarrolladores de software. Se han realizado muchos documentos que relacionan al estandar con la industria del software, pero no entran en una gran cantidad de detalles. El objetivo de esta seccion es descnbir lo que significael ISO 9001 en términos de elementos de cali- dad y técnicas de desarrollo Para la industria del software los estandares rele- vantes son: + 150.9001. Quatity Systems-Modelfor Quality Assu- rance in Design, Development, Production, Insta- ation and Servicing Este es un estandar que describe el sistema de,calidad utilizado para mante- net el desaroo de un producto que mplique deta 1SO 9000-3. Guidelinesfor Applicationof [SO 9001 to the Development, Supply and Maintainance of Software. Este es vin documento especifico que interpreta el ISO 9001 para el desarrollador de soft- ware. + 150 9004-2. Quality Management and Quality Sys- tem Elements —Part 2— Este documento propor ciona las directrices para el servicio de faclidades del software como soporte de usuarios. Los requisitos se agrupan bajo 20 titulos: Responsabilidad de la gestion Inspeccién, medicién y equipo de pruebas. Sistema de calidad. Inspeccién y estado de pruebas Revision de contrato Acai correctiva Control de disefio Control de producto no aceptado. Control de documento Tratamiento, almacenamiento, empaquetamientoy entrega Compras. Producto proporcionado al comprador. Registros de calidad. Identificacieny postbilidad de seguimientodel producto, Auuditorias intemas de calidad. Fommacion Control del proceso Servicios Inspeccion y estado de prueba Técnicas estadisticas. Merece la pena ver un pequeiio extracto de la 180 9001. Este le dara al lector una idea del nivel con el que Ja ISO 9001 trata la garantia de calidad y el proceso de us www.elsalucionaria.net desarrollo, El extracto elegido proviene de le seccién Ll: ALLL Elequipo de Inpecciin, mediciin yprusbas. Elruministradordche controby, calbrary mantener ins- eeckin mediry prebarelequipe, ya sexel due el numinis- ‘tader, prertado 0 proporcionade por el comprador, Pars denostzarh conformidaddelprodurtecon os requistorespe ifcados Elequipe debe utlzarsede wn modo que asegure ‘qe oe conoce ha icertstumbre de b medic y que en com ‘Sttenleconcapacided de medicisn requerida Loprimero a destacer es su generalidad, se puede splices al deserrollador de cuslquier producto. Lo segundo a considerar ese dificulted en la interpreta. CCAPIruLo @ GARANTIA DE CALIDAD DEL SOFTWARE cin del pérrafo —es pretendido obviamente por los procesos esténdar de ingenieria donde equipos tales como indicadores de calibracién y potenciémetros son hnabituales— ‘Uns intespretacién del pérrefo anterior es que el dis tribuidor debe asegurar que cualquierade les herramien- tas de software utilizadas pare las pruebas tiene, por 10 menos, lamisma calidad que el software a desarroller, ¥ que cualquier prucba del equipoprothce valoresde med cion, por ejemplo, los monitoresdel rendimiento, tienen una precisiGn aceptable cuando se compare cone preci- sién especificadapara el rencimiento en le especificacian de losrequisitos Biplan de SQA proporciona wn mapa para institucio- nalizar le garentia de calidaddel software El plan, dese- sdlado por un grupo de SQA, sirve como plantilla pera actividades de SQA instituidas para cada proyecto de softwere Anes EVIEEE [IEEE94]| ha recomendadown esténder para Josplanes de SQA Las seccionesiniciales describen el propésito y el alcance del documento e indicen aque- Ils actividades del proceso del software cubiertas por la garantie de calidad Se listen todos los documentos sefialados en el plan de SQA y se destacen todos los estindres aplicables, Le seccién de Gestidn del plan desenbe la stuacion de la SQA dentro de la estructura ongenizetiva, las tareas y las actividades de SQA su emplezamiento a lo lergo del proceso del software; asi camollos papelesy responsebilidades organizativasrele- tivas ale calidad del producto La seccidin de Documentacién describe (por referen- da) cada uno de los productos de trabajo producidos como parte del proceso de software. Entre estos se incluyen: + documentosdel proyecto (par ejemplo: plan del pro- vyects), «+ modelos (por ejemplo: DERS, jerarquias de clases), + documentostécnicos (por ejemplo: especificaciones, ples de prube), + documentos de usuario (por ejemplo: archivos de ayuda), Ademés, esta seccién define el conjunto minimo de productos de trabajo que se pueden acepter pare lograr alta colidad Los estandares, précticas y conenciones muestran todos los estindares/pricticas que se aplicen durante el proceso de software (por ejemplo: estendares de docu- mentos, esténdares de codificaciény directricesde revi- sién). Ademés, se listen todos los proyectos, procesos y (enalgunos casos) métrices de producto que Sevan areco- ger como parte del trabajo de ingeniesia del software La seccién Revistones y Auditorias del plan identi- ficalesrevisionesy euditorias que se van allever a cabo ppor el equipo de ingenieria del software, el grupo de SQAy el cliente, Proporciona une visién general del enfoque de cada revisién y auditoria La seccién Prueba hace referencia al Planty Procedi- mento de Pruebas del Software (Capitulo 18). También define requisitos de mantenimientode registros de prue- bas. La Jaformacién sobre problemas y acctén correcti- fa define procedimientos pare informer, hacer segui- mientoy resolver erroresy defectos, eidentificalasres- ponsabilidades orgenizetivespara estas actividades Elresto delplan de SQd identifica les herramientas y métodos que soportan actividades y tareas de SQA, hnace referencia alos procecimientos de gestion de con- figuracién del software pera controler el cambio, defi- ne un enfoque de gestion de contratos, etablecemétodos para reunit, salvaguardar Y mantener todoslosregistros, ‘dentificale formacién que se requiere para cumplir las necesidades del plan y define métodos para identificar, evaluar, superviser y controler siesgos. www.elsalucionaria.net_ INGENIERIA DEL SOFTWARE. UN ENFOQUE PaRcT:¢0 Sie ea ee a La gerentia de calidad del software es una «actividad de protecciém que se aplice a cada paso del proceso el software Le SQA comprende procedimientos para 1a aplicacion efective de métodos y herramientas, revi- sionestécnicas formeales,técnicasy estrategias de prue- ba, dispostivospokw-yoke, procedimientos de control de cambios, procedimientos de gerantia de ajuste alos estandares y mecanismos de medida e informacion, La SQAes complicedapor la complejanstureleza de Ja calidad del software —tn atributo de los programas de computadora que se define como «concordanciacon los requisitos definidos explicita e implicitamente»— Cuando se considera de formam és general, la celidaddel software engloba muchos Factores de procesoy de pro- ucto diferentescon sus métricas asociadas. Lesrevisiones del software son una de les activide- des més importantes de le SQA. Las revisiones sirven como filtros durante todas les actividades de ingenieria, el software, eliminando defectos mientras que no son selativamente costosos de encontrar y corregr Larevi- sign técnica formal esuna revisiGn especifica que se ha mostrado extremadamenteefectivaen el descubsimiento de errores. Pore llevar a cabo adecuadamente una garentia de calidad del software, se deben recopilar, evaluar y dis tribuir todos los datos relacionados con el proceso dt ingenieria del software. Le SQA estadistica ayudaa mejorarle calidad del producto Y Ia del proceso de soft ware. Los modelos de fiabilided del softwere emplion Iasmedidas, permitiendo extrapoler los datos recogidos sobre los defectos, apredicciones de tasas de falloy de fiebilidad Resumiendo, recordemos las palabras de Dunn Ull- men [DUNS82|:«La garantie de calidad del softwares Jn guia de los preceptos de gestion y de les disciplinas de disefio de la gerantia de calidad para el espaciotec- nolégico ¥ Ie aplicacién de la ingenteria del softwere) La capacidad pera garantizer la calidad es la medida de moachez de la cisciplina de ingenieria. Cuando se gue de forma adecueda esa guia anteriormente mencions- da, 1o que se obtiene es Ia madurez de Ia ingenieria del software ~REFERENCIAS = j IALV64] von Alvin, W. H. (ed), Reliability Engineering, Prentice-Hall, 1964. [ANS87] ANSI/ASQC A3-1987, Quality Systems Termino logy, 1987 [ART92] Arthur, L. 1. Improving Software Quality: An Insi- der’s Guide to TOM, Wiley, 1992 [ARTQ7} Anthur, LJ

Você também pode gostar