Gerência de Configuração de Software Gerência de Configuração de Software Pós-Graduação em...

Gerência de Configuração de SoftwareGerência de Configuração de Software

Pós-Graduação em Análise, Projeto e Gerência de Sistemas de Informação

Professora: Aline Vasconcelos

apires@iff.edu.br

Gerência de Configuração Gerência de Configuração de Software (GCS)de Software (GCS)

ou Software Configuration ou Software Configuration Management (SCM)Management (SCM)

3

Definição

Gerência de ConfiguraçãoGerência de Configuração: : “Disciplina aplicando direcionamento técnico e administrativo para identificar e documentar as características físicas e funcionais de um item de configuração, controlar as modificações sobre estas características, gravar e relatar o processamento da mudança e o status da sua implementação, e verificar a sua adequação aos requisitos especificados.” [IEEE]

4

Motivações para GCS Desenvolvimento iterativo e incrementaliterativo e incremental impõe a

necessidade do controle de versões de artefatos do software em desenvolvimentoem desenvolvimento e versões em produçãoem produção.

Desenvolvimento de software concorrente, em equipeequipe. Desenvolvimento distribuídodistribuído, com equipes

geograficamente dispersas.

Controle sobre diferentes distribuições do softwarediferentes distribuições do software (i.e. standard, professional, enterprise etc.).

Melhor controle e acompanhamento das manutençõesmanutenções.

5

Problemas pela Falta de GCS Perda de código fonte ou de outros artefatos

do desenvolvimento. Impossibilidade de rastrear as evoluções,

correções e adaptações no software. Impossibilidade de se controlar Quem,

Por que e Quando uma modificação foi efetuada. Programa em execução e código fonte em

diferentes versões. Dificuldade de sincronizar o trabalho em equipe. Dificuldade em se retornar o produto a um estado anterior.

etc....

Conceitos

7

Conceitos

Plano de gerência de configuração: documento que

descreve como será aplicada a GC em um projeto;

Item de configuração: agregação de hardware e/ou

software que será passível de GC e tratado como um

elemento único (e.g.: plano de GC, requisitos, modelos,

código-fonte, casos de testes, etc); Versões: instâncias de um mesmo item de

configuração que diferem entre si em algo (sinônimo: revisões);

8

Plano de Gerência de Configuração

A gerência de configuração pode utilizar ferramentas,

convenções de nomes, políticas e procedimentos.

O grau de utilização desses elementos deve variar em

função das características do projeto (e.g.: tamanho,

volatilidade, processo adotado).

O plano de gerência de configuração de

software é o documento utilizado para descrever

como será utilizada a disciplina de gerencia de

configuração no projeto em questão.

9

Plano de Gerência de Configuração

Pode ser definido um plano padrão para a empresa

como um todo ou para determinados departamentos.

Esse plano padrão deverá ser adaptado para cada

novo projeto, levando em consideração as suas

peculiaridades.

Apesar de existirem várias normas para GC (e.g.:

FAA, NASA, DoD, MIL, etc.), as mais aconselhadas

são IEEE e ISO, por não serem voltadas para os

características de uma determinada organização.

10

Repositórios e Baselines Repositórios: local de

acesso controlado, onde as versões dos itens de configuração são armazenadas.

Baselines:em momentos específicos no desenvolvimento de software (denominados milestones), o conjunto de Itens de Configuração resultante é revisado, aprovado e formalmente designado como uma Baseline.

Tarefas de Engenharia de Software

ICs

Revisões Técnicas Formais

ICs

ICs

armazenados

aprovados

ICs

extraídos

Controle de GCS

ICs

modificados

[Pressman, 1997] Processo de atualização

de baseline

11

Baseline (Configuração de Referência)

BaselineBaseline é um conceito de GCS que ajuda a controlar controlar as mudançasas mudanças, pois os Itens de Configuração em uma baseline somente podem ser modificados através de procedimentos formais de controle de mudança.

Modificar um Item de Configuração em uma Baseline requer todo um controle sobre a sua saída do Repositório (CheckoutCheckout) e atualização no repositório (CheckinCheckin).

Como as modificações são controladas sobre os ICs em uma Baseline, a decisão sobre quando ICsquando ICs devem compor Baselines deve ser ponderadaponderada.

12

Quando estabelecer Baselines?

Normalmente, baselines são estabelecidas após o término de cada fase do Ciclo de Vida do software: Requisitos, Projeto, Codificação + Testes, Release.

Uma baseline representa a configuração do software, através das configurações dos seus ICs, em determinados momentos do tempo.

Cada baseline serve como um ponto de partida para a próxima fase do ciclo de vida.

13

Quando estabelecer Baselines?

Baselines devem ser estabelecidas de maneira ponderada, levando em conta uma análise de custo-benefício (“trade-offstrade-offs”):

Baselines determinam marcos no ciclo de vida.

ICs em uma baseline têm a sua modificação controlada.

Controle de mudança apóia o trabalho em equipe, o trabalho gerencial etc.

Mudanças sobre os itens em uma baseline seguem um procedimento “burocrático”.

14

Check-in e Checkout

Check-inCheck-in: formalmente, representa o processo de revisão, aprovação e inclusão/atualização de um item em um repositório controlado. O processo de mudança gera uma nova versão ou revisão do IC.

CheckoutCheckout: uma vez que o pedido de mudança seja aprovado, o item pode ser copiado do repositório para uma base local para que as modificações possam ser realizadas.

15

Versões, Variantes e Releases

Versões (ou Revisões): Versões (ou Revisões): instância controlada de um item de configuração, criada em determinado momento no tempo, que difere de outras instâncias através de alguma característica.

Variante: Variante: versões funcionalmente equivalentes, mas projetadas para ambientes de hardware ou software distintos.

Release (ou Liberação)Release (ou Liberação): conjunto de produtos que deve ser entregue ao cliente. Liberações diferem de versões pois versões podem ser somente para uso interno ao projeto.

16

Desenvolvimento Paralelo e Ramificação (Branching)

1.0

Versões Lineares de um Item de Configuração

1.1 1.2 1.3

1.3

Versões ramificadas de um Item de Configuração (Branches)

1.3.1.0 1.3.1.1 1.3.1.2

1.4 1.5 Linha Principal

Primeira Ramificação

1.3.2.0 1.3.2.1 Segunda Ramificação

17

Desenvolvimento Paralelo e Ramificação (Branching)

Ramos (Branches): versões que não seguem

a linha principal de desenvolvimento. Os ramos

são temporários e terão que sofrer junção

(merge) com a linha principal de

desenvolvimento.

Branches são adequados para permitir que 2

ou mais desenvolvedores trabalhem sobre um

mesmo item ao mesmo tempo

(desenvolvimento paralelo, concorrente).

18

Desenvolvimento Paralelo e Ramificação (Branching)

Números de Versões em Branches: Números de Versões da Linha de desenvolvimento Números de Versões da Linha de desenvolvimento

principal contêm 2 partes (principal contêm 2 partes (majormajor e e minorminor). ).

Números de versões em Números de versões em BranchesBranches contêm 4 partes: os contêm 4 partes: os

dois primeiros números correspondem ao ponto em que dois primeiros números correspondem ao ponto em que

o o branch branch (ramo) se desvia da linha principal; o terceiro (ramo) se desvia da linha principal; o terceiro

número corresponde ao número do número corresponde ao número do branch; branch; o quarto o quarto

número indica a versão do artefato naquele número indica a versão do artefato naquele branchbranch

específico.específico.

19

Outros Conceitos Importantes

Item Derivado: item de configuração que pode ser obtido a

partir de outro item de configuração. Ex: arquivos binários,

executáveis etc.

Item Fonte: item de configuração que serve como origem para

um item derivado.

Exemplo: os itens de configuração que compõem o código-fonte

são itens fonte para o programa executável, que é item derivado.

É necessário documentar as ferramentas e o ambiente utilizado,

para que a geração possa ser repetível. Por exemplo, para

programas em Java, deve ser registrada a versão do compilador

utilizada na geração da release, parâmetros de compilação,

bibliotecas utilizadas, recursos, classpath, buildfile etc.

20

Outros Conceitos Importantes

Building (construção):Building (construção): processo de compilação

do sistema a partir dos itens fonte para uma

configuração alvo.

Utiliza arquivos de comando que descreve como

deve ocorrer a construção.

Exemplo: makefile.

Os arquivos de comando também são

considerados itens de configuração.

21

Outros Conceitos Importantes: Deltas

É importante que sistemas de versionamento

mantenham registro da última versão e das

versões anteriores de um item de configuração.

Usuários (releases) podem estar usando versões

mais antigas dos itens.

Versões mais antigas nos ajudam a detectar

problemas em versões mais recentes.

22

Outros Conceitos Importantes: Deltas

Idealmente, cópias de todas as versões dos itens poderiam ser mantidas no repositório. Mas, isso requer considerável espaço de armazenamento em disco...

Deltas Deltas visam poupar este espaço de armazenamento! Delta representa a diferença entre a versão atual e a última versão de um item de configuração.

Repositório

23

Deltas

Ao invés de armazenar cópias completas

de todas as versões de um item, uma única

versão e seus Deltas são armazenados. Assim, a qualquer momento,

versões podem ser derivadas a partir de

uma versão base. Deltas podem ser: forward e reverse.

Versão 1

Versão 2

Versão 3

Delt

aD

elt

a

24

Deltas: Forward e Reverse

Versão 1.0Versão Base /

Completa

Delta Versão 1.1

Delta Versão 1.2

Delta Versão 1.3 Última Versão Versão 1.3

Delta Versão 1.0

Delta Versão 1.1

Delta Versão 1.2

Versão Base

/Completa

Versão Original

25

Delta: Considerações

A decisão pela adoção do Delta em ferramentas de Controle de Versões envolve uma análise de custo-benefício de espaço de armazenamento x tempo de recuperação.

Algumas ferramentas oferecem a facilidade de se optar pelo uso de Delta ou armazenamento das cópias completas das versões dos itens.

26

Atividades IEEE divide as funções da SCM nas quatro

atividades seguintes:

1. Identificação da Configuração

2. Controle da Configuração

3. Relato de Status

4. Auditorias e Revisões

27

Identificação da Configuração Atividades: (1) estabelece os itens a serem controlados, (2)

estabelece esquemas de identificação para os itens e suas versões, e (3) estabelece as ferramentas e técnicas a serem utilizadas na aquisição e gerência dos itens controlados.

Atividades 1 e 2 envolvem: Seleção de itens de configuração: agrupamento dos artefatos de

software em itens de configuração, que serão sujeitos ao controle da SCM.

Designação: desenvolvimento de um esquema de numeração ou nomenclatura para relacionar os artefatos de software e a sua documentação associada.

Descrição: documentação das características funcionais e físicas para cada um dos itens de configuração. Determinar que características devem ser capturadas, de forma que as propriedades e os requisitos do produto sejam refletidos corretamente, é uma decisão importante.

28

Item de Configuração Item de Configuração (IC): agregação de hardware

e/ou software que será passível de gerência de configuração e tratado como um elemento único.

Exemplos:planos, especificação de análise e projeto, modelos, material de teste, código fonte, código executável, bibliotecas, documentação de instalação, documentação de manutenção, manual de usuário, dentre outros.

Características de um Item de Configuração:é versionado, tem a sua evolução/modificação controlada (quem, por que, quando), fonte de informação sobre o software, pode ser composto.

29

Atividades IEEE divide as funções da SCM nas quatro

atividades seguintes:

1. Identificação da Configuração

2. Controle da Configuração

3. Relato de Status

4. Auditorias e Revisões

Processo de Controle da Configuração

Identificação da Necessidadede Mudança

Requisição de Mudança Classificação e Análise da Requisição

de Mudança

Avaliação e Aprovação da MudançaAtravés da Requisição e Documento de

Análise

Requisição de Mudança Aprovada Requisição de Mudança RejeitadaRequisição de Mudança

Adiada

.... ....Informações complementares da Requisição são fornecidas para

uma resolução futura

Requisição de Mudança Aprovada

A Requisição de Mudança é repassadapara um profissional para implementação

Itens a serem modificados sãoObtidos do repositório (Checkout)

Modificações são aplicadas aosItens de configuração com base na Requisição

de Mudança e no Documento de Análise

Testes e/ou Inspeções são aplicados para aVerificação e validação dos itens

Itens modificados são atualizados no repositórioe promovidos à nova baseline

Nova versão do software pode ser liberada

Requisição de Mudança Rejeitada

Responsável pela Requisição de Mudança é informado,sendo fornecidas as razões pela rejeição

33

Formulário de Requisição de Mudança

Informações: Nome do Projeto/Sistema; Componente/Item a ser Modificado; Classificação da Mudança; Prioridade; Descrição; Status; Observações; Número de Requisição da Mudança (Modificação).

Status: Iniciada (submetida); Recebida; Classificada: Aprovada/Rejeitada/Adiada; Analisada; Atribuída a um Desenvolvedor; Checked-out; Modificações realizadas e testadas; Revisada; Aprovada; Checked-in; Incluída em uma Nova Baseline.

Requisições de Mudança devem ter um identificador único para fins de rastreamento.

34

Classificação e Análise da Mudança

Os critérios de classificação das mudanças devem estar detalhados no plano de gerência de configuração.

A classificação visa priorizar modificações mais

importantes (críticas, fatais, não fatais,

cosméticas).

A análise visa relatar os impactos em custo,

cronograma, funcionalidades, etc. da

implementação da modificação.

35

Informações do Relatório de Análise da Mudança

Número da Requisição de Modificação; Sistema/Projeto; Item a ser analisado; Analisada por; Itens afetados;Itens afetados; Alternativas de implementação; Esforço estimado; Impacto no cronograma e custo do projeto.

36

Análise de Impacto de Modificação em Software

A análise de impacto pode ser definida como o processo de identificação de possíveis conseqüências de uma modificação no software (BOHNER, 2002).

A partir da análise do impacto da modificação no software, estima-se o esforço e o custo da implementação.

Técnicas para apoiar a Análise de Impacto:Técnicas para apoiar a Análise de Impacto: Análise de documentos de análise e projeto;Análise de documentos de análise e projeto; Engenharia reversa;Engenharia reversa; Busca de referências a variáveis e funções (ex: Eclipse);Busca de referências a variáveis e funções (ex: Eclipse); Análise de rastros entre diferentes artefatos do software (ex: Análise de rastros entre diferentes artefatos do software (ex:

ambiente OdysseyLight);ambiente OdysseyLight); Análise de artefatos modificados em conjunto em repositórios Análise de artefatos modificados em conjunto em repositórios

de gerência de configuração (ex:Odyssey-WI).de gerência de configuração (ex:Odyssey-WI).

37

Classificação e Análise da Mudança

•Caso a análise conclua que não existe chance de aprovar a modificação (casos extremos), pode ocorrer rejeição antes da avaliação para poupar custos no processo.•A avaliação utilizará a requisição de modificação e o laudo da análise para tomar a decisão.

•A requisição de modificação pode ser aceita, aceita, rejeitada ou adiada.rejeitada ou adiada.•No caso de rejeição, deve ser informada a razão, e no caso de adiamento deve ser informado o novo prazo, a razão e as novas informações desejadas (caso se aplique).

38

Implementação da Modificação Checkout dos itens de configuração do repositório;Checkout dos itens de configuração do repositório; Implementação das mudanças com base na Implementação das mudanças com base na

requisição e documento de análise da modificação:requisição e documento de análise da modificação: Para manutenção em código, Para manutenção em código, Testes de UnidadeTestes de Unidade

devem ser realizados.devem ser realizados. Durante a verificação, devem ser aplicados Durante a verificação, devem ser aplicados

Testes de Sistema Testes de Sistema também. Isso pode requerer a também. Isso pode requerer a re-execução de testes especificados re-execução de testes especificados anteriormente (testes de regressão).anteriormente (testes de regressão).

A documentação de projeto deve ser revisada A documentação de projeto deve ser revisada para refletir a mudança.para refletir a mudança.

39

Implementação da Modificação

Itens modificados são atualizados no repositório.Itens modificados são atualizados no repositório. Uma nova configuração de referência ou Uma nova configuração de referência ou

baselinebaseline é gerada. é gerada. Uma nova Uma nova releaserelease pode ser gerada. Mas, pode ser gerada. Mas,

geralmente mudanças são agrupadas para a geralmente mudanças são agrupadas para a geração de uma nova geração de uma nova releaserelease..

No caso de correções emergenciais, podem ser criados ramos sem a necessidade do processo formal.

40

Atividades IEEE divide as funções da SCM nas quatro

atividades seguintes:

1. Identificação da Configuração

2. Controle da Configuração

3. Relato de Status

4. Auditorias e Revisões

41

Relato de Status (Status Accouting)

Representa o acompanhamento da configuração.

Envolve o registro e relato de informações necessárias para efetivamente se gerenciar um software e os seus itens de configuração.

Inclui, entre outros itens de informação: Registro de documentação das configurações

aprovadas: modelo, documentos, código; Status das requisições de mudança; Informações sobre builds e releases; etc.

42

Atividades IEEE divide as funções da SCM nas quatro

atividades seguintes:

1. Identificação da Configuração

2. Controle da Configuração

3. Relato de Status

4. Auditorias e Revisões

43

Auditoria

Tarefas: Verificação funcional, assegurando que a configuração

de referência cumpre o que foi especificado.

Verificação física, assegurando que a configuração de

referência é completa (todos os itens de configuração

especificados).

Auditorias servem para garantir que os

procedimentos e padrões foram aplicados.

44

Auditoria A auditoria ocorre antes de cada liberação,

para verificar a configuração de referência de produto.

Preferencialmente, auditoria deve ser efetuada por auditor externo e isento.

Caso deseje efetuar internamente, a equipe de auditoria deve ser composta por representantes da gerência, garantia de qualidade e do cliente.

45

Auditoria

A auditoria funcional ocorre através da revisão dos planos,

dados, metodologia e resultado dos teste, para verificar se

são satisfatórios.

A auditoria física examina a estrutura de todos os itens de

configuração que compõem a configuração de referência.

A auditoria física é efetuada após a auditoria funcional.

Pode ocorrer auditorias no próprio sistema de GC pelos

mantenedores do plano de GC, para verificar se as

políticas e procedimentos estão sendo cumpridos.

Ferramentas de GCS

47

CVS: Concurrent Versions System

Sistema de Controle de Versões. Gerencia um repositório de artefatos

de software. Desenvolvimento distribuído com

conexões convencionais (pserver) e seguras (ssh).

Desenvolvimento concorrente via verificação de conflitos e merge.

48

CVS: Concurrent Versions System

Clientes e Servidores: cvs (http://www.cvshome.org) cvsnt (http://www.cvsnt.org) cygwin (http://www.cygwin.com) wincvs, maccvs, gcvs (http://www.wincvs.org) jCVS (http://www.jcvs.org) Embutido em IDEs (Eclipse, NetBeans, JBuilder,

etc.)

49

CVS - Funcionalidades

Obter artefatos do repositório: Checkout.Checkout. Atualizar artefatos no repositório: Commit.Commit. Atualização do espaço de trabalho local em relação

ao estado atual do repositório: UpdateUpdate Sincronização de atualizações com as informações do

repositório: Synchronize with RepositorySynchronize with Repository Verificação do Histórico de atualização de um

artefato, com autor da modificação e motivo: History.History. Obter versões de artefatos de um projeto em uma Obter versões de artefatos de um projeto em uma

data específica.data específica. Verificação de conflitosVerificação de conflitos e e mergemerge..

50

CVS: Detecção de Conflitos e Merge

Usuários recuperam o mesmo artefato do repositório.

Um dos usuários atualiza o artefato e faz checkin (commit).

Quando o próximo usuário vai atualizar, se as linhas modificadas não coincidem, o CVS faz o merge das modificações.

Se as linhas modificadas coincidem, o CVS apresenta os conflitos e o usuário deve solucioná-los.

Uma vez solucionados os conflitos, o usuário deve atualizar novamente o repositório (commit).

51

CVS: Detecção de Conflitos e Merge

Cenário: Usuário A faz Checkout e Usuário B faz checkout do

artefato AloMundo.java versão 1.1. Usuário A atualiza (commit ou checkin) o

AloMundo.Java no repositório, gerando a versão (ou revisão) 1.2.

Quando o usuário B vai fazer o commit, o CVS indica que existem problemas.

Usuário B então faz um Update para atualizar a base local em relação ao repositório. Neste momento, o CVS tenta fazer o merge da versão 1.2 com a 1.1.

52

CVS: Detecção de Conflitos e Merge

Cenário: Se as modificações realizadas pelos usuários A e B

foram realizadas em linhas diferentes, o CVS faz o Merge e o usuário B deve novamente fazer o commit, gerando a versão (ou revisão) 1.3.

Se as modificações realizadas pelos usuários A e B foram realizadas em linhas coincidentes, o CVS aponta os conflitos e o usuário B deve editar o arquivo para solucioná-los.

Uma vez solucionados os conflitos, o usuário B deve realizar novamente um commit (checkin), gerando a versão 1.3.

53

Apache Ant

Sistema de apoio à construção (building) escrito em Java.

Semelhante ao Make. Descritores (arquivos de build) são escritos em

XML. Utilizado pela maioria das IDEs de programação,

como o Eclipse, NetBeans e JBuilder. Home-Page:

http://ant.apache.org; http://nant.sourceforge.net (versão para .NET/Mono);

54

Apache Ant Usualmente, os descritores de construção Ant são

definidos via arquivo build.xml; Todo descritor de construção Ant é composto por três

elementos principais: Project: Representa o projeto em questão; Target: Representa um alvo de construção (e.g.:

compila, testa, empacota, etc.); Task: Representa uma tarefa específica a ser

automatizada (e.g.: javac, ftp, ssh, cvs, junit, etc.)

Project Target Task* *

55

Apache Ant

Exemplo de Arquivo de Build:<?xml version="1.0" encoding="UTF-8" ?> <!-- Copyright 2003 (c) Projeto Odyssey. http://reuse.cos.ufrj.br/odyssey  

--> - <project basedir="." default="test" name="odysseylight">- ......<path id="class.path">  <pathelement path="${build.dir}" /> - <fileset dir="${lib.dir}">  <include name="*.jar" />   </fileset>- <fileset dir="${test.lib.dir}">  <include name="*.jar" />   </fileset></path>

56

Apache Ant

Exemplo de Arquivo de Build:......<target name="compile" depends="prepare">  <javac classpathref="class.path" srcdir="${src.dir}" destdir="$

{build.dir}" optimize="true" /> </target>

.....................

57

Bugzilla

Sistema para Controle de Modificações. Desenvolvido no contexto do projeto Mozilla. Escrito em Perl. Faz uso do SGBD relacional MySQL. Permite a integração com outras ferramentas de GCS:

Exemplo CVS. Download:

www.bugzilla.org

58

Bugzilla

O Bugzilla se baseia no conceito de máquina de estados.

Toda requisição de modificação se encontra em um determinado estado.

Papéis específicos podem atuar na requisição em função do estado corrente.

Toda troca de estados é catalogada para possibilitar auditoria futura.

QUESTÕES DE PESQUISA

60

Questões de Pesquisa em GCS

Testes de RegressãoTestes de Regressão: quando aplicar? Como selecionar os casos de teste que devem ser re-executados em função da manutenção realizada?

Técnicas para apoiar a Análise de ImpactoAnálise de Impacto de Modificações.

Ferramentas de Gerência de ConfiguraçãoFerramentas de Gerência de Configuração: funcionalidades cobertas, ambientes de desenvolvimento,plataformas, número de usuários (popularidade), paralelo entre ferramentas.