1 / 46

2. Historia de Calidad del Software

2. Historia de Calidad del Software. LS3148 - Calidad de Software 3IM1 Universidad Antonio de Nebrija Justo Hidalgo –con algunos apuntes de Manuel Fernando Juan-. Historia del Control de Calidad. El control de calidad tiene tres etapas: La especificación de lo que se quiere.

annick
Download Presentation

2. Historia de Calidad del Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  19. Ishikawa (VI) Aplicación de métodos estadísticos. Paretos, diagramas causa-efecto, histogramas, nubes de puntos, tablas de control, etc. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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: Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  25. Juran (V) Los defectos en los productos software son de dos tipos: Controlables por el trabajador. Controlables 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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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´.’ Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  30. Juran (y X) Resumen: Trilogía de Juran Planificación de la calidad. Control de la calidad. Mejora de la calidad. Calidad de Software - 2. Historia - Justo Hidalgo

  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 Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  36. Crosby (II) Crosby define cinco niveles de madurez, basados en la actitud de los gerentes: Incertidumbre Despertar Esclarecimiento Sabiduría Certidumbre La gestión de la calidad evoluciona (madura) siguiendo el patrón anterior de cinco niveles. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

  43. Crosby (IX) En la etapa de certidumbre, el construir software de calidad, a tiempo y dentro del presupuesto, es posible. Calidad de Software - 2. Historia - Justo Hidalgo

  44. Crosby (y X) ¿Es cumplimiento de los requisitos suficiente para hacer un software de calidad? ¿Es cero defectos un objetivo realista? Calidad de Software - 2. Historia - Justo Hidalgo

  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 Definido Gestionado Optimizante Calidad de Software - 2. Historia - Justo Hidalgo

  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. Calidad de Software - 2. Historia - Justo Hidalgo

More Related