Unidad III.

-Aseguramiento de
la calidad de los sistemas de
informacin (SQA)
Aunque hay muchas medidas de la calidad de software, la
correccin, facilidad de mantenimiento, integridad y facilidad de
uso suministran indicadores tiles para el equipo del proyecto. Gilb
[Len O. Ejiogo 90] sugiere definiciones y medidas para cada uno
de ellos, tales como:

Correccin: A un programa le corresponde operar correctamente o

suministrar poco valor a sus usuarios. La correccin es el grado
en el que el software lleva a cabo una funcin requerida. La
medida ms comn de correccin son los defectos por
KLDC(KLCD=(PF * Lneas de cdigo por cada PF)/1000), en
donde un defecto se define como una falla verificada de
conformidad con los requisitos.
Facilidad de mantenimiento. El mantenimiento del software cuenta
con ms esfuerzo que cualquier otra actividad de ingeniera del
software.
La facilidad de mantenimiento es la habilidad con la que se puede
corregir un programa si se encuentra un error, se puede adaptar si su
entorno cambia u optimizar si el cliente desea un cambio de
requisitos.
No hay forma de medir directamente la facilidad de mantenimiento;
por consiguiente, se deben utilizar medidas indirectas. Una mtrica
orientada al tiempo simple es el tiempo medio de cambio (TMC), es
decir, el tiempo que se tarda en analizar la peticin de cambio, en
disear una modificacin apropiada, en efectuar el cambio, en
probarlo y en distribuir el cambio a todos los usuarios. En promedio,
los programas que son ms fciles de mantener tendrn un TMC ms
bajo (para tipos equivalentes de cambios) que los programas que son
ms difciles de mantener.
Hitachi ha empleado una mtrica orientada al costo (precio)
para la capacidad de mantenimiento, llamada desperdicios. El
costo estar en corregir defectos hallados despus de haber
distribuido el software a sus usuarios finales.

Cuando la proporcin de desperdicios en el costo global del

proyecto se simboliza como una funcin del tiempo, es aqu
donde el administrador logra determinar si la facilidad de
mantenimiento del software producido por una organizacin de
desarrollo est mejorando y asimismo se pueden emprender
acciones a partir de las conclusiones obtenidas de esa
informacin.
Integridad. En esta poca de intrusos informticos y de virus, la
integridad del software ha llegado a tener mucha importancia. Este
atributo mide la habilidad de un sistema para soportar ataques
(tanto accidentales como intencionados) contra su seguridad. El
ataque se puede ejecutar en cualquiera de los tres componentes del
software, ya sea en los programas, datos o documentos.
Para medir la integridad, se tienen que definir dos atributos
adicionales:
amenaza y seguridad. La amenaza es la probabilidad (que se logra
evaluar o concluir de la evidencia emprica) de que un ataque de un
tipo establecido ocurra en un tiempo establecido. La seguridad es la
probabilidad (que se puede estimar o deducir de la evidencia
emprica) de que se pueda repeler el ataque de un tipo establecido,
en donde la integridad del sistema se puede especificar como:
integridad = [1- amenaza x (1- seguridad)]

donde se suman la amenaza y la seguridad para cada tipo de ataque.

Facilidad de uso. El calificativo amigable con el usuario se ha
transformado universalmente en disputas sobre productos de
software. Si un programa no es amigable con el usuario,
prcticamente est prximo al fracaso, incluso aunque las funciones
que realice sean valiosas. La facilidad de uso es un intento de
cuantificar lo amigable que pude ser con el usuario y se consigue
medir en funcin de cuatro caractersticas:
(1) destreza intelectual y/o fsica solicitada para aprender el sistema;
(2) el tiempo requerido para alcanzar a ser moderadamente eficiente
en el uso del sistema;
(3) aumento neto en productividad (sobre el enfoque que el sistema
reemplaza) medida cuando alguien emplea el sistema
moderadamente y eficientemente, y
(4) valoracin subjetiva (a veces obtenida mediante un cuestionario)
de la disposicin de los usuarios hacia el sistema.
Los cuatro factores anteriores son slo un ejemplo de todos los que
se han propuesto como medidas de la calidad del software.
 3.1. Medidas de fiabilidad y de disponibilidad.
Los trabajos iniciales sobre fiabilidad buscaron extrapolar las
matemticas de la teora de fiabilidad del hardware a la prediccin
de la fiabilidad del software.
La mayora de los modelos de fiabilidad relativos al hardware van
ms orientados a los fallos debidos al desajuste, que a los fallos
debidos a defectos de diseo, ya que son ms probables debido al
desgaste fsico (p. ej.: el efecto de la temperatura, del deterioro, y
los golpes) que los fallos relativos al diseo.

Desgraciadamente, para el software lo que ocurre es lo contrario.

De hecho, todos los fallos del software, se producen por problemas
de diseo o de implementacin.
Considerando un sistema basado en computadora, una medida
sencilla de la fiabilidad es el tiempo medio entre fallos (TMEF) ,
donde:
TMEF = TMDF+TMDR
TMDF =tiempo medio de fallo
TMDR =tiempo medio de reparacin.

Muchos investigadores argumentan que el TMDF es con mucho,

una medida ms til que los defectos/KLDC, simplemente
porque el usuario final se enfrenta a los fallos, no al nmero total
de errores. Como cada error de un programa no tiene la misma
tasa de fallo, la cuenta total de errores no es una buena indicacin
de la fiabilidad de un sistema. Por ejemplo, consideremos un
programa que ha estado funcionando durante 14 meses. Muchos
de los errores del programa pueden pasar desapercibidos durante
dcadas antes de que se detecten.
El TMEF de esos errores puede ser de 50 e incluso de 100 aos.
Otros errores, aunque no se hayan descubierto an, pueden tener una
tasa de fallo de 18 24 meses, incluso aunque se eliminen todos los
errores de la primera categora (los que tienen un gran TMEF), el
impacto sobre la fiabilidad del software ser muy escaso.
Adems de una medida de la fiabilidad debemos obtener una medida
de la disponibilidad. La disponibilidad (ver ecuacin) del software es
la probabilidad de que un programa funcione de acuerdo con los
requisitos en un momento dado, y se define como:

Disponibilidad = TMDF/(TMDF + TMDR) x 100 %

La medida de fiabilidad TMEF es igualmente sensible al TMDF que

al TMDR. La medida de disponibilidad es algo ms sensible al
TMDR ya que es una medida indirecta de la facilidad de
mantenimiento del software.
 3.2. Seguridad de los sistemas de informacin.
Los objetivos de seguridad perseguidos con la aplicacin de
medidas de seguridad en los sistemas de informacin y
comunicaciones son:
a) Proporcionar confidencialidad a la informacin manejada por
el sistema.
b) Proporcionar integridad a la informacin manejada por el
sistema, as como a los recursos y servicios del mismo.
c) Mantener la disponibilidad de la informacin manejada por el
sistema, as como de los recursos y servicios del mismo.
d) Autenticar a las personas que acceden a la informacin
manejada por el sistema o a los recursos del mismo.
e) Proporcionar al sistema el servicio de no repudio, mediante el
cual es posible proporcionar la prueba de que una determinada
accin ha sido realizada, no pudiendo los agentes participantes negar
que se haya producido.
 Principios de seguridad
Todo sistema en el que se vaya a manejar informacin clasificada
deber atenerse a
unos principios bsicos dirigidos a asegurar la debida proteccin de la
informacin
clasificada:
a) Todos los sistemas debern ser sometidos a un proceso de
acreditacin que garantice que se encuentran protegidos mediante
un conjunto apropiado de elementos hardware y software,
adecuadamente configurados, de forma que permitan garantizar la
confidencialidad, integridad y disponibilidad de la informacin
clasificada manejada por el sistema, as como la integridad y
disponibilidad del propio sistema.
b) El manejo de informacin clasificada en un sistema requerir la
previa autorizacin para ello por la autoridad de acreditacin de
seguridad.
c) La interconexin de sistemas que manejen informacin
clasificada requerir la previa acreditacin por las autoridades
competentes para cada sistema. Cada sistema tratar a los otros
sistemas como de no confianza y aplicar medidas de proteccin
para controlar el intercambio de informacin con otros sistemas.
d) A los usuarios del sistema slo se les concedern los privilegios
y autorizaciones que necesiten para llevar a cabo sus tareas y
cometidos. Debern estar habilitados slo hasta el mayor grado de
clasificacin de la informacin de la que stos tengan necesidad de
conocer.
e) Los responsables de equipos de cifra, material de claves o de los
elementos de seguridad utilizados para la proteccin de los
sistemas, requerirn de una acreditacin especial.
f) Los locales destinados a alojar sistemas que manejen
informacin clasificada CONFIDENCIAL o equivalente o
superior debern estar acreditados como zonas de acceso
restringido rea clase I o rea clase II. Si nicamente van a
manejar informacin clasificada de grado DIFUSIN LIMITADA
o equivalente, bastar su constitucin como zonas administrativas
de proteccin.
g) Los locales destinados a alojar sistemas que manejen
informacin clasificada CONFIDENCIAL o equivalente o
superior debern estar acreditados como zonas de acceso
restringido rea clase I o rea clase II.
h) Toda la informacin clasificada CONFIDENCIAL o
equivalente o superior extrada de un sistema deber quedar
registrada en el sistema de registro correspondiente, constituido
por los rganos de control.

i) Se aplicar una gestin del riesgo de seguridad en los sistemas,

para controlar, reducir, eliminar y evitar o aceptar riesgos.

La aplicacin de estos principios y la posterior aplicacin de las

medidas de proteccin se verificarn, inicial y peridicamente,
por la autoridad de acreditacin de seguridad de cada sistema.
 Medidas de seguridad
Todo sistema en el que se vaya a manejar informacin clasificada
deber implementarlas siguientes medidas de proteccin mnimas:
a) Dispondr de los medios necesarios para identificar y
autentificar de forma fiable a las personas cuyo acceso est
autorizado, asegurando que se cumple el principio de la necesidad
de conocer.
b) Toda informacin y equipamiento que permita el acceso a los
sistemas deber ser protegida de acuerdo al mayor grado de
clasificacin de la informacin clasificada a la que pudiera dar
acceso.
c) Todo medio de almacenamiento utilizado en sistemas ser
protegido de acuerdo al mximo grado de clasificacin de la
informacin que contiene.
d) Deber contar con los dispositivos necesarios para realizar el
registro automtico de los accesos e intentos de acceso a la
informacin clasificada.
e) Todo dispositivo de seguridad destinado a su empleo en
sistemas que manejen informacin clasificada deber haber sido
aprobado por el Centro Criptolgico Nacional (CCN).
f) La interconexin entre sistemas ubicados en distintas zonas de
acceso restringido requerir la utilizacin de elementos de cifra
certificados por el CCN, de acuerdo al grado de clasificacin de la
informacin a transmitir.
g) La informacin clasificada contenida en los dispositivos de
almacenamiento removibles deber estar protegida mediante una
herramienta de cifrado adecuada y aprobada para su grado de
clasificacin.
h) Los sistemas que manejen informacin clasificada
CONFIDENCIAL o equivalente o superior, debern ser
protegidos contra las amenazas derivadas de emanaciones
electromagnticas no deseadas, cuyo estudio y control se conoce
como TEMPEST, acorde con el nivel de riesgo de explotacin
existente.
i) Todo sistema deber contar con programas actualizados de
deteccin de virus y de software malicioso.
j) No se permitir el uso de equipos o dispositivos electrnicos
particulares, incluidos soportes de almacenamiento, para el manejo
de informacin clasificada.
k) No se permitir la entrada de equipos o dispositivos electrnicos,
incluidos soportes de almacenamiento, a zonas de acceso
restringido (ZAR), excepto los pertenecientes a los sistemas
autorizados para el manejo de informacin clasificada existentes en
la propia ZAR.
l) Las tareas de instalacin, administracin, mantenimiento y
reparacin de los sistemas que manejen informacin clasificada
debern ser llevadas a cabo por personal con HPS de grado igual o
superior al grado de clasificacin de la informacin que manejen
los sistemas a que dicho personal tenga acceso.
m) Los sistemas que manejan informacin clasificada estarn
sujetos a una valoracin y gestin de riesgos acorde con los
requisitos especificados en la norma CCNSTIC correspondiente.
n) Se adoptarn medidas adicionales, adecuadas a las
circunstancias, all donde una valoracin de los riesgos haya
establecido que la informacin clasificada, o los servicios y
recursos de apoyo al sistema, estn sujetos a mayores riesgos,
procedentes de amenazas y vulnerabilidades concretas.
Requisitos de seguridad

Todos los sistemas debern disponer de un conjunto equilibrado

de servicios de seguridad que permitan alcanzar los objetivos de
seguridad requeridos:
- Identificar y autenticar a los individuos con acceso autorizado.
- Controlar los accesos a la informacin en base al principio de
necesidad de conocer.
-Verificar y mantener la integridad de la informacin clasificada y
de los elementos del sistema.
- Mantener la disponibilidad requerida para la informacin y los
elementos del sistema.
- Garantizar y verificar el funcionamiento de los mecanismos de
seguridad del sistema.
- Registrar y auditar la actividad de los usuarios del sistema.
- Controlar las conexiones y los enlaces de los sistemas.
- Prevenir, detectar y corregir los impactos o incidentes que
afecten a la confidencialidad, integridad y disponibilidad de la
informacin o a la integridad y disponibilidad del sistema que la
maneja.
 Interconexin de sistemas
Se produce una conexin entre sistemas cuando se proveen medios
fsicos y lgicos de transmisin (por ejemplo enlace satlite, fibra
ptica, etc.) susceptibles de ser empleados para el intercambio de
informacin entre ambos sistemas.
Se produce una interconexin entre sistemas cuando existe una
conexin y se habilitan flujos de informacin entre los mismos.

Cuando se produce una interconexin entre sistemas surgen

nuevas vulnerabilidades y amenazas que afectan a la
confidencialidad, integridad y disponibilidad de la informacin
manejada por dichos sistemas, principalmente por las siguientes
razones:
- Se incrementa el nmero de usuarios (autorizados y no
autorizados) que acceden a los sistemas.
- El nuevo sistema que se interconecta puede tener conexiones
o vas de acceso desconocidas para los administradores y
supervisores de seguridad del sistema que se considere.
- El nuevo sistema que se interconecta puede tener unas
amenazas distintas a las que en su da se consideraron para
establecer los requisitos de seguridad del sistema en
cuestin.
- El flujo de informacin entre ambos sistemas puede requerir
restricciones concretas.
- Ambos sistemas pueden tener distintas polticas de seguridad,
diferentes niveles de confianza, diferentes AOSTIC o una
combinacin de las anteriores.
Por ello es necesaria la acreditacin de la interconexin de
sistemas al mayor grado de clasificacin de la informacin que
manejen.
Todos los sistemas que manejen informacin clasificada, como
paso previo a la solicitud de acreditacin de su interconexin a
otro sistema, redes pblicas o similares, debern estar en posesin
de un certificado de acreditacin al nivel correspondiente a la
informacin que manejen.
3.3. Relacin de la ingeniera de sistemas de informacin con
SQA.
La concordancia con los requerimientos funcionales y de rendimiento
explcitamente establecidos, con los estndares de desarrollo explcitamente
documentados y con las caractersticas implcitas que se espera de todo software
se define como:

Los requerimientos del software son los fundamentos desde los que se mide la
calidad. La falta de concordancia con los requerimientos es una falta de calidad.

Los estndares especificados definen un conjunto de criterios de desarrollo que

gua la forma en se aplica la ingeniera del software; si no se siguen ciertos
criterios, casi siempre se dar una falta de calidad.

Existe un conjunto de requerimiento implcitos (el deseo de buen mantenimiento).

Si el software se ajusta a sus requerimientos pero falla en alcanzar los
requerimientos implcitos del software queda en entre dicho.
La calidad del software es una compleja mezcla de ciertos factores que varan para
las diferentes aplicaciones y los clientes que las solicitan. La garanta de calidad
es una actividad esencial en cualquier empresa que produce productos que van a
ser usados por otros.
Antes del siglo veinte, la garanta de calidad era responsabilidad nica de la
persona que construa el producto. La primera funcin de control y de garanta de
calidad formal fue introducida por los laboratorios Bell en 1916 y se extendi
rpidamente por todo el mundo de las manufacturas.
Hoy en da, cada compaa tiene un mecanismo que asegura la calidad de sus
productos de hecho, durante la pasada dcada, se han usado ampliamente como
tcticas de mercado la declaracin explcita de mensajes que ponan de manifiesto
la calidad ofrecida por las compaas.
La historia de la garanta de calidad en el desarrollo de software ha sido paralela a
la historia en la fabricacin de hardware. Durante los primeros aos de
informacin (los 50 y los 60), la calidad era responsabilidad nicamente del
programador. Durante los aos 70 se introdujeron estndares de garanta de
calidad para el software en los contratos militares de desarrollo de software y sean
extendido rpidamente en los desarrollos de software del mundo comercial.
El papel de la garanta del software (SQA) se ilustra esquemticamente en la
siguiente figura:
 3.4. Definicin y propsito del SQA
SQA es un conjunto de actividades sistemticas y planeadas para asegurar que los
procesos y productos del software cumplen con los requerimientos, estndares y
procedimientos.

Procesos: incluyen todas las actividades involucradas en el diseo, codificacin, pruebas

y mantenimiento.
Productos: incluyen software, datos asociados, documentacin y todo el soporte y
reportes de trabajo.

SQA brinda a la administracin la seguridad de que procesos oficialmente establecidos

estn siendo implementados. Y asegura que:

Una metodologa de desarrollo apropiada este establecida.

Que los proyectos utilicen estndares y procedimientos en su trabajo.
Que la documentacin sea creada para mantenimiento y mejoramiento.
La administracin de configuracin de software este adecuada para controlar cambios.
Se realicen pruebas y que se aprueben.
Cualquier deficiencia y desviaciones sean identificadas y llevadas con atencin a la
administracin.
Propsito SQA:
Proporcionar visibilidad sobre los procesos utilizados por el proyecto de
software y sobre los productos que genera.

Objetivos SQA:

1.-Planificar las actividades de aseguramiento de la calidad.

2.-Revisar y auditar objetivamente los productos y las actividades para
verificar que estn conformes con los procedimientos y estndares aplicables.
3.-Proporcionar los resultados de estas revisiones o auditoras informando a
la direccin cuando sea necesaria su mediacin.
 3.4.2. Roles y responsabilidades de los
equipos de SQA
Como polica del proceso: asegura que el desarrollo sigue el
proceso establecido.
Entre sus funciones en este rol se encuentran:

Auditar los productos del trabajo para identificar deficiencias.

Determinar el cumplimiento del plan de desarrollo del proyecto y

del proceso de desarrollo de software.

Juzgar el proceso y no el producto.

Como abogado del cliente: representa al cliente, entre sus funciones
en este rol se encuentran:

Identificar la funcionalidad que al cliente le gustara encontrar.

Ayudar a la organizacin a sensibilizarse con las necesidades del
cliente.

Actuar como un cliente de prueba para obtener una alta satisfaccin

del cliente.

Como analista recaba informacin. entre sus funciones en este rol se

encuentran:

Juntar muchos datos sobre todos los aspectos del producto y del
proceso.

Con esta informacin ayudar a mejorar los procesos y los productos.

Como proveedor de informacin revisa qu es lo que est hecho y
decir cules objetivos tcnicos realmente estn cumplidos para que
la gerencia pueda tomar mejores decisiones de negocios. Entre sus
funciones en este rol se encuentran:

Proveer informacin tcnica objetiva para que la gerencia pueda

usarla para tomar mejores decisiones.
Proveer informacin apropiada de las clases de productos y de los
riesgos asociados con estos.
Concentrarse ms en la reduccin de los riesgos que en el
cumplimiento del proceso.
Como responsable de la elaboracin del proceso participa
en la definicin de los planes, procesos, estndares y
procedimientos para asegurar que se ajustan a las necesidades
del proyecto y que pueden ser usados para realizar las
evaluaciones de QA y cumplir los requerimientos del proyecto
y las polticas de la organizacin. Para cumplir este rol el
aseguramiento de la calidad debera comenzar en las fases
tempranas del proyecto.

El equipo de SQA trabaja con la gerencia de proyectos durante

los inicios del desarrollo para establecer los planes, estndares
y los procedimientos que agregarn valor al proyecto de SW y
satisfacer los problemas del proyecto y de las polticas de la
organizacin,participa en establecer los planes, estndares y
procedimientos.
El equipo ayuda a asegurar que se cumplan con las necesidades
del proyecto y verifica que sean usables para realizar revisiones e
intervenciones durante todo el ciclo de vida.

Las revisiones proyectan las actividades y revisan el producto de

trabajo de SW, adems de proveer a la gerencia la posibilidad de
saber si el proyecto est de acuerdo a los planes estndares y
procedimientos establecidos.

El grupo encargado de SQA.

trabaja con el equipo del proyecto desde el inicio.

debe ser objetivo e independiente.
ayuda al proyecto, ms que controlar sus actividades.
3.4.3. Mtodos, metodologas, estndares y Herramientas
Mtodos: deben de utilizarse mtodos que contengan u
observen las polticas, procedimientos y estndares de la
organizacin.

METODOLOGA SQA

Las pruebas de SW son tanto un arte como una ciencia en

general, en aplicaciones complejas, como los sistemas
operativos, es prcticamente imposible eliminar todos los
errores antes de liberar la versin, esto se debe a los diferentes
puntos de vista y a las limitaciones de tiempo. Diferentes
aplicaciones de SW requieren distintos enfoques en lo que
respecta a las pruebas.
Los mtodos ms comunes para el aseguramiento de la calidad
son los siguientes:

1) Auditoras PPQA (Process and Product Quality

Assurance)
Es la actividad de garantizar que el proceso y el producto de
trabajo se ajustan al plan acordado.

2) Pruebas de Validacin: Es el acto de introducir datos, los

cuales el tester sabe que son errneos en la aplicacin.

3) Comparacin de datos: Tcnica que se realiza comparando

los resultados de una aplicacin con parmetros especficos con
los resultados de otra aplicacin previamente creada,
introduciendo los mismos parmetros de manera que se obtenga
un resultado exacto.
4) Prueba de esfuerzo (Stress Testing)
Se realiza cuando el SW es utilizado de la manera ms ruda
posible en un perodo de tiempo para ver si trabaja con altos
niveles de carga.

5) Pruebas de Uso:
A veces conseguir usuarios que no estn familiarizados con el
SW para probarlo por un tiempo determinado, ofrece
retroalimentacin a los desarrolladores acerca de las dificultades
que encontraron. Esta es la mejor maneta de realizar mejoras a la
interfaz.

6) Revisiones por Pares (Peer Reviews).

Son actividades efectivas para el control de la calidad. Pueden
aplicarse al anlisis, diseo y codificacin.
7) Revisin Tcnica formal (RTF):
Es una actividad de garanta de calidad de SW. Es una revisin
que incluye recorridos, inspecciones y revisiones cclicas

Estndares. El IEEE, ISO y otras organizaciones que

establecen estndares han producido una amplia variedad de
ellos para ingeniera de software y documentos relacionados.
Los estndares los adopta de manera voluntaria una
organizacin de software o los impone el cliente u otros
participantes. El trabajo del ACS es asegurar que los estndares
que se hayan adoptado se sigan, y que todos los productos del
trabajo se apeguen a ellos.
HERRAMIENTAS DE CALIDAD

Herramientas bsicas.

Diagrama de flujo: es una representacin grfica de un proceso.

Cada paso del proceso es representado por un smbolo diferente
que contiene una breve descripcin de la etapa de proceso. Los
smbolos grficos del flujo del proceso estn unidos entre s con
flechas que indican la direccin de flujo del proceso.

Diagrama causa efecto: tambin llamado Diagrama de

Ishikawa o Diagrama de Espina de Pescado. Muestra, por
medio de ejemplos, cmo la construccin sistemtica de estos
diagramas es capaz de ofrecer una visin sencilla y concentrada
del anlisis de las causas que contribuyen a una situacin
compleja.
A continuacin se citan una serie de caractersticas que ayudan a
comprender la naturaleza de la herramienta.

Impacto visual: Muestra las interrelaciones entre un efecto y

sus posibles causas de forma ordenada, clara, precisa y de un
solo golpe de vista.
Capacidad de comunicacin
Muestra las posibles interrelaciones causa-efecto permitiendo
una mejor comprensin del fenmeno en estudio, incluso en
situaciones muy complejas.
Centra la atencin de todos los componentes del grupo en un
problema especfico de forma estructurada y sistemtica.
Ejemplo de un diagrama causa-efecto
Pasos para la construccin del diagrama causa-efecto
Paso 1: Definir, sencilla y brevemente, el efecto o fenmeno
cuyas causas han de ser identificadas. El efecto debe ser:
Especfico
Para que no sea interpretado de diferente forma por los miembros
del grupo de trabajo, y para que las aportaciones se concentren
sobre el autntico efecto a estudiar.
No sesgado
Para no excluir posibles lneas de estudio sobre el efecto objeto
del anlisis.
Es conveniente definirlo por escrito especificando que es lo que
incluye y lo que excluye.
Paso 2: Colocar el efecto dentro de un rectngulo a la derecha de
la superficie de escritura y dibujar una flecha, que corresponder
al eje central del diagrama, de izquierda a derecha, apuntando
hacia el efecto. Ejemplo 1.
Paso 3: Identificar las posibles causas que contribuyen al efecto o
fenmeno de estudio.
Atendiendo a las caractersticas y particularidades del grupo de
trabajo y a las del problema analizado, se decidir cual de los dos
enfoques existentes para desarrollar este paso es el ms
adecuado:
Tormenta de Ideas
Proceso lgico paso a paso

En el caso de utilizar la Tormenta de Ideas la lista resultado de la

sesin ser la fuente primaria a utilizar en los siguientes pasos de
construccin del diagrama.
En el caso de utilizar un proceso lgico paso a paso, la fuente
primaria sern los propios componentes del grupo, aportando sus
ideas segn se va construyendo el diagrama.
Paso 4: Identificar las causas principales e incluirlas en el
diagrama.
a) En primer lugar se identificarn las causas o clases de causas
ms generales en la contribucin al efecto.
Esta clasificacin ser tal que cualquier idea de los miembros del
grupo podr ser asociada a alguna de dichas causas.

Muchos grupos comienzan utilizando las "5M" o las "5P" y,

despus de analizar ms en detalle el resultado, agrupan las causas
de forma ms adecuada a su propio problema.
b) En segundo lugar se escriben en un recuadro y se conectan
con la lnea central segn la figura siguiente.
Ejemplo 2
Paso 5: Aadir causas para cada rama principal. En este paso
se rellenan cada una de las ramas principales con sus causas
del efecto enunciado, es decir con causas de las causas
principales. Para incluir estas en el diagrama se escriben al
final de unas lneas, paralelas a la de la flecha central,
conectadas con la lnea principal correspondiente. Ejemplo 3
Paso 6: Aadir causas subsidiarias para las subcausas anotadas.
Cada una de estas causas se coloca al final de una lnea que se
traza para conectar con la lnea asociada al elemento al que afecta
y paralela a la lnea principal o flecha central.
Este proceso contina hasta que cada rama alcanza una causa
raz. Causa raz es aquella que:
-Es causa del efecto que estamos analizando
-Es controlable directamente
Ejemplo 4
Paso 7: Comprobar la validez lgica de cada cadena causal. Para
cada causa raz "leer" el diagrama en direccin al efecto analizado,
asegurndose de que cada cadena causal tiene sentido lgico y
operativo.
Este anlisis asegura que la ordenacin es correcta y tambin
puede ayudar a identificar factores causales intermedios u
omitidos.
Paso 8: Comprobar la integracin del diagrama. Finalmente
debemos comprobar, en una visin de conjunto del Diagrama la
existencia de ramas principales que:
-Tienen menos de 3 causas.
-Tienen, apreciablemente, ms o menos causas que las dems.
-Tienen menos niveles de causas subsidiarias que las dems.
La existencia de alguna de estas circunstancias no significa un
defecto en el diagrama pero sugiere una comprobacin a fondo
del proceso.
Paso 9: Conclusin y resultado. El resultado de la utilizacin de
esta herramienta es un diagrama ordenado de posibles causas
(teoras) que contribuyen a un efecto.
Checklist: Una lista de verificacin es un tipo de ayuda de trabajo
informativo que se utiliza para reducir el fracaso mediante la
compensacin de los posibles lmites del ser humano la memoria y
la atencin. Esto ayuda a garantizar la coherencia y la integridad en
el desempeo de una tarea. Un ejemplo bsico es la "lista de
tareas". Una lista de control ms avanzado sera un calendario, que
establece las tareas a realizar segn la hora del da o de otros
factores.

Grfica de control NP: es un tipo especial de grfica que se dirige

a la posibilidad de interpretar informacin derivada de un proceso
creando una imagen de las fronteras o lmites de variacin
permisibles.
Permite de manera objetiva determinar si un proceso se encuentra
en control o fuera de control.
 A) Determine lo que va a medirse:
Ser necesario identificar una medida clave que quiera medir a
travs del tiempo o contra algn otro factor. Esta medida deber
ser un indicador de calidad /productividad (cliente externo o
proceso interno) que nos de informacin til para la toma de
decisiones.
Algunos factores de medicin posibles son los siguientes:
Volumen: Por ejemplo qu tanto dentro de un perodo especfico.
Tiempo del ciclo: Qu tanto tiempo toma el realizar o llevar a
cabo algo.
Errores y Defectos: Cuntos errores en un perodo.
Desperdicio: Qu tanto es rechazado o retrabajado.
B) Recolecte los datos:
Algunas sugerencias para recolectar la informacin:
Utilice una muestra que contenga al menos 50 unidades /
artculos o elementos inspeccionados o factibles de ser revisados,
(la muestra debe ser lo suficientemente grande como para dar un
promedio de 3 o ms defectos por muestra).
Evite tomar muestras a travs de perodos prolongados (por
ejemplo reduzca las muestras grandes en perodos ms
manejables de 2 a 4 horas en lugar de uno de 24 horas).
Evite variar el tamao de las muestras.
Utilice un mnimo de 20 muestras.
Despus de haber tomado un mnimo de 20 muestras y calculado
el porcentaje de defectos de cada una, elabore la escala en el eje
vertical de la grfica
La escala debe reflejar lo que sea apropiado de acuerdo a la medida
que usted ha seleccionado. Elabore el eje horizontal con un marcaje
por cada fecha de la muestra.
Grafique el porcentaje de defectos. A continuacin calcule el
porcentaje promedio sumando todos los porcentajes de defectos y
divida el resultado entre el total de muestras sumadas. Dibuje una
lnea horizontal en la grfica con el valor resultante y nmbrela P.
C) Calcule los Lmites de Control
Los lmites de control le dirn si su proceso tiene un control
estadstico ( en el ejemplo slo se denota variacin por causa
comn, o la cantidad de variacin de da a da que podra esperarse
por causas comunes tales como alguna diferencia en materiales,
mtodos, equipo, etc.). Piense que los lmites de control son
fronteras invisibles. Mientras que los puntos se encuentren entre las
fronteras de control, todo estar bien. Sin embargo, cuando los
puntos rebasan estas fronteras se deber investigar las causas por las
que se han rebasado.
La media de las proporciones

P = media de las proporciones

m = nmero de muestras
Sumatoria de las proporciones
Ejemplo:
m=6
P = 1/6 * (0.05 +0.02 + 0.07 + 0.03 + 0.06 + 0.02)
P = 0,041666667

Nmero medio:
NP = P x n
NP = nmero medio;
n = tamao de la muestra ( n = 100 )
NP = 0,04167 * 100 = 4,166666667
Las frmulas que se utilizan para calcular los lmites de
control son:

LSC=4,166666667+3*(4,166666667*(1-0,041666667)) ^(1/2)
LSC= 10,16145607

LIC=4,166666667-3(4,166666667*(1-0,041666667)) ^(1/2)
LIC= -1,828122737

Como el lmite inferior de control no puede ser un nmero

negativo, se asume como LIC el menor valor posible, por
tanto LIC = 0.
 1 2 3 4 5 6
n 100 100 100 100 100 100
d 5 2 7 3 6 2
p 0.05 0.02 0.07 0.03 0.06 0.02

Defectuosas LSC LIC NP

5 10,16145607
2 10,16145607
7 10,16145607
3 10,16145607
6 10,16145607
2 10,16145607
0 4,166666667
0 4,166666667
0 4,166666667
0 4,166666667
0 4,166666667
0 4,166666667

Sacamos los datos y la estadstica

 12

10

8
Defectuosas
6 LSC
LIC
4 NP

0
1 2 3 4 5 6

Grafico de control NP
Histograma.

Un histograma es una representacin grfica de una

variable en forma de barras, donde la superficie de cada
barra es proporcional a la frecuencia de los valores
representados. En el eje vertical se representan las
frecuencias, y en el eje horizontal los valores de las
variables, normalmente sealando las marcas de clase, es
decir, la mitad del intervalo en el que estn agrupados los
datos.
Diagrama de dispersin.

El diagrama de correlacin es una representacin grfica en

un eje de coordenadas de los datos que se recogen sobre dos
variables para poder estudiar si existe relacin de causa efecto
entre ellas (Kume 1985b).

Se utiliza para comprender si se encuentran vinculadas entre

s dos magnitudes y en qu medida. Sirve para verificar
causas reales, definir y medir relaciones existentes entre dos
variables.