2. Historia de Calidad del Software

1
2. Historia de Calidad del Software

• LS3148 - Calidad de Software
• 3IM1
• Universidad Antonio de Nebrija
• Justo Hidalgo con algunos apuntes de Manuel
  Fernando Juan-

2
Historia del Control de Calidad

• El control de calidad tiene tres etapas
• La especificación de lo que se quiere.
• La producción de algo que satisface la
  especificación.
• La inspección de lo producido para comprobar si
  realmente satisface la especificación.

3
La Antigüedad (I)
Hace 1.000.000 de años aproximadamente, el hombre
empieza a diferenciarse del resto de los animales
a través del control de su entorno y la
fabricación de herramientas. Hace 10.000 años,
comienza a hacer herramientas complejas que
constan de varias partes. Hasta esta fecha, cada
hombre se hace sus propias herramientas. En el
Egipto antiguo ya existía el concepto de piezas
intercambiables.
4
La Antigüedad (II)
En Egipto los arquitectos responsables de
construir las pirámides ya empleaban la
estandarización para el tallado exacto de las
piedras. El seguir unos procesos de tallado
definidos hacía innecesaria las inspecciones
finales. El la antigua Roma la estandarización
era esencial sistema métrico normalizado,
normalización para el tamaño de los ladrillos y
las tuberías, y normas de construcción. Ya había
reuniones para mejorar la calidad de las
edificaciones.
5
La Antigüedad (III)
En todo caso, la calidad de los productos
dependía del cumplimiento de los procesos y
normas establecidas. En China, desde el siglo 20
antes de Cristo, en la dinastía Xia, existía una
industria organizada, legislación, normalización,
mediciones e inspecciones. Había departamentos
centralizados a cargo de producción, manufactura,
normalización y supervisión de los
productos. Los proyectos de arquitectura estaban
diseñados y planificados, con complejas división
de tareas.
6
La Antigüedad (y IV)
Desde la edad media hasta finales del siglo XVIII
la producción de bienes y servicios se realizaba
fundamentalmente por individuos o negocios
familiares. El control de calidad era llevado a
cabo principalmente por el propio productor. Hay
rastros de control de calidad en la Inglaterra
del siglo XI. En la Francia de los siglos XVII y
XVII, la construcción naval ya poseía controles
de calidad. Se estudiaban los defectos de los
barcos, los ingenieros supervisaban su
construcción en los puertos y los suministradores
se escogían basandose en factores como retrasos,
costes y prestaciones.
7
Tiempos Modernos (I)
1840 concepto de límite superior de
control. 1870 límites de tolerancia. Límite
superior y límite inferior. Todavía queda el
problema de las piezas que están fuera de los
límites de control probabilidad de ocurrencia,
causa, coste, coste de reparación, como evitarlo,
coste de evitarlo, ... Minimización del número
de piezas defectuosas.
8
Tiempos Modernos (II)
Introducción de inspecciones en las diferentes
etapas de desarrollo para detectar las partes
defectuosas antes de que se ensamblen para formar
el producto. En cada etapa se debe determinar el
número óptimo de partes defectuosas para
maximizar la rentabilidad. Otro problema es el
de las pruebas para verificar el producto No
todas las características de la calidad son fácil
o económicamente rentables de probar.
9
Tiempos Modernos (III)
Introducción del concepto de muestreo, pero cuál
es la mínima muestra que nos da suficiente
confianza en la calidad del producto? 1924
concepto de control estadístico de la calidad,
con la introducción de los diagramas de
control. Esto es posible debido al interés y los
esfuerzos en estandarización de principios de
siglo Gran Bretaña establece en 1901 el primer
organismo nacional de normalización. Tras la 1ª
Guerra Mundial se vio la necesidad de la
estandarización. Entre 1917 y 1920 Holanda,
Alemania, Francia, Suiza, Estados Unidos,
Bélgica, Canadá y Austria establecieron
organismos de normalización.
10
Tiempos Modernos (IV)
Cambio de mentalidad 1787 introdujo el concepto
de piezas intercambiables, pero con la mentalidad
de una ciencia exacta. A partir de 1900 se
introdujo los conceptos de probabilidad y
estadística. Se pasa de no conocer las causas de
no obtener los atributos de calidad deseados de
unos productos, a la confianza de que por seguir
unos procesos de producción determinados se va a
conseguir unos productos dentro de unos límites
de control. Si en cualquier caso hay productos
que se salen de los límites de control, se es
capaz de analizar los problemas y determinar las
causas.
11
Tiempos Modernos (y V)
1- Minimización del número de errores. 2-
Minimización de los costes de inspección. 1776
Adam Smith publica La riqueza de las naciones
Se habla de la división del trabajo y la
especialización como manera de aumentar la
productividad. 1880 Frederick Taylor Gestión
Científica.
12
Fundadores (I)
Principios de la gestión científica de
Taylor 1- Desarrollar una ciencia para cada
elemento del trabajo de cada individuo, que
reemplace la subjetividad. 2- Seleccionar y
formar de una manera científica al trabajador
para hacer su trabajo. 3- Cooperar con los
trabajadores para asegurar que el trabajo se
lleva a cabo de acuerdo a los principios de la
ciencia que se ha desarrollado. 4- Dividir el
trabajo y la responsabilidad entre los
trabajadores y sus jefes.
13
Fundadores (y II)
Henry L. Gantt Colaborador de Taylor. A parte de
la gestión científica, Gantt buscó la mejora de
la productividad a través de ofrecer bonos e
incentivos a los trabajadores y a sus jefes, si
terminaban sus trabajos o tareas en menos tiempo
del previsto. No obstante Gantt en más conocido
por los diagramas de Gant que por otra cosa. Un
diagrama de Gantt es una representación gráfica
de para planificar y controlar el trabajo.
14
Ishikawa (I)

• La filosofía de Ishikawa
• Explica el milagro económico japonés tras la 2ª
  Guerra mundial
• Control de calidad en toda la compañía.
• Auditorías de calidad hechas por la alta
  dirección de la compañía.
• Educación y formación en control de calidad.
• Círculos de calidad.
• Aplicación de métodos estadísticos.
• Actividades de promoción de la calidad a nivel de
  estado.

15
Ishikawa (II)
Control de calidad en toda la compañía. Todos
los departamentos y todos los niveles están
implicados en su trabajo, guiados por políticas
de calidad escritas por la alta dirección. Los
desarrolladores del software están comprometidos
con producir un software de calidad, guiados por
los gerentes que tienen el mismo objetivo.
16
Ishikawa (III)
Auditorías de calidad hechas por la alta
dirección de la compañía. La alta dirección
visita cada departamento para descubrir y
eliminar los obstáculos a los objetivos de
productividad y calidad. Normalmente la calidad
del software es auditada por un equipo de
expertos, pero de vez en cuando la alta dirección
interviene para mostrar su conocimiento y
compromiso.
17
Ishikawa (IV)
Educación y formación en control de
calidad. Formación para todos y a todos los
niveles. La calidad es responsabilidad de todos y
cada uno de los participantes en el desarrollo
del software. La formación sobre como se hace
software de calidad debe conseguir imponer la
disciplina necesaria para alcanzar los objetivos.
18
Ishikawa (V)
Círculos de calidad. Los círculos de calidad son
pequeños grupos que se reúnen informalmente, para
analizar los métodos de trabajo que están usando
y ver la manera de mejorarlos. Están compuestos
por los trabajadores, supervisores y gerentes,
etc. Proporciona el foro para discutir los
problemas del desarrollo del software en la
organización y determinar mejores maneras de
desarrollar software.
19
Ishikawa (VI)
Aplicación de métodos estadísticos. Paretos,
diagramas causa-efecto, histogramas, nubes de
puntos, tablas de control, etc.
20
Ishikawa (y VII)
Actividades de promoción de la calidad a nivel de
estado. Mes de la calidad (Noviembre), en el que
se entrega el Premio Deming. Incentivos a los
contratos por mejoras de la calidad.
21
Juran (I)
La filosofía de Joseph M. Juran Fundador del
instituto Juran, que ofrece consultoría y
formación en calidad. Ha trabajado como
ingeniero, director corporativo en el sector
privado, y administrador y profesor en el sector
público. Calidad adecuación al uso. Centrarse
en las necesidades del cliente / usuario.
22
Juran (II)
Para alcanzar los retos de mejora de la calidad
requeridos por Japón tras la 2ª Guerra Mundial,
Juran prescribió Estructuración anual de las
mejoras de calidad. Un programa masivo de
formación en calidad. Liderazgo desde la alta
dirección de las organizaciones en
calidad. Influyendo, junto con Deming, en la
transformación de Japón en lo que es ahora.
23
Juran (III)
La realidad actual del software es parecida a la
de la industria electrónica japonesa en la
posguerra Muchos sistemas software no cumplen
los requisitos, ya sea por mala interpretación,
problemas de presupuesto o falta de
usabilidad. Es necesario plantearse objetivos de
calidad anuales y estructurar las estrategias
para alcanzarlos. Para ello
24
Juran (IV)
1. Análisis de los síntomas de los defectos y
fallos. 2. Desarrollar una teoría(s) de las
causas de estos síntomas. 3. Probar la teoría(s)
hasta obtener certidumbre sobre las causas. 4.
Aplicar las acciones de mejora necesarias.
25
Juran (V)
Los defectos en los productos software son de dos
tipos Controlables por el trabajador. Control
ables por la gerencia. Este último tipo se
refiere a errores que el trabajador no puede
evitar por más que quiera, y que solo pueden ser
resueltos por la gerencia.
26
Juran (VI)
Si el trabajador 1- Sabe qué debe hacer. 2-
Sabe cual debe ser el resultado de su propio
trabajo. 3- Tiene medios para controlar el
resultado. y aun así el resultado de su trabajo
es defectuoso, el trabajador es responsable. Si
no se cumple alguna de las tres condiciones
anteriores, el responsable es la gerencia.
27
Juran (VII)
Un comentario de Deming a esto es Llamar la
atención a un trabajador (desarrollador de
software) acerca de un acto de descuido por su
parte en su trabajo, dentro de un clima general
de descuido, es una perdida de tiempo y sólo
puede generar conflictos, ya que el descuido es
generalizado, y es debido a un fallo de la
dirección, no de los trabajadores.
28
Juran (VIII)
Uno de los principales problemas en el desarrollo
de software es el proveniente de que el
desarrollador no sabe exactamente lo que debe
hacer. Esto proviene del hecho de que las
especificaciones cambian frecuentemente durante
el desarrollo y la comunicación de estos cambios
a los desarrolladores no es adecuada. En
software el trabajador normalmente ve el
resultado de su trabajo y tiene medios para
influir en el.
29
Juran (IX)
El el área del desarrollo de software, lo más
importante para establecer los objetivos anuales
de mejora es el saber de que punto se
parte. Identificar los errores que se cometen y
averiguar sus causas. Para producir software de
calidad es necesario tanto el compromiso de la
dirección de la organización como de los
desarrolladores y de los gerentes a todos los
niveles.
30
Juran (y X)
Resumen Trilogía de Juran Planificación de la
calidad. Control de la calidad. Mejora de la
calidad.
31
Deming (I)
La filosofía de W. Edwards Deming Deming es el
que difundió a nivel mundial los principios del
control estadístico de la calidad de
Shewhart. El control estadístico de la calidad
es la aplicación de los principios y técnicas de
la estadística en todas las etapas de la
producción, mantenimiento y servicio, dirigidas
hacia la satisfacción rentable de la demanda.
Deming
32
Deming (II)
En desarrollo de software, un método aceptado
para la mejora de la calidad es el de las
inspecciones. Tras la inspección, los errores
detectados, tanto de diseño como del código, se
categorizan para facilitar la determinación de
las causas.
33
Deming (III)
No obstante, Deming dice No se puede
inspeccionar calidad dentro de un producto. Es
decir, la calidad se debe construir dentro del
producto. Hay que hacer un producto con la
calidad dentro de el. No se puede meter después.
Inspecciones y pruebas exhaustivas no garantizan
la calidad, es demasiado tarde. La fase de
pruebas del software es ya demasiado tarde para
introducir calidad dentro del software, si no
estaba allí desde el principio.
34
Deming (y IV)
Deming popularizó también el método de Shewhart
de atacar problemas, el Plan - Do - Check - Act
(PDCA). Se llama normalmente el ciclo de Deming.
35
Crosby (I)
La filosofía de Philip Crosby Fundador de la
Philip Crosby Associates en 1979. Antes,
vicepresidente corporativo de ITT, responsable
mundial de calidad. Comenzó desde inspector en
las líneas de fabricación, ascendiendo hasta
fundar su propia compañía.
36
Crosby (II)
Crosby define cinco niveles de madurez, basados
en la actitud de los gerentes Incertidumbre Desp
ertar Esclarecimiento Sabiduría Certidumbre La
gestión de la calidad evoluciona (madura)
siguiendo el patrón anterior de cinco niveles.
37
Crosby (III)
En la etapa de incertidumbre hay un cierto número
de hechos que todo el mundo asume La calidad
no se puede definir. Como no se puede definir, no
se puede medir. El problema con la calidad es que
los trabajadores no se preocupan. La calidad es
deseable, pero no podemos permitirnosla. El
software es diferente. Los errores son
inevitables. En el mundo del software hay
generalmente acuerdo en todos estos puntos,
especialmente en el último acerca de la
inevitabilidad de los errores.
38
Crosby (IV)
Es más un problema de mentalidad que de problemas
reales con la calidad. Existe la mentalidad de
que calidad, coste y plazos son tres aspectos
mutuamente exclusivos. No es así según Crosby
se pueden obtener mejoras significativas en coste
y plazos enfocandose a la calidad. También
Deming afirma que la única manera de incrementar
la productividad y reducir los costes en
incrementando la calidad.
39
Crosby (V)
En la etapa de despertar, los únicos momentos en
que el personal de aseguramiento de la calidad
del software es llamado es en tiempos de crisis
Los clientes se quejan a cerca de la calidad
del software entregado o los proyectos de
desarrollo están descontrolados. La
documentación no se ha hecho, o no coincide lo
que aparece en ella con lo que el software hace
realmente.
40
Crosby (VI)
La etapa de esclarecimiento ocurre cuando se
comprende que el aseguramiento de la calidad del
software es parte de la gestión del desarrollo
del software, y una actividad útil. Se
establecen objetivos de calidad y se planifica su
cumplimiento, tanto a nivel de organización como
de proyecto. En un proyecto de desarrollo de
software, hay requisitos de preparar planes no
solo para el desarrollo, sino también para la
gestión de la configuración y el aseguramiento de
la calidad.
41
Crosby (VII)
El plan de aseguramiento de la calidad se escribe
antes que el resto de planes para asegurar que la
calidad se construye en el producto, y no se
trata de introducir posteriormente. El plan de
aseguramiento de la calidad del software debe
reflejar la política y objetivos de la
organización, y establecer estrategias y
directrices dentro del proyecto.
42
Crosby (VIII)
La etapa de sabiduría se alcanza cuando la
organización se da cuenta que la calidad del
software solo se puede construir dentro del
producto con un esfuerzo consciente de todas las
partes implicadas. Los gerentes o responsables
del proyecto son los que toman las decisiones
iniciales de planificación. Los responsables del
aseguramiento de calidad del software deben estar
presentes en esta toma de decisiones. El
personal de aseguramiento de la calidad del
software debe estar presente desde el mismo
momento que el proyecto es concebido, para
asegurar que la calidad se construye en el
producto.
43
Crosby (IX)
En la etapa de certidumbre, el construir software
de calidad, a tiempo y dentro del presupuesto, es
posible.
44
Crosby (y X)
Es cumplimiento de los requisitos suficiente
para hacer un software de calidad? Es cero
defectos un objetivo realista?
45
Otros (I)
Watts Humphrey Adapta los niveles de Crosby y
los usa para caracterizar la madurez del proceso
de desarrollo del software Inicial Repetible Def
inido Gestionado Optimizante
46
Otros (y II)
Victor Basili El Quality Improvement Paradigm
y la Experience Factory La factoría de
experiencia es la organización para el reuso de
la experiencia ganada durante el ciclo de vida
del producto software. Es una organización
lógica y física separada de la organización de
desarrollo dedicada a extraer esta experiencia y
a distribuirla por el resto de la organización.