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 parámetros, 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 compañía. También nos habla de la importancia de los métodos estadísticos 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 diseño del producto y terminar sólo cuando se encuentre en manos de un

consumidor satisfecho”. Uno de los puntos que más me llama la atención es el que dice que

la calidad debe estar siempre orientada a la excelencia, y no basándose 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 prevención de fallas.

También dice algo muy importante de analizar y es lo siguiente: “La automatización no es

la solución 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 Japón y orientó el Control Estadístico de la

Calidad a la necesidad de que se convierta en un instrumento de la alta dirección. Ese

propio año dictó seminarios a gerentes altos y medios. A partir de ese entonces hubo un

cambio en las actividades del control de calidad en Japón.

Juran señaló que el control estadístico de la calidad tiene un límite y que es necesario que el

mismo se convierta en un instrumento de la alta dirección, y dijo que “para obtener calidad

es necesario que todos participen desde el principio. Si sólo se hiciera como inspecciones

de la calidad, estuviéramos 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 organización,

de modo que sea posible producir bienes y servicios a los niveles más económicos y que

sean compatibles con la plena satisfacción de los clientes”

Siendo la calidad tarea de todos en una organización, él temía que se convirtiera en tarea de

nadie, entonces sugirió que el control total de la calidad estuviera respaldado por una

función gerencial bien organizada, cuya única área de especialización 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

Años más tarde, Ishikawa retoma el término de Feigenbaum de Control Total de la Calidad,

pero al estilo japonés 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 documentación del sistema de calidad será la siguiente (Vidal, 1999, p. 12):

· Manual de calidad: documento principal del sistema, en él se recogen las

políticas de calidad, describe la estructura organizativa y de responsabilidades.

· Manual de procedimientos: completa al manual de calidad, describe cómo se

deben de realizar las funciones descritas.

· Instrucciones técnicas: describe cómo se deben de realizar las tareas concretas y

específicas de un modo más operativo.

· Especificaciones técnicas: 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 actuación, y varios de los dirigentes del área de actuación

(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

cálculo de los costes de calidad, así como su seguimiento y la forma de informar

periódicamente.

· Grupo de acciones correctoras: diseñará un sistema para eliminar las causas de

las no conformidades y que los problemas de la empresa proporcionen

retroalimentación.

· Grupo para los indicadores de calidad: desarrollarán los indicadores que

reflejen cómo se van produciendo los requisitos clave.

Otros grupos que se pueden formar son: los de compras, servicio post venta, recepción de

pedidos, producción, etc.

1.4.3. EL AUMENTO DEL RIESGO ASOCIADO A LA POCA CALIDAD

Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares

conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos

preocupa, ¿qué riesgos podrían hacer que nuestro proyecto fracasara? El cambio es nuestra

preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías

de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades

relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general?

Para terminar, nos enfrentamos con elecciones ¿qué métodos y herramientas deberíamos

emplear, cuánta gente debería estar implicada, qué importancia hay que darle a la calidad?

Riesgo

Aunque ha habido amplios debates sobre la definición adecuada para riesgo de software,

hay acuerdo común en que el riesgo siempre implica dos características:

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

ejemplo, no hay riesgos de un 100 por ciento de probabilidad.

• Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o

pérdidas.

Riesgos del software

Todas las actividades de análisis 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 considerar tres aspectos:

• Evitar el riesgo.

• Supervisar el riesgo.

• Gestion del riesgo y planes de contingencia.

Reducción, supervisión y gestión del riesgo

• Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a

modificar.

• Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o

por el mercado.

• Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad

del desarrollador para comunicarse con el cliente en los momentos oportunos.

• Definición del proceso: riesgos asociados con el grado de definición del proceso del

software y su seguimiento por la organización de desarrollo.

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

herramientas que se van a emplear en la construcción del producto.

• Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la

tecnología punta que contiene el sistema.

Identificación del riesgo

"Mientras que es inútil 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 jefes de proyectos y profesionales del software.

El aumento del riesgo asociado a la poca calidad

Proyeccion del Riesgo

Evaluación del impacto 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

aparecerán si ocurre. Por ejemplo, una interfaz externa mal definida para el hardware del

cliente (un riesgo técnico) impedirá un diseño y pruebas tempranas y probablemente lleve a

problemas de integración más adelante en el proyecto. El alcance de un riesgo combina la

severidad (¿cómo de serio es el problema?) con su distribución general (¿qué proporción

del proyecto se verá afectado y cuantos clientes se verán perjudicados?). Finalmente, la

temporización de un riesgo considera cuándo y por cuánto tiempo se dejará sentir el

impacto. En la mayoría de los casos, un jefe de proyecto prefiere las "malas noticias"

cuanto antes, pero en algunos casos, cuanto más tarden, mejor.

El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos después

de haber desarrollado con éxito el software y de haberlo entregado al cliente. Estos riesgos

están típicamente asociados con las consecuencias del fallo del software una vez en el

mercado.

Aunque la probabilidad de fallo de un sistema de alta ingeniería es pequeña, un defecto no

detectado en un sistema de control y supervisión basados en ordenador podría provocar

unas pérdidas económicas enormes, o peor, daños físicos significativos o pérdida de vidas

humanas. Pero el coste y beneficios funcionales del control y supervisión basados en

computadora a rnenudo superan al riesgo. Hoy en día, se emplean regularmente hardware y

software para el control de sistemas de seguridad crítica.

Riesgos y peligros para la seguridad

La proyección del riesgo, también denominada estimación 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 técnico, realiza cuatro actividades de proyección 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 proyección del riesgo de manera que no haya

confusiones.