SlideShare uma empresa Scribd logo
1 de 51
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

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Projeto de Software
Projeto de SoftwareProjeto de Software
Projeto de Software
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!
 
Aula 1 - Introdução a Engenharia de Software
Aula 1 -  Introdução a Engenharia de SoftwareAula 1 -  Introdução a Engenharia de Software
Aula 1 - Introdução a Engenharia de Software
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Metodos Ageis
Metodos AgeisMetodos Ageis
Metodos Ageis
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
 
Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
 
Uml Diagramas Estruturais
Uml   Diagramas EstruturaisUml   Diagramas Estruturais
Uml Diagramas Estruturais
 

Destaque

Testes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de TestesTestes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de Testes
Paulo César M Jeveaux
 
20 dinamicas pedagogicas
20 dinamicas pedagogicas20 dinamicas pedagogicas
20 dinamicas pedagogicas
Silvana
 

Destaque (11)

Solução técnica - CMMI nível 3
Solução técnica - CMMI nível 3Solução técnica - CMMI nível 3
Solução técnica - CMMI nível 3
 
Gestão de Ativos de Software
Gestão de Ativos de SoftwareGestão de Ativos de Software
Gestão de Ativos de Software
 
Gestão de Ativos de Software - Riscos e Oportunidades
Gestão de Ativos de Software - Riscos e OportunidadesGestão de Ativos de Software - Riscos e Oportunidades
Gestão de Ativos de Software - Riscos e Oportunidades
 
Obsolência de Software e Hardware
Obsolência de Software e HardwareObsolência de Software e Hardware
Obsolência de Software e Hardware
 
Software de Manutenção - NG Informática
Software de Manutenção - NG InformáticaSoftware de Manutenção - NG Informática
Software de Manutenção - NG Informática
 
Gerência de configuração de softwares
Gerência de configuração de softwaresGerência de configuração de softwares
Gerência de configuração de softwares
 
Trabalho em Equipe
Trabalho em EquipeTrabalho em Equipe
Trabalho em Equipe
 
Testes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de TestesTestes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de Testes
 
Trabalho coletivo - Trabalho de Equipe, Cooperação, Colaboração como elemento...
Trabalho coletivo - Trabalho de Equipe, Cooperação, Colaboração como elemento...Trabalho coletivo - Trabalho de Equipe, Cooperação, Colaboração como elemento...
Trabalho coletivo - Trabalho de Equipe, Cooperação, Colaboração como elemento...
 
20 dinamicas pedagogicas
20 dinamicas pedagogicas20 dinamicas pedagogicas
20 dinamicas pedagogicas
 
Lideranca em 7 passos | Resumo do livro "O Monge e o Executivo"
Lideranca em 7 passos | Resumo do livro "O Monge e o Executivo"Lideranca em 7 passos | Resumo do livro "O Monge e o Executivo"
Lideranca em 7 passos | Resumo do livro "O Monge e o Executivo"
 

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

ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...
ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...
ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...
Antonio Lobato
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
elliando dias
 

Semelhante a Introdução a Gerência de Configuração de Software (20)

Aula 2 - Gerencia De Configuração_definições e processos.pdf
Aula 2 - Gerencia De Configuração_definições e processos.pdfAula 2 - Gerencia De Configuração_definições e processos.pdf
Aula 2 - Gerencia De Configuração_definições e processos.pdf
 
Simtecce 2011 Integracao Continua
Simtecce 2011 Integracao ContinuaSimtecce 2011 Integracao Continua
Simtecce 2011 Integracao Continua
 
Alm open source
Alm open sourceAlm open source
Alm open source
 
Academia do Arquiteto - Implantando A.L.M. em uma semana!
Academia do Arquiteto - Implantando A.L.M. em uma semana!Academia do Arquiteto - Implantando A.L.M. em uma semana!
Academia do Arquiteto - Implantando A.L.M. em uma semana!
 
Projeto de Melhoria da Qualidade do Desenvolvimento de um Software Multiplat...
Projeto de Melhoria da Qualidade do Desenvolvimento  de um Software Multiplat...Projeto de Melhoria da Qualidade do Desenvolvimento  de um Software Multiplat...
Projeto de Melhoria da Qualidade do Desenvolvimento de um Software Multiplat...
 
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
 
Qualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual StudioQualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual Studio
 
Integração Contínua
Integração ContínuaIntegração Contínua
Integração Contínua
 
Integração contínua - Prática de desenvolvimento
Integração contínua - Prática de desenvolvimentoIntegração contínua - Prática de desenvolvimento
Integração contínua - Prática de desenvolvimento
 
ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...
ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...
ld0mg1hrlhzbyvgfiyyq-signature-d9919623d100cd87ad7553e4c50163aa9329a439464540...
 
Como aumentar a produtividade da sua equipe
Como aumentar a produtividade da sua equipeComo aumentar a produtividade da sua equipe
Como aumentar a produtividade da sua equipe
 
Bugzilla - Uma visão geral
Bugzilla - Uma visão geral Bugzilla - Uma visão geral
Bugzilla - Uma visão geral
 
Subm_SamuelPereira_FINAL
Subm_SamuelPereira_FINALSubm_SamuelPereira_FINAL
Subm_SamuelPereira_FINAL
 
Introdução aos computadores e à World Wide Web
Introdução aos computadores e à World Wide WebIntrodução aos computadores e à World Wide Web
Introdução aos computadores e à World Wide Web
 
DevOps
DevOpsDevOps
DevOps
 
Modelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de SoftwareModelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de Software
 
Visual Basic Básico
Visual Basic BásicoVisual Basic Básico
Visual Basic Básico
 
Engenharia de software
Engenharia de software Engenharia de software
Engenharia de software
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Integração Contínua
Integração ContínuaIntegração Contínua
Integração Contínua
 

Mais de Camilo Almendra

Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em Empresas
Camilo Almendra
 

Mais de Camilo Almendra (13)

NPI - Palestra WTISC 2015 - UFC Quixadá
NPI - Palestra WTISC 2015 - UFC QuixadáNPI - Palestra WTISC 2015 - UFC Quixadá
NPI - Palestra WTISC 2015 - UFC Quixadá
 
Seminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
Seminário - Estudos Empíricos em Engenharia de Software - RE@QuixadáSeminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
Seminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
 
Estágio Supervisionado e NPI - UFC Quixadá
Estágio Supervisionado e NPI - UFC QuixadáEstágio Supervisionado e NPI - UFC Quixadá
Estágio Supervisionado e NPI - UFC Quixadá
 
Workshop de Requisitos
Workshop de RequisitosWorkshop de Requisitos
Workshop de Requisitos
 
Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em Empresas
 
Empreendedorismo: Tendências na Internet
Empreendedorismo: Tendências na InternetEmpreendedorismo: Tendências na Internet
Empreendedorismo: Tendências na Internet
 
Relato Experiência Taxonomia SOLO
Relato Experiência Taxonomia SOLORelato Experiência Taxonomia SOLO
Relato Experiência Taxonomia SOLO
 
Introdução a Gestão de Projetos
Introdução a Gestão de ProjetosIntrodução a Gestão de Projetos
Introdução a Gestão de Projetos
 
Das Fábricas aos Time Auto-organizados
Das Fábricas aos Time Auto-organizadosDas Fábricas aos Time Auto-organizados
Das Fábricas aos Time Auto-organizados
 
Introdução à Iniciação de Projetos de Software
Introdução à Iniciação de Projetos de SoftwareIntrodução à Iniciação de Projetos de Software
Introdução à Iniciação de Projetos de Software
 
Dissertação - Janeiro/2003 - DC/UFC
Dissertação - Janeiro/2003 - DC/UFCDissertação - Janeiro/2003 - DC/UFC
Dissertação - Janeiro/2003 - DC/UFC
 
Introdução de Kanban para Equipes Scrum
Introdução de Kanban para Equipes ScrumIntrodução de Kanban para Equipes Scrum
Introdução de Kanban para Equipes Scrum
 
Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
 

Último

Último (8)

ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 

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

  • 1. 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
  • 2. Pacote: REC.MESW.GC.01 Motivação e Fundamentos de Gerência de Configuração 2
  • 3. Motivação e Fundamentos de Gerência de Configuração Professor: Camilo Almendra Pacote: REC.MESW.GC.01 Tempo Previsto: 04 horas/aula 3
  • 4. 1. Gerência de Configuração de Software Professor: Camilo Almendra Aula: REC.MESW.GC.01.01 Tempo Previsto: 4h/aula 4
  • 5. 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
  • 6. 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
  • 7. Problema da Quebra de Comunicação Desenvolvedor A Desenvolvedor B Desenvolvedor C 7
  • 8. 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
  • 9. Problema dos Dados Compartilhados Desenvolvedor A Desenvolvedor B Programa de A Programa de B Componente A1 A2 A3 B1 B2 B3 Compartilhado 9
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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.
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. Baselines importantes 1. Baselines são considerados marcos no processo de desenvolvimento: 1. Funcional : requisitos 2. De Produto : releases, iterações 29
  • 30. 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
  • 31. 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
  • 32. Check-Out Check-out cliente Repositório 32
  • 33. 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
  • 34. Check-In Check-in cliente Repositório 34
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 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
  • 47. Release 1. Implantado no cliente 2. Deve ser devidamente mantido 1. Enquanto a linha principal evolui 2. Uso de branches e merges 47
  • 48. 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
  • 49. 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
  • 50. 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
  • 51. Bibliografia 1. Software Configuration Management Handbook, Second Edition (Hardcover). Alexis Leon. 51