Este documento apresenta os principais conceitos e benefícios da Gerência de Configuração, incluindo problemas comuns no desenvolvimento de software que a GC pode ajudar a resolver, como quebra de comunicação entre equipes e atualização simultânea de componentes compartilhados. A GC é definida como o processo de identificar, organizar e controlar modificações ao software sendo construído.

1. Pós-graduação
MESW - Metodologia
para Engenharia de
Software
Disciplina: GC – Gerência de
Configuração
Pacote de Aulas: REC.MESW.GC.01
Professor: Camilo Almendra
1

2. Pacote:
REC.MESW.GC.01
Motivação e Fundamentos de
Gerência de Configuração
2

3. Motivação e Fundamentos
de Gerência de
Configuração
Professor: Camilo Almendra
Pacote: REC.MESW.GC.01
Tempo Previsto: 04 horas/aula
3

4. 1. Gerência de
Configuração de Software
Professor: Camilo Almendra
Aula: REC.MESW.GC.01.01
Tempo Previsto: 4h/aula
4

5. Objetivos deste módulo
• Fornecer os principais conceitos
relacionados a GC.
• Criar uma visão geral de como GC pode
ser aplicada ao seu projeto.
5

6. Tópicos
1. Introdução
2. Problemas comuns no
desenvolvimento de software
1. O que é Gerência de Configuração?
2. Para que serve?
3. Conceitos Básicos
4. Principais Atividades
5. Oportunidades criadas por GC
6. Conclusão
6

7. Problema da Quebra de
Comunicação
Desenvolvedor A Desenvolvedor B
Desenvolvedor C
7

8. Problema da Quebra de
Comunicação
(continuação)
1. Falhas de comunicação em equipes
2. Ocorre pelas mais diversas razões:
1. Vocabulários incompatíveis
2. Culturas de desenvolvimento diferentes
3. Distância geográfica
4. Dificuldade de expressão
3. Quando este problema acontece:
1. Os sistemas produzidos não atendem aos
requisitos
2. Força de trabalho é desperdiçada
8

9. Problema dos Dados
Compartilhados
Desenvolvedor A Desenvolvedor B
Programa de A Programa de B
Componente
A1 A2 A3 B1 B2 B3
Compartilhado
9

10. Problema dos Dados
Compartilhados
(continuação)
1. Cenário:
1. O desenvolvedor A modifica o componente
compartilhado
2. Mais tarde, o desenvolvedor B realiza
algumas alterações no mesmo
3. Ao tentar compilar o componente, erros
são apontados pelo compilador, mas
nenhum deles ocorre na parte que B
alterou
4. O desenvolvedor B não tem a menor idéia
sobre a causa do problema 10

11. Problema dos Dados
Compartilhados
(continuação)
1. Solução simplista:
1. cada desenvolvedor trabalha em
uma cópia “local” do componente
2. resolve o Problema dos Dados
Compartilhados, mas cria um novo
problema
11

12. Problema da Manutenção
Múltipla Desenvolvedor B
Desenvolvedor A
Programa de A Programa de B
Componente Componente
Compartilhado Compartilhado
A1 A2 A3 B1 B2 B3
Versão de A do Versão de B do
Componente Componente
Compartilhado Compartilhado
12

13. Problema da Manutenção
Múltipla (continuação)
1. Ocorre quando cada desenvolvedor trabalha
com uma cópia “local” do que seria o mesmo
componente
2. Dificuldade para saber:
1. Que funcionalidades foram implementadas em
quais versões do componente
2. Que defeitos foram corrigidos
3. Evitado através de uma biblioteca central de
componentes compartilhados
1. Nesse esquema, cada componente é copiado para
a biblioteca sempre que alterado
2. Resolve o Problema da Manutenção Múltipla, mas...
13

14. Problema da Atualização
Simultânea
Biblioteca Central de
Recursos Compartilhados
Desenvolvedor A Desenvolvedor B
Componente
Compartilhado
Programa de A Programa de B
Versão de A do Versão de B do
Componente Componente
A1 A2 A3 B1 B2 B3
Compartilhado Compartilhado
14

15. Problema da Atualização
Simultânea (continuação)
1. Primeiro cenário:
1. O desenvolvedor A encontra e corrige um
defeito em sua versão do componente
compartilhado
2. Uma vez corrigido, o componente
modificado é copiado para a biblioteca
central
3. 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 15
4. O trabalho de A é desperdiçado

16. Problema da Atualização
Simultânea (continuação)
1. Segundo cenário:
1. O desenvolvedor A encontra e corrige um defeito
em sua versão do componente compartilhado
2. Uma vez corrigido, o componente modificado é
copiado para a biblioteca central
3. O desenvolvedor B encontra e corrige um outro
defeito em sua versão do componente, sem saber
do defeito corrigido por A
4. O desenvolvedor B copia sua versão do
componente para a biblioteca central
5. 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
16
6. O desenvolvedor A julga o problema como
resolvido

17. Como Resolver ?
1. O problema da atualização
simultânea não pode ser
resolvido simplesmente copiando
componentes compartilhados
para uma biblioteca central
2. Algum mecanismo de controle é
necessário para gerenciar a
entrada e saída dos componentes
17

18. Sobre Gerência de
Configuração
1. “Em qualquer time, um certo grau de
confusão é inevitável. O objetivo é
minimizar a confusão de modo que
mais trabalho possa ser feito.”
2. “A arte de coordenar o
desenvolvimento de software para
minimizar esse tipo particular de
confusão é chamada de Gerência de
Configuração.”
W.A. Babich, Software Configuration 18
Management. Addison-Wesley, 1986.

19. O que é Gerência de
Configuração?
1. Gerência de configuração (GC) é
o processo de identificar,
organizar e controlar
modificações ao software sendo
construído
2. A idéia é maximizar a
produtividade minimizando os
enganos
19

20. Importância da GC em
Software
1. Produtos, projetos e equipes de
desenvolvimento de software são
complexos
2. Alta demanda por software:
novos sistemas, manutenção e
modificação de sistemas
existentes
20

21. Objetivos de GC
1. Definir o ambiente de
desenvolvimento
2. Políticas para controle de versões
garantindo a consistência dos
artefatos produzidos
3. Definir procedimentos para
solicitações de mudanças
4. Administrar o ambiente e auditar
mudanças
21
5. Facilitar a integração das partes do

22. Benefícios gerais
1. Aumento de produtividade no
desenvolvimento
2. Menores custos de manutenção
3. Redução de defeitos
4. Maior rapidez na identificação e
correção de problemas
22

23. Lista de benefícios
1. Improved 1. Improved security
organizational 2. Higher software reuse
competitiveness 3. Lower maintenance
2. Better customer costs
service and improved 4. Better quality
customer goodwill assurance
3. Better return on 5. Reduction of defects
investment and bugs
4. Improved management 6. Faster problem
control over software identification and bug
development activities fixes
5. Improved software 7. Process-dependent
development development rather
productivity than person-dependent
6. Easier handling of 23
development
software complexity 8. Assurance that the

24. O que GC não é... ou pelo
menos não deveria ser!
1. Difícil, monótona e demorada
2. Apenas para desenvolvedores
3. Apenas para time de GC
4. Apenas para ser usado na fase de
produção e manutenção do sistema
5. Apenas para código-fonte
6. Apenas para conseguir
reconhecimentos ou certificados
(CMMI, ISO, etc) 24

25. Configuração
1. Um projeto de desenvolvimento de
software produz os seguintes itens:
1. Programas (código fonte, programas
executáveis, bibliotecas de componentes,
etc.)
2. Documentação (manuais do usuário,
documento de requisitos, modelo de
análise e projeto, etc.)
3. Dados (dados de teste e do projeto)
2. Esses conjuntos de itens são
chamados, coletivamente, de
25

26. Item de Configuração
1. Um conjunto de itens de hardware
e/ou software vistos como uma
entidade única para fins de gerência
de configuração
2. Um item de configuração está sujeito
a mudanças e essas devem obedecer
às políticas estabelecidas
3. Normalmente, um item de
configuração é estabelecido para cada
pedaço de software que pode ser
projetado, implementado e testado de 26
forma independente

27. Baseline
1. Uma especificação ou produto que foi
formalmente revisado e aceito
1. Serve como base para os passos
posteriores do desenvolvimento
2. A configuração do software em um
ponto discreto no tempo
3. Só pode ser modificado através de
procedimentos formais (solicitações de
mudança)
4. Um artefato ou conjunto de artefatos
só se torna um item de configuração 27
depois que um baseline é estabelecido

28. 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
28

29. Baselines importantes
1. Baselines são considerados
marcos no processo de
desenvolvimento:
1. Funcional : requisitos
2. De Produto : releases, iterações
29

30. Repositório
1. Local (físico e lógico) onde os itens de
um sistema são guardados
2. Pode conter diversas versões do
sistema
3. Utiliza mecanismos de controle de
acesso
Repositório
Desenvolvedor
30

31. Lock
1. Resolve a Atualização Simultânea
2. Garante que apenas o usuário
que detém o lock pode alterar o
arquivo
3. Problema: “serializa” o trabalho
dos desenvolvedores
31

32. Check-Out
Check-out
cliente Repositório
32

33. Check-Out (continuação)
1. Recuperar a (última) versão de um
item de configuração guardada no
repositório
1. Escrita
1. Verifica que ninguém detém o lock do item de
configuração
2. Obtém o lock do item
3. Cria uma cópia, para edição, no cliente
2. Leitura
1. Verifica que alguém já detém o lock
2. Cria uma cópia, apenas para leitura, no cliente 33

34. Check-In
Check-in
cliente Repositório
34

35. Check-In (continuação)
1. Ação de inserir/atualizar um item
de configuração no repositório
1. Verifica o lock do item de
configuração, caso o mesmo já
exista
2. Verifica e incrementa a versão do
item
3. Registra informações das mudanças
(autor, data, hora, comentários) 35
4. Inclui/atualiza o item

36. Tags
1. Rótulos que são associados a
conjuntos de arquivos
2. Um tag referencia um ou mais
arquivos em um ou mais diretórios
1. Costuma-se usar tags para:
1. Denominar projeto rotulando todos os arquivos
associados ao projeto
2. Denominar uma da versão do projeto (um build
ou release) rotulando todos os arquivos
associados ao build ou release
36

37. Tags (continuação)
1. Cenário:
1.4
1.2 1.3
1.1
release_1 release_2
Histórico
de um tag
arquivo
6. Outro cenário:
37

38. Branch
1. Criação de um fluxo alternativo para
atualização de versões de itens de
configuração
2. Recurso muito poderoso
3. Regras bem definidas para criação de
branches
1. Por que e quando devem ser criados
2. Quais os passos
3. Quando retornar ao fluxo principal
38

39. Branch (continuação)
1. Uso de lock inviabiliza a criação
de branches
2. Branches normalmente se
originam de correções em
versões anteriores
39

40. Branch (exemplo)
3.m.1 3.m.3
hello.c 3.m.2
Maria
2.m.1 2.m.2
hello.h
1 2 3• 4 5 6
hello.c
1 2 •3 4
hello.h
3.j.1 3.j.2 3.j.3
hello.c
José
2.j.1 2.j.2
hello.h
40

41. Merge
1. Unificação de diferentes versões de
um mesmo item de configuração
2. Integração de itens de configuração de
um branch com os itens de
configuração do fluxo principal
3. Check-out atualizando a área local
4. Algumas ferramentas fornecem um
mecanismo automático para
realização de merges
1. Mesmo com o uso de ferramentas, em
vários casos há necessidade de intervenção
humana 41

42. Merge (exemplo)
3.m.1 3.m.3
3.m.2
hello.c
Maria
hello.h 2.m.1 2.m.2
3 4 5
hello.c •
2 3 4
hello.h •
3.j.1 3.j.2 3.j.3
hello.c 3.j.4
José
2.j.1 2.j.2
hello.h 2.j.3
42

43. Branching e Merging
• Esquema gráfico: Branch
patch
tag
x
_fi
1.2.2.1 1.2.2.2
_1
rel
1.1 1.2 1.3 1.4
release_2
release_1
Merge
tag
Tronco principal
de
desenvolvimento
43

44. Build
1. Representa uma versão ainda
incompleta do sistema em
desenvolvimento, mas com certa
estabilidade
2. Costumam apresentar limitações
conhecidas
3. Espaço para integração de
funcionalidades
44

45. Build (continuação)
• Incluem 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
• A geração de builds deve
ser automatizada e
realizada com freqüência
adequada
45

46. Release
1. Versão do sistema validada após
os diversos tipos de teste
2. Produto de software
3. Supostamente sem erros
4. Entregue ao cliente ou ao
mercado
5. Processo iterativo/incremental
produz, em geral, mais de um 46
release

47. Release
1. Implantado no cliente
2. Deve ser devidamente mantido
1. Enquanto a linha principal evolui
2. Uso de branches e merges
47

48. Oportunidades criadas
com GC
1. Reuso de itens de software
1. Artefatos
2. Componentes
2. Automação de processo
1. Construção de builds
2. Geração de releases
3. Testes
4. Integração
48

49. Conclusões
1. GC é um fluxo de apoio ao projeto
como um todo
2. Passos iniciais para a adoção de
um processo de software
3. Requer uma certa disciplina na
manipulação de itens de
configuração
4. Apoio de ferramentas sempre que
possível 49

50. Atividade
1. Gerência de configuração dos
projetos das equipes:
1. Listar problemas, identificar
soluções
2. Em relação a natureza do projeto
da equipe, escolher 4 principais
benefícios que a GC pode trazer
(ver lista slide 23)
50

51. Bibliografia
1. Software Configuration
Management Handbook, Second
Edition (Hardcover). Alexis Leon.
51