manual de implementação de processo do mps.br com apoio...
TRANSCRIPT
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
Ewelton Yoshidome, Maurício Ronny
04/12/2009 0.6 Integração, Desenvolvimento da
Metodologia e ajustes no documento
Ewelton Yoshidome, Maurício Ronny
10/12/2009 0.7 Instalação das ferramentas
Ewelton Yoshidome, Maurício Ronny
16/12/2009 1.0 Instalação das ferramentas e revisão do
documento
Ewelton Yoshidome, Maurício Ronny
Confidencial Página 3 de 76
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
Confidencial Página 4 de 76
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
Confidencial Página 5 de 76
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.
Confidencial Página 6 de 76
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
Confidencial Página 7 de 76
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.
Confidencial Página 8 de 76
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
Confidencial Página 9 de 76
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:
Confidencial Página 10 de 76
Confidencial Página 11 de 76
Confidencial Página 12 de 76
Confidencial Página 13 de 76
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
Confidencial Página 14 de 76
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.
Confidencial Página 15 de 76
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).
Confidencial Página 16 de 76
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.
Confidencial Página 17 de 76
*/
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 ) );
Confidencial Página 18 de 76
$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
}
/**
Confidencial Página 19 de 76
* 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:
Confidencial Página 20 de 76
$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
Confidencial Página 21 de 76
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.
Confidencial Página 22 de 76
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 é
Confidencial Página 23 de 76
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.
Confidencial Página 24 de 76
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
Confidencial Página 25 de 76
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...
Confidencial Página 26 de 76
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.
Confidencial Página 27 de 76
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.
Confidencial Página 28 de 76
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.
Confidencial Página 29 de 76
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
Confidencial Página 30 de 76
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
Confidencial Página 31 de 76
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.
Confidencial Página 32 de 76
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:”.
Confidencial Página 33 de 76
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.
Confidencial Página 34 de 76
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
Confidencial Página 35 de 76
5.2.1. Objetivo do GCO2
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).
5.2.2. Implementação com base nas Ferramentas de Apoio
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.
Confidencial Página 36 de 76
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
Confidencial Página 37 de 76
pelas organizações também deve ser inclusa no plano de gerencia de configuração, juntamente com
regras de versionamento.
Conjunto de Ferramentas A
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.
Confidencial Página 38 de 76
Conjunto de Ferramentas B
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.
Confidencial Página 39 de 76
Criando referencia ao checklist na seção apropriada
Exemplo de Plano de Gerência de Configuração
5.2.3. Ajustes na Ferramenta
Confidencial Página 40 de 76
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.3. Resultado Esperado: GCO3
Os itens de configuração sujeitos a um controle formal são colocados sob baseline
5.3.1. Objetivo do GCO3
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.
5.3.2. Implementação com base nas Ferramentas de Apoio
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.
Confidencial Página 41 de 76
Conjunto de Ferramentas A
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.
Confidencial Página 42 de 76
Conjunto de Ferramentas B
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.
Confidencial Página 43 de 76
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.
Confidencial Página 44 de 76
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”.
Confidencial Página 45 de 76
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.
Confidencial Página 46 de 76
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].
5.4.2. Implementação com base nas Ferramentas de Apoio
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.
Conjunto de Ferramentas A
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.
Confidencial Página 47 de 76
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.
Confidencial Página 48 de 76
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.
Confidencial Página 49 de 76
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)
Confidencial Página 50 de 76
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.
Conjunto de Ferramentas B
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.
Confidencial Página 51 de 76
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.
Confidencial Página 52 de 76
Visualização dos Itens e suas Revisões em uma Baseline no Subversion.
5.5. Resultado Esperado: GCO5
Modificações em itens de configuração são controladas
5.5.1. Objetivo do GCO5
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].
5.5.2. Implementação com base nas Ferramentas de Apoio
Confidencial Página 53 de 76
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
Confidencial Página 54 de 76
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.
Conjunto de Ferramentas A
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;
Confidencial Página 55 de 76
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.
Confidencial Página 56 de 76
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.
Confidencial Página 57 de 76
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.
Confidencial Página 58 de 76
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).
Confidencial Página 59 de 76
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.
Confidencial Página 60 de 76
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”.
Confidencial Página 61 de 76
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.
Confidencial Página 62 de 76
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,
Confidencial Página 63 de 76
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.
Confidencial Página 64 de 76
Histórico de mudanças do ticket.
5.5.3. Ajustes na Ferramenta
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.
5.6. Resultado Esperado: GCO6
O armazenamento, o manuseio e a liberação de itens de configuração e baselines são
controlados
5.6.1. Objetivo do GCO6
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].
5.6.2. Implementação com base nas Ferramentas de Apoio
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.
Confidencial Página 65 de 76
É 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.
Confidencial Página 66 de 76
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.
Confidencial Página 67 de 76
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.
Confidencial Página 68 de 76
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.
Confidencial Página 69 de 76
Conjunto de Ferramentas B
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.
Confidencial Página 70 de 76
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.
5.7. Resultado Esperado: GCO7
Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os
itens de configuração estejam íntegros, completos e consistentes
Confidencial Página 71 de 76
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].
5.7.2. Implementação com base nas Ferramentas de Apoio
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
Confidencial Página 72 de 76
Confidencial Página 73 de 76
Exemplo de checklist para auditoria de configuração
Conjunto de Ferramentas A
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.
Confidencial Página 74 de 76
Conjunto de Ferramentas B
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.
Confidencial Página 75 de 76
Página de uma Auditoria de Configuração específica.
5.7.3. Ajustes na Ferramenta
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
Confidencial Página 76 de 76
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.