ISO/IEC 12207 – 1995
produto entregável.
Introdução
O software é parte integrante da tecnologia da informação e dos sistemas convencionais, como transporte,
militar, assistência médica e finanças. Há uma proliferação de padrões, procedimentos, métodos, ferramentas
e ambientes para desenvolvimento e gerenciamento de software. Essa proliferação criou dificuldades no
gerenciamento e na engenharia de software, especialmente na integração de produtos e serviços. A disciplina
de software precisa migrar dessa proliferação para uma estrutura comum que pode ser usada por
profissionais de software para "falar a mesma linguagem" para criar e gerenciar software. Esta Norma
Internacional fornece um quadro tão comum.
A estrutura abrange o ciclo de vida do software, desde a conceituação de ideias até a aposentadoria, e
consiste em processos de aquisição e fornecimento de produtos e serviços de software. Além disso, o
framework fornece controle e aprimoramento desses processos.
Os processos deste Padrão Internacional formam um conjunto abrangente. Uma organização, dependendo
da sua finalidade, pode selecionar um subconjunto apropriado para cumprir esse propósito. A norma
internacional é, portanto, projetada para ser adaptada para uma organização, projeto ou aplicativo individual.
Ele também é projetado para ser usado quando o software é uma entidade autônoma ou uma parte
incorporada ou integral do sistema total.
1 Âmbito e campo de aplicação
1.1 Finalidade
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 sistema que
contém software, um produto de software independente e serviço de software e durante o
fornecimento, desenvolvimento, operação e manutenção de produtos de software.
O software inclui a parte de software do firmware.
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.
1.2 Campo de aplicação
Esta Norma aplica-se à aquisição de sistemas e produtos e serviços de software, ao fornecimento,
desenvolvimento, operação e manutenção de produtos de software, e à parte de software do
firmware, seja realizada interna 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.
Nota - Os processos utilizados durante o ciclo de vida do software precisam ser compatíveis com
os processos usados durante o ciclo de vida do sistema.
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. A Norma Internacional pode ser usada por
uma única parte como tarefas auto-impostas.
Esta Norma não se destina a produtos de software de prateleira, a menos que incorporada em um
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.
1.3 Adaptação deste Padrão Internacional
Esta Norma contém um conjunto de processos, atividades e tarefas projetadas para serem
adaptadas em relação a projetos de software. O processo de adaptação é a exclusão de processos,
atividades e tarefas não aplicáveis.
Nota - A adição de processos, atividades e tarefas exclusivos ou especiais pode ser fornecida no
contrato.
1.4 Conformidade
A conformidade com esta Norma é definida como o desempenho de todos os processos, atividades
e tarefas selecionados a partir desta Norma no Processo de Adaptação (Anexo A) para o projeto
de software. O desempenho de um processo ou de uma atividade é concluído quando todas as
tarefas necessárias são executadas de acordo com os critérios pré-estabelecidos e os requisitos
especificados no contrato, conforme aplicável.
Qualquer organização (por exemplo, associação industrial nacional, empresa) que imponha esta
Norma, como uma condição de comércio, é responsável por especificar e tornar público o conjunto
mínimo de processos, atividades e tarefas requeridos, que constituem o cumprimento por parte
dos fornecedores. Padrão internacional.
1.5 Limitações
Esta Norma descreve a arquitetura dos processos do ciclo de vida do software, mas não especifica
os detalhes de como implementar ou executar as atividades e tarefas incluídas nos processos.
Esta Norma não se destina a prescrever o nome, formato ou conteúdo explícito da documentação
a ser produzida. 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.
Esta Norma não prescreve um modelo específico de ciclo de vida ou método de desenvolvimento
de software. o 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, normas ou regulamentos de
qualquer organização. procedimentos que já estão em vigor. Entretanto, qualquer conflito precisa
ser resolvido e quaisquer condições e situações primordiais precisam ser citadas por escrito como
exceções à aplicação da Norma Internacional. Ao longo desta Norma, "deverá" é usado para
expressar uma cláusula vinculativa entre duas ou mais partes, "expressará" uma declaração de
propósito ou intenção por uma parte, "deverá" expressar uma recomendação entre outras
possibilidades, e "pode" indicar um curso de ação permissível dentro dos limites da Norma
Internacional. Nesta Norma Internacional, existem várias listas de tarefas; nenhum destes é
presumido ser exaustivo - - Eles são destinados como exemplos.
4 Aplicação desta Norma Internacional
Esta cláusula apresenta os processos do ciclo de vida do software que podem ser empregados para
adquirir, fornecer, desenvolver, operar e manter produtos de software. O objetivo é fornecer um
roteiro para os usuários desta Norma para que eles possam se orientar e aplicá-la criteriosamente.
4.1 Organização desta Norma Internacional
4.1.1 Processos do ciclo de vida
Este Padrão Internacional agrupa as atividades que podem ser realizadas durante o ciclo de vida
do software em cinco processos primários, oito processos de suporte e quatro processos
organizacionais. Cada processo de ciclo de vida é dividido em um conjunto de atividades; cada
atividade é dividida em um conjunto de tarefas. A numeração da cláusula a.b denota um processo,
a.b.c uma atividade e a.b.c.d uma tarefa. Esses processos do ciclo de vida são apresentados abaixo
e ilustrados Figura 1.
4.1.1.1 Processos primários do ciclo de vida
Os principais processos do ciclo de vida (cláusula 5) consistem em cinco processos que atendem às
partes principais durante o ciclo de vida do software. Uma parte principal é aquela que inicia ou
executa o desenvolvimento, operação ou manutenção de produtos de software. Essas partes
primárias são o adquirente, o fornecedor, o desenvolvedor, o operador e o mantenedor de
produtos de software. Os principais processos são:
1) Processo de aquisição (cláusula 5.1).
a. Define as atividades do adquirente, a organização que adquire um sistema, produto de
software ou serviço de software.
2) Processo de suprimento (cláusula 5.2).
a. Define as atividades do fornecedor, a organização que fornece o sistema, produto de
software ou serviço de software ao adquirente.
3) processo de desenvolvimento (cláusula 5.3).
a. Define as atividades do desenvolvedor, a organização que define e desenvolve o
produto de software.
4) Processo de operação (cláusula 5.4).
a. Define as atividades do operador, a organização que fornece o serviço de operar um
sistema de computador em seu ambiente ativo para seus usuários.
5) Processo de manutenção (cláusula 5.5).
a. Define as atividades do mantenedor, a organização que fornece o serviço de
manutenção do produto de software; isto é, gerenciar modificações no produto de
software para mantê-lo atualizado e em adequação operacional. Esse processo inclui
a migração e a desativação do produto de software.
4.1.1.2 Apoiando processos do ciclo de vida
Os processos de ciclo de vida de suporte (cláusula 6) consistem em oito processos. Um processo
de suporte suporta outro processo como parte integrante com uma finalidade distinta e contribui
para o sucesso e a qualidade do projeto de software. Um processo de suporte é empregado e
executado, conforme necessário, por outro processo. Os processos de suporte são:
1) Processo de documentação (cláusula 6.1).
a. Define as atividades para registrar as informações produzidas por um processo
de ciclo de vida.
2) Processo de gerenciamento de configuração (cláusula 6.2).
a. Define as atividades de gerenciamento de configuração.
3) processo de garantia de qualidade (cláusula 6.3).
a. Define as atividades para garantir objetivamente que os produtos e processos de
software estejam em conformidade com os requisitos especificados e sigam suas
planos estabelecidos. Revisões conjuntas, auditorias, verificação e validação
podem ser usadas como técnicas de garantia de qualidade.
4) Processo de verificação (cláusula 6.4).
a. Define as atividades (para o adquirente, o fornecedor ou uma parte
independente) para verificar os produtos de software em profundidade variável,
dependendo do projeto de software.
5) Processo de validação (cláusula 6.5).
a. Define as atividades (para o adquirente, o fornecedor ou uma parte
independente) para validar os produtos de software do projeto de software.
6) Processo de revisão conjunta (cláusula 6.6).
a. Define as atividades para avaliar o status e os produtos de uma atividade. Este
processo pode ser empregado por quaisquer duas partes, onde uma parte (parte
revisora) analisa outra parte (parte revisada) em um fórum conjunto.
7) Processo de auditoria (cláusula 6.7).
a. Define as atividades para determinar a conformidade com os requisitos, planos
e contrato. Esse processo pode ser empregado por duas partes, onde uma parte
(parte da auditoria) audita os produtos de software ou atividades de outra parte
(parte auditada).
8) Processo de resolução de problemas (cláusula 6.8).
a. Define um processo para analisar e remover os problemas (incluindo não-
conformidades), independentemente da sua natureza ou origem, descobertos
durante a execução do desenvolvimento, operação, manutenção ou outros
processos.
4.1.1.3 Processos organizacionais do ciclo de vida
Os processos do ciclo de vida organizacional (cláusula 7) consistem em quatro processos. Eles são
empregados por uma organização para estabelecer e implementar uma estrutura subjacente
composta de processos e pessoal associados ao ciclo de vida e melhorar continuamente a estrutura
e os processos. Eles são tipicamente empregados fora do âmbito de projetos e contratos
específicos; no entanto, lições de tais projetos e contratos contribuem para a melhoria da
organização. Os processos organizacionais são:
 1) Processo de gestão (cláusula 7.1).
a. Define as atividades básicas da gerência, incluindo projetos gestão, durante um
processo de ciclo de vida.
2) Processo de infraestrutura (cláusula 7.2).
a. Define as atividades básicas para estabelecer a estrutura subjacente de um
processo de ciclo de vida.
3) Processo de melhoria (cláusula 7.3).
a. Define as atividades básicas que uma organização (ou seja, adquirente,
fornecedor, desenvolvedor, operador, mantenedor ou gerente de outro
processo) executa para estabelecer, medir, controlar e melhorar seu processo de
ciclo de vida.
4) Processo de treinamento (cláusula 7.4).
a. Define as atividades para fornecer pessoal adequadamente treinado.
4.1.2 Processo de adaptação.
O Anexo A, que é normativo, define as atividades básicas necessárias para realizar a adaptação
desta Norma. O Anexo B contém uma breve orientação sobre como adaptar os requisitos desta
Norma Internacional; lista os principais fatores sobre os quais as decisões de adaptação podem ser
feitas.
4.1.3 Relação entre os processos e organizações
Esta Norma Internacional contém vários processos que são aplicados ao longo do ciclo de vida do
software por várias organizações, dependendo de suas necessidades e objetivos. Para fins de
compreensão, o Anexo C apresenta as relações entre os processos do ciclo de vida e partes
relacionadas.
5 Processos primários do ciclo de vida
Esta cláusula define os seguintes processos principais do ciclo de vida:
1) processo de aquisição;
2) processo de suprimento;
3) processo de desenvolvimento;
4) processo de operação;
5) processo de manutenção.
As atividades e tarefas em um processo primário são de responsabilidade da organização que inicia
e executa esse processo. Esta organização garante que o processo está em existência e funcional.
5.1 Processo de aquisição
O Processo de Aquisição contém as atividades e tarefas do adquirente. O processo começa com a
definição da necessidade de adquirir um sistema, produto de software ou serviço de software. O
processo continua com a preparação e emissão de uma solicitação de proposta, seleção de um
fornecedor e gerenciamento do processo de aquisição até a aceitação do sistema, produto de
software ou serviço de software.
A organização individual com necessidade pode ser chamada de proprietária. O proprietário pode
contratar qualquer ou todos os
atividades de aquisição para um agente que, por sua vez, conduzirá essas atividades de acordo
com o Processo de Aquisição.
O adquirente nesta cláusula pode ser o proprietário ou o agente.
O adquirente gerencia o Processo de Aquisição no nível do projeto seguindo o Processo de
Gerenciamento (cláusula 7.1), que é instanciado nesse processo; estabelece uma infra-estrutura
sob o processo seguindo o Processo de Infraestrutura (cláusula 7.2); adapta o processo para o
projeto seguindo o Processo de Adaptação (Anexo A); e gerencia o processo no nível organizacional
seguindo o Processo de Melhoria (7.3) e o Processo de Treinamento (7.4).
Lista de atividades:
Este processo consiste nas seguintes atividades: 1) Iniciação; 2) Preparação do pedido
de proposta [-tender]; 3) Preparação e atualização de contratos; 4) Monitoramento de
fornecedores; 5) Aceitação e conclusão.
5.1.1 Iniciação.
Esta atividade consiste nas seguintes tarefas:
5.1.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.
5.1.1.2 O adquirente definirá e analisará os requisitos do sistema. Os requisitos do
sistema devem incluir negócios, organização e usuário, bem como segurança, segurança e outros
requisitos de criticalidade, juntamente com os padrões e procedimentos de projeto, testes e
conformidade relacionados.
5.1.1.3 Se o adquirente retiver um fornecedor para realizar a análise de requisitos do
sistema, o adquirente aprovará os requisitos analisados.
5.1.1.4 O adquirente pode realizar a definição e análise de requisitos de software por
si só ou pode reter fornecedor para executar esta tarefa.
5.1.1.5 O Processo de Desenvolvimento (5.3) deve ser utilizado para executar as
tarefas das cláusulas 5.1.1.2 e 5.1.1.4.
5.1.1.6 O adquirente considerará opções para aquisição contra 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.
5.1.1.7 Quando um produto de software de prateleira for adquirido, o adquirente
assegurará que as seguintes condições sejam satisfeitas:
a) Os requisitos para o produto de software estão satisfeitos.
 b) A documentação 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.
5.1.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 utilizado;
f) Riscos considerados e métodos para gerenciar os riscos.
5.1.1.9 O adquirente deve definir e documentar a estratégia e condições de aceitação
(critérios).
5.1.2 Preparação do pedido de proposta [-tender].
5.1.2.1 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 cláusula
5.1.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).
5.1.2.2 O adquirente deve determinar quais processos, atividades e tarefas desta
Norma Internacional são apropriados para o projeto e deve adequá-los adequadamente.
Especialmente, o adquirente deve especificar os processos de suporte aplicáveis (cláusula 6) e suas
organizações executoras, incluindo responsabilidades (se não forem fornecedor), para que os
fornecedores possam, em suas propostas, definir a abordagem para cada um dos processos de
suporte especificados. O adquirente definirá o escopo das tarefas que fazem referência ao
contrato.
5.1.2.3 A documentação de aquisição também definirá os marcos do contrato nos quais
o progresso do fornecedor será revisado e auditado como parte do monitoramento da aquisição
(ver cláusulas 6.6 e 6.7).
5.1.2.4 Os requisitos de aquisição devem ser fornecidos à organização selecionada para
a realização de atividades de aquisição.
5.1.3 Preparação e atualização do contrato.
5.1.3.1 O adquirente deve estabelecer um procedimento para seleção de fornecedores,
incluindo critérios de avaliação de propostas e ponderação de conformidade de requisitos.
5.1.3.2 O adquirente deve selecionar um fornecedor com base na avaliação das
propostas, capacidades e outros fatores dos fornecedores que precisam ser considerados.
5.1.3.3 O adquirente pode envolver outras partes, incluindo potenciais fornecedores,
antes da adjudicação do contrato, na adaptação desta Norma para o projeto. No entanto, o
adquirente tomará a decisão final sobre a alfaiataria.
O adquirente incluirá ou referenciará a Norma Internacional sob medida no contrato.
5.1.3.4 O adquirente irá então preparar e negociar um contrato com o fornecedor, que
aborde os requisitos de aquisição, incluindo o custo e o cronograma, do produto ou serviço de
software a ser entregue. O contrato tratará dos direitos de propriedade, uso, propriedade, garantia
e licenciamento associados aos produtos de software reutilizáveis que estão fora da plataforma.
5.1.3.5 Quando o contrato estiver em andamento, o adquirente controlará as
alterações 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.
Nota - O adquirente determina se o termo "contrato" ou "acordo" deve ser usado na aplicação
desta Norma.
5.1.4 Monitoramento de fornecedores.
5.1.4.1 O adquirente monitorará as atividades do fornecedor de acordo com o Processo
de Revisão Conjunta (cláusula 6.6) e o Processo de Auditoria (cláusula 6.7). O adquirente deve
complementar o monitoramento com o processo de verificação (6.4) e o processo de validação
(6.5), conforme necessário.
5.1.4.2 O adquirente cooperará com o fornecedor para fornecer todas as informações
necessárias em tempo hábil e resolver todos os itens pendentes.
5.1.5 Aceitação e conclusão.
5.1.5.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.
5.1.5.2 O adquirente realizará a análise de aceitação e o teste de aceitação do produto
ou serviço de software de entrega e o aceitará do fornecedor quando todas as condições de
aceitação forem satisfeitas. O procedimento de aceitação deve obedecer ao disposto na cláusula
5.1.1.9.
5.1.5.3 Após a aceitação, o adquirente deve assumir a responsabilidade pelo
gerenciamento da configuração do produto de software entregue (consulte a cláusula 6.2).
Nota - O adquirente pode instalar o produto de software ou executar o serviço de software de
acordo com instruções definidas pelo fornecedor.
5.2 Processo de fornecimento
O processo de fornecimento contém as atividades e tarefas do fornecedor. O processo pode ser
iniciado por uma decisão de preparar uma proposta para responder ao pedido de proposta do
adquirente ou pela assinatura e celebração de um contrato com o adquirente para fornecer o
sistema, produto de software ou serviço de software. O processo continua com a determinação de
procedimentos e recursos necessários para gerenciar e assegurar o projeto, incluindo o
desenvolvimento de planos de projeto e a execução dos planos por meio da entrega do sistema,
produto de software ou serviço de software ao adquirente.
O fornecedor gerencia o processo de fornecimento no nível do projeto seguindo o processo de
gerenciamento (cláusula 7.1), que é instanciado nesse processo; estabelece uma infra-estrutura
sob o processo seguindo o Processo de Infraestrutura (cláusula 7.2); adapta o processo para o
projeto seguindo o Processo de Adaptação (Anexo A); e gerencia o processo no nível organizacional
seguindo o Processo de Melhoria (7.3) e o Processo de Treinamento (7.4).
List of activities: This process consists of the following activities:
1) Initiation;
2) Preparation of response;
3) Contract;
4) Planning;
5) Execution and control;
6) Review and evaluation;
7) Delivery and completion.
5.2.1 Iniciação.
5.2.1.1 O fornecedor realiza uma revisão dos requisitos na solicitação de proposta,
levando em consideração as políticas organizacionais e outras regulamentações.
5.2.1.2 O fornecedor deve tomar a decisão de licitar ou aceitar o contrato.
5.2.2 Preparação da resposta. - 5.2.2.1 O fornecedor deve definir e preparar uma proposta em
resposta ao pedido de proposta, incluindo sua alfaiataria recomendada desta Norma Internacional.
5.2.3 Contrato.
5.2.3.1 O fornecedor deve negociar e celebrar um contrato com a organização
adquirente para fornecer o produto ou serviço de software.
5.2.3.2 O fornecedor pode solicitar modificações no contrato como parte do
mecanismo de controle de mudanças.
5.2.4 Planejamento.
5.2.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.
5.2.4.2 Se não estipulado no contrato, o fornecedor deve definir ou selecionar um
modelo de ciclo de vida de software apropriado ao escopo, magnitude e complexidade do projeto.
Os processos, atividades e tarefas desta Norma Internacional devem ser selecionados e mapeados
no modelo de ciclo de vida.
5.2.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 de entrega. Os
requisitos para os planos devem incluir necessidades de recursos e envolvimento do adquirente.
5.2.4.4 Uma vez estabelecidos os requisitos de planejamento, o fornecedor deve
considerar as opções para desenvolver o produto de software ou fornecer o serviço de software,
contra 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.
5.2.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 cláusula 5.2.4.4.
Os 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 dos processos e atividades do ciclo de vida, incluindo produtos de software,
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) Administração do Subcontratado, incluindo a seleção e envolvimento do subcontratado entre o
subcontratado eo adquirente, se houver;
g) Garantia de qualidade (ver cláusula 6.3);
h) Verificação (ver 6.4) e validação (ver cláusula 6.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 conjuntas (ver cláusula 6.6), auditorias
(ver cláusula 6.7), reuniões informais, relatórios, modificações e mudanças; 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; que é a gestão das áreas do projeto que envolvem possíveis riscos
técnicos, de custo e 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 seção 7.4).
5.2.5 Execução e controle.
5.2.5.1 O fornecedor deve implementar e executar o (s) plano (s) de gerenciamento do
projeto desenvolvido (s) na cláusula 5.2.4.
5.2.5.2 O fornecedor deve:
a) Desenvolver o produto de software de acordo com o processo de
desenvolvimento (5.3).
b) Operar o produto de software de acordo com o Processo de Operação
(cláusula 5.4).
c) Manter o produto de software de acordo com o processo de manutenção
(cláusula 5.5).
5.2.5.3 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 e interativa, que deverá prever:
a) Monitorar o progresso do desempenho técnico, custos e cronogramas e
relatar o status do projeto;
b) Identificação, registro, análise e resolução de problemas.
5.2.5.4 O fornecedor deve gerenciar e controlar os subcontratados de acordo com o
Processo de Aquisição (cláusula 5.1). O fornecedor deve passar todos os requisitos contratuais
necessários para garantir que o produto ou serviço de software entregue ao adquirente seja
desenvolvido ou executado de acordo com os requisitos do contrato principal.
5.2.5.5 O fornecedor deve interagir com o agente independente de verificação,
validação ou teste, conforme especificado no contrato e nos planos do projeto.
5.2.5.6 O fornecedor deve interagir com outras partes, conforme especificado no
contrato e nos planos do projeto.
5.2.6 Revisão e avaliação.
5.2.6.1 O fornecedor deve coordenar as atividades de revisão do contrato, interfaces e
comunicação com a organização do adquirente.
5.2.6.2 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 realizada de acordo com a cláusula
6.6, auditorias de acordo com a cláusula 6.7.
5.2.6.3 O fornecedor deve realizar a verificação e a validação de acordo com as
cláusulas 6.4 e 6.5, respectivamente, para demonstrar que os produtos ou serviços de software e
os processos satisfazem plenamente seus respectivos requisitos.
5.2.6.4 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.
5.2.6.5 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.
5.2.6.6 O fornecedor deve realizar atividades de garantia de qualidade de acordo com
a cláusula 6.3.
5.2.7 Entrega e conclusão.
5.2.7.1 O fornecedor deve entregar o produto ou serviço de software conforme
especificado no contrato.
5.2.7.2 O fornecedor deve fornecer assistência ao adquirente em suporte ao produto
de software entregue ou serviço conforme especificado no contrato.
5.3 Processo de desenvolvimento
O processo de desenvolvimento contém as atividades e tarefas do desenvolvedor. O processo
contém as atividades para análise de requisitos, design, codificação, integração, testes e instalação
e aceitação relacionados a produtos de software. Pode conter atividades relacionadas ao sistema,
se estipulado no contrato. O desenvolvedor realiza ou apóia as atividades nesse processo de
acordo com o contrato.
O desenvolvedor gerencia o processo de desenvolvimento no nível do projeto seguindo o processo
de gerenciamento (cláusula 7.1), que é instanciado nesse processo; estabelece uma infra-estrutura
sob o processo seguindo o Processo de Infraestrutura (cláusula 7.2); adapta o processo para o
projeto seguindo o Processo de Adaptação (Anexo A); e gerencia o processo no nível organizacional
seguindo o Processo de Melhoria (7.3) e o Processo de Treinamento (7.4). Quando o desenvolvedor
é o fornecedor do produto de software desenvolvido, o
o desenvolvedor executa o processo de fornecimento (cláusula 5.2).
List of activities:
1) Process implementation;
2) System requirements analysis;
3) System architectural design;
4) Software requirements analysis;
5) Software architectural design;
6) Software detailed design;
7) Software coding and testing;
8) Software integration;
9) Software qualification testing;
10) System integration;
11) System qualification testing;
12) Software installation;
13) Software acceptance support.
5.3.1 Implementação do processo.
5.3.1.1 Se não estipulado no contrato, o desenvolvedor deve definir ou selecionar um
modelo de ciclo de vida de software apropriado ao escopo, magnitude e complexidade do projeto.
As atividades e tarefas do Processo de Desenvolvimento devem ser selecionadas e mapeadas no
modelo de ciclo de vida.
Nota - Essas atividades e tarefas podem se sobrepor ou interagir e podem ser executadas
iterativamente ou recursivamente.
5.3.1.2 O desenvolvedor deve:
a) Documentar as saídas de acordo com o processo de documentação (6.1).
b) Coloque as saídas sob o processo de gerenciamento de configuração
(cláusula 6.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 (cláusula
6.8).
d) Executar os processos de suporte (cláusula 6) conforme especificado no
contrato.
5.3.1.3 O desenvolvedor 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 Desenvolvimento. e processos de apoio (cláusula 6).
5.3.1.4 O desenvolvedor deve desenvolver planos para conduzir as atividades do
processo de desenvolvimento. 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.
5.3.1.5 Itens não entregáveis podem ser empregados no desenvolvimento ou
manutenção do produto de software. No entanto, deve-se assegurar que a operação e a
manutenção do produto de software de entrega após a entrega ao adquirente sejam
independentes de tais itens, caso contrário, esses itens devem ser considerados como
entregável.
5.3.2 Análise de requisitos do sistema.
5.3.2.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.
5.3.2.2 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.
5.3.3 Projeto arquitetônico do sistema.
5.3.3.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.
5.3.3.2 A arquitetura do sistema e os requisitos para os itens devem ser avaliados
considerando os 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 e métodos de projeto utilizados;
d) Viabilidade dos itens de software que cumpram seus requisitos alocados;
e) Viabilidade de operação e manutenção.
5.3.4 Análise de requisitos de software.
5.3.4.1 O desenvolvedor deve estabelecer e documentar os requisitos de software,
incluindo as características de qualidade
especificações descritas abaixo. Orientações para especificação de características de qualidade
podem ser encontradas na ISO / IEC 9126.
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 (is) de operação e manutenção;
i) documentação do usuário;
j) Requisitos de operação e execução do usuário;
 k) Requisitos de manutenção do usuário.
5.3.4.2 O desenvolvedor 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 de design de software;
f) Viabilidade de operação e manutenção.
5.3.4.3 O desenvolvedor deve conduzir revisão (ões) conjunta (s) de acordo com a
cláusula 6.6. Após a conclusão bem-sucedida da (s) revisão (ões), uma linha de base para os
requisitos do item de software deve ser estabelecida.
5.3.5 Projeto de arquitetura de software.
5.3.5.1 O desenvolvedor 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.
5.3.5.2 O desenvolvedor 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.
5.3.5.3 O desenvolvedor deve desenvolver e documentar um projeto de alto nível para
o banco de dados.
5.3.5.4 O desenvolvedor deve desenvolver e documentar versões preliminares da
documentação do usuário.
5.3.5.5 O desenvolvedor deve definir e documentar os requisitos preliminares do teste
e o cronograma da Integração de Software.
5.3.5.6 O desenvolvedor 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 do 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.
5.3.5.7 O desenvolvedor deve conduzir revisão (ões) conjunta (s) de acordo com a
cláusula 6.6.
5.3.6 Projeto detalhado de software.
5.3.6.1 O desenvolvedor deve desenvolver um projeto detalhado para cada
componente de software do item de software. Os componentes de software devem ser 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.
5.3.6.2 O desenvolvedor 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.
5.3.6.3 O desenvolvedor deve desenvolver e documentar um projeto detalhado para o
banco de dados.
5.3.6.4 O desenvolvedor deve atualizar a documentação do usuário conforme
necessário.
5.3.6.5 O desenvolvedor 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.
5.3.6.6 O desenvolvedor deve atualizar os requisitos de teste e o cronograma para
Integração de Software.
5.3.6.7 O desenvolvedor deve avaliar o projeto detalhado do software e testar os
requisitos, 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.
5.3.6.8 O desenvolvedor deve conduzir revisão (ões) conjunta (s) de acordo com a
cláusula 6.6.
5.3.7 Codificação e teste de software.
5.3.7.1 O desenvolvedor 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.
5.3.7.2 O desenvolvedor deve testar cada unidade de software e banco de dados,
garantindo que satisfaça seus requisitos. Os resultados do teste devem ser documentados.
5.3.7.3 O desenvolvedor deve atualizar a documentação do usuário conforme
necessário.
5.3.7.4 O desenvolvedor deve atualizar os requisitos de teste e o cronograma para
Integração de Software.
5.3.7.5 O desenvolvedor 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 utilizados;
f) Viabilidade de integração e testes de software;
g) Viabilidade de operação e manutenção.
5.3.8 Integração de software.
5.3.8.1 O desenvolvedor 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.
5.3.8.2 O desenvolvedor 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.
5.3.8.3 O desenvolvedor deve atualizar a documentação do usuário conforme
necessário.
5.3.8.4 O desenvolvedor 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.
5.3.8.5 O desenvolvedor 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 de 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.
5.3.8.6 O desenvolvedor deve conduzir revisão (ões) conjunta (s) de acordo com a
cláusula 6.6.
5.3.9 Teste de qualificação de software.
5.3.9.1 O desenvolvedor 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.
5.3.9.2 O desenvolvedor deve atualizar a documentação do usuário conforme
necessário.
5.3.9.3 O desenvolvedor deve avaliar o projeto, código, testes, resultados de testes e
documentação do usuário, os critérios listados abaixo. Os resultados das avaliações devem ser
documentados.
a) Teste de cobertura dos requisitos do item de software;
b) Conformidade com os resultados esperados;
c) Viabilidade de integração de sistemas e testes, se realizados;
d) Viabilidade de operação e manutenção.
5.3.9.4 O desenvolvedor deve apoiar auditoria (s) de acordo com a cláusula 6.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.
5.3.9.5 Após a conclusão bem sucedida das auditorias, se conduzido, o desenvolvedor
deve:
a) 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.
b) Estabeleça uma linha de base para o design e código do item de software.
Nota - O Teste de Qualificação de Software pode ser usado no Processo de Verificação
(6.4) ou no Processo de Validação (6.5).
5.3.10 Integração do sistema. Esta atividade consiste nas seguintes tarefas, que o desenvolvedor
deve executar ou suportar conforme exigido pelo contrato.
5.3.10.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.
5.3.10.2 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 documentados.
O desenvolvedor deve garantir que o sistema integrado esteja pronto para o Teste de Qualificação
do Sistema.
5.3.10.3 O sistema integrado deve ser avaliado considerando os critérios listados
abaixo. Os resultados das avaliações devem ser documentados.
a) Teste de 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.
5.3.11 Teste de qualificação do sistema.
5.3.11.1 O teste de qualificação do sistema deve ser conduzido de acordo com os
requisitos de qualificação especificados para o sistema. Deve-se assegurar que a implementação
de cada requisito do sistema seja testada quanto à conformidade e que o sistema esteja pronto
para entrega. Os resultados do teste de qualificação devem ser documentados.
5.3.11.2 O sistema deve ser avaliado considerando os critérios listados abaixo. Os
resultados das avaliações devem ser documentados.
 a) Teste de cobertura dos requisitos do sistema;
b) Conformidade com os resultados esperados;
c) Viabilidade de operação e manutenção.
5.3.11.3 O desenvolvedor deve dar suporte a auditoria (s) de acordo com a cláusula 6.7.
Os resultados da auditoria devem ser documentados.
Nota - Esta cláusula não é aplicável a esses itens de configuração de software para os
quais as auditorias foram realizadas anteriormente.
5.3.11.4 Após a conclusão bem sucedida da (s) auditoria (ões), se conduzida, o
desenvolvedor deve:
a) Atualizar e preparar o produto de software de entrega para instalação de
software e suporte de aceitação de software.
b) Estabeleça uma linha de base para o design e o código de cada item de
configuração de software.
Nota - O Teste de Qualificação do Sistema pode ser usado no Processo de Verificação
(6.4) ou no Processo de Validação (6.5).
5.3.12 Instalação de software.
5.3.12.1 O desenvolvedor 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 desenvolvedor deve ajudar o adquirente com as atividades
de configuração. Quando o produto de software instalado estiver substituindo um sistema
existente, o desenvolvedor deverá suportar quaisquer atividades de execução paralela exigidas por
contrato. O plano de instalação deve ser documentado.
5.3.12.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.
5.3.11.2 O sistema deve ser avaliado considerando os critérios listados abaixo. Os
resultados das avaliações devem ser documentados.
a) Teste de cobertura dos requisitos do sistema;
b) Conformidade com os resultados esperados;
c) Viabilidade de operação e manutenção.
5.3.11.3 O desenvolvedor deve dar suporte a auditoria (s) de acordo com a cláusula 6.7.
Os resultados da auditoria devem ser documentados.
Nota - Esta cláusula não é aplicável a esses itens de configuração de software para os quais as
auditorias foram realizadas anteriormente.
5.3.11.4 Após a conclusão bem sucedida da (s) auditoria (ões), se conduzida, o
desenvolvedor deve:
a) Atualizar e preparar o produto de software de entrega para instalação de
software e suporte de aceitação de software.
b) Estabeleça uma linha de base para o design e o código de cada item de
configuração de software.
Nota - O Teste de Qualificação do Sistema pode ser usado no Processo de Verificação
(6.4) ou no Processo de Validação (6.5).
5.3.13 Suporte de aceitação de software.
5.3.13.1 O desenvolvedor deve apoiar a revisão de aceitação do adquirente e o teste
do produto de software. A análise e o teste de aceitação devem considerar os resultados das
Revisões Conjuntas (cláusula 6.6), Auditorias (6.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.
5.3.13.2 O desenvolvedor deve completar e entregar o produto de software conforme
especificado no contrato.
5.3.13.3 O desenvolvedor deve fornecer treinamento e suporte inicial e contínuo ao
adquirente, conforme especificado no contrato.
5.4 processo de operação
O Processo de Operação contém as atividades e tarefas do operador. O processo cobre
a operação do produto de software e o suporte operacional aos usuários. Como a operação do
produto de software é integrada à operação do sistema, as atividades e tarefas desse processo se
referem ao sistema.
O operador gerencia o Processo de Operação no nível do projeto seguindo o Processo
de Gerenciamento (cláusula 7.1), que é instanciado neste processo; estabelece uma infra-estrutura
sob o processo seguindo o Processo de Infraestrutura (cláusula 7.2); adapta o processo para o
projeto seguindo o Processo de Adaptação (Anexo A); e gerencia o processo no nível organizacional
seguindo o Processo de Melhoria (7.3) e o Processo de Treinamento (7.4). Quando o operador é o
fornecedor do serviço de operação, o operador executa o processo de fornecimento (cláusula 5.2).
List of activities. This process consists of the following activities:
1) Process implementation;
2) Operational testing;
3) System operation;
4) User support.
5.4.1 Implementação do processo
5.4.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.
5.4.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 (cláusula 6.8).
5.4.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 (cláusula 5.5) e para liberar o produto de software para uso
operacional.
5.4.2 Teste operacional.
5.4.2.1 Para cada lançamento 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.
5.4.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.
5.4.3 Operação do sistema. - 5.4.3.1 O sistema deve ser operado no ambiente pretendido de
acordo com a documentação do usuário.
5.4.4 Suporte ao usuário.
5.4.4.1 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.
5.4.4.2 O operador deve encaminhar solicitações do usuário, conforme necessário,
para o Processo de Manutenção (cláusula 5.5) para resolução. Estes pedidos devem ser abordados
e as acções planeadas e tomadas devem ser comunicadas aos os originadores dos pedidos. Todas
as resoluções devem ser monitoradas até a conclusão.
5.4.4.3 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 no sistema devem ser aplicadas ao produto de software operacional usando o processo
de manutenção (cláusula 5.5).
5.5 Processo de Manutenção
O processo de manutenção contém as atividades e tarefas do mantenedor. Este processo é ativado
quando o produto de software sofre modificações no código e documentação associada devido a
um problema ou a necessidade de melhoria ou adaptação. O objetivo é modificar o produto de
software existente, preservando sua integridade. Esse processo inclui a migração e a desativação
do produto de software. O processo termina com a retirada do produto de software.
As atividades previstas nesta cláusula são específicas para o processo de manutenção; no entanto,
o processo pode utilizar outros processos nesta Norma Internacional. Se o processo de
desenvolvimento (5.3) for utilizado, o termo desenvolvedor será interpretado como mantenedor.
O mantenedor gerencia o processo de manutenção no nível do projeto seguindo o processo de
gerenciamento (cláusula 7.1), que é instanciado nesse processo; estabelece uma infra-estrutura
sob o processo seguindo o Processo de Infraestrutura (cláusula 7.2); adapta o processo para o
projeto seguindo o Processo de Adaptação (Anexo A); e gerencia o processo no nível organizacional
seguindo o Processo de Melhoria (7.3) e o Processo de Treinamento (7.4). Quando o mantenedor
é o fornecedor do serviço de manutenção, o mantenedor executa o Processo de Suprimento
(cláusula 5.2).
List of activities. This process consists of the following activities:
1) Process implementation;
2) Problem and modification analysis;
3) Modification implementation;
4) Maintenance review/acceptance;
5) Migration;
6) Software retirement.
5.5.1 Implementação do processo.
5.5.1.1 O mantenedor deve desenvolver, documentar e executar planos e
procedimentos para conduzir as atividades e tarefas do Processo de Manutenção.
5.5.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 (cláusula 6.8).
5.5.1.3 O mantenedor deve implementar (ou estabelecer interface organizacional com)
o Processo de Gerenciamento de Configuração (6.2) para gerenciar modificações no sistema
existente.
5.5.2 Análise de problemas e modificações.
5.5.2.1 O mantenedor deve analisar o relatório de problema 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.
5.5.2.2 O mantenedor deve replicar ou verificar o problema.
5.5.2.3 Com base na análise, o mantenedor deve desenvolver opções para implementar
a modificação.
5.5.2.4 O mantenedor deve documentar a solicitação de problema / modificação, os
resultados da análise e as opções de implementação.
5.5.2.5 O mantenedor deverá obter aprovação para a opção de modificação
selecionada, conforme especificado no contrato.
5.5.3 Implementação de modificação.
5.5.3.1 O mantenedor deve conduzir análises e determinar que documentação,
unidades de software e versões de lá precisam ser modificadas. Estes devem ser documentados.
5.5.3.2 O mantenedor deve entrar no Processo de Desenvolvimento (5.3) para
implementar as modificações. Os requisitos do processo de desenvolvimento devem ser
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.
5.5.4 Revisão / aceitação de manutenção.
5.5.4.1 O mantenedor deve conduzir revisão (ões) com a organização autorizando a
modificação para determinar a integridade do sistema modificado.
5.5.4.2 O mantenedor deverá obter aprovação para a conclusão satisfatória da
modificação conforme especificado no contrato.
5.5.5 Migração.
5.5.5.1 Se um sistema ou produto de software (incluindo dados) for migrado de um
ambiente operacional antigo para um novo, deve-se assegurar que qualquer produto de software
ou dados produzidos ou modificados durante a migração estejam de acordo com esta Norma.
5.5.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 de software e dados;
d) Execução da migração;
e) Verificação de migração;
f) Suporte para o ambiente antigo no futuro.
5.5.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 a 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.
5.5.5.4 Operações paralelas dos antigos e novos ambientes 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.
5.5.5.5 Quando a migração programada chegar, a notificação deverá ser enviada a
todos os envolvidos. Toda a documentação, logs e códigos do ambiente antigo associado devem
ser colocados em arquivos.
5.5.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.
5.5.5.7 Os dados utilizados ou associados ao ambiente antigo devem ser acessíveis de
acordo com os requisitos do contrato para proteção de dados e auditoria aplicáveis aos dados.
5.5.6 Retirada de software.
Nota - O produto de software será retirado a pedido do proprietário.
5.5.6.1 Um plano de aposentadoria 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 deve abordar os itens listados abaixo. O plano deve ser executado.
a) Cessação de apoio 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 o novo produto de software, se aplicável;
e) Acessibilidade de cópias arquivadas de dados.
5.5.6.2 Os usuários devem receber notificação dos planos e atividades de
aposentadoria. As notificações devem incluir:
a) Descrição da 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.
5.5.6.3 As operações paralelas do produto de software descontinuado e 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.
5.5.6.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.
5.5.6.5 Os dados utilizados ou associados pelo 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.
6 Apoiando os processos do ciclo de vida
Esta cláusula define os seguintes processos de ciclo de vida de suporte:
1) processo de documentação;
2) processo de gerenciamento de configuração;
3) processo de garantia de qualidade;
4) processo de verificação;
5) processo de validação;
6) processo de revisão conjunta;
7) processo de auditoria;
8) processo de resolução de problemas.
As atividades e tarefas em um processo de suporte são de responsabilidade da organização que
executa esse processo. Esta organização garante que o processo está em existência e funcional.
A organização que emprega e executa um processo de suporte a gerencia no nível do projeto
seguindo o Processo de Gerenciamento (cláusula 7.1); estabelece uma infra-estrutura sob ela
seguindo o Processo de Infraestrutura (cláusula 7.2); adapta-o para o projeto seguindo o Processo
de Adaptação (Anexo A); e administra-o no nível organizacional seguindo o Processo de Melhoria
(7.3) e o Processo de Treinamento (7.4). Revisões conjuntas, auditorias, verificação e validação
podem ser usadas como técnicas de garantia de qualidade.
6.1 Processo de Documentação
O processo de documentação é um processo para registrar informações produzidas por um
processo ou atividade de ciclo de vida.
O processo contém o conjunto de atividades que planejam, projetam, desenvolvem, produzem,
editam, distribuem e mantêm os documentos necessários a todos os envolvidos, como gerentes,
engenheiros e usuários do sistema ou produto de software.
List of activities. This process consists of the following activities:
1) Process implementation;
2) Design and development;
3) Production;
4) Maintenance.
6.1.1 Implementação do processo.
6.1.1.1 Um plano, identificando os documentos a serem produzidos durante o ciclo de
vida do produto de software, deve ser desenvolvido, documentado e implementado. Para cada
documento identificado, deve ser tratado o seguinte:
a) título ou nome;
b) Propósito;
c) público pretendido;
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.
6.1.2 Design e desenvolvimento.
6.1.2.1 Cada documento identificado deve ser projetado de acordo com os padrões de
documentação aplicáveis para 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.
6.1.2.2 A fonte e adequação dos dados de entrada para os documentos devem ser
confirmados. Ferramentas automatizadas de documentação podem ser usadas.
6.1.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.
6.1.3 Produção.
6.1.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.
6.1.3.2 Os controles devem ser estabelecidos de acordo com o Processo de
Gerenciamento da Configuração (cláusula 6.2).
6.1.4 Manutenção. - 6.1.4.1 As tarefas, que devem ser executadas quando a documentação deve
ser modificada, devem ser executadas (ver cláusula 5.5). Para aqueles documentos que estão sob
gerenciamento de configuração, as modificações devem ser gerenciadas de acordo com o Processo
de Gerenciamento da Configuração (cláusula 6.2).
6.2 Processo de gerenciamento de configuração
O Processo de Gerenciamento da Configuração é um processo de aplicação de procedimentos
administrativos e técnicos ao longo do ciclo de vida do software para: identificar, definir e basear
itens de software em um sistema; controle de modificações e liberações dos itens; registrar e
relatar o status dos itens e solicitações de modificação; garantir a integridade, consistência e
correção dos itens; e controle de armazenamento, manuseio e entrega dos itens.
Nota - Quando este processo é empregado em outros produtos ou entidades de software, o termo
"item de software" abaixo é interpretado em conformidade.
List of activities. This process consists of the following activities:
1) Process implementation;
2) Configuration identification;
3) Configuration control;
4) Configuration status accounting;
5) Configuration evaluation;
6) Release management and delivery.
6.2.1 Implementação do processo. - 6.2.1.1 Um plano de gerenciamento de configuração 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.
6.2.2 Identificação da configuração - 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
6.2.3 Controle de configuração. - 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.
6.2.4 Contabilização do status da configuração. - Registros de gerenciamento e relatórios de status
que mostrem o status e o histórico de itens de software controlados, incluindo linha 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.
6.2.5 Avaliação de configuração - Os itens a seguir 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 (se o design e o código refletem uma descrição técnica atualizada).
6.2.6 Gerenciamento de liberação e entrega. - 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.
6.3 Processo de garantia de qualidade
O Processo de Garantia de Qualidade é um processo para fornecer garantia adequada de que os
produtos e processos de software no ciclo de vida do projeto atendem aos requisitos especificados
e aderem aos seus planos estabelecidos.
Para ser imparcial, a garantia de qualidade precisa ter liberdade e autoridade organizacionais de
pessoas diretamente responsáveis pelo desenvolvimento do produto de software ou pela
execução do processo no projeto. A garantia da qualidade pode ser interna ou externa,
dependendo se a evidência da qualidade do produto ou do processo é demonstrada para a
gerência do fornecedor ou do adquirente. A garantia de qualidade pode utilizar os resultados de
outros processos de suporte, como Verificação, Validação, Revisões Conjuntas, Auditorias e
Resolução de Problemas.
List of activities. This process consists of the following activities:
1) Process implementation;
2) Product assurance;
3) Process assurance;
4) Assurance of quality systems.
6.3.1 Implementação do processo.
6.3.1.1 Um processo de garantia de qualidade adaptado ao projeto deve ser
estabelecido. Os objetivos do processo de garantia da 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 com os planos estabelecidos.
6.3.1.2 O processo de garantia de qualidade deve ser coordenado com os Processos de
Verificação (6.4), Validação (6.5), Revisão Conjunta (6.6) e Auditoria (6.7) relacionados.
6.3.1.3 Um plano para conduzir as 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
realizar as atividades de garantia de qualidade (ou suas referências na documentação oficial da
organização);
b) Procedimentos para revisão e coordenação de contratos;
c) Procedimentos para identificação, coleta, arquivamento, manutenção e
disposição de registros de qualidade;
d) Recursos, cronograma e responsabilidades para a condução das
atividades de garantia de qualidade;
e) Atividades e tarefas selecionadas de processos de apoio, tais como
Verificação (6.4), Validação (6.5), Revisão Conjunta (6.6), Auditoria (6.7) e Resolução de Problemas
(6.8).
6.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 (cláusula 6.8). Registros dessas atividades e tarefas, sua execução,
problemas e resoluções de problemas devem ser preparados e mantidos.
6.3.1.5 Os registros das atividades e tarefas de garantia da qualidade devem ser
disponibilizados ao adquirente, conforme especificado no contrato.
6.3.1.6 Deve-se assegurar que as pessoas responsáveis por assegurar a conformidade
com os requisitos do contrato tenham liberdade, recursos e autoridade organizacionais para
permitir avaliações objetivas e para iniciar, efetuar, resolver e verificar a resolução de problemas.
6.3.2 Garantia do produto.
6.3.2.1 Deve ser assegurado que todos os planos exigidos pelo contrato estão
documentados, cumprem o contrato, são mutuamente consistentes e estão sendo executados
conforme necessário.
6.3.2.2 Deve ser assegurado que os produtos de software e a documentação
relacionada cumprem com o contrato e aderem aos planos.
6.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.
6.3.3 Garantia de processo.
6.3.3.1 Deve-se assegurar que os processos de ciclo de vida de software (fornecimento,
desenvolvimento, operação, manutenção e processos de suporte, incluindo garantia de qualidade)
utilizados para o projeto cumpram o contrato e sigam os planos.
6.3.3.2 Deve-se assegurar que as práticas internas de engenharia de software, o
ambiente de desenvolvimento, o ambiente de teste e as bibliotecas cumpram o contrato.
6.3.3.3 Deve ser assegurado que os requisitos aplicáveis ao contrato principal sejam
transmitidos ao subcontratado, e que os produtos de software do subcontratado satisfaçam os
requisitos do contrato principal.
6.3.3.4 Deve ser assegurado que o adquirente e outras partes recebam o apoio e
cooperação necessários de acordo com o contrato, negociações e planos.
6.3.3.5 Deve-se assegurar que as medições de produto e processo de software estejam
de acordo com os padrões e procedimentos estabelecidos.
6.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 receba qualquer treinamento
necessário.
6.3.4 Garantia de sistemas de qualidade. - Atividades adicionais de gerenciamento da qualidade
devem ser asseguradas de acordo com as cláusulas da ISO 9001, conforme especificado no
contrato.
6.4 Processo de verificação
O Processo de Verificação é um processo para determinar se os produtos de software de uma
atividade cumprem os requisitos ou condições impostos a eles nas atividades anteriores. Para a
eficácia de custos e desempenho, a verificação deve ser integrada, o mais cedo possível, ao
processo (como fornecimento, desenvolvimento, operação ou manutenção) que o emprega. Esse
processo pode incluir análise, revisão e teste.
Este processo pode ser executado com vários graus de independência. O grau de independência
pode variar da mesma pessoa ou pessoa diferente na mesma organização a uma pessoa em uma
organização diferente com graus variados de separação. No caso em que o processo é executado
por uma organização independente do fornecedor, desenvolvedor, operador ou mantenedor, ele
é chamado Processo de Verificação Independente.
List of activities. This process consists of the following activities:
1) Process implementation;
2) Verification.
6.4.1 Implementação do processo
6.4.1.1 Uma determinação deve ser feita se o projeto justificar 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.
6.4.1.2 Se o projeto garantir um esforço de verificação, um processo de verificação deve
ser estabelecido para verificar o produto de software.
6.4.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.
6.4.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 cláusula 6.4.2, incluindo
métodos, técnicas e ferramentas associadas para a execução das tarefas, devem ser selecionadas
para as atividades do ciclo de vida de destino e produtos de software.
6.4.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.
6.4.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 (cláusula 6.8). Todos os problemas e não-conformidades serão resolvidos. Os resultados
das atividades de verificação devem ser disponibilizados para o adquirente e outras organizações
envolvidas.
6.4.2 Verificação.
6.4.2.1 Verificação do contrato O contrato deve ser verificado considerando os critérios
listados abaixo:
a) O fornecedor tem a capacidade de satisfazer os requisitos.
b) Os requisitos são consistentes e cobrem as necessidades do usuário.
c) Procedimentos adequados para lidar com mudanças nos requisitos e
problemas crescentes são estipulados.
d) Procedimentos e sua extensão para interface e cooperação entre as
partes são estipulados, incluindo propriedade, garantia, direitos autorais e confidencialidade.
e) Os critérios e procedimentos de aceitação são estipulados de acordo com
os requisitos.
Nota - Esta atividade pode ser usada na revisão do contrato (ver cláusula 6.3.1.3 b).
6.4.2.2 Verificação do processo O processo deve ser verificado considerando os
critérios listados abaixo:
a) Os requisitos de planejamento do projeto são adequados e oportunos.
b) Os processos selecionados para o projeto são adequados,
implementados, sendo executados conforme planejado e em conformidade com o contrato.
c) Os padrões, procedimentos e ambientes para os processos do projeto são
adequados.
d) O projeto tem pessoal e pessoal treinado conforme exigido pelo contrato.
6.4.2.3 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.
6.4.2.4 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.
6.4.2.5 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.
6.4.2.6 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.
6.4.2.7 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.
6.5 Processo de validação
O Processo de Validação é um processo para determinar se os requisitos e o sistema final,
construído ou produto de software, cumprem o seu uso específico pretendido. A validação pode
ser realizada em etapas anteriores. Este processo pode ser conduzido como parte do Suporte de
Aceitação de Software (cláusula 5.3.13).
Este processo pode ser executado com vários graus de independência. O grau de independência
pode variar da mesma pessoa ou pessoa diferente na mesma organização a uma pessoa em uma
organização diferente com graus variados de separação. No caso em que o processo é executado
por uma organização independente do fornecedor, desenvolvedor, operador ou mantenedor, ele
é chamado de Processo de Validação Independente.
List of activities. This process consists of the following activities:
1) Process implementation;
2) Validation.
6.5.1 Implementação do processo.
6.5.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.
6.5.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.
6.5.1.3 Se o projeto garantir 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.
6.5.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.
6.5.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
(cláusula 6.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.
6.5.2 Validação.
6.5.2.1 Preparar os requisitos de teste selecionados, casos de teste e especificações de
teste para analisar os resultados do teste.
6.5.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.
6.5.2.3 Realizar os ensaios previstos nas cláusulas 6.5.2.1 e 6.5.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.
6.5.2.4 Valide se o produto de software satisfaz o uso pretendido.
6.5.2.5 Teste o produto de software conforme apropriado nas áreas selecionadas do
ambiente de destino.
6.6 Processo de revisão conjunta
O Processo de Revisão Conjunta é um processo para avaliar o status e os produtos de uma atividade
de um projeto, conforme apropriado. As revisões conjuntas estão nos níveis técnico e de
gerenciamento do projeto e são realizadas durante a vigência do contrato. Este processo pode ser
empregado por quaisquer duas partes, onde uma parte (parte revisora) analisa outra parte (parte
revisada).
List of activities: This process consists of the following activities:
1) Process implementation;
2) Project management reviews;
3) Technical reviews.
6.6.1 Implementação do processo.
6.6.1.1 Revisões periódicas devem ser realizadas em marcos predeterminados,
conforme especificado no (s) plano (s) do projeto. Revisões ad hoc devem ser feitas quando
consideradas necessárias por qualquer uma das partes.
6.6.1.2 Todos os recursos necessários para conduzir as revisões devem ser acordados
pelas partes. Esses recursos incluem pessoal, localização, instalações, hardware, software e
ferramentas.
6.6.1.3 As partes 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.
6.6.1.4 Problemas detectados durante as revisões devem ser registrados e inseridos no
Processo de Resolução de Problemas (cláusula 6.8), conforme necessário.
6.6.1.5 Os resultados da revisão devem ser documentados e distribuídos. A parte
revisora confirmará à parte revisada a adequação (por exemplo, aprovação, desaprovação ou
aprovação contingente) dos resultados da revisão.
6.6.1.6 As partes devem concordar com o resultado da revisão e com quaisquer
responsabilidades sobre itens de ação e critérios de fechamento.
6.6.2 Revisões de gerenciamento de projetos.
6.6.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 discutido entre as
duas partes 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.
6.6.3 Revisões técnicas.
6.6.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 (cláusula 6.2).
d) Eles estão aderindo aos horários aplicáveis.
e) Eles estão prontos para a próxima atividade.
f) O desenvolvimento, operação ou manutenção está sendo conduzido de
acordo com os planos, cronogramas, padrões e diretrizes do projeto.
6.7 Processo de auditoria
O Processo de Auditoria é um processo para determinar a conformidade com os requisitos, planos
e contrato, conforme apropriado. Esse processo pode ser empregado por duas partes, onde uma
parte (parte da auditoria) audita os produtos de software ou atividades de outra parte (parte
auditada).
List of activities. This process consists of the following activities:
1) Process implementation;
2) Audit.
6.7.1 Implementação do processo.
6.7.1.1 As auditorias devem ser realizadas em marcos predeterminados, conforme
especificado no (s) plano (s) do projeto.
6.7.1.2 O pessoal de auditoria não deve ter responsabilidade direta pelos produtos de
software e atividades que eles auditam.
6.7.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.
6.7.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.
6.7.1.5 Os problemas detectados durante as auditorias devem ser registrados e
inseridos no processo de resolução de problemas (cláusula 6.8), conforme necessário.
6.7.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.
6.7.1.7 As partes devem concordar com o resultado da auditoria e com quaisquer
responsabilidades sobre itens de ação e critérios de fechamento.
6.7.2 Auditoria.
6.7.2.1 As auditorias devem ser realizadas para assegurar que:
a) Produtos de software codificados (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.
6.8 Processo de resolução de problemas
O Processo de Resolução de Problemas é um processo para analisar e resolver os problemas
(incluindo não-conformidades), independentemente da sua natureza ou fonte, que são
descobertos durante a execução do desenvolvimento, operação, manutenção ou outros processos.
O objetivo é fornecer um meio oportuno, responsável e documentado para garantir que todos os
problemas descobertos sejam analisados e resolvidos e as tendências sejam reconhecidas.
List of activities. This process consists of the following activities:
1) Process implementation;
2) Problem resolution.
6.8.1 Implementação do processo.
6.8.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.
6.8.2 Resolução de problemas. - 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 Organizational life cycle processes
This clause defines the following organizational life cycle processes:
1) Management process;
2) Infrastructure process;
3) Improvement process;
4) Training process.
The activities and tasks in an organizational process are the responsibility of the organization using
that process. The organization ensures that the process is in existence and functional.
7.1 Processo de gerenciamento
O Processo de Gerenciamento contém as atividades e tarefas genéricas, que podem ser
empregadas por qualquer parte que tenha que gerenciar seu (s) respectivo (s) processo (s). O
gerente é responsável pelo gerenciamento de produtos, gerenciamento de projetos e
gerenciamento de tarefas dos processos aplicáveis, como o processo de aquisição, fornecimento,
desenvolvimento, operação, manutenção ou suporte.
List of activities: This process consists of the following activities:
1) Initiation and scope definition;
2) Planning;
3) Execution and control;
4) Review and evaluation;
5) Closure.
7.1.1 Iniciação e definição do escopo.
7.1.1.1 O processo de gestão deve ser iniciado através do estabelecimento dos
requisitos do processo a ser realizado.
7.1.1.2 Uma vez que os requisitos sejam estabelecidos, o gerente deve estabelecer a
viabilidade do processo, verificando se os recursos (pessoal, materiais, tecnologia e ambiente)
necessários para executar e gerenciar o processo estão disponíveis, adequados e adequados e se
o escalas de tempo até a conclusão são alcançáveis.
7.1.1.3 Conforme necessário, e por acordo de todas as partes envolvidas, os requisitos
do processo podem ser modificados neste momento para atingir os critérios de conclusão.
7.1.2 Planejamento. – O gerente deve preparar os planos para a execução do processo. Os planos
associados à execução do processo 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 processo em si;
g) Medidas de controle de qualidade a serem empregadas durante todo o processo;
h) Custos associados à execução do processo;
i) Provisão de ambiente e infraestrutura.
7.1.3 Execução e controle.
7.1.3.1 O gerente deve iniciar a implementação do plano para satisfazer os objetivos e
critérios definidos, exercendo controle sobre o processo.
 7.1.3.2 O gerente deve monitorar a execução do processo, fornecendo relatórios
internos do progresso do processo e relatórios externos ao adquirente, conforme definido no
contrato.
7.1.3.3 O gerente deve investigar, analisar e resolver os problemas descobertos
durante a execução do processo. 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.
7.1.3.4 O gerente deve relatar, nos pontos acordados, o andamento do processo,
declarando a adesão ao planejar e resolver instâncias da falta de progresso. Estes incluem
relatórios internos e externos, conforme exigido pelos procedimentos organizacionais e pelo
contrato.
7.1.4 Revisão e avaliação.
7.1.4.1 O gerente deve assegurar que os produtos e planos de software sejam avaliados
quanto à satisfação dos requisitos.
7.1.4.2 O gerente deve avaliar os resultados da avaliação dos produtos de software,
atividades e tarefas
concluída durante a execução do processo para a realização dos objetivos e conclusão dos planos.
7.1.5 Encerramento.
7.1.5.1 Quando todos os produtos de software, atividades e tarefas forem concluídos,
o gerente deve determinar se o processo está completo, levando em conta os critérios
especificados no contrato ou como parte do procedimento da organização.
7.1.5.2 O gerente deve verificar os resultados e registros dos produtos de software,
atividades e tarefas empregadas para a integralidade. Estes resultados e registros devem ser
arquivados em um ambiente adequado, conforme especificado
no contrato.
7.2 Processo de Infraestrutura
O Processo de Infraestrutura é um processo para estabelecer e manter a infraestrutura necessária
para qualquer outra
processo. A infraestrutura pode incluir hardware, software, ferramentas, técnicas, padrões e
instalações para desenvolvimento, operação ou manutenção.
Lista de atividades:
1) implementação do processo;
2) Estabelecimento da infraestrutura;
3) Manutenção da infraestrutura.
7.2.1 Implementação do processo.
7.2.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.
7.2.1.2 O estabelecimento da infraestrutura deve ser planejado e documentado.
7.2.2 Estabelecimento da infraestrutura.
7.2.2.1 A configuração da infraestrutura deve ser planejada e documentada.
Funcionalidade, desempenho, segurança, disponibilidade, requisitos de espaço, equipamentos,
custos e restrições de tempo devem ser considerados.
7.2.2.2 A infra-estrutura deve ser instalada a tempo para a execução do processo
relevante.
7.2.3 Manutenção da infraestrutura.
7.2.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.
7.3 Processo de melhoria
O Processo de Melhoria é um processo para estabelecer, avaliar, medir, controlar e melhorar um
processo de ciclo de vida de software.
Lista de atividades.
1) Estabelecimento de processo;
2) Avaliação de processos;
3) Melhoria de processos.
7.3.1 Estabelecimento do processo.- A organização deve estabelecer um conjunto de processos
organizacionais para todos os processos de ciclo de vida de software, conforme se apliquem às
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).
7.3.2 Avaliação do processo.
7.3.2.1 Um procedimento de avaliação de processo deve ser desenvolvido,
documentado e aplicado. Avaliação
registros devem ser mantidos e mantidos.
7.3.2.2 A organização deve planejar e realizar revisões dos processos em intervalos
apropriados para garantir
sua contínua adequação e eficácia à luz dos resultados da avaliação.
7.3.3 Melhoria de processos.
7.3.3.1 A organização deve efetuar essas 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 a melhoria nos processos organizacionais.
7.3.3.2 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.
 7.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.

7.4 Processo de treinamento

O processo de treinamento é um processo para fornecer e manter pessoal treinado. A aquisição,
fornecimento, O desenvolvimento, operação ou manutenção de produtos de software depende,
em grande parte, de pessoal qualificado e experiente.

Por exemplo: o pessoal do desenvolvedor deve ter treinamento essencial em gerenciamento de

software e engenharia de software. Portanto, é imprescindível que o treinamento de pessoal seja
planejado e implementado com antecedência, para que pessoal treinado esteja disponível à
medida que o produto de software é adquirido, fornecido, desenvolvido, operado ou mantido.

Lista de atividades.
1) implementação do processo;
2) Desenvolvimento de material de treinamento;
3) Implementação do plano de treinamento.

7.4.1 Implementação do processo. Uma revisão dos requisitos do projeto deve ser conduzida para
estabelecer e fazer provisão
adquirir ou desenvolver os recursos e habilidades requeridos pela gerência e equipe técnica. Os
tipos e níveis de formação e as categorias de pessoal que necessitam de formação devem ser
determinados. Um plano de treinamento, abordando os cronogramas de implementação, os
requisitos de recursos e as necessidades de treinamento, deve ser desenvolvido e documentado.

7.4.2 Desenvolvimento de material de treinamento. -Manuais de treinamento, incluindo

materiais de apresentação utilizados no treinamento, devem ser desenvolvidos.

7.4.3 Implementação do plano de treinamento

7.4.3.1 O plano de treinamento deve ser implementado para fornecer treinamento ao
pessoal. Registros de treinamento devem ser mantidos.
7.4.3.2 Deve ser assegurado que a combinação certa e as categorias de pessoal
adequadamente treinado estejam disponíveis para as atividades e tarefas planejadas em tempo
hábil.