Você está na página 1de 14

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
Diretrizes para a aplicação da NBR 19001 ao
CEP 20003 - Caixa Postal 1680 desenvolvimento, fornecimento e manutenção de
Rio de Janeiro - RJ
Tel.: PABX (021) 210 -3122
"software"
Telex: (021) 34333 ABNT - BR
Endereço Telegráfico:
NORMATÉCNICA

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
Copyright © 1990, programme.
ABNT–Associação Brasileira
de Normas Técnicas
Printed in Brazil/ Descritores: Programação (computadores). Garantia da 14 páginas
Impresso no Brasil qualidade. Programa de garantia da qualidade
Todos os direitos reservados

Sumário pos de produtos industriais, tornando necessário prover,


Introdução nesse campo da tecnologia de desenvolvimento tão
1 Objetivo rápido, orientações adicionais para o estabeleci-
2 Referências normativas mento de sistemas da qualidade onde estejam envol-
3 Definições vidos os produtos de “software”, levando-se em conta o
4 Sistema da qualidade - Estrutura estágio atual da tecnologia.
5 Sistema da qualidade - Atividades do ciclo de vida
6 Sistema da qualidade - Atividades de apoio (não
A natureza do desenvolvimento de “software” é tal,
dependentes de fase)
que algumas atividades estão relacionadas às fases
Anexos
específicas do processo de desenvolvimento, en-
A - Referência cruzada entre NBR ISO 9000-3 e
quanto outras podem ser aplicadas ao longo de to-
NBR 19001
do o processo. Estas diretrizes foram assim estrutu-
B - Referência cruzada entre as NBR 19001 e
radas para refletir tais diferenças. Outrossim, este
NBR ISO 9000-3
documento, no que se refere ao formato, não corres-
ponde diretamente à norma NBR 19001, sendo, por
Introdução essa razão, fornecidos índices de referência cruza-
da (anexos A e B) para facilitar a consulta àquela
Com o progresso da tecnologia da informação, a quan- norma.
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 da Contratos entre duas partes, para o desenvolvimen-
qualidade é fornecer orientação para a garantia da quali- to de “software”, podem ocorrer com muitas varia-
dade do “software”. ções. Em certos casos de contratos entre duas par-
tes, estas diretrizes podem não ser aplicáveis ain-
Os requisitos para um sistema da qualidade genérico, pa-ra da que adaptadas. Torna-se, portanto, indispensá-
situações contratuais entre duas partes, já estão dispo- vel determinar a adequação do uso desta
níveis na NBR 19001 (ISO 9001):1990, Sistemas da quali- NBR ISO 9000-3 ao contrato.
dade -Modelo para garantia da qualidade em projetos/
desenvolvimento, produção, instalação e assistência téc-
nica. Esta NBR ISO 9000-3 aborda basicamente situa-
ções em que um “software” específico é desenvol-vido
Entretanto, o processo de desenvolvimento e manuten- como parte de um contrato, de acordo com as
ção de “software” é diferente da maioria dos demais ti- 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 si- Modelo para garantia da qualidade em projetos/de-
tuações. senvolvimento, produção, instalação e assistência téc-
nica.
NOTAS
NBR ISO 10011-1:1993, Diretrizes para auditoria de sis-
1 Ao longo desta NBR ISO 9000-3, quando não houver orien- temas de qualidade - Parte 1: Auditoria.
tações adicionais, o texto do item pertinente da NBR 19001 é
impresso em itálico. 3 Definições

Para os propósitos desta NBR ISO 9000-3, são aplicá-


2 Nesta NBR ISO 9000-3, há várias listas, sendo que nenhuma
veis as definições contidas nas ISO 2382-1 e
delas pretende ser exaustiva. São apresentadas a título de
NBR ISO 8402, juntamente com as definições a seguir.
exemplo.

3.1 “software”: criação intelectual compreendendo os


1 Objetivo programas, procedimentos, regras e qualquer docu-
mentação correlata à operação de um sistema de pro-
Esta NBR ISO 9000-3 define diretrizes para facilitar a cessamento de dados.
aplicação da NBR 19001 a organizações que desenvol-
vem, fornecem e mantêm “software”. [ISO 2382-1: 1984, 01.04.04]

Destina-se a fornecer orientação quando um contrato NOTA - O “software” não depende do meio no qual é regis-
entre duas partes exigir a demonstração da capacidade trado.
de um fornecedor em desenvolver, fornecer e manter
produtos de “software”. 3.2 produto de “software”: Conjunto completo de pro-
gramas de computador, procedimentos e documenta-ção
Estas diretrizes destinam-se a descrever os controles e correlata, assim como dados designados para en-trega a
métodos sugeridos para a produção de “software” que um usuário.
atendam aos requisitos do comprador, evitando-se não-
conformidades em todos os estágios, desde o desen- 3.3 item de “software”: Qualquer parte identificável
volvimento até a manutenção. de um produto de “software” em etapa intermediária ou
na etapa final do desenvolvimento.
As diretrizes desta NBR ISO 9000-3 são aplicáveis em
situações contratuais para produtos de “software”, quan- 3.4 desenvolvimento: Todas as atividades a serem rea-
do: lizadas para a criação de um produto de “software”.

a) o contrato exigir, especificamente, esforço de pro- 3.5 fase: Segmento definido do trabalho.
jeto, e os requisitos do produto forem indicados
principalmente em termos de desempenho, ou NOTA - Uma fase não implica no uso de qualquer modelo de
precisarem ser estabelecidos; ciclo de vida específico, nem implica em um período de tempo
durante o desenvolvimento de um produto de “software”.
b) a confiança no produto puder ser obtida através
da demonstração adequada da capacidade de 3.6 verificação (de “software”): Processo de avaliação
desenvolvimento, fornecimento e manutenção de dos produtos de uma determinada fase a fim de asse-gurar
um determinado fornecedor. a correção e a consistência no que diz respeito
aos produtos e normas fornecidos como entrada para a
referida fase.
2 Referências normativas
3.7 Validação (para "software"): Processo de avaliação
As normas relacionadas contêm disposições que, atra-vés de "software" a fim de assegurar que este atende aos re-
de referências neste texto, constituem prescrições desta quisitos especificados.
NBR ISO 9000-3. Na data da publicação desta
NBR ISO 9000-3, as edições indicadas eram válidas. 4 Sistema da qualidade - Estrutura
Como todas as normas estão sujeitas a revisões, as par-
tes interessadas dos acordos baseados nesta
4.1 Responsabilidade da administração
NBR ISO 9000-3 são encorajadas a investigar a possibi-
lidade de utilização de edições mais recentes das nor-
4.1.1 Responsabilidade da administração do fornecedor
mas indicadas a seguir. A ABNT mantem registros das
normas válidas atualmente.
4.1.1.1 Política da qualidade

ISO 2382-1:1984, Data processing - Vocabulary - Part 01: A administração do fornecedor deve definir e documen-tar
Fundamental terms. sua política e objetivos para a qualidade, e assumir o
compromisso com estes. O fornecedor deve assegurar
NBR ISO 8402:1993, Gestão da qualidade e garantia da que esta política é entendida, implementada e mantida
qualidade - Terminologia. 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
A responsabilidade, autoridade e interação de todo o hábil e resolver itens pendentes.
pessoal que administra, desempenha e verifica ativida-
des que influem na qualidade devem ser definidas, par- O comprador deve designar um representante respon-
ticularmente as do pessoal que necessita de autonomia sável para tratar de assuntos contratuais com o forne-
organizacional e autoridade para: cedor. Este representante deve ter autoridade, de acor-
do com a necessidade, para tratar dos assuntos contra-
a) iniciar ações para prevenir a ocorrência de não- tuais que incluem os seguintes itens, mas não se limi-
conformidade em produto; tam a estes:
b) identificar e registrar quaisquer problemas de
a) definir requisitos do comprador para fornecedor;
qualidade do produto;
b) responder a perguntas do fornecedor;
c) iniciar, recomendar ou providenciar soluções
através dos canais designados;
c) aprovar as propostas do fornecedor;
d) verificar a implementação das soluções;
d) concluir acordos com o fornecedor;
e) controlar processamento posterior, entrega ou ins-
talação de produto não-conforme, até que a de- e) garantir que a organização do comprador obser-
ficiência ou condição insatisfatória tenha sido va os acordos firmados com o fornecedor;
corrigida.
f) definir critérios e procedimentos de aceitação;
[NBR 19001:1990, 4.1.2.1]
g) negociar com o comprador sobre itens de “soft-
4.1.1.2.2 Recursos e pessoal para verificação ware” fornecidos que foram considerados inade-
quados para o uso.
O fornecedor deve identificar seus requisitos internos de
verificação, prover recursos adequados e designar pessoal 4.1.3 Análises críticas conjuntas
treinado para as atividades de verificação.
Análises críticas conjuntas regulares, envolvendo o for-
As atividades de verificação devem incluir inspeção, ensaio necedor e o comprador, devem ser programadas a fim
e monitorização de processos e/ou produto de projeto, de cobrir os aspectos a seguir, conforme apropriado:
produção, instalação e de assistência técnica; análises
críticas de projeto e auditorias do sistema da qualidade, a) conformidade do “software” com os requisitos es-
dos processos e/ou produto, devem ser realizadas por pecificados e acordados com o comprador;
pessoal independente daquele que tem responsabilidade
direta pelo trabalho que está sendo executado. b) resultados da verificação;

[NBR 19001:1990, 4.1.2.2] c) resultados do ensaio de aceitação.

4.1.1.2.3 Representante da administração Os resultados destas análises críticas devem ser acor-
dados e documentados.
O fornecedor deve designar um representante da admi-
nistração que, independentemente de outras responsa-
4.2 Sistema da qualidade
bilidades, tenha autoridade e responsabilidade definidas
para assegurar que os requisitos da NBR 19001 sejam
4.2.1 Generalidades
implementados e mantidos.
O fornecedor deve estabelecer e manter um sistema
[NBR 19001:1990, 4.1.2.3]
da qualidade documentado. O sistema da qualidade de-
4.1.1.3 Análise crítica pela administração ve ser um processo integrado por todo o ciclo de vida,
assegurando assim que a qualidade seja perseguida ao
O sistema da qualidade adotado para atender aos requi- longo do desenvolvimento do processo, em vez de ser ve-
sitos da NBR 19001, deve ser analisado criticamente, rificada ao final. A prevenção de problemas deve ser en-
em intervalos adequados, pela administração do forne- fatizada mais do que a correção após a ocorrência des-
cedor, a fim de assegurar a sua contínua adequação e efi- tes.
cácia. Devem ser mantidos registros destas análises.
O fornecedor deve assegurar a implementação efetiva
NOTA - As análises críticas incluem normalmente a avaliação do sistema da qualidade documentado.
dos resultados de auditorias internas do sistema da qualida-
de, executadas pela administração do fornecedor ou, em seu 4.2.2 Documentação do sistema da qualidade
nome, pelo pessoal da administração com responsabilidade
direta pelo sistema. Todos os elementos, requisitos e prescrições do siste-
ma da qualidade devem ser claramente documentados
[NBR 19001:1990, 4.1.3] de maneira sistemática e ordenada.
Cópia não autorizada
4 NBR ISO 9000-3/1993

4.2.3 Plano da qualidade Atividades relacionadas à qualidade devem ser planeja-


das e implementadas de acordo com a natureza do mo-
O fornecedor deve preparar e documentar um plano da delo de ciclo de vida utilizado.
qualidade, a fim de implementar atividades da qualida-
de para cada desenvolvimento de “software”, basean- Esta Norma destina-se à aplicação de qualquer modelo
do-se no sistema da qualidade e assegurando que este de ciclo de vida utilizado. Qualquer descrição, orienta-
seja entendido e observado pelas organizações envolvi- ção, requisito ou estrutura deve ser entendido como
das. indicação de que atende a todos os modelos de ciclo de
vida.
4.3 Auditorias internas do sistema da qualidade
5.2 Análise crítica de contrato
Auditorias internas da qualidade
5.2.1 Generalidades
O fornecedor deve implantar um sistema abrangente de
auditorias internas da qualidade, planejadas e documen- O fornecedor deve estabelecer e manter procedimen-
tadas, para verificar se as atividades da qualidade estão tos para análise crítica de contrato e para a coordena-
em conformidade com a forma planejada e para deter- ção destas atividades.
minar a eficácia do sistema da qualidade.
Cada contrato deve ser analisado criticamente pelo for-
As auditorias devem ser programadas com base na situa-
necedor para assegurar que:
ção atual e importância da atividade. As auditorias e as
ações de acompanhamento devem ser executadas con-
a) o objetivo do contrato e os requisitos sejam de-
forme os procedimentos documentados.
finidos e documentados;
Os resultados das auditorias devem ser documentados e
b) possíveis contingências ou riscos sejam identifi-
levados ao conhecimento do pessoal que tenha respon-
sabilidade pela área auditada. O pessoal responsável pe- cados;
la administração da área deve tomar, em tempo hábil,
c) as informações reservadas sejam protegidas
ações corretivas referentes às deficiências encontradas
adequadamente;
pela auditoria.

[NBR 19001:1990, 4.17]. d) quaisquer requisitos diferentes daqueles da pro-


posta sejam resolvidos;
Ver NBR ISO 10011-1.
e) o fornecedor tenha capacitação para atender aos
4.4 Ação corretiva requisitos contratuais;

O fornecedor deve estabelecer, documentar e manter f) a responsabilidade do fornecedor quanto ao tra-


procedimentos para: balho subcontratado seja definida;

a) investigar a causa de produto não-conforme e a g) a terminologia seja aceita por ambas as partes;
ação corretiva necessária para prevenir repetição;
h) o comprador tenha capacitação para atender às
b) analisar todos os processos, operações de tra- obrigações contratuais.
balho, concessões, registros da qualidade, relató-
rios de assistência técnica e reclamações de cli- Devem ser mantidos registros de tais análises críticas
ente para detectar e eliminar causas potenciais de contrato.
de produto não-conforme;
5.2.2 Itens de contrato relativos à qualidade
c) iniciar ações preventivas para tratar dos proble-
mas a nível correspondente aos riscos encontra- Os itens a seguir, entre outros, são freqüentemente
dos; considerados pertinentes ao contrato:
d) aplicar controles que assegurem que ações cor- a) critérios de aceitação;
retivas são tomadas e que, as mesmas são efica-
zes; b) tratamento das alterações nos requisitos do com-
prador durante o desenvolvimento;
e) implementar e registrar alterações nos procedi-
mentos resultantes de ação corretiva.
c) tratamento de problemas detectados após a
aceitação, incluindo reivindicações relacionadas
[NBR 19001:1990, 4.14]
à qualidade e reclamações do comprador;
5 Sistema da qualidade - Atividades do ciclo de
vida d) atividades realizadas pelo comprador, especial-
mente no que se refere à especificação dos re-
5.1 Generalidades quisitos, instalação e aceitação;

Um projeto de desenvolvimento de “software” deve ser e) recursos, ferramentas e itens de “software” a se-
organizado de acordo com um modelo de ciclo de vida. rem fornecidos pelo comprador;
Cópia não autorizada
NBR ISO 9000-3/1993 5

f) normas e procedimentos a serem utilizados; estrutura da equipe, as responsabilidades, o uso


de subcontratados e os recursos materiais a se-
g) requisitos relativos a cópia (ver item 5.9). rem empregados;

5.3 Especificação dos requisitos do comprador c) fases do desenvolvimento (conforme definidas


no item 5.4.2.1);
5.3.1 Generalidades
d) programação do projeto, identificando as tarefas
A fim de continuar com o desenvolvimento do “software”, a serem realizadas, os recursos e o tempo neces-
o fornecedor deve ter um conjunto completo, e sem am- sários para cada uma delas, e quaisquer inter-re-
bigüidades, dos requisitos funcionais. Além disso, os re- lações das tarefas;
quisitos devem incluir todos os aspectos necessários à
satisfação das necessidades do comprador, aspectos e) identificação de planos correlatos, tais como:
estes como desempenho, segurança contra riscos, pri-
vacidade e confiabilidade. Tais requisitos devem ser es- - plano da qualidade;
tabelecidos de maneira precisa, o suficiente para permi-
tir a validação durante a aceitação do produto. - plano de gestão de configuração;

A especificação dos requisitos do comprador deve re- - plano de integração;


gistrar estes requisitos. Em alguns casos, esta especifi-
cação é fornecida pelo comprador. Caso contrário, o for- - plano de ensaio.
necedor deve desenvolver estes requisitos em estreita
cooperação com o comprador e obter dele a aprova- O plano de desenvolvimento deve ser atualizado à me-
ção, antes de passar ao estágio de desenvolvimento. A dida que o desenvolvimento progredir e cada fase deve
especificação dos requisitos do comprador deve estar ser definida conforme 5.4.2.1, antes de as atividades da-
sujeita ao controle de documentação e à gestão de con- quela fase iniciarem-se. Estas devem ser analisadas cri-
figuração, como parte da documentação de desenvolvi- ticamente e aprovadas antes da execução.
mento.
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 5.4.2.1 Fase
plenamente especificadas, diretamente ou por meio de
referência, na especificação dos requisitos do comprador. O plano de desenvolvimento deve definir um processo
ou metodologia disciplinada, para transformar a especi-
5.3.2 Cooperação mútua ficação dos requisitos do comprador em um produto de
“software”. Este fato pode envolver a divisão do trabalho
Durante o desenvolvimento da especificação dos requisi- em fases, e a identificação dos seguintes pontos:
tos do comprador, recomenda-se dar atenção às se-
guintes questões: a) fases de desenvolvimento a serem realizadas;

a) designação de pessoas (de ambas as partes) res- b) entradas requeridas para cada fase;
ponsáveis pelo estabelecimento da especifica-
ção dos requisitos do comprador; c) saídas requeridas para cada fase;

b) métodos para se obter acordo quanto aos requi- d) procedimentos de verificação a serem executa-
sitos e aprovação das alterações; dos em cada fase;

c) esforços para evitar mal-entendidos, tais como: e) análise dos problemas potenciais associados às
definições de termos, explicação de fundamen- fases de desenvolvimento e ao atendimento dos
tos dos requisitos; requisitos especificados.

d) registro e análise crítica dos resultados de dis- 5.4.2.2 Gestão


cussões por ambas as partes.
O plano de desenvolvimento deve definir como o projeto
5.4 Planejamento do desenvolvimento deve ser gerenciado, incluindo a identificação de:

5.4.1 Generalidades a) programação de desenvolvimento, implementa-


ção e entregas;
O plano de desenvolvimento deve abranger os seguin-
tes pontos: b) controle da execução;

a) definição do projeto, incluindo uma declaração de c) responsabilidades organizacionais, recursos e


seus objetivos e referências a projetos relaciona- atribuição de tarefas
dos, do comprador ou do fornecedor;
d) interfaces organizacionais e técnicas entre os di-
b) organização dos recursos do projeto, incluindo a ferentes grupos.
Cópia não autorizada
6 NBR ISO 9000-3/1993

5.4.2.3 Métodos e ferramentas de desenvolvimento Os resultados da verificação, e quaisquer ações suple-


mentares requeridas para assegurar que os requisitos
O plano de desenvolvimento deve identificar métodos para especificados foram atendidos, devem ser registrados e
assegurar que todas as atividades sejam realiza- verificados quando da conclusão destas ações. Apenas
das corretamente, podendo incluir: saídas de desenvolvimento verificadas devem ser sub-
metidas à gerência de configuração e aceitas para uso
a) regras, práticas e convenções para o desenvolvi- subseqüente.
mento;
5.5 Planejamento da qualidade
b) ferramentas e técnicas para o desenvolvimento;
5.5.1 Generalidades
c) gestão de configuração.

5.4.3 Controle da execução


O fornecedor deve preparar um plano da qualidade co-
mo parte do planejamento de desenvolvimento.
As análises críticas da execução física devem ser plane-
jadas, executadas e documentadas, a fim de assegurar O plano da qualidade deve ser atualizado, ao longo da
que questões importantes relativas aos recursos se- execução do desenvolvimento, e os itens pertinentes a
jam resolvidas, além de assegurar a execução efetiva cada fase devem estar totalmente definidos ao ser ini-
dos planos de desenvolvimento. ciada a fase.

5.4.4 Entrada das fases de desenvolvimento O plano da qualidade deve ser analisado crítica e for-
malmente e acordado por todas as organizações envolvi-
A entrada requerida para cada fase de desenvolvimen- das em sua implementação.
to deve ser definida e documentada. Cada requisito de-
ve ser definido de tal modo que seu atendimento possa O documento que descreve o plano da qualidade (ver
ser verificado. Requisitos incompletos, ambíguos ou 5.5.2) pode ser um documento independente (denomi-
conflitantes devem ser esclarecidos junto aos responsá- nado plano da qualidade) ou parte de outro documento,
veis pela definição destes. 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 de-
ve ser definida e documentada. A saída de cada fase de O plano da qualidade deve especificar ou fazer referên-
desenvolvimento deve ser verificada, e ainda: cia aos seguintes itens:

a) atender aos requisitos pertinentes; a) objetivos da qualidade, expressos em termos men-


suráveis sempre que possível;
b) conter ou fazer referência a critérios de aceitação
para que se passe às fases subseqüentes; b) critérios de entrada e de saída definidos para ca-
da fase de desenvolvimento;
c) atender às práticas de desenvolvimento e con-
venções adequadas, quer estas tenham ou não
c) identificação de tipos de ensaios e de atividades
sido estipuladas nas informações de entrada;
de verificação e de validação a serem realizadas;
d) identificar as características do produto que são
d) planejamento detalhado de atividades de ensaio,
de importância crucial para seu funcionamento
de verificação e de validação a serem realizadas,
seguro e adequado;
incluindo a programação, os recursos e as auto-
e) atender aos requisitos regulamentares aplicáveis. ridades encarregadas da aprovação;

5.4.6 Verificação de cada fase e) responsabilidades específicas para atividades da


qualidade, tais como:
O fornecedor deve elaborar um plano para verificação
de todas as saídas ao final de cada fase de desenvolvi- - análises críticas e ensaios;
mento.
- 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 en- - controle de defeitos e ação corretiva.
trada correspondentes, mediante a adoção de medidas
de controle de desenvolvimento, tais como: 5.6 Projeto e implementação

a) análises críticas do desenvolvimento em pontos 5.6.1 Generalidades


apropriados das fases deste;
As atividades de projeto e implementação são aquelas
b) comparação do novo projeto com um projeto seme- que transformam as especificações dos requisitos do
lhante já comprovado, caso haja algum disponível; comprador em um produto de “software”. Devido à com-
plexidade dos produtos de “software”, é imperativo que tais
c) realização de ensaios e demonstrações. 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 ware” completo. Há várias abordagens diferentes para
de validação para assegurar a qualidade. os ensaios e a integração.

NOTA - A quantidade de informações a serem fornecidas para Em alguns casos, a validação, os ensaios de campo e os
o comprador deve ser acordada mutuamente pelas partes, ensaios de aceitação podem ser uma mesma atividade.
uma vez que os processos de projeto e implementação são fre-
qüentemente de propriedade do fornecedor. O documento que descreve o plano de ensaio pode ser
um documento independente, parte de outro documen-
5.6.2 Projeto to ou composto de vários documentos.
Além dos requisitos aplicáveis a todas as fases de de- 5.7.2 Planejamento de ensaios
senvolvimento, os aspectos a seguir, inerentes às ativi-
dades de projeto, devem ser levados em consideração. O fornecedor deve estabelecer e analisar criticamente
os planos de ensaios, especificações e procedimentos,
a) Identificação das considerações de projeto:
antes de iniciar as atividades de ensaio. Os seguintes
além das especificações de entrada e saída, de-
pontos devem ser considerados:
vem ser examinados aspectos, tais como, as re-
gras de projeto e as definições de interfaces inter-
a) planos para itens de “software”, integração, ensaio
nas.
de sistema e ensaio de aceitação;
b) Metodologia de projeto: deve ser usada uma me-
b) casos e dados de ensaios e resultados espera-
todologia sistemática de projeto, apropriada pa-
dos;
ra o tipo de produto de “software” em desenvol-
vimento.
c) tipos de ensaios a serem realizados, como, por
c) Uso de experiências anteriores de projeto: utili- exemplo: ensaios funcionais, ensaios de frontei-
zando lições aprendidas a partir de experiências ras, ensaios de desempenho e ensaios de utiliza-
anteriores de projeto, o fornecedor deve evitar a ção;
repetição de problemas idênticos ou semelhantes.
d) ambiente, ferramentas e “software” de ensaio;
d) Processos subseqüentes: o produto deve ser
projetado de modo a facilitar os ensaios, manu- e) critérios a partir dos quais a conclusão dos en-
tenção e uso. saios 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 g) pessoal requerido e requisitos de seu treinamen-
desenvolvimento, os aspectos a seguir devem ser con- to.
siderados em cada atividade de implementação.
5.7.3 Ensaios
a) Regras: regras, tais como, de programação, de lin-
guagens de programação, de convenções con- Atenção especial deve ser dada aos seguintes aspec-
sistentes de nomenclatura, de codificação, bem tos dos ensaios:
como de comentários adequados, devem ser es-
pecificadas e observadas. a) os resultados dos ensaios devem ser registrados
conforme definido na especificação pertinente;
b) Metodologias de implementação: o fornecedor
deve usar métodos e ferramentas de implementa- b) quaisquer problemas encontrados e seus possí-
ção apropriados para atender aos requisitos do veis impactos sobre quaisquer partes do “soft-
comprador. ware” devem ser registrados, e os responsáveis
notificados, para que eles possam ser seguidos
5.6.4 Análises críticas até serem solucionados;
O fornecedor deve realizar análises críticas, a fim de as-
c) as áreas atingidas por quaisquer alterações de-
segurar que os requisitos são atendidos e que os méto-
vem ser identificadas e ensaiadas novamente;
dos descritos anteriormente são aplicados de forma cor-
reta. O processo de projeto ou de implementação não
d) a adequação e a pertinência dos ensaios devem
deve prosseguir até que as conseqüências de todas as
ser avaliadas;
deficiências conhecidas sejam esclarecidas satisfa-
toriamente, ou até que o risco de prosseguir de outro mo- e) a configuração de “hardware” e de “software” de-ve
do seja conhecido. ser considerada e documentada.
Registros de tais análises críticas devem ser mantidos.
5.7.4 Validação
5.7 Ensaios e validação
Antes de liberar o produto para entrega e aceitação do
5.7.1 Generalidades comprador, o fornecedor deve validar sua operação co-
mo um produto completo, quando possível, sob condi-
Ensaios, em vários níveis, podem ser requeridos desde ções semelhantes às do ambiente de aplicação, confor-
um item individual de “software” até o produto de “soft- me 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 cam- Prescrições devem ser feitas para verificar a correção e
po, os seguintes aspectos devem ser considerados: a completeza das cópias do produto de “software” entre-
gues.
a) as características a serem ensaiadas no ambien-
te de campo; 5.9.3 Instalação

b) as responsabilidades específicas do fornecedor As funções, responsabilidades e obrigações do fornece-


e do comprador para realizar e avaliar o ensaio; dor e do comprador devem ser claramente estabeleci-
das, levando em conta:
c) a restauração do ambiente do usuário (após o en-
saio).
a) a programação, incluindo horas de trabalho fora
do horário normal e nos fins de semana;
5.8 Aceitação

5.8.1 Generalidades b) o acesso às instalações do comprador (crachás


de segurança, senhas, acompanhantes);
Quando o fornecedor está pronto para entregar o produ-
to validado, o comprador deve julgar se o produto é acei- c) a disponibilidade de pessoal capacitado;
tável ou não, conforme os critérios previamente acorda-
dos e o especificado no contrato. d) a disponibilidade e acesso aos sistemas e equi-
pamentos do comprador;
O método para tratar dos problemas detectados, duran-
te o procedimento de aceitação e a sua rejeição, deve e) a necessidade de validação como parte de cada
ser documentado e acordado entre o comprador e o for- instalação deve ser determinada em contrato;
necedor.
f) um procedimento formal para aprovação de cada
5.8.2 Planejamento dos ensaios de aceitação instalação após sua conclusão.

Antes de realizar os procedimentos de aceitação, o for- 5.10 Manutenção


necedor deve auxiliar o comprador a identificar os se-
guintes pontos: 5.10.1 Generalidades

a) cronograma;
A manutenção do produto de “software” deve ser estipu-
lada no contrato, após a entrega e a instalação inicial,
b) procedimentos para avaliação;
quando requerida pelo comprador. O fornecedor deve
c) ambientes e recursos de “software”/”hardware”; estabelecer e manter procedimentos para realizar
atividades de manutenção e verificar se estas ativida-
d) critérios de aceitação. des atendem aos requisitos especificados para a manu-
tenção.
5.9 Cópia, entrega e instalação
As atividades de manutenção para produtos de “soft-
5.9.1 Cópia ware” são tipicamente classificadas em:

A cópia é uma etapa que deve ser conduzida antes da a) resolução de problemas;
entrega. Ao providenciar-se a cópia, deve-se considerar:
b) modificação de interface;
a) o número de cópias de cada item de “software” a
ser entregue; c) expansão funcional ou aprimoramento do de-
sempenho.
b) o meio físico de fornecimento para cada item de
“software”, incluindo formato e versão, em forma Os itens nos quais a manutenção deve ser realizada e o
inteligível; período de tempo, durante o qual ela deve ser efetua-
da, devem ser especificados no contrato. A seguir são
c) a estipulação da documentação requerida, tais apresentados exemplos de tais itens:
como manuais e guias de usuário;
a) programa(s);
d) definição e acordo quanto aos direitos autorais
e licenças;
b) dados e suas estruturas;
e) custódia de cópias-mestre e de segurança, quando
aplicável, incluindo planos de recuperação, c) especificações;
em caso de desastres;
d) documentos para o comprador e/ou usuário;
f) o período de obrigação do fornecedor para o su-
primento de cópias. e) documentos para o uso do fornecedor.
Cópia não autorizada
NBR ISO 9000-3/1993 9

5.10.2 Plano de manutenção para a apresentação de relatórios de manutenção devem


ser estabelecidas e acordadas entre o fornecedor e o
Todas as atividades de manutenção devem ser realiza- comprador.
das e administradas de acordo com um plano de manu-
tenção previamente definido e acordado entre o fornece- Os registros de manutenção devem incluir, para cada
dor e o comprador. O plano deve incluir: item de “software” em que se realiza a manutenção, os
seguintes tópicos:
a) o objetivo da manutenção;
a) lista de solicitações de assistência ou de relató-
b) a identificação da situação inicial do produto; rios de problemas que tiverem sido recebidos, e a
situação atual de cada um deles;
c) a(s) organização(ões) de suporte;
b) organização responsável pelo atendimento às re-
d) as atividades de manutenção; quisições para assistência ou implementação
das ações corretivas adequadas;
e) os registros e os relatórios de manutenção.
c) prioridades que foram atribuídas às ações cor-
5.10.3 Identificação da situação inicial do produto retivas;

A situação inicial do produto em que será realizada a ma- d) resultados das ações corretivas;
nutenção deve ser definida, documentada e acordada
entre o fornecedor e o comprador. e) dados estatísticos sobre a ocorrência de falhas
e atividades de manutenção.
5.10.4 Organização de suporte
O registro das atividades de manutenção pode ser utiliza-
Pode ser necessário estabelecer uma organização, com do para avaliação e aprimoramento do produto de “soft-
representantes do fornecedor e do comprador, para dar ware” e para melhoria do próprio sistema da qualidade.
suporte às atividades de manutenção. Como as ativida-
des da etapa de manutenção não podem ser sempre rea- 5.10.7 Procedimentos de liberação
lizadas de acordo com uma programação, esta organiza-
ção deve ser bastante flexível para lidar com a ocorrên- O fornecedor e o comprador devem entrar em acordo e
cia de problemas inesperados. Também pode ser ne- documentar os procedimentos para a incorporação de
cessário identificar instalações e recursos a serem usa- alterações em um produto de “software”, resultantes da
dos para as atividades de manutenção. necessidade de manter o desempenho.

5.10.5 Tipos de atividades de manutenção Tais procedimentos devem incluir:

Todas as alterações no “software” (devido à resolução a) regras básicas para determinar onde as corre-
de problemas, modificações de interface, expansão fun- ções (“patches”) localizadas podem ser incorpora-
cional ou aprimoramento do desempenho), realizadas das, ou quando é necessária a liberação de uma
durante a manutenção, devem ser feitas, tanto quanto cópia completa atualizada do produto de “soft-
possível, de acordo com os mesmos procedimentos usa- ware”;
dos para o desenvolvimento do produto de “software”.
Todas estas alterações devem também ser documen- b) descrições dos tipos (ou classes) de liberações, de-
tadas, de acordo com os procedimentos para controle pendendo de sua freqüência e/ou do impacto so-
de documentos e gestão de configuração: bre as operações e a capacidade do comprador
de implementar alterações a qualquer momento;
a) Resolução de problemas: envolve a detecção, a
análise e a correção de não-conformidades de c) métodos pelos quais o comprador deve ser aler-
“software” que possam causar problemas ope- tado sobre alterações atuais ou planejadas para
racionais. Soluções temporárias podem ser usa- o futuro;
das para minimizar o tempo fora de operação,
efetuando-se, posteriormente, as modificações d) métodos para confirmar que as alterações im-
definitivas. plementadas não introduzem outros problemas;

b) Modificações de interface: podem ser requeri- e) requisitos para os registros, indicando quais alte-
das, quando acréscimos ou alterações são feitos rações foram implementadas e em que locais,
no sistema de “hardware”, ou nos componentes, para os vários produtos e instalações.
controlados pelo “software”.
6 Sistema da qualidade - Atividades de suporte
c) Expansão funcional ou aprimoramento do desem- (não dependentes de fase)
penho pode ser requerido pelo comprador du-
rante a etapa de manutenção. 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 registra- A gestão de configuração fornece um mecanismo para a
das em formatos prédefinidos, e arquivadas. As regras identificação, controle e acompanhamento das versões
Cópia não autorizada
10 NBR ISO 9000-3/1993

de cada item de “software”. Em muitos casos, versões b) todas as ferramentas de desenvolvimento que
anteriores, ainda em uso, também têm que receber ma- afetam as especificações funcionais e técnicas;
nutenção e ser controladas.
c) todas as interfaces com outros itens de “soft-
O sistema de gestão de configuração deve: ware” e com o “hardware”;

a) identificar, de forma única, as versões de cada d) todos os documentos e arquivos de computa-


item de “software”; dor relacionados com o item de “software”.

b) identificar as versões de cada item de “software” A identificação de um item de “software” deve ser feita
que, juntas, constituem uma versão específica de de tal modo que a relação entre o item e os requisitos do
um produto completo; contrato possa ser demonstrada.

c) identificar a situação de elaboração de produtos Para produtos já liberados, deve haver procedimentos
de “software”, em desenvolvimento ou já entre- para facilitar a rastreabilidade do item ou produto de
gues e instalados; “software”.

d) controlar a atualização simultânea de um deter- 6.1.3.2 Controle de alterações


minado item de “software” por mais de uma pessoa;
O fornecedor deve estabelecer e manter procedimen-
e) fornecer coordenação para a atualização de pro- tos para identificar, documentar, analisar criticamente e
dutos múltiplos, em um ou mais locais, confor- autorizar quaisquer alterações em itens de “software”
me requerido; sob gestão de configuração. Todas as alterações em
itens de “software” devem ser realizadas de acordo com
f) identificar e seguir, do início até a liberação, todas estes procedimentos.
as ações e alterações resultantes de uma solici-
tação de alteração. Antes da aceitação de uma alteração, sua validade deve
ser confirmada, e os efeitos causados sobre outros itens
6.1.2 Plano de gestão de configuração devem ser identificados e examinados.

O fornecedor deve desenvolver e implementar um pla- Devem ser fornecidos os métodos para informar aos
no de gestão de configuração que inclua: envolvidos quanto às alterações e para demonstrar a
rastreabilidade entre as alterações e as partes modifica-
a) organizações envolvidas na gestão de configura- das dos itens de “software”.
ção e as responsabilidades atribuídas a cada uma
delas; 6.1.3.3 Relatório de situação da configuração

b) atividades de gestão de configuração a serem O fornecedor deve estabelecer e manter procedimen-


realizadas; tos para registrar, administrar e relatar a situação de itens
de “software”, de requisições de alteração e da imple-
c) ferramentas, técnicas e metodologias de gestão mentação das alterações aprovadas.
de configuração a serem usadas;
6.2 Controle de documentos
d) o estágio ao qual os itens devem ser trazidos sob
o controle de configuração. 6.2.1 Generalidades

6.1.3 Atividades de gestão de configuração O fornecedor deve estabelecer e manter procedimentos


para controlar todos os documentos relacionados ao
6.1.3.1 Identificação e rastreabilidade de configuração conteúdo desta Norma, abrangendo:

O fornecedor deve estabelecer e manter procedimen- a) a determinação dos documentos que devem es-
tos para identificar itens de “software” durante todas as tar sujeitos aos procedimentos de controle de
fases, desde a especificação até o desenvolvimento, có- documentos;
pia e entrega.
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 contra- c) os procedimentos de alteração, incluindo a retira-
to. Cada item de “software” individual deve possuir uma da e, quando apropriado, a liberação.
identificação única.
6.2.2 Tipos de documentos
Procedimentos devem ser aplicados para assegurar
que os pontos a seguir possam ser identificados em ca- Os procedimentos de controle de documentos devem
da versão de um item de “software”: ser aplicados a documentos pertinentes, incluindo:

a) as especificações funcionais e técnicas; a) procedimentos, descrevendo o sistema da qualida-


de a ser aplicado ao ciclo de vida do “software”;
Cópia não autorizada
NBR ISO 9000-3/1993 11

b) documentos de planejamento, descrevendo o pla- monstrar a obtenção da qualidade requerida e a efetiva


nejamento e a execução de todas as atividades operação do sistema da qualidade. Registros da qualida-
do fornecedor e suas interações com o compra- de pertinentes aos subfornecedores devem ser conside-
dor; rados como parte desses dados.

c) documentos de produto, descrevendo um determi- Todos os registros da qualidade devem ser legíveis e
nado produto de “software”, que incluam: identificáveis em relação ao produto envolvido. Os regis-
tros da qualidade devem ser armazenados e mantidos de
- entradas da fase de desenvolvimento; tal forma que sejam prontamente recuperáveis em ins-
talações que forneçam um ambiente adequado, para mi-
- saídas da fase de desenvolvimento; nimizar a deterioração ou danos e para prevenir perdas.
Os tempos de retenção dos registros da qualidade de-
- planos e resultados de verificação e validação; vem ser estabelecidos e registrados. Quando acordado
em contrato, os registros da qualidade devem estar dis-
- documentação para o comprador e o usuário; poníveis para avaliação pelo comprador ou por seu re-
presentante durante um período preestabelecido.
- 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 critica-
mente e aprovados por pessoal autorizado, antes de se- 6.4.1 Medição de produtos
rem emitidos. Deve haver procedimentos para assegu-
rar que: As medidas devem ser relatadas e utilizadas para geren-
ciar o processo de desenvolvimento e entrega, e devem
a) as emissões pertinentes dos documentos apro- ser pertinentes ao produto de “software” específico.
priados estejam disponíveis em locais adequa-
dos onde sejam realizadas operações essenciais Atualmente não há indicadores da qualidade de “soft-
ware” aceitos universalmente. No entanto, no mínimo, al-
para o funcionamento efetivo do sistema da quali-
dade; gum tipo de indicador deve ser usado para expressar fa-
lhas e/ou defeitos de campo relatados, do ponto de vista do
cliente. O indicador selecionado deve ser descrito de
b) documentos obsoletos sejam prontamente removi-
dos dos pontos apropriados de emissão ou uso. tal modo que os resultados possam ser comparáveis.

O fornecedor de produtos de “software” deve coletar e


Quando for feito uso de arquivos de computador, deve
agir de acordo com indicadores quantitativos da quali-
ser dada atenção especial aos procedimentos ade-
dade destes produtos. Estes indicadores quantitativos
quados de aprovação, acesso, distribuição e arquivamento.
devem ser usados para os seguintes fins:
6.2.4 Alterações em documentos
a) coletar dados e relatar medidas em uma base
regular;
As alterações em documentos devem ser analizadas cri-
ticamente e aprovadas pelas mesmas funções/orgãos b) identificar o nível atual do desempenho em cada
que realizaram a análise crítica e aprovação dos origi- indicador;
nais, salvo prescrição em contrário. Os orgãos designa-
dos devem ter acesso às informações básicas pertinen- c) tomar ações remediadoras, caso os níveis dos in-
tes, para subsidiar sua análise crítica e aprovação. dicadores se deteriorem ou ultrapassem as me-
tas-alvo estabelecidas;
Onde praticável, a natureza das alterações deve ser iden-
tificada no documento ou em anexo apropriado. d) estabelecer metas específicas de aprimoramen-
to expressas em termos dos indicadores.
Um índice geral, ou procedimento equivalente de contro-
le de documentos deve ser elaborado para identificar a 6.4.2 Medição de processos
revisão atual dos documentos, a fim de evitar a utilização
de documentos não aplicáveis. O fornecedor deve dispor de indicadores quantitativos
da qualidade do processo de desenvolvimento e entre-
Os documentos devem ser reemitidos após incorporação ga, os quais devem refletir:
de um número razoável de alterações.
a) o quanto o processo de desenvolvimento está
[NBR 19001:1990, 4.5.2] sendo efetuado em termos de atendimento a pon-
to significante do Projeto e aos objetivos da qua-
6.3 Registros da qualidade lidade ao longo do processo, conforme progra-
mado;
O fornecedor deve estabelecer e manter procedimentos
para identificar, coletar, indexar, arquivar, armazenar, man- b) com que eficácia o processo de desenvolvimento
ter e dispor os registros da qualidade. está reduzindo a probabilidade de que sejam in-
troduzidos defeitos, ou que quaisquer defeitos in-
Os registros da qualidade devem ser mantidos para de- troduzidos não sejam detectados.
Cópia não autorizada
12 NBR ISO 9000-3/1993

Assim como ocorre em relação a indicadores de produ- 6.7.3 Validação de produtos adquiridos
tos, o importante é que os níveis sejam conhecidos e
utilizados para o controle de processo e para o aprimo- O fornecedor é responsável pela validação do trabalho
ramento, e não quais indicadores específicos são utiliza- subcontratado, o que exige que ele conduza o projeto e
dos. A escolha de indicadores deve se adequar ao pro- outras análises críticas de modo coerente com seu pró-
cesso usado e, se possível, causar um impacto direto so- prio sistema da qualidade e, neste caso, tais requisitos
bre a qualidade do “software” entregue. Indicadores di- devem ser incluídos no subcontrato. Quaisquer requisi-
ferentes podem ser apropriados para produtos de “soft- tos de ensaios de aceitação, pelo fornecedor, do trabalho
ware” diferentes produzidos pelo mesmo fornecedor. subcontratado devem ser incluídos da mesma maneira.

6.5 Regras, práticas e convenções


Quando especificado no contrato, o comprador, ou seu
representante, deve ter o direito de verificar, na fonte ou
O fornecedor deve suprir regras, práticas e convenções
no recebimento, se o produto adquirido está em confor-
de modo a tornar efetivo o sistema da qualidade espe-
midade com os requisitos especificados. A validação pe-
cificado nesta NBR ISO 9000-3. O fornecedor deve ana-
lo comprador não isenta o fornecedor da responsabilida-
lisar criticamente estas regras, práticas e convenções e
de de prover produtos aceitáveis, nem impede as rejei-
revisá-las, quando requerido.
ções subseqüentes.
6.6 Ferramentas e técnicas
Quando o comprador, ou seu representante, decide efe-
O fornecedor deve utilizar ferramentas, recursos e técni- tuar a validação nas instalações do subfornecedor, tal
cas para tornar efetivas as diretrizes do sistema da quali- validação não deve ser utilizada pelo fornecedor como
dade desta Norma. Estas ferramentas, recursos e técni- evidência de efetivo controle da qualidade pelo sub-
cas podem ser eficazes para fins de gerenciamento, as- fornecedor.
sim como para o desenvolvimento de produtos. O for-
necedor deve aprimorar estas ferramentas e técnicas, 6.8 Produto de “software” incluído
quando requerido.
A inclusão ou uso de produtos de “software” fornecidos
6.7 Aquisição pelo comprador, ou por terceira parte, pode ser requerido
ao fornecedor. O fornecedor deve estabelecer e manter
6.7.1 Generalidades procedimentos para validação, armazenamento, proteção
e manutenção de tais produtos. Deve-se considerar o
O fornecedor deve assegurar que um produto ou ser- suporte de cada produto de “software” em qualquer acordo
viço adquirido está de acordo com os requisitos especi- de manutenção relacionado ao produto a ser entregue.
ficados.

Os documentos de aquisição devem conter dados des- Produtos fornecidos pelo comprador que sejam inade-
crevendo claramente o produto ou serviço encomenda- quados para o uso devem ser registrados e relatados ao
do. O fornecedor deve analisar criticamente e aprovar comprador. A validação pelo fornecedor não isenta o
os documentos de aquisição, quanto à adequação dos comprador da responsabilidade de prover produtos
requisitos especificados antes da liberação. aceitáveis.

NOTA - Um produto adquirido pode ser um item de “software” 6.9 Treinamento


e/ou de “hardware” destinado à inclusão no produto final re-
querido, ou uma ferramenta para auxiliar no desenvolvimento O fornecedor deve estabelecer e manter procedimen-
do produto requerido. tos para identificar as necessidades de treinamento, e
providenciá-lo para todo o pessoal que executa ativida-
6.7.2 Avaliação de subfornecedores des que influenciam a qualidade. O pessoal que execu-
ta tarefas específicas designadas deve ser qualificado
O fornecedor deve selecionar subfornecedores, baseado com base em educação adequada, treinamento e/ou
na capacidade destes em atender aos requisitos de sub- experiência, conforme requerido.
fornecimento, incluindo requisitos da qualidade. O forne-
cedor deve estabelecer e manter registros de subforne-
Os assuntos a serem abordados devem ser determina-
cedores qualificados.
dos, considerando-se as ferramentas, técnicas, metodo-
logias e recursos de computador específicos a serem
A seleção de subfornecedores, o tipo e a abrangência do
usados no desenvolvimento e gerenciamento do produto
controle exercido pelo fornecedor, devem depender do ti-
de “software”.
po do produto e, quando aplicável, de registros de capa-
cidade e de desempenho previamente demonstrados pe-
los subfornecedores. Também pode ser necessário incluir treinamento de ha-
bilidades e conhecimento do campo específico com o
O fornecedor deve garantir que os controles do sistema qual o “software” deve lidar.
da qualidade são eficazes.
Registros apropriados do treinamento/experiência de-
[NBR 19001:1990, 4.6.2] vem 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