ATRIBUTOS DE LA NORMA PARA CALIDAD EXTERNA

1. ¿Qué es calidad?
2. Evolución de la calidad
3. Calidad de sistemas de información. 
4. Defectos y errores de calidad en los sistemas de información.
5. Mediciones de software
6. Estimación de Costos
7. Modelos de calidad
8. Atributos de la norma para calidad 

ATRIBUTOS DE LA NORMA PARA CALIDAD EXTERNA

1. FUNCIONALIDAD

Adecuación: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.

Exactitud: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisión.

Interoperabilidad: Capacidad del producto software para interactuar con uno o más sistemas especificados.

Seguridad de acceso: Capacidad del producto software para proteger información y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados

Cumplimiento funcional: Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con funcionalidad.

2. CONFIABILIDAD (FIABILIDAD)

Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software.

Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software o de infringir sus interfaces especificados.

Capacidad de recuperación: Capacidad del producto software para reestablecer un nivel de prestaciones especificado y de recuperar los datos directamente afectados en caso de fallo.

Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a normas, convenciones o regulaciones relacionadas con al fiabilidad.

3. FACTIBILIDAD DE USO (USABILIDAD)

Capacidad para ser entendido: Capacidad del producto software que permite al usuario entender si el software es adecuado y cómo puede ser usado para unas tareas o condiciones de uso particulares.

Capacidad para ser aprendido: Capacidad del producto software que permite al usuario aprender sobre su aplicación.

Capacidad para ser operado: Capacidad del producto software que permite al usuario operarlo y controlarlo.

Capacidad de atracción: Capacidad del producto software para ser atractivo al usuario.

Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a normas, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.

4. EFICIENCIA

Comportamiento temporal: Capacidad del producto software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas.

Utilización de recursos: Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas.

Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la eficiencia.

5. MANTENIBILIDAD

Capacidad para ser analizado: Es la capacidad del producto software para serle diagnosticadas deficiencias o causas de los fallos en el software, o para identificar las partes que han de ser modificadas.

Capacidad para ser cambiado: Capacidad del producto software que permite que una determinada modificación sea implementada.

Estabilidad: Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software.

Capacidad para ser probado: Capacidad del producto software que permite que el software modificado sea validado.

Cumplimiento de la mantenibilidad : Capacidad del producto software para adherirse a normas o convenciones relacionadas con la mantenibilidad.

8. PORTABILIDAD

Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el propio software considerado.

.

Instalabilidad : Capacidad del producto software para ser instalado en un entorno especificado.

Coexistencia: Capacidad del producto software para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes.

Capacidad para reemplazar: Capacidad del producto software para ser usado en lugar de otro producto software, para el mismo propósito, en el mismo entorno.

Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad.

MODELOS DE CALIDAD

1. ¿Qué es calidad?
2. Evolución de la calidad
3. Calidad de sistemas de información. 
4. Defectos y errores de calidad en los sistemas de información.
5. Mediciones de software
6. Estimación de Costos
7. Modelos de calidad

¿Que es la norma ISO 9126?

La Norma ISO/IEC 9126 es un estándar internacional para la evaluación del software que surge debido a la necesidad de un modelo único para expresar la calidad de un software. Fue publicado en 1992 con el nombre de “Information technology Software product evaluation: Quality characteristics and guidelines for their use”, en el cual se establecen las características de calidad para productos de software.

Ámbitos de uso de ISO/IEC 9126

• Validar la integridad de una definición de requisitos;
• Identificar los requisitos del software;
• Identificar los objetivos del diseño del software;
• Identificar los objetivos de la prueba de software;
• Identificar el criterio de aseguramiento de calidad;
• Identificar el criterio de aceptación para un producto de software completo.
• Priorizar los recursos en los aspectos más importantes en términos de calidad.
• Etc.

Características

• FUNCIONALIDAD

Esta característica permite calificar si un producto de software maneja en forma adecuada el conjunto de funciones que satisfagan las necesidades para las cuales fue diseñado.

Atributos:Adecuación. Exactitud. Interoperabilidad. Conformidad. Seguridad.

• CONFIABILIDAD

Se refieren a la capacidad del software de mantener su nivel de ejecución bajo condiciones normales en un periodo de tiempo establecido.
Sub-características: Nivel de Madurez. Tolerancia a fallas. Recuperación.

• USABILIDAD

Característica que permiten evaluar el esfuerzo necesario que deberá invertir el usuario para utilizar el sistema.
Atributos: Comprensibilidad. Facilidad de Aprender. Operabilidad.

• EFICIENCIA

Esta característica permite evaluar la relación entre el nivel de funcionamiento del software y la cantidad de recursos usados.
Aspectos a evaluar: Comportamiento con respecto al Tiempo. Comportamiento con respecto a Recursos.

• MANTENIBILIDAD

Aquí permite medir el esfuerzo necesario para realizar modificaciones al software, ya sea por la corrección de errores o por el incremento de funcionalidad.
Factores: Capacidad de análisis. Capacidad de modificación. Estabilidad. Facilidad de Prueba.

• PORTABILIDAD

Se refiere a la habilidad del software de ser transferido de un ambiente a otro.
Aspectos: Adaptabilidad. Facilidad de Instalación. Conformidad. Capacidad de reemplazo.

ESTIMACIÓN DE COSTOS

1. ¿Qué es calidad?
2. Evolución de la calidad
3. Calidad de sistemas de información. 
4. Defectos y errores de calidad en los sistemas de información.
5. Mediciones de software
6. Estimación de Costos
7. Modelos de calidad

Estimación de Costos

Medidas relacionadas con el tamaño del código ( LOC - Lines of code). Esta forma de medir el tamaño de un software era utilizado cuando los lenguajes de programación, patrones de desarrollo y entornos de desarrollo (IDE), no estaban ampliamente desarrollados. Hoy en día es impráctico tratar de estimar el software a través de sus líneas de código ya que depende de la experiencia de los programadores o si hablamos de lenguajes de programación dinámicos como Ruby, Scala y Groovy o herramientas e IDEs que facilitan gran parte del trabajo de programación.

Medidas relacionadas con la función (UFC – Puntos de Función). El total de puntos de función no es una característica simple sino que es una combinación de características del software a las cuales se les asigna un valor que cambia dependiendo de su complejidad.UFC es igual a la suma de los “n” elementos evaluados por el peso asignado al tipo de función.
Sin embargo a lo largo del proyecto las funciones cambian, las métricas de puntos de función tienen en cuenta esto y multiplican los UFC iniciales por un factor de complejidad (asignándoles un factor de peso que va desde 3 a 15 puntos). Una desventaja de los puntos de función se presenta cuando el sistema está orientado por eventos. Por eso algunos autores piensan que UFC no es muy útil para medir productividad.

Los Puntos de Objeto (PO). Los PO se utilizan en el modelo de estimación Cocomo II con el nombre de Puntos de Aplicación. Estos son una alternativa a los UFC, y son usados en los lenguajes orientados a objetos y de scripts. Dan valor a cada pantalla dependiendo de su complejidad: simples = 1, medianamente complejas = 2, muy complejas = 3. Los reportes van de 2 a 8 dependiendo del nivel de complejidad, y los módulos en lenguaje imperativo como Java o C++ se contabilizan como 10. Esto puede ser relacionado directamente a las historias de usuario de algunas metodologías agiles con lo cual facilita la estimación de la iteración.

Modelo Constructivo de Costo: COCOMO II

Uno de los modelos de estimación más usados es COCOMO (Constructive Cost Model) creado por el Dr. Barry Boehm. COCOMO apareció por primera vez en su libro Software Engineering Economics [1] en 1981. En 1999 se definió la segunda versión del modelo que toma en cuenta el proyecto, el producto, el hardware y la experiencia del equipo de desarrollo en sus fórmulas de estimación de costo, incluyendo mecanismos de predicción de tiempo.

Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes momentos del desarrollo ya que la estimación de costos debe de ser un proceso dinámico a lo largo del desarrollo, actualizando constantemente las variables, la evolución del equipo de desarrollo, las herramientas y lenguajes involucrados. Los distintos niveles son:

Construcción de prototipos. Las estimaciones de tamaño están basadas en puntos de aplicación con base en componentes reutilizables, prototipos y la fórmula para estimar el esfuerzo requerido es muy simple: tamaño / productividad.

Diseño inicial. Está basado en los requerimientos originales del sistema a un alto nivel (pantallas, reportes, procesos, transacciones) lo que son traducidos a puntos de aplicación, esto nos sirve para hacer una predicción temprana del costo.

Reutilización. Este nivel se utiliza para calcular el esfuerzo requerido para integrar el código generado por los IDE’s o herramientas de generación de código reutilizable como Spring Roo o Genexus por ejemplo, tomando en cuenta componentes reutilizables que facilitan el desarrollo como Apache Commons.

Post-arquitectura. Ya diseñado el sistema se pueden hacer estimaciones más precisas del tamaño del software, aquí es importante señalar que el software tiene una tasa de crecimiento de los requerimientos del sistema entre el 2 y el 5 por ciento mensual, por lo cual no es posible hacer una estimación exacta pero las predicciones de costo se pueden acercar mucho a la realidad gracias a la aplicación de métricas que nos permiten tener una variación muy pequeña con respecto al producto final.

Cocomo está basado en fórmulas para hacer las estimaciones, véase la figura 1 donde se estima el esfuerzo del personal por mes (PM), después se hace la estimación del tamaño del proyecto (SIZE) y finalmente se obtiene una proyección del esfuerzo requerido (B) contemplando los factores involucrados (SF).

MODELO COCOMO 81

ver 

MEDICIONES DE SOFTWARE

1. ¿Qué es calidad?
2. Evolución de la calidad
3. Calidad de sistemas de información. 
4. Defectos y errores de calidad en los sistemas de información.
5. Mediciones de software
6. Estimación de Costos

MEDICIONES DE SOFTWARE

Medimos para mejorar cuando recogemos la información cuantitativa que nos ayuda a identificar obstáculos, problemas de raíz, in eficiencias y otras oportunidades para mejorar la calidad del producto y el rendimiento del proceso.

Las métricas del software se refieren a un amplio elenco de mediciones para el software de computadora. La medición se puede aplicar al proceso del software con el intento de mejorarlo sobre una base continua. Se puede utilizar en el proyecto del software para ayudar en la estimación, el control de calidad, la evaluación de productividad y el control de proyectos. Finalmente, el ingeniero de software puede utilizar la medición para ayudar a evaluar la calidad de los resultados de trabajos técnicos y para ayudar en la toma de decisiones táctica a medida que el proyecto evoluciona.

·         Medidas métricas e indicadores

Aunque los términos medida, medición y métricas se utilizan a menudo indistintamente, es importante destacar las diferencias sutiles entre ellos. Como los términos «medida» y «medición» se pueden utilizar como un nombre o como un verbo, las definiciones de estos términos se pueden confundir.

Dentro del contexto de la ingeniería del software, una medida proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto.

La medición es el acto de determinar una medida.

Un ingeniero del software recopila medidas y desarrolla métricas para obtener indicadores.

Un indicador es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del software, del proyecto de software o del producto en sí.

Un indicador proporciona una visión profunda que permite al gestor de proyectos o a los ingenieros de software ajustar el producto, el proyecto o el proceso para que las cosas salgan mejor.

Las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo. Su intento es proporcionar indicadores que lleven a mejoras de los procesos de software a largo plazo.

·         Los indicadores de proyecto permiten al gestor de proyectos del software:

(1)Evaluar el estado del proyecto en curso;

(2) Seguir la pista de los riesgos potenciales;

(3) Detectar las áreas de problemas antes de que se conviertan en «críticas»;

(4) Ajustar el flujo y las tareas del trabajo, y

(5) Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo del software.

DEFECTOS Y ERRORES DE CALIDAD EN LOS SISTEMAS DE INFORMACIÓN

1. ¿Qué es calidad?
2. Evolución de la calidad
3. Calidad de sistemas de información. 
4. Defectos y errores de calidad en los sistemas de información.
5. Mediciones de software
6. Estimación de Costos

Defectos y errores de calidad en los sistemas de información.

Los defectos en el software y los datos son una amenaza constante para los sistemas de información, y causan innumerables pérdidas en la productividad, son cuando los sistemas de fallan o no funcionan como es debido o cuando se almacenan grandes cantidades de datos, y estos pueden ser vulnerables a muchos tipos de amenazas como son errores y fallos.

FALLO 

Un fallo ocurre cuando algo deja de funcionar: 

• Cuando debería de hacerlo o  
• Como debería de hacerlo. Un infarto cardíaco es un FALLO 

Los fallos están referidos directamente al (in)cumplimiento de las especificaciones tanto explícitas como implícitas. (Definición de calidad). La OCURRENCIA de fallos señala la distancia del producto al objetivo de la calidad y en consecuencia del proceso que lo creó. 

DEFECTOS 

Un defecto es la causa de un fallo. 

Es algo en el producto que: 

o    Está, pero no debe. 

o    No está, pero debe. 

o    No está como debe estar. 

La acumulación de colesterol en el sistema circulatorio es un DEFECTO. 

Desde el punto de vista de la corporación, sus efectos se computan como “COSTE DE LA NO CALIDAD”, que se agravan cuanto más “tiempo” permanezca sin ser eliminado. 

La PRESENCIA de defectos apunta de forma directa a la validez de los procedimientos de inspección y prueba. 

BUGS (BICHOS) 

Un bug es el término común usado para describir un defecto, en un programa.  

La introducción del término "bug" a menudo se atribuye Grace Hopper, que en 1946 informó sobre la causa de una avería en uno de los primeros equipos electromecánicos de (MARK II).

Hooper junto con otros operadores encontraron una polilla muerta que bloqueaba un contacto. El informe incluía la polilla pegada con cinta adhesiva. Desde entonces se utiliza el término bug para nombrar a los defectos sw, debug(ear) para nombrar la operación de eliminarlos y debuggera las herramientas útiles a tal fin.  

ERRORES 

Un error es la acción que ha provocado la introducción de un defecto en el producto. 

No mantener una dieta sana y equilibrada es un ERROR 

La COMISIÓN de errores señala de forma directa a la calidad de los procesos de desarrollo. 

· Un fallo OCURRE durante el FUNCIONAMIENTO del equipo. 

· Un defecto se INTRODUCE en el PRODUCTO durante su desarrollo. 

· Un error lo COMETE una PERSONA durante el desarrollo.

 El costo de encontrar y corregir defectos 

El costo medio de encontrar y corregir un defecto crece unas 10 veces en cada paso del proceso de desarrollo. Aunque el tiempo de corregir los defectos varía enormemente, estos valores medios muestran, a pesar de todo, los tipos de defectos.  

El tiempo de encontrar los defectos en las pruebas de integración, de componentes o del sistema, también variará con el tamaño y la complejidad del sistema. Una vez que los productos son entregados a los clientes, el coste de encontrar y corregir los defectos puede ser mucho mayor, dependiendo de la clase de productos y de los tipos y número de clientes. Además del coste, una razón de igual importancia para encontrar los defectos al principio es que la compilación, depuración y las pruebas tienen una efectividad reducida. Así, si se requiere producir un producto de alta calidad, tendrás que producir un programa sin defectos al principio o esperar dedicarle mucho tiempo en las pruebas. 

CALIDAD DE SISTEMAS DE INFORMACIÓN

1. ¿Qué es calidad?
2. Evolución de la calidad
3. Calidad de sistemas de información. 
4. Defectos y errores de calidad en los sistemas de información.
5. Mediciones de software
6. Estimación de Costos

Calidad de sistemas de información.

La calidad de sistemas de información no es una cuestión de data quality únicamente, sino que también depende del entorno empresarial y la forma en que los procesos de negocio y los propios usuarios emplean los datos. Un dato de calidad es aquél que se ajusta al uso para el que se destina y cumple con los requisitos de exactitud, fiabilidad, completitud, actualización y consistencia. Pero, para salvaguardarlos, es necesario que la organización dicte las políticas necesarias al respecto.

Resulta conveniente el proponer un estándar de calidad del sistema de información en base a cinco dimensiones, desde el punto de vista del usuario:

A/ Disponibilidad: es el grado de comodidad para los usuarios a la hora de obtener datos e información relacionada. Para su evaluación, puede descomponerse en tres elementos: accesibilidad, autorización y puntualidad.

B/ Facilidad de uso: alude al grado de utilidad de los datos, en función de la idoneidad con que sean capaces de cumplir con las necesidades de los usuarios.

C/ Fiabilidad: se refiere al potencial del dato para resultar confiable, en base a su precisión, consistencia, integridad y suficiencia.

D/ Pertinencia: se utiliza para describir el grado de correlación entre el contenido de los datos y las expectativas o demandas de los usuarios. La adaptabilidad sería considerada como un valor.

E/ Calidad de la presentación: se refiere al modo en que se describen los datos y la manera en que el usuario los percibe. Debe tratarse de una presentación que permita a los usuarios comprenderlos y puede evaluarse en función de variables como la legibilidad y la estructura.

Un Sistema de Información de la Calidad (SIC), es un método organizado para recolectar, almacenar y reportar la información sobre la calidad para ayudar a los tomadores de decisiones en todos los niveles.

En el pasado, la información sobre la calidad se refería principalmente a los datos de inspección de planta. Sin embargo, los productos son ahora más complejos, los programas para la controlar la calidad cubren actualmente, el espectro de departamentos funcionales y la atención se centra en la adecuación para el uso de la conformancia con las especificaciones. Estas condiciones cambiantes, que van de la mano con el advenimiento de la computadora, han dado como resultado un punto de vista más amplio sobre la información de la calidad. Las industrias de servicio información cambios similares en el ambiente de la información.

Aplicadas las definiciones de calidad al ámbito de la información podría decirse que la calidad de la información de un sistema de información, vendrá determinada por su capacidad para satisfacer las necesidades de información de la persona o personas que lo utilicen. De allí la urgencia de contar con sistemas de información donde la información revista de la calidad exigida, a objeto de que aquellos logren los objetivos para los cuales fueron diseñados e implantados.  

Son muchos los autores que han expresado lo difícil de una definición de calidad; el Diccionario de la Lengua Española define el vocablo calidad en los siguientes términos: “Propiedad o conjunto de propiedades inherentes a una cosa, que permite apreciarla como igual, mejor o peor que las restantes de su especie”.  

Según lo que plantea la norma ISO 9000:2000, calidad: “Es el grado en el que un conjunto de características (rango diferenciador) inherentes cumple con los requisitos (necesidad o expectativa establecida, generalmente implícita u obligatoria)”.  

Según la norma ISO 8402 define calidad como: “La totalidad de las características de una entidad que le confieren la aptitud para satisfacer las necesidades establecidas e implícitas”.  

Por otro lado, no son numerosos los conceptos existentes en la bibliografía sobre la información de la calidad en los servicios. Es importante la definición de calidad de la información donde se dice que: “Comprende un conjunto de actividades dirigidas a la obtención en tiempo y forma de los datos acerca del comportamiento de los principales índices de calidad de los productos, así como de los indicadores que reflejan la calidad de los mismos”. [Gómez, 1985].  

Lucey [1987] define un Sistema de Información para la dirección como: “Un sistema para convertir datos procedentes del interior o exterior del mismo en información y para brindarle esta, en forma apropiada a los directivos de todos los niveles, para facilita la toma de decisiones”.  

Como sabemos, el concepto de calidad es relativo, está en los ojos del observador, por lo que podemos considerar la calidad como un concepto multidimensional, sujeta a restricciones y ligada a compromisos aceptables (Piattini et al., 1997). 

Así, por ejemplo, Redman (1996) señala quince características deseables en una vista de datos "ideal":  

1. La vista debería proporcionar los datos necesarios para la aplicación (relevancia)  

2. Los valores de los datos deberían ser fácilmente obtenibles (facilidad de obtención)  

3. Cada término en la definición de la vista debería estar claramente definido (claridad de definición). 

4. Todo elemento de datos necesario debería ser incluido (totalidad). 

5. No se debería incluir ningún elemento de datos innecesario (esencialidad)  

6. Los atributos deberían definirse al nivel adecuado de detalle para soportar aplicaciones  

7. Los dominios de los posibles valores deberían ser lo suficientemente grandes para soportar las aplicaciones (precisión de dominio)  

8. Todo elemento de la vista debería tener un homólogo en el mundo real (naturalidad)  

9. La vista debería facilitar la identificación de las entidades individuales (identificación de ocurrencias)  

10. Los tipos de entidad deberían definirse con el fin de minimizar la ocurrencia de atributos innecesarios (homogeneidad)  

11. La redundancia debería mantenerse al mínimo (redundancia mínima)  

12. La vista debería ser clara, no ambigua y consistente (consistencia semántica)  

13. Los tipos de entidad y atributos deberían tener la misma estructura básica cuando sea posible (consistencia estructural)  

14. La vista debería ser lo suficientemente amplia como para no requerir cambios cada vez que cambien las aplicaciones (robustez)  

15. Cuando sea necesario, la vista puede ser modificada fácilmente (flexibilidad)  

EVOLUCIÓN DE LA CALIDAD

1. ¿Qué es calidad?
2. Evolución de la calidad
3. Calidad de sistemas de información. 
4. Defectos y errores de calidad en los sistemas de información.
5. Mediciones de software
6. Estimación de Costos

EVOLUCIÓN DE LA CALIDAD

A lo largo de la historia de la humanidad la búsqueda y el afán de perfección por parte de la humanidad ha sido constante, de forma que el interés por el trabajo bien hecho y la necesidad de asumir responsabilidades sobre la labor efectuada derivó paulatinamente en el concepto de calidad.

La verificación de la calidad se remonta a épocas anteriores a nuestra era. En el año 2150 a.n.e., la calidad en la construcción de casas estaba regida por el Código de Hammurabi, cuya regla 229 establecía que "si un constructor construye una casa y no lo hace con buena resistencia y la casa se derrumba y mata a los ocupantes, el constructor debe ser ejecutado". Los fenicios también utilizaban un programa de acción correctiva para asegurar la calidad, con el objeto de eliminar la persistencia de errores. Los inspectores simplemente cortaban una mano a la persona responsable de la calidad insatisfactoria. Otro ejemplo temprano se encuentra entre los años 2000 y 3000 a.n.e., cuando los faraones egipcios mandaron construir las famosas pirámides. Muchas de ellas tienen parámetros que las acercan casi a la perfección en la construcción pues en la orientación de la base con respecto a la alineación N-S, E-W el error máximo llega a ser de seis minutos de arco, distando la base de algunas de ellas de ser un cuadrado perfecto menos de 17.78 cm.

En la edad media surgió en Europa el sistema de organización en gremios. Éstos imponían los precios y especificaciones de los distintos productos de los que proveían a la sociedad. Los productos de calidad daban prestigio al artesano, así como al gremio de la zona cuando todos sus artesanos seguían sus especificaciones. Este hecho constituye una de las primeras pruebas de un organismo que se encarga tanto de fijar unas normas básicas, como de controlar su cumplimiento.

Con la llegada de la revolución industrial se inició el fin del artesanado, se crearon grandes organizaciones y los antiguos artesanos se transformaron en los trabajadores de las empresas. En esta época Taylor elaboró su teoría acerca de la "gestión científica del trabajo", cuyo objeto fue la preparación de normas para que los trabajadores las cumpliesen. Comenzó con ello la instauración paulatina de la división del trabajo, lo que suponía que los operarios interviniesen solamente en algunas operaciones del proceso productivo. Este hecho provocó la necesidad de que surgiese la figura de los empleados dedicados a tareas de inspección, aunque se prestaba más atención a la forma de realizar el trabajo (los procesos) que a la calidad de los productos. Finalmente, el control de calidad moderno o control de calidad estadístico comenzó en los años 30 del siglo XX. Seguidamente se indican las fases históricas recientes.

Inspección/detección de errores: hasta los años 1940

• Inicialmente trabajo artesanal: control individual de cada tarea.
• 1918: Ford Motor Company. (Primera cadena de montaje).
• 1930: Laboratorios Bell (W. A. Shewhart).

Control (estadístico) de calidad: hasta los años 1980

• Mercado poco competitivo. Precio de venta fijado por el fabricante en función de los costes.
• Impedir que el producto defectuoso llegue al cliente.
• Conseguir uniformidad de servicio.
• Control de calidad = problema a resolver.
• Controlar la calidad del departamento de producción utilizando técnicas estadísticas.
• 1940-70: Japón y Calidad total. Deming, Ishikawa, Juran, Crosby,

Garantía de calidad: a partir de los 1980

• Mercado competitivo y de oferta
• Precio de venta fijado por el mercado
• Planificación y medida de la calidad. Modelos de calidad.
• Afecta a todos los departamentos.
• 1980. Interés por la calidad en los EE.UU. TQM
• 1987. Premio Malcom Baldrige Quality Award
• 1987. ISO 9000. A partir de las normas británicas
• 1992. Premio Europeo a la calidad de la EFQM (Fundación Europea para la Gestión de la Calidad).

Gestión de calidad actualmente

• Impacto estratégico. Oportunidad de ventaja competitiva.
• Planificación, fijación de objetivos, coordinación, formación, adaptación de toda la organización.
• Afecta a la sociedad en general: directivos, trabajadores, clientes.
• "Una filosofía, una cultura, una estrategia, un estilo de gerencia de la empresa".

ISO 9001:2000

ISO es la Organización internacional de Estandarización (International Organization of Standarization) con sede en Suiza http://www.iso.org/iso/home.html, desarrolla estándares de uso mundial que permiten a las empresas competir en el mercado internacional.

Terminología (ISO 8402)

• Calidad: "Conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explícitas o implícitas"

• Control de calidad: "Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio"

• Garantía de calidad: "Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfará los requerimientos dados sobre calidad"

• Gestión de la calidad: "Aspecto de la función de gestión que determina y aplica la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad".

La gestión de la calidad es responsabilidad de todos los niveles ejecutivos, pero debe estar guiada por la alta dirección. Su realización involucra a todos los miembros de la organización. En la gestión de la calidad, se tienen en cuenta también criterios de rentabilidad.

Sistema de gestión de la calidad (QS): "Conjunto de la estructura de la organización, de responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a término la gestión de calidad".

El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad.

El QS de una organización está fundamentalmente previsto para satisfacer las necesidades internas de la organización. Es más amplio que los requerimientos de un cliente concreto que únicamente valora el QS que le interesa (directamente).

Para finalidades contractuales o vinculantes en la valoración de la calidad, se puede exigir que se ponga de manifiesto la realización de ciertos elementos del QS.

Bibliográfia:

https://www.um.es/docencia/barzana/IAGP/IAGP2-Calidad-informatica.html