Nbr iso 9000 3 2003 gestão da qualidade aplicacao da nbr 19001

Cópia não autorizada

CDU: 658.56:681.3.06

NOV 1993

NBR ISO 9000-3

Normas de gestão da qualidade e garantia da qualidade ABNT-Associação Brasileira de Normas Técnicas

Parte 3: Sede: Rio de Janeiro Av. Treze de Maio, 13 - 28º andar CEP 20003 - Caixa Postal 1680 Rio de Janeiro - RJ Tel.: PABX (021) 210 -3122 Telex: (021) 34333 ABNT - BR Endereço Telegráfico: NORMATÉCNICA

Copyright © 1990, ABNT–Associação Brasileira de Normas Técnicas Printed in Brazil/ Impresso no Brasil Todos os direitos reservados

Diretrizes para a aplicação da NBR 19001 ao desenvolvimento, fornecimento e manutenção de "software"

CB-25 - Comitê Brasileiro da Qualidade CE-25:000.02 - Comissão de Estudo de Sistemas de Qualidade NBR ISO 9000-3 - Quality management and quality assurance standards Parte 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software Descriptors: Programming (computers) Quality assurance. Quality assurance programme.

Descritores: Programação (computadores). Garantia da qualidade. Programa de garantia da qualidade

Sumário Introdução 1 Objetivo 2 Referências normativas 3 Definições 4 Sistema da qualidade - Estrutura 5 Sistema da qualidade - Atividades do ciclo de vida 6 Sistema da qualidade - Atividades de apoio (não dependentes de fase) Anexos A - Referência cruzada entre NBR ISO 9000-3 e NBR 19001 B - Referência cruzada entre as NBR 19001 e NBR ISO 9000-3

Introdução Com o progresso da tecnologia da informação, a quantidade de “software” vem crescendo e tornando essencial a gestão da qualidade de produtos de “software”.

Um dos meios de estabelecer um sistema de gestão da qualidade é fornecer orientação para a garantia da qualidade do “software”.

Os requisitos para um sistema da qualidade genérico, pa-ra situações contratuais entre duas partes, já estão disponíveis na NBR 19001 (ISO 9001):1990, Sistemas da qualidade -Modelo para garantia da qualidade em projetos/ desenvolvimento, produção, instalação e assistência técnica.

Entretanto, o processo de desenvolvimento e manutenção de “software” é diferente da maioria dos demais ti-

14 páginas

pos de produtos industriais, tornando necessário prover, nesse campo da tecnologia de desenvolvimento tão rápido, orientações adicionais para o estabelecimento de sistemas da qualidade onde estejam envolvidos os produtos de “software”, levando-se em conta o estágio atual da tecnologia.

A natureza do desenvolvimento de “software” é tal, que algumas atividades estão relacionadas às fases específicas do processo de desenvolvimento, enquanto outras podem ser aplicadas ao longo de todo o processo. Estas diretrizes foram assim estruturadas para refletir tais diferenças. Outrossim, este documento, no que se refere ao formato, não corresponde diretamente à norma NBR 19001, sendo, por essa razão, fornecidos índices de referência cruzada (anexos A e B) para facilitar a consulta àquela norma.

Contratos entre duas partes, para o desenvolvimento de “software”, podem ocorrer com muitas variações. Em certos casos de contratos entre duas partes, estas diretrizes podem não ser aplicáveis ainda que adaptadas. Torna-se, portanto, indispensável determinar a adequação do uso desta NBR ISO 9000-3 ao contrato.

Esta NBR ISO 9000-3 aborda basicamente situações em que um “software” específico é desenvol-vido como parte de um contrato, de acordo com as especificações do comprador. No entanto, os con-

Cópia não autorizada

2

NBR ISO 9000-3/1993

ceitos descritos podem ser de igual valor em outras situações.

Modelo para garantia da qualidade em projetos/desenvolvimento, produção, instalação e assistência técnica.

NOTAS 1 Ao longo desta NBR ISO 9000-3, quando não houver orientações adicionais, o texto do item pertinente da NBR 19001 é impresso em itálico.

2 Nesta NBR ISO 9000-3, há várias listas, sendo que nenhuma delas pretende ser exaustiva. São apresentadas a título de exemplo.

1 Objetivo Esta NBR ISO 9000-3 define diretrizes para facilitar a aplicação da NBR 19001 a organizações que desenvolvem, fornecem e mantêm “software”.

Destina-se a fornecer orientação quando um contrato entre duas partes exigir a demonstração da capacidade de um fornecedor em desenvolver, fornecer e manter produtos de “software”.

Estas diretrizes destinam-se a descrever os controles e métodos sugeridos para a produção de “software” que atendam aos requisitos do comprador, evitando-se nãoconformidades em todos os estágios, desde o desenvolvimento até a manutenção.

As diretrizes desta NBR ISO 9000-3 são aplicáveis em situações contratuais para produtos de “software”, quando: a) o contrato exigir, especificamente, esforço de projeto, e os requisitos do produto forem indicados principalmente em termos de desempenho, ou precisarem ser estabelecidos; b) a confiança no produto puder ser obtida através da demonstração adequada da capacidade de desenvolvimento, fornecimento e manutenção de um determinado fornecedor.

2 Referências normativas As normas relacionadas contêm disposições que, atra-vés de referências neste texto, constituem prescrições desta NBR ISO 9000-3. Na data da publicação desta NBR ISO 9000-3, as edições indicadas eram válidas.

Como todas as normas estão sujeitas a revisões, as partes interessadas dos acordos baseados nesta NBR ISO 9000-3 são encorajadas a investigar a possibilidade de utilização de edições mais recentes das normas indicadas a seguir. A ABNT mantem registros das normas válidas atualmente.

ISO 2382-1:1984, Data processing - Vocabulary - Part 01: Fundamental terms.

NBR ISO 10011-1:1993, Diretrizes para auditoria de sistemas de qualidade - Parte 1: Auditoria.

3 Definições Para os propósitos desta NBR ISO 9000-3, são aplicáveis as definições contidas nas ISO 2382-1 e NBR ISO 8402, juntamente com as definições a seguir.

3.1 “software”: criação intelectual compreendendo os programas, procedimentos, regras e qualquer documentação correlata à operação de um sistema de processamento de dados.

[ISO 2382-1: 1984, 01.04.04] NOTA - O “software” não depende do meio no qual é registrado.

3.2 produto de “software”: Conjunto completo de programas de computador, procedimentos e documenta-ção correlata, assim como dados designados para en-trega a um usuário.

3.3 item de “software”: Qualquer parte identificável de um produto de “software” em etapa intermediária ou na etapa final do desenvolvimento.

3.4 desenvolvimento: Todas as atividades a serem realizadas para a criação de um produto de “software”.

3.5 fase: Segmento definido do trabalho.

NOTA - Uma fase não implica no uso de qualquer modelo de ciclo de vida específico, nem implica em um período de tempo durante o desenvolvimento de um produto de “software”.

3.6 verificação (de “software”): Processo de avaliação dos produtos de uma determinada fase a fim de asse-gurar a correção e a consistência no que diz respeito aos produtos e normas fornecidos como entrada para a referida fase.

3.7 Validação (para "software"): Processo de avaliação de "software" a fim de assegurar que este atende aos requisitos especificados.

4 Sistema da qualidade - Estrutura 4.1 Responsabilidade da administração 4.1.1 Responsabilidade da administração do fornecedor 4.1.1.1 Política da qualidade

NBR ISO 8402:1993, Gestão da qualidade e garantia da qualidade - Terminologia.

A administração do fornecedor deve definir e documen-tar sua política e objetivos para a qualidade, e assumir o compromisso com estes. O fornecedor deve assegurar que esta política é entendida, implementada e mantida em todos os níveis da organização.

NBR 19001:1990 (ISO 9001), Sistemas da qualidade -

[NBR 19001:1990 4.1.1]

Cópia não autorizada

NBR ISO 9000-3/1993

3

4.1.1.2 Organização

4.1.2 Responsabilidade da administração do comprador

4.1.1.2.1 Responsabilidade e autoridade

O comprador deve cooperar com o fornecedor, a fim de prover todas as informações necessárias em tempo hábil e resolver itens pendentes.

A responsabilidade, autoridade e interação de todo o pessoal que administra, desempenha e verifica atividades que influem na qualidade devem ser definidas, particularmente as do pessoal que necessita de autonomia organizacional e autoridade para: a) iniciar ações para prevenir a ocorrência de nãoconformidade em produto; b) identificar e registrar quaisquer problemas de qualidade do produto; c) iniciar, recomendar ou providenciar soluções através dos canais designados; d) verificar a implementação das soluções; e) controlar processamento posterior, entrega ou instalação de produto não-conforme, até que a deficiência ou condição insatisfatória tenha sido corrigida.

O comprador deve designar um representante responsável para tratar de assuntos contratuais com o fornecedor. Este representante deve ter autoridade, de acordo com a necessidade, para tratar dos assuntos contratuais que incluem os seguintes itens, mas não se limitam a estes: a) definir requisitos do comprador para fornecedor; b) responder a perguntas do fornecedor; c) aprovar as propostas do fornecedor; d) concluir acordos com o fornecedor; e) garantir que a organização do comprador observa os acordos firmados com o fornecedor; f) definir critérios e procedimentos de aceitação;

[NBR 19001:1990, 4.1.2.1] 4.1.1.2.2 Recursos e pessoal para verificação

O fornecedor deve identificar seus requisitos internos de verificação, prover recursos adequados e designar pessoal treinado para as atividades de verificação.

As atividades de verificação devem incluir inspeção, ensaio e monitorização de processos e/ou produto de projeto, produção, instalação e de assistência técnica; análises críticas de projeto e auditorias do sistema da qualidade, dos processos e/ou produto, devem ser realizadas por pessoal independente daquele que tem responsabilidade direta pelo trabalho que está sendo executado.

[NBR 19001:1990, 4.1.2.2] 4.1.1.2.3 Representante da administração

O fornecedor deve designar um representante da administração que, independentemente de outras responsabilidades, tenha autoridade e responsabilidade definidas para assegurar que os requisitos da NBR 19001 sejam implementados e mantidos.

[NBR 19001:1990, 4.1.2.3] 4.1.1.3 Análise crítica pela administração

O sistema da qualidade adotado para atender aos requisitos da NBR 19001, deve ser analisado criticamente, em intervalos adequados, pela administração do fornecedor, a fim de assegurar a sua contínua adequação e eficácia. Devem ser mantidos registros destas análises.

NOTA - As análises críticas incluem normalmente a avaliação dos resultados de auditorias internas do sistema da qualidade, executadas pela administração do fornecedor ou, em seu nome, pelo pessoal da administração com responsabilidade direta pelo sistema.

[NBR 19001:1990, 4.1.3]

g) negociar com o comprador sobre itens de “software” fornecidos que foram considerados inadequados para o uso.

4.1.3 Análises críticas conjuntas

Análises críticas conjuntas regulares, envolvendo o fornecedor e o comprador, devem ser programadas a fim de cobrir os aspectos a seguir, conforme apropriado: a) conformidade do “software” com os requisitos especificados e acordados com o comprador; b) resultados da verificação; c) resultados do ensaio de aceitação.

Os resultados destas análises críticas devem ser acordados e documentados.

4.2 Sistema da qualidade 4.2.1 Generalidades

O fornecedor deve estabelecer e manter um sistema da qualidade documentado. O sistema da qualidade deve ser um processo integrado por todo o ciclo de vida, assegurando assim que a qualidade seja perseguida ao longo do desenvolvimento do processo, em vez de ser verificada ao final. A prevenção de problemas deve ser enfatizada mais do que a correção após a ocorrência destes.

O fornecedor deve assegurar a implementação efetiva do sistema da qualidade documentado.

4.2.2 Documentação do sistema da qualidade

Todos os elementos, requisitos e prescrições do sistema da qualidade devem ser claramente documentados de maneira sistemática e ordenada.

Cópia não autorizada

4

NBR ISO 9000-3/1993

4.2.3 Plano da qualidade

O fornecedor deve preparar e documentar um plano da qualidade, a fim de implementar atividades da qualidade para cada desenvolvimento de “software”, baseando-se no sistema da qualidade e assegurando que este seja entendido e observado pelas organizações envolvidas.

Atividades relacionadas à qualidade devem ser planejadas e implementadas de acordo com a natureza do modelo de ciclo de vida utilizado.

Esta Norma destina-se à aplicação de qualquer modelo de ciclo de vida utilizado. Qualquer descrição, orientação, requisito ou estrutura deve ser entendido como indicação de que atende a todos os modelos de ciclo de vida.

4.3 Auditorias internas do sistema da qualidade Auditorias internas da qualidade O fornecedor deve implantar um sistema abrangente de auditorias internas da qualidade, planejadas e documentadas, para verificar se as atividades da qualidade estão em conformidade com a forma planejada e para determinar a eficácia do sistema da qualidade.

As auditorias devem ser programadas com base na situação atual e importância da atividade. As auditorias e as ações de acompanhamento devem ser executadas conforme os procedimentos documentados.

Os resultados das auditorias devem ser documentados e levados ao conhecimento do pessoal que tenha responsabilidade pela área auditada. O pessoal responsável pela administração da área deve tomar, em tempo hábil, ações corretivas referentes às deficiências encontradas pela auditoria.

[NBR 19001:1990, 4.17].

5.2 Análise crítica de contrato 5.2.1 Generalidades

O fornecedor deve estabelecer e manter procedimentos para análise crítica de contrato e para a coordenação destas atividades.

Cada contrato deve ser analisado criticamente pelo fornecedor para assegurar que: a) o objetivo do contrato e os requisitos sejam definidos e documentados; b) possíveis contingências ou riscos sejam identificados; c) as informações reservadas sejam protegidas adequadamente; d) quaisquer requisitos diferentes daqueles da proposta sejam resolvidos;

Ver NBR ISO 10011-1.

4.4 Ação corretiva

e) o fornecedor tenha capacitação para atender aos requisitos contratuais;

O fornecedor deve estabelecer, documentar e manter procedimentos para:

f) a responsabilidade do fornecedor quanto ao trabalho subcontratado seja definida;

a) investigar a causa de produto não-conforme e a ação corretiva necessária para prevenir repetição; b) analisar todos os processos, operações de trabalho, concessões, registros da qualidade, relatórios de assistência técnica e reclamações de cliente para detectar e eliminar causas potenciais de produto não-conforme; c) iniciar ações preventivas para tratar dos problemas a nível correspondente aos riscos encontrados; d) aplicar controles que assegurem que ações corretivas são tomadas e que, as mesmas são eficazes; e) implementar e registrar alterações nos procedimentos resultantes de ação corretiva.

[NBR 19001:1990, 4.14]

5 Sistema da qualidade - Atividades do ciclo de vida

g) a terminologia seja aceita por ambas as partes; h) o comprador tenha capacitação para atender às obrigações contratuais.

Devem ser mantidos registros de tais análises críticas de contrato.

5.2.2 Itens de contrato relativos à qualidade

Os itens a seguir, entre outros, são freqüentemente considerados pertinentes ao contrato: a) critérios de aceitação; b) tratamento das alterações nos requisitos do comprador durante o desenvolvimento; c) tratamento de problemas detectados após a aceitação, incluindo reivindicações relacionadas à qualidade e reclamações do comprador;

5.1 Generalidades

d) atividades realizadas pelo comprador, especialmente no que se refere à especificação dos requisitos, instalação e aceitação;

Um projeto de desenvolvimento de “software” deve ser organizado de acordo com um modelo de ciclo de vida.

e) recursos, ferramentas e itens de “software” a serem fornecidos pelo comprador;

Cópia não autorizada

NBR ISO 9000-3/1993

f) normas e procedimentos a serem utilizados; g) requisitos relativos a cópia (ver item 5.9).

5.3 Especificação dos requisitos do comprador

5

estrutura da equipe, as responsabilidades, o uso de subcontratados e os recursos materiais a serem empregados; c) fases do desenvolvimento (conforme definidas no item 5.4.2.1);

5.3.1 Generalidades

A fim de continuar com o desenvolvimento do “software”, o fornecedor deve ter um conjunto completo, e sem ambigüidades, dos requisitos funcionais. Além disso, os requisitos devem incluir todos os aspectos necessários à satisfação das necessidades do comprador, aspectos estes como desempenho, segurança contra riscos, privacidade e confiabilidade. Tais requisitos devem ser estabelecidos de maneira precisa, o suficiente para permitir a validação durante a aceitação do produto.

A especificação dos requisitos do comprador deve registrar estes requisitos. Em alguns casos, esta especificação é fornecida pelo comprador. Caso contrário, o fornecedor deve desenvolver estes requisitos em estreita cooperação com o comprador e obter dele a aprovação, antes de passar ao estágio de desenvolvimento. A especificação dos requisitos do comprador deve estar sujeita ao controle de documentação e à gestão de configuração, como parte da documentação de desenvolvimento.

d) programação do projeto, identificando as tarefas a serem realizadas, os recursos e o tempo necessários para cada uma delas, e quaisquer inter-relações das tarefas; e) identificação de planos correlatos, tais como: - plano da qualidade; - plano de gestão de configuração; - plano de integração; - plano de ensaio.

O plano de desenvolvimento deve ser atualizado à medida que o desenvolvimento progredir e cada fase deve ser definida conforme 5.4.2.1, antes de as atividades daquela fase iniciarem-se. Estas devem ser analisadas criticamente e aprovadas antes da execução.

5.4.2 Plano de desenvolvimento

Todas as interfaces entre o produto de “software” e ou-tros produtos de “software” ou de “hardware” devem ser plenamente especificadas, diretamente ou por meio de referência, na especificação dos requisitos do comprador.

5.3.2 Cooperação mútua Durante o desenvolvimento da especificação dos requisitos do comprador, recomenda-se dar atenção às seguintes questões:

5.4.2.1 Fase

O plano de desenvolvimento deve definir um processo ou metodologia disciplinada, para transformar a especificação dos requisitos do comprador em um produto de “software”. Este fato pode envolver a divisão do trabalho em fases, e a identificação dos seguintes pontos: a) fases de desenvolvimento a serem realizadas;

a) designação de pessoas (de ambas as partes) responsáveis pelo estabelecimento da especificação dos requisitos do comprador;

b) entradas requeridas para cada fase;

b) métodos para se obter acordo quanto aos requisitos e aprovação das alterações;

d) procedimentos de verificação a serem executados em cada fase;

c) esforços para evitar mal-entendidos, tais como: definições de termos, explicação de fundamentos dos requisitos;

e) análise dos problemas potenciais associados às fases de desenvolvimento e ao atendimento dos requisitos especificados.

d) registro e análise crítica dos resultados de discussões por ambas as partes.

5.4 Planejamento do desenvolvimento 5.4.1 Generalidades

O plano de desenvolvimento deve abranger os seguintes pontos: a) definição do projeto, incluindo uma declaração de seus objetivos e referências a projetos relacionados, do comprador ou do fornecedor; b) organização dos recursos do projeto, incluindo a

c) saídas requeridas para cada fase;

5.4.2.2 Gestão

O plano de desenvolvimento deve definir como o projeto deve ser gerenciado, incluindo a identificação de: a) programação de desenvolvimento, implementação e entregas; b) controle da execução; c) responsabilidades organizacionais, recursos e atribuição de tarefas d) interfaces organizacionais e técnicas entre os diferentes grupos.

Cópia não autorizada

6

NBR ISO 9000-3/1993

5.4.2.3 Métodos e ferramentas de desenvolvimento

O plano de desenvolvimento deve identificar métodos para assegurar que todas as atividades sejam realizadas corretamente, podendo incluir: a) regras, práticas e convenções para o desenvolvimento; b) ferramentas e técnicas para o desenvolvimento; c) gestão de configuração.

Os resultados da verificação, e quaisquer ações suplementares requeridas para assegurar que os requisitos especificados foram atendidos, devem ser registrados e verificados quando da conclusão destas ações. Apenas saídas de desenvolvimento verificadas devem ser submetidas à gerência de configuração e aceitas para uso subseqüente.

5.5 Planejamento da qualidade 5.5.1 Generalidades

5.4.3 Controle da execução

O fornecedor deve preparar um plano da qualidade como parte do planejamento de desenvolvimento.

As análises críticas da execução física devem ser planejadas, executadas e documentadas, a fim de assegurar que questões importantes relativas aos recursos sejam resolvidas, além de assegurar a execução efetiva dos planos de desenvolvimento.

O plano da qualidade deve ser atualizado, ao longo da execução do desenvolvimento, e os itens pertinentes a cada fase devem estar totalmente definidos ao ser iniciada a fase.

5.4.4 Entrada das fases de desenvolvimento

A entrada requerida para cada fase de desenvolvimento deve ser definida e documentada. Cada requisito deve ser definido de tal modo que seu atendimento possa ser verificado. Requisitos incompletos, ambíguos ou conflitantes devem ser esclarecidos junto aos responsáveis pela definição destes.

O plano da qualidade deve ser analisado crítica e formalmente e acordado por todas as organizações envolvidas em sua implementação.

O documento que descreve o plano da qualidade (ver 5.5.2) pode ser um documento independente (denominado plano da qualidade) ou parte de outro documento, ou, ainda, ser composto de vários documentos, incluindo o plano de desenvolvimento.

5.4.5 Saída das fases de desenvolvimento 5.5.2 Conteúdo do plano da qualidade

A saída requerida de cada fase de desenvolvimento deve ser definida e documentada. A saída de cada fase de desenvolvimento deve ser verificada, e ainda: a) atender aos requisitos pertinentes; b) conter ou fazer referência a critérios de aceitação para que se passe às fases subseqüentes; c) atender às práticas de desenvolvimento e convenções adequadas, quer estas tenham ou não sido estipuladas nas informações de entrada; d) identificar as características do produto que são de importância crucial para seu funcionamento seguro e adequado; e) atender aos requisitos regulamentares aplicáveis.

5.4.6 Verificação de cada fase

O fornecedor deve elaborar um plano para verificação de todas as saídas ao final de cada fase de desenvolvimento.

O plano da qualidade deve especificar ou fazer referência aos seguintes itens: a) objetivos da qualidade, expressos em termos mensuráveis sempre que possível; b) critérios de entrada e de saída definidos para cada fase de desenvolvimento; c) identificação de tipos de ensaios e de atividades de verificação e de validação a serem realizadas; d) planejamento detalhado de atividades de ensaio, de verificação e de validação a serem realizadas, incluindo a programação, os recursos e as autoridades encarregadas da aprovação; e) responsabilidades específicas para atividades da qualidade, tais como: - análises críticas e ensaios; - gestão de configuração e controle de alteração;

A verificação do desenvolvimento deve estabelecer que as saídas de cada fase atendam aos requisitos de entrada correspondentes, mediante a adoção de medidas de controle de desenvolvimento, tais como: a) análises críticas do desenvolvimento em pontos apropriados das fases deste; b) comparação do novo projeto com um projeto semelhante já comprovado, caso haja algum disponível; c) realização de ensaios e demonstrações.

- controle de defeitos e ação corretiva.

5.6 Projeto e implementação 5.6.1 Generalidades

As atividades de projeto e implementação são aquelas que transformam as especificações dos requisitos do comprador em um produto de “software”. Devido à complexidade dos produtos de “software”, é imperativo que tais atividades sejam realizadas de maneira disciplinada, a fim de produzir um produto de acordo com a espe-

Cópia não autorizada

NBR ISO 9000-3/1993

7

cificação, e não depender das atividades de ensaio e de validação para assegurar a qualidade.

ware” completo. Há várias abordagens diferentes para os ensaios e a integração.

NOTA - A quantidade de informações a serem fornecidas para o comprador deve ser acordada mutuamente pelas partes, uma vez que os processos de projeto e implementação são freqüentemente de propriedade do fornecedor.

Em alguns casos, a validação, os ensaios de campo e os ensaios de aceitação podem ser uma mesma atividade.

5.6.2 Projeto

Além dos requisitos aplicáveis a todas as fases de desenvolvimento, os aspectos a seguir, inerentes às atividades de projeto, devem ser levados em consideração. a) Identificação das considerações de projeto: além das especificações de entrada e saída, devem ser examinados aspectos, tais como, as regras de projeto e as definições de interfaces internas. b) Metodologia de projeto: deve ser usada uma metodologia sistemática de projeto, apropriada para o tipo de produto de “software” em desenvolvimento. c) Uso de experiências anteriores de projeto: utilizando lições aprendidas a partir de experiências anteriores de projeto, o fornecedor deve evitar a repetição de problemas idênticos ou semelhantes. d) Processos subseqüentes: o produto deve ser projetado de modo a facilitar os ensaios, manutenção e uso.

O documento que descreve o plano de ensaio pode ser um documento independente, parte de outro documento ou composto de vários documentos.

5.7.2 Planejamento de ensaios

O fornecedor deve estabelecer e analisar criticamente os planos de ensaios, especificações e procedimentos, antes de iniciar as atividades de ensaio. Os seguintes pontos devem ser considerados: a) planos para itens de “software”, integração, ensaio de sistema e ensaio de aceitação; b) casos e dados de ensaios e resultados esperados; c) tipos de ensaios a serem realizados, como, por exemplo: ensaios funcionais, ensaios de fronteiras, ensaios de desempenho e ensaios de utilização; d) ambiente, ferramentas e “software” de ensaio; e) critérios a partir dos quais a conclusão dos ensaios deve ser julgada;

5.6.3 Implementação

f) documentação do usuário;

Além dos requisitos aplicáveis a todas as atividades de desenvolvimento, os aspectos a seguir devem ser considerados em cada atividade de implementação.

g) pessoal requerido e requisitos de seu treinamento.

5.7.3 Ensaios

a) Regras: regras, tais como, de programação, de linguagens de programação, de convenções consistentes de nomenclatura, de codificação, bem como de comentários adequados, devem ser especificadas e observadas. b) Metodologias de implementação: o fornecedor deve usar métodos e ferramentas de implementação apropriados para atender aos requisitos do comprador.

5.6.4 Análises críticas

O fornecedor deve realizar análises críticas, a fim de assegurar que os requisitos são atendidos e que os métodos descritos anteriormente são aplicados de forma correta. O processo de projeto ou de implementação não deve prosseguir até que as conseqüências de todas as deficiências conhecidas sejam esclarecidas satisfatoriamente, ou até que o risco de prosseguir de outro modo seja conhecido.

Registros de tais análises críticas devem ser mantidos.

5.7 Ensaios e validação 5.7.1 Generalidades

Ensaios, em vários níveis, podem ser requeridos desde um item individual de “software” até o produto de “soft-

Atenção especial deve ser dada aos seguintes aspectos dos ensaios: a) os resultados dos ensaios devem ser registrados conforme definido na especificação pertinente; b) quaisquer problemas encontrados e seus possíveis impactos sobre quaisquer partes do “software” devem ser registrados, e os responsáveis notificados, para que eles possam ser seguidos até serem solucionados; c) as áreas atingidas por quaisquer alterações devem ser identificadas e ensaiadas novamente; d) a adequação e a pertinência dos ensaios devem ser avaliadas; e) a configuração de “hardware” e de “software” de-ve ser considerada e documentada.

5.7.4 Validação

Antes de liberar o produto para entrega e aceitação do comprador, o fornecedor deve validar sua operação como um produto completo, quando possível, sob condições semelhantes às do ambiente de aplicação, conforme especificado no contrato.

Cópia não autorizada

8

NBR ISO 9000-3/1993

5.7.5 Ensaios de campo

5.9.2 Entrega

Quando forem requeridos ensaios sob condições de campo, os seguintes aspectos devem ser considerados:

Prescrições devem ser feitas para verificar a correção e a completeza das cópias do produto de “software” entregues.

a) as características a serem ensaiadas no ambiente de campo; b) as responsabilidades específicas do fornecedor e do comprador para realizar e avaliar o ensaio; c) a restauração do ambiente do usuário (após o ensaio).

5.8 Aceitação 5.8.1 Generalidades

Quando o fornecedor está pronto para entregar o produto validado, o comprador deve julgar se o produto é aceitável ou não, conforme os critérios previamente acordados e o especificado no contrato.

5.9.3 Instalação

As funções, responsabilidades e obrigações do fornecedor e do comprador devem ser claramente estabelecidas, levando em conta: a) a programação, incluindo horas de trabalho fora do horário normal e nos fins de semana; b) o acesso às instalações do comprador (crachás de segurança, senhas, acompanhantes); c) a disponibilidade de pessoal capacitado; d) a disponibilidade e acesso aos sistemas e equipamentos do comprador;

O método para tratar dos problemas detectados, durante o procedimento de aceitação e a sua rejeição, deve ser documentado e acordado entre o comprador e o fornecedor.

e) a necessidade de validação como parte de cada instalação deve ser determinada em contrato;

5.8.2 Planejamento dos ensaios de aceitação

f) um procedimento formal para aprovação de cada instalação após sua conclusão.

Antes de realizar os procedimentos de aceitação, o fornecedor deve auxiliar o comprador a identificar os seguintes pontos: a) cronograma; b) procedimentos para avaliação; c) ambientes e recursos de “software”/”hardware”; d) critérios de aceitação.

5.10 Manutenção 5.10.1 Generalidades

A manutenção do produto de “software” deve ser estipulada no contrato, após a entrega e a instalação inicial, quando requerida pelo comprador. O fornecedor deve estabelecer e manter procedimentos para realizar atividades de manutenção e verificar se estas atividades atendem aos requisitos especificados para a manutenção.

5.9 Cópia, entrega e instalação 5.9.1 Cópia

A cópia é uma etapa que deve ser conduzida antes da entrega. Ao providenciar-se a cópia, deve-se considerar:

As atividades de manutenção para produtos de “software” são tipicamente classificadas em: a) resolução de problemas; b) modificação de interface;

a) o número de cópias de cada item de “software” a ser entregue; b) o meio físico de fornecimento para cada item de “software”, incluindo formato e versão, em forma inteligível; c) a estipulação da documentação requerida, tais como manuais e guias de usuário; d) definição e acordo quanto aos direitos autorais e licenças; e) custódia de cópias-mestre e de segurança, quando aplicável, incluindo planos de recuperação, em caso de desastres;

c) expansão funcional ou aprimoramento do desempenho.

Os itens nos quais a manutenção deve ser realizada e o período de tempo, durante o qual ela deve ser efetuada, devem ser especificados no contrato. A seguir são apresentados exemplos de tais itens: a) programa(s); b) dados e suas estruturas; c) especificações; d) documentos para o comprador e/ou usuário;

f) o período de obrigação do fornecedor para o suprimento de cópias.

e) documentos para o uso do fornecedor.

NBR ISO 9000-3/1993

Cópia não autorizada

5.10.2 Plano de manutenção

Todas as atividades de manutenção devem ser realizadas e administradas de acordo com um plano de manutenção previamente definido e acordado entre o fornecedor e o comprador. O plano deve incluir:

9

para a apresentação de relatórios de manutenção devem ser estabelecidas e acordadas entre o fornecedor e o comprador.

Os registros de manutenção devem incluir, para cada item de “software” em que se realiza a manutenção, os seguintes tópicos:

a) o objetivo da manutenção; b) a identificação da situação inicial do produto;

a) lista de solicitações de assistência ou de relatórios de problemas que tiverem sido recebidos, e a situação atual de cada um deles;

c) a(s) organização(ões) de suporte; d) as atividades de manutenção;

b) organização responsável pelo atendimento às requisições para assistência ou implementação das ações corretivas adequadas;

e) os registros e os relatórios de manutenção.

5.10.3 Identificação da situação inicial do produto

A situação inicial do produto em que será realizada a manutenção deve ser definida, documentada e acordada entre o fornecedor e o comprador.

c) prioridades que foram atribuídas às ações corretivas; d) resultados das ações corretivas; e) dados estatísticos sobre a ocorrência de falhas e atividades de manutenção.

5.10.4 Organização de suporte

Pode ser necessário estabelecer uma organização, com representantes do fornecedor e do comprador, para dar suporte às atividades de manutenção. Como as atividades da etapa de manutenção não podem ser sempre realizadas de acordo com uma programação, esta organização deve ser bastante flexível para lidar com a ocorrência de problemas inesperados. Também pode ser necessário identificar instalações e recursos a serem usados para as atividades de manutenção.

5.10.5 Tipos de atividades de manutenção

Todas as alterações no “software” (devido à resolução de problemas, modificações de interface, expansão funcional ou aprimoramento do desempenho), realizadas durante a manutenção, devem ser feitas, tanto quanto possível, de acordo com os mesmos procedimentos usados para o desenvolvimento do produto de “software”.

Todas estas alterações devem também ser documentadas, de acordo com os procedimentos para controle de documentos e gestão de configuração: a) Resolução de problemas: envolve a detecção, a análise e a correção de não-conformidades de “software” que possam causar problemas operacionais. Soluções temporárias podem ser usadas para minimizar o tempo fora de operação, efetuando-se, posteriormente, as modificações definitivas. b) Modificações de interface: podem ser requeridas, quando acréscimos ou alterações são feitos no sistema de “hardware”, ou nos componentes, controlados pelo “software”. c) Expansão funcional ou aprimoramento do desempenho pode ser requerido pelo comprador durante a etapa de manutenção.

O registro das atividades de manutenção pode ser utilizado para avaliação e aprimoramento do produto de “software” e para melhoria do próprio sistema da qualidade.

5.10.7 Procedimentos de liberação

O fornecedor e o comprador devem entrar em acordo e documentar os procedimentos para a incorporação de alterações em um produto de “software”, resultantes da necessidade de manter o desempenho.

Tais procedimentos devem incluir: a) regras básicas para determinar onde as correções (“patches”) localizadas podem ser incorporadas, ou quando é necessária a liberação de uma cópia completa atualizada do produto de “software”; b) descrições dos tipos (ou classes) de liberações, dependendo de sua freqüência e/ou do impacto sobre as operações e a capacidade do comprador de implementar alterações a qualquer momento; c) métodos pelos quais o comprador deve ser alertado sobre alterações atuais ou planejadas para o futuro; d) métodos para confirmar que as alterações implementadas não introduzem outros problemas; e) requisitos para os registros, indicando quais alterações foram implementadas e em que locais, para os vários produtos e instalações.

6 Sistema da qualidade - Atividades de suporte (não dependentes de fase) 6.1 Gestão de configuração

5.10.6 Registros e relatórios de manutenção

6.1.1 Generalidades

Todas as atividades de manutenção devem ser registradas em formatos prédefinidos, e arquivadas. As regras

A gestão de configuração fornece um mecanismo para a identificação, controle e acompanhamento das versões

10

Cópia não autorizada

NBR ISO 9000-3/1993

de cada item de “software”. Em muitos casos, versões anteriores, ainda em uso, também têm que receber manutenção e ser controladas.

O sistema de gestão de configuração deve:

b) todas as ferramentas de desenvolvimento que afetam as especificações funcionais e técnicas; c) todas as interfaces com outros itens de “software” e com o “hardware”;

a) identificar, de forma única, as versões de cada item de “software”;

d) todos os documentos e arquivos de computador relacionados com o item de “software”.

b) identificar as versões de cada item de “software” que, juntas, constituem uma versão específica de um produto completo;

A identificação de um item de “software” deve ser feita de tal modo que a relação entre o item e os requisitos do contrato possa ser demonstrada.

c) identificar a situação de elaboração de produtos de “software”, em desenvolvimento ou já entregues e instalados;

Para produtos já liberados, deve haver procedimentos para facilitar a rastreabilidade do item ou produto de “software”.

d) controlar a atualização simultânea de um determinado item de “software” por mais de uma pessoa;

6.1.3.2 Controle de alterações

e) fornecer coordenação para a atualização de produtos múltiplos, em um ou mais locais, conforme requerido; f) identificar e seguir, do início até a liberação, todas as ações e alterações resultantes de uma solicitação de alteração.

6.1.2 Plano de gestão de configuração

O fornecedor deve desenvolver e implementar um plano de gestão de configuração que inclua: a) organizações envolvidas na gestão de configuração e as responsabilidades atribuídas a cada uma delas; b) atividades de gestão de configuração a serem realizadas; c) ferramentas, técnicas e metodologias de gestão de configuração a serem usadas;

O fornecedor deve estabelecer e manter procedimentos para identificar, documentar, analisar criticamente e autorizar quaisquer alterações em itens de “software” sob gestão de configuração. Todas as alterações em itens de “software” devem ser realizadas de acordo com estes procedimentos.

Antes da aceitação de uma alteração, sua validade deve ser confirmada, e os efeitos causados sobre outros itens devem ser identificados e examinados.

Devem ser fornecidos os métodos para informar aos envolvidos quanto às alterações e para demonstrar a rastreabilidade entre as alterações e as partes modificadas dos itens de “software”.

6.1.3.3 Relatório de situação da configuração

O fornecedor deve estabelecer e manter procedimentos para registrar, administrar e relatar a situação de itens de “software”, de requisições de alteração e da implementação das alterações aprovadas.

6.2 Controle de documentos

d) o estágio ao qual os itens devem ser trazidos sob o controle de configuração.

6.1.3 Atividades de gestão de configuração 6.1.3.1 Identificação e rastreabilidade de configuração

O fornecedor deve estabelecer e manter procedimentos para identificar itens de “software” durante todas as fases, desde a especificação até o desenvolvimento, cópia e entrega.

6.2.1 Generalidades

O fornecedor deve estabelecer e manter procedimentos para controlar todos os documentos relacionados ao conteúdo desta Norma, abrangendo: a) a determinação dos documentos que devem estar sujeitos aos procedimentos de controle de documentos; b) a aprovação e a emissão de procedimentos;

Estes procedimentos podem também ser aplicados após a entrega do produto, quando requerido pelo contrato. Cada item de “software” individual deve possuir uma identificação única.

c) os procedimentos de alteração, incluindo a retirada e, quando apropriado, a liberação.

6.2.2 Tipos de documentos

Procedimentos devem ser aplicados para assegurar que os pontos a seguir possam ser identificados em cada versão de um item de “software”: a) as especificações funcionais e técnicas;

Os procedimentos de controle de documentos devem ser aplicados a documentos pertinentes, incluindo: a) procedimentos, descrevendo o sistema da qualidade a ser aplicado ao ciclo de vida do “software”;

NBR ISO 9000-3/1993

Cópia não autorizada

11

b) documentos de planejamento, descrevendo o planejamento e a execução de todas as atividades do fornecedor e suas interações com o comprador;

monstrar a obtenção da qualidade requerida e a efetiva operação do sistema da qualidade. Registros da qualidade pertinentes aos subfornecedores devem ser considerados como parte desses dados.

c) documentos de produto, descrevendo um determinado produto de “software”, que incluam:

Todos os registros da qualidade devem ser legíveis e identificáveis em relação ao produto envolvido. Os registros da qualidade devem ser armazenados e mantidos de tal forma que sejam prontamente recuperáveis em instalações que forneçam um ambiente adequado, para minimizar a deterioração ou danos e para prevenir perdas.

Os tempos de retenção dos registros da qualidade devem ser estabelecidos e registrados. Quando acordado em contrato, os registros da qualidade devem estar disponíveis para avaliação pelo comprador ou por seu representante durante um período preestabelecido.

- entradas da fase de desenvolvimento; - saídas da fase de desenvolvimento; - planos e resultados de verificação e validação; - documentação para o comprador e o usuário; - documentação de manutenção.

[NBR 19001:1990, 4.16] 6.2.3 Aprovação e emissão de documentos

6.4 Medição Todos os documentos devem ser analisados criticamente e aprovados por pessoal autorizado, antes de serem emitidos. Deve haver procedimentos para assegurar que: a) as emissões pertinentes dos documentos apropriados estejam disponíveis em locais adequados onde sejam realizadas operações essenciais para o funcionamento efetivo do sistema da qualidade; b) documentos obsoletos sejam prontamente removidos dos pontos apropriados de emissão ou uso.

Quando for feito uso de arquivos de computador, deve ser dada atenção especial aos procedimentos adequados de aprovação, acesso, distribuição e arquivamento.

6.2.4 Alterações em documentos

As alterações em documentos devem ser analizadas criticamente e aprovadas pelas mesmas funções/orgãos que realizaram a análise crítica e aprovação dos originais, salvo prescrição em contrário. Os orgãos designados devem ter acesso às informações básicas pertinentes, para subsidiar sua análise crítica e aprovação.

Onde praticável, a natureza das alterações deve ser identificada no documento ou em anexo apropriado.

Um índice geral, ou procedimento equivalente de controle de documentos deve ser elaborado para identificar a revisão atual dos documentos, a fim de evitar a utilização de documentos não aplicáveis.

Os documentos devem ser reemitidos após incorporação de um número razoável de alterações.

[NBR 19001:1990, 4.5.2] 6.3 Registros da qualidade O fornecedor deve estabelecer e manter procedimentos para identificar, coletar, indexar, arquivar, armazenar, manter e dispor os registros da qualidade.

Os registros da qualidade devem ser mantidos para de-

6.4.1 Medição de produtos

As medidas devem ser relatadas e utilizadas para gerenciar o processo de desenvolvimento e entrega, e devem ser pertinentes ao produto de “software” específico.

Atualmente não há indicadores da qualidade de “software” aceitos universalmente. No entanto, no mínimo, algum tipo de indicador deve ser usado para expressar falhas e/ou defeitos de campo relatados, do ponto de vista do cliente. O indicador selecionado deve ser descrito de tal modo que os resultados possam ser comparáveis.

O fornecedor de produtos de “software” deve coletar e agir de acordo com indicadores quantitativos da qualidade destes produtos. Estes indicadores quantitativos devem ser usados para os seguintes fins: a) coletar dados e relatar medidas em uma base regular; b) identificar o nível atual do desempenho em cada indicador; c) tomar ações remediadoras, caso os níveis dos indicadores se deteriorem ou ultrapassem as metas-alvo estabelecidas; d) estabelecer metas específicas de aprimoramento expressas em termos dos indicadores.

6.4.2 Medição de processos

O fornecedor deve dispor de indicadores quantitativos da qualidade do processo de desenvolvimento e entrega, os quais devem refletir: a) o quanto o processo de desenvolvimento está sendo efetuado em termos de atendimento a ponto significante do Projeto e aos objetivos da qualidade ao longo do processo, conforme programado; b) com que eficácia o processo de desenvolvimento está reduzindo a probabilidade de que sejam introduzidos defeitos, ou que quaisquer defeitos introduzidos não sejam detectados.

Cópia não autorizada

12

NBR ISO 9000-3/1993

Assim como ocorre em relação a indicadores de produtos, o importante é que os níveis sejam conhecidos e utilizados para o controle de processo e para o aprimoramento, e não quais indicadores específicos são utilizados. A escolha de indicadores deve se adequar ao processo usado e, se possível, causar um impacto direto sobre a qualidade do “software” entregue. Indicadores diferentes podem ser apropriados para produtos de “software” diferentes produzidos pelo mesmo fornecedor.

6.5 Regras, práticas e convenções O fornecedor deve suprir regras, práticas e convenções de modo a tornar efetivo o sistema da qualidade especificado nesta NBR ISO 9000-3. O fornecedor deve analisar criticamente estas regras, práticas e convenções e revisá-las, quando requerido.

6.7.3 Validação de produtos adquiridos

O fornecedor é responsável pela validação do trabalho subcontratado, o que exige que ele conduza o projeto e outras análises críticas de modo coerente com seu próprio sistema da qualidade e, neste caso, tais requisitos devem ser incluídos no subcontrato. Quaisquer requisitos de ensaios de aceitação, pelo fornecedor, do trabalho subcontratado devem ser incluídos da mesma maneira.

Quando especificado no contrato, o comprador, ou seu representante, deve ter o direito de verificar, na fonte ou no recebimento, se o produto adquirido está em conformidade com os requisitos especificados. A validação pelo comprador não isenta o fornecedor da responsabilidade de prover produtos aceitáveis, nem impede as rejeições subseqüentes.

6.6 Ferramentas e técnicas O fornecedor deve utilizar ferramentas, recursos e técnicas para tornar efetivas as diretrizes do sistema da qualidade desta Norma. Estas ferramentas, recursos e técnicas podem ser eficazes para fins de gerenciamento, assim como para o desenvolvimento de produtos. O fornecedor deve aprimorar estas ferramentas e técnicas, quando requerido.

6.7 Aquisição 6.7.1 Generalidades

O fornecedor deve assegurar que um produto ou serviço adquirido está de acordo com os requisitos especificados.

Quando o comprador, ou seu representante, decide efetuar a validação nas instalações do subfornecedor, tal validação não deve ser utilizada pelo fornecedor como evidência de efetivo controle da qualidade pelo subfornecedor.

6.8 Produto de “software” incluído A inclusão ou uso de produtos de “software” fornecidos pelo comprador, ou por terceira parte, pode ser requerido ao fornecedor. O fornecedor deve estabelecer e manter procedimentos para validação, armazenamento, proteção e manutenção de tais produtos. Deve-se considerar o suporte de cada produto de “software” em qualquer acordo de manutenção relacionado ao produto a ser entregue.

Os documentos de aquisição devem conter dados descrevendo claramente o produto ou serviço encomendado. O fornecedor deve analisar criticamente e aprovar os documentos de aquisição, quanto à adequação dos requisitos especificados antes da liberação.

Produtos fornecidos pelo comprador que sejam inadequados para o uso devem ser registrados e relatados ao comprador. A validação pelo fornecedor não isenta o comprador da responsabilidade de prover produtos aceitáveis.

NOTA - Um produto adquirido pode ser um item de “software” e/ou de “hardware” destinado à inclusão no produto final requerido, ou uma ferramenta para auxiliar no desenvolvimento do produto requerido.

6.9 Treinamento

6.7.2 Avaliação de subfornecedores

O fornecedor deve selecionar subfornecedores, baseado na capacidade destes em atender aos requisitos de subfornecimento, incluindo requisitos da qualidade. O fornecedor deve estabelecer e manter registros de subfornecedores qualificados.

A seleção de subfornecedores, o tipo e a abrangência do controle exercido pelo fornecedor, devem depender do tipo do produto e, quando aplicável, de registros de capacidade e de desempenho previamente demonstrados pelos subfornecedores.

O fornecedor deve garantir que os controles do sistema da qualidade são eficazes.

[NBR 19001:1990, 4.6.2]

O fornecedor deve estabelecer e manter procedimentos para identificar as necessidades de treinamento, e providenciá-lo para todo o pessoal que executa atividades que influenciam a qualidade. O pessoal que executa tarefas específicas designadas deve ser qualificado com base em educação adequada, treinamento e/ou experiência, conforme requerido.

Os assuntos a serem abordados devem ser determinados, considerando-se as ferramentas, técnicas, metodologias e recursos de computador específicos a serem usados no desenvolvimento e gerenciamento do produto de “software”.

Também pode ser necessário incluir treinamento de habilidades e conhecimento do campo específico com o qual o “software” deve lidar.

Registros apropriados do treinamento/experiência devem ser mantidos. /ANEXOS

Cópia não autorizada

NBR ISO 9000-3/1993

13

Anexo A (Informativo)

Referência cruzada entre a NBR ISO 9000-3 e NBR 19001:1990 (ISO 9001) Item desta NBR ISO 9000-3

Item na NBR 19001

4.1

Responsabilidade da administração

4.1

4.2

Sistema da qualidade

4.2

4.3

Auditorias internas do sistema da qualidade

4.17

4.4

Ação corretiva

4.14

5.2

Análise crítica do contrato

4.3

5.3

Especificação dos requisitos do comprador

4.3, 4.4

5.4

Planejamento do desenvolvimento

4.4

5.5

Planejamento da qualidade

4.2, 4.4

5.6

Projeto e implementação

4.4, 4.9, 4.13

5.7

Ensaios e validação

4.4, 4.10, 4.11, 4.13

5.8

Aceitação

4.10, 4.15

5.9

Cópia, entrega e instalação

4.10, 4.13, 4.15

5.10 Manutenção

4.13, 4.19

6.1

Gestão de configuração

4.4, 4.5, 4.8, 4.12, 4.13

6.2

Controle de documentos

4.5

6.3

Registros da qualidade

4.16

6.4

Medição

4.20

6.5

Regras, práticas e convenções

4.9, 4.11

6.6

Ferramentas e técnicas

4.9, 4.11

6.7

Aquisição

4.6

6.8

Produto de “software” incluído

4.7

6.9

Treinamento

4.18

/ANEXO B

Cópia não autorizada

14

NBR ISO 9000-3/1993

Anexo B (Informativo)

Referência cruzada entre a NBR 19001:1990 e NBR ISO 9000-3 Item na NBR 19001

Item desta NBR ISO 9000-3

4

Requisitos para o sistema da qualidade

4, 5, 6

4.1

Responsabilidade da administração

4.1

4.2

Sistema da qualidade

4.2, 5.5

4.3

Análise crítica de contrato

5.2, 5.3

4.4

Controle de projeto

5.3, 5.4, 5.5, 5.6, 5.7, 6.1

4.5

Controle de documentos

6.1, 6.2

4.6

Aquisição

6.7

4.7

Produto fornecido pelo comprador

6.8

4.8

Identificação e rastreabilidade de produto

6.1

4.9

Controle de processos

5.6, 6.5, 6.6

4.10 Inspeção e ensaios

5.7, 5.8, 5.9

4.11 Equipamento de inspeção, medição e ensaios

5.7, 6.5, 6.6

4.12 Situação da inspeção e ensaios

6.1

4.13 Controle de produtos não-conformes

5.6, 5.7, 5.9, 6.1

4.14 Ação corretiva

4.4

4.15 Manuseio, armazenamento, embalagem e expedição

5.8, 5.9

4.16 Registros da qualidade

6.3

4.17 Auditorias internas da qualidade

4.3

4.18 Treinamento

6.9

4.19 Assistência técnica

5.10

4.20 Técnicas estatísticas

6.4