GCM AulaI

Gerência de Configuração e Mudança de
Software
3/5/2006 GCM – MBA em Engenharia de Software

Conteúdo
• Primeira Aula –Conceitos Básicos e

Considerações de Implementação
• Segunda Aula – GCM na ótica COBIT
e ITIL
• Terceira Aula – GCM na ótica UCM e
noções de Ferramentas
• Quarta Aula – Exame.

Definição
• Gerência de Configuração e
Mudança é a arte de identificar,
organizar e controlar modificações
no software que está sendo
construído por uma equipe de
desenvolvimento.

Objetivos
• O objetivo é maximizar a produção,

minimizando os erros.
• Uma das bases da Engenharia de
Software.
• Usada para controlar o desenvolvimento
do produto e suas versões.
• Necessária para assegurar a qualidade do
software durante o desenvolvimento e a
manutenção operacional do produto.

Objetivos
• A GCM assegura que todas as pessoas

envolvidas no processo de software sabem o que
está sendo projetado, desenvolvido, construído,
testado e entregue. Através da GCM as
necessidades do projeto podem ser traçadas e
incorporadas ao produto de software final.
• Gerência de Configuração e Mudança de
Software previne o processo de software de se
tornar intratável, controlando as alterações e
mantendo a integridade do sistema.

A Importância da GCM numa
Organização
• A "Segunda Lei da Evolução do Software"
diz que, a não ser que passos sejam
seguidos para manter o controle do
sistema de software, a entropia do
sistema irá aumentar continuamente.
• Todas as organizações exercem alguma
forma de gerência de configuração de
software, apesar de muitas não
reconhecerem isso como tal.
A Importância da GCM numa
Organização
• A GCM dá meios aos desenvolvedores para
coordenar o trabalho de numerosas pessoas num
projeto comum tanto se eles trabalham próximos
uns aos outros quanto se espalhados por uma
grande área geográfica.
• Sem um bom plano de gerência de configuração
de software, os projetos podem, e irão, se tornar
cada vez mais difíceis de controlar e podem
atingir um ponto onde terão de ser
descontinuados por que o controle já estará
perdido.

CONCEITOS BÁSICOS

Identificação da Configuração
• A identificação e estruturação do plano de

gerência de configuração de software são
feitas quando o processo de software está
sendo definido.
• Itens de Configuração de Software (ICSs)
adicionados à GCM são coisas tais como
ferramentas, documentos de projeto,
especificações de requerimentos, etc.

Responsabilidades da GCM
• As responsabilidades da GCM
também são identificadas.
• Definir responsabilidades pode ser
tratado de diversas maneiras. Em
grandes projetos deve haver um
conselho de controle de mudanças,
com vários nomeados, para se
inspecionar as alterações.
ICS e Baselines
• Os ICSs identificados determinam a

“baseline” associada ao projeto.
• O número e tipos de baselines vai
depender do projeto.
• As baselines são o núcleo da GCM e
estabelecem uma plataforma estável para
se trabalhar.
• Só mudanças autorizadas podem ser
feitas nas baselines.

BASELINES
• Conceitos
• As-Planned E As-Released Baseline
• Conteúdo, Formato e Aplicações

Controle de Mudanças
• Os procedimentos de controle de mudanças

asseguram que as alterações no sistema são
controlados e seus efeitos no sistema podem ser
previstos.
• Para fazer mudanças, documentos de controle de
mudanças devem ser preenchidos.
• Eles devem conter informações como dados de
custos estimados, as datas de quando a
mudança foi requerida, aprovada, implementada
e validada.

• A informação dos documentos de controle

de mudanças devem ser definidas no
plano de GCM e são informação relevante
na base de dados da GCM.
• Uma vez que o documento seja submetido
para o responsável pelo controle de
mudanças (RCM), ele é então examinado
para ser validado e para se estimar o
impacto da mudança e seu custo.
• A mudança deve ser então aprovada ou

reprovada pelo RCM. Se ela for aprovada,
será incorporada ao software, e testes
regressivos serão feitos para se ter
certeza que a mudança não terá efeito em
outras partes do sistema.
• Devm ser mantidos logs de todas as
mudanças aprovadas e reprovadas. Isso
possibilita que um histórico seja gerado
quando requerido.
Relatório de Status da Configuração
• O Relatório de Status da Configuração é

um registro da gerência de configuração
de software.
• Na primeira vez que os ICSs são
identificados, todas as mudanças e o
status atual de mudanças e documentos
são guardados na base de dados do
relatório de status.

Relatório de Status
• A base de dados do relatório de status da

configuração guarda registros mostrando o
histórico dos produtos, como os produtos foram
desenvolvidos, e em que ponto o sistema está
em relação à baseline atual.
• A administração usa o relatório para rastrear e
relatar todos os ICSs formalmente identificados e
controlados.
• A base de dados do relatório de status também
mantém registros para apoiar a auditoria da GCM.

Relatório de Status
• Devido à grande quantidade de dados complexos

que o relatório rastreia, ele geralmente é um
processo automatizado.
• A geração de relatórios de status torna possível
para a gerência e os desenvolvedores avaliar as
mudanças no sistema.
• Os relatórios permitem que as pessoas se
comuniquem melhor, deixando-as verem o que as
outras pessoas estão fazendo e como as coisas
mudaram no projeto.

Auditorias e Revisões
• Auditorias e revisões são usadas para

assegurar que as mudanças foram
implementadas corretamente.
• A revisão formal busca a correção técnica
de qualquer item de configuração de
software (ICS) que tenha sido modificado.
• Um ICS é examinado para sejam
identificadas omissões, efeitos colaterais
potenciais, e sua consistência com outros
ICSs.
• Revisões formais são feitas em tudo, menos as

alterações mais triviais.
• A auditoria completa a revisão técnica,
examinando características do ICS que
geralmente não são consideradas durante a
revisão.
• Algumas dessas características são: se a revisão
formal foi feita, se todo o padrão de engenharia
de software foi seguido, se as alterações foram
identificadas, datadas e o autor foi especificado.

• A auditoria nos dá uma idéia de quão

próximo está o atual sistema de software
do sistema de software da baseline, e das
especificações de requerimentos.
• A auditoria nos dá um mecanismo para se
estabelecer uma nova baseline. No
estágio final de uma auditoria é
sancionada uma nova baseline.
• A verificação e a validação de quaisquer
mudanças ocorridas assegura que a
respectiva baseline
3/5/2006
é consistente com a
GCM – MBA em Engenharia de Software
baseline anterior.
• A auditoria e o estabelecimento de uma nova

baseline são uma das principais atividades que
asseguram a integridade do produro
• A auditoria aumenta a visibilidade do software e
proporciona a possibilidade de rastreamento.
Isso ajuda a evitar replanejamentos e re-
equipamentos custosos.
• Os desenvolvedores e o cliente são capazes de
usar a auditoria para concordar com o que foi
projetado e construído.

Relacionamento Entre essas Quatro
Áreas
• A Identificação da Configuração determina e registra os
itens de configuração de software (ICSs) no processo de
software.
• O Controle de Mudanças gerencia as alterações ocorridas
nos ICSs.
• O Relatório de Status nos dá uma visão instantânea do
status de todos os ICSs no sistema.
• A Auditoria e as Revisões verificam se todas as mudanças
nos ICSs do sistema foram feitas adequadamente, e
proporciona a criação de uma nova baseline quando todos
os ICSs passarem na verificação e na validação.

Automatização e GCM
• Por que automatização?

• quantia enorme de dados detalhados.
• difícil ou até impossível manter inspecionar
todos os items de configuração de software,
versões, código-fonte, e outros materiais
relacionados, sem alguma forma de base de
dados ou outra ferramenta automatizada.
• Ferramentas nos dão a capacidade de rastrear
modificações passadas e fazer a o teste de
regressão onde os componentes foram alterados.

Ferramentas para a GCM
• Antes de se decidir usar qualquer

ferramenta no projeto, todos os
requerimentos de gerência de software
locais devem ser determinados.
• A complexidade dos requerimentos irão
ajudar a determinar o tipo de ferramenta,
ou ferramentas, que o projeto irá
necessitar.

Ferramentas para a GCM
• Existem dúzias de fornecedores de ferramentas

para se escolher, e a escolha de uma
determinada ferramenta irá depender
exclusivamente do que o projeto necessita.
• SGBD
• OMS
• Traçadores de versões
• Controladores de Consistência
• Ferramentas de Construção

Desafios da GCM
• Desenvolvimento Remoto e Distribuído

• Múltiplas Versões
– Quantas versões existem?
Quando cada versão foi criada?
Que configuração de hardware e sistema operacional
são necessários para se rodar cada versão?
Cada versão deve manter registros de todos os
documentos, dados de teste, manuais de usuários, etc.
pertinentes a ela.
Se uma versão particular é alterada, quantas outras
versões serão afetadas pela alteração.
Quais clientes possuem cada versão?
• O problema “Where is used”

IMPLANTAÇÃO

KEY PLAYERS
• Documentador
• Técnico das Ferramentas
• Administrador de Dados
• Administrador de Versões
• Gerente de Desenvolvimento
• Gerente de Configurações
• Diretor de Gerenciamento de Configurações
INFLUÊNCIAS ORGANIZACIONAIS
• Quais as influências ocultas que podem pesar negativamente?

– Recursos financeiros
– Treinamento
– Agenda
– Patrocínio
– Atitude
– Territorialidade
• O que pode pesar positivamente em adição?
– Bom planejamento
– Práticas compartilhadas,
– Membros do time ensináveis

ESTRUTURAS ORGANIZACIONAIS PARA AS EQUIPES DE cm
• Organização Hierárquica
• Sem uma estrutura “real”
• Organizações matriciais

O PROCESSO CM
• Descreve, organiza e completa o trabalho de projeto

• Deve atender aos seguintes requisitos
– Acomodar mudanças
– Otimizar o reuso de padrões e melhores práticas
– Assegurar que todos os requisitos permaneçam claros, concisos e claros
– Assegurar a comunicação correta, tempestiva e precisa
– Assegurar a conformidade

INICIANDO O PROCESSO CM
• Recursos Financeiros
• Apoio e direcionamento gerencial
• Abordagem de Planejamento
– Se totalmente desenvolvido pelo CM exige um grande esforço de venda
posteriormente
– Desenvolvido pelo time
– Padronização

EXECUÇÃO DO PROCESSO CM
• Ditatorialmente
• Democraticamente
– Venda para a alta gerência
– Venda para os demais integrantes da organização
• Fechamento
– O principal objetivo do fechamento é permitir que o projeto possa ser reiniciado
onde quer que ele tenha parado se for requerido.
• Interações do Processo
• Fazendo acontecer
– Treinamento
– Coordenação
– Cooperação
• Áreas de Conhecimento

PLANEJAMENTO DO CM I
• Não é trivial
• Deve-se estabelecer como um processo crítico para o negócio
• Deve tratar:
– Dos produtos e serviços e os seus dados técnicos definidores
– Da infraestrutura do processos de negócios
• Recomenda-se uma abordagem em quatro fase:
– Preparação
– Transição
– Implementação/
– Adaptação/Melhoria Contínua
• Necessita de equipes multifuncionais

ESTRATÉGIA DE IMPLEMENTAÇÃO I
• 12 PASSOS
– Step 1 – Compra da alta gerência
– Step 2 – Estabelecimento de Políticas
– Step 3 – Definição de Requisitos
• Requisitos de Negócios
• Requisitos de Produtos e Serviços

ESTRATÉGIA DE IMPLEMENTAÇÃO
II
• Step 4 – Requisitos de Documentação
– ISO 9000 afirma:" Document what you do; Do what
you documented."
– CMMI vai além: :" A Requirement is not a
requirement unless it is documented, validated and
released."
– Deve-se documentar os requisitos de gerenciamento,
as políticas organizacionais e de gerencioamento de
configurações, os padrões e procedimentos.

PIRÂMIDE DOCUMENTAL

III
• Step 5 – Definir padrões terminológicos e

acrônimos
• Step 6 – Criar um Plano de CM
• Step 7 – Estruturar Requisitos
• Step 8 – Implementar um Processo CM
• Step 9 – Medir Performance

MÉTRICAS I
• São fundamentais para o aperfeiçoamento

constante e para administrar os riscos
• Uma métrica consiste em:
– uma definição operacional
– na coleção de registros de dados reais
mensurados
– Na apresentação dos dados mensurados numa
formato amigável
MÉTRICAS II
• Ela é significativa e compreensível

• Relaciona-se com as metas e objetivos
organizacionais
• É tempestiva, simples, lógica, repetível,
bem definida, econômica
• Mensurável ao longo do tempo

Métricas
• As métricas que podem ser coletadas e registradas para a GCM devem ser
abrangentes. Algumas delas são:
– Número total de alterações completadas.
Número de alterações solicitadas que estão sendo tratadas.
Número de alterações rejeitadas
Número atual de versões.
Histórico de modificações dos ICSs
Identidade do ICS
Autor
Data de criação
Data da modificação
Modificações feitas.
Nome da pessoa que modificou
Razão da alteração
Dados de todos os testes.
Status de bugs atual .

IV
• Step 10 – Instituir um Plano de Auditoria de

CM interno e executar pré auditorias
internas
• Step 11 – Definir o STAFF
• Step 12 – Definir as Ferramentas
Automatizadas

PLANEMANTO DE CM II
• Deve-se atentar para o 5W1H

• Deve-se levar em consideração os outros
padrões e planos organizacionais.
• Deve-se buscar um padrão que melhor
atenda a organização
• Requer acima de tudo educação e venda
• Deve ser revisto e atualizado
periodicamente
FERRAMENTAS DE CM I
• Version Control Automation Tools (VCATs

• Automated Problem Report Tracking Tools
(APRTT)
• Library Automation Tools (LATs)
• Work Flow Management Tools (WFMTs)
• Requirements Management Tool (RMT)

FERRAMENTAS DE CM II
• Entenda o seu ambiente

• Encontre o que pode se beneficiar da
automação
• Especifique suas necessidades e requisitos
• Realize test drives
• Somente então tome a decisão

FERRAMENTAS DE CM III
• Outras considerações
– APIS
– Manipulação de Gatilhos
– Integração com outras ferramentas de
desenvolvimento e SGBDS

ATIVIDADES CM CRÍTICAS
• Planning
• Acquisition and Support
• Configuration Identification
• Configuration Control
• Configuration Status Accounting
• Configuration Audits

PRINCÍPIOS PARA A IDENTIFICAÇÃO
DE CONFIGURAÇÃO
• Determines the structure (hierarchy) of a product and the organization and relationships of its
configuration documentation and other product information
• Document the performance, interface, and other attributes of a product
• Determines the appropriate level of identification marking of product and documentation
• Provides unique identity to a product or to a component part of a product
• Provides unique identity to the technical documents describing a product
• Modifies identification of product and documents to reflect incorporation of major changes
• Maintains release control of documents for baseline management
• Enables a user or a service person to distinguish between product variantions
• Enables a user or a service person to correlate a product to related user or maintenance
instructions
• Facilitates management of information including that in digital format
• Correlates individual product units to warranties and service life obligations
• Enables correlation of document revision level to product version/configuration
• Provides a reference point for defining changes and corrective actions.

Estrutura de um Plano de Instalação de
GCM
• Escopo e propósito.
Organização e recursos.
Atividades de GC para:
– Identificação
– Controle de Mudanças
– Relatório de Status
– Auditorias
– Controle de Interface
– Agenda de GCM
– Notas e Apêndices
Escopo e propósito:
• Descrevem o produto a ser

construído, as necessidades do
cliente. Essa seção pode incluir uma
visão geral do processo de Gerência
de Configuração.

Organização e recursos:
• Para montar um plano de GCM o

gerente de configuração deve estar
familiarizado com as necessidades
da organização. O tamanho do
projeto e os recursos alocados para
ele irão determinar o quão
abrangente o plano de GCM será.

Atividades de GC:
• Identifica todos os documentos e itens de configuração de software (ICSs) que

estarão sob controle da GCM, tais como: planos de projeto, especificações, projetos,
programas, ferramentas, e suítes de teste.
• Define um esquema de nomeação de documentos e mostra inter-relações entre os
ICSs.
• Delega e define responsabilidades para o controle de mudanças.
• Redigi procedimentos para o controle de mudanças, a construção do sistema, e o
controle de versões.
• Controle de interface: Especifica como os documentos de interface (interface entre
computadores) serão revisados e entregues ao controle de configuração.
• Agendas de GC: Rastreiam o progresso do plano de gerência de configuração.
Quando o plano estiver completo, ele deve garantir a rastreabilidade e a integridade,
e proteger a baseline durante todo o ciclo de vida.

Conclusão
• A Gerência de Configuração de Software deve ser uma etapa

chave de qualquer projeto de software.
• O grau de gerência de configuração usado irá depender do
tamanho do projeto e dos recursos disponíveis para o
desenvolvedor.
• Ele tem de ser sempre um meio-termo entre muito controle e
controle insuficiente. Muito controle irá atolar o projeto em
burocracia.
• Controle insuficiente irá fazer com que o projeto escape do
controle dos desenvolvedores e nunca seja completado.
• O plano de GCM deve ser flexível o suficiente para permitir
modificações durante todo o ciclo de vida do projeto.
• A GCM requer esforço e recursos, mas os resultados valem a
pena.

GCM AulaI

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GCM AulaI

Uploaded by

Copyright:

Available Formats

Gerência de Configuração e Mudança de

3/5/2006 GCM – MBA em Engenharia de Software

• Primeira Aula –Conceitos Básicos e

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• O objetivo é maximizar a produção,

3/5/2006 GCM – MBA em Engenharia de Software

• A GCM assegura que todas as pessoas

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• A identificação e estruturação do plano de

3/5/2006 GCM – MBA em Engenharia de Software

• Os ICSs identificados determinam a

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• Os procedimentos de controle de mudanças

3/5/2006 GCM – MBA em Engenharia de Software

• A informação dos documentos de controle

• A mudança deve ser então aprovada ou

• O Relatório de Status da Configuração é

3/5/2006 GCM – MBA em Engenharia de Software

• A base de dados do relatório de status da

3/5/2006 GCM – MBA em Engenharia de Software

• Devido à grande quantidade de dados complexos

3/5/2006 GCM – MBA em Engenharia de Software

• Auditorias e revisões são usadas para

• Revisões formais são feitas em tudo, menos as

3/5/2006 GCM – MBA em Engenharia de Software

• A auditoria nos dá uma idéia de quão

• A auditoria e o estabelecimento de uma nova

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• Por que automatização?

3/5/2006 GCM – MBA em Engenharia de Software

• Antes de se decidir usar qualquer

3/5/2006 GCM – MBA em Engenharia de Software

• Existem dúzias de fornecedores de ferramentas

3/5/2006 GCM – MBA em Engenharia de Software

• Desenvolvimento Remoto e Distribuído

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• Quais as influências ocultas que podem pesar negativamente?

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• Descreve, organiza e completa o trabalho de projeto

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• Step 5 – Definir padrões terminológicos e

3/5/2006 GCM – MBA em Engenharia de Software

• São fundamentais para o aperfeiçoamento

• Ela é significativa e compreensível

3/5/2006 GCM – MBA em Engenharia de Software

3/5/2006 GCM – MBA em Engenharia de Software

• Step 10 – Instituir um Plano de Auditoria de

3/5/2006 GCM – MBA em Engenharia de Software

• Deve-se atentar para o 5W1H

• Version Control Automation Tools (VCATs