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 Desenvolvedor B

Programa de A Componente Programa de B

A1 A2 A3 Compartilhado 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 Desenvolvedor B

Programa de A Componente Componente Programa de B

Compartilhado Compartilhado
A1 A2 A3 B1 B2 B3

Versão de A do Versão de B do
Componente Componente
Compartilhado 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 Versão de A do Versão de B do Programa de B

Componente Componente
A1 A2 A3 Compartilhado Compartilhado 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 file5

file7 file8 file9

tag2
39/113
Tags – Cenário 2

1.1 1.2 1.3 1.4

release_1 release_2
Histórico
de um tag
arquivo

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)
hello.c 3.m.1 3.m.2 3.m.3
Maria
hello.h 2.m.1 2.m.2

hello.c 1 2 3 • 4 5 6

hello.h 1 2 • 3 4

hello.c 3.j.1 3.j.2 3.j.3

José
hello.h 2.j.1 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
Maria
hello.h 2.m.1 2.m.2

hello.c 3 • 4 5

hello.h 2 • 3 4

hello.c 3.j.1 3.j.2 3.j.3 3.j.4

José
hello.h 2.j.1 2.j.2 2.j.3

45/113
Branching e Merging: esquema gráfico

Branch patch

x
_ fi
tag
1.2.2.1 1.2.2.2

_1
rel
1.1 1.2 1.3 1.4

release_1 release_2

Tronco principal
de Merge
tag
desenvolvimento

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

do
ira
Revisão/aceitação
Release

t
re
(baseline)

Draft Aceito Manutenção

Mudanças feitas Mudanças via Mudanças em

de forma informal controle formal manutenção
(CCB)

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
Aná
intr lise de
a-p
roje impac
to to
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

1. Requisição 4.Negociação sobre 6. Verificação

da mudança a realização da da mudança
mudança

(mudança aceita)
2. Classificação
da mudança
7. Promoção dos
itens modificados
para um novo
3. Avaliação 5. Implementação
baseline
da mudança da mudança

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 Aceito  ASSIGNED

alguém (automático) Reatribuído  NEW
Resolvido  RESOLVED
ASSIGNED Atribuído à pessoa Reatribuído  NEW
apropriada Resolvido  RESOLVED
REOPENED Reaberto: foi Aceito  ASSIGNED
constatado que Reatribuído  NEW
ainda não tinha sido
Resolvido  RESOLVED
resolvido

UNCONFIRMED Não confirmado que Confirmado  NEW

existe Resolvido  RESOLVED

73/113
Exemplos de Status dos Defeitos
Estados Fechados Próximos Estados

RESOLVED Foi resolvido (só Não foi resolvido  REOPENED

está esperando Está ok  VERIFIED
a homologação) Está ok e pode ser fechado 
CLOSED

VERIFIED A correção foi Defeito é fechado  CLOSED

homologada

CLOSED O bug é tido Não foi resolvido  REOPENED

como resolvido

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 Construção Transição

Requisitos.......................................

Análise e Projeto............................

Implementação...............................
Testes.............................................
Implantação...................................
Fluxos de Suporte
Planejamento e Gerenciamento.....
Iteração Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Gerência de Configuração e Mudanças Preliminar #1 #2 #i #i+1 #i+2 #n #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 Submeter CCB Analisar

solicitações de solicitações de
mudanças mudanças

Gerente de Definir Estruturar Planejar Implantar e

Configuração ferramentas e ambiente gerência de administrar
e Ambiente equipamentos configuração 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 Solicitante CCB
Configuração

Documento de Registro de Registro de

Definição de Solicitação de Solicitação de
Ambiente Mudanças 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
software.> 92/113
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 Submeter CCB Analisar

solicitações de solicitações de
mudanças mudanças

Gerente de Definir Estruturar Planejar Implantar e

Configuração ferramentas e ambiente gerência de administrar
e Ambiente equipamentos configuração 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 Submeter CCB Analisar

solicitações de solicitações de
mudanças mudanças

Gerente de Definir Estruturar Planejar Implantar e

Configuração ferramentas e ambiente gerência de administrar
e Ambiente equipamentos configuração 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 Submeter CCB Analisar

solicitações de solicitações de
mudanças mudanças

Gerente de Definir Estruturar Planejar Implantar e

Configuração ferramentas e ambiente gerência de administrar
e Ambiente equipamentos configuração 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 Submeter CCB Analisar

solicitações de solicitações de
mudanças mudanças

Gerente de Definir Estruturar Planejar Implantar e

Configuração ferramentas e ambiente gerência de administrar
e Ambiente equipamentos configuração 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