Manual de Implementação de Processo do MPS.BR com Apoio ...spider.ufpa.br/publicacoes/manuais/SPIDER_gerenciaConfiguracao... · Entre as vantagens do SVN está o modelo de versionamento

www.ufpa.br/spider

Manual de Implementação de Processo do MPS.BR com Apoio Ferramental

Processo: Gerência de Configuração

Versão: 1.0

Confidencial Página 2 de 76

Histórico de Revisões

Data

Versão

Descrição

Autor

25/11/2009

0.1 Inicio da produção do documento.

Desenvolvimento dos tópicos:

1. Introdução 2. Conceitos

Básicos do Processo de Gerência de configuração

3. Ferramental de Apoio

Maurício Ronny

26/11/2009 0.2 Descrição dos Resultados Esperados

Maurício Ronny

01/12/2009 0.3 Desenvolvimento da Metodologia

Ewelton Yoshidome, Maurício Ronny

02/12/2009 0.4 Descrição da configuração das

ferramentas CVS e Mantis

Ewelton Yoshidome

03/12/2009 0.5 Desenvolvimento da Metodologia


04/12/2009 0.6 Integração, Desenvolvimento da

Metodologia e ajustes no documento


10/12/2009 0.7 Instalação das ferramentas


16/12/2009 1.0 Instalação das ferramentas e revisão do

documento



Sumário

1. Introdução 2. Conceitos Básicos do Processo de Gerência de Projetos 3. Ferramental de Apoio 4. Instalação/Configuração das Ferramentas 5. Implementação do Processo de Gerência de Projetos do MPS.BR


Manual de Implementação de Processo com Apoio

Ferramental 1. Introdução 1.1. Finalidade

Este manual tem o propósito de descrever uma metodologia de implementação do processo de Gerência de

Configuração do Nível F do MPS.BR, utilizando apoio ferramental. Utilizando apenas ferramentas livres com algumas

modificações propostas, este guia descreve como atingir ou como as ferramentas fornecem insumos para alcançar os

resultados esperados do processo.

1.2. Escopo

Este documento se restringe à visão ferramental da implementação do processo de Gerencia de Configuração no

Nível F do MPS.BR. Não faz parte do escopo deste documento definir um processo para as organizações, mas definir

práticas que podem ser inseridas ao processo de organizações que adotem este manual.

1.3. Definições

Auditoria Física – Tipo de auditoria de configuração que tem o propósito de garantir

que as baselines estejam completas.

Auditoria Funcional – Tipo de auditoria de configuração que tem o propósito de

garantir que as baselines estejam corretas.

Baseline – Configuração específica de versões de IC sujeita a controle formal

CCC – Comitê de Controle de Configuração.

Checkin – Ação de enviar mudanças ao repositório

Checklist – uma lista de atributos ou qualidades que devem ser avaliados em um

determinado produto de trabalho, onde cada um desses atributos possui uma lista de

possíveis valores dos quais apenas um pode ser marcado. Um checklist nada mais é do

que uma relação organizada de critérios objetivos.

Checkout – Ação de receber dados do repositório

Commit – Mesmo que checkin

IC – Itens de Configuração

Issue – Registro de problema identificado em ferramentas de controle de mudança

Item de Configuração – Produtos de trabalho sujeitos a ação da gerência de

configuração

GCO – Sigla do Processo de Gerência de Configuração do MPS.BR

Resultados Esperados – Boas práticas que devem ser adotadas para o atendimento de

um processo do MPS.BR

Repositório – Banco de dados para armazenamento de itens de configuração ao longo

do tempo

Ticket – Registro de problema identificado em ferramentas de controle de mudança


1.4. Referências

Manual do Usuário – SPIDER CL – Versão 1.2

MPS.BR Guia Geral:2009

MPS.BR Guia de Implementação:2009 parte 2

2. Conceitos Básicos do Processo de Gerência de Configuração

2.1. O que é Gerência de Configuração ?

Gerência de Modificação ou Gerência de Configuração de Software (Software Configuration

Management – SCM) é uma atividade de apoio que se desenvolve ao longo de todo o processo de

software, comportando as ações de identificar e controlar mudanças, garantir que as modificações

sejam implementadas de forma adequada e comunicar as modificações a todos os interessados

[Pressman, 2006].

O papel principal da gerência de configuração é garantir que a produtividade não seja

prejudicada por erros, problemas ou mudanças, segundo Babich (1986), que define “a arte de

coordenar o desenvolvimento de software para minimizar... confusão é chamada de gerência de

configuração. A gerência de configuração é a arte de identificar, organizar e controlar modificações no

software que está sendo construído por uma equipe de programação. O objetivo é maximizar a

produtividade pela minimização dos erros.”

O processo de Gerência de Configuração é o processo responsável por controlar e acompanhar

a evolução dos produtos de trabalho, fornecendo mecanismos de armazenamento e disponibilização

destes além de avaliar e tratar todas as suas solicitações de modificação.

2.2. Benefícios do Processo de Gerência de Configuração

A sistematização do processo de Gerência de Configuração traz maior precisão para o rastreio

de problemas, maior controle na administração de mudanças e melhor coordenação na manipulação de

produtos de trabalho. O principal ganho é na diminuição de retrabalho e perda de informações, visto

que as modificações têm um processo para controlar a execução de modificações de produtos de

trabalho, diminuindo a chance de que duas pessoas resolvam os mesmos problemas, tratando a

concorrência de acesso e mantendo um repositório bem estruturado com todas as versões de cada

produto de trabalho sob observação da Gerência de Configuração.

2.3. Objetivo do Processo de Gerência de Configuração no contexto do MPS.BR

O processo de gerência de configuração (GCO) do MPS.BR, faz parte dos processos do nível

de maturidade F (parcialmente gerenciado), com o propósito de estabelecer e manter a integridade de

todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos

[SOFTEX, 2009a]. Este propósito é atingido ao passo que processos formais de controle de

modificação são aplicados sobre baselines do projeto, mantendo a integridade dos produtos de trabalho

e posteriormente submetendo-os ao processo de liberação [SOFTEX, 2009a].

O processo de gerência de configuração é composto por sete resultados esperados que norteiam

a implementação do processo de a definição do sistema de gerência de configuração e identificação

dos ites de configuração até a execução de auditorias para verificar o estado das baselines.


Um fato importante no processo GCO, é que este está ligado a todos os demais processos do

MR-MPS por meio do atributo de processo RAP 13, que estabelece: “os produtos de trabalho são

colocados em níveis apropriados de controle” [Softex, 2009]. É competência do GCO estabelecer

quais produtos de trabalho estarão sujeitos a quais níveis de controle, de acordo com sua criticidade.

3. Ferramental de Apoio 3.1. Ferramentais de Apoio

Neste documento, a metodologia de implementação do processo será aplicada a utilização de

dois conjuntos de ferramentas, Conjunto A e B. Isto ocorre para ilustrar como a metodologia proposta

não está ligada a um único grupo de ferramentas, mas que pode ser adaptada para a utilização com

outros conjuntos de ferramentas de gerência de configuração, contanto que estes se adéqüem aos

determinados requisitos:

Seja um sistema constituído por ferramentas que façam o controle de versão, controle de mudanças e a

geração de checklists.

As ferramentas de controle de versão devem ter mecanismos para: a criação de repositório com

capacidade de armazenamento das diferentes versões de um produto de trabalho; operações de checkin e

checkout; atribuir comentários às operações de checkin; sistema de versionamento dos itens do

repositório; recuperação de versões antigas dos itens do repositório ou acesso a configurações específicas;

criação de baselines (pode ser feito por funcionalidade de criação de rótulos ou tags); registro de

histórico de mudanças; controle de acesso e autenticação de usuários; estabelecimento de canais de

comunicação seguros.

As ferramentas de controle de mudança devem ter mecanismos para: a identificação ou registro de

problemas/solicitações de mudança; registrar, nos problemas identificados, atributos como nome, data,

descrição, responsável, tipo, prioridade e categoria ou processo de origem ; mudanças registradas devem

ser passíveis de um ciclo de vida; registro de histórico para cada solicitação de modificação; geração de

relatórios para a contabilização das solicitações de mudança de um projeto; acomodar o plano de gerencia

de configuração e resultados de auditoria (páginas wiki integradas são suficientes para isso); definição de

política de controle e permissão de acesso; autenticação de usuários.

Ferramentas para a geração de checklists devem ter mecanismos para: definição de critérios objetivos;

criação de checklists com os critérios registrados; aplicação dos checklists; armazenamento dos resultados

dos checklists.

Os conjuntos de ferramentas utilizados durante a confecção deste manual são compostos pelas

seguintes ferramentas, respeitando os requisitos citados:

Grupo Ferramenta Fornecedor Versão Data Site de Apoio

A CVS www.nongnu.org/cvs

A Mantis \ www.mantisbt.org

B Subversion CollabNet 1.6.5 22/08/2009 www.subversion.tigris.org

B Trac Edgewall Software 0.11.5 17/07/2009 www.trac.edgewall.org

A/B Spider-CL Projeto Spider 1.0 www.ufpa.br/spider

3.2. CVS

O CVS (disponível em http://nongnu.org/cvs/) é um sistema de controle de versões, usado para

se registrar o histórico de modificações de arquivos. Inicialmente criado por Dick Grune em 1986

como um conjunto de scripts para facilitar o uso do RCS, o CVS começou a ser reescrito na linguagem


C em1989 por Brian Berliner. Hoje o CVS é um software livre, de uso gratuito e mantido pela Free

Software Foundation, sob licença GNU General Public License v2.

A utilização do CVS é feita através de linha de comando, ou através de uma das várias opções

de clientes gráficos (TortoiseCVS, por exemplo), e IDE’s (Integrated Development Environment –

Ambiente de Desenvolvimento Integrado) que fornecem integração com a ferramenta (como o caso da

IDE Eclipse).

3.3. Mantis

O Mantis (disponível em http://www.mantisbt.org/) é uma ferramenta de bugtracking, sob

licença GPL, desenvolvido para auxiliar o controle de modificações, no contexto do processo de

Gerência de Configuração, através do gerenciamento das issues. Issues são relatos de problemas

identificados nos produtos de trabalho, que terão sua evolução acompanhada desde a solicitação da

mudança até seu desfecho.

Por ser um software executado em browser, ele independe de sistema operacional e sua base de

dados pode ser estruturada em MySQL, MS SQL e PostgreSQL. A sua versão mais recente e estável é

a versão 1.1.8, mas atualmente está sendo desenvolvida a versão 1.2.0rc2.

Entre as principais funcionalidades desta ferramenta são identificados: criação de issues;

gerenciamento do ciclo de vida dos issues; registro do histórico dos issues; e controle de workflow da

ferramenta. Outros aspectos marcantes são: a possibilidade de customização; interface amigável,

proporcionando fácil utilização; e a facilidade de extensão através de plugins.

3.4. Subversion

O Subversion, ou SVN, (disponível em http://subversion.tigris.org/) é uma ferramenta de

controle de versão, projeto da CollabNet. Além do controle de versão do conteúdo dos arquivos,

também permite controle de mudanças sobre diretórios, cópias, renomeações e meta-dados. Algumas

das principais funcionalidades do Subversion estão listadas a seguir:

controle de versões de arquivos texto e binário: utiliza um algoritmo para diferenciação binário

que funciona de modo idêntico para arquivos textos e binários;

ramificações de projetos: possui mecanismos para criação de ramos em projetos, permitindo

desenvolvimentos paralelos;

acesso ao repositório: pode ser acessado através de protocolos de rede ou disco local. Sua

localização sempre é determinada através de uma URL.

Entre as vantagens do SVN está o modelo de versionamento da ferramenta, que adota um

sistema de commits atômicos, ou seja, ou um conjunto de modificações é registrado de uma vez no

repositório ou não é, permitindo aos desenvolvedores trabalharem com as alterações como blocos

lógicos, evitando problemas do envio de partes das alterações. Isto alia-se ao fato do SVN versionar

não apenas os arquivos, mas toda a árvore de diretórios, o que implica em ter uma revisão global para

o repositório e revoes específicas para cada diretório e arquivo.

O SVN não conta com interface gráfica, porém clientes gráficos de terceiros fornecem essa

funcionalidade, a exemplo de clientes como o TortoiseSVN e RapidSVN, e conta com clientes e plugins

para integração com alguns IDE’s como o Subeclipse (plugins para eclipse), AnkhSVN e VisualSVN

(ambos para Visual Studio).

A ferramenta se encontra na versão 1.6.6 e está disponível sob licença GNU GPL.


3.5. Trac

O Trac é uma ferramenta de bugtracking utilizada para o controle de mudanças em projetos.

Esta é uma ferramenta utilizada para auxiliar no processo de desenvolvimento de softwares com o

objetivo é gerenciar bugs, sua estrutura é baseada em wiki e acessada via browser. Este aplicativo open

source é implementado em python e sua versão mais estável é 0.11.5, possuindo integração nativa com

o subversion, mas capaz de se integrar com outros sistemas de controle de versão, permitindo

navegação no repositório do projeto.

Por ser baseado em wiki, o Trac permitindo a construção colaborativo e seu ambiente além de

possibilitar o recurso de referências cruzadas, permitindo que suas páginas e componentes sejam

acessados e referenciados em qualquer parte do sistema através de links. Outra característica

interessante é a implementação do conceito de milestones, que representam os pontos de controle ou

marcos do projeto, aos quais as solicitações de modificação podem ser associadas.

3.6. Spider-CL

Spider-CL é uma ferramenta desenvolvida no projeto SPIDER, com propósito de criar

checklists compostos por critérios objetivos para utilização em diversos contextos, provendo

mecanismos para a aplicação destes checklists, mantendo histórico e registrando seus resultados.

Checklists são bastante utilizados para avaliações e inspeções objetivas de produtos de

trabalhos diversos em organizações. Um checklist é uma lista de atributos ou qualidades que devem ser

avaliados em um determinado produto de trabalho, onde cada um desses atributos possui uma lista de

possíveis valores dos quais apenas um pode ser marcado. Um checklist nada mais é do que uma

relação organizada de critérios objetivos [Barros, 2009].

A Spider-CL é uma ferramenta web, que pode ser executada através de servidor Tomcat, sendo

acessível de qualquer navegador web, e seu banco de dados é estruturado em MySQL. Conta com

serviço de controle de acesso através de cadastro de usuários e provê a sistematização do processo de

definição e aplicação de checklists para avaliação, inspeção ou revisão através de critérios objetivos. A

interface da Spider-CL foi desenvolvida utilizando componentes gráficos convencionais como caixas

de textos, tabelas, listas e botões, para permitir fácil utilização [Barros, 2009].

A ferramenta Spider-CL é marcada pelas seguintes características:

É uma ferramenta gratuita;

É portável, sendo desenvolvida como uma aplicação para o servidor Tomcat. A ferramenta

pode ser executada em qualquer servidor capaz de executar o Tomcat 6.0 e o MySQL 5.1;

Possui uma interface de fácil utilização;

Pode ser utilizada para o desenvolvimento de qualquer tipo de checklist objetivo;

Possui controle de acesso e mantém registro de todas as utilizações de cada checklist;

Exporta os checklists preenchidos e seus resultados para o formato PDF.

No contexto da metodologia a ser proposta neste manual os checklists gerados pela ferramenta

Spider-CL serão utilizados para definição de critérios objetivos, necessários para a implementação de

alguns resultados esperados.

4. Instalação/Configuração das Ferramentas


4.1. Conjunto de Ferramentas A

4.1.1. Requerimentos das Ferramentas

A ferramenta CVS não demanda qualquer requerimento especial, já a ferramenta Mantis,

requer um servidor Apache para a sua disponibilização.

4.1.2. Instalação/Configuração das Ferramentas

Primeiramente, será instalado e configurado a ferramenta de controle de versão, nesta

metodologia será utilizado a ferramenta CVSNT 2.5 ou superior

(http://web.telia.com/~u86216177/cvsntinstaller.html) para atuar como o servidor. Inicialmente, deve-

se criar dos diretórios c:\cvsrepos e c:\cvsrepos\cvstemp. Após criado os diretórios, executar o

instalador do CVSNT e direcionar a instalação ao diretório c:\Arquivos de Programa\CVSNT. Feito

isso, basta seguir os passos das figuras abaixo:





Feito a instalação, será necessário configurar o servidor CVS , para isso, deve-se executar o

CVSNT o qual abrirá uma janela exibindo o status do servidor. Antes de iniciar a configuração, deve-

se inicialmente parar os serviços CVSNT Service e CVSNT Lock Service.

Após os serviços parados, o próximo passo será configurar a aba Server Settings. Nesta tela,

será preenchida os campos Default domain onde constará o nome da máquina que estára hospedando o


repositório, Temporary Directory possuirá o diretório da pasta temporária criada anteriormente

(c:/cvsrepos/cvstemp). O CVS server port será a porta 2401 e Lock Server será localhost com a porta

2402.

O próximo passo é configurar a aba compatibility options o qual será marcado apenas a opção

Emulate ‘-n checkout’ bug e em Clients allowed to connect ficará como Any CVS/CVSNT.

Na aba plugins, será listado vários protocolos de acesso ao servidor, nele será selecionado o

protocolo sserver e em seguida clica-se em configure.


Na tela de configuração do protocolo, será habilitado o plugin e nos campos Certificate file e

Private Key File serão preenchidos com o local onde o servidor CVSNT foi instalado e sua

autenticação será feita apenas por senha.

Para finalizar a configuração, na última aba (em advanced) será selecionado apenas a opção

Lockserver listens locally only e manter a opção de dropdown como Internet. Após todas essas

operações serem efetuadas, retornar para a primeira aba e reiniciar os dois serviços (CVSNT Service e

CVSNT Lock Service).


Para instalar o Mantis, basta efetuar o download no site http://www.mantisbt.org/ e

descompactar o arquivo para a pasta onde o apache carrega os projetos. Para instalar o Dokuwiki será

necessário fazer o download na página http://www.splitbrain.org/projects/dokuwiki e descompactá-lo

para o mesmo diretório onde se encontra o Mantis.

Feito a instalação do Mantis e Dokuwiki, será necessário integrá-los para o uso da metodologia.

Primeiramente, deve-se configurar a autenticação de acesso no Dokuwiki a partir do Mantis, criando

um arquivo chamado de mantis.class.php no diretório dokuwiki/inc/auth com o seguinte conteúdo:

<?php

/**

* Mantis auth backend

*

* Uses external Trust mechanism to check against Mantis'

* user cookie.

*

* @author Victor Boctor (http://www.futureware.biz)

*/

require_once( MANTIS_ROOT . 'core.php' );

class auth_mantis extends auth_basic {

/**

* Constructor.

*

* Sets additional capabilities and config strings

*/

function auth_mantis(){

$this->cando['external'] = true;

}

/**

* Authenticates the user using Mantis APIs.


*/

function trustExternal($user,$pass,$sticky=false){

global $USERINFO;

global $conf;

if ( auth_is_user_authenticated() ) {

// okay we're logged in - set the globals

$USERINFO['pass'] = current_user_get_field( 'password' );

$USERINFO['name'] = current_user_get_field( 'username' );

$USERINFO['mail'] = current_user_get_field( 'email' );

$t_project_name = getNS( getID() );

$t_project_id = project_get_id_by_name( $t_project_name );

$t_access_level = access_get_project_level( $t_project_id );

$t_access_level_string = strtoupper( get_enum_to_string( config_get(

'access_levels_enum_string' ), $t_access_level ) );

$USERINFO['grps'] = array( $t_access_level_string );

$_SERVER['REMOTE_USER'] = $USERINFO['name'];

$_SESSION[$conf['title']]['auth']['user'] = $USERINFO['name'];

$_SESSION[$conf['title']]['auth']['info'] = $USERINFO;

return true;

}

// to be sure

auth_logoff();

return false;

}

/**

* Logout from Mantis

*/

function logOff(){

auth_logout();

}

/**

* Retrieves the user data of the user identified by

* username $user. This is used, e.g., by dokuwiki's

* email notification feature.

*/

function getUserData( $user ) {

$userData = false;

$mantis_uid = user_get_id_by_name( $user );

if ( $mantis_uid ) {

$userData['username'] = user_get_field( $mantis_uid, 'username' );

$userData['mail'] = user_get_field( $mantis_uid, 'email' );

$t_project_name = getNS( getID() );

$t_project_id = project_get_id_by_name( $t_project_name );

$t_access_level = access_get_project_level( $t_project_id , $mantis_uid );

$t_access_level_string = strtoupper( get_enum_to_string( config_get(

'access_levels_enum_string' ), $t_access_level ) );

http://www.php.net/global

http://www.php.net/global

http://www.php.net/strtoupper

http://www.php.net/array


$userData['grps'] = array( $t_access_level_string );

}

return $userData;

}

}

?>

Em seguida, criar um arquivo no diretório dokuwiki/lib/plugins/mantis/ com o nome de

syntax.php, dentro deste arquivo deverá conter:

<?php

/**

* Mantis Plugin: Hyperlinks references to Mantis Issues

*

* @license GPL 2 (http://www.gnu.org/licenses/gpl.html)

* @author Victor Boctor (http://www.futureware.biz)

*/

if(!defined('DOKU_INC'))

define('DOKU_INC',realpath(dirname(__FILE__).'/../../').'/');

if(!defined('DOKU_PLUGIN')) define('DOKU_PLUGIN',DOKU_INC.'lib/plugins/');

require_once(DOKU_PLUGIN.'syntax.php');

/**

* A plug-in that hyper links references to Mantis issues. References

* to Mantis issues should use the following format: ~~Mantis:123~~.

*

* All DokuWiki plugins to extend the parser/rendering mechanism

* need to inherit from this class

*/

class syntax_plugin_mantis extends DokuWiki_Syntax_Plugin {

/**

* return some info

*/

function getInfo(){

return array(

'author' => 'Victor Boctor',

'email' => 'vboctor at users . sourceforge . net',

'date' => '2006-05-18',

'name' => 'Mantis Issues Plugin',

'desc' => 'Support References to Mantis Issues',

'url' => 'http://www.futureware.biz',

);

}

/**

* What kind of syntax are we?

*/

function getType(){

return 'substition'; # typo is intentional

}

/**

http://www.php.net/defined

http://www.php.net/define

http://www.php.net/realpath

http://www.php.net/dirname

http://www.php.net/defined

http://www.php.net/define


http://www.php.net/gettype


* What about paragraphs?

*/

function getPType(){

return 'normal';

}

/**

* Where to sort in?

*/

function getSort(){

return 156;

}

/**

* Connect pattern to lexer

*/

function connectTo($mode) {

$this->Lexer->addSpecialPattern('~~Mantis:[0-9]+~~', $mode,

'plugin_mantis');

}

/**

* Handle the match

*/

function handle($match, $state, $pos, &$handler){

$match = substr( $match, 9, -2 ); // strip "~~Mantis:" from start and "~~"

from end

return array( strtolower( $match ) );

}

/**

* Create output

*/

function render($format, &$renderer, $data) {

if ( $format == 'xhtml' ) {

$renderer->externallink( MANTIS_URL . 'view.php?id=' .

$data[0], $data[0] );

return true;

}

return false;

}

}

?>

Feito as configurações anteriores, agora é necessário configurar os arquivos de configuração do

Mantis, primeiramente, deve-se ir no diretório raíz da ferramenta de controle de mudança (Mantis) e

acrescentar as seguintes linhas de comando no arquivo config_inc.php:

$g_wiki_enable = ON;

$g_wiki_root_namespace = 'mantis';

Com a adição dessas linhas de código, fará aparecer um link no menu do Mantis para acessar o

Dokuwiki. E por fim, no diretório mantis/core/ no arquivo html_api.php, buscar a linha de comando:

http://www.php.net/substr


http://www.php.net/strtolower


$t_menu_options[] = '<a href="wiki.php?type=project&id=' . $t_current_project

. '">' . lang_get( 'wiki' ) . '</a>';

e modificá-la por:

$t_menu_options[] = '<a href=“wiki.php?type=project&id=' . $t_current_project

. '” target=“_blank”>' . lang_get( 'wiki' ) . '</a>';

Após efetuar esses passos, a integração entre o Mantis e o Dokuwiki estará concluída. Para

acessar o conteúdo da wiki, será necessário o usuário estar logado no Mantis.

4.2. Conjunto de Ferramentas B

4.2.1. Requerimentos das Ferramentas

A ferramenta Subversion não demanda nenhum requisito especial, porém na configuração

utilizada neste manual, foi utilizado um servidor apache para a disponibilização da mesma. A

ferramenta Trac demanda a instalação do Python 2.6.4, as ferramentas Setuptools e Genshi para a sua

devida configuração, além de ser desejado um servidor Apache para sua disponibilização.

4.2.2. Instalação/Configuração das Ferramentas

4.2.2.1. Subversion

A instalação do Subversion necessita apenas do download do instalador do site do

desenvolvedor, e um setup será feito automaticamente, apenas seguindo os passos da instalação.

A configuração do servidor SVN, depende do tipo de servidor desejado. Pode ser servido por

servidor próprio do SVN (SVNServe) ou através de um sistema Web Server (como o Apache)

No caso de configuração do servidor Apache, é necessário a instalação do mesmo (download

disponível em www.apache.org/ ). A instalação é guiada por um instalador.

Localize o arquivo de configurações do apache e insire a linha abaixo no final do arquivo

Apache2\conf\httpd.conf (apenas um caminho para exemplificar, o diretório deve corresponder ao

endereço do arquivo de configuração do svn):

Include "C:/Svn/subversion.conf"

Navegue até a pasta Apache2\bin, onde se encontra o htpasswd.exe. Utilizaremos o comando

htpasswd para criar usuários e atribuir suas senhas. Exemplo:

htpasswd -cm C:\Svn\svn-auth-file NomeUsuario

New password: *****

Re-type new password: *****

Adding password for user NomeUsuario


Para adicionar outros usuários o procedimento é o mesmo. A única mudança está no parâmetro

-c que impõe a criação / substituição do arquivo svn-auth-file. Ou seja, após a primeira execução o

comando passa a ser:

htpasswd -m C:\Svn\svn-auth-file NovoUsuario

Para definir as permissões de acesso e leitura do repositório, deve ser criado um arquivo svn-

acl, onde irão ser listadas as permissões de cada usuário, para cada repositório ou diretório do

repositório. Este arquivo pode ser alterado conforme novos repositórios forem criados.

Agora é necessário definir no Apache o caminho para os repositórios que forem criados. Para

isso, deve ser inserido no arquivo de configuração do Apache, um bloco como segue:

<Location /nome_projeto>

DAV svn

SVNPath diretório/do/repositório

AuthType Basic

AuthName “Subversion Nome Projeto repository”

AuthUserFile diretório/do/arquivo/svn-auth-file

Require valid-user

AuthzSVNAccessFile diretório/do/arquivo/svn-acl

</Location>

O repositório passará a estar disponível através do endereço:

Endereço.do.servidor:8080/nome_do_projeto

É possível alterar a porta na qual o Apache é acessado neste mesmo arquivo, caso a porta esteja

sendo utilizada por outra aplicação.


Para definir um canal de acesso seguro, pode ser configurado um módulo SSL (Secure Socket

Layer) no Apache, através de instalação do OpenSSl (no Windows) e a criação de um certificado de

segurança. 4.2.2.2. Trac

Ver Documentação do Trac para informações sobre a instalação em ambiente Linux (disponível

em http://trac.edgewall.org/wiki/0.11/TracInstall) ou Windows (disponível em

http://trac.edgewall.org/wiki/TracOnWindows).

4.3. Spider-CL

Ver Manual do Usuário – SPIDER CL – Versão 1.2

5. Implementação do Processo de Gerência de Configuração do MPS.BR 5.1. Resultado Esperado: GCO1

Um Sistema de Gerência de Configuração é estabelecido e mantido

5.1.1. Objetivo do GCO1

O primeiro resultado esperado, GCO1, exige que um sistema de gerência de configuração seja instalado

na organização. Para que seja instalado esse sistema é necessário a implementação de três subsistemas: controle

de versão, controle de modificação e gerenciamento de construção [SOFTEX, 2009a].

O controle de versão é responsável em sistematizar o versionamento dos produtos de trabalho

de forma segura e controlada, assegurando que versões anteriores possam ser resgatadas. No que diz

respeito à segurança, pode-se definir políticas de controle de acesso, enquanto que políticas de controle

de concorrência podem ser implementados para garantir uma maior organização e controle nos

produtos de trabalho [SOFTEX, 2009a].

O controle de modificação gerencia a evolução de problemas identificados nos produtos de

trabalho desde sua solicitação até a sua conclusão. Por fim, a função do gerenciamento de construção é

transformar itens de configuração fontes em produtos para o usuário final, um exemplo disso é tornar

código fonte em um executável [SOFTEX, 2009a].

Um ponto importante que deve ser observado na implantação de um sistema de gerência de

configuração é a possibilidade de implementação pela organização sem o auxílio de ferramentas

automatizadas [SOFTEX, 2009a]. Porém, o auxílio de uma ferramenta torna-se indispensável, pois

existem operações difíceis de gerenciar apenas com documentação, como regaste de históricos e

versões anteriores, evoluções de versões paralelas de um dado projeto, controlar o ciclo de vida de

solicitações de mudanças, mapeamento entre itens de configuração e baselines.

5.1.2. Implementação com base nas Ferramentas de Apoio

Primeiramente, deve ser estabelecido o repositório para o projeto, de acordo com estratégias

definidas pela organização, através de ferramenta de controle de versão. Neste momento também é


estabelecido o banco de dados de solicitações de mudanças, isto é, os projetos são instanciados nas

ferramentas de controle de mudança, para o devido controle sistematizado.

Com os sistemas de controle de versão e de mudança devidamente estabelecidos para o projeto,

deve ser iniciado um plano de gerencia de configuração, para descrição dos procedimentos referentes a

gerencia de configuração através destas ferramentas. O plano é definido, nesta metodologia, através de

paginas wiki integradas às ferramentas de controle de mudança, e nele deve ser descrito: os

responsáveis ou envolvidos; a identificação dos itens de configuração; planejamento de baseline;

estrutura do repositório; ferramentas utilizadas no processo de gerência de configuração e suas

metodologias e políticas de uso; descrição do processo de gerencia de configuração; e planejamento

das auditorias de configuração.

Conjunto de Ferramentas A

Com o servidor de repositório configurado, na ferramente CVSNT, na aba Repository

configuration será selecionado o botão add para criar um repositório.

Ao clicar em add, será aberto uma janela para configurar o respositório adiocionado, o qual

será preenchido o local onde será criado o repositório, o nome que será usado para acessar o

repositório e uma descriação do repositório, após os três campos preenchidos, confirmar a operação

clicando em ok.


Note que na metodologia deste manual, o repositório será criado em

c:/cvsrepos/portaldaamazonia, além disso, será criado uma pasta denominado cvstemp dentro do

diretório c:/cvsrepos o qual servirá como um diretório de arquivos temporários para o servidor de

CVS.

Após confirmar a configuração, será exibido uma tela avisando que não existe um repositório

no local especificado e então perguntará se deseja criar algum, aceitando esta operação irá criar o

repositório, juntamente com uma pasta denominada CVSROOT onde contém todos os arquivos de

configuração do CVS. Quando a operação de criação de repositório for concluído, será exibido o

repositório na lista de Repository configuration


Quando o repositório for criado, será necessário criar o usuário administrador do CVS, para

isso, é necessário abrir o prompt de comando e digitar set cvsroot=:sspi:<nome do computador>:<o

nome do repositório, no caso da metodologia, será /portaldaamazonia>. Depois de configurar o

ambiente, será criado o primeiro usuário digitando o comando cvs passwd –r <administrador do

sistema> -a <login que será utilizado>, logo após será pedido a senha para este usuário. Depois que a

senha for definida, o usuário será criado no arquivo passwd dentro do diretório CVSROOT do

repositório e então o servidor estará configurado.

Após configurar o repositório, um projeto será submetido utilizando o cliente TortoiseCVS,

para isso, seleciona-se o diretório do projeto e então usar a opção Make New Module...


Na tela que será exibida, o campo CVSROOT deverá ser preenchida com

:sserver:<usuário>@<computador do servidor>:/<nome do repositório> e selecionar ok.

Feito a submissão no repositório, agora o momento de criar um projeto no Mantis selecionando o

link Manage.

Dentro de Manage, o link Manage Projects será selecionado e em seguida o batão Create New

Projetc.


Na página seguinte será exibida uma tela de formulário, nela deve ser preenchido com o nome

do projeto, o sua situação, a permissão de visualização e uma breve descrição.

Para definir o Plano de Gerência de Configuração, será utilizado o Dokuwiki integrado a partir

do link no menu. No Mantis, cada projeto possuirá uma wiki correspondente que será possível o acesso

apenas se o usuário estiver logado no Mantis. Nesta metodologia, será criado um Plano de Gerência de

Configuração Geral que será utilizado como template para os demais projetos, para instanciar este

plano, basta selecionar a opção Project como all projects.

Dentro da página wiki, não será exibido nada, inicialmente, para editá-lo, basta clicar em Create

this page e escrever o templete do Plano de Gerência de Configuração.


Para criar o Plano de Gerência de Configuração em um projeto, basta selecionar o projeto

desejado no Mantis e clicar em wiki. Ao selecionar Create this page, é recomendável a criação de um

link para direcionar o Plano de Gerência de Configuração para uma outra página, para melhor

organização, para isso, basta digitar o nome do link entre colchetes duplos.


Conjunto de Ferramentas B

O repositório do projeto deve ser criado na ferramenta Subversion com a estrutura trunk,

branches e tags, onde: a pasta trunk é onde será armazenada a principal linha evolutiva dos itens de

configuração; em branches, serão armazenados os ramos do projeto; e pasta tags é onde serão

guardadas as baselines do projeto.

A criação do repositório é feita através do prompt de comando, com a linha:

svn create caminho/do/repositório

Ou usando o TortoiseSVN, basta criar uma pasta no local desejado e clicar com o botão direito

sobre a mesma e acessar a opção “Create repository here” no menu do TortoiseSVN.

Criação de repositório no TortoiseSVN

Com isso, temos um repositório criado, e pronto para uso. Agora devemos adicionar o conteúdo

do repositório, mas para isso devemos primeiro organizar o repositório na estrutura trunk, branches e

tags. Basta criar as três pastas em um diretório qualquer localmente, e utilizar o comando de importar

do SVN:

svn import /diretório/local/a/importar /caminho/do/repositório


Usando o TortoiseSVN, o diretório a ser importado, deve ser selecionado e então usar a opção

“import” do TortoiseSVN.

Importando conteúdos para o repositório


Figura 5.4 – Visualização do repositório através do TortoiseSVN

Agora, deve ser instanciado um ambiente Trac para o projeto. O ambiente é instanciado através

de linha de comando, a partir do diretório Scripts onde o Python foi instalado. Deve ser fornecido um

caminho onde o ambiente será configurado. O comando é:

trac-admin /diretório/do/ambiente initenv

Durante a criação do projeto, deve ser definido: nome do projeto; conexão com um banco de

dados; tipo de repositório (SVN, neste caso); e caminho para o repositório. Com isto será criado o

sistema de controle de mudança já integrado ao sistema de controle de versão.

Criação de um ambiente Trac para um projeto

O projeto criado agora aparecerá entre os projetos disponíveis do Trac, sendo acessível pelo

browser conforme foi configurado o servidor durante a instalação do Trac.


Visualização de Projetos Disponíveis no Trac

O plano de gerencia de configuração deve criado em uma pagina wiki do Trac. Para isso,

usuários com permissão de edição de paginas, podem acessar a seção “wiki” do Trac, e lá utilizar o

botão “Edit this page” para modificá-la.

Editando páginas wiki do Trac

Na tela de edição da página wiki, novas páginas podem ser criadas, criando novos links. Para

isso basta colocar o nome da pagina em notação camelo ou utilizando o prefixo “wiki:”.


Adicionando Link para criação do plano de gerência de configuração

Após submetidas as mudanças, o link aparecerá na pagina.

Link para o plano de gerência de configuração

A partir do link criado pode ser criado o plano de gerência de configuração, com as seções

listadas anteriormente.


Exemplo de Estrutura de Plano de Gerência de Configuração na Ferramenta Trac.

5.1.3. Ajustes na Ferramenta

Para que estes resultados esperados sejam contemplados, é necessária a integração com o

sistema DokuWiki para integrar uma wiki ao Mantis. A partir dessa instalação, será possível criar uma

instância de uma página da wiki onde haverá o plano de gerência de configuração.

5.2. Resultado Esperado: GCO2

Os itens de configuração são identificados com base em critérios estabelecidos



O segundo resultado esperado, GCO2, requer a identificação dos itens de configuração do

projeto. A identificação necessita que critérios sejam estabelecidos para definir o que será um item de

configuração (IC). Esses critérios, geralmente, encontram-se no Plano de Gerência de Configuração

[SOFTEX, 2009a].

Com os critérios definidos, a identificação de IC envolve (1) avaliar os produtos de trabalho de

acordo com os critérios estabelecidos definindo os itens de configuração; (2) atribuir identificadores

únicos aos itens selecionados, isto é, estabelecer um padrão de nomenclatura para os itens de

configuração; e (3) listar os itens de configuração registrando detalhando suas características (atributos

como nome, conteúdo, responsáveis, autores, localização no repositório, nível de controle desejado).


Tendo um sistema definido, é necessário definir os itens de configuração. Critérios objetivos

devem ser elaborados para condução da identificação dos itens de configuração, o que pode ser obtido

através da utilização da ferramenta Spider-CL. No Spider-CL, os critérios serão definidos e integram

checklists que podem ser aplicados e registrados através da própria ferramenta. Os resultados obtidos

devem ser anexados aos planos de gerencia de configuração, encontrados nas paginas wiki das

ferramentas de controle de mudança.


Checklist criado e aplicado através do Spider-CL

Os itens de configuração definidos com base nos critérios objetivos devem ser listados no plano

de gerência de configuração e devem ter informações sobre atributos como o nome, responsáveis,

localização e conteúdo. A regra de padronização da nomenclatura dos itens de configuração definida


pelas organizações também deve ser inclusa no plano de gerencia de configuração, juntamente com

regras de versionamento.


Para implementar o GCO 2 no conjunto de ferramentas A, será utilizado o checklist definido

anteriormente o qual estará anexado junto à lista de Itens de configuração. Para anexar um arquivo no

Dokuwiki, basta selecionar a opção Add images and other files o qual abrirá uma nova janela.

Na nova janela, basta selecionar o diretório em que se encontra o checklist no campo Select file

to upload e, em seguida, clicar em Upload. Esta operação fará com que seja carregado o arquivo em

uma lista, para adicioná-lo no documento, deve-se clicar no documento adicionado na lista.



A implementação deste resultado esperado envolve a criação do checklist na ferramenta Spider-

CL e colocar no plano de gerência de configuração os itens de configuração identificados com as

informações apropriadas, conforme foi definido pela organização e de forma compatível com as

informações requeridas pelo MPS.BR, já citadas.

O checklist pode ser anexado ao plano de gerência de configuração utilizando o botão “Attach

File”.

Anexando checklist ao plano

Pode-se adicionar referências ao arquivo na seção apropriada do plano, de forma a evidenciar

que os itens de configuração foram identificados conforme os critérios indicados.


Criando referencia ao checklist na seção apropriada

Exemplo de Plano de Gerência de Configuração



Para que estes resultados esperados sejam contemplados, é necessária a integração com o

sistema DokuWiki para integrar uma wiki ao Mantis. A partir dessa instalação, será possível criar uma

instância de uma página da wiki onde haverá o plano de gerência de configuração.


Os itens de configuração sujeitos a um controle formal são colocados sob baseline


O GCO3 descreve o estabelecimento de baselines nos diferentes estágios do ciclo de vida do

software de forma a aumentar o controle sobre itens de configuração que necessitam de um controle

formal, por servirem de insumos para as diversas atividades do processo de desenvolvimento. O

processo de estabelecimento de baselines envolve atividades de planejamento, autorização por

responsáveis (normalmente o CCC), documentação dos pertencentes a baseline e disponibilização aos

interessados [SOFTEX, 2009a].

O Guia de Implementação [SOFTEX, 2009a] sugere que pode ser utilizado o mecanismo de

criação de rótulos (tags), presente em ferramentas de controle de versões, sobre uma configuração de

versões de IC, é suficiente para implementar o conceito de baselines.


Em algum momento do projeto, haverá necessidade de eleger configurações ao estado e

baselines, e estas devem ser planejadas, ou seja, devem ser definidos no plano de gerência de

configuração o padrão de identificação das baselines, quando serão geradas, critérios de validação e

questões relacionadas as auditorias sobre essas baselines.

As baselines devem ser geradas através da criação de um rótulo (tag) sobre a configuração que se

deseja definir como linha base, funcionalidade das ferramentas de controle de versão. Deve ser

atribuído um nome compatível com o padrão de nomenclatura definido para as baselines.utilizou-se

nomes que contenham as informações:

[Nome do projeto][tipo de baseline][versão][data no formato AAAAMMDD]

Quando uma baseline for gerada, esta deve também ser cadastrada nas ferramentas de controle

de mudança como “versões” do projeto, de forma que as solicitações de mudanças registradas estejam

relacionadas as baselines apropriadas.

A definição de baselines é parte do escopo do GCO 3 e é necessário evidenciar tanto o

planejamento quanto a criação dessas baselines.



No conjunto de ferramentas A, o processo de criação de baselines será feita utilizando o CVS, no

qual, após ser decidido a configuração da versão que se tornará uma baseline e devidamente aprovado

em uma auditoria, a funcionalidade cvs tag será utilizada para submeter o projeto ao repositório. A tag

estará associada à esta versão do projeto e a todos os itens de configuração presentes na mesma. Para

utilizar a funcionalidade, basta clicar com o botão direito no projeto ou item de configuração desejado

e escolher a opção tag.

Em seguida, uma janela contendo um campo onde deverá ser preenchida o nome da tag será

exibida, é muito importante que este nome seja um identificador único de baseline e esteja definido no

Plano de Gerência de Configuração, para facilitar nos mapeamentos e recuperação. Quando for

necessário recuperar a baseline, será utilizado a funcionalide cvs checkout, contendo como parâmetro o

identificador da baseline desejada.



A criação de baselines será feita através da funcionalidade de criação de rótulos do Subversion.

Esta funcionalidade pode ser utilizada de duas maneiras: gerar uma baseline de uma revisão específica

do repositório/diretório do repositório ou gerar uma baseline a partir de uma configuração contendo

itens em diferentes revisões.

Para a primeira opção é utilizada a funcionalidade de rótulo apontando o endereço do que se

quer gerar uma baseline e colocando-a na pasta “tags” do repositório, sob um nome a ser padronizado.

svn copy <diretório que irá virar uma baseline>

repositório/tags/”NomeDaBaseline” –m “comentário”

Usando o TortoiseSVN, é feito utilizando a funcionalidade “copy to” ou “branch/tag”, na tela

de visualização do repositório, após selecionar um diretório a ser transformado em baseline.


Na tela seguinte, será escolhido o local onde a baseline será armazenada, que deverá ser

definida como o diretório /tags do repositório, e seguido do nome que se deseja identificar a baseline.

Além disso, é possível escolher qual revisão do diretório irá originar a baseline e definir um

comentário para a criação da baseline.


Criação de Baseline no Subversion (Tags).

Após criada a baseline, esta deverá ser registrada no Trac como uma versão do sistema, através

da opção “versions” no menu “Admin”.


Para cada versão registrada, deve ser cadastrado informações sobre esta para controle do que

foi feito, conforme estratégia definida pela organização.


Para recuperar uma baseline, é feito o procedimento semelhante ao checkout de uma

configuração qualquer, apenas mudando o caminho desejado para o diretório onde se encontra a

baseline, dentro do diretório “/tags”.

5.4. Resultado Esperado: GCO 4

A situação dos itens de configuração e das baselines é registrada ao longo do tempo e

disponibilizada

5.4.1. Objetivo do GCO 4

O quarto resultado esperado, GCO4, exige que haja o registro de toda operação efetuada sobre

os itens de configuração e baselines, e esse registro esteja disponível para todos os interessados do

projeto, de forma que seja possível conhecer a situação dos itens de configuração e baselines. O

sistema de gerência de configuração deve possuir mecanismos para a recuperação de versões mais

antigas de itens de configuração a qualquer momento do projeto. O guia de implementação cita que

além de diferenciar duas verões de um mesmo item de configuração, é interessante poder diferenciar o

estado em que se encontra o item de configuração no ciclo de vida (analise, desenvolvimento, teste) o

que pode ser obtido através do mecanismo de ramificação (branch), presente em ferramentas de

controle de versões[Softex, 2009].

Outra exigência importante neste resultado esperado é a possibilidade de mapear as baselines

com todas as versões de IC que as compõem, além de poder diferenciar as baselines de acordo com as

solicitações de mudança implementadas[Softex, 2009a].


Conforme os itens de configuração evoluírem ao longo do projeto e baselines forem definidas,

surge a necessidade de identificar, diferenciar e recuperar o conteúdo de itens de configuração em

diferentes etapas do projeto, ou seja, é necessário assegurar que todos os interessados tenham acesso e

conhecimento sobre o histórico e situação específica de itens de configuração ou baselines ao longo do

tempo. Conforme citado anteriormente, as ferramentas de controle de versão armazenam um histórico

das alterações realizadas sobre os itens do repositório, e é através desta funcionalidade das ferramentas

que pode-se alcançar o GCO 4.

Os históricos das ferramentas de controle de versão devem fornecer informações suficientes

para um mapeamento preciso dos componentes de uma determinada baseline, apresentando a versão

específica de cada item de configuração e permitindo a recuperação desta configuração. Com essas

informações é possível fazer comparações entre releases, contabilizando o que foi feito ao longo do

projeto. Aliado ao sistema de controle de mudanças, é possível um controle ainda maior sobre o

andamento do projeto.


Para implementar o quarto resultado esperado (GCO 4), no conjunto de ferramentas A, será

utilizado a ferramenta CVS. Para verificar a diferenciação entre versões de itens de configuração,

deve-se selecionar o item desejado e em seguida utilizar a funcionalidade History do TortoiseCVS.


Após clicar na opção History será exibida uma árvore de evolução para um determinado item de

configuração contendo todas as suas versões, também será exibido um rótulo ligando a uma

determinada versão do IC se a mesma estiver associado à uma baseline. Ao selecionar uma das

versões, será exibida a data de submissão, o autor e o comentário onde estará descrito a modificação

que foi realizada. A tela de History será utilizado para fazer o acompanhamento do histórico dos itens

de configuração.


Histórico de Alterações do CVS.

Para efetuar o mapeamento dos itens de configuração com a baseline, a mesma deve ser

selecionada e em seguida a opção Web log do TortoiseCVS deve ser utilizada.


Na tela de Weblog será exibida todos os itens de configuração presentes no projeto, juntamente

com todas as versões existentes de cada item de configuração. Para mapeá-los com as baselines, existe

um campo denominado symbolic names em cada IC, neste campo haverá uma lista de baselines sendo

associada com a versão do item de configuração correspondente, no exemplo da figura, a versão 1.1 do

primeiro item de configuração está presente na baseline portaldaamazonia-release_1_1-2009_11_22.

Os itens de configuração estarão separadas por uma sequência de iguais (“======”) e as revisões dos

itens de configuração estarão separadas por uma sequência de hífens (“---------”).

Tela de log do CVS (a partir do Web log)


As funcionalidades History e Web Log são parecidos, porém, a funcionalidade History permite

visualizar apenas em um item de configuração, enquanto que a funcionalidade Web Log permite

visualizar um conjunto de IC (uma pasta ou todo o projeto) ao mesmo tempo, por esse motivo, a

funcionalidade Web log também será utilizado para efetuar o acompanhamento do histórico de todo o

projeto.


No conjunto de ferramentas B, o GCO 4, é obtido através da interpretação das informações dos

relatórios fornecidos pela funcionalidade svn log, que funciona como uma máquina do tempo do

repositório, informando todas as alterações feitas, listando para cada alteração: autor, data (ano, mês,

dia e hora), número de revisão e o comentário da operação de commit. Mais detalhes podem ser

obtidos através de variações do comando svn log, como a adição de opções para listar apenas

mudanças de uma revisão em específico ou detalhamento de mudanças envolvendo criação, exclusão

ou movimentação de arquivos.

No caso de utilização de um cliente gráfico, as informações podem aparecer de forma mais clara.

O TortoiseSVN, oferece uma interface para visualização de histórico mais clara, mas suas informações

são todas advindas do próprio svn log.


Histórico de Alterações do Subversion.

É importante em dados momentos do projeto realizar a comparação entre configurações,

baselines ou até mesmo em itens de configuração, para a verificação de sua evolução. O SVN permite

também a visualização de mudanças no próprio corpo do arquivo, através da funcionalidade svn diff,

que permite visualização das linhas alteradas em um dado arquivo de uma revisão para outra. Para

realizar o mapeamento entre configurações/baselines e a versão de seus itens, é possível utilizar a

funcionalidade svn list, que lista todos os itens de uma dada revisão.


Visualização dos Itens e suas Revisões em uma Baseline no Subversion.


Modificações em itens de configuração são controladas


Itens de configuração componentes de baseline devem ter suas mudanças formalmente

controladas, sendo assim, as solicitações de mudanças sobre estes devem ser devidamente analisadas

buscando verificar o impacto no projeto, autorizadas por responsáveis e comunicadas a todos os

interessados a fim de evitar retrabalho e conseqüências indesejadas ao projeto. Este controle requer um

ciclo de vida e a definição de critérios para a aprovação das mudanças.

De acordo com o Guia de Implementação, pelo menos os seguintes passos são registrados: (1)

Documentação da necessidade de modificação; (2) Análise de impacto da modificação; e (3) Avaliação da

modificação (aprovação ou reprovação). Após a implementação de uma modificação, ao menos os

seguintes passos são usualmente registrados: (1) Verificação da implementação; e (2) Atualização da

baseline com a modificação. Caso seja decidido pelo CCC, também pode ser feita a liberação da baseline.

Nos momentos pertinentes desse processo, os interessados e autorizados são comunicados sobre o

andamento da solicitação [Softex, 2009a].



Cada ferramenta de controle de mudança possui um mecanismo de registro de problemas,

geralmente chamado de issue, e através desse mecanismo, os problemas são registrados e

acompanhados através de um ciclo de vida baseado em estados. Deve ser registrado no plano de

gerencia de configuração o ciclo de vida e os critérios para a aprovação das solicitações de mudança. A

resolução dos problemas e mudanças é acompanhada alimentando os issues com informações das

ações tomadas, alterando o estados dos issues conforme sua evolução e atribuindo-os a responsáveis.

Cada problema encontrado ou necessidade de mudança deve ser registrada através de um issue.

No preenchimento do formulário da issue, deve-se registrar:

Nome: identificador claro e facilmente relacionável ao problema ou mudança em

questão. É uma boa prática criar uma padronização para os nomes de issues, tornando

mais fácil a interpretação dos issues apenas pelo nome;

Descrição da solicitação de modificação: onde relatado o caráter da mudança, quais os

itens de configuração relacionados, a origem do problema e demais informações que

facilitem a solução do modificação;

Tipo: classificar o issue de acordo com os possíveis tipos definidos pela organização.

Geralmente, os tipos padrões são “Problema”, “Tarefa” e “Melhoria”;

Categoria: Qual a área de origem da solicitação de mudança, sejam áreas de processo ou

componente do sistema.

Versão: especificar a qual é a versão do sistema, a mudança diz respeito.

Estes campos são os principais, geralmente encontrados na maioria das ferramentas de

bugtracking ou controle de modificação, porém, de acordo com a necessidade da organização, novos

campos podem ser adicionados, e dependendo da ferramenta, outros campos podem ser oferecidos

como data de entrega, configuração do sistema, a qual marco do projeto a mudança está relacionado,

entre outros.

O controle das modificações é obtido a partir do acompanhamento da evolução dos issues em

harmonia com as alterações feitas sobre os itens de configuração, onde cada ação tomada e alteração

feita deve ser registrada no issue, atualizando-o para que sempre esteja em sincronia com a

implementação da modificação. As modificações devem ser acompanhadas até serem fechadas, ou

seja, até que atinjam um estado final, seja uma solicitação recusada ou um solicitação completamente

implementada. O controle pode ser feito através dos históricos do sistema de controle de mudança, que


armazena todas as mudanças feitas nas solicitações de modificação, fornecendo uma visão abrangente

das ações tomadas para a conclusão das modificações.


Para efetuar o registro das solicitações de mudança no conjunto de ferramentas A, deve-se

clicar no link Report Issue no menu superior do Mantis.

Em Report Issue, será exibido um formulário onde deverá ser preenchido com as informações de

toda solicitação de mudança que for feita, nesse formulário contém os campos:

Category: campo referente à área de processo do produto de trabalho que originou a

solicitação de mudança;

Reproducibility: conterá a frequência que o problema ocorre, exemplos de atributos para

este campo podem ser sempre, às vezes, nunca ou variado. Mas fica a cargo da

organização a escolha desses atributos que devem estar contidos no Plano de Gerência de

Configuração;

Severity: refere-se à gravidade do problema, ou seja, o quanto o problema afeta no

projeto;

Priority: refere-se à urgência que o problema deve ser resolvido. Este campo trabalha em

conjunto com o campo Severity, pois um problema crítico ao projeto, geralmente possui

alta prioridade;

Summary: local onde será definido o nome da issue, ou seja, o identificador do problema;

Description: área onde conterá a descrição detalhada do problema;


Addicional Information: campo opicional no qual poderá ser descrito uma possível

solução do problema ou experiências de ocorrência do mesmo problema.

Criação de issue na ferramenta Mantis.

Para submiter a issue para disponibilizar para os demais da equipe, basta clicar no botão Submit

Report.

Para executar o controle na issues, a funcionalidade View Issues será utilizada, ao selecionar esta

funcionalidade, será listada todos os problemas exibindo os seus Ids, categorias, severidades, estado,

data da última atualização e o nome do problema.


Figura 5.20- Visualização de issues (View Issues)

Ao selecionar uma issue, será possível visualizá-la de forma mais detalhada, tendo acesso a sua

descrição, as issues que possuem relacionadas e ao seu histórico de mudanças. O histórico de

mudanças serve para efetuar o acompanhamento da evolução da issue, regisrando a data da atualização

e seu autor, os campos foram modificados e a mudança que foi realizada. Uma issue pode atualizada

clicando-se no botão Update Issue.


Figura 5.21- Histórico de mudanças de issues.

Dentro da página de atualização da issue será exibida uma tela onde será possível alterar além

dos campos preenchidos ao se registrar uma nova issue, os campos:

Assigned to: este campo encaminhará o problema à algum integrante do projeto para sua

resolução;

Status: este campo indicará em que estado a solicitação de modificação se encontra, ou

seja, indicará se uma determindada issue está resolvida, confirmada a ocorrência do

problema, designada para alguém corrigir ou fechada. Fica a cargo de cada organização a

definição dos status das issues que devem estar contidos no Plano de Gerência de

Configuração.


Resolution: indica como uma issue foi finalizada, ou seja, verifica se uma dada issue foi

corrigida, suspensa, duplicada ou impossível de corrigir. Além indicar se a issue está

ativa (caso não tenha sido finalizada) ou se foi reativada.

Add note: este campo será utilizado para preencher com um comentário toda vez que a

issue for atualizada, descrevendo o motivo e a resolução, caso a issue tenha sido

finalizada;

Conjunto de ferramentas B

No conjunto de ferramentas B, problemas devem ser identificados com a criação de tickets no

Trac (Create New Ticket).


Tela de criação de tickets

Para cada ticket deve ser cadastrado: um nome (summary)de acordo com o padrão definido pela

organização; um autor (reporter), que é preenchido automaticamente com o usuário acessando

atualmente o sistema; uma descrição do problema/solicitação de mudança (description) respeitando o

padrão estabelecido; um tipo que pode ser problema/defeito (defect), melhoria (enhancement) ou uma

tarefa (task); a prioridade de resolução do problema que varia de trivial a blocker; no caso de

documentação, a área de processo da qual o problema advêm (campo category); a versão sobre a qual

o problema ocorre (campo version, definido durante a criação de baselines); e deve ser apontado um

responsável, se houver, para a resolução do problema.


Criação de ticket na ferramenta Trac.

Caso um ticket impeça a resolução de outro, ou seja, um ticket esteja “bloqueando” outro, deve

ser preenchido o campo “Blocking” com o número do ticket que está sofrendo o bloqueio. De forma

análoga, tickets que são bloqueados podem ter o campo “Blocked by” preenchido com o numero do

ticket que o está bloqueando.

O campo “milestone” (marcos), representa um marco ou ponto de controle do projeto, e

durante o cadastro, deve ser registrado os assuntos discutidos na reunião. Todos os tickets criados

referentes a problemas apontados durante àquela reunião, devem ter o campo milestone preenchido

com o referido marco.

Para cadastrar um marco, deve-se acessar o menu “Roadmap”, e usar o botão “Add new

milestone”.


Tela “Roadmap”

Durante o cadastro de um novo milestone, deve ser fornecido um identificador e uma descrição

(preferencialmente os assuntos tratados durante o mesmo).

O acompanhamento das mudanças que estão ocorrendo no projeto é possível através do sistema

de visualização de tickets (view tickets), onde o usuário pode obter uma lista dos tickets do projeto

ordenados e filtrados conforme desejar, de acordo com buscas SQL. A lista é útil para informar o

andamento das várias solicitações de mudança registradas.


Visualização de Tickets no Trac (Ticket View).

Também é possível fazer o acompanhamento do andamento dos milestones, ou seja, verificar o

estado de resolução das solicitações de mudança registada em um dado marco ou ponto de controle.

Isto pode ser obtido acessando a funcionalidade “Roadmap”, que listará todos os milestones

cadastrados com uma barra de estado que representa a porcentagem de quantos tickets foram

resolvidos. Acessando um milestone, será apresentada a lista de issues específicas àquele marco.

Exibição dos Milestones do projeto no Trac (Roadmap).

A resolução de um ticket deve seguir um ciclo de vida, onde o ticket parte do estado “novo”,

pode ser atribuído a algum responsável, é aceito, e é resolvido ou redirecionado para outra pessoa,


renovando o ciclo. Para isto, o ticket deve ser acessado através da tela “view tickets” e utilizar a seção

“action” para mudar o estado do ticket, conforme este for sendo trabalhado.

Mudança de estado do ticket

Além disso, sempre que uma ação for tomada para resolver um ticket, envolvendo ou não

mudança do seu estado, deve ser adicionado um comentário (campo comment) descrevendo o que foi

feito.

Comentando modificações no ticket

Todas as alterações realizadas sobre o ticket são armazenadas sob forma de histórico. O

histórico de mudanças lista as ações tomadas com os seus comentários, os usuários responsáveis pelas

mudanças e as datas de ocorrência. O histórico é localizado na tela do próprio ticket.


Histórico de mudanças do ticket.


Na ferramenta Trac, não há suporte para criação de tickets com relacionamento. Para que tal

funcionalidade seja utilizada, é necessário a instalação do plugin MasterTickets, conforme descrito na

seção 4 deste documento.


O armazenamento, o manuseio e a liberação de itens de configuração e baselines são

controlados


No sexto resultado esperado, GCO6, espera que a organização armazene todos os itens de

configuração seguindo as especificações definidas no Plano de Gerência de Configuração. Além disso,

deverá ser definido o método de acesso concorrente aos ICs do repositório e o sistema de autenticação

para acessá-los, principalmente quando as informações são acessadas por meios inseguros.

Ainda no GCO6, é necessário estabelecer a liberação de baselines para os interessados, gerando

versões de baseline para produção e produtos de trabalho fechados. As baselines de produção são

utilizadas pela equipe de desenvolvimento para evolução do produto de forma incremental. Os

produtos de trabalho fechados são as baselines que serão enviadas para o cliente, essa versão só será

liberada depois da aprovação do processo de auditoria [SOFTEX, 2009a].


Deve ser definido uma política de acesso às ferramentas de controle de versão e de mudança.

Para isso é necessário primeiramente a definição de responsáveis (definido no plano de gerência de

configuração), e então a devida configuração do sistema para permitir acessos de leitura e escrita de

acordo com o nível de autorização de cada participante do projeto.


É importante também definir como tratar o acesso concorrente aos dados do repositório, para

evitar problemas de perda de informação ou retrabalho. Para isto as ferramentas de controle de versão

utilizam as metodologias copy-modify-merge e lock-modify-unlock (definidas no capítulo 4). Também

é possível ramificar o projeto, isto é criar ramos (branches), utilizando variações das funcionalidades

de criação de rótulos, já explicadas anteriormente.

Além disso, as informações devem ser disponibilizadas através de um canal de comunicação

seguro, para tanto, deve ser configurado algum protocolo de segurança e autenticação para o acesso ao

repositório. Nas ferramentas utilizadas nesta metodologia foi configurado o protocolo SSL (Secure

Socket Layer), em conjunto com a configuração de seus sistemas de autenticação de usuário. Para

detalhes de como configurar as ferramentas ver Manual de Implementação do Processo de Gerência de

Configuração.

Conjunto de Ferramentas A Na ferramenta CVS, a configuração do canal de comunicação seguro já foi descrito no capítulo

4: Instalação/Configuração da Ferramenta, e devido a isso, não será discutido nesta sessão.

Para o acesso concorrente aos dados no repositório, o CVS utilizará a metodologia lock-modify-

merge. Efetuar esta operação, primeiramente, é necessário executar a operação de checkout do

repositório.

No momento em que a opção CVS Checkout for selecionada, será exibida uma janela com

informações do repositório ao qual está sendo acessado. No lado esquerdo, haverá o comando que está

sendo utilizado para acessar o repositório, o usuário pode digitar diretamente o camando ou utilizar as

opções abaixo para montá-lo. Ao lado direito será exibido a lista de projetos que está disponível no

repositório, para carregá-lo, basta clicar na opção Fetch list. O usuário pode navegar os diretórios do

projeto, caso queira efetuar o checkout de um arquivo ou diretório específico. Para efetuar o checkout,

basta selecionar o diretório desejado e clicar em ok.


Agora que o projeto foi retirado do repositório, quando for efetuado uma modificação, uma

operação de commit será realizado. O arquivo modificado possuirá o seu ícone alterado para indicar

que a versão local está diferente da versão do repositório.


Na tela de commit, será disponibilizado uma caixa de texto para adicionar um comentário, na

metodologia deste manual, o formato do comentário será: o tipo de modificação (evolução, mudança,

artefato novo), juntamente com a versão do documento e a data que foi modificada; em seguida o id da

issue que gerou a modificação e, por fim, a descrição da mudança.


Se o arquivo submetido já foi alterado por outra pessoa, será exibida uma mensagem avisando

que a versão que está sendo submetida está obsoleta.

Para efetuar a submissão, é necessário executar a operação de update e em seguida adicionar a

modificação de forma manual no documento, e então tentar submetê-lo novamente.



Conforme definido na seção 4, a questão de permissões de acesso e configuração de um canal

de acesso seguro, são definidas durante a configuração das ferramentas e adequação do arquivo de

permissão de leitura e escrita dos repositórios (svn-acl), em conformidade com o que for definido no

plano de gerência de configuração sobre os responsáveis do projeto.

Questões de concorrência de acesso são tratadas no SVN tanto pelo método lock-modify-

unlock, quanto pelo método copy-modify-merge.

Operação Lock-Modify-Unlock

A política Copy-Modify-Merge é feita quando, em paralelo, duas ou mais pessoas criam suas

cópias locais de trabalho (check-out), e realizam suas modificações sobre uma mesma revisão de

determinado produto de trabalho. Quando o primeiro indivíduo submete suas alterações (check-in), o

numero de revisão irá incrementar, sugerindo uma evolução do item, porem a segunda pessoa, quando

submeter suas mudanças, estará realizando o commit de uma revisão anterior, e receberá um erro

informando que sua versão está desatualizada, então este segundo usuário atualizará sua cópia de

trabalho e ocorrerá neste momento a fusão (merge) das informações submetidas pelos dois usuários.

Esta junção não é automática, e deve ser feita pelo ultimo indivíduo a submeter alterações. É

importante que a organização defina uma estratégia para que operações de merge sejam feitas,

respeitando as alterações de todos, e que informações importantes não sejam perdidas.


Operação Copy-Modify-Merge.

Além disso, branches ou ramos podem ser criados, de forma idêntica a criação de baselines

(funcionalidade de tags), porém salvando os ramos no diretório /branches do repositório.


Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os

itens de configuração estejam íntegros, completos e consistentes


5.7.1. Objetivo do GCO 7

O GCO7, refere-se às auditorias de configuração, que irão avaliar se todos os procedimentos

previstos no Plano de Gerência de Configuração estão sendo seguidos, além de verificar a consistência,

completitude e integridade dos IC e baselines. As datas das auditorias são definidas previamente no

Plano de Gerência de Configuração e são auditadas por alguém que não está diretamente ligado ao

projeto, sendo possível o auxílio de um checklist para aumentar a objetividade da auditoria [SOFTEX,

2009a].


Os passos descritos até aqui constituíram o âmago do processo de gerencia de configuração,

porém ainda é necessário que este processo seja auditado, ou seja, que seja verificado se a gerência de

configuração foi realizada de maneira apropriada. É necessário a geração de um roteiro para a

realização desta auditoria, implementado através de um checklist na ferramenta Spider-CL, contendo

os critérios para condução de uma auditoria de configuração. A auditoria de configuração tem o

principal objetivo de garantir que as baselines e os itens de configuração estejam íntegros, completos e

consistentes.

Utilizando a Spider-CL, será gerado um checklist objetivo contendo critérios para a execução

da auditoria de configuração, tanto funcional quanto física. O checklist deve ser dividido de forma a

deixar claro estas duas categorias de auditoria.

O checklist gerado deve ser aplicado pela ferramenta Spider-CL, utilizando os históricos de

mudanças das ferramentas de controle de versão e modificação e os relatórios das ferramentas de

bugtracking/controle de modificação como insumos para a verificação dos itens do checklist.

Para apresentar e manter os resultados de auditorias ao longo do projeto, deve ser criada uma

página wiki apenas com este objetivo, onde serão listadas todas as auditorias feitas com informações

de data de execução e auditor. Cada uma das auditorias listadas deve possuir um link para uma página

wiki própria daquela auditoria, com informações sobre o andamento da auditoria, resultados, plano de

ação (para o caso de inconsistências identificadas) e o próprio checklist publicado



Exemplo de checklist para auditoria de configuração


Para disponibilizar os resultados de auditoria, deve-se criar um link na mesma página onde

encontra-se o link do Plano de Gerência de Configuração do projeto.

Ao clicar no link Auditorias de Configuração, será exibida uma página contendo uma lista de

auditorias feitas no projeto.

Nesta página, cada auditoria é um link para uma nova página contendo informações de data da

realização da auditoria, o nome do auditor, a baseline que foi feita a auditoria e um anexo do checklist

utilizado.



Após a criação do roteiro de auditoria na ferramenta Spider-CL, a auditoria deve ser conduzida,

usando como base os recursos apresentados nos GCO4 e GCO5, onde foram definidos métodos de

controle e acompanhamento dos itens de configuração e suas modificações.

Após realizadas as auditorias, os resultados devem ser armazenados na ferramenta Trac. Para

apresentar e manter os resultados de auditorias ao longo do projeto deve ser criada uma página wiki

apenas com este objetivo, onde serão listadas todas as auditorias feitas com informações de data de

execução e auditor.

Página “Auditorias de Configuração”

Cada uma das auditorias listadas deve possuir um link para uma página wiki própria daquela

auditoria, com informações sobre o andamento da auditoria, resultados e o próprio checklist publicado.


Página de uma Auditoria de Configuração específica.


A ferramenta Mantis necessita de integração com o DokuWiki para fornecer paginas wiki para

abrigar as páginas de auditorias.

5.8. Análise do Atendimento ao Processo de Gerência de Configuração do MPS.BR

A metodologia proposta com base em ferramental livre é capaz de atender aos resultados

esperados do processo de gerência de configuração do MPS.BR, desde que sejam utilizadas

ferramentas que obedeçam aos requisitos citados. É possível adaptar esta metodologia de forma a


melhor adequá-la ao uso de diferentes conjuntos de ferramentas que realizem o controle de versão e

mudança.

A análise realizada sobre a aplicação das ferramentas descritas neste manual, nos leva a tabela

de mapeamento apresentada a seguir onde é exibido o nível de aderência das ferramentas utilizadas a

cada resultado esperado do processo GCO.

Documents

Manual de Implementação de Processo do MPS.BR com Apoio ...spider.ufpa.br/publicacoes/manuais/SPIDER_gerenciaConfiguracao... · Entre as vantagens do SVN está o modelo de versionamento