FASTHELP SYSTEM

Plano de Gerenciamento de Configuração

Versão <1.6>

Histórico da Revisão
Data Versão Descrição Autor
06/04/2010 1.0 Criação do PGC do Eduardo
FASTHELP
07/04/2010 1.5 Elaboração do PGC Hamden

10/04/2010 1.6 Revisão do PGC Hamden

Conteúdo
1.Plano de Gerenciamento de Configuração ..........................................................................3
1.1Introdução: ...............................................................................................................3
1.2Finalidade: .....................................................................................................................3
1.3Escopo: ..........................................................................................................................4
1.4Definições, Acrônimos e Abreviações: .........................................................................5
1.5Definições:.....................................................................................................................5
1.6Abreviações:...................................................................................................................6
1.7Referências ....................................................................................................................6
1.8Visão Geral ....................................................................................................................6
2.Gerenciamento de Configuração de Software .....................................................................7
2.1Organização, Responsabilidades e Interfaces................................................................7
2.2Ferramentas, Ambiente e Infra-estrutura ......................................................................7
2.3Servidor de Desenvolvimento: ......................................................................................8
2.4Servidor de Testes:.........................................................................................................8
2.5Servidor de Homologação:.............................................................................................9
3.Programa de Gerenciamento de Configuração ....................................................................9
3.1Identificação da Configuração
.............................................................................................................................................9
3.1Métodos de Identificação...............................................................................................9
3.2Formato do Número de Versão......................................................................................9
3.3Evolução do Número de Versão..................................................................................10
3.4Rótulos Comuns...........................................................................................................11
3.5Baselines do Projeto ....................................................................................................11
3.6Plano de Identificação da Configuração.......................................................................12
3.7Lista dos itens de configurações aprovados.................................................................12
3.8Os Requisitos...............................................................................................................12
3.9Design do Produto........................................................................................................12
3.10Código-Fonte..............................................................................................................12
3.11Material e Resultado dos Testes.................................................................................12
3.2 Controle de Configuração e Mudança ..........................................................12
3.2.1Processamento e Aprovação de Solicitações de Mudança ...................................12
4. Treinamento e Recursos ..................................................................................13
5. Referências Bibliográficas ..............................................................................13
1. Plano de Gerenciamento de Configuração
1.1 Introdução:
Gerência de Configuração de Software (GCS) pode ser definida como o controle
da evolução de sistemas complexos ou, de forma mais pragmática, como a disciplina
que permite manter produtos de software em evolução sob controle, e, portanto,
contribuindo para satisfazer restrições de qualidade e de cronograma.
Este documento tem por finalidade definir um Plano de Gerenciamento de
Configuração de Software para o sistema FAST-HELP, controlando a criação e
evolução dos artefatos, como documentos, arquivos de ajuda, código-fonte e dados,
dentre outros, utilizados ao longo do ciclo de vida deste software. Portanto, a
aplicação deste plano tem como objetivo principal garantir a integridade dos artefatos
envolvidos no projeto do sistema FAST-HELP.
Este plano de Gerenciamento de Configuração descreve padrões e
procedimentos relevantes ao controle e a integridade de um software, identificando e
gerenciando mudanças e registrando e informando tais mudanças. Todos estes
artefatos são controlados pela disciplina da gerência de configuração de software,
cujo controle também possuirá o seu histórico de alterações e também todas as
versões salvas, garantindo-se assim a qualidade da consistência dos artefatos
produzidos através do versionamento estável desta produção e o acompanhamento da
evolução da mesma. Tal processo é contínuo, pois estas atividades não ocorrem
apenas no início do processo, pois um item de configuração pode ser identificado
mesmo depois do processo de gerência de configuração já ter sido iniciado.

1.2 Finalidade:
Os papéis desempenhados neste processo de GCS são o Gerente de Projeto,
Gerente de Configuração e Equipe do Projeto.
Gerente de Projeto: O Gerente de Projeto é o responsável por autorizar a
atualização de uma versão de produção do sistema, por uma nova versão estabelecida
pelo Gerente de Configuração. Qualquer mudança em versões de produção deverá ser
autorizada pelo Gerente de Projeto. Responsável por emitir um parecer final, que será
o último processo de apreciação (aprovação ou rejeição) de todas as solicitações de
alterações oriundas do Gerente de Configuração, bem como definir os itens de
configuração que serão gerenciados e indicar os responsáveis que farão o papel de
Gerente de Configuração, que analisarão os pedidos de alteração da Equipe do
Projeto.
Também é responsável por indicar a utilização de uma ferramenta de controle de
versão, para atender a característica principal de versionamento, controle e
administração de todos os artefatos envolvidos durante o ciclo de vida do sistema.
Gerente de Configuração: É o responsável por estruturar o repositório de
dados do sistema, identificar e controlar os itens de configuração (definindo números
únicos para cada versão e rotulando os itens de configuração que a compõe com
referências aos números de versão), estabelecer versões do sistema, gerenciar a
utilização de ferramentas de gerência de configuração e adequá-las à equipe de
desenvolvimento, e finalmente, elaborar registro das alterações implementadas em
cada versão disponibilizada do sistema.
Equipe do Sistema: A equipe do sistema é responsável pela publicação e
controle das versões de produção do sistema. Ela também administra os itens de
configuração, envolvendo inclusão, exclusão e principalmente modificação nos itens
existentes. Também será responsável por realizar a substituição das versões de
produção do sistema por novas versões disponibilizadas pelos Gerentes de
Configuração e autorizadas pelos Gerentes de Projeto.
Além disso, a Equipe do Sistema também é responsável pela elaboração de manual de
ajuda, disponibilização de informações sobre versões de produção dos sistemas,
descrição e acompanhamento de todos os procedimentos para manter a segurança ao
distribuir versões do sistema para o ambiente do usuário, e finalmente a execução de
processos operacionais como: backup e restauração, configuração e administração de
usuários e permissões.

1.3 Escopo:
Este documento se aplica ao sistema FASTHELP. Abrange os artefatos gerados
pela Equipe de Desenvolvimento envolvida, tais como os requisitos, design, código-
fonte, manual, modelos de dados e casos de teste.
Este Plano tem aplicabilidade direta e imediata nas atividades realizadas pelos
profissionais de desenvolvimento de sistemas, como modelagem, programação, banco
de dados, homologação, testes, etc.

1.4 Definições, Acrônimos e Abreviações:

1.5 Definições:
Baseline é uma linha de referência composta por todos os itens de configuração
de um projeto. O objetivo de uma baseline é servir de referência para o gerenciamento
de mudanças de um projeto. Ela deve ser como uma fotografia capaz de descrever um
projeto em um determinado instante de sua execução.
A criação de baselines pode ser realizada de acordo com os marcos do
projeto (milestones) ou de alguma outra forma definida pela gerência. A baseline é
armazenada em um repositório de itens de configuração. E, a partir desse momento,
só pode ser alterado por meio de uma solicitação de alteração formal para controle de
mudança.
Um release do sistema é uma versão distribuída ao cliente. Cada release deve
incorporar novas funcionalidades ou ser planejado para uma plataforma diferente de
hardware. Há, normalmente, muito mais versões de um sistema do que liberações. As
versões são criadas no âmbito da organização, para desenvolvimentos ou testes
internos, e não são previstas para serem liberadas para os clientes.
Um release do sistema não é somente um código executável do sistema. Ele
pode incluir: arquivos de configuração que definem como o release pode ser
configurado para instalações específicas; arquivo de dados necessário para a operação
do sistema com sucesso; um programa de instalação usado para auxiliar a instalação
do sistema no hardware-alvo; documentação eletrônica e em papel que descreve o
sistema; empacotamento e publicidade associada projetados para release.
Para documentar um release, deve-se:
 Registrar as versões específicas dos componentes de código-fonte usados
para criar o código executável;
 manter cópias dos códigos-fonte, do código-executável, de todos os
arquivos de dados e de configuração;
  registrar as versões do sistema operacional, as bibliotecas, os compiladores
e outras ferramentas usadas para construir o software.

1.6 Abreviações:

PLN Planos do Projeto

REQ Campos de Requisitos
USC Casos de Uso
MOD Arquivos de Modelo
SRC Arquivos de Código-Fonte
INT Interfaces Públicas
TST Scripts e Resultados de Teste
DOC Documentação (Notas de Release, do Usuário)
BIN Executáveis

1.7 Referências
Não se aplica.

1.8 Visão Geral

Este Plano de Gerenciamento está organizado em seções:
A seção 1 mostra a Introdução, que por sua vez descreve as responsabilidades e
papéis envolvidos no processo, bem como a sua definição. Também é informado o
escopo do Plano, definições, abreviações utilizadas e referências às especificações de
casos de uso.
A seção 2 descreve as responsabilidade da equipes de projeto, gerentes de
configuração e de projeto,bem como a descrição detalhada dos ambientes utilizadas
no processo.
A seção 3 apresenta o Processo de Gerenciamento de Configuração detalhado,
descrevendo sucintamente os métodos de identificação, baselines, e a descrição das
atividades seqüenciais do processo em si.
 2. Gerenciamento de Configuração de Software
2.1 Organização, Responsabilidades e Interfaces

Atividades de GCS Gerente de Projeto Gerente de Configuração Equipe do Sistema

Identificar Atividades do X
Processo
Identificar Responsáveis X
Integrar Plano de CGS X
Identificar Itens de Configuração X
Identificar Responsáveis X
Solicitar Alteração X
Analisar Pedido de Alteração X X
Implementar Alteração X
Verificar Item de Software X X
Alterado
Relatar Situação X X X
Auditoria da Configuração X
Criar Baseline X
Entregar Baseline X

2.2 Ferramentas, Ambiente e Infra-estrutura

A ferramenta de controle de versão utilizada neste processo é o Subversion

(SVN).
O Subversion é um sistema de controle de versão, isto é, ele gerencia arquivos e
diretórios ao longo do tempo. Uma árvore de arquivos é colocada em um repositório
central. Este repositório se parece muito com um servidor de arquivos comum, exceto
que ele se lembra de todas as mudanças feitas em seus arquivos e diretórios. Isso
permite-se recuperar versões antigas dos seus dados, ou examinar o histórico de como
os dados foram alterados. Para o projeto do sistema FASTHELP, serão criados 3
servidores, um de Desenvolvimento, outro de Homologação, e mais um de Testes.

2.3 Servidor de Desenvolvimento:

Este servidor será responsável por indicar à Equipe Técnica onde armazenar os
requisitos iniciais do sistema, bem como as atividades relacionadas ao
desenvolvimento do mesmo.

 /dev – Diretório onde se encontrarão os código-fontes;

 /docs – Diretório onde se encontrará a documentação;

 /telas - Diretório onde se encontrará os arquivos como especificação

de telas;

 /temp - Armazena versões temporárias onde desenvolvedores podem

realizar modificações e testes sem impactar a versão principal do sistema.

2.4 Servidor de Testes:

Este servidor será responsável pelas atividades e planos de teste, durante

todo o ciclo de vida do sistema. Os artefatos de teste envolvidos são: código
compilado, planos de testes e seus resultados. Este servidor não terá permissão de
escrita para todos, somente para o Gerente de Configuração, que fica responsável por
o gerenciamento de versões e de manter este repositório sempre atualizado. Terá sua
estrutura baseada em:

 /planos – Diretório onde se encontram os documentos para o teste;

 /prog - Diretório onde se encontra o programa compilado e

funcionando.
 2.5 Servidor de Homologação:

Será responsável pelas versões homologadas do sistema, terá acesso

restrito, da mesma forma com que o segundo trabalha. Conterá somente o executável
do programa e um breve manual do usuário.

 /prog - Diretório onde se encontra o programa compilado e

funcionando.

 /manual - Diretório com os manuais para utilização do programa.

Diretório Equipe do Sistema Gerente de Gerente de Projeto

Configuração
/dev L/E L L
/docs L/E L L
/telas L/E L L
/temp L/E L L
/planos L L/E L/E
/prog L L/E L/E
/manual L L/E L/E
Legenda: E=Escrita/ L = Legenda.

3. Programa de Gerenciamento de Configuração

3.1 Identificação da Configuração

3.1 Métodos de Identificação

Todo o Processo de GCS deve seguir uma política de numeração de versões.

Esta política permite a identificação das versões salvas no repositório de dados, de
todos os itens de configuração envolvidos e versionados do sistema.

3.2 Formato do Número de Versão

O número de versão dos sistemas deve seguir o formato abaixo:
maior.menor[.correção][-rótulo]
 • Maior – Número principal da versão. A atualização deste número indica uma
alteração mais significativa do sistema com relação a versão anterior. Também pode
implicar em uma quebra total de compatibilidade com a versão anterior, no sentido
de alteração completa da arquitetura do sistema.
• Menor – Número secundário da versão. São atualizações que tem um menor
impacto, no sentido de funcionalidades, porém mantendo toda a compatibilidade com
as versões secundárias anteriores.
• Correção (opcional) – Número de versões de correção disponibilizadas. A
atualização deste número indica a correções de problemas existentes na versão
anterior, mantendo total compatibilidade com a mesma.
• Rótulo (opcional) – Texto, preferencialmente em letras minúsculas, que
descreve características da versão disponibilizada. Por exemplo: alfa, beta, data de
geração da versão ou nome da fase do projeto (interessantes durante o
desenvolvimento do sistema), UF (nos casos de sistemas com versões customizadas
para cada unidade da federação) etc.

3.3 Evolução do Número de Versão

Toda primeira versão gerada durante o desenvolvimento de um sistema deverá
ser chamada de 0.1, enquanto que toda primeira versão disponibilizada de um sistema
deverá ser chamada de 1.0.
A partir desta numeração inicial, todas as alterações seguirão com a formatação
padrão descrita acima, para documentar cada versão de um dado artefato.
A relação a seguir descreve um exemplo de evolução das versões de um
sistema:
0.1 Primeira versão gerada durante o desenvolvimento do projeto.
0.2 Atualização ou acréscimo de uma funcionalidade, referente a versão
anterior.
0.2.1 Correção de um bug da versão anterior (versão gerada com a atualização
ou acréscimo de uma funcionalidade).
0.2-iteracao3 Mesma versão 0.2, com indicação de que a versão foi gerada ao
término da terceira iteração do projeto.
1.0-beta1 Primeira versão beta do sistema, disponibilizada aos usuários para
 homologação.
1.0-beta2 Segunda versão beta, corrigindo problemas observados na versão
1.0-beta1.
1.0 Primeira versão final do sistema.
A partir da disponibilização da versão 1.0, todo número subsequente de versão
indicará nova versão disponibilizada aos usuários. Desta forma, sendo necessária a
identificação de versões de desenvolvimento (por exemplo, durante um projeto de
desenvolvimento de nova versão de um sistema), devem-se usar rótulos para indicar
estas versões.

3.4 Rótulos Comuns

Estão relacionados a seguir alguns rótulos comuns utilizados no
desenvolvimento de sistemas:
• alfa – versão instável, disponibilizada para testes pela equipe de
desenvolvimento, testes e/ou homologação.
• beta – versão instável, disponibilizada para testes pelos usuários finais do
sistema.
• RC (release canditate) – versão estável, possível versão final do sistema, caso
não sejam identificados erros impeditivos durante os testes de aceitação pelos
usuários finais.

3.5 Baselines do Projeto

Baseline
Marco dos Objetivos do Ciclo de Vida (Fase de
Iniciação)
Marco da Arquitetura do Ciclo de Vida (Fase de
Elaboração)
Marco da Capacidade Operacional Inicial (Fase de
Construção)
Marco de Release do Produto (Fase de Transição)
Descrição
Casos de Uso, Requisitos Funcionais e Não-
Funcionais.
Diagrama de Classes, Diagrama de Sequência,
Diagrama de Componentes
Código-Fonte, Modelos de Instalação,
Implementação e Teste
Preparação da divulgação do sistema, Preparação da
Documentação, Divulgação (Release) do Sistema,
Coleta de Informações sobre Defeitos e
Planejamento de Correções.
 3.6 Plano de Identificação da Configuração
3.7 Lista dos itens de configurações aprovados
A lista dos itens aprovados pela gerência de configuração, bem como a última
versão de cada módulo, estarão listadas nos servidores de Homologação e de Teste.
No servidor de Homologação, nos diretórios Prog e Manual, e no servidor de Teste,
nos diretórios Plano e Prog.

3.8 Os Requisitos
Os requisitos também se encontrarão no servidor de desenvolvimento,
disponível a todos.

3.9 Design do Produto

O design do Programa, modelos, telas e etc, se encontrarão no servidor de
desenvolvimento, para que os desenvolvedores possam se utilizar do mesmo.

3.10 Código-Fonte
O Código fonte do programa estará disponível no repositório de
desenvolvimento também e poderá ser alterado por qualquer desenvolvedor. Cabe ao
mesmo, relatar as mudanças, acréscimos e remoções na hora que em der commit nos
arquivos.

3.11 Material e Resultado dos Testes

A parte de testes estará toda no servidor específico (servidor de Testes, diretório
Plano e Prog). Se encontrarão tanto os planos de teste, bem como suas expectativas e
seus real resultados.

3.2 Controle de Configuração e Mudança

3.2.1 Processamento e Aprovação de Solicitações de Mudança
Primeiramente, o Gerente de Projeto solicita a criação de um repositório de
dados. Feito isso, a Equipe de Projeto criará este repositório no servidor de controle
de versão. Após a criação do repositório, o Gerente de Configuração do sistema
estrutura o ambiente de desenvolvimento do repositório de acordo com a estrutura
dos itens de configuração do sistema.
Então, o processo de Gerenciamento de Configuração e Mudança se inicia quando um
 membro da Equipe de Trabalho solicita uma alteração em algum artefato produzido
pelo sistema.
Esta requisição será primeiramente encaminhada à apreciação do Gerente de
Configuração e Mudança, a quem deve emitir um parecer no caso de sua aprovação
ou de uma justificativa no caso de sua rejeição. No caso de uma aprovação, o pedido
será finalmente encaminhado ao Gerente de Projeto, a quem deverá fazer a sua última
apreciação deste processo. Se aprovado, então o artefato é versionado (pelo Gerente
de Configuração) e homologado para a continuação dos testes, antes de ir para o
ambiente de Produção. Se rejeitado, o Gerente de Projeto enviará sua justificativa
final de rejeição e a solicitação de alteração será arquivada.

4. Treinamento e Recursos
Não se aplica.

5. Referências Bibliográficas
SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson
Addison Wesley, 2007.
Rational Unified Process, 1987 - 2001 Rational Software Corporation.