Carregar apresentação
A apresentação está carregando. Por favor, espere
1
Contexto para Gerência de Configuração
2
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
Problema da Quebra de Comunicação
Desenvolvedor A Desenvolvedor B Desenvolvedor C Introdução
4
Problema da Quebra de Comunicação (continuação)
Falhas de comunicação em equipes Ocorre pelas mais diversas razões: Vocabulários incompatíveis Culturas de desenvolvimento diferentes Distância geográfica Dificuldade de expressão Quando este problema acontece: Os sistemas produzidos não atendem aos requisitos Força de trabalho é desperdiçada Introdução
5
Problema dos Dados Compartilhados
Componente Compartilhado Desenvolvedor A Desenvolvedor B A1 A2 A3 Programa de A Programa de B B1 B2 B3 O Problema dos Dados Compartilhados é extremamente comum em qualquer ambiente no qual dois ou mais desenvolvedores compartilham um recurso. Por exemplo, se o recurso compartilhado for um componente de software, o problema poderá ocorrer sempre que um desenvolvedor A modificar o componente compartilhado e esquecer de avisar aos outros (uma instância do problema da falha de comunicação). Da próxima vez que um dos outros desenvolvedores for trabalhar no componente, este não estará no estado esperado. Se, por exemplo, ele fizer uma alteração no componente e essa alteração afetar a parte que foi modificada por A, um erro poderá ocorrer. Por não saber da modificação feita por A, o desenvolvedor estará completamente no escuro com relação à causa do problema. Introdução
6
Problema dos Dados Compartilhados - Cenário
O desenvolvedor A modifica o componente compartilhado Mais tarde, o desenvolvedor B realiza algumas alterações no mesmo Ao tentar compilar o componente, erros são apontados pelo compilador, mas nenhum deles ocorre na parte que B alterou O desenvolvedor B não tem a menor idéia sobre a causa do problema Introdução
7
Problema dos Dados Compartilhados - 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
Problema da Manutenção Múltipla
Componente Compartilhado Desenvolvedor A Desenvolvedor B A1 A2 A3 B1 B2 B3 Programa de A Programa de B Versão de A do Componente Versão de B do Componente O Problema da Manutenção Múltipla acontece quando os membros de uma equipe precisam modificar um mesmo recurso (no exemplo, novamente um componente de software) mas, ao invés compartilhá-lo, cada um mantém uma cópia “local” para que as modificações realizadas por um desenvolvedor não afetem o desenvolvimento do outro. O problema fica evidente quando é necessário saber qual a versão mais “atualizada” do componente. Um desenvolvedor A pode ter detectado um defeito que não foi percebido por outro desenvolvedor, B. Ao mesmo tempo, B pode ter implementado uma funcionalidade que A não implementou. Qual versão do componente deve ser utilizada? A de A ou a de B? A situação torna-se mais crítica, quão maior for o tamanho da equipe. Introdução
9
Problema da Manutenção Múltipla (continuação)
Ocorre quando cada desenvolvedor trabalha com uma cópia “local” do que seria o mesmo componente Dificuldade para saber: Que funcionalidades foram implementadas em quais versões do componente Que defeitos foram corrigidos Evitado através de uma biblioteca central de componentes compartilhados Nesse esquema, cada componente é copiado para a biblioteca sempre que alterado Resolve o Problema da Manutenção Múltipla, mas... Introdução
10
Problema 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 B Versão de B do Componente Biblioteca Central de Recursos Compartilhados Componente O Problema da Atualização Simultânea acontece quando os membros de uma equipe precisam modificar um mesmo recurso (no exemplo, novamente um componente de software) e cada um trabalha em uma cópia local do componente mas, sempre que uma modificação no componente é realizada, ele é copiado para uma biblioteca central de componentes compartilhados. Nessa biblioteca deve sempre estar disponível a versão mais nova do componente. O problema com esse esquema é que quando dois desenvolvedores A e B pegam a mesma versão V1 do componente compartilhado para trabalhar localmente, se A terminar suas modificações e copiar a nova versão do componente para a biblioteca mas não avisar a B, da próxima vez que B copiar a sua versão modificada para a biblioteca o trabalho de A estará perdido, uma vez que B alterou a versão V1 e não levou em consideração as modificações feitas por A. Introdução
11
Problema da Atualização Simultânea – Cenário 1
O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado Uma vez corrigido, o componente modificado é copiado para a biblioteca central O desenvolvedor B encontra e corrige o mesmo defeito em sua versão do componente por não saber que A já tinha feito isso O trabalho de A é desperdiçado Introdução
12
Problema da Atualização Simultânea – Cenário 2
O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado Uma vez corrigido, o componente modificado é copiado para a biblioteca central O desenvolvedor B encontra e corrige um outro defeito em sua versão do componente, sem saber do defeito corrigido por A O desenvolvedor B copia sua versão do componente para a biblioteca central Além de o trabalho de A ser desperdiçado, a versão do componente que se encontra na biblioteca central continua apresentando um defeito O desenvolvedor A julga o problema como resolvido Introdução
13
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 Introdução
14
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 Introdução
15
Objetivos de GC Definir o ambiente de desenvolvimento
Definir políticas para controle de versões, garantindo a consistência dos artefatos produzidos Definir procedimentos para solicitações de mudanças Administrar o ambiente e auditar mudanças Facilitar a integração das partes do sistema Introdução
16
Benefícios Aumento de produtividade no desenvolvimento
Menores Custos de Manutenção Redução de defeitos Maior rapidez na identificação e correção de problemas Introdução
17
Conceitos Básicos Introdução
18
Configuração Um projeto de desenvolvimento de software produz os seguintes itens: Programas (código fonte, programas executáveis, bibliotecas de componentes, etc.) Documentação (manuais do usuário, documento de requisitos, modelo de análise e projeto, etc.) Dados (dados de teste e do projeto) Esses conjuntos de itens são chamados, coletivamente, de configuração do software Introdução
19
Item de Configuração Um conjunto de itens de hardware e/ou software vistos como uma entidade única para fins de gerência de configuração Um item de configuração está sujeito a mudanças e essas devem obedecer às políticas estabelecidas Normalmente, um item de configuração é estabelecido para cada pedaço de software que pode ser projetado, implementado e testado de forma independente Na literatura, é comum o termo “item de configuração” ser definido como “um programa e sua documentação associada”. Apesar de simplificada, essa definição captura bem a idéia de que um item de configuração é um conjunto de artefatos visto como uma entidade única, para fim de gerência de configuração. Frequentemente, quando se modifica algo em um programa, sua documentação tem que ser atualizada para refletir as mudanças. É muito importante, porém, ressaltar: um item de configuração não é necessariamente um programa. Pode ser um documento, um arquivo de propriedades, dados ou qualquer artefato que só possa ser modificado de acordo com as políticas de gerência de configuração. Introdução
20
Configuração de Software
item fluxo de desenvolvimento tempo
21
Baseline Uma especificação ou produto que foi formalmente revisado e aceito Serve como base para os passos posteriores do desenvolvimento A configuração do software em um ponto discreto no tempo Só pode ser modificado através de procedimentos formais (solicitações de mudança) Um artefato ou conjunto de artefatos só se torna um item de configuração depois que um baseline é estabelecido Introdução
22
Baseline item tempo fluxo de desenvolvimento
23
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 Há diversas vantagens em criar baselines: Um baseline provê um ponto estável e uma visão dos artefatos de desenvolvimento em um ponto discreto do tempo. Baselines provêm um ponto estável a partir do qual novos projetos podem ser criados. Desenvolvedores individuais podem pegar componentes para os quais baselines foram estabelecidos para servir como base para atualizações em suas áreas de trabalho individuais. Um baseline fornece uma maneira de voltar atrás nas mudanças, caso elas sejam consideradas suspeitas ou instáveis. Um baseline fornece uma maneira de reproduzir defeitos reportados, dado que se pode recriar a configuração quando um release foi construído. Introdução
24
Baselines importantes
Baselines são considerados marcos no processo de desenvolvimento: Funcional : requisitos De Produto : releases, iterações Funcional: é o primeiro baseline. Consiste de um documento de requisitos (DR) aprovado, contendo todos os requisitos, funcionais e não-funcionais, associados a um determinado item de configuração. O processo formal de gerência de mudanças é iniciado quando este baseline é estabelecido. Alocado: É alcançado ao fim da fase de projeto. Consiste de todos os artefatos (diagramas, modelo de dados, descrições dos casos de uso, etc.) produzidos para um item de configuração. O nome “alocado” deriva da idéia de as funcionalidades definidas no documento de requisitos estarem alocadas aos componentes e sub-sistemas, quando este baseline é atingido. De Produto: O conjunto de todos os artefatos produzidos pelo processo de desenvolvimento (código fonte, código objeto, documentação, dados, arquivos de configuração, etc). Introdução
25
Repositório Local (físico e lógico) onde os itens de um sistema são guardados Pode conter diversas versões do sistema Utiliza mecanismos de controle de acesso Desenvolvedor Repositório Introdução
26
Lock Resolve a Atualização Simultânea
Garante que apenas o usuário que detém o lock pode alterar o arquivo Problema: “serializa” o trabalho dos desenvolvedores Introdução
27
Check-Out Check-out cliente Repositório Introdução
28
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 Introdução
29
Check-In Check-in cliente Repositório Introdução
30
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 Introdução
31
Build Representa uma versão ainda incompleta do sistema em desenvolvimento, mas com certa estabilidade Costuma apresentar limitações conhecidas Espaço para integração de funcionalidades Inclue não só código fonte, mas documentação, arquivos de configuração, base de dados, etc. A política de geração dos builds deve ser bem definida na estruturação do ambiente Introdução
32
Os Problemas na Geração de Builds
Fazer os builds do sistema manualmente é muito demorado Pode ser difícil saber qual a versão “correta” de um arquivo Os pedaços do sistema podem estar em diversos locais diferentes Alguns arquivos podem ser esquecidos
33
Os Problemas na Geração de Builds
A integração das partes de um sistema em desenvolvimento normalmente é: Realizada poucas vezes, apenas perto de sua implantação Feita em freqüência inversamente proporcional à complexidade do sistema Integrar as partes de um sistema é uma tarefa trabalhosa e sujeita a erros Quanto maior o sistema, mais difícil
34
Os Problemas na Geração de Builds
Consequência: problemas de integração tornam-se difíceis de detectar cedo no desenvolvimento Costumam ser encontrados muito depois de sua introdução É muito difícil rastrear suas causas
35
Geração de Buils através da Integração Contínua
Geração freqüente (pelo menos diária) de builds do sistema As partes do sistema são integradas constantemente Problemas de integração passam a ser encontrados logo que introduzidos, na maioria dos casos Considerada uma das “melhores práticas” no desenvolvimento de software A geração de builds deve ser automatizada e realizada com freqüência adequada Usar o quadro para mostrar um cenário exemplo de iintegração contínua: Desenvolve de dia A noite gera um build e faz os testes De manha conserta erros e desenvolve mais Introdução
36
Release Identificação e empacotamento de artefatos entregues ao cliente (interno ou externo) ou ao mercado Um release implica no estabelecimento de um novo baseline, de produto Produto de software supostamente sem erros Versão do sistema validada após os diversos tipos de teste Garantia de que todos os itens de configuração foram devidamente testados, avalidos, aceitos e estão disponíveis no novo baseline Processo iterativo/incremental produz, em geral, mais de um release Introdução
37
Tipos de release Normalmente, releases estão associados aos milestones do plano de projeto Internos Controle de qualidade, acompanhamento de projeto, controle de riscos, aceitação, aquisição de conhecimento através da coleta de feedbacks, desenho da estratégia de implantação Externos Implantado e utilizado pelo cliente
38
Tags Rótulos que são associados a conjuntos de arquivos
Um tag referencia um ou mais arquivos em um ou mais diretórios Costuma-se usar tags para: Denominar projeto rotulando todos os arquivos associados ao projeto Denominar uma versão do projeto (um build ou release) rotulando todos os arquivos associados ao build ou release Introdução
39
Tags – Cenário 1 tag1 tag2 raiz file2 subdir1 file3 file1 file4 file6
Introdução
40
Histórico de um arquivo
Tags – Cenário 2 1.1 1.2 1.3 1.4 release_1 release_2 Histórico de um arquivo tag
41
Branch Criação de um fluxo alternativo para atualização de versões de itens de configuração Recurso muito poderoso Devem existir regras bem definidas para criação de branches Por que e quando devem ser criados? Quais os passos? Quando retornar ao fluxo principal? Por que e quando devem ser criados: em que circunstâncias é justificável criar um novo branch? Apenas para correção de bugs? Para realizar melhorias solicitadas pelos usuários? Quais os passos: que procedimentos devem ser seguidos para criar um branch? Deve ser feita uma solicitação formal? Um backup do item de configuração deve ser realizado? Algum membro da equipe deve ser notificado? Quando retornar ao fluxo principal: quando pode se considerar o branch como encerrado? Isso depende da razão pela qual ele foi criado. Se foi para remover defeitos, o branch deve acabar assim que esses defeitos tenham sido corrigidos, ou deve ser mantido para corrigir novos defeitos que foram descobertos? Introdução
42
Branch (continuação) Uso de lock inviabiliza a criação de branches
Branches normalmente se originam de correções em versões anteriores Introdução
43
Branch (exemplo) 3.m.1 3.m.2 3.m.3 1 hello.c 2 3 hello.h José Maria
4 5 6 • 3 4 • 3.j.1 3.j.2 3.j.3 2.j.1 2.j.2 Introdução
44
Merge Unificação de diferentes versões de um mesmo item de configuração Integração dos itens de configuração de um branch com os itens de configuração do fluxo principal Check-out atualizando a área local Algumas ferramentas fornecem um mecanismo automático para realização de merges Mesmo com o uso de ferramentas, em vários casos há necessidade de intervenção humana Introdução
45
Merge (exemplo) 3.m.1 3.m.2 3.m.3 hello.c Maria hello.h 2.m.1 2.m.2
4 5 • 2 3 4 hello.h • hello.c 3.j.1 3.j.2 3.j.3 3.j.4 José hello.h 2.j.1 2.j.2 2.j.3 Introdução
46
Branching e Merging: esquema gráfico
patch rel_1_fix tag 1.1 1.2 1.3 1.4 release_1 release_2 Tronco principal de desenvolvimento Merge tag
47
Oportunidades criadas com GC
Reuso de itens de software Artefatos Componentes Automação de processo Construção de builds Geração de releases Testes Integração Aumento da produtividade das equipes Redução de re-trabalho Melhoria do acompanhamento do projeto
48
Controle de Mudanças Introdução
49
Contexto Desenvolvimento iterativo/incremental
Novos conjuntos de requisitos, detalhados a cada iteração Mudanças em estratégias de negócio motivadas pelas mais diversas fontes: mercado, cultura, leis, etc
50
Problemas Controle do escopo do projeto
Modificações podem ampliar o leque de funcionalidades e aumentar significativamente o custo do projeto Atrasos em entregas planejadas Controle de consistência dos artefatos Uma mudança aparentemente localizada pode causar muito mais impacto do que o previsto Degradação da qualidade do software (ex: abandono dos testes automatizados devido à inconsistência dos dados de teste) Retrabalho
51
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 Introdução
52
Objetivos da Gerência de Mudanças
Garantir que os artefatos do sistema alcançam e mantêm uma estrutura definida através do seu ciclo de vida Definir procedimentos e documentação necessários para realizar modificações a ICs Prover os mecanismos necessários para conduzir mudanças de uma maneira controlada Introdução
53
Benefícios Controle sobre o escopo do projeto Mais produtividade
cada solicitação será tratada de forma coordenada Redução dos problemas de comunicação entre membros da equipe Mais qualidade, uma vez que cada mudança, antes de ser realizada, tem seu impacto avaliado Geração de dados para o acompanhamento (tracking) do projeto É importante esclarecer o que foi dito no terceiro tópico. O sistema se torna mais robusto porque cada mudança é avaliada antes de ser realizada. Nessa avaliação, além de questões como custo/benefício e tempo para a realização da mudança, é levado em consideração também o impacto que a mudança terá nas partes do sistema que dependem da que será modificada. O objetivo dessa avaliação é garantir que essas outras partes do sistema não sejam “quebradas” pela realização da mudança. Uma vez que a mudança tenha sido aceita, ela é planejada antes de ser implementada. Um dos objetivos desse planejamento é justamente garantir que as partes do sistema afetadas pela mudança são devidamente adaptadas para que o sistema não fique “quebrado”. Com relação ao quarto item, o número de erros diminui porque o controle sobre “quem fez qual mudança” passa a ser centralizado. Se um programador tentar corrigir um erro que já foi corrigido, ele simplesmente será avisado sobre esse fato e informado sobre onde pode encontrar a solução do problema. O problema dos dados compartilhados, por exemplo, poderia ser resolvido trivialmente. Introdução
54
Controle do caos Controle de mudanças Solicitação de mudança Projeto
Organização Projeto
55
Ciclo de vida de um artefato
56
Ciclo de vida de um artefato
Draft Aceito Manutençã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
Artefato Draft Mudanças freqüentes e rápidas Demanda por agilidade
Controle formal dificulta a criação do artefato Artefatos apenas gerenciados e controlados Uso de controle de versão (CVS, Clear Case, entre outras ferramentas)
58
Artefato Aceito Artefato seguiu um processo de revisão, testes (se aplicável) e aceitação Inserido dentro do processo de controle de mudanças, tornando-se de fato item de configuração Mudanças via solicitação formal Presença do grupo gestor de mudanças (CCB) para avaliar e priorizar mudanças
59
Artefato em Manutenção
Após a entrega de uma versão do produto, os artefatos passam para a fase de manutenção Controle de mudanças permanece formal para os artefatos de um baseline Novas artefatos podem ser desenvolvidos usando o mesmo modelo de ciclo de vida Sistema pode ser descontinuado ou removido do ambiente de produção
60
Processo de Gerência de Mudanças
61
Motivação Mudança é inevitável
Mudar é fácil – controlar diversas mudanças simultâneas é difícil A gerência de mudanças introduz controle sobre as mudanças de maior relevância Todas as mudanças são analisadas Apenas as aprovadas são realizadas Sempre se sabe quem modificou o que, onde e quando
62
Responsabilidades do CCB
Analisar as solicitações de mudança Controlar o escopo do projeto Reuniões com freqüência adequada ao ritmo das solicitações de mudança Envolver stakeholders no processo de priorização no processo de decisão Balanço entre o nível de controle desejado e overhead suportado Questões menores devem ser resolvidas pelo líder do projeto junto à equipe, reduzindo o overhead do CCB
63
Características do CCB
Composição multidisciplinar SQA, gerente, cliente, arquiteto Profissionais com grande capacidade de comunicação e negociação Pode apresentar uma estrutura hierarquica dependendo do tamanho e da quantidade de stakeholders e sistemas envolvidos (integrações)
64
Análise de impacto Mudanças de grande impacto devem ser comunicadas aos stakeholders envolvidos Análises de custo x benefício produzidas pelos stakeholders Priorização de mudanças Mudança pode ser rejeitada se o CCB perceber que o custo será mais caro que o benefício percebido Por questões de eficiência, algumas solicitações de mudança podem ser agrupadas por tema, subsistema ou área de negócio
65
Importância da análise de impacto
Dentro do projeto Análises inter-sistemas também devem ser consideradas Exemplo: frameworks, componentes ou bancos de dados compartilhados Requisitos A&P Componentes Análise de impacto intra-projeto
66
Sobre o Processo de Gerência de Mudanças
Deve ser definido um documento padrão para que mudanças possam ser solicitadas Esse documento normalmente se chama Solicitação de Mudança (SM, Em inglês CR) A um conjunto de pessoas (CCB), deve ser dada a autoridade para decidir se uma mudança será ou não implementada O processo é necessário para garantir que apenas mudanças avaliadas e aprovadas são realizadas em ICs Introdução
67
Solicitações de Mudança
Algumas informações que podem estar incluídas em uma SM: Identificação única Solicitante Sistema/Projeto Item a ser modificado Classificação (melhoria, correção de defeito, outra) Prioridade Descrição Situação (nova, atribuída, finalizada, verificada, fechada) Introdução
68
Estrutura de um registro de solicitação de mudança
1. IDENTIFICADOR DA SOLICITAÇÃO <Um código (normalmente numérico) que identifica unicamente a solicitação de mudança.> 2. IDENTIFICAÇÃO DO SOLICITANTE <O nome do indivíduo que solicitou a mudança, possivelmente incluindo informação adicional como posição, matrícula, etc.> 3. SISTEMA DESENVOLVIDO 3.1. NOME DO SISTEMA <O nome do sistema no qual está sendo solicitada a mudança.> 3.2. NOME DO MÓDULO <O nome do módulo no qual a mudança está sendo solicitada.> 3.3. NOME DA FUNCIONALIDADE <O nome da funcionalidade na qual a mudança será efetuada.>
69
Estrutura de um registro de solicitação de mudança
4. CLASSIFICAÇÃO <O tipo de mudança que está sendo solicitada. Normalmente três tipos de mudança são realizados: adição de nova funcionalidade, melhoria de funcionalidade já existente e correção de defeitos. Também é comum que a classificação seja feita com relação à natureza da mudança. Por exemplo: mudança de requisitos, de projeto, de implementação, etc.> 5. DESCRIÇÃO <Uma descrição da mudança que está sendo solicitada. A descrição deve ser o mais não-ambígua e objetiva possível. Ao mesmo tempo, deve incluir toda informação necessária para implantar a mudança.> 6. STATUS <A situação atual da mudança. Por exemplo: aprovada, rejeitada, em implantação, postergada, etc. Essa informação deve ser mantida sempre atualizada.> 7. OBSERVAÇÕES GERAIS <Informações adicionais sobre a solicitação de mudança. Por exemplo: se o solicitante já souber de módulos que serão afetados pela implantação da mudança, pode enumerá-los nesta seção.>
70
Etapas do Processo de Gerência de Mudanças Genérico
1. Requisição da mudança 2. Classificação 3. Avaliação 4.Negociação sobre a realização da mudança 5. Implementação 6. Verificação 7. Promoção dos itens modificados para um novo baseline (mudança aceita) CCB Não entraremos nos detalhes do processo de gerência de mudança neste momento porque este tópico é visto em detalhes em outro módulo do curso, no qual é apresentado o fluxo de Gestão de Mudanças. Introdução
71
Correções Emergenciais
Em algumas situações, não há tempo para seguir os procedimentos padrão para a realização de mudanças Defeitos não são normalmente processados pelo CCB, salvo se envolverem algum questionamento relativo ao escopo do projeto Mesmo nessas situações, porém, é muito importante que seja criada uma solicitação de mudança O objetivo é garantir um mínimo de ordem, mesmo em uma situação caótica Introdução
72
Correções Emergenciais
Mudanças realizadas nessas circunstâncias podem comprometer a arquitetura ou inserir bugs Decisão: Desfazer correção ou Transformar a correção: refactoring, acréscimo de novos casos de teste Introdução
73
Exemplos de Status dos Defeitos
Estados Abertos Próximos Estados NEW Bug inserido por alguém (automático) Aceito a ASSIGNED Reatribuído a NEW Resolvido a RESOLVED ASSIGNED Atribuído à pessoa apropriada REOPENED Reaberto: foi constatado que ainda não tinha sido resolvido UNCONFIRMED Não confirmado que existe Confirmado a NEW
74
Exemplos de Status dos Defeitos
Estados Fechados Próximos Estados RESOLVED Foi resolvido (só está esperando a homologação) Não foi resolvido a REOPENED Está ok a VERIFIED Está ok e pode ser fechado a CLOSED VERIFIED A correção foi homologada Defeito é fechado a CLOSED CLOSED O bug é tido como resolvido
75
Release notes Relação de solicitações de mudanças implementadas e testadas Pode ser parcialmente automatizado Comentários adicionais Limitações atuais, problemas não resolvidos Id Descrição 1 Problema de performance na validação de pedido 2 Nova rotina de validação de crédito conforme normas de dezembro de 2002 …
76
Desafios Cultura organizacional
Agrupamento de solicitações em releases bem definidos e estabelecidos deve ser negociado com os stakeholders do projeto Releases internos utilizados de forma efetiva como ferramenta de gestão de projeto Integração entre sistemas de controle de versão e mudanças
77
Ferramentas de Apoio à Gerência de Configuração
Ferramenta de Controle de Versões (CVS, por exemplo) Manter todos os arquivos em um repositório central Controlar o acesso a esse repositório, de modo a garantir a consistência dos artefatos Automatizar o processo de geração de builds Automatizar o processo de submissão e gestão de SMs Ferramentas de Geração de Builds (Ant, por exemplo) Ferramentas de Gestão de Solicitações de Mudanças (Bugzilla, por exemplo)
78
Gerência de Configuração no Desenvolvimento Iterativo - Relação com as Fases e Disciplinas de Desenvolvimento do RUP
79
Fases, iterações e disciplinas
Concepção Elaboração Construção Transição Iteração Preliminar Iter. #1 #2 #i #i+1 #i+2 #n #n+1 Requisitos Análise e Projeto Implementação Testes Implantação Planejamento e Gerenciamento..... Fluxos de Atividades Fluxos de Suporte Fases Iterações Gerência de Configuração e Mudanças
80
Relação com as Fases de Desenvolvimento e com as Outras Disciplinas
Tem uma maior concentração na fase de concepção Nas iterações das fases seguintes, o nível de esforço é mantido constante Acontece em paralelo e com uma forte integração com a disciplina de planejamento e gerenciamento Algumas atividades relacionadas com a gerência da configuração ocorrem em outras disciplinas como a implementação e a implantação 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 ao fluxo de planejamento e gerenciamento Algumas atividades relacionadas com a gerência da configuração ocorrem em outros fluxos como o de implantação e o de implementação Introdução
81
Atividades, Artefatos e Responsabilidades da Disciplina Gerência de Configuração
82
Objetivos deste módulo
Apresentar atividades da Disciplina de Gerrência de Configuração Discutir os artefatos e responsáveis envolvidos na realização das atividades da disciplina
83
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 Solicitante Submeter solicitações de mudanças CCB Analisar solicitações de mudanças
84
Objetivos do Fluxo Definir Recursos de hardware e software
Política de atualização destes recursos Estruturação de diretórios e repositórios Plataforma de desenvolvimento Política de utilização do ambiente As atividades de Gerência de Configuração que deverão ser realizadas e em que momentos do desenvolvimento Introdução
85
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 CCB
86
Gerente de Configuração
Responsável pela definição dos equipamentos e softwares utilizados e suas configurações Define o ambiente, regras de uso do mesmo e política de mudanças Define os papéis dos membros da equipe responsáveis pelas atividades de gerência de configuração Estabelece as atividades de gerência de configuração que serão realizadas Introdução
87
Solicitante Qualquer pessoa que possa fazer uma solicitação de Mudanças
88
CCB Grupo Responsável por analisar e autorizar uma solicitação de mudanças
89
Artefato – Documento de Definição de Ambiente
1. INTRODUÇÃO <Descreva os objetivos do documento> 2. INFRA-ESTRUTURA 2.1. FERRAMENTAS <Descreva que ferramentas serão usadas por todos os envolvidos no projeto durante o seu desenvolvimento, fornecendo uma breve descrição de cada uma e a quantidade de licenças disponíveis> 2.2. EQUIPAMENTOS <Descreva que equipamentos serão usadas durante o desenvolvimento do sistema, detalhando suas configurações> 3. ORGANIZAÇÃO FÍSICA <Forneça uma breve descrição da estrutura física do local onde o sistema será desenvolvido>
90
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> Introdução
91
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 Introdução
92
Artefato – Plano de Gerência de Configuração de Software
1. INTRODUÇÃO <Descreva os objetivos do documento, forneça definições de termos necessários para o entendimento do mesmo e liste algumas referências interessantes.> 2. GERENCIAMENTO DA GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE 2.1. ORGANIZAÇÃO <Deve ser descrita nesta seção a estrutura da equipe de GCS e como ela se encaixa na estrutura da organização com relação a outras equipes> 2.2. RESPONSABILIDADES <Defina nesta seção os deveres e responsabilidades daqueles que estiverem envolvidos com as atividades de GCS.> 2.3. RELAÇÃO COM AS FASES DO DESENVOLVIMENTO E OUTROS FLUXOS DE ATIVIDADES <Nesta seção são relacionadas as atividades de GCS com as diferentes etapas do ciclo de vida do desenvolvimento de software.>
93
Artefato – Plano de Gerência de Configuração de Software
3. ATIVIDADES DA GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE 3.1. IDENTIFICAÇÃO DA CONFIGURAÇÃO <Esta seção descreve como identificar, nomear e adquirir os itens de configuração do sistema.> Identificação de itens de configuração Nomeação dos itens de configuração Aquisição e armazenamento de itens de configuração 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
Artefato – Plano de Gerência de Configuração de Software
3.3. REGISTRO DO STATUS DA CONFIGURAÇÃO <Esta seção lida com os detalhes de registrar o status de cada item de configuração e apresentar essa informação aos indivíduos que precisam saber sobre ela.> Identificação das necessidades de informação Mecanismos de coleta de informações Relatórios, seus conteúdos e frequências 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.> Auditorias que devem ser realizadas Procedimentos de auditoria
95
Artefato – Plano de Gerência de Configuração de Software
4. AGENDA DA GERÊNCIA DE CONFIGURAÇÃO <Esta seção descreve a seqüência de atividades de GCS, suas interdependências e a relação com o ciclo de vida do projeto.> 5. RECURSOS DE GERÊNCIA DE CONFIGURAÇÃO <Indique nesta seção as ferramentas de software, técnicas, equipamentos, pessoas e treinamentos necessários para a implementação das atividades de gerência de configuração especificadas.> 6. MANUTENÇÃO DO PLANO DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE <Esta seção descreve as atividades que são necessárias para manter o plano atualizado durante o ciclo de vida do projeto.>
96
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 Solicitante Submeter solicitações de mudanças CCB Analisar solicitações de mudanças
97
Definir Ferramentas e Equipamentos(continuação)
Objetivos Definir ferramentas de suporte ao desenvolvimento, controle de versões e softwares em geral Definir hardwares e suas configurações Definir regras para atualizações de hardware e software Responsável Gerente de configuração Introdução
98
Definir Ferramentas e Equipamentos(continuação)
Entradas Documento de requisitos Lista de riscos Estudo de viabilidade Saídas Documento de definição de ambiente Plano de gerência de configuração de software Introdução
99
Passos para Definir Ferramentas e Equipamentos
Definir plataformas de desenvolvimento Definir ferramentas Definir equipamentos e suas configurações Introdução
100
Estruturar Ambiente Gerente de Configuração e Ambiente Definir
ferramentas e equipamentos 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
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 Introdução
102
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) Introdução
103
Passos para Estruturar Ambiente
Definir estrutura de diretórios, repositórios e áreas de backup Definir política para utilização do ambiente Introdução
104
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 Solicitante Submeter solicitações de mudanças CCB Analisar solicitações de mudanças
105
Planejar Gerência de Configuração (continuação)
Objetivos Definir os papéis e responsabilidades dos membros da equipe responsável pelas atividades de gerência de configuração (GC) Definir os baselines que deverão ser estabelecidos Definir o cronograma das atividades de GC Definir as políticas, procedimentos e padrões que guiarão essas atividades Identificar os itens de configuração Responsável Gerente de configuração
106
Planejar Gerência de Configuração (continuação)
Entradas Plano de gerência de configuração de software Saídas Plano de gerência de configuração de software (atualizado)
107
Passos para Planejar Gerência de Configuração
Definir organização, papéis e responsabilidades Definir políticas e procedimentos para registro do status da configuração Definir esquema de nomeação para itens de configuração Identificar e registrar itens de configuração Planejar auditorias Definir baselines Definir cronograma de gerência de configuração
108
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 Solicitante Submeter solicitações de mudanças CCB Analisar solicitações de mudanças
109
Implantar e Administrar Ambiente (continuação)
Objetivos Implantar o ambiente com base na estrutura definida na atividade anterior Gerenciar a utilização do ambiente de acordo com as normas propostas (através de auditorias) Avaliar e revisar o ambiente Responsável Gerente de configuração Introdução
110
Implantar e Administrar Ambiente (continuação)
Entradas Documento de definição de ambiente Plano de gerência de configuração de software Saídas Documento de definição de ambiente (atualizado) Plano de gerência de configuração de software (atualizado) 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) Introdução
111
Passos para Implantar e Administrar Ambiente
Instalar máquinas e criar diretórios Disseminar política de utilização do ambiente Gerenciar e avaliar ambiente
112
Conclusões GC é um fluxo de apoio ao projeto como um todo
Requer uma certa disciplina na manipulação de itens de configuração e apoio de ferramentas sempre que possível
113
Referências Descrição do workflow de gerência de configuração e mudanças do RUP Configuration Management Today - Software Release Methodology, M.E.Bays, Prentice Hall, 1999.
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.