advertisement

Introdução a Gerência de Configuração de Software

67 %
33 %
advertisement
Information about Introdução a Gerência de Configuração de Software
Technology

Published on March 24, 2009

Author: ccalmendra

Source: slideshare.net

Description

Curso de 4h de Introdução a Gerência de Configuração de Software
advertisement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Problema da Atualização Simultânea (continuação) 1. Primeiro cenário: 1. O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado 2. Uma vez corrigido, o componente modificado é copiado para a biblioteca central 3. O desenvolvedor B encontra e corrige o mesmo defeito em sua versão do componente por não saber que A já tinha feito isso 15 4. O trabalho de A é desperdiçado

Problema da Atualização Simultânea (continuação) 1. Segundo cenário: 1. O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado 2. Uma vez corrigido, o componente modificado é copiado para a biblioteca central 3. O desenvolvedor B encontra e corrige um outro defeito em sua versão do componente, sem saber do defeito corrigido por A 4. O desenvolvedor B copia sua versão do componente para a biblioteca central 5. Além de o trabalho de A ser desperdiçado, a versão do componente que se encontra na biblioteca central continua apresentando um defeito 16 6. O desenvolvedor A julga o problema como resolvido

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

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

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

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

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

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

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

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

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

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

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

Razões para Criar um Baseline • Reproducibilidade – a habilidade de reproduzir uma versão anterior do sistema • Rastreabilidade – Estabelece uma relação predecessor-sucessor entre artefatos do projeto (projeto satisfaz requisitos, código implementa projeto, etc.) • Geração de Relatórios – A comparação dos conteúdos de dois baselines ajuda na depuração e criação de documentação • Controle de Mudanças – referencial para comparações, discussões e negociações 28

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

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

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

Check-Out Check-out cliente Repositório 32

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

Check-In Check-in cliente Repositório 34

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

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

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

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

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

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

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

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

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

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

Build (continuação) • Incluem não só código fonte, mas documentação, arquivos de configuração, base de dados, etc. • A política de geração dos builds deve ser bem definida na estruturação do ambiente • A geração de builds deve ser automatizada e realizada com freqüência adequada 45

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

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

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

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

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

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

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Marcel mesmo: Gerência de configuração de software

A seguir temos os fundamentos da gerência de configuração de software, ... Introdução à orientação a objetos; Caixas com cantos ...
Read more

Gestão de Configuração de Software e Gestão da Qualidade

Gerência de Configuração de Software e Qualidade de Software. ... Plano de Gestão de Configuração de Software Introdução: Glossário e Referência
Read more

Ferramenta de apoio a gerência de configuração de software

Introdução Com o aumento da complexidade do desenvolvimento de software, ... Na engenharia de software existe a gerência de configuração,
Read more

Gerência de Configuração de Software - devmedia.com.br

Do ponto de vista gerencial, o processo de Gerência de Configuração de Software é dividido ... uma breve introdução sobre Gerência de ...
Read more

Print | Processo de Software Project | Assembla

Introdução. O Plano de Gerenciamento de Configuração estabelece e mantem a integridade dos artefatos gerados no projeto Processo de Software doravante ...
Read more

IMPLANTAÇÃO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO DE ...

INTRODUÇÃO ... Gerência de Configuração de Software ...
Read more

1 Gerenciamento de Configuração de Software - Mandrado Santos

4 O Processo de gerência de configuração. 5 ... atividade de gestão de configuração de software, ... manutenção e evitar a introdução ...
Read more

Gerenciamento do Ciclo de Vida de Software - Mandrado Santos

Muitas ferramentas para gestão e gerenciamento de configuração de software ... Introdução. Quando estamos ... plano de gerência de configuração de ...
Read more