Tema 4 Calidad

INGENIERA DEL SOFTWARE III
TEMA 4
CONTROL Y GESTIN DEL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
CONTROL Y GESTIN DEL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
Introduccin al Aseguramiento de la Calidad del Software.
Marco normativo relacionado con la calidad. Factores y modelos de calidad. Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad.
Plan General de Calidad.
Introduccin al aseguramiento de la calidad del Software
Se conoce como SQA (Software Quality Assurance) o GCS (Gestin de la Calidad del Software). Es una actividad de proteccin que se aplica a lo largo de todo el ciclo de vida. Varias definiciones: Conjunto de propiedades inherentes a una cosa, que permiten apreciarla como igual, mejor o peor que las restantes de su especie (Diccionario de la Real Academia Espaola) Conjunto de Caractersticas de un producto o servicio relativas a su capacidad para satisfacer unas necesidades dadas. (Norma UNE 66-001-92 traduccin de ISO 8402) [AENOR, 1992] Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente. (Pressman) Grado con el que un sistema, componente o proceso cumple: Los requisitos especificados Las necesidades o expectativas del cliente o usuario. (IEEE Std. 610-1990) [IEEE, 1993].
3

Algunos conceptos
Gestin de la calidad del software: Aspecto de la funcin general de la gestin que determina y aplica la poltica de calidad [AENOR]. Aseguramiento de la calidad del software: Conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto satisfar los requisitos dados de calidad [AENOR, 1992]. Conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el producto. [IEEE]. Control de calidad del software: Tcnicas y actividades de carcter operativo utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales: mantener bajo control un proceso y eliminar las causas de defectos en las diferentes fases del ciclo de vida [AENOR]. Proceso de verificar el propio trabajo o el de un compaero. [IEEE]. Verificacin y validacin: Verificacin. Comprobar si los productos construidos en una fase del ciclo de vida satisfacen los requisitos establecidos en la fase anterior. Validacin: Comprobar si el software construido satisface los requisitos de usuario.

El coste de calidad
Coste de prevencin:

Planificacin de la calidad. Revisiones tcnicas formales. Equipo de pruebas. Formacin. Inspeccin en el proceso y entre procesos. Calibrado y mantenimiento del equipo. Pruebas. Internos: revisin y reparacin, ... Externos: resolucin de quejas. devolucin y sustitucin del producto, ...
Costes de evaluacin:

Costes de fallos:

1000
Coste relativo
Evolucin relativa del coste de correccin de un defecto. 30 a 70 15 a 40
40 a 1000
100 10 3a6 1
Pruebas de unidad
10 1
Requisitos
Diseo
Cdigo
Pruebas Explotacin de sistema
Principios bsicos de la calidad del software

Debe construirse durante todo el ciclo de vida del proyecto. Slo se alcanza con la contribucin de todas las personas involucradas. Se debe planificar y gestionar con eficacia. Se debe invertir recursos en la prevencin de defectos. Se deben reforzar los sistemas de deteccin y eliminacin de defectos durante las primeras fases del proyecto. Es un parmetro importante del proyecto al igual que los plazos de entrega, coste y productividad. Es esencial que se involucre la direccin.

Actividades bsicas que garantizan la calidad del software.
Establecimiento de un plan para el aseguramiento de la calidad del proyecto:

Se desarrolla durante la planificacin del proyecto Se revisa por todas las partes involucradas
Aplicacin de metodologas y herramientas en el desarrollo. Ajuste a los estndares y normas establecidos, ajustndose en todo momento a la poltica de empresa. Realizacin de revisiones tcnicas formales. Controlar los cambios. Recopilacin y anlisis de mtricas para evaluar tanto la calidad del producto como la calidad del proceso. Verificacin y validacin del software. Realizacin de pruebas Revisin de las actividades de IS:

Seguimiento de las desviaciones Verificacin de la realizacin de las correcciones
Asegurar la documentacin de las desviaciones Registrar lo que no se ajuste a los requisitos Elaboracin de bases histricas e informes.
7

Equipo de aseguramiento de la calidad
Es el encargado de realizar el aseguramiento de la calidad del software. Sus miembros deben tener como caractersticas:

Titulacin informtica y experiencia en desarrollo de software. Conocimiento de la organizacin. Conocimiento de las metodologas de desarrollo y de los mtodos y tcnicas de control de calidad. Capacidad de comunicacin oral y escrita. Capacidad de interrelacin personal. Capacidad de hacer frente a problemas. Capacidad de dilogo. Establecer el plan SQA del proyecto. Participar en la definicin del proceso de software del proyecto. Revisar las actividades de ingeniera de software aplicadas en el proyecto. Auditar los productos software obtenidos. Garantizar la documentacin de las desviaciones detectadas. Registrar las diferencias respecto a los requisitos. Decidir las acciones correctoras necesarias. Desarrollar herramientas de prueba. Coordinar el control y la gestin de cambios. Recopilar y analizar las mtricas del software. 8
Sus funciones son:


mbitos del aseguramiento de la calidad
El aseguramiento de la calidad a nivel de empresa u organizacin consiste en la creacin de una estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las personas y departamentos de la empresa. En cada proyecto de desarrollo se deben aplicar las directrices de calidad fijadas a nivel de la organizacin. Para ello es imprescindible la adaptacin de las mismas a las condiciones de cada proyecto.
Marco normativo relacionado con la calidad

Principales organismos de normalizacin
IEEE
ANSI
(USA)
ISO
(Inter.)
CEN
(Europa)
AENOR
(Espaa)
Los estndares ANSI/IEEE estn orientados al aseguramiento de la calidad a nivel del proyecto: Std. 730: proporciona la estructura de la documentacin del plan de aseguramiento de la calidad. Std.1061: definicin de mtricas para productos y para procesos, as como procedimientos para la recogida de valores de mtricas. Existen tambin estndares para otras actividades relacionadas con la calidad como pruebas, verificacin y validacin, revisiones, etc. Los principales se recogen en la siguiente tabla.
I E E E 7 3 0 -1 9 9 8 I E E E 8 2 9 -1 9 9 8 I E E E 9 8 2 .1 , 9 8 2 .2 IE E E 1 0 0 8 -1 9 8 7 IE E E 1 0 1 2 -1 9 9 8 IE E E 1 0 2 8 -1 9 9 7 IE E E 1 0 4 4 -1 9 9 3 IE E E 1 0 6 1 -1 9 9 2 IE E E 1 2 2 8 -1 9 9 4 P l a n e s d e a s e g u r a m i e n to d e l a c a l i d a d d e l s o f t w a r e D o c u m e n t a c i n d e p r u e b a s d e l s o f t w a r e D i c c io n a r i o e s t n d a r d e m e d i d a s p a r a p r o d u c i r s o ftw a re fia b le P ru e b a s d e u n id a d d e l s o ftw a re V e r i f ic a c i n y v a l i d a c i n d e l s o f t w a r e R e v isio n e s d e l s o ftw a re C l a s i f i c a c i n e s t n d a r p a r a a n o m a l a s d e l s o f t w a r e E s t n d a r p a ra u n a m e to d o lo g a d e m tric a s d e c a li d a d d e l s o f t w a r e P la n e s d e s e g u rid a d d e l so ftw a re
10

Estndares ISO 9000
La Organizacin Internacional de Estndares, ISO, ha producido una serie de estndares para la gestin y aseguramiento de la calidad conocidos colectivamente como ISO 9000. Se pueden dividir en dos grupos:
Normas para el aseguramiento externo de la calidad. ISO 9001: Aseguramiento de la calidad en organizaciones cuyo proceso abarca desde el diseo hasta el servicio posventa. ISO 9002: Aseguramiento de la calidad en organizaciones cuya actividad se basa en las fases de produccin y de instalacin. ISO 9003: Aseguramiento de la calidad en organizaciones cuya actividad requiere inspecciones y ensayos finales. Normas para la gestin interna de la calidad. ISO 9004: define los elementos de un sistema de calidad
Gua ISO 9000-3: gua para aplicar ISO 9001 al desarrollo, suministro y mantenimiento de software.
11
Gua ISO 9000-3 contempla: Marco de trabajo de la empresa Responsabilidades de gestin (proveedor comprador) Sistema de calidad Auditorias internas Acciones correctivas Actividades del ciclo de vida Revisin de la contratacin Especificacin de requisitos del comprador Planificacin del desarrollo Planificacin de la calidad Diseo e implementacin Prueba y validacin Aceptacin Replicacin, venta e instalacin Mantenimiento Actividades de apoyo (no dependientes del c.v) Gestin de la configuracin Control de la documentacin Registro de la calidad Medicin Reglas, prcticas y convenios Herramientas y tcnicas Ventas Productos software incluidos Formacin
12

CONCEPTOS Y DIRECTRICES GENERALES
ISO 9000
ISO 9004
GESTIN INTERNA DE LA CALIDAD
ISO 9001
DISEO, PRODUCCIN, INSTALACIN Y POSVENTA
ISO 9002
PRODUCCIN, INSTALACIN
UNE 66-907-91
GUA PARA MANUALES DE CALIDAD
ISO 9003
INSPECCIN Y ENSAYOS FINALES
ASEGURAMIENTO EXTERNO DE LA CALIDAD
Las normas de la serie ISO 9000 han sido adoptadas sin modificacin como normas europeas (serie EN 29000) y como normas espaolas (serie UNE 66-900). La norma UNE 66-907-91 (gua para manuales de calidad) es la correspondiente a ISO 9004.
13

ISO 9000
Aspectos positivos:

Es un elemento competitivo para las empresas. Proporciona confianza a los clientes. Ahorra tiempo y dinero una vez que est implantado. Implantado en ms de 90 pases y en todo tipo de empresas industriales y de servicios. Proporciona cierta seguridad de que las cosas se hacen tal y como se han dicho que se han de hacer. Es costoso de implantar, especialmente en las pequeas empresas. Muchas veces se hace por obligacin. Puede existir diferentes interpretaciones de los apartados del estndar. Existe publicidad engaosa.
Aspectos negativos:
La importancia de estos estndares radica en que permiten la certificacin a las empresas. Certificacin: proceso realizado por auditores externos que examinan si la empresa se ajusta o no a ciertos estndares.
14
Factores y Modelos de Calidad
La calidad del producto software se sustenta en una compleja mezcla de factores.
Revisin Facilidad de mantenimiento. Flexibilidad. Facilidad de prueba.
Transicin Portabilidad. Reusabilidad. Interoperatividad.
Categorizacin de McCall
Operacin Correccin. Fiabilidad. Usabilidad. Integridad. Eficiencia.
15

Para medir los factores de calidad existen diversos modelos a seguir.
Modelo de McCall
Define las siguientes mtricas:
Facilidad de auditora (FA). Exactitud (EX). Normalizacin de comunicaciones (NO). Completitud (COT). Complejidad (COJ). Concisin (COC). Consistencia (COS). Estructuracin de datos (ES). Tolerancia al error (TO). Eficiencia en la ejecucin (EF). Facilidad de expansin (FAE). Generalidad (GE). Independencia del hardware (INH). Instrumentacin (INS). Modularidad (MO). Facilidad de operacin (FAO). Seguridad (SE). Autodocumentacin (AU). Simplicidad (SI). Independencia del entorno software (INS). Trazabilidad (FAT). Formacin (FO).
16

La relacin entre las mtricas de calidad y los factores es:
Modelo de McCall
17

Modelo de McCall
Cada mtrica se estima en la escala de 0 a 10. Para cada factor de calidad se calcula: n
Fc = Ci.mi
i=1
Fc : valor cuantitativo del factor de calidad. mi : valor asignado a la mtrica (de 0 a 10). Ci : peso (tanto por uno) de la mtrica en el factor de calidad.
Ci = 1.
18

SQA Estadstica
Implica los siguientes pasos: Se clasifica la informacin sobre los defectos del software durante un tiempo determinado. Se intenta encontrar la causa subyacente de cada defecto. Se aplica el principio de Pareto: el 80% de los defectos se pueden encontrar en el 20% de las posibles causas. Se aislan el 20% de los defectos no vitales. Una vez identificados los defectos vitales, se acta para corregir los problemas que los han originado. Tiene como objetivos: Detectar los errores que ms se producen y analizar sus causas. Medir la calidad de los proyectos.
19

SQA Estadstica (aplicacin)
Las causas de error localizadas son: Especificacin incompleta o errnea (EIE). Mala interpretacin de la comunicacin con el cliente/usuario (MCC). Desviacin deliberada de la especificacin (DDE). Incumplimiento de los estndares de programacin (IEP). Error en la representacin de los datos (ERD). Interfaz de mdulo inconsistente (IMI). Error en la lgica de diseo (ELD). Prueba incompleta o errnea (PIE). Documentacin imprecisa o incompleta (DII). Error en la traduccin del diseo al lenguaje de programacin (TLP). Interfaz hombre-mquina ambigua o inconsistente (IHM). Varios (VAR).
20

La distribucin de errores por causa es:
Total
Error EIE MCC DDE IEP IMI ERD ELD PIE DII TLP IHM VAR TOTAL N 205 156 48 25 58 130 45 95 36 60 28 56 942 % 22 17 5 3 6 14 5 10 4 6 3 5 100
Grave
N 34 12 1 0 9 26 14 12 2 15 3 0 128 % 27 9 1 0 7 20 11 9 2 12 2 0 100
Moderado
N 68 68 24 15 18 68 12 35 20 19 17 15 379 % 18 18 6 4 5 18 3 9 5 5 4 5 100
Leve
N 103 76 23 10 31 36 19 48 14 26 8 41 435 % 24 17 5 2 7 8 4 11 3 6 4 9 100
21

Adems de la recopilacin de informacin de los defectos, los equipos de dearrollo pueden calcular un ndice de Errores (IE) para cada etapa principal (anlisis, diseo, codificacin, prueba y entrega) del ciclo de vida. Para cada etapa se recopila: Ei : n total de defectos descubiertos en la etapa i. Si : n de defectos graves. Mi : n de defectos moderados. Ti : n de defectos leves. PS : tamao del producto (LDC, sentencias de diseo, pginas de documentacin, etc.). Sean Ws, Wm, Wt los factores de peso de errores graves, moderados y leves (10, 3 y 1 como valores recomendados). Para cada etapa se calcula el ndice de fase (IFi): IFi = Ws (Si/Ei) + Wm (Mi/Ei) + Wt (Ti/Ei) Los factores de peso de cada fase deberan aumentar a medida que el desarrollo evoluciona. Para calcular el ndice de errores: n IE =
i * IFi ) / PS = (1*IF1 +. . . + i*Ifi) / PS

22
i =1
Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad
Procedimientos de control
Revisiones: aplicables a productos documentales en las fases iniciales e intermedias del proyecto.
Revisin mnima: intensidad 0. (DIR, EDS, USR). Revisiones tcnicas formales: intensidad 1. (DIR, EGC, EDS, USR). Inspecciones detalladas: intensidad 2. (DIR, EGC, EDS, USR).
Pruebas: aplicables a productos software ejecutables.

Validacin de mdulos: (DIR, EDS, EGC). Integracin: (DIR, EDS, EGC). Aceptacin: (DIR, EDS, EGC, USR).
Auditoras: pretende garantizar la tarea del EDS y del EGC. (DIR, AUD, EDS, EGC, USR). Evaluacin de prototipos: (USR, EGC, EDS).
23

Revisiones e inspecciones Pretenden detectar manualmente defectos, mediante la lectura, en productos de desarrollo impresos en papel. Fases: Inicio. Planificacin: seleccin de participantes y definicin de roles. Lanzamiento: explicacin del producto. Deteccin de defectos. Bsqueda de defectos. Actividad individual o de grupo. Coleccin de defectos. Evaluacin de los defectos. Documentacin de defectos. Correccin y seguimiento. Los autores corrigen el producto. El equipo de revisin/inspeccin hace el seguimiento de la correccin y de la finalizacin de la inspeccin.
24
Contexto de la Prueba de Software

Configuracin del Software Resultados de la prueba Prueba Datos de tasa de error Configuracin de la Prueba Evaluacin
Fallos
Depuracin
Resultados esperados Modelo de Fiabilidad Correciones Prediccin Fiabilidad
25

CARACTERSTICAS DE UNA BUENA PRUEBA Una buena prueba ha de tener una alta probabilidad de encontrar un fallo. Una buena prueba no debe ser redundante. Una buena prueba debera ser la mejor de la cosecha. Una buena prueba no debera ser ni demasiado sencilla ni demasiado compleja. FASES DE LA PRUEBA Diseo de las pruebas (tcnicas?) Generacin de casos de prueba (datos de prueba?) Definicin del procedimiento de la prueb (cmo, donde? Ejecucin de la prueba Informe de la prueba (resultados?) TCNICAS DE PRUEBA Pruebas estructurales o de Caja Blanca. Pruebas funcionales o de caja negra. ESTRATEGIAS DE PRUEBA Pruebas unitarias. Pruebas de integracin. Pruebas de sistema. Pruebas de aceptacin. Pruebas de regresin.
26

PRUEBAS ESTRUCTURALES Atienden al comportamiento interno y la estructura del programa, examinando la lgica interna. Disear casos de prueba para que se ejecuten: Todas las sentencias al menos una vez Todas las condiciones con valor verdadero y falso. Informacin de entrada: diseo y cdigo. Hay distintos criterios de cobertura: Cobertura de sentencias Cobertura de decisiones Cobertura de condiciones Cobertura de decisin/condicin Cobertura de condicin mltiple Cobertura de caminos COBERTURA DE CAMINOS Camino: Secuencia de sentencias encadenadas desde la entrada del programa hasta su salida. Disea casos para caminos independientes: Todas las sentencias se ejecutan al menos una vez. Las condiciones son probadas para valores verdadero y falso. Tcnica, prueba del camino bsico : Se basa en la medida de complejidad ciclomtica de Mc Cabe. Consta de los pasos: Representacin del programa como grafo de flujo. Clculo de la complejidad ciclomtica. Determinacin de un conjunto bsico de caminos linealmente independientes. Derivacin de los casos de prueba.
27

PRUEBA DEL CAMINO BSICO: Representacin del Programa como Grafo de Flujo
Notacin Nodos. Representan cero, una o varias sentencias. Aristas: Unen dos nodos. Regiones: reas delimitadas por aristas y nodos. Para contarlas, se incluir la externa. Nodos Predicado: Surgen al descomponer las sentencias condicionales compuestas en simples.
Secuencia
opcin N
While CASE
if
opcin2 END CASE
Repeat
opcin1
28
1 Aristas 2 Nodos
5 7
Regin 8
IF a OR b THEN x ELSE y ENDIF
Nodos Predicado a
False
b
True
x
False
y
29
Complejidad ciclomtica Mtrica software para averiguar la complejidad lgica de un programa. Aqu define el nmero de caminos independientes. Pone lmite superior al nmero de caminos a recorrer. Representando como V(G) la complejidad:

V(G) = Nmero de regiones V(G) = Aristas - Nodos + 2 V(G) = Nmero de nodos predicado + 1
1 Aristas 2 Nodos
3
R2
R1
R3
V(G) = Nmero de regiones = 4 V(G) = Aristas Nodos + 2 = 11-9 + 2 = 4 V(G) = Nodos Predicado + 1 = 3 +1 = 4
Regin
7 8
R4
30

CONJUNTO BSICO DE CAMINOS INDEPENDIENTES Camino independiente es cualquier camino del programa que introduce, al menos, un nuevo conjunto de sentencias de proceso o una condicin, respecto a los caminos existentes. Elegir como primer camino un camino principal que atraviese el mximo nmero de decisiones en el grafo. Definir los restantes caminos a partir del anlisis de los diferentes nodos predicados. Para el ejemplo anterior: Camino 1 : 1-9 Camino 2 : 1-2-4-8-1-9 Camino 3 : 1-2-3-5-7-8-1-9 Camino 4 : 1-2-3-6-7-8-1-9
DERIVACIN DE LOS CASOS DE PRUEBA Cada caso de prueba se disear de tal modo, que corresponda a cada uno de los caminos elegidos. Nmero de Camino Caso de Prueba Resutado Esperado
PROBLEMA: El nmero ciclomtico no da idea acerca de la complejidad de los datos.

31
PRUEBAS FUNCIONALES Se utiliza la especificacin del componente El componente se ve como una Caja Negra. Se estudia el comportamiento a partir de entradas y salidas. Tcnicas:

Particin de Equivalencia Anlisis de Valores Lmite
PARTICIN DE EQUIVALENCIA
Se basa en dos consideraciones: Se debe dividir el dominio de entrada en clases de datos (clases de equivalencia). Se deben crear casos de prueba que descubran clases de errores. Se debe minimizar el nmero total de casos de prueba. Dos pasos Identificar las clases de equivalencia. Identificar los casos de prueba.
32

IDENTIFICAR CLASES DE EQUIVALENCIA Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos para las condiciones de entrada de un programa. Se examina cada condicin de entrada y se divide en dos o ms grupos. Se identifican dos tipos de clases: Clases de equivalencia vlidas. Clases de equivalencia no vlidas. Pautas de identificacin: Rango de valores: una clase vlida y dos invlidas. Rango de valores: una clase vlida y dos no vlidas. Nmero de valores: una clase vlida y dos no vlidas Conjunto de valores de entrada: una clase vlida y otra no vlida, o tambin, antas clases vlidas como valores y una no vlida. Situacin (lgica) que debe ocurrir: Una clase vlida y una no vlidas. Se cree que no todos los elementos de la case se tratan igual: dividir en subclases.
Condicin de entrada Cdigo banco Tipo Clases de Equivalencia Vlidas 1: en blanco 2: 100<= cdigo banco <= 999 Clases de Equivalencia No Vlidas 3: un valor no numrico 4: cdigo banco < 100 5: cdigo banco > 999
Lgica (puede estar o no). Si est es rango
33
IDENTIFICACIN DE LOS CASOS DE PRUEBA

El objetivo es minimizar el nmero de casos de prueba. Asignar un nmero nico a cada clase de equivalencia. Escribir un caso que cubra tantas clases vlidas no cubiertas como sea posible hasta que se cubran todas las clases de equivalencia vlidas. Escribir un caso que cubra una sola clase no vlida no cubierta hasta que se cubran todas las clases de equivalencia no vlidas.
34
ANLISIS DE VALORES LMITES Condiciones lmite: aquellas que se hallan en los mrgenes de las clases de equivalencia, tanto de entrada como de salida. Complementan la tcnica anterior: Se seleccionan uno o ms elementos tal que los mrgenes de la clase se sometan a prueba. Se considerar tambin el dominio de salida. Seleccin de casos de prueba: Rango de valores: dos casos de prueba para los dos lmites del rango y dos casos para situaciones justo ms all de los extremos. Nmero de valores: casos de prueba para los valores mnimo y mximo, otros dos casos para valores justo por encima del mximo y justo por debajo del mnimo. Aplicar las reglas anteriores para datos de salida Si la entrada o la salida es un conjunto ordenado, atencin al primero y ltimo.
35
ESTRATEGIA DE PRUEBAS Pruebas Unitarias: (caja blanca y caja negra) Cada mdulo es probado por separado y por la persona que lo cre: Mdulo: pieza de cdigo que cumple: Bloque bsico de programa Implementa funcin independiente simple Puede probarse por separado Normalmente menor de 500 lneas de cdigo. Pruebas de Integracin: (caja negra)
Incremental:
Incremental Ascendente: se combinan los mdulos de ms bajo nivel, utilizando controladores para los de ms alto nivel.
Incremental Descendente: se comienza en el mdulo de mayor nivel y se incorporan los mdulos subordinados bien en profundidad o anchura No incremental
36

INCREMENTAL ASCENDENTE Ma C1 Mc Mb
C2
C3
Grupo 3
Grupo 1
Grupo 2 M1 M2 M4 R3
R7 R6
M3 INCREMENTAL DESCENDENTE
37
R5
M7
M5
M6

ESTRATEGIA DE PRUEBAS Pruebas del Sistema: (caja negra) Se cumplen los requisitos funcionales establecidos durante el anlisis. El funcionamiento y rendimiento en las interfaces hardware, software y de usuario. La adecuacin de la documentacin de usuario. Rendimiento y respuesta en condiciones lmite y de sobrecarga. Pruebas Alfa y pruebas Beta. Pruebas de Aceptacin: Participacin activa del usuario, que deber ejecutar casos de prueba ayudado por miembros del equipo de pruebas. Estn enfocadas para probar los requisitos de usuario. Corresponden a la fase final del proceso de desarrollo software. Pruebas de Regresin: Regresin: Repeticin selectiva de pruebas para detectar fallos introducidos durante la modificacin de un sistema o componente. En ellas habr que: Probar los mdulos cambiados Decidir las pruebas a efectuar en los mdulos no cambiados. Debern efectuarse: Cuando existe riesgo de que los cambios afecten a otras reas no modificadas directamente. Durante el desarrollo, despus de ciertos cambios. Durante el mantenimiento.
38

Instrumentos de control
Listas de control: definen de forma explcita los puntos concretos que deben ser controlados al aplicar el procedimiento de control de calidad Guiones de recomendaciones: contienen criterios, ideas y recomendaciones aplicables al realizar las tareas correspondientes a los procedimientos de control de calidad.
Elementos auxiliares
Hacen referencia a formatos o plantillas que se pueden aplicar a los distintos documentos auxiliares que se han de ir generando al realizar las actividades de aseguramiento de la calidad:
Hojas de comentarios de usuarios. Hojas de comentarios de revisin. Lista de acciones correctivas. Hoja de aprobacin provisional. Plan de pruebas. Informe de pruebas de validacin de mdulos. Informe de pruebas de integracin. Informe de monitorizacin de las pruebas de aceptacin. Informe de anlisis e interpretacin de resultados. Plan de auditora del proyecto. Informe de auditora del proyecto. Informe de evaluacin del prototipo. Informe final de verificacin y validacin de la aplicacin.
39
40
41
42

Dossier del Aseguramiento de la Calidad
Documentos generados por el EDS: DBP: documento base y de planificacin. DED: documento de especificaciones de diseo. DDD: documento de descripcin del diseo. DDF: documento de diseo funcional. DDT: documento de diseo tcnico. DTP: documentacin tcnica de programacin. DOP: documentacin de operacin. DRU: documento de referencia para usuarios. Documentos auxiliares generados por el EDS: IAIR: informe de anlisis e interpretacin de resultados de las pruebas de aceptacin. Documentos generados por el USR: HCU: hojas de comentarios de usuario. Documentos generados por el EGC: PGC: plan de garanta de calidad del proyecto. HCR: hojas de comentarios de revisin. LAC: listas de acciones correctivas. HAP: hojas de aprobacin provisional. PPRB: plan de pruebas. IPVM: informe de pruebas de validacin de mdulos. IPI: informe de pruebas de integracin. IPAA: indorme de monitorizacin de pruebas de aceptacin de la aplicacin. IEP: informes de evaluacin de prototipos. IVVA: informe final de verificacin y validacin de la aplicaci.on. Documentos generados por AUD: PAUD: plan de auditora del proyecto. IAUD: informes de auditora del proyecto.
43
Plan General de Aseguramiento de la Calidad
Marco homogneo de referencia para disear y aplicar los planes especficos de calidad a los proyectos.
Plan calidad proyecto 1 Plan calidad proyecto 2
PGAC
Plan calidad proyecto n
Objetivos:

Ofrecer una metodologa para elaborar los planes especficos. Ofrecer una metodologa para evaluar preliminarmente a los proyectos. Elaborar procedimientos e instrumentos de control. Gua metodolgica para elaborar Planes Especficos de Aseguramiento de la Calidad. Esquema formal para la clasificacin de proyectos. Procedimientos de Control de Calidad. Instrumentos de control y elementos auxiliares de aseguramiento de la calidad.
Se estructura en:
Es independiente de las metodologas de desarrollo. Se basa en estndares: ISO 8402, 9000, 9001, 9002, 9003, 10011-1, -2, -3, y diferentes normas ANSI/IEEE.
44

Caractersticas de los planes especficos de calidad

Adaptacin al proyecto y a las circunstancias. Respeto de los estndares de aseguramiento de calidad reconocidos.
Agentes participantes en un proyecto USR
DIR
EDS
EGC
AUD
Relacin de los agentes con el PGAC DIR
PGAC
AUD EGC
Plan especfico de calidad
USR EDS
45

Metodologa para la elaboracin de planes especficos de calidad
I. Actuaciones preliminares
II. Caracterizacin del proyecto
III. Seleccin y adaptacin de procedimientos de control
IV. Seleccin y adaptacin de instrumentos de control y elementos auxiliares
V. Redaccin y aprobacin del plan especfico de calidad

46

Metodologa para la elaboracin de planes especficos de calidad
Actuaciones preliminares

Designar al representante de los usuarios Designar al director del proyecto Elaborar las especificaciones de usuario para desarrollo/contratacin
Caracterizacin del proyecto a efectos de calidad

Designar al responsable de calidad Obtener el Diagrama Caracterstico Aplicar el esquema Formal de Clasificacin

Modelo de referencia Perfil de riesgo Foco de inters
Seleccin y adaptacin de procedimientos de control calidad Seleccin y adaptacin de instrumentos de control de calidad y elementos auxiliares Redaccin y aprobacin del plan Ejecucin del plan (y del proyecto) 47
48
49
50
51
52

Estructura y contenido del PAC especfico del proyecto

Objetivos y alcance. Fases, productos y componentes del proyecto. Procedimientos de control. Instrumentos de control y elementos auxiliares. Organizacin y gestin del aseguramiento de la calidad del proyecto. Registro de actuaciones: el Dossier de Aseguramiento de la Calidad. Estndares y normas. Documentos de referencia. Revisin del Plan.
53
Esquema formal para la clasificacin de proyectos (EFC)
Etapas a seguir
I. Estimacin de factores crticos y obtencin del diagrama caracterstico
II. Seleccin del modelo de referencia
III. Obtencin del perfil de riesgos
IV. Determinacin del foco de inters
54

Estimacin de factores crticos y obtencin del diagrama caracterstico Atributos significativos del proyecto Intrnsecos de la aplicacin:

Dimensin (DIM). Complejidad (COMP). Requisitos de fiabilidad (FIAB). Requisitos de seguridad (SEC). Requisitos de comportamiento externo (CEX). Requisitos de comportamiento interno (CIN). Grado de definicin y estructura de las especificaciones (DESP). Caracterstica de la mquina:

Relativos al entorno de implantacin:
Tipologa (TPMV). Funcionalidad (FCMV). Grado de distribucin y heterogeneidad (DHMV).
Carga de trabajo (CTR). Nivel de interaccin con otras aplicaciones o datos del entorno. Diferencias entre los entornos de desarrollo y de implementacin.
55

Estimacin de factores crticos y obtencin del diagrama caracterstico Atributos significativos del proyecto Relativos al proyecto o proceso de desarrollo.

Coste estimado del proyecto (COST). Plazo estimado de ejecucin (PLZ). Estabilidad del proyecto (EPRY). Evaluacin previa del contratista (ECON). Disponibilidad de recursos para el aseguramiento de la calidad.
56

Estimacin de factores crticos y obtencin del diagrama caracterstico
Atributos significativos del proyecto

El rango de todos ellos es 1..5. Dimensin (DIM). 1: pequeo. 1 a 6 meses hombre. 2: moderado. 6 a 24 meses hombre. 3: mediano. 24 a 60 meses hombre. 4: grande. 60 a 120 meses hombre. 5: muy grande. >= 120 meses hombre. Complejidad (COMP). Los factores a considerar son;

N de mdulos y nivel de interrelacin. N y tipo de interfaces con otros sistemas. Distribucin y heterogeneidad del entorno de implantacin. Grado de satisfaccin de las herramientas de desarrollo. Naturaleza de los algoritmos que hay que disear e implementar. Otros factores.
A cada factor se le asigna un valor de 1 a 5 y se promedia el valor final. 1: el efecto de un fallo no causa perjuicio significativo para el usuario. 2: el efecto de un defecto causa perjuicios que el usuario puede asumir. 3: el efecto del defecto lo puede asumir el usuario a un elevado coste. 4: el defecto causa grandes prdidas al usuario o perjuicios a un nmero considerable de personas. 5: el defecto puede poner en peligro vidas humanas o causar prdidas irrecuperables.
Requisitos de fiabilidad (FIAB).
57

Requisitos de seguridad (SEC). 1 a 3: sistemas administrativos. 4 a 5: sistemas crticos. Requisitos de comportamiento externo (CEX). 1: inexistencia de requisitos de comportamiento externo en el documento de especificaciones. ... 5: condicionantes muy severos de requisitos de comportamiento externo.
Requisitos de comportamiento interno (CIN).
1: inexistencia de requisitos de comportamiento interno en el documento de especificaciones. ... 5: condicionantes muy severos de requisitos de comportamiento interno.
Grado de definicin, estructura y modularidad de las especificaciones (DESP).
1 a 4: en funcin de la claridad, facilidad de comprensin, verificabilidad, trazabilidad, . . . 5: las especificaciones, adems de un buen nivel de detalle poseen un notable grado de modularidad.
58

Tipologa de la mquina virtual (TPMV). 1: bajo nivel de sofisticacin. 2: moderado nivel de sofisticacin. 3: nivel intermedio de sofisticacin. 4: Nivel alto de sofisticacin. 5: Nivel muy alto de sofisticacin.
Funcionalidad de la mquina virtual (FCMV).

1 a 3: rica. 4 a 5: pobre.
Grado de destribucin y heterogeneidad de la mquina virtual (DHMV).

1: sistema monoltico. 2: varias plataformas hardware idnticas con el mismo sistema operativo y el mismo software intermedio. 3: varias plataformas hardware con la misma familia de ordenadores con el mismo sistema operativo y el mismo software intermedio. 4: varias plataformas hradware diferentes, con diferentes sistemas operativos y con el mismo software intermedio. 5: varias plataformas hardware diferentes, con diferentes sistemas operativos y con diferentes software intermedio. 1: mnima severidad de las condiciones de carga de trabajo. ... 5: mxima severidad de las condiciones de carga de trabajo. 59
Carga de trabajo (CTR).


Atributos significativos del proyecto Nivel de interaccin con otros sistemas o datos (INT).

1: no existe interaccin. 2: el sistema usa datos o procedimientos compartidos. 3: el sistema acta como post-procesador de otros sistemas. 4: el sistema acta en modo cliente-servidor con otros sistemas. 5: el sistema intercambia mensajes y datos con otros sistemas en un entorno distribuido y heterogneo.
Diferencias entre los entornos de desarrollo y de implementacin (DIFE).

1: total coincidencia. 2: coincidencia en la mquina pero existen diferencias organizativas y de recursos humanos. 3: diferencias moderadas en la mquina y en las organizaciones. Diferencias significativas en la mquina y en las organizaciones. Diferencias acusadas en la mquina y en las organizaciones. 1: 2: 3: 4: 5: pequo (<= 18.000 euros). moderado (18000 <= coste <= 60000). medio (60000 <= coste <= 150000). grande (150000 <= coste <= 600000). muy grande (>= 600000). 60
Coste total estimado del proyecto (COST).


Atributos significativos del proyecto Plazo estimado de desarrollo (PLZ).

1: 2: 3: 4: 5:
pequo (<= 3 meses). moderado (3 meses <= plazo <= 6 meses). medio (6 meses <= plazo <= 1 ao). grande (1 ao <= plazo <= 2 aos). muy grande (>= 2 aos).
Estabilidad del proyecto (EPRY).
Se puede contemplar:

Definicin, exhaustividad y precisin de las especificaciones. Neutralidad del dominio del problema frente a disposiciones normativas de probable aparicin. Independencia de las especificaciones respecto al entorno de implantacin. Permanencia de los usuario s o promotores. Nmero de interlocutores o centros de decisin afectados por el proyecto. Grado de homogeneidad y de comunidad de intereses entre los distintos interlocutores.
Evaluacin previa del contratista (ECON).

1: 2: 3: 4: 5:
elevado grado de confianza. moderado grado de confianza. situacin de incertidumbre y neutralidad. cierto grado de prevencin, o varios contratistas. manifiesto recelo, o excesivo nmero de contratistas.
Disponibilidad de recursos para el aseguramiento de la calidad (REC).

1: 2: 3: 4: 5:
serias dificultades. claras limitaciones. cierto nivel de disponibilidad, pero con limitaciones. situacin favorable. no existen limitaciones.
61

62

63
Seleccin del modelo de referencia
El PGAC contempla cinco modelos de referencia: Secuencial bsico. Secuencial intermedio. Secuencial detallado. Desarrollo evolutivo por prototipo. Desarrollo modular.
64

Secuencial bsico Productos a obtener: Diseo: documento de especificaciones de diseo (DED); documento de descripcin del diseo (DDD). Programacin: cdigo fuente; documentacin tcnica de programacin (DTP). Implantacin y pruebas de aceptacin: aplicacin software ejecutable (APL); documento de operacin (DOP); documento de referencia para usuarios (DRU).
65

Secuencial intermedio Productos a obtener: Elaboracin especificaciones de diseo: documento de especificaciones de diseo (DED). Diseo funcional: documento de diseo funcional (DDF). Diseo tcnico detallado: documento de diseo tcnico (DDT). Programacin: cdigo fuente; documentacin tcnica de programacin (DTP). Implantacin y pruebas de aceptacin: aplicacin software ejecutable (APL); documento de operacin (DOP); documento de referencia para usuarios (DRU).
66
Secuencial intermedio
67

Secuencial detallado Productos a obtener: Planificacin del desarrollo: Documento baso de planificacin del desarrollo (DBP) Elaboracin especificaciones de diseo: documento de especificaciones de diseo (DED). Diseo funcional: documento de diseo funcional (DDF). Diseo tcnico detallado: documento de diseo tcnico (DDT). Programacin: cdigo fuente; documentacin tcnica de programacin (DTP). Integracin: software ejecutable de partes constituyentes de la aplicacin (APL). Implantacin y pruebas de aceptacin: aplicacin software ejecutable (APL); documento de operacin (DOP); documento de referencia para usuarios (DRU).
68
Secuencial detallado
69

Desarrollo evolutivo por prototipo Productos a obtener: Procesos de experimentacin: por cada iteracin se realiza el Informe de Evaluacin del Prototipo (IEP). Especificaciones finales y diseo:
documento de especificaciones de diseo (DED) y documento de descripcin del diseo (DDD), si se sigue el modelo secuencial bsico. documento de diseo funcional (DDF) y documento de diseo tcnico (DDT), si se sigue el modelo secuencial intermedio.
Programacin: cdigo fuente; documentacin tcnica de programacin (DTP). Implantacin y pruebas de aceptacin: aplicacin software ejecutable (APL); documento de operacin (DOP); documento de referencia para usuarios (DRU).
70

Evolucin de prototipos
71

Desarrollo modular Productos a obtener: Estudio preliminar y planificacin del desarrollo: Documento base de planificacin del desarrollo (DBP). Desarrollo de mdulos en paralelo: los correspondientes a cada fase del modelo secuencial que se siga y aplicados a cada uno de los mdulos. Integracin de mdulos: software ejecutable e integrado de todos los mdulos. Implantacin y pruebas de aceptacin: aplicacin software ejecutable (APL); documento de operacin (DOP); documento de referencia para usuarios (DRU).
72

Desarrollo modular
73

Pasos a seguir Evaluar los factores de discriminacin del proyecto (FDPi) en relacin con cada uno de los modelos de referencia. Para ello, para cada modelo:
Se contrasta el diagrama caracterstico del proyecto con la plantilla de comparacin correspondiente.
Aj) se obtien el valor del factor de discriminacin parcial fj: fj = ( tjk * dk ) / n Tjk : valor de cada uno de los cuadros de la trama
Para cada fila de la parrilla (atributo del diagrama caracterstico del proyecto no cubierto por la trama de la plantilla de comparacin que se est utilizando.
distancia medida entre ese cuadro y el que resulte ms prximo en la plantilla (valor absoluto de la diferencia entre los valores correspondientes). : nmero total de cuadros del diagrama caracterstico no cubiertos por la plantilla del modelo, en la fila de que se trate. El valor del FDPi correspondiente es la media aritmtica simple de los valores j:
dk : n
FDPi
Se seleccionar el modelo que presente el FDPi menor.
fj / 18
74

(plantillas de comparacin)
Secuencial bsico
75

76

Desarrollo modular
77

(comparacin con la plantilla)
Secuencial bsico
78

79

Desarrollo modular
80

Obtencin del perfil de riesgos
Dos umbrales de riesgos: ordinario y extraordinario. Siete tipos de riesgos:
R1: defectos graves y recurrentes en el comportamiento externo de la aplicacin. R2: baja calidad de los productos obtenidos en las fases del desarrollo. R3: dificultades graves de implantacin por mala adecuacin de la aplicacin a su entorno real de operacin. R4: imposibilidad de mantener los costes de desarrollo en consonancia con lo establecido en la contratacin. R5: incumplimiento grave de los plazos de ejecucin. R6: imposibilidad de gestionar y controlar adecuadamente el desarrollo del proyecto. R7: no finalizacin del proyecto.
Se ha de obtener el coeficiente de divergencia CDi para cada tipo de riesgo:
CDj = ( aij )/n - ( bik )/m

j=1,n k=1,m
81

Los atributos de los grupos A y B para cada tipo de riesgo son: Para R1.

Grupo A: [FIAB], [SEC], [CEX],[CTR], [ECON] Grupo B: [DESP], [PLZ], [REC] Grupo A: [DIM], [COMP], [FIAB], [SEC], [CEX], [ECON] Grupo B: [DESP], [COST], [PLZ], [EPRY], [REC] Grupo A: [CIN], [FCMV], [DHMV], [INT], [DIFE], [ECON] Grupo B: [COST], [PLZ], [REC] Grupo A: [DIM], [COMP], [FIAB], [FCMV], [ECON] Grupo B: [DESP], [COST], [EPRY] Grupo A: [DIM], [COMP], [FIAB], [FCMV], [ECON] Grupo B: [DESP], [PLZ], [EPRY] Grupo A: [DIM], [COMP] Grupo B: [REC] Grupo A: [DIM], [COMP], [FIAB], [SEC], [CEX], [CIN], [TPMV], [FCMV], [DHMV], [CTR], [INT], [DIFE], [ECON] Grupo B: [DESP], [COST], [PLZ], [EPRY], [REC]
Para R2.

Para R3.
Para R4.

Para R5.

Para R6.

Para R7.
82

La interpretacin de los valores obtenidos para cada Cdi es:

0 <= Cdi < 3 : nivel ordinario de riesgos. 3 <= Cdi <= 5 : nivel de riesgos extraordinarios. -3 < Cdi <= 0 : proyecto satisfactorio. -5 <= Cdi <= -3 : planteamiento inicial del proyecto desajustado.
Se obtiene el perfil de riesgos del proyecto:
Ejemplo
83

Determinacin del foco de inters
Permite disear el plan especfico de garanta de calidad del proyecto. Se asigna a cada fase y producto del proyecto el nivel de intensidad correspondiente. Los dos niveles de intensidad son: normal (1) y especial (2). El procedimiento a seguir:
Se contrasta el diagrama caracterstico del proyetco con la plantilla correspondiente. Se elabora la matriz de intensidades. Se deduce el grado de intensidad ms adecuado para el control de las fases y productos a partir de la matriz de intensidades y de la criticidad de los atributos del proyecto. A partir del foco de inters se disea el plan especfico de garanta de calidad del proyecto.
Existe un nivel mnimo de intensidad (0) aplicable a las situaciones en las que no se disponga de recursos adecuados para la gestin de la garanta de calidad.
84

85

86

87

88

89

90

91

Segn la matriz anterior, el foco de inters del proyecto ejemplo sera:

Fase 1( Anlisis ): nivel 1 Fase 2(Desarrollo):

21.(Especificaciones): nivel 2. 2.2.1 (Diseo funcional): nivel 1. 2.2.2. (Diseo tcnico): nivel 1. 2.3 (Programacin): nivel 1. 2.4 (Pruebas del mdulo): nivel 2.
Fase 3 (Integracin de mdulos): nivel 2. Fase 4: Pruebas de aceptacin): nivel 2.
92
BIBLIOGRAFA
Dolado, j.j.; Fernndez, l y otros. Medicin para la gestin en la Ingeniera del Software. Ra-Ma, 2000 Jenner, M. L. Software Quality Management and ISO 9001. How to make them work for you. JohnWiley & Sons, Inc., 1995. IEEE Standards Collection Software Engineering. IEEE, 1997. Plan General de Garanta de Calidad Aplicable al Desarrollo de Equipos Lgicos. Ministerio de Administraciones Pblicas, 1991. Pressman, R.S., Ingeniera del Software, un enfoque prctico, Mc Graw Hill, 2001.
93

Tema 4 Calidad

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tema 4 Calidad

Transféré par

Droits d'auteur :

Formats disponibles

INGENIERA DEL SOFTWARE III

CONTROL Y GESTIN DEL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

CONTROL Y GESTIN DEL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

Introduccin al Aseguramiento de la Calidad del Software.

Plan General de Calidad.

Introduccin al aseguramiento de la calidad del Software

Introduccin al aseguramiento de la calidad del Software

Introduccin al aseguramiento de la calidad del Software

Evolucin relativa del coste de correccin de un defecto. 30 a 70 15 a 40

Pruebas Explotacin de sistema

Introduccin al aseguramiento de la calidad del Software

Principios bsicos de la calidad del software

Introduccin al aseguramiento de la calidad del Software

Establecimiento de un plan para el aseguramiento de la calidad del proyecto:

Seguimiento de las desviaciones Verificacin de la realizacin de las correcciones

Introduccin al aseguramiento de la calidad del Software

Sus funciones son:

Introduccin al aseguramiento de la calidad del Software

Marco normativo relacionado con la calidad

Marco normativo relacionado con la calidad

Marco normativo relacionado con la calidad

Marco normativo relacionado con la calidad

ASEGURAMIENTO EXTERNO DE LA CALIDAD

Marco normativo relacionado con la calidad

Factores y Modelos de Calidad

La calidad del producto software se sustenta en una compleja mezcla de factores.

Revisin Facilidad de mantenimiento. Flexibilidad. Facilidad de prueba.

Transicin Portabilidad. Reusabilidad. Interoperatividad.

Operacin Correccin. Fiabilidad. Usabilidad. Integridad. Eficiencia.

Factores y Modelos de Calidad

Factores y Modelos de Calidad

Factores y Modelos de Calidad

Factores y Modelos de Calidad

Factores y Modelos de Calidad

Factores y Modelos de Calidad

Factores y Modelos de Calidad

i * IFi ) / PS = (1*IF1 +. . . + i*Ifi) / PS

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Pruebas: aplicables a productos software ejecutables.

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Contexto de la Prueba de Software

Resultados esperados Modelo de Fiabilidad Correciones Prediccin Fiabilidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

IF a OR b THEN x ELSE y ENDIF

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

PROBLEMA: El nmero ciclomtico no da idea acerca de la complejidad de los datos.

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Particin de Equivalencia Anlisis de Valores Lmite

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Lgica (puede estar o no). Si est es rango

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

IDENTIFICACIN DE LOS CASOS DE PRUEBA

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

Procedimientos, instrumentos de control y elementos auxiliares del aseguramiento de la calidad

i * IFi ) / PS = (1IF1 +. . . + iIfi) / PS