Regularize - Software Original é Aqui!
Busca Rápida:

Pirata to fora!

Olá Visitante,

Aqui você encontra tudo em softwares e aplicativos dos melhores fabricantes.

Ainda não é Cadastrado?
Clique Aqui e cadastre-se agora.

Login
:

:



Cadastre-se e Compre
Cadastro de Revendas

Softwares são fonte de bons negócios e ótima lucratividade, estamos cadastrando revendedores de todo Brasil.

Seja nosso Fornecedor

Procuramos soluções para agregar ao nosso potifórlio e estamos prontos para distribuir os seus produtos e serviços à nossa base de clientes.

Gerência de Configuração de Software

Gerência de Configuração de Software

Gerência de Configuração de Software , Gerência de Configuração ou ainda Gestão de Configuração de Software é uma área da engenharia de software cuja equipe é responsável por fornecer o apoio para o desenvolvimento de software . Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria das configurações.


Roger Pressman , em seu livro Software Engineering: A Practitioner`s Approach, afirma que a gerência de configuração de software (GCS) é o:





conjunto de atividades projetadas para controlar as mudanças pela
identificação dos produtos do trabalho que serão alterados,
estabelecendo um relacionamento entre eles, definindo o mecanismo para
o gerenciamento de diferentes versões destes produtos, controlando as
mudanças impostas, e auditando e relatando as mudanças realizadas.


Roger Pressman



Em outras palavras, a Gerência de Configuração de Software tem como objetivo responder as seguintes perguntas:


  • O que mudou e quando?
  • Por que mudou?
  • Quem fez a mudança?
  • Podemos reproduzir esta mudança?

  • Cada uma dessas perguntas corresponde a uma das atividades
    realizadas pela Gerência de Configuração de Software. O controle de
    versão é capaz de dizer o que mudou e quando mudou. O controle de
    mudanças é capaz de atribuir os motivos a cada uma das mudanças. A
    Auditoria por sua vez responde as duas últimas perguntas: Quem fez a
    mudança e podemos reproduzir a mudança?

    Histórico

    A história da Gerência de Configuração de Software surge em meados da década 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 necessárias
    metodologias próprias, 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 padrão DoD-STD-2167 que
    abordava o desenvolvimento de software. A abordagem do DoD para
    controlar isto consistia da adoção de uma linguagem padronizada -- Ada -- e de práticas padrão para desenvolvimento de software e Gerência de Configuração.


    Outras organizações estavam por sua vez adotando práticas e métodos
    de Gerência de Configuração de Software, algumas das quais envolvidas
    também com o desenvolvimento de sistemas para o DoD e outros órgãos do
    governo Americano. Isto levou o próprio DoD a adotar algumas práticas
    comerciais e eventualmente uni-las com seus padrões, gerando assim o
    padrão IEEE/IEA 12207. Um outro padrão a respeito é o IEEE 828-1983.



    Funções

    A Gerência de Configuração e Software é definida por quatro funções básicas [1] :


  • Identificação
  • Documentação
  • Controle
  • Auditoria

  • No início do desenvolvimento, a GCS permite à equipe de desenvolvimento identificar
    as unidades que compõem o sistema de acordo com as funcionalidades que
    elas deverão desempenhar, e as interfaces entre estas unidades, documentando assim a interação entre elas. O controle
    contínuo da evolução destas funcionalidades e interfaces permite que a
    integração entre estas unidades tenha sucesso continuado, com as
    mudanças devidamente gerenciadas e documentadas. Por fim, a auditoria das funcionalidades identificadas, documentadas e controladas garante a confiabilidade do sistema.



    Conceitos e Terminologia

    A terminologia especifica da GCS, como também sua história, tem dado
    origem a controvérsias, de freqüentes variações. Ferramentas vendidas
    como também acadêmicas tiraram vantagem disto para deliberadamente
    mudar a terminologia ou procedimentos para reduzir a possibilidade dos
    clientes para mudanças, algumas vezes tentando desta maneira redefinir
    o estabelecimento de acrônimos .


    Em particular, o vendedor conhecido como Atria (depois Rational Software ), agora uma parte da IBM , usava SCM como padrão para Software Configuration Management (em portugês: "Gerência de Configuração de Software") enquanto o Gartner Group usa o termo SCCM ou Software Change and Configuration Management (em português: "Gerência de Mudanças e Configuração de Software").


    Entretanto, os conceitos básicos da GCS descritos abaixo são bem
    aceitos, divergindo de um autor ou fornecedor para o outro meramente
    nos termos utilizados.



    Configuração de software

    Configuração é o estado em que um sistema se encontra em um
    determinado momento. Este sistema pode ser composto de todo tipo de
    elementos, como peças de hardware, artefatos eletrônicos ou não (i.e.
    documentos em papel), etc. A Configuração de Software trata
    apenas dos elementos que se encontram em formato eletrônico e fazem
    parte dessa configuração. Isso inclui todos os arquivos fontes, todos
    os documentos eletrônicos, as ferramentas de software utilizadas para
    construir ou mesmo ler estes arquivos, o sistema operacional utilizado,
    as bibliotecas de software, etc.


    Essa configuração varia com o tempo, pois novos arquivos são
    incluídos, e arquivos existentes são alterados ou removidos. O objetivo
    da Gerência de Configuração 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 mudança de versão,
    quando o sistema foi enviado para auditoria, etc). A Gerência de
    Configuração como um todo trata dos elementos, incluindo hardware,
    necessários para a manutenção apropriada do sistema. a Gestão de
    Configuração de Software trata especificamente dos elementos
    necessários a construção de sistemas de software, e em geral, controla
    apenas os elementos em formato computadorizado.


    Em Sistemas de controle de versão as configurações específicas são geralmente identificadas pelo uso de tags ou labels (placas ou etiquetas, em inglês).



    Item de configuração

    Item de configuração , ou artefato de configuração , ou ainda apenas artefato
    é o elemento básico da gerência de configuração. O Item de configuração
    é um elemento unitário que será gerenciado: um arquivo de código fonte,
    um documento de texto, um projeto de uma placa eletrônica, uma planta
    feita em papel, um CD-ROM de instalação de um sistema operacional, etc.
    A configuração de um sistema é basicamente a lista de todos os itens de
    configuração necessários para reproduzir um determinado estado de um
    sistema. Em geral números de versão são associados aos itens de
    configuração de forma a podermos identificar também a evolução destes
    itens. Um exemplo de configuração pode ser:


  • Item A: CD de instalação do sistema operacional, versão 1.0
  • Item B: Documento de ajuda do sistema em formato eletrônico, versão 2.0
  • Item C: Processador de texto usado para imprimir o documento de ajuda, versão 5.0

  • e assim por diante.



    Controle de revisões

    O controle de revisões é o controle que se faz em cima de cada item
    de configuração para armazenar todas as mudanças que foram aplicadas
    nele. Em geral, na Gerência de Configuração de Software, usam-se Sistemas de controle de versão
    para automatizar esta tarefa. O controle de revisões deve permitir que
    se tenha acesso a todas as formas anteriores de um artefato e também
    saber quem fez as alterações e quando (para fins de auditoria). Dessa
    maneira podemos facilmente recompor uma configuração antiga (para
    identificar problemas que ocorrem em versões específicas do sistema,
    mas não em outras) e auditar as mudanças realizadas para ver se estão
    de acordo com o que foi solicitado originalmente.



    Conjunto de mudanças

    Um Conjunto de mudanças (do inglês: change set) é o conjunto
    de todas as alterações que ocorreram no sistema para atender um
    determinado fim, ou num determinado período de tempo. Associados com a
    Gerência de Mudanças, os conjuntos de mudanças mapeiam os itens que
    foram mudados para uma dada versão do sistema com os motivos das
    mudanças. Um exemplo de conjunto de mudanças:


    Mudanças da versão 1.0 para a versão 1.1
  • Item A mudou da revisão 1.0 para a revisão 1.1
  • Item B mudou da revisão 5.0 para a revisão 4.5
  • Item C foi eliminado
  • Item D foi acrescentado na versão 5.5
  • Item E mudou de nome para item F.


  • Linha-base

    Linhas-base ou Baseline é um conjunto de configurações
    passadas e futuras que devem ser seguidas para se alcançar determinado
    objetivo. Elas podem ser simultâneas ou consecutivas: a versão 1.0 pode
    estar ao mesmo tempo sendo corrigida para falhas de segurança, gerando
    a versão 1.1 e evoluída com novas funcionalidades gerando a versão 2.0
    do sistema. Nesse caso específico podemos identificar duas linhas-base
    simultâneas (versão 1.1 e versão 2.0) e uma linha base passada (versão
    1.0). Linhas-base não são configurações fixas, mas sim toda a evolução
    de determinadas configurações. Todo o trabalho realizado para se chegar
    a versão 2.0 e todo o trabalho realizado depois em cima desta versão
    para se testar e corrigir problemas são parte da linha base, e não
    apenas a versão 2.0 em si.


    Exemplos de linhas-base
  • Versão 1.0
  • Versão de correção de erros 1.1
  • Versão personalizada do sistema para o governo americano

  • Em Sistemas de controle de versão uma linha-base é geralmente identificada pelo uso de branches (galhos, em inglês).


    Gerência de mudanças



    A Gerência de mudanças é uma parte geralmente negligenciada da
    Gerência de configuração. Como ela não tem resultados imediatos para os
    desenvolvedores e engenheiros de software
    envolvidos no projeto, estes acabam por não perceber sua importância.
    Gerência de mudanças entretanto é uma parte importante da Gerência de
    configuração, pois é a atividade que permite se saber o motivo
    de uma configuração ter sido mudada para outra configuração. Esta
    atividade também pode ser parcialmente automatizada, e diversos Sistemas de controle de versão
    já são integrados com sistemas de gerência de mudanças. A gerência de
    mudanças tem por objetivo mapear, para cada mudança efetuada no
    sistema, qual foi o motivo que gerou esta mudança. É comum vermos em
    sistemas de software arquivos que listam as melhorias e mudanças entre
    duas versões. Estes arquivos são resultado da gerência de mudanças,
    identificando o que mudou entre uma versão e outra.


    Exemplos
  • mudança da versão 1.0 para 1.1 inclui:
  • correção do problema 355
  • correção do problema 356
  • correção do problema 358
  • nova funcionalidade de impressão de relatórios

  • pendências para a versão 1.2:
  • correção das mudanças 357 e 359.
  • impressão de relatórios coloridos.



  • Política de Gerência de Configuração de Software

    A finalidade da política de Gerência de Configuração de Software
    consiste em definir a maneira como as atividades de Gerência de
    Configuração de Software serão executadas, o momento adequado, os
    responsáveis em executa-las e os conceitos envolvidos no processo.
    Entre as definições que devem contar nas políticas de Gerência de
    configuração de software podemos citar:


  • Ferramentas para automatização do controle de revisões ( Sistema de controle de versão ) caso seja usada.
  • Caso não seja usada ferramenta, deve se definir o procedimento manual para o controle de revisões.
  • Caso existam elementos que não estejam em formato eletrônico
    (ferramentas de hardware por exemplo), os procedimentos de controle de
    revisões para estes elementos deve também ser definido.

  • Ferramentas para o controle de mudanças
  • Caso não seja usada ferramenta, deve também ser definido o procedimento manual.

  • Controle de acesso às ferramentas de controle de revisão e controle de mudanças
  • Nível de integração entre as ferramentas caso sejam ferramentas distintas
  • Alguns fabricantes fornecem ferramentas que já desempenham os
    papeis de controle de revisão e controle de mudanças num único sistema,
    enquanto outros fabricantes as fornecem em separado.

  • Periodicidade e granularidade do controle de revisões
  • Recomenda-se um controle diário para elementos em formato
    eletrônico. A granularidade em geral depende do tipo de item e da
    ferramenta utilizada.

  • Papeis a serem desempenhados pelos membros da equipe dentro do contexto de Gerência de Configuração de Software.
  • Freqüência e forma de realização das auditorias de configuração.
  • Em geral apenas a primeira auditoria de configuração de uma
    linha-base precisa de intervenção humana, sendo que as auditorias
    subseqüentes apenas verificam se houve quebra da integridade dos
    arquivos auditados.



  • Papéis

    Uma das principais definições da política de Gerência de
    Configuração de Software são os papeis a serem desempenhados. A
    política não determina quais pessoas desempenharão quais papeis,
    cabendo isso a gerência de projeto . Alguns papeis necessários numa política são:


  • Gestor de configuração do projeto. Ele é o responsável por
    acompanhar as alterações dos itens de configurações de um determinado
    projeto. Em geral este papel cabe ao integrador.
  • Gestor de ferramentas de Gerência de configuração. Ele é o
    responsável pela manutenção da infra-estrutura necessária para o bom
    funcionamento da Gerência de configuração no conjunto dos projetos da
    organização, ou no contexto do projeto, se for o caso. Em geral é uma
    pessoa da área de infra-estrutura com bons conhecimentos da plataforma
    operacional e das ferramentas usadas.
  • Gestor de Configuração de Software, ou Responsável de Gerência de
    Configuração de Software. Ele é o responsável por aprovar e gerenciar
    as atividades relativas a Gerência de Configuração de Software,
    coordenar a equipe de Gerência de Configuração de Software e algumas
    vezes, coordenar o trabalho de integração de sistemas.
  • Auditor de Configuração de Software. Ele é o responsável pela realização das auditorias de configuração nos projetos.
  • Desenvolvedor. Ele é o principal usuário da Gerência de
    configuração de software, sendo quem produz os itens de configuração
    que serão gerenciados.


  • Bibliografia
  • BROWN, William J. et ali. Antipatterns and Patterns in Software Configuration Management. Nova Iorque: Wiley computer publishing, 1999. 0-471-32929-0
  • MIKKELSEN, Tim, PHERIGO, Suzanne. Parctical Software Configuration Management: The Latenight Developer`s Handbook. Upper Saddle River, NJ, EUA: Prentice Hall PTR, 1997. 0-13-240854-6
  • MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software. Florianópolis: Visual Books, 2007. 85-7502-210-5


  • Notas e Referências
    1. BROWN, William J. et ali. Antipatterns and Patterns in Software Configuration Management. Nova Iorque: Wiley computer publishing, 1999. 0-471-32929-0

    Ver também



  • Sistema de controle de versão
  • Engenharia de software