Cópia não autorizada

NBR ISO/IEC 12207

OUT 1998

Tecnologia de informação - Processos

de ciclo de vida de software
ABNT-Associação
Brasileira de
Normas Técnicas

Sede:
Rio de Janeiro
Av. Treze de Maio, 13 - 28º andar
CEP 20003-900 - Caixa Postal 1680
Rio de Janeiro - RJ
Tel.: PABX (021) 210 -3122
Fax: (021) 220-1762/220-6436
Endereço Telegráfico:
NORMATÉCNICA Origem: Projeto 21:101.03.002:1997
CB-21 - Comitê Brasileiro de Processamento de Dados
CE-21:101.03 - Processos de Ciclo de Vida de Software
NBR ISO/IEC 12207 - Information technology - Software life cycle process
Descriptors: Data processing. Data processing equipment. Computers.
Computer software. Life cycle
Esta Norma é equivalente à ISO/IEC 12207:1995
Válida a partir de 30.11.1998
Copyright © 1998, Palavras-chave: Processamento de dados. Equipamento de 35 páginas
ABNT–Associação Brasileira
de Normas Técnicas
processamento de dados. Computadores.
Printed in Brazil/ Software. Ciclo de vida. Informação
Impresso no Brasil tecnológica
Todos os direitos reservados

Sumário Prefácio
Prefácio
Introdução A ABNT - Associação Brasileira de Normas Técnicas - é
1 Objetivo e campo de aplicação o Fórum Nacional de Normalização. As Normas Brasi-
2 Referências normativas leiras, cujo conteúdo é de responsabilidade dos Comitês
3 Definições Brasileiros (CB) e dos Organismos de Normalização
4 Aplicação desta Norma Setorial (ONS), são elaboradas por Comissões de Estudo
5 Processos fundamentais de ciclo de vida (CE), formadas por representantes dos setores envol-
5.1 Processo de aquisição vidos, delas fazendo parte: produtores, consumidores e
5.2 Processo de fornecimento neutros (universidades, laboratórios e outros).
5.3 Processo de desenvolvimento
5.4 Processo de operação
5.5 Processo de manutenção Os Projetos de Norma Brasileira, elaborados no âmbito
6 Processos de apoio de ciclo de vida dos CB e ONS, circulam para Votação Nacional entre os
6.1 Processo de documentação associados da ABNT e demais interessados.
6.2 Processo de gerência de configuração
6.3 Processo de garantia da qualidade A NBR ISO/IEC 12207 foi preparada pela CE-21:101.03 -
6.4 Processo de verificação Processos de Ciclo de Vida de Software, do CB-21 - Co-
6.5 Processo de validação mitê Brasileiro de Processamento de Dados.
6.6 Processo de revisão conjunta
6.7 Processo de auditoria
Esta Norma contém o anexo A, que é normativo, e os
6.8 Processo de resolução de problema
anexos B e C, que são apenas informativos.
7 Processos organizacionais de ciclo de vida
7.1 Processo de gerência
7.2 Processo de infra-estrutura Introdução
7.3 Processo de melhoria
7.4 Processo de treinamento Software é uma parte fundamental da tecnologia de in-
ANEXOS formação e de sistemas convencionais, tais como siste-
A Processo de adaptação mas de transporte, militares, da área médica e financeiros.
B Orientação para a adaptação Tem havido uma proliferação de normas, procedimentos,
C Orientações sobre processos e organizações métodos, ferramentas e ambientes de desenvolvimento
D Bibliografia e de gerência de software. Esta proliferação tem criado
Cópia não autorizada

2 NBR ISO/IEC 12207:1998

dificuldades na gerência e engenharia de software, Esta Norma foi escrita para adquirentes de sistemas e
principalmente na integração de produtos e serviços. produtos e serviços de software, e para fornecedores,
A disciplina de software necessita migrar desta proli- desenvolvedores, operadores, mantenedores, gerentes,
feração para uma estrutura comum que possa ser usada gerentes de garantia da qualidade e usuários dos pro-
por profissionais de software para “falar a mesma língua” dutos de software.
na criação e gerência de software. Esta Norma provê tal
estrutura comum. 1.3 Adaptação desta Norma

A estrutura cobre o ciclo de vida de software desde a Esta Norma contém um conjunto de processos, atividades
concepção de idéias até a descontinuação do software, e tarefas projetado para ser adaptado de acordo com
e consiste nos processos de aquisição e fornecimento cada projeto de software. O processo de adaptação
de produtos e serviços de software. Adicionalmente, a consiste na supressão de processos, atividades e tarefas
estrutura provê o controle e a melhoria destes processos. não aplicáveis.

NOTA - Processos, atividades e tarefas, específicos ou es-

Os processos desta Norma formam um conjunto abran-
peciais, podem ser adicionados ao contrato.
gente. Uma organização, dependendo de seu objetivo,
pode selecionar um subconjunto apropriado para
1.4 Conformidade
satisfazê-lo. Esta Norma é, portanto, projetada para ser
adaptada para uma organização, projeto ou aplicação A conformidade a esta Norma é definida como a execução
específicos. Também é projetada para ser utilizada de todos os processos, atividades e tarefas, selecionados
quando o software é uma entidade independente ou desta Norma no processo de adaptação (anexo A), para
embutida ou integrada a um sistema. o projeto de software. A execução de um processo ou
uma atividade é concluída quando todas as suas tarefas
1 Objetivo e campo de aplicação requeridas são executadas de acordo com os critérios
preestabelecidos e com os requisitos especificados no
1.1 Objetivo
contrato, quando aplicável.
Esta Norma estabelece uma estrutura comum para os Qualquer organização (por exemplo, estatal ou privada)
processos de ciclo de vida de software, com terminologia que exija o cumprimento desta Norma como uma con-
bem definida, que pode ser referenciada pela indústria dição de negócio, é responsável por especificar e dispo-
de software. A estrutura contém processos, atividades e nibilizar o conjunto mínimo de processos, atividades e
tarefas que servem para ser aplicadas durante a aquisição tarefas requeridos, que constitui a conformidade dos for-
de um sistema que contém software, de um produto de necedores a esta Norma.
software independente ou de um serviço de software, e
durante o fornecimento, desenvolvimento, operação e 1.5 Limitações
manutenção de produtos de software. O termo software
inclui a parte de software de firmware. Esta Norma descreve a arquitetura dos processos de ciclo
de vida de software, mas não especifica os detalhes de
Esta Norma também provê um processo que pode ser como implementar ou executar as atividades e tarefas
utilizado para definir, controlar e melhorar os processos incluídas nos processos.
de ciclo de vida de software.
Esta Norma não pretende prescrever o nome, formato ou
1.2 Campo de aplicação conteúdo explícito da documentação a ser produzida.
Esta Norma pode requerer o desenvolvimento de docu-
Esta Norma aplica-se à aquisição de sistemas, produtos mentos de mesma categoria ou tipo; por exemplo, dife-
e serviços de software, para o fornecimento, o desenvolvi- rentes planos. Esta Norma, contudo, não sugere que tais
mento, a operação e a manutenção de produtos de soft- documentos sejam desenvolvidos ou emitidos separa-
ware, e para a parte de software de firmware, quer sejam damente ou combinados de alguma forma. Estas decisões
executados interna ou externamente a uma organização. são deixadas para o usuário desta Norma.
Alguns aspectos necessários de definição de sistemas,
para prover o contexto a produtos e serviços de software, Esta Norma não prescreve um modelo específico de ciclo
estão incluídos. de vida ou método de desenvolvimento de software. As
partes envolvidas com esta Norma são responsáveis pela
NOTA - Os processos utilizados durante o ciclo de vida de seleção de um modelo de ciclo de vida para o projeto de
software necessitam ser compatíveis com os processos software e pelo mapeamento dos processos, atividades
utilizados durante o ciclo de vida de sistema. e tarefas desta Norma dentro deste modelo. As partes
envolvidas são também responsáveis pela seleção e
Esta Norma é destinada para ser utilizada em uma relação aplicação dos métodos de desenvolvimento de software
entre duas partes e pode ser igualmente aplicada quando e pela execução das atividades e tarefas adequadas ao
as duas partes forem da mesma organização. A relação projeto de software.
pode ser desde um acordo informal até um contrato le-
gal. Esta Norma pode ser utilizada por uma única parte Esta Norma não pretende entrar em conflito com quais-
por meio de tarefas impostas a ela mesma. quer políticas, normas ou procedimentos já existentes na
organização. Entretanto, qualquer conflito necessita ser
Esta Norma não foi concebida para produtos de software resolvido e quaisquer condições e situações de sobrepo-
de prateleira, a menos que eles estejam incorporados sição precisam ser citadas por escrito como exceções
dentro de um produto encomendado. para a aplicação desta Norma.
Cópia não autorizada

NBR ISO/IEC 12207:1998 3

Ao longo desta Norma, “deve” é utilizado para expressar 3.4 auditoria: Processo conduzido por uma pessoa auto-
uma obrigação entre duas ou mais partes; “deverá” para rizada, com o objetivo de prover um julgamento indepen-
expressar uma declaração de objetivo ou intenção de dente de produtos e processos de software, a fim de ava-
uma das partes; “deveria” para expressar uma reco- liar a conformidade com seus requisitos.
mendação entre várias possibilidades; e “pode” para in-
dicar uma ação permitida dentro dos limites desta Norma. 3.5 linha básica (baseline): Versão formalmente apro-
vada de um item de configuração, independente de mídia,
Nesta Norma, as listas definidas para as tarefas não pre- formalmente definida e fixada em um determinado mo-
tendem ser exaustivas, porém usadas como exemplos. mento durante o ciclo de vida do item de configuração.

2 Referências normativas 3.6 item de configuração: Entidade dentro de uma con-

figuração que satisfaz uma função de uso final e que
pode ser identificada de forma única em um determinado
As normas relacionadas a seguir contêm disposições que,
ponto de referência.
ao serem citadas neste texto, constituem prescrições para
esta Norma. As edições indicadas estavam em vigor no
3.7 contrato: Acordo realizado entre duas partes, respal-
momento desta publicação. Como toda norma está sujeita
dado pela lei, ou acordo interno similar restrito a uma or-
a revisão, recomenda-se àqueles que realizam acordos
ganização, para o fornecimento de serviços de software
com base nesta que verifiquem a conveniência de se
ou para o fornecimento, desenvolvimento, produ-
usarem as edições mais recentes das normas citadas a
ção, operação ou manutenção de um produto de
seguir. A ABNT possui a informação das normas em vigor
software.
em um dado momento.
3.8 desenvolvedor: Organização que executa ati-
ISO/AFNOR:1989 - Dictionary of computer science vidades de desenvolvimento (incluindo análise de re-
quisitos, projeto, testes até aceitação) durante o processo
ISO/IEC 2382-1:1993 - Information technology - de ciclo de vida de software.
Vocabulary - Part 1: Fundamental terms
3.9 avaliação: Determinação sistemática do grau de
ISO/IEC 2382-20:1990 - Information technology - atendimento de uma entidade em relação aos critérios
Vocabulary - Part 20: System development para ela estabelecidos.

NBR ISO 8402:1994 - Gestão da qualidade e garantia 3.10 firmware: Combinação de um dispositivo de
da qualidade - Terminologia hardware e instruções ou dados de computador que
residem como um software somente para leitura no dispo-
NBR ISO 9001:1994 - Sistema da qualidade - Modelo sitivo de hardware. Este software não pode ser direta-
para garantia da qualidade em projeto, desenvol- mente modificado por um programa.
vimento, produção, instalação e serviços associados
3.11 modelo de ciclo de vida: Estrutura contendo pro-
cessos, atividades e tarefas envolvidas no desenvol-
ISO/IEC 9126:1991 1) - Information technology -
vimento, operação e manutenção de um produto de
Software product evaluation - Quality characteristics
software, abrangendo a vida do sistema desde a definição
and guidelines for their use.
de seus requisitos até o término de seu uso.
3 Definições 3.12 mantenedor: Organização que executa atividades
de manutenção.
Para os propósitos desta Norma as definições contidas
nas NBR ISO 8402, ISO/IEC 2382-1 e ISO/IEC 2382-20 3.13 monitoração: Exame da situação das atividades de
aplicam-se em conjunto com as seguintes definições: um fornecedor e dos seus resultados, efetuado pelo adqui-
rente ou uma terceira parte.
NOTA - Um produto pode ser entendido como uma parte de um
sistema, quando aplicável. 3.14 item que não será entregue: Hardware ou produto
de software cuja entrega não é exigida em contrato, mas
3.1 adquirente: Uma organização que adquire ou obtém pode ser utilizado no desenvolvimento do produto de
um sistema, produto de software ou serviço de software software.
de um fornecedor.
3.15 produto de prateleira: Produto já desenvolvido e
NOTA - O adquirente poderia ser: comprador, cliente, proprietário
disponível para utilização na forma em que se encontra
ou usuário.
ou com modificação.

3.16 operador: Organização que opera o sistema.

3.2 aquisição: Processo de obtenção de um sistema,
produto de software ou serviço de software. 3.17 processo: Conjunto de atividades inter-relaciona-
das, que transforma entradas em saídas.
3.3 acordo: Definição de termos e condições sob a qual
o relacionamento de trabalho entre as partes deverá ser NOTA - O termo “atividades” engloba a utilização de recursos.
conduzido. [Ver NBR ISO 8402:1994, 1.2]

1)
Para efeitpo de norma brasileira utilizar a NBR 13596:1996.
Cópia não autorizada

4 NBR ISO/IEC 12207:1998

3.18 qualificação: Processo de demonstrar se uma 3.26 produto de software: Conjunto de programas de
entidade é capaz de atender os requisitos especificados. computador, procedimentos e possível documentação e
[Ver NBR ISO 8402:1994, 2.13] dados associados.

3.27 serviço de software: Execução de atividades,

3.19 requisito de qualificação: Conjunto de critérios ou
trabalho ou obrigações relacionados ao produto de
de condições que, quando atendido, qualifica um produto
software, tais como seu desenvolvimento, manutenção e
de software quanto à conformidade às suas especifi-
operação.
cações e quanto à sua utilização no seu ambiente-alvo.
3.28 unidade de software: Parte de código compilável
3.20 teste de qualificação: Teste conduzido pelo desen- separadamente.
volvedor e testemunhado pelo adquirente (quando apro-
priado), para demonstrar que o produto de software 3.29 descrição de tarefas: Documento utilizado pelo
atende as suas especificações e está pronto para utili- adquirente como um meio para descrever e especificar
zação no seu ambiente-alvo. as tarefas a serem executadas conforme o contrato.

3.30 fornecedor: Organização que firma um contrato com

3.21 garantia da qualidade: Conjunto de atividades pla- o adquirente para fornecimento de um sistema, produto
nejadas e sistemáticas, implementadas no sistema da de software ou serviço de software conforme os termos
qualidade e demonstradas como necessárias, para pro- do contrato.
ver confiança adequada de que uma entidade atenderá
os requisitos para a qualidade. NOTAS

1 O termo “fornecedor” é sinônimo de contratado, produtor,

NOTAS
vendedor ou distribuidor.

1 A garantia da qualidade visa, simultaneamente, aos objetivos 2 O adquirente pode designar uma parte de sua organização
internos e externos: como fornecedor.

3.31 sistema: Conjunto integrado que consiste em um

a) Garantia da qualidade interna: dentro de uma orga-
ou mais processos, hardware, software, recursos e
nização, a garantia da qualidade provê confiança à admi-
pessoas, capaz de satisfazer uma necessidade ou
nistração;
objetivo definido.

b) Garantia da qualidade externa: em situações contratuais 3.32 cobertura de teste: Extensão em que os casos de
ou outras, a garantia da qualidade provê confiança aos teste dos requisitos de um sistema ou produto de
clientes ou a outros. software são testados.

3.33 testabilidade: Extensão em que um teste objetivo

2 Algumas ações do controle da qualidade e da garantia da qua-
e factível pode ser projetado para determinar se um requi-
lidade são inter-relacionadas.
sito é atendido.

3 Se os requisitos para a qualidade não refletirem inteiramente 3.34 usuário: Indivíduo ou organização que utiliza um
as necessidades do usuário, a garantia da qualidade pode não sistema em operação para executar uma função espe-
prover a confiança adequada. cífica.

NOTA - O usuário pode executar outros papéis, tais como

[NBR ISO 8402:1994, 3.5]
adquirente, desenvolvedor ou mantenedor.

3.22 liberação (release): Versão particular de um item 3.35 validação: Confirmação, por exame e fornecimento
de configuração que é colocada à disposição para um de evidência objetiva, de que os requisitos específicos,
propósito específico (por exemplo, liberação para tes- para um determinado uso pretendido, são atendidos.
te).
NOTAS

3.23 pedido de proposta: Documento utilizado pelo adqui- 1 Nas atividades de projeto e desenvolvimento, a validação se
rente como meio para divulgar aos potenciais fornece- refere ao processo de examinar um produto para determinar
dores sua intenção de adquirir um sistema, produto de sua conformidade com as necessidades do usuário.
software ou serviço de software especificado.
2 A validação é feita normalmente no produto final sob condições
3.24 descontinuação: Cancelamento do suporte ativo de operação definidas, podendo, contudo, tornar-se necessária
pela organização de operação e manutenção, substi- em fases anteriores.
tuição total ou parcial por um novo sistema, ou instalação
3 O termo “validado” é usado para designar o estado após a va-
de um sistema atualizado.
lidação.

3.25 segurança: Proteção de informações e dados de 4 “Validações múltiplas” podem ser realizadas se existirem dife-
modo que pessoas ou sistemas não autorizados não rentes usos pretendidos.
possam lê-los ou modificá-los e que pessoas ou sistemas
autorizados não tenham acesso negado a eles. [NBR ISO 8402:1994, 2.18]
Cópia não autorizada

NBR ISO/IEC 12207:1998 5

3.36 verificação: Confirmação, por exame e fornecimento 4) Processo de operação (subseção 5.4). Define as ativi-
de evidência objetiva, do atendimento aos requisitos es- dades do operador, organização que provê serviço de
pecificados. operação de um sistema computacional, no seu ambiente
de funcionamento, para seus usuários.
NOTAS
5) Processo de manutenção (subseção 5.5). Define as
1 Nas atividades de projeto e desenvolvimento, a verificação atividades do mantenedor, organização que provê o ser-
refere-se ao processo de examinar o resultado de dada atividade viço de manutenção do produto de software, isto é, geren-
para determinar sua conformidade com os requisitos estabe- ciando as modificações no produto de software para man-
lecidos para a mesma atividade. tê-lo atualizado e em perfeita operação. Este processo
inclui a migração e a descontinuação do produto de
2 O termo “verificado” é usado para designar o estado após a
software.
verificação.
4.1.1.2 Processos de apoio de ciclo de vida
[NBR ISO 8402:1994, 2.17]
Os processos de apoio de ciclo de vida (seção 6) cons-
3.37 versão: Instância identificada de um item.
tituem um conjunto de oito processos. Um processo de
NOTA - Modificações em uma versão de produto de software, apoio auxilia um outro processo como uma parte inte-
resultando em uma nova versão, requerem uma ação de gerência grante, com um propósito distinto, e contribui para o
de configuração. sucesso e qualidade do projeto de software. Um processo
de apoio é empregado e executado, quando necessário,
4 Aplicação desta Norma por outro processo. Os processos de apoio são:

Esta seção apresenta os processos de ciclo de vida de 1) Processo de documentação (subseção 6.1). Define as
software que podem ser empregados para adquirir, atividades para registro da informação produzida por um
fornecer, desenvolver, operar e manter produtos de processo de ciclo de vida.
software. O objetivo é prover um guia para os usuários
desta Norma para que eles possam orientar-se na mesma 2) Processo de gerência de configuração (subseção 6.2).
e aplicá-la criteriosamente. Define as atividades de gerência de configuração.

4.1 Organização desta Norma 3) Processo de garantia da qualidade (subseção 6.3).

Define as atividades para garantir objetivamente que os
4.1.1 Processos de ciclo de vida produtos e processos de software estão em conformidade
com seus requisitos especificados e aderem aos seus
Esta Norma agrupa as atividades que podem ser execu- planos estabelecidos. Revisões conjuntas, auditorias,
tadas durante o ciclo de vida de software em cinco pro- verificação e validação podem ser utilizadas como
cessos fundamentais, oito processos de apoio e quatro técnicas para garantia da qualidade.
processos organizacionais. Cada processo de ciclo de
vida é dividido em um conjunto de atividades; cada 4) Processo de verificação (subseção 6.4). Define as
atividade é então dividida em um conjunto de tarefas. atividades (para o adquirente, o fornecedor, ou uma parte
Uma seção numerada por a.b denota um processo, a.b.c independente) para verificação dos produtos de software,
uma atividade e a.b.c.d uma tarefa. Estes processos de em profundidade variável, dependendo do projeto de
ciclo de vida são introduzidos a seguir e ilustrados na software.
figura 1.
5) Processo de validação (subseção 6.5). Define as
4.1.1.1 Processos fundamentais de ciclo de vida atividades (para o adquirente, o fornecedor ou uma parte
independente) para validação dos produtos de software
Os processos fundamentais de ciclo de vida (seção 5) do projeto de software.
constituem um conjunto de cinco processos que atendem
as partes fundamentais (pessoa ou organização) durante 6) Processo de revisão conjunta (subseção 6.6). Define
o ciclo de vida de software. Uma parte fundamental é as atividades para avaliação da situação e produtos de
aquela que inicia ou executa o desenvolvimento, ope- uma atividade. Este processo pode ser empregado por
ração ou manutenção dos produtos de software. Estas qualquer uma das duas partes, onde uma delas (parte
partes fundamentais são o adquirente, o fornecedor, o revisora) revisa a outra parte (parte revisada) em um fórum
desenvolvedor, o operador e o mantenedor do software. conjunto.
Os processos fundamentais são:
7) Processo de auditoria (subseção 6.7). Define as ati-
1) Processo de aquisição (subseção 5.1). Define as ati- vidades para determinar a conformidade com requisitos,
vidades do adquirente, organização que adquire um sis- planos e contrato. Este processo pode ser empregado
tema, produto de software ou serviço de software. por qualquer uma das duas partes, onde uma delas (parte
auditora) audita os produtos de software ou atividades
2) Processo de fornecimento (subseção 5.2). Define as da outra parte (parte auditada).
atividades do fornecedor, organização que provê o sis-
tema, produto de software ou serviço de software ao 8) Processo de resolução de problema (subseção 6.8).
adquirente. Define um processo para análise e remoção dos
problemas (incluindo não-conformidades), independente
3) Processo de desenvolvimento (subseção 5.3). Define da sua natureza ou origem, que forem descobertos du-
as atividades do desenvolvedor, organização que define rante a execução dos processos de desenvolvimento, de
e desenvolve o produto de software. operação, de manutenção ou de outros processos.
Cópia não autorizada

6 NBR ISO/IEC 12207:1998

5. Processos fundamentais de ciclo de vida 6. Processos de apoio de ciclo de vida

5.1 Aquisição 6.1 Documentação

5.2 Fornecimento 6.2 Gerência de configuração

6.3 Garantia de qualidade

5.4 Operação

6.4 Verificação
5.3 Desenvolvimento

6.5 Validação

5.5 Manutenção 6.6 Revisão conjunta

6.7 Auditoria

6.8 Resolução de problema

7. Processos organizacionais de ciclo de vida

7.1 Gerência 7.2 Infra-estrutura

7.3 Melhoria 7.4 Treinamento

Figura 1 - Estrutura desta Norma

4.1.1.3 Processos organizacionais de ciclo de vida 3) Processo de melhoria (subseção 7.3). Define as ativi-
dades básicas que uma organização (isto é, adquirente,
Os processos organizacionais de ciclo de vida (seção 7) fornecedor, desenvolvedor, operador, mantenedor, ou o
constituem um conjunto de quatro processos. Eles são gerente de outro processo) executa para estabe-
empregados por uma organização para estabelecer e lecer, medir, controlar e melhorar seu processo de ciclo
implementar uma estrutura subjacente, constituída de pro- de vida.
cessos de ciclo de vida e pessoal associados, e melhorar
continuamente a estrutura e os processos. Eles são tipica-
mente empregados fora do domínio de projetos e con- 4) Processo de treinamento (subseção 7.4). Define as
tratos específicos; entretanto, ensinamentos destes pro- atividades para prover pessoal adequadamente treinado.
jetos e contratos contribuem para a melhoria da orga-
nização. Os processos organizacionais são: 4.1.2 Processo de adaptação

1) Processo de gerência (subseção 7.1). Define as

atividades básicas da gerência, incluindo gerência de O anexo A define as atividades básicas necessárias para
projeto, durante um processo de ciclo de vida. executar as adaptações desta Norma. O anexo B contém
orientação para a adaptação dos requisitos desta Norma;
2) Processo de infra-estrutura (subseção 7.2). Define as ele relaciona os fatores-chave sobre os quais as decisões
atividades básicas para o estabelecimento da estrutura de adaptação podem ser feitas.
de apoio de um processo de ciclo de vida.
Cópia não autorizada

NBR ISO/IEC 12207:1998 7

4.1.3 Relacionamento entre os processos e as organizações 5.1.1 Iniciação - Esta atividade consiste nas seguintes
tarefas:
Esta Norma contém vários processos que são aplicados
ao longo de ciclo de vida de software por várias organi-
5.1.1.1 O adquirente inicia o processo de aquisição pela
zações, dependendo de suas necessidades e objetivos.
descrição de um conceito ou de uma necessidade em
Para melhor esclarecimento, o anexo C apresenta os re-
adquirir, desenvolver ou melhorar um sistema, produto
lacionamentos entre os processos de ciclo de vida e as
de software ou serviço de software.
partes envolvidas.

5 Processos fundamentais de ciclo de vida 5.1.1.2 O adquirente deverá definir e analisar os requisitos
do sistema. Estes requisitos devem incluir requisitos de
Este capítulo define os seguintes processos fundamentais negócio, organizacionais e de usuário, bem como de se-
de ciclo de vida: gurança, proteção e outros requisitos críticos relacionados
às atividades de projeto, testes e aderência a padrões e
1) Processo de aquisição; procedimentos.
2) Processo de fornecimento;
5.1.1.3 Se o adquirente mantiver acordo com um for-
3) Processo de desenvolvimento; necedor para a execução da análise dos requisitos de
um sistema, o adquirente deverá aprovar estes requisitos.
4) Processo de operação;

5) Processo de manutenção. 5.1.1.4 O adquirente pode executar a definição e a análise

dos requisitos do software por conta própria ou pode
As atividades e as tarefas em um processo fundamental manter acordo com um fornecedor para executar essa
são de responsabilidade da organização que inicia e tarefa.
executa este processo. Esta organização assegura a exis-
tência e a funcionalidade do processo. 5.1.1.5 O processo de desenvolvimento (5.3) deveria ser
usado para executar as tarefas de 5.1.1.2 e 5.1.1.4.
5.1 Processo de aquisição

O processo de aquisição contém as atividades e tarefas 5.1.1.6 O adquirente deverá considerar opções para
do adquirente. Inicia-se com a definição da necessidade aquisição através de uma análise, com critérios
de adquirir um sistema, um produto de software ou um apropriados, incluindo risco, custo e benefícios para cada
serviço de software. O processo continua com a prepa- opção. As opções incluem:
ração e emissão de pedido de proposta, seleção de for-
necedor e gerência do processo de aquisição através da a) Comprar um produto de software de prateleira
aceitação do sistema, produto de software ou serviço de que satisfaça os requisitos;
software.

A organização individual, que tem a necessidade, pode b) Internamente desenvolver o produto de software
ser chamada de proprietária. O proprietário pode contratar ou obter o serviço de software;
algumas ou todas as atividades de aquisição junto a um
agente que, por sua vez, conduzirá estas atividades de c) Através de contrato, desenvolver o produto de
acordo com o processo de aquisição. O adquirente nesta software ou obter o serviço de software;
subseção pode ser tanto o proprietário quanto o agente
contratado por ele.
d) Uma combinação dos itens a, b e c acima;
O adquirente gerencia o processo de aquisição em nível
de projeto, seguindo o processo de gerência (7.1), o qual e) Melhorar um produto ou serviço de software exis-
passa a existir nesse processo; estabelece uma infra- tente.
estrutura sob o projeto, seguindo o processo de infra-
estrutura (7.2); adapta o processo para o projeto, se-
5.1.1.7 Para a aquisição de um produto de software de
guindo o processo de adaptação (anexo A); e gerencia o
prateleira, o adquirente deverá assegurar que as se-
processo em nível organizacional, seguindo o processo
guintes condições sejam satisfeitas:
de melhoria (7.3) e o processo de treinamento (7.4).

Lista de atividades - Este processo consiste nas seguintes a) Os requisitos do produto de software sejam satis-
atividades: feitos;

1) Iniciação;
b) A documentação esteja disponível;
2) Preparação de pedido de proposta;
c) Os direitos de propriedade, de uso, de autoria,
3) Preparação e atualização do contrato; de garantia e de licença sejam satisfeitos;
4) Monitoração do fornecedor;
d) O suporte futuro para o produto de software esteja
5) Aceitação e conclusão. planejado.
Cópia não autorizada

8 NBR ISO/IEC 12207:1998

5.1.1.8 O adquirente deveria preparar, documentar e 5.1.3 Preparação e atualização do contrato. Esta atividade
executar um plano de aquisição. O plano deveria conter consiste nas seguintes tarefas:
o seguinte:
5.1.3.1 O adquirente deveria estabelecer um procedi-
a) Requisitos para o sistema; mento para selecionar o fornecedor, incluindo critérios
de avaliação de proposta e ponderação da aderência
aos requisitos.
b) Emprego planejado para o sistema;
5.1.3.2 O adquirente deveria selecionar um fornecedor
c) Tipo de contrato a ser empregado; baseado na avaliação das propostas dos fornecedores,
capacidades e outros fatores que precisam ser conside-
d) Responsabilidades das organizações envolvidas; rados.

e) Conceito de suporte a ser usado; 5.1.3.3 O adquirente pode envolver outras partes, incluindo
fornecedores potenciais, antes do fechamento do contrato,
durante a adaptação desta Norma ao projeto. Entretanto,
f) Riscos considerados, assim como métodos para
o adquirente deverá tomar a decisão final sobre esta
gerenciá-los.
adaptação. O adquirente deverá incluir ou referenciar a
Norma adaptada no contrato.
5.1.1.9 O adquirente deveria definir e documentar a
estratégia e condições (critérios) de aceitação. 5.1.3.4 O adquirente deverá, então, preparar e negociar
um contrato com o fornecedor que trate dos requisitos de
5.1.2 Preparação de pedido de proposta. Esta atividade aquisição, incluindo o custo e cronograma do produto ou
consiste nas seguintes tarefas: serviço de software a ser entregue. O contrato deverá
tratar direitos de uso, de propriedade, de autoria, de
5.1.2.1 O adquirente deveria documentar os requisitos de garantia e de licença, associados com os produtos de
aquisição (exemplo: pedido de proposta) cujo conteúdo software de prateleira reusáveis.
depende da opção de aquisição selecionada em 5.1.1.6.
A documentação de aquisição deveria incluir, quando 5.1.3.5 Estando o contrato em andamento, o adquirente
apropriado: deverá controlar alterações no contrato através de
negociação com o fornecedor, como parte do mecanismo
de controle de alteração. Alterações no contrato deverão
a) Requisitos do sistema;
ser investigadas quanto ao impacto nos planos, custos,
benefícios, qualidade e cronograma do projeto.
b) Declaração do escopo;
NOTA - O adquirente determina se o termo “contrato” ou “acordo”
c) Instruções para os proponentes; será utilizado na aplicação desta Norma.

d) Lista de produtos de software; 5.1.4 Monitoração do fornecedor. Esta atividade consiste

nas seguintes tarefas:
e) Termos e condições;
5.1.4.1 O adquirente deverá monitorar as atividades do
fornecedor de acordo com o processo de revisão conjunta
f) Controle dos subcontratos; (6.6) e com o processo de auditoria (6.7). O adquirente
deveria complementar a monitoração com o processo de
g) Restrições técnicas (exemplo: ambiente-alvo). verificação (6.4) e com o processo de validação (6.5),
quando necessário.
5.1.2.2 O adquirente deveria determinar quais processos,
atividades e tarefas desta Norma são apropriados para o 5.1.4.2 O adquirente deverá cooperar com o fornecedor
projeto e deveria adaptá-los, quando necessário. Espe- para prover toda a informação necessária no momento
cialmente, o adquirente deveria especificar os processos oportuno e resolver todos os itens pendentes.
de apoio aplicáveis (seção 6) e suas organizações exe-
cutoras, incluindo responsabilidades (se outras além do 5.1.5 Aceitação e conclusão. Esta atividade consiste nas
fornecedor), para que os fornecedores possam, em suas seguintes tarefas:
propostas, definir como abordar cada um dos processos
5.1.5.1 O adquirente deveria preparar-se para aceitação
de apoio especificados. O adquirente deverá definir o
baseado na estratégia e nos critérios de aceitação de-
escopo daquelas tarefas que referenciam o contrato.
finidos. A preparação de casos de teste, dados de teste,
procedimentos de teste e ambiente de teste deveria estar
5.1.2.3 A documentação de aquisição também deverá
incluída. A abrangência do envolvimento do fornecedor
definir no contrato os pontos de controle nos quais o deveria ser definida.
progresso do fornecimento deverá ser revisado e audi-
tado como parte da monitoração da aquisição (ver 6.6 e 5.1.5.2 O adquirente deverá conduzir a revisão de
6.7). aceitação e teste de aceitação do produto ou serviço de
software a ser entregue e deverá aceitá-lo do fornecedor
5.1.2.4 Os requisitos de aquisição deveriam ser fornecidos quando todas as condições de aceitação forem satisfeitas.
à organização selecionada para executar as atividades O procedimento de aceitação deveria obedecer ao
de aquisição. estabelecido em 5.1.1.9.
Cópia não autorizada

NBR ISO/IEC 12207:1998 9

5.1.5.3 Após a aceitação, o adquirente deveria assumir a 5.2.3 Contrato. Esta atividade consiste nas seguintes
responsabilidade pela gerência de configuração do tarefas:
produto de software entregue (ver 6.2).
5.2.3.1 O fornecedor deve negociar e firmar o contrato
NOTA - O adquirente pode instalar o produto de software ou com a organização adquirente para fornecer o produto
executar o serviço de software de acordo com as instruções ou serviço de software.
definidas pelo fornecedor.
5.2.3.2 O fornecedor pode solicitar modificação no contrato
5.2 Processo de fornecimento
como parte do mecanismo de controle de alteração.
O processo de fornecimento contém as atividades e as
tarefas do fornecedor. O processo pode ser iniciado tanto 5.2.4 Planejamento. Esta atividade consiste nas seguin-
por uma decisão de preparar uma proposta para res- tes tarefas:
ponder a um pedido de proposta de um adquirente quanto
pela assinatura e celebração de um contrato com o adqui- 5.2.4.1 O fornecedor deve conduzir uma revisão dos requi-
rente para fornecer o sistema, produto de software ou sitos de aquisição, para definir a estrutura para gerenciar
serviço de software. O processo continua com a deter- e garantir o projeto e para garantir a qualidade do produto
minação dos procedimentos e recursos necessários para ou serviço de software a ser entregue.
gerenciar e garantir o projeto, incluindo o desenvolvimen-
to e a execução dos planos de projeto até a entrega do 5.2.4.2 Se não estiver estipulado no contrato, o fornecedor
sistema, produto de software ou serviço de software para deve definir ou selecionar um modelo de ciclo de vida de
o adquirente. software apropriado para o escopo, magnitude e
complexidade do projeto. Os processos, atividades e
O fornecedor gerencia o processo de fornecimento em tarefas desta Norma devem ser selecionados e mapeados
nível de projeto, seguindo o processo de gerência (7.1), no modelo de ciclo de vida.
o qual passa a existir nesse processo; estabelece uma
infra-estrutura sob o processo, seguindo o processo de 5.2.4.3 O fornecedor deve estabelecer requisitos para os
infra-estrutura (7.2); adapta o processo para o projeto, planos, para gerenciar e garantir o projeto e para garantir
seguindo o processo de adaptação (anexo A); e gerencia a qualidade do produto ou serviço de software a ser
o processo em nível organizacional, seguindo o processo entregue. Requisitos para os planos deveriam incluir
de melhoria (7.3) e o processo de treinamento (7.4). necessidades de recursos e o envolvimento do adqui-
rente.
Lista de atividades. Este processo consiste nas seguintes
atividades:
5.2.4.4 Uma vez estabelecidos os requisitos de plane-
jamento, o fornecedor deve considerar as opções para o
1) Iniciação;
desenvolvimento do produto de software ou provisão do
serviço de software, a partir de uma análise dos riscos
2) Preparação de resposta;
associados a cada uma das opções. As opções incluem:
3) Contrato;
a) Desenvolver o produto de software ou prover o
4) Planejamento; serviço de software usando recursos internos;

5) Execução e controle; b) Desenvolver o produto de software ou prover o

serviço de software através de subcontratação;
6) Revisão e avaliação;
c) Obter produtos de software de prateleira a partir
7) Entrega e conclusão. de fontes internas ou externas;

5.2.1 Iniciação. Esta atividade consiste nas seguintes d) Uma combinação de a, b e c anteriores.
tarefas:
5.2.4.5 O fornecedor deve desenvolver e documentar o(s)
5.2.1.1 O fornecedor conduz uma revisão dos requisitos
plano(s) de gerência do projeto de acordo com os requi-
que constam no pedido de proposta, levando em consi- sitos de planejamento e as opções selecionadas em
deração políticas e outros regulamentos da organização. 5.2.4.4. Os itens a serem considerados no plano não se
limitam a, mas incluem o seguinte:
5.2.1.2 O fornecedor deveria decidir entre propor ou aceitar
o contrato.
a) Estrutura organizacional do projeto, autoridade
e responsabilidade de cada unidade organizacional,
5.2.2 Preparação de resposta. Esta atividade consiste na
incluindo organizações externas;
seguinte tarefa:

5.2.2.1 O fornecedor deveria definir e preparar uma b) Ambiente de engenharia (para desenvolvimento,
proposta em resposta ao pedido de proposta, incluindo operação ou manutenção, quando aplicável),
sua recomendação da adaptação desta Norma. incluindo ambiente de teste, biblioteca, equipamento,
instalações, padrões, procedimentos e ferramentas;
Cópia não autorizada

10 NBR ISO/IEC 12207:1998

c) Estrutura de divisão de trabalho dos processos e 5.2.5.3 O fornecedor deve monitorar e controlar o pro-
atividades de ciclo de vida, incluindo os produtos de gresso e a qualidade dos produtos ou serviços de
software, serviços de software e itens que não serão software do projeto através do ciclo de vida contratado.
entregues, a ser executada de acordo com os orça- Esta deve ser uma tarefa contínua e iterativa que deve
mentos, pessoal, recursos físicos, tamanho do servir para:
software e cronogramas associados às tarefas;

d) Gerenciamento das características da qualidade a) Monitoração do progresso do desempenho técnico,

dos produtos ou serviços de software. Planos para de custos e de cronogramas, e o relato da situação
qualidade podem ser desenvolvidos em separado; do projeto;

e) Gerenciamento de proteção, segurança e outros b) Identificação, registro, análise e resolução de pro-

requisitos críticos dos produtos ou serviços de blema.
software. Planos para proteção e segurança podem
ser desenvolvidos em separado;
5.2.5.4 O fornecedor deve gerenciar e controlar os subcon-
f) Gerenciamento do subcontratado, incluindo a sua tratados de acordo com o processo de aquisição (5.1).
seleção e o seu envolvimento com o adquirente, se O fornecedor deve verificar todos os requisitos contratuais
houver; necessários, para assegurar que o produto ou serviço de
software entregue ao adquirente foi desenvolvido ou
g) Garantia da qualidade (ver 6.3); executado de acordo com os requisitos do contrato origi-
nal.
h) Verificação (ver 6.4) e validação (ver 6.5) incluindo
a abordagem para a interação com o agente de ve-
rificação e validação, se especificado; 5.2.5.5 O fornecedor deve interagir com os agentes
independentes de verificação, validação ou testes, con-
i) Envolvimento do adquirente, isto é, através de forme especificado no contrato e nos planos do projeto.
revisões conjuntas (ver 6.6), auditorias (ver 6.7),
reuniões informais, relatórios, modificação e alte-
5.2.5.6 O fornecedor deve interagir com outras partes,
ração; implementação, aprovação, aceitação e
conforme especificado no contrato e nos planos do pro-
acesso às instalações;
jeto.
j) Envolvimento do usuário, através de exercícios de
consolidação de requisitos, demonstrações de pro- 5.2.6 Revisão e avaliação. Esta atividade consiste nas se-
tótipos e avaliações; guintes tarefas:

k) Gerenciamento de risco: gerenciamento das áreas

do projeto que envolvem potenciais riscos técnicos, 5.2.6.1 O fornecedor deveria coordenar as atividades de
de custo e de cronograma; revisão do contrato, interações e comunicação com a
organização do adquirente.
l) Política de segurança: as regras para gestão e
acesso às informações em cada nível organizacional 5.2.6.2 O fornecedor deve conduzir ou dar suporte às
do projeto; reuniões informais, revisão de aceitação, teste de acei-
m) Aprovação requerida através de regulamentos, tação, revisões conjuntas e auditorias com o adquirente
certificações, direitos de propriedade, de uso, de conforme especificado no contrato e planos do projeto.
autoria, de garantia e de licença; As revisões conjuntas devem ser conduzidas de acordo
com 6.6 e as auditorias de acordo com 6.7.
n) Meios para elaborar cronogramas, realizar acom-
panhamento e elaborar relatórios; 5.2.6.3 O fornecedor deve executar a verificação e a
validação, de acordo com 6.4 e 6.5, respectivamente,
o) Treinamento de pessoal (ver 7.4).
para demonstrar que os produtos ou serviços de
5.2.5 Execução e controle. Esta atividade consiste nas software e os processos satisfazem completamente os
seguintes tarefas: seus respectivos requisitos.

5.2.5.1 O fornecedor deve implementar e executar o(s)

5.2.6.4 O fornecedor deve disponibilizar ao adquirente
plano(s) de gerenciamento do projeto desenvolvido(s)
os relatórios de avaliação, revisões, auditorias, testes e
em 5.2.4.
resolução de problemas, conforme especificado no con-
5.2.5.2 O fornecedor deve: trato.

a) Desenvolver o produto de software de acordo com 5.2.6.5 O fornecedor deve prover ao adquirente acesso
o processo de desenvolvimento (5.3); aos recursos do fornecedor e dos subcontratados, para a
b) Operar o produto de software de acordo com o revisão dos produtos ou serviços de software, conforme
processo de operação (5.4); especificado no contrato e planos do projeto.

c) Manter o produto de software de acordo com o 5.2.6.6 O fornecedor deve executar atividades de garantia
processo de manutenção (5.5). da qualidade, de acordo com 6.3.
Cópia não autorizada

NBR ISO/IEC 12207:1998 11

5.2.7 Entrega e conclusão. Esta atividade consiste nas 5.3.1.2 O desenvolvedor deve:
seguintes tarefas:
a) Documentar os resultados, de acordo com o pro-
5.2.7.1 O fornecedor deve entregar o produto ou serviço cesso de documentação (6.1);
de software, conforme especificado no contrato.

5.2.7.2 O fornecedor deve prover assistência ao adquirente b) Colocar os resultados sob o processo de gerência
no suporte do produto ou serviço de software entregue, de configuração (6.2) e executar controle de alte-
conforme especificado no contrato. rações, de acordo com ele;

5.3 Processo de desenvolvimento c) Documentar e resolver problemas e não-confor-

midades encontrados nos produtos de software e ta-
O processo de desenvolvimento contém as atividades e
refas, de acordo com o processo de resolução de
tarefas do desenvolvedor. O processo contém as ati-
problema (6.8);
vidades para análise de requisitos, projeto, codificação,
integração, testes, instalação e aceitação relacionada aos
d) Executar os processos de apoio (seção 6), con-
produtos de software. Pode conter atividades relaciona-
forme especificado no contrato.
das ao sistema, se estipulado no contrato. O desenvol-
vedor executa ou apóia as atividades neste processo, de
5.3.1.3 O desenvolvedor deve selecionar, adaptar e utilizar
acordo com o contrato.
estes padrões, métodos, ferramentas e linguagens de
O desenvolvedor gerencia o processo de desenvol- programação de computador (se não estipulados no con-
vimento em nível de projeto, seguindo o processo de ge- trato) que sejam documentados, apropriados e esta-
rência (7.1), o qual passa a existir nesse processo; esta- belecidos pela organização, para executar as atividades
belece uma infra-estrutura sob o processo, seguindo o do processo de desenvolvimento e dos processos de
processo de infra-estrutura (7.2); adapta o processo para apoio (seção 6).
o projeto, seguindo o processo de adaptação (anexo A);
e gerencia o processo em nível organizacional, seguindo 5.3.1.4 O desenvolvedor deve desenvolver planos para
o processo de melhoria (7.3) e o processo de treinamento conduzir as atividades do processo de desenvolvimento.
(7.4). Quando o desenvolvedor é o fornecedor do produto Os planos deveriam incluir padrões específicos, métodos,
de software desenvolvido, o desenvolvedor executa o ferramentas, ações e responsabilidades associados com
processo de fornecimento (5.2). o desenvolvimento e qualificação de todos os requisitos,
incluindo proteção e segurança. Se necessário, planos
Lista de atividades. Este processo consiste nas seguintes em separado podem ser elaborados. Estes planos devem
atividades: ser documentados e executados.
1) Implementação do processo;
5.3.1.5 Itens que não serão entregues podem ser empre-
2) Análise dos requisitos do sistema; gados no desenvolvimento ou manutenção do produto
de software. Entretanto, deve ser assegurado que a ope-
3) Projeto da arquitetura do sistema; ração e manutenção do produto de software a ser en-
4) Análise dos requisitos do software; tregue, depois de sua liberação ao adquirente, são inde-
pendentes daqueles itens; caso contrário, estes itens
5) Projeto da arquitetura do software; deveriam ser considerados como a ser entregues.
6) Projeto detalhado do software; 5.3.2 Análise dos requisitos do sistema. Esta atividade
7) Codificação e testes do software; consiste nas seguintes tarefas, as quais o desenvolvedor
deve executar ou apoiar conforme especificado no
8) Integração do software; contrato:
9) Teste de qualificação do software;
5.3.2.1 O uso específico pretendido do sistema a ser de-
10) Integração do sistema; senvolvido deve ser analisado para especificar os requi-
sitos do sistema. A especificação dos requisitos do sis-
11) Teste de qualificação do sistema; tema deve descrever: funções e capacidades do sistema;
requisitos de negócio, organizacionais e de usuários; re-
12) Instalação do software;
quisitos de proteção, de segurança, de engenharia de
13) Apoio à aceitação do software. fatores humanos (ergonomia), de interface, de operações
e de manutenção; restrições de projeto e requisitos de
5.3.1 Implementação do processo. Esta atividade consiste qualificação. A especificação dos requisitos do sistema
na seguinte tarefa: deve ser documentada.
5.3.1.1 Se não estipulado no contrato, o desenvolvedor
5.3.2.2 Os requisitos do sistema devem ser avaliados,
deve definir ou selecionar um modelo de ciclo de vida de
software apropriado ao escopo, magnitude e complexi- considerando os critérios listados a seguir. Os resultados
dade do projeto. As atividades e tarefas do processo de das avaliações devem ser documentados.
desenvolvimento devem ser selecionadas e mapeadas
no modelo de ciclo de vida. a) Rastreabilidade para as necessidades de aqui-
sição;
NOTA - Estas atividades e tarefas podem se sobrepor ou interagir
e podem ser executadas iterativa ou recursivamente. b) Consistência com as necessidades de aquisição;
Cópia não autorizada

12 NBR ISO/IEC 12207:1998

c) Testabilidade; e) Especificações de segurança, incluindo aquelas

relacionadas com o comprometimento de informa-
d) Viabilidade do projeto da arquitetura do sistema; ções sigilosas;

e) Viabilidade da operação e manutenção. f) Especificações de engenharia de fatores humanos

(ergonomia), incluindo aquelas relacionadas com
5.3.3 Projeto da arquitetura do sistema. Esta atividade operações manuais, interações entre homem-
consiste nas seguintes tarefas, as quais o desenvolvedor máquina, restrições a pessoal e áreas que neces-
deve executar ou apoiar conforme especificado no sitam de maior atenção humana, que são sensíveis
contrato: a erros humanos e treinamento;

g) Definição de dados e requisitos de bases de

5.3.3.1 Uma arquitetura de alto nível do sistema deve ser
dados;
estabelecida. A arquitetura deve identificar itens de
hardware, software e operações manuais. Deve ser asse-
h) Requisitos de instalação e aceitação do produto
gurado que todos os requisitos do sistema sejam alocados
de software entregue no(s) local(ais) de operação e
entre os itens. Itens de configuração de hardware, itens
manutenção;
de configuração de software e operações manuais devem
ser subseqüentemente identificados, a partir destes itens.
i) Documentação do usuário;
A arquitetura do sistema e os requisitos do sistema alo-
cados aos itens devem ser documentados. j) Requisitos do usuário para execução e operação;

5.3.3.2 A arquitetura do sistema e os requisitos para os k) Requisitos do usuário para manutenção.

itens devem ser avaliados, considerando os critérios
listados a seguir. Os resultados das avaliações devem 5.3.4.2 O desenvolvedor deve avaliar os requisitos do
ser documentados. software considerando os critérios listados a seguir.
Os resultados das avaliações devem ser documentados.
a) Rastreabilidade para os requisitos do sistema;
a) Rastreabilidade para os requisitos do sistema e
b) Consistência com os requisitos do sistema; projeto do sistema;

c) Adequação dos métodos e padrões de projeto b) Consistência externa com os requisitos do sistema;
utilizados;
c) Consistência interna;
d) Viabilidade de os itens de software atenderem
seus requisitos alocados; d) Testabilidade;

e) Viabilidade do projeto do software;

e) Viabilidade da operação e da manutenção.
f) Viabilidade da operação e manutenção.
5.3.4 Análise dos requisitos do software. Esta atividade
deve ser realizada para cada item de software (ou item 5.3.4.3 O desenvolvedor deve conduzir revisão(ões)
de configuração de software, se identificado) e consiste conjunta(s), de acordo com a seção 6.6. Sendo bem
nas seguintes tarefas: sucedidas as conclusões da(s) revisão(ões), uma linha
básica (baseline) para os requisitos do item de software
5.3.4.1 O desenvolvedor deve estabelecer e documentar deve ser estabelecida.
os requisitos do software, incluindo as especificações
das características de qualidade descritas a seguir. Um 5.3.5 Projeto da arquitetura do software. Esta atividade
guia para especificar as características de qualidade pode deve ser realizada para cada item de software (ou item
ser encontrado na ISO/IEC 9126 2) - Information de configuração de software, se identificado) e consiste
technology - Software product evaluation - Quality nas seguintes tarefas:
characteristics and guidelines for their use.
5.3.5.1 O desenvolvedor deve transformar os requisitos
a) Especificações funcionais e de capacidade, para o item de software em uma arquitetura que descreve
incluindo desempenho, características físicas e con- sua estrutura de alto nível e identifica os componentes
dições do ambiente sob o qual o item de de software. Deve ser garantido que todos os requisitos
software será executado; do item de software sejam alocados aos seus com-
ponentes de software e, mais adiante, sejam refinados
b) Interfaces externas ao item de software; para facilitar o projeto detalhado. A arquitetura do item
de software deve ser documentada.
c) Requisitos de qualificação;
5.3.5.2 O desenvolvedor deve desenvolver e documentar
d) Especificações de proteção, incluindo aquelas um projeto de alto nível para as interfaces externas ao
relacionadas aos métodos de operação e manu- item de software e entre os componentes de software do
tenção, influências do ambiente e danos pessoais; item de software.

2)
Utilizar a NBR 13596.
Cópia não autorizada

NBR ISO/IEC 12207:1998 13

5.3.5.3 O desenvolvedor deve desenvolver e documentar 5.3.6.6 O desenvolvedor deve atualizar os requisitos de
um projeto de alto nível para a base de dados. teste e o cronograma para a integração do software.

5.3.5.4 O desenvolvedor deveria desenvolver e do- 5.3.6.7 O desenvolvedor deve avaliar o projeto detalhado
cumentar versões preliminares da documentação do do software e requisitos de teste, considerando os
usuário. critérios listados a seguir. Os resultados das avaliações
devem ser documentados.
5.3.5.5 O desenvolvedor deve definir e documentar os
requisitos preliminares de teste e o cronograma para a a) Rastreabilidade para os requisitos do item de
integração do software. software;

b) Consistência externa com o projeto da arquitetura;

5.3.5.6 O desenvolvedor deve avaliar a arquitetura do item
de software e os projetos de interface e base de dados, c) Consistência interna entre componentes e
considerando os critérios listados a seguir. Os resultados unidades de software;
das avaliações devem ser documentados.
d) Adequação dos métodos e padrões de projeto
a) Rastreabilidade para os requisitos do item de utilizados;
software;
e) Viabilidade dos testes;
b) Consistência externa com os requisitos do item
de software; f) Viabilidade da operação e manutenção.

5.3.6.8 O desenvolvedor deve conduzir revisão(ões)

c) Consistência interna entre os componentes de
conjunta(s), de acordo com a seção 6.6.
software;
5.3.7 Codificação e testes do software. Esta atividade deve
d) Adequação dos métodos e padrões de projeto ser realizada para cada item de software (ou item de
utilizados; configuração de software, se identificado) e consiste nas
seguintes tarefas:
e) Viabilidade do projeto detalhado;
5.3.7.1 O desenvolvedor deve desenvolver e documentar
f) Viabilidade da operação e manutenção. o seguinte:
5.3.5.7 O desenvolvedor deve conduzir revisão(ões) a) Cada unidade de software e base de dados;
conjunta(s), de acordo com a seção 6.6.
b) Procedimentos de teste e dados para testar cada
5.3.6 Projeto detalhado do software. Esta atividade deve unidade de software e base de dados.
ser realizada para cada item de software (ou item de
configuração de software, se identificado) e consiste nas 5.3.7.2 O desenvolvedor deve testar cada unidade de
seguintes tarefas: software e base de dados, garantindo que sejam aten-
didos seus requisitos. Os resultados dos testes devem
5.3.6.1 O desenvolvedor deve desenvolver um projeto ser documentados.
detalhado para cada componente de software do item de
5.3.7.3 O desenvolvedor deve atualizar a documentação
software. Os componentes de software devem ser refi-
do usuário, quando necessário.
nados em níveis mais baixos, contendo unidades de
software que possam ser codificadas, compiladas e 5.3.7.4 O desenvolvedor deve atualizar os requisitos de
testadas. Deve ser garantido que todos os requisitos do teste e o cronograma, para integração do software.
software sejam alocados para unidades de software a
partir dos componentes de software. O projeto detalhado 5.3.7.5 O desenvolvedor deve avaliar o código do
deve ser documentado. software e os resultados dos testes, considerando os
critérios listados a seguir. Os resultados das avaliações
5.3.6.2 O desenvolvedor deve desenvolver e documentar devem ser documentados.
um projeto detalhado das interfaces externas ao item de
software, entre os componentes de software e entre as a) Rastreabilidade para os requisitos e projeto do
unidades de software. O projeto detalhado das interfaces item de software;
deve permitir a codificação sem a necessidade de
informação adicional. b) Consistência externa com os requisitos e projeto
do item de software;
5.3.6.3 O desenvolvedor deve desenvolver e documentar
c) Consistência interna entre os requisitos da uni-
um projeto detalhado para a base de dados.
dade;
5.3.6.4 O desenvolvedor deve atualizar a documentação d) Cobertura de teste das unidades;
do usuário, quando necessário.
e) Adequação dos métodos e padrões de codifica-
5.3.6.5 O desenvolvedor deve definir e documentar os ção utilizados;
requisitos de teste e o cronograma para testar unidades
de software. Os requisitos de teste deveriam incluir tes- f) Viabilidade da integração e testes do software;
tes de estresse da unidade de software, até o limite de
seus requisitos. g) Viabilidade da operação e manutenção.
Cópia não autorizada

14 NBR ISO/IEC 12207:1998

5.3.8 Integração do software. Esta atividade deve ser 5.3.9.2 O desenvolvedor deve atualizar a documentação
realizada para cada item de software (ou item de do usuário, quando necessário.
configuração de software, se identificado) e consiste nas
seguintes tarefas: 5.3.9.3 O desenvolvedor deve avaliar o projeto, código,
testes, resultados dos testes e a documentação do
5.3.8.1 O desenvolvedor deve desenvolver um plano de usuário, considerando os critérios listados a seguir. Os
integração para integrar as unidades de software e resultados das avaliações devem ser documentados.
componentes de software no item de software. O plano
deve incluir requisitos de teste, procedimentos, dados, a) Cobertura de teste dos requisitos do item de
responsabilidades e cronograma. O plano deve ser docu- software;
mentado.
b) Conformidade com os resultados esperados;
5.3.8.2 O desenvolvedor deve integrar as unidades e
componentes de software e testar essas agregações à c) Viabilidade da integração e testes do sistema, se
medida que forem sendo integradas, de acordo com o conduzidos;
plano de integração. Deve ser garantido que cada
d) Viabilidade da operação e manutenção.
agregação atenda os requisitos do item de software e
que o item de software esteja integrado na conclusão da 5.3.9.4 O desenvolvedor deve apoiar auditorias, de acordo
atividade de integração. Os resultados da integração e com 6.7. Os resultados das auditorias devem ser docu-
dos testes devem ser documentados. mentados. Se ambos, hardware e software, estão sendo
5.3.8.3 O desenvolvedor deve atualizar a documentação
desenvolvidos e integrados, as auditorias podem ser
do usuário, quando necessário. adiadas até o teste de qualificação do sistema.

5.3.9.5 Uma vez bem sucedida a conclusão das auditorias,

5.3.8.4 O desenvolvedor deve desenvolver e documentar,
para cada requisito de qualificação do item de software, se conduzidas, o desenvolvedor deve:
um conjunto de testes, casos de teste (entradas, saídas e
a) Atualizar e preparar o produto de software a ser
critérios de teste) e procedimentos de teste, para conduzir
entregue para a integração do sistema, teste de
o teste de qualificação do software. O desenvolvedor deve
qualificação do sistema, instalação do software ou
garantir que o item de software integrado está pronto
apoio à aceitação do software, quando aplicável;
para o teste de qualificação do software.
b) Estabelecer uma linha básica (baseline) para o
5.3.8.5 O desenvolvedor deve avaliar o plano de inte-
projeto e código do item de software.
gração, projeto, código, testes, resultados dos testes e a
documentação do usuário, considerando os critérios NOTA - O teste de qualificação do software pode ser utilizado
listados a seguir. Os resultados das avaliações devem no processo de verificação (6.4) ou no processo de validação
ser documentados. (6.5).
a) Rastreabilidade para os requisitos do sistema; 5.3.10 Integração do sistema. Esta atividade consiste nas
seguintes tarefas, as quais o desenvolvedor deve
b) Consistência externa com os requisitos do sistema;
executar ou apoiar conforme especificado no contrato.
c) Consistência interna;
5.3.10.1 Os itens de configuração de software devem ser
d) Cobertura de teste dos requisitos do item de integrados ao sistema com itens de configuração de
software; hardware, com operações manuais e com outros
sistemas, quando necessário. As agregações devem ser
e) Adequação dos métodos e padrões de teste uti- testadas, quando forem integradas, de acordo com seus
lizados; requisitos. A integração e resultados dos testes devem
ser documentados.
f) Conformidade com os resultados esperados;
5.3.10.2 Para cada requisito de qualificação do sistema,
g) Viabilidade do teste de qualificação do software; um conjunto de testes, casos de teste (entradas, saídas e
critérios de teste) e procedimentos de teste para conduzir
h) Viabilidade da operação e manutenção.
o teste de qualificação do sistema deve ser desenvolvido
5.3.8.6 O desenvolvedor deve conduzir revisão(ões) e documentado. O desenvolvedor deve garantir que o
conjunta(s), de acordo com a seção 6.6. sistema integrado está pronto para o teste de qualificação
do sistema.
5.3.9 Teste de qualificação do software. Esta atividade
deve ser realizada para cada item de software (ou item 5.3.10.3 O sistema integrado deve ser avaliado, conside-
de configuração de software, se identificado) e consiste rando os critérios listados a seguir. Os resultados das
nas seguintes tarefas: avaliações devem ser documentados.

5.3.9.1 O desenvolvedor deve conduzir o teste de quali- a) Cobertura de teste dos requisitos do sistema;
ficação de acordo com os requisitos de qualificação para
o item de software. Deve ser garantido que a imple- b) Adequação dos métodos e padrões de teste
mentação de cada requisito do software seja testada para utilizados;
conformidade. Os resultados do teste de qualificação
c) Conformidade com os resultados esperados;
devem ser documentados.
Cópia não autorizada

NBR ISO/IEC 12207:1998 15

d) Viabilidade do teste de qualificação do sistema; 5.3.12.2 O desenvolvedor deve instalar o produto de

software de acordo com o plano de instalação. Deve ser
e) Viabilidade da operação e manutenção. assegurado que o código do software e as bases de
dados sejam iniciados, executados e finalizados, con-
5.3.11 Teste de qualificação do sistema. Esta atividade forme especificado no contrato. Os eventos e resultados
consiste nas seguintes tarefas, as quais o desenvolvedor da instalação devem ser documentados.
deve executar ou apoiar conforme especificado no
contrato. 5.3.13 Apoio à aceitação do software. Esta atividade
consiste nas seguintes tarefas:
5.3.11.1 O teste de qualificação do sistema deve ser con-
duzido de acordo com os requisitos de qualificação es- 5.3.13.1 O desenvolvedor deve apoiar a revisão de
pecificados para o sistema. Deve ser garantido que a aceitação do adquirente e testes do produto de software.
implementação de cada requisito do sistema seja testada, A revisão de aceitação e testes deve considerar os
para conformidade, e que o sistema está pronto para ser resultados de revisões conjuntas (6.6), auditorias (6.7),
entregue. Os resultados do teste de qualificação devem teste de qualificação do software e teste de qualificação
ser documentados. do sistema (se executado). Os resultados da revisão de
aceitação e teste devem ser documentados.
5.3.11.2 O sistema deve ser avaliado considerando os
critérios listados a seguir. Os resultados das avaliações 5.3.13.2 O desenvolvedor deve concluir e entregar o
devem ser documentados. produto de software, conforme especificado no contrato.

a) Cobertura de teste dos requisitos do sistema; 5.3.13.3 O desenvolvedor deve prover treinamento inicial
e contínuo e suporte ao adquirente, conforme especificado
b) Conformidade com os resultados esperados; no contrato.

c) Viabilidade da operação e manutenção. 5.4 Processo de operação

5.3.11.3 O desenvolvedor deve apoiar auditorias, de O processo de operação contém as atividades e as tarefas
acordo com 6.7. Os resultados das auditorias devem ser do operador. O processo cobre a operação do produto
documentados. de software e o suporte operacional aos usuários. Como
a operação do produto de software está integrada à
operação do sistema, as atividades e tarefas deste
NOTA - Esta tarefa não é aplicável para aqueles itens de
processo se referem ao sistema.
configuração de software cujas auditorias foram conduzidas
previamente.
O operador gerencia o processo de operação em nível
do projeto, seguindo o processo de gerência (7.1), o qual
5.3.11.4 Uma vez bem sucedida a conclusão das audi-
passa a existir nesse processo; estabelece uma infra-
torias, se conduzidas, o desenvolvedor deve:
estrutura sob o processo, seguindo o processo de infra-
estrutura (7.2); adapta o processo para o projeto, se-
a) Atualizar e preparar o produto de software a ser guindo o processo de adaptação (anexo A); e gerencia o
entregue para a instalação do software e para o processo em nível organizacional, seguindo o processo
apoio à aceitação do software; de melhoria (7.3) e o processo de treinamento (7.4).
Quando o operador é o fornecedor do serviço de ope-
b) Estabelecer uma linha básica (baseline) para o ração, o operador executa o processo de fornecimento
projeto e código de cada item de configuração de (5.2).
software.
Lista de atividades. Este processo consiste nas seguintes
NOTA - O teste de qualificação do sistema pode ser utilizado no atividades:
processo de verificação (6.4) ou no processo de validação (6.5).
1) Implementação do processo;
5.3.12 Instalação do software. Esta atividade consiste nas
seguintes tarefas: 2) Teste operacional;

5.3.12.1 O desenvolvedor deve desenvolver um plano

3) Operação do sistema;
para instalar o produto de software no ambiente-alvo,
conforme designado no contrato. Os recursos e infor-
4) Suporte ao usuário.
mações necessários para instalar o produto de software
devem ser determinados e estar disponíveis. Quando es-
pecificado no contrato, o desenvolvedor deve auxiliar o 5.4.1 Implementação do processo. Esta atividade consiste
adquirente com as atividades de preparação. Onde o nas seguintes tarefas:
produto de software a ser instalado estiver substituindo
um sistema existente, o desenvolvedor deve apoiar 5.4.1.1 O operador deve desenvolver um plano e um
qualquer atividade em execução paralela, conforme conjunto de padrões de operação para executar as
especificado no contrato. O plano de instalação deve ser atividades e tarefas deste processo. O plano deve ser
documentado. documentado e executado.
Cópia não autorizada

16 NBR ISO/IEC 12207:1998

5.4.1.2 O operador deve estabelecer procedimentos para As atividades providas nesta seção são específicas para
receber, registrar, resolver e rastrear problemas, e prover o processo de manutenção. Entretanto, o processo pode
realimentação (feedback). Sempre que os problemas fo- utilizar outros processos desta Norma. Se o processo de
rem encontrados, eles devem ser registrados e incluídos desenvolvimento (seção 5.3) é utilizado, o termo de-
no processo de resolução de problema (seção 6.8). senvolvedor é interpretado como mantenedor.

5.4.1.3 O operador deve estabelecer procedimentos para

O mantenedor gerencia o processo de manutenção em
testar o produto de software no seu ambiente de ope- nível de projeto, seguindo o processo de gerência (7.1),
ração, para inserir os relatórios de problemas e pedidos o qual passa a existir nesse processo; estabelece uma
de modificação no processo de manutenção (5.5) e para infra-estrutura sob o processo, seguindo o processo de
liberar o produto de software para uso operacional. infra-estrutura (7.2); adapta o processo para o projeto
seguindo o processo de adaptação (anexo A); e gerencia
o processo em nível organizacional seguindo o processo
5.4.2 Teste operacional. Esta atividade consiste nas
de melhoria (7.3) e o processo de treinamento (7.4).
seguintes tarefas:
Quando o mantenedor é o fornecedor do serviço de manu-
tenção, o mantenedor executa o processo de forneci-
5.4.2.1 Para cada liberação do produto de software, o mento (5.2).
operador deve executar o teste operacional e, satis-
fazendo os critérios especificados, liberar o produto de Lista de atividades. Este processo consiste nas seguintes
software para uso operacional. atividades:

5.4.2.2 O operador deve garantir que o código de 1) Implementação do processo;

software e as bases de dados sejam iniciados, executados
2) Análise do problema e da modificação;
e finalizados, como descrito no plano.
3) Implementação da modificação;
5.4.3 Operação do sistema. Esta atividade consiste na
seguinte tarefa: 4) Revisão/aceitação da manutenção;

5.4.3.1 O sistema deve ser operado no ambiente para o 5) Migração;

qual foi pretendido, de acordo com a documentação do
6) Descontinuação do software.
usuário.
5.5.1 Implementação do processo. Esta atividade consiste
5.4.4 Suporte ao usuário. Esta atividade consiste nas nas seguintes tarefas:
seguintes tarefas:
5.5.1.1 O mantenedor deve desenvolver, documentar e
5.4.4.1 O operador deve prover assistência e consultoria executar planos e procedimentos para a condução das
aos usuários quando solicitado. Estas solicitações e ações atividades e tarefas do processo de manutenção.
subseqüentes devem ser registradas e monitoradas.
5.5.1.2 O mantenedor deve estabelecer procedimentos
para receber, registrar e rastrear relatórios de problemas
5.4.4.2 O operador deve encaminhar as solicitações do e pedidos de modificação dos usuários, e prover reali-
usuário, quando necessário, para resolução no processo mentação (feedback) para os usuários. Sempre que pro-
de manutenção (5.5). Estas solicitações devem ser en- blemas forem encontrados, eles devem ser registrados e
caminhadas e as ações que foram planejadas e exe- incluídos no processo de resolução de problema
cutadas devem ser relatadas aos solicitantes. Todas as (seção 6.8).
resoluções devem ser monitoradas até a conclusão.
5.5.1.3 O mantenedor deve implementar (ou estabelecer
5.4.4.3 Se um problema relatado tiver uma solução tem- interface organizacional com) o processo de gerência de
porária antes que uma solução definitiva possa ser configuração (6.2), para gerenciar modificações no
liberada, deve ser dada, ao solicitante, a opção de usá- sistema existente.
la. Correções definitivas, liberações que incluem funções
ou características previamente omitidas e melhorias do 5.5.2 Análise do problema e da modificação. Esta atividade
sistema devem ser aplicadas ao produto de software em consiste nas seguintes tarefas:
operação, utilizando o processo de manutenção (5.5).
5.5.2.1 O mantenedor deve analisar o relatório de
problema ou pedido de modificação segundo o seu im-
5.5 Processo de manutenção
pacto na organização, no sistema existente e nos sistemas
com os quais interage, com relação ao seguinte:
O processo de manutenção contém as atividades e tarefas
do mantenedor. Este processo é ativado quando o produto a) Tipo: por exemplo, corretivo, melhoria, preventivo,
de software é submetido a modificações no código e na ou adaptativo para um novo ambiente;
documentação associada devido a um problema, ou à
necessidade de melhoria ou adaptação. O objetivo é mo- b) Escopo: por exemplo, tamanho da modificação,
dificar um produto de software existente, preservando a custo envolvido, prazo para modificar;
sua integridade. Este processo inclui a migração e a des-
continuação do produto de software. O processo termina c) Criticidade: por exemplo, impacto no desempenho,
com a descontinuação do produto de software. proteção ou segurança.
Cópia não autorizada

NBR ISO/IEC 12207:1998 17

5.5.2.2 O mantenedor deve reproduzir ou verificar o d) Execução da migração;

problema.
e) Verificação da migração;
5.5.2.3 Baseado na análise, o mantenedor deve desen-
volver alternativas para a implementação da modificação. f) Suporte para o ambiente antigo.

5.5.2.4 O mantenedor deve documentar o problema/pe-

5.5.5.3 Usuários devem receber notificação dos planos e
dido de modificação, os resultados da análise e as alter- atividades de migração. Notificações devem conter o se-
nativas de implementação. guinte:
5.5.2.5 O mantenedor deve obter aprovação para a al-
a) Explicação do porquê o ambiente antigo não será
ternativa de modificação selecionada, conforme especi-
mais suportado;
ficado no contrato.

5.5.3 Implementação da modificação. Esta atividade b) Descrição do novo ambiente com sua data de dis-
consiste nas seguintes tarefas: ponibilização;

5.5.3.1 O mantenedor deve conduzir a análise e determinar c) Descrição de outras opções de suporte dispo-
que documentação, unidades de software e versões níveis, se existirem, uma vez que o suporte para o
destas necessitam ser modificadas. Estas devem ser do- ambiente antigo seja descontinuado.
cumentadas.
5.5.5.4 Operações paralelas dos ambientes antigo e novo
5.5.3.2 O mantenedor deve utilizar o processo de de- podem ser conduzidas para a transição gradual ao novo
senvolvimento (5.3) para implementar as modificações. ambiente. Durante este período, deve ser provido o treina-
Os requisitos do processo de desenvolvimento devem mento necessário, conforme especificado no contrato.
ser complementados, como segue:
5.5.5.5 Quando a migração programada ocorrer, devem
a) Devem ser definidos e documentados critérios de ser enviadas notificações a todos os interessados. Toda
teste e de avaliação para testar e avaliar as partes documentação, históricos (logs) e código associados ao
modificadas e as não modificadas do sistema (uni- ambiente antigo deveriam ser arquivados.
dades de software, componentes e itens de con-
figuração). 5.5.5.6 Após a migração, uma revisão deve ser executada
para avaliar o impacto da mudança para o novo ambiente.
b) Deve ser garantida a implementação completa e
Os resultados da revisão devem ser enviados às auto-
correta dos requisitos novos e dos modificados.
ridades apropriadas para informação, orientação e pro-
Também deve ser garantido que os requisitos ori-
vidências.
ginais não modificados não foram afetados. Os resul-
tados dos testes devem ser documentados.
5.5.5.7 Dados utilizados ou associados com o ambiente
5.5.4 Revisão/aceitação da manutenção. Esta atividade antigo devem estar acessíveis, de acordo com os requi-
consiste nas seguintes tarefas: sitos do contrato para preservação e auditoria dos dados.

5.5.4.1 O mantenedor deve conduzir revisão(ões) com a 5.5.6 Descontinuação do software. Esta atividade consiste
organização que autorizou a modificação para determinar nas seguintes tarefas:
a integridade do sistema modificado.
NOTA - O produto de software deverá ser descontinuado a
5.5.4.2 O mantenedor deve obter aprovação para a con- pedido do proprietário.
clusão satisfatória da modificação, conforme especificado
no contrato. 5.5.6.1 Um plano de descontinuação, para remover o su-
porte ativo pelas organizações responsáveis pela ope-
5.5.5 Migração. Esta atividade consiste nas seguintes ração e manutenção, deve ser desenvolvido e documen-
tarefas: tado. As atividades de planejamento devem incluir os
usuários. O plano deve conter os itens listados a seguir.
5.5.5.1 Se um sistema ou produto de software (incluindo
O plano deve ser executado.
dados) é migrado de um ambiente de operação antigo
para um novo, deve ser assegurado que qualquer produto
a) Cessação total ou parcial de suporte após um
de software ou dados produzidos ou modificados durante
certo período de tempo;
a migração estejam de acordo com esta Norma.

5.5.5.2 Um plano de migração deve ser desenvolvido, b) Arquivamento do produto de software e sua do-
documentado e executado. As atividades de plane- cumentação associada;
jamento devem incluir os usuários. Os itens incluídos no
plano devem conter o seguinte: c) Responsabilidade por quaisquer questões futuras
de suporte residual;
a) Análise e definição dos requisitos de migração;
d) Transição para o novo produto de software, se
b) Desenvolvimento de ferramentas de migração; aplicável;

c) Conversão de produto de software e dados; e) Disponibilidade de cópias de arquivos de dados.

Cópia não autorizada

18 NBR ISO/IEC 12207:1998

5.5.6.2 Os usuários devem receber notificação dos planos 6.1 Processo de documentação
e atividades de descontinuação. Notificações devem
incluir o seguinte: O processo de documentação é um processo para regis-
trar informações produzidas por um processo ou atividade
a) Descrição da substituição ou atualização com sua do ciclo de vida. O processo contém o conjunto de ativi-
data de disponibilidade; dades que planeja, projeta, desenvolve, produz, edita,
distribui e mantém aqueles documentos necessários a
b) Explicação do porquê o produto de software não todos os interessados, tais como gerentes, engenheiros
receberá mais suporte; e usuários do sistema ou produto de software.

c) Descrição de outras opções de suporte dispo- Lista das atividades. Este processo consiste nas seguintes
níveis, uma vez que o suporte seja descontinuado. atividades:

5.5.6.3 Operações paralelas do produto de software em 1) Implementação do processo;

descontinuação e do novo deveriam ser conduzidas para
transição gradual ao novo sistema. Durante este período,
2) Projeto e desenvolvimento;
deve ser provido treinamento de usuário, conforme es-
pecificado no contrato.
3) Produção;
5.5.6.4 Quando a descontinuação programada ocorrer,
devem ser enviadas notificações a todos os interessados. 4) Manutenção.
Toda documentação, históricos (logs) e código asso-
ciados ao desenvolvimento deveriam ser arquivados, 6.1.1 Implementação do processo. Esta atividade consiste
quando apropriado. nas seguintes tarefas:

5.5.6.5 Dados utilizados ou associados com o produto de 6.1.1.1 Um plano, identificando os documentos a serem
software descontinuado devem estar acessíveis, de acor- produzidos durante o ciclo de vida do produto de
do com os requisitos do contrato para preservação e audi- software, deve ser desenvolvido, documentado e imple-
toria dos dados. mentado. Para cada documento identificado, o seguinte
deve ser definido:
6 Processos de apoio de ciclo de vida
a) Título ou nome;
Este capítulo define os seguintes processos de apoio de
ciclo de vida: b) Propósito;

1) Processo de documentação; c) Público-alvo;

2) Processo de gerência de configuração; d) Procedimentos e responsabilidades pelas en-

tradas, desenvolvimento, revisão, alteração, apro-
3) Processo de garantia da qualidade; vação, produção, armazenamento, distribuição, ma-
nutenção e gerência de configuração.
4) Processo de verificação;
e) Cronograma das versões intermediárias e final.
5) Processo de validação;
6.1.2 Projeto e desenvolvimento. Esta atividade consiste
6) Processo de revisão conjunta;
nas seguintes tarefas:
7) Processo de auditoria;
6.1.2.1 Cada documento identificado deve ser projetado
de acordo com os padrões de documentação aplicáveis
8) Processo de resolução de problema.
no que se refere ao formato, descrição de conteúdo, nu-
meração de página, localização de figuras/tabelas, marcas
As atividades e tarefas em um processo de apoio são de
de propriedade/segurança, empacotamento, e outros
responsabilidade da organização que o executa.
itens de apresentação.
Essa organização garante que o processo existe e é fun-
cional.
6.1.2.2 A fonte e a adequação dos dados de entrada para
A organização que utiliza e executa um processo de apoio os documentos devem ser confirmadas. Ferramentas
o gerencia em nível de projeto, seguindo o processo de para a automatização da documentação podem ser uti-
gerência (7.1); estabelece uma infra-estrutura sob este lizadas.
processo, seguindo o processo de infra-estrutura (7.2);
adapta o processo para o projeto, seguindo o processo 6.1.2.3 Os documentos preparados devem ser revisados
de adaptação (anexo A); e gerencia o processo em nível e editados em comparação com os seus padrões de do-
organizacional, seguindo o processo de melhoria (7.3) e cumentação no que se refere ao formato, conteúdo técnico
o processo de treinamento (7.4). Revisões conjuntas, e estilo de apresentação. Eles devem ser aprovados
auditorias, verificação e validação podem ser utilizadas quanto à sua adequação, pelo pessoal autorizado, antes
como técnicas de garantia da qualidade. de sua emissão.
Cópia não autorizada

NBR ISO/IEC 12207:1998 19

6.1.3 Produção. Esta atividade consiste nas seguintes 6.2.2 Identificação da configuração. Esta atividade consiste
tarefas: na seguinte tarefa:

6.1.3.1 Os documentos devem ser produzidos e fornecidos 6.2.2.1 Uma sistemática para o projeto deve ser estabe-
de acordo com o plano. A produção e a distribuição dos lecida para a identificação dos itens de software e suas
documentos podem utilizar papel, meio eletrônico ou outra versões a serem controladas. Para cada item de
mídia. As matrizes devem ser armazenadas de acordo software e suas versões deve ser identificado o seguinte:
com os requisitos para guarda de registro, segurança, a documentação que estabelece a linha básica (baseline);
manutenção e cópia de segurança. as referências de versão e outros detalhes de identi-
ficação.
6.1.3.2 Controles devem ser estabelecidos, de acordo com
6.2.3 Controle da configuração. Esta atividade consiste
o processo de gerência de configuração (6.2).
na seguinte tarefa:
6.1.4 Manutenção. Esta atividade consiste na seguinte ta- 6.2.3.1 Deve ser executado o seguinte: identificação e
refa: registro dos pedidos de alteração; análise e avaliação
das alterações; aprovação ou rejeição do pedido; e imple-
6.1.4.1 Quando a documentação está para ser alterada, mentação, verificação e liberação do item de software
as tarefas necessárias devem ser executadas (5.5). Para modificado. Devem existir registros de auditoria, de tal
aqueles documentos que estão sob a gerência de confi- forma que, para cada modificação, a sua razão e a sua
guração, as alterações devem ser gerenciadas, de acordo autorização possam ser rastreadas. Deve ser realizado
com o processo de gerência de configuração (6.2). controle e auditoria de todos os acessos aos itens de
software controlados que tratam de funções críticas de
6.2 Processo de gerência de configuração proteção ou segurança.
O processo de gerência de configuração é um processo 6.2.4 Relato da situação da configuração. Esta atividade
de aplicação de procedimentos administrativos e téc- consiste na seguinte tarefa:
nicos, por todo o ciclo de vida de software, destinado a:
identificar e definir os itens de software em um sistema, e 6.2.4.1 Devem ser preparados registros de gerenciamento
estabelecer suas linhas básicas (baseline); controlar as e relatórios de situação que mostrem a situação e o his-
modificações e liberações dos itens; registrar e apre- tórico dos itens de software controlados, incluindo a linha
sentar a situação dos itens e dos pedidos de modificação; básica (baseline). Os relatórios de situação deveriam
garantir a completeza, a consistência e a correção dos incluir o número de alterações em um projeto, as últimas
itens; e controlar o armazenamento, a manipulação e a versões do item de software, identificadores de liberação,
distribuição dos itens. a quantidade de liberações e as comparações entre elas.

NOTA - O termo “item de software” pode ser empregado para 6.2.5 Avaliação da configuração. Esta atividade consiste
outros produtos de software ou entidades. na seguinte tarefa:

6.2.5.1 Deve ser determinado e garantido o seguinte: a

Lista das atividades. Este processo consiste nas seguintes
completeza funcional dos itens de software em relação
atividades:
aos seus requisitos e a completeza física dos itens de
software (ou seja, se seu projeto e código refletem uma
1) Implementação do processo;
descrição técnica atualizada).
2) Identificação da configuração; 6.2.6 Gerência de liberação e distribuição. Esta atividade
consiste na seguinte tarefa:
3) Controle da configuração;
6.2.6.1 A liberação e a distribuição de produtos de
4) Relato da situação da configuração; software e documentação devem ser formalmente con-
troladas. Cópias matrizes do código e da documentação
5) Avaliação da configuração; devem ser mantidas durante a vida do produto de
software. O código e a documentação que contenham
6) Gerência de liberação e distribuição. funções críticas de proteção ou segurança devem ser
manipulados, armazenados, empacotados e distribuídos
6.2.1 Implementação do processo. Esta atividade consiste de acordo com as políticas das organizações envolvidas.
na seguinte tarefa:
6.3 Processo de garantia da qualidade
6.2.1.1 Um plano de gerência de configuração deve ser
desenvolvido. O plano deve descrever: as atividades da O processo de garantia da qualidade é um processo para
gerência de configuração; procedimentos e cronograma fornecer garantia adequada de que os processos e pro-
para executar estas atividades; as organizações res- dutos de software, no ciclo de vida do projeto, estejam
ponsáveis pela execução destas atividades; e seu rela- em conformidade com seus requisitos especificados e
cionamento com outras organizações, como por exemplo sejam aderentes aos planos estabelecidos. Para ser im-
a de desenvolvimento ou manutenção de software. parcial, a garantia da qualidade necessita ter autoridade
O plano deve ser documentado e implementado. e autonomia organizacional, independente das pessoas
diretamente responsáveis pelo desenvolvimento do
NOTA - O plano pode ser parte do plano de gerência de confi- produto de software ou pela execução do processo no
guração do sistema. projeto.
Cópia não autorizada

20 NBR ISO/IEC 12207:1998

A garantia da qualidade pode ser interna ou externa, 6.3.1.5 Registros das atividades e tarefas de garantia da
dependendo da necessidade da qualidade do produto qualidade devem ser disponibilizados ao adquirente,
ou do processo ser evidenciada para a gerência do como especificado no contrato.
fornecedor ou do adquirente.
6.3.1.6 Deve ser assegurado que pessoas responsáveis
A garantia da qualidade pode utilizar os resultados de por garantir a conformidade aos requisitos do contrato
outros processos de apoio tais como: verificação, tenham autonomia, recursos e autoridade organi-
validação, revisões conjuntas, auditorias e resolução de zacionais, para possibilitar avaliações objetivas e para
problema. iniciar, efetuar, resolver e verificar resoluções de pro-
blemas.
Lista das atividades. Este processo consiste nas
seguintes atividades: 6.3.2 Garantia do produto. Esta atividade consiste nas
seguintes tarefas:
1) Implementação do processo;
6.3.2.1 Deve ser garantido que todos os planos exigidos
2) Garantia do produto;
pelo contrato sejam documentados, estejam de acordo
3) Garantia do processo; com o contrato, sejam mutuamente consistentes e sejam
executados quando requerido.
4) Sistemas de garantia da qualidade.
6.3.2.2 Deve ser garantido que os produtos de software e
6.3.1 Implementação do processo. Esta atividade consiste a documentação relacionada estejam de acordo com o
nas seguintes tarefas: contrato e aderentes aos planos.

6.3.1.1 Um processo de garantia da qualidade adaptado 6.3.2.3 Na preparação da entrega dos produtos de
ao projeto deve ser estabelecido. Os objetivos do pro- software deve ser garantido que os produtos de software
cesso de garantia da qualidade devem ser determinados, tenham seus requisitos contratuais inteiramente satis-
para garantir que os produtos de software e os processos feitos e sejam aceitáveis pelo adquirente.
empregados para fornecê-los estejam conforme os seus
requisitos estabelecidos e sejam aderentes aos seus 6.3.3 Garantia do processo. Esta atividade consiste nas
planos estabelecidos. seguintes tarefas:

6.3.1.2 O processo de garantia da qualidade deveria ser 6.3.3.1 Deve ser garantido que aqueles processos do ciclo
coordenado com os processos de verificação (6.4), de vida do sofware (fornecimento, desenvolvimento,
validação (6.5), revisão conjunta (6.6) e auditoria (6.7). operação, manutenção e os processos de apoio, in-
cluindo garantia da qualidade) empregados no projeto
6.3.1.3 Um plano para conduzir as atividades e tarefas do estejam de acordo com o contrato e aderentes aos planos.
processo de garantia da qualidade deve ser desen-
volvido, documentado, implementado e mantido durante 6.3.3.2 Deve ser garantido que as práticas internas de
a vigência do contrato. O plano deve incluir o seguinte: engenharia de software, ambiente de desenvolvimento,
ambiente de teste e bibliotecas estejam de acordo com o
a) Padrões de qualidade, metodologias, procedi-
contrato.
mentos e ferramentas para executar as atividades
de garantia da qualidade (ou referências na docu-
6.3.3.3 Deve ser garantido que os requisitos aplicáveis
mentação oficial da organização);
ao contrato original sejam passados para o subcontratado
b) Procedimentos para revisão de contrato e sua e que os produtos de software do subcontratado
coordenação; satisfaçam os requisitos do contrato original.

c) Procedimentos para identificação, coleta, arqui- 6.3.3.4 Deve ser garantido que o adquirente e outras
vamento, manutenção e disponibilização dos re- partes envolvidas sejam providos do apoio e da coope-
gistros da qualidade; ração requeridos, de acordo com o contrato, negociações
e planos.
d) Recursos, cronograma e responsabilidades para
conduzir as atividades de garantia da qualidade; 6.3.3.5 Deveria estar garantido que as medições do
produto e do processo de software estejam de acordo
e) Atividades e tarefas selecionadas dos processos com padrões e procedimentos estabelecidos.
de apoio, tais como verificação (6.4), validação (6.5),
revisão conjunta (6.6), auditoria (6.7) e resolução de 6.3.3.6 Deve ser garantido que a equipe alocada tenha a
problema (6.8). qualificação e o conhecimento necessários para atender
os requisitos do projeto e recebam todo treinamento
6.3.1.4 Atividades e tarefas de garantia da qualidade necessário.
agendadas e em andamento devem ser executadas.
Quando problemas ou não-conformidades aos requisitos 6.3.4 Sistemas de garantia da qualidade. Esta atividade
do contrato são detectados, devem ser documentados e consiste na seguinte tarefa:
servem de entrada ao processo de resolução de pro-
blema (seção 6.8). Registros destas atividades e tarefas, 6.3.4.1 Atividades adicionais de gerência da qualidade
sua execução, problemas e resoluções de problemas devem ser garantidas de acordo com as cláusulas da
devem ser gerados e mantidos. NBR ISO 9001, como especificado no contrato.
Cópia não autorizada

NBR ISO/IEC 12207:1998 21

6.4 Processo de verificação 6.4.1.5 Baseado nas tarefas de verificação determinadas

anteriormente, um plano de verificação deve ser desen-
O processo de verificação é um processo para determinar volvido e documentado. O plano deve indicar as ativi-
se os produtos de software de uma atividade atendem dades do ciclo de vida e produtos de software sujeitos a
completamente os requisitos ou condições impostas a verificação, as tarefas de verificação requeridas para
eles nas atividades anteriores. Para a eficácia de custo e cada atividade do ciclo de vida e produto de software; e
desempenho, a verificação deveria ser integrada, o quanto recursos, responsabilidades e cronograma associados.
antes, com o processo que a utiliza (tais como forneci- O plano deve indicar procedimentos para enviar relatórios
mento, desenvolvimento, operação ou manutenção). Este de verificação ao adquirente e outras organizações en-
processo pode incluir análise, revisão e teste. volvidas.

Este processo pode ser executado com variados graus 6.4.1.6 O plano de verificação deve ser implementado.
de independência. O grau de independência pode variar Problemas e não-conformidades detectados pelo esforço
da mesma pessoa ou outra pessoa da organização, para de verificação devem ser incluídos no processo de
uma pessoa de outra organização, com variados graus resolução de problema (6.8). Todos os problemas e não-
de envolvimento. No caso em que o processo é executado conformidades devem ser resolvidos. Os resultados das
por uma organização independente do fornecedor, de- atividades de verificação devem ser disponibilizados
senvolvedor, operador ou mantenedor, é chamado de para o adquirente e outras organizações envolvidas.
processo de verificação independente.
6.4.2 Verificação. Esta atividade consiste nas seguintes
Lista das atividades. Este processo consiste nas seguintes tarefas:
atividades:

1) Implementação do processo; 6.4.2.1 Verificação do contrato. O contrato deve ser

verificado considerando os seguintes critérios:
2) Verificação.
a) O fornecedor tem a capacidade de atender os re-
6.4.1 Implementação do processo. Esta atividade consiste quisitos.
nas seguintes tarefas:
b) Os requisitos estão consistentes e cobrem as
6.4.1.1 Deve ser determinado se o projeto justifica um necessidades do usuário.
esforço de verificação e o grau de independência organi-
zacional. Os requisitos do projeto devem ser analisados
c) Procedimentos adequados, para tratar alterações
em função dos fatores críticos. Estes fatores podem ser
nos requisitos e priorização de problemas, estão
aferidos nos seguintes termos:
estipulados.

a) O potencial de que um erro não detectado em um

requisito do sistema ou software possa causar morte d) Procedimentos e sua abrangência para interação
ou dano pessoal, não alcance de objetivos, perda e cooperação entre as partes são estipulados,
ou dano financeiro ou de equipamento; incluindo propriedade, garantia, direitos autorais e
confidencialidade.
b) A maturidade e riscos associados com a tecnologia
de software a ser utilizada; e e) Critérios e procedimentos de aceitação estão
estipulados de acordo com os requisitos.
c) A disponibilidade financeira e de recursos.
NOTA - Esta atividade pode ser usada na revisão do contrato
6.4.1.2 Se o projeto justifica um esforço de verificação, um (ver 6.3.1.3 b).
processo de verificação deve ser estabelecido para
verificar o produto de software.
6.4.2.2 Verificação do processo. O processo deve ser
verificado considerando os seguintes critérios:
6.4.1.3 Se o projeto justifica um esforço de verificação
independente, deve ser selecionada uma organização
qualificada responsável para conduzi-la. Esta organi- a) Os requisitos de planejamento do projeto estão
zação deve ter assegurada a independência e autoridade adequados e oportunos.
para executar as atividades de verificação.
b) Os processos selecionados para o projeto estão
6.4.1.4 Baseado no escopo, magnitude, complexidade e adequados, implementados, sendo executados
análise dos fatores críticos mencionados anteriormente, como planejados e conforme o contrato.
devem ser determinadas as atividades do ciclo de vida e
os produtos de software que requerem verificação. c) Os padrões, procedimentos e ambientes para os
As atividades e tarefas de verificação definidas no item processos do projeto estão adequados.
6.4.2, incluindo métodos, técnicas e ferramentas asso-
ciados para executar as tarefas, devem ser selecionadas
para as atividades do ciclo de vida e produtos de d) O projeto dispõe de equipe e pessoal capacitado,
software em questão. como requerido no contrato.
Cópia não autorizada

22 NBR ISO/IEC 12207:1998

6.4.2.3 Verificação dos requisitos. Os requisitos devem 6.4.2.7 Verificação da documentação. A documentação
ser verificados considerando os seguintes critérios: deve ser verificada, considerando os seguintes critérios:

a) Os requisitos do sistema são consistentes, viáveis a) A documentação está adequada, completa e

e testáveis. consistente.
b) Os requisitos do sistema foram distribuídos apro- b) A preparação da documentação está oportuna.
priadamente para os itens de hardware, itens de
software e operações manuais, de acordo com os c) A gerência de configuração dos documentos segue
critérios do projeto. procedimentos especificados.
c) Os requisitos de software são consistentes, viáveis, 6.5 Processo de validação
testáveis e refletem precisamente os requisitos do
sistema. O processo de validação é um processo para determinar
se os requisitos e o produto final, sistema ou produto de
d) Os requisitos de software relacionados à proteção,
software construído, atendem ao uso específico pre-
à segurança e aos fatores críticos estão corretos,
tendido. A validação pode ser conduzida nos estágios
conforme demonstrado por métodos adequadamente
iniciais. Este processo pode ser conduzido como parte
rigorosos.
da atividade de apoio à aceitação do software (5.3.13).
6.4.2.4 Verificação de projeto. O projeto deve ser verificado
considerando os seguintes critérios: Este processo pode ser executado com variados graus
de independência. O grau de independência pode variar
a) O projeto está correto e consistente com os re- da mesma pessoa ou outra pessoa da organização, para
quisitos e rastreável aos mesmos. uma pessoa de outra organização, com variados graus
de envolvimento. No caso em que o processo é executado
b) O projeto implementa uma seqüência adequada
por uma organização independente do fornecedor,
de eventos, entradas, resultados, interfaces, fluxo
desenvolvedor, operador ou mantenedor, é chamado de
lógico, alocação de tempo e de orçamentos, e de-
processo de validação independente.
finição, isolamento e recuperação de erro.

c) O projeto selecionado pode ser originado a partir Lista das atividades. Este processo consiste nas seguintes
dos requisitos. atividades:

d) O projeto implementa proteção, segurança e 1) Implementação do processo;

outros requisitos críticos corretamente, conforme
demonstrado por métodos adequadamente rigo- 2) Validação.
rosos.
6.5.1 Implementação do processo. Esta atividade consiste
6.4.2.5 Verificação do código. O código deve ser verificado, nas seguintes tarefas:
considerando os seguintes critérios:
6.5.1.1 Deve ser determinado se o projeto justifica um
a) O código é rastreável para o projeto e para os re- esforço de validação e o grau de independência organi-
quisitos, testável, correto e aderente aos requisitos e zacional.
padrões de codificação.
6.5.1.2 Se o projeto justifica um esforço de validação, um
b) O código implementa a seqüência de eventos processo de validação deve ser estabelecido para validar
apropriada, interfaces consistentes, dados e fluxo o sistema ou o produto de software. As tarefas de vali-
de controle corretos, completeza, alocação de tempo dação definidas a seguir, incluindo métodos, técnicas e
e de orçamentos apropriada, e definição, isolamento ferramentas associados para executar as tarefas, devem
e recuperação de erros. ser selecionadas.
c) O código selecionado pode ser originado a partir
6.5.1.3 Se o projeto justifica um esforço de validação
do projeto ou dos requisitos.
independente, deve ser selecionada uma organização
d) O código implementa proteção, segurança e outros qualificada responsável para conduzi-la. O condutor deve
requisitos críticos corretamente, conforme demons- ter assegurada a independência e autoridade para exe-
trado por métodos adequadamente rigorosos. cutar as tarefas de validação.

6.4.2.6 Verificação da integração. A integração deve ser 6.5.1.4 Um plano de validação deve ser desenvolvido e
verificada considerando os seguintes critérios: documentado. O plano deve incluir, mas não estar limitado
ao seguinte:
a) Os componentes de software e unidades de cada
item de software foram completa e corretamente a) Itens sujeitos à validação;
integrados dentro do item de software.
b) Tarefas de validação a serem executadas;
b) Os itens de hardware, de software e operações
manuais do sistema foram completa e corretamente c) Recursos, responsabilidades e cronograma para
integrados ao sistema. validação; e

c) As tarefas de integração foram executadas de d) Procedimentos para encaminhar relatórios de va-

acordo com um plano de integração. lidação ao adquirente e outras partes envolvidas.
Cópia não autorizada

NBR ISO/IEC 12207:1998 23

6.5.1.5 O plano de validação deve ser implementado. 6.6.1.2 Todos os recursos requeridos para conduzir as
Problemas e não-conformidades detectados pelo esforço revisões devem ser acordados pelas partes. Estes re-
de validação devem ser incluídos no processo de reso- cursos incluem pessoal, local, instalações, hardware,
lução de problema (6.8). Todos os problemas e não- software e ferramentas.
conformidades devem ser resolvidos. Os resultados das
atividades de validação devem ser disponibilizados para 6.6.1.3 As partes deveriam concordar com os seguintes
o adquirente e outras organizações envolvidas. itens em cada revisão: agenda da reunião, produtos de
software (resultados de uma atividade) e problemas a
6.5.2 Validação. Esta atividade consiste nas seguintes serem revisados; escopo e procedimentos; e critérios
tarefas: para início e término da revisão.
6.5.2.1 Preparar os requisitos de teste, casos de teste e
especificações de teste selecionados para análise dos 6.6.1.4 Problemas detectados durante as revisões devem
resultados dos testes. ser registrados e incluídos no processo de resolução de
problema (6.8), conforme requerido.
6.5.2.2 Assegurar que estes requisitos de teste, casos de
teste e especificações de teste reflitam os requisitos 6.6.1.5 Os resultados da revisão devem ser documentados
particulares para o uso específico pretendido. e distribuídos. A parte revisora apresentará à parte revi-
sada a adequabilidade (por exemplo: aprovação, desa-
6.5.2.3 Conduzir os testes nos itens 6.5.2.1 e 6.5.2.2, provação ou aprovação condicional) dos resultados da
incluindo: revisão.

a) Teste de estresse, limites e entradas específicas. 6.6.1.6 As partes devem concordar com os resultados da
revisão e quaisquer responsabilidades pelo item de ação
b) Teste do produto de software para verificar sua
e critérios de encerramento.
habilidade em isolar e minimizar efeitos de erros;
isto é, degradação suave em caso de falha, pedido
de assistência do operador em caso de estresse, de 6.6.2 Revisões de gerenciamento do projeto. Esta atividade
exceder limites e de condições específicas. consiste na seguinte tarefa.

c) Teste para que usuários representativos possam 6.6.2.1 A situação do projeto deve ser avaliada em relação
executar, com sucesso, suas tarefas pretendidas aos planos, cronogramas, padrões e diretrizes aplicáveis
usando o produto de software. ao projeto. O resultado da revisão deveria ser discutido
entre as duas partes e deveria fornecer subsídios para o
6.5.2.4 Validar que o produto de software satisfaça seu seguinte:
uso pretendido.
a) Fazer com que as atividades progridam de acordo
6.5.2.5 Testar o produto de software, quando apropriado,
com o plano, baseado em uma avaliação da situação
nas áreas selecionadas do ambiente-alvo.
da atividade ou do produto de software;
6.6 Processo de revisão conjunta
b) Manter o controle geral do projeto através da alo-
O processo de revisão conjunta é um processo para cação adequada de recursos;
avaliar a situação e produtos de uma atividade de um
projeto, se apropriado. As revisões conjuntas são feitas c) Redirecionar o projeto ou determinar a necessi-
tanto nos níveis de gerenciamento do projeto como nos dade de um planejamento alternativo; e
níveis técnicos e são executadas durante a vigência do
contrato. Este processo pode ser empregado por d) Avaliar e gerenciar as situações de risco que
qualquer das duas partes, onde uma parte (parte revisora) possam comprometer o sucesso do projeto.
revisa a outra parte (parte revisada).

Lista das atividades. Este processo consiste nas seguintes 6.6.3 Revisões técnicas. Esta atividade consiste na seguinte
atividades: tarefa:

1) Implementação do processo; 6.6.3.1 Revisões técnicas devem ser promovidas para

avaliar os produtos ou serviços de software em conside-
2) Revisões de gerenciamento do projeto; ração e prover evidência de que:

3) Revisões técnicas.
a) Eles estão completos;
6.6.1 Implementação do processo. Esta atividade consiste
nas seguintes tarefas: b) Eles estão aderentes aos seus padrões e espe-
cificações;
6.6.1.1 Revisões periódicas devem ser promovidas em
marcos predeterminados, como especificado no(s) c) Suas alterações estão implementadas adequa-
plano(s) do projeto. Revisões ad hoc deveriam ser damente e afetam somente aquelas áreas identi-
realizadas quando julgadas necessárias por quaisquer ficadas pelo processo de gerência de configura-
das partes. ção (6.2);
Cópia não autorizada

24 NBR ISO/IEC 12207:1998

d) Eles estão aderentes aos cronogramas aplicáveis; c) Dados de teste estejam aderentes à especificação;

e) Eles estão prontos para a próxima atividade; e

d) Os produtos de software sejam testados com su-
f) O desenvolvimento, operação ou manutenção estão cesso e atendam às suas especificações;
sendo conduzidos de acordo com os planos, cro-
nogramas, padrões e diretrizes do projeto. e) Os relatórios de teste estejam corretos e discre-
pâncias entre o resultado real e o esperado sejam
6.7 Processo de auditoria resolvidos;
O processo de auditoria é um processo para determinar
adequação aos requisitos, planos e contrato, quando f) A documentação do usuário esteja aderente aos
apropriado. Este processo pode ser empregado por padrões, conforme o especificado;
quaisquer das duas partes, onde uma parte (parte
auditora) faz a auditoria nos produtos de software ou nas g) As atividades sejam conduzidas de acordo com
atividades da outra parte (parte auditada). os requisitos, planos e contrato aplicáveis; e

Lista das atividades. Este processo consiste nas seguintes h) Os custos e cronogramas adiram aos planos es-
atividades: tabelecidos.
1) Implementação do processo;
6.8 Processo de resolução de problema
2) Auditoria.
O processo de resolução de problema é um processo
6.7.1. Implementação do processo. Esta atividade consiste
para analisar e resolver os problemas (incluindo não-
nas seguintes tarefas:
conformidades), de qualquer natureza ou fonte, que são
6.7.1.1 As auditorias devem ser promovidas em marcos descobertos durante a execução do desenvolvimento,
predeterminados, conforme especificado no(s) plano(s) operação, manutenção ou outros processos. O objetivo
do projeto. é prover os meios em tempo adequado e de forma res-
ponsável e documentada para garantir que todos os pro-
6.7.1.2 O pessoal da auditoria não deve ter nenhuma blemas encontrados sejam analisados e resolvidos e
responsabilidade direta pelos produtos de software e tendências sejam identificadas.
atividades que eles auditam.
Lista das atividades. Este processo consiste nas seguintes
6.7.1.3 Todos os recursos requeridos para conduzir a atividades:
auditoria devem ser acordados pelas partes. Esses
recursos incluem pessoal de apoio, local, instalações,
hardware, software e ferramentas. 1) Implementação do processo;

6.7.1.4 As partes deveriam concordar com os seguintes 2) Resolução de problema.

itens em cada auditoria: agenda; produtos de software (e
resultados de uma atividade) a serem revisados; escopo 6.8.1 Implementação do processo. Esta atividade consiste
e procedimentos da auditoria; e critérios de início e na seguinte tarefa:
término da auditoria.

6.7.1.5 Problemas detectados durante as auditorias 6.8.1.1 Um processo de resolução de problema deve ser
devem ser registrados e incluídos no processo de reso- estabelecido para tratar todos os problemas (incluindo
lução de problema (6.8), quando requerido. não-conformidades) detectados nos produtos de
software e atividades. O processo deve atender aos se-
6.7.1.6 Após a conclusão de uma auditoria, os resultados guintes requisitos:
da auditoria devem ser documentados e entregues à parte
auditada. A parte auditada deve apresentar à parte audi- a) O processo deve ser de ciclo fechado (closed-
tora quaisquer problemas encontrados na auditoria e o loop), garantindo que: todos os problemas detectados
planejamento das resoluções dos problemas relatados. sejam prontamente relatados e incluídos no processo
de resolução de problema; a ação seja iniciada nos
6.7.1.7 As partes devem concordar com o resultado da
problemas detectados; as partes relevantes sejam
auditoria e quaisquer responsabilidades pelo item de
alertadas da existência do problema, quando
ação e critérios de encerramento.
apropriado; as causas sejam identificadas, anali-
6.7.2. Auditoria. Esta atividade consiste na seguinte tarefa: sadas e, quando possível, eliminadas; a resolução e
sua aplicação sejam alcançadas; a situação seja
6.7.2.1 As auditorias devem ser conduzidas para asse- rastreada e relatada; e os registros dos problemas
gurar que: sejam mantidos, conforme estipulado no contrato;

a) Produtos de software codificados (tais como item b) O processo deveria conter um esquema para cate-
de software) reflitam a documentação do projeto; gorizar e priorizar os problemas. Cada problema
b) A revisão de aceitação e requisitos de teste pres- deveria ser classificado por categoria e prioridade
critos pela documentação estejam adequados para para facilitar a análise de tendência e resolução de
aceitação dos produtos de software; problema;
Cópia não autorizada

NBR ISO/IEC 12207:1998 25

c) A análise deve ser executada para detectar ten- 7.1.1 Iniciação e definição do escopo. Esta atividade
dências nos problemas relatados; consiste nas seguintes tarefas:

d) As resoluções de problemas e suas aplicações 7.1.1.1 O processo de gerência deve ser iniciado pelo
devem ser avaliadas para: verificar se os problemas estabelecimento dos requisitos do processo a ser
foram resolvidos, se as tendências adversas foram empreendido.
revertidas e se as alterações foram implementadas
7.1.1.2 Tendo estabelecido os requisitos, o gerente deve
corretamente nos produtos de software e atividades
estabelecer a viabilidade do processo, verificando se os
apropriados; e determinar se problemas adicionais
recursos (de pessoal, materiais, tecnológicos e de am-
foram introduzidos.
biente) requeridos para executar e gerenciar o processo
estão disponíveis, adequados e apropriados e se os
6.8.2 Resolução do problema. Esta atividade consiste na
prazos para conclusão podem ser atingidos.
seguinte tarefa:
7.1.1.3 Quando necessário, e com a concordância de
6.8.2.1 Quando problemas (incluindo não-conformidades) todas as partes envolvidas, os requisitos do processo
forem detectados em um produto de software ou em uma podem ser modificados neste ponto para atingir os
atividade, um relatório de problema deve ser preparado critérios de conclusão.
para descrever cada problema detectado. O relatório de
problema deve ser usado como parte do processo de 7.1.2 Planejamento. Esta atividade consiste na seguinte
ciclo fechado (closed-loop) descrito acima: a partir da tarefa:
detecção do problema, ao longo da investigação, análise
e resolução do problema e sua causa, e para detectar 7.1.2.1 O gerente deve preparar os planos para execução
tendências. do processo. Os planos associados à execução do pro-
cesso devem conter descrições das tarefas e atividades
7 Processos organizacionais de ciclo de vida associadas e identificação dos produtos de software que
serão providos. Esses planos não se limitam a, mas
Este capítulo define os seguintes processos organi- devem incluir o seguinte:
zacionais de ciclo de vida:
a) Cronogramas para a conclusão oportuna das ta-
refas;
1) Processo de gerência;
b) Estimativa de esforço;
2) Processo de infra-estrutura;
c) Recursos adequados necessários para executar
3) Processo de melhoria; as tarefas;

4) Processo de treinamento. d) Alocação das tarefas;

e) Atribuição de responsabilidades;
As atividades e tarefas em um processo organizacional
são de responsabilidade da organização que o utiliza. f) Quantificação de riscos associados com as tarefas
Essa organização garante que o processo existe e é fun- ou com o próprio processo;
cional.
g) Medidas de controle de qualidade a serem em-
7.1 Processo de gerência pregadas durante o processo;

O processo de gerência contém as atividades e tarefas h) Custos associados com a execução do processo;
genéricas que podem ser empregadas por quaisquer das
i) Provisão de ambiente e infra-estrutura.
partes que têm que gerenciar seu(s) respectivo(s)
processo(s). O gerente é responsável pelo gerenciamento 7.1.3 Execução e controle. Esta atividade consiste nas
de produto, gerenciamento de projeto e gerenciamento seguintes tarefas:
de tarefa do(s) processo(s) aplicável(eis), tais como
aquisição, fornecimento, desenvolvimento, operação, 7.1.3.1 O gerente deve iniciar a implementação do plano
manutenção ou processos de apoio. para atender o conjunto de objetivos e critérios, exer-
cendo controle sobre o processo.
Lista de atividades. Este processo consiste nas seguintes
atividades: 7.1.3.2 O gerente deve monitorar a execução do processo,
provendo relatórios internos do progresso do processo e
1) Iniciação e definição do escopo; relatórios externos para o adquirente, conforme definido
no contrato.
2) Planejamento;
7.1.3.3 O gerente deve investigar, analisar e resolver os
problemas descobertos durante a execução do processo.
3) Execução e controle;
A resolução de problema pode resultar em alterações
dos planos. É responsabilidade do gerente garantir que
4) Revisão e avaliação; o impacto de quaisquer alterações seja determinado,
controlado e monitorado. Os problemas e suas resoluções
5) Conclusão. devem ser documentados.
Cópia não autorizada

26 NBR ISO/IEC 12207:1998

7.1.3.4 O gerente deve reportar em pontos acordados o 7.2.2.2 A infra-estrutura deve ser instalada a tempo para a
progresso do processo, demonstrando aderência aos execução do processo relevante.
planos e resolvendo casos de necessidade de progresso.
Isto inclui relatórios internos e externos, conforme 7.2.3 Manutenção da infra-estrutura. Esta atividade
requerem os procedimentos organizacionais e o contrato. consiste na seguinte tarefa:
7.1.4 Revisão e avaliação. Esta atividade consiste nas
seguintes tarefas: 7.2.3.1 A infra-estrutura deve ser mantida, monitorada e
modificada quando necessário, para garantir que ela con-
7.1.4.1 O gerente deve garantir que o software e os planos tinue a satisfazer os requisitos do processo que emprega
sejam avaliados para satisfazer requisitos. este processo. Como parte da manutenção da infra-
estrutura, deve ser definido até que ponto a infra-estrutura
7.1.4.2 O gerente deve verificar os resultados da avaliação está sob controle da gerência de configuração.
dos produtos de software, atividades e tarefas finalizados
durante a execução do processo para atingir os objetivos 7.3 Processo de melhoria
e para concluir os planos.

7.1.5 Conclusão. Esta atividade consiste nas seguintes O processo de melhoria é um processo para estabelecer,
tarefas: avaliar, medir, controlar e melhorar um processo de ciclo
de vida de software.
7.1.5.1 Quando todos os produtos de software, atividades
e tarefas estiverem completos, o gerente deve determinar Lista de atividades: Este processo consiste nas seguintes
se o processo está completo, levando em consideração atividades:
os critérios especificados no contrato ou como parte de
um procedimento da organização.
1) Estabelecimento do processo;
7.1.5.2 Para finalizar, o gerente deve verificar os resultados
e registros dos produtos de software, atividades e tarefas 2) Avaliação do processo;
empregados. Estes resultados e registros devem ser
arquivados em um ambiente adequado, conforme 3) Melhoria do processo.
especificado no contrato.

7.2 Processo de infra-estrutura 7.3.1 Estabelecimento do processo. Esta atividade consiste

nas seguintes tarefas:
O processo de infra-estrutura é um processo para esta-
belecer e manter a infra-estrutura necessária para 7.3.1.1 A organização deve estabelecer um conjunto de
qualquer outro processo. A infra-estrutura pode incluir processos organizacionais para todos os processos de
hardware, software, ferramentas, técnicas, padrões e ciclo de vida de software que se aplicam para suas ati-
recursos para o desenvolvimento, operação ou manu- vidades de negócio. Os processos e suas aplicações
tenção. para casos específicos devem ser documentados em pu-
blicações da organização. Quando apropriado, um meca-
Lista de atividades. Este processo consiste nas seguintes nismo de controle de processo deveria ser estabelecido
atividades: para desenvolver, monitorar, controlar e melhorar o(s)
processo(s).
1) Implementação do processo;

2) Estabelecimento da infra-estrutura; 7.3.2 Avaliação do processo. Esta atividade consiste nas

seguintes tarefas:
3) Manutenção da infra-estrutura.
7.3.2.1 Um procedimento de avaliação de processo
7.2.1 Implementação do processo. Esta atividade consiste deveria ser desenvolvido, documentado e aplicado.
nas seguintes tarefas: Registros de avaliação deveriam ser guardados e
preservados.
7.2.1.1 A infra-estrutura deveria ser definida e docu-
mentada de acordo com os requisitos do processo que
emprega este processo, considerando os procedimentos, 7.3.2.2 A organização deve planejar e executar revisões
padrões, ferramentas e técnicas aplicáveis. dos processos em intervalos apropriados para garantir
sua contínua adequação e eficiência, considerando os
7.2.1.2 O estabelecimento da infra-estrutura deveria ser resultados da avaliação.
planejado e documentado.
7.3.3 Melhoria do processo. Esta atividade consiste nas
7.2.2 Estabelecimento da infra-estrutura. Esta atividade seguintes tarefas:
consiste nas seguintes tarefas:

7.2.2.1 A configuração da infra-estrutura deveria ser pla- 7.3.3.1 A organização deve efetuar tais melhorias nos
nejada e documentada. Deveriam ser considerados: a seus processos se for determinada esta necessidade,
funcionalidade, o desempenho, a proteção, a segurança, como resultado da avaliação e revisão do processo. A
a disponibilidade, os requisitos de espaço, os equipa- documentação do processo deveria ser atualizada para
mentos, os custos e as restrições de tempo. refletir a melhoria dos processos organizacionais.
Cópia não autorizada

NBR ISO/IEC 12207:1998 27

7.3.3.2 Dados históricos, técnicos e de avaliação de- 7.4.1 Implementação do processo. Esta atividade consiste
veriam ser coletados e analisados para aumentar um na seguinte tarefa:
entendimento dos pontos fortes e fracos dos processos
empregados. Estas análises deveriam ser usadas como 7.4.1.1 Uma revisão dos requisitos do projeto deve ser
realimentação (feedback) para melhorar estes processos, conduzida para estabelecer e providenciar, oportu-
para recomendar alterações nas diretrizes dos projetos namente, a aquisição ou o desenvolvimento de recursos
(ou projetos subseqüentes), e para determinar necessi- e conhecimentos necessários ao pessoal técnico e ge-
dades de avanços tecnológicos. rencial. Os tipos e níveis de treinamento e categorias de
7.3.3.3 Dados de custo de qualidade deveriam ser cole- pessoal que necessitam de treinamento devem ser
tados, mantidos e usados, para melhorar os processos determinados. Um plano de treinamento deveria ser
da organização como uma atividade gerencial. Estes desenvolvido e documentado, de acordo com os cro-
dados devem servir ao propósito de estabelecer o custo nogramas de implementação, requisitos de recurso e ne-
de prevenção e resolução de problemas e não-conformi- cessidades de treinamento.
dade em produtos e serviços de software.
7.4.2 Desenvolvimento do material de treinamento. Esta
7.4 Processo de treinamento
atividade consiste na seguinte tarefa:
O processo de treinamento é um processo para prover e
manter pessoal treinado. A aquisição, o fornecimento, o 7.4.2.1 Manuais de treinamento, incluindo materiais de
desenvolvimento, a operação ou a manutenção de pro- apresentação utilizados para prover treinamento,
dutos de software é extremamente dependente de deveriam ser desenvolvidos.
pessoal com conhecimento e qualificação. Por exemplo:
pessoal de desenvolvimento deveria ter treinamento bá-
7.4.3 Implementação do plano de treinamento. Esta
sico em gerência de software e engenharia de software.
atividade consiste nas seguintes tarefas:
É, portanto, imperativo que o treinamento de pessoal seja
planejado e implementado com antecedência para que
o pessoal treinado esteja disponível quando o produto 7.4.3.1 O plano de treinamento deve ser implementado
de software for adquirido, fornecido, desenvolvido, ope- para prover treinamento ao pessoal. Registros de treina-
rado ou mantido. mento deveriam ser preservados.

Lista de atividades. Este processo consiste nas seguintes

atividades: 7.4.3.2 Deveria ser assegurado que uma equipe ade-
quadamente treinada esteja disponível, oportunamente,
1) Implementação do processo; para as atividades e tarefas planejadas. Esta equipe
deveria ser formada por uma composição e categorias
2) Desenvolvimento do material de treinamento; corretas de pessoal.
3) Implementação do plano de treinamento.

/ANEXOS
Cópia não autorizada

28 NBR ISO/IEC 12207:1998

Anexo A (normativo)
Processo de adaptação

O processo de adaptação é um processo para realizar a A.3 Seleção de processos, atividades e tarefas.
adaptação básica desta Norma para um projeto de Esta atividade consiste nas seguintes tarefas:
software. Este anexo fornece requisitos para adaptar esta
Norma. A.3.1 Os processos, atividades e tarefas que serão exe-
Lista de atividades. Este processo consiste nas seguintes cutados devem ser determinados. Isto inclui a documen-
atividades: tação a ser desenvolvida e quem será responsável por
ela. Para este propósito, esta Norma deveria ser avaliada
1) Identificação do ambiente do projeto; em relação aos dados relevantes reunidos em A.1 e A.2.

2) Solicitação de informações;
A.3.2 Os processos, atividades e tarefas que foram de-
3) Seleção de processos, atividades e tarefas; terminados em A.3.1, mas não providos nesta Norma,
devem ser especificados no próprio contrato. Proces-
4) Documentação de decisões e motivos da adap- sos organizacionais do ciclo de vida (seção 7) deveriam
tação. ser avaliados para determinar se eles poderiam dar sus-
tentação a estes processos, atividades e tarefas.
A.1 Identificação do ambiente do projeto. Esta ativi-
dade consiste na seguinte tarefa:
A.3.3 Nesta Norma, requisitos são indicados pelas
A.1.1 As características do ambiente do projeto que influ- tarefas que contêm “deve” ou “deverá”. Deveria ser cuida-
enciarão na adaptação devem ser identificadas. Algumas dosamente considerado se estas tarefas devem ser
das características podem ser: modelo de ciclo de vida; mantidas ou suprimidas para um determinado projeto
atividade atual de ciclo de vida de sistema; requisitos do ou setor de negócio. Os fatores a serem considerados
sistema e do software; políticas, procedimentos e estra- não se limitam a, mas incluem: risco, custo, cronograma,
tégias organizacionais; tamanho, criticabilidade e tipos desempenho, tamanho, criticabilidade e interface
do sistema, produto ou serviço de software; e quantidade humana.
de pessoas e partes envolvidas.

A.2 Solicitação de informações. Esta atividade con- A.4 Documentação de decisões e motivos da
siste na seguinte tarefa: adaptação. Esta atividade consiste na seguinte tarefa:

A.2.1 As informações das organizações que são afetadas A.4.1 Todas as decisões de adaptação devem ser docu-
pelas decisões de adaptação devem ser solicitadas. mentadas juntamente com seus motivos.
Usuários, pessoal de suporte, gerentes de contrato e po-
tenciais proponentes deveriam ser envolvidos na
adaptação.

/ANEXO B
Cópia não autorizada

NBR ISO/IEC 12207:1998 29

Anexo B (informativo)
Orientação para adaptação

Nenhum projeto é idêntico a outro. Variações nas políticas b) Verificação (6.4) e validação (6.5) são conduzidas
e procedimentos organizacionais, métodos e estratégias pelo adquirente, pelo fornecedor ou por uma parte
de aquisição, tamanho e complexidade do projeto, independente, para verificar e validar os produtos
requisitos e métodos de desenvolvimento do sistema, em níveis variáveis de detalhamento, dependendo
entre outras coisas, influenciam na forma como um do projeto. Estas avaliações não são redundantes
sistema é adquirido, desenvolvido, operado e mantido. nem substituem outras avaliações, apenas as
Para acomodar essas variações, tanto quanto possível, complementam.
esta Norma foi escrita para um projeto genérico. Portanto,
no interesse de redução de custo e melhoria da c) Revisões conjuntas (6.6) e auditorias (6.7) são
qualidade, esta Norma deveria ser adaptada para um conduzidas em um fórum conjunto pelas partes
projeto específico. Todas as partes envolvidas no projeto revisora e revisada, para avaliar o estado e a confor-
deveriam ser envolvidas na adaptação. midade de produtos e atividades, em relação aos
cronogramas previamente acordados.
B.1 Orientação geral de adaptação
d) Garantia da qualidade (6.3) é conduzida por
Esta seção provê orientação na adaptação desta Norma pessoal independente do pessoal diretamente
e não é exaustiva. Esta seção pode ser usada para responsável pelo desenvolvimento do produto de
realizar um primeiro nível de adaptação desta Norma software ou pela execução do processo. O objetivo
para uma determinada organização ou área de negócio. é garantir, com independência, a conformidade dos
Por exemplo, aeronáutica, nuclear, médica, militar, produtos de software e processos com os requisitos
agropecuária, comercial. Um segundo nível de adaptação do contrato e aderência aos planos estabelecidos.
deveria ser realizado para cada projeto ou contrato Este processo pode utilizar os resultados de a, b e c,
específico. descritos anteriormente, como entradas. Este
processo pode coordenar suas atividades com as
B.2 Adaptação do processo de desenvolvimento de a, b e c.

O processo de desenvolvimento (5.3) necessita de e) Melhoria (7.3) é conduzida por uma organização
atenção especial, porque este processo pode ser utilizado para o gerenciamento eficiente e automelhoria de
por diferentes partes, com objetivos diferentes. Como um seu processo. Esta é conduzida independentemente
primeiro nível de adaptação deste processo, é recomen- do projeto ou requisitos do contrato.
dado o seguinte: B.4 Considerações de adaptação e aplicação
a) Para um produto de software que esteja embutido Os parágrafos desta seção fornecem uma visão geral de
ou integrado ao sistema: todas as atividades do considerações de adaptação e aplicação para as ca-
processo deveriam ser consideradas e deveria ser racterísticas chave do projeto. As considerações e as ca-
esclarecido se o desenvolvedor é requerido para racterísticas não são exaustivas e representam apenas a
executar ou dar suporte às atividades do sistema. forma atual de pensar. A figura B.1 fornece um exemplo
da aplicação desta Norma.
b) Para um produto de software independente, as
atividades do sistema (5.3.2, 5.3.3, 5.3.10 e 5.3.11) Políticas organizacionais. Determina quais políticas
podem não ser requeridas, mas deveriam ser con- organizacionais são relevantes e aplicáveis, tais como:
sideradas. linguagens de computador, proteção e segurança, re-
quisitos do hardware e gerenciamento de risco. As se-
B.3 Adaptação das atividades relacionadas com ções desta Norma, relacionadas com estas políticas
avaliação organizacionais, deveriam ser mantidas.
As pessoas envolvidas em qualquer atividade de um Estratégia de aquisição. Determina quais estratégias de
processo ou de ciclo de vida de um projeto, conduzem aquisição são relevantes e aplicáveis para o projeto, tais
avaliações de produto de software e atividades, próprios como: tipos de contrato, mais de um contratado, envol-
ou de outros. Esta Norma agrupa estas avaliações em vimento de subcontratados e agentes de verificação e
cinco categorias, as quais estão listadas abaixo. As quatro validação, nível de envolvimento do adquirente com os
primeiras categorias de avaliação estão em nível de contratados e avaliação da capacidade dos contratados.
projeto; a última está em nível organizacional. Estas As seções desta Norma, relacionadas com estas
avaliações deveriam ser selecionadas e adaptadas de estratégias, deveriam ser mantidas.
acordo com o escopo, magnitude, complexidade e critica-
bilidade do projeto ou da organização. Os relatórios de Conceito de suporte. Determina quais conceitos de
problema, de não-conformidade e de melhoria destas suporte são relevantes e aplicáveis, tais como: duração
avaliações alimentam o processo de resolução de esperada de suporte, grau de alteração e se o suporte
problema (6.8). será fornecido pelo adquirente ou pelo fornecedor. Para
um produto de software que venha a ter uma vida longa
a) Avaliações internas de processos (tarefas de de suporte ou para o qual se espere mudanças signifi-
avaliação de 5.1 a 5.5) são conduzidas pelo pessoal cativas, todos os requisitos de documentação deveriam
que executa as tarefas atribuídas, dentro do pro- ser considerados. É aconselhável ter a documentação
cesso, durante as suas atividades diárias. automatizada.
Cópia não autorizada

30 NBR ISO/IEC 12207:1998

Modelo(s) de ciclo de vida. Determina qual(is) modelo(s) Características do nível de software. Determina quais as
de ciclo de vida é(são) relevante(s) e aplicável(is) para o características do nível de software são relevantes e
projeto, tais como cascata, evolucionário, construtivo, in- aplicáveis, tais como: quantidade de itens de software,
cremental e espiral. Todos estes modelos prescrevem tipos, tamanho e criticabilidade dos produtos de software,
certos processos e atividades que podem ser executados e riscos técnicos. Se o produto de software tiver muitos
em seqüência, repetidamente e em combinação; nestes itens de software, componentes e unidades, o processo
modelos as atividades de ciclo de vida desta Norma de desenvolvimento (5.3) deveria ser cuidadosamente
deveriam ser mapeadas para o(s) modelo(s) sele- adaptado para cada item de software. Todos os requisitos
cionado(s). Para os modelos evolucionário, construtivo e de interface e de integração deveriam ser considerados.
incremental, os resultados de uma atividade do projeto
alimentam a próxima. Nestes casos, a documentação Determina quais tipos de produto de software estão
deveria estar completa ao final de uma atividade ou tarefa. envolvidos, pois tipos diferentes de software podem
requerer diferentes decisões de adaptação. Alguns
Partes envolvidas. Determina ou identifica a quantidade exemplos:
de pessoas e quais partes estão envolvidas no projeto,
tais como: adquirente, fornecedor, desenvolvedor, a) Novo desenvolvimento. Todos os requisitos,
subcontratado, agente de verificação, agente de vali- particularmente o processo de desenvolvimento
dação, mantenedor. Todos os requisitos relacionados (5.3), deveriam ser considerados
com as interfaces organizacionais entre duas partes estão
b) Uso de produto de software de prateleira na forma
sob consideração; por exemplo, adquirente com de-
em que se encontra. Todo o processo de desen-
senvolvedor, e fornecedor com agente de verificação ou
volvimento (5.3) pode ser excessivo. Desempenho,
de validação. Um grande projeto envolvendo muitas
documentação, direitos de propriedade, de uso, de
pessoas (dezenas ou centenas) necessita de significativa
autoria, de garantia e de licença e suporte futuro re-
supervisão e controle gerenciais. Ferramentas, tais como:
lacionado ao produto de software, deveriam ser
avaliações internas e independentes, revisões, audito-
avaliados.
rias, inspeções e coleta de dados são importantes para
um grande projeto. Para projetos pequenos, estes c) Modificação do produto de software de prateleira.
controles podem ser excessivos. A documentação pode não estar disponível. De-
pendendo da criticabilidade e alterações futuras
Atividade de ciclo de vida de sistema. Determina quais
esperadas, o processo de desenvolvimento (5.3)
atividades correntes de ciclo de vida de sistema são
deveria ser utilizado via processo de manutenção
relevantes e aplicáveis, tais como: início do projeto pelo
(5.5). Desempenho, documentação, direitos de pro-
adquirente; desenvolvimento pelo fornecedor e
priedade, de uso, de autoria, de garantia e de licença
manutenção. Alguns cenários:
e suporte futuro relacionado ao produto de software,
O adquirente está iniciando ou definindo os requisitos do deveriam ser avaliados
sistema. Estudos de viabilidade e prototipação de re-
d) Produto de software ou firmware embutido ou
quisitos e projeto podem ser conduzidos. Código do
integrado a um sistema. Desde que tal produto de
software para protótipos pode ser desenvolvido, o qual
software é uma parte de um sistema maior, as ativi-
pode ou não ser utilizado, mais tarde, no desenvolvimento
dades relacionadas ao sistema no processo de de-
dos produtos de software realizado sob contrato.
senvolvimento (5.3) deveriam ser consideradas e
Requisitos do sistema e requisitos preliminares do
determinado se serão executadas ou suportadas.
software podem ser desenvolvidos. Nestes casos, o pro-
Se o produto de software ou firmware não tende a
cesso de desenvolvimento (5.3) pode ser usado mais
ser modificado no futuro, necessidades de docu-
como um guia do que como requisito; o rigor na qualifi-
mentação extensa deveriam ser examinadas cui-
cação e avaliação pode não ser necessário; e revisões
dadosamente.
conjuntas e auditorias podem não ser necessárias.
e) Produto de software que é independente. Desde
O desenvolvedor está produzindo produtos de software
que tal produto de software não é parte de um sis-
sob contrato. Neste caso todos os requisitos do processo
tema, as atividades relacionadas ao sistema no
de desenvolvimento (5.3) deveriam ser considerados du-
processo de desenvolvimento (5.3) não necessitam
rante a adaptação.
ser consideradas. As necessidades de documen-
O mantenedor está modificando produtos de software. tação, especialmente para manutenção, deveriam
O processo de manutenção (5.5) está sob consideração. ser examinadas cuidadosamente.
Partes do processo de desenvolvimento (seção 5.3)
f) Produto de software que não será entregue. Já
podem ser usadas como miniprocessos.
que nenhum item está sendo adquirido, fornecido
Características do nível de sistema. Determina quais as ou desenvolvido, nenhuma provisão nesta Norma,
características do nível de sistema são relevantes e apli- com exceção da atividade 5.3.1.5 no processo de
cáveis, tais como: a quantidade de subsistemas e itens desenvolvimento (5.3), deveria ser considerada.
de configuração. Se o sistema tiver muitos subsistemas Entretanto, se o adquirente decide adquirir uma parte
ou itens de configuração, o processo de desenvolvimento deste produto de software para futura operação e
(5.3) deveria ser cuidadosamente adaptado para cada manutenção, então este produto de software deveria
subsistema e item de configuração. Todos os requisitos ser tratado como nos itens b) ou c), descritos ante-
de interface e de integração deveriam ser considerados. riormente.
Cópia não autorizada

NBR ISO/IEC 12207:1998 31

Outras considerações O desenvolvimento do produto de software pode envolver

riscos técnicos. Se a tecnologia de software utilizada não
Quanto maior a dependência do sistema em relação ao estiver amadurecida, ou se o produto de software a ser
prazo de entrega e à operação correta do produto de desenvolvido é complexo e sem precedentes, ou se o
software, maior controle gerencial deveria ser imposto produto de software contém requisitos críticos de proteção,
via testes, revisões, auditorias, verificação, validação e segurança ou outros, então, especificação, projeto, tes-
outros. Por outro lado, um controle gerencial excessivo tes e avaliações rigorosos podem ser necessários. Veri-
para um produto de software não-crítico ou de pequeno ficação e validação independentes podem ser impor-
porte pode não ser apropriado em termos de custo. tantes.

Outras entradas Modelos e métodos

Tempo

E
Normas de M
Requisitos processos
Cascata P
Legislação de ciclo de R
Segurança vida de E
software S
Proteção
Espiral A
Método

Credenciais Ambiente
(NBR 9001 ....)

Capacidade
organizacional

Aplicação
Manual da qualidade Adaptação
Avaliação
Teste
ETC

Procedimentos

O que Aquisição Fornecimento Desenvolvimento Operação Manutenção

Quem

Adquirente

Fornecedor
Contrato
Desenvolvedor
Plano de
qualidade Operadores
Plano de
projeto Manutenedores

Projeto
iniciado

Figura B.1 - Um exemplo de aplicação desta Norma

/ANEXO C
Cópia não autorizada

32 NBR ISO/IEC 12207:1998

Anexo C (informativo)
Orientações sobre processos e organizações

Para proporcionar um melhor entendimento, este anexo processo de desenvolvimento e um processo de manu-
apresenta uma discussão sobre os processos, as orga- tenção. Em cada processo são apresentadas suas ativi-
nizações e seus relacionamentos sob pontos de vista dades. O processo de desenvolvimento é empregado
relevantes. por engenheiros de desenvolvimento para produzir
produtos de software. O processo de manutenção é em-
C.1 Processos sob pontos de vista relevantes pregado pelos engenheiros de manutenção para mo-
dificar o software e mantê-lo atualizado.

Esta Norma contém os processos que são aplicáveis ao

A visão de operação tem um processo de ciclo de vida
longo do ciclo de vida de software. Entretanto, estes
(ver o quadro sombreado mais abaixo à direita, dentro
processos podem ser utilizados de diferentes formas, por
dos processos fundamentais de ciclo de vida): um
diferentes organizações e partes, com diferentes visões
processo de operação e suas respectivas atividades.
e objetivos. Esta seção apresenta os processos e seus
O processo de operação é empregado para operar o
relacionamentos sob pontos de vista relevantes.
software para seus usuários.

Ver 4.1.1 para sinopses dos processos.

A visão da gerência da qualidade tem cinco processos
de ciclo de vida (ver o quadro sombreado dentro dos
A figura C.1 representa os processos de ciclo de vida de processos de apoio de ciclo de vida): processo de garantia
software e seus relacionamentos sob diferentes visões da qualidade; processo de verificação; processo de vali-
de utilização desta Norma. As visões básicas mostradas dação; processo de revisão conjunta; e processo de au-
são: contrato, gerência, operação, engenharia e apoio. ditoria. Suas atividades constituintes não são mostradas.
Sob a visão de contrato, as partes adquirente e fornecedor Esses processos relacionados à qualidade são empre-
negociam e celebram um contrato, empregando respecti- gados para gerenciar qualidade ao longo do ciclo de
vamente o processo de aquisição e o processo de forneci- vida de software. Os processos de verificação, validação,
mento. Sob a visão de gerência, o adquirente, fornecedor, revisão conjunta e auditoria podem ser empregados se-
desenvolvedor, operador, mantenedor ou outra parte, paradamente por diferentes partes e também como
gerencia seu respectivo processo. Sob a visão de opera- técnicas do processo de garantia da qualidade.
ção, o operador provê serviço de operação de software
para os usuários. Sob a visão de engenharia, o desen-
A visão de gerência tem um processo (ver quadro som-
volvedor ou mantenedor conduz suas respectivas tarefas
breado dentro dos processos organizacionais de ciclo
de engenharia para produzir ou modificar produtos de
de vida): um processo de gerência que é utilizado por
software. Sob a visão de apoio, as partes (tais como ge-
qualquer organização para gerenciar seu respectivo pro-
rência de configuração, garantia da qualidade) provêem
cesso. Suas atividades constituintes são apresentadas.
serviços de apoio a outros, atendendo às tarefas espe-
cíficas. Também são mostrados os processos organi-
zacionais (veja o quadro em segundo plano); que são C.2 Processos, organizações e relacionamentos
empregados por uma organização em nível corporativo
para estabelecer, implementar e continuamente melhorar Os processos e organizações (ou partes) se relacionam
uma estrutura subjacente constituída de processo(s) de apenas funcionalmente. Eles não impõem uma estrutura
ciclo de vida e pessoal associado. para uma organização (ou uma parte).

A figura C.2 apresenta os processos de ciclo de vida Nesta Norma, os termos “organização” e “parte” são
fundamentais (no alto, quadro esquerdo), de apoio (no quase sinônimos. Uma organização é um grupo de pes-
alto, quadro direito) e organizacionais (quadro de baixo) soas organizado para um propósito específico, como um
e os nomes de suas atividades constituintes sob diferentes clube, sindicato, corporação ou sociedade. Quando uma
visões. Um numeral, prefixado a um processo, refere-se organização, como um todo ou uma parte, celebra um
ao número da seção nesta Norma. contrato, ela é uma “parte”. Organizações são entidades
separadas, mas as “partes” podem ser da mesma orga-
A visão de contrato tem dois processos de ciclo de vida nização ou de organizações distintas.
(ver quadro sombreado no alto, dentro dos processos
fundamentais de ciclo de vida): um processo de aquisição Uma organização ou uma parte é denominada pelo pro-
para o adquirente e um processo de fornecimento para o cesso que executa. Por exemplo, é chamada de adqui-
fornecedor. Em cada processo são apresentadas suas rente quando executa o processo de aquisição.
atividades. Esses processos definem as tarefas para o
adquirente e para o fornecedor, respectivamente, do ponto Uma organização pode executar um ou mais processos;
de vista contratual. um processo pode ser executado por uma ou mais orga-
nizações. Sob um contrato ou aplicação desta Norma,
A visão da engenharia tem dois processos de ciclo de uma determinada parte não deveria executar ambos os
vida (ver o quadro sombreado mais abaixo à esquerda, processos de aquisição e de fornecimento, mas pode
dentro dos processos fundamentais de ciclo de vida): um executar outros processos.
Cópia não autorizada

NBR ISO/IEC 12207:1998 33

Nesta Norma, os relacionamentos entre os processos O processo de desenvolvimento (e o desenvolvedor) con-

são estáticos. É importante ressaltar que os relaciona- tribui examinando o sistema para uma correta definição do
mentos dinâmicos e efetivos entre os processos, entre as produto de software, pelo desenvolvimento do produto de
partes e entre os processos e as partes são estabelecidos software e pelo apoio à integração apropriada do produto
automaticamente quando a Norma é aplicada nos projetos de software ao sistema. O processo de operação (e o ope-
de software. Cada processo (e a parte que o executa) rador) contribui operando o produto de software no am-
contribui para o projeto de software de sua maneira pró- biente do sistema em benefício dos usuários, do negócio,
pria e única. O processo de aquisição (e o adquirente) e do objetivo do sistema. O processo de manutenção (e o
contribui definindo o sistema, o qual conteria o produto mantenedor) contribui mantendo e sustentando o produto
de software. O processo de fornecimento (e o fornecedor) de software para adequação operacional e fornecendo
contribui provendo o produto de software ou serviço do apoio e orientação aos usuários. Cada processo de apoio
qual aquele sistema dependeria. ou organizacional contribui fornecendo funções especiali-
zadas para outros processos, quando necessário.

Visão de
contrato
emprega Processo de Processo de . Adquirente
aquisição fornecimento .Fornecedor

emprega
Visão de
gerência
emprega

Processo de gerência Gerente

emprega emprega emprega

Visão de
operação
emprega
Processo de operação Operador/
usuário

emprega
Visão de
engenharia
emprega
Processo de Processo de . Desenvolvedor
manutenção desenvolvimento . Mantenedor

Visão de
Encarregado
apoio
dos
processos
Processos de apoio
de
Documentação Verificação
suporte
Gerência de configuração Validação
Resolução de problema Revisão conjunta
Garantia da qualidade Auditoria

Processos organizacionais
. Infra-estrutura . Melhoria . Treinamento

Figura C.1 - Processos de ciclo de vida de software - Regras e relacionamentos

Cópia não autorizada

34 NBR ISO/IEC 12207:1998

5. Processos fundamentais de ciclo de vida 6. Processos de apoio

de ciclo de vida

Visão d e co ntrato
5.1 Processo de aquisição
6.1 Processo de
documentação
Iniciação Preparação de pedido Preparação e atualização Monitoração do Aceitação e
de proposta do contrato fornecedor conclusão

6.2 Processo de
5.2 Processo de fornecimento gerência de
configuração
Preparação Execução e Revisão e Entrega e
Iniciação Contrato Planejamento
de resposta controle avaliação conclusão

V isã
são de g erê
rênc
nci a da
da
quuaaliidaade

6.3 Processo de
Visão d e eng enh aria Visão d e o pe ração garantia da
qualidade
5.3 Processo de desenvolvimento 5.4 Processo de operação
6.4 Processo de
Implementação Teste
do processo
verificação
Implementação Apoio à operacional
Instalação
do processo aceitação
do software
do software
Operação Suporte ao
do sistema usuário
6.5 Processo de
Análise de Projeto da Teste de
validação
Integração
requisitos arquitetura qualificação
do sistema do sistema
do sistema do sistema
6.6 Processo de
5.5 Processo de manutenção
revisão
Análise de Projeto da Projeto Teste de Análise dos conjunta
Implementação
Integração problemas e
requisitos arquitetura detalhado qualificação do processo
do software da modificação
do software do software do software do software
6.7 Processo de
Implementação Revisão/ auditoria
aceitação da
da modificação
Codificação e manutenção
integração do 6.8 Processo de
software
Migração Descontinuação resolução de
do software problema

7. Processos organizacionais de ciclo de vida

7.1 Processo de gerência 7.2 Processo de infra-estrutura 7.4 Processo de treinamento

Iniciação e
definição do Planejamento
escopo 7.3 Processo de melhoria

Execução e Revisão e Estabelecimento do

Conclusão Avaliação do processo Melhoria do processo
controle avaliação processo

A ordem de posição das atividades não significa ordem temporal.

Os nomes das atividades no processo de desenvolvimento não são os nomes das fases de desenvolvimento.

Figura C.2 - Processos, visões e atividades de ciclo de vida de software

/ANEXO D
Cópia não autorizada

NBR ISO/IEC 12207:1998 35

Anexo D (informativo)
Bibliografia

NBR ISO/IEC 12119:1994, Tecnologia de informação -

Pacotes de software - Teste e requisitos de qualidade