Universidad Nacional
Jos Faustino Snchez
Carrin


Facultad de
Ingeniera
Escuela Acadmico Profesional
de Ingeniera de Sistemas
Escuela Acadmico Profesional
de Ingeniera Informtica

&8562


7(0$


7RPDGRSRU


6(*85,'$'<$8',725,$(1
&20387$&,1<6,67(0$6
$8',725$'(/$&$/,'$'
(Indicado en la siguiente pgina)

7,78/$&,21

,

6(0$1$



)8(17(:


MARIO

G.

PIATINNI,

EMILIO

PESO.

AUDITORIA INFORMATICA

UN

ENFOQUE

PRCTICO.

EDITORIAL ALFAOMEGA 1996

/(&785$: AUDITORIA DE LA CALIDAD
 

PAG 361 - 388

DE

&$378/2

$8',725$'(/$&$/,'$'
35(0%8/2

-RVp/XLV/XFHUR0DQUHVD

La calidad ha dejado de ser un tpico, y forma parte, es necesario que

forme parte, de los productos o servicios que comercializamos para nuestros
clientes. Est incorporada en nuestra forma de ver la vida. Cada vez exigimos
ms que los productos o servicios que nos suministran nuestros proveedores
tengan el mayor grado de calidad dentro de un precio razonable. El aforismo de
El precio se olvida y la calidad perdura se hace cada vez ms patente.
El cliente es el mejor auditor de la Calidad, l exige el nivel que est
dispuesto a pagar por ella, pero no ms. Por tanto, debemos de cuantificar cul
es el nivel de Calidad que nos exige para poder planificar la Calidad de los
productos semielaborados que se generen a lo largo del proceso de produccin
del producto o servicio final.
Al analizar las necesidades de nuestros clientes, deberemos tener en
cuenta tambin la previsible evolucin de sus necesidades y tendencias en
cuanto a caractersticas. Deberemos tener en cuenta la evolucin tecnolgica
del entorno de produccin de nuestros productos para suministrarlos con el
nivel tecnolgico adecuado. No debemos olvidar tampoco el nivel de Calidad
de nuestros competidores, debiendo elaborar productos cuyas caractersticas y
funcionalidades sean competitivas con las de nuestros competidores, as como
su calidad.
La Calidad se ha convertido en el medio de subsistir dentro de un mercado
competitivo, lo cual beneficia al consumidor final, es decir, a nosotros. Es el
primer filtro lgico por el que las empresas prevalecen en el mercado, el
segundo ser la productividad que emplean para conseguir esa calidad.


La Calidad ser el objetivo global a conseguir, y la Productividad nos vendr
por aadidura, nunca al revs.

'(),1,&,21(635(9,$6
Vamos a citar algunas definiciones de varios autores que nos ayudarn a
centrar lo que se entiende por calidad:

J.M. JURAN: Adecuacin al uso.

P.B. CROSBY: Cumplimiento de unas especificaciones.

W.E. DEMING: Un grado predecible de uniformidad y fiabilidad a bajo coste

y adecuado. a las necesidades del mercado.

G.TAGUCHI: Prdidas mnimas para la sociedad en la vida del producto.

FEIGENBAUM: Conjunto de caractersticas del producto de marketing,

ingeniera, fabricacin y mantenimiento a travs del cual el producto en uso
satisface las expectativas del cliente.

P. DRUCKER: Calidad es lo que el cliente est dispuesto a pagar en

funcin de lo que obtiene y valora.

AEC (Asociacin Espaola para la Calidad): Conjunto de propiedades y

caractersticas de un producto o servicio que le confiere su aptitud para
satisfacer necesidades establecidas o implcitas.
Los Sistemas de Informacin cada vez estn ms presentes en nuestra

actividad y en las cosas que nos rodean y que usamos. Simplemente recordar
que cuando vamos a m banco cualquier operacin que hacemos tiene detrs
un Sistema de Informacin, al nacemos un seguro, al comprar en un
supermercado o en unos grandes almacenes, al pagar con nuestra tarjeta de
crdito, en todos los casos hay un Sistema de Informacin que est
controlando y gestionando esas operaciones. Incluso al arrancar nuestro coche
hay un software que chequea los puntos vitales del mismo.
En este captulo vamos a centrar nuestro foco en la Calidad del Software y
podemos recordar la definicin que encontramos en Pressman:

Concordancia con los requisitos funcionales y de rendimiento explcitamente

establecidos,

FRQ

ORV

HVWiQGDUHV

GH

GHVDUUROOR

H[SOtFLWDPHQWH

GRFXPHQWDGRV \ con las caractersticas implcitas que se espera de todo

software desarrollado profesionalmente.

En esta definicin podemos destacar qu se entiende por calidad, el

cumplimiento los requerimientos que se han establecido (normalmente por el
usuario o el cliente) las caractersticas implcitas que debe cumplir todo
software hecho profesionalmente aparte de su realizacin segn unos

determinados estndares. Es decir, que 

adems de cumplir con las especificaciones que nos ha dado el cliente o el

usuario, debe cumplir con otras caractersticas que se dan por sobreentendido
que estn dentro del saber hacer de un buen profesional y que no estn
especficamente explicitadas.
En muchas ocasiones, esta circunstancia no se da, y algunos
desarrolladores de dudosa profesionalidad se parapetan tras la frase: de eso
no se dieron especificaciones, para ocultar una falta de previsin o una
carencia de habilidad para obtener del usuario en las entrevistas la informacin
necesaria para completar y complementar los requerimientos funcionales.
 ,1752'8&&,1

Al decidir acometer la realizacin de un producto software, deberemos

hacer una planificacin, y entre otros, habr que hacer un Plan de Calidad
especfico para ese producto.
En el centro de produccin de software, deber haber un Plan General de
Calidad en el que estarn las especificaciones para poder definir cada uno de
los Planes especficos de nuestros desarrollos en funcin de los atributos de
Calidad que deseamos implementar en el software.
En este Plan se definen las actividades de Calidad que se tienen que
realizar, en qu momentos tiene que intervenir la funcin de Aseguramiento de
la Calidad, que a diferencia del Control de Calidad intervendr proponiendo y
supervisando los procesos de calidad a realizar en la fase de generacin de los
distintos componentes, adherencia a estndares, y la intensidad de aplicacin
de la misma segn la criticidad de los productos y el nivel de riesgos que se
haya encontrado en la evaluacin del sistema.

Dentro de este captulo, como no podra ser menos, QRVvamos a referir a

una serie de normas que afectan a su contenido, y en algunos casos

incorporaremos algunos de sus prrafos o apartados completos.
En el caso de los procesos de revisiones de calidad, tenemos la norma
IEEE Standard 1028 for Software Reviews and Audits.

El objeto de esta norma es definir los requerimientos para los procesos de

revisin y auditora. No est dentro de su cometido el establecer cundo se
necesita realizar un proceso de revisin o de auditora, quedando determinado
este aspecto dentro de los Planes de Aseguramiento de la Calidad especficos
de cada Organizacin, segn se ha indicado anteriormente.
En dicha norma da las siguientes definiciones:
5HYLVLyQ

Es una evaluacin del elemento o elementos software o estado del proyecto

que investiga las discrepancias con los resultados planificados y las mejoras
recomendadas. Esta evaluacin sigue un proceso formal (por ejemplo, proceso
de revisin de gestin, proceso de revisin tcnica, proceso de inspeccin de

software, o proceso de ZDONWKURXJK

(OHPHQWRVRIWZDUH

Es un producto entregable o un documento producido- durante el proceso o

adquirido durante- el -desarrollo o mantenimiento del software. Algunos
ejemplos pueden ser:
1. Documentos de Planificacin del proyecto (por ejemplo, planes del
desarrollo del software y planes de verificacin y validacin del software).
2. Especificaciones de requerimientos y diseo del software.
3. Documentacin del esfuerzo de las pruebas.
4. Documentacin suministrable al cliente.
5. Cdigo fuente de los programas.
6. Representacin de las soluciones software implementadas en el firmware.
7. Informes (por ejemplo, revisiones, auditorias y estado del proyecto) y datos
(por ejemplo, deteccin de defectos, pruebas).

$XGLWRUtD

Es una evaluacin independiente de los procesos, los productos software, el

progreso del proyecto o el cmo se realiza el trabajo, que investiga la
coincidencia con, estndares, lneas gua, especificaciones y procedimientos
basados en criterios objetivos que incluyen los documentos que especifican:
1. La forma o contenido de los productos a producir.
2. Los procesos en los que los productos deben ser producidos.
3. Cmo debe ser medida la adherencia con los estndares o lneas gua.
Tambin incluimos otras definiciones segn la EEA

&RQFHSWRGHHYDOXDFLyQVHJ~QOD(($
Es el proceso de recoleccin y anlisis de informacin, y a partir de ella
presentar las recomendaciones que facilitarn la toma de decisiones. Las
decisiones resultantes de esta evaluacin o valoracin pueden dar lugar a:

Autorizacin para proceder con un proyecto.

Aprobacin para incluir en las listas a nuevos contratistas o suministradores.

Defensa de la aprobacin de un contratista.

&RQFHSWRGH$XGLWRUtDVHJ~QOD(($

Es una herramienta de valoracin. Es un documento interpersonal de examen y

anlisis de evidencias objetivas. A los efectos del control de la calidad, una
auditora no incluye vigilancia o inspeccin con el objeto de un control de
calidad.
Debe reconocer que slo una muestra de la informacin disponible puede ser
examinada. Que es importante que el tamao de la muestra de la auditora
aporte la confianza suficiente en las recomendaciones finales.

&$5$&7(567,&$6'(/$&$/,'$'6(*1
Antes de detallar los Procesos de Calidad, vamos a describir los

componentes de una especificacin de calidad del software segn el modelo

definido en la norma 150 9126 y el modelo extendido 150 para la Calidad del
Software.

&DUDFWHUtVWLFDV
Segn la citada norma ISO 9126, define las caractersticas de calidad

como Un conjunto de atributos del producto software a travs de los cuales la

calidad es descrita y evaluada. Las caractersticas de calidad del software
pueden ser precisadas a travs de mltiples niveles de subcaractersticas.
Dicha norma define seis caractersticas:

)XQFLRQDOLGDG Conjunto de atributos que se refieren a la existencia de un

conjunto de funciones y sus propiedades especficas. Las funciones son tales

que cumplen unos requerimientos o satisfacen unas necesidades implcitas.

)LDELOLGDG Conjunto de atributos que se refieren a la capacidad del software

de mantener su nivel de rendimiento bajo unas condiciones especificadas

durante un p2rodo definido.

8VDELOLGDG Conjunto de atributos que se refieren al esfuerzo necesario para

usarlo, y sobre la valoracin individual de tal uso, por un conjunto de usuarios

definidos o implcitos.

(ILFLHQFLDConjunto de atributos que se refieren a las relaciones entre el nivel

de rendimiento del software y la cantidad de recursos utilizados bajo unas
condiciones predefinidas.

0DQWHQLELOLGDG Conjunto de atributos que se refieren al esfuerzo necesario

para hacer modificaciones especificadas.

3RUWDELOLGDGConjunto de atributos que se refieren a la habilidad del software

para ser transferido desde un entorno a otro.
La norma incluye un anexo en el que desglosa en un conjunto de
subcaractersticas cada una de las caractersticas anteriormente citadas. Este
anexo puede considerarse informativo y no como parte oficial del estndar ISO
9126.
El prefijo sub nos hace destacar un importante aspecto del modelo ISO 9126:
La calidad es modelizada en forma jerrquica. En la figura adjunta se incluye
una representacin de este modelo jerrquico.
MODELO ISO 9126

FUNCIONALIDAD

FIABILIDAD

USABILIDAD

MADUREZ
TOLERANCIA A

APTITUD

FALLOS

PRESICIN
INTEROPERATIVIDAD






RECUPERABILIDAD

EFICIENCIA

MANTENIBILIDAD

PORTABILIDAD

RESPECTO AL
TRABAJO

FACILIDAD DE ANALISIS

RESPECTO A KLOS

FACILIDAD DE CAMBIO

RECURSOS

ESTABILIDAD
FACILIDAD DE PRUEBA

CONFORMIDAD
SEGURIDAD
ADAPTABILIADAD
COMPRENSIBILIDAD

FACILIDAD DE INSTALACIN

FACILIDAD APRENDIZAJE

CONFORMIDAD

OPERATIVIDAD

REEMPLAZABILIDAD

 0RGHOR,62([WHQGLGR
El modelo ISO Extendido incluye al modelo ISO 9126 adicionando doce
caractersticas ms, segn se expone en la figura adjunta.
MODELO ISO 9126

FUNCIONALIDAD

FIABILIDAD

USABILIDAD

MADUREZ
TOLERANCIA A

APTITUD

FALLOS

PRESICIN
INTEROPERATIVIDAD
CONFORMIDAD

RECUPERABILIDAD

EFICIENCIA

MANTENIBILIDAD

PORTABILIDAD

RESPECTO AL
TRABAJO

FACILIDAD DE ANALISIS

RESPECTO A KLOS

FACILIDAD DE CAMBIO

RECURSOS

ESTABILIDAD
FACILIDAD DE PRUEBA

DISPONIBILIDAD
DEGRADABILIDAD

SEGURIDAD

ADAPTABILIADAD

TRAZABILIDAD
COMPRENSIBILIDAD

FACILIDAD DE INSTALACIN

FACILIDAD APRENDIZAJE

CONFORMIDAD

OPERATIVIDAD

REEMPLAZABILIDAD

EXPLICITUD
ADAPTABILIDAD AL USUARIO
ATRACTIVIDAD

La valoracin de estas caractersticas es til para que el usuario pueda definir

los requerimientos del producto utilizando solamente las caractersticas que
emplee en la prctica.
Para algunos tipos de productos, hay determinadas caractersticas que no son
significativas, y las restantes no garantizan que con ellas comprendan todos los
requerimientos de los productos, por lo que en cada caso habr que
completarlas con otras definiciones ms especficas para esos productos o
situaciones.
No obstante el modelo tiene el nivel de abstraccin suficiente como para que
sea adaptable en la mayora de las situaciones, siendo, adems, independiente
de la tecnologa.
Las caractersticas no pueden ser cuantificadas como tales, y para
cuantificarlas en alguna forma, usaremos los Indicadores.
Para usar los indicadores, deberemos definir un Protocolo, de forma que
mediante dicho protocolo podamos establecer la medida de la caracterstica
repetible. Este protocolo nos describir los pasos que hay que dar para
conseguir obtener esta medida de forma tal que en las mismas situaciones

obtengamos idnticos resultados.

Los indicadores que se describen en el modelo ISO Extendido, sirven como
punto de partida, no queriendo decir que esa lista sea completa. En ella se
pretenden presentar ideas para poder definir las especificaciones de calidad,
siendo muy importante seleccionar los indicadores que mejor se ajusten a la
situacin de nuestro proyecto o producto.
El protocolo de medida tiene como objetivo el reproducir los resultados de
las mediciones de los indicadores. Segn se ha indicado anteriormente, al
describir los requerimientos de la calidad del software, se corre el peligro de
una interpretacin subjetiva del significado de calidad. Es, por tanto, de gran
importancia acordar de una forma clara cmo medir los indicadores de forma
que esta medida sea reproducible con los mismos resultados.
Ejemplo2:
Si deseamos medir el atributo Facilidad de aprendizaje, que podemos definir
como el esfuerzo de los usuarios para aprender a manejar una aplicacin.
Podramos hacer una cuantificacin fcil, si pudiramos medir de una forma
objetiva un factor de Facilidad de aprendizaje de 7 sobre 10, pero ste no sera
muy descriptivo ni til.

Podemos buscar un LQGLFDGRU de este atributo que estuviera presente en el

producto software. Este indicador debe- estar acompaado del 3URWRFROR de

medida
que describa los pasos a dar para asegurar la repetitividad de la medida.
En este ejemplo hemos tomado como indicador el tiempo medio de
aprendizaje, siendo el tiempo promedio que el usuario final de un determinado
grupo necesita para aprender a trabajar con el producto software, ms el
tiempo necesario de tutelaje.
El protocolo sera:
1. Seleccin de un grupo representativo de usuarios.
2. Preparacin de un curso para este grupo, diseado para este producto
software, o dar a este grupo la oportunidad de auto-enseanza del
producto.
3. Definicin del tiempo del curso o de la auto-enseanza, ms el tiempo de
tutelaje necesario para conseguir su manejo o pasar con xito un test.
4. Clculo del nmero medio de horas.

Los valores obtenidos de las caractersticas se pueden representar en un

diagrama de Kiviat segn se muestra en la figura, en el que en cada radio nos
mostrara el valor de una caracterstica.
El valor de los indicadores depende del propsito de la especificacin de
calidad, pudiendo definirse diferentes valores. Es aconsejable usar una
plantilla con estos valores. A continuacin se expone un pequeo ejemplo de
este tipo de plantilla3.

3HRU El peor lmite aceptable de la escala, tal como un fallo total del sistema.

3ODQLILFDGR Valor esperado del indicador que se considera un xito.

5pFRUG Mximo valor terico o prctico de un indicador, valor lmite pero no

un requerimiento esperado.

$FWXDO Valor actual del indicador - en el. sistema que se- est considerando a
-efectos de posibles comparaciones.
Como experiencia prctica del uso del modelo ISO Extendido tenemos la
realizada por las compaas participantes en el proyecto QUINT (Quality in
information Technology)4 cuyo primer proyecto empez en 1991, siendo su
objetivo el desarrollar un modelo y una gua para las especificaciones de
calidad del software, participando todas las partes involucradas en la
negociacin sobre los requerimientos.
El segundo proyecto QUINT expandi los resultados del primero. En l
participaron seis compaas bajo la direccin de los institutos de investigacin
SERC, TNO/TPD y FPIQM.

2%-(7,926'(/$6$8',725$6'(&$/,'$'
Una auditora de Calidad tiene como objetivo el mostrar la situacin real para

aportar confianza y destacar las reas que pueden afectar adversamente esa
confianza.
Hay varias razones para realizar una auditora:

Establecer el estado de un proyecto.

Verificar la capacidad de realizar o continuar un trabajo especfico.

Verificar qu elementos aplicables del programa o Plan de Aseguramiento

de la Calidad han sido desarrollados y documentados.

Verificar la adherencia de esos elementos con el programa o Plan de

Aseguramiento de la Calidad.

El propsito y la actividad de la auditora es recoger, examinar y analizar la

informacin necesaria para tomar las decisiones de aprobacin.

La auditora debe tener capacidad para investigar la pericia tcnica, el
desarrollo del software o la capacidad del departamento de desarrollo, el
esfuerzo disponible, el soporte del mantenimiento o la efectividad de la gestin.
En las auditorias debe acordarse el dirigirse a criterios especficos tales como
la realizacin del cdigo software.
Cuando se identifiquen los puntos dbiles, los auditores debern tomar una
actitud positiva y utilizar sus conocimientos y experiencia para hacer
recomendaciones constructivas. En realidad, una funcin del auditor es pactar
la idoneidad de cualquier accin correctiva propuesta. Este papel, si es usado
adecuadamente, es uno de los vnculos ms valorados entre las partes.
352&(626'(&$/,'$'

En el entorno econmico actual, la caracterstica ms importante es la

competitividad, lo que quiere decir que los precios a los que ofrezcamos
nuestros productos a nuestros clientes deben ser iguales o ms bajos que los
de la competencia, pero con una calidad ms alta. Para conseguirlo es
necesario tener una estructura de costes adecuada y disponer de una
estrategia de Calidad que afecte a todas las reas de la entidad u organismo.
Para satisfacer los requisitos de calidad es necesario conocer las Necesidades
del Cliente. stas vienen dadas por estos tres parmetros:
Calidad de los productos y servicios.
Plazo de entrega adecuado.
Coste dentro de los lmites fijados.
El establecimiento de acuerdos de Nivel de Servicio y el cumplimiento de sus
requerimientos le dar un determinado grado de satisfaccin, que deberemos
saber medir sobre todo una vez pasado el perodo de estabilizacin del
producto entregado.
Una de las principales caractersticas de los procesos de calidad es la
repetitividad de los mismos. Todo proceso debe estar suficientemente definido
como para que pueda ser repetido consiguiendo los mismos resultados cada
vez que se realice el mismo proceso. La idea Sigma est unida a la
variabilidad de un proceso.
Una vez alcanzada esta repetitividad de los procesos y teniendo elementos
para medir los atributos de los productos obtenidos, trataremos de ir refinando

el modelo del proceso para reducir los defectos entregados (definiendo defecto
como cualquier variacin de una caracterstica establecida que origina el
incumplimiento de las necesidades del cliente con la consiguiente insatisfaccin
del mismo).
Como se ha indicado anteriormente, las revisiones y las auditorias pueden
usarse para actividades de aseguramiento de la calidad, gestin de proyectos,
gestin de la configuracin o funciones de control singulares.
Segn el estndar IEEE 1028, incluimos una tabla en la que se sealan los
principales Procesos para conseguir Objetivos de Calidad.
35,1&,3$/(6352&(6263$5$&216(*8,52%-(7,926'(&$/,'$'
2EMHWLYRV
Evaluacin
Verificacin
Validacin
Conformidad, Confirmacin

3ULQFLSDOHV3URFHVRVTXHLQFOX\H
Revisiones de Gestin, Revisiones Tcnicas
Inspecciones, walkthrough
Pruebas
Auditoria

Tambin en la figura siguiente se refleja la relacin entre procesos y productos

dentro de la actividad de aseguramiento de la calidad.

5HODFLyQHQWUH3URFHVRV64$FRQSURGXFWRV\3UR\HFWRV

352'8&72


352<(&7
Revisin Tcnica

Pruebas

Inspeccin Software

Simulaciones
Pruebas formales

Wlakthrough
Auditoria

$0%26

Pruebas
de Gestin

El examen de los aspectos tcnicos y de gestin se realiza en varias fases

durante el ciclo de vida del proyecto. El resultado son controles para permitir
mejorar los mtodos y asegurar la calidad del software y la posibilidad de
conjugar las restricciones de tiempo y coste. La evaluacin de los elementos
software se realiza durante la generacin de esos elementos y a su termino .
esto asegura que los elementos terminados expresan correctamente las
especificaciones de su lnea base.
Cualquier proceso estndar tiene unas condiciones como prerrequisitos; estas
son 1 necesarias, aunque no son suficientes en s mismas para que el proceso
quede completado. Para las revisiones las auditorias las condiciones son:
3UHUUHTXLVLWRV(Q/RV3URFHVRV'H5HYLVLyQ

El objetivo de una Revisin de un elemento software es evaluar el

software o el estado, del proyecto para identificar las discrepancias sobre los
resultados planificados y recomendar mejoras cuando sea apropiado.
En la figura de la pgina siguiente se reflejan los prerrequisitos del Proceso de
Revisin.
El objetivo de la auditora del Software es suministrar una evaluacin
objetiva de los productos y los procesos para corroborar la conformidad con los
estndares, las lneas gua, las especificaciones y los procedimientos. Los
siguientes requerimientos son prerrequisitos para conseguir este objetivo:
1. Objetivo de la auditora, criterios existentes (por ejemplo, contratistas,
requerimientos, planes, especificaciones, estndares) en relacin con los
elementos software y los procesos que puedan ser evaluados.
2. El personal de auditora es seleccionado para promover los objetivos del
grupo. Son independientes de cualquier responsabilidad directa para los
productos y los procesos examinados y pueden provenir de una
organizacin externa.
3. El personal de auditora debe tener la suficiente autoridad que le permita
una adecuada gestin con el fin de realizar la auditora.


 
 

Responsable
Responsablede
de revisar
revisar y
anticipar
rehacer los
los
y anticiparalal rehacer
productos

productos

Responsable del desarrollo de

la revisin y de informar de los
resultados en relacin con los
hitos del proyecto

Suministra los recursos necesarios

de tiempo, personal, presupuesto y
elementos necesarios para planificar,
definir, realizar y gestionar la revisin.

Tcnicos de
Desarrollo

Los tcnicos tienen un nivel de pericia en

el desarrollo y un conocimiento del
producto suficiente para entender el
software a revisar

Los tcnicos tienen la formacin y la

orientacin en el uso de los procesos
de revisin.

   

  



   

Han sido definidos

los criterios de
comienzo y de
finalizacin de las
bases
de
desarrollo.

Los criterios de los productos

(tales como la legibilidad y la
modularidad)
estn
suficientemente definidos por
los estndares de desarrollo

El
producto
dividido
en
unidades
gestionables
y revisables

Los elementos de Software a ser revisados

y los procesos de revisin empleados estn
identificados en los documentos de
planificacin del proyecto (p.a. Plan de
Aseguramiento DE La calidad del Software,
Plan de Verificacin del software, Plan de
Gestin del Proyecto Software.

 !  

  

"
#
$   

Cada
tipo
de
revisin a emplear
esta
completamente
especificado

Los procesos administrativos

estn definidos y disponibles
para que la revisin pueda
iniciarse,
ejecutarse
y
registrarse

Se asigna la responsabilidad
de
la
planificacin,
especificacin, administracin
y mantenimiento de los
procesos de revisiones

En al figura de la pgina siguiente se incluye una descripcin esquemtica del

procedimiento a utilizar para planificar, preparar y realizar cualquier proceso de
revisin o de auditoria, segn el estndar IEEE 1028.


% &  
  '  "
# 
$   )(+*    
1. Objetivo
Meta del Proceso

2. Resumen
Panorama del Proceso
3. Responsabilidades
Roles nicos para
procesos especficos
4. Entradas
Productos a los que es aplicado
el proceso informacin soportada
5. Criterio de Comienzo
Condiciones que deben ser
satisfechas antes de que pueda
empezar el proceso

6. Procedimientos
Pasos estndar seguidos
para realizar el proceso

7. Criterio de terminacin
Condiciones que deben ser
satisfacerse antes de el proceso
sea considerado completo

6.1 Planificacin

6.2 Introduccin
8. salidas
El mnimo conjunto de
productos resultante de la
terminacin del proceso

9. Auditabilidad
Descripcin de la evidencia
necesaria para determinar en
una fecha posterior como se ha
seguido el proceso

(/352&(62'($8',725,$'(/62)7:$5(

6.3 Preparacin
6.4 Examen

6.5 Informes

1 REMHWLYR Segn se ha indicado es proveer la confirmacin de la

conformidad de los productos y los procesos para certificar la adherencia con
los estndares, lneas gua, especificaciones y procedimientos.
 5HVXPHQ La auditora es realizada de acuerdo con los planes y
procedimientos documentados. El plan de auditora establece un procedimiento
para dirigir la auditora y para las acciones, de seguimiento sobre las
recomendaciones de la auditoria.
Al realizar la auditora, el personal de la auditora evala los elementos
software
y los procesos para contrastarlos con los objetivos y criterios de la auditora,
tales

como

contratos,

requerimientos,

planes,

especificaciones

procedimientos, lneas gua y estndares.

Los resultados de la auditora son documentados y remitidos al director de
la organizacin auditada, a la entidad iniciadora de la auditora, y a cualquier
organizacin externa identificada en el plan de auditora. El informe incluye una
lista de elementos no conformes u otros aspectos para las posteriores
revisiones y acciones cuando sea estipulado en el plan de auditora, las
recomendaciones son informadas e incluidas en los resultados de la auditora.

5HVSRQVDELOLGDGHV HVSHFLDOHV Es responsabilidad del lder del equipo de

auditora el organizar y dirigir la auditora y la coordinacin de la preparacin de
los untos del informe de auditora. El lder del equipo deber asegurar que el
equipo de auditora est preparado para llevar sta, y que los procedimientos y
los distintos puntos son realizados y reflejados en los informes de acuerdo con
su alcance.
La entidad iniciadora de la auditora es responsable para autorizar sta. La
direccin de la organizacin auditora asume la responsabilidad de la auditora,
y la asignacin de los recursos necesarios para realizar dicha auditora.
Aquellos cuyos productos y procesos son auditados suministrarn todos
los materiales y recursos relevantes y corregirn o resolvern las deficiencias
citadas por el equipo de auditora.

(QWUDGDSe requieren las siguientes entradas para realizar la auditora:

1. El propsito y alcance de la auditora.
2. Criterios objetivos de la auditora, tales como contratos, requerimientos,

planes, especificaciones, procedimientos, lneas gua y estndares.

3. Los elementos software y los procesos a auditar y cualquier
antecedente pertinente.
4. Informacin complementaria respecto a la organizacin responsable de
los productos y los procesos a auditar (por ejemplo, organigramas de la
organizacin).

&ULWHULR GH FRPLHQ]R La necesidad para que una auditora se inicie debe
ser por uno de los siguientes sucesos:

1. Se ha alcanzado un hito especial del proyecto. La auditora es iniciada

por planes previos (por ejemplo, el plan de aseguramiento de calidad, el
plan de desarrollo del software).
2. Partes externas (por ejemplo, agencias reguladores o usuarios finales)
demandando una auditora en una fecha especfica o en un hito del
proyecto. sta puede ser por la realizacin de un requerimiento de un
contrato o como prerrequisito a un acuerdo contractual.
3. Un elemento de la organizacin local (por ejemplo, el director del
proyecto, la direccin funcional, ingeniera de sistemas, aseguramiento
o control interno de la calidad) ha requerido la auditora estableciendo
una necesidad clara y especfica.
4. Un hito especial del proyecto, fecha de calendario, u otro criterio ha sido
alcanzado y dentro de la planificacin de la organizacin de auditora le
corresponde la iniciacin de una auditora.

3URFHGLPLHQWRV

6.1. Planificacin. La organizacin de auditora debe desarrollar y

documentar un plan de auditora para cada auditora. Este plan deber
apoyarse en el alcance de la auditora identificando lo siguiente:
1.

El proceso del proyecto a examinar (suministrado como entrada) y el

tiempo de observacin del equipo de auditora.

2. Los requerimientos del software a examinar (suministrado como

entrada) y -su disponibilidad. Cuando se usa el muestreo, debe
utilizarse una metodologa estadstica vlida al respecto para
establecer los criterios de seleccin y el tamao de la muestra.
3. Los

informes

sern

identificados

(informes

de

resultados,

opcionalmente el informe de recomendaciones y definido su formato

general). Si las recomendaciones son requeridas o excluidas, debe ser
indicado explcitamente.
4. Distribucin de informes.
5. Requerimientos de las actividades de seguimiento.
6. Requerimientos: actividades necesarias, elementos y procedimientos
para cubrir el alcance de la auditora.
7. Objetivos y criterios de auditora: proveen las bases para determinar
las coincidencias (suministradas como entrada).
8. Procedimientos de auditora y listas de comprobacin.
9. Personal de auditora: nmero requerido, perfiles, experiencia y
responsabilidades.
10. Organizaciones

involucradas

en

la auditora (por ejemplo, la

organizacin cuyos productos y procesos estn siendo auditados).

11. Fecha, hora, lugar, agenda y la audiencia a quien se dirige la sesin
de introduccin (opcional).
El lder del equipo de auditora asegurar que su equipo est preparado e
incluye los miembros con la experiencia y pericia necesaria.
La notificacin de la auditora a las organizaciones involucradas debe realizarse
con una anterioridad razonable, excepto en el caso de las auditorias no
anunciadas. La notificacin deber ser hecha por escrito y deber incluir el
alcance la identificacin de los procesos y productos a auditar, as como la
identificacin de los auditores.

 ,QWURGXFFLyQ Opcionalmente es recomendable hacer una reunin

introductoria con la organizacin a auditar en el momento del arranque para

examinar las fases de la auditora. La reunin de introduccin encabezada por
el lder del equipo de auditora, abordar lo siguiente:
1. Introduccin sobre los acuerdos existentes (por ejemplo, alcance de la
auditora, planificacin, contratos afectados).
2. Introduccin

de

la

produccin

procesos

ser

auditados.

3 Introduccin7del proceso de auditora, sus objetivos y sus salidas.

4. Contribuciones esperadas de la organizacin auditada al proceso de
auditora (nmero de personas a entrevistar, facilidades para reuniones,
etc.).

 Planificacin especfica de la auditora.

3UHSDUDFLyQ

Los

siguientes

puntos

son

requeridos

para

la

preparacin del equipo de auditora:

1. Entender la organizacin: es esencial para identificar las funciones y las
actividades realizadas por la organizacin auditada, as como para
identificar las responsabilidades funcionales.
2. Entender los productos y los procesos: es prerrequisito para el equipo
de auditora conocer los procesos y los productos a auditar mediante
lecturas e informes.
3. Entender los objetivos y criterios de la auditora: es importante que el
equipo de auditora est familiarizado con el objetivo de la auditora y
los criterios usados en ella.
4. Preparacin para el informe de auditora: es importante seleccionar el
mecanismo administrativo de informacin que ser usado durante la
auditora para ir confeccionando el informe siguiendo el diseo
determinado en el plan de auditora.

 Detalle del plan de auditora: seleccionar el mtodo apropiado para

cada paso en el programa de auditora.
Adicionalmente el lder del equipo de auditora deber hacer los preparativos
necesarios para:
1. Orientar a su equipo y formarlo si es necesario.
2. Preparar lo necesario para las entrevistas de la auditora.
3. Preparar los materiales, documentos y herramientas necesarias segn
los procedimientos de auditora.
4. Identificar los elementos software a auditar (por ejemplo, documentos,
ficheros informticos, personal a entrevistar).

 Planificar las entrevistas.

([DPHQ Los elementos que han sido seleccionados para auditarse

debern ser valorados en relacin con el objetivo y criterios de la auditora. Las
evidencias debern ser examinadas con la profundidad necesaria para
determinar si esos elementos cumplen con los criterios especificados.
La auditora ser la adecuada para conseguir:
1. Revisar los procedimientos e instrucciones.
2; Examinar la estructura de descomposicin de los trabajos.

Examinar las evidencias de la implantacin y lo equilibrado del control.

4. Entrevistar al personal para averiguar el estado y el funcionamiento de
los procesos y el estado de los productos.

 Examinar cada documento.

6. Comprobar cada elemento.

 ,QIRUPHV A continuacin del examen de auditora, el equipo auditor

deber emitir un borrador del informe de auditora a la organizacin auditada

para su revisin y comentarios.
El equipo auditor podr rehacer el informe de auditora antes de que se
tenga el resultado formal del informe. Estas adaptaciones se harn de acuerdo
con la revisin del borrador del informe y resolvern cualquier mal entendido o
ambigedad mientras se mantiene la objetividad y exactitud. Esto tambin sirve
para asegurar la fcil utilizacin del informe dndole consistencia en los
detalles e incluyendo cualquier nueva informacin verificada. La prctica
recomendada es involucrar a los representantes de la organizacin auditada en
la revisin de los resultados de la auditora.
Involucrando a la organizacin auditada se contribuye a mejorar la calidad
del informe mediante la interaccin y la posible aportacin de cualquier
evidencia adicional.
El grupo de auditora organizar una conferencia posterior a la auditora
para revisar con los tcnicos de la organizacin auditada las deficiencias, fallos
y (Si es aplicable) las recomendaciones. Los comentarios y los puntos
abordados por la organizacin auditada, debern ser resueltos.
El informe final de la auditora debe ser preparado, aprobado y distribuido por el
lder del equipo de auditora a las organizaciones especificadas en el plan de
auditora.


&ULWHULR GH WHUPLQDFLyQ Una auditora debe ser considerada

terminada cuando:
1. Se ha examinado cada elemento dentro del alcance de la auditora.
2. Los resultados han sido presentados a la organizacin auditada.
3. La respuesta al borrador de los resultados ha sido recibida y evaluada.
4. El resultado final ha sido formalmente presentado a la organizacin
auditada y a la entidad iniciadora.

El informe final ha sido preparado y enviado a los receptores designados

en el plan de auditora.
6. El informe de recomendaciones, si el plan lo requiere, ha sido preparado
y enviado a los receptores designados en el plan de auditora.
7. Se han realizado .todas las acciones de seguimiento incluidas en el
alcance de la auditora (o en el contrato).

6DOLGDV Como un marco estndar para los informes, el informe

borrador de auditora y el informe final de auditora, debern contener como
mnimo, lo siguiente:

,GHQWLILFDFLyQGHODDXGLWRUtDTtulo .del informe, organizacin

auditada, organizacin auditora y fecha de la auditora.

$OFDQFH Alcance de la auditora, incluyendo la enumeracin de los

estndares,

especificaciones,

prcticas

procedimientos

que

constituyen su objetivo y el criterio contra el cual ser dirigida la

auditora de los elementos software y de los procesos a auditar.

&RQFOXVLRQHV Un resumen e interpretacin de los resultados de la

auditora incluyendo los puntos clave de los aspectos no conformes.

6LQRSVLV Un listado de todos los elementos software auditados, los

procesos y los elementos asociados.

6HJXLPLHQWREl tipo y el cronograma de las actividades de seguimiento

de la auditora.
Adicionalmente, cuando lo estipule el plan de auditora, las recomendaciones
debern enviarse a la organizacin auditada o a la entidad que inicie la
auditora. Las recomendaciones irn en un informe separado de los resultados.

$XGLWDELOLGDG Los materiales que documentan el proceso de auditora

deben ser mantenidos por la organizacin auditora durante un perodo

estipulado despus de la auditora e incluyendo lo siguiente:
1.Todos los programas de trabajo, listas de comprobacin, etc. con todos
sus comentarios.
2. El equipo de tcnicos.
3. Comentarios de las entrevistas as como de las observaciones.
4. Evidencias de pruebas de conformidad.

Copias de los elementos examinados con sus comentarios.

6. Informes borradores con las respuestas de la organizacin auditada.
7. Memorndum del seguimiento si es necesario.

 $8',725$'(6,67(0$6'(&$/,'$''(62)7:$5(
El propsito de la auditora de un Sistema de Calidad, o un programa de
evaluacin de la calidad, es suministrar una valoracin independiente sobre la
conformidad de un Plan de Aseguramiento de la Calidad del Software.
Especficamente el objetivo es determinar, basndose en evidencias
observables y verificables, que:
1. La documentacin del programa de calidad del software establecida por la
organizacin de desarrollo recoge como mnimo los elementos bsicos del
estndar ANSIJIEEE 730 u otro estndar apropiado.
2. La organizacin de desarrollo del software sigue el programa de calidad de
software por ellos documentado.
El Plan de Aseguramiento de la Calidad del Software debe incorporar todos los
objetivos y los criterios de actuacin organizativos; estndares internos y
procedimientos; procesos requeridos por la legislacin, contratos u otras
polticas; conformidad con el estndar ANSIIIEEE 730 u otro estndar
apropiado para el aseguramiento de la calidad del software.

 352&(62'($6(*85$0,(172'(/$&$/,'$''(6&5,72325

62

Para realizar cualquier proceso de auditora, es imprescindible conocer la

actividad que se va auditar, por tanto, no debe extraar al lector que vayamos
intercalando descripciones de los procesos de calidad y los de desarrollo a lo
largo del texto, en este caso lo que al respecto describe la norma ISO 12207.
La norma ISO/IEC 12207 Information technology Software life cycle
processes 1995, no podramos dejar de citarla en este captulo, ya que es una
importante norma para el proceso de desarrollo del software y para los
procesos de calidad.

(VWUXFWXUDGHODQRUPD,62,(&
352&(62635,0$5,26'(/
&,&/2'(9,'$
5.1 Adquisicin
5.2 Sumario
5.3
Desarrollo

5.4
Operacin
5.5
Mantenimiento

352&(626'(623257(
'(/&,&/2'(9,'$
6.1 Documentacin
6.2 Gestin de la configuracin
6.3 Aseguramiento de la Calidad
6.4 Verificacin
6.5 Validacin
6.6 Revisin conjunta
6.7 Auditoria
6.8 Resolucin de Problemas

352&(6225*$1,=$7,92'(/&,&/2'(9,'$
7.1 Gestin

7.2 Infraestructura

7.3 Mejora

7.4 Formacin

En la figura anterior se muestra la estructura de dicha norma en la que vemos

los procesos Primarios del Ciclo de Vida, los de Soporte y los Organizativos. El
nmero que figura antes de cada proceso corresponde al apartado donde se
describe el mismo en la norma.
De ella vamos a describir dos de los procesos ms relacionados con nuestro
tema, como son el Proceso de Aseguramiento de la Calidad y el Proceso de
Auditora, que consideramos que contribuyen a completar una perspectiva ms
amplia del tema que nos ocupa.
El apartado 6.3 relativo a los Procesos de Aseguramiento de la Calidad dice:
Los Procesos de Aseguramiento de la Calidad sirven para suministrar la
seguridad de que durante el ciclo de vida del proyecto los productos y los
procesos estn de acuerdo con los requerimientos especificados y se adhieren
a los planes establecidos. Al ser imparcial, el aseguramiento de la calidad
necesita tener libertad organizativa y autoridad de las personas directamente
responsables del desarrollo de los productos software o los que realizan los
procesos en el proyecto. El aseguramiento de - la calidad puede ser interno o
externo, dependiendo de si la evidencia de la calidad de los productos o los

procesos se va a demostrar a la direccin del suministrador o al cliente. El

aseguramiento de la calidad puede hacer uso de los resultados de otros
procesos de Soporte, tales como Verificacin, Validacin, Revisiones
Conjuntas, Auditorias y Resolucin de Problemas.
Este proceso de aseguramiento de la calidad se compone de las cuatro
actividades que describimos a continuacin:
,PSOHPHQWDFLyQGHOSURFHVR

Esta actividad tiene las siguientes tareas:

El proceso de aseguramiento de la calidad debe establecerse adaptado al

proyecto. Los objetivos de este proceso de aseguramiento de la calidad
sern asegurar que los productos software y los procesos utilizados para
conseguir estos productos software cumplen con los requerimientos
establecidos y se adaptan a los planes previstos.

Los procesos de aseguramiento de la calidad deben ser coordinados con

los procesos indicados de Verificacin, Validacin, Revisin Conjunta y
Auditora.

El plan para dirigir los, procesos, actividades y tareas de aseguramiento de

la calidad debe ser desarrollado_ documentado, implementado y mantenido
durante el tiempo de duracin del contrato. Este plan deber incluir lo
siguiente:
a) Estndares de calidad, metodologas, procedimientos, y herramientas
para
realizar las actividades de aseguramiento de la calidad (o sus
referencias a la documentacin oficial de la organizacin).
b) Procedimientos para la revisin y coordinacin del contrato.
c) Procedimientos para identificar, recoger, cumplimentar, mantener y
acceder
a los registros de calidad.
d) Recursos, planes, y responsabilidades para dirigir las actividades de
aseguramiento de calidad.
e) Determinadas actividades y tareas de los procesos de soporte, tales
como
Verificacin, Validacin, Revisiones Conjuntas, Auditorias y Resolucin
de Problemas.

Las actividades y tareas planificadas de aseguramiento de la calidad deben

realizarse. Cuando son detectados problemas o no conformidades con los
requerimientos contractuales, deben ser documentados y servir de entrada
al Proceso de Resolucin de Problemas. Deben prepararse y mantenerse
los registros de estas actividades y tareas, su realizacin, los problemas y
su resolucin.

Los registros de las actividades y tareas de aseguramiento de la calidad

deben estar disponibles al cliente as como especificados en el contrato.

Deber cerciorarse de que las personas responsables de asegurar la

concordancia con los requerimientos del contrato tienen la libertad organizativa,
los recursos y la autoridad para permitir evaluaciones objetivas e iniciar,
efectuar, resolver y verificar la resolucin de problemas.
$VHJXUDPLHQWRGHOSURGXFWR

Esta actividad tiene las siguientes tareas:

Deber asegurar que aquellos planes requeridos por el contrato estn
documentados, cumplen con el contrato, son mutuamente consistentes, y estn
siendo ejecutados como se requiere.

Deber asegurar que aquellos productos software y su documentacin

cumplen con el contrato y estn de acuerdo con los planes.

En la preparacin para el - -suministro de los - productos software, debern

asegurarse

de

que

satisfacen

completamente

los

requerimientos

contractuales y son aceptables para el cliente.

$VHJXUDPLHQWRGHOSURFHVR

Esta actividad tiene las siguientes tareas:

Deber asegurar los procesos del ciclo de vida del software (suministro,
desarrollo,

operacin,

mantenimientos

soporte,

incluyendo

el

aseguramiento de la calidad) empleados para que el proyecto est de

acuerdo con el contrato y se ajuste a los planes.

Deber asegurar que las prcticas internas de ingeniera de software,

entorno de desarrollo y libreras estn de acuerdo con el contrato.

Deber asegurar que los requerimientos aplica6les del contrato principal

son pasados al subcontratista, y que los productos software del
subcontratista satisfacen los requerimientos del contrato principal.

Deber asegurar que al cliente y a las otras partes se les aporta el soporte y
la cooperacin requeridos de acuerdo con el contrato, las negociaciones y
los planes.

Deber asegurar que los productos software y los procesos medidos estn
de acuerdo con los estndares y procedimientos establecidos.

Deber asegurar que el personal tcnico asignado tiene el perfil y los

conocimientos necesarios para conseguir cumplir los requerimientos del
proyecto y que recibe la formacin que pudiera necesitar.
$VHJXUDPLHQWRGHODFDOLGDGGHORVVLVWHPDV
Esta actividad tiene la siguiente tarea:

Las actividades adicionales de gestin de calidad debern asegurar su

concordancia con la clusula de ISO 9001 segn especifique el contrato.

352&(62'($8',725$'(6&5,72325

El proceso de auditora sirve para determinar la adherencia con - los requerimientos,

los planes y el contrato cuando es apropiado. Este proceso puede ser
empleado por
cualquiera de las dos partes, donde una de ellas (parte auditora) audita los
productos software o las actividades de la otra parte (parte auditada).
Este proceso se compone de dos actividades:
LPSOHPHQWDFLyQGHOSURFHVR

Esta actividad tiene las siguientes tareas:

Las

auditorias deben realizarse en determinados hitos, segn lo

especificado en los planes del proyecto.

El personal auditor no debe tener ninguna responsabilidad directa en los

productos software ni en las actividades que auditan.

Todos los recursos requeridos para llevar la auditora deben ser pactados
por las partes, stos incluyen personal de soporte, locales, hardware,
software, herramientas y elementos complementarios.

Las partes debern ponerse de acuerdo en cada auditora sobre: agenda;

productos software (y resultados de las actividades) a revisar; alcance de la
auditora y procedimientos; y criterios de comienzo y de terminacin de la
auditora.

Los problemas detectados durante la auditora deben ser registrados y

tratados en el Proceso de Resolucin de Problemas.

Despus de completar la auditora, los resultados de sta deben ser

documentados y entregados a la parte auditada, quien deber acusar recibo
a la parte auditora de cualquier problema detectado en la auditora y en la
resolucin de problemas planificada.

Las partes debern ponerse de acuerdo sobre los resultados de la auditora

y sobre cualquier punto de accin, responsabilidades y criterios de cierre.

$XGLWRUtD

Esta actividad tiene la siguiente tarea:

La auditora deber ser dirigida para asegurar que:
a. Los productos software codificados (tal como elemento software) reflejarn
lo diseado en la documentacin.
b. Los requerimientos de la revisin de aceptacin y de pruebas prescritos por
la documentacin son adecuados para la aceptacin de los productos
software.
c. Los datos de prueba cumplen con la especificacin.
d. Los productos software fueron sucesivamente probados y alcanzaron sus
especificaciones.
e. Los informes de pruebas son correctos y las discrepancias entre los
resultados conseguidos y lo esperado han sido resueltas.
f. La documentacin del usuario cumple con los estndares tal como se ha
especificado.
g. Las actividades han sido llevadas de acuerdo con los requerimientos
aplicables, los planes y el contrato.
h. El coste y el cronograma se ajustan a los planes establecidos.

&21&/86,21(6
demos pretendido hacer una semblanza de los aspectos que consideramos
ms importantes para hacer una Auditora de Calidad, tratando de soportarlos
en diversos estndares y normas que en la mayora de los casos hemos
insertado traducindolos exactamente de las mismas para no adulterarlos con
una posible subjetividad. Con esto consideramos que nos puede permitir tener
una visin ms amplia a travs de los distintos enfoques que dan dichas
normas sobre las Auditorias de Calidad.
Aunque somos conscientes de que el abordar una auditora slo con este
bagaje no es suficiente. Un buen auditor en Tecnologas de la Informacin
necesita tener una amplia experiencia en las distintas funciones de dicha
actividad, estar muy al da en las distintas metodologas, procesos y

herramientas que se emplean, de forma que le sea IiFLO detectar los defectos

en los planes, en los productos y en los procesos, as como estar capacitado

para poder proponer recomendaciones.
Reconocemos que no es una tarea fcil, pero precisamente por ello es
altamente gratificante el alcanzar un xito que satisfaga los intereses, en
muchas ocasiones contrapuestos, de las partes involucradas, consiguiendo de
la entidad auditada el reconocimiento de la profesionalidad del auditor al
conseguir detectar los problemas existentes y proponer soluciones, y de la
parte que promovi la auditora el conseguir que se pueda conocer en dnde
residan los problemas que no permitan alcanzar los objetivos deseables.
Pero debemos recordar que esta actividad no es un arte, sino una tcnica, y
como tal debe seguirse un orden y un mtodo en el que nada se da por
supuesto si no existe una evidencia objetiva que lo acredita. En ese conjunto
de evidencias se apoyaran nuestras conclusiones, y de nuestra experiencia y

NQRZKRZsaldrn las recomendaciones a proponer.

 /(&785$65(&20(1'$'$6

Cohen, L. -QVSHFWLRQ0RGHUDWRUV+DQGERRNMayard, M. A: Digital Equipment

Corporation. 1991.

Freedman D. P. y Weinberg G. M. +DQGERRN RI :DONWKURXJKV -QVSHFWLRQV

DQG7HFKQLFDO5HYLHZV

 &8(67,21(6'(5(3$62
1. Elabore su propia definicin de calidad.
2. Qu caractersticas de la calidad define la norma 150 9126?