Gerncia de configurao de software

Origem: Wikipdia, a enciclopdia livre.

Gerncia de configurao de software, gerncia de configurao ou ainda gesto de configurao de

software uma rea da engenharia de software responsvel por fornecer o apoio para o desenvolvimento de
software. Suas principais atribuies so o controle de verso, o controle de mudana e a auditoria das
configuraes. Roger Pressman, em seu livro Software Engineering: A Practitioner's Approach, especfica que
a gerncia de configurao de software (GCS) o:

conjunto de atividades projetadas para controlar as mudanas pela identificao dos produtos do
trabalho que sero alterados, estabelecendo um relacionamento entre eles, definindo o
mecanismo para o gerenciamento de diferentes verses destes produtos, controlando as
mudanas impostas, e auditando e relatando as mudanas realizadas.
ndice
1 Contextualizao
2 Objetivos
3 Termos
3.1 Software Configuration
3.2 Baseline
3.3 Software Configuration Item
3.4 Object Manufacturing
4 Gerncia de mudanas
4.1 Versionamento
4.1.1 Controle de verses dos itens do projeto
4.1.2 Diferentes verses de projeto
4.1.3 Sincronizao de mudanas concorrentes
4.1.4 Problema do compartilhamento de arquivos
4.2 Conjunto de mudanas
4.3 Histrico de alteraes
5 Auditoria de configurao
5.1 Executar auditoria de configurao fsica
5.2 Outros nveis da auditoria de configurao fsica
5.3 Executar auditoria de configurao funcional
5.4 Reportar descobertas
6 Maneira de realizao
7 Referncias
8 Bibliografia
9 Ver tambm
10 Ligaes externas

Contextualizao
A histria da gerncia de configurao de software surge em meados da dcada de 1970, quando os
microprocessadores se tornaram populares e o software deixou de ser considerado parte integrante do hardware
para se tornar um produto independente. Nesta poca, os sistemas se tornaram cada vez maiores e sofisticados,
ficando claro que seriam necessrias metodologias prprias, diferentes das usadas no desenvolvimento de
hardware, para controlar o desenvolvimento desses sistemas.
O Departamento de Defesa (DoD) dos EUA foi um dos pioneiros nessa rea, criando o padro DoD-STD-2167
que abordava o desenvolvimento de software. A abordagem do DoD para controlar isto consistia da adoo de
uma linguagem padronizada -- Adae de prticas padro para desenvolvimento de software e gerncia de
configurao.

Outras organizaes estavam por sua vez adotando prticas e mtodos de gerncia de configurao de software,
algumas das quais envolvidas tambm com o desenvolvimento de sistemas para o DoD e outros rgos do
governo Americano. Isto levou o prprio DoD a adotar algumas prticas comerciais e eventualmente uni-las
com seus padres, gerando assim o padro IEEE/IEA 12207. Um outro padro a respeito o IEEE 828-1983.

Objetivos
No incio do desenvolvimento, a GCS permite equipe de desenvolvimento identificar as unidades que
compem o sistema de acordo com as funcionalidades que elas devero desempenhar, e as interfaces entre estas
unidades, documentando assim a interao entre elas. O controle contnuo da evoluo destas funcionalidades e
interfaces permite que a integrao entre estas unidades tenha sucesso continuado, com as mudanas
devidamente gerenciadas e documentadas. Por fim, a auditoria das funcionalidades identificadas,
documentadas e controladas garante a confiabilidade do sistema.

Termos
A terminologia especifica da GCS, como tambm sua histria, tem dado origem a controvrsias, de freqentes
variaes. Ferramentas vendidas como tambm acadmicas tiraram vantagem disto para deliberadamente
mudar a terminologia ou procedimentos para reduzir a possibilidade dos clientes para mudanas, algumas vezes
tentando desta maneira redefinir o estabelecimento de acrnimos.

Em particular, o vendedor conhecido como Atria (depois Rational Software), agora uma parte da IBM, usava
SCM como padro para Software Configuration Management (em portugus: "Gerncia de Configurao de
Software") enquanto o Gartner Group usa o termo SCCM ou Software Change and Configuration Management
(em portugus: "Gerncia de Mudanas e Configurao de Software").

Entretanto, os conceitos bsicos da GCS descritos abaixo so bem aceitos, divergindo de um autor ou
fornecedor para o outro meramente nos termos utilizados.

Software Configuration

Configurao o estado do conjunto de itens que formam o sistema em um determinado momento [1] (https://
blog.pronus.io/posts/o-que-eh-gerencia-de-configuracao-de-software/). Este sistema pode ser composto de todo
tipo de elementos, como peas de hardware, artefatos eletrnicos ou no (i.e. documentos em papel), etc. A
configurao de software trata apenas dos elementos que se encontram em formato eletrnico e fazem parte
dessa configurao. Isso inclui todos os arquivos fontes, todos os documentos eletrnicos, as ferramentas de
software utilizadas para construir ou mesmo ler estes arquivos, o sistema operacional utilizado, as bibliotecas
de software, etc.

Essa configurao varia com o tempo, pois novos arquivos so includos, e arquivos existentes so alterados ou
removidos. O objetivo da gerncia de configurao como um todo organizar todos estes elementos de forma a
saber em qual estado o sistema se encontrava nos momentos chave do desenvolvimento (por exemplo, quando
o sistema foi entregue ao cliente, quando o sistema passou por uma mudana de verso, quando o sistema foi
enviado para auditoria, etc). A gerncia de configurao como um todo trata dos elementos, incluindo
hardware, necessrios para a manuteno apropriada do sistema. A gerncia de configurao de software trata
especificamente dos elementos necessrios construo de sistemas de software, e em geral, controla apenas os
elementos em formato computadorizado.
Em sistemas de controle de verso as configuraes especficas so geralmente identificadas pelo uso de tags
ou labels (etiquetas ou rtulos, em ingls).

Baseline

Linha-base ou baseline um conceito de gerenciamento de configurao de software que nos ajuda a controlar
as mudanas, sem impedir seriamente as mudanas justificveis. Segundo PRESSMAN no contexto de
engenharia de software, definimos uma linha-base como um marco de referncia no desenvolvimento de um
software, que caracterizado pela entrega de um ou mais itens de configurao (em ingls, Software
Configuration Items - SCIs) e pela aprovao desses SCIs, obtida por meio de uma reviso tcnica formal.

Exemplos de linhas-base:

Verso 1.0
Verso de correo de erros 1.1
Verso personalizada do sistema para o governo americano

Em Sistemas de controle de verso uma linha-base geralmente identificada pelo uso de branches (ramos, em
ingls).

Software Configuration Item

Durante o desenvolvimento de software, uma grande quantidade de informaes produzida e cada um desses
documentos produzidos que precisam sofrer controle de verses e de mudanas chamado de item de
configurao de software O Item de configurao um elemento unitrio que ser gerenciado: um arquivo de
cdigo fonte, um documento de texto, um projeto de uma placa eletrnica, uma planta feita em papel, um CD-
ROM de instalao de um sistema operacional, etc. A configurao de um sistema basicamente a lista de
todos os itens de configurao necessrios para reproduzir um determinado estado de um sistema. Em geral
nmeros de verso so associados aos itens de configurao de forma a podermos identificar tambm a
evoluo destes itens.

Exemplos de itens de configurao podem ser:

Item A: CD de instalao do sistema operacional, verso 1.0

Item B: Documento de ajuda do sistema em formato eletrnico, verso 2.0
Item C: Processador de texto usado para imprimir o documento de ajuda, verso 5.0

e assim por diante.

Segundo Pressman os seguintes SCIs tornam-se alvos das tcnicas de GCS e formam um conjunto de linhas
bsicas (baselines):

1. Especificao do Sistema.

2. Plano de Projeto do Software.

3. a) Especificao dos Requisitos de Software; b) Prottipo executvel ou "em papel".

4. Manual Preliminar do Usurio.

5. Especificao de Projeto: a) Descrio do projeto de dados; b) Descries do projeto arquitetural; c)

Descries do projeto modular; d) Descries do projeto de interfaces; e) Descries de objetos (no caso do uso
da metodologia OO).

6. Listagem do cdigo-fonte.

7. Teste de Software/Sistema: a) Plano e Procedimentos de Testes; b) Casos de teste e resultados registrados.

8. Manuais Operacionais e de Instalao.

9. Programa Executvel: a) Mdulos; b) Mdulos interligados.

10. Descrio do Banco de Dados: a) Esquema e estrutura de arquivo; b) Contedo inicial.

11. Manual Feito de Acordo com o Usurio.

12. Documentos de Manuteno: a) Relatrios de problemas de software; b) Solicitaes de manuteno; c)

Pedidos de mudana de engenharia.

13. Padres e procedimentos para engenharia de software.

Object Manufacturing

Definimos SCI, no mecanismo de identificao de gerenciamento de configuraes, como sendo a sua entidade
mais elementar.

Segundo PRESSMAN dois tipos de objetos podem ser identificados:

Objeto bsico: uma "unidade de texto" que foi criada pelo engenheiro de software durante a anlise, o
projeto, a codificao ou o teste.
Objeto composto: coleo de objetos bsicos e outros objetos compostos.

Cada objeto tem um conjunto distinto de caractersticas que o identifica unicamente: um nome, uma descrio,
uma lista de recursos e uma realizao.

Nome: cadeia de caracteres que identifica o objeto claramente.

Descrio: uma lista de itens de dados que identifica: - O tipo de SCI (ex.: documento, programa,
dados) que representado pelo objeto; - Um identificador do projeto; - Informaes sobre mudanas e/ou
verso
Recursos: entidades fornecidas, processadas, consultadas ou, por outro lado, exigidas pelo objeto.

Para um objeto bsico, a realizao um indicador para a "unidade texto" e para o objeto composto a realizao
nula.

Gerncia de mudanas
A gerncia de mudanas uma parte geralmente negligenciada da Gerncia de configurao. Como ela no tem
resultados imediatos para os desenvolvedores e engenheiros de software envolvidos no projeto, estes acabam
por no perceber sua importncia. Gerncia de mudanas entretanto uma parte importante da Gerncia de
configurao, pois a atividade que permite se saber o motivo de uma configurao ter sido mudada para outra
configurao. Esta atividade tambm pode ser parcialmente automatizada, e diversos sistemas de controle de
verso j so integrados com sistemas de gerncia de mudanas. A gerncia de mudanas tem por objetivo
mapear, para cada mudana efetuada no sistema, qual foi o motivo que gerou esta mudana. comum vermos
em sistemas de software arquivos que listam as melhorias e mudanas entre duas verses. Estes arquivos so
resultado da gerncia de mudanas, identificando o que mudou entre uma verso e outra.

Exemplos

mudana da verso 1.0 para 1.1 inclui:

correo do problema 355
correo do problema 356
correo do problema 358
nova funcionalidade de impresso de relatrios
pendncias para a verso 1.2:
correo das mudanas 357 e 359.
 impresso de relatrios coloridos.

Versionamento

Ocorrem muitos problemas durante o desenvolvimento de software que so causados por falta de controle sobre
os arquivos do projeto.

Vamos a uma avaliao [2] (https://blog.pronus.io/posts/conceitos-basicos-de-controle-de-versao-de-software-c

entralizado-e-distribuido/):

Voc j perdeu alguma verso anterior do arquivo do projeto?

J teve problemas em manter diferentes verses do sistema rodando ao mesmo tempo?
Algum j sobrescreveu o seu cdigo por acidente e voc acabou perdendo seu arquivo?
Voc tem dificuldades em saber quais as alteraes que foram efetuadas e quando foram feitas e quem
fez?

Se voc respondeu que sim para as perguntas acima, ento voc precisa de um sistema para controle de verso
para o seu projeto. Controle de verso deve ser utilizado em todo o andamento do projeto de desenvolvimento
de software.

O controle de verso rastreia e controla todos os artefatos do projeto (cdigo-fonte, arquivos de configurao,
documentao etc.) e assim consegue coordenar o trabalho paralelo de desenvolvedores atravs das seguintes
funcionalidades:

Mantm e disponibiliza cada verso j produzida de cada item do projeto

Possui mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existncia de
diferentes verses ao mesmo tempo (concorrncia)
Estabelece uma poltica de sincronizao de mudanas que evita a sobreposio de mudanas
Fornece um histrico completo de alteraes sobre cada item do projeto

Controle de verso resolve diversos problemas bsicos de desenvolvimento tais como uso de diferentes verses
de cdigo, sincronizao do trabalho paralelo de desenvolvedores no mesmo projeto, recuperao de verses
anteriores e registro do histrico de alteraes.

A finalidade do controle de verso dar um controle maior sobre tudo que voc altera no seu projeto de
software. Ele permite que voc tenha um histrico de tudo o que voc mudar no seu projeto. Se voc modificou
aquela rotina para otimizar uma consulta, se voc inseriu uma nova funo e retirou outra, se voc modificou a
imagem que era exibida em determinada pgina html, tudo fica guardado neste histrico. Para que isso? Para o
caso de sua alterao causar algum problema! Se deu voc nem precisa se preocupar em relembrar o que foi
que tinha alterado, se fez tudo correto, basta um simples comando e voc recupera o estado anterior.

Controle de verses dos itens do projeto

Todos os arquivos e diretrios que compem o projeto ficam sob a responsabilidade do sistema de controle de
verso num local denominado de repositrio, lugar onde se guarda, arquiva, coleciona alguma coisa. o local
onde voc vai guardar o seu projeto. Na prtica, um diretrio, uma pasta qualquer guardada ou no seu
computador, ou no seu pendrive. O repositrio registra cada alterao realizada em cada arquivo e diretrio
controlado. medida que o projeto evolui, o repositrio passa a guardar mltiplas verses dos arquivos que
compem o projeto. Essas mltiplas verses so organizadas em revises. Uma reviso funciona como um
clone de todos os arquivos do projeto em um determinado momento do tempo. Os clone antigos so mantidos e
podem ser recuperados e analisados a qualquer momento. Para economizar espao, apenas as diferenas entre
as revises costumam ser armazenadas no repositrio. Quando se deseja recuperar determinado arquivo, as
diferenas so analisadas e o arquivo remontado de acordo com a reviso desejada. Mesmo que no haja
alterao em um arquivo entre uma reviso e outra, o nmero da reviso do arquivo acompanha o nmero da
reviso global, de modo a manter sempre um grupo coeso e coerente de arquivos.
Diferentes verses de projeto

Alguns projetos precisam de variaes especficas, conforme as necessidades especficas de cada cliente, ou
criao de um ramo para experimentaes no projeto, sem comprometer a linha principal de desenvolvimento.
O sistema de controle de verso oferece funcionalidades que facilitam a coordenao de ramos diferentes de
desenvolvimento em um mesmo projeto. As alteraes feitas em um ramo muitas vezes precisam ser mescladas
em outro ramo. Essa operao bastante delicada e facilitada em muito com o sistema de controle de verso,
que permite bastante controle e automao no processo. Mesmo em caso de uma fuso malsucedida, o sistema
de controle de verso permite voltar ao estado anterior, o que traz bastante segurana aos desenvolvedores.

Sincronizao de mudanas concorrentes

Como os desenvolvedores trabalham em paralelo e concorrentemente nos mesmos arquivos do projeto,

necessria uma poltica para ordenar e integrar todas essas alteraes, de modo a evitar que um desenvolvedor
sobrescreva as alteraes de outro desenvolvedor.

O controle de verso alm de rastrear e controlar alteraes, tambm coordena a edio colaborativa e o
compartilhamento de dados entre os vrios desenvolvedores de uma equipe.

Problema do compartilhamento de arquivos

Cpia de trabalho

Os desenvolvedores no trabalham diretamente nos arquivos do repositrio. Cada desenvolvedor possui uma
cpia de trabalho que espelha os arquivos do repositrio para trabalhar com liberdade enquanto termina suas
tarefas, isolado dos outros desenvolvedores.

Poltica TRAVA-MODIFICA-DESTRAVA

Nessa poltica, o sistema de controle de verso permite que apenas um desenvolvedor por vez altere um
determinado arquivo do projeto. Ela restritiva e frequentemente atrapalha o trabalho dos usurios. O
travamento pode causar alguns problemas administrativos e forar a uma serializao desnecessria.

Poltica COPIA-MODIFICA-RESOLVE

Nessa poltica, no existe travamento de arquivos. Cada desenvolvedor trabalha livremente em qualquer
arquivo da sua cpia de trabalho. Ao final, as alteraes de cada desenvolvedor so mescladas no repositrio
formando a verso final. A soluo "copia-modifica-resolve" parece um pouco estranha e bagunada a
princpio, mas funciona bem na prtica. Conflitos so raros e so causados basicamente pela falta de
comunicao entre desenvolvedores. Na grande maioria dos casos, as alteraes no se sobrepe e so
mescladas automaticamente pelo sistema de controle de verso.

Conjunto de mudanas

o conjunto de todas as alteraes que ocorreram no sistema para atender um determinado fim, ou num
determinado perodo de tempo. Fazendo um mapeamento dos itens que foram mudados para uma dada verso
do sistema com os motivos das mudanas. Um exemplo de conjunto de mudanas:

Mudanas da verso 1.0 para a verso 1.1

Item A mudou da reviso 1.0 para a reviso 1.1

Item B mudou da reviso 4.5 para a reviso 5.0
Item C foi eliminado
Item D foi acrescentado na reviso 5.5
Item E mudou de nome para item F.
Histrico de alteraes

Como o repositrio registra todas as alteraes que foram efetuadas, o sistema de controle de verso pode
informar com facilidade quais as alteraes que foram realizadas entre uma reviso e outra, quando isso
ocorreu e quem fez as alteraes. Essas informaes permitem um controle maior sobre mudanas no projeto.

Auditoria de configurao
Executar auditoria de configurao fsica

Uma auditoria de configurao fsica (PCA) identifica os componentes de um produto que sero implantados
do Repositrio do Projeto. Os passos so:

Identificar a baseline a ser implantada (geralmente apenas um nome e/ou nmero, mas tambm pode
ser uma lista completa de todos os componentes e suas respectivas verses).
Confirmar que todos os artefatos necessrios, conforme especificado pelo Caso de Desenvolvimento,
esto presentes na baseline. Liste os artefatos ausentes em Descobertas da Auditoria de Configurao.

Outros nveis da auditoria de co nfigurao fsica

Algumas organizaes usam uma Auditoria de Configurao Fsica para confirmar a consistncia do design
e/ou documentao do usurio com o cdigo. O Rational Unified Process recomenda que a verificao dessa
consistncia seja executada como parte da atividade de reviso no decorrer do processo de desenvolvimento.
No ltimo estgio, as auditorias devem se limitar a verificar os produtos liberados necessrios que esto
presentes, sem se preocupar em revisar o contedo.

Executar auditoria de configurao funcional

Uma Auditoria de Configurao Funcional (FCA) confirma que uma baseline atende aos requisitos
estabelecidos para ela. Os passos para a execuo dessa auditoria so:

Preparar um relatrio que liste cada requisito estabelecido para a baseline, seu procedimento de teste
correspondente e o resultado de teste (aprovado/reprovado) da baseline.
Confirmar que cada requisito passou por um ou mais testes e que o resultado de todos esses testes foi
'aprovado'. Em Descobertas da Auditoria de Configurao, liste quaisquer requisitos que no tenham
passado por procedimentos de teste e os requisitos que esto com teste incompleto ou que foram
reprovados.
Gerar uma lista das CRs estabelecidas para essa baseline. Confirme que cada CR foi fechada. Em
Descobertas da Auditoria de Configurao, liste quaisquer CRs que no esto fechadas.

Reportar descobertas

Se houver alguma discrepncia, ela ser capturada em Descobertas da Auditoria de Configurao conforme
descrito anteriormente. Alm disso, os seguintes passos devero ser executados:

Identificar aes corretivas. Talvez, isso requeira a entrevista de vrios membros da equipe do projeto
para que a origem da discrepncia e as aes apropriadas sejam identificadas.
Para artefatos ausentes, a ao apropriada geralmente controlar a configurao do artefato ou criar uma
CR ou tarefa que produzir o artefato ausente.
No caso de requisitos no testados ou reprovados no teste, o requisito pode ser estabelecido para uma
baseline posterior ou negociado para ser removido do conjunto de requisitos.
Para CRs em aberto, a CR pode ser simplesmente fechada, testada ou adiada para uma baseline posterior.
Para cada ao corretiva, atribua uma responsabilidade e determine uma data de concluso.
Maneira de realizao
A finalidade da poltica de gerncia de configurao de software consiste em definir a maneira como as
atividades de gerncia de configurao de software sero executadas, o momento adequado, os responsveis em
execut-las e os conceitos envolvidos no processo. Entre as definies que devem contar nas polticas de
Gerncia de configurao de software podemos citar:

Ferramentas para automatizao do controle de revises (sistema de controle de verso) caso seja usada.
Caso no seja usada ferramenta, deve se definir o procedimento manual para o controle de
revises.
Caso existam elementos que no estejam em formato eletrnico (ferramentas de hardware por
exemplo), os procedimentos de controle de revises para estes elementos deve tambm ser
definido.
Ferramentas para o controle de mudanas
Caso no seja usada ferramenta, deve tambm ser definido o procedimento manual.
Controle de acesso s ferramentas de controle de reviso e controle de mudanas
Nvel de integrao entre as ferramentas caso sejam ferramentas distintas
Alguns fabricantes fornecem ferramentas que j desempenham os papeis de controle de reviso e
controle de mudanas num nico sistema, enquanto outros fabricantes as fornecem em separado.
Periodicidade e granularidade do controle de revises
Recomenda-se um controle dirio para elementos em formato eletrnico. A granularidade em geral
depende do tipo de item e da ferramenta utilizada.
Papis a serem desempenhados pelos membros da equipe dentro do contexto de gerncia de configurao
de software.
Frequncia e forma de realizao das auditorias de configurao.
Em geral apenas a primeira auditoria de configurao de uma linha-base precisa de interveno
humana, sendo que as auditorias subsequentes apenas verificam se houve quebra da integridade
dos arquivos auditados.

Referncias
Bibliografia
BROWN, William J. et ali (1999). Antipatterns and Patterns in Software Configuration Management.
Wiley computer publishing. 0-471-32929-0 Parmetro desconhecido |Autor= ignorado (|autor=)
sugerido (ajuda);
MIKKELSEN, Tim, PHERIGO, Suzanne (1997). Practical Software Configuration Management. The
Latenight Developer's Handbook. Prentice Hall PTR. 0-13-240854-6 Parmetro desconhecido |Autor=
ignorado (|autor=) sugerido (ajuda)
MOLINARI, Leonardo (2007). Gerncia de Configurao - Tcnicas e Prticas no Desenvolvimento do
Software. Visual Books. 85-7502-210-5 Parmetro desconhecido |Autor= ignorado (|autor=) sugerido
(ajuda);
PRESSMAN, Roger S. (1995). Engenharia de Software. Pearson Makron Books. 85-346-0237-9
Parmetro desconhecido |Autor= ignorado (|autor=) sugerido (ajuda);

Ver tambm
Sistema de controle de verso
Engenharia de software

Ligaes externas
O que Gerncia de Configurao de Software (https://blog.pronus.io/posts/o-que-eh-gerencia-de-config
uracao-de-software/)
Obtida de "https://pt.wikipedia.org/w/index.php?
title=Gerncia_de_configurao_de_software&oldid=46754574"

Categorias: Gerenciamento de configurao Engenharia de software

Esta pgina foi modificada pela ltima vez (s) 18h04min de 19 de setembro de 2016.
Este texto disponibilizado nos termos da licena Creative Commons - Atribuio - Compartilha Igual
3.0 No Adaptada (CC BY-SA 3.0); pode estar sujeito a condies adicionais. Para mais detalhes,
consulte as condies de uso.