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
1 Objetivo
2 Referências normativas
3 Definições
4 Sistema da qualidade - Estrutura
5 Sistema da qualidade - Atividades do ciclo de vida
6 Sistema da qualidade - Atividades de apoio (não
dependentes de fase)
Anexos
A - Referência cruzada entre NBR ISO 9000-3 e
NBR 19001
B - Referência cruzada entre as NBR 19001 e
NBR ISO 9000-3
Introdução
Com o progresso da tecnologia da informação, a 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 da
qualidade é fornecer orientação para a garantia da quali-
dade do “software”.
Os requisitos para um sistema da qualidade genérico, pa-ra
situaçõ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-
nesse campo da tecnologia de desenvolvimento tão
rápido, orientações adicionais para o estabeleci-
mento de sistemas da qualidade onde estejam envol-
vidos os produtos de “software”, levando-se em conta o
estágio atual da tecnologia.
A natureza do desenvolvimento de “software” é tal,
que algumas atividades estão relacionadas às fases
específicas do processo de desenvolvimento, 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, este
documento, no que se refere ao formato, não corres-
ponde diretamente à norma NBR 19001, sendo, por
essa razão, fornecidos índices de referência cruza-
da (anexos A e B) para facilitar a consulta àquela
norma.
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 desta
NBR ISO 9000-3 ao contrato.
Esta NBR ISO 9000-3 aborda basicamente situa-
ções em que um “software” específico é desenvol-vido
como parte de um contrato, de acordo com as
especificações do comprador. No entanto, os con-
 Cópia não autorizada
2 NBR ISO 9000-3/1993
ceitos descritos podem ser de igual valor em outras 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 nenhuma
delas pretende ser exaustiva. São apresentadas a título de
exemplo.
1 Objetivo
Esta NBR ISO 9000-3 define diretrizes para facilitar a
aplicação da NBR 19001 a organizações que desenvol-
vem, fornecem e mantêm “software”.
Destina-se a fornecer orientação quando um contrato
entre duas partes exigir a demonstração da capacidade
de um fornecedor em desenvolver, fornecer e manter
produtos de “software”.
Estas diretrizes destinam-se a descrever os controles e
métodos sugeridos para a produção de “software” que
atendam aos requisitos do comprador, evitando-se nã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 em
situações contratuais para produtos de “software”, quan-
do:
a) o contrato exigir, especificamente, esforço de pro-
jeto, e os requisitos do produto forem indicados
principalmente em termos de desempenho, ou
precisarem ser estabelecidos;
b) a confiança no produto puder ser obtida através
da demonstração adequada da capacidade de
desenvolvimento, fornecimento e manutenção de
um determinado fornecedor.
2 Referências normativas
As normas relacionadas contêm disposições que, atra-vés
de referências neste texto, constituem prescrições desta
NBR ISO 9000-3. Na data da publicação desta
NBR ISO 9000-3, as edições indicadas eram válidas.
Como todas as normas estão sujeitas a revisões, as par-
tes interessadas dos acordos baseados nesta
NBR 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 das
normas válidas atualmente.
ISO 2382-1:1984, Data processing - Vocabulary - Part 01:
Fundamental terms.
NBR ISO 8402:1993, Gestão da qualidade e garantia da
qualidade - 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 e
NBR ISO 8402, juntamente com as definições a seguir.
3.1 “software”: criação intelectual compreendendo os
programas, 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-ção
correlata, assim como dados designados para en-trega a
um usuário.
3.3 item de “software”: Qualquer parte identificável
de um produto de “software” em etapa intermediária ou
na etapa final do desenvolvimento.
3.4 desenvolvimento: Todas as atividades a serem 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 de
ciclo de vida específico, nem implica em um período de tempo
durante o desenvolvimento de um produto de “software”.
3.6 verificação (de “software”): Processo de avaliação
dos produtos de uma determinada fase a fim de asse-gurar
a correção e a consistência no que diz respeito
aos produtos e normas fornecidos como entrada para a
referida fase.
3.7 Validação (para "software"): Processo de avaliação
de "software" a fim de assegurar que este atende aos 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-tar
sua política e objetivos para a qualidade, e assumir o
compromisso com estes. O fornecedor deve assegurar
que esta política é entendida, implementada e mantida
em todos os níveis da organização.
[NBR 19001:1990 4.1.1]
 Cópia não autorizada
NBR ISO 9000-3/1993
4.1.1.2 Organização
4.1.1.2.1 Responsabilidade e autoridade
A responsabilidade, autoridade e interação de todo o
pessoal que administra, desempenha e verifica ativida-
des que influem na qualidade devem ser definidas, par-
ticularmente as do pessoal que necessita de autonomia
organizacional e autoridade para:
a) iniciar ações para prevenir a ocorrência de não-
conformidade em produto;
b) identificar e registrar quaisquer problemas de
qualidade do produto;
c) iniciar, recomendar ou providenciar soluções
através dos canais designados;
d) verificar a implementação das soluções;
e) controlar processamento posterior, entrega ou ins-
talação de produto não-conforme, até que a de-
ficiência ou condição insatisfatória tenha sido
corrigida.
[NBR 19001:1990, 4.1.2.1]
4.1.1.2.2 Recursos e pessoal para verificação
O fornecedor deve identificar seus requisitos internos de
verificação, prover recursos adequados e designar pessoal
treinado para as atividades de verificação.
As atividades de verificação devem incluir inspeção, ensaio
e monitorização de processos e/ou produto de projeto,
produção, instalação e de assistência técnica; análises
críticas de projeto e auditorias do sistema da qualidade,
dos processos e/ou produto, devem ser realizadas por
pessoal independente daquele que tem responsabilidade
direta pelo trabalho que está sendo executado.
[NBR 19001:1990, 4.1.2.2]
4.1.1.2.3 Representante da administração
O fornecedor deve designar um representante da admi-
nistração que, independentemente de outras responsa-
bilidades, tenha autoridade e responsabilidade definidas
para assegurar que os requisitos da NBR 19001 sejam
implementados e mantidos.
[NBR 19001:1990, 4.1.2.3]
4.1.1.3 Análise crítica pela administração
O sistema da qualidade adotado para atender aos 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ção
dos resultados de auditorias internas do sistema da qualida-
de, executadas pela administração do fornecedor ou, em seu
nome, pelo pessoal da administração com responsabilidade
direta pelo sistema.
[NBR 19001:1990, 4.1.3]
3
4.1.2 Responsabilidade da administração do comprador
O comprador deve cooperar com o fornecedor, a fim
de prover todas as informações necessárias em tempo
hábil e resolver itens pendentes.
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 fim
de 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 sistema
da 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 ao
longo 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 efetiva
do 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 documentados
de maneira sistemática e ordenada.
 Cópia não autorizada
4 NBR ISO 9000-3/1993
4.2.3 Plano da qualidade
O fornecedor deve preparar e documentar um plano da
qualidade, a fim de implementar atividades da qualida-
de para cada desenvolvimento de “software”, basean-
do-se no sistema da qualidade e assegurando que este
seja 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 de
auditorias internas da qualidade, planejadas e documen-
tadas, para verificar se as atividades da qualidade estão
em 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 as
ações de acompanhamento devem ser executadas con-
forme os procedimentos documentados.
Os resultados das auditorias devem ser documentados e
levados 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 encontradas
pela auditoria.
[NBR 19001:1990, 4.17].
Ver NBR ISO 10011-1.
4.4 Ação corretiva
O fornecedor deve estabelecer, documentar e manter
procedimentos para:
a) investigar a causa de produto não-conforme e a
ação corretiva necessária para prevenir repetição;
b) analisar todos os processos, operações de 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 potenciais
de 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 de
vida
5.1 Generalidades
Um projeto de desenvolvimento de “software” deve ser
organizado 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 modelo
de ciclo de vida utilizado. Qualquer descrição, orienta-
ção, requisito ou estrutura deve ser entendido como
indicação de que atende a todos os modelos de ciclo de
vida.
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 protegidas
adequadamente;
d) quaisquer requisitos diferentes daqueles da pro-
posta sejam resolvidos;
e) o fornecedor tenha capacitação para atender aos
requisitos 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 às
obrigações contratuais.
Devem ser mantidos registros de tais análises críticas
de contrato.
5.2.2 Itens de contrato relativos à qualidade
Os itens a seguir, entre outros, são freqüentemente
considerados pertinentes ao contrato:
a) critérios de aceitação;
b) tratamento das alterações nos requisitos do com-
prador durante o desenvolvimento;
c) tratamento de problemas detectados após a
aceitaçã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;
 Cópia não autorizada
NBR ISO 9000-3/1993
f) normas e procedimentos a serem utilizados;
g) requisitos relativos a cópia (ver item 5.9).
5.3 Especificação dos requisitos do comprador
5.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, aspectos
estes 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 estreita
cooperação com o comprador e obter dele a aprova-
ção, antes de passar ao estágio de desenvolvimento. A
especificação dos requisitos do comprador deve estar
sujeita ao controle de documentação e à gestão de con-
figuração, como parte da documentação de desenvolvi-
mento.
Todas as interfaces entre o produto de “software” e ou-tros
produtos de “software” ou de “hardware” devem ser
plenamente especificadas, diretamente ou por meio de
referência, na especificação dos requisitos do comprador.
5.3.2 Cooperação mútua
Durante o desenvolvimento da especificação dos 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 de
seus objetivos e referências a projetos relaciona-
dos, do comprador ou do fornecedor;
b) organização dos recursos do projeto, incluindo a
5
estrutura da equipe, as responsabilidades, o uso
de subcontratados e os recursos materiais a se-
rem empregados;
c) fases do desenvolvimento (conforme definidas
no item 5.4.2.1);
d) programação do projeto, identificando as tarefas
a 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 deve
ser 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 processo
ou 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 trabalho
em 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 às
fases de desenvolvimento e ao atendimento dos
requisitos especificados.
5.4.2.2 Gestão
O plano de desenvolvimento deve definir como o projeto
deve ser gerenciado, incluindo a identificação de:
a) programação de desenvolvimento, implementa-
ção e entregas;
b) controle da execução;
c) responsabilidades organizacionais, recursos e
atribuição de tarefas
d) interfaces organizacionais e técnicas entre os di-
ferentes grupos.
 Cópia não autorizada
6 NBR ISO 9000-3/1993
5.4.2.3 Métodos e ferramentas de desenvolvimento
O plano de desenvolvimento deve identificar métodos para
assegurar que todas as atividades sejam 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 assegurar
que questões importantes relativas aos recursos se-
jam resolvidas, além de assegurar a execução efetiva
dos 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 possa
ser verificado. Requisitos incompletos, ambíguos ou
conflitantes 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 de
desenvolvimento deve ser verificada, e ainda:
a) atender aos requisitos pertinentes;
b) conter ou fazer referência a critérios de aceitação
para que se passe às fases subseqüentes;
c) atender às práticas de desenvolvimento e con-
venções adequadas, quer estas tenham ou não
sido estipuladas nas informações de entrada;
d) identificar as características do produto que são
de importância crucial para seu funcionamento
seguro e adequado;
e) atender aos requisitos regulamentares aplicáveis.
5.4.6 Verificação de cada fase
O fornecedor deve elaborar um plano para verificação
de todas as saídas ao final de cada fase de desenvolvi-
mento.
A verificação do desenvolvimento deve estabelecer que
as saídas de cada fase atendam aos requisitos de en-
trada correspondentes, mediante a adoção de medidas
de controle de desenvolvimento, tais como:
a) análises críticas do desenvolvimento em pontos
apropriados das fases deste;
b) comparação do novo projeto com um projeto 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 requisitos
especificados foram atendidos, devem ser registrados e
verificados quando da conclusão destas ações. Apenas
saídas de desenvolvimento verificadas devem ser sub-
metidas à gerência de configuração e aceitas para uso
subseqü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 da
execução do desenvolvimento, e os itens pertinentes a
cada 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 (ver
5.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, incluindo
o 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 atividades
de verificação e de validação a serem realizadas;
d) planejamento detalhado de atividades de ensaio,
de verificação e de validação a serem realizadas,
incluindo a programação, os recursos e as auto-
ridades encarregadas da aprovação;
e) responsabilidades específicas para atividades da
qualidade, tais como:
- análises críticas e ensaios;
- gestão de configuração e controle de alteração;
- controle de defeitos e ação corretiva.
5.6 Projeto e implementação
5.6.1 Generalidades
As atividades de projeto e implementação são aquelas
que transformam as especificações dos requisitos do
comprador em um produto de “software”. Devido à com-
plexidade dos produtos de “software”, é imperativo que tais
atividades sejam realizadas de maneira disciplinada,
a fim de produzir um produto de acordo com a espe-
 Cópia não autorizada
NBR ISO 9000-3/1993
cificação, e não depender das atividades de ensaio e
de validação para assegurar a qualidade.
NOTA - A quantidade de informações a serem fornecidas para
o comprador deve ser acordada mutuamente pelas partes,
uma vez que os processos de projeto e implementação são 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ências
anteriores de projeto, o fornecedor deve evitar a
repetição de problemas idênticos ou semelhantes.
d) Processos subseqüentes: o produto deve ser
projetado de modo a facilitar os ensaios, manu-
tenção e uso.
5.6.3 Implementação
Além dos requisitos aplicáveis a todas as atividades de
desenvolvimento, 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, bem
como de comentários adequados, devem ser es-
pecificadas e observadas.
b) Metodologias de implementação: o fornecedor
deve usar métodos e ferramentas de implementa-
ção apropriados para atender aos requisitos do
comprador.
5.6.4 Análises críticas
O fornecedor deve realizar análises críticas, a fim de 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ão
deve prosseguir até que as conseqüências de todas as
deficiê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 desde
um item individual de “software” até o produto de “soft-
7
ware” completo. Há várias abordagens diferentes para
os ensaios e a integração.
Em alguns casos, a validação, os ensaios de campo e os
ensaios de aceitação podem ser uma mesma atividade.
O documento que descreve o plano de ensaio pode ser
um 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 criticamente
os planos de ensaios, especificações e procedimentos,
antes de iniciar as atividades de ensaio. Os seguintes
pontos devem ser considerados:
a) planos para itens de “software”, integração, ensaio
de sistema e ensaio de aceitação;
b) casos e dados de ensaios e resultados espera-
dos;
c) tipos de ensaios a serem realizados, como, por
exemplo: 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 registrados
conforme 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áveis
notificados, para que eles possam ser seguidos
até 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 devem
ser avaliadas;
e) a configuração de “hardware” e de “software” de-ve
ser considerada e documentada.
5.7.4 Validação
Antes de liberar o produto para entrega e aceitação do
comprador, o fornecedor deve validar sua operação co-
mo um produto completo, quando possível, sob condi-
ções semelhantes às do ambiente de aplicação, confor-
me especificado no contrato.
 Cópia não autorizada
8 NBR ISO 9000-3/1993
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 fornecedor
e 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, deve
ser 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 da
entrega. Ao providenciar-se a cópia, deve-se considerar:
a) o número de cópias de cada item de “software” a
ser entregue;
b) o meio físico de fornecimento para cada item de
“software”, incluindo formato e versão, em forma
inteligível;
c) a estipulação da documentação requerida, tais
como manuais e guias de usuário;
d) definição e acordo quanto aos direitos autorais
e licenças;
e) custódia de cópias-mestre e de segurança, quando
aplicável, incluindo planos de recuperação,
em caso de desastres;
f) o período de obrigação do fornecedor para o su-
primento de cópias.
5.9.2 Entrega
Prescrições devem ser feitas para verificar a correção e
a 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 fora
do horário normal e nos fins de semana;
b) o acesso às instalações do comprador (crachás
de segurança, senhas, acompanhantes);
c) a disponibilidade de pessoal capacitado;
d) a disponibilidade e acesso aos sistemas e equi-
pamentos do comprador;
e) a necessidade de validação como parte de cada
instalação deve ser determinada em contrato;
f) um procedimento formal para aprovação de cada
instalaçã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 deve
estabelecer e manter procedimentos para realizar
atividades 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 o
período de tempo, durante o qual ela deve ser efetua-
da, devem ser especificados no contrato. A seguir são
apresentados exemplos de tais itens:
a) programa(s);
b) dados e suas estruturas;
c) especificações;
d) documentos para o comprador e/ou usuário;
e) documentos para o uso do fornecedor.
 Cópia não autorizada
NBR ISO 9000-3/1993
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 acordada
entre o fornecedor e o comprador.
5.10.4 Organização de suporte
Pode ser necessário estabelecer uma organização, com
representantes do fornecedor e do comprador, para dar
suporte às atividades de manutenção. Como as 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ção
de problemas, modificações de interface, expansão fun-
cional ou aprimoramento do desempenho), realizadas
durante a manutenção, devem ser feitas, tanto quanto
possí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 controle
de documentos e gestão de configuração:
a) Resolução de problemas: envolve a detecção, a
análise e a correção de não-conformidades de
“software” que possam causar problemas ope-
racionais. Soluções temporárias podem ser usa-
das para minimizar o tempo fora de operação,
efetuando-se, posteriormente, as modificações
definitivas.
b) Modificações de interface: podem ser requeri-
das, quando acréscimos ou alterações são feitos
no sistema de “hardware”, ou nos componentes,
controlados pelo “software”.
c) Expansão funcional ou aprimoramento do 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
9
para a apresentação de relatórios de manutenção devem
ser estabelecidas e acordadas entre o fornecedor e o
comprador.
Os registros de manutenção devem incluir, para cada
item de “software” em que se realiza a manutenção, os
seguintes tópicos:
a) lista de solicitações de assistência ou de relató-
rios de problemas que tiverem sido recebidos, e a
situação atual de cada um deles;
b) organização responsável pelo atendimento às re-
quisições para assistência ou implementação
das 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 falhas
e 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 e
documentar os procedimentos para a incorporação de
alterações em um produto de “software”, resultantes da
necessidade de manter o desempenho.
Tais procedimentos devem incluir:
a) regras básicas para determinar onde as corre-
ções (“patches”) localizadas podem ser incorpora-
das, ou quando é necessária a liberação de uma
có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 comprador
de implementar alterações a qualquer momento;
c) métodos pelos quais o comprador deve ser aler-
tado sobre alterações atuais ou planejadas para
o 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 a
identificação, controle e acompanhamento das versões
 Cópia não autorizada
10
de cada item de “software”. Em muitos casos, versões
anteriores, 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 cada
item de “software”;
b) identificar as versões de cada item de “software”
que, juntas, constituem uma versão específica de
um produto completo;
c) identificar a situação de elaboração de produtos
de “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, todas
as 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 uma
delas;
b) atividades de gestão de configuração a serem
realizadas;
c) ferramentas, técnicas e metodologias de gestão
de configuração a serem usadas;
d) o estágio ao qual os itens devem ser trazidos sob
o controle de configuração.
6.1.3 Atividades de gestão de configuração
6.1.3.1 Identificação e rastreabilidade de configuração
O fornecedor deve estabelecer e manter procedimen-
tos para identificar itens de “software” durante todas as
fases, desde a especificação até o desenvolvimento, có-
pia e entrega.
Estes procedimentos podem também ser aplicados
após a entrega do produto, quando requerido pelo contra-
to. Cada item de “software” individual deve possuir uma
identificação única.
Procedimentos devem ser aplicados para assegurar
que 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;
NBR ISO 9000-3/1993
b) todas as ferramentas de desenvolvimento que
afetam 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 feita
de tal modo que a relação entre o item e os requisitos do
contrato possa ser demonstrada.
Para produtos já liberados, deve haver procedimentos
para 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 e
autorizar quaisquer alterações em itens de “software”
sob gestão de configuração. Todas as alterações em
itens de “software” devem ser realizadas de acordo com
estes procedimentos.
Antes da aceitação de uma alteração, sua validade deve
ser confirmada, e os efeitos causados sobre outros itens
devem ser identificados e examinados.
Devem ser fornecidos os métodos para informar aos
envolvidos quanto às alterações e para demonstrar a
rastreabilidade entre as alterações e as partes 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 itens
de “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 procedimentos
para controlar todos os documentos relacionados ao
conteúdo desta Norma, abrangendo:
a) a determinação dos documentos que devem es-
tar sujeitos aos procedimentos de controle de
documentos;
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 devem
ser aplicados a documentos pertinentes, incluindo:
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
b) documentos de planejamento, descrevendo o pla-
nejamento e a execução de todas as atividades
do 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 essenciais
para 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, deve
ser 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ãos
que 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 a
revisão atual dos documentos, a fim de evitar a utilização
de documentos não aplicáveis.
Os documentos devem ser reemitidos após incorporação
de um número razoável de alterações.
[NBR 19001:1990, 4.5.2]
6.3 Registros da qualidade
O fornecedor deve estabelecer e manter procedimentos
para identificar, coletar, indexar, arquivar, armazenar, man-
ter e dispor os registros da qualidade.
Os registros da qualidade devem ser mantidos para de-
11
monstrar a obtenção da qualidade requerida e a efetiva
operaçã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 e
identificáveis em relação ao produto envolvido. Os regis-
tros da qualidade devem ser armazenados e mantidos de
tal 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 acordado
em 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 devem
ser 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 do
cliente. O indicador selecionado deve ser descrito de
tal modo que os resultados possam ser comparáveis.
O fornecedor de produtos de “software” deve coletar e
agir de acordo com indicadores quantitativos da quali-
dade destes produtos. Estes indicadores quantitativos
devem ser usados para os seguintes fins:
a) coletar dados e relatar medidas em uma base
regular;
b) identificar o nível atual do desempenho em cada
indicador;
c) tomar ações remediadoras, caso os níveis dos 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 quantitativos
da 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 desenvolvimento
está reduzindo a probabilidade de que sejam in-
troduzidos defeitos, ou que quaisquer defeitos in-
troduzidos não sejam detectados.
 Cópia não autorizada
12
Assim como ocorre em relação a indicadores de produ-
tos, o importante é que os níveis sejam conhecidos e
utilizados 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ções
de 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 e
revisá-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 aprovar
os documentos de aquisição, quanto à adequação dos
requisitos 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 desenvolvimento
do produto requerido.
6.7.2 Avaliação de subfornecedores
O fornecedor deve selecionar subfornecedores, baseado
na 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 do
controle 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 sistema
da qualidade são eficazes.
[NBR 19001:1990, 4.6.2]
NBR ISO 9000-3/1993
6.7.3 Validação de produtos adquiridos
O fornecedor é responsável pela validação do trabalho
subcontratado, o que exige que ele conduza o projeto e
outras análises críticas de modo coerente com seu pró-
prio sistema da qualidade e, neste caso, tais requisitos
devem ser incluídos no subcontrato. Quaisquer requisi-
tos de ensaios de aceitação, pelo fornecedor, do trabalho
subcontratado devem ser incluídos da mesma maneira.
Quando especificado no contrato, o comprador, ou seu
representante, deve ter o direito de verificar, na fonte ou
no recebimento, se o produto adquirido está em 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, tal
validação não deve ser utilizada pelo fornecedor como
evidê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” fornecidos
pelo comprador, ou por terceira parte, pode ser requerido
ao fornecedor. O fornecedor deve estabelecer e manter
procedimentos para validação, armazenamento, proteção
e manutenção de tais produtos. Deve-se considerar o
suporte de cada produto de “software” em qualquer acordo
de manutenção relacionado ao produto a ser entregue.
Produtos fornecidos pelo comprador que sejam inade-
quados para o uso devem ser registrados e relatados ao
comprador. A validação pelo fornecedor não isenta o
comprador da responsabilidade de prover produtos
aceitáveis.
6.9 Treinamento
O fornecedor deve estabelecer e manter procedimen-
tos para identificar as necessidades de treinamento, e
providenciá-lo para todo o pessoal que executa ativida-
des que influenciam a qualidade. O pessoal que execu-
ta tarefas específicas designadas deve ser qualificado
com base em educação adequada, treinamento e/ou
experiência, conforme requerido.
Os assuntos a serem abordados devem ser determina-
dos, considerando-se as ferramentas, técnicas, metodo-
logias e recursos de computador específicos a serem
usados no desenvolvimento e gerenciamento do produto
de “software”.
Também pode ser necessário incluir treinamento de ha-
bilidades e conhecimento do campo específico com o
qual o “software” deve lidar.
Registros apropriados do treinamento/experiência de-
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