ISO/IEC 12207 – 2008
configuração recomendações e alinhamento com outras normas aplicáveis.
International Standard ISO/IEC 12207:2008(E)
A ISO (Organização Internacional para Padronização) e a IEC (Comissão Eletrotécnica
Internacional) formam o sistema especializado para padronização mundial. Organismos
nacionais que são membros da ISO ou IEC participam no desenvolvimento de Normas
Internacionais através de comitês técnicos estabelecidos pela respectiva organização para lidar
com campos específicos da atividade técnica. Os comitês técnicos ISO e IEC colaboram em áreas
de interesse mútuo. Outras organizações internacionais, governamentais e não-governamentais,
em ligação com a ISO e a IEC, também participam do trabalho. No campo da tecnologia da
informação, a ISO e a IEC estabeleceram um Comitê Técnico, ISO / IEC JTC 1. As Normas
Internacionais são elaboradas de acordo com as regras estabelecidas nas Diretrizes da ISO / IEC,
Parte 2. A principal tarefa do comitê técnico conjunto é preparar Normas Internacionais. As
normas internacionais adotadas pelo comitê técnico conjunto são distribuídas aos órgãos
nacionais para votação. A publicação como uma norma internacional requer a aprovação de pelo
menos 75% dos órgãos nacionais que votam. Chama-se a atenção para a possibilidade de que
alguns dos elementos deste documento possam ser objeto de direitos de patente. A ISO e a IEC
não serão responsáveis por identificar qualquer ou todos os direitos de patente. A ISO / IEC 12207
foi preparada pelo Comitê Técnico Conjunto ISO / IEC JTC 1, Tecnologia da Informação, Subcomitê
SC 7, Software e engenharia de sistemas.
Esta segunda edição cancela e substitui a primeira edição (ISO / IEC 12207: 1995), que foi
tecnicamente revisada. Incorpora também as Emendas ISO / IEC 12207: 1995 / Amd.1: 2002 e
ISO / IEC 12207: 1995 / Amd.2: 2004. As alterações nesta revisão da ISO / IEC 12207 foram
desenvolvidas em conjunto com uma revisão correspondente da ISO / IEC 15288. O objetivo
dessas revisões é alinhar melhor as duas Normas Internacionais para facilitar seu uso conjunto.
Esse alinhamento é o primeiro passo em direção à harmonização das estruturas e conteúdos das
duas Normas Internacionais, ao mesmo tempo em que apóia os requisitos da comunidade
avaliadora. Esse alinhamento fornece a base para facilitar a evolução para um tratamento
integrado e totalmente harmonizado dos processos do ciclo de vida. Esta Norma Internacional
foi desenvolvida com os seguintes objetivos:
⎯ incorporar e racionalizar ambas as alterações;
⎯ fornecer uma terminologia comum entre a revisão da ISO / IEC 15288 e ISO / IEC 12207;
⎯ quando aplicável, fornecer nomes de processos comuns e estrutura do processo entre a revisão
da ISO / IEC 15288 e esta Norma Internacional;
⎯ permitir que a comunidade de usuários evolua para padrões totalmente harmonizados e
forneça um padrão estável, enquanto maximiza a compatibilidade com versões anteriores; e
⎯ alavancar dez anos de experiência com o desenvolvimento e uso de ISO / IEC 12207 e ISO / IEC
15288. Uma revisão subsequente destina-se a obter uma visão totalmente harmonizada do
sistema e dos processos de ciclo de vida de software. As áreas identificadas a serem abordadas
no futuro incluem: finalidades e resultados de processos comuns, arquitetura dos padrões, nível
de prescrição de atividades e tarefas, tratamentos de ciclo de vida, tratamento de produtos e
serviços, conceitos comuns de verificação e validação, conceitos comuns de gerenciamento de
A IEEE Computer Society colaborou com a ISO / IEC JTC 1 no desenvolvimento desta Norma
Internacional. IEEE / EIA 12207.0-1996, Implementação Industrial da Norma Internacional ISO /
IEC 12207: 1995 Padrão para Tecnologia da Informação - Processos de Ciclo de Vida de Software,
foi um dos documentos básicos utilizados no desenvolvimento desta Norma Internacional.
Os documentos dos Padrões IEEE são desenvolvidos dentro das Sociedades do IEEE e dos Comitês
de Coordenação de Padrões do Conselho de Normas da IEEE-SA (IEEE-SA). O IEEE desenvolve seus
padrões por meio de um processo de desenvolvimento de consenso, aprovado pelo American
National Standards Institute, que reúne voluntários representando diversos pontos de vista e
interesses para alcançar o produto final. Voluntários não são necessariamente membros do
Instituto e servem sem compensação. Enquanto o IEEE administra o processo e estabelece regras
para promover a justiça no processo de desenvolvimento de consenso, o IEEE não avalia, testa
ou verifica de forma independente a precisão de qualquer informação contida em seus padrões.
O uso de um padrão IEEE é totalmente voluntário. O IEEE isenta-se da responsabilidade por
qualquer dano pessoal, propriedade ou outro dano, de qualquer natureza, seja especial, indireta,
conseqüente ou compensatória, direta ou indiretamente resultante da publicação, uso ou
confiança neste ou em qualquer outro Padrão do IEEE. O IEEE não garante ou representa a
exatidão ou o conteúdo do material aqui contido e se isenta expressamente de qualquer garantia
expressa ou implícita, incluindo qualquer garantia implícita de comerciabilidade ou adequação a
uma finalidade específica, ou de que o uso do material aqui contido está livre de violação de
patente. Os documentos dos Padrões IEEE são fornecidos “COMO ESTÃO”. A existência de um
Padrão IEEE não implica que não haja outras maneiras de produzir, testar, medir, comprar,
comercializar ou fornecer outros bens e serviços relacionados ao escopo do Padrão IEEE. . Além
disso, o ponto de vista expresso no momento em que uma norma é aprovada e emitida está
sujeito a alterações nos desenvolvimentos do estado da técnica e comentários recebidos dos
usuários da norma. Cada Padrão IEEE é sujeito a revisão pelo menos a cada cinco anos para
revisão ou reafirmação. Quando um documento tem mais de cinco anos e não foi reafirmado, é
razoável concluir que seu conteúdo, embora ainda tenha algum valor, não reflete totalmente o
atual estado da arte. Os usuários são alertados para verificar se eles têm a edição mais recente
de qualquer padrão IEEE.
Ao publicar e disponibilizar este documento, o IEEE não está sugerindo ou prestando serviços
profissionais ou outros para, ou em nome de, qualquer pessoa ou entidade. Tampouco é a
empresa IEEE para executar qualquer dever devido por qualquer outra pessoa ou entidade para
outro. Qualquer pessoa que utilize este documento e qualquer outro documento normativo do
IEEE deve confiar no conselho de um profissional competente para determinar o exercício de um
cuidado razoável em quaisquer circunstâncias. Interpretações: Ocasionalmente, podem surgir
questões relativas ao significado de partes de padrões, na medida em que elas se relacionam
com aplicações específicas. Quando a necessidade de interpretações for trazida à atenção do
IEEE, o Instituto iniciará ações para preparar respostas apropriadas. Como os Padrões IEEE
representam um consenso de interesses preocupados, é importante garantir que qualquer
interpretação também tenha recebido a concordância de um equilíbrio de interesses. Por essa
razão, o IEEE e os membros de suas sociedades e os Comitês de Coordenação de Normas não são
capazes de fornecer uma resposta instantânea aos pedidos de interpretação, exceto nos casos
em que o assunto tenha recebido anteriormente uma consideração formal. Em palestras,
simpósios, seminários ou cursos educacionais, um indivíduo que apresenta informações sobre os
padrões do IEEE deve deixar claro que suas opiniões devem ser consideradas as visões pessoais
daquele indivíduo, em vez da posição, explicação ou interpretação formal do IEEE. Comentários
para revisão dos Padrões IEEE são bem-vindos de qualquer parte interessada,
independentemente da afiliação do IEEE. Sugestões para mudanças em documentos devem ser
na forma de uma proposta de mudança de texto, juntamente com comentários de apoio
apropriados. Comentários sobre normas e pedidos de interpretação devem ser endereçados a:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854
USA
A autorização para fotocopiar partes de qualquer padrão individual para uso interno ou pessoal
é concedida pelo Instituto de Engenheiros Elétricos e Eletrônicos, Inc., desde que a taxa
apropriada seja paga ao Copyright Clearance Center. Para providenciar o pagamento da taxa de
licenciamento, entre em contato com o Centro de Liberação de Direitos Autorais, Atendimento
ao Cliente, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. A permissão para
fotocopiar porções de qualquer padrão individual para uso educacional em sala de aula também
pode ser obtida através do Copyright Authorance Center.
Introdução
O ISO / IEC 12207 foi publicado em 1 de agosto de 1995 e foi o primeiro Padrão Internacional a
fornecer um conjunto abrangente de processos, atividades e tarefas do ciclo de vida para
software que faz parte de um sistema maior e para produtos e serviços de software autônomos.
Essa norma internacional foi seguida em novembro de 2002 pela ISO / IEC 15288, que tratava
dos processos do ciclo de vida do sistema. A onipresença do software significa que o software e
seus processos de design não devem ser considerados separadamente desses sistemas, mas
devem ser considerados como parte integrante dos processos de projeto do sistema e do
sistema. As alterações da ISO / IEC 12207 em 2002 e 2004 adicionaram a finalidade e os
resultados do processo à Norma Internacional e estabeleceram um Modelo de Referência do
Processo de acordo com os requisitos da ISO / IEC 15504-2. Esta Norma Internacional, uma
revisão da ISO / IEC 12207 alterada, é um passo inicial na estratégia de harmonização do SC7 para
alcançar um conjunto totalmente integrado de processos de ciclo de vida de sistemas e software
e orientação para sua aplicação. Esta revisão integra a ISO / IEC 12207: 1995 com suas duas
alterações e aplica as diretrizes do SC7 para a definição de processos para dar suporte à
consistência e melhor usabilidade. A execução do projeto foi cuidadosamente coordenada com
a revisão paralela da ISO / IEC 15288: 2002 para alinhar estrutura, termos e correspondentes
processos organizacionais e de projeto. Este Padrão Internacional pode ser usado em um ou mais
dos seguintes modos:
⎯ Por uma organização - para ajudar a estabelecer um ambiente de processos desejados. Esses
processos podem ser suportados por uma infraestrutura de métodos, procedimentos, técnicas,
ferramentas e pessoal treinado. A organização pode, então, empregar esse ambiente para
executar e gerenciar seus projetos e sistemas de progresso em seus estágios do ciclo de vida.
Neste modo, esta Norma é usada para avaliar a conformidade de um conjunto declarado e
estabelecido de processos de ciclo de vida às suas provisões.
⎯ Por um projeto - para ajudar a selecionar, estruturar e empregar os elementos de um conjunto
estabelecido de processos de ciclo de vida para fornecer produtos e serviços. Neste modo, esta
Norma é utilizada na avaliação da conformidade do projeto com o ambiente declarado e
estabelecido.
⎯ Por um adquirente e um fornecedor - para ajudar a desenvolver um acordo sobre processos e
atividades. Por meio do acordo, os processos e atividades desta Norma Internacional são
selecionados, negociados, acordados e executados. Neste modo, esta Norma é usada para
orientação no desenvolvimento do acordo.
⎯ Por organizações e assessores - para realizar avaliações que podem ser usadas para apoiar a
melhoria do processo organizacional.
Esta Norma contém requisitos em quatro Cláusulas: Cláusula 6, que define os requisitos para os
processos do ciclo de vida do sistema, Cláusula 7, que define os requisitos para processos de ciclo
de vida de software específicos, cláusulas do Anexo A, que fornece requisitos para adaptação
desta Norma e cláusulas do Anexo B, que fornece um Modelo de Referência de Processo (PRM)
que pode ser usado para fins de avaliação. Cinco anexos informativos apoiam a estratégia de
harmonização iniciada por esta revisão.
⎯ O Anexo C amplia a história e a justificativa para as mudanças e fornece rastreabilidade de alto
nível entre as Normas Internacionais que foram usadas como entradas para esta revisão.
⎯ O Anexo D descreve o alinhamento dos processos da ISO / IEC 15288 e ISO / IEC 12207 - um
foco importante desta revisão.
⎯ O Anexo E fornece um exemplo de uma visão de processo para Usabilidade, destinada a ilustrar
como um projeto pode reunir processos, atividades e tarefas da ISO / IEC 12207 para fornecer
atenção focada à obtenção de características do produto que foram selecionadas como sendo
de interesse especial.
⎯ O Anexo F contém alguns exemplos de descrições de processos que são considerados úteis
para alguns leitores desta Norma.
⎯ O Anexo G fornece suporte para usuários do IEEE e descreve os relacionamentos deste
Padrão Internacional com os padrões do IEEE. Recomenda-se aos leitores desta Norma que
consultem a Cláusula 5 para entender os principais conceitos usados.
NOTA Um Relatório Técnico futuro (ISO / IEC TR 24748) descreverá as relações entre esta
Norma Internacional e a ISO / IEC 15288: 2008.
Introdução IEEE
Esta introdução não faz parte do IEEE Std 12207 ™ -2008, Engenharia de Sistemas e Software -
Processos de Ciclo de Vida de Software. IEEE Std 12207 ™ -2008 e IEEE Std 15288 ™ -2008 são
idênticos aos ISO / IEC 12207: 2008 e ISO / IEC 15288: 2008. Portanto, todas as referências à ISO
/ IEC 12207 ou ISO / IEC 15288 aplicam-se igualmente bem às suas contrapartes IEEE. Maiores
detalhes sobre os relacionamentos com os padrões do IEEE podem ser encontrados no Anexo G.
Esta norma substitui a norma IEEE / EIA 12207.0-1996, Implementação Industrial da Norma
Internacional ISO / IEC 12207: 1995 para Tecnologia da Informação - Processos de Ciclo de Vida
de Software, que foi uma adoção com alterações da ISO / IEC 12207: 1995. Os usuários do padrão
anterior podem estar interessados em saber o que acontecerá com seus acompanhantes, IEEE /
EIA 12207.1-1996 e IEEE / EIA 12207.2-1997. Atualmente, há um projeto em andamento para
substituir o IEEE / EIA 12207.1 pela adoção da ISO / IEC 15289. A conclusão do projeto atual
tornará o IEEE / EIA 12207.2 obsoleto; provavelmente será retirada a menos que haja uma
demonstração de interesse para revisá-lo. O ISO / IEC 12207 original foi publicado em 1 de agosto
de 1995 e foi o primeiro padrão internacional a fornecer um conjunto abrangente de processos,
atividades e tarefas do ciclo de vida para software que faz parte de um sistema maior e para
produtos e serviços de software autônomos. Esse padrão internacional foi seguido em novembro
de 2002 pela ISO / IEC 15288, que abordava os processos do ciclo de vida do sistema.
O IEEE cooperou com a Electronic Industries Alliance (EIA) na adoção da ISO / IEC com mudanças
para se tornar IEEE / EIA 12207-1996. Em 2004, o IEEE realizou uma adoção idêntica da ISO / IEC
15288: 2002. As emendas ISO / IEC 12207 em 2002 e 2004 adicionaram a finalidade e os
resultados do processo à Norma Internacional e estabeleceram um Modelo de Referência de
Processo de acordo com os requisitos da ISO / IEC 15504-2. O IEEE não selecionou essas
alterações, preferindo uma base estável para os usuários de seu padrão. Esta nova revisão da ISO
/ IEC 12207 é o produto de um esforço coordenado pelo IEEE e ISO / IEC JTC 1 / SC 7. Os
documentos base para a revisão incluíram o padrão ISO / IEC e suas emendas, e o padrão IEEE /
EIA e seu material exclusivo. Esta revisão integra a ISO / IEC 12207: 1995 com suas duas alterações
e aplica as diretrizes do SC7 para a definição de processos para dar suporte à consistência e
melhor usabilidade. A execução do projeto foi cuidadosamente coordenada com a revisão
paralela da ISO / IEC 15288: 2002 para alinhar estrutura, termos e correspondentes processos
organizacionais e de projeto.
1. Visão Geral
1.1 Escopo
Esta Norma estabelece uma estrutura comum para processos de ciclo de vida de software, com
terminologia bem definida, que pode ser referenciada pela indústria de software. Ele contém
processos, atividades e tarefas que devem ser aplicadas durante a aquisição de um produto ou
serviço de software e durante o fornecimento, desenvolvimento, operação, manutenção e
descarte de produtos de software. O software inclui a parte de software do firmware. Esta Norma
aplica-se à aquisição de sistemas e produtos e serviços de software, ao fornecimento,
desenvolvimento, operação, manutenção e descarte de produtos de software e à parte de
software de um sistema, seja ele feito internamente ou externamente a uma organização. Esses
aspectos da definição do sistema necessários para fornecer o contexto para produtos e serviços
de software estão incluídos. Esta Norma Internacional também fornece um processo que pode
ser empregado para definir, controlar e melhorar os processos do ciclo de vida do software. Os
processos, atividades e tarefas desta Norma - seja sozinhos ou em conjunto com a ISO / IEC 15288
- também podem ser aplicados durante a aquisição de um sistema que contenha software.
1.2 Propósito
O objetivo desta Norma Internacional é fornecer um conjunto definido de processos para facilitar
a comunicação entre adquirentes, fornecedores e outras partes interessadas no ciclo de vida de
um produto de software. Esta Norma é escrita para adquirentes de produtos e serviços de
sistemas e software e para fornecedores, desenvolvedores, operadores, mantenedores,
gerentes, gerentes de garantia de qualidade e usuários de produtos de software. Esta Norma se
destina ao uso em uma situação de duas partes e pode ser igualmente aplicada quando as duas
partes são da mesma organização. A situação pode variar desde um acordo informal até um
contrato juridicamente vinculativo. o A Norma Internacional pode ser usada por uma única parte
através de um conjunto de processos auto-impostos. Esta cláusula não impede o uso da ISO / IEC
12207 por fornecedores ou desenvolvedores de software pronto para uso.
1.3 Limitações
Esta Norma não detalha os processos do ciclo de vida em termos de métodos ou procedimentos
necessários para atender aos requisitos e resultados de um processo. Esta Norma não detalha a
documentação em termos de nome, formato, conteúdo explícito e mídia de gravação. A Norma
Internacional pode exigir o desenvolvimento de documentos de classe ou tipo similar; vários
planos são um exemplo. A Norma Internacional, entretanto, não implica que tais documentos
sejam desenvolvidos ou embalados separadamente ou combinados de alguma forma. Essas
decisões são deixadas para o usuário do Padrão Internacional. NOTA A ISO / IEC 15289 aborda o
conteúdo dos itens de informação do processo de ciclo de vida (documentação). Esta Norma não
prescreve um modelo específico de sistema ou modelo de ciclo de vida de software, metodologia
de desenvolvimento, método, modelo ou técnica. As partes da Norma Internacional são
responsáveis por selecionar um modelo de ciclo de vida para o projeto de software e mapear os
processos, atividades e tarefas desta Norma nesse modelo. As partes também são responsáveis
por selecionar e aplicar os métodos de desenvolvimento de software e por executar as atividades
e tarefas adequadas ao projeto de software. Esta Norma não se destina a entrar em conflito com
as políticas, procedimentos e padrões de qualquer organização ou com quaisquer leis e
regulamentos nacionais. Qualquer conflito desse tipo deve ser resolvido antes de usar este
Padrão Internacional.
2 Conformidade
2.1 Uso pretendido
Os requisitos desta Norma Internacional estão contidos nas Cláusulas 6 e 7 e no Anexo A. Esta
Norma Internacional fornece requisitos para vários processos adequados para uso durante o ciclo
de vida de um produto ou serviço de software. É reconhecido que determinados projetos ou
organizações podem não precisar usar todos os processos fornecidos por esta Norma. Portanto,
a implementação desta Norma normalmente envolve a seleção de um conjunto de processos
adequados à organização ou projeto. Existem duas maneiras pelas quais uma implementação
pode ser reivindicada em conformidade com as provisões desta Norma. Qualquer reivindicação
de conformidade é citada em apenas uma das duas formas abaixo.
2.2 Conformidade total
Uma reivindicação de conformidade total declara o conjunto de processos para os quais a
conformidade é reivindicada. A plena conformidade é obtida demonstrando que todos os
requisitos do conjunto declarado de processos foram satisfeitos usando os resultados como
evidência.
2.3 Conformidade sob medida
Quando esta Norma é usada como base para estabelecer um conjunto de processos que não se
qualificam para total conformidade, as cláusulas desta Norma são selecionadas ou modificadas
de acordo com o processo de adaptação prescrito no Anexo A. O texto personalizado, para o qual
conformidade sob medida é reivindicada, é declarada. Conformidade sob medida é obtida
demonstrando que os requisitos para os processos, conforme adaptados, foram satisfeitos
usando os resultados como evidência.
NOTA 1 Quando esta Norma é usada para ajudar a desenvolver um acordo entre um adquirente
e um fornecedor, cláusulas desta Norma Internacional podem ser selecionadas para
incorporação no contrato com ou sem modificação. Neste caso, é mais apropriado para o
adquirente e fornecedor reivindicar a conformidade com o acordo do que a conformidade com
esta Norma.
NOTA 2 Qualquer organização (por exemplo, associação industrial nacional, empresa) que
imponha esta Norma, como uma condição de comércio, deve especificar e tornar público o
conjunto mínimo de processos, atividades e tarefas requeridos, que constituem a conformidade
dos fornecedores com este padrão. Padrão internacional.
NOTA 3 Os requisitos desta Norma Internacional são marcados pelo uso do verbo "deve". As
recomendações são marcadas pelo uso do verbo "deveria". As permissões são marcadas pelo uso
do verbo "may".
5 Aplicação desta Norma Internacional
Esta cláusula apresenta uma visão geral dos processos do ciclo de vida do software que podem
ser empregados para adquirir, fornecer, desenvolver, operar, manter e descartar produtos e
serviços de software. O objetivo é fornecer um roteiro para os usuários desta Norma para que
eles possam se orientar e aplicá-la criteriosamente.
5.1 Principais conceitos desta Norma Internacional
Esta subcláusula introduz conceitos-chave úteis na leitura e aplicação deste Padrão Internacional.
Em alguns casos, palavras comumente usadas são usadas de maneira especial nesta Norma
Internacional. Esta subcláusula também descreverá esses usos especiais. Uma elaboração mais
detalhada desses conceitos pode ser encontrada na ISO / IEC TR 15271, Guia para a aplicação dos
processos do ciclo de vida do software ISO / IEC 12207.
NOTA Um relatório técnico futuro (ISO / IEC TR 24748, Guia para gerenciamento do ciclo de vida)
também fornecerá mais detalhes.
5.1.1 Relacionamento de produtos de software e serviços de software
Em geral, esta Norma se aplica a produtos de software e serviços de software. As disposições de
processos específicos indicam sua aplicabilidade.
NOTA A ISO / IEC 20000 fornece processos, requisitos e orientação para provedores de serviços
para a entrega de serviços gerenciados.
5.1.2 Relação entre sistemas e software
Esta Norma estabelece uma forte ligação entre um sistema e seu software. Baseia-se nos
princípios gerais da engenharia de sistemas. O software é tratado como parte integrante do
sistema total e executa determinadas funções nesse sistema. Isso é implementado extraindo os
requisitos de software dos requisitos do sistema e do design, produzindo o software e
integrando-o ao sistema. É uma premissa fundamental deste padrão que o software sempre
exista no contexto de um sistema, mesmo se o sistema consistir apenas no processador no qual
o software é executado. Portanto, um produto ou serviço de software é sempre tratado como
um item em um sistema. Por exemplo, o padrão faz uma distinção entre análise de requisitos do
sistema e análise de requisitos de software, porque, no caso geral, o projeto de arquitetura do
sistema alocará os requisitos do sistema a vários itens do sistema e a análise de requisitos de
software derivará os requisitos do software.
requisitos do sistema alocados para cada item de software. É claro que, em alguns casos, os itens
que não são de software de um sistema podem ser tão mínimos que pode não ser necessário
realizar análises distintas de sistema e software. Esta norma tem uma forte relação com a ISO /
IEC 15288: 2008, Processos do Ciclo de Vida do Sistema e pode ser usada em conjunto com ela.
Em muitos casos, os processos desta Norma correspondem diretamente aos processos da ISO /
IEC 15288, mas com alguma especialização para produtos e serviços de software. Um exemplo
notável é que o processo de Implementação de Software deste padrão é uma especialização -
uma especialização detalhada - do Processo de Implementação da ISO / IEC 15288.
No caso em que o sistema possui importantes elementos que não sejam de software, uma
organização pode desejar aplicar a ISO / IEC 15288 para fornecer os processos de ciclo de vida
apropriados. Para cada elemento de software do sistema, a organização aplicaria o Processo de
Implementação de Software deste padrão para criar o elemento de software.
No caso em que as partes sem software do sistema são mínimas, uma organização pode desejar
aplicar este padrão sem referência à ISO / IEC 15288. Este padrão contém o processo adicional
no nível do sistema - embora especializado para as necessidades do software - para fornecer o
contexto de sistema mínimo apropriado para o software. Ao aplicar este padrão em conjunto
com a ISO / IEC 15288, uma pequena divergência na terminologia deve ser considerada. A ISO /
IEC 15288 decompõe um sistema em um conjunto de "elementos" do sistema. Alguns desses
elementos podem ser determinados como produtos de software a serem implementados usando
esse padrão. Este padrão usa o termo "item" para se referir a um elemento principal do sistema.
Em resumo, este padrão usa o termo "item" onde a ISO / IEC 15288 usaria o termo "elemento de
software".
Alguns dos itens podem eventualmente ser designados como sujeitos ao gerenciamento de
configuração; eles são chamados de "itens de configuração". O Processo de Projeto de
Arquitetura de Software transforma itens em "componentes" e o Processo de Design Detalhado
de Software refina os componentes em "unidades".
5.1.3 Organizações e partidos
Neste padrão, os termos "organização" e "parte" estão intimamente relacionados. Uma
organização é um grupo de pessoas com responsabilidades e autoridades identificadas
organizadas para algum propósito específico, como clube, sindicato, corporação ou sociedade.
Quando uma organização, como um todo ou uma parte, celebra um contrato, é uma festa. As
partes podem ser da mesma organização ou de organizações separadas. Um indivíduo é um
exemplo de organização, se o indivíduo tiver responsabilidades e autoridades atribuídas. Uma
organização ou partido recebe seu nome do processo pelo qual é responsável. Por exemplo, ele
é chamado de adquirente quando executa o processo de aquisição. Portanto, quando os termos
a seguir são usados neste padrão, eles não têm seu significado genérico, mas referem-se à
organização ou parte responsável pela execução do processo com um nome semelhante:
adquirente, fornecedor, implementador, mantenedor e operador. Alguns outros termos são
aplicados a organizações nesta norma: "usuário" pode ser a organização que se beneficia da
utilização do produto ou serviço de software; "cliente" refere-se ao usuário e ao adquirente
coletivamente; e "stakeholder" refere-se a uma organização com interesse no sucesso do
projeto. Os processos e organizações (ou partes) são relacionados apenas funcionalmente. A
norma não dita ou implica uma estrutura para uma organização (ou parte). Os processos neste
padrão formam um conjunto abrangente para atender a várias organizações. Uma organização,
pequena ou grande, dependendo do propósito de negócios ou da estratégia de aquisição, pode
selecionar um conjunto apropriado de processos (e atividades e tarefas associadas) para cumprir
esse propósito. Uma organização pode executar um processo ou mais de um processo. Sob um
contrato ou aplicação desta norma, uma determinada parte não deve executar tanto o Processo
de Aquisição quanto o Processo de Fornecimento, mas pode executar outros processos. Um
processo pode ser executado por uma organização ou mais de uma organização. Um exemplo de
um processo realizado por mais de uma organização é o processo de Revisão de Software. Esta
norma destina-se a ser aplicada por uma organização interna ou externamente por duas ou mais
organizações.
Quando aplicadas internamente, as duas partes concordantes normalmente agem sob os termos
de um acordo que pode variar em formalidade sob diferentes circunstâncias. Quando aplicadas
externamente, as duas partes concordantes agem normalmente sob os termos de um contrato.
Para facilitar a aplicação desta norma, seja interna ou contratualmente, as tarefas são expressas
em linguagem contratual. Quando aplicada internamente, a linguagem contratual deve ser
interpretada como disciplina auto-imposta. Para o propósito desta norma, qualquer projeto é
assumido como sendo conduzido dentro do contexto de uma organização. Isso é importante
porque um projeto de software depende de vários resultados produzidos pelos processos de
negócios da organização, por exemplo, funcionários para contratar o projeto e instalações para
abrigar o projeto. Para este propósito, este padrão fornece um conjunto de processos
“Organizational Project-Enabling”. Esses processos não são considerados adequados para operar
um negócio, e nenhum Processo de Projeto individual é assumido como completamente
definido. Em vez disso, os processos, considerados como uma coleção, destinam-se a declarar o
conjunto mínimo de dependências que o projeto coloca na organização.
5.1.4 Adopção ao nível da organização e do projecto
Empresas modernas de software se esforçam para desenvolver um conjunto robusto de
processos de ciclo de vida de software que são aplicados repetidamente aos projetos de software
da empresa. Portanto, esse padrão deve ser útil para adoção no nível da organização ou no nível
do projeto. Uma organização adotaria o padrão e o suplementaria com procedimentos, práticas,
ferramentas e políticas apropriados. Um projeto de software da organização normalmente
estaria em conformidade com os processos da organização, em vez de se ajustar diretamente a
esse padrão. Em alguns casos, os projetos podem ser executados por uma organização que não
possui um conjunto adequado de processos adotados no nível organizacional. Tal projeto pode
aplicar as provisões desta norma diretamente ao projeto.
5.1.5 Adaptação
O Anexo A, que é normativo, define as atividades básicas necessárias para realizar a adaptação
desta Norma. Deve-se notar que a adaptação pode diminuir o valor percebido de uma
reivindicação de conformidade com este padrão. Isso ocorre porque é difícil para outras
organizações entenderem até que ponto a adaptação pode ter excluído as disposições
desejáveis. Uma organização que defende uma reivindicação de conformidade de uma única
parte a esse padrão pode achar vantajoso reivindicar conformidade absoluta com uma lista
menor de processos, em vez de atender a uma lista maior de processos.
5.1.6 Relações temporais entre os processos
Neste padrão, os processos e suas atividades e tarefas são organizados em uma seqüência
adequada para exposição. Esta sequência posicional não prescreve ou determina qualquer
sequência dependente do tempo. Por falta de consenso ou uso de uma sequência universal
dependente do tempo, o usuário deste padrão pode selecionar e ordenar os processos,
atividades e tarefas conforme apropriado e eficaz. Essa norma estimula a interação entre as
atividades e a recursão em uma atividade para compensar os efeitos de qualquer sequência
implícita de atividades e tarefas. As partes deste padrão são responsáveis por selecionar um
modelo de ciclo de vida para o projeto e mapear os processos, atividades e tarefas para esse
modelo.
5.1.7 Avaliação versus verificação e validação
Organizações envolvidas em qualquer processo do ciclo de vida conduzem avaliações dos
produtos dessa tarefa.
Os processos de Verificação de Software e Validação de Software oferecem a oportunidade de
avaliações adicionais.
Esses processos são conduzidos pelo adquirente, pelo fornecedor ou por uma parte
independente para verificar e validar os produtos em profundidades variadas, dependendo do
projeto. Essas avaliações não duplicam ou substituem outras avaliações, mas as complementam.
Oportunidades adicionais para avaliação são fornecidas pela Análise de Software, Auditoria de
Software, Garantia de Qualidade de Software e os Processos de Gerenciamento de Modelo de
Ciclo de Vida.
5.1.8 Critérios para processos
Este padrão estabelece uma estrutura para o ciclo de vida do software. O ciclo de vida começa
com uma ideia ou uma necessidade que pode ser satisfeita total ou parcialmente por software e
termina com a retirada do software. A arquitetura é construída com um conjunto de processos
e inter-relações entre esses processos. A determinação dos processos do ciclo de vida baseia-se
em dois princípios básicos: coesão e responsabilidade.
Coesão: Os processos do ciclo de vida são coesos e acoplados à extensão ideal
considerada prática e viável.
Responsabilidade: Um processo é colocado sob a responsabilidade de uma
organização ou de uma parte no ciclo de vida do software.
5.1.9 Descrição dos processos
Os processos desta norma são descritos de maneira semelhante à ISO / IEC 15288, a fim de
facilitar o uso de ambos os padrões em uma única organização ou projeto. Cada processo deste
padrão é descrito em termos dos seguintes atributos:
⎯ O título transmite o escopo do processo como um todo
⎯ O objetivo descreve os objetivos de realizar o processo
⎯ Os resultados expressam os resultados observáveis esperados do desempenho bem-sucedido
do processo
⎯ As atividades são uma lista de ações que são usadas para alcançar os resultados
⎯ As tarefas são requisitos, recomendações ou ações permitidas destinadas a apoiar a obtenção
dos resultados.
Detalhes adicionais sobre essa forma de descrição podem ser encontrados em ISO / IEC 24774,
Engenharia de Sistemas e Software - Gerenciamento do Ciclo de Vida - Diretrizes para definição
de processos.
5.1.10 Características gerais dos processos
Os atributos descritos na subcláusula 5.1.9 caracterizam a especificidade de cada processo.
Quando um processo implementado está em conformidade com esses atributos, a finalidade e
os resultados especificamente definidos do processo são alcançados por meio da implementação
de suas atividades definidas. Além desses atributos básicos, os processos podem ser
caracterizados por outros atributos comuns a todos os processos. A ISO / IEC 15504-2 identifica
atributos de processo comuns que caracterizam 6 níveis de realização dentro de uma estrutura
de medição para capacidade de processo. O Anexo B desta Norma inclui a lista de atributos do
processo que contribuem para a obtenção de níveis mais altos de capacidade do processo,
conforme definido na ISO / IEC 15504-2.
5.1.11 Decomposição de processos
Cada processo deste padrão satisfaz os critérios descritos acima. Para fins de descrição clara, os
processos às vezes são decompostos em partes menores. Alguns processos são decompostos em
atividades e / ou processos de nível inferior. Um processo de nível inferior é descrito quando a
parte decomposta do processo em si satisfaz os critérios para ser um processo. Uma atividade é
usada quando a unidade decomposta não se qualifica como um processo. Uma atividade pode
ser considerada simplesmente uma coleção de tarefas (veja abaixo). Às vezes, é útil decompor
processos em processos de nível inferior em um nível mais refinado de detalhes. Alguns
processos de nível inferior são descritos apenas para fins de avaliação. Esses processos de nível
inferior não são descritos no corpo do padrão, mas são fornecidos em um anexo. Em cada caso,
o processo de avaliação de nível inferior descrito no anexo é uma elaboração de uma atividade
do processo associado no corpo da norma.
Uma tarefa é expressa na forma de um requisito, recomendação ou ação permissível, destinada
a apoiar a obtenção dos resultados de um processo. Para este propósito, este padrão emprega
cuidadosamente certos verbos auxiliares (deve, deve e deve) para diferenciar entre as formas
distintas de uma tarefa. "Deverá" é usado para expressar uma provisão requerida para
conformidade, "deveria" expressar uma recomendação entre outras possibilidades, e "pode"
indicar um curso de ação permissível dentro dos limites deste padrão. Material informativo
adicional é fornecido na forma de notas não-normativas ou anexos não normativos.
5.1.12 Modelos e fases do ciclo de vida
A vida de um sistema ou de um produto de software pode ser modelada por um modelo de ciclo
de vida que consiste em etapas. Os modelos podem ser usados para representar toda a vida,
desde o conceito até o descarte ou para representar a parte da vida correspondente ao projeto
atual. O modelo de ciclo de vida é composto por uma sequência de estágios que podem se
sobrepor e / ou iterar, conforme apropriado para o escopo, magnitude, complexidade,
necessidades e oportunidades de mudança do projeto. Cada estágio é descrito com uma
declaração de propósito e resultados. Os processos e atividades do ciclo de vida são selecionados
e empregados em um estágio para cumprir a finalidade e os resultados desse estágio. Diferentes
organizações podem realizar diferentes etapas do ciclo de vida. No entanto, cada etapa é
conduzida pela organização responsável por essa etapa, com a devida consideração das
informações disponíveis sobre planos de ciclo de vida e decisões tomadas nas etapas anteriores.
Da mesma forma, a organização responsável por essa etapa registra as decisões tomadas e
registra as suposições relativas aos estágios subsequentes do ciclo de vida. Esta Norma não
requer o uso de nenhum modelo específico de ciclo de vida. No entanto, exige que cada projeto
defina um modelo de ciclo de vida adequado, de preferência um que tenha sido definido pela
organização para uso em diversos projetos. A aplicação de um modelo de ciclo de vida fornece
os meios para estabelecer a seqüência dependente do tempo necessária para o gerenciamento
de projetos. Além disso, esta Norma não requer o uso de nenhum conjunto particular de etapas.
Um exemplo de conjunto de estágios para o ciclo de vida de um sistema inclui: conceito,
desenvolvimento, produção, utilização, suporte e aposentadoria. Um exemplo de conjunto de
estágios para o ciclo de vida de um produto de software é desenvolvimento, operação e
manutenção. Vários tipos ou classes de modelos de ciclo de vida foram descritos. Exemplos
desses tipos são conhecidos por nomes como cascata, desenvolvimento incremental,
desenvolvimento evolucionário e espiral. Deve-se notar que simplesmente selecionar o nome de
um tipo de modelo não satisfaz o requisito de definir um modelo composto de estágios com
propósito definido e resultados alcançados através dos processos desta Norma Internacional.
NOTA Um Relatório Técnico futuro (ISO / IEC TR 24748) fornece detalhes adicionais sobre
modelos e estágios do ciclo de vida.

5.2 Organização desta Norma Internacional
5.2.1 Categorias de Processos de Ciclo de Vida
Este Padrão Internacional agrupa as atividades que podem ser realizadas durante o ciclo de vida
de um sistema de software em sete grupos de processos. Cada um dos processos do ciclo de vida
dentro desses grupos é descrito em termos de sua finalidade e resultados desejados e lista
atividades e tarefas que precisam ser realizadas para alcançar esses resultados.
a) Processos do Acordo - dois processos (subseções 5.2.2.1.1 e 6.1)
b) Processos de habilitação de projetos organizacionais - cinco processos (subseções 5.2.2.1.2 e
6.2)
c) Processos do Projeto - sete processos (subseções 5.2.2.1.3 e 6.3)
d) Processos Técnicos - onze processos (subseções 5.2.2.1.4 e 6,4)
e) Processos de Implementação de Software - sete processos (subseções 5.2.2.2.1 e 7.1)
f) Processos de Suporte ao Software - oito processos (subseções 5.2.2.2.2 e 7.2)
g) Processos de Reutilização de Software - três processos (subseções 5.2.2.2.3 e 7.3)
Os propósitos e resultados dos processos do ciclo de vida constituem um Modelo de Referência
do Processo.
Dentro desta numeração das cláusulas do Padrão Internacional:
A 6.a e 7.a denotam um grupo de processos
A 6.a.b e 7.a.b denotar um processo (ou processo de nível inferior) dentro desse grupo
A 6.a.b.1 e 7.a.b.1 descrevem o propósito do processo
A 6.a.b.2 e 7.a.b.2 descrevem o resultado do processo
A 6.a.b.3.c e 7.a.b.3.c lista atividades do processo e cláusulas
A 6.a.b.3.c.d e 7.a.b.3.c.d listar tarefas da atividade 'c'
Esses grupos de processos do ciclo de vida são apresentados abaixo e representados na Figura 1.
O Modelo de Referência de Processos não representa uma abordagem de implementação de
processo específica nem prescreve um modelo, metodologia ou técnica de ciclo de vida de
sistema / software. Em vez disso, o modelo de referência deve ser adotado por uma organização
com base em suas necessidades de negócios e domínio de aplicativo. O processo definido pela
organização é adotado pelos projetos da organização no contexto dos requisitos do cliente. Os
resultados do processo são usados para demonstrar o êxito da finalidade de um processo. Isso
ajuda os avaliadores de processo a determinar a capacidade do processo implementado pela
organização e fornecer material de origem para planejar a melhoria do processo organizacional.
5.2.2 Resumo dos Processos do Ciclo de Vida
Existem duas principais subdivisões de processo nesta Norma Internacional. A cláusula 6 fornece
um contexto do sistema para lidar com um produto ou serviço de software independente ou um
sistema de software. A cláusula 7 contém os processos específicos de software para uso na
implementação de um produto ou serviço de software que é um elemento de um sistema maior.
Para auxiliar o uso simultâneo da ISO / IEC 15288 e ISO / IEC 12207, os processos correspondentes
da Cláusula 6 possuem o mesmo número de subcláusula (no nível 6.x.x).
Em geral, a coleção de processos fornecidos nesta Norma Internacional são especializações
apropriadas de software, ou contribuições para os resultados dos processos previstos na ISO /
IEC 15288. Muitos dos processos ISO / IEC 15288 parecem similares a implementações de
processos específicos de software, mas preservam distinções cruciais baseadas no propósito, nos
resultados e no público. Usuários de ambos ISO / IEC 15288 e ISO / IEC 12207 devem ter certeza
de considerar as explicações e notas distintas em cada processo específico.
5.2.2.1 Processos de Contexto do Sistema
5.2.2.1.1 Processos do Acordo - Esses processos definem as atividades necessárias
para estabelecer um acordo entre duas organizações. Se o Processo de Aquisição for invocado,
ele fornecerá os meios para conduzir negócios com um fornecedor de produtos fornecidos para
uso como sistema operacional, de serviços em suporte a um sistema operacional ou de
elementos de um sistema sendo desenvolvido por um projeto. Se o processo de suprimento for
invocado, ele fornecerá os meios para
condução de um projeto em que o resultado é um produto ou serviço que é entregue ao
adquirente. Em geral, os Processos do Contrato fornecidos nesta Norma Internacional são
especializações apropriadas de software dos Processos do Contrato fornecidos na ISO / IEC
15288.
5.2.2.1.2 Processos de ativação de projetos organizacionais - Os processos de
capacitação de projetos organizacionais gerenciam a capacidade da organização de adquirir e
fornecer produtos ou serviços por meio da iniciação, suporte e controle de projetos. Eles
fornecem recursos e infra-estrutura necessária para apoiar projetos e garantir a satisfação dos
objetivos organizacionais e dos acordos estabelecidos. Eles não pretendem ser um conjunto
abrangente de processos de negócios que permitem o gerenciamento dos negócios da
organização.
Os Processos de Ativação de Projetos Organizacionais consistem no seguinte:
a) Processo de Gestão do Modelo de Ciclo de Vida;
b) Processo de Gestão de Infraestrutura;
c) Processo de Gestão de Portfólio de Projetos;
d) Processo de Gestão de Recursos Humanos;
e) Processo de Gestão da Qualidade.
Em geral, os Processos de Ativação de Projetos Organizacionais fornecidos nesta Norma
Internacional são especializações apropriadas de software do conjunto correspondente de
processos fornecidos na ISO / IEC 15288.
5.2.2.1.3 Processos do Projeto - Nesta Norma Internacional, o projeto foi escolhido como o
contexto para descrever processos relacionados ao planejamento, avaliação e controle. Os
princípios relacionados a esses processos podem ser aplicados em qualquer área do
gerenciamento de uma organização.
Existem duas categorias de processos de projeto. Os processos de gerenciamento de projetos
são usados para planejar, executar, avaliar e controlar o andamento de um projeto. Os processos
de suporte do projeto apóiam objetivos de gerenciamento especializados. Ambos são descritos
abaixo.
Os Processos de Gerenciamento de Projetos são usados para estabelecer e evoluir planos de
projetos, para avaliar as conquistas e progressos reais em relação aos planos e para controlar a
execução do projeto até o cumprimento.
Processos individuais de gerenciamento de projetos podem ser invocados a qualquer momento
no ciclo de vida e em qualquer nível de uma hierarquia de projetos, conforme exigido pelos
planos do projeto ou por eventos imprevistos. Os processos de gerenciamento de projetos
são aplicados com um nível de rigor e formalidade que depende do risco e da complexidade do
projeto.
a) Processo de Planejamento do Projeto
b) Processo de Avaliação e Controle do Projeto
Os processos de suporte do projeto fornecem um conjunto específico de tarefas focadas para a
execução de um objetivo de gerenciamento especializado. Todos eles são evidentes na gestão
de qualquer empreendimento, desde uma organização completa até um processo de ciclo de
vida único e suas tarefas.
a) Processo de Gerenciamento de Decisões;
b) Processo de Gerenciamento de Risco;
c) Processo de Gerenciamento de Configuração;
d) Processo de Gestão da Informação;
e) Processo de Medição.
Em geral, os Processos de Suporte do Projeto fornecidos nesta Norma são idênticos aos Processos
de Suporte do Projeto fornecidos na ISO / IEC 15288, além de algumas diferenças na formatação.
Em vários casos, os Processos de Suporte de Software podem ter um relacionamento com os
Processos de Suporte do Projeto.
5.2.2.1.4 Processos Técnicos –
Os Processos Técnicos são usados para definir os requisitos para um sistema, para transformar
os requisitos em um produto efetivo, para permitir a reprodução consistente do produto, quando
necessário, para usar o produto, para fornecer os serviços necessários, para sustentar a provisão
desses serviços. e descartar o produto quando ele for retirado do serviço.
Os processos técnicos definem as atividades que permitem que as funções organizacionais e do
projeto otimizem os benefícios e reduzam os riscos decorrentes de decisões e ações técnicas.
Essas atividades permitem que os produtos
e serviços que possuam a oportunidade e a disponibilidade, a rentabilidade e a funcionalidade,
confiabilidade, manutenibilidade, produtividade, usabilidade e outras qualidades exigidas pelas
organizações de aquisição e fornecimento.
Eles também permitem que produtos e serviços estejam em conformidade com as expectativas
ou requisitos legislados da sociedade,
incluindo saúde, segurança, proteção e fatores ambientais.
Os Processos Técnicos consistem nos seguintes processos:
a) Definição de Requisitos das Partes Interessadas (uma especialização do Processo de Definição
de Requisitos das Partes Interessadas da ISO / IEC 15288);
b) Análise de Requisitos do Sistema (uma especialização do Processo de Análise de Requisitos da
ISO / IEC 15288);
c) Projeto arquitetônico do sistema (uma especialização do processo de projeto arquitetônico da
ISO / IEC 15288);
d) Processo de Implementação (uma especialização do Processo de Implementação da ISO / IEC
15288 e mais detalhada na Cláusula 7 desta Norma como o Processo de Implementação de
Software);
e) Processo de Integração de Sistemas (uma especialização do Processo de Integração da ISO /
IEC 15288);
f) Processo de Teste de Qualificação do Sistema (um processo que contribui para alcançar os
resultados do Processo de Verificação da ISO / IEC 15288);
g) Processo de Instalação de Software (um processo que contribui para alcançar os resultados do
Processo de Transição da ISO / IEC 15288);
h) Processo de Suporte à Aceitação de Software (um processo que contribui para alcançar os
resultados do Processo de Transição da ISO / IEC 15288);
i) Processo de Operação de Software (uma especialização do Processo de Operação da ISO / IEC
15288);
j) Processo de Manutenção de Software (uma especialização do Processo de Manutenção da ISO
/ IEC 15288);
k) Processo de Disposição de Software (uma especialização do Processo de Disposição da ISO /
IEC 15288).
Em geral, os Processos Técnicos fornecidos nesta Norma Internacional são especializações ou
contribuições apropriadas para os resultados dos Processos Técnicos fornecidos na ISO / IEC
15288. Muitos parecem semelhantes aos Processos de Implementação de Software mas
preservam distinções cruciais, por exemplo, Análise de Requisitos do Sistema e A Análise de
Requisitos de Software começa de diferentes pontos e tem diferentes públicos-alvo.
5.2.2.2 Processos Específicos de Software
5.2.2.2.1 Processos de Implementação de Software
Os Processos de Implementação de Software são usados para produzir um elemento do sistema
especificado (item de software) implementado no software. Esses processos transformam o
comportamento especificado, as interfaces e as restrições de implementação em ações de
implementação, resultando em um elemento do sistema que satisfaz os requisitos derivados dos
requisitos do sistema.
O processo guarda-chuva é o Processo de Implementação de Software, uma especialização
específica de software do Processo de Implementação da ISO / IEC 15288.
O Processo de Implementação de Software possui vários processos de nível inferior específicos
de software:
a) Processo de Análise de Requisitos de Software;
b) Processo de Design Arquitetônico de Software;
c) Processo de Design Detalhado de Software;
d) Processo de Construção de Software;
e) Processo de Integração de Software;
f) Processo de teste de qualificação de software.
5.2.2.2.2 Processos de Suporte de Software
Os processos de suporte de software fornecem um conjunto específico de atividades para a
execução de um processo de software especializado. Um processo de suporte auxilia o Processo
de Implementação de Software como uma parte integral com uma finalidade distinta,
contribuindo para o sucesso e a qualidade do projeto de software. Existem oito desses processos:
a) Processo de Gerenciamento de Documentação de Software;
b) Processo de Gerenciamento de Configuração de Software;
c) Processo de Garantia de Qualidade de Software;
d) Processo de Verificação de Software;
e) Processo de Validação de Software;
f) Processo de Revisão de Software;
g) Processo de Auditoria de Software;
h) Processo de resolução de problemas de software.
5.2.2.2.3 Processos de Reutilização de Software
O Grupo de processos de reutilização de software consiste em três processos que suportam a
capacidade de uma organização de reutilizar itens de software nos limites do projeto. Esses
processos são únicos porque, por sua natureza, eles operam fora dos limites de qualquer projeto
em particular.
Os processos de reutilização de software são:
a) Processo de Engenharia de Domínio;
b) Reutilizar o processo de gerenciamento de ativos;
c) Reutilizar o processo de gerenciamento de programas.
5.2.3 Modelo de Referência do Processo
O Anexo B define um Modelo de Referência de Processo (PRM) em um nível de abstração maior
do que o dos requisitos detalhados contidos no texto principal desta Norma. O PRM é aplicável
a uma organização que está avaliando seus processos para determinar a capacidade desses
processos. O objetivo e os resultados são uma declaração dos objetivos do desempenho de cada
processo. Essa declaração de objetivos permite avaliar a eficácia dos processos de outras
maneiras além da simples avaliação da conformidade. Por exemplo, novas definições de processo
podem ser avaliadas em relação às declarações de Propósito e Resultados do Anexo B, e não
contra as disposições detalhadas no texto principal desta Norma.
6 System Life Cycle Processes
6.1 Agreement Processes
6.1.1 Acquisition Process
6.1.1.1 Purpose
O objetivo do Processo de Aquisição é obter o produto e / ou serviço que satisfaça a necessidade
expressa pelo adquirente. O processo começa com a identificação das necessidades do cliente e
termina com a aceitação do produto e / ou serviço exigido pelo adquirente.
6.1.1.2 Resultados
Como resultado da implementação bem sucedida da processo de aquisição:
a) necessidades de aquisição, metas, critérios de aceitação de produtos e / ou serviços e
estratégias de aquisição são definidos;
b) é desenvolvido um acordo que expresse claramente as expectativas, responsabilidades e
responsabilidades do adquirente e do fornecedor;
c) um ou mais fornecedores são selecionados;
d) um produto e / ou serviço é adquirido que satisfaça a necessidade declarada do adquirente;
e) a aquisição é monitorada para que restrições especificadas, como custo, cronograma e
qualidade, sejam atendidas;
f) as entregas do fornecedor são aceitas; e
g) quaisquer itens em aberto identificados tiverem uma conclusão satisfatória conforme
acordado entre o adquirente e o fornecedor.
6.1.1.3 Atividades e tarefas
O adquirente deve implementar as seguintes atividades de acordo com as políticas e
procedimentos organizacionais aplicáveis em relação ao Processo de Aquisição.
NOTA As atividades e tarefas neste processo podem ser aplicadas a um ou mais fornecedores.
6.1.1.3.1 Preparação da aquisição.
6.1.1.3.1.1 O adquirente inicia o processo de aquisição descrevendo um conceito ou uma
necessidade de adquirir, desenvolver ou aprimorar um sistema, produto de software ou serviço
de software.
6.1.1.3.1.2 O adquirente deve definir e analisar os requisitos do sistema. Os requisitos do sistema
devem incluir requisitos empresariais, organizacionais e de usuário, bem como segurança,
segurança e outros requisitos de criticalidade, juntamente com padrões e procedimentos de
projeto, testes e conformidade relacionados.
6.1.1.3.1.3 O adquirente pode realizar a definição e análise de requisitos de software por si
próprio ou pode reter um fornecedor para executar esta tarefa.
6.1.1.3.1.4 Se o adquirente retiver um fornecedor para realizar a análise de requisitos de sistema
ou de software, o adquirente deve reter autoridade de aprovação para os requisitos analisados.
6.1.1.3.1.5 Os Processos Técnicos (subcláusula 6.4) devem ser utilizados para executar as tarefas
nas subcláusulas 6.1.1.3.1.2 e 6.1.1.3.1.4. O adquirente pode usar o Processo de Definição de
Requisitos das Partes Interessadas para estabelecer os requisitos do cliente.
6.1.1.3.1.6 O adquirente deve considerar opções de aquisição contra a análise de critérios
apropriados para incluir risco, custo e benefícios para cada opção. Opções incluem:
a) Compre um produto de software de prateleira que atenda aos requisitos.
b) Desenvolver o produto de software ou obter o serviço de software internamente.
c) Desenvolver o produto de software ou obter o serviço de software por meio de
contrato.
d) Uma combinação de a, b e c acima.
e) Aprimore um produto ou serviço de software existente.
6.1.1.3.1.7 Quando um produto de software de prateleira for adquirido, o adquirente deve
assegurar que as seguintes condições sejam atendidas:
a) Os requisitos para o produto de software estão satisfeitos.
 b) A documentação necessária está disponível.
c) Os direitos de propriedade, uso, propriedade, garantia e licenciamento são
satisfeitos.
d) O suporte futuro para o produto de software é planejado.
6.1.1.3.1.8 O adquirente deve preparar, documentar e executar um plano de aquisição. O plano
deve conter o seguinte:
a) Requisitos para o sistema.
b) Emprego planejado do sistema.
c) Tipo de contrato a ser empregado
d) Responsabilidades das organizações envolvidas.
e) Conceito de suporte a ser usado.
f) Riscos considerados e métodos para gerenciar os riscos.
6.1.1.3.1.9 O adquirente deve definir e documentar a estratégia de aceitação e condições
(critérios).
6.1.1.3.1.10 O adquirente deve documentar os requisitos de aquisição (por exemplo, solicitação
de proposta), cujo conteúdo depende da opção de aquisição selecionada na subcláusula
6.1.1.3.1.6. A documentação de aquisição deve incluir, conforme apropriado:
a) Requisitos do sistema.
b) Declaração do escopo.
c) Instruções para licitantes.
d) Lista de produtos de software.
e) Termos e condições.
f) Controle de subcontratos.
g) Restrições técnicas (por exemplo, ambiente de destino).
6.1.1.3.1.11 O adquirente deve determinar quais processos desta Norma Internacional são
apropriados para a aquisição e especificar quaisquer requisitos de adquirente para adaptar esses
processos. O adquirente deve especificar se algum dos processos deve ser realizado por outras
partes que não o fornecedor, para que os fornecedores possam, nas suas propostas, definir a sua
abordagem para apoiar o trabalho de outras partes. O adquirente deve definir o escopo das
tarefas que fazem referência ao contrato.
6.1.1.3.1.12 A documentação de aquisição deve também definir os marcos do contrato nos quais
o progresso do fornecedor deve ser revisado e auditado como parte do monitoramento da
aquisição (ver subseções 7.2.6 e 7.2.7).
6.1.1.3.1.13 Os requisitos de aquisição devem ser fornecidos à organização selecionada para a
realização das atividades de aquisição.
6.1.1.3.2 Anúncio de aquisição.
6.1.1.3.2.1 O adquirente deve comunicar a solicitação para o fornecimento de um produto ou
serviço a fornecedores identificados.
NOTA Isso pode incluir parcerias de gerenciamento da cadeia de suprimentos que troquem
informações com fornecedores e adquirentes relacionados para obter uma abordagem
harmonizada ou coletiva para questões técnicas e comerciais comuns.
6.1.1.3.3 Seleção de fornecedores.
6.1.1.3.3.1 O adquirente deve estabelecer um procedimento para seleção de fornecedores,
incluindo avaliação de propostas
critérios e requisitos de ponderação de conformidade.
6.1.1.3.3.2 O adquirente deve selecionar um fornecedor com base na avaliação das propostas,
capacidades e de acordo com as estratégias e condições de aceitação do adquirente.
6.1.1.3.4 Contrato.
6.1.1.3.4.1 O adquirente pode envolver outras partes, incluindo potenciais fornecedores ou
quaisquer terceiros necessários (tais como reguladores), antes da adjudicação do contrato, na
determinação dos requisitos do adquirente para a esta Norma Internacional para o projeto. Ao
fazer essa determinação, o adquirente deve considerar o efeito dos requisitos de alfaiataria nos
processos adotados organizacionalmente pelo fornecedor. O adquirente deve incluir ou
referenciar os requisitos de alfaiataria no contrato.
6.1.1.3.4.2 O adquirente deverá então preparar e negociar um contrato com o fornecedor que
requisitos de aquisição, incluindo o custo e o cronograma, do produto ou serviço de software a
ser entregue. O contrato deve abordar os direitos de propriedade, uso, propriedade, garantia e
licenciamento associados aos produtos de software reutilizáveis prontos para uso.
6.1.1.3.4.3 Uma vez que o contrato esteja em andamento, o adquirente deve controlar as
mudanças no contrato por meio de negociação com o fornecedor como parte de um mecanismo
de controle de mudanças. As mudanças no contrato devem ser investigadas quanto ao impacto
nos planos, custos, benefícios, qualidade e cronograma do projeto.
6.1.1.3.5 Monitoramento de acordo.
6.1.1.3.5.1 O adquirente deve monitorar as atividades do fornecedor de acordo com o Processo
de Revisão do Software (subcláusula 7.2.6) e o Processo de Auditoria do Software (subcláusula
7.2.7). O adquirente deve suplementar o monitoramento com o Processo de Verificação de
Software (subcláusula 7.2.4) e o Processo de Validação de Software (subcláusula 7.2.5), conforme
necessário.
6.1.1.3.5.2 O adquirente deve cooperar com o fornecedor para fornecer todas as informações
necessárias em tempo hábil e resolver todos os itens pendentes.
6.1.1.3.6 Aceitação do adquirente.
6.1.1.3.6.1 O adquirente deve preparar-se para aceitação com base na estratégia e nos critérios
de aceitação definidos. A preparação de casos de teste, dados de teste, procedimentos de teste
e ambiente de teste deve ser incluída.
A extensão do envolvimento do fornecedor deve ser definida.
6.1.1.3.6.2 O adquirente deve conduzir o teste de aceitação e revisão do produto ou serviço de
software de fornecimento e aceitá-lo ao fornecedor quando todas as condições de aceitação
forem satisfeitas.
O procedimento de aceitação deve estar em conformidade com as disposições da subcláusula
6.1.1.3.1.9.
6.1.1.3.6.3 Após a aceitação, o adquirente deve assumir a responsabilidade pelo gerenciamento
da configuração do produto de software entregue (consulte a subcláusula 7.2.2).
NOTA O adquirente pode instalar o produto de software ou executar o serviço de software de
acordo com as instruções definidas pelo fornecedor.
6.1.1.3.7 Fechamento - O adquirente deverá efetuar o pagamento ou fornecer outra
contrapartida acordada ao fornecedor pelo produto ou serviço prestado.
6.1.2 Supply Process
6.1.2.1 Purpose
A finalidade do processo de fornecimento é fornecer um produto ou serviço ao adquirente que
atenda aos requisitos acordados.
6.1.2.2 Resultados
Como resultado da implementação bem-sucedida do processo de fornecimento:
a) um adquirente de um produto ou serviço é identificado;
b) uma resposta ao pedido de um adquirente é produzida;
c) um acordo é estabelecido entre o comprador e o fornecedor para desenvolver, manter, operar,
embalar, entregar e instalar o produto e / ou serviço;
d) um produto e / ou serviço que atenda aos requisitos acordados seja desenvolvido pelo
fornecedor;
e) o produto e / ou serviço é entregue ao adquirente de acordo com os requisitos acordados; e
f) o produto é instalado de acordo com os requisitos acordados.
6.1.2.3 Atividades e tarefas
O fornecedor deve implementar as seguintes atividades de acordo com as políticas
organizacionais aplicáveis e procedimentos relativos ao processo de fornecimento.
6.1.2.3.1 Identificação da oportunidade - O fornecedor deve determinar a existência e a
identidade de um adquirente que tenha ou represente uma organização ou organizações que
tenham necessidade de um produto ou serviço.
6.1.2.3.2 Licitação de fornecedores.
6.1.2.3.2.1 O fornecedor deve conduzir uma revisão dos requisitos na solicitação de
proposta, levando em consideração as políticas organizacionais e outras regulamentações.
6.1.2.3.2.2 O fornecedor deve tomar a decisão de licitar ou aceitar o contrato.
6.1.2.3.2.3 O fornecedor deve preparar uma proposta em resposta ao pedido de
proposta.
6.1.2.3.3 Contrato de contrato.
6.1.2.3.3.1 O fornecedor deve negociar e celebrar um contrato com o adquirente para
fornecer o produto ou serviço de software.
(final da paginal 22)
6.1.2.3.3.2 O fornecedor pode solicitar modificações no contrato como parte do
mecanismo de controle de mudanças.
6.1.2.3.4 Execução do contrato.
6.1.2.3.4.1 O fornecedor deve conduzir uma revisão dos requisitos de aquisição para
definir a estrutura para gerenciar e assegurar o projeto e para assegurar a qualidade do produto
ou serviço de software de entrega.
6.1.2.3.4.2 Se não estipulado no contrato, o fornecedor deve definir ou selecionar um
modelo de ciclo de vida apropriado ao escopo, magnitude e complexidade do projeto. O modelo
do ciclo de vida deve ser composto por etapas e o propósito e os resultados de cada etapa. Os
processos, atividades e tarefas desta Norma Internacional devem ser selecionados e mapeados
no modelo de ciclo de vida.
OBSERVAÇÃO Idealmente, isso é realizado usando um modelo de ciclo de vida
definido organizacionalmente.
6.1.2.3.4.3 O fornecedor deve estabelecer requisitos para os planos de
gerenciamento e garantia do projeto e para garantir a qualidade do produto ou serviço de
software a ser entregue. Os requisitos para os planos devem incluir necessidades de recursos e
envolvimento do adquirente.
6.1.2.3.4.4 Uma vez estabelecidos os requisitos de planejamento, o fornecedor deve
considerar as opções para desenvolver o produto de software ou fornecer ao serviço de software
uma análise dos riscos associados a cada opção. Opções incluem:
a) Desenvolver o produto de software ou fornecer o serviço de software usando recursos
internos.
b) Desenvolver o produto de software ou fornecer o serviço de software por subcontratação.
c) Obter produtos de software prontos para uso de fontes internas ou externas.
d) Uma combinação de a, b e c acima.
6.1.2.3.4.5 O fornecedor deve desenvolver e documentar o (s) plano (s) de
gerenciamento do projeto com base nos requisitos de planejamento e nas opções selecionadas
na subcláusula 6.1.2.3.4.4.
NOTA Itens a serem considerados no plano incluem, mas não estão limitados ao seguinte:
a) Estrutura organizacional do projeto e autoridade e responsabilidade de cada unidade
organizacional, incluindo organizações externas.
b) Ambiente de engenharia (para desenvolvimento, operação ou manutenção, conforme
aplicável), incluindo ambiente de teste, biblioteca, equipamentos, instalações, padrões,
procedimentos e ferramentas.
c) Estrutura analítica do trabalho dos processos e atividades do ciclo de vida, incluindo os serviços
de software e itens não entregáveis, a serem executados em conjunto com orçamentos, pessoal,
recursos físicos, tamanho do software e cronogramas associados às tarefas.
d) Gerenciamento das características de qualidade dos produtos ou serviços de software. Planos
separados de qualidade podem ser desenvolvidos.
e) Gerenciamento da segurança, segurança e outros requisitos críticos dos produtos ou serviços
de software. Planos separados para segurança podem ser desenvolvidos.
f) Gestão de subcontratados, incluindo a seleção e envolvimento de subcontratados entre o
subcontratado e o adquirente, se houver.
g) Garantia de qualidade (ver subcláusula 7.2.3).
h) Verificação (consulte a subcláusula 7.2.4) e validação (consulte a subcláusula 7.2.5), incluindo
a abordagem para interface com o agente de verificação e validação, se especificado.
i) envolvimento do adquirente; isto é, por meio de revisões (vide subcláusula 7.2.6), auditorias
(vide subcláusula 7.2.7), reuniões informais, relatórios, modificações e alterações;
implementação, aprovação, aceitação e acesso a instalações.
j) Envolvimento do usuário; por tais meios como exercícios de definição de requisitos,
demonstrações de protótipos e avaliações.
k) Gerenciamento de risco; isto é, gestão das áreas do projeto que envolvem riscos potenciais
técnicos, de custo ou de cronograma.
l) Política de segurança; isto é, as regras para a necessidade de conhecer e acessar informações
em cada nível da organização do projeto.
m) Aprovação exigida por tais meios como regulamentos, certificados exigidos, direitos de
propriedade, uso, propriedade, garantia e licenciamento.
n) Meios de agendamento, rastreamento e relatório.
o) Treinamento de pessoal (ver subitem 6.2.4).
6.1.2.3.4.6 O fornecedor deve implementar e executar o (s) plano (s) de
gerenciamento do projeto desenvolvido (s) de acordo com a subcláusula 6.1.2.3.4.5.
6.1.2.3.4.7 O fornecedor deve:
a) Desenvolver o produto de software de acordo com os Processos Técnicos (subseção 6.4).
b) Operar o produto de software de acordo com o Software Operation Process (subseção 6.4.9).
c) Mantenha o produto de software de acordo com o processo de manutenção de software
(subseção 6.4.10).
6.1.2.3.4.8 O fornecedor deve monitorar e controlar o progresso e a qualidade dos
produtos ou serviços de software do projeto durante todo o ciclo de vida contratado. Esta será
uma tarefa contínua, iterativa, que deverá
fornecer:
a) Monitorar o progresso do desempenho técnico, custos e cronogramas e relatórios do status
do projeto.
b) Identificação, registro, análise e resolução de problemas.
6.1.2.3.4.9 O fornecedor deve gerenciar e controlar os subcontratados de acordo com
o Processo de Aquisição (subcláusula 6.1.1). O fornecedor deve passar todos os requisitos
contratuais necessários para garantir que o produto ou serviço de software entregue ao
adquirente é desenvolvido ou executado de acordo com os requisitos do contrato principal.
6.1.2.3.4.10 O fornecedor deve interagir com o agente independente de verificação,
validação ou teste, conforme especificado no contrato e nos planos do projeto.
6.1.2.3.4.11 O fornecedor deve interagir com outras partes conforme especificado no
contrato e nos planos do projeto.
6.1.2.3.4.12 O fornecedor deve coordenar as atividades de revisão de contrato,
interfaces e comunicação com a organização do adquirente.
6.1.2.3.4.13 O fornecedor deve conduzir ou apoiar reuniões informais, revisão de
aceitação, teste de aceitação, revisões conjuntas e auditorias com o adquirente, conforme
especificado no contrato e nos planos do projeto. A revisão conjunta deve ser conduzida de
acordo com a subcláusula 7.2.6, auditorias de acordo com a subcláusula 7.2.7.
6.1.2.3.4.14 O fornecedor deve realizar a verificação e validação de acordo com as
subseções 7.2.4 e 7.2.5, respectivamente, para demonstrar que os produtos ou serviços de
software e os processos satisfazem plenamente seus respectivos requisitos.
6.1.2.3.4.15 O fornecedor deve disponibilizar ao adquirente os relatórios de
avaliação, revisões, auditorias, testes e resoluções de problemas, conforme especificado no
contrato.
6.1.2.3.4.16 O fornecedor deve fornecer ao adquirente acesso às instalações do
fornecedor e dos subcontratados para revisão de produtos ou serviços de software, conforme
especificado no contrato e nos planos do projeto.
6.1.2.3.4.17 O fornecedor deve realizar atividades de garantia de qualidade de acordo
com a subcláusula 7.2.3.
6.1.2.3.5 Entrega e suporte de produtos / serviços.
6.1.2.3.5.1 O fornecedor deve entregar o produto ou serviço de software conforme
especificado no contrato.
NOTA Quando exigido pelo contrato, o fornecedor deve instalar o produto de acordo com os
requisitos estabelecidos.
6.1.2.3.5.2 O fornecedor deve fornecer assistência ao adquirente em apoio ao
produto ou serviço de software entregue, conforme especificado no contrato.
6.1.2.3.6 Encerramento.
6.1.2.3.6.1 O fornecedor deve aceitar e acusar o pagamento ou outra contrapartida
acordada.
6.1.2.3.6.2 O fornecedor deve transferir a responsabilidade pelo produto ou serviço
para o adquirente, ou outra parte, conforme instruído pelo contrato.
NOTA O acordo deve abordar os termos e a autorização para iniciar o encerramento do projeto.
6.2 Organizational Project-Enabling Processes
6.2.1 Life Cycle Model Management Process
6.2.1.1 Purpose - O propósito do Processo de Gerenciamento do Modelo de Ciclo de Vida é
definir, manter e assegurar a disponibilidade de políticas, processos do ciclo de vida, modelos de
ciclo de vida e procedimentos para uso pela organização com relação ao escopo desta Norma.
Esse processo fornece políticas, processos e procedimentos de ciclo de vida consistentes com os
objetivos da organização, que são definidos, adaptados, aprimorados e mantidos para dar
suporte a necessidades de projetos individuais dentro do contexto da organização e que podem
ser aplicados usando métodos e ferramentas comprovados.
6.2.1.2 Resultados
Como resultado da implementação bem-sucedida do Processo de Gerenciamento do Modelo de
Ciclo de Vida:
a) políticas e procedimentos para a gestão e implantação de modelos e processos de ciclo de vida
são forneceu;
b) responsabilidade, prestação de contas e autoridade para o gerenciamento do ciclo de vida são
definidas;
c) os processos, modelos e procedimentos do ciclo de vida para uso da organização são definidos,
mantidos e melhorados; e
d) melhorias de processo priorizadas são implementadas.
6.2.1.3 Atividades e tarefas
A organização deve implementar as seguintes atividades de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Gerenciamento do Modelo
de Ciclo de Vida.
6.2.1.3.1 Estabelecimento do processo.
6.2.1.3.1.1 A organização estabelece um conjunto de processos organizacionais para
todos os processos de ciclo de vida de software e modelos de ciclo de vida que se aplicam a suas
atividades de negócios. Os processos e sua aplicação a casos específicos devem ser
documentados nas publicações da organização. Conforme apropriado, um mecanismo de
controle de processo deve ser estabelecido para desenvolver, monitorar, controlar e melhorar o
(s) processo (s).
NOTA O estabelecimento do mecanismo de controle do processo inclui a definição de
responsabilidade, responsabilidade e autoridade para o gerenciamento do ciclo de vida.
6.2.1.3.2 Avaliação de processo.
6.2.1.3.2.1 A organização deve desenvolver, documentar e aplicar um procedimento
de avaliação do processo.
Registros de avaliação devem ser produzidos e mantidos.
6.2.1.3.2.2 A organização deve planejar e realizar revisões dos processos em
intervalos apropriados para assegurar sua contínua adequação e eficácia à luz dos resultados da
avaliação.
6.2.1.3.3 Melhoria de processos.
6.2.1.3.3.1 A organização deve efetuar tais melhorias em seus processos, conforme
for necessário, como resultado da avaliação e revisão do processo. A documentação do processo
deve ser atualizada para
refletir melhoria nos processos organizacionais.
6.2.1.3.3.2 Os dados históricos, técnicos e de avaliação devem ser coletados e
analisados para obter uma compreensão dos pontos fortes e fracos dos processos empregados.
Essas análises devem ser usadas como feedback para melhorar esses processos, para
recomendar mudanças na direção dos projetos (ou projetos subseqüentes) e para determinar as
necessidades de avanço tecnológico.
6.2.1.3.3.3 Os dados de custo de qualidade devem ser coletados, mantidos e usados
para melhorar os processos da organização como uma atividade de gerenciamento. Esses dados
servirão ao propósito de estabelecer o custo da prevenção e resolução de problemas e da não
conformidade em produtos e serviços de software.
6.2.2 Processo de Gerenciamento de Infraestrutura
6.2.2.1 Propósito
O objetivo do Processo de Gerenciamento de Infra-estrutura é fornecer a infraestrutura e os
serviços de capacitação aos projetos para apoiar os objetivos da organização e do projeto ao
longo do ciclo de vida. Este processo define, fornece e mantém os recursos, ferramentas e ativos
de tecnologia de comunicações e informações necessários para os negócios da organização com
relação ao escopo desta Norma.
6.2.2.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de
infraestrutura:
a) são definidos os requisitos para infra-estrutura para suportar processos;
b) os elementos da infraestrutura são identificados e especificados;
c) elementos de infraestrutura são adquiridos;
d) os elementos de infraestrutura são implementados; e
e) uma infra-estrutura estável e confiável é mantida e melhorada.
NOTA Os elementos de infraestrutura podem incluir hardware, software, métodos, ferramentas,
técnicas, padrões e recursos para desenvolvimento, operação ou manutenção.
6.2.2.3 Atividades e tarefas
A organização deve implementar as seguintes atividades de acordo com as políticas da
organização aplicáveis
e procedimentos relacionados ao processo de gerenciamento de infraestrutura.
6.2.2.3.1 Implementação do processo.
6.2.2.3.1.1 A infraestrutura deve ser definida e documentada para atender aos
requisitos do processo que emprega esse processo, considerando os procedimentos, padrões,
ferramentas e técnicas aplicáveis.
6.2.2.3.1.2 O estabelecimento da infraestrutura deve ser planejado e documentado.
6.2.2.3.2 Estabelecimento da infraestrutura.
6.2.2.3.2.1 A configuração da infraestrutura deve ser planejada e documentada.
Funcionalidade desempenho, segurança, segurança, disponibilidade, requisitos de espaço,
equipamentos, custos e restrições de tempo devem ser considerados.
6.2.2.3.2.2 A infra-estrutura deve ser instalada a tempo para a execução do processo
relevante.
6.2.2.3.3 Manutenção da infraestrutura.
6.2.2.3.3.1 A infra-estrutura deve ser mantida, monitorada e modificada, conforme
necessário, para assegurar que continue satisfazendo os requisitos do processo que emprega
esse processo. Como parte da manutenção da infraestrutura, deve-se definir até que ponto a
infraestrutura está sob o gerenciamento da configuração.
6.2.3 Processo de gerenciamento de portfólio de projetos
6.2.3.1 Propósito
O objetivo do Processo de Gerenciamento de Portfólio de Projetos é iniciar e sustentar projetos
necessários, suficientes e adequados para atender aos objetivos estratégicos da organização.
Este processo compromete o investimento de financiamento e recursos adequados da
organização e sanciona as autoridades necessárias para estabelecer projetos selecionados.
Realiza a qualificação contínua de projetos para confirmar que eles justificam ou podem ser
redirecionados para justificar o investimento contínuo.
6.2.3.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de portfólio de
projetos:
a) oportunidades de negócios, investimentos ou necessidades são qualificados, priorizados e
selecionados;
b) os recursos e orçamentos de cada projeto são identificados e alocados;
c) responsabilidade e autoridades de gerenciamento de projetos são definidas;
d) projetos que atendem aos requisitos do acordo e das partes interessadas são sustentados; e
e) projetos que não atendem aos requisitos do acordo ou das partes interessadas são
redirecionados ou encerrados.
6.2.3.3 Atividades e tarefas
A organização deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Gerenciamento de
Portfólio de Projetos.
6.2.3.3.1 Início do projeto.
 6.2.3.3.1.1 A organização deve identificar, priorizar, selecionar e estabelecer novas
oportunidades de negócios, empreendimentos ou empreendimentos de maneira consistente
com a estratégia de negócios e os planos de ação da organização.
NOTA Priorize os projetos a serem iniciados e estabeleça limites para determinar quais projetos
serão executados.
6.2.3.3.1.2 A organização deve definir responsabilidades e autoridades para cada
projeto.
6.2.3.3.1.3 A organização deve identificar os resultados esperados dos projetos.
6.2.3.3.1.4 A organização deve alocar recursos para o alcance dos objetivos do
projeto.
6.2.3.3.1.5 A organização deve identificar quaisquer interfaces multiprojetos que
devam ser gerenciadas ou apoiadas pelo projeto.
NOTA Isso inclui o uso de sistemas de habilitação usados por mais de um projeto e o uso de
elementos de sistema comuns por mais de um projeto.
6.2.3.3.1.6 A organização deve especificar os requisitos de relatório do projeto e
revisar os marcos que irão reger a execução do projeto.
6.2.3.3.1.7 A organização deve autorizar o projeto a iniciar a execução dos planos de
projeto aprovados, incluindo os planos técnicos.
6.2.3.3.2 Avaliação de portfólio.
6.2.3.3.2.1 A organização deve avaliar projetos em andamento para confirmar que:
a) Os projetos estão progredindo para atingir as metas estabelecidas.
b) Os projetos estão em conformidade com as diretrizes do projeto.
c) Os projetos estão sendo conduzidos de acordo com os planos e procedimentos do
ciclo de vida do sistema.
d) Os projetos permanecem viáveis, como indicado, por exemplo, pela necessidade
contínua do serviço, implementação prática do produto, benefícios de investimento aceitáveis.
6.2.3.3.2.2 A organização deve agir para continuar ou redirecionar projetos que
estejam progredindo satisfatoriamente ou que possam progredir satisfatoriamente por
redirecionamento apropriado.
6.2.3.3.3 Encerramento do projeto.
6.2.3.3.3.1 A organização deve agir para cancelar ou suspender projetos cujas
desvantagens ou riscos para a organização superam os benefícios de investimentos contínuos,
quando os acordos permitirem isso.
6.2.3.3.3.2 Após a conclusão do acordo para produtos e serviços, a organização deve
agir para encerrar o projeto por políticas e procedimentos organizacionais e pelo contrato.
OBSERVAÇÃO 1 A organização garante que o encerramento do projeto seja responsável pela
retenção da documentação pela organização após o encerramento do projeto.
NOTA 2 Após o encerramento do projeto, a organização pode autorizar a liberação do projeto do
portfólio do projeto.
6.2.4 Processo de Gerenciamento de Recursos Humanos
6.2.4.1 Propósito
O propósito do Processo de Gerenciamento de Recursos Humanos é fornecer à organização os
recursos humanos e manter suas competências, de acordo com as necessidades do negócio. O
processo garante o fornecimento de um pessoal qualificado e experiente, qualificado para
realizar a vida processos de ciclo para alcançar objetivos de organização, projeto e cliente.
6.2.4.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de recursos
humanos:
a) as habilidades exigidas pelos projetos são identificadas;
b) os recursos humanos necessários são fornecidos aos projetos;
c) as habilidades do pessoal são desenvolvidas, mantidas ou aprimoradas;
d) os conflitos nas demandas de recursos multiprojetos são resolvidos; e
e) conhecimento individual, informações e habilidades são coletadas, compartilhadas,
reutilizadas e melhoradas em toda a organização.
6.2.4.3 Atividades e tarefas
A organização deve implementar as seguintes atividades de acordo com as políticas da
organização aplicáveis e procedimentos relacionados ao Processo de Gerenciamento de
Recursos Humanos:
6.2.4.3.1 Identificação da habilidade.
6.2.4.3.1.1 Uma revisão dos requisitos da organização e do projeto deve ser
conduzida para estabelecer e fazer provisão oportuna para adquirir ou desenvolver os recursos
e habilidades requeridos pela gerência e equipe técnica. Essas necessidades podem ser atendidas
por meio de treinamento, recrutamento ou outros mecanismos de desenvolvimento de pessoal.
6.2.4.3.1.2 Os tipos e níveis de treinamento e conhecimento necessários para
satisfazer a organização e o projeto requisitos devem ser determinados.
6.2.4.3.2 Desenvolvimento de habilidades.
6.2.4.3.2.1 Um plano de treinamento, abordando os cronogramas de implementação,
os requisitos de recursos e as necessidades de treinamento, deve ser desenvolvido e
documentado.
6.2.4.3.2.2 Manuais de treinamento, incluindo materiais de apresentação utilizados
no treinamento devem ser desenvolvidos ou adquiridos.
6.2.4.3.2.3 O plano de treinamento deve ser implementado para fornecer
treinamento ao pessoal. Registros de treinamento devem ser mantidos.
6.2.4.3.3 Aquisição e fornecimento de competências.
6.2.4.3.3.1 Estabelecer um programa sistemático de recrutamento de pessoal
qualificado para atender às organização e projetos. Proporcionar oportunidades para o
desenvolvimento da carreira do pessoal existente.
6.2.4.3.3.2 Definir critérios objetivos que possam ser usados para avaliar o
desempenho do pessoal.
6.2.4.3.3.3 Avaliar o desempenho do pessoal em relação às suas contribuições para
as metas da organização ou projeto.
6.2.4.3.3.4 Garantir que o feedback seja fornecido à equipe sobre os resultados de
quaisquer avaliações realizadas.
6.2.4.3.3.5 Manter registros adequados do desempenho da equipe, incluindo
informações sobre habilidades, treinamento concluído e avaliações de desempenho.
 6.2.4.3.3.6 Definir a necessidade da organização e do projeto para as equipes de
projeto. Definir estrutura de equipe e regras de operação.
OBSERVAÇÃO Os conflitos nas demandas de recursos de vários projetos devem ser resolvidos.
6.2.4.3.3.7 Capacitar as equipes para desempenhar sua função, garantindo que as
equipes tenham:
a) Uma compreensão de seu papel no projeto.
b) Uma visão compartilhada ou senso de interesses comuns sobre o sucesso do projeto.
c) Mecanismos apropriados ou facilidades para comunicação e interações entre equipes.
d) Suporte de gerenciamento apropriado para atender aos requisitos do projeto.
6.2.4.3.3.8 Deve-se assegurar que a mistura correta e as categorias de pessoal
adequadamente treinados estejam disponíveis para as atividades e tarefas planejadas em tempo
hábil.
6.2.4.3.4 Gestão do conhecimento.
6.2.4.3.4.1 A organização deve planejar os requisitos para gerenciar os ativos de
conhecimento da organização. O planejamento deve incluir a definição de infraestrutura e
treinamento para apoiar os contribuintes e os usuários dos ativos de conhecimento da
organização, o esquema de classificação para os ativos e os critérios do ativo.
6.2.4.3.4.2 A organização deve estabelecer uma rede de especialistas dentro da
organização. A rede deve conter a identificação dos especialistas da organização, uma lista de
sua área de especialização e identificação de informação disponível dentro de um esquema de
classificação, por exemplo, área de conhecimento. A organização
deve assegurar que a rede seja mantida em dia.
6.2.4.3.4.3 A organização deve estabelecer um mecanismo para apoiar a troca de
informações entre os especialistas e o fluxo de informações especializadas para os projetos da
organização. O mecanismo deve apoiar os requisitos de acesso, armazenamento e recuperação
da organização.
6.2.4.3.4.4 A organização deve executar o gerenciamento de configuração de ativos
de acordo com o Processo de Gerenciamento da Configuração especificado na subcláusula 6.4.2.
6.2.4.3.4.5 As organizações devem capturar e manter informações para acesso da
organização de acordo com o plano.
6.2.5 Processo de Gestão da Qualidade
6.2.5.1 Propósito
O objetivo do Processo de Gestão da Qualidade é garantir que os produtos, serviços e
implementações dos processos do ciclo de vida atendam aos objetivos de qualidade da
organização e atinjam a satisfação do cliente.
6.2.5.2 Resultados
Como resultado da implementação bem-sucedida do processo de Gerenciamento de Qualidade:
a) as políticas e procedimentos de gestão da qualidade da organização são definidos;
b) os objetivos de qualidade da organização são definidos;
c) responsabilidade e autoridade para gestão da qualidade são definidas;
d) o status de satisfação do cliente é monitorado; e
e) ação apropriada é tomada quando os objetivos de qualidade não são alcançados.
6.2.5.3 Atividades e tarefas
A organização deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos da organização aplicáveis em relação ao Processo de Gestão da Qualidade.
6.2.5.3.1 Gestão de qualidade.
6.2.5.3.1.1 A organização deve estabelecer políticas, normas e procedimentos de
gestão da qualidade.
NOTA 1 Um modelo de processo para o sistema de gerenciamento de qualidade pode ser
encontrado na ISO 9001: 2000. Para organizações que desejam ir além da ISO 9001: 2000, em
busca da melhoria contínua do desempenho, a orientação é fornecida na ISO 9004: 2000.
NOTA 2 A orientação para a aplicação da ISO 9001: 2000 ao software pode ser encontrada na ISO
/ IEC 90003: 2004.
6.2.5.3.1.2 A organização deve estabelecer metas e objetivos de gestão da qualidade
da organização com base na estratégia de negócios para a satisfação do cliente.
6.2.5.3.1.3 A organização deve definir responsabilidades e autoridade para
implementação da gestão da qualidade.
6.2.5.3.1.4 A organização deve avaliar a satisfação e o relatório do cliente.
NOTA A implementação desta Norma Internacional fornece à organização uma abordagem para
alcançar a satisfação do cliente.
6.2.5.3.1.5 A organização deve conduzir revisões periódicas dos planos de qualidade
do projeto.
OBSERVAÇÃO Assegurar que os objetivos de qualidade com base nos requisitos das partes
interessadas sejam estabelecidos para cada projeto.
6.2.5.3.1.6 A organização deve monitorar o status das melhorias de qualidade em
produtos e serviços.
6.2.5.3.2 Ação corretiva de gerenciamento de qualidade.
6.2.5.3.2.1 A organização deve tomar ações corretivas quando as metas de gestão da
qualidade não são
alcançado.
6.2.5.3.2.2 A organização deve implementar ações corretivas e comunicar os
resultados por meio do
organização.
6.3 Processos do Projeto
6.3.1 Processo de Planejamento do Projeto
6.3.1.1 Propósito
O objetivo do Processo de Planejamento do Projeto é produzir e comunicar planos de projetos
efetivos e viáveis.
Esse processo determina o escopo do gerenciamento de projetos e das atividades técnicas,
identifica as saídas do processo, as tarefas e as entregas do projeto, estabelece cronogramas para
a conduta da tarefa do projeto, incluindo critérios de realização e recursos necessários para
realizar as tarefas do projeto.
6.3.1.2 Resultados
Como resultado da implementação bem-sucedida do processo de planejamento do projeto:
a) o escopo do trabalho para o projeto é definido;
b) a viabilidade de atingir as metas do projeto com recursos disponíveis e restrições são avaliadas;
c) as tarefas e recursos necessários para concluir o trabalho são dimensionados e estimados;
d) são identificadas interfaces entre os elementos do projeto e com outras unidades de projeto
e organizacionais;
e) planos para a execução do projeto são desenvolvidos; e
f) os planos para a execução do projeto são ativados.
6.3.1.3 Atividades e tarefas
O gerente deve implementar as seguintes atividades de acordo com as políticas e
procedimentos relativos ao Processo de Planejamento do Projeto:
6.3.1.3.1 Início do projeto.
6.3.1.3.1.1 O gerente deve estabelecer os requisitos do projeto a ser realizado.
NOTA O estabelecimento dos requisitos inclui a identificação dos objetivos, motivações e limites
do projeto.
6.3.1.3.1.2 Uma vez estabelecidos os requisitos do projeto, o gerente deve
estabelecer a viabilidade do projeto, verificando se os recursos (pessoal, materiais, tecnologia e
meio ambiente) necessários para executar e gerenciar o projeto estão disponíveis, adequados e
adequados. e que os prazos para a conclusão são realizáveis.
6.3.1.3.1.3 Conforme necessário, e por acordo de todas as partes envolvidas, os
requisitos do projeto podem ser modificados neste momento para atingir os critérios de
conclusão.
6.3.1.3.2 Planejamento do projeto.
6.3.1.3.2.1 O gerente deve preparar os planos para a execução do projeto. Os planos
associados à execução do projeto devem conter descrições das atividades e tarefas associadas e
identificação dos produtos de software que serão fornecidos. Esses planos devem incluir, mas
não estão limitados a, o seguinte:
a) Horários para a conclusão oportuna de tarefas.
b) Estimativa de esforço.
c) Recursos adequados necessários para executar as tarefas.
d) Atribuição de tarefas.
e) Atribuição de responsabilidades.
f) Quantificação dos riscos associados às tarefas ou ao próprio processo.
g) Medidas de garantia de qualidade a serem empregadas durante todo o projeto.
h) Custos associados à execução do processo.
i) Provisão de ambiente e infraestrutura.
j) Definição e manutenção de um modelo de ciclo de vida que é composto por etapas usando os
modelos de ciclo de vida definidos para projetos da organização.
NOTA Os modelos organizacionais para uso do projeto seriam fornecidos através do Processo
de Gerenciamento do Modelo de Ciclo de Vida.
6.3.1.3.3 Ativação do projeto.
6.3.1.3.3.1 O gerente deve obter autorização para o projeto.
6.3.1.3.3.2 O gerente deve enviar solicitações de recursos necessários para executar
o projeto.
6.3.1.3.3.3 O gerente deve iniciar a implementação do (s) plano (s) do projeto para
satisfazer os objetivos e critérios definidos, exercendo controle sobre o projeto
6.3.2 Processo de Avaliação e Controle do Projeto
6.3.2.1 Propósito
A finalidade do Processo de Avaliação e Controle do Projeto é determinar o status do projeto e
garantir que o projeto atue de acordo com planos e cronogramas, e dentro dos orçamentos
projetados, e que ele atenda aos objetivos técnicos.
Esse processo inclui o redirecionamento das atividades do projeto, conforme apropriado, para
corrigir desvios e variações identificados de outros processos técnicos ou de gerenciamento de
projetos. Redirecionamento pode incluir replanejamento como
apropriado.
6.3.2.2 Resultados
Como resultado da implementação bem-sucedida do Processo de Avaliação e Controle do
Projeto:
a) o progresso do projeto é monitorado e reportado;
b) as interfaces entre os elementos do projeto e com outras unidades do projeto e
organizacionais são monitoradas;
c) ações para corrigir desvios do plano e prevenir a recorrência de problemas identificados no
projeto são tomadas quando as metas do projeto não são alcançadas; e
d) os objetivos do projeto são alcançados e registrados.
6.3.2.3 Atividades e tarefas
O gerente deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Avaliação e Controle do Projeto:
6.3.2.3.1 Monitoramento do projeto.
6.3.2.3.1.1 O gerente deve monitorar a execução geral do projeto, fornecendo tanto
relatórios internos do progresso do projeto quanto relatórios externos ao adquirente, conforme
definido no contrato.
OBSERVAÇÃO O gerente garante que as interfaces internas do elemento do projeto, bem como
as interfaces com outros projetos e unidades organizacionais relevantes, sejam monitoradas
durante essa atividade.
6.3.2.3.2 Controle do projeto.
6.3.2.3.2.1 O gerente deve investigar, analisar e resolver os problemas descobertos
durante a execução do projeto. A resolução de problemas pode resultar em alterações nos
planos. É responsabilidade do gerente garantir que o impacto de quaisquer alterações seja
determinado, controlado e monitorado. Problemas e sua resolução devem ser documentados.
6.3.2.3.2.2 O gerente deve relatar, nos pontos acordados, o andamento do projeto,
declarando a adesão aos planos e resolvendo as instâncias da falta de progresso. Estes incluem
relatórios internos e externos, conforme exigido pelos procedimentos organizacionais e pelo
contrato.
6.3.2.3.3 Avaliação do projeto.
6.3.2.3.3.1 O gerente deve garantir que os produtos e planos de software sejam
avaliados quanto à satisfação de requisitos.
6.3.2.3.3.2 O gerente deve avaliar os resultados da avaliação dos produtos de
software, atividades e tarefas concluída durante a execução do projeto para a realização dos
objetivos e conclusão dos planos.
OBSERVAÇÃO O gerente usa os resultados da avaliação para tomar medidas para evitar a
recorrência futura de problemas identificados no projeto.
6.3.2.3.4 Encerramento do projeto.
6.3.2.3.4.1 Quando todos os produtos de software, atividades e tarefas forem
concluídos, o gerente deve determinar se o projeto está completo, levando em conta os critérios
especificados no contrato ou como parte do procedimento da organização.
6.3.2.3.4.2 Estes resultados e registros devem ser arquivados em um ambiente
adequado, conforme especificado no contrato.
6.3.3 Processo de Gerenciamento de Decisões
6.3.3.1 Propósito
O propósito do Processo de Gerenciamento de Decisões é selecionar o curso mais benéfico da
ação do projeto, onde existem alternativas.
Esse processo responde a uma solicitação de decisão encontrada durante o ciclo de vida do
sistema, seja qual for sua natureza ou fonte, para atingir resultados especificados, desejáveis ou
otimizados. Ações alternativas são analisadas e um curso de ação é selecionado e direcionado.
Decisões e seus fundamentos são registrados para apoiar futuras tomadas de decisão.
6.3.3.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de decisões:
a) uma estratégia de tomada de decisão é definida;
b) cursos alternativos de ação são definidos;
c) um curso de ação preferido é selecionado; e
d) a resolução, a lógica da decisão e as suposições são capturadas e relatadas.
6.3.3.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Gerenciamento de
Decisões.
6.3.3.3.1 Planejamento de decisão.
6.3.3.3.1.1 O projeto deve definir uma estratégia de tomada de decisão.
NOTA Isso inclui identificar categorias de decisão e um esquema de priorização e
identificar as partes responsáveis.
Os tomadores de decisão são identificados e recebem a responsabilidade e
autoridade para tomar decisões. Decisões podem surgir como resultado de uma avaliação de
eficácia, um trade-off técnico, um problema que precisa ser resolvido, ação necessária como
resposta ao risco que excede o limite aceitável, uma nova oportunidade ou aprovação para a
progressão do projeto para o próximo ciclo de vida
palco. Uma estratégia de tomada de decisão inclui a identificação e a atribuição de
responsabilidade e autoridade para tomar decisões.
6.3.3.3.1.2 O projeto deve envolver as partes relevantes na tomada de decisões, a fim
de aproveitar a experiência e o conhecimento.
6.3.3.3.1.3 O projeto deve identificar as circunstâncias e a necessidade de uma
decisão.
OBSERVAÇÃO Registrar, categorizar e reportar de maneira rápida e objetiva problemas ou
oportunidades e os cursos de ação alternativos que resolverão seus resultados.
6.3.3.3.2 Análise de decisão.
6.3.3.3.2.1 O projeto deve selecionar e declarar a estratégia de tomada de decisão
para cada situação de decisão.
O projeto deve identificar os resultados desejados e os critérios de sucesso mensuráveis.
6.3.3.3.2.2 O projeto deve avaliar o balanço de conseqüências de ações alternativas,
utilizando a estratégia de tomada de decisão definida, para chegar a uma otimização ou a uma
melhoria em uma situação de decisão identificada.
6.3.3.3.3 Acompanhamento de decisão.
6.3.3.3.3.1 O projeto deve registrar, rastrear, avaliar e relatar os resultados da decisão
para confirmar que os problemas foram efetivamente resolvidos, tendências adversas foram
revertidas e oportunidades foram aproveitadas.
6.3.3.3.3.2 O projeto deve manter registros de problemas e oportunidades e sua
disposição, conforme estipulado em acordos ou procedimentos organizacionais e de uma
maneira que permita a auditoria e a aprendizagem a partir da experiência.
6.3.4 Processo de Gerenciamento de Risco
6.3.4.1 Propósito
O objetivo do processo de gerenciamento de riscos é identificar, analisar, tratar e monitorar os
riscos continuamente. O Processo de Gerenciamento de Risco é um processo contínuo para
abordar sistematicamente os riscos ao longo do ciclo de vida de um sistema ou produto ou
serviço de software. Pode ser aplicado a riscos relacionados à aquisição, desenvolvimento,
manutenção ou operação de um sistema.
6.3.4.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de riscos:
a) o escopo do gerenciamento de risco a ser executado é determinado;
b) estratégias apropriadas de gestão de risco são definidas e implementadas;
c) os riscos são identificados à medida que se desenvolvem e durante a condução do projeto;
d) os riscos são analisados e a prioridade na qual se aplicam recursos para o tratamento desses
riscos é determinada;
e) as medidas de risco são definidas, aplicadas e avaliadas para determinar mudanças no status
de risco e progresso das atividades de tratamento; e
f) tratamento apropriado é tomado para corrigir ou evitar o impacto do risco com base em sua
prioridade, probabilidade e conseqüência ou outro limite de risco definido.
6.3.4.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Gerenciamento de Riscos.
NOTA O ISO / IEC 16085, Processo de Gerenciamento de Riscos, fornece um conjunto mais
detalhado de atividades e tarefas que estão alinhadas com as atividades e tarefas mostradas
abaixo.
6.3.4.3.1 Planejamento do gerenciamento de riscos.
6.3.4.3.1.1 Políticas de gerenciamento de risco descrevendo as diretrizes sob as quais
o gerenciamento de risco deve ser executado devem ser definidas.
6.3.4.3.1.2 Uma descrição do processo de gerenciamento de riscos a ser
implementado deve ser documentada.
 6.3.4.3.1.3 As partes responsáveis pela execução da gestão de riscos e suas funções
e responsabilidades devem ser identificadas.
6.3.4.3.1.4 Os responsáveis deverão dispor de recursos adequados para realizar o
Processo de Gerenciamento de Riscos.
6.3.4.3.1.5 Deve ser fornecida uma descrição do processo de avaliação e melhoria do
processo de gerenciamento de riscos.
NOTA Isso inclui a captura de lições aprendidas.
6.3.4.3.2 Gerenciamento do perfil de risco.
6.3.4.3.2.1 O contexto do Processo de Gerenciamento de Risco deve ser definido e
documentado.
6.3.4.3.2.2 Os limites de risco, definindo as condições sob as quais um nível de risco
pode ser aceito, devem ser documentados.
6.3.4.3.2.3 Um perfil de risco deve ser estabelecido e mantido.
NOTA Os registros do perfil de risco: o contexto de gerenciamento de riscos; um registro do
estado de cada risco, incluindo suas probabilidades, consequências e limites de risco; a prioridade
de cada risco com base em critérios de risco fornecidos pelas partes interessadas; e as
solicitações de ações de risco, juntamente com o status de seu tratamento. O perfil de risco é
atualizado quando há alterações no estado de um risco individual. A prioridade no perfil de risco
é usada para determinar a aplicação de recursos para tratamento.
6.3.4.3.2.4 O perfil de risco relevante deve ser comunicado periodicamente às partes
interessadas com base necessidades.
6.3.4.3.3 Análise de risco.
6.3.4.3.3.1 Os riscos devem ser identificados nas categorias descritas no contexto de
gerenciamento de riscos.
6.3.4.3.3.2 A probabilidade de ocorrência e as consequências de cada risco
identificado devem ser estimadas.
6.3.4.3.3.3 Cada risco deve ser avaliado em relação aos seus limites de risco.
6.3.4.3.3.4 Para cada risco acima do limite de risco, as estratégias de tratamento
recomendadas devem ser definidas e documentadas. Medidas que indiquem a eficácia das
alternativas de tratamento também devem ser definidas e documentadas.
NOTA As estratégias de tratamento de risco incluem, mas não se limitam a, eliminar o risco,
reduzir sua probabilidade de ocorrência ou gravidade das conseqüências ou aceitar o risco.
6.3.4.3.4 Tratamento de risco.
6.3.4.3.4.1 As partes interessadas devem receber alternativas recomendadas para o
tratamento de riscos em solicitações de ações de risco.
6.3.4.3.4.2 Se as partes interessadas determinarem que devem ser tomadas medidas
para tornar um risco aceitável, deve ser implementada uma alternativa de tratamento de risco.
6.3.4.3.4.3 Se as partes interessadas aceitarem um risco que exceda seu limite, elas
devem ser consideradas de alta prioridade e monitoradas continuamente para determinar se são
necessárias ações futuras de tratamento de risco.
6.3.4.3.4.4 Uma vez selecionado o tratamento de risco, ele deve receber as mesmas
ações de gerenciamento que os problemas
fazer, de acordo com as atividades de avaliação e controle na subcláusula 6.3.2 desta norma ou
ISO / IEC 15288: 2008.
6.3.4.3.5 Monitoramento de risco.
6.3.4.3.5.1 Todos os riscos e o contexto de gerenciamento de riscos devem ser
continuamente monitorados quanto a mudanças. Os riscos cujos estados mudaram serão
submetidos a avaliação de risco.
6.3.4.3.5.2 Medidas devem ser implementadas e monitoradas para avaliar a eficácia
do risco tratamentos.
6.3.4.3.5.3 O projeto deve monitorar continuamente novos riscos e fontes ao longo
de seu ciclo de vida.
6.3.4.3.6 Avaliação do processo de gerenciamento de riscos.
6.3.4.3.6.1 As informações devem ser coletadas ao longo do ciclo de vida do projeto
para fins de melhoria do
Processo de Gestão de Riscos e geração de lições aprendidas.
NOTA As informações de risco incluem os riscos identificados, suas fontes, suas causas, seu
tratamento e o sucesso dos tratamentos selecionados.
6.3.4.3.6.2 O Processo de Gerenciamento de Riscos deve ser periodicamente revisado
quanto a sua eficácia e eficiência.
6.3.4.3.6.3 As informações sobre os riscos identificados, seu tratamento e o sucesso
dos tratamentos devem ser revisados periodicamente para fins de identificação de riscos
sistêmicos e riscos da organização.
6.3.5 Processo de Gerenciamento de Configuração
6.3.5.1 Propósito
O objetivo do Processo de Gerenciamento da Configuração é estabelecer e manter a integridade
de todas as saídas identificadas de um projeto ou processo e disponibilizá-las às partes
interessadas.
6.3.5.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de
configuração:
a) uma estratégia de gerenciamento de configuração é definida;
b) itens que requerem gerenciamento de configuração são definidos;
c) as linhas de base de configuração são estabelecidas;
d) alterações nos itens sob gerenciamento de configuração são controladas;
e) a configuração dos itens lançados é controlada; e
f) o status dos itens sob gerenciamento de configuração é disponibilizado ao longo do ciclo de
vida.
NOTA O Processo de Gerenciamento de Configuração de Software é uma especialização do
Processo de Gerenciamento de Configuração e está incluído no Grupo de Processo de Suporte
de Software.
6.3.5.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Gerenciamento da
Configuração.
6.3.5.3.1 Planejamento do gerenciamento de configuração.
6.3.5.3.1.1 O projeto deve definir uma estratégia de gerenciamento de configuração.
NOTA Isso inclui a definição de autoridades para a deposição, acesso, liberação e controle de
alterações nos itens de configuração; definir os locais e condições de armazenamento, seu
ambiente e, no caso de informações, meios de armazenamento, de acordo com níveis designados
de integridade, segurança e proteção; definir os critérios ou eventos para iniciar o controle de
configuração e manter as linhas de base das configurações em evolução e definir a estratégia de
auditoria e as responsabilidades para garantir integridade e segurança contínuas das
informações de definição de configuração. As atividades de gerenciamento de configuração
devem ser compatíveis com as orientações fornecidas na ISO 10007.
6.3.5.3.1.2 O projeto deve identificar itens que estão sujeitos ao controle de
configuração.
6.3.5.3.2 Execução do gerenciamento de configuração.
6.3.5.3.2.1 O projeto deve manter informações sobre configurações com um nível
apropriado de integridade e segurança.
NOTA Isso inclui levar em consideração a natureza dos itens sob controle de configuração. As
descrições de configuração obedecem, sempre que possível, aos padrões de produto ou
tecnologia. Assegure-se de que as informações de configuração permitam a rastreabilidade de
avanço e retrocesso para outros estados de configuração de linha de base. Consolide os estados
de configuração em evolução dos itens de configuração para formar linhas de base
documentadas em horários designados ou sob circunstâncias definidas. Registre a justificativa
para a linha de base e as autorizações associadas nos dados da linha de base de configuração.
Mantenha registros de configuração durante o ciclo de vida do sistema e arquive-os de acordo
com os contratos, a legislação relevante ou a melhor prática do setor.
6.3.5.3.2.2 O projeto deve assegurar que as mudanças nas linhas de base de
configuração sejam adequadamente identificadas, registradas, avaliadas, aprovadas,
incorporadas e verificadas.
OBSERVAÇÃO Consolide os estados de configuração em evolução de itens de configuração para
formar linhas de base documentadas em horários designados ou sob circunstâncias definidas.
Registre as etapas de configuração, a justificativa para a linha de base e as autorizações
associadas nos dados da linha de base de configuração. Mantenha registros de configuração
durante o ciclo de vida do sistema e arquive-os de acordo com os contratos, a legislação relevante
ou a melhor prática do setor. Gerenciar a gravação, recuperação e consolidação do status atual
da configuração e o status de todas as configurações anteriores para confirmar a exatidão, a
atualidade, a integridade e a segurança das informações. Realize auditorias para verificar a
conformidade de uma linha de base com desenhos, documentos de controle de interface e
outros requisitos de contrato.
6.3.6 Processo de Gerenciamento de Informações
6.3.6.1 Propósito
A finalidade do processo de gerenciamento de informações é fornecer informações relevantes,
oportunas, completas, válidas e, se informações confidenciais necessárias às partes designadas
durante e, conforme apropriado, após o ciclo de vida do sistema.
Esse processo gera, coleta, transforma, retém, recupera, dissemina e descarta informações. Ele
gerencia informações designadas, incluindo informações técnicas, de projeto, organizacionais,
de contrato e de usuário.
6.3.6.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de
informações:
a) a informação a ser gerenciada é identificada;
b) as formas das representações da informação são definidas;
c) a informação é transformada e descartada conforme necessário;
d) o status da informação é registrado;
e) a informação é atual, completa e válida; e
f) a informação é disponibilizada às partes designadas.
6.3.6.3 Activities and tasks
6.3.6.3.1 Planejamento do gerenciamento de informações.
6.3.6.3.1.1 O projeto deve definir os itens de informação que serão gerenciados
durante o ciclo de vida do sistema e, de acordo com a política ou a legislação organizacional,
mantidos por um período definido além.
6.3.6.3.1.2 O projeto deve designar autoridades e responsabilidades relativas à
originação, geração, captura, arquivamento e descarte de itens de informação.
6.3.6.3.1.3 O projeto deve definir os direitos, obrigações e compromissos relativos à
retenção, transmissão e acesso aos itens de informação.
NOTA É dada a devida atenção à legislação e segurança de dados e informações, por exemplo,
propriedade, restrições de contrato, direitos de acesso, propriedade intelectual e patentes. Onde
restrições ou restrições se aplicam, a informação é identificada de acordo. O pessoal com
conhecimento de tais informações é informado de suas obrigações e responsabilidades.
6.3.6.3.1.4 O projeto deve definir o conteúdo, semântica, formatos e meio para a
representação, retenção, transmissão e recuperação de informações.
NOTA As informações podem ser originadas e podem terminar em qualquer forma (por exemplo,
verbal, textual, gráfica, numérica) e podem ser armazenadas, processadas, replicadas e
transmitidas usando qualquer meio (por exemplo, eletrônico, impresso, magnético, óptico).
Preste a devida atenção às restrições da organização, por exemplo, infraestrutura, comunicações
inter organizacionais, trabalho de projeto distribuído. Padrões e convenções relevantes de
armazenamento, transformação, transmissão e apresentação de informações são utilizados de
acordo com as restrições de políticas, acordos e legislação.
6.3.6.3.1.5 O projeto deve definir ações de manutenção da informação.
NOTA Isso inclui revisões de status de informações armazenadas quanto à integridade, validade
e disponibilidade e quaisquer necessidades de replicação ou transformação para um meio
alternativo. Considere a necessidade de reter a infraestrutura à medida que a tecnologia muda
para que a mídia arquivada possa ser lida ou a necessidade de gravar novamente a mídia
arquivada usando a nova tecnologia.
6.3.6.3.2 Execução do gerenciamento de informações.
6.3.6.3.2.1 O projeto deve obter os itens de informação identificados.
NOTA Isso pode incluir gerar as informações ou coletá-las de fontes apropriadas.
6.3.6.3.2.2 O projeto deve manter os itens de informação e seus registros de
armazenamento de acordo com os requisitos de integridade, segurança e privacidade.
OBSERVAÇÃO Registre o status dos itens de informação, por exemplo, descrição da versão,
registro de distribuição, classificação de segurança.
As informações devem ser legíveis e armazenadas e retidas de tal maneira que sejam
prontamente recuperáveis em instalações que forneçam um ambiente adequado e que evitem
danos, deterioração e perda.
6.3.6.3.2.3 O projeto deve recuperar e distribuir informações para as partes
designadas, conforme exigido pelo horários acordados ou circunstâncias definidas.
6.3.6.3.2.4 O projeto deve fornecer documentação oficial, conforme necessário.
NOTA Exemplos de documentação oficial são certificação, credenciamento, licença de piloto e
avaliações de avaliação.
6.3.6.3.2.5 O projeto deve arquivar as informações designadas, de acordo com a
auditoria, conhecimento retenção e encerramento do projeto
6.3.7.1 Propósito
O objetivo do Processo de Medição é coletar, analisar e relatar dados relativos aos produtos
desenvolvidos e aos processos implementados na unidade organizacional, para apoiar o
gerenciamento eficaz dos processos e para demonstrar objetivamente a qualidade dos produtos.
6.3.7.2 Resultados
Como resultado da implementação bem-sucedida do Processo de Medição:
a) as necessidades de informação dos processos técnicos e de gestão são identificadas;
b) um conjunto apropriado de medidas, orientadas pelas necessidades de informação, sejam
identificadas e / ou desenvolvidas;
c) as atividades de medição são identificadas e planejadas;
d) os dados necessários são coletados, armazenados, analisados e os resultados interpretados;
e) produtos de informação são usados para apoiar decisões e fornecer uma base objetiva para a
comunicação;
f) o Processo de Medição e as medidas são avaliadas; e
g) as melhorias são comunicadas ao proprietário do Processo de Medição.
6.3.7.3 Activities and tasks
6.3.7.3.1 Planejamento de medições.
6.3.7.3.1.1 O projeto deve descrever as características da organização que são
relevantes para a medição.
6.3.7.3.1.2 O projeto deve identificar e priorizar as necessidades de informação.
6.3.7.3.1.3 O projeto deve selecionar e documentar medidas que satisfaçam as
necessidades de informação.
6.3.7.3.1.4 O projeto deve definir procedimentos de coleta, análise e relato de dados.
6.3.7.3.1.5 O projeto deve definir critérios para avaliação dos produtos de informação
e da medição
6.3.7.3.1.6 O projeto deve revisar, aprovar e fornecer recursos para tarefas de
medição.
6.3.7.3.1.7 O projeto deve adquirir e implantar tecnologias de suporte.
6.3.7.3.2 Desempenho de medição.
6.3.7.3.2.1 O projeto deve integrar procedimentos para geração, coleta, análise e
reporte de dados nos processos relevantes.
6.3.7.3.2.2 O projeto deve coletar, armazenar e verificar dados.
6.3.7.3.2.3 O projeto deve analisar dados e desenvolver produtos de informação.
6.3.7.3.2.4 O projeto deve documentar e comunicar os resultados para os usuários
de medição.
6.3.7.3.3 Avaliação de medição.
6.3.7.3.3.1 O projeto deve avaliar os produtos de informação e o processo de
medição.
6.3.7.3.3.2 O projeto deve identificar e comunicar melhorias potenciais.
6.4 Processos Técnicos
6.4.1 Processo de Definição de Requisitos das Partes Interessadas
NOTA O Processo de Definição de Requisitos das Partes Interessadas nesta Norma é uma
especialização do Processo de Definição dos Requisitos das Partes Interessadas da ISO / IEC
15288. Os usuários podem considerar a reivindicação de conformidade com o processo 15288
em vez do processo desta norma.
6.4.1.1 Propósito
O propósito do Processo de Definição de Requisitos das Partes Interessadas é definir os requisitos
para um sistema que podem fornecer os serviços necessários pelos usuários e outras partes
interessadas em um ambiente definido.
Ele identifica as partes interessadas, ou classes de partes interessadas, envolvidas com o sistema
ao longo de seu ciclo de vida e suas necessidades e desejos. Ele os analisa e os transforma em
um conjunto comum de requisitos de partes interessadas que expressam a interação pretendida
que o sistema terá com seu ambiente operacional e que são a referência contra a qual cada
serviço operacional resultante é validado para confirmar que o sistema atende às necessidades.
6.4.1.2 Resultados
Como resultado da implementação bem-sucedida do Processo de Definição de Requisitos das
Partes Interessadas:
a) as características requeridas e o contexto de uso dos serviços são especificados;
b) as restrições em uma solução de sistema são definidas;
c) a rastreabilidade dos requisitos das partes interessadas para as partes interessadas e suas
necessidades é alcançada;
d) a base para definição dos requisitos do sistema é descrita;
e) a base para validar a conformidade dos serviços é definida; e
f) uma base para negociar e concordar em fornecer um serviço ou produto é fornecida.
6.4.1.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Definição de Requisitos das
Partes Interessadas.
6.4.1.3.1 Identificação das partes interessadas.
6.4.1.3.1.1 O projeto deve identificar as partes interessadas individuais ou classes de
partes interessadas que
interesse legítimo no sistema ao longo do seu ciclo de vida.
NOTA Isso inclui, mas não se limita a, usuários, operadores, apoiadores, desenvolvedores,
produtores, treinadores, mantenedores, fornecedores, organizações de fornecedores e
adquirentes, partes responsáveis por entidades externas de interface, órgãos reguladores e
membros da sociedade. Quando a comunicação direta não for praticável, por exemplo, para
produtos e serviços ao consumidor, são selecionados representantes ou partes interessadas
designadas do proxy.
6.4.1.3.2 Identificação dos requisitos.
6.4.1.3.2.1 O projeto deve suscitar exigências das partes interessadas.
6.4.1.3.2.2 O projeto deve definir as restrições em uma solução de sistema que são
conseqüências inevitáveis de acordos existentes, decisões de gerenciamento e decisões técnicas.
NOTA Podem resultar de 1) instâncias ou áreas de solução definida por partes interessadas; 2)
decisões de implementação feitas em níveis mais altos de estrutura hierárquica do sistema; 3)
uso obrigatório de sistemas, recursos e funcionários habilitados definidos.
6.4.1.3.2.3 O projeto deve definir um conjunto representativo de seqüências de
atividades para identificar todas as serviços que correspondem a cenários e ambientes
operacionais e de apoio previstos.
6.4.1.3.2.4 O projeto deve identificar a interação entre os usuários eo sistema,
levando em consideração conta as capacidades humanas e as limitações de habilidades.
NOTA 1 Os requisitos de usabilidade são determinados, estabelecendo, no mínimo, o
desempenho humano mais eficaz, eficiente e confiável e a interação entre sistema humano e
sistema. Quando possível, padrões aplicáveis, por exemplo, ISO 9241, e práticas profissionais
aceitas são usadas para definir:
a) Capacidades físicas, mentais e aprendidas;
b) Local de trabalho, ambiente e instalações, incluindo outros equipamentos no contexto de uso;
c) condições normais, incomuns e de emergência;
d) Recrutamento de operadores e usuários, treinamento e cultura.
6.4.1.3.2.5 O projeto deve especificar requisitos e funções relativos à saúde,
segurança, meio ambiente e demais partes interessadas, relacionados a qualidades críticas, e
deve abordar possíveis efeitos adversos do uso do sistema na saúde e segurança humana.
6.4.1.3.3 Avaliação de requisitos.
6.4.1.3.3.1 O projeto deve analisar o conjunto completo de requisitos elicitados.
OBSERVAÇÃO A análise inclui identificar e priorizar o conflito, falta, incompleto, ambíguo,
inconsistente, requisitos incongruentes ou não verificáveis.
6.4.1.3.4 Acordo de requisitos.
6.4.1.3.4.1 O projeto deve resolver problemas de requisitos.
NOTA Isso inclui requisitos que não podem ser realizados ou que são impraticáveis.
6.4.1.3.4.2 O projeto deve realimentar os requisitos analisados às partes interessadas
aplicáveis para
que as necessidades e expectativas foram adequadamente captadas e expressas.
NOTA Explicar e obter concordância com as propostas para resolver requisitos de partes
interessadas conflitantes, impraticáveis e irrealizáveis.
6.4.1.3.4.3 O projeto deve estabelecer com as partes interessadas que seus requisitos
são expressos corretamente.
NOTA Isso inclui a confirmação de que os requisitos das partes interessadas são compreensíveis
para os originadores e que a resolução do conflito nos requisitos não corrompeu ou
comprometeu as intenções dos envolvidos.
6.4.1.3.5 Gravação de requisitos.
6.4.1.3.5.1 O projeto deve registrar os requisitos das partes interessadas em uma
forma adequada para o gerenciamento de requisitos durante o ciclo de vida e além.
6.4.2 Processo de Análise de Requisitos do Sistema
NOTA O Processo de Análise de Requisitos do Sistema nesta Norma é uma especialização do
Processo de Análise de Requisitos da ISO / IEC 15288. Os usuários podem considerar a
reivindicação de conformidade com o processo 15288 do que o processo neste padrão.
6.4.2.1 Propósito
A finalidade da Análise de Requisitos do Sistema é transformar os requisitos das partes
interessadas definidas em um conjunto dos requisitos técnicos do sistema que orientarão o
design do sistema.
6.4.2.2 Resultados
Como resultado da implementação bem-sucedida da Análise de Requisitos do Sistema:
a) um conjunto definido de requisitos funcionais e não funcionais do sistema descrevendo o
problema a ser resolvido;
b) as técnicas apropriadas são realizadas para otimizar a solução de projeto preferida;
c) os requisitos do sistema são analisados quanto à exatidão e testabilidade;
d) o impacto dos requisitos do sistema no ambiente operacional é entendido;
e) os requisitos são priorizados, aprovados e atualizados conforme necessário;
f) a consistência e a rastreabilidade são estabelecidas entre os requisitos do sistema e os
requisitos do cliente.
linha de base dos requisitos;
g) as mudanças na linha de base são avaliadas quanto ao custo, cronograma e impacto técnico;
e
h) os requisitos do sistema são comunicados a todas as partes afetadas e à linha de base.
6.4.2.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com a organização
aplicável políticas e procedimentos relacionados ao processo de análise de requisitos do sistema.
6.4.2.3.1 Especificação de requisitos.
6.4.2.3.1.1 O uso específico pretendido do sistema a ser desenvolvido deve ser
analisado para especificar os requisitos do sistema. A especificação dos requisitos do sistema
deve descrever: funções e capacidades do sistema; requisitos empresariais, organizacionais e de
usuário; segurança, segurança, engenharia de fatores humanos (ergonomia), interface,
operações e requisitos de manutenção; restrições de design e requisitos de qualificação. A
especificação dos requisitos do sistema deve ser documentada.
6.4.2.3.2 Avaliação de requisitos.
6.4.2.3.2.1 Os requisitos do sistema devem ser avaliados considerando os critérios
listados abaixo. Os resultados das avaliações devem ser documentados.
a) Rastreabilidade às necessidades de aquisição;
b) Consistência com as necessidades de aquisição;
c) testabilidade;
d) Viabilidade do projeto arquitetônico do sistema;
e) Viabilidade de operação e manutenção.
NOTA As necessidades de aquisição incluem a linha de base dos requisitos das partes
interessadas.
6.4.3 Processo de Design Arquitetônico do Sistema
OBSERVAÇÃO O Processo de Projeto Arquitetônico do Sistema neste Padrão Internacional é uma
especialização do Processo de Projeto Arquitetônico da ISO / IEC 15288. Os usuários podem
considerar a reivindicação de conformidade com o processo 15288 em vez do processo neste
padrão.
6.4.3.1 Propósito
O objetivo do System Architectural Design Process é identificar quais requisitos do sistema
devem ser alocados a quais elementos do sistema.
6.4.3.2 Resultados
Como resultado da implementação bem-sucedida do processo de design arquitetônico do
sistema:
a) é definido um projeto de arquitetura do sistema que identifica os elementos do sistema e
atende aos requisitos definidos;
b) os requisitos funcionais e não funcionais do sistema são abordados;
c) os requisitos são alocados aos elementos do sistema;
d) interfaces internas e externas de cada elemento do sistema são definidas;
e) verificação entre os requisitos do sistema e a arquitetura do sistema é executada;
f) os requisitos alocados aos elementos do sistema e suas interfaces são rastreáveis até o cliente
linha de base dos requisitos;
g) consistência e rastreabilidade entre os requisitos do sistema e o design da arquitetura do
sistema é mantido; e
h) os requisitos do sistema, o design da arquitetura do sistema e seus relacionamentos são
estabelecidos em comunicada a todas as partes afetadas;
i) fatores humanos e conhecimentos ergonômicos e técnicas são incorporados no projeto do
sistema; e
j) atividades de design centradas no ser humano são identificadas e executadas.
6.4.3.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização em relação ao Processo de Projeto Arquitetônico do
Sistema.
6.4.3.3.1 Estabelecimento de arquitetura.
6.4.3.3.1.1 Uma arquitetura de alto nível do sistema deve ser estabelecida. A
arquitetura deve identificar itens de hardware, software e operações manuais. Deve-se assegurar
que todos os requisitos do sistema sejam alocados entre os itens. Itens de configuração de
hardware, itens de configuração de software e operações manuais devem ser subsequentemente
identificados a partir desses itens. A arquitetura do sistema e os requisitos do sistema alocados
aos itens devem ser documentados.
6.4.3.3.2 Avaliação de arquitetura.
6.4.3.3.2.1 A arquitetura do sistema e os requisitos para os itens devem ser avaliados
considerando a critérios listados abaixo. Os resultados das avaliações devem ser documentados.
a) Rastreabilidade aos requisitos do sistema.
b) Consistência com os requisitos do sistema.
c) Adequação dos padrões de projeto e métodos utilizados.
d) Viabilidade dos itens de software cumprindo seus requisitos alocados.
e) Viabilidade de operação e manutenção.
OBSERVAÇÃO A rastreabilidade da arquitetura do sistema para os requisitos do sistema também
deve fornecer rastreabilidade à linha de base dos requisitos da parte interessada.
6.4.4 Processo de Implementação
6.4.4.1 Propósito
O objetivo do processo de implementação é realizar um elemento do sistema especificado.
NOTA Os usuários desta Norma têm a intenção de tratar um produto de software ou um
elemento de software de um sistema maior. O Processo de Implementação de Software
(subcláusula 7.1.1) é uma instância conforme da Implementação
Processo da ISO / IEC 15288, especializado para as necessidades específicas de implementação
de um produto ou serviço de software. O O processo de implementação de software substitui o
processo de implementação nesta norma internacional.
6.4.5 Processo de Integração do Sistema
NOTA O Processo de Integração do Sistema nesta Norma é uma especialização do Processo de
Integração da ISO / IEC 15288. Os usuários podem considerar a reivindicação de conformidade
com o processo 15288 em vez do processo desta norma.
6.4.5.1 Propósito
O objetivo do Processo de Integração do Sistema é integrar os elementos do sistema (incluindo
itens de software, itens de hardware, operações manuais e outros sistemas, conforme
necessário) para produzir um sistema completo que satisfaça o design do sistema e as
expectativas dos clientes expressas no requisitos de sistema.
6.4.5.2 Resultados
Como resultado da implementação bem-sucedida do processo de integração do sistema:
a) uma estratégia é desenvolvida para integrar o sistema de acordo com as prioridades dos
requisitos do sistema;
b) critérios são desenvolvidos para verificar a conformidade com os requisitos do sistema
alocados para os elementos do sistema, incluindo as interfaces entre os elementos do sistema;
c) a integração do sistema é verificada utilizando os critérios definidos;
d) uma estratégia de regressão é desenvolvida e aplicada para testar novamente o sistema
quando mudanças são feitas;
e) consistência e rastreabilidade são estabelecidas entre o projeto do sistema e o sistema
integrado elementos;
f) é construído um sistema integrado que demonstra conformidade com o projeto do sistema; e
g) é construído um sistema integrado que demonstra que existe um conjunto completo de
elementos utilizáveis do sistema entregável.
6.4.5.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Integração do Sistema.
6.4.5.3.1 Integração.
6.4.5.3.1.1 Os itens de configuração do software devem ser integrados, com itens de
configuração de hardware, operações manuais e outros sistemas, conforme necessário, no
sistema. Os agregados devem ser testados, à medida que são desenvolvidos, em relação às suas
necessidades. A integração e os resultados dos testes devem ser documentados.
6.4.5.3.2 Teste de prontidão.
6.4.5.3.2.1 Para cada requisito de qualificação do sistema, um conjunto de testes,
casos de teste (entradas, saídas, critérios de teste) e procedimentos de teste para a realização
do Teste de Qualificação do Sistema devem ser desenvolvidos e
documentado. O desenvolvedor deve garantir que o sistema integrado esteja pronto para o Teste
de Qualificação do Sistema.
6.4.5.3.2.2 O sistema integrado deve ser avaliado considerando os critérios listados
abaixo. Os resultados das avaliações devem ser documentados.
a) Teste a cobertura dos requisitos do sistema.
b) Adequação dos métodos e padrões de teste utilizados.
c) Conformidade com os resultados esperados.
d) Viabilidade do teste de qualificação do sistema.
e) Viabilidade de operação e manutenção.
6.4.6 Processo de teste de qualificação do sistema
6.4.6.1 Propósito
A finalidade do processo de teste de qualificação de sistemas é garantir que a implementação de
cada requisito do sistema é testado quanto à conformidade e o sistema está pronto para entrega.
6.4.6.2 Resultados
Como resultado da implementação bem-sucedida do processo de teste de qualificação de
sistemas:
a) critérios para avaliar a conformidade com os requisitos do sistema são desenvolvidos;
b) o sistema integrado é testado usando os critérios definidos;
c) os resultados dos testes são registrados; e
d) a prontidão do sistema para entrega é garantida.
6.4.6.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Teste de Qualificação do
Sistema.
6.4.6.3.1 Teste de qualificação.
6.4.6.3.1.1 O teste de qualificação do sistema deve ser conduzido de acordo com os
requisitos de qualificação especificados para o sistema. Deve assegurar-se que a implementação
de cada sistema requisito é testado quanto à conformidade e que o sistema está pronto para
entrega. Os resultados do teste de qualificação devem ser documentados.
NOTA Os requisitos de qualificação para o sistema devem incluir critérios para avaliar a
conformidade com os requisitos do sistema.
6.4.6.3.1.2 O sistema deve ser avaliado considerando os critérios listados abaixo. Os
resultados das avaliações devem ser documentadas.
a) Teste de cobertura dos requisitos do sistema;
b) Conformidade com os resultados esperados;
c) Viabilidade de operação e manutenção.
NOTA Os critérios de avaliação devem abordar a prontidão do sistema para entrega.
6.4.6.3.1.3 O desenvolvedor deve suportar auditoria (s) de acordo com a subcláusula
7.2.7. Os resultados do auditoria (s) deve ser documentada.
OBSERVAÇÃO Esta subcláusula não se aplica a esses itens de configuração de software para os
quais foram realizadas auditorias anteriormente.
6.4.6.3.1.4 Após a conclusão bem-sucedida da (s) auditoria (ões), se conduzida, o
desenvolvedor deve atualizar e preparar o produto de software de entrega para a Instalação de
Software e Suporte de Aceitação de Software.
NOTA O Processo de Teste de Qualificação do Sistema pode ser usado no Processo de Verificação
de Software (subcláusula 7.2.4) ou no Processo de Validação de Software (subcláusula 7.2.5).
6.4.7 Processo de Instalação de Software
NOTA O Processo de Instalação de Software desta Norma contribui para os resultados da
Transição. Processo da ISO / IEC 15288. Os usuários podem considerar a reivindicação de
conformidade com o processo 15288 em vez do processo desta norma.
6.4.7.1 Propósito
A finalidade do processo de instalação de software é instalar o produto de software que atenda
aos requisitos acordados no ambiente de destino.
6.4.7.2 Resultados
Como resultado da implementação bem-sucedida do processo de instalação de software:
a) uma estratégia de instalação de software é desenvolvida;
b) critérios para instalação de software são desenvolvidos para demonstrar a conformidade com
os requisitos de instalação de software;
c) o produto de software é instalado no ambiente de destino; e
d) a prontidão do produto de software para uso em seu ambiente pretendido é garantida.
6.4.7.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Instalação do Software.
6.4.7.3.1 Instalação do software.
6.4.7.3.1.1 O implementador deve desenvolver um plano para instalar o produto de
software no ambiente de destino, conforme designado no contrato. Os recursos e informações
necessários para instalar o produto de software devem ser determinados e estar disponíveis.
Conforme especificado no contrato, o implementador deve auxiliar o adquirente nas atividades
de configuração. Onde o produto de software instalado está substituindo um sistema existente,
o implementador apoiará quaisquer atividades paralelas que sejam exigidas por contrato. O
plano de instalação deve ser documentado.
NOTA 1 A estratégia de instalação de software deve ser desenvolvida de acordo com o cliente e
com o organização.
NOTA 2 Uma parte importante do desenvolvimento de uma estratégia de instalação é
desenvolver uma estratégia para retornar ao último sistema de trabalho.
versão do sistema. Para poder reinstalar a última versão de trabalho, um backup completo do
sistema deve ser feito antes de iniciar a instalação.
NOTA 3 Com base nos requisitos de instalação, o instalador deve desenvolver critérios para o
ambiente em que o software será instalado.
NOTA 4 O instalador deve especificar os requisitos para adaptação do sistema para o ambiente
pretendido.
NOTA 5 O instalador deve adaptar o sistema para atender aos requisitos de operação.
6.4.7.3.1.2 O desenvolvedor deve instalar o produto de software de acordo com o plano
de instalação. Deve-se assegurar que o código de software e os bancos de dados sejam
inicializados, executados e terminados conforme especificado no contrato. Os eventos e
resultados da instalação devem ser documentados.
NOTA O instalador deve assegurar que o software esteja pronto para uso no ambiente
pretendido.
6.4.8 Processo de Suporte à Aceitação de Software
OBSERVAÇÃO O Processo de Suporte à Aceitação do Software deste padrão contribui para os
resultados do Processo de Transição da ISO / IEC 15288. O Processo de Suporte à Aceitação do
Software deste padrão também pode contribuir para os resultados do Processo de Validação da
ISO / IEC 15288. Os usuários podem considerar alegando conformidade com o processo ou
processos 15288 em vez do processo neste padrão.
6.4.8.1 Propósito
A finalidade do processo de suporte de aceitação de software é ajudar o adquirente a obter a
confiança de que o produto atende aos requisitos.
6.4.8.2 Resultados
Como resultado da implementação bem-sucedida do processo de suporte de aceitação de
software:
a) o produto é preenchido e entregue ao adquirente;
b) testes e revisões de aceitação do adquirente são suportados;
c) o produto é colocado em operação no ambiente dos clientes; e
d) os problemas detectados durante a aceitação são identificados e comunicados aos
responsáveis pela resolução.
NOTA A entrega incremental estaria em incrementos concluídos.
6.4.8.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Suporte à Aceitação do
Software.
6.4.8.3.1 Suporte de aceitação de software.
6.4.8.3.1.1 O desenvolvedor deve apoiar a revisão de aceitação do adquirente e o teste
do software produtos. A análise e o teste de aceitação devem considerar os resultados dos
processos de Revisão de Software (subcláusula 7.2.6), Auditoria de Software (subcláusula 7.2.7),
Teste de Qualificação de Software e Teste de Qualificação do Sistema (se executado). Os
resultados da revisão e teste de aceitação devem ser documentados.
NOTA Isso inclui documentação e comunicação de problemas detectados durante o teste de
aceitação para os responsáveis pela resolução.
6.4.8.3.1.2 O desenvolvedor deve concluir e entregar o produto de software conforme
especificado no contrato.
NOTA O contrato pode exigir que o desenvolvedor coloque o produto em operação no ambiente
do cliente.
6.4.8.3.1.3 O desenvolvedor deve fornecer treinamento inicial e contínuo e suporte ao
adquirente como especificado no contrato.
OBSERVAÇÃO O suporte inicial inclui a identificação e comunicação de problemas detectados
durante a aceitação para os responsáveis pela resolução.
6.4.9 Processo de Operação de Software
É uma especialização do Processo de Operação da ISO / IEC 15288. Os usuários podem considerar
a reivindicação de conformidade com o processo 15288 em vez do processo em questão.
este padrão.
6.4.9.1 Propósito
O objetivo do Processo de Operação de Software é operar o produto de software em seu
ambiente pretendido e fornecer suporte aos clientes do produto de software.
6.4.9.2 Resultados
Como resultado da implementação bem-sucedida do processo de operação de software:
a) uma estratégia de operação é definida;
b) as condições para o correto funcionamento do software em seu ambiente pretendido são
identificadas e avaliadas;
c) o software é testado e determinado a operar no ambiente pretendido;
d) o software é operado no ambiente pretendido; e
e) assistência e consulta são fornecidas aos clientes do produto de software de acordo com o
contrato.
6.4.9.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Operação do Software.
6.4.9.3.1 Preparação para operação.
6.4.9.3.1.1 O operador deve desenvolver um plano e estabelecer padrões operacionais
para executar as atividades e tarefas deste processo. O plano deve ser documentado e
executado.
6.4.9.3.1.2 O operador deve estabelecer procedimentos para receber, registrar,
resolver, rastrear problemas e fornecer feedback. Sempre que forem encontrados problemas,
eles devem ser registrados e inseridos no processo de resolução de problemas de software
(subseção 7.2.8).
6.4.9.3.1.3 O operador deve estabelecer procedimentos para testar o produto de
software em seu ambiente de operação, para inserir relatórios de problemas e solicitações de
modificação no Processo de Manutenção de Software (subseção 6.4.10) e para liberar o produto
de software para uso operacional.
6.4.9.3.2 Ativação e check-out da operação.
6.4.9.3.2.1 Para cada versão do produto de software, o operador deve realizar testes
operacionais e, ao satisfazer os critérios especificados, liberar o produto de software para uso
operacional.
6.4.9.3.2.2 O operador deve assegurar que o código de software e os bancos de dados
sejam inicializados, executados e terminados conforme descrito no plano.
6.4.9.3.2.3 O operador deve ativar o sistema em sua situação operacional pretendida
para fornecer instâncias de serviço ou serviço contínuo de acordo com a finalidade a que se
destina.
OBSERVAÇÃO Onde acordado, mantenha a capacidade e a qualidade do serviço contínuo quando
o sistema substituir um sistema existente que estiver sendo retirado. Durante um período
especificado de transição ou operação simultânea, gerencie a transferência de serviços para que
a conformidade contínua com as necessidades persistentes das partes interessadas seja
alcançada.
6.4.9.3.3 Uso operacional - O sistema deve ser operado no ambiente pretendido de acordo com
a documentação do usuário.
6.4.9.3.4 Suporte ao cliente. - O operador deve fornecer assistência e consulta aos usuários,
conforme solicitado. Essas solicitações e ações subseqüentes devem ser registradas e
monitoradas.
OBSERVAÇÃO A assistência e a consulta incluem o fornecimento de treinamento, documentação
e outros serviços de suporte que apóiam o uso eficaz do produto.
6.4.9.3.4.2 O operador deve encaminhar solicitações do usuário, conforme necessário,
para o processo de manutenção de software (subcláusula 6.4.10) para resolução. Esses pedidos
devem ser endereçados e as ações planejadas e tomadas devem ser relatadas aos originadores
dos pedidos. Todas as resoluções devem ser monitoradas para conclusão.
6.4.9.3.5 Resolução do problema de operação.
6.4.9.3.5.1 O operador deve encaminhar os problemas identificados para o processo de
resolução de problemas de software para resolução.
6.4.9.3.5.2 Se um problema relatado tiver uma solução temporária antes que uma
solução permanente possa ser liberada, o originador do relatório de problemas deve ter a opção
de usá-lo. Correções permanentes, liberações que incluem funções ou recursos previamente
omitidos e melhorias do sistema devem ser aplicadas ao produto de software operacional usando
o Processo de Manutenção de Software (subseção 6.4.10).
6.4.10 Processo de Manutenção de Software
NOTA 1 O Processo de Manutenção de Software nesta Norma é uma especialização da
Manutenção.
Processo da ISO / IEC 15288. Os usuários podem considerar a reivindicação de conformidade com
o processo 15288 em vez do processo desta norma.
NOTA 2 O Processo de Manutenção de Software deste Padrão Internacional é compatível com a
ISO / IEC 14764: 2006.
6.4.10.1 Propósito
A finalidade do processo de manutenção de software é fornecer suporte econômico a um
produto de software entregue.
OBSERVAÇÃO Software pré-entrega As atividades de manutenção incluem o planejamento das
operações pós-entrega, a capacidade de suporte e a determinação da logística. As atividades pós-
entrega incluem modificação de software e suporte operacional, como treinamento ou operação
de um help desk
6.4.10.2 Resultados
Como resultado da implementação bem-sucedida do processo de manutenção de software:
a) uma estratégia de manutenção é desenvolvida para gerenciar a modificação e migração de
produtos de acordo com a estratégia de liberação;
b) o impacto de mudanças no sistema existente na organização, operações ou interfaces é
identificado;
c) o sistema afetado e a documentação do software são atualizados conforme necessário;
d) produtos modificados são desenvolvidos com testes associados que demonstram que os
requisitos não são comprometidos;
e) as atualizações de produtos são migradas para o ambiente do cliente; e
f) a modificação do software do sistema é comunicada a todas as partes afetadas.
6.4.10.3 Atividades e tarefas
O mantenedor deve implementar as seguintes atividades de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Manutenção de Software.
6.4.10.3.1 Implementação do processo.
6.4.10.3.1.1 O mantenedor deve desenvolver, documentar e executar planos e
procedimentos para conduzir as atividades e tarefas do Processo de Manutenção de Software.
6.4.10.3.1.2 O mantenedor deve estabelecer procedimentos para receber, registrar e
rastrear relatórios de problemas e solicitações de modificação dos usuários e fornecer feedback
aos usuários. Sempre que forem encontrados problemas, eles devem ser registrados e inseridos
no processo de resolução de problemas de software (subseção 7.2.8).
6.4.10.3.1.3 O mantenedor deve implementar (ou estabelecer interface organizacional
com) o Processo de Gerenciamento da Configuração (subcláusula 7.2.2) para gerenciar
modificações no sistema existente.
6.4.10.3.2 Análise de problemas e modificações.
6.4.10.3.2.1 O mantenedor deve analisar o relatório de problemas ou solicitação de
modificação para seu impacto na organização, no sistema existente e nos sistemas de interface
para o seguinte:
a) um tipo; por exemplo, corretivo, melhoria, preventivo ou adaptativo ao novo ambiente;
b) Escopo; por exemplo, tamanho da modificação, custo envolvido, tempo para modificar;
c) criticidade; por exemplo, impacto no desempenho, segurança ou segurança.
6.4.10.3.2.2 O mantenedor deve replicar ou verificar o problema.
6.4.10.3.2.3 Com base na análise, o mantenedor deve desenvolver opções para
implementar a modificação.
6.4.10.3.2.4 O mantenedor deve documentar o pedido de modificação / problema, os
resultados da análise e opções de implementação.
6.4.10.3.2.5 O mantenedor deverá obter aprovação para a opção de modificação
selecionada, conforme especificado no contrato.
6.4.10.3.3 Implementação de modificação.
6.4.10.3.3.1 O mantenedor deve conduzir a análise e determinar que documentação,
unidades de software e suas versões precisam ser modificadas. Estes devem ser documentados.
6.4.10.3.3.2 O mantenedor deverá entrar nos Processos Técnicos (subcláusula 6.4) para
implementar as modificações. Os requisitos dos Processos Técnicos serão complementados da
seguinte forma:
a) Os critérios de teste e avaliação para testar e avaliar as peças modificadas e não modificadas
(unidades de software, componentes e itens de configuração) do sistema devem ser definidos e
documentados.
b) A implementação completa e correcta dos requisitos novos e modificados deve ser
assegurada. Também deve ser assegurado que os requisitos originais, não modificados, não
foram afetados. Os resultados do teste devem ser documentados.
6.4.10.3.4 Revisão / aceitação de manutenção.
6.4.10.3.4.1 O mantenedor deve conduzir revisão (ões) com a organização autorizando
a modificação para determinar a integridade do sistema modificado.
6.4.10.3.4.2 O mantenedor deverá obter aprovação para a conclusão satisfatória da
modificação conforme especificado no contrato.
6.4.10.3.5 Migração.
6.4.10.3.5.1 Se um sistema ou produto de software (incluindo dados) é migrado de um
antigo para um novo ambiente, deve ser assegurado que qualquer produto de software ou dados
produzidos ou modificados durante a migração estejam de acordo com esta Norma.
6.4.10.3.5.2 Um plano de migração deve ser desenvolvido, documentado e executado.
As atividades de planejamento devem incluir usuários. Os itens incluídos no plano devem incluir
o seguinte:
a) Análise de requisitos e definição de migração.
b) Desenvolvimento de ferramentas de migração.
c) Conversão de produto e dados de software.
d) Execução da migração.
e) Verificação de migração.
f) Suporte para o ambiente antigo no futuro.
6.4.10.3.5.3 Os usuários devem receber notificação dos planos e atividades de migração.
As notificações devem incluir o seguinte:
a) Declaração de porque o ambiente antigo não deve mais ser suportado.
b) Descrição do novo ambiente com sua data de disponibilidade.
c) Descrição de outras opções de suporte disponíveis, se houver, uma vez que o suporte para o
ambiente antigo foi removido.
6.4.10.3.5.4 Operações paralelas dos ambientes antigo e novo podem ser conduzidas
para uma transição suave para o novo ambiente. Durante este período, o treinamento necessário
será fornecido conforme especificado no contrato.
6.4.10.3.5.5 Quando a migração programada chegar, a notificação deverá ser enviada a
todos os envolvidos. Associado
documentação do ambiente antigo, logs e código devem ser colocados em arquivos.
6.4.10.3.5.6 Uma revisão pós-operação deve ser realizada para avaliar o impacto da
mudança para o novo ambiente. Os resultados da revisão devem ser enviados às autoridades
competentes para informação, orientação e ação.
6.4.10.3.5.7 Os dados utilizados ou associados ao ambiente antigo devem estar
acessíveis de acordo com os requisitos do contrato para proteção de dados e auditoria aplicáveis
aos dados.
6.4.11 Processo de descarte de software
OBSERVAÇÃO O processo de descarte de software nesta Norma é uma especialização do
processo de descarte da ISO / IEC 15288. Os usuários podem considerar a reivindicação de
conformidade com o processo 15288, e não com o processo desta norma.
6.4.11.1 Propósito
O objetivo do processo de descarte de software é encerrar a existência de uma entidade de
software do sistema.
Esse processo acaba com o suporte ativo da organização de operação e manutenção ou desativa,
desmonta e remove os produtos de software afetados, consignando-os a uma condição final e
deixando o ambiente em uma condição aceitável. Esse processo destrói ou armazena elementos
de software do sistema e produtos relacionados de maneira sólida, de acordo com a legislação,
os acordos, as restrições organizacionais e os requisitos das partes interessadas. Onde
necessário, mantém registros que podem ser monitorados.
OBSERVAÇÃO O objetivo é aposentar os produtos ou serviços de software existentes do sistema,
preservando a integridade das operações organizacionais.
6.4.11.2 Resultados
Como resultado da implementação bem-sucedida do processo de descarte de software:
a) uma estratégia de descarte de software é definida;
b) as restrições de descarte são fornecidas como entradas para os requisitos;
c) os elementos de software do sistema são destruídos ou armazenados;
d) o ambiente é deixado em um estado acordado; e
e) registros permitindo a retenção do conhecimento das ações de descarte e qualquer análise de
impactos de longo prazo estão disponíveis.
6.4.11.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Disposição do Software.
6.4.11.3.1 Planejamento de descarte de software.
6.4.11.3.1.1 Uma estratégia de descarte de software é definida e documentada. Um
plano para remover o apoio ativo das organizações de operação e manutenção deve ser
desenvolvido e documentado. As atividades de planejamento devem incluir usuários. O plano de
descarte de software deve abordar os itens listados abaixo:
a) Cessação de suporte total ou parcial após um determinado período de tempo.
b) Arquivamento do produto de software e sua documentação associada.
c) Responsabilidade por quaisquer futuras questões residuais de suporte.
d) Transição para qualquer novo produto de software, se aplicável.
e) Acessibilidade de cópias arquivadas de dados.
NOTA 1 Define agendas, ações e recursos que: 1) terminam a entrega de serviços de software; 2)
transformar o sistema em, ou retê-lo, em um estado social e fisicamente aceitável, evitando
conseqüentemente efeitos adversos sobre as partes interessadas, a sociedade e o meio
ambiente; 3) levar em conta a saúde, a segurança, a proteção e a privacidade aplicáveis às ações
de descarte e à condição de longo prazo de material físico e informações resultantes.
NOTA 2 As restrições de descarte devem ser fornecidas como entradas para os requisitos das
atividades de descarte planejadas.
6.4.11.3.2 Execução de descarte de software.
6.4.11.3.2.1 O plano de descarte de software deve ser executado.
6.4.11.3.2.2 Os usuários devem receber notificação dos planos e atividades para a
retirada de produtos e serviços de software. As notificações devem incluir o seguinte:
a) Descrição de qualquer substituição ou atualização com sua data de disponibilidade.
b) Declaração de porque o produto de software não deve mais ser suportado.
c) Descrição de outras opções de suporte disponíveis, uma vez que o suporte foi removido.
6.4.11.3.2.3 As operações paralelas do produto de software descontinuado e qualquer
novo devem ser conduzidas para uma transição suave para o novo sistema. Durante este período,
o treinamento do usuário deve ser fornecido conforme especificado no contrato.
6.4.11.3.2.4 Quando a aposentadoria programada chegar, a notificação deverá ser
enviada a todos os envolvidos. Toda documentação, logs e códigos de desenvolvimento
associados devem ser colocados em arquivos, quando apropriado.
6.4.11.3.2.5 Os dados utilizados ou associados ao produto de software desativado
devem estar acessíveis de acordo com os requisitos do contrato para proteção de dados e
auditoria aplicável aos dados.
7 Processos Específicos de Software
7.1 Processos de Implementação de Software
7.1.1 Processo de Implementação de Software
NOTA O Processo de Implementação de Software é uma instância conforme do Processo de
Implementação da ISO / IEC. 15288, especializada para as necessidades específicas de
implementação de um produto ou serviço de software.
7.1.1.1 Propósito
A finalidade do processo de implementação de software é produzir um elemento do sistema
especificado implementado como um produto ou serviço de software. Esse processo transforma
o comportamento especificado, as interfaces e as restrições de implementação em ações que
criam um elemento do sistema implementado como um produto ou serviço de software,
também conhecido como "item de software". Esse processo resulta em um item de software que
satisfaz os requisitos de projeto de arquitetura por meio de verificação e requisitos de partes
interessadas por meio de validação.
7.1.1.2 Resultados
Como resultado da implementação bem-sucedida do processo de implementação de software:
a) uma estratégia de implementação é definida;
b) as limitações de tecnologia de implementação no projeto são identificadas;
c) um item de software é realizado; e
d) um item de software é embalado e armazenado de acordo com um acordo para o seu
fornecimento. Além de suas atividades, o Processo de Implementação de Software possui os
seguintes processos de nível inferior:
⎯ Processo de Análise de Requisitos de Software *
⎯ Processo de Design Arquitetônico de Software *
⎯ Processo de Design Detalhado de Software
⎯ Processo de construção de software
⎯ Processo de Integração de Software *
⎯ Processo de Teste de Qualificação de Software *
NOTA Os usuários da ISO / IEC 15288 podem decidir que os processos marcados por um asterisco
(*) na lista acima devem ser fornecidos pela aplicação recursiva da ISO / IEC 15288, mesmo para
elementos de software do sistema.
7.1.1.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Implementação de Software.
7.1.1.3.1 Estratégia de implementação de software.
7.1.1.3.1.1 Se não estipulado no contrato, o desenvolvedor deve definir ou selecionar
um modelo de ciclo de vida apropriado ao escopo, magnitude e complexidade do projeto. O
modelo do ciclo de vida deve ser composto por etapas e o propósito e os resultados de cada
etapa. As atividades e tarefas do Processo de Implementação de Software devem ser
selecionadas e mapeadas no modelo de ciclo de vida.
OBSERVAÇÃO Essas atividades e tarefas podem se sobrepor ou interagir e podem ser executadas
iterativamente ou recursivamente.
OBSERVAÇÃO Idealmente, isso é realizado usando um modelo de ciclo de vida definido
organizacionalmente.

7.1.1.3.1.2 O implementador deve:
a) Documente as saídas de acordo com o processo de gerenciamento da documentação do
software (subcláusula 7.2.1).
b) Coloque as saídas sob o Processo de Gerenciamento de Configuração de Software (subcláusula
7.2.2) e execute o controle de alterações de acordo com ele.
c) Documentar e resolver problemas e não-conformidades encontrados nos produtos e tarefas
de software de acordo com o Processo de Resolução de Problemas de Software (subseção 7.2.8).
d) Executar processos de suporte conforme especificado no contrato.
e) Estabelecer linhas de base e incorporar itens de configuração em momentos apropriados,
conforme determinado pelo adquirente e pelo fornecedor.
7.1.1.3.1.3 O implementador deve selecionar, adaptar e usar esses padrões, métodos,
ferramentas e linguagens de programação de computador (se não estipulado no contrato) que
são documentados, apropriados e estabelecidos pela organização para executar as atividades do
Processo de Implementação de Software e processos de suporte. NOTA As restrições de
tecnologia de implementação no projeto devem ser identificadas como parte da estratégia de
implementação de software.
7.1.1.3.1.4 O implementador deve desenvolver planos para conduzir as atividades do
processo de Implementação de Software. Os planos devem incluir padrões, métodos,
ferramentas, ações e responsabilidades específicas associadas ao desenvolvimento e
qualificação de todos os requisitos, incluindo proteção e segurança. Se necessário, planos
separados podem ser desenvolvidos. Esses planos devem ser documentados e executados.
7.1.1.3.1.5 Itens não entregáveis podem ser empregados no desenvolvimento ou
manutenção do produto de software. No entanto, deve ser assegurado que a operação e a
manutenção do produto de software de entrega após a sua entrega ao adquirente sejam
independentes de tais itens; caso contrário, esses itens devem ser considerados como
entregáveis.
7.1.2 Processo de Análise de Requisitos de Software
NOTA O Processo de Análise de Requisitos de Software nesta Norma Internacional é um processo
de baixo nível do Processo de Implementação de Software. Os usuários da ISO / IEC 15288 podem
decidir que esse processo deve ser fornecido pelo Processo de Análise de Requisitos da ISO / IEC
15288 em uma aplicação recursiva desse padrão.
7.1.2.1 Propósito
A finalidade do Processo de Análise de Requisitos de Software é estabelecer os requisitos dos
elementos de software do sistema.
7.1.2.2 Resultados
Como resultado da implementação bem sucedida do Processo de Análise de Requisitos de
Software:
a) os requisitos alocados aos elementos de software do sistema e suas interfaces são definidos;
b) os requisitos de software são analisados quanto à correção e testabilidade;
c) o impacto dos requisitos de software no ambiente operacional é entendido;
d) consistência e rastreabilidade são estabelecidas entre os requisitos de software e os requisitos
do sistema;
e) a priorização para implementação dos requisitos de software é definida;
f) os requisitos de software são aprovados e atualizados conforme necessário;
g) as mudanças nos requisitos de software são avaliadas quanto ao custo, cronograma e impacto
técnico; e
h) os requisitos de software são estabelecidos em linhas de base e comunicados a todas as partes
afetadas.
7.1.2.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Análise de Requisitos de
Software.
7.1.2.3.1 Análise de requisitos de software.
7.1.2.3.1.1 O implementador deve estabelecer e documentar os requisitos de
software (incluindo as especificações das características da qualidade) descritos abaixo.
a) Especificações funcionais e de capacidade, incluindo desempenho, características físicas e
condições ambientais sob as quais o item de software deve ser executado.
b) Interfaces externas ao item de software.
c) Requisitos de qualificação.
d) Especificações de segurança, incluindo aquelas relacionadas a métodos de operação e
manutenção, influências ambientais e lesões corporais.
e) Especificações de segurança, incluindo aquelas relacionadas ao comprometimento de
informações sigilosas.
f) Especificações de engenharia de fatores humanos (ergonomia), incluindo aquelas relacionadas
a operações manuais, interações homem-equipamento, limitações de pessoal e áreas que
necessitam de atenção humana concentrada, que são sensíveis a erros humanos e treinamento.
g) Definição de dados e requisitos de banco de dados.
h) Requisitos de instalação e aceitação do produto de software entregue no (s) local (ais) de
operação e manutenção.
i) Requisitos de documentação do usuário.
j) Requisitos de operação e execução do usuário.
k) Requisitos de manutenção do usuário.
NOTA 1 A orientação para a especificação de características de qualidade pode ser encontrada
na ISO / IEC 9126-1.
NOTA 2 A prioridade de implementação dos requisitos de software deve ser determinada.
NOTA 3 Se a usabilidade for um requisito importante, as recomendações para obter o nível
desejado de usabilidade podem ser encontradas em ISO TR 18529, Ergonomia - Ergonomia da
interação do sistema humano - Descrições do processo de ciclo de vida centradas no ser humano.
O Anexo E contém uma visão de processo focada na usabilidade.
7.1.2.3.1.2 O implementador deve avaliar os requisitos de software considerando os
critérios listados abaixo. Os resultados das avaliações devem ser documentados.
a) Rastreabilidade aos requisitos do sistema e projeto do sistema.
b) consistência externa com os requisitos do sistema.
c) consistência interna.
d) testabilidade.
e) Viabilidade do design de software.
f) Viabilidade de operação e manutenção.
 7.1.2.3.1.3 O implementador deve conduzir a (s) revisão (ões) de acordo com a
subcláusula 7.2.6.
OBSERVAÇÃO Após uma avaliação e revisão bem-sucedida, os requisitos de software devem ser
aprovados, estabelecidos em linhas de base e comunicados a todas as partes afetadas. Alterações
subseqüentes na linha de base de requisitos de software devem ser avaliadas quanto ao custo,
cronograma e impacto técnico.
7.1.3 Processo de Design Arquitetônico de Software
NOTA O Processo de Projeto Arquitetônico de Software neste Padrão Internacional é um
processo de baixo nível do Processo de Implementação de Software. Os usuários da ISO / IEC
15288 podem decidir que esse processo deve ser fornecido pelo Processo de Projeto Arquitetural
da ISO / IEC 15288 em uma aplicação recursiva desse padrão.
7.1.3.1 Propósito
O objetivo do Processo de Projeto de Arquitetura de Software é fornecer um design para o
software que implementa e pode ser verificado em relação aos requisitos.
7.1.3.2 Resultados
Como resultado da implementação bem-sucedida do Processo de Design de Arquitetura de
Software:
a) um projeto de arquitetura de software é desenvolvido e baseado na baseline que descreve os
itens de software que implementarão os requisitos de software;
b) interfaces internas e externas de cada item de software são definidas; e
c) a consistência e a rastreabilidade são estabelecidas entre os requisitos de software e o design
de software
7.1.3.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Projeto Arquitetónico de Software.
NOTA Esta atividade é implementada para cada item de software, consistente com um projeto
de arquitetura do sistema.
7.1.3.3.1 Projeto de arquitetura de software.
7.1.3.3.1.1 O implementador deve transformar os requisitos do item de software em
uma arquitetura que descreva sua estrutura de nível superior e identifique os componentes de
software. Deve-se assegurar que todos os requisitos para o item de software sejam alocados a
seus componentes de software e refinados para facilitar o projeto detalhado. A arquitetura do
item de software deve ser documentada.
OBSERVAÇÃO O projeto de arquitetura do software também fornece uma base para verificar os
itens de software, a integração de itens de software entre si e a integração de itens de software
com o restante dos itens do sistema.
7.1.3.3.1.2 O implementador deve desenvolver e documentar um projeto de alto
nível para as interfaces externas ao item de software e entre os componentes de software do
item de software.
7.1.3.3.1.3 O implementador deve desenvolver e documentar um projeto de alto
nível para o banco de dados.
7.1.3.3.1.4 O implementador deve desenvolver e documentar versões preliminares
da documentação do usuário.
7.1.3.3.1.5 O implementador deve definir e documentar os requisitos preliminares de
teste e o cronograma para a Integração de Software.
7.1.3.3.1.6 O implementador deve avaliar a arquitetura do item de software e os
projetos de interface e banco de dados considerando os critérios listados abaixo. Os resultados
das avaliações devem ser documentados.
a) Rastreabilidade aos requisitos do item de software.
b) Consistência externa com os requisitos do item de software.
c) consistência interna entre os componentes de software.
d) Adequação dos métodos de projeto e padrões utilizados.
e) Viabilidade do desenho detalhado.
f) Viabilidade de operação e manutenção.
7.1.3.3.1.7 O implementador deve conduzir a (s) revisão (ões) de acordo com a
subcláusula 7.2.6
7.1.4 Processo de Design Detalhado de Software
NOTA O Processo de Design de Detalhes de Software nesta Norma Internacional é um processo
de baixo nível do Processo de Implementação de Software.
7.1.4.1 Propósito
A finalidade do processo de design detalhado de software é fornecer um design para o software
que implementa e pode ser verificado em relação aos requisitos e à arquitetura de software e é
suficientemente detalhado para permitir a codificação e o teste.
7.1.4.2 Resultados
Como resultado da implementação bem-sucedida do processo de design detalhado do software:
a) um projeto detalhado de cada componente de software, descrevendo as unidades de software
a serem construídas, é desenvolvido;
b) as interfaces externas de cada unidade de software são definidas; e
c) consistência e rastreabilidade são estabelecidas entre o projeto detalhado e os requisitos e
projeto arquitetónico.
7.1.4.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Design Detalhado do Software.
7.1.4.3.1 Projeto detalhado do software.
7.1.4.3.1.1 O implementador deve desenvolver um projeto detalhado para cada
componente de software do item de software. Os componentes de software devem ser refinados
em níveis inferiores contendo unidades de software que podem ser codificadas, compiladas e
testadas. Deve-se assegurar que todos os requisitos de software sejam alocados dos
componentes de software para as unidades de software. O projeto detalhado deve ser
documentado.
7.1.4.3.1.2 O implementador deve desenvolver e documentar um projeto detalhado
para as 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 codificação sem a
necessidade de mais informações.
7.1.4.3.1.3 O implementador deve desenvolver e documentar um projeto detalhado
para o banco de dados.
 7.1.4.3.1.4 O implementador deve atualizar a documentação do usuário conforme
necessário.
7.1.4.3.1.5 O implementador deve definir e documentar os requisitos de teste e o
cronograma para testar as unidades de software. Os requisitos do teste devem incluir o estresse
da unidade de software nos limites de seus requisitos.
7.1.4.3.1.6 O implementador deve atualizar os requisitos de teste e o cronograma
para a Integração de Software.
7.1.4.3.1.7 O implementador deve avaliar o projeto detalhado do software e os
requisitos de teste, considerando os critérios listados abaixo. Os resultados das avaliações devem
ser documentados.
a) Rastreabilidade aos requisitos do item de software;
b) consistência externa com projeto arquitetónico;
c) consistência interna entre componentes de software e unidades de software;
d) Adequação dos métodos de projeto e padrões utilizados;
e) Viabilidade de testes;
f) Viabilidade de operação e manutenção.
7.1.4.3.1.8 O implementador deve conduzir a (s) revisão (ões) de acordo com a
subcláusula 7.2.6.
7.1.5 Processo de construção de software
NOTA O Processo de Construção de Software nesta Norma é um processo de baixo nível do
Processo de Implementação de Software.
7.1.5.1 Propósito
O objetivo do Processo de Construção de Software é produzir unidades de software executáveis
que reflitam adequadamente o design do software.
7.1.5.2 Resultados
Como resultado da implementação bem-sucedida do Processo de Construção de Software:
a) critérios de verificação são definidos para todas as unidades de software em relação aos seus
requisitos;
b) unidades de software definidas pelo design são produzidas;
c) consistência e rastreabilidade são estabelecidas entre unidades de software e requisitos e
design; e
d) verificação das unidades de software em relação aos requisitos e o projeto é realizado.
7.1.5.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Construção de Software.
7.1.5.3.1 Construção de software.
7.1.5.3.1.1 O implementador deve desenvolver e documentar o seguinte:
a) Cada unidade de software e banco de dados.
b) Procedimentos de teste e dados para testar cada unidade de software e banco de dados.
7.1.5.3.1.2 O implementador deve testar cada unidade de software e banco de dados,
garantindo que ela atenda aos seus requisitos. Os resultados do teste devem ser documentados.
7.1.5.3.1.3 O implementador deve atualizar a documentação do usuário conforme
necessário.
7.1.5.3.1.4 O implementador deve atualizar os requisitos de teste e o cronograma
para Integração de Software.
7.1.5.3.1.5 O implementador deve avaliar o código do software e os resultados do
teste, considerando os critérios listados abaixo. Os resultados das avaliações devem ser
documentados.
a) Rastreabilidade aos requisitos e design do item de software.
b) consistência externa com os requisitos e design do item de software.
c) Consistência interna entre os requisitos da unidade.
d) Teste de cobertura de unidades.
e) Adequação dos métodos e padrões de codificação usados.
f) Viabilidade de integração e teste de software.
g) Viabilidade de operação e manutenção.
7.1.6 Processo de Integração de Software
NOTA O Processo de Integração de Software neste Padrão Internacional é um processo de baixo
nível do Processo de Implementação de Software. Os usuários da ISO / IEC 15288 podem decidir
que esse processo deve ser fornecido pelo Processo de Integração da ISO / IEC 15288 em uma
aplicação recursiva dessa norma.
7.1.6.1 Propósito
O objetivo do Processo de Integração de Software é combinar as unidades de software e
componentes de software, produzindo itens de software integrados, consistentes com o design
do software, que demonstram que os requisitos de software funcionais e não funcionais são
atendidos em uma plataforma operacional equivalente ou completa.
7.1.6.2 Resultados
Como resultado da implementação bem-sucedida do processo de integração de software:
a) uma estratégia de integração é desenvolvida para unidades de software consistentes com o
design do software e os requisitos de software priorizados;
b) critérios de verificação para itens de software são desenvolvidos para garantir a conformidade
com os requisitos de software alocados aos itens;
c) os itens de software são verificados utilizando os critérios definidos;
d) itens de software definidos pela estratégia de integração são produzidos;
e) os resultados dos testes de integração são registrados;
f) consistência e rastreabilidade são estabelecidas entre o design de software e os itens de
software; e
g) uma estratégia de regressão é desenvolvida e aplicada para verificar novamente os itens de
software quando ocorrer uma alteração nas unidades de software (incluindo requisitos, design e
código associados).
7.1.6.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Integração de Software.
7.1.6.3.1 Integração de software.
7.1.6.3.1.1 O implementador deve desenvolver um plano de integração 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
documentado.
 7.1.6.3.1.2 O implementador deve integrar as unidades de software e componentes
de software e testar como os agregados são desenvolvidos de acordo com o plano de integração.
Deve-se assegurar que cada agregado satisfaça os requisitos do item de software e que o item
de software seja integrado na conclusão da atividade de integração. A integração e os resultados
dos testes devem ser documentados.
NOTA Uma estratégia de regressão deve ser desenvolvida para ser aplicada para verificar os itens
do software quando for feita uma alteração nas unidades de software (incluindo requisitos,
design e código associados).
7.1.6.3.1.3 O implementador deve atualizar a documentação do usuário conforme
necessário.
7.1.6.3.1.4 O implementador deve desenvolver e documentar, para cada requisito de
qualificação do item de software, um conjunto de testes, casos de teste (entradas, saídas,
critérios de teste) e procedimentos de teste para a realização do Teste de Qualificação de
Software. O desenvolvedor deve garantir que o item de software integrado esteja pronto para o
Teste de Qualificação de Software.
7.1.6.3.1.5 O implementador deve avaliar o plano de integração, design, código,
testes, resultados de testes e documentação do usuário, considerando os critérios listados
abaixo. Os resultados das avaliações devem ser documentados.
a) Rastreabilidade aos requisitos do sistema.
b) consistência externa com os requisitos do sistema.
c) consistência interna.
d) Teste a cobertura dos requisitos do item de software.
e) Adequação dos padrões e métodos de teste utilizados.
f) Conformidade com os resultados esperados.
g) Viabilidade de testes de qualificação de software.
h) Viabilidade de operação e manutenção.
NOTA Os critérios de avaliação devem incluir consistência e rastreabilidade entre o design do
software e os itens do software.
7.1.6.3.1.6 O implementador deve conduzir a (s) revisão (ões) de acordo com a
subcláusula 7.2.6.
7.1.7 Processo de Teste de Qualificação de Software
NOTA O Processo de Teste de Qualificação de Software nesta Norma é um processo de nível
inferior de o processo de implementação de software. Os usuários da ISO / IEC 15288 podem
decidir que esse processo deve ser fornecido pelo Processo de Verificação da ISO / IEC 15288 em
uma aplicação recursiva dessa norma.
7.1.7.1 Propósito
O objetivo do processo de teste de qualificação de software é confirmar se o produto de software
integrado atende aos requisitos definidos.
7.1.7.2 Resultados
Como resultado da implementação bem-sucedida do processo de teste de qualificação de
software:
a) é desenvolvido um critério para o software integrado que demonstra a conformidade com os
requisitos de software;
b) o software integrado é verificado usando os critérios definidos;
c) os resultados dos testes são registrados; e
d) uma estratégia de regressão é desenvolvida e aplicada para testar novamente o software
integrado quando uma alteração nos itens de software é feita.
NOTA Uma estratégia de regressão deve ser desenvolvida para ser aplicada para testar
novamente o software integrado quando uma alteração for feita nos itens de software.
7.1.7.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Teste de Qualificação de Software.
7.1.7.3.1 Teste de qualificação de software.
7.1.7.3.1.1 O implementador deve realizar testes de qualificação de acordo com os
requisitos de qualificação para o item de software. Deve-se assegurar que a implementação de
cada requisito de software seja testada quanto à conformidade. Os resultados do teste de
qualificação devem ser documentados.
7.1.7.3.1.2 O implementador deve atualizar a documentação do usuário conforme
necessário.
7.1.7.3.1.3 O implementador deve avaliar o projeto, código, testes, resultados de
testes e documentação do usuário, considerando os critérios listados abaixo. Os resultados das
avaliações devem ser documentados.
a) Teste a cobertura dos requisitos do item de software.
b) Conformidade com os resultados esperados.
c) Viabilidade de integração do sistema e testes, se realizados.
d) Viabilidade de operação e manutenção.
7.1.7.3.1.4 O implementador deve suportar auditoria (s) de acordo com a subcláusula
7.2.7. Os resultados das auditorias devem ser documentados. Se hardware e software estiverem
em desenvolvimento ou integração, as auditorias podem ser adiadas até o Teste de Qualificação
do Sistema.
7.1.7.3.1.5 Após a conclusão bem-sucedida das auditorias, se conduzida, o
implementador deve atualizar e preparar o produto de software de entrega para Integração do
Sistema, Teste de Qualificação do Sistema, Instalação do Software ou Suporte à Aceitação do
Software, conforme aplicável.
NOTA O Processo de Teste de Qualificação de Software pode ser usado no Processo de
Verificação de Software (subcláusula 7.2.4) ou no Processo de Validação de Software
(subcláusula 7.2.5).
7.2 Processos de Suporte de Software
NOTA Os processos de suporte listados nesta subseção são específicos do software e são
rotulados como processos de suporte de software. Embora eles desempenhem um papel integral
na assistência ao Processo de Implementação de Software, os Processos de Suporte de Software
também podem fornecer serviços para outros processos, por exemplo, os Processos de Acordo,
Teste de Qualificação de Sistemas, Suporte de Aceitação de Software, Operação de Software e o
Processo de Manutenção de Software.
7.2.1 Processo de gerenciamento da documentação do software
NOTA O Processo de Gerenciamento de Documentação do Software é uma especialização do
Processo de Gerenciamento de Informações do Grupo de Processos do Projeto nesta Norma.
7.2.1.1 Propósito
O objetivo do processo de gerenciamento da documentação do software é desenvolver e manter
as informações de software gravadas produzidas por um processo.
NOTA A ISO / IEC 15289 fornece um conteúdo mais detalhado para itens de informações do
processo de ciclo de vida (documentação).
7.2.1.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento da
documentação do software:
a) uma estratégia identificando a documentação a ser produzida durante o ciclo de vida do
produto ou serviço de software é desenvolvida;
b) os padrões a serem aplicados para o desenvolvimento da documentação do software são
identificados;
c) a documentação a ser produzida pelo processo ou projeto é identificada;
d) o conteúdo e propósito de toda a documentação é especificado, revisado e aprovado;
e) a documentação é desenvolvida e disponibilizada de acordo com padrões identificados; e
f) a documentação é mantida de acordo com critérios definidos.
7.2.1.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Gerenciamento da Documentação do
Software.
7.2.1.3.1 Implementação do processo.
7.2.1.3.1.1 Um plano, identificando os documentos a serem produzidos durante o ciclo de vida
do produto de software, deve ser desenvolvido, documentado e implementado. Para
documentação identificada, deve ser tratado o seguinte:
a) título ou nome.
b) Propósito e conteúdo.
c) Público alvo.
d) Procedimentos e responsabilidades para insumos, desenvolvimento, revisão, modificação,
aprovação, produção, armazenamento, distribuição, manutenção e gerenciamento de
configuração.
e) Cronograma para versões intermediárias e final.
7.2.1.3.2 Design e desenvolvimento. Esta atividade consiste nas seguintes tarefas:
7.2.1.3.2.1 Cada documento identificado deve ser projetado de acordo com os padrões de
documentação aplicáveis para mídia, formato, descrição de conteúdo, numeração de página,
posicionamento de figura / tabela, marcação proprietária / de segurança, embalagem e outros
itens de apresentação.
NOTA A documentação pode ser originada e pode terminar em qualquer forma (por exemplo,
verbal, textual, gráfica, numérica) e pode ser armazenada, processada, replicada e transmitida
usando qualquer meio (por exemplo, eletrônico, impresso, magnético, óptico).
7.2.1.3.2.2 A fonte e adequação dos dados de entrada para os documentos devem ser
confirmados. Ferramentas automatizadas de suporte de documentação podem ser usadas.
7.2.1.3.2.3 Os documentos preparados devem ser revisados e editados para formato, conteúdo
técnico e estilo de apresentação em relação aos seus padrões de documentação. Eles devem ser
aprovados para adequação por pessoal autorizado antes da emissão.
7.2.1.3.3 Produção.
7.2.1.3.3.1 Os documentos devem ser produzidos e fornecidos de acordo com o plano. A
produção e distribuição de documentos podem usar papel, mídia eletrônica ou outras mídias. Os
materiais principais devem ser armazenados de acordo com os requisitos de retenção de
registros, segurança, manutenção e backup.
7.2.1.3.3.2 Os controles devem ser estabelecidos de acordo com o Processo de Gerenciamento
da Configuração de Software (subseção 7.2.2).
7.2.1.3.4 Manutenção
7.2.1.3.4.1 As tarefas do Processo de Manutenção de Software, necessárias quando a
documentação deve ser modificada, devem ser executadas (ver subitem 6.4.10). Para os
documentos que estão sob gerenciamento de configuração, as modificações devem ser
gerenciadas de acordo com o Processo de Gerenciamento de Configuração de Software
(subseção 7.2.2).
7.2.2 Processo de gerenciamento de configuração de software
NOTA O Processo de Gerenciamento de Configuração de Software é uma especialização do
Processo de Gerenciamento de Configuração do Grupo de Processo de Projeto nesta Norma.
7.2.2.1 Propósito
O objetivo do Processo de Gerenciamento de Configuração de Software é estabelecer e manter
a integridade dos itens de software de um processo ou projeto e disponibilizá-los às partes
interessadas.
7.2.2.2 Resultados
Como resultado da implementação bem-sucedida do Processo de Gerenciamento de
Configuração de Software:
a) uma estratégia de gerenciamento de configuração de software é desenvolvida;
b) itens gerados pelo processo ou projeto são identificados, definidos e fixados;
c) modificações e liberações dos itens são controladas;
d) modificações e liberações são disponibilizadas às partes afetadas;
e) o status dos itens e modificações são registrados e relatados;
f) a integridade e consistência dos itens é assegurada; e
g) o armazenamento, manuseio e entrega dos itens são controlados.
7.2.2.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Gerenciamento de Configuração de
Software.
7.2.2.3.1 Implementação do processo.
7.2.2.3.1.1 Um plano de gerenciamento de configuração de software deve ser desenvolvido. O
plano deve descrever: as atividades de gerenciamento de configuração; procedimentos e
cronograma para a realização dessas atividades; a(s) organização(ões) responsável(s) pela
realização dessas atividades; e seu relacionamento com outras organizações, como
desenvolvimento ou manutenção de software. O plano deve ser documentado e implementado.
NOTA O plano pode fazer parte do plano de gerenciamento de configuração do sistema.
7.2.2.3.2 Identificação da configuração
7.2.2.3.2.1 Um esquema deve ser estabelecido para identificação de itens de software e suas
versões a serem controladas pelo projeto. Para cada item de software e suas versões, deve ser
identificado o seguinte: a documentação que estabelece a linha de base; as referências de
versão; e outros detalhes de identificação.
7.2.2.3.3 Controle de configuração
7.2.2.3.3.1 Os seguintes itens devem ser realizados: identificação e registro dos pedidos de
mudança; análise e avaliação das mudanças; aprovação ou desaprovação do pedido; e
implementação, verificação e liberação do item de software modificado. Uma trilha de auditoria
deve existir, onde cada modificação, o motivo da modificação e a autorização da modificação
podem ser rastreados. O controle e a auditoria de todos os acessos aos itens de software
controlados que lidam com funções críticas de segurança ou segurança devem ser executados.
NOTA O processo de gerenciamento de resolução de problemas de software pode fornecer
suporte para essa atividade.
7.2.2.3.4 Contabilização do status da configuração
7.2.2.3.4.1 Registros de gerenciamento e relatórios de status que mostram o status e o histórico
de itens de software controlados, incluindo linhas de base, devem ser preparados. Os relatórios
de status devem incluir o número de alterações para um projeto, versões mais recentes de itens
de software, identificadores de lançamento, o número de releases e comparações de
lançamentos.
7.2.2.3.5 Avaliação de configuração.
7.2.2.3.5.1 Os seguintes itens devem ser determinados e assegurados: a integridade funcional
dos itens de software em relação aos seus requisitos e a integridade física dos itens de software
(independentemente de seu design e código refletirem uma descrição técnica atualizada).
7.2.2.3.6 Gerenciamento de liberação e entrega
7.2.2.3.6.1 A liberação e entrega de produtos de software e documentação devem ser
formalmente controladas. Cópias mestras de código e documentação devem ser mantidas
durante a vida útil do produto de software. O código e a documentação que contêm funções
críticas de segurança ou segurança devem ser manuseados, armazenados, empacotados e
entregues de acordo com as políticas das organizações envolvidas.
7.2.3 Processo de garantia de qualidade de software
7.2.3.1 Propósito
A finalidade do processo de garantia da qualidade do software é garantir que os produtos e
processos de trabalho estejam em conformidade com as disposições e planos predefinidos.
7.2.3.2 Resultados
Como resultado da implementação bem-sucedida do processo de garantia de qualidade de
software:
a) uma estratégia para a realização de garantia de qualidade é desenvolvida;
b) evidência de garantia de qualidade de software é produzida e mantida;
c) problemas e / ou não conformidade com os requisitos são identificados e registrados; e
d) a aderência de produtos, processos e atividades às normas, procedimentos e requisitos
aplicáveis é verificada.
7.2.3.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Garantia de Qualidade de Software.
7.2.3.3.1 Implementação do processo
7.2.3.3.1.1 Um processo de garantia de qualidade adequado ao projeto deve ser estabelecido.
Os objetivos do processo de garantia de qualidade devem ser assegurar que os produtos de
software e os processos empregados para fornecer esses produtos de software cumpram com
seus requisitos estabelecidos e sigam seus planos estabelecidos.
7.2.3.3.1.2 O processo de garantia de qualidade deve ser coordenado com a Verificação de
Software relacionada (subcláusula 7.2.4), Validação de Software (subcláusula 7.2.5), Revisão de
Software (subcláusula 7.2.6) e Auditoria de Software (subseção 7.2.7 ) Processos.
7.2.3.3.1.3 Um plano para a condução das atividades e tarefas do processo de garantia de
qualidade deve ser desenvolvido, documentado, implementado e mantido durante a vigência do
contrato. O plano deve incluir o seguinte:
a) Padrões de qualidade, metodologias, procedimentos e ferramentas para executar as
atividades de garantia de qualidade (ou suas referências na documentação oficial da
organização).
b) Procedimentos para revisão de contratos e coordenação dos mesmos.
c) Procedimentos para identificação, coleta, arquivamento, manutenção e disposição de
registros de qualidade.
d) Recursos, cronograma e responsabilidades pela condução das atividades de garantia da
qualidade.
e) Atividades e tarefas selecionadas de processos de suporte, como Verificação de Software
(subcláusula 7.2.4), Validação de Software (subcláusula 7.2.5), Revisão de Software (subcláusula
7.2.6), Auditoria de Software (subcláusula 7.2.7) e Software Resolução de Problemas (subseção
7.2.8).
7.2.3.3.1.4 Atividades e tarefas de garantia de qualidade programadas e em andamento devem
ser executadas. Quando forem detectados problemas ou não-conformidades com os requisitos
do contrato, eles devem ser documentados e servir como entrada para o Processo de Resolução
de Problemas (subseção 7.2.8). Registros dessas atividades e tarefas, sua execução, problemas e
resoluções de problemas devem ser preparados e mantidos.
7.2.3.3.1.5 Os registros das atividades e tarefas de garantia da qualidade devem ser
disponibilizados ao adquirente conforme especificado no contrato.
7.2.3.3.1.6 Deve-se assegurar que as pessoas responsáveis por assegurar a conformidade com os
requisitos do contrato tenham liberdade organizacional, recursos e autoridade para permitir
avaliações objetivas e para iniciar, efetuar, resolver e verificar a resolução de problemas.
7.2.3.3.2 Garantia do produto. Esta atividade consiste nas seguintes tarefas:
7.2.3.3.2.1 Deve-se assegurar que todos os planos exigidos pelo contrato estejam
documentados, cumpram o contrato, sejam mutuamente consistentes e estejam sendo
executados conforme necessário.
7.2.3.3.2.2 Deve ser assegurado que os produtos de software e a documentação relacionada
cumprem com o contrato e aderem aos planos.
7.2.3.3.2.3 Na preparação para a entrega dos produtos de software, deve-se assegurar que eles
satisfizeram plenamente seus requisitos contratuais e são aceitáveis para o adquirente.
7.2.3.3.3 Garantia do processo
7.2.3.3.3.1 Deve-se assegurar que os processos de ciclo de vida de software (processos de
fornecimento, desenvolvimento, operação, manutenção e suporte, incluindo garantia de
qualidade) utilizados para o projeto cumprem o contrato e aderem aos planos.
7.2.3.3.3.2 Deve-se assegurar que as práticas internas de engenharia de software, ambiente de
desenvolvimento, ambiente de teste e bibliotecas cumpram o contrato.
7.2.3.3.3.3 Deve ser assegurado que os requisitos aplicáveis ao contrato principal sejam
transmitidos ao subcontratante, e que os produtos de software do subcontratado satisfaçam os
requisitos do contrato principal.
7.2.3.3.3.4 Deve ser assegurado que o adquirente e outras partes recebem o apoio e cooperação
necessários de acordo com o contrato, negociações e planos.
7.2.3.3.3.5 Deve-se assegurar que as medições de produto e processo de software estão de
acordo com os padrões e procedimentos estabelecidos.
7.2.3.3.3.6 Deve ser assegurado que o pessoal designado tenha a habilidade e os conhecimentos
necessários para atender aos requisitos do projeto e receber qualquer treinamento necessário.
7.2.3.3.4 Garantia de sistemas de qualidade.
7.2.3.3.4.1 Atividades adicionais de gerenciamento da qualidade podem ser asseguradas de
acordo com as cláusulas da ISO 9001.
7.2.4 Processo de Verificação de Software
7.2.4.1 Propósito
O objetivo do processo de verificação de software é confirmar se cada produto de trabalho de
software e / ou serviço de um processo ou projeto reflete adequadamente os requisitos
especificados.
7.2.4.2 Resultados
Como resultado da implementação bem-sucedida do processo de verificação de software:
a) uma estratégia de verificação é desenvolvida e implementada;
b) os critérios para verificação de todos os produtos de trabalho de software necessários são
identificados;
c) as atividades de verificação necessárias são realizadas;
d) os defeitos são identificados e registrados; e
e) os resultados das atividades de verificação são disponibilizados para o cliente e outras partes
envolvidas.
7.2.4.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Verificação de Software.
7.2.4.3.1 Implementação do processo.
7.2.4.3.1.1 Uma determinação deve ser feita se o projeto exigir um esforço de verificação e o
grau de independência organizacional desse esforço necessário. Os requisitos do projeto devem
ser analisados quanto à criticidade. A criticidade pode ser medida em termos de:
a) O potencial de um erro não detectado em um sistema ou requisito de software por causar
morte ou lesão pessoal, falha na missão ou perda ou dano financeiro ou catastrófico de
equipamento.
b) A maturidade e os riscos associados à tecnologia de software a ser utilizada.
c) Disponibilidade de fundos e recursos.
7.2.4.3.1.2 Se o projeto exigir um esforço de verificação, um processo de verificação deve ser
estabelecido para verificar o produto de software.
7.2.4.3.1.3 Se o projeto exigir um esforço de verificação independente, uma organização
qualificada responsável por conduzir a verificação deve ser selecionada. Esta organização deve
ter a certeza da independência e autoridade para realizar as atividades de verificação.
7.2.4.3.1.4 Com base no escopo, magnitude, complexidade e análise de criticidade acima, as
atividades do ciclo de vida alvo e os produtos de software que requerem verificação devem ser
determinados. As atividades e tarefas de verificação definidas na subcláusula 7.2.4.3.2, incluindo
métodos, técnicas e ferramentas associadas para executar as tarefas, devem ser selecionadas
para as atividades do ciclo de vida de destino e produtos de software.
7.2.4.3.1.5 Com base nas tarefas de verificação, conforme determinado, um plano de verificação
deve ser desenvolvido e documentado. O plano deve abordar as atividades do ciclo de vida e os
produtos de software sujeitos a verificação, as tarefas de verificação necessárias para cada
atividade de ciclo de vida e produto de software e recursos, responsabilidades e cronograma
relacionados. O plano deve abordar procedimentos para encaminhar relatórios de verificação
para o adquirente e outras organizações envolvidas.
7.2.4.3.1.6 O plano de verificação deve ser implementado. Problemas e não-conformidades
detectados pelo esforço de verificação devem ser inseridos no Processo de Resolução de
Problemas de Software (subseção 7.2.8). Todos os problemas e não conformidades devem ser
resolvidos. Os resultados das atividades de verificação devem ser disponibilizados para o
adquirente e outras organizações envolvidas.
7.2.4.3.2 Verificação.
7.2.4.3.2.1 Verificação de requisitos. Os requisitos devem ser verificados considerando os
critérios listados abaixo:
a) Os requisitos do sistema são consistentes, viáveis e testáveis.
b) Os requisitos do sistema foram alocados adequadamente a itens de hardware, itens de
software e operações manuais de acordo com os critérios de design.
c) Os requisitos de software são consistentes, viáveis, testáveis e refletem com precisão os
requisitos do sistema.
d) Os requisitos de software relacionados a segurança, segurança e criticidade estão corretos,
conforme mostrado por métodos adequadamente rigorosos.
7.2.4.3.2.2 Verificação de projeto. O projeto deve ser verificado considerando os critérios
listados abaixo:
a) O design é correto e consistente e rastreável aos requisitos.
b) O design implementa a sequência adequada de eventos, entradas, saídas, interfaces, fluxo
lógico, alocação de orçamentos e orçamentos de dimensionamento e definição, isolamento e
recuperação de erros.
c) O design selecionado pode ser derivado de requisitos.
d) O projeto implementa a segurança, segurança e outros requisitos críticos corretamente,
conforme mostrado por métodos adequadamente rigorosos.
7.2.4.3.2.3 Verificação de código. O código deve ser verificado considerando os critérios listados
abaixo:
a) O código é rastreável para design e requisitos, testável, correto e compatível com os requisitos
e padrões de codificação.
b) O código implementa sequência de eventos adequada, interfaces consistentes, dados corretos
e fluxo de controle, integridade, tempo de alocação apropriado e orçamentos de
dimensionamento e definição, isolamento e recuperação de erros.
c) O código selecionado pode ser derivado do design ou dos requisitos.
d) O código implementa a segurança, segurança e outros requisitos críticos corretamente,
conforme mostrado por métodos adequadamente rigorosos.
7.2.4.3.2.4 Verificação de integração. A integração deve ser verificada considerando os critérios
listados abaixo:
a) Os componentes e unidades de software de cada item de software foram completamente e
corretamente integrados ao item de software.
b) Os itens de hardware, itens de software e operações manuais do sistema foram
completamente e corretamente integrados ao sistema.
c) As tarefas de integração foram executadas de acordo com um plano de integração.
7.2.4.3.2.5 Verificação da documentação. A documentação deve ser verificada considerando os
critérios listados abaixo:
a) A documentação é adequada, completa e consistente.
b) A preparação da documentação é oportuna.
c) O gerenciamento de configuração de documentos segue os procedimentos especificados.
7.2.5 Processo de validação de software
7.2.5.1 Propósito
A finalidade do processo de validação de software é confirmar que os requisitos para um uso
específico pretendido do produto de trabalho de software foram atendidos
7.2.5.2 Resultados
Como resultado da implementação bem-sucedida do processo de validação de software:
a) uma estratégia de validação é desenvolvida e implementada;
b) critérios para validação de todos os produtos de trabalho necessários são identificados;
c) as atividades de validação necessárias são realizadas;
d) os problemas são identificados e registrados;
e) é fornecida evidência de que os produtos de trabalho de software desenvolvidos são
adequados para o uso pretendido; e
f) os resultados das atividades de validação são disponibilizados para o cliente e outras partes
envolvidas.
7.2.5.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades e tarefas de acordo com as políticas e
procedimentos aplicáveis da organização com relação ao Processo de Validação de Software.
7.2.5.3.1 Implementação do processo.
7.2.5.3.1.1 Uma determinação deve ser feita se o projeto exigir um esforço de validação e o grau
de independência organizacional desse esforço necessário.
7.2.5.3.1.2 Se o projeto justificar um esforço de validação, um processo de validação deve ser
estabelecido para validar o sistema ou produto de software. Tarefas de validação definidas
abaixo, incluindo métodos associados, técnicas e ferramentas para executar as tarefas, devem
ser selecionadas.
7.2.5.3.1.3 Se o projeto justificar um esforço independente, uma organização qualificada
responsável pela condução do esforço deve ser selecionada. O condutor deve ter a certeza da
independência e autoridade para executar as tarefas de validação.
7.2.5.3.1.4 Um plano de validação deve ser desenvolvido e documentado. O plano deve incluir,
mas não está limitado a, o seguinte:
a) Itens sujeitos a validação.
b) Tarefas de validação a serem realizadas.
c) Recursos, responsabilidades e cronograma para validação.
d) Procedimentos para encaminhar relatórios de validação ao adquirente e outras partes.
7.2.5.3.1.5 O plano de validação deve ser implementado. Problemas e não-conformidades
detectados pelo esforço de validação devem ser inseridos no Processo de Resolução de
Problemas de Software (subseção 7.2.8). Todos os problemas e não conformidades devem ser
resolvidos. Os resultados das atividades de validação devem ser disponibilizados para o
adquirente e outras organizações envolvidas.
7.2.5.3.2 Validação.
NOTA Outros meios além de testes (como análise, modelagem, simulação, etc.) podem ser
empregados para validação.
7.2.5.3.2.1 Prepare requisitos de teste selecionados, casos de teste e especificações de teste para
analisar os resultados do teste.
7.2.5.3.2.2 Assegure-se de que esses requisitos de teste, casos de teste e especificações de teste
reflitam os requisitos específicos para o uso específico pretendido.
7.2.5.3.2.3 Realizar os testes nas subseções 7.2.5.3.2.1 e 7.2.5.3.2.2, incluindo:
a) Teste com insumos de estresse, limite e singular;
b) Testar o produto de software por sua capacidade de isolar e minimizar o efeito de erros; isto
é, degradação graciosa em caso de falha, solicitação de assistência do operador sob condições
de estresse, limite e singular;
c) Testar que usuários representativos podem realizar com sucesso as tarefas pretendidas usando
o produto de software.
7.2.5.3.2.4 Valide se o produto de software satisfaz o uso pretendido.
7.2.5.3.2.5 Teste o produto de software conforme apropriado nas áreas selecionadas do
ambiente de destino.

7.2.6 Processo de Revisão de Software
7.2.6.1 Propósito
O objetivo do Processo de Revisão de Software é manter um entendimento comum com as partes
interessadas do progresso em relação aos objetivos do acordo e o que deve ser feito para ajudar
a garantir o desenvolvimento de um produto que satisfaça as partes interessadas. As revisões de
software estão nos níveis técnico e de gerenciamento de projetos e são realizadas durante toda
a vida do projeto
7.2.6.2 Resultados
Como resultado da implementação bem sucedida do Processo de Revisão de Software:
a) a gestão e revisões técnicas são realizadas com base nas necessidades do projeto;
b) o status e os produtos de uma atividade de um processo são avaliados através de atividades
de revisão;
c) os resultados da revisão são divulgados a todas as partes afetadas;
d) itens de ação resultantes de revisões são rastreados até o fechamento; e
e) riscos e problemas são identificados e registrados.
7.2.6.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com respeito ao Processo de Revisão de Software.
7.2.6.3.1 Implementação do processo.
7.2.6.3.1.1 Revisões periódicas devem ser realizadas em marcos predeterminados, conforme
especificado no (s) plano (s) do projeto. As partes interessadas devem determinar a necessidade
de quaisquer revisões ad hoc em que partes concordantes possam participar.
7.2.6.3.1.2 Todos os recursos necessários para conduzir as revisões devem ser fornecidos. Esses
recursos incluem pessoal, localização, instalações, hardware, software e ferramentas.
7.2.6.3.1.3 As partes que participam de uma revisão devem concordar com os seguintes itens em
cada revisão: agenda da reunião, produtos de software (resultados de uma atividade) e
problemas a serem analisados; escopo e procedimentos; e critérios de entrada e saída para a
revisão.
7.2.6.3.1.4 Os problemas detectados durante as revisões devem ser registrados e inseridos no
Processo de Resolução de Problemas de Software (subcláusula 7.2.8), conforme necessário.
7.2.6.3.1.5 Os resultados da revisão devem ser documentados e distribuídos. Essa comunicação
inclui a adequação da revisão (por exemplo, aprovação, desaprovação ou aprovação
contingente) dos resultados da revisão.
7.2.6.3.1.6 As partes participantes devem concordar com o resultado da revisão e com quaisquer
responsabilidades de itens de ação e critérios de fechamento.
7.2.6.3.2 Revisões de gerenciamento de projetos.
7.2.6.3.2.1 O status do projeto deve ser avaliado em relação aos planos de projeto, cronogramas,
padrões e diretrizes aplicáveis. O resultado da revisão deve ser considerado pela gerência
apropriada e deve prever o seguinte:
a) Fazer as atividades progredirem de acordo com o planejado, com base em uma avaliação da
atividade ou status do produto de software.
b) Manter o controle global do projeto por meio da alocação adequada de recursos.
c) Alterar a direção do projeto ou determinar a necessidade de planejamento alternativo.
d) Avaliar e gerenciar as questões de risco que possam comprometer o sucesso do projeto.
7.2.6.3.3 Revisões Técnicas
7.2.6.3.3.1 Revisões técnicas devem ser realizadas para avaliar os produtos de software ou
serviços sob consideração e fornecer evidência de que:
a) Eles estão completos.
b) Eles cumprem com seus padrões e especificações.
c) Alterações a eles são implementadas corretamente e afetam apenas as áreas identificadas
pelo Processo de Gerenciamento da Configuração (subseção 7.2.2).
d) Eles estão aderindo aos horários aplicáveis.
e) Eles estão prontos para a próxima atividade planejada.
f) O desenvolvimento, operação ou manutenção está sendo conduzido de acordo com os planos,
cronogramas, padrões e diretrizes do projeto.
7.2.7 Processo de Auditoria de Software
7.2.7.1 Propósito
O objetivo do Processo de Auditoria de Software é determinar independentemente a
conformidade de produtos e processos selecionados com os requisitos, planos e contratos,
conforme apropriado.
7.2.7.2 Resultados
Como resultado da implementação bem-sucedida do processo de auditoria de software:
a) uma estratégia de auditoria é desenvolvida e implementada;
b) a conformidade de produtos de trabalho de software selecionados e / ou serviços ou processos
com requisitos, planos e contratos é determinada de acordo com a estratégia de auditoria;
c) as auditorias são conduzidas por uma parte independente apropriada; e
d) os problemas detectados durante uma auditoria são identificados e comunicados aos
responsáveis pela ação corretiva e pela resolução.
7.2.7.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Auditoria do Software.
7.2.7.3.1 Implementação do processo
7.2.7.3.1.1 As auditorias devem ser realizadas em marcos predeterminados, conforme
especificado no (s) plano (s) do projeto.
7.2.7.3.1.2 O pessoal de auditoria não deve ter responsabilidade direta pelos produtos de
software e atividades que eles auditam.
7.2.7.3.1.3 Todos os recursos necessários para conduzir as auditorias devem ser acordados pelas
partes. Esses recursos incluem pessoal de suporte, localização, instalações, hardware, software
e ferramentas.
7.2.7.3.1.4 As partes devem concordar com os seguintes itens em cada auditoria: agenda;
produtos de software (e resultados de uma atividade) a serem revisados; escopo e
procedimentos de auditoria; e critérios de entrada e saída para a auditoria.
7.2.7.3.1.5 Os problemas detectados durante as auditorias devem ser registrados e inseridos no
Processo de Resolução de Problemas de Software (subseção 7.2.8), conforme necessário.
7.2.7.3.1.6 Após a conclusão de uma auditoria, os resultados da auditoria devem ser
documentados e fornecidos à parte auditada. A parte auditada deve reconhecer à parte auditada
quaisquer problemas encontrados na auditoria e nas resoluções de problemas relacionadas
planejadas.
7.2.7.3.1.7 As partes devem concordar com o resultado da auditoria e com quaisquer
responsabilidades de itens de ação e critérios de fechamento.
7.2.7.3.2 Auditoria de software
7.2.7.3.2.1 Auditorias de software devem ser realizadas para garantir que:
a) Como codificados, os produtos de software (como um item de software) refletem a
documentação de design.
b) Os requisitos de revisão e teste de aceitação prescritos pela documentação são adequados
para a aceitação dos produtos de software.
c) Os dados de teste estão em conformidade com a especificação.
d) Os produtos de software foram testados com sucesso e atendem às suas especificações.
e) Os relatórios de teste estão corretos e as discrepâncias entre os resultados reais e esperados
foram resolvidas.
f) A documentação do usuário está em conformidade com os padrões especificados.
g) As atividades foram conduzidas de acordo com os requisitos, planos e contratos aplicáveis.
h) Os custos e cronogramas aderem aos planos estabelecidos.
7.2.8 Processo de resolução de problemas de software
7.2.8.1 Propósito
A finalidade do Processo de Resolução de Problemas de Software é garantir que todos os
problemas descobertos sejam identificados, analisados, gerenciados e controlados para a
resolução.
7.2.8.2 Resultados
Como resultado da implementação bem-sucedida do processo de resolução de problemas de
software:
a) uma estratégia de gerenciamento de problemas é desenvolvida;
b) os problemas são registrados, identificados e classificados;
c) os problemas são analisados e avaliados para identificar solução (ões) aceitáveis;
d) resolução de problemas é implementada;
e) os problemas são rastreados até o fechamento;
f) o estado de todos os problemas relatados é conhecido.
NOTA O Processo de Resolução de Problemas de Software pode ser usado ou facilmente
adaptado para gerenciar, rastrear e controlar solicitações de mudança de software.
7.2.8.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Resolução de Problemas de Software.
7.2.8.3.1 Implementação do processo.
7.2.8.3.1.1 Um processo de resolução de problemas deve ser estabelecido para lidar com todos
os problemas (incluindo não-conformidades) detectados nos produtos e atividades de software.
O processo deve obedecer aos seguintes requisitos:
a) O processo deve ser de malha fechada, garantindo que: todos os problemas detectados sejam
prontamente reportados e inseridos no Processo de Resolução de Problemas; ação é iniciada
sobre eles; as partes relevantes são avisadas da existência do problema, conforme apropriado;
as causas são identificadas, analisadas e, quando possível, eliminadas; resolução e disposição são
alcançadas; status é rastreado e relatado; e registros dos problemas são mantidos conforme
estipulado no contrato.
b) O processo deve conter um esquema para categorizar e priorizar os problemas. Cada problema
deve ser classificado pela categoria e prioridade para facilitar a análise de tendências e resolução
de problemas.
c) A análise deve ser realizada para detectar tendências nos problemas relatados.
d) As resoluções e disposições de problemas devem ser avaliadas: para avaliar se os problemas
foram resolvidos, se as tendências adversas foram revertidas e se as alterações foram
implementadas corretamente nos produtos e atividades de software apropriados; e para
determinar se problemas adicionais foram introduzidos.
7.2.8.3.2 Resolução de problemas:
7.2.8.3.2.1 Quando problemas (incluindo não-conformidades) forem detectados em um produto
de software ou em uma atividade, um relatório de problema deve ser preparado para descrever
cada problema detectado. O relatório de problemas deve ser usado como parte do processo de
ciclo fechado descrito acima: desde a detecção do problema, passando pela investigação, análise
e resolução do problema e sua causa, até a detecção de tendências entre os problemas.
7.3 Processos de Reutilização de Software
OBSERVAÇÃO Os usuários destas Normas Internacionais que desejam adotar práticas de
reutilização de software organizacional podem desejar complementar as provisões desta Norma
Internacional com aquelas do IEEE Std 1517 ™ -1999, Padrão IEEE para Tecnologia da Informação
- Processos de Ciclo de Vida de Software - Processos de Reutilização.
7.3.1 Processo de Engenharia de Domínio
7.3.1.1 Propósito
O propósito do Processo de Engenharia de Domínio é desenvolver e manter modelos de domínio,
arquiteturas de domínio e ativos para o domínio.
7.3.1.2 Resultados
Como resultado da implementação bem-sucedida do processo de engenharia de domínio:
a) as formas de representação para os modelos de domínio e as arquiteturas de domínio são
selecionadas;
b) os limites do domínio e suas relações com outros domínios são estabelecidos;
c) um modelo de domínio que captura os recursos essenciais comuns, recursos, conceitos e
funções no domínio são desenvolvidos;
d) uma arquitetura de domínio descrevendo a família de sistemas dentro do domínio, incluindo
suas semelhanças e variabilidades, é desenvolvida;
e) ativos pertencentes ao domínio são especificados;
f) os bens pertencentes ao domínio são adquiridos ou desenvolvidos e mantidos ao longo de seus
ciclos de vida; e
g) os modelos e arquiteturas de domínio são mantidos ao longo de seus ciclos de vida.
NOTA 1 Engenharia de domínio é uma abordagem baseada em reutilização para definir o escopo
(ou seja, definição de domínio), especificando a estrutura (ou seja, arquitetura de domínio) e
construindo os ativos (por exemplo, requisitos, projetos, código de software, documentação)
para uma classe. de sistemas, subsistemas ou aplicativos.
NOTA 2 O Processo de Engenharia de Domínio pode se sobrepor a processos de desenvolvimento
e manutenção que utilizam ativos produzidos pelo Processo de Engenharia de Domínio.
7.3.1.3 Atividades e tarefas O projeto deve implementar as seguintes atividades e tarefas de
acordo com as políticas e procedimentos aplicáveis da organização com relação ao Processo de
Engenharia de Domínio.
NOTA IEEE Std 1517 ™, Padrão IEEE para Tecnologia da Informação - Processos de Ciclo de Vida
de Software - Reutilizar Processos, fornece um conjunto mais detalhado de atividades e tarefas
que estão alinhadas com as atividades e tarefas mostradas abaixo.
7.3.1.3.1 Implementação do processo.
7.3.1.3.1.1 O engenheiro de domínio deve criar e executar um plano de engenharia de domínio.
7.3.1.3.1.2 O engenheiro de domínio deve selecionar o (s) formulário (s) de representação a ser
utilizado para arquiteturas e modelos de domínio.
7.3.1.3.1.3 O engenheiro de domínio deve estabelecer procedimentos para receber, resolver e
fornecer feedback ao gerente de ativos sempre que ocorrerem problemas ou solicitações de
mudança para os ativos desenvolvidos pelo engenheiro de domínio.
7.3.1.3.2 Análise de domínio.
7.3.1.3.2.1 O engenheiro de domínio deve definir os limites do domínio e as relações entre este
domínio e outros domínios.
7.3.1.3.2.2 O engenheiro de domínio deve identificar as necessidades atuais e antecipadas das
partes interessadas dos produtos de software dentro deste domínio.
7.3.1.3.2.3 O engenheiro de domínio deve construir os modelos de domínio utilizando os
formulários de representação selecionados na Atividade de Implementação do Processo para
este processo.
7.3.1.3.2.4 O engenheiro de domínio deve construir um vocabulário que forneça a terminologia
para descrever os conceitos importantes do domínio e as relações entre ativos similares ou
comuns do domínio.
7.3.1.3.2.5 O engenheiro de domínio deve classificar e documentar os modelos de domínio.
7.3.1.3.2.6 O engenheiro de domínio deve avaliar os modelos de domínio e o vocabulário de
domínio de acordo com as disposições da técnica de modelagem selecionada e de acordo com
os procedimentos de aceitação e certificação de ativos da organização.
7.3.1.3.2.7 O engenheiro de domínio deve conduzir a (s) análise (ões) de análise de domínio.
Desenvolvedores de software, gerentes de ativos, especialistas em domínio e usuários devem ser
incluídos nas revisões.
7.3.1.3.2.8 O engenheiro de domínio deve submeter os modelos de domínio ao gerente de
ativos.
7.3.1.3.3 Projeto de domínio.
7.3.1.3.3.1 O engenheiro de domínio deve criar e documentar a arquitetura do domínio,
consistente com o modelo de domínio e seguindo os padrões da organização.
7.3.1.3.3.2 A arquitetura do domínio deve ser avaliada de acordo com as disposições da técnica
de projeto de arquitetura selecionada e os procedimentos de aceitação e certificação de ativos
da organização.
7.3.1.3.3.3 Para cada entidade selecionada para ser projetada para reutilização, o engenheiro de
domínio deve desenvolver e documentar uma especificação de ativo.
7.3.1.3.3.4 Para cada ativo especificado, a especificação deve ser avaliada de acordo com os
procedimentos de aceitação e certificação de ativos da organização.
7.3.1.3.3.5 O engenheiro de domínio deve conduzir revisão (ões) de projeto de domínio.
Desenvolvedores de software, especialistas de domínio e gerentes de ativos devem ser incluídos
nas revisões.
7.3.1.3.3.6 O engenheiro de domínio deve submeter a arquitetura do domínio ao gerente de
ativos.
7.3.1.3.4 Provisão de ativos. Para cada ativo desenvolvido ou adquirido, essa atividade consiste
nas seguintes tarefas:
7.3.1.3.4.1 O engenheiro de domínio deve obter o ativo por aquisição ou por desenvolvimento.
7.3.1.3.4.2 O engenheiro de domínio deve documentar e classificar o ativo.
7.3.1.3.4.3 O engenheiro de domínio deve avaliar o ativo de acordo com os procedimentos de
aceitação e certificação de ativos da organização.
7.3.1.3.4.4 O engenheiro de domínio deve conduzir a(s) revisão(ões) do ativo. Desenvolvedores
de software e gerentes de ativos devem ser incluídos nas revisões.
7.3.1.3.4.5 O engenheiro de domínio deve submeter o ativo ao gerente de ativos.
7.3.1.3.5 Manutenção de ativos. A seguinte tarefa relacionada à reutilização é adicionada a este
processo de manutenção de software quando é aplicada para manter um ativo.
7.3.1.3.5.1 Ao analisar solicitações de modificação de ativos e escolher opções de
implementação, o engenheiro de domínio deve considerar:
a) Conformidade com os modelos de domínio e a arquitetura de domínio;
b) Impacto nos sistemas e produtos de software que usam o ativo;
c) Impacto nos futuros usuários do ativo;
d) Impacto na reutilização do ativo.
7.3.2 Reutilizar o processo de gerenciamento de ativos
7.3.2.1 Propósito
O objetivo do processo de gerenciamento de ativos de reutilização é gerenciar a vida útil dos
ativos reutilizáveis desde a concepção até a aposentadoria.
7.3.2.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento de ativos de
reutilização:
a) uma estratégia de gerenciamento de ativos é documentada;
b) um esquema de classificação de ativos é estabelecido;
c) critérios para aceitação de ativos, certificação e aposentadoria são definidos;
d) um mecanismo de armazenamento e recuperação de ativos é operado;
e) o uso de ativos é registrado;
f) as alterações nos ativos são controladas e
g) usuários de ativos são notificados de problemas detectados, modificações feitas, novas
versões criadas e exclusão de ativos do mecanismo de armazenamento e recuperação.
7.3.2.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas e procedimentos
aplicáveis da organização com relação ao Processo de Gerenciamento de Ativos de Reutilização.
7.3.2.3.1 Implementação do processo.
7.3.2.3.1.1 O gestor de ativos deve criar um plano de gerenciamento de ativos para
definir os recursos e procedimentos para o gerenciamento de ativos.
7.3.2.3.1.2 O gestor de ativos deve executar o plano.
7.3.2.3.1.3 O plano de gerenciamento de ativos deve ser revisado de acordo com o
Processo de Revisão de Software. Engenheiros de domínio e administradores de programas de
reutilização devem ser incluídos na revisão.
7.3.2.3.2 Definição de armazenamento e recuperação de ativos.
7.3.2.3.2.1 O gestor de ativos deve implementar e manter um mecanismo de
armazenamento e recuperação de ativos.
7.3.2.3.2.2 O gestor de ativos deve desenvolver, documentar e manter um esquema de
classificação a ser usado na classificação dos ativos.
7.3.2.3.2.3 O gestor de ativos deve conduzir a (s) análise (ões) do mecanismo de
armazenamento e recuperação de ativos de acordo com o Processo de Revisão do Software. Os
administradores do programa de reutilização e os engenheiros de domínio devem ser incluídos
na (s) revisão (ões).
7.3.2.3.3 Gerenciamento e controle de ativos.
7.3.2.3.3.1 Para cada ativo submetido ao gestor de ativos, o ativo deve ser avaliado com
base nos critérios de aceitação e certificação de ativos.
7.3.2.3.3.2 Para cada ativo aceito, ele deve ser disponibilizado para reutilização através
do mecanismo de armazenamento e recuperação de ativos.
7.3.2.3.3.3 O ativo deve ser classificado de acordo com o esquema de classificação de
reutilização, se houver.
7.3.2.3.3.4 O gerente de ativos deve executar o gerenciamento de configuração para o
ativo usando o Processo de Gerenciamento de Configuração de Software.
7.3.2.3.3.5 O gestor de ativos deve acompanhar cada reutilização do ativo e reportar ao
engenheiro de domínio informações sobre as reutilizações reais do ativo.
7.3.2.3.3.6 O gerente de ativos deve encaminhar solicitações de modificação de ativos
e relatórios de problemas recebidos de reutilizadores de ativos para o engenheiro de domínio
para planos e ações de revisão e correção / modificação.
7.3.2.3.3.7 O gerente de ativos deve monitorar e registrar essas solicitações / relatórios
de ativos e as ações subseqüentes executadas.
7.3.2.3.3.8 O gerente de ativos deve notificar todos os reutilizadores de ativos e o
engenheiro de domínio sobre os problemas detectados no ativo, as modificações feitas no ativo,
as novas versões do ativo e a exclusão do ativo
do mecanismo de armazenamento e recuperação de ativos.
7.3.2.3.3.9 O gestor de ativos deve retirar ativos do mecanismo de armazenamento e
recuperação de ativos de acordo com os procedimentos e critérios de baixa de ativos.
7.3.3 Reutilizar o processo de gerenciamento de programas
7.3.3.1 Propósito
O objetivo do processo de gerenciamento do programa de reutilização é planejar, estabelecer,
gerenciar, controlar e monitorar o programa de reutilização de uma organização e explorar
sistematicamente as oportunidades de reutilização.
7.3.3.2 Resultados
Como resultado da implementação bem-sucedida do processo de gerenciamento do programa
de reutilização:
a) a estratégia de reutilização da organização, incluindo sua finalidade, escopo, metas e objetivos,
é definida;
b) os domínios para possíveis oportunidades de reutilização são identificados;
c) a capacidade sistemática de reutilização da organização é avaliada;
d) o potencial de reutilização de cada domínio é avaliado;
e) as propostas de reutilização são avaliadas para garantir que o produto de reutilização seja
adequado para a aplicação proposta;
f) a estratégia de reutilização é implementada na organização;
g) mecanismos de feedback, comunicação e notificação que operam entre as partes afetadas são
estabelecidos; e
h) o programa de reutilização é monitorado e avaliado.
OBSERVAÇÃO As partes afetadas podem incluir administradores do programa de reutilização,
gerentes de ativos, engenheiros de domínio, desenvolvedores, operadores e mantenedores.
7.3.3.3 Atividades e tarefas
O projeto deve implementar as seguintes atividades de acordo com as políticas da organização
aplicáveis e procedimentos relativos ao Processo de Gerenciamento de Ativos de Reuso.
7.3.3.3.1 Iniciação.
 7.3.3.3.1.1 O programa de reutilização de uma organização deve ser iniciado
estabelecendo a estratégia de reutilização da organização, que inclui suas metas de reutilização,
objetivos, objetivos e escopo.
7.3.3.3.1.2 Um patrocinador de reutilização deve ser nomeado.
7.3.3.3.1.3 Os participantes do programa de reutilização devem ser identificados e suas
funções devem ser atribuídas.
7.3.3.3.1.4 Uma função de direção de reutilização deve ser estabelecida para assumir a
autoridade e o programa de reutilização da organização.
7.3.3.3.1.5 Uma função de suporte do programa de reutilização deve ser estabelecida.
7.3.3.3.2 Identificação de domínio.
7.3.3.3.2.1 O administrador do programa de reuso, auxiliado pelo gerente apropriado,
engenheiros de domínio, usuários e desenvolvedores de software, deve identificar e documentar
os domínios nos quais investigar oportunidades de reutilização ou nos quais a organização
pretende praticar a reutilização.
7.3.3.3.2.2 O administrador do programa de reutilização, auxiliado pelos gerentes,
engenheiros de domínio, usuários e desenvolvedores de software apropriados, deve avaliar os
domínios para garantir que eles reflitam com precisão a estratégia de reutilização da organização.
7.3.3.3.2.3 O administrador do programa de reutilização deve conduzir revisões de
acordo com o Processo de Revisão do Software. Desenvolvedores de software, engenheiros de
domínio e usuários devem ser incluídos nas revisões.
7.3.3.3.2.4 À medida que mais informações sobre os domínios e planos da organização
para futuros produtos de software forem disponibilizados ou quando os domínios forem
analisados, os domínios poderão ser refinados e salvos pelo administrador do programa de
reutilização.
7.3.3.3.3 Avaliação de reutilização.
7.3.3.3.3.1 O administrador do programa de reutilização deve avaliar a capacidade
sistemática de reutilização da organização.
7.3.3.3.3.2 O administrador do programa de reutilização deve avaliar cada domínio
considerado para reutilização para determinar o potencial de sucesso de reutilização no domínio.
7.3.3.3.3.3 O administrador do programa de reuso deve fazer recomendações para
refinar a estratégia de reutilização da organização e reutilizar o plano de implementação do
programa com base nos resultados das avaliações de reutilização.
7.3.3.3.3.4 O administrador do programa de reutilização, em conjunto com os
adquirentes, fornecedores, desenvolvedores, operadores, mantenedores, gerentes de ativos e
engenheiros de domínio devem aprimorar, de forma incremental, as habilidades, a tecnologia,
os processos de reutilização, a estrutura organizacional e as métricas que, juntas, formam a
infraestrutura de reutilização.
7.3.3.3.4 Planejamento.
7.3.3.3.4.1 Um plano de implementação do programa de reutilização deve ser criado,
documentado e mantido para definir os recursos e procedimentos para a implementação de um
programa de reutilização.
7.3.3.3.4.2 O plano deve ser revisado e avaliado quanto à sua integridade, viabilidade
de implementação e capacidade de realizar a estratégia de reutilização da organização. Aqueles
que avaliam o plano devem incluir membros do Reutilizar a função de direção.
7.3.3.3.4.3 A aprovação e apoio ao plano de implementação do programa de reutilização
devem ser obtidos a partir da função de reutilização da direção e dos gerentes apropriados.
7.3.3.3.4.4 O administrador do programa de reutilização deve conduzir a (s) revisão
(ões) de acordo com o Processo de Revisão do Software. Os membros da função de reutilização
de direção e os gerentes apropriados devem ser incluídos nas revisões.
7.3.3.3.5 Execução e Controle.
7.3.3.3.5.1 As atividades do plano de implementação do programa de reutilização
devem ser executadas de acordo com o plano.
7.3.3.3.5.2 O administrador do programa de reutilização deve monitorar o progresso do
programa de reutilização em relação à estratégia de reutilização da organização e fazer os ajustes
necessários ao plano para realizar a estratégia.
7.3.3.3.5.3 Problemas e não conformidades que ocorram durante a execução do plano
de implementação do programa de reutilização devem ser registrados e resolvidos.
7.3.3.3.5.4 O administrador do programa de reuso deve reafirmar periodicamente o
patrocínio, apoio e comprometimento da gerência com o programa de reutilização.
7.3.3.3.6 Revisão e avaliação.
7.3.3.3.6.1 O administrador do programa de reutilização deve avaliar periodicamente o
programa de reutilização para atingir a estratégia de reutilização da organização e a adequação
e eficácia contínuas do programa de reutilização.
7.3.3.3.6.2 O administrador do programa de reutilização deve fornecer os resultados da
avaliação e lições aprendidas para a função de reutilização da direção, e para os gerentes
apropriados.
7.3.3.3.6.3 O administrador do programa de reutilização deve recomendar e fazer
alterações no programa de reutilização,
expandir o programa de reutilização e melhorar o programa de reutilização de acordo.