Aula10 GerenciaConfiguracaoMudancas

Prévia do material em texto

Gerência de Projetos 
e Manutenção de Software 
Aula 10 – Gerência de Configuração e 
Mudanças
Andréa Magalhães Magdaleno
andrea@ic.uff.br
2016.02
2GPMS 2016.02
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 2016.02
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çada
Desenvolvedor A Desenvolvedor B
Desenvolvedor C
Problema dos Dados Compartilhados
Componente
Compartilhado
Desenvolvedor A Desenvolvedor B
A1 A2 A3
Programa de A Programa de B
B1 B2 B3
6GPMS 2016.02
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 2016.02
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
Componente
Compartilhado
Desenvolvedor A Desenvolvedor B
A1 A2 A3 B1 B2 B3
Programa de A Programa de BComponente
Compartilhado
Versão de A do 
Componente
Compartilhado
Componente
Compartilhado
Componente
Compartilhado
Versão de B do 
Componente
Compartilhado
9GPMS 2016.02
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 2016.02
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
Desenvolvedor A Desenvolvedor B
A1 A2 A3 B1 B2 B3
Programa de A Programa de BVersão de B do 
Componente
Compartilhado
Biblioteca Central de 
Recursos Compartilhados
Componente
Compartilhado
12GPMS 2016.02
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 2016.02
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 2016.02
Problema da Atualização Simultânea
Soluçã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 2016.02
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 disciplina
para o controle da evolução de sistemas de software
(Susan Dart, 1991)
17GPMS 2016.02
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 2016.02
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 2016.02
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 2016.02
Sistema de Gerência de Configuração
Artefatos
Controle de 
Versões
Construção 
e Release
Controle de 
Modificações
Solicitações
21GPMS 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
Tipos de Versão
VersãoVersão
RevisãoRevisão VarianteVariante
Cooperação 
(Rascunho)
Cooperação 
(Rascunho)
(Conradi e Westfechtel 1998)
30GPMS 2016.02
Revisões
Gerações do iMac (1998 – 2013)
31GPMS 2016.02
Variantes
Hatchback
Coupe
Sedan
Honda Civic
32GPMS 2016.02
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 2016.02
Versões de rascunho podem ser 
combinadas (operação de merge)
João Maria Pedro
Revisões
34GPMS 2016.02
Conflitos podem ocorrer durante o 
merge
João Paulo
Revisões
35GPMS 2016.02
Outras duas operações importantes…
… para guardar, transferir e compreender versões.
Diff =
Patch =
36GPMS 2016.02
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 2016.02
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 2016.02
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 2016.02
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. 1
1.0 1.1 1.2
Rel. 2
2.0 2.1
Verif. Verif.
1.0 RC 2.0 RCEvolução EvoluçãoDesenv.
Correção Correção Correção
40GPMS 2016.02
Merge
• Unificação de diferentes versões de um mesmo item de 
configuração
• Integração dos itens de configuração de um branch
com os itens de configuração do fluxo principal
• 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 2016.02
Exemplo
(merge no Eclipse)
42GPMS 2016.02
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 2016.02
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 2016.02
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 Projeto
Baseline 1:
•An. Req. 1
Requisito 2 Análise Projeto
Tempo
Baseline 2:
•An. Req. 1
•Pr. Req. 1
•An. Req. 2
45GPMS 2016.02
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 2016.02
Plano de GC - Exemplo
 
BASELINES 
 BASELINE: 
Dt PREVISTA: 
Dt REAL: 
BASELINE: 
Dt PREVISTA: 
Dt REAL: 
BASELINE: 
Dt PREVISTA: 
Dt REAL: 
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 2016.02
Principais sistemas de controle de 
versão open-source
GESTÃO DE MUDANÇAS
49GPMS 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
Gestão de Mudanças
• 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 2016.02
Gestão de Mudanças
• Solicitação de Modificação
58GPMS 2016.02
Gestão de Mudanças
• 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 2016.02
Gestão de Mudanças
• Análise de Modificação
(Leon, 2000)
60GPMS 2016.02
Gestão de Mudanças
• 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 2016.02
Gestão de Mudanças
• 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 2016.02
Gestão de Mudanças
• 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 2016.02
Gestão de Mudanças
• 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 2016.02
Gestão de Mudanças
Resultado do relatório no modo tabular no Bugzilla
65GPMS 2016.02
Auditoria da configuração
• Deve ocorrer ao menos antes de uma liberação 
(release)
• Tarefas
• Verificação funcional, assegurando que a baseline
cumpre 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 2016.02
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 2016.02
Gestão de Mudanças
Ferramentas
• 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 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
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 2016.02
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: Releasesmuito curtas podem levar a círculo-
vicioso de defeitos...
75GPMS 2016.02
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 2016.02
Application Lifecycle Management
(ALM)
COS 823 - Aula 6 76Out 2013
77GPMS 2016.02
Collaborative Lifecycle Management
(CLM)
COS 823 - Aula 6 77Out 2013
78GPMS 2016.02
Collaborative Lifecycle Management
(CLM)
COS 823 - Aula 6 78Out 2013
Requisitos
Planejamento de Testes
Gerenciamento 
de Defeitos
Gerência de 
Configuração
79GPMS 2016.02
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 2016.02
Dúvidas?
81GPMS 2016.02
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. VersionModels 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's
Approach”, McGraw-Hill.
82GPMS 2016.02
Próxima Aula
Gerência de 
Configuração
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
Atividades
Gerenciais
Atividades de 
Desenvolvimento
Atividades de 
Apoio
Aquisição
Gerência de Projetos 
e Manutenção de Software 
Aula 10 – Gerência de Configuração e 
Mudanças
Andréa Magalhães Magdaleno
andrea@ic.uff.br
2016.02