NBR Iso 12207

Copyright 1998,
ABNTAssociao Brasileira
de Normas Tcnicas
Printed in Brazil/
Impresso no Brasil
Todos os direitos reservados
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
Endereo Telegrfico:
NORMATCNICA
ABNT-Associao
Brasileira de
Normas Tcnicas
Tecnologia de informao - Processos
de ciclo de vida de software
NBR ISO/IEC 12207
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
Vlida a partir de 30.11.1998
Palavras-chave: Processamento de dados. Equipamento de
processamento de dados. Computadores.
Software. Ciclo de vida. Informao
tecnolgica
35 pginas
OUT 1998
Sumrio
Prefcio
Introduo
1 Objetivo e campo de aplicao
2 Referncias normativas
3 Definies
4 Aplicao desta Norma
5 Processos fundamentais de ciclo de vida
5.1 Processo de aquisio
5.2 Processo de fornecimento
5.3 Processo de desenvolvimento
5.4 Processo de operao
5.5 Processo de manuteno
6 Processos de apoio de ciclo de vida
6.1 Processo de documentao
6.2 Processo de gerncia de configurao
6.3 Processo de garantia da qualidade
6.4 Processo de verificao
6.5 Processo de validao
6.6 Processo de reviso conjunta
6.7 Processo de auditoria
6.8 Processo de resoluo de problema
7 Processos organizacionais de ciclo de vida
7.1 Processo de gerncia
7.2 Processo de infra-estrutura
7.3 Processo de melhoria
7.4 Processo de treinamento
ANEXOS
A Processo de adaptao
B Orientao para a adaptao
C Orientaes sobre processos e organizaes
D Bibliografia
Prefcio
A ABNT - Associao Brasileira de Normas Tcnicas -
o Frum Nacional de Normalizao. As Normas Brasi-
leiras, cujo contedo de responsabilidade dos Comits
Brasileiros (CB) e dos Organismos de Normalizao
Setorial (ONS), so elaboradas por Comisses de Estudo
(CE), formadas por representantes dos setores envol-
vidos, delas fazendo parte: produtores, consumidores e
neutros (universidades, laboratrios e outros).
Os Projetos de Norma Brasileira, elaborados no mbito
dos CB e ONS, circulam para Votao Nacional entre os
associados da ABNT e demais interessados.
A NBR ISO/IEC 12207 foi preparada pela CE-21:101.03 -
Processos de Ciclo de Vida de Software, do CB-21 - Co-
mit Brasileiro de Processamento de Dados.
Esta Norma contm o anexo A, que normativo, e os
anexos B e C, que so apenas informativos.
Introduo
Software uma parte fundamental da tecnologia de in-
formao e de sistemas convencionais, tais como siste-
mas de transporte, militares, da rea mdica e financeiros.
Tem havido uma proliferao de normas, procedimentos,
mtodos, ferramentas e ambientes de desenvolvimento
e de gerncia de software. Esta proliferao tem criado
Cpia no autorizada
2 NBR ISO/IEC 12207:1998
dificuldades na gerncia e engenharia de software,
principalmente na integrao de produtos e servios.
A disciplina de software necessita migrar desta proli-
ferao para uma estrutura comum que possa ser usada
por profissionais de software para falar a mesma lngua
na criao e gerncia de software. Esta Norma prov tal
estrutura comum.
A estrutura cobre o ciclo de vida de software desde a
concepo de idias at a descontinuao do software,
e consiste nos processos de aquisio e fornecimento
de produtos e servios de software. Adicionalmente, a
estrutura prov o controle e a melhoria destes processos.
Os processos desta Norma formam um conjunto abran-
gente. Uma organizao, dependendo de seu objetivo,
pode selecionar um subconjunto apropriado para
satisfaz-lo. Esta Norma , portanto, projetada para ser
adaptada para uma organizao, projeto ou aplicao
especficos. Tambm projetada para ser utilizada
quando o software uma entidade independente ou
embutida ou integrada a um sistema.
1 Objetivo e campo de aplicao
1.1 Objetivo
Esta Norma estabelece uma estrutura comum para os
processos de ciclo de vida de software, com terminologia
bem definida, que pode ser referenciada pela indstria
de software. A estrutura contm processos, atividades e
tarefas que servem para ser aplicadas durante a aquisio
de um sistema que contm software, de um produto de
software independente ou de um servio de software, e
durante o fornecimento, desenvolvimento, operao e
manuteno de produtos de software. O termo software
inclui a parte de software de firmware.
Esta Norma tambm prov um processo que pode ser
utilizado para definir, controlar e melhorar os processos
de ciclo de vida de software.
1.2 Campo de aplicao
Esta Norma aplica-se aquisio de sistemas, produtos
e servios de software, para o fornecimento, o desenvolvi-
mento, a operao e a manuteno de produtos de soft-
ware, e para a parte de software de firmware, quer sejam
executados interna ou externamente a uma organizao.
Alguns aspectos necessrios de definio de sistemas,
para prover o contexto a produtos e servios de software,
esto includos.
NOTA - Os processos utilizados durante o ciclo de vida de
software necessitam ser compatveis com os processos
utilizados durante o ciclo de vida de sistema.
Esta Norma destinada para ser utilizada em uma relao
entre duas partes e pode ser igualmente aplicada quando
as duas partes forem da mesma organizao. A relao
pode ser desde um acordo informal at um contrato le-
gal. Esta Norma pode ser utilizada por uma nica parte
por meio de tarefas impostas a ela mesma.
Esta Norma no foi concebida para produtos de software
de prateleira, a menos que eles estejam incorporados
dentro de um produto encomendado.
Esta Norma foi escrita para adquirentes de sistemas e
produtos e servios de software, e para fornecedores,
desenvolvedores, operadores, mantenedores, gerentes,
gerentes de garantia da qualidade e usurios dos pro-
dutos de software.
1.3 Adaptao desta Norma
Esta Norma contm um conjunto de processos, atividades
e tarefas projetado para ser adaptado de acordo com
cada projeto de software. O processo de adaptao
consiste na supresso de processos, atividades e tarefas
no aplicveis.
NOTA - Processos, atividades e tarefas, especficos ou es-
peciais, podem ser adicionados ao contrato.
1.4 Conformidade
A conformidade a esta Norma definida como a execuo
de todos os processos, atividades e tarefas, selecionados
desta Norma no processo de adaptao (anexo A), para
o projeto de software. A execuo de um processo ou
uma atividade concluda quando todas as suas tarefas
requeridas so executadas de acordo com os critrios
preestabelecidos e com os requisitos especificados no
contrato, quando aplicvel.
Qualquer organizao (por exemplo, estatal ou privada)
que exija o cumprimento desta Norma como uma con-
dio de negcio, responsvel por especificar e dispo-
nibilizar o conjunto mnimo de processos, atividades e
tarefas requeridos, que constitui a conformidade dos for-
necedores a esta Norma.
1.5 Limitaes
Esta Norma descreve a arquitetura dos processos de ciclo
de vida de software, mas no especifica os detalhes de
como implementar ou executar as atividades e tarefas
includas nos processos.
Esta Norma no pretende prescrever o nome, formato ou
contedo explcito da documentao a ser produzida.
Esta Norma pode requerer o desenvolvimento de docu-
mentos de mesma categoria ou tipo; por exemplo, dife-
rentes planos. Esta Norma, contudo, no sugere que tais
documentos sejam desenvolvidos ou emitidos separa-
damente ou combinados de alguma forma. Estas decises
so deixadas para o usurio desta Norma.
Esta Norma no prescreve um modelo especfico de ciclo
de vida ou mtodo de desenvolvimento de software. As
partes envolvidas com esta Norma so responsveis pela
seleo de um modelo de ciclo de vida para o projeto de
software e pelo mapeamento dos processos, atividades
e tarefas desta Norma dentro deste modelo. As partes
envolvidas so tambm responsveis pela seleo e
aplicao dos mtodos de desenvolvimento de software
e pela execuo das atividades e tarefas adequadas ao
projeto de software.
Esta Norma no pretende entrar em conflito com quais-
quer polticas, normas ou procedimentos j existentes na
organizao. Entretanto, qualquer conflito necessita ser
resolvido e quaisquer condies e situaes de sobrepo-
sio precisam ser citadas por escrito como excees
para a aplicao desta Norma.
Cpia no autorizada
NBR ISO/IEC 12207:1998
3
Ao longo desta Norma, deve utilizado para expressar
uma obrigao entre duas ou mais partes; dever para
expressar uma declarao de objetivo ou inteno de
uma das partes; deveria para expressar uma reco-
mendao entre vrias possibilidades; e pode para in-
dicar uma ao permitida dentro dos limites desta Norma.
Nesta Norma, as listas definidas para as tarefas no pre-
tendem ser exaustivas, porm usadas como exemplos.
2 Referncias normativas
As normas relacionadas a seguir contm disposies que,
ao serem citadas neste texto, constituem prescries para
esta Norma. As edies indicadas estavam em vigor no
momento desta publicao. Como toda norma est sujeita
a reviso, recomenda-se queles que realizam acordos
com base nesta que verifiquem a convenincia de se
usarem as edies mais recentes das normas citadas a
seguir. A ABNT possui a informao das normas em vigor
em um dado momento.
ISO/AFNOR:1989 - Dictionary of computer science
ISO/IEC 2382-1:1993 - Information technology -
Vocabulary - Part 1: Fundamental terms
ISO/IEC 2382-20:1990 - Information technology -
Vocabulary - Part 20: System development
NBR ISO 8402:1994 - Gesto da qualidade e garantia
da qualidade - Terminologia
NBR ISO 9001:1994 - Sistema da qualidade - Modelo
para garantia da qualidade em projeto, desenvol-
vimento, produo, instalao e servios associados
ISO/IEC 9126:1991
1)
- Information technology -
Software product evaluation - Quality characteristics
and guidelines for their use.
3 Definies
Para os propsitos desta Norma as definies contidas
nas NBR ISO 8402, ISO/IEC 2382-1 e ISO/IEC 2382-20
aplicam-se em conjunto com as seguintes definies:
NOTA - Um produto pode ser entendido como uma parte de um
sistema, quando aplicvel.
3.1 adquirente: Uma organizao que adquire ou obtm
um sistema, produto de software ou servio de software
de um fornecedor.
NOTA - O adquirente poderia ser: comprador, cliente, proprietrio
ou usurio.
3.2 aquisio: Processo de obteno de um sistema,
produto de software ou servio de software.
3.3 acordo: Definio de termos e condies sob a qual
o relacionamento de trabalho entre as partes dever ser
conduzido.
3.4 auditoria: Processo conduzido por uma pessoa auto-
rizada, com o objetivo de prover um julgamento indepen-
dente de produtos e processos de software, a fim de ava-
liar a conformidade com seus requisitos.
3.5 linha bsica (baseline): Verso formalmente apro-
vada de um item de configurao, independente de mdia,
formalmente definida e fixada em um determinado mo-
mento durante o ciclo de vida do item de configurao.
3.6 item de configurao: Entidade dentro de uma con-
figurao que satisfaz uma funo de uso final e que
pode ser identificada de forma nica em um determinado
ponto de referncia.
3.7 contrato: Acordo realizado entre duas partes, respal-
dado pela lei, ou acordo interno similar restrito a uma or-
ganizao, para o fornecimento de servios de software
ou para o fornecimento, desenvolvimento, produ-
o, operao ou manuteno de um produto de
software.
3.8 desenvolvedor: Organizao que executa ati-
vidades de desenvolvimento (incluindo anlise de re-
quisitos, projeto, testes at aceitao) durante o processo
de ciclo de vida de software.
3.9 avaliao: Determinao sistemtica do grau de
atendimento de uma entidade em relao aos critrios
para ela estabelecidos.
3.10 firmware: Combinao de um dispositivo de
hardware e instrues ou dados de computador que
residem como um software somente para leitura no dispo-
sitivo de hardware. Este software no pode ser direta-
mente modificado por um programa.
3.11 modelo de ciclo de vida: Estrutura contendo pro-
cessos, atividades e tarefas envolvidas no desenvol-
vimento, operao e manuteno de um produto de
software, abrangendo a vida do sistema desde a definio
de seus requisitos at o trmino de seu uso.
3.12 mantenedor: Organizao que executa atividades
de manuteno.
3.13 monitorao: Exame da situao das atividades de
um fornecedor e dos seus resultados, efetuado pelo adqui-
rente ou uma terceira parte.
3.14 item que no ser entregue: Hardware ou produto
de software cuja entrega no exigida em contrato, mas
pode ser utilizado no desenvolvimento do produto de
software.
3.15 produto de prateleira: Produto j desenvolvido e
disponvel para utilizao na forma em que se encontra
ou com modificao.
3.16 operador: Organizao que opera o sistema.
3.17 processo: Conjunto de atividades inter-relaciona-
das, que transforma entradas em sadas.
NOTA - O termo atividades engloba a utilizao de recursos.
[Ver NBR ISO 8402:1994, 1.2]
1)
Para efeitpo de norma brasileira utilizar a NBR 13596:1996.
Cpia no autorizada
4 NBR ISO/IEC 12207:1998
3.18 qualificao: Processo de demonstrar se uma
entidade capaz de atender os requisitos especificados.
[Ver NBR ISO 8402:1994, 2.13]
3.19 requisito de qualificao: Conjunto de critrios ou
de condies que, quando atendido, qualifica um produto
de software quanto conformidade s suas especifi-
caes e quanto sua utilizao no seu ambiente-alvo.
3.20 teste de qualificao: Teste conduzido pelo desen-
volvedor e testemunhado pelo adquirente (quando apro-
priado), para demonstrar que o produto de software
atende as suas especificaes e est pronto para utili-
zao no seu ambiente-alvo.
3.21 garantia da qualidade: Conjunto de atividades pla-
nejadas e sistemticas, implementadas no sistema da
qualidade e demonstradas como necessrias, para pro-
ver confiana adequada de que uma entidade atender
os requisitos para a qualidade.
NOTAS
1 A garantia da qualidade visa, simultaneamente, aos objetivos
internos e externos:
a) Garantia da qualidade interna: dentro de uma orga-
nizao, a garantia da qualidade prov confiana admi-
nistrao;
b) Garantia da qualidade externa: em situaes contratuais
ou outras, a garantia da qualidade prov confiana aos
clientes ou a outros.
2 Algumas aes do controle da qualidade e da garantia da qua-
lidade so inter-relacionadas.
3 Se os requisitos para a qualidade no refletirem inteiramente
as necessidades do usurio, a garantia da qualidade pode no
prover a confiana adequada.
[NBR ISO 8402:1994, 3.5]
3.22 liberao (release): Verso particular de um item
de configurao que colocada disposio para um
propsito especfico (por exemplo, liberao para tes-
te).
3.23 pedido de proposta: Documento utilizado pelo adqui-
rente como meio para divulgar aos potenciais fornece-
dores sua inteno de adquirir um sistema, produto de
software ou servio de software especificado.
3.24 descontinuao: Cancelamento do suporte ativo
pela organizao de operao e manuteno, substi-
tuio total ou parcial por um novo sistema, ou instalao
de um sistema atualizado.
3.25 segurana: Proteo de informaes e dados de
modo que pessoas ou sistemas no autorizados no
possam l-los ou modific-los e que pessoas ou sistemas
autorizados no tenham acesso negado a eles.
3.26 produto de software: Conjunto de programas de
computador, procedimentos e possvel documentao e
dados associados.
3.27 servio de software: Execuo de atividades,
trabalho ou obrigaes relacionados ao produto de
software, tais como seu desenvolvimento, manuteno e
operao.
3.28 unidade de software: Parte de cdigo compilvel
separadamente.
3.29 descrio de tarefas: Documento utilizado pelo
adquirente como um meio para descrever e especificar
as tarefas a serem executadas conforme o contrato.
3.30 fornecedor: Organizao que firma um contrato com
o adquirente para fornecimento de um sistema, produto
de software ou servio de software conforme os termos
do contrato.
NOTAS
1 O termo fornecedor sinnimo de contratado, produtor,
vendedor ou distribuidor.
2 O adquirente pode designar uma parte de sua organizao
como fornecedor.
3.31 sistema: Conjunto integrado que consiste em um
ou mais processos, hardware, software, recursos e
pessoas, capaz de satisfazer uma necessidade ou
objetivo definido.
3.32 cobertura de teste: Extenso em que os casos de
teste dos requisitos de um sistema ou produto de
software so testados.
3.33 testabilidade: Extenso em que um teste objetivo
e factvel pode ser projetado para determinar se um requi-
sito atendido.
3.34 usurio: Indivduo ou organizao que utiliza um
sistema em operao para executar uma funo espe-
cfica.
NOTA - O usurio pode executar outros papis, tais como
adquirente, desenvolvedor ou mantenedor.
3.35 validao: Confirmao, por exame e fornecimento
de evidncia objetiva, de que os requisitos especficos,
para um determinado uso pretendido, so atendidos.
NOTAS
1 Nas atividades de projeto e desenvolvimento, a validao se
refere ao processo de examinar um produto para determinar
sua conformidade com as necessidades do usurio.
2 A validao feita normalmente no produto final sob condies
de operao definidas, podendo, contudo, tornar-se necessria
em fases anteriores.
3 O termo validado usado para designar o estado aps a va-
lidao.
4 Validaes mltiplas podem ser realizadas se existirem dife-
rentes usos pretendidos.
[NBR ISO 8402:1994, 2.18]
Cpia no autorizada
5
3.36 verificao: Confirmao, por exame e fornecimento
de evidncia objetiva, do atendimento aos requisitos es-
pecificados.
NOTAS
1 Nas atividades de projeto e desenvolvimento, a verificao
refere-se ao processo de examinar o resultado de dada atividade
para determinar sua conformidade com os requisitos estabe-
lecidos para a mesma atividade.
2 O termo verificado usado para designar o estado aps a
verificao.
[NBR ISO 8402:1994, 2.17]
3.37 verso: Instncia identificada de um item.
NOTA - Modificaes em uma verso de produto de software,
resultando em uma nova verso, requerem uma ao de gerncia
de configurao.
4 Aplicao desta Norma
Esta seo apresenta os processos de ciclo de vida de
software que podem ser empregados para adquirir,
fornecer, desenvolver, operar e manter produtos de
software. O objetivo prover um guia para os usurios
desta Norma para que eles possam orientar-se na mesma
e aplic-la criteriosamente.
4.1 Organizao desta Norma
4.1.1 Processos de ciclo de vida
Esta Norma agrupa as atividades que podem ser execu-
tadas durante o ciclo de vida de software em cinco pro-
cessos fundamentais, oito processos de apoio e quatro
processos organizacionais. Cada processo de ciclo de
vida dividido em um conjunto de atividades; cada
atividade ento dividida em um conjunto de tarefas.
Uma seo numerada por a.b denota um processo, a.b.c
uma atividade e a.b.c.d uma tarefa. Estes processos de
ciclo de vida so introduzidos a seguir e ilustrados na
figura 1.
4.1.1.1 Processos fundamentais de ciclo de vida
Os processos fundamentais de ciclo de vida (seo 5)
constituem um conjunto de cinco processos que atendem
as partes fundamentais (pessoa ou organizao) durante
o ciclo de vida de software. Uma parte fundamental
aquela que inicia ou executa o desenvolvimento, ope-
rao ou manuteno dos produtos de software. Estas
partes fundamentais so o adquirente, o fornecedor, o
desenvolvedor, o operador e o mantenedor do software.
Os processos fundamentais so:
1) Processo de aquisio (subseo 5.1). Define as ati-
vidades do adquirente, organizao que adquire um sis-
tema, produto de software ou servio de software.
2) Processo de fornecimento (subseo 5.2). Define as
atividades do fornecedor, organizao que prov o sis-
tema, produto de software ou servio de software ao
adquirente.
3) Processo de desenvolvimento (subseo 5.3). Define
as atividades do desenvolvedor, organizao que define
e desenvolve o produto de software.
4) Processo de operao (subseo 5.4). Define as ativi-
dades do operador, organizao que prov servio de
operao de um sistema computacional, no seu ambiente
de funcionamento, para seus usurios.
5) Processo de manuteno (subseo 5.5). Define as
atividades do mantenedor, organizao que prov o ser-
vio de manuteno do produto de software, isto , geren-
ciando as modificaes no produto de software para man-
t-lo atualizado e em perfeita operao. Este processo
inclui a migrao e a descontinuao do produto de
software.
4.1.1.2 Processos de apoio de ciclo de vida
Os processos de apoio de ciclo de vida (seo 6) cons-
tituem um conjunto de oito processos. Um processo de
apoio auxilia um outro processo como uma parte inte-
grante, com um propsito distinto, e contribui para o
sucesso e qualidade do projeto de software. Um processo
de apoio empregado e executado, quando necessrio,
por outro processo. Os processos de apoio so:
1) Processo de documentao (subseo 6.1). Define as
atividades para registro da informao produzida por um
processo de ciclo de vida.
2) Processo de gerncia de configurao (subseo 6.2).
Define as atividades de gerncia de configurao.
3) Processo de garantia da qualidade (subseo 6.3).
Define as atividades para garantir objetivamente que os
produtos e processos de software esto em conformidade
com seus requisitos especificados e aderem aos seus
planos estabelecidos. Revises conjuntas, auditorias,
verificao e validao podem ser utilizadas como
tcnicas para garantia da qualidade.
4) Processo de verificao (subseo 6.4). Define as
atividades (para o adquirente, o fornecedor, ou uma parte
independente) para verificao dos produtos de software,
em profundidade varivel, dependendo do projeto de
software.
5) Processo de validao (subseo 6.5). Define as
atividades (para o adquirente, o fornecedor ou uma parte
independente) para validao dos produtos de software
do projeto de software.
6) Processo de reviso conjunta (subseo 6.6). Define
as atividades para avaliao da situao e produtos de
uma atividade. Este processo pode ser empregado por
qualquer uma das duas partes, onde uma delas (parte
revisora) revisa a outra parte (parte revisada) em um frum
conjunto.
7) Processo de auditoria (subseo 6.7). Define as ati-
vidades para determinar a conformidade com requisitos,
planos e contrato. Este processo pode ser empregado
por qualquer uma das duas partes, onde uma delas (parte
auditora) audita os produtos de software ou atividades
da outra parte (parte auditada).
8) Processo de resoluo de problema (subseo 6.8).
Define um processo para anlise e remoo dos
problemas (incluindo no-conformidades), independente
da sua natureza ou origem, que forem descobertos du-
rante a execuo dos processos de desenvolvimento, de
operao, de manuteno ou de outros processos.
Cpia no autorizada
6 NBR ISO/IEC 12207:1998
Figura 1 - Estrutura desta Norma
4.1.1.3 Processos organizacionais de ciclo de vida
Os processos organizacionais de ciclo de vida (seo 7)
constituem um conjunto de quatro processos. Eles so
empregados por uma organizao para estabelecer e
implementar uma estrutura subjacente, constituda de pro-
cessos de ciclo de vida e pessoal associados, e melhorar
continuamente a estrutura e os processos. Eles so tipica-
mente empregados fora do domnio de projetos e con-
tratos especficos; entretanto, ensinamentos destes pro-
jetos e contratos contribuem para a melhoria da orga-
nizao. Os processos organizacionais so:
1) Processo de gerncia (subseo 7.1). Define as
atividades bsicas da gerncia, incluindo gerncia de
projeto, durante um processo de ciclo de vida.
2) Processo de infra-estrutura (subseo 7.2). Define as
atividades bsicas para o estabelecimento da estrutura
de apoio de um processo de ciclo de vida.
3) Processo de melhoria (subseo 7.3). Define as ativi-
dades bsicas que uma organizao (isto , adquirente,
fornecedor, desenvolvedor, operador, mantenedor, ou o
gerente de outro processo) executa para estabe-
lecer, medir, controlar e melhorar seu processo de ciclo
de vida.
4) Processo de treinamento (subseo 7.4). Define as
atividades para prover pessoal adequadamente treinado.
4.1.2 Processo de adaptao
O anexo A define as atividades bsicas necessrias para
executar as adaptaes desta Norma. O anexo B contm
orientao para a adaptao dos requisitos desta Norma;
ele relaciona os fatores-chave sobre os quais as decises
de adaptao podem ser feitas.
5. Processos fundamentais de ciclo de vida 6. Processos de apoio de ciclo de vida
5.1 Aquisio 6.1 Documentao
5.2 Fornecimento 6.2 Gerncia de configurao
6.3 Garantia de qualidade
6.4 Verificao
6.5 Validao
6.6 Reviso conjunta
6.7 Auditoria
6.8 Resoluo de problema
7. Processos organizacionais de ciclo de vida
7.1 Gerncia 7.2 Infra-estrutura
7.3 Melhoria 7.4 Treinamento
5.4 Operao
5.5 Manuteno
5.3 Desenvolvimento
Cpia no autorizada
7
4.1.3 Relacionamento entre os processos e as organizaes
Esta Norma contm vrios processos que so aplicados
ao longo de ciclo de vida de software por vrias organi-
zaes, dependendo de suas necessidades e objetivos.
Para melhor esclarecimento, o anexo C apresenta os re-
lacionamentos entre os processos de ciclo de vida e as
partes envolvidas.
5 Processos fundamentais de ciclo de vida
Este captulo define os seguintes processos fundamentais
de ciclo de vida:
1) Processo de aquisio;
2) Processo de fornecimento;
3) Processo de desenvolvimento;
4) Processo de operao;
5) Processo de manuteno.
As atividades e as tarefas em um processo fundamental
so de responsabilidade da organizao que inicia e
executa este processo. Esta organizao assegura a exis-
tncia e a funcionalidade do processo.
O processo de aquisio contm as atividades e tarefas
do adquirente. Inicia-se com a definio da necessidade
de adquirir um sistema, um produto de software ou um
servio de software. O processo continua com a prepa-
rao e emisso de pedido de proposta, seleo de for-
necedor e gerncia do processo de aquisio atravs da
aceitao do sistema, produto de software ou servio de
software.
A organizao individual, que tem a necessidade, pode
ser chamada de proprietria. O proprietrio pode contratar
algumas ou todas as atividades de aquisio junto a um
agente que, por sua vez, conduzir estas atividades de
acordo com o processo de aquisio. O adquirente nesta
subseo pode ser tanto o proprietrio quanto o agente
contratado por ele.
O adquirente gerencia o processo de aquisio em nvel
de projeto, seguindo o processo de gerncia (7.1), o qual
passa a existir nesse processo; estabelece uma infra-
estrutura sob o projeto, seguindo o processo de infra-
estrutura (7.2); adapta o processo para o projeto, se-
guindo o processo de adaptao (anexo A); e gerencia o
processo em nvel organizacional, seguindo o processo
de melhoria (7.3) e o processo de treinamento (7.4).
Lista de atividades - Este processo consiste nas seguintes
atividades:
1) Iniciao;
2) Preparao de pedido de proposta;
3) Preparao e atualizao do contrato;
4) Monitorao do fornecedor;
5) Aceitao e concluso.
5.1.1 Iniciao - Esta atividade consiste nas seguintes
tarefas:
5.1.1.1 O adquirente inicia o processo de aquisio pela
descrio de um conceito ou de uma necessidade em
adquirir, desenvolver ou melhorar um sistema, produto
de software ou servio de software.
5.1.1.2 O adquirente dever definir e analisar os requisitos
do sistema. Estes requisitos devem incluir requisitos de
negcio, organizacionais e de usurio, bem como de se-
gurana, proteo e outros requisitos crticos relacionados
s atividades de projeto, testes e aderncia a padres e
procedimentos.
5.1.1.3 Se o adquirente mantiver acordo com um for-
necedor para a execuo da anlise dos requisitos de
um sistema, o adquirente dever aprovar estes requisitos.
5.1.1.4 O adquirente pode executar a definio e a anlise
dos requisitos do software por conta prpria ou pode
manter acordo com um fornecedor para executar essa
tarefa.
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.1.6 O adquirente dever considerar opes para
aquisio atravs de uma anlise, com critrios
apropriados, incluindo risco, custo e benefcios para cada
opo. As opes incluem:
a) Comprar um produto de software de prateleira
que satisfaa os requisitos;
b) Internamente desenvolver o produto de software
ou obter o servio de software;
c) Atravs de contrato, desenvolver o produto de
software ou obter o servio de software;
d) Uma combinao dos itens a, b e c acima;
e) Melhorar um produto ou servio de software exis-
tente.
5.1.1.7 Para a aquisio de um produto de software de
prateleira, o adquirente dever assegurar que as se-
guintes condies sejam satisfeitas:
a) Os requisitos do produto de software sejam satis-
feitos;
b) A documentao esteja disponvel;
c) Os direitos de propriedade, de uso, de autoria,
de garantia e de licena sejam satisfeitos;
d) O suporte futuro para o produto de software esteja
planejado.
Cpia no autorizada
8 NBR ISO/IEC 12207:1998
5.1.1.8 O adquirente deveria preparar, documentar e
executar um plano de aquisio. O plano deveria conter
o seguinte:
a) Requisitos para o sistema;
b) Emprego planejado para o sistema;
c) Tipo de contrato a ser empregado;
d) Responsabilidades das organizaes envolvidas;
e) Conceito de suporte a ser usado;
f) Riscos considerados, assim como mtodos para
gerenci-los.
5.1.1.9 O adquirente deveria definir e documentar a
estratgia e condies (critrios) de aceitao.
5.1.2 Preparao de pedido de proposta. Esta atividade
consiste nas seguintes tarefas:
5.1.2.1 O adquirente deveria documentar os requisitos de
aquisio (exemplo: pedido de proposta) cujo contedo
depende da opo de aquisio selecionada em 5.1.1.6.
A documentao de aquisio deveria incluir, quando
apropriado:
a) Requisitos do sistema;
b) Declarao do escopo;
c) Instrues para os proponentes;
d) Lista de produtos de software;
e) Termos e condies;
f) Controle dos subcontratos;
g) Restries tcnicas (exemplo: ambiente-alvo).
5.1.2.2 O adquirente deveria determinar quais processos,
atividades e tarefas desta Norma so apropriados para o
projeto e deveria adapt-los, quando necessrio. Espe-
cialmente, o adquirente deveria especificar os processos
de apoio aplicveis (seo 6) e suas organizaes exe-
cutoras, incluindo responsabilidades (se outras alm do
fornecedor), para que os fornecedores possam, em suas
propostas, definir como abordar cada um dos processos
de apoio especificados. O adquirente dever definir o
escopo daquelas tarefas que referenciam o contrato.
5.1.2.3 A documentao de aquisio tambm dever
definir no contrato os pontos de controle nos quais o
progresso do fornecimento dever ser revisado e audi-
tado como parte da monitorao da aquisio (ver 6.6 e
6.7).
5.1.2.4 Os requisitos de aquisio deveriam ser fornecidos
organizao selecionada para executar as atividades
de aquisio.
5.1.3 Preparao e atualizao do contrato. Esta atividade
5.1.3.1 O adquirente deveria estabelecer um procedi-
mento para selecionar o fornecedor, incluindo critrios
de avaliao de proposta e ponderao da aderncia
aos requisitos.
5.1.3.2 O adquirente deveria selecionar um fornecedor
baseado na avaliao das propostas dos fornecedores,
capacidades e outros fatores que precisam ser conside-
rados.
5.1.3.3 O adquirente pode envolver outras partes, incluindo
fornecedores potenciais, antes do fechamento do contrato,
durante a adaptao desta Norma ao projeto. Entretanto,
o adquirente dever tomar a deciso final sobre esta
adaptao. O adquirente dever incluir ou referenciar a
Norma adaptada no contrato.
5.1.3.4 O adquirente dever, ento, preparar e negociar
um contrato com o fornecedor que trate dos requisitos de
aquisio, incluindo o custo e cronograma do produto ou
servio de software a ser entregue. O contrato dever
tratar direitos de uso, de propriedade, de autoria, de
garantia e de licena, associados com os produtos de
software de prateleira reusveis.
5.1.3.5 Estando o contrato em andamento, o adquirente
dever controlar alteraes no contrato atravs de
negociao com o fornecedor, como parte do mecanismo
de controle de alterao. Alteraes no contrato devero
ser investigadas quanto ao impacto nos planos, custos,
benefcios, qualidade e cronograma do projeto.
NOTA - O adquirente determina se o termo contrato ou acordo
ser utilizado na aplicao desta Norma.
5.1.4 Monitorao do fornecedor. Esta atividade consiste
nas seguintes tarefas:
5.1.4.1 O adquirente dever monitorar as atividades do
fornecedor de acordo com o processo de reviso conjunta
(6.6) e com o processo de auditoria (6.7). O adquirente
deveria complementar a monitorao com o processo de
verificao (6.4) e com o processo de validao (6.5),
quando necessrio.
5.1.4.2 O adquirente dever cooperar com o fornecedor
para prover toda a informao necessria no momento
oportuno e resolver todos os itens pendentes.
5.1.5 Aceitao e concluso. Esta atividade consiste nas
seguintes tarefas:
5.1.5.1 O adquirente deveria preparar-se para aceitao
baseado na estratgia e nos critrios de aceitao de-
finidos. A preparao de casos de teste, dados de teste,
procedimentos de teste e ambiente de teste deveria estar
includa. A abrangncia do envolvimento do fornecedor
deveria ser definida.
5.1.5.2 O adquirente dever conduzir a reviso de
aceitao e teste de aceitao do produto ou servio de
software a ser entregue e dever aceit-lo do fornecedor
quando todas as condies de aceitao forem satisfeitas.
O procedimento de aceitao deveria obedecer ao
estabelecido em 5.1.1.9.
Cpia no autorizada
9
5.1.5.3 Aps a aceitao, o adquirente deveria assumir a
responsabilidade pela gerncia de configurao do
produto de software entregue (ver 6.2).
NOTA - O adquirente pode instalar o produto de software ou
executar o servio de software de acordo com as instrues
definidas pelo fornecedor.
O processo de fornecimento contm as atividades e as
tarefas do fornecedor. O processo pode ser iniciado tanto
por uma deciso de preparar uma proposta para res-
ponder a um pedido de proposta de um adquirente quanto
pela assinatura e celebrao de um contrato com o adqui-
rente para fornecer o sistema, produto de software ou
servio de software. O processo continua com a deter-
minao dos procedimentos e recursos necessrios para
gerenciar e garantir o projeto, incluindo o desenvolvimen-
to e a execuo dos planos de projeto at a entrega do
sistema, produto de software ou servio de software para
o adquirente.
O fornecedor gerencia o processo de fornecimento em
nvel de projeto, seguindo o processo de gerncia (7.1),
o qual passa a existir nesse processo; estabelece uma
infra-estrutura sob o processo, seguindo o processo de
infra-estrutura (7.2); adapta o processo para o projeto,
seguindo o processo de adaptao (anexo A); e gerencia
o processo em nvel organizacional, seguindo o processo
Lista de atividades. Este processo consiste nas seguintes
atividades:
1) Iniciao;
2) Preparao de resposta;
3) Contrato;
4) Planejamento;
5) Execuo e controle;
6) Reviso e avaliao;
7) Entrega e concluso.
5.2.1 Iniciao. Esta atividade consiste nas seguintes
tarefas:
5.2.1.1 O fornecedor conduz uma reviso dos requisitos
que constam no pedido de proposta, levando em consi-
derao polticas e outros regulamentos da organizao.
5.2.1.2 O fornecedor deveria decidir entre propor ou aceitar
o contrato.
5.2.2 Preparao de resposta. Esta atividade consiste na
seguinte tarefa:
5.2.2.1 O fornecedor deveria definir e preparar uma
proposta em resposta ao pedido de proposta, incluindo
sua recomendao da adaptao desta Norma.
5.2.3 Contrato. Esta atividade consiste nas seguintes
tarefas:
5.2.3.1 O fornecedor deve negociar e firmar o contrato
com a organizao adquirente para fornecer o produto
ou servio de software.
5.2.3.2 O fornecedor pode solicitar modificao no contrato
como parte do mecanismo de controle de alterao.
5.2.4 Planejamento. Esta atividade consiste nas seguin-
tes tarefas:
5.2.4.1 O fornecedor deve conduzir uma reviso dos requi-
sitos de aquisio, para definir a estrutura para gerenciar
e garantir o projeto e para garantir a qualidade do produto
ou servio de software a ser entregue.
5.2.4.2 Se no estiver estipulado no contrato, o fornecedor
deve definir ou selecionar um modelo de ciclo de vida de
software apropriado para o escopo, magnitude e
complexidade do projeto. Os processos, atividades e
tarefas desta Norma devem ser selecionados e mapeados
no modelo de ciclo de vida.
5.2.4.3 O fornecedor deve estabelecer requisitos para os
planos, para gerenciar e garantir o projeto e para garantir
a qualidade do produto ou servio de software a ser
entregue. Requisitos para os planos deveriam incluir
necessidades de recursos e o envolvimento do adqui-
rente.
5.2.4.4 Uma vez estabelecidos os requisitos de plane-
jamento, o fornecedor deve considerar as opes para o
desenvolvimento do produto de software ou proviso do
servio de software, a partir de uma anlise dos riscos
associados a cada uma das opes. As opes incluem:
a) Desenvolver o produto de software ou prover o
servio de software usando recursos internos;
b) Desenvolver o produto de software ou prover o
servio de software atravs de subcontratao;
c) Obter produtos de software de prateleira a partir
de fontes internas ou externas;
d) Uma combinao de a, b e c anteriores.
5.2.4.5 O fornecedor deve desenvolver e documentar o(s)
plano(s) de gerncia do projeto de acordo com os requi-
sitos de planejamento e as opes selecionadas em
5.2.4.4. Os itens a serem considerados no plano no se
limitam a, mas incluem o seguinte:
a) Estrutura organizacional do projeto, autoridade
e responsabilidade de cada unidade organizacional,
incluindo organizaes externas;
b) Ambiente de engenharia (para desenvolvimento,
operao ou manuteno, quando aplicvel),
incluindo ambiente de teste, biblioteca, equipamento,
instalaes, padres, procedimentos e ferramentas;
Cpia no autorizada
10 NBR ISO/IEC 12207:1998
c) Estrutura de diviso de trabalho dos processos e
atividades de ciclo de vida, incluindo os produtos de
software, servios de software e itens que no sero
entregues, a ser executada de acordo com os ora-
mentos, pessoal, recursos fsicos, tamanho do
software e cronogramas associados s tarefas;
d) Gerenciamento das caractersticas da qualidade
dos produtos ou servios de software. Planos para
qualidade podem ser desenvolvidos em separado;
e) Gerenciamento de proteo, segurana e outros
requisitos crticos dos produtos ou servios de
software. Planos para proteo e segurana podem
ser desenvolvidos em separado;
f) Gerenciamento do subcontratado, incluindo a sua
seleo e o seu envolvimento com o adquirente, se
houver;
g) Garantia da qualidade (ver 6.3);
h) Verificao (ver 6.4) e validao (ver 6.5) incluindo
a abordagem para a interao com o agente de ve-
rificao e validao, se especificado;
i) Envolvimento do adquirente, isto , atravs de
revises conjuntas (ver 6.6), auditorias (ver 6.7),
reunies informais, relatrios, modificao e alte-
rao; implementao, aprovao, aceitao e
acesso s instalaes;
j) Envolvimento do usurio, atravs de exerccios de
consolidao de requisitos, demonstraes de pro-
ttipos e avaliaes;
k) Gerenciamento de risco: gerenciamento das reas
do projeto que envolvem potenciais riscos tcnicos,
de custo e de cronograma;
l) Poltica de segurana: as regras para gesto e
acesso s informaes em cada nvel organizacional
do projeto;
m) Aprovao requerida atravs de regulamentos,
certificaes, direitos de propriedade, de uso, de
autoria, de garantia e de licena;
n) Meios para elaborar cronogramas, realizar acom-
panhamento e elaborar relatrios;
o) Treinamento de pessoal (ver 7.4).
5.2.5 Execuo e controle. Esta atividade consiste nas
seguintes tarefas:
5.2.5.1 O fornecedor deve implementar e executar o(s)
plano(s) de gerenciamento do projeto desenvolvido(s)
em 5.2.4.
5.2.5.2 O fornecedor deve:
a) Desenvolver o produto de software de acordo com
o processo de desenvolvimento (5.3);
b) Operar o produto de software de acordo com o
processo de operao (5.4);
c) Manter o produto de software de acordo com o
processo de manuteno (5.5).
5.2.5.3 O fornecedor deve monitorar e controlar o pro-
gresso e a qualidade dos produtos ou servios de
software do projeto atravs do ciclo de vida contratado.
Esta deve ser uma tarefa contnua e iterativa que deve
servir para:
a) Monitorao do progresso do desempenho tcnico,
de custos e de cronogramas, e o relato da situao
do projeto;
b) Identificao, registro, anlise e resoluo de pro-
blema.
5.2.5.4 O fornecedor deve gerenciar e controlar os subcon-
tratados de acordo com o processo de aquisio (5.1).
O fornecedor deve verificar todos os requisitos contratuais
necessrios, para assegurar que o produto ou servio de
software entregue ao adquirente foi desenvolvido ou
executado de acordo com os requisitos do contrato origi-
nal.
5.2.5.5 O fornecedor deve interagir com os agentes
independentes de verificao, validao ou testes, con-
forme especificado no contrato e nos planos do projeto.
5.2.5.6 O fornecedor deve interagir com outras partes,
conforme especificado no contrato e nos planos do pro-
jeto.
5.2.6 Reviso e avaliao. Esta atividade consiste nas se-
guintes tarefas:
5.2.6.1 O fornecedor deveria coordenar as atividades de
reviso do contrato, interaes e comunicao com a
organizao do adquirente.
5.2.6.2 O fornecedor deve conduzir ou dar suporte s
reunies informais, reviso de aceitao, teste de acei-
tao, revises conjuntas e auditorias com o adquirente
conforme especificado no contrato e planos do projeto.
As revises conjuntas devem ser conduzidas de acordo
com 6.6 e as auditorias de acordo com 6.7.
5.2.6.3 O fornecedor deve executar a verificao e a
validao, de acordo com 6.4 e 6.5, respectivamente,
para demonstrar que os produtos ou servios de
software e os processos satisfazem completamente os
seus respectivos requisitos.
5.2.6.4 O fornecedor deve disponibilizar ao adquirente
os relatrios de avaliao, revises, auditorias, testes e
resoluo de problemas, conforme especificado no con-
trato.
5.2.6.5 O fornecedor deve prover ao adquirente acesso
aos recursos do fornecedor e dos subcontratados, para a
reviso dos produtos ou servios de software, conforme
especificado no contrato e planos do projeto.
5.2.6.6 O fornecedor deve executar atividades de garantia
da qualidade, de acordo com 6.3.
Cpia no autorizada
11
5.2.7 Entrega e concluso. Esta atividade consiste nas
seguintes tarefas:
5.2.7.1 O fornecedor deve entregar o produto ou servio
de software, conforme especificado no contrato.
5.2.7.2 O fornecedor deve prover assistncia ao adquirente
no suporte do produto ou servio de software entregue,
conforme especificado no contrato.
O processo de desenvolvimento contm as atividades e
tarefas do desenvolvedor. O processo contm as ati-
vidades para anlise de requisitos, projeto, codificao,
integrao, testes, instalao e aceitao relacionada aos
produtos de software. Pode conter atividades relaciona-
das ao sistema, se estipulado no contrato. O desenvol-
vedor executa ou apia as atividades neste processo, de
acordo com o contrato.
O desenvolvedor gerencia o processo de desenvol-
vimento em nvel de projeto, seguindo o processo de ge-
rncia (7.1), o qual passa a existir nesse processo; esta-
belece uma infra-estrutura sob o processo, seguindo o
processo de infra-estrutura (7.2); adapta o processo para
o projeto, seguindo o processo de adaptao (anexo A);
e gerencia o processo em nvel organizacional, seguindo
o processo de melhoria (7.3) e o processo de treinamento
(7.4). Quando o desenvolvedor o fornecedor do produto
de software desenvolvido, o desenvolvedor executa o
processo de fornecimento (5.2).
atividades:
1) Implementao do processo;
2) Anlise dos requisitos do sistema;
3) Projeto da arquitetura do sistema;
4) Anlise dos requisitos do software;
5) Projeto da arquitetura do software;
6) Projeto detalhado do software;
7) Codificao e testes do software;
8) Integrao do software;
9) Teste de qualificao do software;
10) Integrao do sistema;
11) Teste de qualificao do sistema;
12) Instalao do software;
13) Apoio aceitao do software.
5.3.1 Implementao do processo. Esta atividade consiste
na seguinte tarefa:
5.3.1.1 Se no estipulado no contrato, o desenvolvedor
deve definir ou selecionar um modelo de ciclo de vida de
software apropriado ao escopo, magnitude e complexi-
dade do projeto. As atividades e tarefas do processo de
desenvolvimento devem ser selecionadas e mapeadas
no modelo de ciclo de vida.
NOTA - Estas atividades e tarefas podem se sobrepor ou interagir
e podem ser executadas iterativa ou recursivamente.
5.3.1.2 O desenvolvedor deve:
a) Documentar os resultados, de acordo com o pro-
cesso de documentao (6.1);
b) Colocar os resultados sob o processo de gerncia
de configurao (6.2) e executar controle de alte-
raes, de acordo com ele;
c) Documentar e resolver problemas e no-confor-
midades encontrados nos produtos de software e ta-
refas, de acordo com o processo de resoluo de
problema (6.8);
d) Executar os processos de apoio (seo 6), con-
forme especificado no contrato.
5.3.1.3 O desenvolvedor deve selecionar, adaptar e utilizar
estes padres, mtodos, ferramentas e linguagens de
programao de computador (se no estipulados no con-
trato) que sejam documentados, apropriados e esta-
belecidos pela organizao, para executar as atividades
do processo de desenvolvimento e dos processos de
apoio (seo 6).
5.3.1.4 O desenvolvedor deve desenvolver planos para
conduzir as atividades do processo de desenvolvimento.
Os planos deveriam incluir padres especficos, mtodos,
ferramentas, aes e responsabilidades associados com
o desenvolvimento e qualificao de todos os requisitos,
incluindo proteo e segurana. Se necessrio, planos
em separado podem ser elaborados. Estes planos devem
ser documentados e executados.
5.3.1.5 Itens que no sero entregues podem ser empre-
gados no desenvolvimento ou manuteno do produto
de software. Entretanto, deve ser assegurado que a ope-
rao e manuteno do produto de software a ser en-
tregue, depois de sua liberao ao adquirente, so inde-
pendentes daqueles itens; caso contrrio, estes itens
deveriam ser considerados como a ser entregues.
5.3.2 Anlise dos requisitos do sistema. Esta atividade
consiste nas seguintes tarefas, as quais o desenvolvedor
deve executar ou apoiar conforme especificado no
contrato:
5.3.2.1 O uso especfico pretendido do sistema a ser de-
senvolvido deve ser analisado para especificar os requi-
sitos do sistema. A especificao dos requisitos do sis-
tema deve descrever: funes e capacidades do sistema;
requisitos de negcio, organizacionais e de usurios; re-
quisitos de proteo, de segurana, de engenharia de
fatores humanos (ergonomia), de interface, de operaes
e de manuteno; restries de projeto e requisitos de
qualificao. A especificao dos requisitos do sistema
deve ser documentada.
5.3.2.2 Os requisitos do sistema devem ser avaliados,
considerando os critrios listados a seguir. Os resultados
das avaliaes devem ser documentados.
a) Rastreabilidade para as necessidades de aqui-
sio;
b) Consistncia com as necessidades de aquisio;
Cpia no autorizada
12 NBR ISO/IEC 12207:1998
c) Testabilidade;
d) Viabilidade do projeto da arquitetura do sistema;
e) Viabilidade da operao e manuteno.
5.3.3 Projeto da arquitetura do sistema. Esta atividade
contrato:
5.3.3.1 Uma arquitetura de alto nvel do sistema deve ser
estabelecida. A arquitetura deve identificar itens de
hardware, software e operaes manuais. Deve ser asse-
gurado que todos os requisitos do sistema sejam alocados
entre os itens. Itens de configurao de hardware, itens
de configurao de software e operaes manuais devem
ser subseqentemente identificados, a partir destes itens.
A arquitetura do sistema e os requisitos do sistema alo-
cados aos itens devem ser documentados.
5.3.3.2 A arquitetura do sistema e os requisitos para os
itens devem ser avaliados, considerando os critrios
listados a seguir. Os resultados das avaliaes devem
ser documentados.
a) Rastreabilidade para os requisitos do sistema;
b) Consistncia com os requisitos do sistema;
c) Adequao dos mtodos e padres de projeto
utilizados;
d) Viabilidade de os itens de software atenderem
seus requisitos alocados;
e) Viabilidade da operao e da manuteno.
5.3.4 Anlise dos requisitos do software. Esta atividade
deve ser realizada para cada item de software (ou item
de configurao de software, se identificado) e consiste
5.3.4.1 O desenvolvedor deve estabelecer e documentar
os requisitos do software, incluindo as especificaes
das caractersticas de qualidade descritas a seguir. Um
guia para especificar as caractersticas de qualidade pode
ser encontrado na ISO/IEC 9126
2)
- Information
technology - Software product evaluation - Quality
characteristics and guidelines for their use.
a) Especificaes funcionais e de capacidade,
incluindo desempenho, caractersticas fsicas e con-
di es do ambi ente sob o qual o i tem de
software ser executado;
b) Interfaces externas ao item de software;
c) Requisitos de qualificao;
d) Especificaes de proteo, incluindo aquelas
relacionadas aos mtodos de operao e manu-
teno, influncias do ambiente e danos pessoais;
e) Especificaes de segurana, incluindo aquelas
relacionadas com o comprometimento de informa-
es sigilosas;
f) Especificaes de engenharia de fatores humanos
(ergonomia), incluindo aquelas relacionadas com
operaes manuais, interaes entre homem-
mquina, restries a pessoal e reas que neces-
sitam de maior ateno humana, que so sensveis
a erros humanos e treinamento;
g) Definio de dados e requisitos de bases de
dados;
h) Requisitos de instalao e aceitao do produto
de software entregue no(s) local(ais) de operao e
manuteno;
i) Documentao do usurio;
j) Requisitos do usurio para execuo e operao;
k) Requisitos do usurio para manuteno.
5.3.4.2 O desenvolvedor deve avaliar os requisitos do
software considerando os critrios listados a seguir.
Os resultados das avaliaes devem ser documentados.
a) Rastreabilidade para os requisitos do sistema e
projeto do sistema;
b) Consistncia externa com os requisitos do sistema;
c) Consistncia interna;
d) Testabilidade;
e) Viabilidade do projeto do software;
f) Viabilidade da operao e manuteno.
5.3.4.3 O desenvolvedor deve conduzir reviso(es)
conjunta(s), de acordo com a seo 6.6. Sendo bem
sucedidas as concluses da(s) reviso(es), uma linha
bsica (baseline) para os requisitos do item de software
deve ser estabelecida.
5.3.5 Projeto da arquitetura do software. Esta atividade
5.3.5.1 O desenvolvedor deve transformar os requisitos
para o item de software em uma arquitetura que descreve
sua estrutura de alto nvel e identifica os componentes
de software. Deve ser garantido que todos os requisitos
do item de software sejam alocados aos seus com-
ponentes de software e, mais adiante, sejam refinados
para facilitar o projeto detalhado. A arquitetura do item
de software deve ser documentada.
5.3.5.2 O desenvolvedor deve desenvolver e documentar
um projeto de alto nvel para as interfaces externas ao
item de software e entre os componentes de software do
item de software.
2)
Utilizar a NBR 13596.
Cpia no autorizada
13
um projeto de alto nvel para a base de dados.
5.3.5.4 O desenvolvedor deveria desenvolver e do-
cumentar verses preliminares da documentao do
usurio.
5.3.5.5 O desenvolvedor deve definir e documentar os
requisitos preliminares de teste e o cronograma para a
integrao do software.
5.3.5.6 O desenvolvedor deve avaliar a arquitetura do item
de software e os projetos de interface e base de dados,
considerando os critrios listados a seguir. Os resultados
das avaliaes devem ser documentados.
a) Rastreabilidade para os requisitos do item de
software;
b) Consistncia externa com os requisitos do item
de software;
c) Consistncia interna entre os componentes de
software;
d) Adequao dos mtodos e padres de projeto
utilizados;
e) Viabilidade do projeto detalhado;
conjunta(s), de acordo com a seo 6.6.
5.3.6 Projeto detalhado do software. Esta atividade deve
ser realizada para cada item de software (ou item de
configurao de software, se identificado) e consiste nas
seguintes tarefas:
5.3.6.1 O desenvolvedor deve desenvolver um projeto
detalhado para cada componente de software do item de
software. Os componentes de software devem ser refi-
nados em nveis mais baixos, contendo unidades de
software que possam ser codificadas, compiladas e
testadas. Deve ser garantido que todos os requisitos do
software sejam alocados para unidades de software a
partir dos componentes de software. O projeto detalhado
deve ser documentado.
um projeto detalhado das interfaces externas ao item de
software, entre os componentes de software e entre as
unidades de software. O projeto detalhado das interfaces
deve permitir a codificao sem a necessidade de
informao adicional.
um projeto detalhado para a base de dados.
5.3.6.4 O desenvolvedor deve atualizar a documentao
do usurio, quando necessrio.
5.3.6.5 O desenvolvedor deve definir e documentar os
requisitos de teste e o cronograma para testar unidades
de software. Os requisitos de teste deveriam incluir tes-
tes de estresse da unidade de software, at o limite de
seus requisitos.
5.3.6.6 O desenvolvedor deve atualizar os requisitos de
teste e o cronograma para a integrao do software.
5.3.6.7 O desenvolvedor deve avaliar o projeto detalhado
do software e requisitos de teste, considerando os
critrios listados a seguir. Os resultados das avaliaes
devem ser documentados.
a) Rastreabilidade para os requisitos do item de
software;
b) Consistncia externa com o projeto da arquitetura;
c) Consistncia interna entre componentes e
unidades de software;
d) Adequao dos mtodos e padres de projeto
utilizados;
e) Viabilidade dos testes;
5.3.7 Codificao e testes do software. Esta atividade deve
ser realizada para cada item de software (ou item de
seguintes tarefas:
o seguinte:
a) Cada unidade de software e base de dados;
b) Procedimentos de teste e dados para testar cada
unidade de software e base de dados.
5.3.7.2 O desenvolvedor deve testar cada unidade de
software e base de dados, garantindo que sejam aten-
didos seus requisitos. Os resultados dos testes devem
ser documentados.
5.3.7.4 O desenvolvedor deve atualizar os requisitos de
teste e o cronograma, para integrao do software.
5.3.7.5 O desenvolvedor deve avaliar o cdigo do
software e os resultados dos testes, considerando os
a) Rastreabilidade para os requisitos e projeto do
item de software;
b) Consistncia externa com os requisitos e projeto
do item de software;
c) Consistncia interna entre os requisitos da uni-
dade;
d) Cobertura de teste das unidades;
e) Adequao dos mtodos e padres de codifica-
o utilizados;
f) Viabilidade da integrao e testes do software;
g) Viabilidade da operao e manuteno.
Cpia no autorizada
14 NBR ISO/IEC 12207:1998
5.3.8 Integrao do software. Esta atividade deve ser
realizada para cada item de software (ou item de
seguintes tarefas:
5.3.8.1 O desenvolvedor deve desenvolver um plano de
integrao para integrar as unidades de software e
componentes de software no item de software. O plano
deve incluir requisitos de teste, procedimentos, dados,
responsabilidades e cronograma. O plano deve ser docu-
mentado.
5.3.8.2 O desenvolvedor deve integrar as unidades e
componentes de software e testar essas agregaes
medida que forem sendo integradas, de acordo com o
plano de integrao. Deve ser garantido que cada
agregao atenda os requisitos do item de software e
que o item de software esteja integrado na concluso da
atividade de integrao. Os resultados da integrao e
dos testes devem ser documentados.
5.3.8.4 O desenvolvedor deve desenvolver e documentar,
para cada requisito de qualificao do item de software,
um conjunto de testes, casos de teste (entradas, sadas e
critrios de teste) e procedimentos de teste, para conduzir
o teste de qualificao do software. O desenvolvedor deve
garantir que o item de software integrado est pronto
para o teste de qualificao do software.
5.3.8.5 O desenvolvedor deve avaliar o plano de inte-
grao, projeto, cdigo, testes, resultados dos testes e a
documentao do usurio, considerando os critrios
listados a seguir. Os resultados das avaliaes devem
ser documentados.
a) Rastreabilidade para os requisitos do sistema;
b) Consistncia externa com os requisitos do sistema;
c) Consistncia interna;
d) Cobertura de teste dos requisitos do item de
software;
e) Adequao dos mtodos e padres de teste uti-
lizados;
f) Conformidade com os resultados esperados;
g) Viabilidade do teste de qualificao do software;
h) Viabilidade da operao e manuteno.
5.3.9 Teste de qualificao do software. Esta atividade
5.3.9.1 O desenvolvedor deve conduzir o teste de quali-
ficao de acordo com os requisitos de qualificao para
o item de software. Deve ser garantido que a imple-
mentao de cada requisito do software seja testada para
conformidade. Os resultados do teste de qualificao
5.3.9.3 O desenvolvedor deve avaliar o projeto, cdigo,
testes, resultados dos testes e a documentao do
usurio, considerando os critrios listados a seguir. Os
resultados das avaliaes devem ser documentados.
a) Cobertura de teste dos requisitos do item de
software;
b) Conformidade com os resultados esperados;
c) Viabilidade da integrao e testes do sistema, se
conduzidos;
d) Viabilidade da operao e manuteno.
5.3.9.4 O desenvolvedor deve apoiar auditorias, de acordo
com 6.7. Os resultados das auditorias devem ser docu-
mentados. Se ambos, hardware e software, esto sendo
desenvolvidos e integrados, as auditorias podem ser
adiadas at o teste de qualificao do sistema.
5.3.9.5 Uma vez bem sucedida a concluso das auditorias,
se conduzidas, o desenvolvedor deve:
a) Atualizar e preparar o produto de software a ser
entregue para a integrao do sistema, teste de
qualificao do sistema, instalao do software ou
apoio aceitao do software, quando aplicvel;
b) Estabelecer uma linha bsica (baseline) para o
projeto e cdigo do item de software.
NOTA - O teste de qualificao do software pode ser utilizado
no processo de verificao (6.4) ou no processo de validao
(6.5).
5.3.10 Integrao do sistema. Esta atividade consiste nas
seguintes tarefas, as quais o desenvolvedor deve
executar ou apoiar conforme especificado no contrato.
5.3.10.1 Os itens de configurao de software devem ser
integrados ao sistema com itens de configurao de
hardware, com operaes manuais e com outros
sistemas, quando necessrio. As agregaes devem ser
testadas, quando forem integradas, de acordo com seus
requisitos. A integrao e resultados dos testes devem
ser documentados.
5.3.10.2 Para cada requisito de qualificao do sistema,
um conjunto de testes, casos de teste (entradas, sadas e
critrios de teste) e procedimentos de teste para conduzir
o teste de qualificao do sistema deve ser desenvolvido
e documentado. O desenvolvedor deve garantir que o
sistema integrado est pronto para o teste de qualificao
do sistema.
5.3.10.3 O sistema integrado deve ser avaliado, conside-
rando os critrios listados a seguir. Os resultados das
avaliaes devem ser documentados.
a) Cobertura de teste dos requisitos do sistema;
b) Adequao dos mtodos e padres de teste
utilizados;
c) Conformidade com os resultados esperados;
Cpia no autorizada
15
d) Viabilidade do teste de qualificao do sistema;
e) Viabilidade da operao e manuteno.
5.3.11 Teste de qualificao do sistema. Esta atividade
contrato.
5.3.11.1 O teste de qualificao do sistema deve ser con-
duzido de acordo com os requisitos de qualificao es-
pecificados para o sistema. Deve ser garantido que a
implementao de cada requisito do sistema seja testada,
para conformidade, e que o sistema est pronto para ser
entregue. Os resultados do teste de qualificao devem
ser documentados.
5.3.11.2 O sistema deve ser avaliado considerando os
a) Cobertura de teste dos requisitos do sistema;
b) Conformidade com os resultados esperados;
c) Viabilidade da operao e manuteno.
5.3.11.3 O desenvolvedor deve apoiar auditorias, de
acordo com 6.7. Os resultados das auditorias devem ser
documentados.
NOTA - Esta tarefa no aplicvel para aqueles itens de
configurao de software cujas auditorias foram conduzidas
previamente.
5.3.11.4 Uma vez bem sucedida a concluso das audi-
torias, se conduzidas, o desenvolvedor deve:
a) Atualizar e preparar o produto de software a ser
entregue para a instalao do software e para o
apoio aceitao do software;
b) Estabelecer uma linha bsica (baseline) para o
projeto e cdigo de cada item de configurao de
software.
NOTA - O teste de qualificao do sistema pode ser utilizado no
processo de verificao (6.4) ou no processo de validao (6.5).
5.3.12 Instalao do software. Esta atividade consiste nas
seguintes tarefas:
5.3.12.1 O desenvolvedor deve desenvolver um plano
para instalar o produto de software no ambiente-alvo,
conforme designado no contrato. Os recursos e infor-
maes necessrios para instalar o produto de software
devem ser determinados e estar disponveis. Quando es-
pecificado no contrato, o desenvolvedor deve auxiliar o
adquirente com as atividades de preparao. Onde o
produto de software a ser instalado estiver substituindo
um sistema existente, o desenvolvedor deve apoiar
qualquer atividade em execuo paralela, conforme
especificado no contrato. O plano de instalao deve ser
documentado.
5.3.12.2 O desenvolvedor deve instalar o produto de
software de acordo com o plano de instalao. Deve ser
assegurado que o cdigo do software e as bases de
dados sejam iniciados, executados e finalizados, con-
forme especificado no contrato. Os eventos e resultados
da instalao devem ser documentados.
5.3.13 Apoio aceitao do software. Esta atividade
5.3.13.1 O desenvolvedor deve apoiar a reviso de
aceitao do adquirente e testes do produto de software.
A reviso de aceitao e testes deve considerar os
resultados de revises conjuntas (6.6), auditorias (6.7),
teste de qualificao do software e teste de qualificao
do sistema (se executado). Os resultados da reviso de
aceitao e teste devem ser documentados.
5.3.13.2 O desenvolvedor deve concluir e entregar o
produto de software, conforme especificado no contrato.
5.3.13.3 O desenvolvedor deve prover treinamento inicial
e contnuo e suporte ao adquirente, conforme especificado
no contrato.
O processo de operao contm as atividades e as tarefas
do operador. O processo cobre a operao do produto
de software e o suporte operacional aos usurios. Como
a operao do produto de software est integrada
operao do sistema, as atividades e tarefas deste
processo se referem ao sistema.
O operador gerencia o processo de operao em nvel
do projeto, seguindo o processo de gerncia (7.1), o qual
passa a existir nesse processo; estabelece uma infra-
estrutura sob o processo, seguindo o processo de infra-
estrutura (7.2); adapta o processo para o projeto, se-
guindo o processo de adaptao (anexo A); e gerencia o
processo em nvel organizacional, seguindo o processo
Quando o operador o fornecedor do servio de ope-
rao, o operador executa o processo de fornecimento
(5.2).
atividades:
2) Teste operacional;
3) Operao do sistema;
4) Suporte ao usurio.
5.4.1.1 O operador deve desenvolver um plano e um
conjunto de padres de operao para executar as
atividades e tarefas deste processo. O plano deve ser
documentado e executado.
Cpia no autorizada
16 NBR ISO/IEC 12207:1998
5.4.1.2 O operador deve estabelecer procedimentos para
receber, registrar, resolver e rastrear problemas, e prover
realimentao (feedback). Sempre que os problemas fo-
rem encontrados, eles devem ser registrados e includos
no processo de resoluo de problema (seo 6.8).
5.4.1.3 O operador deve estabelecer procedimentos para
testar o produto de software no seu ambiente de ope-
rao, para inserir os relatrios de problemas e pedidos
de modificao no processo de manuteno (5.5) e para
liberar o produto de software para uso operacional.
5.4.2 Teste operacional. Esta atividade consiste nas
seguintes tarefas:
5.4.2.1 Para cada liberao do produto de software, o
operador deve executar o teste operacional e, satis-
fazendo os critrios especificados, liberar o produto de
software para uso operacional.
5.4.2.2 O operador deve garantir que o cdigo de
software e as bases de dados sejam iniciados, executados
e finalizados, como descrito no plano.
5.4.3 Operao do sistema. Esta atividade consiste na
seguinte tarefa:
5.4.3.1 O sistema deve ser operado no ambiente para o
qual foi pretendido, de acordo com a documentao do
usurio.
5.4.4 Suporte ao usurio. Esta atividade consiste nas
seguintes tarefas:
5.4.4.1 O operador deve prover assistncia e consultoria
aos usurios quando solicitado. Estas solicitaes e aes
subseqentes devem ser registradas e monitoradas.
5.4.4.2 O operador deve encaminhar as solicitaes do
usurio, quando necessrio, para resoluo no processo
de manuteno (5.5). Estas solicitaes devem ser en-
caminhadas e as aes que foram planejadas e exe-
cutadas devem ser relatadas aos solicitantes. Todas as
resolues devem ser monitoradas at a concluso.
5.4.4.3 Se um problema relatado tiver uma soluo tem-
porria antes que uma soluo definitiva possa ser
liberada, deve ser dada, ao solicitante, a opo de us-
la. Correes definitivas, liberaes que incluem funes
ou caractersticas previamente omitidas e melhorias do
sistema devem ser aplicadas ao produto de software em
operao, utilizando o processo de manuteno (5.5).
O processo de manuteno contm as atividades e tarefas
do mantenedor. Este processo ativado quando o produto
de software submetido a modificaes no cdigo e na
documentao associada devido a um problema, ou
necessidade de melhoria ou adaptao. O objetivo mo-
dificar um produto de software existente, preservando a
sua integridade. Este processo inclui a migrao e a des-
continuao do produto de software. O processo termina
com a descontinuao do produto de software.
As atividades providas nesta seo so especficas para
o processo de manuteno. Entretanto, o processo pode
utilizar outros processos desta Norma. Se o processo de
desenvolvimento (seo 5.3) utilizado, o termo de-
senvolvedor interpretado como mantenedor.
O mantenedor gerencia o processo de manuteno em
nvel de projeto, seguindo o processo de gerncia (7.1),
o qual passa a existir nesse processo; estabelece uma
infra-estrutura sob o processo, seguindo o processo de
infra-estrutura (7.2); adapta o processo para o projeto
seguindo o processo de adaptao (anexo A); e gerencia
o processo em nvel organizacional seguindo o processo
Quando o mantenedor o fornecedor do servio de manu-
teno, o mantenedor executa o processo de forneci-
mento (5.2).
atividades:
2) Anlise do problema e da modificao;
3) Implementao da modificao;
4) Reviso/aceitao da manuteno;
5) Migrao;
6) Descontinuao do software.
5.5.1.1 O mantenedor deve desenvolver, documentar e
executar planos e procedimentos para a conduo das
atividades e tarefas do processo de manuteno.
5.5.1.2 O mantenedor deve estabelecer procedimentos
para receber, registrar e rastrear relatrios de problemas
e pedidos de modificao dos usurios, e prover reali-
mentao (feedback) para os usurios. Sempre que pro-
blemas forem encontrados, eles devem ser registrados e
includos no processo de resoluo de problema
(seo 6.8).
5.5.1.3 O mantenedor deve implementar (ou estabelecer
interface organizacional com) o processo de gerncia de
configurao (6.2), para gerenciar modificaes no
sistema existente.
5.5.2 Anlise do problema e da modificao. Esta atividade
5.5.2.1 O mantenedor deve analisar o relatrio de
problema ou pedido de modificao segundo o seu im-
pacto na organizao, no sistema existente e nos sistemas
com os quais interage, com relao ao seguinte:
a) Tipo: por exemplo, corretivo, melhoria, preventivo,
ou adaptativo para um novo ambiente;
b) Escopo: por exemplo, tamanho da modificao,
custo envolvido, prazo para modificar;
c) Criticidade: por exemplo, impacto no desempenho,
proteo ou segurana.
Cpia no autorizada
17
5.5.2.2 O mantenedor deve reproduzir ou verificar o
problema.
5.5.2.3 Baseado na anlise, o mantenedor deve desen-
volver alternativas para a implementao da modificao.
5.5.2.4 O mantenedor deve documentar o problema/pe-
dido de modificao, os resultados da anlise e as alter-
nativas de implementao.
5.5.2.5 O mantenedor deve obter aprovao para a al-
ternativa de modificao selecionada, conforme especi-
ficado no contrato.
5.5.3 Implementao da modificao. Esta atividade
5.5.3.1 O mantenedor deve conduzir a anlise e determinar
que documentao, unidades de software e verses
destas necessitam ser modificadas. Estas devem ser do-
cumentadas.
5.5.3.2 O mantenedor deve utilizar o processo de de-
senvolvimento (5.3) para implementar as modificaes.
Os requisitos do processo de desenvolvimento devem
ser complementados, como segue:
a) Devem ser definidos e documentados critrios de
teste e de avaliao para testar e avaliar as partes
modificadas e as no modificadas do sistema (uni-
dades de software, componentes e itens de con-
figurao).
b) Deve ser garantida a implementao completa e
correta dos requisitos novos e dos modificados.
Tambm deve ser garantido que os requisitos ori-
ginais no modificados no foram afetados. Os resul-
tados dos testes devem ser documentados.
5.5.4 Reviso/aceitao da manuteno. Esta atividade
5.5.4.1 O mantenedor deve conduzir reviso(es) com a
organizao que autorizou a modificao para determinar
a integridade do sistema modificado.
5.5.4.2 O mantenedor deve obter aprovao para a con-
cluso satisfatria da modificao, conforme especificado
no contrato.
5.5.5 Migrao. Esta atividade consiste nas seguintes
tarefas:
5.5.5.1 Se um sistema ou produto de software (incluindo
dados) migrado de um ambiente de operao antigo
para um novo, deve ser assegurado que qualquer produto
de software ou dados produzidos ou modificados durante
a migrao estejam de acordo com esta Norma.
5.5.5.2 Um plano de migrao deve ser desenvolvido,
documentado e executado. As atividades de plane-
jamento devem incluir os usurios. Os itens includos no
plano devem conter o seguinte:
a) Anlise e definio dos requisitos de migrao;
b) Desenvolvimento de ferramentas de migrao;
c) Converso de produto de software e dados;
d) Execuo da migrao;
e) Verificao da migrao;
f) Suporte para o ambiente antigo.
5.5.5.3 Usurios devem receber notificao dos planos e
atividades de migrao. Notificaes devem conter o se-
guinte:
a) Explicao do porqu o ambiente antigo no ser
mais suportado;
b) Descrio do novo ambiente com sua data de dis-
ponibilizao;
c) Descrio de outras opes de suporte dispo-
nveis, se existirem, uma vez que o suporte para o
ambiente antigo seja descontinuado.
5.5.5.4 Operaes paralelas dos ambientes antigo e novo
podem ser conduzidas para a transio gradual ao novo
ambiente. Durante este perodo, deve ser provido o treina-
mento necessrio, conforme especificado no contrato.
5.5.5.5 Quando a migrao programada ocorrer, devem
ser enviadas notificaes a todos os interessados. Toda
documentao, histricos (logs) e cdigo associados ao
ambiente antigo deveriam ser arquivados.
5.5.5.6 Aps a migrao, uma reviso deve ser executada
para avaliar o impacto da mudana para o novo ambiente.
Os resultados da reviso devem ser enviados s auto-
ridades apropriadas para informao, orientao e pro-
vidncias.
5.5.5.7 Dados utilizados ou associados com o ambiente
antigo devem estar acessveis, de acordo com os requi-
sitos do contrato para preservao e auditoria dos dados.
5.5.6 Descontinuao do software. Esta atividade consiste
NOTA - O produto de software dever ser descontinuado a
pedido do proprietrio.
5.5.6.1 Um plano de descontinuao, para remover o su-
porte ativo pelas organizaes responsveis pela ope-
rao e manuteno, deve ser desenvolvido e documen-
tado. As atividades de planejamento devem incluir os
usurios. O plano deve conter os itens listados a seguir.
O plano deve ser executado.
a) Cessao total ou parcial de suporte aps um
certo perodo de tempo;
b) Arquivamento do produto de software e sua do-
cumentao associada;
c) Responsabilidade por quaisquer questes futuras
de suporte residual;
d) Transio para o novo produto de software, se
aplicvel;
e) Disponibilidade de cpias de arquivos de dados.
Cpia no autorizada
18 NBR ISO/IEC 12207:1998
5.5.6.2 Os usurios devem receber notificao dos planos
e atividades de descontinuao. Notificaes devem
incluir o seguinte:
a) Descrio da substituio ou atualizao com sua
data de disponibilidade;
b) Explicao do porqu o produto de software no
receber mais suporte;
c) Descrio de outras opes de suporte dispo-
nveis, uma vez que o suporte seja descontinuado.
5.5.6.3 Operaes paralelas do produto de software em
descontinuao e do novo deveriam ser conduzidas para
transio gradual ao novo sistema. Durante este perodo,
deve ser provido treinamento de usurio, conforme es-
pecificado no contrato.
5.5.6.4 Quando a descontinuao programada ocorrer,
devem ser enviadas notificaes a todos os interessados.
Toda documentao, histricos (logs) e cdigo asso-
ciados ao desenvolvimento deveriam ser arquivados,
quando apropriado.
5.5.6.5 Dados utilizados ou associados com o produto de
software descontinuado devem estar acessveis, de acor-
do com os requisitos do contrato para preservao e audi-
toria dos dados.
6 Processos de apoio de ciclo de vida
Este captulo define os seguintes processos de apoio de
ciclo de vida:
1) Processo de documentao;
2) Processo de gerncia de configurao;
3) Processo de garantia da qualidade;
4) Processo de verificao;
5) Processo de validao;
6) Processo de reviso conjunta;
7) Processo de auditoria;
8) Processo de resoluo de problema.
As atividades e tarefas em um processo de apoio so de
responsabilidade da organizao que o executa.
Essa organizao garante que o processo existe e fun-
cional.
A organizao que utiliza e executa um processo de apoio
o gerencia em nvel de projeto, seguindo o processo de
gerncia (7.1); estabelece uma infra-estrutura sob este
processo, seguindo o processo de infra-estrutura (7.2);
adapta o processo para o projeto, seguindo o processo
de adaptao (anexo A); e gerencia o processo em nvel
organizacional, seguindo o processo de melhoria (7.3) e
o processo de treinamento (7.4). Revises conjuntas,
auditorias, verificao e validao podem ser utilizadas
como tcnicas de garantia da qualidade.
6.1 Processo de documentao
O processo de documentao um processo para regis-
trar informaes produzidas por um processo ou atividade
do ciclo de vida. O processo contm o conjunto de ativi-
dades que planeja, projeta, desenvolve, produz, edita,
distribui e mantm aqueles documentos necessrios a
todos os interessados, tais como gerentes, engenheiros
e usurios do sistema ou produto de software.
Lista das atividades. Este processo consiste nas seguintes
atividades:
2) Projeto e desenvolvimento;
3) Produo;
4) Manuteno.
6.1.1.1 Um plano, identificando os documentos a serem
produzidos durante o ciclo de vida do produto de
software, deve ser desenvolvido, documentado e imple-
mentado. Para cada documento identificado, o seguinte
deve ser definido:
a) Ttulo ou nome;
b) Propsito;
c) Pblico-alvo;
d) Procedimentos e responsabilidades pelas en-
tradas, desenvolvimento, reviso, alterao, apro-
vao, produo, armazenamento, distribuio, ma-
nuteno e gerncia de configurao.
e) Cronograma das verses intermedirias e final.
6.1.2 Projeto e desenvolvimento. Esta atividade consiste
6.1.2.1 Cada documento identificado deve ser projetado
de acordo com os padres de documentao aplicveis
no que se refere ao formato, descrio de contedo, nu-
merao de pgina, localizao de figuras/tabelas, marcas
de propriedade/segurana, empacotamento, e outros
itens de apresentao.
6.1.2.2 A fonte e a adequao dos dados de entrada para
os documentos devem ser confirmadas. Ferramentas
para a automatizao da documentao podem ser uti-
lizadas.
6.1.2.3 Os documentos preparados devem ser revisados
e editados em comparao com os seus padres de do-
cumentao no que se refere ao formato, contedo tcnico
e estilo de apresentao. Eles devem ser aprovados
quanto sua adequao, pelo pessoal autorizado, antes
de sua emisso.
Cpia no autorizada
19
6.1.3 Produo. Esta atividade consiste nas seguintes
tarefas:
6.1.3.1 Os documentos devem ser produzidos e fornecidos
de acordo com o plano. A produo e a distribuio dos
documentos podem utilizar papel, meio eletrnico ou outra
mdia. As matrizes devem ser armazenadas de acordo
com os requisitos para guarda de registro, segurana,
manuteno e cpia de segurana.
6.1.3.2 Controles devem ser estabelecidos, de acordo com
o processo de gerncia de configurao (6.2).
6.1.4 Manuteno. Esta atividade consiste na seguinte ta-
refa:
6.1.4.1 Quando a documentao est para ser alterada,
as tarefas necessrias devem ser executadas (5.5). Para
aqueles documentos que esto sob a gerncia de confi-
gurao, as alteraes devem ser gerenciadas, de acordo
com o processo de gerncia de configurao (6.2).
6.2 Processo de gerncia de configurao
O processo de gerncia de configurao um processo
de aplicao de procedimentos administrativos e tc-
nicos, por todo o ciclo de vida de software, destinado a:
identificar e definir os itens de software em um sistema, e
estabelecer suas linhas bsicas (baseline); controlar as
modificaes e liberaes dos itens; registrar e apre-
sentar a situao dos itens e dos pedidos de modificao;
garantir a completeza, a consistncia e a correo dos
itens; e controlar o armazenamento, a manipulao e a
distribuio dos itens.
NOTA - O termo item de software pode ser empregado para
outros produtos de software ou entidades.
atividades:
2) Identificao da configurao;
3) Controle da configurao;
4) Relato da situao da configurao;
5) Avaliao da configurao;
6) Gerncia de liberao e distribuio.
na seguinte tarefa:
6.2.1.1 Um plano de gerncia de configurao deve ser
desenvolvido. O plano deve descrever: as atividades da
gerncia de configurao; procedimentos e cronograma
para executar estas atividades; as organizaes res-
ponsveis pela execuo destas atividades; e seu rela-
cionamento com outras organizaes, como por exemplo
a de desenvolvimento ou manuteno de software.
O plano deve ser documentado e implementado.
NOTA - O plano pode ser parte do plano de gerncia de confi-
gurao do sistema.
6.2.2 Identificao da configurao. Esta atividade consiste
na seguinte tarefa:
6.2.2.1 Uma sistemtica para o projeto deve ser estabe-
lecida para a identificao dos itens de software e suas
verses a serem controladas. Para cada item de
software e suas verses deve ser identificado o seguinte:
a documentao que estabelece a linha bsica (baseline);
as referncias de verso e outros detalhes de identi-
ficao.
6.2.3 Controle da configurao. Esta atividade consiste
na seguinte tarefa:
6.2.3.1 Deve ser executado o seguinte: identificao e
registro dos pedidos de alterao; anlise e avaliao
das alteraes; aprovao ou rejeio do pedido; e imple-
mentao, verificao e liberao do item de software
modificado. Devem existir registros de auditoria, de tal
forma que, para cada modificao, a sua razo e a sua
autorizao possam ser rastreadas. Deve ser realizado
controle e auditoria de todos os acessos aos itens de
software controlados que tratam de funes crticas de
proteo ou segurana.
6.2.4 Relato da situao da configurao. Esta atividade
consiste na seguinte tarefa:
6.2.4.1 Devem ser preparados registros de gerenciamento
e relatrios de situao que mostrem a situao e o his-
trico dos itens de software controlados, incluindo a linha
bsica (baseline). Os relatrios de situao deveriam
incluir o nmero de alteraes em um projeto, as ltimas
verses do item de software, identificadores de liberao,
a quantidade de liberaes e as comparaes entre elas.
6.2.5 Avaliao da configurao. Esta atividade consiste
na seguinte tarefa:
6.2.5.1 Deve ser determinado e garantido o seguinte: a
completeza funcional dos itens de software em relao
aos seus requisitos e a completeza fsica dos itens de
software (ou seja, se seu projeto e cdigo refletem uma
descrio tcnica atualizada).
6.2.6 Gerncia de liberao e distribuio. Esta atividade
6.2.6.1 A liberao e a distribuio de produtos de
software e documentao devem ser formalmente con-
troladas. Cpias matrizes do cdigo e da documentao
devem ser mantidas durante a vida do produto de
software. O cdigo e a documentao que contenham
funes crticas de proteo ou segurana devem ser
manipulados, armazenados, empacotados e distribudos
de acordo com as polticas das organizaes envolvidas.
6.3 Processo de garantia da qualidade
O processo de garantia da qualidade um processo para
fornecer garantia adequada de que os processos e pro-
dutos de software, no ciclo de vida do projeto, estejam
em conformidade com seus requisitos especificados e
sejam aderentes aos planos estabelecidos. Para ser im-
parcial, a garantia da qualidade necessita ter autoridade
e autonomia organizacional, independente das pessoas
diretamente responsveis pelo desenvolvimento do
produto de software ou pela execuo do processo no
projeto.
Cpia no autorizada
20 NBR ISO/IEC 12207:1998
A garantia da qualidade pode ser interna ou externa,
dependendo da necessidade da qualidade do produto
ou do processo ser evidenciada para a gerncia do
fornecedor ou do adquirente.
A garantia da qualidade pode utilizar os resultados de
outros processos de apoio tais como: verificao,
validao, revises conjuntas, auditorias e resoluo de
problema.
Lista das atividades. Este processo consiste nas
seguintes atividades:
2) Garantia do produto;
3) Garantia do processo;
4) Sistemas de garantia da qualidade.
6.3.1.1 Um processo de garantia da qualidade adaptado
ao projeto deve ser estabelecido. Os objetivos do pro-
cesso de garantia da qualidade devem ser determinados,
para garantir que os produtos de software e os processos
empregados para fornec-los estejam conforme os seus
requisitos estabelecidos e sejam aderentes aos seus
planos estabelecidos.
6.3.1.2 O processo de garantia da qualidade deveria ser
coordenado com os processos de verificao (6.4),
validao (6.5), reviso conjunta (6.6) e auditoria (6.7).
6.3.1.3 Um plano para conduzir as atividades e tarefas do
processo de garantia da qualidade deve ser desen-
volvido, documentado, implementado e mantido durante
a vigncia do contrato. O plano deve incluir o seguinte:
a) Padres de qualidade, metodologias, procedi-
mentos e ferramentas para executar as atividades
de garantia da qualidade (ou referncias na docu-
mentao oficial da organizao);
b) Procedimentos para reviso de contrato e sua
coordenao;
c) Procedimentos para identificao, coleta, arqui-
vamento, manuteno e disponibilizao dos re-
gistros da qualidade;
d) Recursos, cronograma e responsabilidades para
conduzir as atividades de garantia da qualidade;
e) Atividades e tarefas selecionadas dos processos
de apoio, tais como verificao (6.4), validao (6.5),
reviso conjunta (6.6), auditoria (6.7) e resoluo de
problema (6.8).
6.3.1.4 Atividades e tarefas de garantia da qualidade
agendadas e em andamento devem ser executadas.
Quando problemas ou no-conformidades aos requisitos
do contrato so detectados, devem ser documentados e
servem de entrada ao processo de resoluo de pro-
blema (seo 6.8). Registros destas atividades e tarefas,
sua execuo, problemas e resolues de problemas
devem ser gerados e mantidos.
6.3.1.5 Registros das atividades e tarefas de garantia da
qualidade devem ser disponibilizados ao adquirente,
como especificado no contrato.
6.3.1.6 Deve ser assegurado que pessoas responsveis
por garantir a conformidade aos requisitos do contrato
tenham autonomia, recursos e autoridade organi-
zacionais, para possibilitar avaliaes objetivas e para
iniciar, efetuar, resolver e verificar resolues de pro-
blemas.
6.3.2 Garantia do produto. Esta atividade consiste nas
seguintes tarefas:
6.3.2.1 Deve ser garantido que todos os planos exigidos
pelo contrato sejam documentados, estejam de acordo
com o contrato, sejam mutuamente consistentes e sejam
executados quando requerido.
6.3.2.2 Deve ser garantido que os produtos de software e
a documentao relacionada estejam de acordo com o
contrato e aderentes aos planos.
6.3.2.3 Na preparao da entrega dos produtos de
software deve ser garantido que os produtos de software
tenham seus requisitos contratuais inteiramente satis-
feitos e sejam aceitveis pelo adquirente.
6.3.3 Garantia do processo. Esta atividade consiste nas
seguintes tarefas:
6.3.3.1 Deve ser garantido que aqueles processos do ciclo
de vida do sofware (fornecimento, desenvolvimento,
operao, manuteno e os processos de apoio, in-
cluindo garantia da qualidade) empregados no projeto
estejam de acordo com o contrato e aderentes aos planos.
6.3.3.2 Deve ser garantido que as prticas internas de
engenharia de software, ambiente de desenvolvimento,
ambiente de teste e bibliotecas estejam de acordo com o
contrato.
6.3.3.3 Deve ser garantido que os requisitos aplicveis
ao contrato original sejam passados para o subcontratado
e que os produtos de software do subcontratado
satisfaam os requisitos do contrato original.
6.3.3.4 Deve ser garantido que o adquirente e outras
partes envolvidas sejam providos do apoio e da coope-
rao requeridos, de acordo com o contrato, negociaes
e planos.
6.3.3.5 Deveria estar garantido que as medies do
produto e do processo de software estejam de acordo
com padres e procedimentos estabelecidos.
6.3.3.6 Deve ser garantido que a equipe alocada tenha a
qualificao e o conhecimento necessrios para atender
os requisitos do projeto e recebam todo treinamento
necessrio.
6.3.4 Sistemas de garantia da qualidade. Esta atividade
6.3.4.1 Atividades adicionais de gerncia da qualidade
devem ser garantidas de acordo com as clusulas da
NBR ISO 9001, como especificado no contrato.
Cpia no autorizada
21
6.4 Processo de verificao
O processo de verificao um processo para determinar
se os produtos de software de uma atividade atendem
completamente os requisitos ou condies impostas a
eles nas atividades anteriores. Para a eficcia de custo e
desempenho, a verificao deveria ser integrada, o quanto
antes, com o processo que a utiliza (tais como forneci-
mento, desenvolvimento, operao ou manuteno). Este
processo pode incluir anlise, reviso e teste.
Este processo pode ser executado com variados graus
de independncia. O grau de independncia pode variar
da mesma pessoa ou outra pessoa da organizao, para
uma pessoa de outra organizao, com variados graus
de envolvimento. No caso em que o processo executado
por uma organizao independente do fornecedor, de-
senvolvedor, operador ou mantenedor, chamado de
processo de verificao independente.
atividades:
2) Verificao.
6.4.1.1 Deve ser determinado se o projeto justifica um
esforo de verificao e o grau de independncia organi-
zacional. Os requisitos do projeto devem ser analisados
em funo dos fatores crticos. Estes fatores podem ser
aferidos nos seguintes termos:
a) O potencial de que um erro no detectado em um
requisito do sistema ou software possa causar morte
ou dano pessoal, no alcance de objetivos, perda
ou dano financeiro ou de equipamento;
b) A maturidade e riscos associados com a tecnologia
de software a ser utilizada; e
c) A disponibilidade financeira e de recursos.
6.4.1.2 Se o projeto justifica um esforo de verificao, um
processo de verificao deve ser estabelecido para
verificar o produto de software.
6.4.1.3 Se o projeto justifica um esforo de verificao
independente, deve ser selecionada uma organizao
qualificada responsvel para conduzi-la. Esta organi-
zao deve ter assegurada a independncia e autoridade
para executar as atividades de verificao.
6.4.1.4 Baseado no escopo, magnitude, complexidade e
anlise dos fatores crticos mencionados anteriormente,
devem ser determinadas as atividades do ciclo de vida e
os produtos de software que requerem verificao.
As atividades e tarefas de verificao definidas no item
6.4.2, incluindo mtodos, tcnicas e ferramentas asso-
ciados para executar as tarefas, devem ser selecionadas
para as atividades do ciclo de vida e produtos de
software em questo.
6.4.1.5 Baseado nas tarefas de verificao determinadas
anteriormente, um plano de verificao deve ser desen-
volvido e documentado. O plano deve indicar as ativi-
dades do ciclo de vida e produtos de software sujeitos a
verificao, as tarefas de verificao requeridas para
cada atividade do ciclo de vida e produto de software; e
recursos, responsabilidades e cronograma associados.
O plano deve indicar procedimentos para enviar relatrios
de verificao ao adquirente e outras organizaes en-
volvidas.
6.4.1.6 O plano de verificao deve ser implementado.
Problemas e no-conformidades detectados pelo esforo
de verificao devem ser includos no processo de
resoluo de problema (6.8). Todos os problemas e no-
conformidades devem ser resolvidos. Os resultados das
atividades de verificao devem ser disponibilizados
para o adquirente e outras organizaes envolvidas.
6.4.2 Verificao. Esta atividade consiste nas seguintes
tarefas:
6.4.2.1 Verificao do contrato. O contrato deve ser
verificado considerando os seguintes critrios:
a) O fornecedor tem a capacidade de atender os re-
quisitos.
b) Os requisitos esto consistentes e cobrem as
necessidades do usurio.
c) Procedimentos adequados, para tratar alteraes
nos requisitos e priorizao de problemas, esto
estipulados.
d) Procedimentos e sua abrangncia para interao
e cooperao entre as partes so estipulados,
incluindo propriedade, garantia, direitos autorais e
confidencialidade.
e) Critrios e procedimentos de aceitao esto
estipulados de acordo com os requisitos.
NOTA - Esta atividade pode ser usada na reviso do contrato
(ver 6.3.1.3 b).
6.4.2.2 Verificao do processo. O processo deve ser
verificado considerando os seguintes critrios:
a) Os requisitos de planejamento do projeto esto
adequados e oportunos.
b) Os processos selecionados para o projeto esto
adequados, implementados, sendo executados
como planejados e conforme o contrato.
c) Os padres, procedimentos e ambientes para os
processos do projeto esto adequados.
d) O projeto dispe de equipe e pessoal capacitado,
como requerido no contrato.
Cpia no autorizada
22 NBR ISO/IEC 12207:1998
6.4.2.3 Verificao dos requisitos. Os requisitos devem
ser verificados considerando os seguintes critrios:
a) Os requisitos do sistema so consistentes, viveis
e testveis.
b) Os requisitos do sistema foram distribudos apro-
priadamente para os itens de hardware, itens de
software e operaes manuais, de acordo com os
critrios do projeto.
c) Os requisitos de software so consistentes, viveis,
testveis e refletem precisamente os requisitos do
sistema.
d) Os requisitos de software relacionados proteo,
segurana e aos fatores crticos esto corretos,
conforme demonstrado por mtodos adequadamente
rigorosos.
6.4.2.4 Verificao de projeto. O projeto deve ser verificado
considerando os seguintes critrios:
a) O projeto est correto e consistente com os re-
quisitos e rastrevel aos mesmos.
b) O projeto implementa uma seqncia adequada
de eventos, entradas, resultados, interfaces, fluxo
lgico, alocao de tempo e de oramentos, e de-
finio, isolamento e recuperao de erro.
c) O projeto selecionado pode ser originado a partir
dos requisitos.
d) O projeto implementa proteo, segurana e
outros requisitos crticos corretamente, conforme
demonstrado por mtodos adequadamente rigo-
rosos.
6.4.2.5 Verificao do cdigo. O cdigo deve ser verificado,
considerando os seguintes critrios:
a) O cdigo rastrevel para o projeto e para os re-
quisitos, testvel, correto e aderente aos requisitos e
padres de codificao.
b) O cdigo implementa a seqncia de eventos
apropriada, interfaces consistentes, dados e fluxo
de controle corretos, completeza, alocao de tempo
e de oramentos apropriada, e definio, isolamento
e recuperao de erros.
c) O cdigo selecionado pode ser originado a partir
do projeto ou dos requisitos.
d) O cdigo implementa proteo, segurana e outros
requisitos crticos corretamente, conforme demons-
trado por mtodos adequadamente rigorosos.
6.4.2.6 Verificao da integrao. A integrao deve ser
verificada considerando os seguintes critrios:
a) Os componentes de software e unidades de cada
item de software foram completa e corretamente
integrados dentro do item de software.
b) Os itens de hardware, de software e operaes
manuais do sistema foram completa e corretamente
integrados ao sistema.
c) As tarefas de integrao foram executadas de
acordo com um plano de integrao.
6.4.2.7 Verificao da documentao. A documentao
deve ser verificada, considerando os seguintes critrios:
a) A documentao est adequada, completa e
consistente.
b) A preparao da documentao est oportuna.
c) A gerncia de configurao dos documentos segue
procedimentos especificados.
6.5 Processo de validao
O processo de validao um processo para determinar
se os requisitos e o produto final, sistema ou produto de
software construdo, atendem ao uso especfico pre-
tendido. A validao pode ser conduzida nos estgios
iniciais. Este processo pode ser conduzido como parte
da atividade de apoio aceitao do software (5.3.13).
Este processo pode ser executado com variados graus
de independncia. O grau de independncia pode variar
da mesma pessoa ou outra pessoa da organizao, para
uma pessoa de outra organizao, com variados graus
de envolvimento. No caso em que o processo executado
por uma organizao independente do fornecedor,
desenvolvedor, operador ou mantenedor, chamado de
processo de validao independente.
atividades:
2) Validao.
6.5.1.1 Deve ser determinado se o projeto justifica um
esforo de validao e o grau de independncia organi-
zacional.
6.5.1.2 Se o projeto justifica um esforo de validao, um
processo de validao deve ser estabelecido para validar
o sistema ou o produto de software. As tarefas de vali-
dao definidas a seguir, incluindo mtodos, tcnicas e
ferramentas associados para executar as tarefas, devem
ser selecionadas.
6.5.1.3 Se o projeto justifica um esforo de validao
independente, deve ser selecionada uma organizao
qualificada responsvel para conduzi-la. O condutor deve
ter assegurada a independncia e autoridade para exe-
cutar as tarefas de validao.
6.5.1.4 Um plano de validao deve ser desenvolvido e
documentado. O plano deve incluir, mas no estar limitado
ao seguinte:
a) Itens sujeitos validao;
b) Tarefas de validao a serem executadas;
c) Recursos, responsabilidades e cronograma para
validao; e
d) Procedimentos para encaminhar relatrios de va-
lidao ao adquirente e outras partes envolvidas.
Cpia no autorizada
23
6.5.1.5 O plano de validao deve ser implementado.
Problemas e no-conformidades detectados pelo esforo
de validao devem ser includos no processo de reso-
luo de problema (6.8). Todos os problemas e no-
conformidades devem ser resolvidos. Os resultados das
atividades de validao devem ser disponibilizados para
o adquirente e outras organizaes envolvidas.
6.5.2 Validao. Esta atividade consiste nas seguintes
tarefas:
6.5.2.1 Preparar os requisitos de teste, casos de teste e
especificaes de teste selecionados para anlise dos
resultados dos testes.
6.5.2.2 Assegurar que estes requisitos de teste, casos de
teste e especificaes de teste reflitam os requisitos
particulares para o uso especfico pretendido.
6.5.2.3 Conduzir os testes nos itens 6.5.2.1 e 6.5.2.2,
incluindo:
a) Teste de estresse, limites e entradas especficas.
b) Teste do produto de software para verificar sua
habilidade em isolar e minimizar efeitos de erros;
isto , degradao suave em caso de falha, pedido
de assistncia do operador em caso de estresse, de
exceder limites e de condies especficas.
c) Teste para que usurios representativos possam
executar, com sucesso, suas tarefas pretendidas
usando o produto de software.
6.5.2.4 Validar que o produto de software satisfaa seu
uso pretendido.
6.5.2.5 Testar o produto de software, quando apropriado,
nas reas selecionadas do ambiente-alvo.
6.6 Processo de reviso conjunta
O processo de reviso conjunta um processo para
avaliar a situao e produtos de uma atividade de um
projeto, se apropriado. As revises conjuntas so feitas
tanto nos nveis de gerenciamento do projeto como nos
nveis tcnicos e so executadas durante a vigncia do
contrato. Este processo pode ser empregado por
qualquer das duas partes, onde uma parte (parte revisora)
revisa a outra parte (parte revisada).
atividades:
2) Revises de gerenciamento do projeto;
3) Revises tcnicas.
6.6.1.1 Revises peridicas devem ser promovidas em
marcos predeterminados, como especificado no(s)
plano(s) do projeto. Revises ad hoc deveriam ser
realizadas quando julgadas necessrias por quaisquer
das partes.
6.6.1.2 Todos os recursos requeridos para conduzir as
revises devem ser acordados pelas partes. Estes re-
cursos incluem pessoal, local, instalaes, hardware,
software e ferramentas.
6.6.1.3 As partes deveriam concordar com os seguintes
itens em cada reviso: agenda da reunio, produtos de
software (resultados de uma atividade) e problemas a
serem revisados; escopo e procedimentos; e critrios
para incio e trmino da reviso.
6.6.1.4 Problemas detectados durante as revises devem
ser registrados e includos no processo de resoluo de
problema (6.8), conforme requerido.
6.6.1.5 Os resultados da reviso devem ser documentados
e distribudos. A parte revisora apresentar parte revi-
sada a adequabilidade (por exemplo: aprovao, desa-
provao ou aprovao condicional) dos resultados da
reviso.
6.6.1.6 As partes devem concordar com os resultados da
reviso e quaisquer responsabilidades pelo item de ao
e critrios de encerramento.
6.6.2 Revises de gerenciamento do projeto. Esta atividade
consiste na seguinte tarefa.
6.6.2.1 A situao do projeto deve ser avaliada em relao
aos planos, cronogramas, padres e diretrizes aplicveis
ao projeto. O resultado da reviso deveria ser discutido
entre as duas partes e deveria fornecer subsdios para o
seguinte:
a) Fazer com que as atividades progridam de acordo
com o plano, baseado em uma avaliao da situao
da atividade ou do produto de software;
b) Manter o controle geral do projeto atravs da alo-
cao adequada de recursos;
c) Redirecionar o projeto ou determinar a necessi-
dade de um planejamento alternativo; e
d) Avaliar e gerenciar as situaes de risco que
possam comprometer o sucesso do projeto.
6.6.3 Revises tcnicas. Esta atividade consiste na seguinte
tarefa:
6.6.3.1 Revises tcnicas devem ser promovidas para
avaliar os produtos ou servios de software em conside-
rao e prover evidncia de que:
a) Eles esto completos;
b) Eles esto aderentes aos seus padres e espe-
cificaes;
c) Suas alteraes esto implementadas adequa-
damente e afetam somente aquelas reas identi-
ficadas pelo processo de gerncia de configura-
o (6.2);
Cpia no autorizada
24 NBR ISO/IEC 12207:1998
d) Eles esto aderentes aos cronogramas aplicveis;
e) Eles esto prontos para a prxima atividade; e
f) O desenvolvimento, operao ou manuteno esto
sendo conduzidos de acordo com os planos, cro-
nogramas, padres e diretrizes do projeto.
6.7 Processo de auditoria
O processo de auditoria um processo para determinar
adequao aos requisitos, planos e contrato, quando
apropriado. Este processo pode ser empregado por
quaisquer das duas partes, onde uma parte (parte
auditora) faz a auditoria nos produtos de software ou nas
atividades da outra parte (parte auditada).
atividades:
2) Auditoria.
6.7.1. Implementao do processo. Esta atividade consiste
6.7.1.1 As auditorias devem ser promovidas em marcos
predeterminados, conforme especificado no(s) plano(s)
do projeto.
6.7.1.2 O pessoal da auditoria no deve ter nenhuma
responsabilidade direta pelos produtos de software e
atividades que eles auditam.
6.7.1.3 Todos os recursos requeridos para conduzir a
auditoria devem ser acordados pelas partes. Esses
recursos incluem pessoal de apoio, local, instalaes,
hardware, software e ferramentas.
6.7.1.4 As partes deveriam concordar com os seguintes
itens em cada auditoria: agenda; produtos de software (e
resultados de uma atividade) a serem revisados; escopo
e procedimentos da auditoria; e critrios de incio e
trmino da auditoria.
6.7.1.5 Problemas detectados durante as auditorias
devem ser registrados e includos no processo de reso-
luo de problema (6.8), quando requerido.
6.7.1.6 Aps a concluso de uma auditoria, os resultados
da auditoria devem ser documentados e entregues parte
auditada. A parte auditada deve apresentar parte audi-
tora quaisquer problemas encontrados na auditoria e o
planejamento das resolues dos problemas relatados.
6.7.1.7 As partes devem concordar com o resultado da
auditoria e quaisquer responsabilidades pelo item de
ao e critrios de encerramento.
6.7.2. Auditoria. Esta atividade consiste na seguinte tarefa:
6.7.2.1 As auditorias devem ser conduzidas para asse-
gurar que:
a) Produtos de software codificados (tais como item
de software) reflitam a documentao do projeto;
b) A reviso de aceitao e requisitos de teste pres-
critos pela documentao estejam adequados para
aceitao dos produtos de software;
c) Dados de teste estejam aderentes especificao;
d) Os produtos de software sejam testados com su-
cesso e atendam s suas especificaes;
e) Os relatrios de teste estejam corretos e discre-
pncias entre o resultado real e o esperado sejam
resolvidos;
f) A documentao do usurio esteja aderente aos
padres, conforme o especificado;
g) As atividades sejam conduzidas de acordo com
os requisitos, planos e contrato aplicveis; e
h) Os custos e cronogramas adiram aos planos es-
tabelecidos.
6.8 Processo de resoluo de problema
O processo de resoluo de problema um processo
para analisar e resolver os problemas (incluindo no-
conformidades), de qualquer natureza ou fonte, que so
descobertos durante a execuo do desenvolvimento,
operao, manuteno ou outros processos. O objetivo
prover os meios em tempo adequado e de forma res-
ponsvel e documentada para garantir que todos os pro-
blemas encontrados sejam analisados e resolvidos e
tendncias sejam identificadas.
atividades:
2) Resoluo de problema.
na seguinte tarefa:
6.8.1.1 Um processo de resoluo de problema deve ser
estabelecido para tratar todos os problemas (incluindo
no-conformidades) detectados nos produtos de
software e atividades. O processo deve atender aos se-
guintes requisitos:
a) O processo deve ser de ciclo fechado (closed-
loop), garantindo que: todos os problemas detectados
sejam prontamente relatados e includos no processo
de resoluo de problema; a ao seja iniciada nos
problemas detectados; as partes relevantes sejam
alertadas da existncia do problema, quando
apropriado; as causas sejam identificadas, anali-
sadas e, quando possvel, eliminadas; a resoluo e
sua aplicao sejam alcanadas; a situao seja
rastreada e relatada; e os registros dos problemas
sejam mantidos, conforme estipulado no contrato;
b) O processo deveria conter um esquema para cate-
gorizar e priorizar os problemas. Cada problema
deveria ser classificado por categoria e prioridade
para facilitar a anlise de tendncia e resoluo de
problema;
Cpia no autorizada
25
c) A anlise deve ser executada para detectar ten-
dncias nos problemas relatados;
d) As resolues de problemas e suas aplicaes
devem ser avaliadas para: verificar se os problemas
foram resolvidos, se as tendncias adversas foram
revertidas e se as alteraes foram implementadas
corretamente nos produtos de software e atividades
apropriados; e determinar se problemas adicionais
foram introduzidos.
6.8.2 Resoluo do problema. Esta atividade consiste na
seguinte tarefa:
6.8.2.1 Quando problemas (incluindo no-conformidades)
forem detectados em um produto de software ou em uma
atividade, um relatrio de problema deve ser preparado
para descrever cada problema detectado. O relatrio de
problema deve ser usado como parte do processo de
ciclo fechado (closed-loop) descrito acima: a partir da
deteco do problema, ao longo da investigao, anlise
e resoluo do problema e sua causa, e para detectar
tendncias.
7 Processos organizacionais de ciclo de vida
Este captulo define os seguintes processos organi-
zacionais de ciclo de vida:
1) Processo de gerncia;
2) Processo de infra-estrutura;
3) Processo de melhoria;
4) Processo de treinamento.
As atividades e tarefas em um processo organizacional
so de responsabilidade da organizao que o utiliza.
Essa organizao garante que o processo existe e fun-
cional.
O processo de gerncia contm as atividades e tarefas
genricas que podem ser empregadas por quaisquer das
partes que tm que gerenciar seu(s) respectivo(s)
processo(s). O gerente responsvel pelo gerenciamento
de produto, gerenciamento de projeto e gerenciamento
de tarefa do(s) processo(s) aplicvel(eis), tais como
aquisio, fornecimento, desenvolvimento, operao,
manuteno ou processos de apoio.
atividades:
1) Iniciao e definio do escopo;
2) Planejamento;
3) Execuo e controle;
4) Reviso e avaliao;
5) Concluso.
7.1.1 Iniciao e definio do escopo. Esta atividade
7.1.1.1 O processo de gerncia deve ser iniciado pelo
estabelecimento dos requisitos do processo a ser
empreendido.
7.1.1.2 Tendo estabelecido os requisitos, o gerente deve
estabelecer a viabilidade do processo, verificando se os
recursos (de pessoal, materiais, tecnolgicos e de am-
biente) requeridos para executar e gerenciar o processo
esto disponveis, adequados e apropriados e se os
prazos para concluso podem ser atingidos.
7.1.1.3 Quando necessrio, e com a concordncia de
todas as partes envolvidas, os requisitos do processo
podem ser modificados neste ponto para atingir os
critrios de concluso.
7.1.2 Planejamento. Esta atividade consiste na seguinte
tarefa:
7.1.2.1 O gerente deve preparar os planos para execuo
do processo. Os planos associados execuo do pro-
cesso devem conter descries das tarefas e atividades
associadas e identificao dos produtos de software que
sero providos. Esses planos no se limitam a, mas
devem incluir o seguinte:
a) Cronogramas para a concluso oportuna das ta-
refas;
b) Estimativa de esforo;
c) Recursos adequados necessrios para executar
as tarefas;
d) Alocao das tarefas;
e) Atribuio de responsabilidades;
f) Quantificao de riscos associados com as tarefas
ou com o prprio processo;
g) Medidas de controle de qualidade a serem em-
pregadas durante o processo;
h) Custos associados com a execuo do processo;
i) Proviso de ambiente e infra-estrutura.
7.1.3 Execuo e controle. Esta atividade consiste nas
seguintes tarefas:
7.1.3.1 O gerente deve iniciar a implementao do plano
para atender o conjunto de objetivos e critrios, exer-
cendo controle sobre o processo.
7.1.3.2 O gerente deve monitorar a execuo do processo,
provendo relatrios internos do progresso do processo e
relatrios externos para o adquirente, conforme definido
no contrato.
7.1.3.3 O gerente deve investigar, analisar e resolver os
problemas descobertos durante a execuo do processo.
A resoluo de problema pode resultar em alteraes
dos planos. responsabilidade do gerente garantir que
o impacto de quaisquer alteraes seja determinado,
controlado e monitorado. Os problemas e suas resolues
Cpia no autorizada
26 NBR ISO/IEC 12207:1998
7.1.3.4 O gerente deve reportar em pontos acordados o
progresso do processo, demonstrando aderncia aos
planos e resolvendo casos de necessidade de progresso.
Isto inclui relatrios internos e externos, conforme
requerem os procedimentos organizacionais e o contrato.
7.1.4 Reviso e avaliao. Esta atividade consiste nas
seguintes tarefas:
7.1.4.1 O gerente deve garantir que o software e os planos
sejam avaliados para satisfazer requisitos.
7.1.4.2 O gerente deve verificar os resultados da avaliao
dos produtos de software, atividades e tarefas finalizados
durante a execuo do processo para atingir os objetivos
e para concluir os planos.
7.1.5 Concluso. Esta atividade consiste nas seguintes
tarefas:
7.1.5.1 Quando todos os produtos de software, atividades
e tarefas estiverem completos, o gerente deve determinar
se o processo est completo, levando em considerao
os critrios especificados no contrato ou como parte de
um procedimento da organizao.
7.1.5.2 Para finalizar, o gerente deve verificar os resultados
e registros dos produtos de software, atividades e tarefas
empregados. Estes resultados e registros devem ser
arquivados em um ambiente adequado, conforme
especificado no contrato.
O processo de infra-estrutura um processo para esta-
belecer e manter a infra-estrutura necessria para
qualquer outro processo. A infra-estrutura pode incluir
hardware, software, ferramentas, tcnicas, padres e
recursos para o desenvolvimento, operao ou manu-
teno.
atividades:
2) Estabelecimento da infra-estrutura;
3) Manuteno da infra-estrutura.
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,
padres, ferramentas e tcnicas aplicveis.
7.2.1.2 O estabelecimento da infra-estrutura deveria ser
planejado e documentado.
7.2.2 Estabelecimento da infra-estrutura. Esta atividade
7.2.2.1 A configurao da infra-estrutura deveria ser pla-
nejada e documentada. Deveriam ser considerados: a
funcionalidade, o desempenho, a proteo, a segurana,
a disponibilidade, os requisitos de espao, os equipa-
mentos, os custos e as restries de tempo.
7.2.2.2 A infra-estrutura deve ser instalada a tempo para a
execuo do processo relevante.
7.2.3 Manuteno da infra-estrutura. Esta atividade
7.2.3.1 A infra-estrutura deve ser mantida, monitorada e
modificada quando necessrio, para garantir que ela con-
tinue a satisfazer os requisitos do processo que emprega
este processo. Como parte da manuteno da infra-
estrutura, deve ser definido at que ponto a infra-estrutura
est sob controle da gerncia de configurao.
O processo de melhoria um processo para estabelecer,
avaliar, medir, controlar e melhorar um processo de ciclo
de vida de software.
Lista de atividades: Este processo consiste nas seguintes
atividades:
1) Estabelecimento do processo;
2) Avaliao do processo;
3) Melhoria do processo.
7.3.1 Estabelecimento do processo. Esta atividade consiste
7.3.1.1 A organizao deve estabelecer um conjunto de
processos organizacionais para todos os processos de
ciclo de vida de software que se aplicam para suas ati-
vidades de negcio. Os processos e suas aplicaes
para casos especficos devem ser documentados em pu-
blicaes da organizao. Quando apropriado, um meca-
nismo de controle de processo deveria ser estabelecido
para desenvolver, monitorar, controlar e melhorar o(s)
processo(s).
7.3.2 Avaliao do processo. Esta atividade consiste nas
seguintes tarefas:
7.3.2.1 Um procedimento de avaliao de processo
deveria ser desenvolvido, documentado e aplicado.
Registros de avaliao deveriam ser guardados e
preservados.
7.3.2.2 A organizao deve planejar e executar revises
dos processos em intervalos apropriados para garantir
sua contnua adequao e eficincia, considerando os
resultados da avaliao.
7.3.3 Melhoria do processo. Esta atividade consiste nas
seguintes tarefas:
7.3.3.1 A organizao deve efetuar tais melhorias nos
seus processos se for determinada esta necessidade,
como resultado da avaliao e reviso do processo. A
documentao do processo deveria ser atualizada para
refletir a melhoria dos processos organizacionais.
Cpia no autorizada
27
7.3.3.2 Dados histricos, tcnicos e de avaliao de-
veriam ser coletados e analisados para aumentar um
entendimento dos pontos fortes e fracos dos processos
empregados. Estas anlises deveriam ser usadas como
realimentao (feedback) para melhorar estes processos,
para recomendar alteraes nas diretrizes dos projetos
(ou projetos subseqentes), e para determinar necessi-
dades de avanos tecnolgicos.
7.3.3.3 Dados de custo de qualidade deveriam ser cole-
tados, mantidos e usados, para melhorar os processos
da organizao como uma atividade gerencial. Estes
dados devem servir ao propsito de estabelecer o custo
de preveno e resoluo de problemas e no-conformi-
dade em produtos e servios de software.
O processo de treinamento um processo para prover e
manter pessoal treinado. A aquisio, o fornecimento, o
desenvolvimento, a operao ou a manuteno de pro-
dutos de software extremamente dependente de
pessoal com conhecimento e qualificao. Por exemplo:
pessoal de desenvolvimento deveria ter treinamento b-
sico em gerncia de software e engenharia de software.
, portanto, imperativo que o treinamento de pessoal seja
planejado e implementado com antecedncia para que
o pessoal treinado esteja disponvel quando o produto
de software for adquirido, fornecido, desenvolvido, ope-
rado ou mantido.
atividades:
2) Desenvolvimento do material de treinamento;
3) Implementao do plano de treinamento.
na seguinte tarefa:
7.4.1.1 Uma reviso dos requisitos do projeto deve ser
conduzida para estabelecer e providenciar, oportu-
namente, a aquisio ou o desenvolvimento de recursos
e conhecimentos necessrios ao pessoal tcnico e ge-
rencial. Os tipos e nveis de treinamento e categorias de
pessoal que necessitam de treinamento devem ser
determinados. Um plano de treinamento deveria ser
desenvolvido e documentado, de acordo com os cro-
nogramas de implementao, requisitos de recurso e ne-
cessidades de treinamento.
7.4.2 Desenvolvimento do material de treinamento. Esta
atividade consiste na seguinte tarefa:
7.4.2.1 Manuais de treinamento, incluindo materiais de
apresentao utilizados para prover treinamento,
deveriam ser desenvolvidos.
7.4.3 Implementao do plano de treinamento. Esta
atividade consiste nas seguintes tarefas:
7.4.3.1 O plano de treinamento deve ser implementado
para prover treinamento ao pessoal. Registros de treina-
mento deveriam ser preservados.
7.4.3.2 Deveria ser assegurado que uma equipe ade-
quadamente treinada esteja disponvel, oportunamente,
para as atividades e tarefas planejadas. Esta equipe
deveria ser formada por uma composio e categorias
corretas de pessoal.
/ANEXOS
Cpia no autorizada
28 NBR ISO/IEC 12207:1998
Anexo A (normativo)
Processo de adaptao
O processo de adaptao um processo para realizar a
adaptao bsica desta Norma para um projeto de
software. Este anexo fornece requisitos para adaptar esta
Norma.
atividades:
1) Identificao do ambiente do projeto;
2) Solicitao de informaes;
3) Seleo de processos, atividades e tarefas;
4) Documentao de decises e motivos da adap-
tao.
A.1 Identificao do ambiente do projeto. Esta ativi-
dade consiste na seguinte tarefa:
A.1.1 As caractersticas do ambiente do projeto que influ-
enciaro na adaptao devem ser identificadas. Algumas
das caractersticas podem ser: modelo de ciclo de vida;
atividade atual de ciclo de vida de sistema; requisitos do
sistema e do software; polticas, procedimentos e estra-
tgias organizacionais; tamanho, criticabilidade e tipos
do sistema, produto ou servio de software; e quantidade
de pessoas e partes envolvidas.
A.2 Solicitao de informaes. Esta atividade con-
siste na seguinte tarefa:
A.2.1 As informaes das organizaes que so afetadas
pelas decises de adaptao devem ser solicitadas.
Usurios, pessoal de suporte, gerentes de contrato e po-
tenciais proponentes deveriam ser envolvidos na
adaptao.
A.3 Seleo de processos, atividades e tarefas.
Esta atividade consiste nas seguintes tarefas:
A.3.1 Os processos, atividades e tarefas que sero exe-
cutados devem ser determinados. Isto inclui a documen-
tao a ser desenvolvida e quem ser responsvel por
ela. Para este propsito, esta Norma deveria ser avaliada
em relao aos dados relevantes reunidos em A.1 e A.2.
A.3.2 Os processos, atividades e tarefas que foram de-
terminados em A.3.1, mas no providos nesta Norma,
devem ser especificados no prprio contrato. Proces-
sos organizacionais do ciclo de vida (seo 7) deveriam
ser avaliados para determinar se eles poderiam dar sus-
tentao a estes processos, atividades e tarefas.
A.3.3 Nesta Norma, requisitos so indicados pelas
tarefas que contm deve ou dever. Deveria ser cuida-
dosamente considerado se estas tarefas devem ser
mantidas ou suprimidas para um determinado projeto
ou setor de negcio. Os fatores a serem considerados
no se limitam a, mas incluem: risco, custo, cronograma,
desempenho, tamanho, criticabilidade e interface
humana.
A.4 Documentao de decises e motivos da
adaptao. Esta atividade consiste na seguinte tarefa:
A.4.1 Todas as decises de adaptao devem ser docu-
mentadas juntamente com seus motivos.
/ANEXO B
Cpia no autorizada
29
Anexo B (informativo)
Orientao para adaptao
Nenhum projeto idntico a outro. Variaes nas polticas
e procedimentos organizacionais, mtodos e estratgias
de aquisio, tamanho e complexidade do projeto,
requisitos e mtodos de desenvolvimento do sistema,
entre outras coisas, influenciam na forma como um
sistema adquirido, desenvolvido, operado e mantido.
Para acomodar essas variaes, tanto quanto possvel,
esta Norma foi escrita para um projeto genrico. Portanto,
no interesse de reduo de custo e melhoria da
qualidade, esta Norma deveria ser adaptada para um
projeto especfico. Todas as partes envolvidas no projeto
deveriam ser envolvidas na adaptao.
B.1 Orientao geral de adaptao
Esta seo prov orientao na adaptao desta Norma
e no exaustiva. Esta seo pode ser usada para
realizar um primeiro nvel de adaptao desta Norma
para uma determinada organizao ou rea de negcio.
Por exemplo, aeronutica, nuclear, mdica, militar,
agropecuria, comercial. Um segundo nvel de adaptao
deveria ser realizado para cada projeto ou contrato
especfico.
B.2 Adaptao do processo de desenvolvimento
O processo de desenvolvimento (5.3) necessita de
ateno especial, porque este processo pode ser utilizado
por diferentes partes, com objetivos diferentes. Como um
primeiro nvel de adaptao deste processo, recomen-
dado o seguinte:
a) Para um produto de software que esteja embutido
ou integrado ao sistema: todas as atividades do
processo deveriam ser consideradas e deveria ser
esclarecido se o desenvolvedor requerido para
executar ou dar suporte s atividades do sistema.
b) Para um produto de software independente, as
atividades do sistema (5.3.2, 5.3.3, 5.3.10 e 5.3.11)
podem no ser requeridas, mas deveriam ser con-
sideradas.
B.3 Adaptao das atividades relacionadas com
avaliao
As pessoas envolvidas em qualquer atividade de um
processo ou de ciclo de vida de um projeto, conduzem
avaliaes de produto de software e atividades, prprios
ou de outros. Esta Norma agrupa estas avaliaes em
cinco categorias, as quais esto listadas abaixo. As quatro
primeiras categorias de avaliao esto em nvel de
projeto; a ltima est em nvel organizacional. Estas
avaliaes deveriam ser selecionadas e adaptadas de
acordo com o escopo, magnitude, complexidade e critica-
bilidade do projeto ou da organizao. Os relatrios de
problema, de no-conformidade e de melhoria destas
avaliaes alimentam o processo de resoluo de
problema (6.8).
a) Avaliaes internas de processos (tarefas de
avaliao de 5.1 a 5.5) so conduzidas pelo pessoal
que executa as tarefas atribudas, dentro do pro-
cesso, durante as suas atividades dirias.
b) Verificao (6.4) e validao (6.5) so conduzidas
pelo adquirente, pelo fornecedor ou por uma parte
independente, para verificar e validar os produtos
em nveis variveis de detalhamento, dependendo
do projeto. Estas avaliaes no so redundantes
nem substituem outras avaliaes, apenas as
complementam.
c) Revises conjuntas (6.6) e auditorias (6.7) so
conduzidas em um frum conjunto pelas partes
revisora e revisada, para avaliar o estado e a confor-
midade de produtos e atividades, em relao aos
cronogramas previamente acordados.
d) Garantia da qualidade (6.3) conduzida por
pessoal independente do pessoal diretamente
responsvel pelo desenvolvimento do produto de
software ou pela execuo do processo. O objetivo
garantir, com independncia, a conformidade dos
produtos de software e processos com os requisitos
do contrato e aderncia aos planos estabelecidos.
Este processo pode utilizar os resultados de a, b e c,
descritos anteriormente, como entradas. Este
processo pode coordenar suas atividades com as
de a, b e c.
e) Melhoria (7.3) conduzida por uma organizao
para o gerenciamento eficiente e automelhoria de
seu processo. Esta conduzida independentemente
do projeto ou requisitos do contrato.
B.4 Consideraes de adaptao e aplicao
Os pargrafos desta seo fornecem uma viso geral de
consideraes de adaptao e aplicao para as ca-
ractersticas chave do projeto. As consideraes e as ca-
ractersticas no so exaustivas e representam apenas a
forma atual de pensar. A figura B.1 fornece um exemplo
da aplicao desta Norma.
Polticas organizacionais. Determina quais polticas
organizacionais so relevantes e aplicveis, tais como:
linguagens de computador, proteo e segurana, re-
quisitos do hardware e gerenciamento de risco. As se-
es desta Norma, relacionadas com estas polticas
organizacionais, deveriam ser mantidas.
Estratgia de aquisio. Determina quais estratgias de
aquisio so relevantes e aplicveis para o projeto, tais
como: tipos de contrato, mais de um contratado, envol-
vimento de subcontratados e agentes de verificao e
validao, nvel de envolvimento do adquirente com os
contratados e avaliao da capacidade dos contratados.
As sees desta Norma, relacionadas com estas
estratgias, deveriam ser mantidas.
Conceito de suporte. Determina quais conceitos de
suporte so relevantes e aplicveis, tais como: durao
esperada de suporte, grau de alterao e se o suporte
ser fornecido pelo adquirente ou pelo fornecedor. Para
um produto de software que venha a ter uma vida longa
de suporte ou para o qual se espere mudanas signifi-
cativas, todos os requisitos de documentao deveriam
ser considerados. aconselhvel ter a documentao
automatizada.
Cpia no autorizada
30 NBR ISO/IEC 12207:1998
Modelo(s) de ciclo de vida. Determina qual(is) modelo(s)
de ciclo de vida (so) relevante(s) e aplicvel(is) para o
projeto, tais como cascata, evolucionrio, construtivo, in-
cremental e espiral. Todos estes modelos prescrevem
certos processos e atividades que podem ser executados
em seqncia, repetidamente e em combinao; nestes
modelos as atividades de ciclo de vida desta Norma
deveriam ser mapeadas para o(s) modelo(s) sele-
cionado(s). Para os modelos evolucionrio, construtivo e
incremental, os resultados de uma atividade do projeto
alimentam a prxima. Nestes casos, a documentao
deveria estar completa ao final de uma atividade ou tarefa.
Partes envolvidas. Determina ou identifica a quantidade
de pessoas e quais partes esto envolvidas no projeto,
tais como: adquirente, fornecedor, desenvolvedor,
subcontratado, agente de verificao, agente de vali-
dao, mantenedor. Todos os requisitos relacionados
com as interfaces organizacionais entre duas partes esto
sob considerao; por exemplo, adquirente com de-
senvolvedor, e fornecedor com agente de verificao ou
de validao. Um grande projeto envolvendo muitas
pessoas (dezenas ou centenas) necessita de significativa
superviso e controle gerenciais. Ferramentas, tais como:
avaliaes internas e independentes, revises, audito-
rias, inspees e coleta de dados so importantes para
um grande projeto. Para projetos pequenos, estes
controles podem ser excessivos.
Atividade de ciclo de vida de sistema. Determina quais
atividades correntes de ciclo de vida de sistema so
relevantes e aplicveis, tais como: incio do projeto pelo
adquirente; desenvolvimento pelo fornecedor e
manuteno. Alguns cenrios:
O adquirente est iniciando ou definindo os requisitos do
sistema. Estudos de viabilidade e prototipao de re-
quisitos e projeto podem ser conduzidos. Cdigo do
software para prottipos pode ser desenvolvido, o qual
pode ou no ser utilizado, mais tarde, no desenvolvimento
dos produtos de software realizado sob contrato.
Requisitos do sistema e requisitos preliminares do
software podem ser desenvolvidos. Nestes casos, o pro-
cesso de desenvolvimento (5.3) pode ser usado mais
como um guia do que como requisito; o rigor na qualifi-
cao e avaliao pode no ser necessrio; e revises
conjuntas e auditorias podem no ser necessrias.
O desenvolvedor est produzindo produtos de software
sob contrato. Neste caso todos os requisitos do processo
de desenvolvimento (5.3) deveriam ser considerados du-
rante a adaptao.
O mantenedor est modificando produtos de software.
O processo de manuteno (5.5) est sob considerao.
Partes do processo de desenvolvimento (seo 5.3)
podem ser usadas como miniprocessos.
Caractersticas do nvel de sistema. Determina quais as
caractersticas do nvel de sistema so relevantes e apli-
cveis, tais como: a quantidade de subsistemas e itens
de configurao. Se o sistema tiver muitos subsistemas
ou itens de configurao, o processo de desenvolvimento
(5.3) deveria ser cuidadosamente adaptado para cada
subsistema e item de configurao. Todos os requisitos
de interface e de integrao deveriam ser considerados.
Caractersticas do nvel de software. Determina quais as
caractersticas do nvel de software so relevantes e
aplicveis, tais como: quantidade de itens de software,
tipos, tamanho e criticabilidade dos produtos de software,
e riscos tcnicos. Se o produto de software tiver muitos
itens de software, componentes e unidades, o processo
de desenvolvimento (5.3) deveria ser cuidadosamente
adaptado para cada item de software. Todos os requisitos
de interface e de integrao deveriam ser considerados.
Determina quais tipos de produto de software esto
envolvidos, pois tipos diferentes de software podem
requerer diferentes decises de adaptao. Alguns
exemplos:
a) Novo desenvolvimento. Todos os requisitos,
particularmente o processo de desenvolvimento
(5.3), deveriam ser considerados
b) Uso de produto de software de prateleira na forma
em que se encontra. Todo o processo de desen-
volvimento (5.3) pode ser excessivo. Desempenho,
documentao, direitos de propriedade, de uso, de
autoria, de garantia e de licena e suporte futuro re-
lacionado ao produto de software, deveriam ser
avaliados.
c) Modificao do produto de software de prateleira.
A documentao pode no estar disponvel. De-
pendendo da criticabilidade e alteraes futuras
esperadas, o processo de desenvolvimento (5.3)
deveria ser utilizado via processo de manuteno
(5.5). Desempenho, documentao, direitos de pro-
priedade, de uso, de autoria, de garantia e de licena
e suporte futuro relacionado ao produto de software,
deveriam ser avaliados
d) Produto de software ou firmware embutido ou
integrado a um sistema. Desde que tal produto de
software uma parte de um sistema maior, as ativi-
dades relacionadas ao sistema no processo de de-
senvolvimento (5.3) deveriam ser consideradas e
determinado se sero executadas ou suportadas.
Se o produto de software ou firmware no tende a
ser modificado no futuro, necessidades de docu-
mentao extensa deveriam ser examinadas cui-
dadosamente.
e) Produto de software que independente. Desde
que tal produto de software no parte de um sis-
tema, as atividades relacionadas ao sistema no
processo de desenvolvimento (5.3) no necessitam
ser consideradas. As necessidades de documen-
tao, especialmente para manuteno, deveriam
ser examinadas cuidadosamente.
f) Produto de software que no ser entregue. J
que nenhum item est sendo adquirido, fornecido
ou desenvolvido, nenhuma proviso nesta Norma,
com exceo da atividade 5.3.1.5 no processo de
desenvolvimento (5.3), deveria ser considerada.
Entretanto, se o adquirente decide adquirir uma parte
deste produto de software para futura operao e
manuteno, ento este produto de software deveria
ser tratado como nos itens b) ou c), descritos ante-
riormente.
Cpia no autorizada
31
Outras consideraes
Quanto maior a dependncia do sistema em relao ao
prazo de entrega e operao correta do produto de
software, maior controle gerencial deveria ser imposto
via testes, revises, auditorias, verificao, validao e
outros. Por outro lado, um controle gerencial excessivo
para um produto de software no-crtico ou de pequeno
porte pode no ser apropriado em termos de custo.
O desenvolvimento do produto de software pode envolver
riscos tcnicos. Se a tecnologia de software utilizada no
estiver amadurecida, ou se o produto de software a ser
desenvolvido complexo e sem precedentes, ou se o
produto de software contm requisitos crticos de proteo,
segurana ou outros, ento, especificao, projeto, tes-
tes e avaliaes rigorosos podem ser necessrios. Veri-
ficao e validao independentes podem ser impor-
tantes.
/ANEXO C
O que Aquisio Fornecimento Desenvolvimento Operao Manuteno
Quem
Adquirente
Fornecedor
Desenvolvedor
Operadores
Manutenedores
Figura B.1 - Um exemplo de aplicao desta Norma
Requisitos
Legislao
Segurana
Proteo
Tempo
Normas de
processos
de ciclo de
vida de
software
Outras entradas
Cascata
Espiral
E
M
P
R
E
S
A
Mtodo
Ambiente
Capacidade
organizacional
Manual da qualidade
Procedimentos
Aplicao
Adaptao
Avaliao
Teste
ETC
Modelos e mtodos
Credenciais
(NBR 9001 ....)
Contrato
Plano de
qualidade
Plano de
projeto
Projeto
iniciado
Cpia no autorizada
32 NBR ISO/IEC 12207:1998
Anexo C (informativo)
Orientaes sobre processos e organizaes
Para proporcionar um melhor entendimento, este anexo
apresenta uma discusso sobre os processos, as orga-
nizaes e seus relacionamentos sob pontos de vista
relevantes.
C.1 Processos sob pontos de vista relevantes
Esta Norma contm os processos que so aplicveis ao
longo do ciclo de vida de software. Entretanto, estes
processos podem ser utilizados de diferentes formas, por
diferentes organizaes e partes, com diferentes vises
e objetivos. Esta seo apresenta os processos e seus
relacionamentos sob pontos de vista relevantes.
Ver 4.1.1 para sinopses dos processos.
A figura C.1 representa os processos de ciclo de vida de
software e seus relacionamentos sob diferentes vises
de utilizao desta Norma. As vises bsicas mostradas
so: contrato, gerncia, operao, engenharia e apoio.
Sob a viso de contrato, as partes adquirente e fornecedor
negociam e celebram um contrato, empregando respecti-
vamente o processo de aquisio e o processo de forneci-
mento. Sob a viso de gerncia, o adquirente, fornecedor,
desenvolvedor, operador, mantenedor ou outra parte,
gerencia seu respectivo processo. Sob a viso de opera-
o, o operador prov servio de operao de software
para os usurios. Sob a viso de engenharia, o desen-
volvedor ou mantenedor conduz suas respectivas tarefas
de engenharia para produzir ou modificar produtos de
software. Sob a viso de apoio, as partes (tais como ge-
rncia de configurao, garantia da qualidade) provem
servios de apoio a outros, atendendo s tarefas espe-
cficas. Tambm so mostrados os processos organi-
zacionais (veja o quadro em segundo plano); que so
empregados por uma organizao em nvel corporativo
para estabelecer, implementar e continuamente melhorar
uma estrutura subjacente constituda de processo(s) de
ciclo de vida e pessoal associado.
A figura C.2 apresenta os processos de ciclo de vida
fundamentais (no alto, quadro esquerdo), de apoio (no
alto, quadro direito) e organizacionais (quadro de baixo)
e os nomes de suas atividades constituintes sob diferentes
vises. Um numeral, prefixado a um processo, refere-se
ao nmero da seo nesta Norma.
A viso de contrato tem dois processos de ciclo de vida
(ver quadro sombreado no alto, dentro dos processos
fundamentais de ciclo de vida): um processo de aquisio
para o adquirente e um processo de fornecimento para o
fornecedor. Em cada processo so apresentadas suas
atividades. Esses processos definem as tarefas para o
adquirente e para o fornecedor, respectivamente, do ponto
de vista contratual.
A viso da engenharia tem dois processos de ciclo de
vida (ver o quadro sombreado mais abaixo esquerda,
dentro dos processos fundamentais de ciclo de vida): um
processo de desenvolvimento e um processo de manu-
teno. Em cada processo so apresentadas suas ativi-
dades. O processo de desenvolvimento empregado
por engenheiros de desenvolvimento para produzir
produtos de software. O processo de manuteno em-
pregado pelos engenheiros de manuteno para mo-
dificar o software e mant-lo atualizado.
A viso de operao tem um processo de ciclo de vida
(ver o quadro sombreado mais abaixo direita, dentro
dos processos fundamentais de ciclo de vida): um
processo de operao e suas respectivas atividades.
O processo de operao empregado para operar o
software para seus usurios.
A viso da gerncia da qualidade tem cinco processos
de ciclo de vida (ver o quadro sombreado dentro dos
processos de apoio de ciclo de vida): processo de garantia
da qualidade; processo de verificao; processo de vali-
dao; processo de reviso conjunta; e processo de au-
ditoria. Suas atividades constituintes no so mostradas.
Esses processos relacionados qualidade so empre-
gados para gerenciar qualidade ao longo do ciclo de
vida de software. Os processos de verificao, validao,
reviso conjunta e auditoria podem ser empregados se-
paradamente por diferentes partes e tambm como
tcnicas do processo de garantia da qualidade.
A viso de gerncia tem um processo (ver quadro som-
breado dentro dos processos organizacionais de ciclo
de vida): um processo de gerncia que utilizado por
qualquer organizao para gerenciar seu respectivo pro-
cesso. Suas atividades constituintes so apresentadas.
C.2 Processos, organizaes e relacionamentos
Os processos e organizaes (ou partes) se relacionam
apenas funcionalmente. Eles no impem uma estrutura
para uma organizao (ou uma parte).
Nesta Norma, os termos organizao e parte so
quase sinnimos. Uma organizao um grupo de pes-
soas organizado para um propsito especfico, como um
clube, sindicato, corporao ou sociedade. Quando uma
organizao, como um todo ou uma parte, celebra um
contrato, ela uma parte. Organizaes so entidades
separadas, mas as partes podem ser da mesma orga-
nizao ou de organizaes distintas.
Uma organizao ou uma parte denominada pelo pro-
cesso que executa. Por exemplo, chamada de adqui-
rente quando executa o processo de aquisio.
Uma organizao pode executar um ou mais processos;
um processo pode ser executado por uma ou mais orga-
nizaes. Sob um contrato ou aplicao desta Norma,
uma determinada parte no deveria executar ambos os
processos de aquisio e de fornecimento, mas pode
executar outros processos.
Cpia no autorizada
33
Nesta Norma, os relacionamentos entre os processos
so estticos. importante ressaltar que os relaciona-
mentos dinmicos e efetivos entre os processos, entre as
partes e entre os processos e as partes so estabelecidos
automaticamente quando a Norma aplicada nos projetos
de software. Cada processo (e a parte que o executa)
contribui para o projeto de software de sua maneira pr-
pria e nica. O processo de aquisio (e o adquirente)
contribui definindo o sistema, o qual conteria o produto
de software. O processo de fornecimento (e o fornecedor)
contribui provendo o produto de software ou servio do
qual aquele sistema dependeria.
O processo de desenvolvimento (e o desenvolvedor) con-
tribui examinando o sistema para uma correta definio do
produto de software, pelo desenvolvimento do produto de
software e pelo apoio integrao apropriada do produto
de software ao sistema. O processo de operao (e o ope-
rador) contribui operando o produto de software no am-
biente do sistema em benefcio dos usurios, do negcio,
e do objetivo do sistema. O processo de manuteno (e o
mantenedor) contribui mantendo e sustentando o produto
de software para adequao operacional e fornecendo
apoio e orientao aos usurios. Cada processo de apoio
ou organizacional contribui fornecendo funes especiali-
zadas para outros processos, quando necessrio.
Figura C.1 - Processos de ciclo de vida de software - Regras e relacionamentos
Viso de
contrato
. Adquirente
.Fornecedor
Viso de
gerncia
Gerente
Operador/
usurio
. Desenvolvedor
. Mantenedor
Encarregado
dos
processos
de
suporte
Processos organizacionais
. Infra-estrutura . Melhoria . Treinamento
Processos de apoio
Documentao Verificao
Gerncia de configurao Validao
Resoluo de problema Reviso conjunta
Garantia da qualidade Auditoria
emprega
emprega
emprega
emprega
Processo de
aquisio
Processo de
fornecimento
Processo de gerncia
Processo de operao
Processo de
manuteno
Processo de
desenvolvimento
emprega
emprega emprega emprega
emprega
Viso de
operao
Viso de
engenharia
Viso de
apoio
Cpia no autorizada
34 NBR ISO/IEC 12207:1998
A ordem de posio das atividades no significa ordem temporal.
Os nomes das atividades no processo de desenvolvimento no so os nomes das fases de desenvolvimento.
Figura C.2 - Processos, vises e atividades de ciclo de vida de software
/ANEXO D
Iniciao
Preparao de pedido
de proposta
Preparao e atualizao
do contrato
Monitorao do
fornecedor
Aceitao e
concluso
Iniciao
Preparao
de resposta
Contrato Planejamento
Execuo e
controle
Reviso e
avaliao
Entrega e
concluso
Implementao
do processo
Anlise de
requisitos
do sistema
Codificao e
integrao do
software
Teste
operacional
Suporte ao
usurio
Migrao
Projeto da
arquitetura
do sistema
Anlise de
requisitos
do software
Projeto da
arquitetura
dosoftware
Projeto
detalhado
do software
Integrao
do software
Teste de
qualificao
do software
Integrao
do sistema
Teste de
qualificao
do sistema
Instalao
do software
Apoio
aceitao
do software
Implementao
do processo
Operao
do sistema
Anlise dos
problemas e
da modificao
Reviso/
aceitao da
manuteno
Implementao
do processo
Implementao
da modificao
Descontinuao
do software
6.1 Processo de
documentao
6.2 Processo de
gerncia de
configurao
6.3 Processo de
garantia da
qualidade
6.4 Processo de
verificao
6.5 Processo de
validao
6.6 Processo de
reviso
conjunta
6.7 Processo de
auditoria
6.8 Processo de
resoluo de
problema
5. Processos fundamentais de ciclo de vida 6. Processos de apoio
de ciclo de vida
Iniciao e
definio do
escopo
Execuo e
controle
Planejamento
Reviso e
avaliao
Concluso
Estabelecimento do
processo
Avaliao do processo Melhoria do processo
7. Processos organizacionais de ciclo de vida
VViis soo ddee ggeer r n ncciiaa d daa
qqu ua alli idda addee
VVi i s so o d dee o oppe erra a o o VVi i s s o o d dee een ng geen nh haar ri i a a
VVi i s s o o d dee cco onnt trra at t o o
Cpia no autorizada
35
Anexo D (informativo)
Bibliografia
NBR ISO/IEC 12119:1994, Tecnologia de informao -
Pacotes de software - Teste e requisitos de qualidade
Cpia no autorizada

NBR Iso 12207

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

NBR Iso 12207

Загружено:

Авторское право:

Доступные форматы

Copyright 1998,

Вам также может понравиться