Dr.

Kaoru Ishikawa me parece que es muy radical en sus conceptos ya que es muy exigente
a la hora de hablar de calidad, como por ejemplo: El control de la calidad que no muestra
resultados no es control. Es muy estricto, cosa que me parece genial, ya que el proceso de
control de calidad debe llevarse a cabo con este tipo de parmetros, si queremos obtener los
resultados que cumplan con las necesidades de nuestros clientes, es decir, si queremos
obtener

resultados

de

calidad.

Dice que el control de calidad es responsabilidad de todos los trabajadores y divisiones de

la compaa. Tambin nos habla de la importancia de los mtodos estadsticos en el control
de la calidad, los cuales son parte fundamental de sta.
Armand Feigenbaum establece que Para que el control de calidad sea efectivo, debe
iniciarse con el diseo del producto y terminar slo cuando se encuentre en manos de un
consumidor satisfecho. Uno de los puntos que ms me llama la atencin es el que dice que
la calidad debe estar siempre orientada a la excelencia, y no basndose en el enfoque
tradicional de la falla. sta es una manera de ver el concepto de calidad muy interesante, ya
que rompe con todos los esquemas anteriores, que hablaban de prevencin de fallas.
Tambin dice algo muy importante de analizar y es lo siguiente: La automatizacin no es
la solucin a los problemas de calidad. Las actividades humanas son fundamentales en
cualquier programa de calidad total.

1.4.1 LA CALIDAD Y EL MUNDO GLOBALIZADO.

En 1954, Juran visit por primera vez el Japn y orient el Control Estadstico de la
Calidad a la necesidad de que se convierta en un instrumento de la alta direccin. Ese
propio ao dict seminarios a gerentes altos y medios. A partir de ese entonces hubo un
cambio en las actividades del control de calidad en Japn.
Juran seal que el control estadstico de la calidad tiene un lmite y que es necesario que el
mismo se convierta en un instrumento de la alta direccin, y dijo que para obtener calidad
es necesario que todos participen desde el principio. Si slo se hiciera como inspecciones

de la calidad, estuviramos solamente impidiendo que salgan productos defectuosos y no

que se produzcan defectos
Feigenbaum fue el fundador del concepto de Control Total de la Calidad (CTC) al cual
define como un sistema eficaz para integrar los esfuerzos en materia de desarrollo de
calidad, mantenimiento de la calidad, realizados por los diversos grupos de la organizacin,
de modo que sea posible producir bienes y servicios a los niveles ms econmicos y que
sean compatibles con la plena satisfaccin de los clientes
Siendo la calidad tarea de todos en una organizacin, l tema que se convirtiera en tarea de
nadie, entonces sugiri que el control total de la calidad estuviera respaldado por una
funcin gerencial bien organizada, cuya nica rea de especializacin fuera la calidad de
los productos y cuya nica rea de operaciones fuera el control de la calidad, de ah es que
nacen los llamados Departamentos de Control de la Calidad
Aos ms tarde, Ishikawa retoma el trmino de Feigenbaum de Control Total de la Calidad,
pero al estilo japons y prefiere llamarlo control de calidad en toda la empresa, y
significa que toda persona de la empresa deber estudiar, participar y practicar el control de
la calidad.

1.4.2. COMPROMISO TOTAL CON LA CALIDAD

La documentacin del sistema de calidad ser la siguiente (Vidal, 1999, p. 12):
Manual de calidad: documento principal del sistema, en l se recogen las
polticas de calidad, describe la estructura organizativa y de responsabilidades.
Manual de procedimientos: completa al manual de calidad, describe cmo se
deben de realizar las funciones descritas.
Instrucciones tcnicas: describe cmo se deben de realizar las tareas concretas y
especficas de un modo ms operativo.
Especificaciones tcnicas: establecen los valores y las tolerancias exigidos a los
materiales, procesos o productos.

 Planes de calidad: describe las formas de operar, los recursos y la secuencia de

actividades ligadas a la calidad para un determinado producto, servicio, contrato o
proyecto.
Documentos asociados: documentos de apoyo.
Registros de calidad: recogen los datos de las actividades efectuadas y sus
resultados.
Para desarrollar cada uno de los elementos del sistema de calidad se configuran los grupos
de mejora. Cada grupo estar formado por un miembro del comit de calidad, que ser el
responsable del rea de actuacin, y varios de los dirigentes del rea de actuacin
(Schonberger 1982 p 52).
Estos grupos pueden ser: (Harrintong, 1990, p. 54)
Grupo de costes totales de calidad: deben establecer el sistema y modelo de
clculo de los costes de calidad, as como su seguimiento y la forma de informar
peridicamente.
Grupo de acciones correctoras: disear un sistema para eliminar las causas de
las no conformidades y que los problemas de la empresa proporcionen
retroalimentacin.
Grupo para los indicadores de calidad: desarrollarn los indicadores que
reflejen cmo se van produciendo los requisitos clave.
Otros grupos que se pueden formar son: los de compras, servicio post venta, recepcin de
pedidos, produccin, etc.

1.4.3. EL AUMENTO DEL RIESGO ASOCIADO A LA POCA CALIDAD

Cuando se considera el riesgo en el contexto de la ingeniera del software, los tres pilares
conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos

preocupa, qu riesgos podran hacer que nuestro proyecto fracasara? El cambio es nuestra
preocupacin cmo afectarn los cambios en los requisitos del cliente, en las tecnologas
de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades
relacionadas con l, al cumplimiento de la planificacin temporal y al xito en general?
Para terminar, nos enfrentamos con elecciones qu mtodos y herramientas deberamos
emplear, cunta gente debera estar implicada, qu importancia hay que darle a la calidad?
Riesgo
Aunque ha habido amplios debates sobre la definicin adecuada para riesgo de software,
hay acuerdo comn en que el riesgo siempre implica dos caractersticas:

Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por

ejemplo,

no

hay

riesgos

de

un

100

por

ciento

de

probabilidad.

Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o

prdidas.
Riesgos

del

software

Todas las actividades de anlisis de riesgo presentadas hasta ahora tienen un solo objetivo:
ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una
estrategia

eficaz

debe

Evitar

considerar

Reduccin,

del
supervisin

aspectos:

el

Supervisar
Gestion

tres

riesgo.

el

riesgo

y
y

planes
gestin

riesgo.
de

contingencia.
del

riesgo

Tamao del producto: riesgos asociados con el tamao general del software a construir o a
modificar.
Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestin o
por

el

mercado.

 Caractersticas del cliente: riesgos asociados con la sofisticacin del cliente y la habilidad
del desarrollador para comunicarse con el cliente en los momentos oportunos.
Definicin del proceso: riesgos asociados con el grado de definicin del proceso del
software

su

seguimiento

por

la

organizacin

de

desarrollo.

Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las

herramientas

que

se

van

emplear

en

la

construccin

del

producto.

Tecnologa a construir: riesgos asociados con la complejidad del sistema a construir y la

tecnologa

punta

que

contiene

Identificacin

el

sistema.

del

riesgo

"Mientras que es intil intentar eliminar el riesgo y cuestionable el poder

minimizarlo, es esencial que los riesgos que se tomen sean los riesgos adecuados".
Antes de poder identificar los "riesgos adecuados" que se pueden tomar en un
proyecto de software, es importante poder identificar todos los riesgos que sean obvios
a
El

jefes

de

aumento

proyectos
del

riesgo

Proyeccion

Evaluacin

profesionales
asociado

del
la

del

del

impacto

software.
poca

calidad
Riesgo

del

riesgo

Tres factores afectan a las consecuencias probables de un riesgo, si ocurre: su naturaleza, su

alcance y cuando ocurre. La naturaleza del riesgo indica los problemas probables que
aparecern si ocurre. Por ejemplo, una interfaz externa mal definida para el hardware del
cliente (un riesgo tcnico) impedir un diseo y pruebas tempranas y probablemente lleve a
problemas de integracin ms adelante en el proyecto. El alcance de un riesgo combina la
severidad (cmo de serio es el problema?) con su distribucin general (qu proporcin
del proyecto se ver afectado y cuantos clientes se vern perjudicados?). Finalmente, la

temporizacin de un riesgo considera cundo y por cunto tiempo se dejar sentir el

impacto. En la mayora de los casos, un jefe de proyecto prefiere las "malas noticias"
cuanto

antes,

pero

en

algunos

casos,

cuanto

ms

tarden,

mejor.

El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos despus

de haber desarrollado con xito el software y de haberlo entregado al cliente. Estos riesgos
estn tpicamente asociados con las consecuencias del fallo del software una vez en el
mercado.
Aunque la probabilidad de fallo de un sistema de alta ingeniera es pequea, un defecto no
detectado en un sistema de control y supervisin basados en ordenador podra provocar
unas prdidas econmicas enormes, o peor, daos fsicos significativos o prdida de vidas
humanas. Pero el coste y beneficios funcionales del control y supervisin basados en
computadora a rnenudo superan al riesgo. Hoy en da, se emplean regularmente hardware y
software
Riesgos

para

el
y

control

de

peligros

sistemas
para

de

seguridad
la

crtica.
seguridad

La proyeccin del riesgo, tambin denominada estimacin del riesgo, intenta medir cada
riesgo de dos maneras -la probabilidad de que el riesgo sea real y las consecuencias de los
problemas asociados con el riesgo, si ocurriera. El jefe del proyecto, junto con otros
gestores y personal tcnico, realiza cuatro actividades de proyeccin del riesgo: (1)
establecer una escala que refleje la probabilidad percibida del riesgo; (2) definir las
consecuencias del riesgo; (3) estimar el impacto del riesgo en el proyecto y en el producto;
y (4) apuntar la exactitud general de la proyeccin del riesgo de manera que no haya
confusiones.