9._garantia_de_calidad_del_software.pdf

Ingeniera del SoftwareAntonio Navarro

1

9. Garanta de calidad del software


2

ndice

Introduccin Conceptos de calidad

Calidad. Control de calidad. Garanta de calidad. Coste de calidad

El equipo de garanta de calidad del software


3

ndice

Revisiones del software

Revisiones Tcnicas Formales Introduccin.

La reunin de revisin.

Registro e informe de revisin.

Directrices para la revisin.

El IEEE Std. 1028-1997.


4

ndice

Garanta de calidad estadstica Mejora estadstica.

ndice de errores.

Fiabilidad del software

Plan SQA. El IEEE Std. 730-2002


5

ndice

El enfoque de calidad ISO 9000 Introduccin. Principios de gestin de la calidad. La familia ISO 9000. Implementacin de ISO 9001:2000. Estructura de ISO 9001:2000. Relacin con otros estndares. AENOR.

ConclusionesIngeniera del SoftwareAntonio Navarro

6

Introduccin

Uno de los objetivos principales de la IS es construir software de calidad

Podemos definir calidad como una caracterstica o atributo de algo

Cmo medimos la calidad del software?

Con medidas indirectas


7

Introduccin

Hay dos tipos de calidad:- Calidad de diseo. Caractersticas especificadas para un elemento (software: SRS y Diseo).- Calidad de concordancia. Grado de cumplimento de las especificaciones de diseo durante su realizacin (software: implementacin).

En ingeniera, la SQA se centra en el control de variacin entre muestras

En IS, la variacin entre muestras no tiene sentido


8

Introduccin

En IS hay dos formas de conseguir calidad:- Haciendo SRS, diseos e implementaciones correctos desde un punto de vista tcnico.- Introduciendo en el modelo de proceso una serie de actividades que garanticen que todas las entregas resultantes de una actividad de trabajo sean correctas.

Las tcnicas de IS para conseguir calidad en el software se denominan Garanta de Calidad del Software (SQA: Software QualityAssurance)


9

Introduccin

La SQA engloba:- Enfoque de gestin de calidad.- Tecnologas de IS (mtodos y herramientas).- Revisiones Tcnicas Formales.- Estrategia de pruebas.- Control de la documentacin y de cambios.- Procedimientos que aseguren ajustes a los estndares de IS-Mecanismos de medicin y generacin de informes


10

Conceptos sobre calidadCalidad

Definimos calidad como concordancia con:- Los requisitos funcionales y de rendimiento explcitamente establecidos.

- Los estndares de desarrollo explcitamente documentados.

- Las caractersticas implcitas de todo software desarrollado profesionalmente.


11

Conceptos sobre calidadCalidad

El IEEE Std. 610.12 define calidadcomo:- Grado en que un sistema, componente o proceso cumple las especificaciones.- Grado en que un sistema, componente o proceso cumple las necesidades o deseos de clientes y usuarios.

Discusin difieren ambas definiciones?


12

Conceptos sobre calidadControl de calidad

El control de calidad es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados

Incluye un bucle de realimentacin


13

Conceptos sobre calidadGaranta de calidad

La garanta de calidad es el establecimiento de un marco de procedimientos organizativos que llevan a conseguir una alta calidad del software

e.g.:- El control de calidad nos lleva a hacer una RTF del diseo de una parte del sistema.- Hacemos RTFs porque forman parte de la garanta de calidad de nuestra organizacin.


14

Conceptos sobre calidadCoste de calidad

El coste de calidad incluye todos los costes que se derivan de la bsqueda de la calidad o en las actividades relacionadas en la obtencin de la calidad

Hay tres tipos de costes de calidad:- De prevencin.- De evaluacin.- De fallos.


15


Los costes de prevencin incluyen:- Planificacin de calidad.

- Revisiones tcnicas formales.

- Equipo de pruebas.

- Formacin.


16


Los costes de evaluacin incluyen:- Inspeccin en el proceso y entre procesos.

- Calibrado y mantenimiento del equipo.

- Pruebas.

Los costes de fallos se dividen en:- Internos.

- Externos.


17


Los fallos internos se producen cuando se detecta un error antes de la entrega al cliente.- Los costes asociados incluyen:

- Revisin.

- Reparacin.

- Anlisis de fallos.


18


Los fallos externos se producen cuando se detecta un error despus de la entrega al cliente- Los costes asociados a fallos externos incluyen:

- Costes de los internos.- Resolucin de quejas.- Devolucin y sustitucin de productos.- Soporte de lnea de ayuda.- Trabajo de garanta.


19


Evidentemente, cuanto ms tardemos en resolver un fallo, ms costosa ser su resolucin

Coste de resolucin de fallosIngeniera del SoftwareAntonio Navarro

20


Por ejemplo un anlisis del trabajo de IBM en Rochester indica:- 7053 horas de RTFs de 200000LDC

- 3112 errores descubiertos

- Coste programador 40$/h

- Coste eliminacin defectos: 282120$ (91$/defecto)


21


- Supongamos que en vez de RTFs somos muy cuidadosos

- Supongamos que hay 1 fallo por 1000LDC

- Tenemos unos 200 defectos

- Con un coste de 25000$ por reparacin

- Coste reparacin de 5 millones de dlares

- Es decir, 18 veces ms caro que el coste de prevencin


22

Conceptos sobre calidadEl equipo SQA

La SQA comprende tareas llevadas a cabo por dos tipos de personal:- Desarrolladores. Llevan a cabo el trabajo tcnico.

- Grupo SQA. Ayudan al equipo de desarrolladores para que el software alcance una alta calidad.


23


Actividades del grupo SQA:- Establecimiento del plan SQA para el proyecto.- Participar en el desarrollo de la descripcin del proceso de software.- Revisin de las actividades de ingeniera del software para verificar su ajuste al proceso del software.- Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso de software.


24


- Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido.

- Registrar lo que no se ajuste a los requisitos e informar a sus superiores.

- Coordinar el control y la gestin de cambios.

- Analizar las mtricas del software.


25


Las revisiones del software son un filtropara el proceso de IS

Se aplican en varias etapas del desarrollo del software

Purifican las actividades estructurales

Hay diversos tipos de revisiones de mayor o menor formalidad y/o vala


26


Nosotros nos centraremos en las RevisionesTcnicas Formales RTFs o InspeccionesFormales

Antes de ver las RTFs, nos centraremos en su necesidad

El objetivo bsico de las RTFs es detectar errores antes de que se conviertan en defectos


27


Veremos la efectividad de las RTFs a travs del modelo de amplificacin de defectos

Modelo de amplificacin de defectosIngeniera del SoftwareAntonio Navarro

28


Amplificacin de defectos sin revisiones


29


Amplificacin de defectos, con revisiones


30

Revisiones Tcnicas FormalesIntroduccin

Una RTF es una actividad de garanta de calidad del software llevada a cabo por los ingenieros del software (y otros)

Los objetivos de la RTF son:- Descubrir errores.

- Verificar que el software alcanza sus requisitos.

- Garantizar que el software se desarrolla de acuerdo a ciertos estndares predefinidos.


31

Revisiones Tcnicas FormalesIntroduccin

- Conseguir un software desarrollado de manera uniforme.

- Hacer que los proyectos sean ms manejables.

La RTF se instrumenta mediante una reunin, que debe ser convenientemente planificada


32

Revisiones Tcnicas FormalesLa reunin de revisin

Normas de la reunin:- Deben convocarse para la reunin entre tres y cinco personas.

- Se debe preparar por adelantado, pero sin que requiera ms de dos horas de trabajo por persona.

- La duracin debe ser menor de dos horas.

Evidentemente, la RTF se centran en partes especficas del software


33


Se deben revisar los productos resultantes de las tareas de trabajo

El procedimiento es:- El responsable del producto (productor) informa al jefe del proyecto del fin de un trabajo.

- El jefe del proyecto contacta con el jefe de revisin que distribuye el producto a dos o tres revisores.


34


- Cada revisor, incluido el jefe de revisin, revisa el producto durante una o dos horas.- El jefe de revisor establece una agenda y planifica una reunin (normalmente para el da siguiente).- A la reunin asisten el productor, los revisores y el jefe de revisin.- Uno de los revisores juega el papel de registrador.


35


- El productor expone su producto.- Los revisores exponen sus pegas.- Cuando se descubre un problema u error real, el registrador toma nota.

Al final de la reunin se puede decidir:- Aceptar el producto sin modificaciones.- Rechazar el producto debido a los errores encontrados.- Aceptar el producto supuesto que se llevan a cabo algunas modificaciones (sin nueva RTF)


36


Una vez llevada a cabo la reunin, los participantes firman el registros de revisin

As se indica:- Asistentes.

- Conformidad.


37

Revisiones Tcnicas FormalesRegistro e informe de revisin

El registrador toma nota de todos los problemas identificados en la RTF

Al final de la reunin se genera una lista de sucesos de revisin que resume todas las pegas

Adems genera un informe sumario de revisin


38


El informe sumario de revisin contiene:- Qu se revis.

- Quin lo revis.

- Qu se descubri, y cules son las conclusiones.

Dicho informe es una pgina simple (con posibles suplementos) que se adjunta al registro histrico del proyecto


39


La lista de sucesos de revisin sirve para:- Identificar las reas problemticas dentro de un producto.

- Servir como lista de comprobacin de puntos de accin que gue al productor para hacer las correcciones.

La lista de sucesos puede adjuntarse al informe sumario


40


Cuando el producto es aceptado con cambios, alguien debe encargarse del seguimiento de los cambios identificados en la lista de sucesos de revisin

El revisor jefe o el equipo SQA pueden ser los encargados de dicho seguimiento


41

Revisiones Tcnicas FormalesDirectrices para la revisin

Las directrices de revisin deben establecerse de antemano para evitar problemas

Directrices:- Revisar el producto, no al productor.- Fijar una agenda y mantenerla.- Limitar el debate y las impugnaciones.- Enunciar reas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto.


42

Revisiones Tcnicas FormalesDirectrices para la revisin

- Tomar notas escritas.- Limitar el nmero de participantes e insistir en la preparacin anticipada.- Desarrollar una lista de comprobacin para cada producto que vaya a ser revisado.- Disponer de recursos y una agenda para la RTF.- Llevar a cabo un buen entrenamiento de todos los revisores.- Repasar las reuniones anteriores.


43

Revisiones Tcnicas FormalesEl IEEE Std. 1028-1997

Las nociones sobre RTFs presentadas estn inspiradas en el Software Formal Inspections Guidebook NASA-GB-A302del Software Assurance TechnologyCenter* de la NASA

Este manual data de 1993 e incluye listas de comprobacin

*http://satc.gsfc.nasa.gov/


44


El IEEE Std. 1028-1997 es otro manual para realizar revisiones en el software

Identifica 37 productos a revisar Distingue entre cinco tipos de revisiones en

funcin del producto a revisar: Revisiones de gestin. Revisiones tcnicas. Inspecciones. Andar por. Auditorias.


45


Revisiones de gestin- Su propsito es:

- Monitorizar el progreso.

- Determinar el estado del plan y las planificaciones.

- Confirmar los requisitos y su localizacin en el sistema.

- Evaluar la efectividad de las actividades de gestin para conseguir sus objetivos.


46


- Entre otros revisan:- Plan del proyecto.- Planes de gestin del riesgo.- Planes SQA.

Revisiones tcnicas- Evalan un producto software para determinar si:

- El producto software se ajusta a sus especificaciones.- El producto software respeta los criterios o estndares aplicados en el proyecto.


47

Revisiones Tcnicas FormalesEl IEEE Std. 1028-1997- Los cambios en el producto software se implementan adecuadamente.

- Entre otros revisan:- SRS.

- Diseo.

- Documentacin de prueba.

- Manual de mantenimiento.


48


Inspecciones- Buscan anomalas mediante un examen que:

- Verifica que el producto software cumple sus especificaciones.- Verifica que el producto software cumple con sus atributos de calidad especficos.- Verifica que el producto software se ajusta a los criterios y estndares del proyecto.- Identifica desviaciones de estndares y especificaciones.- Opcionalmente recoge datos de IS.


49


- Similares a las revisiones tcnicas, pero llevadas a cabo por revisores imparciales.


- Diseo.

- Cdigo.

- Casos de prueba.


50


Andar por- Sirve para evaluar un producto software:

- Buscando anomalas.- Mejorando el producto.- Considerando implementaciones alternativas.- Evaluando la conformidad con estndares y especificaciones.

- Es lo que (en la forma) ms se ajusta con una RTF.- De ah el nombre.


51



- Diseo.

- Cdigo fuente.

- Casos de prueba.


52


Auditorias- Proporcionan una evaluacin independiente de conformidad del producto software y los procesos de gestin con regulaciones y estndares.- Entre otros revisan:

- Informes y datos.- Plan del proyecto.- Planes de gestin del riesgo.- Planes de garanta de calidad.


53

Garanta de calidad estadsticaMejora estadstica

La garanta de calidad estadstica de IS, no tiene nada que ver con la aplicacin de tcnicas estadsticas en el control de muestras

Como ya hemos comentado en el apartado de mtricas:- Se agrupa y clasifica la informacin sobre los fallos del software.- Se intenta encontrar la causa subyacente a cada fallo.- Se aplica el principio de Pareto.- Se acta para corregir los fallos vitales.


54

Garanta de calidad estadsticaMejora estadstica

#total: IEE, MCC y ERD#graves: IEE, ERD, TLP y ELD

Recoleccin de datos para SQA estadstica


55

Garanta de calidad estadsticandice de errores

El ndice de errores permite cuantificar la magnitud de los fallos durante el proceso de desarrollo


56


IE = (6ifasesiIFi)/Tdonde

T: tamao del software (LDC, documentacin, diseo)

IFi = pggi/ei + pmmi/ei + plli/eidonde

gi, mi, li: # errores graves, moderados y leves en la etapa i-sima

ei: # errores en la etapa i-sima

pg, pm, pl: pesos grave (10), moderado (3) y leve (1)


57


Tal y como dice Pressman la SQA estadstica se puede resumir en: Utilizar el tiempo para centrarse en cosas que realmente interesan, pero primero asegurarse que se entiende qu es lo que realmente interesa!


58

Fiabilidad del software

Ya comentado en el Captulo 4 (t84-t87): PFBD. FDF. TMF. Disponibilidad.

Ya comentado en el Captulo 6 (t97): Si de la construccin u operacin del sistema se

derivan riesgos para la salud, la SQA es primordial.


59

Plan SQAEl IEEE Std. 730-2002

El IEEE Std. 730-2002 describe la preparacin y contenidos de los planes SQA

Un plan SQA sirve como gua de las actividades de SQA en el proyecto

Lo desarrolla el equipo SQA


60


El ndice del plan SQA es:1. Propsito2. Documentos de referencia3. Gestin4. Documentacin

4.1 Propsito4.2 Requisitos mnimos de documentacin4.3 Otra documentacin

5. Estndares, prcticas, convenciones y mtricas5.1 Propsito5.2 Contenido


61


6. Revisiones del software

6.1 Propsito

6.2 Requisitos mnimos

6.3 Otras revisiones y auditorias

7. Pruebas

8. Informe de errores y acciones correctoras

9. Herramientas, tcnicas y metodologas

10. Control de medios

11. Control de proveedor

12. Coleccin de registros, mantenimiento y conservacin


62


13. Formacin

14. Gestin del riesgo

15. Glosario

16. Procedimiento de cambio e historial del plan de SQA

No toda la informacin listada tiene porque encontrarse en el documento


63


Propsito (1)- Delinea el propsito especfico y el alcance del plan SQA.

- Lista los nombres de los elementos software cubiertos por el plan SQA y el uso de dichos elementos.

- Determina la porcin del ciclo de vida cubierta por el plan para cada elemento software.


64


Documentos de referencia (2)- Proporciona una lista completa de cualquier documento referenciado en el plan o utilizado en su elaboracin.

Gestin (3)- Est muy ligado al plan del proyecto del software.

- Idealmente redactado en formato IEEE Std. 1058-1998.


65


Organizacin (3.1)- Describe la estructura organizativa que influye y controla la calidad del software.

- Identifica roles y responsabilidades dentro del plan SQA.

- Identifica a los responsables de preparar y mantener el plan SQA.


66


Tareas (3.2)- Describe

- Las porcin del ciclo de vida cubierta por el plan SQA.

- Las tareas a desarrollar.

- Los criterios de entrada y salida para cada tarea.

- Las relaciones entre estas tareas y los principales puntos de control planeados.


67


Roles y responsabilidades (3.3)- Identifica los elementos organizativos especficos responsables de llevar a cabo cada tarea.

Recursos estimados de garanta de calidad (3.4)- Proporciona la estimacin de recursos y costes gastados en garanta de calidad y en las tareas de control de calidad


68


Documentacin (4)- Describe toda la documentacin que se va a generar durante el proceso de desarrollo.

Propsito (4.1)- Identifica la documentacin que dirige el desarrollo, verificacin y validacin, uso y mantenimiento del software.- Lista los documentos que sern revisados o auditados, as como los criterios de revisin.


69


Requisitos mnimos de documentacin (4.2)- Para asegurar que la implementacin del software satisface los requisitos tcnicos, se requiere como mnimo la siguiente documentacin:

- Descripcin de requisitos software.- Descripcin del diseo del software.- Planes de verificacin y validacin.- Informe de resultados de verificacin e informe de resultados de validacin


70


- Documentacin de usuario.

- Plan de gestin de la configuracin software.

Descripcin de requisitos software (4.2.1)- Es la SRS.

- Idealmente redactada segn IEEE. Std 830-1998.

Descripcin de diseo software (4.2.2)- Describe la estructuracin del software para cumplir con los requisitos de la SRS.


71


- Debe describir los componentes y subcomponentes del diseo del software.- Idealmente redactado segn IEEE Std. 1016-1998, IEEE Recommended Practice for SoftwareDesign Descriptions.

Planes de validacin y verificacin (4.2.3)- Estos planes se utilizan para determinar si el producto software desarrollado se ajusta a sus requisitos, y si cumple con las expectativas del usuario.


72


- Idealmente redactado segn los estndares:

- IEEE Std. 829-1998 for Software TestDocumentation.

- IEEE Std. 1008-1997 IEEE for Software UnitTesting.

- IEEE Std. 1012-1998 for Software Validation andVerification.


73


Informe de resultados de verificacin e informe de resultados de validacin (4.2.4)- Describen los resultados de las actividades de verificacin y planificacin del software llevadas a cabo segn los planes descritos en el punto anterior.


74


Documentacin de usuario (4.2.5)- La documentacin de usuario gua al usuario en la instalacin, operacin, gestin y mantenimiento de los productos software.

- Debera describir las entradas y salidas, as comolos mensajes de error.

- Idealmente redactado segn IEEE Std. 1063-1987 for Software User Documentation.


75


Plan de gestin de la configuracin software (4.2.6)- Describe el proceso de gestin de configuracin software.

- Idealmente redactado segn IEEE Std. 828-1998 for Software Configuration Management Plans.


76


Otra documentacin (4.3)- Identifica otros documentos necesarios durante el proceso de desarrollo, como:

- Plan de proceso de desarrollo.

- Descripcin de estndares de desarrollo de software.

- Descripcin de mtodos/procedimientos/herramientas de IS.

- Plan de gestin del proyecto de software (idealmente segn IEEE Std. 1058).


77


- Plan de Mantenimiento (idealmente segn IEEE Std. 1219-1998).

- Planes de seguridad del software (idealmente segn IEEE Std. 1228-1994).

- Plan de integracin del software.

Estndares, prcticas convenciones y mtricas (5)- Esta seccin es un poco miscelnea en SQA.


78


Propsito (4.5.1)- Identifica:

- Estndares.

- Prcticas.

- Convenciones.

- Tcnicas estadsticas.

- Mtricas aplicables al proyecto.


79


- Las medidas se incluirn en las mtricas utilizadas y podran identificarse en un plan de medicin independiente (idealmente redactados segn IEEE Std. 1219-1998 for SoftwareMaintenance e IEEE Std. 1228-1994 for Software

Safety Plans).

- Tambin determina como se monitoriza y garantiza la conformidad con el plan.


80


Contenido (4.5.2)- Como mnimo debe incluir:

- Estndares de documentacin.

- Estndares de diseo.

- Estndares de codificacin.

- Estndares de comentarios.

- Prcticas y estndares de prueba.

- Mtricas del producto y proceso de garanta de calidad seleccionada.


81


Revisiones del software (6)- Determina las revisiones del software.

Propsito (6.1)- Fija las revisiones del software.

- Idealmente redactado segn IEEE Std. 1028-1997.


82


Requisitos mnimos (6.2)- Como mnimo deberan producirse las siguientes revisiones:

- Revisin de las especificaciones software.- Revisin del diseo arquitectnico.- Revisin del diseo detallado.- Revisin del plan de verificacin y validacin.- Auditoria de la funcionalidad (cumplir SRS).- Auditoria fsica (consistencia y fecha entrega).


83


- Auditoria durante el proceso (consistencia del diseo).

- Revisiones de gestin (garantizar cumplimiento plan SQA).

- Revisin del plan de gestin de la configuracin software.

- Revisin post-implementacin.

Otras revisiones y auditorias (4.6.3)- e.g. revisin de la documentacin de usuario.


84


Prueba (7)- Identifica todas las pruebas no incluidas en el plan de verificacin y validacin.

Informe de problemas y accin correctiva (8)- Describe las prcticas y procedimientos de informe, seguimiento y resolucin de problemas, tanto a nivel producto como proceso.


85


- Determina las responsabilidades organizativas relativas a su implementacin.

Herramientas, tcnicas y metodologas (9)- Herramientas, tcnicas y metodologas utilizadas para soportar el proceso de SQA.

Control de medios (10)- Determina los mtodos para:

- Identificar el medio fsico de cada producto software.- Protegerlo de daos durante el proceso.


86


Control de proveedor (11)- Determina las tcnicas para garantizar que el software proporcionado por proveedores externos cumple sus requisitos.

- Tambin es aplicable a cdigo heredado.


87


Coleccin de registros, mantenimiento y conservacin (12)- Identifica la documentacin SQA que no se debe tirar tras acabar el proceso.- Determina los mtodos y medios para ensamblar, archivar, salvaguardar y mantener la documentacin.- Fija el periodo de conservacin de la informacin.


88


Formacin (13)- Identifica las actividades de formacin necesarias para satisfacer las necesidades del plan SQA.

Gestin del riesgo (14)

- Especifica el plan de gestin del riesgo.

- Idealmente redactado segn IEEE Std. 1540-2001 for Software Life Cycle Processes RiskManagement


89


Glosario (15)- Trminos especficos del plan SQA.

Procedimiento de cambio e historia del plan SQA (16)- Procedimientos de modificacin del plan SQA.- Procedimientos de mantenimiento del historial de cambios.- Historial de cambios.


90

El enfoque de calidad ISO 9000Introduccin

La International Organization forStandarization ISO* tiene el enfoque ISO 9000 para la gestin de la calidad

El enfoque ISO 9000 busca la gestin a travs de la implantacin de un sistema de gestin de la calidad QMS (QualityManagement Systems)*http://www.iso.org


91


Calidad: grado en el que un conjunto de caractersticas cumplen sus requisitos

Gestin de la calidad: actividades coordinadas para dirigir y controlar una organizacin en lo concerniente a la calidad

Sistema de gestin de calidad: conjunto de directrices e instrucciones cuyo objetivo es alcanzar unos niveles satisfactorios y constantes de calidad en productos y/o servicios


92


ISO 9000 es una familia de estndares genricos

De esta forma pueden aplicarse a distintos sectores productivos (software, hardware, automocin, textil, etc.)


93


ISO 9000 es:- Una herramienta para clientes que compran, ms que para fabricantes que construyen.

- Se centra en qu, no en cmo. El estndar define un conjunto de objetivos a cumplir, pero no dice como conseguirlo.

- Define elementos necesarios, pero no suficientes.


94

El enfoque de calidad ISO 9000Principios de gestin de calidad ISO 9000 se basa en ocho principios de

gestin de calidad:

- Centrado en el cliente.

- Liderazgo.

- Participacin de la gente.

- Aproximacin basada en el proceso.

- Aproximacin basada en el sistema de gestin.


95

El enfoque de calidad ISO 9000Principios de gestin de calidad

- Mejora continua.

- Acercamiento verdadero a la toma de decisiones.

- Relaciones de proveedor mutuamente beneficiosas.


96

El enfoque de calidad ISO 9000La familia ISO 9000

ISO 9000:2000 Quality managementsystems - Fundamentals and vocabulary

- Determina un punto de partida para comprender la familia de estndares y define los trminos y definiciones fundamentales utilizadas en la familia ISO 9000


97

El enfoque de calidad ISO 9000La familia ISO 9000

ISO 9001:2000 Quality managementsystems - Requirements.- Identifica los requisitos que una organizacin debe satisfacer para tener implementado un sistema de gestin de calidad ISO 9000.

ISO 9004:2000 Quality managementsystems Guidelines for performance improvement

- Gua para una continua mejora del proceso.


98

El enfoque de calidad ISO 9000Implementacin ISO 9001:2000 Una entidad (en particular de desarrollo de

software) que desee implementar ISO 9001:2000 debe seguir una serie de pasos

1. Identificar los objetivos a alcanzar.2. Identificar que se espera por parte de los dems.3. Obtener informacin acerca de la familia ISO

9000.4. Aplicar la familia ISO 9000 de estndares al

sistema de gestin.


99

El enfoque de calidad ISO 9000Implementacin ISO 9001:20005. Obtener una gua sobre los aspectos especficos

dentro del sistema de gestin de calidad. ISO 10006 para gestin del proyecto. ISO 10007 para gestin de la configuracin. ISO 10012 para sistemas de medidas. ISO 10013 para documentacin de calidad. ISO/TR 10014 para gestionar la economa de la calidad. ISO 10015 para formacin. ISO/TS 16949 para suministradores de automocin. ISO 19011 para auditoria.


100

El enfoque de calidad ISO 9000Implementacin ISO 9001:20006. Establecer el estado actual, y determinar las

discrepancias entre el sistema de gestin de la calidad actual y las exigencias de ISO 9001:2000.

7. Determinar los procesos necesarios para suministrar productos a los clientes.

8. Desarrollar un plan para eliminar las discrepancias del paso 6 desarrollar los procesos del paso 7.


101

El enfoque de calidad ISO 9000Implementacin ISO 9001:20009. Ejecutar el plan.

10. Sufrir la evaluacin peridica interna

11. Si es necesario demostrar conformidad pasar a 12, si no pasar a 13.

12. Sufrir auditorias externas.

13. Continuar con la mejora del negocio.


102

El enfoque de calidad ISO 9000Estructura de ISO 9001:2000

El ncleo de ISO 9001:2000 est dividido en cinco apartados:- Sistema de gestin de calidad.

- Responsabilidades de gestin.

- Gestin de recursos.

- Realizacin del producto.

- Medida, anlisis y mejora.


103

El enfoque de calidad ISO 9000Relacin con otros estndares

El modelo de capacidad de madurez SEI- ISO 9001 es genrico, y CMM especfico para la industria del software.- CMM es ms detallado y especfico.- ISO 9001 es binario, mientras que CMM permite cinco niveles.- ISO 9001 se centra en la relacin cliente-proveedor, mientras que CMM se centra en el desarrollo de software.


104

El enfoque de calidad ISO 9000Relacin con otros estndares

IEEE Std. 730- IEEE Std. 730 se centra en el plan de garanta de calidad, y en como implementarlo, mientras que ISO 9001 busca una gestin global de la calidad centrada en auditorias externas.

AQAP-110 y AQAP-150- AQAP-110* Edition 2 - February 1995:NATO Quality Assurance Requirements for Design, Development and Production.

*http://www.mi.government.bg/integration/euroatl/NATO-AQAPs.doc


105

El enfoque de calidad ISO 9000Relacin con otros estndares- AQAP-150* Edition 2 - September 1997:NATO Quality Assurance Requirements for Software Development

- AQAP-110, ISO 9001:1994 con algunas ampliaciones.

- AQAP-150, especfico para el software mientras ISO 9001 genrico.


106

El enfoque de calidad ISO 9000AENOR

AENOR*- Entidad privada, espaola, independiente y sin nimo de lucro.- Dedicada a:

- Elaborar normas tcnicas espaolas.- Certificar productos, servicios y empresas.

- En particular proporciona certificaciones ISO 9000.

*http://www.aenor.es


107

El enfoque...AENOR

Proceso de certificacin ISO 9000 de AENOR


108

Conclusiones

Calidad: base de IS

Calidad de diseo vs. calidad concordancia

Variacin entre muestras

SQA

Calidad: concordancia

Control de calidad y garanta de calidad

Coste de calidad: asumible


109

Conclusiones

Equipo SQA

RTFs

IEEE Std. 1028-1997

MEPS

Plan SQA IEEE Std. 730-2002

ISO 9000

Sentido comn

9._garantia_de_calidad_del_software.pdf

Documents