View
110
Download
0
Category
Preview:
Citation preview
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
Desenvolvedor A Desenvolvedor B
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
Desenvolvedor A Desenvolvedor B
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
Artefato – Documento de Definição Artefato – Documento de Definição de Ambientede Ambiente
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
Artefato – Documento de Definição Artefato – Documento de Definição de Ambientede Ambiente
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
Artefato – Plano de Gerência de Artefato – Plano de Gerência de Configuração de SoftwareConfiguraçã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çã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
Artefato – Plano de Gerência de Artefato – Plano de Gerência de Configuração de SoftwareConfiguraçã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çã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
Artefato – Plano de Gerência de Artefato – Plano de Gerência de Configuração de SoftwareConfiguraçã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.>
96/113
Definir Ferramentas e Definir Ferramentas e EquipamentosEquipamentos
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
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
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
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
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
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
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
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.
Recommended