Você está na página 1de 54

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.

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


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.

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


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.

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


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.

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


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.
3/5/2006 GCM – MBA em Engenharia de Software
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.

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


CONCEITOS BÁSICOS

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


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.

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


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.
3/5/2006 GCM – MBA em Engenharia de Software
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.

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


BASELINES

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

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


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.

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


Controle de Mudanças

• 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.
3/5/2006 GCM – MBA em Engenharia de Software
Controle de Mudanças

• 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.
3/5/2006 GCM – MBA em Engenharia de Software
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.

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


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.

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


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.

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


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.
3/5/2006 GCM – MBA em Engenharia de Software
Auditorias e Revisões

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

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


Auditorias e Revisões

• 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.
Auditorias e Revisões

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

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


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.

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


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.

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


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.

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


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

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


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”

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


IMPLANTAÇÃO

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


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
3/5/2006 GCM – MBA em Engenharia de Software
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

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


ESTRUTURAS ORGANIZACIONAIS PARA AS EQUIPES DE cm

• Organização Hierárquica
• Sem uma estrutura “real”
• Organizações matriciais

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


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

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


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

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


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

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


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

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


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

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


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.

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


PIRÂMIDE DOCUMENTAL

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


ESTRATÉGIA DE IMPLEMENTAÇÃO
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

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


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
3/5/2006 GCM – MBA em Engenharia de Software
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

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


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 .

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


ESTRATÉGIA DE IMPLEMENTAÇÃO
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

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


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
3/5/2006 GCM – MBA em Engenharia de Software
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)

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


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

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


FERRAMENTAS DE CM III

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

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


ATIVIDADES CM CRÍTICAS

• Planning
• Acquisition and Support
• Configuration Identification
• Configuration Control
• Configuration Status Accounting
• Configuration Audits

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


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.

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


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
3/5/2006 GCM – MBA em Engenharia de Software
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.

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


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á.

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


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.

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


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.

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