Gerencia de Configuracao de Sof - Unisinos

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 contab ilizaçã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 trab alho 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ão
do compilador em determinado idioma podem ser levados em
conta.
c. Gerenciamento dos b uilds: 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 (Capab ility 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 estab elecer 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.

Esses papéis podem ser definidos como:
Controlador/gerente de configuração: responsável pelo

planejamento e execução das atividades de 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 b aselines 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 b oard 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 b aselines.
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 b aseline 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. Capab ility 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.
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.
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.

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.
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 Capab ility 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 b ase, 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 trab alho (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 atrib utos 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 Atrib uto 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: identificar produtos 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.
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 atrib utos 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 (Capab ility 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.
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

utilizando identificação da configuração, controle da
configuração, contabilizaçã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
b aselines. Entre as principais atividades, tem-se:
a identificação da configuração de produtos de trabalho

selecionados que irão compor as linhas-base (b aselines) 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 b uild) produtos de trabalho a partir do sistema de
gerenciamento de configuração;
a necessidade de manter a integridade de linhas-base
(b aselines);
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 (b aselines) 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 (b aselines);

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 b aselines;
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.

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 ob jetivos 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 envolver partes 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.
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 disponibilizá-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 b aseline.
GCO 4: a situação dos itens de configuração e das b aselines é
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 b aselines 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 b aselines 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 trab alho 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.

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%20Legisla
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
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.

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.


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:
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 b uilds 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.
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 Amb iente .......................................................2
3. Papéis......................................................................................
4. Padrões de Identificação e Desenvolvimento.......................2
5. Itens de Configuração............................................................2
6. Produtos de Trab alho.............................................................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, responsab ilidades, itens de configuração, produtos de trab alho,
ciclo de vida, amb iente 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úb lico etc.) estarão sendo disponib ilizados.
Descrição do amb iente 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 b anco, 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 trab alho (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 sub metidos 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
responsab ilidade dos papéis envolvidos no processo.
8. Cronograma de atividades
Esta seção deverá ab ordar o cronograma das atividades de gerência de
configuração de software (b uilds, criação de b aselines, 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 amb os, 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.
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.
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.
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.
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 garantir a 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 b ranch 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 b aselines 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 b aselines 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 b aselines podem ser estabelecidas a partir de propósitos
internos ou externos.
A b aseline 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 b aseline de planejamento conterá todos
os artefatos finalizados e aprovados como versão final para dar início a
fase de desenvolvimento.
A b aseline 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 b aseline, 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 b aselines 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 b aselines

Figura 20 – Ilustração das tarefas relacionadas à geração de baselines.
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.
A partir do momento que os itens de configuração passam a fazer

parte de uma b aseline, toda e qualquer modificação sob re 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 diretórios do repositório ou em bases de dados.
O impacto das mudanças e dos ajustes de defeitos (b ug fixes)
propostos nas solicitações de mudança deve ser analisado.
As mudanças são avaliadas por meio de atividades que garantam
que elas estejam consistentes com todos os requisitos técnicos e do
projeto.
O impacto da mudança também deverá ser avaliado, além dos
requisitos imediatos de projeto ou de contrato. As mudanças em um item
utilizado em múltiplos produtos podem resolver um problema imediato e,
ao mesmo tempo, causar um problema em outras aplicações.
Nesse sentido, alguns itens devem ser observados:
reveja as solicitações de mudança que serão endereçadas na

próxima linha de base, com as partes interessadas relevantes, e
consiga suas aprovações;
conduza a revisão da solicitação de mudança com participantes
apropriados;
registre a disposição de cada solicitação de mudança e o racional
para a decisão, incluindo os critérios de sucesso, um plano de
ação breve, se apropriado, e as necessidades atingidas ou não
pela mudança;
execute as ações requeridas na disposição e relate os resultados
às partes interessadas relevantes;
acompanhe o status de solicitações de mudança até o
fechamento.
As solicitações de mudança trazidas ao sistema necessitam ser

gerenciadas de maneira eficiente e oportuna.
Uma vez que a solicitação de mudança tenha sido processada, é
crítico fechá-la o quanto antes com a ação de aprovação apropriada.
Ações deixadas em aberto resultam em listas de status maiores do
que seria necessário, o que resulta, por sua vez, custos maiores e
confusão.
4.5.1 Controle de mudança em itens de configuração
O controle é mantido sobre a configuração da linha de base de um

item de configuração. Esse controle inclui acompanhar a configuração de
cada um dos itens de configuração, aprovar uma configuração nova, se
necessário, e atualizar a linha de base.
Como resultados esperados do controle, têm-se:
histórico de revisão de itens de configuração;

arquivo de controle das b aselines.
O histórico de revisão de itens de configuração pode ser atribuído de

forma automatizada a partir da utilização de uma ferramenta (sistema de
gerência de configuração) como suporte ao relatório de versões e
documentação.
Abaixo, vê-se um exemplo de controle de b aselines:
Figura 22 – Ilustração de uma tabela para o acompanhamento de mudanças.

No controle de configuração, deve-se:
controlar mudanças aos itens de configuração durante toda a vida

do produto;
obter a autorização apropriada antes que os itens de configuração
alterados sejam incorporados ao sistema de gerência da
configuração. Por exemplo, a autorização pode vir do grupo de
controle de configuração, do gerente de projeto ou do cliente.
Realizar o check-in e check-out de itens de configuração do
sistema de gerência da configuração para incorporar mudanças,
de maneira que se mantenha a exatidão e a integridade dos itens
de configuração. Exemplos de passos de check-in e de check-out
incluem:
confirmar que as revisões estão autorizadas;
atualizar os itens de configuração;
arquivar a linha de base substituída e recuperar a linha
de base nova.
Fazer revisões para assegurar-se de que as mudanças não
causem efeitos não intencionados nas b aselines (por exemplo,
assegurar-se de que as mudanças não comprometam a
segurança das pessoas e/ou a segurança do sistema);
registrar mudanças aos itens de configuração e razões para as
mudanças, conforme apropriado.
Se uma mudança proposta ao produto de trabalho for aceita, um

cronograma é identificado para incorporar a mudança no produto de
trabalho e em outras áreas afetadas.
Os mecanismos do controle de configuração podem ser adaptados
às categorias de mudanças. Por exemplo, as aprovações necessárias
poderiam ser mais ou menos estritas para as mudanças que não afetam
outros componentes.
Os itens de configuração alterados são liberados após a revisão e a
aprovação das mudanças de configuração. As mudanças não são oficiais
até que estejam liberadas.
4.6 Definição de políticas
Um processo de software consiste em um conjunto de políticas, de

estruturas organizacionais, de tecnologias, de procedimentos e de
artefatos necessários para conceber, desenvolver, construir e manter um
produto de software e tem um impacto direto na qualidade dos produtos
gerados.
A definição de políticas é requerida na implementação de processos
e, no caso do CMMI, endereça à prática geral 2.1 (do objetivo geral 2), e, no
MPS.BR, o endereça ao atributo de processo AP2.1 (RAP2).
As políticas geralmente referem-se a definições escritas de uma
política organizacional, que garantem a implementação das práticas de
processo definidas em cada projeto.
As políticas estabelecem as expectativas para a avaliação objetiva
dos processos e dos produtos de trabalho associados, sendo utilizadas
nos projetos em relação às definições aplicáveis de práticas, aos padrões
e aos procedimentos, garantindo que as não conformidades sejam
encaminhadas.
Uma política enfatiza a conexão entre o compromisso organizacional
e os projetos que estão sendo desenvolvidos.
Em geral, as políticas organizacionais são criadas em torno das
práticas e objetivos considerados fundamentais para a implementação do
processo.
Na implementação de processos, com base no modelo CMMI,
aconselha-se que as políticas sejam criadas com base nas subpráticas
de cada área de processo.
Exemplos de políticas são:
os compromissos de configuração de software são negociados

previamente pelo controlador de configuração com o gerente de
projeto e/ou comitê de controle de configuração da empresa e
devem estar documentados no plano de Gerência de
Configuração;
o controlador de configuração deve determinar responsáveis para
a revisão do plano de Gerência de Configuração e para outros
compromissos relacionados aos projetos de software;
o plano de Gerência de Configuração deve ser documentado,
gerenciado e controlado e serve de base para o
acompanhamento da configuração dos produtos dos projetos;
as alterações nos compromissos de configuração de software e o
replanejamento são realizados com o envolvimento e a
concordância de todos os envolvidos (equipe, gerente de projeto
etc.);
os documentos de configuração de software possuem a versão
controlada e são armazenados no repositório do projeto;
a aprovação do plano de Gerência de Configuração deve ser
realizada pelo gerente de projeto e pelo comitê de controle de
configuração;
deve haver um controlador de configuração em todos os projetos
da organização;
o comitê de controle de configuração deve autorizar a geração de
b aselines dos projetos;
o comitê de controle de configuração deve revisar e autorizar
mudanças em b aselines dos projetos;
os repositórios dos projetos devem ser criados pelo controlador
de configuração somente por meio de uma solicitação formal do
gerente de projetos.
4.7 Auditorias
A execução de auditorias do processo de gerência de configuração

faz parte do estabelecimento da integridade dos artefatos e é, em geral,
realizada pelo papel responsável pela garantida da qualidade dos
processos (analista de qualidade).
Do ponto de vista das definições de conformidade e capacidade dos
modelos CMMI e MPS.BR, o primeiro endereça o objetivo específico 2 (nas
práticas específicas 2.8, 2.9 e 2.10) e o objetivo específico 3 (e sua prática
específica 3.2) e o segundo endereça o atributo de processo 2.1 (RAP 9 e
RAP 10) e os resultados esperados GCO6 e GCO7.
As auditorias da configuração confirmam se as b aselines e a
documentação resultantes estão em conformidade com um padrão ou
requisito especificado.
As evidências da execução do processo (solicitações, aprovações,
comunicações) deverão estar propriamente armazenadas e disponíveis.
Os resultados da auditoria devem ser registrados conforme
apropriado. Sugere-se que os mesmos também sejam tratados como
produto de trabalho, de modo a estarem sob o processo de Gerência de
Configuração.
São definidos três principais tipos de auditoria:
Auditorias funcionais da configuração (FCA): auditorias

conduzidas para verificar se as características funcionais de um
item de configuração atingiram os requisitos especificados em
sua documentação funcional da linha de base e se a
documentação operacional e de suporte é completa e satisfatória.
Auditorias físicas da configuração (PCA): auditorias conduzidas
para verificar se o item de configuração, como construído, está
em conformidade com a documentação técnica que o define.
Auditorias de Gerência da Configuração: auditorias conduzidas
para confirmar se os registros de Gerência da Configuração e os
itens de configuração estão completos, consistentes e exatos.

<http://www.sei.cmu.edu/reports/10tr033.pdf >. Acesso em: 21 mai. 2014.

Resumo do capítulo
Foram abordadas, neste capítulo, as principais atividades da área

de processo de Gerência da Configuração, detalhando a forma de executá-
las, passando por definições, responsabilidades, entradas e saídas
(principais artefatos). Será importante para o sucesso na disciplina
compreender:
a. plano de configuração;
b. tarefas da identificação da configuração;
c. b aselines;
d. definição de um sistema de configuração (e seus tipos);
e. tarefas da gestão da mudança;
f. definição de políticas;
g. tipos de auditoria.
CAPÍTULO 5
GERÊNCIA DE CONFIGURAÇÃO EM PROJETOS
BASEADOS EM MÉTODOS ÁGEIS
Este capítulo aborda quais são as características de um projeto baseado em
métodos ágeis e qual a forma de aplicar as práticas de Gerência de Configuração nesse
contexto.
Projetos baseados em métodos ágeis são realizados em um ciclo

interativo, com duração, em geral, de duas a três semanas.
Segundo CMMI (2010, p. 58), nesse contexto, a Gerência de
Configuração é fundamental, pois ela precisa suportar mudanças
frequentes, b uilds frequentes (tipicamente diários), múltiplas b aselines e
múltiplas áreas de trabalho (b ranchs).
Por outro lado, uma implementação convencional das práticas de
Gerência de Configuração é vista, por adeptos de métodos ágeis, como
burocrática e pesada.
Aconselha-se, então, que, em projetos ágeis, dois pontos principais
sejam endereçados: o nível de documentação e a automação de grande
parte das atividades de Gerência de Configuração.
Segundo importantes referências na área de Gerência de
Configuração (APLLETON, 2003; BERCZUK, 2003; KONIECZKA, 2003),
uma Gerência de Configuração ágil requer disciplina e feedb ack efetivo e
recorrente. O nível de documentação deve ser readequado para que não
se despenda esforço em criar artefatos (produtos de trabalho) que não
serão utilizados. Do ponto de vista da solução de Gerência de
Configuração ágil, esta deve possibilitar que os desenvolvedores façam
uma mudança precisa no código, enquanto coletam dados sobre novas
mudanças que possam ocorrer.
Nesse sentido, os especialistas advogam que, tendo-se uma
ferramenta que ofereça bom rastreamento de mudança e alto nível de
automação, o mais importante será a disciplina do desenvolvedor.
Em projetos ágeis, tipicamente têm-se poucos desenvolvedores
trabalhando em um número não tão grande (algo em torno de um milhão)
de linhas de código. Logo, se os mesmos forem disciplinados em
documentar corretamente suas alterações e se a ferramenta oferecer bom
suporte de versionamento, a necessidade de controles formais e de
relatórios de revisão (rastreamento) diminuem.
Aconselha-se, então, que as definições das atividades do processo
sejam realizadas o mais objetivamente possível, de modo que os critérios
de seleção, os padrões de identificação e as responsabilidades estejam
definidos a nível de processo e que sejam publicados em repositório de
fácil acesso para o time, evitando a construção de planos de Gerência de
Configuração a cada ciclo.
As atividades de execução do processo devem ser automatizadas
ao máximo, de modo que as atividades rotineiras, como solicitações de
b aselines, aprovações, comunicações, b uilds e rastreamentos (relatórios
de gerência de configuração) sejam endereçadas por meio de integrações
contínuas.
Em ciclos de poucas semanas, as solicitações de mudanças
devem ser priorizadas em tempo de revisão do b acklog, e deve haver a
determinação do escopo de uma nova interação (sprint).
5.1 SCM Patterns
Os patterns, ou padrões em Gerência de Configuração, endereçam

a resolução de problemas específicos (na maioria dos casos conhecidos).
Alguns patterns podem (e devem) ser combinados dentro da
execução do processo de Gerência de Configuração, para que eles
adicionem melhor valor e agilidade na execução do processo.
A seguir, tem-se um conjunto de patterns que podem ser utilizados
para endereçar a Gerência de Configuração em projetos ágeis.
5.1.1 Mainline
Essa prática demonstra como gerenciar o desenvolvimento de sua

solução, de modo a minimizar o esforço de integração.
Em geral, um b ranch possibilita isolar esforços de desenvolvimento
na mesma base de código, permitindo alterações paralelas. Sendo assim,
o b ranch é uma derivação do conjunto base de artefatos que compõe a
solução.
O b ranch, embora muito útil, pode ter um alto custo quando não se
tem uma definição de como os artefatos alterados no próprio b ranch
devem ser reintegrados (merge) para a formação de uma b aseline (versão
estável do produto).
A mainline, também denominada trunk, possibilita que os diferentes
b ranchs (suporte, novos releases etc.) sejam, após atingirem estabilidade,
integrados a uma estrutura denominada base ou principal, e que origina a
versão do produto.
5.1.2 Active development line
Essa prática (ou padrão) ajuda a balancear a estabilidade e o

progresso de um contexto específico de desenvolvimento (release, suporte
etc.) derivado de uma mainline.
Uma active development line deve ter (como vimos em módulos
anteriores) um ciclo de vida bem definido.
O ciclo de vida define estados pelos quais os artefatos podem e/ou
devem progredir no desenvolvimento, suportando verificações de evolução
de qualidade .
Entre esses estados, exemplificamos: “em desenvolvimento”, “bom
para teste”, “em teste integrado”, “em teste de usuário” etc.
As ferramentas de gerência de configuração, em geral,
implementam esses estados por meio das features de TAGS ou LABELS.
5.1.3 Private workspace
Essa prática define que, para o bom suporte ao desenvolvimento

paralelo, desenvolvedores devem manter uma área privada de
desenvolvimento.
A área privada, entretanto, deve seguir os padrões definidos para o
desenvolvimento do produto (estrutura de diretórios, bibliotecas,
ferramentas etc.).
A área privada deve ser um espelho da estrutura da mainline ou da
active line, garantindo que não existam especificidades locais e que área
privada possa tanto ser atualizada a partir da mainline ou da active line
quanto a partir das próprias áreas. sem riscos de violação de integridade
dos artefatos e do produto.
5.1.4 Private system b uild

Essa prática defende que b uilds privados possam ser realizados
com base nos artefatos trabalhados em private workspace.
Nesse sentido, os procedimentos de b uilds (passos e
dependências) para a geração do produto, a partir da private workspace,
devem ser os mesmos utilizados para a geração do produto a partir da
mainline ou de b uilds automatizados.
A realização de private b uilds ira garantir que o conjunto de
componentes locais esteja estável o suficiente para retornar da private
workspace para a active development line.
5.1.5 Integration b uild
Essa prática define que um procedimento padrão para a geração

(b uild) da solução a partir do b ranch referido a uma active development
line ou mainline deve ser definido.
O processo de b uild dever:
ocorrer a partir de um conjunto de artefatos estáveis publicados

na active development line ou mainline;
ser reproduzível;
estar o mais próximo possível dos procedimentos de b uild final
do produto;
ser automatizado, se possível;
possuir mecanismo de logging que facilite a identificação de
problemas (erros ou inconsistências) nos artefatos que compõem
o produto.
5.1.6 Third party codeline
Essa prática orienta que seja criada uma linha de desenvolvimento

para componentes de terceiros.
Para a aceitação de código de terceiros, é necessário:
adicionar o código do fornecedor para o diretório apropriado de

um codeline fornecedor. O mesmo deverá ser adicionado a essa
codeline exatamente do jeito que é recebido do meio de
distribuição. Se o componente é algo que você pode construir
(b uild), você deve ser capaz de construí-lo da área de check-out.
Rotular o check-in ponto com uma etiqueta identificando o produto
e a versão;
imediatamente ramificar esse codeline novo. Todos os projetos
que vão utilizar essa versão do código de fornecedor usarão o
código a partir do ramo, tornando possível customizar o código
quando a fonte estiver disponível. Se você precisar construir os
componentes localmente, é melhor construí-los nesse ramo e
check-in dos objetos derivados.
Verificar objetos derivados para economizar tempo e esforço, não
deve mudar frequentemente;
quando um novo vendor release aparece, adicioná-lo à parte da
linha principal codeline fornecedor. Ramo de novo, e mesclar as
alterações relevantes do ramo antes no novo ramo.
5.1.7 Task Level Commit
Essa prática define que o commit seja realizado em granularidade

baixa (em cada arquivo), auxiliando na garantia da integridade do produto.
O commit de vários itens gera o risco de introduzir-se artefatos não
estáveis (não finalizados) em uma active codeline ou mainline.
5.1.8 Task Branch
Essa prática define que a feature de b ranch seja utilizada para o

suporte ao desenvolvimento de atividades de longa duração em torno de
um conjunto de itens de configuração.
O b ranch deve ser gerado a partir da linha ativa de desenvolvimento,
e , uma vez estável, deve retornar a ela.
O task b ranch garante que membros do time não sejam
bloqueados por atualizações ou por novos requisitos, sendo
implementados artefatos comuns dentro da solução.

BERCZUK, S.; APPLETON, B.; Software Configuration Management
Patterns. Boston: Addison-Wesley, 2002.
BERCZUK, S.; APPLETON, B.; KONIECZKA, S. The Need for Agility in SCM.
2003 Disponível em: <http://www.cmcrossroads.com/article/need-agility-
scm>. Acesso em: 21 mai. 2014.
BERCZUK, S.; APPLETON, B.; KONIECZKA, S. Agile Configuration

Management Environments. 2005. Disponível em :
<http://www.cmcrossroads.com/article/agile-configuration-management-
environments>. Acesso em: 21 mai. 2014.
ALEGRÍA, J.; BASTARRICA, M. Implementing CMMI using a Combination of

Agile Methods. CLEI Electronic Journal, v. 9, N. 1, Paper 7, 2006.
Resumo do capítulo
O capítulo final traz uma interpretação do ponto de vista de autores

contemporâneos e profissionais de Gerência de Configuração sobre a
adoção da área de processo em projetos baseados em métodos ágeis. É
importante assimilar que projetos ágeis têm ciclos de desenvolvimento
pequenos, e que, então, o processo de Gerência de Configuração precisa
ser adaptado, com forte necessidade de disciplina e automação.
REFERÊNCIAS
BAMFORD, R.; DEIBLER II. Configuration Management and ISO 9001.

1995. Disponível em: <http://www.ssqc.com/do25v6new.pdf>. Acesso em:
21 mai. 2014.
HARVEY, K. Summay of SEI Workshop on Software Configuration

Management. 1996. Disponível em: <http://resources.sei.cmu.edu/>.
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%20Legisla
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.


HASS, A. Configuration Management Principles and Practices. Boston:

Addison Wesley, 2003.
BERCZUK, S.; APPLETON, B. Software Configuration Management

Patterns. Boston: Addison-Wesley, 2002.
ALEGRÍA, J.; BASTARRICA, M. Implementing CMMI using a Combination of

Agile Methods. CLEI Electronic Journal, v. 9, n. 1, paper 7, 2006.
UNIVERSIDADE DO VALE DO RIO DOS SINOS – UNISINOS
Reitor: Pe. Marcelo Fernandes de Aquino, SJ

Vice-reitor: Pe. José Ivo Follmann, SJ
Diretor da Editora Unisinos: Pe. Pedro Gilberto Gomes
Editora Unisinos
Avenida Unisinos, 950, 93022-000, São Leopoldo, Rio Grande do Sul,
Brasil
editora@unisinos.br
www.edunisinos.com.br
© dos autores, 2014

2014 Direitos de publicação da versão eletrônica (em e-book) deste livro
exclusivos da Editora Unisinos.
S111g Saad, Rodrigo.

Gerência de configuração de software [recurso eletrônico] /
Rodrigo Saad. – São Leopoldo : Ed. UNISINOS, 2014.
1 recurso online – (EaD)
ISBN 978-85-7431-645-1
1. Engenharia de software. 2. Gerenciamento de

configurações de software. 3. Livros eletrônicos. I. Título. II.
Série.
CDD 005.1
CDU 004.41
Dados Internacionais de Catalogação na Publicação (CIP)
(Bibliotecário: Flávio Nunes – CRB 10/1298)
Coleção EAD
Editor: Carlos Alberto Gianotti
Acompanhamento editorial: Mateus Colombo Mendes
Revisor: Guilherme Pedrosa
Editoração: Guilherme Hockmüller
A reprodução, ainda que parcial, por qualquer meio, das páginas que
compõem este livro, para uso não individual, mesmo para fins didáticos,
sem autorização escrita do editor, é ilícita e constitui uma contrafação
danosa à cultura. Foi feito depósito legal.

Gerencia de Configuracao de Sof - Unisinos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerencia de Configuracao de Sof - Unisinos

Enviado por

Direitos autorais:

Formatos disponíveis

GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE

Editora Unisinos, 2014

Este livro tem por objetivo apresentar um conjunto de conceitos

A Gerência de Configuração passou a ser tratada como uma

1.1 Principais estudos

As primeiras publicações sobre a Gerência de Configuração de

a. identificar unicamente as versões de cada item de software;

Em um estudo complementar, o SEI (1992), em sua publicação SEI-

a. Identificação da configuração: determina qual conjunto de

Na evolução do estudo em gestão da qualidade, a ISO publicou

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

Em outras palavras, a Gerência de Configuração estará presente

1.3 Benefícios da Gerência de Configuração

Sendo uma atividade de suporte/apoio a outras áreas de processo,

desenvolver uma nova versão de um pedaço de software enquanto

As atividades de Gerência de Configuração podem ser vistas como

1.4 Principais papéis e artefatos

Figura 2 – Principais Papéis no contexto de Gerência de Configuração.

Esses papéis podem ser definidos como:

Controlador/gerente de configuração: responsável pelo

O relatório técnico do SEI (1986, p.02), CMU/SEI-86-TR-5, menciona

Plano de gerência ou de controle de configuração: artefato parte

Ainda, segundo a ABNT (1998), a b aseline pode ser definida como

Recomendações para complementação de estudos referentes aos

BAMFORD, R.; DEIBLER II. Configuration Management and ISO 9001.

Software Engineering Institute. Capab ility Maturity Model Integration,

HARVEY, K. Summary of SEI Workshop on Software Configuration

Neste capítulo, foram apresentados os conceitos base da Gerência

a. das principais atividades de Gerência de Configuração de

2.1 Padrões ISO/IEC 12207 e 15288

A ISO/IEC 12207 foi publicada inicialmente em 1º de agosto de 1995

No intuito de descrever mais objetivamente os processos

Nesse contexto, o processo de gerência de configuração faz parte

Figura 4 – Descrição resumida do processo de Gerência de Configuração na ISO/IEC

Similar a ISO/IEC 12207, a ISO/IEC 15288 tem como foco os

Figura 5 – Grupos de processos – ISO/IEC 15288.

A ISO/IEC 15288 entende a definição de sistemas de uma forma

Figura 6 – Descrição resumida do processo de Gerência de Configuração na ISO/IEC

Quando o elemento foco é o software, e não o sistema, a ISO/IEC

2.2 Padrão ISO/IEC 15504 - SPICE

A norma ISO/IEC 15504, também conhecida como SPICE (Software

Na dimensão de processos, a norma limita-se a suportar a

BP1 Desenvolver uma estratégia de gerência de configuração:

Na dimensão de avaliação de capacidade, a ISO/IEC 15504 é

AP 1.1 - desempenho do processo;

Similar à definição de práticas base na dimensão de processo, na

PA 1.1 Atrib uto de processo de performance – A extensão por meio

a. o escopo de trabalho a ser realizado e os produtos de

As práticas gerenciais relacionadas são:

MP 1.1.1: identificar produtos de trabalho de entrada e de saída

Para melhor ilustrar a organização dos níveis e o que é esperado na

Em resumo, e de maneira geral, em uma avaliação de capacidade

Não atingido (not achieved):0-15%.

A ISO/IEC 15504 ainda traz, em suas partes, orientações específicas

O CMMI (Capab ility Maturity Model Integration) é um modelo de

CMMI para o desenvolvimento (CMMI-DEV): foca-se em processo

O modelo de referência CMMI-DEV ainda apresenta as suas 22

A área de processo de gerência de configuração é, assim como na

Os elementos das áreas de processo garantem a verificação da

Estabelecer e manter a integridade dos produtos de trabalho

Na nota introdutória, tem-se um resumo das principais atividades e

a identificação da configuração de produtos de trabalho

A definição de que os produtos de trabalho colocados sob gerência