GERÊNCIA DE CONFIGURAÇÃO E
VERSÕES DE SOFTWARE
Curso de Sistemas de Informação PUC Minas
Prof. Humberto Torres Marques Neto - Abril / 2009 Prof. André Pereira Viveiros - Fevereiro / 2012
Objetivos
• Discutir os principais problemas do processo de
desenvolvimento de software que estão relacionados com a configuração e/ou com a versão de um item que compõe tal processo
• Propor e discutir algumas soluções para os problemas discutidos
• Identificar e analisar ferramentas que apóiam a gerência de configuração e versão de software
Referência Bibliográfica
PRESSMAN, Roger S. Engenharia de Software. 6 ed. São Paulo: McGraw-Hill, 2006.
BABICH, Wayne A. Software Configuration
Management: coordination for team productivity. (s.l.) Addinson-Wesley, 1986.
BERSOFF, Edward. H., HENDERSON, Vilas D., SIEGEL, Stanley G. Software Configuration
Management: an investiment in product integrity. (s.l.) Prentice-hall, 1980.
Algumas situações que envolvem o processo de
desenvolvimento de software
• É necessário corrigir algo que já está sofrendo outros tipos de manutenção, contudo a correção tem prioridade sobre a evolução
• Um usuário “poderoso” solicita uma manutenção que afetará o trabalho de outros usuários
• Os usuários de um software não aceitam fazer o upgrade para a nova versão, criando assim a necessidade de
manter duas versões de um determinado software • Os módulos de um sistema funcionam separados,
Algumas situações que envolvem o processo de
desenvolvimento de software
• Um software atualiza uma biblioteca que está sendo utilizada por outro software, contudo a atualização não funciona para o segundo software
• Não existe backup das bibliotecas que foram atualizadas • Não existe backup de uma versão de um software que
possui as funcionalidades que precisam ser reimplantadas • A nova versão do software não atende as reais
necessidades do usuário, pois as modificações não foram solicitadas por ele
Primeira Lei da Engenharia de Sistemas
“Não importa a fase do processo de
desenvolvimento de sistemas, o sistema
demandará mudanças, e o desejo de
modificá-lo persistirá durante todo o
processo.” (BERSOFF, 1980. p. 43).
Marcos do Processo de Desenvolvimento de
Sistemas
• “Baselines”: marcos de referência do processo de
desenvolvimento de sistemas, normalmente aprovado formalmente.
• Principais “baselines” do ciclo de vida de um sistema (BERSOFF, 1980. p. 46-48):
• Funcional: proposta de desenvolvimento de sistemas • Alocação: especificação de requisitos
• Projeto: especificação de implementação, bem como a revisão
crítica do projeto de desenvolvimento do sistema
• Produto: documentação da implementação, bem como o plano
de testes de aceitação
• Operacional: documentação do sistema, bem como o documento
Marcos do Processo de Desenvolvimento de
Sistemas
•
“O gerenciamento do processo de
desenvolvimento de sistemas é o
gerenciamento das ‘baselines’”.
(BERSOFF, 1980. p. 46-48)
•
“As ‘baselines’ de um sistema são
os produtos tangíveis do seu
processo de desenvolvimento.”
(BERSOFF, 1980. p. 46-48).
Integridade do Produto Software
• Um projeto não pode atingir o “sucesso” extrapolando exageradamente custos e prazos ou sendo sofisticado demais para ser utilizado pelo usuário.
• A integridade de um software é definida pelos seguintes atributos:
• Os que caracterizam um produto que vai ao encontro aos
requisitos impostos, ou assumidos, ou supostos, ou pretendidos pelo usuário durante qualquer fase do processo de seu
desenvolvimento
• Os que facilitam o delineamento do produto, desde a sua
concepção (enquanto idéia), passando por todas as fases subseqüentes do seu processo de desenvolvimento
• Os que caracterizam um produto que alcança satisfatoriamente
Requisitos para se alcançar e manter a integridade de
um Software
Integridade do Produto Software SCM Teste e Avaliação Garantia de Qualidade Verificação e Validação Análise Projeto Implementação Teste Implantação Treinamento Documentação Gerência de ProjetoSegunda Lei da Engenharia de Sistemas
• Esta lei está relacionada à manutenibilidade de um sistema e é expressa nos termos da equação abaixo:
M = k1C + k2/B + k3/A
onde:
M = custo e/ou esforço requerido para manter um sistema no seu estado
operacional um maior intervalo de tempo
C = complexidade inerente às funções que serão realizadas pelo sistema B = grau de existência de “baselines” e documentação
A = grau de características estruturais que tem sido empregadas para
facilitar a manutenibilidade do sistema
Gerenciamento de Configuração de Software
-SCM
“Gerenciamento de Configuração de Software (Software Configuration Management - SCM) é a arte de
identificar, organizar e controlar modificações de um software que está sendo construído por uma equipe. A
meta é maximizar a produtividade e minimizar os erros.” (BABICH, 1986. p. 8).
Gerenciamento de Configuração de
Software
“SCM é uma atividade que abrange e é aplicada em todo o processo de engenharia de um software. Como
as mudanças podem ocorrer a qualquer tempo, as atividades de SCM são desenvolvidas para (1) identificar a mudança; (2) controlar a mudança; (3) garantir que a mudança esteja sendo adequadamente
implementada; e (4) relatar a mudança a outras pessoas que possam ter interesse nela.”
Gerenciamento de Configuração de
Software
“SCM é definido como uma disciplina de identificação de configuração de um sistema em determinados momentos do tempo, com o propósito de controlar sistematicamente as mudanças dessa configuração, mantendo a integridade de tal configuração dentro do
Funções da Gerência de
Configuração de Software
• Como uma organização identifica e gerencia as diversas versões de
programas e suas respectivas documentações e suas estruturas de dados utilizadas de uma maneira que possibilite alterações sem causar muito impacto?
• Identificação de configurações: É o processo que envolve a
identificação de todos os itens de configuração de acordo com um padrão pré-definido.
• Como uma organização controla as mudanças antes e depois da
liberação do software para o usuário? Quem é responsável pela aprovação e pela definição de prioridade das modificações?
• Controle de configurações: Envolve processos para Controle de
Funções da Gerência de
Configuração de Software
• Como podemos avaliar se as mudanças foram realizadas
corretamente?
• Auditoria de configurações: Garante que a base de dados
de configurações e versões é consistente.
• Quais mecanismos e ferramentas são utilizados para verificar
se outras mudanças podem ser realizadas?
• Histórico de configurações: Permite uma recuperação do
Divisão das categorias de informação do
processo de software
• Programas de computador (tanto na forma de código como na forma de executável)
• Produtos de trabalho que descrevem os programas (voltados para os profissionais como para os usuários) • Dados (contidos no programa ou externo a eles)
Gerente Configuração*
Cliente
Gerente Projeto
Equipe Desev
O Cliente gera uma requisição de mudança O Eng. software checks out os objetos configuração necessários Gerente acata a mudança e requisita ao engenheiro de software ES completa mudanças necessárias GM cria uma nova baseline sistema Cliente aprova mudanças
*Administra a base do projeto e provê acesso e controle aos engenheiros de software ES checks in Objetos de configuração modificados e notifica GC GC prepara um nova versão do sistema
Ciclo SCM
Um cenário operacional SCM
• Considerar um produto de 15 mil linhas de código sendo desenvolvidos por uma equipe de 6 pessoas • Um gerente de projeto encarregado de um grupo
de software
• Um gerente de configuração encarregado de procedimentos e políticas de CM
• Engenheiros de software responsáveis por desenvolver e manter
• O cliente que usa o produto
Um cenário operacional SCM
• O gerente de projeto no nível operacional quer
garantir que o produto seja desenvolvido no tempo. O acompanhamento é feito pela geração e análise de relatórios sobre o estado do sistema e suas
revisões
• O gerente de configuração tem o objetivo de
garantir que os procedimentos e políticas para criar, modificar e testar o código estão sendo seguidos, bem como tornar acessível a informação
Um cenário operacional SCM
• Os eng. de software querem trabalhar
efetivamente, comunicando e coordenando suas atividade ajudados pelas ferramentas SCM
• O cliente usa o produto sob controle GC, solicitando modificações e indicando bugs indicando o versionamento.
• O gerente de projeto vê o o sistema CM como um mecanismo de
auditoria; o GC vê como um mecanismo de controle,
acompanhamento e construção de política; o ES vê como
mecanismo de controle de modificação, construção e acesso e o cliente vê como mecanismo de garantia de qualidade
Itens de Configuração de Software
• Itens de configuração de software (software
configuration item - SCI) é qualquer informação
gerada durante o processo de desenvolvimento de software.
• Uma organização de SCIs pode ser
Itens de Configuração de Software
• Alguns exemplos de itens de configuração de software: • Documentos com a formulação conceitual do sistema
• Especificação de requisitos (Diagramas, Modelos, Definições,
Protótipos, etc.)
• Especificação de implementação (Diagramas, Modelos,
Especificações de Módulos, Projeto físico de banco de dados, Projeto de interfaces, Configurações de hardware, etc.)
• Código fonte e executável dos programas desenvolvidos • Esquemas de banco de dados e estruturas de arquivos • Plano de teste (descrição e resultados)
• Carga inicial de dados (procedimento de carga e conteúdo) • Manuais do usuário (preliminar e as-built)
• Documentos relacionados à documentação (solicitações, relatórios de
problemas, ordens de execução, etc.)
Itens de Configuração de Software
Especificação de projeto: •Projeto de dados •Projeto arquitetônico •Projeto modular •Projeto de interface Especificação de teste •Plano de teste •Procedimentos de teste •Casos de teste Modelo de dados Componente N •Descrição de interface •Descrição de algoritmo Código fonteControle de Configuração de Software
• “Gerenciamento de configuração permite um usuário especificar configurações alternativas de um software através da seleção de versões apropriadas. Isso é
possível através da associação de atributos com cada versão de software, permitindo assim que a
configuração seja especificada (e construída) a partir do conjunto de atributos desejados.” (PRESSMAN, 1997. p. 218)
• Controle de configuração de software é responsável pelo gerenciamento do processo pelo o qual o(s)
software(s) de um sistema passa(m) durante o seu ciclo de vida.
Controle de Configurações de um Software
Padrões Ponto de Referência Estabelecido (baseline) Alterações Desejadas Novo Projeto Novo Ponto de Referência Proposto (nova baseline ou baseline atualizada)O Repositório SCM
• É um conjunto de mecanismo e estruturas de dados que permite gerir modificações de forma efetiva. Algumas funções que podem ser
executadas ou propiciadas pelo repositório:
• Integridade de dados: validar entradas, executar modificações “em cascata”
• Compartilhamento de informação: controla o acesso a diferentes usuários,
bloqueia e desbloqueia
• Integração de ferramenta: fornece modelo de dados ao qual podem ter
acesso várias ferramentas
• Integração dos dados: funções permitindo que várias tarefas de SCM sejam
executadas em um ou mais SCIs
• Imposição de metodologia: define um modelo entidade-relacionamento que
implica um modelo de processo
• Padronização da documentação: Definição de objetos que leva a uma
O Repositório SCM e suas características
• Para apoiar SCM o repositório precisa ter um conjunto de ferramentasque forneça as seguinte características:
• Determinação de versão:no progresso do projeto várias versão do SCIs são
criadas. Deve ser capaz voltar uma versão salvar versões
• Acompanhamento de dependências e gestão de modificação: Gerir o
relacionamento dos objetos, por exemplo um diagrama UML modificado deve traze as alterações das classes alteradas aos desenvolvedores
• Acompanhamento dos requisitos: Acompanhamento avante dos objetos
gerados pelo requisito e retroacompanhamento do item de configuração gerado por determinado requisito
• Gestão de configuração: Gerenciamento de marcos e versões específicas
• Pistas de auditoria: informações como, quando, por quem, porque as
O processo de SCM
• O processo e seus objetivos principais: (1)identificar todos os itens itens que identificam coletivamente a configuração de software (2) gerir
modificações em um ou mais desses itens (3) facilitar a construção de diferentes versões de uma aplicação e (4) garantir que a qualidade de software seja mantida a medida que a configuração evolui ao longo do tempo.
• Nos levando a cinco tarefas:Identificação, controle de versão, controle de
modificação, auditoria de configuração e preparação de relatórios.
SCIs identificação Controle de modificação Controle de versão Auditoria de configuração Preparação de relatórios
Identificação de objetos
• Cada item de configuração recebe um nome e sua organização
pode ser dada conforme abordagem OO. Dois tipos de objetos: objeto básico e objeto agregado.
• Objeto básico por exemplo pode ser uma seção de especificação
de requisitos , parte do modelo, uma seqüência de casos testes
• Objeto agregado por exemplo pode ser a especificação do projeto
contendo uma coleção de objetos básicos ou outros objetos agregados. Funcionando como um ponteiro para outros objetos
• Há também na identificação o relacionamento por exemplo:
• diagrama de classe <parte-de> modelo de análise;
Controle versão de Software
• O que é uma versão de software?
“Cada versão de software é uma coleção de SCIs (código fonte, documentos, dados, etc.), que pode ser composta por diferentes ‘variantes’.” (PRESSMAN, 1997. p. 218-219)
• A política de mudanças deve fazer parte da metodologia de
desenvolvimento de sistemas?
“Controle de versão combina procedimentos e ferramentas para gerenciar diferentes versões de objetos de configuração que são criados durante o processo de software.” (PRESSMAN, 2006. p. 750)
Sistema de controle versão de Software
•
Deve implementar ou deverá estar integrado a
quatro capacidades:
Um banco de dados de projeto (repositório) que guarda todos os objetos de configuração relevantes
Uma capacidade de gestão de versão que guarda todas as versões de um objeto de configuração (ou permita que qualquer versão seja construída usando diferenças de versões anteriores)
Um facilidade de construir que permita o ES coletar todos os objetos relevantes para gerar uma versão específica do software Capacidade de acompanhamento de tópicos que permite a equipe registrar e acompanhar tópicos importante associados a cada
Controle de Modificações (PRESSMAN)
• Necessidade de modificação é reconhecida, e solicitada pelo usuário
• O “desenvolvedor” avalia a solicitação e produz um relatório de mudança
• Um “comitê de controle de modificações” (CCM) decide se a modificação será realizada ou não: geração de “ordem
de execução” ou o usuário é avisado da não aprovação
• Em caso de aprovação, os recursos são alocados
• É feito um “check-out” no objeto de configuração que será modificado
• A modificação é realizada e revisada
Controle de Modificações (PRESSMAN)
• Uma baseline é estabelecida para teste
• Atividades para teste e verificação de qualidades são executadas
• É realizada uma nova revisão
• A versão de software apropriada é reconstruída • A alteração de todos os SCIs é revista
• As modificações são incorporadas à nova versão • Finalmente, a configuração é distribuída
• Algumas questões sobre o processo:
Auditoria de Configurações
• Algumas questões que devem ser respondidas por essa função
do processo de gerenciamento de configurações de software (PRESSMAN, 2006. p. 612):
• As modificações especificadas foram realizadas?
• Algo de novo foi realizado? Ou seja, foi feito alguma modificação
que não foi especificada?
• Foi utilizada alguma técnica formal para verificação e validação da
modificação?
• Os padrões de engenharia de software foram criteriosamente
respeitados?
• Os atributos dos objetos de configuração envolvidos na modificação
refletem o que foi modificado? A data e autor do serviço estão identificados?
• Os procedimentos de controle e de geração de histórico da modificação foram realizados?
Algumas questões sobre a
Auditoria de Configurações
• Quando a auditoria de configuração de software deve ser realizada? Deve haver uma periodicidade definida a
priori?
• Qual a relação custo/benefício de um processo de auditoria de configuração de software?
• Quais os custos da prevenção? Quando vale a pena esperar o problema ocorrer?
• Quem deve ser o responsável por tal processo? Uma equipe interna ou externa?
• Existem ferramentas que podem otimizar um processo de configuração de software?
Histórico de Configurações ou relatórios de estado
• Algumas questões que devem ser respondidas por essa
função do processo de gerenciamento de configurações de software (PRESSMAN, 2006. p. 756):
• O que aconteceu? • Quem fez isso? • Quando foi feito?
Métodos utilizados para
armazenamento de versões
• Arquivos separados
• Um arquivo para cada versão do item de configuração • É necessário definir uma padronização de nome de item
para identificar as versões
• Deltas
• Um arquivo para a primeira versão, e arquivos contendo as
diferenças relativas ao “arquivo base”, ou à versão anterior, formando assim uma “cadeia”.
• Compilação condicional
• Todas as versões estão em um único arquivo (programa
fonte) e são “separadas” ou “geradas” em tempo de compilação
Derivações
(BABICH, 1986. cap. 3)
• Derivação é a história do item de configuração e de seus respectivos relacionamentos com outros itens de
configuração, inclusive os que compõem o ambiente (compiladores, esquemas e instâncias de banco de dados, entre outros).
• Para a derivação ser útil em um processo de “debug” ou de reconstrução de uma versão, ela deve ser precisa.
Algumas questões para discussão
• Quais as vantagens e desvantagens de cada método de
armazenamento para cada tipo de versão?
• Tais métodos se aplicam para outros tipos de itens de
