NBR ISO 12207:2008

É uma norma que trata sobre a padronização de processos de ciclo de vida de software para múltiplas áreas de atuação.

Software é uma parte fundamental da tecnologia de informação e de sistemas convencionais, tais como sistemas de transporte, militares, da área médica e financeiros. Tem havido uma proliferação de normas, procedimentos, métodos, ferramentas e ambientes de desenvolvimento e de gerência de software. Esta proliferação tem criado dificuldades na gerência e engenharia de software, principalmente na integração de produtos e serviços. A disciplina de software necessita migrar desta proliferação para uma estrutura comum que possa ser usada por profissionais de software para “falar a mesma língua” na criação e gerência de software. Esta Norma provê tal estrutura comum.

A estrutura cobre o ciclo de vida de software desde a concepção de idéias até a descontinuação do software, e consiste nos processos de aquisição e fornecimento de produtos e serviços de software. Adicionalmente, a estrutura provê o controle e a melhoria destes processos.

Os processos desta Norma formam um conjunto abrangente. Uma organização, dependendo de seu objetivo, pode selecionar um subconjunto apropriado para satisfazê-lo. Esta Norma é, portanto, projetada para ser adaptada para uma organização, projeto ou aplicação específicos. Também é projetada para ser utilizada quando o software é uma entidade independente ou embutida ou integrada a um sistema.

1. Objetivo e campo de aplicação

1.1 Objetivo

Esta Norma estabelece uma estrutura comum para os processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indústria de software. A estrutura contém processos, atividades e tarefas que servem para ser aplicadas durante a aquisição de um sistema que contém software, de um produto de software independente ou de um serviço de software, e durante o fornecimento, desenvolvimento, operação e manutenção de produtos de software. O termo software inclui a parte de software de firmware.

Esta Norma também provê um processo que pode ser utilizado para definir, controlar e melhorar os processos de ciclo de vida de software.

1.2 Campo de aplicação

Esta Norma aplica-se à aquisição de sistemas, produtos e serviços de software, para o fornecimento, o desenvolvimento, a operação e a manutenção de produtos de software, e para a parte de software de firmware, quer sejam executados interna ou externamente a uma organização. Alguns aspectos necessários de definição de sistemas, para prover o contexto a produtos e serviços de software, estão incluídos.

NOTA – Os processos utilizados durante o ciclo de vida de software necessitam ser compatíveis com os processos utilizados durante o ciclo de vida de sistema

Esta Norma é destinada para ser utilizada em uma relação entre duas partes e pode ser igualmente aplicada quando as duas partes forem da mesma organização. A relação pode ser desde um acordo informal até um contrato legal. Esta Norma pode ser utilizada por uma única parte por meio de tarefas impostas a ela mesma.

Esta Norma não foi concebida para produtos de software de prateleira, a menos que eles estejam incorporados dentro de um produto encomendado.

Esta Norma foi escrita para adquirentes de sistemas e produtos e serviços de software, e para fornecedores, desenvolvedores, operadores, mantenedores, gerentes, gerentes de garantia da qualidade e usuários dos produtos de software.

1.3 Adaptação desta Norma

Esta Norma contém um conjunto de processos, atividades e tarefas projetado para ser adaptado de acordo com cada projeto de software. O processo de adaptação consiste na supressão de processos, atividades e tarefas não aplicáveis.

NOTA – Processos, atividades e tarefas, específicos ou especiais, podem ser adicionados ao contrato.

1.4 conformidade

A conformidade a esta Norma é definida como a execução de todos os processos, atividades e tarefas, selecionados desta Norma no processo de adaptação (anexo A), para o projeto de software. A execução de um processo ou uma atividade é concluída quando todas as suas tarefas requeridas são executadas de acordo com os critérios preestabelecidos e com os requisitos especificados no contrato, quando aplicável.

Qualquer organização (por exemplo, estatal ou privada) que exija o cumprimento desta Norma como uma condição de negócio, é responsável por especificar e disponibilizar o conjunto mínimo de processos, atividades e tarefas requeridos, que constitui a conformidade dos fornecedores a esta Norma.

1.5 limitações

Esta Norma descreve a arquitetura dos processos de ciclo de vida de software, mas não especifica os detalhes de como implementar ou executar as atividades e tarefas incluídas nos processos.

Esta Norma não pretende prescrever o nome, formato ou conteúdo explícito da documentação a ser produzida. Esta Norma pode requerer o desenvolvimento de documentos de mesma categoria ou tipo; por exemplo, diferentes planos. Esta Norma, contudo, não sugere que tais documentos sejam desenvolvidos ou emitidos separadamente ou combinados de alguma forma. Estas decisões são deixadas para o usuário desta Norma.

Esta Norma não prescreve um modelo específico de ciclo de vida ou método de desenvolvimento de software. As partes envolvidas com esta Norma são responsáveis pela seleção de um modelo de ciclo de vida para o projeto de software e pelo mapeamento dos processos, atividades e tarefas desta Norma dentro deste modelo. As partes envolvidas são também responsáveis pela seleção e aplicação dos métodos de desenvolvimento de software e pela execução das atividades e tarefas adequadas ao projeto de software.

Esta Norma não pretende entrar em conflito com quaisquer políticas, normas ou procedimentos já existentes na organização. Entretanto, qualquer conflito necessita ser resolvido e quaisquer condições e situações de sobreposição precisam ser citadas por escrito como exceções para a aplicação desta Norma.

Ao longo desta Norma, “deve” é utilizado para expressar uma obrigação entre duas ou mais partes; “deverá” para expressar uma declaração de objetivo ou intenção de uma das partes; “deveria” para expressar uma recomendação entre várias possibilidades; e “pode” para indicar uma ação permitida dentro dos limites desta Norma.

Nesta Norma, as listas definidas para as tarefas não pretendem ser exaustivas, porém usadas como exemplos.

2. Referências normativas

As normas relacionadas a seguir contêm disposições que, ao serem citadas neste texto, constituem prescrições para esta Norma. As edições indicadas estavam em vigor no momento desta publicação. Como toda norma está sujeita a revisão, recomenda-se àqueles que realizam acordos com base nesta que verifiquem a conveniência de se usarem as edições mais recentes das normas citadas a seguir. A ABNT possui a informação das normas em vigor em um dado momento.

• ISO/AFNOR:1989 – Dictionary of computer Science;
• ISO/IEC 2382-1:1993 – Information technology – Vocabulary – Part 1: Fundamental terms;
• ISO/IEC 2382-20:1990 – Information technology – Vocabulary – Part 20: System Development;
• NBR ISO 8402:1994 – Gestão da qualidade e garantia da qualidade – Terminologia NBR
• ISO 9001:1994 – Sistema da qualidade – Modelo para garantia da qualidade em projeto, desenvolvimento, produção, instalação e serviços associados;
• ISO/IEC 9126:19911) – Information technology – Software product evaluation – Quality characteristics and guidelines for their use.

3 Definições

Para os propósitos desta Norma as definições contidas nas NBR ISO 8402, ISO/IEC 2382-1 e ISO/IEC 2382-20 aplicam-se em conjunto com as seguintes definições:

NOTA – Um produto pode ser entendido como uma parte de um sistema, quando aplicável.

3.1 Adquirente

Uma organização que adquire ou obtém um sistema, produto de software ou serviço de software de um fornecedor.

NOTA – O adquirente poderia ser: comprador, cliente, proprietário ou usuário.

3.2 Aquisição

Processo de obtenção de um sistema, produto de software ou serviço de software.

3.3 Acordo

Definição de termos e condições sob a qual o relacionamento de trabalho entre as partes deverá ser conduzido.

3.4 Auditoria

Processo conduzido por uma pessoa autorizada, com o objetivo de prover um julgamento independente de produtos e processos de software, a fim de avaliar a conformidade com seus requisitos.

3.5 Linha básica (baseline)

Versão formalmente aprovada de um item de configuração, independente de mídia, formalmente definida e fixada em um determinado momento durante o ciclo de vida do item de configuração.

3.6 Item de configuração

Entidade dentro de uma configuração que satisfaz uma função de uso final e que pode ser identificada de forma única em um determinado ponto de referência.

3.7 Contrato

Acordo realizado entre duas partes, respaldado pela lei, ou acordo interno similar restrito a uma organização, para o fornecimento de serviços de software ou para o fornecimento, desenvolvimento, produção, operação ou manutenção de um produto de software.

3.8 Desenvolvedor

Organização que executa atividades de desenvolvimento (incluindo análise de requisitos, projeto, testes até aceitação) durante o processo de ciclo de vida de software.

3.9 Avaliação

Determinação sistemática do grau de atendimento de uma entidade em relação aos critérios para ela estabelecidos.

3.10 Firmware

Combinação de um dispositivo de hardware e instruções ou dados de computador que residem como um software somente para leitura no dispositivo de hardware. Este software não pode ser diretamente modificado por um programa.

3.11 Modelo de ciclo de vida

Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos até o término de seu uso.

3.12 Mantenedor

Organização que executa atividades de manutenção.

3.13 Monitoração

Exame da situação das atividades de um fornecedor e dos seus resultados, efetuado pelo adquirente ou uma terceira parte.

3.14 Item que não será entregue

Hardware ou produto de software cuja entrega não é exigida em contrato, mas pode ser utilizado no desenvolvimento do produto de software.

3.15 Produto de prateleira

Produto já desenvolvido e disponível para utilização na forma em que se encontra ou com modificação.

3.16 Operador

Organização que opera o sistema.

3.17 Processo

Conjunto de atividades inter-relacionadas, que transforma entradas em saídas.

NOTA – O termo “atividades” engloba a utilização de recursos. [Ver NBR ISO 8402:1994, 1.2]

3.18 Qualificação

Processo de demonstrar se uma entidade é capaz de atender os requisitos especificados. [Ver NBR ISO 8402:1994, 2.13]

3.19 Requisito de qualificação

Conjunto de critérios ou de condições que, quando atendido, qualifica um produto de software quanto à conformidade às suas especificações e quanto à sua utilização no seu ambiente-alvo.

3.20 Teste de qualificação

Teste conduzido pelo desenvolvedor e testemunhado pelo adquirente (quando apropriado), para demonstrar que o produto de software atende as suas especificações e está pronto para utilização no seu ambiente-alvo.

3.21 Garantia da qualidade

Conjunto de atividades planejadas e sistemáticas, implementadas no sistema da qualidade e demonstradas como necessárias, para prover confiança adequada de que uma entidade atenderá os requisitos para a qualidade.

Notas:

1. A garantia da qualidade visa, simultaneamente, aos objetivos internos e externos:

A) Garantia da qualidade interna: dentro de uma organização, a garantia da qualidade provê confiança à administração;

B) Garantia da qualidade externa: em situações contratuais ou outras, a garantia da qualidade provê confiança aos clientes ou a outros.

2. Algumas ações do controle da qualidade e da garantia da qualidade são inter-relacionadas.

3 Se os requisitos para a qualidade não refletirem inteiramente as necessidades do usuário, a garantia da qualidade pode não prover a confiança adequada.

[Nbr iso 8402:1994, 3.5]

3.22 Liberação (release)

Versão particular de um item de configuração que é colocada à disposição para um propósito específico (por exemplo, liberação para teste).

3.23 Pedido de proposta

Documento utilizado pelo adquirente como meio para divulgar aos potenciais fornecedores sua intenção de adquirir um sistema, produto de software ou serviço de software especificado.

3.24 Descontinuação

Cancelamento do suporte ativo pela organização de operação e manutenção, substituição total ou parcial por um novo sistema, ou instalação de um sistema atualizado.

3.25 Segurança

Proteção de informações e dados de modo que pessoas ou sistemas não autorizados não possam lê-los ou modificá-los e que pessoas ou sistemas autorizados não tenham acesso negado a eles.

3.26 Produto de software

Conjunto de programas de computador, procedimentos e possível documentação e dados associados.

3.27 Serviço de software

Execução de atividades, trabalho ou obrigações relacionados ao produto de software, tais como seu desenvolvimento, manutenção e operação.

3.28 Unidade de software

Parte de código compilável separadamente.

3.29 Descrição de tarefas

Documento utilizado pelo adquirente como um meio para descrever e especificar as tarefas a serem executadas conforme o contrato.

3.30 Fornecedor

Organização que firma um contrato com o adquirente para fornecimento de um sistema, produto de software ou serviço de software conforme os termos do contrato.

Notas

O termo “fornecedor” é sinônimo de contratado, produtor, vendedor ou distribuidor.

2 O adquirente pode designar uma parte de sua organização como fornecedor.

3.31 Sistema

Conjunto integrado que consiste em um ou mais processos, hardware, software, recursos e pessoas, capaz de satisfazer uma necessidade ou objetivo definido.

3.32 Cobertura de teste

Extensão em que os casos de teste dos requisitos de um sistema ou produto de software são testados.

3.33 Testabilidade

Extensão em que um teste objetivo e factível pode ser projetado para determinar se um requisito é atendido.

3.34 Usuário

Indivíduo ou organização que utiliza um sistema em operação para executar uma função específica.

NOTA – O usuário pode executar outros papéis, tais como adquirente, desenvolvedor ou mantenedor.

3.35 Validação

Confirmação, por exame e fornecimento de evidência objetiva, de que os requisitos específicos, para um determinado uso pretendido, são atendidos.

Notas:

1. Nas atividades de projeto e desenvolvimento, a validação se refere ao processo de examinar um produto para determinar sua conformidade com as necessidades do usuário.

2. A validação é feita normalmente no produto final sob condições de operação definidas, podendo, contudo, tornar-se necessária em fases anteriores.

3. O termo “validado” é usado para designar o estado após a validação.

4. “Validações múltiplas” podem ser realizadas se existirem diferentes usos pretendidos.

3.36 Verificação

Confirmação, por exame e fornecimento de evidência objetiva, do atendimento aos requisitos especificados.

Notas

1. Nas atividades de projeto e desenvolvimento, a verificação refere-se ao processo de examinar o resultado de dada atividade para determinar sua conformidade com os requisitos estabelecidos para a mesma atividade.

2. O termo “verificado” é usado para designar o estado após a verificação.

[NBR ISO 8402:1994, 2.17]

3.37 Versão

Instância identificada de um item.

NOTA – Modificações em uma versão de produto de software, resultando em uma nova versão, requerem uma ação de gerência de configuração.

4. Aplicação desta Norma

Esta seção apresenta os processos de ciclo de vida de software que podem ser empregados para adquirir, fornecer, desenvolver, operar e manter produtos de software. O objetivo é prover um guia para os usuários desta Norma para que eles possam orientar-se na mesma e aplicá-la criteriosamente.

4.1 Organização desta Norma

4.1.1 Processos de ciclo de vida

Esta Norma agrupa as atividades que podem ser executadas durante o ciclo de vida de software em cinco processos fundamentais, oito processos de apoio e quatro processos organizacionais. Cada processo de ciclo de vida é dividido em um conjunto de atividades; cada atividade é então dividida em um conjunto de tarefas. Uma seção numerada por a.b denota um processo, a.b.c uma atividade e a.b.c.d uma tarefa. Estes processos de ciclo de vida são introduzidos a seguir e ilustrados na figura 1.

4.1.1.1 Processos fundamentais de ciclo de vida

Os processos fundamentais de ciclo de vida (seção 5) constituem um conjunto de cinco processos que atendem as partes fundamentais (pessoa ou organização) durante o ciclo de vida de software. Uma parte fundamental é aquela que inicia ou executa o desenvolvimento, operação ou manutenção dos produtos de software. Estas partes fundamentais são o adquirente, o fornecedor, o desenvolvedor, o operador e o mantenedor do software. Os processos fundamentais são (FODAM é fundamental):

2) Processo de Fornecimento (subseção 5.2). Define as atividades do fornecedor, organização que provê o sistema, produto de software ou serviço de software ao adquirente.

4) Processo de Operação (subseção 5.4). Define as atividades do operador, organização que provê serviço de operação de um sistema computacional, no seu ambiente de funcionamento, para seus usuários.

3) Processo de Desenvolvimento (subseção 5.3). Define as atividades do desenvolvedor, organização que define e desenvolve o produto de software.

1) Processo de Aquisição (subseção 5.1). Define as atividades do adquirente, organização que adquire um sistema, produto de software ou serviço de software.

5) Processo de Manutenção (subseção 5.5). Define as atividades do mantenedor, organização que provê o serviço de manutenção do produto de software, isto é, gerenciando as modificações no produto de software para mantê- lo atualizado e em perfeita operação. Este processo inclui a migração e a descontinuação do produto de software.

4.1.1.2 Processos de apoio de ciclo de vida

Os processos de apoio de ciclo de vida (seção 6) constituem um conjunto de oito processos. Um processo de apoio auxilia um outro processo como uma parte integrante, com um propósito distinto, e contribui para o sucesso e qualidade do projeto de software. Um processo de apoio é empregado e executado, quando necessário, por outro processo. Os processos de apoio são:

1) Processo de documentação (subseção 6.1). Define as atividades para registro da informação produzida por um processo de ciclo de vida.

2) Processo de gerência de configuração (subseção 6.2). Define as atividades de gerência de configuração.

3) Processo de garantia da qualidade (subseção 6.3). Define as atividades para garantir objetivamente que os produtos e processos de software estão em conformidade com seus requisitos especificados e aderem aos seus planos estabelecidos. Revisões conjuntas, auditorias, verificação e validação podem ser utilizadas como técnicas para garantia da qualidade.

4) Processo de verificação (subseção 6.4). Define as atividades (para o adquirente, o fornecedor, ou uma parte independente) para verificação dos produtos de software, em profundidade variável, dependendo do projeto de software.

5) Processo de validação (subseção 6.5). Define as atividades (para o adquirente, o fornecedor ou uma parte independente) para validação dos produtos de software do projeto de software.

6) Processo de revisão conjunta (subseção 6.6). Define as atividades para avaliação da situação e produtos de uma atividade. Este processo pode ser empregado por qualquer uma das duas partes, onde uma delas (parte revisora) revisa a outra parte (parte revisada) em um fórum conjunto.

7) Processo de auditoria (subseção 6.7). Define as atividades para determinar a conformidade com requisitos, planos e contrato. Este processo pode ser empregado por qualquer uma das duas partes, onde uma delas (parte auditora) audita os produtos de software ou atividades da outra parte (parte auditada).

8) Processo de resolução de problema (subseção 6.8). Define um processo para análise e remoção dos problemas (incluindo não-conformidades), independente da sua natureza ou origem, que forem descobertos durante a execução dos processos de desenvolvimento, de operação, de manutenção ou de outros processos.

4.1.1.3 Processos organizacionais de ciclo de vida

Os processos organizacionais de ciclo de vida (seção 7) constituem um conjunto de quatro processos. Eles são empregados por uma organização para estabelecer e implementar uma estrutura subjacente, constituída de processos de ciclo de vida e pessoal associados, e melhorar continuamente a estrutura e os processos. Eles são tipicamente empregados fora do domínio de projetos e contratos específicos; entretanto, ensinamentos destes projetos e contratos contribuem para a melhoria da organização. Os processos organizacionais são:

1) Processo de gerência (subseção 7.1). Define as atividades básicas da gerência, incluindo gerência de projeto, durante um processo de ciclo de vida.

2) Processo de infra-estrutura (subseção 7.2). Define as atividades básicas para o estabelecimento da estrutura de apoio de um processo de ciclo de vida.

3) Processo de melhoria (subseção 7.3). Define as atividades básicas que uma organização (isto é, adquirente, fornecedor, desenvolvedor, operador, mantenedor, ou o gerente de outro processo) executa para estabelecer, medir, controlar e melhorar seu processo de ciclo de vida.

4) Processo de treinamento (subseção 7.4). Define as atividades para prover pessoal adequadamente treinado.

4.1.2 Processo de adaptação

O anexo A define as atividades básicas necessárias para executar as adaptações desta Norma. O anexo B contém orientação para a adaptação dos requisitos desta Norma; ele relaciona os fatores-chave sobre os quais as decisões de adaptação podem ser feitas.

4.1.3 Relacionamento entre os processos e as organizações

Esta Norma contém vários processos que são aplicados ao longo de ciclo de vida de software por várias organizações, dependendo de suas necessidades e objetivos. Para melhor esclarecimento, o anexo C apresenta os relacionamentos entre os processos de ciclo de vida e as partes envolvidas.

Bibliografia

Questões

• Governança de TI
  • ISO IEC 12207:2008

Resolução de Questões de Concursos Anteriores

RESPOSTA: B

RESPOSTA: Errado

Segundo a norma ISO/IEC 12.207, o processo chamado “Infraestrutura” é responsável criação, organização e manutenção da infraestrutura de suporte (hardware, software, ferramentas, metodologias, padrões e instalações) para os demais processos do ciclo de ciclo de vida. Enquanto o processo de “Gerência” define as atividades básicas de gestão, incluindo a gestão de projetos. Apesar de ambos os processos serem categorizados como Processos Organizacionais, o processo de Infraestrutura não faz parte do processo de Gerência. Eles tem objetivos distintos, apesar de ambos buscarem melhorias na estrutura e nos processos. Assim, a questão está errada.

Abaixo, uma definição de processos organizacionais, somente para termos uma referência teórica:

Processos Organizacionais: Implementam uma estrutura constituída de processos de ciclo de vida e pessoal associados, melhorando continuamente a estrutura e os processos.

RESPOSTA: Certo

RESPOSTA: E

Gestão de Projetos é uma das atividades que pertencem ao grupo de Gerência.

RESPOSTA: D

RESPOSTA: E

A ISO 12207 tem foco em um conjunto de processos chamados processos de ciclo de vida. Ela agrupa seus processos de ciclo de vida em 3 grupos: processos fundamentais, processos de apoio e processos organizacionais.

Além dos processos de ciclo de vida, a ISO 12207 contém anexos que tratam do processo de adaptação, que define atividades básicas necessárias para executar as adaptações da norma.

Não há classificações diferentes destas.

O processo de Manutenção de software é um processo fundamental do ciclo de vida, que não está listado em nenhuma das alternativas da questão, portanto a questão deveria ser anulada. Mas, existe uma versão mais antiga da ISSO que engloba essa classificação:

• Processos contratuais
  • Aquisição e Fornecimento
• Processos Organizacionais Capacitadores de Projeto
  • Gestão de Modelo de Ciclo de Vida
  • Gestão de Infraestrutura
  • Gestão de Portfólio de Projetos
  • Gestão de Recursos Humanos
  • Gestão da Qualidade
• Processos de Projeto
  • Planejamento de Projeto
  • Controle e Avaliação de Projeto
  • Tomada de Decisão
  • Gestão de Risco
  • Gestão de Configuração
  • Gestão da Informação
  • Gestão de Medição
• Processos Técnicos
  • Definição dos Requisitos dos Stakeholders
  • Análises dos Requisitos de Sistema
  • Projeto de Arquitetura de Sistema
  • Implementação, Integração de Sistema
  • Teste de Qualificação de Sistema
  • Instalação de Software
  • Suporte de Aceitação de Software
  • Operação de Software
  • Manutenção de Software
• Processos de Implementação de Software
  • Implementação de Software
  • Análise de Requisito de Software
  • Projeto de Arquitetura de Software
  • Projeto de Software
  • Construção de Software
  • Integração de Software
  • Testes de Qualificação de Software
• Processos de Suporte de Software
  • Gestão de Documentação
  • Gestão de Configuração de Software
  • Garantia da Qualidade de Software
  • Verificação de Software
  • Validação de Software
  • Revisão de Software
  • Auditoria de Software
  • Resolução de Problema de Software
• Processos de Reuso de Software
  • Engenharia de Domínio
  • Gestão do Programa de Reuso

RESPOSTA: B

RESPOSTA: D

o item 6.3 Projeto de Processos (pág. 32 da ISO/IEC 12207, versão em inglês) é composto dos seguintes subitens:

• Processo de Planejamento de Projeto;
• Processo de Controle e Avaliação de Projetos;
• Processo de Gerenciamento/Gestão de Decisão;
• Processo de Gerenciamento/Gestão de Riscos;
• Processo de Gerenciamento/Gestão de Configuração;
• Processo de Gerenciamento/Gestão da Informação;
• Processo de Medição/Medida/Métrica.

RESPOSTA: B

RESPOSTA: C

A ISO/IEC 12207 é a norma ISO/IEC que define processo de desenvolvimento de software.

A norma ISO/IEC 12207 estabelece uma arquitetura de alto nível do ciclo de vida de software que é construída a partir de um conjunto de processos e seus inter-relacionamentos. Os processos são descritos tanto em nível de propósito/saídas como em termos de atividades.

A ISO/IEC 12207 não possui nenhuma ligação com métodos, ferramentas, treinamentos, métricas ou tecnologias empregadas. Esta determinação é útil para permitir que a norma seja utilizada mundialmente e possa acompanhar a evolução da engenharia de software nas diversas culturas organizacionais. Ela pode ser utilizada com qualquer modelo de ciclo de vida, método ou técnica de engenharia de software e linguagem de programação. Sua flexibilidade é uma característica importante, as atividades e tarefas do processo de ciclo de vida do software especificam “o que fazer” e não “como fazer”.

RESPOSTA: D

I – Falso: É a definição do CMMI. A norma 12207 tenta padronizar processos de software e não estabelece níveis de maturidade ou de processos.

RESPOSTA: A

RESPOSTA: E