gerência de projetos e manutenção de software aula 9...

Gerência de Projetos e Manutenção de Software

Aula 9 – Gerência de Configuração e Mudanças

Andréa Magalhães [email protected]

2017.01

2GPMS 2017.01

Agenda

• O Problema

• Gerência de Configuração

• Conceitos Básicos

• Processos• Controle de Versões

• Gestão de Mudanças

• Construção e Release

O PROBLEMA

4GPMS 2017.01

Problema da Quebra de Comunicaçã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çadaDesenvolvedor A Desenvolvedor B

Desenvolvedor C

Problema dos Dados Compartilhados

ComponenteCompartilhado

Desenvolvedor A Desenvolvedor B

A1 A2 A3

Programa de A Programa de B

B1 B2 B3

6GPMS 2017.01

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 ideia sobre a causa do problema

7GPMS 2017.01

Problema dos Dados Compartilhados Solução

• Cada desenvolvedor trabalha em uma cópia “local” do componente

• Resolve o Problema dos Dados Compartilhados, mas cria um novo problema...

Problema da Manutenção Múltipla



A1 A2 A3 B1 B2 B3

Programa de A Programa de BComponenteCompartilhado

Versão de A do Componente

Compartilhado



Versão de B do Componente

Compartilhado

9GPMS 2017.01

Problema da Manutenção Múltipla Cenário• Ocorre quando cada desenvolvedor trabalha com uma

cópia “local” do que seria o mesmo componente

• Dificuldade para saber:• Qual a versão mais “atualizada” do componente?• Que funcionalidades foram implementadas em quais

versões do componente?• Que defeitos foram corrigidos?• Qual versão do componente deve ser utilizada?

• A situação torna-se mais crítica, quão maior for o tamanho da equipe.

10GPMS 2017.01

Problema da Manutenção Múltipla Solução

• Criação de uma biblioteca central de componentes compartilhados• Nesse esquema, cada componente é copiado para a

biblioteca sempre que alterado

• Nessa biblioteca deve sempre estar disponível a versão mais nova do componente.

• Resolve o Problema da Manutenção Múltipla, mas...

Problema da Atualização Simultânea

Versão de A do Componente

Compartilhado


A1 A2 A3 B1 B2 B3

Programa de A Programa de BVersão de B do Componente

Compartilhado

Biblioteca Central de Recursos Compartilhados


12GPMS 2017.01

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

13GPMS 2017.01

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

14GPMS 2017.01

Problema da Atualização SimultâneaSolução

• 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

GERÊNCIA DE CONFIGURAÇÃO

16GPMS 2017.01

Gerência de Configuração (GC)

Desenvolvimento Liberação Implantação Produção

Gerência de Configuração

Gerência de Configuração de Software (GCS) é uma disciplinapara o controle da evolução de sistemas de software

(Susan Dart, 1991)

17GPMS 2017.01

Gerência de Configuração (GC)

• Engenharia de Software envolve refinamentos sucessivos de artefatos

Tarefas de Engenharia de

Software

Artefato novo

Repositório

Artefato modificado

Artefato

18GPMS 2017.01

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

19GPMS 2017.01

Histórico

• Anos 50• GC para produção de aviões de guerra e naves espaciais

• Anos 60 e 70• Surgimento de GCS (S = Software)• Foco ainda em aplicações militares e aeroespaciais

• Anos 80 e 90• Mudança de foco• Surgimento das primeiras normas internacionais• Assimilação por organizações não militares

20GPMS 2017.01

Sistema de Gerência de Configuração

Artefatos

Controle de Versões

Construção e Release

Controle de Modificações

Solicitações

21GPMS 2017.01

Problemas pela falta de GC

• Perda de código-fonte

• Impossibilidade de determinar o que aconteceu com um programa, ou parte dele

• Impossibilidade de determinar quem, porque e quando foram efetuadas modificações

• Requisitos já documentados desaparecem

• Requisitos implementados desaparecem do código

• O programa em execução e o seu código fonte estão em diferentes versões

CONCEITOS BÁSICOS

23GPMS 2017.01

Conceitos Básicos

• Repositórios– Lugar seguro onde versões

de artefatos são depositadas

– Permitem armazenamento, busca e recuperação

– Servem como um ponto de referência

– Apoiam no aumento da memória organizacional

24GPMS 2017.01

Check-Out

• Processo de requisição de modificações, aprovação e cópia de um item de configuração do repositório

Check-out

RepositórioCliente

25GPMS 2017.01

Check-Out

• 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

26GPMS 2017.01

Check-In

• Processo de revisão, aprovação e cópia de um item de configuração para o repositório

Check-in

RepositórioCliente

27GPMS 2017.01

Check-In

• 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

CONTROLE DE VERSÃO

29GPMS 2017.01

Tipos de Versão

VersãoVersão

RevisãoRevisão VarianteVarianteCooperação (Rascunho)Cooperação (Rascunho)

(Conradi e Westfechtel 1998)

30GPMS 2017.01

Revisões

Gerações do iMac (1998 – 2013)

31GPMS 2017.01

Variantes

Hatchback

Coupe

Sedan

Honda Civic

32GPMS 2017.01

Cooperação (versões rascunho)

Espaço de trabalho do João

Espaço de trabalho da Maria

Espaço de trabalho do Pedro

Versão base

33GPMS 2017.01

Versões de rascunho podem ser combinadas (operação de merge)

João Maria Pedro

Revisões

34GPMS 2017.01

Conflitos podem ocorrer durante o merge

João Paulo

Revisões

35GPMS 2017.01

Outras duas operações importantes…

… para guardar, transferir e compreender versões.

Diff =

Patch =

36GPMS 2017.01

Mas afinal, para que servem versões?

• Sincronizar equipes• Reproduzir configurações passadas• Explorar possibilidades• Segregar desenvolvedores• Customizar produtos (LPS)• Rastrear a introdução de bugs• Entender a evolução de software• Auditar mudanças

37GPMS 2017.01

Tratamento de variantes em ramos (branches)• Versões que não seguem a linha principal de

desenvolvimento

• Fornecem isolamento para o processo de desenvolvimento – Ramos usualmente são migrados para a linha principal de

desenvolvimento– A migração pode ser complicada no caso de isolamento longo

• Características dos ramos se comparados a espaços de trabalho– compartilhados por outras pessoas (espaços de trabalho são

isolados)– residem no servidor (espaços de trabalho residem no cliente)– históricos (espaços de trabalho são momentâneos)

38GPMS 2017.01

Tratamento de variantes em ramos (branches)• Recurso muito poderoso• Branches normalmente se originam de correções em versões

anteriores• Devem existir regras bem definidas para criação de branches

• 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?

• 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?

39GPMS 2017.01

Estratégia básica de Ramificação

• Manutenção em série• Ramo principal: evolução• Ramos auxiliares: correções

• Foco• Desenvolvimento in-house• Cliente único (e.g.: aplicações Web)

• Dificuldade de manutenção de várias liberações em paralelo

Sistema

Rel. 11.0 1.1 1.2

Rel. 22.0 2.1

Verif. Verif.

1.0 RC 2.0 RCEvolução EvoluçãoDesenv.

Correção Correção Correção

40GPMS 2017.01

Merge

• Unificação de diferentes versões de um mesmo item de configuração

• Integração dos itens de configuração de um branchcom os itens de configuração do fluxo principal

• Checkout 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

41GPMS 2017.01

Exemplo(merge no Eclipse)

42GPMS 2017.01

Baseline• Configuração revisada e aprovada que serve como base para

uma próxima etapa de desenvolvimento e que somente pode ser modificada via processo formal de GCS

• A atualização de uma baseline consiste em check-out seguido de modificações e check-in

• São estabelecidas ao final de cada fase de desenvolvimento– Análise (functional)– Projeto (allocated)– Implementação (product)

• Momento de criar: • Balanceamento entre controle e burocracia

43GPMS 2017.01

Baseline (níveis de controle)

Coordenação c/ auditoria

Controle

Pré baseline:

•Informal•Sem requisição•Sem aprovação•Sem verificação•Ágil•Ad-hoc

Pós baseline:

•Formal•Com requisição•Com aprovação•Com verificação•Burocrático•Planejado e Controlado

Nível de controle

44GPMS 2017.01

Baseline (níveis de controle)

Req. Análise Projeto Análise Projeto Análise Projeto

1 Inform. - Formal Inform. Formal Formal

2 - - Inform. - Formal Inform.

Requisito 1 Análise ProjetoBaseline 1:

•An. Req. 1

Requisito 2 Análise Projeto

Tempo

Baseline 2:

•An. Req. 1•Pr. Req. 1•An. Req. 2

45GPMS 2017.01

Plano de GC

• 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

• Pode ser definido um plano padrão para a organização

• Esse plano padrão deverá ser adaptado para cada novo projeto, levando em consideração as suas peculiaridades

46GPMS 2017.01

Plano de GC - Exemplo

BASELINES

BASELINE: Dt PREVISTA: Dt REAL:




Sist. ID Item Ext. Título Resp. Resp. Implantação

Incluído Versão Incluído Versão Incluído Versão Incluído Versão

47GPMS 2017.01

Principais sistemas de controle de versão open-source

GESTÃO DE MUDANÇAS

49GPMS 2017.01

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

50GPMS 2017.01

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

51GPMS 2017.01

O que é Gestão de Mudanças?

• Gestão 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

52GPMS 2017.01

Objetivos da Gestão 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 nos itens de configuração

• Prover os mecanismos necessários para conduzir mudanças de uma maneira controlada

53GPMS 2017.01

Change Control Board (CCB)• Analisar as solicitações de mudança

• Controlar o escopo do projeto

• Reuniões com frequência adequada ao ritmo das solicitações de mudança

• Envolver stakeholders no processo de priorização e 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

• Composição multidisciplinar• SQA, gerente, cliente, arquiteto

• Profissionais com grande capacidade de comunicação e negociação

54GPMS 2017.01

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

55GPMS 2017.01

Gestão de Mudanças

• Tarefas• Solicitação de modificação

• Classificação da modificação

• Análise da modificação

• Avaliação da modificação

• Implementação da modificação

• Verificação da modificação

• Geração de baseline

56GPMS 2017.01


• Solicitação de Modificação• 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)

57GPMS 2017.01


• Solicitação de Modificação

58GPMS 2017.01


• O critério de classificação da modificação deve estar explicitado

no plano de GC

• 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

• 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

59GPMS 2017.01


• Análise de Modificação

(Leon, 2000)

60GPMS 2017.01


• A avaliação utilizará a requisição de modificação e o

laudo da análise para tomar a decisão

• A requisição pode ser aceita, rejeitada ou adiada

• A implementação deve ser seguida por testes de unidade

• Durante a verificação, devem ser aplicados testes de sistema

• Após a geração da nova baseline, deve ser decidido se ela será considerada uma nova liberação

61GPMS 2017.01


• Caso especial: Correções emergenciais• No caso de correções emergenciais, podem ser

criados ramos sem a necessidade do processo formal

• Em algum momento esses ramos deverão sofrer junção para a linha principal de desenvolvimento

• Esse procedimento deve estar explicitado no processo!

• Defeitos não são normalmente processados pelo CCB

• Mesmo nessas situações, porém, é muito importante que seja criada uma solicitação de mudança

62GPMS 2017.01


• Caso especial: Defeitos– Alguns sistemas tratam defeitos de forma diferente

das demais requisições

– A correção de defeitos é um tratamento sintomático

– É importante descobrir o real motivo para o acontecimento do defeito para possibilitar a prevenção de defeitos futuros

– A análise de causa é útil para descobrir falhas no processo de desenvolvimento

– Falta de treinamento, padrões inadequados, ferramentas inadequadas

63GPMS 2017.01


• Acompanhamento - Tarefas

• Armazenamento das informações geradas

• Propagação dessas informações aos interessados

através de relatórios

• Permite que métricas sejam utilizadas com o intuito de

melhoria do processo e estimativa de custos futuros

• Fornece relatórios gerenciais ad-hoc

64GPMS 2017.01


Resultado do relatório no modo tabular no Bugzilla

65GPMS 2017.01

Auditoria da configuração

• Deve ocorrer ao menos antes de uma liberação

(release)

• Tarefas

• Verificação funcional, assegurando que a baselinecumpre o que foi especificado

• Verificação física, assegurando que a baseline é completa

(todos os itens de configuração especificados)

• Auditorias servem para garantir que os

procedimentos e padrões foram aplicados

66GPMS 2017.01

Auditoria da configuração

• 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 baseline

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

• Podem 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

67GPMS 2017.01

Gestão de MudançasFerramentas• Livre

• Bugzilla• Mantis• Redmine• Trac

• Comercial• ClearQuest (IBM Rational)• JIRA (Atlassian)• StarTeam (Borland)• Synergy/Change (Telelogic)• TeamTrack (Serena)• Team Foundation Server (Microsoft)

CONSTRUÇÃO E RELEASE

69GPMS 2017.01

Terminologia

• Construção (Building): processo de compilação do sistema a partir dos itens fonte para uma configuração alvo;• Utiliza arquivo de comandos que descreve como

deve ocorrer a construção

• Exemplo: makefile• Os arquivos de comandos também devem ser

considerados itens de configuração

70GPMS 2017.01

Terminologia

• Release: • Conjunto de produtos que deve ser entregue ao

cliente

• Releases diferem de versões, pois versões podem ser somente para uso interno ao projeto

71GPMS 2017.01

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

• A integração das partes de um sistema em desenvolvimento normalmente é:• Realizada poucas vezes, apenas perto de sua implantação• Feita em frequê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

72GPMS 2017.01

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

73GPMS 2017.01

Geração de Builds através da Integração Contínua• Geração frequente (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 frequência adequada

74GPMS 2017.01

Gerenciamento de releases

• Descrição de como construir, liberar e entregar o sistema

• Linguagem natural (conhecimento)

• Linguagem computacional (automação)

• Manter os descritores e documentos sob gerência de

configuração!

• Definição das situações onde o processo pode ser

temporariamente desviado

• Cuidado: Releases muito curtas podem levar a círculo-

vicioso de defeitos...

75GPMS 2017.01

Exemplo de ferramentas de build e release

• Livre• Ant• NAnt• Make• Maven• Rake

• Comercial• ClearMake (IBM Rational)• MSBuild (Microsoft)• Synergy/CM Object Make (Telelogic)

76GPMS 2017.01

Application Lifecycle Management(ALM)

COS 823 - Aula 6 76Out 2013

77GPMS 2017.01

Collaborative Lifecycle Management(CLM)

COS 823 - Aula 6 77Out 2013

78GPMS 2017.01

Collaborative Lifecycle Management(CLM)

COS 823 - Aula 6 78Out 2013

RequisitosPlanejamento de Testes

Gerenciamento de Defeitos


79GPMS 2017.01

Exercício

• Elaborar o plano de configuração do projeto informando no mínimo:• Quais artefatos serão colocados sob

gerência de configuração?

• Quais baselines serão estabelecidas e quais os itens de configuração de cada uma dela?

• Como deve funcionar o processo de gestão de mudanças?

80GPMS 2017.01

Dúvidas?

81GPMS 2017.01

Principais Referências Bibliográficas

• Alexis Leon, “A Guide to Software Configuration Management”, Artech House Publishers, 2000.

• Anne Hass, “Configuration Management Principles and Practices”, Boston, MA, Pearson Education, Inc.

• Conradi, R. and Westfechtel, B. Version Models for Software Configuration Management. ACM Computing Surveys, v.30, n.2, p. 232-282, 1998.

• Dart, S., 1991, “Concepts in Configuration Management Systems”, International Workshop on Software Configuration Management (SCM), Trondheim, Norway (June), pp. 1-18.

• Pressman, R. S. (1997). “Software Engineering: A Practitioner'sApproach”, McGraw-Hill.

82GPMS 2017.01

Próxima Aula


Garantia de Qualidade

Verificação, Validação e Testes

Planejamento de Projetos

Gerência de Riscos

Monitoramento e Controle

Reutilização

Medição e Análise

Levantamento de Requisitos

Análise de Requisitos

Projeto Codificação

Comunicação

AtividadesGerenciais

Atividades de Desenvolvimento

Atividades de Apoio

Aquisição

Gerência de Projetos e Manutenção de Software

Aula 9 – Gerência de Configuração e Mudanças

Andréa Magalhães [email protected]

2017.01

gerência de projetos e manutenção de software aula 9...

Documents