1/113 Contexto para Gerência de Configuração. 2/113 Gerência de Configuração e mudança Objetivo Compreender a importância do uso de mecanismos de gerência

1/113

Contexto para Gerência de Contexto para Gerência de ConfiguraçãoConfiguração

2/113

Gerência de Configuração e Gerência de Configuração e mudançamudanç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.

3/113

Problema da Quebra de ComunicaçãoProblema da Quebra de ComunicaçãoDesenvolvedor A Desenvolvedor B

Desenvolvedor C

4/113

Problema da Quebra de Problema da Quebra de Comunicação (continuação)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

5/113

Problema dos Dados CompartilhadosProblema dos Dados Compartilhados

Componente

Compartilhado

Desenvolvedor A Desenvolvedor B

A1 A2 A3

Programa de A Programa de B

B1 B2 B3

6/113

Problema dos Dados Problema dos Dados Compartilhados - CenárioCompartilhados - 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

7/113

Problema dos Dados Problema dos Dados Compartilhados - Solução simplistaCompartilhados - 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

8/113

Problema da Manutenção MúltiplaProblema da Manutenção Múltipla

Componente

Compartilhado


A1 A2 A3 B1 B2 B3

Programa de A Programa de BComponente

Compartilhado

Versão de A do Componente

Compartilhado

Componente

Compartilhado

Componente

Compartilhado

Versão de B do Componente

Compartilhado

9/113

Problema da Manutenção Múltipla Problema da Manutenção Múltipla (continuação)(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...

10/113

Problema da Atualização SimultâneaProblema da Atualização Simultânea

Versão de A do Componente

Compartilhado


A1 A2 A3 B1 B2 B3

Programa de A Programa de BVersão de B do Componente

Compartilhado

Biblioteca Central de Recursos Compartilhados

Componente

Compartilhado

11/113

Problema da Atualização Problema da Atualização Simultânea – Cenário 1Simultâ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

12/113

Problema da Atualização Problema da Atualização Simultânea – Cenário 2Simultâ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

13/113

Como Resolver?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

14/113

O que é Gerência de Configuração?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

15/113

Objetivos de GCObjetivos 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

16/113

BenefíciosBenefí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

17/113

Conceitos BásicosConceitos Básicos

18/113

ConfiguraçãoConfiguraçã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

19/113

Item de ConfiguraçãoItem 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

20/113

Configuração de SoftwareConfiguração de Softwareitem

tempo

fluxo de desenvolvimento

21/113

BaselineBaseline

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

22/113

BaselineBaseline

item

tempo

fluxo de desenvolvimento

23/113

Razões para Criar um BaselineRazõ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

24/113

Baselines importantesBaselines importantes

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

25/113

RepositórioRepositó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

RepositórioDesenvolvedor

26/113

LockLock

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

27/113

Check-OutCheck-Out

Check-out

Repositóriocliente

28/113

Check-Out (continuação)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

29/113

Check-InCheck-In

Check-in

Repositóriocliente

30/113

Check-In (continuação)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

31/113

BuildBuild

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

32/113

Os Problemas na Geração de Os Problemas na Geração de BuildsBuilds 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

33/113

Os Problemas na Geração de Os Problemas na Geração de BuildsBuilds 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

34/113

Os Problemas na Geração de Os Problemas na Geração de BuildsBuilds 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

35/113

Geração de Buils através da Geração de Buils através da Integração ContínuaIntegraçã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

36/113

ReleaseRelease

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

37/113

Tipos de releaseTipos 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

38/113

TagsTags

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

39/113

Tags – Cenário 1Tags – Cenário 1

file2

raiz

subdir1

subdir2

file1

file3

file4

file5

file6

file7 file8 file9

tag1

tag2

40/113

Tags – Cenário 2Tags – Cenário 2

1.1 1.2 1.3 1.4

release_1

tagHistórico

de um arquivo

release_2

41/113

BranchBranch

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?

42/113

Branch (continuação)Branch (continuação)

Uso de lock inviabiliza a criação de branches Branches normalmente se originam de

correções em versões anteriores

43/113

Branch (exemplo)Branch (exemplo)

4

3

5 6

4

3.j.1 3.j.2 3.j.3

2.j.1 2.j.2

3.m.1 3.m.2 3.m.3

2.m.1

1hello.c 2 3

1hello.h 2

hello.c

hello.h

José

Mariahello.c

hello.h 2.m.2

•

•

44/113

MergeMerge

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

45/113

Merge (exemplo)Merge (exemplo)

3hello.c 4

2hello.h 3

5

4

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

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

Maria3.m.1hello.c 3.m.2 3.m.3

2.m.1hello.h 2.m.2

3.j.4

2.j.3

•

•

46/113

Branching e Merging: esquema Branching e Merging: esquema gráficográfico

1.1 1.2 1.3 1.4

release_2

1.2.2.21.2.2.1

rel_

1_fix

Tronco principal de

desenvolvimento

Branch

release_1

tag

patch

tag

Merge

47/113

Oportunidades criadas com GCOportunidades 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

48/113

Controle de MudançasControle de Mudanças

49/113

ContextoContexto

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

50/113

ProblemasProblemas

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

51/113

O que é Gerência de Mudanças?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

52/113

Objetivos da Gerência de MudançasObjetivos 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

53/113

BenefíciosBenefí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

54/113

Controle do caosControle do caos

Organização

Projeto

Controle de mudanças

Solicitação de mudança

55/113

Ciclo de vida de um artefatoCiclo de vida de um artefato

56/113

Ciclo de vida de um artefatoCiclo de vida de um artefato

Draft Aceito Manutenção

Concepção doartefato

Mudanças feitas de forma informal

Revisão/aceitação(baseline)

Mudanças via controle formal (CCB)

Mudanças em manutenção

Release retir

ado

57/113

Artefato DraftArtefato 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)

58/113

Artefato AceitoArtefato 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

59/113

Artefato em ManutençãoArtefato 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

60/113

Processo de Gerência de Processo de Gerência de MudançasMudanças

61/113

MotivaçãoMotivaçã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

62/113

Responsabilidades do CCBResponsabilidades 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

63/113

Características do CCBCaracterí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)

64/113

Análise de impactoAná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

65/113

Importância da análise de impactoImportâ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

Análise de impacto

intra-projeto

66/113

Sobre o Processo de Gerência de Sobre o Processo de Gerência de MudançasMudanç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

67/113

Solicitações de MudançaSolicitaçõ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)

68/113

Estrutura de um registro de Estrutura de um registro de solicitação de mudançasolicitaçã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.>

69/113

Estrutura de um registro de Estrutura de um registro de solicitação de mudançasolicitaçã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.>

70/113

Etapas do Processo de Gerência de Etapas do Processo de Gerência de Mudanças GenéricoMudanças Genérico

1. Requisição da mudança

2. Classificação da mudança

3. Avaliaçãoda mudança

4.Negociação sobre a realização da

mudança

5. Implementaçãoda mudança

6. Verificação da mudança

7. Promoção dos itens modificados

para um novo baseline

(mudança aceita)

CCB

71/113

Correções EmergenciaisCorreçõ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

72/113

Correções EmergenciaisCorreçõ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

73/113

Exemplos de Status dos DefeitosExemplos de Status dos DefeitosEstados Abertos Próximos Estados

NEW Bug inserido por alguém (automático)

Aceito ASSIGNED

Reatribuído NEW

Resolvido RESOLVED

ASSIGNED Atribuído à pessoa apropriada

Reatribuído NEW

Resolvido RESOLVED

REOPENED Reaberto: foi constatado que ainda não tinha sido resolvido

Aceito ASSIGNED

Reatribuído NEW

Resolvido RESOLVED

UNCONFIRMED Não confirmado que existe

Confirmado NEW

Resolvido RESOLVED

74/113

Exemplos de Status dos DefeitosExemplos de Status dos DefeitosEstados Fechados Próximos Estados

RESOLVED Foi resolvido (só está esperando a homologação)

Não foi resolvido REOPENED

Está ok VERIFIED

Está ok e pode ser fechado CLOSED

VERIFIED A correção foi homologada

Defeito é fechado CLOSED

CLOSED O bug é tido como resolvido

Não foi resolvido REOPENED

75/113

Release notesRelease notes

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

… …

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

76/113

DesafiosDesafios

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

77/113

Ferramentas de Apoio à Gerência Ferramentas de Apoio à Gerência de Configuraçãode Configuração

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

Automatizar o processo de geração de builds

Automatizar o processo de submissão e gestão de SMs

Ferramenta de Controle de Versões (CVS, por exemplo)

Ferramentas de Geração de Builds (Ant, por exemplo)

Ferramentas de Gestão de Solicitações de Mudanças (Bugzilla, por exemplo)

78/113

Gerência de Configuração no Gerência de Configuração no Desenvolvimento Iterativo - Desenvolvimento Iterativo - Relação com as Fases e Relação com as Fases e Disciplinas de Disciplinas de Desenvolvimento do RUPDesenvolvimento do RUP

79/113

Concepção Elaboração Construção Transição

IteraçãoPreliminar

Iter.#1

Iter.#2

Iter.#i

Iter.#i+1

Iter.#i+2

Iter.#n

Iter.#n+1

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

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

Implementação...............................

Testes.............................................

Implantação...................................

Planejamento e Gerenciamento.....

Fluxos de Atividades

Fluxos de Suporte

Fases

Iterações

Fases, iterações e disciplinasFases, iterações e disciplinas

Gerência de Configuração e Mudanças

80/113

Relação com as Fases de Relação com as Fases de Desenvolvimento e com as Outras Desenvolvimento e com as Outras DisciplinasDisciplinas 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

81/113

AAtividades, tividades, AArtefatos e rtefatos e RResponsabilidades da esponsabilidades da Disciplina Disciplina Gerência de Gerência de ConfiguraçãoConfiguração

82/113

Objetivos deste móduloObjetivos 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

83/113

Fluxo de AtividadesFluxo de Atividades

Gerente deConfiguraçãoe Ambiente

Definir ferramentas eequipamentos

Implantar e administrar ambiente

Estruturar ambiente

Planejar gerência de configuração

Solicitante Submeter solicitações de mudanças

CCB Analisar solicitações de mudanças

84/113

Objetivos do FluxoObjetivos 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

85/113

Responsáveis e ArtefatosResponsáveis e Artefatos

Gerente de Configuração

Plano de Gerência de Configuração

de Software

Documento de Definição de Ambiente

Registro de Solicitação de

Mudanças

Solicitante

Registro de Solicitação de

Mudanças

CCB

86/113

Gerente de ConfiguraçãoGerente 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

87/113

SolicitanteSolicitante

Qualquer pessoa que possa fazer uma solicitação de Mudanças

88/113

CCBCCB

Grupo Responsável por analisar e autorizar uma solicitação de mudanças

89/113

Artefato – Documento de Definição Artefato – Documento de Definição de Ambientede Ambiente

1. INTRODUÇÃO<Descreva os objetivos do documento>

2. INFRA-ESTRUTURA2.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 aquantidade de licenças disponíveis>

2.2. EQUIPAMENTOS<Descreva que equipamentos serão usadas durante o desenvolvimento do sistema, detalhando suasconfigurações>

3. ORGANIZAÇÃO FÍSICA<Forneça uma breve descrição da estrutura física do localonde o sistema será desenvolvido>

90/113


4. PADRÃO DE NOMENCLATURA DE ARTEFATOS<Descreva qual será a convenção utilizada para nomear osartefatos, em inglês ou português>

5. AMBIENTE LOCAL5.1. ESTRUTURA DE DIRETÓRIOS5.2. INFORMAÇÕES ADICIONAIS

6. AMBIENTE DE HOMOLOGAÇÃO E TESTES6.1. ESTRUTURA DE DIRETÓRIOS6.2. INFORMAÇÕES ADICIONAIS

7. AMBIENTE DE PRODUÇÃO7.1. ESTRUTURA DE DIRETÓRIOS7.2. INFORMAÇÕES ADICIONAIS

8. ARQUIVOS DE CONFIGURAÇÂO<Descreva os arquivos utilizados para configuração e uso dosistema>

91/113


9. PROMOÇÂO ENTRE AMBIENTES E BACKUPS<Defina a política para promoção dos artefatos entre osambientes e realização de backups>

9.1. AMBIENTE LOCAL AMBIENTE DE HOMOLOGAÇÃO E TESTES

<Descreva o procedimento que deve ser usado para transferirarquivos 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 atransferência de arquivos entre o ambiente de homologação etestes e o ambiente de produção>

10. POLÍTICA DE BACKUP<Descreva o procedimento que deve ser usado para realizaçãode backups em cada um dos ambientes>

11. AVALIAÇÃO E REVISÃO DO AMBIENTE<Descreva as modificações que serão necessárias no ambientepara o desenvolvimento do projeto>

12. REFERÊNCIAS

92/113

Artefato – Plano de Gerência de Artefato – Plano de Gerência de Configuração de SoftwareConfiguraçã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.>

93/113


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ção3.1.2. Nomeação dos itens de configuração3.1.3. Aquisição e armazenamento de itens de configuração3.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.>

94/113


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ção3.1.2. Mecanismos de coleta de informações3.1.3. Relatórios, seus conteúdos e frequências3.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 realizadas3.1.2. Procedimentos de auditoria

95/113


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

96/113

Definir Ferramentas e Definir Ferramentas e EquipamentosEquipamentos




Estruturar ambiente




97/113

Definir Ferramentas e Definir Ferramentas e Equipamentos(continuação)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

98/113

Definir Ferramentas e Definir Ferramentas e Equipamentos(continuação)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

99/113

Passos para Definir Ferramentas e Passos para Definir Ferramentas e EquipamentosEquipamentos Definir plataformas de desenvolvimento Definir ferramentas Definir equipamentos e suas configurações

100/113

Estruturar AmbienteEstruturar Ambiente




Estruturar ambiente




101/113

Estruturar Ambiente(continuação)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

102/113

Estruturar Ambiente(continuação)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)

103/113

Passos para Estruturar AmbientePassos para Estruturar Ambiente

Definir estrutura de diretórios, repositórios e áreas de backup

Definir política para utilização do ambiente

104/113

Planejar Gerência de ConfiguraçãoPlanejar Gerência de Configuração




Estruturar ambiente




105/113

Planejar Gerência de Configuração Planejar Gerência de Configuração (continuaçã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

106/113

Planejar Gerência de Configuração Planejar Gerência de Configuração (continuaçã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)

107/113

Passos para Planejar Gerência de Passos para Planejar Gerência de ConfiguraçãoConfiguraçã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

108/113

Implantar e Administrar AmbienteImplantar e Administrar Ambiente




Estruturar ambiente




109/113

Implantar e Administrar Ambiente Implantar e Administrar Ambiente (continuação)(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

110/113

Implantar e Administrar Ambiente Implantar e Administrar Ambiente (continuação)(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)

111/113

Passos para Passos para Implantar e Implantar e Administrar AmbienteAdministrar Ambiente Instalar máquinas e criar diretórios Disseminar política de utilização do ambiente Gerenciar e avaliar ambiente

112/113

ConclusõesConclusõ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

113/113

ReferênciasReferê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.

Documents

1/113 Contexto para Gerência de Configuração. 2/113 Gerência de Configuração e mudança Objetivo Compreender a importância do uso de mecanismos de gerência