Gerência de Projetos
e Manutenção de Software
Aula 9 – Gerência de Configuração e
Mudanças
2
Agenda
•
Rebobinando...
• Análise de Valor Agregado
•
Gerência de Configuração
• Controle de Versões • Gestão de Mudanças • Construção e Release
4
Análise de valor agregado
Medidas
• Custo orçado do trabalho programado (BCWS - Budgeted Cost of
Work Scheduled):
• Custo do trabalho previsto no cronograma para ser realizado em um
determinado período
• Quanto de trabalho deveria ter sido feito até agora
• Custo real do trabalho realizado (ACWP - Actual Cost of Work
Performed):
• Custo efetivamente incorrido ao executar o trabalho dentro do intervalo de
tempo sendo analisado
• Custo orçado do trabalho realizado (BCWP - Budgeted Cost of Work
Performed):
Análise de valor agregado
Medidas
Trabalho Programado (WS – Work Scheduled) Trabalho Realizado (WP – Work Performed) Custo Orçado (BC – Budget Cost) BCWS BCWPCusto Incorrido (AC
6
Análise de valor agregado
• Imagine o cenário do projeto abaixo• Valor-Hora de R$ 100,00 dos recursos = custo diário de R$ 800,00
Análise de valor agregado
• Imagine o cenário do projeto abaixo• Valor-Hora de R$ 100,00 dos recursos = custo diário de R$ 800,00
8
Análise de valor agregado
• Considere que 2 dias se passaram• Nenhum trabalho foi realizado (%Concluído = 0%)
BCWS indica o custo do trabalho que havia sido agendado. ACWP indica o custo do trabalho efetivamente realizado.
Comparação antiga: Se ACWP < BCWS, o projeto está custando menos do que o planejado, mas isto pode significar atraso.
Análise de valor agregado
• Considere que 2 dias se passaram• Algum trabalho foi realizado (ainda que não exatamente como o
10
Análise de valor agregado
• Mais um dia se passa (já são 3 dias)• A tarefa 1.1. não evolui e o gerente aumenta a duração para 3 dias
BCWS continua igual ao anterior, pois se baseia na baseline (2 dias) ACWP aumenta (3 dias de trabalho)
BCWP se mantém (80% do trabalho, considerando o tempo original) ACWP > BCWP, então temos aumento de custo no projeto
Análise de valor agregado
BCWP > BCWS
Projeto AdiantadoBCWP < BCWS
Projeto AtrasadoBCWP > ACWP
Projeto custando menosBCWP < ACWP
Projeto custando mais12
Análise de valor agregado
•
Day 0
•
Day 2 (sem replanejamento)
Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP
A 4 = 0,5 dia R$ 80,00 R$ 320,00 0% R$ 0,0 R$ 0,0 R$ 0,0 B 4 = 0,5 dia R$ 150,00 R$ 600,00 0% R$ 0,0 R$ 0,0 R$ 0,0 C 12 = 1,5 dia R$ 100,00 R$ 1.200,00 0% R$ 0,0 R$ 0,0 R$ 0,0
Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP
A 4 = 0,5 dia R$ 80,00 R$ 320,00 100% R$ 320 R$ 320 R$ 320
B 4 = 0,5 dia R$ 150,00 R$ 600,00 0% R$ 600 R$ 0,0 R$ 0,0
Análise de valor agregado
•
Day 2 (com replanejamento da tarefa C)
Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP
A 4 = 0,5 dia R$ 80,00 R$ 320,00 100% R$ 320 R$ 320 R$ 320
B 4 = 0,5 dia R$ 150,00 R$ 600,00 0% R$ 600 R$ 0,0 R$ 0,0
C 12 = 1,5 dia
24 = 3 dias R$ 100,00 R$ 1.200,00 50% R$ 1200 R$ 600 R$ 1200
ACWP > BCWP, então temos aumento de custo no projeto BCWP < BCWS, então temos um projeto atrasado
14
Análise de valor agregado
•
Day 0
•
Day 1
Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP
A 16 = 2 dias R$ 50,00 R$ 800,00 0% R$ 0,0 R$ 0,0 R$ 0,0 B 24 = 3 dias R$ 150,00 R$ 3.600,00 0% R$ 0,0 R$ 0,0 R$ 0,0 C 20 = 2,5 dias R$ 100,00 R$ 2.000,00 0% R$ 0,0 R$ 0,0 R$ 0,0
Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP
A 16 = 2 dias R$ 50,00 R$ 800,00 50% R$ 400 R$ 400 R$ 400
B 24 = 3 dias R$ 150,00 R$ 3.600,00 50% R$ 1.200 R$ 1.800 R$ 1.800
C 20 = 2,5 dias R$ 100,00 R$ 2.000,00 40% R$ 800 R$ 800 R$ 800
Tarefa B adiantada (BCWP > BCWS)
Análise de valor agregado
•
Day 1 (com replanejamento)
Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP
A 16 = 2 dias R$ 50,00 R$ 800,00 50% R$ 400 R$ 400 R$ 400
B 24 = 3 dias
16 = 2 dias
R$ 150,00 R$ 3.600,00 50% R$ 1.200 R$ 1.800 R$ 1.200
C 20 = 2,5 dias R$ 100,00 R$ 2.000,00 40% R$ 800 R$ 800 R$ 800
16
Dever de Casa
•
Faça a análise de valor agregado do
18
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
Problema dos Dados Compartilhados
Desenvolvedor A Desenvolvedor B
20
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
Problema dos Dados Compartilhados
-Solução simplista
•
Solução simplista:
•
Cada desenvolvedor trabalha em uma cópia
“local” do componente
•
Resolve o Problema dos Dados
Problema da Manutenção Múltipla
Componente Compartilhado
Desenvolvedor A Desenvolvedor B
A1 A2 A3 B1 B2 B3
Programa de A Componente Programa de B
Compartilhado Versão de A do Componente Compartilhado Componente Compartilhado Componente Compartilhado Versão de B do Componente Compartilhado
Problema da Manutenção Múltipla
(continuação)
• Ocorre quando cada desenvolvedor trabalha com uma
cópia “local” do que seria o mesmo componente
• Dificuldade para saber:
• Que funcionalidades foram implementadas em quais
versões do componente
• Que defeitos foram corrigidos
• Evitado através de uma biblioteca central de
componentes compartilhados
• Nesse esquema, cada componente é copiado para a
biblioteca sempre que alterado
Problema da Atualização Simultânea
Versão de A do Componente Compartilhado Desenvolvedor A Desenvolvedor B A1 A2 A3 B1 B2 B3Programa de A Versão de B do Programa de B
Componente Compartilhado Biblioteca Central de Recursos Compartilhados Componente Compartilhado
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
26
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
Como Resolver?
•
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
Introdução
•
A Engenharia de Software...
• Abordagem disciplinada para o desenvolvimento de software • Grande diversidade de metodologias
•
Ponto em comum nas metodologias:
30
Mas onde ficam esses artefatos?
Tarefas de Engenharia de Software Artefato novo Repositório Artefato modificado Artefato
O que são repositórios?
•
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
32
Gerência de Configuração
Desenvolvimento Liberação Implantação Produção
Gerência de Configuração
Gerência de configuração de software é uma
disciplina
para o
controle da evolução de sistemas de software
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
34
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
Sistema de Gerência de Configuração
Artefatos Controle de Construção Controle de Modificações Solicitações36
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
38
Tipos de Versão
Versão
Versão
Revisão
Revisão
Variante
Variante
Cooperação
(Rascunho)
Cooperação
(Rascunho)
(Conradi e Westfechtel 1998)Revisões
40
Variantes
Hatchback Coupe Sedan Honda CivicCooperação (versões rascunho)
Espaço de trabalho da Maria
Espaço de trabalho do Pedro
42
Versões de rascunho podem ser
combinadas (operação de
merge
)
João Maria Pedro
Conflitos podem ocorrer durante o
merge
44
Outras duas operações importantes…
… para guardar, transferir e compreender versões.
Diff =
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
46
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)
Tratamento de variantes em ramos
(
branches
)
•
Recurso muito poderoso
•
Devem existir regras bem definidas para
criação de
branches
•
Por que e quando devem ser criados?
•
Quais os passos?
•
Quando retornar ao fluxo principal?
•
Branches
normalmente se originam de
48
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 Evolução 2.0 RC Evolução Desenv.
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á
50
Exemplo
Terminologia
•
Check-in
: processo de revisão, aprovação e
cópia de um item de configuração para o
repositório
•
Check-out
: processo de requisição de
modificações, aprovação e cópia de um item de
configuração do repositório
•
A atualização de uma
baseline
consiste em
Check-Out
Check-out
Repositório cliente
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
Check-In
Check-in
Repositório cliente
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)
56
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
•
São estabelecidas ao final de cada fase de
desenvolvimento
– Análise (functional) – Projeto (allocated)
– Implementação (product)
•
Momento de criar:
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 controle58
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 Baseline 1: Projeto •An. Req. 1
Requisito 2 Análise Projeto
Tempo
Baseline 2:
•An. Req. 1 •Pr. Req. 1 •An. Req. 2
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
60
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
Principais sistemas de controle de
versão open-source
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
64
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)
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
66
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
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 no
processo 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
68
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
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
70
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,
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
72
Gestão de Mudanças
•
Análise de Modificação
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 se74
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
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 (e.g. falta de
treinamento, padrões inadequados, ferramentas
inadequadas)
76
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
78
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
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
80
Gestão de Mudanças
Ferramentas
•
Livre
• Bugzilla • Mantis • Redmine • Trac•
Comercial
• ClearQuest (IBM Rational) • JIRA (Atlassian)
• StarTeam (Borland)
• Synergy/Change (Telelogic)
• TeamTrack (Serena)
82
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
Terminologia
•
Release
:
• Conjunto de produtos que deve ser entregue ao
cliente
•
Releases
diferem de versões pois versões podem ser84
Os 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
Os Problemas na Geração de
Builds
•
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
86
Os 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
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 e88
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
Exemplo de ferramentas de
construção e release
•
Livre
•
Ant
•
NAnt
•
Make
•
Maven
•
Rake
•
Comercial
•
ClearMake (IBM Rational)
•
MSBuild (Microsoft)
90
Application Lifecycle Management
(ALM)
COS 823 - Aula 6 90
Collaborative Lifecycle Management
92
Collaborative Lifecycle Management
(CLM)
COS 823 - Aula 6 92 Out 2013 Requisitos Planejamento de Testes Gerenciamento de Defeitos Gerência de ConfiguraçãoExercí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
94
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's
Gerência de Projetos
e Manutenção de Software
Aula 9 – Gerência de Configuração e
Mudanças
Andréa Magalhães Magdaleno andrea@ic.uff.br
