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.

Apresentação em tema: "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."— Transcrição da apresentação:

1 1/113 Contexto para Gerência de Configuração

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

3 3/113 Problema da Quebra de Comunicação Desenvolvedor ADesenvolvedor B Desenvolvedor C

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

5 5/113 Problema dos Dados Compartilhados Componente Compartilhado Desenvolvedor ADesenvolvedor B A1A2A3 Programa de A Programa de B B1B2B3

6 6/113 Problema dos Dados Compartilhados - Cenário n O desenvolvedor A modifica o componente compartilhado n Mais tarde, o desenvolvedor B realiza algumas alterações no mesmo n Ao tentar compilar o componente, erros são apontados pelo compilador, mas nenhum deles ocorre na parte que B alterou n O desenvolvedor B não tem a menor idéia sobre a causa do problema

7 7/113 Problema dos Dados Compartilhados - Solução simplista n Solução simplista: u cada desenvolvedor trabalha em uma cópia “local” do componente u resolve o Problema dos Dados Compartilhados, mas cria um novo problema

8 8/113 Problema da Manutenção Múltipla Componente Compartilhado Desenvolvedor ADesenvolvedor B A1A2A3B1B2B3 Programa de A Programa de B Componente Compartilhado Versão de A do Componente Compartilhado Componente Compartilhado Componente Compartilhado Versão de B do Componente Compartilhado

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

10 10/113 Problema da Atualização Simultânea Versão de A do Componente Compartilhado Desenvolvedor ADesenvolvedor B A1A2A3B1B2B3 Programa de A Programa de B Versão de B do Componente Compartilhado Biblioteca Central de Recursos Compartilhados Componente Compartilhado

11 11/113 Problema da Atualização Simultânea – Cenário 1 n O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado n Uma vez corrigido, o componente modificado é copiado para a biblioteca central n 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 n O trabalho de A é desperdiçado

12 12/113 Problema da Atualização Simultânea – Cenário 2 n O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado n Uma vez corrigido, o componente modificado é copiado para a biblioteca central n O desenvolvedor B encontra e corrige um outro defeito em sua versão do componente, sem saber do defeito corrigido por A n O desenvolvedor B copia sua versão do componente para a biblioteca central n 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 n O desenvolvedor A julga o problema como resolvido

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

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

15 15/113 Objetivos de GC n Definir o ambiente de desenvolvimento n Definir políticas para controle de versões, garantindo a consistência dos artefatos produzidos n Definir procedimentos para solicitações de mudanças n Administrar o ambiente e auditar mudanças n Facilitar a integração das partes do sistema

16 16/113 Benefícios n Aumento de produtividade no desenvolvimento n Menores Custos de Manutenção n Redução de defeitos n Maior rapidez na identificação e correção de problemas

17 17/113 Conceitos Básicos

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

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

20 20/113 Configuração de Software item tempo fluxo de desenvolvimento

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

22 22/113 Baseline item tempo fluxo de desenvolvimento

23 23/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

24 24/113 Baselines importantes n Baselines são considerados marcos no processo de desenvolvimento: u Funcional : requisitos u De Produto : releases, iterações

25 25/113 Repositório n Local (físico e lógico) onde os itens de um sistema são guardados n Pode conter diversas versões do sistema n Utiliza mecanismos de controle de acesso Repositório Desenvolvedor

26 26/113 Lock n Resolve a Atualização Simultânea n Garante que apenas o usuário que detém o lock pode alterar o arquivo n Problema: “serializa” o trabalho dos desenvolvedores

27 27/113 Check-Out Check-out Repositóriocliente

28 28/113 Check-Out (continuação) n Recupera a (última) versão de um item de configuração guardada no repositório u Escrita F Verifica que ninguém detém o lock do item de configuração F Obtém o lock do item F Cria uma cópia, para edição, no cliente u Leitura F Verifica que alguém já detém o lock F Cria uma cópia, apenas para leitura, no cliente

29 29/113 Check-In Check-in Repositóriocliente

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

31 31/113 Build n Representa uma versão ainda incompleta do sistema em desenvolvimento, mas com certa estabilidade n Costuma apresentar limitações conhecidas n Espaço para integração de funcionalidades n Inclue não só código fonte, mas documentação, arquivos de configuração, base de dados, etc. n A política de geração dos builds deve ser bem definida na estruturação do ambiente

32 32/113 Os Problemas na Geração de Builds n Fazer os builds do sistema manualmente é muito demorado n Pode ser difícil saber qual a versão “correta” de um arquivo n Os pedaços do sistema podem estar em diversos locais diferentes u Alguns arquivos podem ser esquecidos

33 33/113 Os Problemas na Geração de Builds n A integração das partes de um sistema em desenvolvimento normalmente é: u Realizada poucas vezes, apenas perto de sua implantação u Feita em freqüência inversamente proporcional à complexidade do sistema n Integrar as partes de um sistema é uma tarefa trabalhosa e sujeita a erros u Quanto maior o sistema, mais difícil

34 34/113 Os Problemas na Geração de Builds n Consequência: problemas de integração tornam-se difíceis de detectar cedo no desenvolvimento u Costumam ser encontrados muito depois de sua introdução u É muito difícil rastrear suas causas

35 35/113 Geração de Buils através da Integração Contínua n Geração freqüente (pelo menos diária) de builds do sistema u As partes do sistema são integradas constantemente u Problemas de integração passam a ser encontrados logo que introduzidos, na maioria dos casos n Considerada uma das “melhores práticas” no desenvolvimento de software n A geração de builds deve ser automatizada e realizada com freqüência adequada

36 36/113 Release n Identificação e empacotamento de artefatos entregues ao cliente (interno ou externo) ou ao mercado n Um release implica no estabelecimento de um novo baseline, de produto n Produto de software supostamente sem erros u Versão do sistema validada após os diversos tipos de teste u Garantia de que todos os itens de configuração foram devidamente testados, avalidos, aceitos e estão disponíveis no novo baseline n Processo iterativo/incremental produz, em geral, mais de um release

37 37/113 Tipos de release n Normalmente, releases estão associados aos milestones do plano de projeto n Internos u 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 n Externos u Implantado e utilizado pelo cliente

38 38/113 Tags n Rótulos que são associados a conjuntos de arquivos n Um tag referencia um ou mais arquivos em um ou mais diretórios u Costuma-se usar tags para: F Denominar projeto rotulando todos os arquivos associados ao projeto F Denominar uma versão do projeto (um build ou release) rotulando todos os arquivos associados ao build ou release

39 39/113 Tags – Cenário 1 file2 raiz subdir1 subdir2 file1 file3 file4 file5 file6 file7file8file9 tag1 tag2

40 40/113 Tags – Cenário 2 1.1 1.21.31.4 release_1 tag Histórico de um arquivo release_2

41 41/113 Branch n Criação de um fluxo alternativo para atualização de versões de itens de configuração n Recurso muito poderoso n Devem existir regras bem definidas para criação de branches u Por que e quando devem ser criados? u Quais os passos? u Quando retornar ao fluxo principal?

42 42/113 Branch (continuação) n Uso de lock inviabiliza a criação de branches n Branches normalmente se originam de correções em versões anteriores

43 43/113 Branch (exemplo) 4 3 56 4 3.j.13.j.23.j.3 2.j.12.j.2 3.m.1 3.m.2 3.m.3 2.m.1 1 hello.c 23 1 hello.h 2 hello.c hello.h José Maria hello.c hello.h 2.m.2

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

45 45/113 Merge (exemplo) 3 hello.c 4 2 hello.h 3 5 4 3.j.1 hello.c 3.j.23.j.3 2.j.1 hello.h 2.j.2 José Maria 3.m.1 hello.c 3.m.2 3.m.3 2.m.1 hello.h 2.m.2 3.j.4 2.j.3

46 46/113 Branching e Merging: esquema gráfico 1.11.2 1.3 1.4 release_2 1.2.2.2 1.2.2.1 rel_1_fix Tronco principal de desenvolvimento Branch release_1 tag patch tag Merge

47 47/113 Oportunidades criadas com GC n Reuso de itens de software u Artefatos u Componentes n Automação de processo u Construção de builds u Geração de releases u Testes u Integração n Aumento da produtividade das equipes n Redução de re-trabalho n Melhoria do acompanhamento do projeto

48 48/113 Controle de Mudanças

49 49/113 Contexto n Desenvolvimento iterativo/incremental n Novos conjuntos de requisitos, detalhados a cada iteração n Mudanças em estratégias de negócio motivadas pelas mais diversas fontes: mercado, cultura, leis, etc

50 50/113 Problemas n Controle do escopo do projeto u Modificações podem ampliar o leque de funcionalidades e aumentar significativamente o custo do projeto u Atrasos em entregas planejadas n Controle de consistência dos artefatos u Uma mudança aparentemente localizada pode causar muito mais impacto do que o previsto u Degradação da qualidade do software (ex: abandono dos testes automatizados devido à inconsistência dos dados de teste) u Retrabalho

51 51/113 O que é Gerência de Mudanças? n 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) n Mudanças aprovadas são implementadas nos itens de configuração e nos dados e documentos relacionados

52 52/113 Objetivos da Gerência de Mudanças n Garantir que os artefatos do sistema alcançam e mantêm uma estrutura definida através do seu ciclo de vida n Definir procedimentos e documentação necessários para realizar modificações a ICs n Prover os mecanismos necessários para conduzir mudanças de uma maneira controlada

53 53/113 Benefícios n Controle sobre o escopo do projeto n Mais produtividade u cada solicitação será tratada de forma coordenada u Redução dos problemas de comunicação entre membros da equipe n Mais qualidade, uma vez que cada mudança, antes de ser realizada, tem seu impacto avaliado n Geração de dados para o acompanhamento (tracking) do projeto

54 54/113 Controle do caos Organização Projeto Controle de mudanças Solicitação de mudança

55 55/113 Ciclo de vida de um artefato

56 56/113 Ciclo de vida de um artefato DraftAceitoManutenção Concepção do artefato Mudanças feitas de forma informal Revisão/aceitação (baseline) Mudanças via controle formal (CCB) Mudanças em manutenção Release retirado

57 57/113 Artefato Draft n Mudanças freqüentes e rápidas n Demanda por agilidade n Controle formal dificulta a criação do artefato n Artefatos apenas gerenciados e controlados u Uso de controle de versão (CVS, Clear Case, entre outras ferramentas)

58 58/113 Artefato Aceito n Artefato seguiu um processo de revisão, testes (se aplicável) e aceitação n Inserido dentro do processo de controle de mudanças, tornando-se de fato item de configuração n Mudanças via solicitação formal n Presença do grupo gestor de mudanças (CCB) para avaliar e priorizar mudanças

59 59/113 Artefato em Manutenção n Após a entrega de uma versão do produto, os artefatos passam para a fase de manutenção n Controle de mudanças permanece formal para os artefatos de um baseline n Novas artefatos podem ser desenvolvidos usando o mesmo modelo de ciclo de vida n Sistema pode ser descontinuado ou removido do ambiente de produção

60 60/113 Processo de Gerência de Mudanças

61 61/113 Motivação n Mudança é inevitável n Mudar é fácil – controlar diversas mudanças simultâneas é difícil n A gerência de mudanças introduz controle sobre as mudanças de maior relevância u Todas as mudanças são analisadas u Apenas as aprovadas são realizadas u Sempre se sabe quem modificou o que, onde e quando

62 62/113 Responsabilidades do CCB n Analisar as solicitações de mudança n Controlar o escopo do projeto n Reuniões com freqüência adequada ao ritmo das solicitações de mudança n Envolver stakeholders no processo de priorização no processo de decisão n Balanço entre o nível de controle desejado e overhead suportado u Questões menores devem ser resolvidas pelo líder do projeto junto à equipe, reduzindo o overhead do CCB

63 63/113 Características do CCB n Composição multidisciplinar u SQA, gerente, cliente, arquiteto n Profissionais com grande capacidade de comunicação e negociação n Pode apresentar uma estrutura hierarquica dependendo do tamanho e da quantidade de stakeholders e sistemas envolvidos (integrações)

64 64/113 Análise de impacto n Mudanças de grande impacto devem ser comunicadas aos stakeholders envolvidos n Análises de custo x benefício produzidas pelos stakeholders n Priorização de mudanças n Mudança pode ser rejeitada se o CCB perceber que o custo será mais caro que o benefício percebido n Por questões de eficiência, algumas solicitações de mudança podem ser agrupadas por tema, subsistema ou área de negócio

65 65/113 Importância da análise de impacto n Dentro do projeto n Análises inter-sistemas também devem ser consideradas u Exemplo: frameworks, componentes ou bancos de dados compartilhados Requisitos A&P Componentes Análise de impacto intra-projeto

66 66/113 Sobre o Processo de Gerência de Mudanças n Deve ser definido um documento padrão para que mudanças possam ser solicitadas n Esse documento normalmente se chama Solicitação de Mudança (SM, Em inglês CR) n A um conjunto de pessoas (CCB), deve ser dada a autoridade para decidir se uma mudança será ou não implementada n O processo é necessário para garantir que apenas mudanças avaliadas e aprovadas são realizadas em ICs

67 67/113 Solicitações de Mudança n Algumas informações que podem estar incluídas em uma SM: u Identificação única u Solicitante u Sistema/Projeto u Item a ser modificado u Classificação (melhoria, correção de defeito, outra) u Prioridade u Descrição u Situação (nova, atribuída, finalizada, verificada, fechada)

68 68/113 Estrutura de um registro de solicitação de mudança 1. IDENTIFICADOR DA SOLICITA Ç ÃO 2. IDENTIFICA Ç ÃO DO SOLICITANTE 3. SISTEMA DESENVOLVIDO 3.1. NOME DO SISTEMA 3.2. NOME DO M Ó DULO 3.3. NOME DA FUNCIONALIDADE

69 69/113 Estrutura de um registro de solicitação de mudança 4. CLASSIFICA Ç ÃO 5. DESCRI Ç ÃO 6. STATUS 7. OBSERVA Ç ÕES GERAIS

70 70/113 Etapas do Processo de Gerência de Mudanças Genérico 1. Requisição da mudança 2. Classificação da mudança 3. Avaliação da mudança 4.Negociação sobre a realização da mudança 5. Implementação da mudança 6. Verificação da mudança 7. Promoção dos itens modificados para um novo baseline (mudança aceita) CCB

71 71/113 Correções Emergenciais n Em algumas situações, não há tempo para seguir os procedimentos padrão para a realização de mudanças n Defeitos não são normalmente processados pelo CCB, salvo se envolverem algum questionamento relativo ao escopo do projeto n Mesmo nessas situações, porém, é muito importante que seja criada uma solicitação de mudança n O objetivo é garantir um mínimo de ordem, mesmo em uma situação caótica

72 72/113 Correções Emergenciais n Mudanças realizadas nessas circunstâncias podem comprometer a arquitetura ou inserir bugs n Decisão: u Desfazer correção ou u Transformar a correção: refactoring, acréscimo de novos casos de teste

73 73/113 Exemplos de Status dos Defeitos Estados Abertos Próximos Estados NEWBug inserido por alguém (automático) Aceito  ASSIGNED Reatribuído  NEW Resolvido  RESOLVED ASSIGNEDAtribuído à pessoa apropriada Reatribuído  NEW Resolvido  RESOLVED REOPENEDReaberto: foi constatado que ainda não tinha sido resolvido Aceito  ASSIGNED Reatribuído  NEW Resolvido  RESOLVED UNCONFIRMEDNão confirmado que existe Confirmado  NEW Resolvido  RESOLVED

74 74/113 Exemplos de Status dos Defeitos Estados Fechados Próximos Estados RESOLVEDFoi resolvido (só está esperando a homologação) Não foi resolvido  REOPENED Está ok  VERIFIED Está ok e pode ser fechado  CLOSED VERIFIEDA correção foi homologada Defeito é fechado  CLOSED CLOSEDO bug é tido como resolvido Não foi resolvido  REOPENED

75 75/113 Release notes IdDescrição 1Problema de performance na validação de pedido 2Nova rotina de validação de crédito conforme normas de dezembro de 2002 …… n Relação de solicitações de mudanças implementadas e testadas n Pode ser parcialmente automatizado n Comentários adicionais u Limitações atuais, problemas não resolvidos

76 76/113 Desafios n Cultura organizacional u Agrupamento de solicitações em releases bem definidos e estabelecidos deve ser negociado com os stakeholders do projeto u Releases internos utilizados de forma efetiva como ferramenta de gestão de projeto n Integração entre sistemas de controle de versão e mudanças

77 77/113 Ferramentas de Apoio à Gerência de Configuração n Manter todos os arquivos em um repositório central n Controlar o acesso a esse repositório, de modo a garantir a consistência dos artefatos n Automatizar o processo de geração de builds n 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 78/113 Gerência de Configuração no Desenvolvimento Iterativo - Relação com as Fases e Disciplinas de Desenvolvimento do RUP

79 79/113 Concepção ElaboraçãoConstruçãoTransição Iteração Preliminar 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 disciplinas Gerência de Configuração e Mudanças

80 80/113 Relação com as Fases de Desenvolvimento e com as Outras Disciplinas n Tem uma maior concentração na fase de concepção n Nas iterações das fases seguintes, o nível de esforço é mantido constante n Acontece em paralelo e com uma forte integração com a disciplina de planejamento e gerenciamento n Algumas atividades relacionadas com a gerência da configuração ocorrem em outras disciplinas como a implementação e a implantação

81 81/113 Atividades, Artefatos e Responsabilidades da Disciplina Gerência de Configuração

82 82/113 Objetivos deste módulo n Apresentar atividades da Disciplina de Gerrência de Configuração n Discutir os artefatos e responsáveis envolvidos na realização das atividades da disciplina

83 83/113 Fluxo de Atividades Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração SolicitanteSubmeter solicitações de mudanças CCB Analisar solicitações de mudanças

84 84/113 Objetivos do Fluxo n Definir u Recursos de hardware e software u Política de atualização destes recursos u Estruturação de diretórios e repositórios u Plataforma de desenvolvimento u Política de utilização do ambiente u As atividades de Gerência de Configuração que deverão ser realizadas e em que momentos do desenvolvimento

85 85/113 Responsá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 86/113 Gerente de Configuração n Responsável pela definição dos equipamentos e softwares utilizados e suas configurações n Define o ambiente, regras de uso do mesmo e política de mudanças n Define os papéis dos membros da equipe responsáveis pelas atividades de gerência de configuração n Estabelece as atividades de gerência de configuração que serão realizadas

87 87/113 Solicitante n Qualquer pessoa que possa fazer uma solicitação de Mudanças

88 88/113 CCB n Grupo Responsável por analisar e autorizar uma solicitação de mudanças

89 89/113 Artefato – Documento de Definição de Ambiente 1. INTRODUÇÃO 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>

90 90/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>

91 91/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

92 92/113 Artefato – Plano de Gerência de Configuração de Software 1. INTRODUÇÃO 2. GERENCIAMENTO DA GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE 2.1. ORGANIZAÇÃO 2.2. RESPONSABILIDADES 2.3. RELAÇÃO COM AS FASES DO DESENVOLVIMENTO E OUTROS FLUXOS DE ATIVIDADES

93 93/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 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

94 94/113 Artefato – Plano de Gerência de Configuração de Software 3.3. REGISTRO DO STATUS DA CONFIGURAÇÃO 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 3.1.1. Auditorias que devem ser realizadas 3.1.2. Procedimentos de auditoria

95 95/113 Artefato – Plano de Gerência de Configuração de Software 4. AGENDA DA GERÊNCIA DE CONFIGURAÇÃO 5. RECURSOS DE GERÊNCIA DE CONFIGURAÇÃO 6. MANUTENÇÃO DO PLANO DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE

96 96/113 Definir Ferramentas e Equipamentos Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração SolicitanteSubmeter solicitações de mudanças CCB Analisar solicitações de mudanças

97 97/113 Definir Ferramentas e Equipamentos(continuação) n Objetivos u Definir ferramentas de suporte ao desenvolvimento, controle de versões e softwares em geral u Definir hardwares e suas configurações u Definir regras para atualizações de hardware e software n Responsável u Gerente de configuração

98 98/113 Definir Ferramentas e Equipamentos(continuação) n Entradas u Documento de requisitos u Lista de riscos u Estudo de viabilidade n Saídas u Documento de definição de ambiente u Plano de gerência de configuração de software

99 99/113 Passos para Definir Ferramentas e Equipamentos n Definir plataformas de desenvolvimento n Definir ferramentas n Definir equipamentos e suas configurações

100 100/113 Estruturar Ambiente Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração SolicitanteSubmeter solicitações de mudanças CCB Analisar solicitações de mudanças

101 101/113 Estruturar Ambiente(continuação) n Objetivos u Determinar a estrutura de diretórios que será adotada para o projeto u Definir os diferentes ambientes (desenvolvimento, integração, testes, produção) u Definir a política de uso do ambiente n Responsável u Gerente de configuração

102 102/113 Estruturar Ambiente(continuação) n Entradas u Documento de definição de ambiente u Plano de gerência de configuração de software n Saídas u Documento de definição de ambiente (atualizado) u Plano de gerência de configuração de software (atualizado)

103 103/113 Passos para Estruturar Ambiente n Definir estrutura de diretórios, repositórios e áreas de backup n Definir política para utilização do ambiente

104 104/113 Planejar Gerência de Configuração Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração SolicitanteSubmeter solicitações de mudanças CCB Analisar solicitações de mudanças

105 105/113 Planejar Gerência de Configuração (continuação) n Objetivos u Definir os papéis e responsabilidades dos membros da equipe responsável pelas atividades de gerência de configuração (GC) u Definir os baselines que deverão ser estabelecidos u Definir o cronograma das atividades de GC u Definir as políticas, procedimentos e padrões que guiarão essas atividades u Identificar os itens de configuração n Responsável u Gerente de configuração

106 106/113 Planejar Gerência de Configuração (continuação) n Entradas u Plano de gerência de configuração de software n Saídas u Plano de gerência de configuração de software (atualizado)

107 107/113 Passos para Planejar Gerência de Configuração n Definir organização, papéis e responsabilidades n Definir políticas e procedimentos para registro do status da configuração n Definir esquema de nomeação para itens de configuração n Identificar e registrar itens de configuração n Planejar auditorias n Definir baselines n Definir cronograma de gerência de configuração

108 108/113 Implantar e Administrar Ambiente Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração SolicitanteSubmeter solicitações de mudanças CCB Analisar solicitações de mudanças

109 109/113 Implantar e Administrar Ambiente (continuação) n Objetivos u Implantar o ambiente com base na estrutura definida na atividade anterior u Gerenciar a utilização do ambiente de acordo com as normas propostas (através de auditorias) u Avaliar e revisar o ambiente n Responsável u Gerente de configuração

110 110/113 Implantar e Administrar Ambiente (continuação) n Entradas u Documento de definição de ambiente u Plano de gerência de configuração de software n Saídas u Documento de definição de ambiente (atualizado) u Plano de gerência de configuração de software (atualizado)

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

112 112/113 Conclusões n GC é um fluxo de apoio ao projeto como um todo n Requer uma certa disciplina na manipulação de itens de configuração e apoio de ferramentas sempre que possível

113 113/113 Referências n Descrição do workflow de gerência de configuração e mudanças do RUP n Configuration Management Today - http://cmtoday.com n Software Release Methodology, M.E.Bays, Prentice Hall, 1999.