Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
la definicin e importancia de la Calidad de Software. Luego se contina con las definiciones de Control de Calidad y las cti!idades "ue se de#en reali$ar para este control. Por ltimo,se explica de forma extensa el Modelo de Inspeccin de Software con Listas de Compro#acin, considerando "ue este Modelo ayuda a Me%orar el proceso de &esarrollo de software. Palabras claves: Calidad de software, Inspeccin de software, Me%ora del proceso INTRODUCCIN '(u) es la Calidad de software* La Calidad de Software se interpreta de diferentes maneras+ para esto, se tienen definidos !arios modelos de Calidad, Modelo de Cal dad de Mc! Call En -.//, Mc. Call especifica una serie de atri#utos "ue sir!en para tratar de medir la Calidad de Software, "ue 0en s10 trata de asociar 2la calidad a la ausencia de defectos2 en el transcurso del &esarrollo y de la !ida del software. Estos atri#utos est3n di!ididos en, 0 Para la 4peracin 0 Para su 5e!isin 0 Para su 6ransicin 7-8. Modelo de Cal dad de "oe#$ En -./9, :oe;m especifica una serie de !einte atri#utos a ser tomados en cuenta para el &esarrollo de software+ no ;ace una clasificacin de estos atri#utos+ es decir0 no los rene en su# 0categor1as como Mc Call o las <ormas IS4. Entre estos atri#utos est3n, correccin, confia#ilidad, integridad, facilidad de uso, eficacia, facilidad de mantenimiento, flexi#ilidad, reutili$acin, facilidad a ser porta#le, claridad, f3cil de modificar, documentacin, comprensi#ilidad, !alide$, generalidad, econom1a. Nor$a ISO% &'() Esta norma di!ide las caracter1sticas del software en seis, tri#utos de Calidad, Listas de compro#acin,
0 =uncionalidad 0 Confia#ilidad 0 Eficiencia 0 =acilidad de >so 0 =acilidad de ser porta#le 0 =acilidad de Mantener. El alcance de esta norma resulta ser limitada, ya "ue no cuenta con un descripcin de un m)todo de proceso de e!aluacin 7?8. Nor$a ISO%(*+++ ,S-.aRE/ Esta norma proporciona una gu1a para el uso de las nue!as series de est3ndares internacionales, llamadas 5e"uisitos y E!aluacin de Calidad de Productos de Software. Es la unin de dos normas, la IS4 .-?@ y la IS4 -AB.9. El o#%eti!o de esta norma es guiar el desarrollo de los productos de software con la especificacin y e!aluacin de re"uisitos de calidad. Esta#lece criterios para la especificacin de re"uisitos de calidad de productos de software, sus m)tricas y si e!aluacin
7C8
Cada uno de estos modelos esta#lece un compromiso con los desarrolladores en su concepto+ es decir, cual"uier modelo "ue se adopte esta#lecer3 una o#ligacin a cumplir dentro del &esarrollo de software. El cumplimiento estar3 determinado por la utili$acin de las m)tricas definidas para medir el cumplimiento de los atri#utos. Entre los conceptos de Calidad de Software "ue se puede encontrar en la #i#liograf1a est3n, 0 La satisfaccin del cliente es la !alidacin final de la Calidad. La Calidad del proceso, del producto y la satisfaccin del cliente conforman el significado total de la calidad Por lo tanto, la Calidad de Software se puede definir de la siguiente manera, 0 Es el grado en el software satisface una serie de re"uisitos de operacin preesta#lecidos, los est3ndares de &esarrollo especificados y las caracter1sticas in;erentes a todo producto de software desarrollado de manera profesional
7B8 7A8
&e este modo, para "ue la Calidad llegue a cumplirse, se de#e adoptar un proceso de control de calidad. La definicin de este proceso es,
El Control de Calidad es el con%unto de t)cnicas y ac ti!idades de car3cter operati!o, utili$adas para !erifi car los re"uisitos relati!os a la calidad del producto y del ser!icio
7B8
Para lle!ar correctamente este proceso de Control de Calidad, se esta#lece un grupo de personas "ue con forman el 2Drupo de seguramiento de Calidad2. Este grupo tiene las
7@8
siguientes acti!idades principales a reali$ar en el &esarrollo del proceso de software 0 Eerificacin, 5e!isiones formales, auditorias de configuracin y de calidad.
0 Ealidacin, 6odos los ni!eles y fases de prue#a Destin de configuracin, Como medio de control de los productos 0 Medicin de Software, Contempla la necesidad de marcar o#%eti!os y asociar m)tricas a los o#%eti!os. La in!estigacin est3 enfocada a la acti!idad de Eerificacin, tomando como ;erramienta de control las Inspecciones de software "ue conforma el grupo de ;erramientas para la Eerificacin. Este proceso de Inspeccin logra ser aplicado en el todo el transcurso del proceso de &esarrollo 7=igural8. Este proceso puede ser planificado para la re!isin de los re"uisitos "ue se ;an planificado para el &esarrollo o para la re!isin del diseFo de la aplicacin+ tam#i)n, para el plan de prue#as, entre otros. Como se puede !er el proceso de Ins peccin "ue est) #ien definido podr3 ser aplicado en distintas fases de &esarrollo. El primer proceso de Inspeccin de software fue definido por =agan al principio de los aFos /G, para la compaF1a I:M+ eran ex3menes estrictos dirigidos al cdigo fuente.Por esta facilidad "ue da las Inspecciones de software, se considera a este proceso como una ;erramienta para encontrar defectos en tempranas etapas de &esarrollo y el me%oramiento del proceso de &esarrollo. 26rata el producto, pero tam#i)n el proceso de &esarrollo as1 como su propio proceso2 7/8. Como se puede !er en la =igura -, las Inspecciones de Software se pueden planificar y e%ecutar en di!ersas etapas del desarrollo. La e%ecucin de este proceso dar3 como resultado un con%unto de defectos, con los cuales se de#e lograr un an3lisis y conclusiones para la me%ora de los procesos espec1ficos y, de forma general, del proceso de desarrollo de software.
Hay seis metas definidas "ue conforman la pr3ctica de las Inspecciones, -.0 para identificar defectos, ?.0 para estimar la Calidad, C.0 para me%orar la Calidad del producto, A.0 para proporcionar los datos para la me%ora de proceso 7m)tricas8 B.0 para proporcionar los medios para la transferencia del conocimiento y @.0 para me%orar la eficacia del proceso del &esarrollo. La pr3ctica de las Inspecciones se clasifica en tres sis temas, -. cti!idades de Soporte
7Destin del Conocimiento8 "ue ayudan a reali$ar el continuo proceso de Inspeccin, ?. Sistema de :ase de las cti!idades de E!aluacin 7Entidad E!aluadora8 "ue son la esencia de la puesta en pr3ctica del proceso de la Inspeccin y C. cti!idades de la organi$acin 7Entidad8, "ue aseguran la me%ora y organi$acin eficiente del proceso de la Inspeccin. Las cti!idades de Soporte son el 2Soporte con ;erramientas de software2, 2Mantener reglas y las Listas de compro#acin2 y 25efinar la informacin2. El sistema cti!idades incluye, Condiciones pre!ias para la Ins peccin, Plan de la Inspeccin, :uscar los pro#lemas y defectos en los artefactos, Categori$ar los defectos, Construir las correcciones y Concluir la Inspeccin. La 5e!isin del sistema consiste en el resto de las acti!idades, por e%emplo, 4rgani$ar la Inspeccin, Entrenan a los participantes y Esta#lecer y me%orar el proceso de la Inspeccin. MODELO DE INSPECCIN CON LISTAS DE COMPRO"ACIN ,MILCO/ Como consecuencia del estudio y an3lisis de los dis tintos m)todos y anali$ando las dificultades en la pr3ctica de las inspecciones de software, se ;a llegado al siguiente Modelo de Inspeccin de Software con la ayuda de las Listas de Compro#acin, el cual ;a ser!ido de #ase para la automati$acin y est3 #asado en el Modelo de =agan y 6om Dil#.
DESCRIPCIN DEL MODELO MILCO Para comprender el modelo propuesto para las Inspecciones de Software, se descri#e a continuacin cada etapa. Se seFala "ue se di!ide en tres fases, -.Planificacin, Est3 conformada por Planificacin, Preparacin y la 5eunin 53pida+ se define las tareas, documentos y las personas "ue participar3n, ?.0 Eerificacin, "ue est3 conformada por la Eerificacin y la 5eunin de 5egistro+ se aplica las Listas de compro#acin para o#tener una !aloracin del artefacto, y C. 5esultados y Conclusiones+ est3 compuesta por, 5esumen de &efectos, Posi#les Soluciones, Planificacin del Seguimiento y Conclusiones y 5ecomendaciones. PLANIFICACIN La etapa de Planificacin es la parte m3s importante en las Inspecciones de software+ es cuando se define la informacin re"uerida para lle!ar aca#o todo el proceso. ntes de reali$ar la etapa, el Iefe de aseguramiento de Calidad o Coordinador, con%untamente con el &esarrollador, !erifica si el artefacto est3 correctamente terminado y con la informacin necesaria para reali$ar la inspeccin. Es necesaria la siguiente informacin, Se selecciona a los inspectores, con su respecti!o rol 7cargo "ue desempeFar38 y perfil 7l1nea de inspeccin8. La primera persona "ue se seleccionar3 ser3 el Inspeccin8 y no de#en ser menos de tres. Se de#e descri#ir el Proyecto, el cual utili$ar3 las Inspecciones. &e#e descri#irse la Inspeccin, tomando en cuenta la siguiente informacin, <om#re del artefacto, Etapa "ue se encuentra el Proyecto, Est3ndares a utili$ar, Si se lle!ar3 a ca#o sincrnicamente o asincrnica mente, =ec;a de iniciali$acin y finali$acin y Propsito de la inspeccin. Lo ltimo son 5eglas de partida, las cuales ser!ir3n para la preparacin de los inspectores. &e#e definirse los &ocumentos de poyo, los cuales re!iran de apoyo a la Inspeccin. &e#e ser definida cada una de las etapas "ue conforma el Modelo para su e%ecucin. &e#e seleccionarse las Listas de Compro#acin de acuerdo al propsito, el tipo de software, la etapa de&esarrollo y el tipo artefacto. &e#e definirse los pesos correspondientes a cada pregunta y o#%eti!o respecto a los o#%eti!os de la Inspeccin. sesor. Los inspectores no de#en so#repasar el nmero de cinco 7incluyendo al sesor y al Iefe de
PREPARACIN Los Inspectores necesitan un tiempo para la re!isin de los distintos documentos planificados para la Inspeccin, para luego reali$ar una reunin de aproximadamente -B minutos. &e#e de o#tenerse la siguiente informacin, Captura del 6iempo de Preparacin por cada inspector. REUNIN R:PIDA El primer encuentro del e"uipo de inspeccin es una 5eunin 53pida, "ue de#e estar planificada. Se aclaran puntos di!ersos "ue no ;an sido entendidos en la documentacin de apoyo y puntos ol!idados "ue no se ;an tomado en cuenta en la Planificacin.Esta reunin de#e durar alrededor de -B minutos, suficientes para la discusin de los o#%eti!os y propsitos de la Inspeccin, "ue ya est3 planificada. Como seFala el Modelo de 6om Dil#, el propsito fundamental de la reunin es conocer los o#%eti!os de la inspeccin y cmo se la !a a reali$ar. La informacin "ue de#e capturarse es la siguiente, Modificaciones de la agenda Eliminacin o adicinde documentos de apoyo dicin o modificacinde las Listas de Compro#acin a ser utili$adas
;ERIFICACIN ASINCRNICA < E;ALUACIN DISTRI"UIDA >na de las !ariantes de las inspecciones es la sincrnica, la cual tiene muc;a utilidad cuando el artefacto es muy extenso o cuando el personal de la empresa "ue desarrolla software es muy limitado 7.8.La caracter1stica es "ue el inspector es "uien es coge el tiempo de iniciali$acin para la Eerificacin del artefacto+ esto "uiere decir "ue puede iniciar la Eerificacin en cual"uier momento o lugar sin tomar en cuenta los dem3s inspectores y es distri#uida, por"ue cada inspector tiene la opcin de !er los defectos en contrados por otro inspector, en el momento cuando reali$a la Eerificacin.En este momento, se emplean las Listas de Compro#acin planificadas en la etapa de Planificacin, sir!iendo al inspector como una gu1a y recurso para los detalles del artefacto en Inspeccin. El inspector, al efectuar la lectura a cada una de las preguntas de las Listas de Compro#acin y !erificando la conformidad de cada una de )stas, efecta una !aloracin de acuerdo a su preparacin, experiencia y !isin, para luego reali$ar un resumen de los defectos "ue, a su parecer, se encuentran en el artefacto. &e esta forma, al culminar con la Eerificacin se tiene los posi#les defectos "ue ser!ir3n como partida para la 5eunin de 5egistro.
La informacin "ue se genera ser3 por cada inspector, "uien participe en la Eerificacin, es la siguiente, Se o#tiene Listas de Compro#acin correctamente !erificadas y con los posi#les defectos en el artefacto. Se o#tiene ;ora y d1a de inicio de la Eerificacin por cada inspector. Se o#tiene el nmero de defectos y o#ser!aciones por cada inspector. Se registra el tiempo empleado para la e!aluacin por cada inspector. Se o#tiene la !aloracin de la Lista de Compro#acin por cada inspector.
;ERIFICACIN SINCRNICA < E;ALUACIN CON=UNTA La Inspeccin Sincrnica y E!aluacin Con%unta son tam#i)n una !ariante de las inspecciones. 6odos los inspectores participan en la Inspeccin del artefacto en un mismo tiempo y lugar, encontrando los defectos y comentando cada uno de )stos+ por este moti!o, de#e asignarse a un notador para "ue !aya tomando nota de todas las o#ser!aciones y defectos encontrados a tra!)s de las Listas de Compro#acin, utili$adas para esta situacin. La informacin generada es por el grupo de inspeccin es la siguiente, Se o#tiene Listas de Compro#acin correctamente !erificadas y una Lista de &efectos encontrados en el artefacto. Se registra ;ora y d1a de inicio de la Eerificacin. Se o#tiene el nmero de defectos y o#ser!aciones. reali$a un conteo de los defectos encontrados. Se registra el tiempo empleado en la Eerificacin. Se o#tiene la e!aluacin de cada una de las Listas de compro#acin. REUNIN DE REGISTRO Cuando la Inspeccin fue reali$ada asincrnicamente, el Iefe de Inspeccin, el sesor y el l finali$ar la Eerificacin, se
notador reali$an un resumen de los defectos encontrados por los dem3s inspectores, para luego %untamente con el coordinador discutir los defectos y clasificarlos por gra!edad. La participacin del &esarrollador en esta etapa es muy importante, ya "ue )l !a entendiendo la realidad de los defectos encontrados, para luego corregir cada uno de ellos. <o es o#ligatoria la participacin del desarrollador en esta etapa. La informacin "ue se genera es la siguiente,
Se o#tiene un resumen parcial de defectos. Se o#tiene una clasificacin de los defectos encontrados por la gra!edad "ue considera "ue tienen.
RESUMEN DE DEFECTOS Pasada la 5eunin de 5egistro, se o#tiene un 5esumen de &efectos "ue es considerado por el Iefe de Inspeccin, el cual %untamente con el corregir los defectos. La informacin "ue se genera es, Se o#tiene un resumen de defectos ordenados por la gra!edad para el artefacto inspeccionado. Se o#tiene una lista de personas "ue ayudar3n a la reconstruccin del artefacto. sesor discuten si es necesaria la participacin de personas con experiencias o formadas profesionalmente para reconstruir el artefacto y
POSI"LES SOLUCIONES A DEFECTOS >na !e$ "ue se o#tiene la clasificacin de los defectos muy gra!es, se reali$a una reunin con personas con experiencia, dirigida por Iefe de Inspeccin %untamente con el &esarrollador y el sesor reali$ando una tormenta de ideas, tratando de ayudar al desarrollador para la correccin de cada uno de los defectos gra!es. La informacin "ue se genera es la siguiente, Se o#tiene o#ser!aciones de solucin por cada defecto gra!e. Se o#tiene un informe general de la Inspeccin.
PLANIFICACIN DEL SEGUIMIENTO &e acuerdo con las o#ser!aciones por cada defecto, se planifica un tiempo de reconstruccin y la asigna cin de las personas "ue participaran en la reconstruccin. La informacin necesaria es la siguiente, Se de#e anali$ar el nmero de personas a reali$ar la reconstruccin. Se de#e especificar el tiempo de reconstruccin.
Puede existir una peticin de cam#io, la cual de#e ser controlada por la Destin de Configuracin de Software.
CONCLUSIONES < RESULTADOS Esta etapa forma parte del Modelo de Inspeccin propuesto+ es la etapa final. La Inspeccin de un artefacto finali$a cuando los defectos encontrados fueron corregidos por el desarrollador. El Iefe de seguramiento de Calidad tiene la la#or de anali$ar las m)tricas para esta#lecer me%oras en el proceso de Inspeccin. ROLES EN LA INSPECCIN Los siguientes roles son necesarios para lle!ar a ca#o una correcta Inspeccin de software, =e6e de Ase>.ra$ e37o de Cal dad o Coord 3ador &e#e cumplir las siguientes tareas en el proceso de Inspeccin, Eerificar "ue el producto cumple los criterios de entrada &eterminar la necesidad de una sesin de adiestramiento Seleccionar a los dem3s inspectores y al asesor Programar la fec;a, ;ora y lugar de las reuniones Preparar y distri#uir la notificacin de la inspeccin a todo el e"uipo 4rgani$ar, anunciar y conducir la reunin de presentacin
Asesor &e#e cumplir las siguientes tareas en el proceso de Inspeccin, yudar a la preparacin de la inspeccin poyar al grupo de inspectores en el momento de la Inspeccin
A3o7ador &e#e cumplir las siguientes tareas en el proceso de Inspeccin, &e#e lle!ar un resumen detallado de los posi#les defectos encontrados. En la reunin de registro, de#e ela#orar el resumen de defectos.
Lec7or &e#e cumplir las siguientes tareas en el proceso de Inspeccin, Es parte de los inspectores. Leer las Listas de compro#acin en la etapa de Eerificacin. yudar al Iefe de Inspeccin a cumplir los est3ndares y reglas.
Desarrollador &e#e cumplir las siguientes tareas en el proceso de Inspeccin, 5ecopilar todos los documentos necesarios para la Inspeccin del artefacto. =acilitar y distri#uir la documentacin al resto de los participantes. 5ecomendar o no la reali$acin de una sesin de presentacin y explicacin del producto. &iscusin de los defectos encontrados en la reunin de registro.
=e6e de I3s4ecc ?3 &e#e cumplir las siguientes tareas en el proceso de Inspeccin, &e#e lle!ar a ca#o la reunin de registro. poyar a los inspectores en la deteccin de los defectos. Eerificar "ue se cumplen los est3ndares y reglas. Ela#orar %untamente con el anotador el resumen de defectos. Eerificar "ue se cumpla la agenda planificada 7;oras y fec;as8.
I3s4ec7or &e#e cumplir las siguientes tareas en el proceso de Inspeccin, Estudiar el material y documentacin de apoyo en tregado. >tili$ar Listas de Compro#acin para detectar defectos. notar y calcular el tiempo empleado de preparacin.
LAS LISTAS DE COMPRO"ACIN COMO @ERRAMIENTA DE LAS INSPECCIONES Las Listas de Compro#acin son muy ricas para la me%ora del proceso de Inspeccin y para el proceso en general de software. &e#e asegurar "ue los principios y est3ndares sean considerados en todo el &esarrollo del software 7ciclo de !ida e ;itos del Proyecto8+ tam#i)n, de#e ayudar a pre!enir, descu#rir y corregir los defectos en los artefactos para pre!er su #uen funcionamiento y "ue permita la re!isin con!eniente, #arata y pertinente de las pr3cticas de la tecnolog1a y la lgica del Proyecto+ adem3s, de#e dar una !aloracin de la calidad del producto. La aplicacin de una Lista de Compro#acin puede durar entre una ;ora y dos ;oras. El %uicio del l1der del e"uipo, generalmente el Iefe de seguramiento de Calidad, se acepta sin la e!idencia de examinar los productos de la pr3ctica o del tra#a%o+ sin em#argo, la e!idencia, tal como la documentacin, "ue podr1a ser proporcionada se de#e anotar expl1citamente en la Lista de Compro#acin. >sando la Lista de Compro#acin en inter!alos regulares, el l1der de Proyecto puede medir el mo!imiento ;acia las pr3cticas recomendadas. En general, las preguntas de las Listas de Compro#acin cu#ren, Compromiso del Proyecto con las metodolog1as o m)todos Capacidad del Proyecto de satisfacer los est3ndares Pr3cticas y acti!idades relacionadas Seguimiento de los o#%eti!os del Proyecto &eteccin de los defectos cometidos en el ciclo de !ida El crecimiento paulatino de la madure$ en el proceso El aumento paulatino de la cultura en el &esarrollo de software de los empleados
Por todo esto, las Listas de Compro#acin son una ;erramienta para las Inspecciones de software, las cuales est3n al alcance de las organi$aciones "ue inician la transformacin ;acia un ni!el superior de organi$acin y de garant1a de Calidad.
La renta#ilidad m3s grande de las Listas de Compro#acin es "ue ayudan a identificar defectos importantes en tempranas etapas de &esarrollo. >n defecto detectado por las Listas de Compro#acin de#e ser tratado, por lo general, por la Destin de Software, reali$ando una peticin de cam#io, "ue puede ser de modificacin, extensin o correccin de errores del software. REGLAS DE LAS LISTAS DE COMPRO"ACIN l iniciar dentro de la empresa el Proceso de Inspeccin, con el propsito de me%orar el Proceso de Software, )ste no ser3 muy riguroso ya "ue las Listas de Compro#acin no ser3n las m3s explicitas, exactas y rigurosas, pues el proceso de Inspeccin me%orar3 a medida "ue se apli"ue. Por este moti!o, las Listas de Compro#acin siguen las siguientes reglas para su creacin, >na Lista de Compro#acin de#e deri!arse del sistema de reglas generales del producto en &esarrollo. Cada pregunta de la Lista de Compro#acin de#e incluir una referencia a la eti"ueta de la regla "ue interpreta dentro de un est3ndar o reglamentos internos de la empresa desarrolladora. Las Listas de Compro#acin de#en ser actuali$adas cuando sea necesario para refle%ar el descu#rimiento de los defectos importantes no incluidos ;asta este momento. Las preguntas y o#%eti!os para una Lista de Compro#acin no de#e exceder de una sola p3gina f1sica. Las descripciones de las preguntas y o#%eti!os de la Lista de Compro#acin pueden incluir las sugerencias para la se!eridad pro#a#le del defecto. Est3 generalmente redactada cada pregunta, pero no necesariamente para "ue una respuesta negati!a identifi"ue un defecto. Las preguntas de la Lista de Compro#acin de#en concentrarse en di!ulgar defectos importantes. Los resultados de la Lista de Compro#acin no de#e emplearse de mala forma para definir una nue!a regla7-G8. CONCLUSIONES Las Inspecciones de software ;an sido y son una ;erramienta "ue ;a ayudado a me%orar el proceso de &esarrollo de software, siendo )stas una de las ;erramientas de control m3s utili$adas. La in!estigacin ;a permitido conocer los distintos m)todos y ;erramientas para este
proceso de Inspeccin. Este conocimiento ;a ser!ido para adaptar un Modelo de Inspeccin al entorno actual de &esarrollo "ue tiene la >ni!ersidad. dicionalmente, se ;a logrado definir y clasificar Lis tas de Compro#acin "ue ayudan a detectar defectos y !er los errores "ue se comente en el &esarrollo. El futuro de esta in!estigacin es adaptar el modelo al entorno acad)mico y sir!a para "ue los estudiantes cono$can una ;erramienta de control en el entorno de &esarrollo "ue se les presente.
REFERENCIAS "I"LIOGR:FICAS
J-K Iose Ia!ier &olado Cosin, :re!es notas so#re la medicin ce los atri#utos externos del software, >ni !ersidad del Pais Easco, EspaFa, ?GGA. J LinLs K
J?K <ally Condori =ernande$, Modelo de agregacin #asado en un sistema neurodifuso para un proceso de e!aluacin de calidad de software, >ni!ersidad <acio nal de San gust1n, Per, ?GG?. J LinLs K
JCK Comunidad IS4 ?BGGG, Calidad el producto de soft ware y la norma IS4MIEC ?BGGG, Comunidad IS40?BGGG,;ttp,MMiso?BGGG.comM, ?GG.. J LinLs K
JAK Sergio Napara, Herramientas de me%ora del proceso de &esarrollo, >ni!ersidad <acional de San Iuan, Ins tituto de Inform3tica, ;ttp,MMwww.idei0uns%.com.arM, rgentina, ?GG-. J LinLs K
JBK IoseIa!iar &orado y Luis =ernande$ San$, Medi cion para la Destion de la Ingenier1a de Software, 5a Ma, EspaFa, ?GGG. J LinLs K
J@K Da#riel :uades, Calidad en la Ingenier1a de soft ware, >ni!ersidad de las Illes :alears, &epartamento de ?GG?. J LinLs K =ilter Prototype0 Ciencias Matem3ticas e Inform3tica, ;ttp,MMdmi.ui#.esMO##uadesMcalidadMsldGG-.;tm, EspaFa,
J9K IlLLa6er!onen, >ni!ersity of 4ulu, &epartament of Information Processing Science, Canada, ?GG-. J LinLs K Software Inspection Process &efinition Language and Prototype
Support 6ool, 6;e >ni!ersity of Strat;clyde in Dlasgow, Computer and Sciences,;ttp,MMwww.cis.strat;.ac.uLMcisMresearc;Mpu#licationsMindex.p;p, -../. J LinLs K
J-GK &on Mills, &ocument (uality Control #y Inspec tion,SPIParners, ;ttp,MMwww.spipartners.nlMdataM, 6;e <et;erlands, ?GG@. J LinLs K