Gerencia de configuracao de sof - Unisinos

Prévia do material em texto

GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
RODRIGO SAAD
Editora Unisinos, 2014
SUMÁRIO
Apresentação
Capítulo 1 – Introdução
Capítulo 2 – Padrões internacionais e modelos de processos
Capítulo 3 – A perspectiva de definição de processos
Capítulo 4 – A perspectiva de execução da gerência de configuração
Capítulo 5 – Gerência de configuração em projetos baseados em métodos
ágeis
Referências
Informações técnicas
APRESENTAÇÃO
Este livro tem por objetivo apresentar um conjunto de conceitos
fundamentais para a disciplina de Gerência de Configuração de Software e
também oferecer uma visão prática que irá ilustrar as perspectivas de
definição e de execução do processo de Gerência de Configuração.
No primeiro capítulo, serão apresentados conceitos base e alguns
mais amplos, tais como as principais definições de Gerência de
Configuração, o relacionamento com outras áreas que compõem o
processo de Engenharia de Software, seus papéis fundamentais e os
artefatos que se espera que sejam resultado da implementação e
execução do processo.
No Capítulo 2, veremos como o padrão ISO (International
Organization for Standardization) e os principais modelos de processo,
como o MPS.BR e o CMMI, abordam a disciplina. A partir dessas
definições, serão apresentadas, no Capítulo 3, a perspectiva de definição
de processo e, no Capítulo 4, uma ilustração mais prática da execução da
Gerência de Configuração em um projeto de Software.
No Capítulo 5, tem-se uma ilustração da adoção das práticas de
Gerência de Configuração no contexto de métodos ágeis.
Espera-se que o material apresentado seja a principal referência
para os estudos da disciplina de Gerência de Configuração. Será
fundamental que as leituras complementares indicadas, bem como as
referências bibliográficas desta obra, sejam também consultadas.
Rodrigo Saad1
__________
1 Rodrigo Saad. Graduado em Análise de Sistemas pela Universidade Católica de
Pelotas, tem pós-graduação em Ciência da Computação pela PUC-RS e MBA em
Gestão Empresarial pela Fundação Getúlio Vargas. Possui mais de dezesseis anos de
experiência em TI, área em que exerceu funções de analista de sistemas, webmaster,
desenvolverdor de sotfware, engenheiro de teste de performance, consultor em modelos
de qualidade de sofware e gerente de tecnologia de informação. É professor na
UNISINOS desde 2007.
CAPÍTULO 1
INTRODUÇÃO
Este capítulo apresenta um pouco do histórico da Gerência de Configuração de
Software e os principais conceitos relacionados a disciplina, tais como: atividades,
propósito, benefícios, impactos em outras áreas de processo presentes no ciclo de
Desenvolvimento de Software e uma visão de principais atores e artefatos no contexto
da execução do processo.
A Gerência de Configuração passou a ser tratada como uma
disciplina distinta no âmbito da Engenharia de Software na década de
1980.
Essa disciplina em si tem como domínio de aplicação o processo
de engenharia de sistemas de uma perspectiva mais ampla (na qual
sistemas podem ser interpretados como um conjunto complexo de
componentes construídos para funcionamento integrado, visando um
propósito comum, e.g. softwares, hardwares, veículos etc).
No contexto dessa disciplina, focaremos na aplicação dos conceitos
de Gerência de Configuração no ramo da Engenharia de Software, que
passa a ser denominada Gerência de Configuração de Software (GCS, ou
Software Configuration Management – SCM, no termo original em inglês).
1.1 Principais estudos
As primeiras publicações sobre a Gerência de Configuração de
Software foram realizadas por quatro fontes: DoD (Departamento de
Defesa Americano), IEEE (Institute of Eletric and Eletronic Engineers), SEI
(Software Engineering Institute at Carnegie Mellon University) e ISO
(International Organization for Standardization).
Em 1986, na publicação CMU/SEI-86-TR-5, definiu-se que a
Gerência de Configuração representa “disciplinas e técnicas de iniciação,
avaliação e controle de mudança em produtos de software durante e
depois do processo de desenvolvimento” (Katherine Harvey, 1986, p. 01).
Na década de 1990, importantes estudos aprofundaram a
discussão sobre a disciplina, e, conjuntamente, a definição base IEEE, ISO
e SEI publicaram interpretações complementares do foco e do conjunto de
atividades que integram a Gerência de Configuração.
Robert Bamfort e William J. Deibler II, em seu artigo Configuration
Management and ISO9001 (1995, p. 01), citam que o IEEE em seu
documento Standard 828-1990, define que as atividades de Gerência de
Configuração de Software são agrupadas em quatro funções: identificação
da configuração, controle da configuração,
contabilização/acompanhamento de estado (status) e revisões e auditorias
da configuração.
Nessa publicação, entende-se a identificação da configuração como
sendo o ato de identificar, nomear e descrever as características físicas e
funcionais documentadas de um código, suas especificações, seu design
e seus elementos de dados a serem controlados para/no projeto. O
controle diz respeito à formalidade e ao acompanhamento de mudanças
por meio de requisições, avaliações, aprovações/desaprovações e da
própria implementação da mudança. A contabilização/acompanhamento
do status registra estados específicos (relativos a evolução do artefato na
sequência/fases do projeto) dos itens de configuração. As revisões e
auditorias determinam/garantem em que extensão os itens de
configuração (desenvolvidos) refletem as características físicas e
funcionais requeridas.
A ISO 9001 (conjunto de normas voltadas para a gestão de
qualidade), em seu documento guia ISO 9000-3-1991 (Guidelines for the
application of ISO 9001 to the development, supply and maintenance of
software) traz uma definição similar para a Gerência de Configuração, bem
como para as atividades que a compõe, dizendo que ela “[...] provê um
mecanismo para identificação, controle e acompanhamento das versões
de cada item de software. Em muitos casos versões anteriores ainda em
uso devem também ser mantidas e controladas” (Robert Bamford e
William J. Deibler II, 1995, p. 01.)
Ainda, nesta publicação, encontra-se que um sistema de Gerência
de Configuração deveria:
a. identificar unicamente as versões de cada item de software;
b. identificar unicamente as versões de cada item de software, as
quais constituem conjuntamente uma versão específica de um
produto;
c. identificar os estados (de construção) do(s) produto(s) de
software em desenvolvimento ou entregue ou instalado;
d. controlar as atualizações simultâneas de um item de software
por mais de uma pessoa;
e. prover a coordenação para atualização de múltiplos produtos em
uma ou mais localizações, se requeridos;
f. identificar e acompanhar todas as ações e mudanças
resultantes de uma solicitação de mudança (da iniciação a
liberação – release).
Em um estudo complementar, o SEI (1992), em sua publicação SEI-
92-TR-8, procura simplificar as atividades definidas no documento do IEEE
(identificação, controle, contabilização do estado, auditoria e revisão) e
amplia a definição, incluindo as etapas de manufatura (manufacturing)
gestão de processos (process management) e trabalho de time (team
work). Sendo assim, promove a definição das atividades, como a seguir:
a. Identificação da configuração: determina qual conjunto de
artefatos (arquivos) de código fonte você está trabalhando. Isso
torna possível saber, entre outras coisas, que você está
consertando um erro no código fonte que está na release correta.
b. Controle de configuração: controla o release de um produto e as
mudanças que ocorrem nele durante todo o seu ciclo de vida,
para assegurar a criação consistente de um produto de software
da linha de base. Pode incluir não somente mudanças no código
fonte, mas também qual compilador e quais outras ferramentas
foram usados. Então problemas como diferenças entre a versãodo compilador em determinado idioma podem ser levados em
conta.
c. Gerenciamento dos builds: gerencia quais processos e
ferramentas os desenvolvedores usam para criar um release, de
forma que se possa repeti-lo. 
d. Gerência do processo: assegura-se de que os processos de
desenvolvimento de organização sejam seguidos por aqueles
que desenvolvem e liberam o software. 
e. Gestão do trabalho do time (team work): controla as interações
de todos os desenvolvedores que trabalham em conjunto em um
produto, de modo que as mudanças feitas pelas pessoas sejam
introduzidas no sistema em um momento oportuno.
f. Auditoria de status: registra e relata o status dos componentes e
dos pedidos da mudança, registrando estatísticas vitais sobre
componentes no produto. Uma pergunta possível de resposta,
por exemplo, seria a de quantos arquivos foram afetados
consertando tal erro.
g. Revisão: identifica um conjunto de artefatos que compõe uma
versão do produto, valida a sua integralidade e mantém a
consistência entre seus artefatos (componentes), assegurando-
se de que eles estejam em um estado apropriado durante todo o
ciclo de vida do projeto, de modo a determinar uma coleção bem
definida
Na evolução do estudo em gestão da qualidade, a ISO publicou
algumas normas voltadas à padronização internacional do processo de
um ciclo de vida de software, sendo elas: ISO/IEC 12207, ISO/IEC 15288 e
ISO/IEC 15504. Essas normas definem, entre outras coisas, padrões para
a definição e avaliação de maturidade/capacidade do processo de
Gerência de Configuração e foram, mais tarde, base para o
aprimoramento e elaboração de modelos de definição e avaliação de
maturidade de processos, como o CMMI (Capability Maturity Model
Integration) e o MPS.BR (Programa de Melhoria de Processos de Software
Brasileiro). O primeiro foi resultante de trabalhos de pesquisa do SEI, e o
último foi desenvolvido pela Softex com o apoio do Ministério da Ciência e
Tecnologia, da FINEP e do Banco Interamericano de Desenvolvimento. No
Capítulo 2, veremos mais detalhes referentes às normas e aos modelos
de processos.
1.2 Propósito da Gerência de Configuração e contexto de aplicação
O SEI define o propósito da Gerência de Configuração como sendo
“o de estabelecer e manter a integridade dos produtos de trabalho usando
identificação da configuração, controle da configuração, contabilização do
estado da configuração e auditorias de configuração” (2000, p. 182).
Para que possamos entender um pouco melhor o contexto da
disciplina de Gerência de Configuração de Software, é importante ressaltar
que, como citado anteriormente, as normas e os modelos de processo
são voltados ao ciclo de vida do software e, sendo assim, apresentam
definições de componentes de um processo (propósito, entradas/saídas,
atividades e tarefas) agrupadas por áreas de aplicação (e.g. Gerência de
Projetos, Gerência de Requisitos etc.) que se relacionam com as fases do
ciclo (definição/visão do projeto, planejamento, desenvolvimento,
verificação/validação, testes etc.).
Nesse cenário, a Gerência de Configuração é um processo de
apoio/suporte às demais áreas de aplicação (ou áreas de processos) que
compõem o ciclo de desenvolvimento de software e, sendo assim, permeia
todas as fases com o foco de garantir a integridade do conjunto de
artefatos que caracterizam um produto.
Figura 1 – Perspectiva da área de Gerência de Configuração em relação as fases de
um projeto de Software.
Fonte: elaborada pelo autor.
Em outras palavras, a Gerência de Configuração estará presente
em cada fase do ciclo de vida de software. Uma vez que os artefatos
resultantes das atividades de áreas de processos (e.g. plano de projeto,
documento de requisitos etc.) sejam selecionados na etapa de
identificação da configuração, eles serão formalmente controlados,
garantindo sua integridade de maneira individual, assim como a do
produto de software como um todo (por meio do controle da configuração:
versionamento, controle de mudanças etc. ).
1.3 Benefícios da Gerência de Configuração
Sendo uma atividade de suporte/apoio a outras áreas de processo,
a Gerência de configuração traz alguns benefícios. Entre os principais,
pode-se ressaltar o controle de versão e o acompanhamento de
mudanças.
O controle de versão é uma parte importante no suporte ao trabalho
efetivo dos times de desenvolvimento. As práticas de controle de versão
ajudam as pessoas a trabalharem nos mesmos componentes de forma
paralela, sem que haja interferência no trabalho um do outro.
O controle de mudanças irá garantir que quaisquer alterações em
artefatos sejam identificadas e, caso eles estejam em fases adiantadas
do desenvolvimento (versões estáveis, como testes, instalação,
manutenção), estas terão de ser avaliadas e formalmente aprovadas,
garantindo que apenas modificações de interesse das principais partes
interessadas (stakeholders) sejam incorporadas.
A Gerência de Configuração, por meio das práticas de controle de
versão e de gestão de mudança, permite ações como:
desenvolver uma nova versão de um pedaço de software enquanto
arrumando problemas com a versão corrente;
compartilhar código com outros membros do time, de um modo
controlado, permitindo o desenvolvimento paralelo com outros
membros e a inclusão do resultado ao código corrente na linha
base de código;
identificar quais versões de código foram incluídas em um
componente específico;
analisar em que ponto uma mudança aconteceu na história do
desenvolvimento de um componente.
As atividades de Gerência de Configuração podem ser vistas como
cíclicas para cada item colocado sob gerência de configuração. Isso
significa que um item de configuração é continuamente
modificado/evoluído. O primeiro ciclo é estabelecido ao início de
determinada fase de um projeto (planejamento, desenvolvimento etc), e,
mais tarde, a força evolutiva se dá a partir da publicação de uma primeira
versão estável e, posteriormente, por solicitações de
mudanças/atualizações.
Em cada ciclo, um item de configuração (ou um conjunto de itens)
será identificado, produzido, armazenado e liberado para uso. Registros de
atualizações ou evoluções irão ocorrer como resultado da validação ou do
uso do item de configuração. Tais modificações irão direcionar os itens ao
processo de controle de mudanças e à criação de solicitações de
mudanças, o que irá requerer aprovação, identificação e assim por diante,
gerando uma nova versão do artefato.
Cada versão de um item de configuração é fortemente relacionada
com as outras. Entretanto, cada uma é um item individual, que é
identificado e que pode ser extraído e utilizado independentemente. Esse é
um dos principais pontos da gerência de configuração: ser capaz de
reverter um item de configuração a suas versões anteriores.
1.4 Principais papéis e artefatos
No caminho de implementação de um processo de Gerência de
Configuração no contexto de uma organização, teremos duas perspectivas:
a definição do processo e a execução do processo.
Em geral, na definição do processo, tende-se a utilizar guias de
implementação (como os padrões ISO já citados) e/ou os modelos de
processos. Estes, em sua forma, definem de maneira geral que um
processo deverá ter uma descrição formal, ser composto de atividades
(conjunto de tarefas) e identificar de maneira explícita suas
entradas/saídas (eventos que marquem o início e o fim de uma etapa do
processo).
Nesse contexto, papéis (funções) são atribuídos para a execução
das atividades, e artefatos são gerados na maior parte das etapas.
Na figura abaixo, temos a ilustração dos principais papéis no
processo e na execução de Gerência de Configuração.
Figura 2 – Principais Papéis no contexto de Gerência de Configuração.
Fonte: elaborada pelo autor.
Esses papéis podem ser definidos como:
Controlador/gerente de configuração: responsável pelo
planejamento e execução das atividadesde gerência de
configuração relativas a um projeto ou a um produto de software.
Gerente de projeto: gestor das atividades, recursos e custos de
um projeto de desenvolvimento de software. No processo de
gerência de configuração, suporta o controlador de configuração
em suas atividades e aprova baselines e solicitações de
mudanças.
Time de projeto: time de desenvolvedores responsável pelo
desenvolvimento e/ou manutenção de um projeto ou produto de
software. No processo de gerência de configuração, será
responsável por manipular os artefatos de software segundo as
definições do plano de Gerência de Configuração.
Cliente: responsável/dono dos requisitos do produto, tem a função
de validar o conjunto de artefatos desenvolvidos para o
atendimento dos requisitos. O cliente, em geral, interage com o
processo por meio de aprovações de liberações (releases) e de
solicitações de mudança.
Auditor de qualidade (ou auditor de configuração): responsável
pela verificação da integridade do processo de gerência de
configuração em sua instanciação dentro da execução de projetos
de desenvolvimento de software. Em seu escopo, inclui-se a
checagem de evidências de execuções de atividades e a geração
de artefatos mandatórios (entregáveis).
Grupo de controle de gerência de configuração (configuration
control board group): composto, em geral, pelo controlador de
configuração, pelo gerente de projeto e pelo líder técnico do
projeto. É responsável pela avaliação e pela aprovação de
solicitações de mudança, bem como pela aprovação da criação
de baselines.
O relatório técnico do SEI (1986, p.02), CMU/SEI-86-TR-5, menciona
que um fator chave em uma implementação efetiva de Gerência de
Configuração é uma estrutura sólida para o grupo de controle de gerência
de configuração (GCGC). Por muitos anos essa estrutura foi endereçada
com baixa prioridade (uma situação na qual profissionais iniciantes
assumiam papéis chave). O GCGC deve ser ativo, um local para
discussões, no qual problemas ou requisições que afetem o escopo, o
custo ou a qualidade de um projeto precisam ser avaliados e aprovados.
Por isso, o GCGC deve ter encontros recorrentes e ser composto por
membros chave (tomadores de decisão) do time de projeto.
Cada atividade desempenhada por um ou mais papéis citados irá
gerar um ou mais artefatos que ou conterão informação crítica para o
desenvolvimento do produto, ou serão parte do produto.
Entre os principais artefatos do processo de Gerência de
Configuração temos:
Plano de gerência ou de controle de configuração: artefato parte
do grupo de planos que suportam o planejamento de projeto, e
que tem como objetivo suportar a definição da instância do
processo de gerência de configuração nesse contexto (projeto).
Solicitação de mudanças: artefato que suporta a documentação
de mudanças de requisito (escopo) que afetem os componentes
do produto e que deverá ser aprovado pelo comitê de gerência de
configuração para que posteriormente a mudança possa ser
implementada.
Plano de comunicação: define o modelo de interação esperado
entre os distintos papéis existentes no processo de Gerência de
Configuração de Software.
Baseline: organização líogica dos artefatos que compõem o
produto de software e que tem como objetivo caracterizar um
conjunto estável desses componentes, relacionados com um
determinado marco (milestone) do projeto. Ex.: em teste funcional,
em teste de usuário, liberado para o cliente (release).
Ainda, segundo a ABNT (1998), a baseline pode ser definida como
uma versão formalmente aprovada de um item de configuração,
independente de mídia, formalmente definido e fixado em um determinado
momento durante o ciclo de vida do item de configuração.
Recomendações para complementação de estudos referentes aos
temas deste capítulo:
BAMFORD, R.; DEIBLER II. Configuration Management and ISO 9001.
1995. Disponível em : <http://www.ssqc.com/do25v6new.pdf>. Acesso em:
17 mai. 2014.
Software Engineering Institute. Capability Maturity Model Integration,
Version 1.02 CMMI for Systems Engineering and Software Engineering
(CMMI-SE/SW, V1.02), Disponível em
http://www.sei.cmu.edu/reports/00tr018.pdf
HARVEY, K. Summary of SEI Workshop on Software Configuration
Management. 1986. Disponível em <http://resources.sei.cmu.edu/>.
Acesso em: 15 mai. 2014.
Resumo do capítulo
Neste capítulo, foram apresentados os conceitos base da Gerência
de Configuração de Software, as principais publicações, o impacto da área
de processo no ciclo de desenvolvimento de software, os benefícios da
Gerência de Configuração de Software e os principais papéis e
responsabilidades dessa área. Salienta-se que será importante para os
próximos capítulos o entendimento:
a. das principais atividades de Gerência de Configuração de
Software;
b. principais papéis e artefatos no processo de Gerência de
Configuração.
CAPÍTULO 2
PADRÕES INTERNACIONAIS E MODELOS DE PROCESSOS
Este capítulo apresenta uma visão geral dos principais padrões internacionais e
modelos de processos que servem como orientação a definição e a implantação da
área de Processo de Gerência de Configuração de Software. Serão abordas algumas
normas do padrão ISO, bem como os modelos de Processos CMMI e Mps.BR.
2.1 Padrões ISO/IEC 12207 e 15288
A ISO/IEC 12207 foi publicada inicialmente em 1º de agosto de 1995
e foi o primeiro padrão internacional a prover um conjunto compreensível
de processos, atividades e tarefas em um ciclo de desenvolvimento de
software (desde de um pedaço de software que compõe um sistema até
produtos de software e serviços). Em novembro de 2002, ela foi seguida
pela norma ISO/IEC 15288, que endereçou processos de ciclo de
desenvolvimento de sistemas. Ambas as normas foram revisadas em
2008, quando novas versões foram publicadas alinhando os termos entre
elas e promovendo a inclusão de ementas criadas em publicações
intermediárias (em 2002 e em 2004). Essas publicações adicionaram as
definições de propósito de processo e de saídas ao padrão internacional e
estabeleceram um modelo de referência de processos de acordo com os
requisitos do padrão ISO/IEC 15504-2.
A ISO/IEC 12207 contém processos, atividades e tarefas com foco
na aquisição de um produto ou serviço de software, assim como no
fornecimento, desenvolvimento, operação, manutenção e distribuição de
produtos de software.
Segundo consta na norma ISO/IEC 12207, os padrões definidos na
mesma podem ser aplicados em um ou mais dos seguintes contextos:
Organização: os padrões auxiliam na implementação de um
conjunto de processos desejados. Esses processos serão baseados em
um grupo de métodos, procedimentos, técnicas, ferramentas e pessoal
treinado. A organização pode então empregar essas definições para
realizar e gerenciar seus projetos e para evoluir seus sistemas (softwares)
por meio dos estágios de seu ciclo de vida. Desse modo, o padrão
internacional é usado para avaliar a conformidade da execução dos
processos organizacionais em relação a suas definições estabelecidas.
Projeto: os padrões ajudam a selecionar, estruturar e empregar os
elementos de processos de ciclo de vida definidos no âmbito da
organização e aplicá-los para desenvolver produtos ou prover serviços.
Desse modo, o padrão internacional é usado para avaliar a conformidade
do projeto em relação às definições de processo estabelecidas.
Adquirente ou fornecedor: os padrões auxiliam no desenvolvimento
de acordos que envolvam processos e atividades. Desse modo, o padrão
internacional é usado para guiar e desenvolver os acordos.
Organizações e avaliadores: os padrões contribuem para a
realização de avaliações que podem ser usadas para melhorias de
processos organizacionais.
A ISO/IEC 12207 descreve um conjunto compreensível de
processos, atividades e tarefas a serem realizadas quando se adquire ou
desenvolve um software (o que engloba a manutenção e o fornecimento).Entretanto, a norma não explicita como realizá-las. Tais conceitos,
conforme vimos anteriormente, podem ser utilizadas na definição dos
processos relacionados ao ciclo de software, bem como na sua avaliação
e controle.
A norma define um processo (ou grupos de processo) da seguinte
forma:
título;
propósito;
resultados esperados (a partir de uma implementação bem
sucedida);
atividades;
tarefas.
No intuito de descrever mais objetivamente os processos
propostos, alguns desses processos possuem uma definição mais
detalhada em níveis adicionais, denominados sub-processos. Nesse
sentido, um processo é formado por sub-processos e/ou atividades,
sabendo-se que atividades são um conjunto de tarefas, que tem por
objetivo apoiar a obtenção de um resultado esperado.
A ISO/IEC 12207 agrupa os processos em dois grandes grupos:
processos de contexto de sistema (ciclo de vida de sistemas) e processos
específicos de software, divididos em sete categorias. como se vê abaixo.
Figura 3 – Grupos de processos – ISO/IEC 12207.
Fonte: elaborada pelo autor.
Nesse contexto, o processo de gerência de configuração faz parte
dos sub-processos de apoio de projetos, que estão contidos nos
processos de projeto no grupo relativo ao contexto de sistema (ciclo de
vida de sistemas).
Conforme a estrutura comentada anteriormente para definição dos
processos, o processo de gerência de configuração é descrito da seguinte
norma:
Figura 4 – Descrição resumida do processo de Gerência de Configuração na ISO/IEC
12207.
Fonte: elaborada pelo autor.
Similar a ISO/IEC 12207, a ISO/IEC 15288 tem como foco os
processos de ciclo de vida de sistemas, e é organizada em três grandes
grupos e quatro categorias:
Figura 5 – Grupos de processos – ISO/IEC 15288.
Fonte: elaborada pelo autor.
A ISO/IEC 15288 entende a definição de sistemas de uma forma
mais ampla, considerando-as um conjunto de componentes criados e
integrados pelo homem com o propósito específico de geração de valor.
Um sistema na norma é configurado como: hardware, software, dados,
humanos, processos (e.g. processos para prover serviços a usuários),
procedimentos (e.g. instruções de operadores), instalações, materiais e
entidades ocorrendo naturalmente.
Nesse contexto, no que se refere à Gerência de Configuração, a
ISO/IEC 15288 tem definições similares às da ISO/IEC 12207, mas seu
escopo vai além do componente software de um sistema.
Na figura a seguir, temos uma visão da definição da ISO/IEC 15288
para o processo de gerência de configuração:
Figura 6 – Descrição resumida do processo de Gerência de Configuração na ISO/IEC
15288.
Fonte: elaborada pelo autor.
Quando o elemento foco é o software, e não o sistema, a ISO/IEC
12207 supre toda a definição de processos a serem definidos, sendo, por
exemplo, uma das principais bases para os modelos de maturidade e
capacidade de processo, como o Mps.Br.
Sendo assim, na sequência não veremos detalhes em relação às
normas (que não são obras de domínio público). Entretanto, exploraremos
mais detalhadamente os modelos CMMI e Mps.BR e examinaremos como
as atividades e os resultados esperados, relacionados às normas, podem
ser endereçados dentro do contexto das organizações que produzem
software ou proveem serviços de software.
2.2 Padrão ISO/IEC 15504 - SPICE
A norma ISO/IEC 15504, também conhecida como SPICE (Software
Process Improvement and Capability Determination), foi criada com o
objetivo de suportar a avaliação dos processos em duas dimensões: a de
processos e a de capacidade. Inicialmente voltada aos processos de
desenvolvimento de software, hoje ela é uma norma mais ampla, que inclui
também processos organizacionais e de suporte, por exemplo.
Os conceitos apresentados na norma são base para a avaliação de
processos implementados a partir de um modelo de referência. Logo, em
sua última edição, essa norma mapeia um modelo de referência (grupo de
processos) fortemente alinhado com as definições da ISO/IEC 12207.
Entretanto, alguns processos adicionais são introduzidos. A dimensão de
processos da 15504 tem como foco suportar a avaliação da conformidade
visando a melhoria e é realizada a partir das definições de propósito e de
resultados esperados, estabelecidos no modelo de referência.
A dimensão dos processos possui cinco categorias:
cliente-fornecedor;
engenharia;
organizacionais;
gerenciamento;
suporte.
Na dimensão de processos, a norma limita-se a suportar a
verificação da execução ou não dos processos (estabelecidos no modelo
de referência).
A Gerência de Configuração é definida como uma área de processo
integrante do grupo de suporte e possui estrutura similar a das definições
da ISO/IEC 12207 (propósito e resultados esperados). A categoria de
processos de suporte consiste em processos que podem ser
empregados por qualquer um dos outros processos dentro do ciclo de
vida do software (incluindo outros processos de suporte).
Como base para verificação da conformidade (avaliação dos
resultados), a norma define um conjunto de práticas base, que servem
como guia para a definição das atividades e das tarefas requeridas no
processo. Em uma avaliação baseada na SPICE, a verificação da
realização da prática de maneira consistente contribui para que os
resultados esperados sejam atingidos. Essa norma ainda ilustra produtos
de trabalho (resultantes da execução da atividade, como, por exemplo,
documentação) que devem estar presentes na definição do processo
(como entradas ou saídas de atividades). 
Vê-se, abaixo, uma amostra de prática base de gerência de
configuração, que na norma encontra-se agrupada às definições de
propósito e às de resultados esperados.
BP1 Desenvolver uma estratégia de gerência de configuração:
desenvolver uma estratégia de gerência de configuração,
incluindo atividades de gerência de configuração, um modelo de
ciclo de vida, responsabilidades e recursos para realização
dessas atividades.
Na dimensão de avaliação de capacidade, a ISO/IEC 15504 é
composta por atributos de processo e por níveis de capacidade. Os
atributos de processo representam características mensuráveis, que são
necessárias para gerenciar um processo e melhorar sua capacidade.
A norma, então, relaciona os atributos de processo com os níveis de
capacidade, de modo a facilitar a verificação da obtenção do nível de
satisfação. O prefixo AP é aplicado junto a dois dígitos, sendo que o
primeiro identifica o nível de capacidade, e o segundo, a ordem de
precedência:
AP 1.1 - desempenho do processo;
AP 2.1 - gestão de produto de trabalho;
AP 2.2 - gestão de desempenho;
AP 3.1 - definição do processo;
AP 3.2 implementação do processo;
AP 4.1 medição do processo;
AP 4.2 controle do processo;
AP 5.1 melhoria e inovação do processo;
AP 5.2 otimização do processo.
Similar à definição de práticas base na dimensão de processo, na
dimensão de capacidade, as práticas denominadas práticas de
gerenciamento são associadas a cada atributo de processo. Práticas de
gerenciamento, com suas características associadas, são os indicadores
da capacidade de processo. Logo, são os meios de atingir-se as
capacidades definidas nos atributos de processo.
Abaixo, temos uma amostra de definição detalhada de atributo de
processo e de suas práticas gerenciais relacionadas.
PA 1.1 Atributo de processo de performance – A extensão por meio
da qual o processo atinge os resultados esperados pela
transformação de produtos de trabalho é identificada como
entrada (do processo ou atividade) e, em outros produtos de
trabalho, é idenficada como saída. Como resultado da completa
obtenção desse resultado temos:
a. o escopo de trabalho a ser realizado e os produtos de
trabalho a serem produzidos e entendidos;
b. produtos de trabalho serão produzidos e darão apoio
para atingir-se o resultado do processo.
As práticas gerenciais relacionadas são:
MP 1.1.1: identificarprodutos de trabalho de entrada e de saída
(do processo ou atividade).
MP 1.1.2: garantir que o escopo de trabalho seja identificado, para
a execução do processo, e que possibilite que os produtos de
trabalho sejam produzidos e utilizados pelo processo.
MP 1.1.3: garantir que as práticas base sejam implementadas,
produzindo produtos de trabalho que apoiarão na obtenção dos
resultados esperados de processo definidos.
Para melhor ilustrar a organização dos níveis e o que é esperado na
perspectiva de objetivo de capacidade de processo, temos a figura abaixo:
Figura 7 – Ilustração dos níveis de capacidade da norma 15504.
Fonte: elaborada pelo autor.
Em resumo, e de maneira geral, em uma avaliação de capacidade
de processos, a norma 15504 orienta quais os processos de um modelo
de referência que devem estar presentes em cada nível, assim como
quais os atributos de processo que os grupos de cada nível devem
satisfazer. Sendo um modelo contínuo, as áreas de processo requeridas
em um determinado nível serão exigidas em níveis superiores, e assim os
atributos de processo desses níveis passam a ser aplicáveis às áreas, ou
seja, a capacidade do processo é avaliada de modo incremental, de forma
que, a cada nível posterior em sua primeira implementação, novos
atributos de processo precisarão ser satisfeitos.
Em um processo de avaliação, cada atributo de processo é
verificado de acordo com uma escala de quatro pontos, como segue:
Não atingido (not achieved):0-15%.
Parcialmente atingido (partially achieved):>15% - 50%.
Largamente atingido (largely achieved): >50% - 85%.
Completamente atingido (fully achieved): >85% - 100%.
A ISO/IEC 15504 ainda traz, em suas partes, orientações específicas
para profissionais que desempenharão funções de avaliadores (rodarão o
processo de avaliação de acordo com a norma), uma amostra de
execução de avaliação de processo, um guia para realização de
avaliações, um guia de competências para avaliadores, um guia para
utilização em melhoria de processos, um guia para determinar a
capacidade de processo de fornecedores e um vocabulário.
Os modelos Mps.Br e CMMI são, hoje em dia, ambos fortemente
alinhados às definições da norma. Logo, ao estudarmos esses modelos,
teremos a oportunidade de detalhar alguns conceitos relativos à disciplina
de Gerência de Configuração.
2.3 CMMI
O CMMI (Capability Maturity Model Integration) é um modelo de
processos criado pelo SEI (Software Engineering Institute), na
Universidade de Carnegie Mellon. O modelo se caracteriza como o
conjunto de melhores práticas que auxiliam organizações a melhorarem
seus processos e é desenvolvido por times compostos por representantes
da indústria, do governo e do próprio SEI.
Similar às normas ISO, o CMMI é formado por modelos de
referência de processos que possuem definições que guiam a avaliação
de maturidade e capacidade. Os modelos de referência de processos são
apresentados em três grupos:
CMMI para o desenvolvimento (CMMI-DEV): foca-se em processo
de desenvolvimento de software e serviços.
CMMI para aquisição (CMMI-ACQ): foca-se na aquisição de
produtos de software e serviços.
CMMI para serviços (CMMI-SVC): voltado aos processos de
prestação de serviços.
O modelo de referência CMMI-DEV ainda apresenta as suas 22
áreas de processo agrupadas em categorias específicas, que são:
engenharia;
gerência de projetos;
suporte.
A área de processo de gerência de configuração é, assim como na
ISO/IEC 15504, agrupada na categoria de suporte. Cada área de processo
é apresentada conforme a seguinte estrutura:
Figura 8 – Organização dos elementos de área de processo no modelo CMMI.
Fonte: elaborada pelo autor.
Os elementos das áreas de processo garantem a verificação da
conformidade (correta definição) do processo em uma organização.
O propósito da área de Gerência de Configuração é definido como:
Estabelecer e manter a integridade dos produtos de trabalho
util izando identificação da configuração, controle da
configuração, contabil ização do status da configuração e
auditorias da configuração (SEI – CMMI DEV – 1.3, 2010, p. 137).
Na nota introdutória, tem-se um resumo das principais atividades e
dos principais conceitos, tais como o de itens de configuração e o de
baselines. Entre as principais atividades, tem-se:
a identificação da configuração de produtos de trabalho
selecionados que irão compor as linhas-base (baselines) em
estágios do ciclo;
o controle das mudanças em itens de configuração;
a necessidade de construir ou prover especificações para
construir (to build) produtos de trabalho a partir do sistema de
gerenciamento de configuração;
a necessidade de manter a integridade de linhas-base
(baselines);
a necessidade de prover o estado preciso e os dados correntes
de configuração para desenvolvedores, usuários finais e clientes.
A definição de que os produtos de trabalho colocados sob gerência
de configuração incluem produtos que são entregues ao cliente, que são
base para produtos de trabalho interno, para produtos adquiridos, para
ferramentas e para quaisquer outros itens usados na criação ou na
descrição desses produtos de trabalho, resume o conceito de item de
configuração.
As linhas-base (baselines) são citadas como provedoras de uma
base estável para evolução contínua dos itens de configuração.
Entre as áreas de processo relacionadas e citadas nessa
introdução, temos o controle e monitoramento de projeto e o planejamento
de projeto.
Os objetivos específicos e as práticas específicas relacionadas são
definidos como:
SG1 estabelecer linhas-base (baselines);
SP1.1 identificar os itens de configuração;
SP1.2 estabelecer um sistema de gerência de configuração;
SP 1.3 criar ou liberar baselines;
SG2 acompanhar e controlar mudanças;
SP2.1 acompanhar solicitações de mudança;
SP2.2 controlar itens de configuração;
SG3 estabelecer integridade;
SP3.1 estabelecer registro de gerência de configuração;
SP3.2 realizar auditorias de configuração.
No Capítulo 4, veremos mais informações relacionadas à
implementação e à execução do processo de Gerência de Configuração.
Na perspectiva de avaliação da maturidade e capacidade, o CMMI
possui duas representações: a em estágio e a contínua.
A representação em estágio possui cinco níveis e suporta a
avaliação da maturidade da organização a partir da avaliação de um
conjunto de processos. Já a representação contínua, em conformidade
com a ISO/IEC 15504, permite a avaliação da capacidade dos processos
de maneira individual e possui quatro níveis.
Para um melhor entendimento, temos a seguir uma tabela com a
comparação das duas representações.
Figura 9 – Níveis de capacidade e maturidade do modelo CMMI.
Fonte: elaborada pelo autor.
Também no CMMI, são definidos objetivos mais amplos, que são
base para a avaliação da maturidade (em um grupo de processos) ou da
capacidade (em uma avaliação individual de área de processo) e que são
chamados objetivos gerais (generic goals), sendo os mesmos detalhados
por meio de práticas genéricas (generic practices).
São três os Objetivos Gerais definidos no modelo, e eles indicam o
grau de institucionalização de uma área de processo.
Objetivo geral 1 – realizar práticas específicas: indica o que é
esperado para que o processo seja interpretado como realizado,
e está relacionado com o nível um de capacidade e maturidade.
Como prática geral, tem-se:
GP 1.1 realizar práticas específicas.
Objetivo geral 2 – institucionalizar e gerenciar o processo: agrupa
itens que apóiam o diagnóstico do processo como gerenciado. 
Está relacionado com o nível dois de capacidade e maturidade.
Como práticas gerais, define:
GP2.1 estabelecer uma política organizacional;
GP2.2 planejar o processo;
GP2.3 prover recursos;
GP2.4 definir responsabilidades;
GP2.5 treinar pessoas;
GP2.6 controlar produtos de trabalho;
GP2.7 identificar e envolverpartes interessadas
(stakeholders);
GP2.8 monitorar e controlar o processo;
GP2.9 avaliar objetivamente a aderência;
GP2.10 revisar status com alta gerência.
Objetivo geral 3: apóia o resultado do processo como definido.
Está relacionado com o nível três de capacidade e maturidade. As
práticas gerais definidas são:
GP3.1 estabelecer um processo definido;
GP3.2 coletar experiências relacionadas ao processo.
O modelo ainda define um método de avaliação. Entretanto, ele não
é relevante para o foco de estudo desta disciplina, que é a definição e a
execução do processo de Gerência de Configuração.
2.4 Modelo MPS.BR
O MPS.BR é um programa para a melhoria de processo do software
brasileiro e está em desenvolvimento desde dezembro de 2003, sendo
coordenado pela Associação para Promoção da Excelência do Software
Brasileiro (Softex). Conta com o apoio do Ministério da Ciência e
Tecnologia (MCT), da Financiadora de Estudos e Projetos (Finep) e do
Banco Interamericano de Desenvolvimento (BID).
O modelo tem como base técnica as normas ISO/IEC 12207,
ISO/IEC 15504, ISO 20000 e o CMMI (por seus modelos de referência
CMMI-DEV e CMMI-SVC).
O modelo MPS está dividido em quatro (4) componentes:
modelo de referência MPS para software (MR-MPS-SW);
modelo de referência MPS para serviços (MR-MPS-SV);
método de avaliação (MA-MPS);
modelo de negócio (MN-MPS).
Cada componente é descrito por meio de guias e/ou documentos
do programa MPS.BR.
O MPS.BR, estando em conformidade com a norma ISO/IEC 15504,
define níveis de maturidade que orientam a avaliação do processo e sua
capacidade.
Sendo voltado à representação em estágios, o MPS.BR foca-se em
avaliar a implementação e a capacidade de um grupo de processos para
que um determinado nível seja atingido.
O MPS.BR possui sete níveis de maturidade. Atrelados a cada nível,
tem-se um conjunto de áreas de processo, que são compostas por
propósitos e resultados esperados, e de atributos de processo. O alcance
de um nível de maturidade se dá a partir da satisfação dos resultados
esperados da execução do processo e dos itens de capacidade
requeridos nos atributos.
Abaixo, temos uma visão dos níveis e de seus atributos.
Figura 10 – Níveis de maturidade e capacidade do modelo MPS.BR.
Fonte: elaborada pelo autor.
A Gerência de Configuração é um dos processos que integra o MR-
MPS-SW e faz parte do conjunto de processos a serem implementados no
nível F.
No MPS.BR-SW, o propósito descreve o objetivo geral a ser atingido
durante a execução do processo. Basicamente, no MPS.BR, o propósito da
Gerência de Configuração transcreve a definição da ISO/IEC 12207, como
segue:
O propósito do processo Gerência de Configuração é estabelecer
e manter a integridade de todos os produtos de trabalho de um
processo ou projeto e disponibil izá-los a todos os envolvidos.
(MPS.BR, 2013, p.18 ).
Relembrando conceitos já vistos em capítulos anteriores sobre as
normas ISO, os resultados esperados do processo estabelecem os
resultados a ser obtidos com a efetiva implementação do processo. Esses
resultados podem ser evidenciados por um artefato produzido ou por uma
mudança significativa de estado ao executar-se o processo.
Os resultados esperados da área de Gerência de Configuração no
modelo MPS.BR-SW são:
GCO 1: um sistema de Gerência de Configuração é estabelecido
e mantido.
GCO 2: os itens de configuração são identificados.
GCO 3: os itens de configuração sujeitos a um controle formal são
colocados sob baseline.
GCO 4: a situação dos itens de configuração e das baselines é
registrada aolongo do tempo e disponibilizada.
GCO 5: modificações em itens de configuração são controladas e
disponibilizadas.
GCO 6: auditorias de configuração são realizadas objetivamente
para assegurar que as baselines e os itens de configuração
estejamíntegros, completos e consistentes.
GCO 7: o armazenamento, o manuseio e a liberação de itens de
configuração e de baselines são controlados.
Como base para implementação da área de processo, o MPS.BR
produziu guias de implementação para cada nível do modelo de
maturidade. O Guia de Implementação Parte 2 traz uma estrutura
detalhada para a definição do processo de Gerência de Configuração, que
é composta por uma fundamentação teórica (similar a do CMMI), e uma
expansão de cada resultado esperado, oferecendo apoio ao entendimento
de quais atividades, tarefas, artefatos (produtos de trabalho) e recursos
precisam estar definidos no processo.
Conforme mencionado anteriormente, o modelo também traz um
conjunto de atributos de processo, que são:
AP1.1 – O processo é executado.
AP2.1 – O processo é gerenciado.
AP2.2 – Os produtos de trabalho são gerenciados.
AP3.1 – O processo é gerenciado.
AP3.2 – O processo está implementado.
AP4.1 – O processo é medido.
AP4.2 – O processo é controlado.
AP5.1 – O processo é objeto de melhorias incrementais e de
inovações.
AP5.2 – O processo é otimizado continuamente.
Para a avaliação da capacidade de Gerência de Configuração nível
F, os atributos requeridos são o AP1.1, o AP2.1e o AP 2.2. A seguir, esses
atributos serão detalhados para uma melhor compreensão dos itens a
serem satisfeitos pelo processo.
O AP 1.1 evidencia o quanto o processo atinge o seu propósito.
Como resultado esperado, tem-se:
RAP 1: o processo atinge seus resultados definidos (GCOs).
O AP 2.1 evidencia o quanto a execução é gerenciada, tendo como
resultados esperados:
RAP 2: existe uma política organizacional estabelecida e mantida
para o processo.
RAP 3: a execução do processo é planejada.
RAP 4 (para o nível G): a execução do processo é monitorada e
ajustes são realizados.
RAP 4 (a partir do nível F): medidas são planejadas e coletadas
para a monitoração da execução do processo e ajustes são
realizados.
RAP 5: as informações e os recursos necessários para a
execução do processo são identificados e disponibilizados.
RAP 6 (até o nível F): as responsabilidades e a autoridade para
executar o processo são definidas, atribuídas e comunicadas.
RAP 6 (a partir do nível E): os papéis requeridos, as
responsabilidades e a autoridade para a execução do processo
definido são atribuídos e comunicados.
RAP 7: as pessoas que executam o processo são competentes
em termos de formação, treinamento e experiência.
RAP 8: a comunicação entre as partes interessadas no processo
é planejada e executada de forma a garantir o seu envolvimento.
RAP 9 (até o nível F): os resultados do processo são revistos com
a gerência de alto nível para fornecer visibilidade sobre a sua
situação na organização.
RAP 10 (para o nível G): o processo planejado para o projeto é
executado.
RAP 10 (a partir do nível F): a aderência dos processos
executados às descrições de processo, de padrões e de
procedimentos é avaliada objetivamente. As não conformidades
são tratadas.
O AP 2.2 evidencia o quanto os produtos de trabalho produzidos
pelo processo são gerenciados apropriadamente, tendo como resultados
esperados:
RAP 11: os requisitos dos produtos de trabalho do processo são
identificados.
RAP 12: requisitos para documentação e controle dos produtos de
trabalho são estabelecidos.
RAP 13: os produtos de trabalho são colocados em níveis
apropriados de controle.
RAP 14: os produtos de trabalho são avaliados objetivamente com
relação aos padrões, procedimentos e requisitos aplicáveis. As
não conformidades são tratadas.
A partir dos próximos capítulos, veremos as perspectivas de
definição do processo e a execução do processo. Os conceitos citados
serão comentados com base nas definições dos modelos MPS.BR e
CMMI.
Recomendações para complementação de estudos referentes aos
temas deste capítulo:
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO);
INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC). Technical
Report ISO/IEC 15504-2. 1998. Disponível em:
<http://wpage.unina.it/paolo.melillo/tesi/Riferimenti%20Normativi%20e%20Legislativi/ISO%2015504/ISO-IEC%20TR%2015504-2.pdf>. Acesso em: 21 mai. 2014.
MOORE, J. ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207: The Entry-Level
Process Standards. 2010. Disponível em: <www.ieee-
stc.org/proceedings/2010/pdfs/JWM2677.pdf>. Acesso em: 21 mai. 2014.
SOFTWERE ENGINEERING INSTITUTE (SEI). CMMI for Development:
version 1.3. 2010. Disponível em:
<http://www.sei.cmu.edu/reports/10tr033.pdf​>. Acesso em: 21 mai. 2014.
SOFTEX. Guia de implementação parte 2: fundamentação para
implementação do nível F do MR-MPS-SW: 2012. 2013. Disponível em:
<http://www.softex.br/wp-
content/uploads/2013/07/MPS.BR_Guia_de_Implementacao_Parte_2_2013.pdf
Acesso em: 21 mai. 2014.
Resumo do capítulo
Os principais modelos e normas de processos de software foram
abordados neste capítulo. Apresentou-se as estruturas de áreas de
processo, as perspectivas de processo e de avaliação de capacidade e
maturidade e os itens de processo relacionados à Gerência de
Configuração. Para a sequência no estudo, é fundamental o entendimento:
a. dos propósitos e resultados esperados;
b. dos atributos de processos;
c. do CMMI e seus objetivos gerais e específicos;
d. dos níveis de maturidade e capacidade.
CAPÍTULO 3
A PERSPECTIVA DE DEFINIÇÃO DE PROCESSOS
Este capítulo revisa os componentes a serem contemplados na implementação
de uma área de processo e apresenta uma amostra de definição do processo de
Gerência de Configuração, com o foco em uma atividade e em suas tarefas
relacionadas.
Conforme estudamos no Capítulo 2, as principais normas e
modelos de processo que servem de base para a definição de um
processo de Gerência de Configuração de Software indicam, a partir de
resultados esperados ou objetivos específicos, que a definição de um
processo contemple os seguintes elementos: propósito, atividades (ou
práticas) e tarefas (ou sub-práticas).
Ainda, esses elementos identificam que as entradas e as saídas,
que em geral estão relacionadas com produtos de trabalho, devem ser
estabelecidas .
Examinando os atributos de processo (ou objetivos genéricos no
CMMI), vemos que também indica-se que recursos sejam atribuídos às
atividades e que políticas organizacionais sejam definidas.
Neste capítulo, ilustra-se a perspectiva de definição do processo de
Gerência de Configuração em uma organização, estabelecendo uma
estrutura exemplo, que contempla os itens citados nos primeiros
parágrafos.
Como base de estudo, estabelece-se que, em uma determinada
organização, busca-se implementar o processo de Gerência de
Configuração tendo como guia o modelo CMMI. Opta-se pela avaliação da
representação contínua (avaliação individual do processo) e pretende-se
atingir o nível um (o processo é realizado).
A primeira etapa é examinar quais são os objetivos genéricos e
específicos a serem atingidos. Como pretendemos alcançar o nível um, é
necessário que o objetivo genérico um seja satisfeito (o processo é
realizado), e, como ele indica que as práticas específicas precisam ser
realizadas, precisamos atender a todos os objetivos e práticas específicos.
Para uma melhor compreensão, vamos limitar a definição da
atividade do processo relativa à prática específica 1.1 (SP1.1): identificar os
itens de configuração.
3.1 Definindo a atividade de processo
Conforme discutido anteriormente, é necessário que todos os
componentes de processo sejam contemplados em sua definição. Sendo
assim, cada atividade do processo (etapa) precisará também conter esses
elementos (propósito, tarefas, recursos, entradas, saídas etc.).
Sugere-se que, ao definir as atividades de um processo, eles sejam
representados sobre as formas gráfica e textual. Para a forma gráfica,
pode-se utilizar a notação de modelagem que melhor se adeque ao
contexto da organização (por exemplo, fluxogramas, Unified Modeling
Language (UML), Business Process Modeling Notation (BPMN) etc.).
Abaixo, temos uma amostra da modelagem referente a SP1.1, que
identifica a fase do ciclo relacionada à atividade (planejamento) e
contempla os recursos e tarefas a serem realizadas.
Figura 11 – Exemplo de modelagem de atividades de processo.
Fonte: elaborada pelo autor.
A SP1.1 estabelece que a atividade de identificação de itens de
configuração deve ser realizada na etapa de planejamento. Logo,
identificamos a fase como “planejar Gerência da Configuração”.
Veremos no próximo capítulo que um produto de trabalho sugerido
na etapa de planejamento é o plano de Gerência de Configuração. Logo,
sua criação é contemplada como a primeira tarefa da atividade, sendo
seguida da definição dos critérios de seleção e da seleção dos itens de
configuração, que endereçam as sub-práticas da SP1.1. O gráfico ainda
identifica os recursos necessários para a execução da atividade, que são o
controlador de configuração e o líder técnico.
Na próxima etapa da definição do processo, faz-se necessário
elaborar uma forma textual, ou seja, uma descrição de cada tarefa
agrupada à atividade, abordando o resultado esperado, a
responsabilidade (atuação) dos recursos e as entradas e saídas (produto
de trabalho).
Abaixo, vê-se um exemplo da definição (resumida) da atividade e
das tarefas relacionadas.
Atividade: identificar itens de configuração.
Propósito: por meio desta atividade, deverão ser estabelecidos
critérios de seleção para os itens de configuração, padrões de
identificação, processo de manipulação, e, a partir disso, estes deverão
ser selecionados como pertencentes à etapa da elaboração do plano de
Gerência de Configuração.
Tarefa 1: definir critérios de seleção de item de configuração.
Entrada: plano de Gerência de Configuração instanciado.
Descrição: critérios de seleção de configuração deverão ser
estabelecidos pelo controlador de configuração. Os critérios
deverão abordar itens que apóiem selecionar quais produtos de
trabalho serão denominados itens de configuração.
Saída: critérios de seleção definidos.
Tarefa 2: revisar critérios de seleção de item de configuração.
Entrada: critérios de seleção definidos.
Descrição: os critérios de seleção definidos deverão ser revisados
e aprovados pelo líder técnico do projeto.
Saída: critérios de seleção revisados e aprovados.
Tarefa 3: selecionar itens de configuração.
Entrada: critérios de seleção revisados e aprovados.
Descrição: com base nos critérios de seleção estabelecidos, o
controlador de configuração deverá, no plano de configuração,
selecionar (documentar) quais produtos de trabalho serão
denominados itens de configuração, bem como definir seus
estados (ciclo de vida) no ciclo de software, padrões de
identificação única e papéis responsáveis (owners) por eles.
Saída: itens de configuração selecionados.
Tarefa 4: revisar itens de configuração.
Entrada: itens de configuração selecionados.
Descrição: os itens de configuração selecionados
(documentados) no plano de gerência de configuração deverão
ser aprovados e revisados pelo líder técnico do projeto.
Saída: itens de configuração revisados e aprovados.
O exemplo apresentado aborda de maneira sucinta a forma como o
processo de Gerência de Configuração deve ser elaborado no contexto de
uma organização e de um projeto de software. Entretanto, é importante
ressaltar que, em um caso real, itens adicionais, como referências aos
modelos de documentos (e.g. modelo de plano de gerência de
configuração), devem ser indicados, e que definições mais objetivas,
considerando as tecnologias utilizadas etc., deverão ser contemplados.
Recomendações para complementação de estudos referentes aos
temas deste capítulo:
SOFTWERE ENGINEERING INSTITUTE (SEI). CMMI for Development:
version 1.3. 2010. Disponível em:
<http://www.sei.cmu.edu/reports/10tr033.pdf​>. Acesso em: 21 mai. 2014.
SOFTEX. Guia de implementação – parte 2: fundamentação para
implementação do nível F do MR-MPS-SW:2012. 2013. Disponível em:
<http://www.softex.br/wp-
content/uploads/2013/07/MPS.BR_Guia_de_Implementacao_Parte_2_2013.pdfAcesso em: 21 mai. 2014.
Resumo do capítulo
Resumidamente, foram apresentados neste capítulo os principais
componentes que devem estar presentes na definição de um processo de
software nas organizações, bem como uma amostra de definição de
processo. No conteúdo abordado, é fundamental a compreensão da forma
de modelar e descrever processos, incluindo descrição, entradas, saídas
e responsabilidades.
CAPÍTULO 4
A PERSPECTIVA DE EXECUÇÃO DA GERÊNCIA DE
CONFIGURAÇÃO
Este capítulo aprofunda os conceitos definidos nas normas e modelos de
processos apresentados no Capítulo 2 e busca dar uma visão de quais atividades da
área de processo devem ser definidas e de como executá-las (passando pelas
definições de tarefas, recursos e artefatos/produtos de trabalho).
Vimos nos capítulos anteriores que, de modo geral, as atividades da
área de processo de Gerência de Configuração são: identificação dos
itens de configuração, controle da configuração (gestão de mudanças),
acompanhamento de estado, gerenciamento de builds e revisão
(auditorias).
A seguir, abordaremos tais atividades agrupadas sob duas
principais fases do ciclo de vida do projeto de software: planejamento e
execução. Serão utilizados representações gráficas e conceitos que
endereçam os itens de verificação de conformidade de processo
(resultados esperados, objetivos específicos) e de capacidade (atributos
de processo, objetivos gerais) definidos nos modelos e normas
estudados.
4.1 Planejando a Gerência da Configuração
O planejamento da Gerência de Configuração agrega atividades do
processo executadas a partir da elaboração do plano de Gerência de
Configuração, que se torna o principal produto de trabalho dessa etapa.
Tais atividades endereçam, no caso do CMMI, o objetivo geral um e
alguns itens do objetivo geral dois (práticas gerais 2.2, 2.3, 2.4, 2.5 e 2.7),
assim como as práticas específicas 1.1 e 1.2. No caso do MPS.BR,
endereçam os atributos de processo 1.1 e alguns itens do 1.2 (RAP3,
RAP4 – nível F, RAP5, RAP6, RAP8, RAP12), bem como os resultados
esperados GCO1 e GCO2.
Abaixo, temos uma amostra de representação gráfica das atividades
do processo de Gerência de Configuração realizadas durante a etapa de
planejamento (de projeto).
Figura 12 – Exemplo de modelagem de atividades de planejamento da Gerência de
Configuração.
Fonte: elaborada pelo autor.
Como todas as atividades de planejamento estão de alguma forma
relacionadas com o plano de Gerência de Configuração, a seguir é
ilustrado um modelo desse plano.
O plano de Gerência de Configuração deve, em sua primeira página,
apresentar uma folha de rosto com a identificação do projeto e do autor, e
uma identificação única do documento (nome), conforme segue:
Plano de Controle de Configuração
<Nome do Projeto >
Autor: <Controlador de Configuração >
Contato: <Fone/e-mail >
Identificação do Documento: XXX
As duas páginas seguintes deverão apresentar, respectivamente,
um sumário e elementos que apóiam o acompanhamento da evolução do
documento, tais como histórico de revisões e aprovações e documentos
relacionados (que apóiem a construção do plano).
Sumário
1. Introdução...............................................................................
2. Descrição de Ambiente .......................................................2
3. Papéis......................................................................................
4. Padrões de Identificação e Desenvolvimento.......................2
5. Itens de Configuração............................................................2
6. Produtos de Trabalho.............................................................3
7. Definições do Processo de Configuração..............................3
8. Cronograma de Atividades....................................................3
9. Histórico de Revisões do Modelo..........................................4
Informações de Acompanhamento
 Histórico de Revisões
Versão Data Descrição Nome do Modificador
 
Histórico de Aprovações
Nome Identificação de Aprovação Data Comentários
 
Documentos Relacionados
Nome do documento Descrição Autor Localização
 
A seguir, tem-se a introdução, na qual se deve descrever o objetivo
do documento Aconselha-se também incluir uma lista com o significado
de acrônimos e abreviações que possam ser referenciados ao longo do
texto.
1. Introdução
Ex: “Este documento descreve as definições para a aplicação do processo
de controle de configuração no projeto <Project Name> (conjunto de
atividades, responsabilidades, itens de configuração, produtos de trabalho,
ciclo de vida, ambiente físico etc.)”.
Acrônimos e Abreviações
Termo Definição Objetivo
CC Controlador de Configuração
GC Gerência de Configuração
CS Configuração de Software
As sessões seguintes apóiam todo o planejamento da Gerência de
Configuração em si, endereçando os principais elementos, como
ambiente físico, itens de configuração, ciclo de vida, papéis e
responsabilidades e principais atividades.
2. Descrição de Ambiente
Esta seção deverá descrever todo o conjunto de hardwares e softwares
requeridos para a produção e implementação dos produtos do projeto,
assim como os locais onde os itens de configuração (ferramenta, diretório
público etc.) estarão sendo disponib ilizados.
Descrição do ambiente físico.
3. Papéis
Nesta seção, deverão ser definidos os papéis relacionados ao processo de
configuração, assim como as pessoas que o desempenharão.
Papel Pessoa ou Grupo
Controlador de Configuração
Grupo de Configuração
Auditor de Configuração
4. Padrões de Identificação e Desenvolvimento
Nesta seção, deverão ser descritos os padrões de identificação (nomes) a
serem aplicados aos itens de configuração, assim como os padrões de
codificação da tecnologia a ser utilizada no projeto.
5. Itens de Configuração
Critérios de Identificação.
Este item da seção deve conter a descrição dos tipos de arquivos de
produção (códigos, imagens etc) e de documentos que devem ser
considerados itens de configuração no contexto do projeto.
Arquivos de Produção.
Por exemplo: .java, .html, .gifs, scripts de banco, dlls etc.
Documentos.
Por exemplo: documento de requisitos, plano de projeto, plano de
configuração etc.
Itens de Configuração selecionados
Define-se aqui quais os itens do projeto selecionados como itens de
configuração, assim como o padrão de identificação de cada item e o seu
procedimento de trabalho (onde deve ser criado, qual o ciclo de vida que
faz parte, documentos ou produto etc.)
6. Produtos de Trabalho
Descreve-se aqui os itens de projeto que devem ser submetidos ao
controle de configuração, mas que não são considerados itens de
configuração.
Por exemplo: planos de teste, documentos de entrada do projeto,
cronograma etc.
7. Definições do Processo de Configuração
Nesta seção, deverão ser definidos o ciclo de vida (estágios dos itens de
configuração), a estrutura física do projeto (pastas e diretórios),a área
controlada (estados de acesso restrito) e os níveis de acesso e
responsabilidade dos papéis envolvidos no processo.
8. Cronograma de atividades
Esta seção deverá abordar o cronograma das atividades de gerência de
configuração de software (builds, criação de baselines, comunicações,
auditorias e relatórios).
4.2 Identificação da configuração
A Gerência de Configuração usualmente inicia-se com a
identificação das partes que constituem o software. Essas partes,
denominadas itens de configuração (configuration items), representam a
agregação de hardware, de software ou de ambos, tratados pela Gerência
de Configuração como um elemento único (IEEE Std 610.12,1990).
Na identificação da configuração, identificam-se os itens de
configuração, os componentes e os produtos de trabalho (work products)
relacionados que serão colocados sob a gerência da configuração.A função de identificação da configuração tem por objetivo
possibilitar:
a seleção dos itens de configuração, que são os elementos
passíveis de Gerência de Configuração;
a definição do esquema de nomes e números, que possibilite a
identificação inequívoca dos itens de configuração no grafo de
versões e variantes;
a descrição dos itens de configuração, tanto física quanto
funcionalmente.
A seleção do que será considerado um item de configuração deve
ser baseada em critérios previamente estabelecidos, descritos no plano
de Gerência de Configuração.
Por exemplo, um critério possível para identificação dos itens de
configuração é o uso de princípios de acoplamento e coesão.
Itens de configuração com alto acoplamento tornam complexo o
processo de construção, devido ao número excessivo de dependências.
Por outro lado, itens de configuração com baixa coesão dificultam o
processo de desenvolvimento, devido ao aumento de modificações
concorrentes.
Figura 13 – Exemplo de tabela para definição de critérios de seleção de itens de
configuração.
Fonte: elaborada pelo autor.
Os produtos de trabalho colocados sob a gerência da configuração
são denominados itens de configuração e incluem os produtos que são
entregues ao cliente, produtos de trabalho internos base para a construção
do software, produtos adquiridos, ferramentas e outros itens que são
usados para criar e descrever esses work products.
Quaisquer outros produtos de trabalho que apóiem o ciclo, mas que
não se enquadrem na definição acima, podem e devem ser gerenciados
(e.g. versionados), mas não precisam ser formalmente controlados (sob
as atividades do processo de gerência de configuração).
Exemplos de itens de configuração que podem ser colocados sob a
gerência da configuração incluem:
planos;
descrições de processos;
requisitos;
dados de design;
desenhos;
especificações de produto;
código;
compiladores;
arquivos de dados do produto;
publicações técnicas do produto.
A identificação da configuração é a seleção, a criação e a
especificação do seguinte:
todo e qualquer produto de trabalho (documentos ou código) que
é entregue ao cliente como parte do produto final;
produtos adquiridos (que farão parte do produto final);
ferramentas e outros recursos importantes do ambiente do
trabalho de projeto;
outros itens que são usados para criar e descrever esses work
products;
Caso os itens de configuração sejam muito pequenos, o número
total de itens de configuração será grande, e isso poderá afetar a
visibilidade do produto, dificultar o gerenciamento e aumentar o custo de
operação.
Por outro lado, caso os itens de configuração sejam muito grandes,
o número total de itens de configuração será pequeno, e isso poderá gerar
dificuldades de logística e manutenção, limitando as possibilidades de
gerência.
Uma identificação de itens de configuração bem sucedida está
intimamente relacionada com a definição da arquitetura do sistema em
questão.
Ao identificar os itens de configuração, algumas ações precisam ser
endereçadas, tais como:
atribuir identificadores únicos aos itens de configuração (nomes
de arquivos significativos/coerentes);
especificar as características importantes de cada item de
configuração. Exemplos de características de itens de
configuração incluem o autor, o tipo de documento ou arquivo e a
linguagem de programação para arquivos de código fonte.
Especificar quando cada item de configuração será colocado sob
a gerência da configuração (em que momento do ciclo de
desenvolvimento de software). Exemplos de critérios para
determinar quando colocar produtos do trabalho sob a gerência
da configuração incluem:
estágio do ciclo de vida do projeto;
quando o produto do trabalho estará pronto para o teste;
o grau de controle desejado no produto do trabalho;
limitações do custo e de cronograma;
exigências do cliente.
Identificar o responsável para cada item de configuração.
4.3 Sistema de Gerência de Configuração
O sistema de Gerência de Configuração caracteriza-se pela soma
de definições de estruturas físicas e lógicas que suportarão o processo de
Gerência de Configuração mais a implementação dessas estruturas em
uma ferramenta (software) que servirá como base para a implementação
do processo.
Entre os passos para a definição do sistema de Gerência de
Configuração, tem-se:
definição da estrutura de diretórios-base para a gestão de itens
de configuração;
definição da identificação de estados do ciclo de vida dos itens de
configuração;
definição do tipo de acesso de cada papel executado (gerente de
projeto, líder técnico etc.) ao sistema ;
definição das áreas controladas (estados de acesso apenas pelo
controlador de configuração);
definição da ferramenta de Gerência de Configuração.
O primeiro passo é a criação de uma estrutura de diretórios que
servirá de repositório para os itens de configuração do projeto. 
Não há padronização para a criação dessa estrutura, mas é comum
que as equipes trabalhem com pastas diferentes para versões de
desenvolvimento e para armazenar versões fechadas do software
(produção). A estrutura é criada tanto na máquina local dos membros da
equipe quanto na base de dados da ferramenta de configuração.
A seguir, vê-se um exemplo de estrutura de diretórios.
Figura 14 – Exemplo de estrutura de diretórios de projeto.
Fonte: elaborada pelo autor.
Na definição dos estados do ciclo de vida, o controlador de
configuração deverá definir quais serão os estados (identificação das
fases) em que os itens de configuração deverão fluir durante o processo
de gerência de configuração de software.
Os ciclos de vida representam estágios evolutivos pelos quais os
itens de configuração passarão durante o processo de desenvolvimento
do projeto de software, quando sob o controle de configuração.
Juntamente com a identificação dos estados, deve-se também
explicitar quais serão os critérios para a transição de estados (também
denominado de promoção).
Por exemplo: para que o item de configuração seja promovido ao
estado de teste integrado, deverá obrigatoriamente ter passado pelo
estado teste unitário. 
A seguir, vê-se um exemplo de um ciclo de vida que busca atender
todos os estágios do ciclo de desenvolvimento de software.
Figura 15 e 16 – Exemplos de ciclos de vida (estágios) aplicáveis a itens de
configuração.
Fonte: elaborada pelo autor.
Como sequência da definição do ciclo de vida, é preciso que no
plano de Gerência de Configuração (ou, de modo geral, na parte das
definições de atividades do processo de Gerência de Configuração) seja
estabelecida uma definição de níveis de acesso que cada papel presente
no projeto poderá ter quanto aos itens de configuração, quando
identificados por cada um dos estados estabelecidos no ciclo de vida.
A seguir, veja um exemplo desta definição, onde CGC = controlador
de configuração, DES = desenvolvedores, GP = gerente de projeto, AS =
system analyst, LT = líder técnico e ET = engenheiro de teste.
Figura 17 – Exemplo de tabela para definição de níveis de acesso a cada etapa do
ciclo de software e área controlada.
Fonte: elaborada pelo autor.
Alguns estados/estágios do ciclo de vida dos itens de configuração
deverão ser de acesso apenas do controlador de configuração, sendo
denominados áreas controladas.
As áreas controladas são estabelecidas para que, uma vez que o
artefato tenha atingido aquele estado desejado, ele seja considerado
estável (ou pronto) e, logo, não mais passível de livre mudança pelos
desenvolvedores, a menos que disparada pelo processo formal de
solicitação de mudança e aprovada pelo grupo de controle de
configuração. 
O sistema de Gerência de Configuração pode ser decomposto em
três subsistemas:
sistema de controle de versões;
sistema de controle de modificações;
sistema de gerenciamento de construção.
O sistema de controle de versões deve garantira identificação única
de um grupo de itens de configuração, que deverão ser base para que o
gerenciamento de construção possa criar uma versão do produto para
algum propósito específico (teste, liberação para produção etc.).
Abaixo, vê-se um exemplo em que a identificação “Release 1.0”
indica o conjunto de artefatos pertencentes à versão 1.0 do produto.
Figura 18 – Ilustração de versionamento e revisões.
Fonte: CVS history graph – Printscreen (http://www.nongnu.org/cvs/).
O sistema de controle de mudanças deve garantir a identificação
única de cada versão de item de configuração produzida (ou atualizada).
Em geral, implementa um controle numérico, denominado revisão,
conforme exemplo abaixo.
Figura 19 – Ilustração de versionamento a nível de arquivos.
Fonte: adaptada de CVS revision history - Printscreen(http://www.nongnu.org/cvs/).
O sistema de gerenciamento da construção deverá possibilitar que
versões aprovadas do produto sejam incorporadas ao repositório principal
de desenvolvimento, bem como facilitar a geração do produto final
(instalação).
Em um sistema automatizado de Gerência de Configuração, as
versões aprovadas do produto retornam a chamada linha principal de
desenvolvimento, denominada nos softwares de Gerência de Configuração
como Trunk.
4.3.1 Estrutura de um sistema de configuração
sistema controlador de versões;
mantém histórico sobre arquivos fontes de sistemas e
documentos sem redundância;
recuperação de versões anteriores;
organização em patches e releases;
arquitetura:
cliente-servidor;
armazena os source codes em um repositório central;
repositório:
estrutura hierárquica de arquivos no sistema operacional
(árvore de diretórios);
não há redundância de fontes, isto é, são armazenadas
apenas as alterações;
controlado por meio de arquivos de controle;
não deve ser alterado diretamente;
diretório de trabalho:
local à parte do repositório, no qual são feitas as
alterações sobre os arquivos;
considerado o local de comunicação entre o client e o
server;
pode estar localizado na máquina do desenvolvedor ou
em um file server.
4.3.2 Principais conceitos de manipulação de arquivos
Revisão: em geral, é designada automaticamente. É uma
determinada versão de um arquivo.
Tag: é um rótulo simbólico designado pelo desenvolvedor.
Utilizado para identificar patches, customizações e releases.
Versão: nomenclatura atribuída a um conjunto de arquivos.
4.3.3 Principais funções de manipulação de arquivos
Import:
utilizado para importar um source code para o repositório;
checkout:
cria o diretório de trabalho e busca os arquivos no
repositório;
update:
atualiza um diretório de trabalho já existente;
commit:
devolve os arquivos alterados para o repositório;
incrementa automaticamente o número da revisão;
libera o modo de edição dos arquivos;
detecta conflitos;
fluxo de trabalho:
checkout/update dos arquivos no diretório de trabalho;
verificar se o arquivo não está sendo editado por alguém;
marcar o arquivo como editado;
fazer as alterações necessárias;
commit/checkin para o repositório;
designação de tags (última revisão).
Branch: é uma linha de desenvolvimento paralela a linha principal.
Utilizada como suporte a determinada versão enquanto a nova
versão estiver sendo desenvolvida.
Merge: é a aplicação das alterações feitas em um branch sobre a
linha de desenvolvimento principal.
4.4 Execução do processo de Gerência de Configuração
As atividades de execução do processo de Gerência de
Configuração estão ligadas ao dia a dia do time, tais como:
manipulação dos itens de configuração por parte das partes
interessadas, desenvolvedores, analistas de sistemas, gerentes
de projeto etc.;
controle da configuração, por parte do gerente de configuração
(alterações de estado), aprovações em solicitações de mudança,
geração e comunicação de baselines etc.;
acompanhamento do processo e de relatórios de itens de
configuração, por parte de um analista de qualidade, por meio de
auditorias.
Tais atividades endereçam, no caso do CMMI, alguns itens do
objetivo geral 2 (prática geral 2.6) e o objetivo específico 1, endereçando as
práticas específicas 1.2 e 1.3. No caso do MPS.BR, essas atividades
endereçam os atributos de processo 1.1 e 2.2, assim como os resultados
esperados GCO3, GCO4 e GCO5.
4.4.1 Baselines
Conforme abordado no primeiro capítulo, as baselines constituem
um ou mais itens de configuração estáveis e aprovados para propósitos
específicos.
O estabelecimento de baselines proporciona o aumento do nível de
controle sobre os itens de configuração que necessitam de um controle
formal à medida que evoluem e estabilizam-se nos estados do ciclo de
desenvolvimento de software.
As baselines podem ser estabelecidas a partir de propósitos
internos ou externos.
A baseline interna suporta a formalização do estado máximo de
estabilidade do item de configuração e, em geral, está relacionada a um
marco de mudança de fase. Ex.: a baseline de planejamento conterá todos
os artefatos finalizados e aprovados como versão final para dar início a
fase de desenvolvimento.
A baseline externa, por sua vez, denota o estado máximo de
estabilidade de um conjunto de itens de configuração aprovados para
compor uma entrega (release) do produto.
Uma vez parte de uma baseline, os itens de configuração (assim
com em área controlada) não poderão sofrer mudanças, a menos que
estas sejam aprovadas como parte do processo formal de solicitação de
mudança do projeto.
Para a implementação do conceito de baselines em sistemas
automatizados de Gerência de Configuração, utiliza-se a funcionalidade de
TAG ou LABEL.
As TAGs ou LABELs são um rótulo simbólico designado controlador
de configuração, que identificará um conjunto de itens de configuração.
4.4.1.1 Geração das baselines
Figura 20 – Ilustração das tarefas relacionadas à geração de baselines.
Fonte: elaborada pelo autor.
4.5 Gestão de mudanças
A gestão de mudanças é uma das principais atividades da Gerência
de Configuração e irá garantir que toda e qualquer alteração em um item
de configuração, após ele atingir um estado de estabilidade (área
controlada) e/ou estar aprovado, será formalmente avaliada e registrada.
Abaixo, temos um exemplo de modelagem da atividade de controle
de mudança e de tarefas relacionadas:
Figura 21 – Exemplo de modelagem da atividade de gestão de mudanças.
Fonte: elaborada pelo autor.
A partir do momento que os itens de configuração passam a fazer
parte de uma baseline, toda e qualquer modificação sobre esses itens de
configuração deve passar por um processo formal de controle de
modificações.
Esse processo formal de controle de modificações visa analisar o
impacto das modificações e notificá-los aos afetados, evitando retrabalho
e efeitos colaterais indesejáveis.
O ciclo de vida das solicitações de modificação, assim como os
critérios estabelecidos para sua aprovação pelo grupo de controle de
configuração, deve estar previamente estabelecido no plano de Gerência
de Configuração.
De acordo com os modelos de processo de Engenharia de Software
(MPS.BR e CMMI), as solicitações de mudança deverão ser formalmente
acompanhadas, ou seja, deverão ser registradas as evidências da
execução do processo de controle de modificações.
As solicitações de mudança endereçam não somente requisitos
novos ou alterados, mas também falhas e defeitos nos produtos de
trabalho.
As solicitações de mudança deverão ser formalmente analisadas
para determinar o impacto que a mudança terá no produto de trabalho, nos
produtos de trabalho relacionados, no orçamento e no cronograma.
Sendo assim, um documento formal de solicitação de mudança
deverá ser gerado a cada solicitação.
Uma estrutura formal no repositório de itens de configuração deverá
suportar o início e o registro de solicitações de mudança, sendo estas
arquivadas em