Contexto para Gerência de
Configuração
1/113
Gerência de Configuração e
mudança
Objetivo
• Compreender a importância do uso de
mecanismos de gerência de configuração e de
mudança, seus métodos, processos e ferramentas.
• Fornecer os principais conceitos relacionados a
GC.
• Criar uma visão geral de como GC pode ser
aplicada a um projeto de software.
2/113
Problema da Quebra de Comunicação
Desenvolvedor A
Desenvolvedor B
Desenvolvedor C
3/113
Problema da Quebra de
Comunicação (continuação)


Falhas de comunicação em equipes
Ocorre pelas mais diversas razões:
Vocabulários incompatíveis
 Culturas de desenvolvimento diferentes
 Distância geográfica
 Dificuldade de expressão


Quando este problema acontece:
Os sistemas produzidos não atendem aos requisitos
 Força de trabalho é desperdiçada

4/113
Problema dos Dados Compartilhados
Desenvolvedor A
Programa de A
A1
A2
A3
Desenvolvedor B
Componente
Compartilhado
Programa de B
B1
B2
B3
5/113
Problema dos Dados
Compartilhados - Cenário




O desenvolvedor A modifica o componente
compartilhado
Mais tarde, o desenvolvedor B realiza algumas
alterações no mesmo
Ao tentar compilar o componente, erros são
apontados pelo compilador, mas nenhum deles
ocorre na parte que B alterou
O desenvolvedor B não tem a menor idéia
sobre a causa do problema
6/113
Problema dos Dados
Compartilhados - Solução simplista

Solução simplista:
 cada
desenvolvedor trabalha em uma cópia
“local” do componente
 resolve o Problema dos Dados Compartilhados,
mas cria um novo problema
7/113
Problema da Manutenção Múltipla
Desenvolvedor A
Programa de A
A1
A2
A3
Componente
Compartilhado
Versão de A do
Componente
Compartilhado
Desenvolvedor B
Componente
Compartilhado
Programa de B
B1 B2 B3
Versão de B do
Componente
Compartilhado
8/113
Problema da Manutenção Múltipla
(continuação)


Ocorre quando cada desenvolvedor trabalha com uma
cópia “local” do que seria o mesmo componente
Dificuldade para saber:
Que funcionalidades foram implementadas em quais
versões do componente
 Que defeitos foram corrigidos


Evitado através de uma biblioteca central de
componentes compartilhados
Nesse esquema, cada componente é copiado para a
biblioteca sempre que alterado
 Resolve o Problema da Manutenção Múltipla, mas...

9/113
Problema da Atualização Simultânea
Biblioteca Central de
Recursos Compartilhados
Desenvolvedor A
Desenvolvedor B
Componente
Compartilhado
Programa de A
A1
A2
A3
Versão de A do
Componente
Compartilhado
Versão de B do
Componente
Compartilhado
Programa de B
B1 B2 B3
10/113
Problema da Atualização
Simultânea – Cenário 1




O desenvolvedor A encontra e corrige um
defeito em sua versão do componente
compartilhado
Uma vez corrigido, o componente modificado é
copiado para a biblioteca central
O desenvolvedor B encontra e corrige o
mesmo defeito em sua versão do componente
por não saber que A já tinha feito isso
O trabalho de A é desperdiçado
11/113
Problema da Atualização
Simultânea – Cenário 2






O desenvolvedor A encontra e corrige um defeito em sua versão
do componente compartilhado
Uma vez corrigido, o componente modificado é copiado para a
biblioteca central
O desenvolvedor B encontra e corrige um outro defeito em sua
versão do componente, sem saber do defeito corrigido por A
O desenvolvedor B copia sua versão do componente para a
biblioteca central
Além de o trabalho de A ser desperdiçado, a versão do
componente que se encontra na biblioteca central continua
apresentando um defeito
O desenvolvedor A julga o problema como resolvido
12/113
Como Resolver?


O problema da atualização simultânea não
pode ser resolvido simplesmente copiando
componentes compartilhados para uma
biblioteca central
Algum mecanismo de controle é necessário
para gerenciar a entrada e saída dos
componentes
13/113
O que é Gerência de Configuração?


Gerência de configuração (GC) é o processo
de identificar, organizar e controlar
modificações ao software sendo construído
A idéia é maximizar a produtividade
minimizando os enganos
14/113
Objetivos de GC





Definir o ambiente de desenvolvimento
Definir políticas para controle de versões,
garantindo a consistência dos artefatos
produzidos
Definir procedimentos para solicitações de
mudanças
Administrar o ambiente e auditar mudanças
Facilitar a integração das partes do sistema
15/113
Benefícios




Aumento de produtividade no desenvolvimento
Menores Custos de Manutenção
Redução de defeitos
Maior rapidez na identificação e correção de
problemas
16/113
Conceitos Básicos
17/113
Configuração

Um projeto de desenvolvimento de software
produz os seguintes itens:
 Programas
(código fonte, programas
executáveis, bibliotecas de componentes, etc.)
 Documentação (manuais do usuário, documento
de requisitos, modelo de análise e projeto, etc.)
 Dados (dados de teste e do projeto)

Esses conjuntos de itens são chamados,
coletivamente, de configuração do software
18/113
Item de Configuração



Um conjunto de itens de hardware e/ou software
vistos como uma entidade única para fins de
gerência de configuração
Um item de configuração está sujeito a mudanças
e essas devem obedecer às políticas
estabelecidas
Normalmente, um item de configuração é
estabelecido para cada pedaço de software que
pode ser projetado, implementado e testado de
forma independente
19/113
Configuração de Software
item
fluxo de desenvolvimento
tempo
20/113
Baseline

Uma especificação ou produto que foi formalmente
revisado e aceito




Serve como base para os passos posteriores do
desenvolvimento
A configuração do software em um ponto discreto no
tempo
Só pode ser modificado através de procedimentos
formais (solicitações de mudança)
Um artefato ou conjunto de artefatos só se torna um
item de configuração depois que um baseline é
estabelecido
21/113
Baseline
item
fluxo de desenvolvimento
tempo
22/113
Razões para Criar um Baseline
• Reproducibilidade – a habilidade de
reproduzir uma versão anterior do sistema
• Rastreabilidade – Estabelece uma relação
predecessor-sucessor entre artefatos do
projeto (projeto satisfaz requisitos, código
implementa projeto, etc.)
• Geração de Relatórios – A comparação dos
conteúdos de dois baselines ajuda na
depuração e criação de documentação
• Controle de Mudanças – referencial para
comparações, discussões e negociações
23/113
Baselines importantes

Baselines são considerados marcos no
processo de desenvolvimento:
 Funcional
: requisitos
 De Produto : releases, iterações
24/113
Repositório



Local (físico e lógico) onde os itens de um
sistema são guardados
Pode conter diversas versões do sistema
Utiliza mecanismos de controle de acesso
Desenvolvedor
Repositório
25/113
Lock



Resolve a Atualização Simultânea
Garante que apenas o usuário que detém o
lock pode alterar o arquivo
Problema: “serializa” o trabalho dos
desenvolvedores
26/113
Check-Out
Check-out
cliente
Repositório
27/113
Check-Out (continuação)

Recupera a (última) versão de um item de
configuração guardada no repositório
 Escrita
 Verifica
que ninguém detém o lock do item de
configuração
 Obtém o lock do item
 Cria uma cópia, para edição, no cliente
 Leitura
 Verifica
que alguém já detém o lock
 Cria uma cópia, apenas para leitura, no cliente
28/113
Check-In
Check-in
cliente
Repositório
29/113
Check-In (continuação)

Ação de inserir/atualizar um item de
configuração no repositório
 Verifica
o lock do item de configuração, caso o
mesmo já exista
 Verifica e incrementa a versão do item
 Registra informações das mudanças (autor,
data, hora, comentários)
 Inclui/atualiza o item
30/113
Build





Representa uma versão ainda incompleta do sistema
em desenvolvimento, mas com certa estabilidade
Costuma apresentar limitações conhecidas
Espaço para integração de funcionalidades
Inclue não só código fonte, mas documentação,
arquivos de configuração, base de dados, etc.
A política de geração dos builds deve ser bem definida
na estruturação do ambiente
31/113
Os Problemas na Geração de
Builds



Fazer os builds do sistema manualmente é
muito demorado
Pode ser difícil saber qual a versão “correta” de
um arquivo
Os pedaços do sistema podem estar em
diversos locais diferentes
 Alguns
arquivos podem ser esquecidos
32/113
Os Problemas na Geração de
Builds

A integração das partes de um sistema em
desenvolvimento normalmente é:
 Realizada
poucas vezes, apenas perto de sua
implantação
 Feita em freqüência inversamente proporcional
à complexidade do sistema

Integrar as partes de um sistema é uma tarefa
trabalhosa e sujeita a erros
 Quanto
maior o sistema, mais difícil
33/113
Os Problemas na Geração de
Builds

Consequência: problemas de integração
tornam-se difíceis de detectar cedo no
desenvolvimento
 Costumam
ser encontrados muito depois de sua
introdução
 É muito difícil rastrear suas causas
34/113
Geração de Buils através da
Integração Contínua

Geração freqüente (pelo menos diária) de builds do
sistema
As partes do sistema são integradas constantemente
 Problemas de integração passam a ser encontrados logo
que introduzidos, na maioria dos casos



Considerada uma das “melhores práticas” no
desenvolvimento de software
A geração de builds deve ser automatizada e
realizada com freqüência adequada
35/113
Release



Identificação e empacotamento de artefatos entregues
ao cliente (interno ou externo) ou ao mercado
Um release implica no estabelecimento de um novo
baseline, de produto
Produto de software supostamente sem erros



Versão do sistema validada após os diversos tipos de teste
Garantia de que todos os itens de configuração foram
devidamente testados, avalidos, aceitos e estão disponíveis no
novo baseline
Processo iterativo/incremental produz, em geral, mais
de um release
36/113
Tipos de release


Normalmente, releases estão associados aos
milestones do plano de projeto
Internos
 Controle
de qualidade, acompanhamento de
projeto, controle de riscos, aceitação, aquisição
de conhecimento através da coleta de
feedbacks, desenho da estratégia de
implantação

Externos
 Implantado
e utilizado pelo cliente
37/113
Tags


Rótulos que são associados a conjuntos de
arquivos
Um tag referencia um ou mais arquivos em um
ou mais diretórios
 Costuma-se
usar tags para:
 Denominar
projeto rotulando todos os arquivos
associados ao projeto
 Denominar uma versão do projeto (um build ou
release) rotulando todos os arquivos associados
ao build ou release
38/113
Tags – Cenário 1
raiz
file2
file3
subdir1
file1
file4
file6
subdir2
tag1
tag2
file5
file7
file8
file9
39/113
Tags – Cenário 2
1.1
1.2
1.3
release_1
Histórico
de um
arquivo
1.4
release_2
tag
40/113
Branch



Criação de um fluxo alternativo para
atualização de versões de itens de
configuração
Recurso muito poderoso
Devem existir regras bem definidas para
criação de branches
 Por
que e quando devem ser criados?
 Quais os passos?
 Quando retornar ao fluxo principal?
41/113
Branch (continuação)


Uso de lock inviabiliza a criação de branches
Branches normalmente se originam de
correções em versões anteriores
42/113
Branch (exemplo)
Maria
hello.c
1
hello.h
1
José
2
hello.c
3.m.1 3.m.2 3.m.3
hello.h
2.m.1
3 •
2
4
2.m.2
5
• 3
hello.c
3.j.1
hello.h
2.j.1
6
4
3.j.2
3.j.3
2.j.2
43/113
Merge




Unificação de diferentes versões de um mesmo item de
configuração
Integração dos itens de configuração de um branch
com os itens de configuração do fluxo principal
Check-out atualizando a área local
Algumas ferramentas fornecem um mecanismo
automático para realização de merges

Mesmo com o uso de ferramentas, em vários casos há
necessidade de intervenção humana
44/113
Merge (exemplo)
hello.c
3.m.1 3.m.2 3.m.3
hello.h
2.m.1
Maria
hello.c
3
hello.h
2
José
•
•
hello.c
3.j.1
hello.h
2.j.1
2.m.2
4
5
3
4
3.j.2
3.j.3
3.j.4
2.j.2
2.j.3
45/113
Branching e Merging: esquema
gráfico
Branch
patch
1.2.2.1
1.1
1.2
tag
1.2.2.2
1.3
1.4
release_2
release_1
Tronco principal
de
desenvolvimento
tag
Merge
46/113
Oportunidades criadas com GC

Reuso de itens de software
Artefatos
 Componentes


Automação de processo
Construção de builds
 Geração de releases
 Testes
 Integração




Aumento da produtividade das equipes
Redução de re-trabalho
Melhoria do acompanhamento do projeto
47/113
Controle de Mudanças
48/113
Contexto



Desenvolvimento iterativo/incremental
Novos conjuntos de requisitos, detalhados a
cada iteração
Mudanças em estratégias de negócio
motivadas pelas mais diversas fontes:
mercado, cultura, leis, etc
49/113
Problemas

Controle do escopo do projeto
Modificações podem ampliar o leque de funcionalidades
e aumentar significativamente o custo do projeto
 Atrasos em entregas planejadas


Controle de consistência dos artefatos
Uma mudança aparentemente localizada pode causar
muito mais impacto do que o previsto
 Degradação da qualidade do software (ex: abandono dos
testes automatizados devido à inconsistência dos dados
de teste)
 Retrabalho

50/113
O que é Gerência de Mudanças?


Gerência de Mudanças é o processo de avaliar,
coordenar e decidir sobre a realização de
mudanças propostas a itens de configuração
(ICs)
Mudanças aprovadas são implementadas nos
itens de configuração e nos dados e
documentos relacionados
51/113
Objetivos da Gerência de Mudanças



Garantir que os artefatos do sistema alcançam e
mantêm uma estrutura definida através do seu ciclo de
vida
Definir procedimentos e documentação necessários
para realizar modificações a ICs
Prover os mecanismos necessários para
conduzir mudanças de uma maneira
controlada
52/113
Benefícios


Controle sobre o escopo do projeto
Mais produtividade
cada solicitação será tratada de forma coordenada
 Redução dos problemas de comunicação entre membros
da equipe



Mais qualidade, uma vez que cada mudança, antes de
ser realizada, tem seu impacto avaliado
Geração de dados para o acompanhamento (tracking)
do projeto
53/113
Controle do caos
Controle de mudanças
Solicitação de mudança
Projeto
Organização
54/113
Ciclo de vida de um artefato
55/113
Ciclo de vida de um artefato
Concepção do
artefato
Revisão/aceitação
(baseline)
Draft
Mudanças feitas
de forma informal
Release
Aceito
Mudanças via
controle formal
(CCB)
Manutenção
Mudanças em
manutenção
56/113
Artefato Draft




Mudanças freqüentes e rápidas
Demanda por agilidade
Controle formal dificulta a criação do artefato
Artefatos apenas gerenciados e controlados
 Uso
de controle de versão (CVS, Clear Case,
entre outras ferramentas)
57/113
Artefato Aceito




Artefato seguiu um processo de revisão, testes
(se aplicável) e aceitação
Inserido dentro do processo de controle de
mudanças, tornando-se de fato item de
configuração
Mudanças via solicitação formal
Presença do grupo gestor de mudanças (CCB)
para avaliar e priorizar mudanças
58/113
Artefato em Manutenção




Após a entrega de uma versão do produto, os
artefatos passam para a fase de manutenção
Controle de mudanças permanece formal para
os artefatos de um baseline
Novas artefatos podem ser desenvolvidos
usando o mesmo modelo de ciclo de vida
Sistema pode ser descontinuado ou removido
do ambiente de produção
59/113
Processo de Gerência de
Mudanças
60/113
Motivação



Mudança é inevitável
Mudar é fácil – controlar diversas mudanças
simultâneas é difícil
A gerência de mudanças introduz controle
sobre as mudanças de maior relevância
 Todas
as mudanças são analisadas
 Apenas as aprovadas são realizadas
 Sempre se sabe quem modificou o que, onde e
quando
61/113
Responsabilidades do CCB





Analisar as solicitações de mudança
Controlar o escopo do projeto
Reuniões com freqüência adequada ao ritmo das
solicitações de mudança
Envolver stakeholders no processo de priorização no
processo de decisão
Balanço entre o nível de controle desejado e overhead
suportado

Questões menores devem ser resolvidas pelo líder do
projeto junto à equipe, reduzindo o overhead do CCB
62/113
Características do CCB

Composição multidisciplinar
 SQA,


gerente, cliente, arquiteto
Profissionais com grande capacidade de
comunicação e negociação
Pode apresentar uma estrutura hierarquica
dependendo do tamanho e da quantidade de
stakeholders e sistemas envolvidos
(integrações)
63/113
Análise de impacto





Mudanças de grande impacto devem ser comunicadas
aos stakeholders envolvidos
Análises de custo x benefício produzidas pelos
stakeholders
Priorização de mudanças
Mudança pode ser rejeitada se o CCB perceber que o
custo será mais caro que o benefício percebido
Por questões de eficiência, algumas solicitações de
mudança podem ser agrupadas por tema, subsistema
ou área de negócio
64/113
Importância da análise de impacto


Dentro do projeto
Análises inter-sistemas também devem ser
consideradas

Exemplo: frameworks, componentes ou bancos de dados
compartilhados
Requisitos
A&P
Componentes 65/113
Sobre o Processo de Gerência de
Mudanças




Deve ser definido um documento padrão para que
mudanças possam ser solicitadas
Esse documento normalmente se chama Solicitação de
Mudança (SM, Em inglês CR)
A um conjunto de pessoas (CCB), deve ser dada a
autoridade para decidir se uma mudança será ou não
implementada
O processo é necessário para garantir que apenas
mudanças avaliadas e aprovadas são realizadas em
ICs
66/113
Solicitações de Mudança

Algumas informações que podem estar incluídas em
uma SM:
Identificação única
 Solicitante
 Sistema/Projeto
 Item a ser modificado
 Classificação (melhoria, correção de defeito, outra)
 Prioridade
 Descrição
 Situação (nova, atribuída, finalizada, verificada, fechada)

67/113
Estrutura de um registro de
solicitação de mudança
1. IDENTIFICADOR DA SOLICITAÇÃO
<Um código (normalmente numérico) que identifica unicamente a
solicitação de mudança.>
2. IDENTIFICAÇÃO DO SOLICITANTE
<O nome do indivíduo que solicitou a mudança, possivelmente
incluindo informação adicional como posição, matrícula, etc.>
3. SISTEMA DESENVOLVIDO
3.1. NOME DO SISTEMA
<O nome do sistema no qual está sendo solicitada a
mudança.>
3.2. NOME DO MÓDULO
<O nome do módulo no qual a mudança está sendo
solicitada.>
3.3. NOME DA FUNCIONALIDADE
<O nome da funcionalidade na qual a mudança será efetuada.>
68/113
Estrutura de um registro de
solicitação de mudança
4. CLASSIFICAÇÃO
<O tipo de mudança que está sendo solicitada. Normalmente três tipos de
mudança são realizados: adição de nova funcionalidade, melhoria de
funcionalidade já existente e correção de defeitos. Também é comum que a
classificação seja feita com relação à natureza da mudança. Por exemplo:
mudança de requisitos, de projeto, de implementação, etc.>
5. DESCRIÇÃO
<Uma descrição da mudança que está sendo solicitada. A descrição deve
ser o mais não-ambígua e objetiva possível. Ao mesmo tempo, deve incluir
toda informação necessária para implantar a mudança.>
6. STATUS
<A situação atual da mudança. Por exemplo: aprovada, rejeitada, em
implantação, postergada, etc. Essa informação deve ser mantida sempre
atualizada.>
7. OBSERVAÇÕES GERAIS
<Informações adicionais sobre a solicitação de mudança. Por exemplo: se
o solicitante já souber de módulos que serão afetados pela implantação da
mudança, pode enumerá-los nesta seção.>
69/113
Etapas do Processo de Gerência de
Mudanças Genérico
CCB
4.Negociação sobre
a realização da
mudança
1. Requisição
da mudança
6. Verificação
da mudança
(mudança aceita)
2. Classificação
da mudança
3. Avaliação
da mudança
5. Implementação
da mudança
7. Promoção dos
itens modificados
para um novo
baseline
70/113
Correções Emergenciais




Em algumas situações, não há tempo para seguir os
procedimentos padrão para a realização de mudanças
Defeitos não são normalmente processados pelo CCB,
salvo se envolverem algum questionamento relativo ao
escopo do projeto
Mesmo nessas situações, porém, é muito importante
que seja criada uma solicitação de mudança
O objetivo é garantir um mínimo de ordem, mesmo em
uma situação caótica
71/113
Correções Emergenciais


Mudanças realizadas nessas circunstâncias
podem comprometer a arquitetura ou inserir
bugs
Decisão:
 Desfazer
correção ou
 Transformar a correção: refactoring, acréscimo
de novos casos de teste
72/113
Exemplos de Status dos Defeitos
Estados Abertos
Próximos Estados
NEW
Bug inserido por
alguém (automático)
Aceito a ASSIGNED
Reatribuído a NEW
Resolvido a RESOLVED
ASSIGNED
Atribuído à pessoa
apropriada
Reatribuído a NEW
Resolvido a RESOLVED
REOPENED
Reaberto: foi
constatado que
ainda não tinha sido
resolvido
Aceito a ASSIGNED
Reatribuído a NEW
Resolvido a RESOLVED
UNCONFIRMED
Não confirmado que
existe
Confirmado a NEW
Resolvido a RESOLVED
73/113
Exemplos de Status dos Defeitos
Estados Fechados
Próximos Estados
RESOLVED
Foi resolvido (só
está esperando
a homologação)
Não foi resolvido a REOPENED
Está ok a VERIFIED
Está ok e pode ser fechado a
CLOSED
VERIFIED
A correção foi
homologada
Defeito é fechado a CLOSED
CLOSED
O bug é tido
como resolvido
Não foi resolvido a REOPENED
74/113
Release notes



Relação de solicitações de mudanças implementadas e
testadas
Pode ser parcialmente automatizado
Comentários adicionais

Limitações atuais, problemas não resolvidos
Id
Descrição
1
Problema de performance na
validação de pedido
2
Nova rotina de validação de crédito
conforme normas de dezembro de
2002
…
…
75/113
Desafios

Cultura organizacional
 Agrupamento
de solicitações em releases bem
definidos e estabelecidos deve ser negociado
com os stakeholders do projeto
 Releases internos utilizados de forma efetiva
como ferramenta de gestão de projeto

Integração entre sistemas de controle de
versão e mudanças
76/113
Ferramentas de Apoio à Gerência
de Configuração
Ferramenta de Controle de Versões (CVS, por exemplo)
Manter todos os arquivos em um repositório central

Controlar o acesso a esse repositório, de modo a
garantir a consistência dos artefatos
Ferramentas de Geração de Builds (Ant, por exemplo)


Automatizar o processo de geração de builds
Ferramentas de Gestão de Solicitações de Mudanças
(Bugzilla, por exemplo)

Automatizar o processo de submissão e gestão de SMs
77/113
Gerência de Configuração no
Desenvolvimento Iterativo Relação com as Fases e
Disciplinas de
Desenvolvimento do RUP
78/113
Fases, iterações e disciplinas
Fases
Fluxos de Atividades
Concepção
Elaboração
Iteração
Preliminar
Iter.
#1
Construção
Transição
Requisitos.......................................
Análise e Projeto............................
Implementação...............................
Testes.............................................
Implantação...................................
Fluxos de Suporte
Planejamento e Gerenciamento.....
Gerência de Configuração e Mudanças
Iter.
#2
Iter.
#i
Iter.
#i+1
Iter.
#i+2
Iter.
#n
Iter.
#n+1
Iterações
79/113
Relação com as Fases de
Desenvolvimento e com as Outras
Disciplinas




Tem uma maior concentração na fase de concepção
Nas iterações das fases seguintes, o nível de esforço é
mantido constante
Acontece em paralelo e com uma forte integração com
a disciplina de planejamento e gerenciamento
Algumas atividades relacionadas com a gerência da
configuração ocorrem em outras disciplinas como a
implementação e a implantação
80/113
Atividades, Artefatos e
Responsabilidades da
Disciplina Gerência de
Configuração
81/113
Objetivos deste módulo


Apresentar atividades da Disciplina de
Gerrência de Configuração
Discutir os artefatos e responsáveis envolvidos
na realização das atividades da disciplina
82/113
Fluxo de Atividades
Solicitante
Gerente de
Configuração
e Ambiente
CCB
Submeter
solicitações de
mudanças
Definir
ferramentas e
equipamentos
Estruturar
ambiente
Analisar
solicitações de
mudanças
Planejar
gerência de
configuração
Implantar e
administrar
ambiente
83/113
Objetivos do Fluxo

Definir
 Recursos
de hardware e software
 Política de atualização destes recursos
 Estruturação de diretórios e repositórios
 Plataforma de desenvolvimento
 Política de utilização do ambiente
 As atividades de Gerência de Configuração que
deverão ser realizadas e em que momentos do
desenvolvimento
84/113
Responsáveis e Artefatos
Gerente de
Configuração
Solicitante
CCB
Documento de
Definição de
Ambiente
Registro de
Solicitação de
Mudanças
Registro de
Solicitação de
Mudanças
Plano de Gerência
de Configuração de
Software
85/113
Gerente de Configuração




Responsável pela definição dos equipamentos
e softwares utilizados e suas configurações
Define o ambiente, regras de uso do mesmo e
política de mudanças
Define os papéis dos membros da equipe
responsáveis pelas atividades de gerência de
configuração
Estabelece as atividades de gerência de
configuração que serão realizadas
86/113
Solicitante

Qualquer pessoa que possa fazer uma
solicitação de Mudanças
87/113
CCB

Grupo Responsável por analisar e autorizar
uma solicitação de mudanças
88/113
Artefato – Documento de Definição
de Ambiente
1. INTRODUÇÃO
<Descreva os objetivos do documento>
2. INFRA-ESTRUTURA
2.1. FERRAMENTAS
<Descreva que ferramentas serão usadas por todos os
envolvidos no projeto durante o seu desenvolvimento,
fornecendo uma breve descrição de cada uma e a
quantidade de licenças disponíveis>
2.2. EQUIPAMENTOS
<Descreva que equipamentos serão usadas durante o
desenvolvimento do sistema, detalhando suas
configurações>
3. ORGANIZAÇÃO FÍSICA
<Forneça uma breve descrição da estrutura física do local
onde o sistema será desenvolvido>
89/113
Artefato – Documento de Definição
de Ambiente
4. PADRÃO DE NOMENCLATURA DE ARTEFATOS
<Descreva qual será a convenção utilizada para nomear os
artefatos, em inglês ou português>
5. AMBIENTE LOCAL
5.1. ESTRUTURA DE DIRETÓRIOS
5.2. INFORMAÇÕES ADICIONAIS
6. AMBIENTE DE HOMOLOGAÇÃO E TESTES
6.1. ESTRUTURA DE DIRETÓRIOS
6.2. INFORMAÇÕES ADICIONAIS
7. AMBIENTE DE PRODUÇÃO
7.1. ESTRUTURA DE DIRETÓRIOS
7.2. INFORMAÇÕES ADICIONAIS
8. ARQUIVOS DE CONFIGURAÇÂO
<Descreva os arquivos utilizados para configuração e uso do
sistema>
90/113
Artefato – Documento de Definição
de Ambiente
9. PROMOÇÂO ENTRE AMBIENTES E BACKUPS
<Defina a política para promoção dos artefatos entre os
ambientes e realização de backups>
9.1. AMBIENTE LOCAL
AMBIENTE DE
HOMOLOGAÇÃO E TESTES
<Descreva o procedimento que deve ser usado para transferir
arquivos do ambiente local para o de homologação e testes
9.2. AMBIENTE LOCAL
AMBIENTE DE PRODUÇÃO
<Descreva o procedimento que deve ser usado para realizar a
transferência de arquivos entre o ambiente de homologação e
testes e o ambiente de produção>
10. POLÍTICA DE BACKUP
<Descreva o procedimento que deve ser usado para realização
de backups em cada um dos ambientes>
11. AVALIAÇÃO E REVISÃO DO AMBIENTE
<Descreva as modificações que serão necessárias no ambiente
para o desenvolvimento do projeto>
12. REFERÊNCIAS
91/113
Artefato – Plano de Gerência de
Configuração de Software
1. INTRODUÇÃO
<Descreva os objetivos do documento, forneça definições de
termos necessários para o entendimento do mesmo e liste algumas
referências interessantes.>
2. GERENCIAMENTO DA GERÊNCIA DE CONFIGURAÇÃO DE
SOFTWARE
2.1. ORGANIZAÇÃO
<Deve ser descrita nesta seção a estrutura da equipe de GCS e
como ela se encaixa na estrutura da organização com relação a
outras equipes>
2.2. RESPONSABILIDADES
<Defina nesta seção os deveres e responsabilidades daqueles
que estiverem envolvidos com as atividades de GCS.>
2.3. RELAÇÃO COM AS FASES DO DESENVOLVIMENTO
E OUTROS FLUXOS DE ATIVIDADES
<Nesta seção são relacionadas as atividades de GCS com as
diferentes etapas do ciclo de vida do desenvolvimento de
92/113
software.>
Artefato – Plano de Gerência de
Configuração de Software
3. ATIVIDADES DA GERÊNCIA DE CONFIGURAÇÃO DE
SOFTWARE
3.1. IDENTIFICAÇÃO DA CONFIGURAÇÃO
<Esta seção descreve como identificar, nomear e adquirir os
itens de configuração do sistema.>
3.1.1. Identificação de itens de configuração
3.1.2. Nomeação dos itens de configuração
3.1.3. Aquisição e armazenamento de itens de
configuração
3.1.4. Gerenciamento de baselines
3.2. CONTROLE DA CONFIGURAÇÃO
<Nesta seção deve ser descrito o processo de gerência de
mudanças. Normalmente, essa informação é colocada em um
documento a parte chamado Documento de Políticas de
Mudanças. Aqui deve apenas ser incluído um apontador para
esse documento.>
93/113
Artefato – Plano de Gerência de
Configuração de Software
3.3. REGISTRO DO STATUS DA CONFIGURAÇÃO
<Esta seção lida com os detalhes de registrar o status de
cada item de configuração e apresentar essa informação aos
indivíduos que precisam saber sobre ela.>
3.1.1. Identificação das necessidades de informação
3.1.2. Mecanismos de coleta de informações
3.1.3. Relatórios, seus conteúdos e frequências
3.1.4. Acesso a dados de registro de status
3.4. AUDITORIA DA CONFIGURAÇÃO
<Esta seção descreve os tipos de auditoria que serão
realizados, o procedimento de auditoria, a freqüência e
qualquer outra informação relevante.>
3.1.1. Auditorias que devem ser realizadas
3.1.2. Procedimentos de auditoria
94/113
Artefato – Plano de Gerência de
Configuração de Software
4. AGENDA DA GERÊNCIA DE CONFIGURAÇÃO
<Esta seção descreve a seqüência de atividades de GCS, suas
interdependências e a relação com o ciclo de vida do projeto.>
5. RECURSOS DE GERÊNCIA DE CONFIGURAÇÃO
<Indique nesta seção as ferramentas de software, técnicas,
equipamentos, pessoas e treinamentos necessários para a
implementação das atividades de gerência de configuração
especificadas.>
6. MANUTENÇÃO DO PLANO DE GERÊNCIA DE
CONFIGURAÇÃO DE SOFTWARE
<Esta seção descreve as atividades que são necessárias para
manter o plano atualizado durante o ciclo de vida do projeto.>
95/113
Definir Ferramentas e
Equipamentos
Solicitante
Gerente de
Configuração
e Ambiente
CCB
Submeter
solicitações de
mudanças
Definir
ferramentas e
equipamentos
Estruturar
ambiente
Analisar
solicitações de
mudanças
Planejar
gerência de
configuração
Implantar e
administrar
ambiente
96/113
Definir Ferramentas e
Equipamentos(continuação)

Objetivos
 Definir
ferramentas de suporte ao
desenvolvimento, controle de versões e
softwares em geral
 Definir hardwares e suas configurações
 Definir regras para atualizações de hardware e
software

Responsável
 Gerente
de configuração
97/113
Definir Ferramentas e
Equipamentos(continuação)

Entradas
 Documento
de requisitos
 Lista de riscos
 Estudo de viabilidade

Saídas
 Documento
de definição de ambiente
 Plano de gerência de configuração de software
98/113
Passos para Definir Ferramentas e
Equipamentos



Definir plataformas de desenvolvimento
Definir ferramentas
Definir equipamentos e suas configurações
99/113
Estruturar Ambiente
Solicitante
Gerente de
Configuração
e Ambiente
CCB
Submeter
solicitações de
mudanças
Definir
ferramentas e
equipamentos
Estruturar
ambiente
Analisar
solicitações de
mudanças
Planejar
gerência de
configuração
Implantar e
administrar
ambiente
100/113
Estruturar Ambiente(continuação)

Objetivos
 Determinar
a estrutura de diretórios que será
adotada para o projeto
 Definir os diferentes ambientes
(desenvolvimento, integração, testes, produção)
 Definir a política de uso do ambiente

Responsável
 Gerente
de configuração
101/113
Estruturar Ambiente(continuação)

Entradas
 Documento
de definição de ambiente
 Plano de gerência de configuração de software

Saídas
 Documento
de definição de ambiente
(atualizado)
 Plano de gerência de configuração de software
(atualizado)
102/113
Passos para Estruturar Ambiente


Definir estrutura de diretórios, repositórios e
áreas de backup
Definir política para utilização do ambiente
103/113
Planejar Gerência de Configuração
Solicitante
Gerente de
Configuração
e Ambiente
CCB
Submeter
solicitações de
mudanças
Definir
ferramentas e
equipamentos
Estruturar
ambiente
Analisar
solicitações de
mudanças
Planejar
gerência de
configuração
Implantar e
administrar
ambiente
104/113
Planejar Gerência de Configuração
(continuação)

Objetivos
Definir os papéis e responsabilidades dos membros da
equipe responsável pelas atividades de gerência de
configuração (GC)
 Definir os baselines que deverão ser estabelecidos
 Definir o cronograma das atividades de GC
 Definir as políticas, procedimentos e padrões que
guiarão essas atividades
 Identificar os itens de configuração


Responsável

Gerente de configuração
105/113
Planejar Gerência de Configuração
(continuação)

Entradas
 Plano

de gerência de configuração de software
Saídas
 Plano
de gerência de configuração de software
(atualizado)
106/113
Passos para Planejar Gerência de
Configuração







Definir organização, papéis e responsabilidades
Definir políticas e procedimentos para registro do status
da configuração
Definir esquema de nomeação para itens de
configuração
Identificar e registrar itens de configuração
Planejar auditorias
Definir baselines
Definir cronograma de gerência de configuração
107/113
Implantar e Administrar Ambiente
Solicitante
Gerente de
Configuração
e Ambiente
CCB
Submeter
solicitações de
mudanças
Definir
ferramentas e
equipamentos
Estruturar
ambiente
Analisar
solicitações de
mudanças
Planejar
gerência de
configuração
Implantar e
administrar
ambiente
108/113
Implantar e Administrar Ambiente
(continuação)

Objetivos
 Implantar
o ambiente com base na estrutura
definida na atividade anterior
 Gerenciar a utilização do ambiente de acordo
com as normas propostas (através de
auditorias)
 Avaliar e revisar o ambiente

Responsável
 Gerente
de configuração
109/113
Implantar e Administrar Ambiente
(continuação)

Entradas
 Documento
de definição de ambiente
 Plano de gerência de configuração de software

Saídas
 Documento
de definição de ambiente
(atualizado)
 Plano de gerência de configuração de software
(atualizado)
110/113
Passos para Implantar e
Administrar Ambiente



Instalar máquinas e criar diretórios
Disseminar política de utilização do ambiente
Gerenciar e avaliar ambiente
111/113
Conclusões


GC é um fluxo de apoio ao projeto como um
todo
Requer uma certa disciplina na manipulação de
itens de configuração e apoio de ferramentas
sempre que possível
112/113
Referências



Descrição do workflow de gerência de
configuração e mudanças do RUP
Configuration Management Today http://cmtoday.com
Software Release Methodology, M.E.Bays,
Prentice Hall, 1999.
113/113