SumárioIntrodução1 Objetivo2 Referências normativas3 Definições4 Sistema da qualidade - Estrutura5 Sistema da qualidade - Atividades do ciclo de vida6 Sistema da qualidade - Atividades de apoio (nãodependentes de fase)AnexosA - Referência cruzada entre NBR ISO 9000-3 e

NBR 19001B - Referência cruzada entre as NBR 19001 e

NBR ISO 9000-3

Introdução

Com o progresso da tecnologia da informação, a quan-tidade de “software” vem crescendo e tornando essen-cial a gestão da qualidade de produtos de “software”.Um dos meios de estabelecer um sistema de gestão daqualidade é fornecer orientação para a garantia da quali-dade do “software”.

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

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

Copyright © 1990,ABNT–Associação Brasileirade Normas TécnicasPrinted in Brazil/Impresso no BrasilTodos os direitos reservados

Sede:Rio de JaneiroAv. Treze de Maio, 13 - 28º andarCEP 20003 - Caixa Postal 1680Rio de Janeiro - RJTel.: PABX (021) 210 -3122Telex: (021) 34333 ABNT - BREndereço Telegráfico:NORMATÉCNICA

ABNT-AssociaçãoBrasileira deNormas Técnicas

Normas de gestão da qualidade egarantia da qualidade

NBR ISO 9000-3

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

14 páginas

CB-25 - Comitê Brasileiro da QualidadeCE-25:000.02 - Comissão de Estudo de Sistemas de QualidadeNBR ISO 9000-3 - Quality management and quality assurance standardsParte 3: Guidelines for the application of ISO 9001 to the development, supply andmaintenance of softwareDescriptors: Programming (computers) Quality assurance. Quality assuranceprogramme.

NOV 1993

Parte 3:

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

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

A natureza do desenvolvimento de “software” é tal,que algumas atividades estão relacionadas às fasesespecíficas do processo de desenvolvimento, en-quanto outras podem ser aplicadas ao longo de to-do o processo. Estas diretrizes foram assim estrutu-radas para refletir tais diferenças. Outrossim, estedocumento, no que se refere ao formato, não corres-ponde diretamente à norma NBR 19001, sendo, poressa razão, fornecidos índices de referência cruza-da (anexos A e B) para facilitar a consulta àquelanorma.

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

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

CDU: 658.56:681.3.06

2 NBR ISO 9000-3/1993

ceitos descritos podem ser de igual valor em outras si-tuações.

NOTAS

1 Ao longo desta NBR ISO 9000-3, quando não houver orien-taçõ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 nenhumadelas pretende ser exaustiva. São apresentadas a título deexemplo.

1 Objetivo

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

Destina-se a fornecer orientação quando um contratoentre duas partes exigir a demonstração da capacidadede um fornecedor em desenvolver, fornecer e manterprodutos de “software”.

Estas diretrizes destinam-se a descrever os controles emétodos sugeridos para a produção de “software” queatendam aos requisitos do comprador, evitando-se não-conformidades em todos os estágios, desde o desen-volvimento até a manutenção.

As diretrizes desta NBR ISO 9000-3 são aplicáveis emsituações contratuais para produtos de “software”, quan-do:

a) o contrato exigir, especificamente, esforço de pro-jeto, e os requisitos do produto forem indicadosprincipalmente em termos de desempenho, ouprecisarem ser estabelecidos;

b) a confiança no produto puder ser obtida atravésda demonstração adequada da capacidade dedesenvolvimento, fornecimento e manutenção deum determinado fornecedor.

2 Referências normativas

As normas relacionadas contêm disposições que, atra-vésde referências neste texto, constituem prescrições destaNBR ISO 9000-3. Na data da publicação destaNBR ISO 9000-3, as edições indicadas eram válidas.Como todas as normas estão sujeitas a revisões, as par-tes interessadas dos acordos baseados nestaNBR ISO 9000-3 são encorajadas a investigar a possibi-lidade de utilização de edições mais recentes das nor-mas indicadas a seguir. A ABNT mantem registros dasnormas válidas atualmente.

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

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

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

Modelo para garantia da qualidade em projetos/de-senvolvimento, produção, instalação e assistência téc-nica.

NBR ISO 10011-1:1993, Diretrizes para auditoria de sis-temas 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 eNBR ISO 8402, juntamente com as definições a seguir.

3.1 “software”: criação intelectual compreendendo osprogramas, procedimentos, regras e qualquer docu-mentação correlata à operação de um sistema de pro-cessamento de dados.

[ISO 2382-1: 1984, 01.04.04]

NOTA - O “software” não depende do meio no qual é regis-trado.

3.2 produto de “software”: Conjunto completo de pro-gramas de computador, procedimentos e documenta-çãocorrelata, assim como dados designados para en-trega aum usuário.

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

3.4 desenvolvimento: Todas as atividades a serem rea-lizadas 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 deciclo de vida específico, nem implica em um período de tempodurante o desenvolvimento de um produto de “software”.

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

3.7 Validação (para "software"): Processo de avaliaçãode "software" a fim de assegurar que este atende aos re-quisitos 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

A administração do fornecedor deve definir e documen-tarsua política e objetivos para a qualidade, e assumir ocompromisso com estes. O fornecedor deve assegurarque esta política é entendida, implementada e mantidaem todos os níveis da organização.

[NBR 19001:1990 4.1.1]

NBR ISO 9000-3/1993 3

4.1.1.2 Organização

4.1.1.2.1 Responsabilidade e autoridade

A responsabilidade, autoridade e interação de todo opessoal que administra, desempenha e verifica ativida-des que influem na qualidade devem ser definidas, par-ticularmente as do pessoal que necessita de autonomiaorganizacional e autoridade para:

a) iniciar ações para prevenir a ocorrência de não-conformidade em produto;

b) identificar e registrar quaisquer problemas dequalidade do produto;

c) iniciar, recomendar ou providenciar soluçõesatravés dos canais designados;

d) verificar a implementação das soluções;

e) controlar processamento posterior, entrega ou ins-talação de produto não-conforme, até que a de-ficiência ou condição insatisfatória tenha sidocorrigida.

[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 deverificação, prover recursos adequados e designar pessoaltreinado para as atividades de verificação.

As atividades de verificação devem incluir inspeção, ensaioe monitorização de processos e/ou produto de projeto,produção, instalação e de assistência técnica; análisescríticas de projeto e auditorias do sistema da qualidade,dos processos e/ou produto, devem ser realizadas porpessoal independente daquele que tem responsabilidadedireta 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 admi-nistração que, independentemente de outras responsa-bilidades, tenha autoridade e responsabilidade definidaspara assegurar que os requisitos da NBR 19001 sejamimplementados 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 requi-sitos da NBR 19001, deve ser analisado criticamente,em intervalos adequados, pela administração do forne-cedor, a fim de assegurar a sua contínua adequação e efi-cácia. Devem ser mantidos registros destas análises.

NOTA - As análises críticas incluem normalmente a avaliaçãodos resultados de auditorias internas do sistema da qualida-de, executadas pela administração do fornecedor ou, em seunome, pelo pessoal da administração com responsabilidadedireta pelo sistema.

[NBR 19001:1990, 4.1.3]

4.1.2 Responsabilidade da administração do comprador

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

O comprador deve designar um representante respon-sável para tratar de assuntos contratuais com o forne-cedor. Este representante deve ter autoridade, de acor-do com a necessidade, para tratar dos assuntos contra-tuais que incluem os seguintes itens, mas não se limi-tam 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 obser-va os acordos firmados com o fornecedor;

f) definir critérios e procedimentos de aceitação;

g) negociar com o comprador sobre itens de “soft-ware” fornecidos que foram considerados inade-quados para o uso.

4.1.3 Análises críticas conjuntas

Análises críticas conjuntas regulares, envolvendo o for-necedor e o comprador, devem ser programadas a fimde cobrir os aspectos a seguir, conforme apropriado:

a) conformidade do “software” com os requisitos es-pecificados 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 acor-dados e documentados.

4.2 Sistema da qualidade

4.2.1 Generalidades

O fornecedor deve estabelecer e manter um sistemada qualidade documentado. O sistema da qualidade de-ve ser um processo integrado por todo o ciclo de vida,assegurando assim que a qualidade seja perseguida aolongo do desenvolvimento do processo, em vez de ser ve-rificada ao final. A prevenção de problemas deve ser en-fatizada mais do que a correção após a ocorrência des-tes.

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

4.2.2 Documentação do sistema da qualidade

Todos os elementos, requisitos e prescrições do siste-ma da qualidade devem ser claramente documentadosde maneira sistemática e ordenada.

4 NBR ISO 9000-3/1993

4.2.3 Plano da qualidade

O fornecedor deve preparar e documentar um plano daqualidade, a fim de implementar atividades da qualida-de para cada desenvolvimento de “software”, basean-do-se no sistema da qualidade e assegurando que esteseja entendido e observado pelas organizações envolvi-das.

4.3 Auditorias internas do sistema da qualidade

Auditorias internas da qualidade

O fornecedor deve implantar um sistema abrangente deauditorias internas da qualidade, planejadas e documen-tadas, para verificar se as atividades da qualidade estãoem conformidade com a forma planejada e para deter-minar 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 asações de acompanhamento devem ser executadas con-forme os procedimentos documentados.

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

[NBR 19001:1990, 4.17].

Ver NBR ISO 10011-1.

4.4 Ação corretiva

O fornecedor deve estabelecer, documentar e manterprocedimentos para:

a) investigar a causa de produto não-conforme e aação corretiva necessária para prevenir repetição;

b) analisar todos os processos, operações de tra-balho, concessões, registros da qualidade, relató-rios de assistência técnica e reclamações de cli-ente para detectar e eliminar causas potenciaisde produto não-conforme;

c) iniciar ações preventivas para tratar dos proble-mas a nível correspondente aos riscos encontra-dos;

d) aplicar controles que assegurem que ações cor-retivas são tomadas e que, as mesmas são efica-zes;

e) implementar e registrar alterações nos procedi-mentos resultantes de ação corretiva.

[NBR 19001:1990, 4.14]

5 Sistema da qualidade - Atividades do ciclo devida

5.1 Generalidades

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

Atividades relacionadas à qualidade devem ser planeja-das e implementadas de acordo com a natureza do mo-delo de ciclo de vida utilizado.

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

5.2 Análise crítica de contrato

5.2.1 Generalidades

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

Cada contrato deve ser analisado criticamente pelo for-necedor para assegurar que:

a) o objetivo do contrato e os requisitos sejam de-finidos e documentados;

b) possíveis contingências ou riscos sejam identifi-cados;

c) as informações reservadas sejam protegidasadequadamente;

d) quaisquer requisitos diferentes daqueles da pro-posta sejam resolvidos;

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

f) a responsabilidade do fornecedor quanto ao tra-balho subcontratado seja definida;

g) a terminologia seja aceita por ambas as partes;

h) o comprador tenha capacitação para atender àsobrigações contratuais.

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

5.2.2 Itens de contrato relativos à qualidade

Os itens a seguir, entre outros, são freqüentementeconsiderados pertinentes ao contrato:

a) critérios de aceitação;

b) tratamento das alterações nos requisitos do com-prador durante o desenvolvimento;

c) tratamento de problemas detectados após aaceitação, incluindo reivindicações relacionadasà qualidade e reclamações do comprador;

d) atividades realizadas pelo comprador, especial-mente no que se refere à especificação dos re-quisitos, instalação e aceitação;

e) recursos, ferramentas e itens de “software” a se-rem fornecidos pelo comprador;

NBR ISO 9000-3/1993 5

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.3.1 Generalidades

A fim de continuar com o desenvolvimento do “software”,o fornecedor deve ter um conjunto completo, e sem am-bigüidades, dos requisitos funcionais. Além disso, os re-quisitos devem incluir todos os aspectos necessários àsatisfação das necessidades do comprador, aspectosestes como desempenho, segurança contra riscos, pri-vacidade e confiabilidade. Tais requisitos devem ser es-tabelecidos de maneira precisa, o suficiente para permi-tir a validação durante a aceitação do produto.

A especificação dos requisitos do comprador deve re-gistrar estes requisitos. Em alguns casos, esta especifi-cação é fornecida pelo comprador. Caso contrário, o for-necedor deve desenvolver estes requisitos em estreitacooperação com o comprador e obter dele a aprova-ção, antes de passar ao estágio de desenvolvimento. Aespecificação dos requisitos do comprador deve estarsujeita ao controle de documentação e à gestão de con-figuração, como parte da documentação de desenvolvi-mento.

Todas as interfaces entre o produto de “software” e ou-trosprodutos de “software” ou de “hardware” devem serplenamente especificadas, diretamente ou por meio dereferência, na especificação dos requisitos do comprador.

5.3.2 Cooperação mútua

Durante o desenvolvimento da especificação dos requisi-tos do comprador, recomenda-se dar atenção às se-guintes questões:

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

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

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

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

5.4 Planejamento do desenvolvimento

5.4.1 Generalidades

O plano de desenvolvimento deve abranger os seguin-tes pontos:

a) definição do projeto, incluindo uma declaração deseus objetivos e referências a projetos relaciona-dos, do comprador ou do fornecedor;

b) organização dos recursos do projeto, incluindo a

estrutura da equipe, as responsabilidades, o usode subcontratados e os recursos materiais a se-rem empregados;

c) fases do desenvolvimento (conforme definidasno item 5.4.2.1);

d) programação do projeto, identificando as tarefasa serem realizadas, os recursos e o tempo neces-sários para cada uma delas, e quaisquer inter-re-laçõ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 à me-dida que o desenvolvimento progredir e cada fase deveser definida conforme 5.4.2.1, antes de as atividades da-quela fase iniciarem-se. Estas devem ser analisadas cri-ticamente e aprovadas antes da execução.

5.4.2 Plano de desenvolvimento

5.4.2.1 Fase

O plano de desenvolvimento deve definir um processoou metodologia disciplinada, para transformar a especi-ficação dos requisitos do comprador em um produto de“software”. Este fato pode envolver a divisão do trabalhoem fases, e a identificação dos seguintes pontos:

a) fases de desenvolvimento a serem realizadas;

b) entradas requeridas para cada fase;

c) saídas requeridas para cada fase;

d) procedimentos de verificação a serem executa-dos em cada fase;

e) análise dos problemas potenciais associados àsfases de desenvolvimento e ao atendimento dosrequisitos especificados.

5.4.2.2 Gestão

O plano de desenvolvimento deve definir como o projetodeve 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 eatribuição de tarefas

d) interfaces organizacionais e técnicas entre os di-ferentes grupos.

6 NBR ISO 9000-3/1993

5.4.2.3 Métodos e ferramentas de desenvolvimento

O plano de desenvolvimento deve identificar métodos paraassegurar que todas as atividades sejam realiza-das corretamente, podendo incluir:

a) regras, práticas e convenções para o desenvolvi-mento;

b) ferramentas e técnicas para o desenvolvimento;

c) gestão de configuração.

5.4.3 Controle da execução

As análises críticas da execução física devem ser plane-jadas, executadas e documentadas, a fim de assegurarque questões importantes relativas aos recursos se-jam resolvidas, além de assegurar a execução efetivados planos de desenvolvimento.

5.4.4 Entrada das fases de desenvolvimento

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

5.4.5 Saída das fases de desenvolvimento

A saída requerida de cada fase de desenvolvimento de-ve ser definida e documentada. A saída de cada fase dedesenvolvimento deve ser verificada, e ainda:

a) atender aos requisitos pertinentes;

b) conter ou fazer referência a critérios de aceitaçãopara que se passe às fases subseqüentes;

c) atender às práticas de desenvolvimento e con-venções adequadas, quer estas tenham ou nãosido estipuladas nas informações de entrada;

d) identificar as características do produto que sãode importância crucial para seu funcionamentoseguro 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çãode todas as saídas ao final de cada fase de desenvolvi-mento.

A verificação do desenvolvimento deve estabelecer queas saídas de cada fase atendam aos requisitos de en-trada correspondentes, mediante a adoção de medidasde controle de desenvolvimento, tais como:

a) análises críticas do desenvolvimento em pontosapropriados das fases deste;

b) comparação do novo projeto com um projeto seme-lhante já comprovado, caso haja algum disponível;

c) realização de ensaios e demonstrações.

Os resultados da verificação, e quaisquer ações suple-mentares requeridas para assegurar que os requisitosespecificados foram atendidos, devem ser registrados everificados quando da conclusão destas ações. Apenassaídas de desenvolvimento verificadas devem ser sub-metidas à gerência de configuração e aceitas para usosubseqüente.

5.5 Planejamento da qualidade

5.5.1 Generalidades

O fornecedor deve preparar um plano da qualidade co-mo parte do planejamento de desenvolvimento.

O plano da qualidade deve ser atualizado, ao longo daexecução do desenvolvimento, e os itens pertinentes acada fase devem estar totalmente definidos ao ser ini-ciada a fase.

O plano da qualidade deve ser analisado crítica e for-malmente e acordado por todas as organizações envolvi-das em sua implementação.

O documento que descreve o plano da qualidade (ver5.5.2) pode ser um documento independente (denomi-nado plano da qualidade) ou parte de outro documento,ou, ainda, ser composto de vários documentos, incluindoo plano de desenvolvimento.

5.5.2 Conteúdo do plano da qualidade

O plano da qualidade deve especificar ou fazer referên-cia aos seguintes itens:

a) objetivos da qualidade, expressos em termos men-suráveis sempre que possível;

b) critérios de entrada e de saída definidos para ca-da fase de desenvolvimento;

c) identificação de tipos de ensaios e de atividadesde 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 auto-ridades encarregadas da aprovação;

e) responsabilidades específicas para atividades daqualidade, tais como:

- análises críticas e ensaios;

- gestão de configuração e controle de alteração;

- 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 aquelasque transformam as especificações dos requisitos docomprador em um produto de “software”. Devido à com-plexidade dos produtos de “software”, é imperativo que taisatividades sejam realizadas de maneira disciplinada,a fim de produzir um produto de acordo com a espe-

NBR ISO 9000-3/1993 7

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

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

5.6.2 Projeto

Além dos requisitos aplicáveis a todas as fases de de-senvolvimento, os aspectos a seguir, inerentes às ativi-dades 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, de-vem ser examinados aspectos, tais como, as re-gras de projeto e as definições de interfaces inter-nas.

b) Metodologia de projeto: deve ser usada uma me-todologia sistemática de projeto, apropriada pa-ra o tipo de produto de “software” em desenvol-vimento.

c) Uso de experiências anteriores de projeto: utili-zando lições aprendidas a partir de experiênciasanteriores de projeto, o fornecedor deve evitar arepetição de problemas idênticos ou semelhantes.

d) Processos subseqüentes: o produto deve serprojetado de modo a facilitar os ensaios, manu-tenção e uso.

5.6.3 Implementação

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

a) Regras: regras, tais como, de programação, de lin-guagens de programação, de convenções con-sistentes de nomenclatura, de codificação, bemcomo de comentários adequados, devem ser es-pecificadas e observadas.

b) Metodologias de implementação: o fornecedordeve usar métodos e ferramentas de implementa-ção apropriados para atender aos requisitos docomprador.

5.6.4 Análises críticas

O fornecedor deve realizar análises críticas, a fim de as-segurar que os requisitos são atendidos e que os méto-dos descritos anteriormente são aplicados de forma cor-reta. O processo de projeto ou de implementação nãodeve prosseguir até que as conseqüências de todas asdeficiências conhecidas sejam esclarecidas satisfa-toriamente, ou até que o risco de prosseguir de outro mo-do 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 desdeum item individual de “software” até o produto de “soft-

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

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

O documento que descreve o plano de ensaio pode serum documento independente, parte de outro documen-to ou composto de vários documentos.

5.7.2 Planejamento de ensaios

O fornecedor deve estabelecer e analisar criticamenteos planos de ensaios, especificações e procedimentos,antes de iniciar as atividades de ensaio. Os seguintespontos devem ser considerados:

a) planos para itens de “software”, integração, ensaiode sistema e ensaio de aceitação;

b) casos e dados de ensaios e resultados espera-dos;

c) tipos de ensaios a serem realizados, como, porexemplo: ensaios funcionais, ensaios de frontei-ras, 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 en-saios deve ser julgada;

f) documentação do usuário;

g) pessoal requerido e requisitos de seu treinamen-to.

5.7.3 Ensaios

Atenção especial deve ser dada aos seguintes aspec-tos dos ensaios:

a) os resultados dos ensaios devem ser registradosconforme definido na especificação pertinente;

b) quaisquer problemas encontrados e seus possí-veis impactos sobre quaisquer partes do “soft-ware” devem ser registrados, e os responsáveisnotificados, para que eles possam ser seguidosaté serem solucionados;

c) as áreas atingidas por quaisquer alterações de-vem ser identificadas e ensaiadas novamente;

d) a adequação e a pertinência dos ensaios devemser avaliadas;

e) a configuração de “hardware” e de “software” de-veser considerada e documentada.

5.7.4 Validação

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

8 NBR ISO 9000-3/1993

5.9.2 Entrega

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

5.9.3 Instalação

As funções, responsabilidades e obrigações do fornece-dor e do comprador devem ser claramente estabeleci-das, levando em conta:

a) a programação, incluindo horas de trabalho forado horário normal e nos fins de semana;

b) o acesso às instalações do comprador (crachásde segurança, senhas, acompanhantes);

c) a disponibilidade de pessoal capacitado;

d) a disponibilidade e acesso aos sistemas e equi-pamentos do comprador;

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

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

5.10 Manutenção

5.10.1 Generalidades

A manutenção do produto de “software” deve ser estipu-lada no contrato, após a entrega e a instalação inicial,quando requerida pelo comprador. O fornecedor deveestabelecer e manter procedimentos para realizaratividades de manutenção e verificar se estas ativida-des atendem aos requisitos especificados para a manu-tenção.

As atividades de manutenção para produtos de “soft-ware” são tipicamente classificadas em:

a) resolução de problemas;

b) modificação de interface;

c) expansão funcional ou aprimoramento do de-sempenho.

Os itens nos quais a manutenção deve ser realizada e operíodo de tempo, durante o qual ela deve ser efetua-da, devem ser especificados no contrato. A seguir sãoapresentados exemplos de tais itens:

a) programa(s);

b) dados e suas estruturas;

c) especificações;

d) documentos para o comprador e/ou usuário;

e) documentos para o uso do fornecedor.

5.7.5 Ensaios de campo

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

a) as características a serem ensaiadas no ambien-te de campo;

b) as responsabilidades específicas do fornecedore do comprador para realizar e avaliar o ensaio;

c) a restauração do ambiente do usuário (após o en-saio).

5.8 Aceitação

5.8.1 Generalidades

Quando o fornecedor está pronto para entregar o produ-to validado, o comprador deve julgar se o produto é acei-tável ou não, conforme os critérios previamente acorda-dos e o especificado no contrato.

O método para tratar dos problemas detectados, duran-te o procedimento de aceitação e a sua rejeição, deveser documentado e acordado entre o comprador e o for-necedor.

5.8.2 Planejamento dos ensaios de aceitação

Antes de realizar os procedimentos de aceitação, o for-necedor deve auxiliar o comprador a identificar os se-guintes pontos:

a) cronograma;

b) procedimentos para avaliação;

c) ambientes e recursos de “software”/”hardware”;

d) critérios de aceitação.

5.9 Cópia, entrega e instalação

5.9.1 Cópia

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

a) o número de cópias de cada item de “software” aser entregue;

b) o meio físico de fornecimento para cada item de“software”, incluindo formato e versão, em formainteligível;

c) a estipulação da documentação requerida, taiscomo manuais e guias de usuário;

d) definição e acordo quanto aos direitos autoraise licenças;

e) custódia de cópias-mestre e de segurança, quandoaplicável, incluindo planos de recuperação,em caso de desastres;

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

NBR ISO 9000-3/1993 9

5.10.2 Plano de manutenção

Todas as atividades de manutenção devem ser realiza-das e administradas de acordo com um plano de manu-tenção previamente definido e acordado entre o fornece-dor e o comprador. O plano deve incluir:

a) o objetivo da manutenção;

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

c) a(s) organização(ões) de suporte;

d) as atividades de manutenção;

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 ma-nutenção deve ser definida, documentada e acordadaentre o fornecedor e o comprador.

5.10.4 Organização de suporte

Pode ser necessário estabelecer uma organização, comrepresentantes do fornecedor e do comprador, para darsuporte às atividades de manutenção. Como as ativida-des da etapa de manutenção não podem ser sempre rea-lizadas de acordo com uma programação, esta organiza-ção deve ser bastante flexível para lidar com a ocorrên-cia de problemas inesperados. Também pode ser ne-cessário identificar instalações e recursos a serem usa-dos para as atividades de manutenção.

5.10.5 Tipos de atividades de manutenção

Todas as alterações no “software” (devido à resoluçãode problemas, modificações de interface, expansão fun-cional ou aprimoramento do desempenho), realizadasdurante a manutenção, devem ser feitas, tanto quantopossível, de acordo com os mesmos procedimentos usa-dos para o desenvolvimento do produto de “software”.Todas estas alterações devem também ser documen-tadas, de acordo com os procedimentos para controlede documentos e gestão de configuração:

a) Resolução de problemas: envolve a detecção, aanálise e a correção de não-conformidades de“software” que possam causar problemas ope-racionais. Soluções temporárias podem ser usa-das para minimizar o tempo fora de operação,efetuando-se, posteriormente, as modificaçõesdefinitivas.

b) Modificações de interface: podem ser requeri-das, quando acréscimos ou alterações são feitosno sistema de “hardware”, ou nos componentes,controlados pelo “software”.

c) Expansão funcional ou aprimoramento do desem-penho pode ser requerido pelo comprador du-rante a etapa de manutenção.

5.10.6 Registros e relatórios de manutenção

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

para a apresentação de relatórios de manutenção devemser estabelecidas e acordadas entre o fornecedor e ocomprador.

Os registros de manutenção devem incluir, para cadaitem de “software” em que se realiza a manutenção, osseguintes tópicos:

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

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

c) prioridades que foram atribuídas às ações cor-retivas;

d) resultados das ações corretivas;

e) dados estatísticos sobre a ocorrência de falhase atividades de manutenção.

O registro das atividades de manutenção pode ser utiliza-do para avaliação e aprimoramento do produto de “soft-ware” 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 edocumentar os procedimentos para a incorporação dealterações em um produto de “software”, resultantes danecessidade de manter o desempenho.

Tais procedimentos devem incluir:

a) regras básicas para determinar onde as corre-ções (“patches”) localizadas podem ser incorpora-das, ou quando é necessária a liberação de umacópia completa atualizada do produto de “soft-ware”;

b) descrições dos tipos (ou classes) de liberações, de-pendendo de sua freqüência e/ou do impacto so-bre as operações e a capacidade do compradorde implementar alterações a qualquer momento;

c) métodos pelos quais o comprador deve ser aler-tado sobre alterações atuais ou planejadas parao futuro;

d) métodos para confirmar que as alterações im-plementadas não introduzem outros problemas;

e) requisitos para os registros, indicando quais alte-raçõ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

6.1.1 Generalidades

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

10 NBR ISO 9000-3/1993

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

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

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

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

c) identificar a situação de elaboração de produtosde “software”, em desenvolvimento ou já entre-gues e instalados;

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

e) fornecer coordenação para a atualização de pro-dutos múltiplos, em um ou mais locais, confor-me requerido;

f) identificar e seguir, do início até a liberação, todasas ações e alterações resultantes de uma solici-tação de alteração.

6.1.2 Plano de gestão de configuração

O fornecedor deve desenvolver e implementar um pla-no 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 umadelas;

b) atividades de gestão de configuração a seremrealizadas;

c) ferramentas, técnicas e metodologias de gestãode configuração a serem usadas;

d) o estágio ao qual os itens devem ser trazidos sobo 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 procedimen-tos para identificar itens de “software” durante todas asfases, desde a especificação até o desenvolvimento, có-pia e entrega.

Estes procedimentos podem também ser aplicadosapós a entrega do produto, quando requerido pelo contra-to. Cada item de “software” individual deve possuir umaidentificação única.

Procedimentos devem ser aplicados para assegurarque os pontos a seguir possam ser identificados em ca-da versão de um item de “software”:

a) as especificações funcionais e técnicas;

b) todas as ferramentas de desenvolvimento queafetam as especificações funcionais e técnicas;

c) todas as interfaces com outros itens de “soft-ware” e com o “hardware”;

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

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

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

6.1.3.2 Controle de alterações

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

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

Devem ser fornecidos os métodos para informar aosenvolvidos quanto às alterações e para demonstrar arastreabilidade entre as alterações e as partes modifica-das dos itens de “software”.

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

O fornecedor deve estabelecer e manter procedimen-tos para registrar, administrar e relatar a situação de itensde “software”, de requisições de alteração e da imple-mentação das alterações aprovadas.

6.2 Controle de documentos

6.2.1 Generalidades

O fornecedor deve estabelecer e manter procedimentospara controlar todos os documentos relacionados aoconteúdo desta Norma, abrangendo:

a) a determinação dos documentos que devem es-tar sujeitos aos procedimentos de controle dedocumentos;

b) a aprovação e a emissão de procedimentos;

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

6.2.2 Tipos de documentos

Os procedimentos de controle de documentos devemser aplicados a documentos pertinentes, incluindo:

a) procedimentos, descrevendo o sistema da qualida-de a ser aplicado ao ciclo de vida do “software”;

NBR ISO 9000-3/1993 11

b) documentos de planejamento, descrevendo o pla-nejamento e a execução de todas as atividadesdo fornecedor e suas interações com o compra-dor;

c) documentos de produto, descrevendo um determi-nado produto de “software”, que incluam:

- 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.

6.2.3 Aprovação e emissão de documentos

Todos os documentos devem ser analisados critica-mente e aprovados por pessoal autorizado, antes de se-rem emitidos. Deve haver procedimentos para assegu-rar que:

a) as emissões pertinentes dos documentos apro-priados estejam disponíveis em locais adequa-dos onde sejam realizadas operações essenciaispara o funcionamento efetivo do sistema da quali-dade;

b) documentos obsoletos sejam prontamente removi-dos dos pontos apropriados de emissão ou uso.

Quando for feito uso de arquivos de computador, deveser dada atenção especial aos procedimentos ade-quados de aprovação, acesso, distribuição e arquivamento.

6.2.4 Alterações em documentos

As alterações em documentos devem ser analizadas cri-ticamente e aprovadas pelas mesmas funções/orgãosque realizaram a análise crítica e aprovação dos origi-nais, salvo prescrição em contrário. Os orgãos designa-dos devem ter acesso às informações básicas pertinen-tes, para subsidiar sua análise crítica e aprovação.

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

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

Os documentos devem ser reemitidos após incorporaçãode 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 procedimentospara identificar, coletar, indexar, arquivar, armazenar, man-ter e dispor os registros da qualidade.

Os registros da qualidade devem ser mantidos para de-

monstrar a obtenção da qualidade requerida e a efetivaoperação do sistema da qualidade. Registros da qualida-de pertinentes aos subfornecedores devem ser conside-rados como parte desses dados.

Todos os registros da qualidade devem ser legíveis eidentificáveis em relação ao produto envolvido. Os regis-tros da qualidade devem ser armazenados e mantidos detal forma que sejam prontamente recuperáveis em ins-talações que forneçam um ambiente adequado, para mi-nimizar a deterioração ou danos e para prevenir perdas.Os tempos de retenção dos registros da qualidade de-vem ser estabelecidos e registrados. Quando acordadoem contrato, os registros da qualidade devem estar dis-poníveis para avaliação pelo comprador ou por seu re-presentante durante um período preestabelecido.

[NBR 19001:1990, 4.16]

6.4 Medição

6.4.1 Medição de produtos

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

Atualmente não há indicadores da qualidade de “soft-ware” aceitos universalmente. No entanto, no mínimo, al-gum tipo de indicador deve ser usado para expressar fa-lhas e/ou defeitos de campo relatados, do ponto de vista docliente. O indicador selecionado deve ser descrito detal modo que os resultados possam ser comparáveis.

O fornecedor de produtos de “software” deve coletar eagir de acordo com indicadores quantitativos da quali-dade destes produtos. Estes indicadores quantitativosdevem ser usados para os seguintes fins:

a) coletar dados e relatar medidas em uma baseregular;

b) identificar o nível atual do desempenho em cadaindicador;

c) tomar ações remediadoras, caso os níveis dos in-dicadores se deteriorem ou ultrapassem as me-tas-alvo estabelecidas;

d) estabelecer metas específicas de aprimoramen-to expressas em termos dos indicadores.

6.4.2 Medição de processos

O fornecedor deve dispor de indicadores quantitativosda qualidade do processo de desenvolvimento e entre-ga, os quais devem refletir:

a) o quanto o processo de desenvolvimento estásendo efetuado em termos de atendimento a pon-to significante do Projeto e aos objetivos da qua-lidade ao longo do processo, conforme progra-mado;

b) com que eficácia o processo de desenvolvimentoestá reduzindo a probabilidade de que sejam in-troduzidos defeitos, ou que quaisquer defeitos in-troduzidos não sejam detectados.

12 NBR ISO 9000-3/1993

Assim como ocorre em relação a indicadores de produ-tos, o importante é que os níveis sejam conhecidos eutilizados para o controle de processo e para o aprimo-ramento, e não quais indicadores específicos são utiliza-dos. A escolha de indicadores deve se adequar ao pro-cesso usado e, se possível, causar um impacto direto so-bre a qualidade do “software” entregue. Indicadores di-ferentes podem ser apropriados para produtos de “soft-ware” diferentes produzidos pelo mesmo fornecedor.

6.5 Regras, práticas e convenções

O fornecedor deve suprir regras, práticas e convençõesde modo a tornar efetivo o sistema da qualidade espe-cificado nesta NBR ISO 9000-3. O fornecedor deve ana-lisar criticamente estas regras, práticas e convenções erevisá-las, quando requerido.

6.6 Ferramentas e técnicas

O fornecedor deve utilizar ferramentas, recursos e técni-cas para tornar efetivas as diretrizes do sistema da quali-dade desta Norma. Estas ferramentas, recursos e técni-cas podem ser eficazes para fins de gerenciamento, as-sim como para o desenvolvimento de produtos. O for-necedor 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 ser-viço adquirido está de acordo com os requisitos especi-ficados.

Os documentos de aquisição devem conter dados des-crevendo claramente o produto ou serviço encomenda-do. O fornecedor deve analisar criticamente e aprovaros documentos de aquisição, quanto à adequação dosrequisitos especificados antes da liberação.

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

6.7.2 Avaliação de subfornecedores

O fornecedor deve selecionar subfornecedores, baseadona capacidade destes em atender aos requisitos de sub-fornecimento, incluindo requisitos da qualidade. O forne-cedor deve estabelecer e manter registros de subforne-cedores qualificados.

A seleção de subfornecedores, o tipo e a abrangência docontrole exercido pelo fornecedor, devem depender do ti-po do produto e, quando aplicável, de registros de capa-cidade e de desempenho previamente demonstrados pe-los subfornecedores.

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

[NBR 19001:1990, 4.6.2]

6.7.3 Validação de produtos adquiridos

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

Quando especificado no contrato, o comprador, ou seurepresentante, deve ter o direito de verificar, na fonte ouno recebimento, se o produto adquirido está em confor-midade com os requisitos especificados. A validação pe-lo comprador não isenta o fornecedor da responsabilida-de de prover produtos aceitáveis, nem impede as rejei-ções subseqüentes.

Quando o comprador, ou seu representante, decide efe-tuar a validação nas instalações do subfornecedor, talvalidação não deve ser utilizada pelo fornecedor comoevidência de efetivo controle da qualidade pelo sub-fornecedor.

6.8 Produto de “software” incluído

A inclusão ou uso de produtos de “software” fornecidospelo comprador, ou por terceira parte, pode ser requeridoao fornecedor. O fornecedor deve estabelecer e manterprocedimentos para validação, armazenamento, proteçãoe manutenção de tais produtos. Deve-se considerar osuporte de cada produto de “software” em qualquer acordode manutenção relacionado ao produto a ser entregue.

Produtos fornecidos pelo comprador que sejam inade-quados para o uso devem ser registrados e relatados aocomprador. A validação pelo fornecedor não isenta ocomprador da responsabilidade de prover produtosaceitáveis.

6.9 Treinamento

O fornecedor deve estabelecer e manter procedimen-tos para identificar as necessidades de treinamento, eprovidenciá-lo para todo o pessoal que executa ativida-des que influenciam a qualidade. O pessoal que execu-ta tarefas específicas designadas deve ser qualificadocom base em educação adequada, treinamento e/ouexperiência, conforme requerido.

Os assuntos a serem abordados devem ser determina-dos, considerando-se as ferramentas, técnicas, metodo-logias e recursos de computador específicos a seremusados no desenvolvimento e gerenciamento do produtode “software”.

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

Registros apropriados do treinamento/experiência de-vem ser mantidos.

/ANEXOS

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

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