Universidade Estadual de Maring

Centro de Tecnologia
Departamento de Informtica







Proposta de um mecanismo de auxlio rastreabilidade no processo de
desenvolvimento distribudo de software

Romulo de Aguiar Beninca

TCC 11-12








Maring Paran
2012

Universidade Estadual de Maring
Centro de Tecnologia
Departamento de Informtica







Proposta de um mecanismo de auxlio rastreabilidade no processo de
desenvolvimento distribudo de software

Romulo de Aguiar Beninca

TCC 11-12




Trabalho de concluso de curso apresen-
tado ao Curso de Cincia da computao,
do Centro de Tecnologia, da Universida-
de Estadual de Maring.
Orientado: Prof. Dr. Renato Balancieri

Maring Paran
2012
Agradecimentos
O desenvolvimento deste trabalho somente foi possvel devido ao apoio dos meus
pais e amigos e professores, por isso agradeo a meus Pais que pelo apoio fornecido, que
me possibilitam a concluso deste trabalho. Agradeo minha namora Krita, que esteve
disposta a ler, reler os textos diversas vezes nas madrugadas.
Agradeo o apoio tcnico e amigo fornecido pelos meus professores orientadores
Dr Elisa, Msr Raqueline e ao Dr Renato O apoio tcnico o desenvolvimento tcnico desse
trabalho agradeo o Dr Renato Balancieri.

Resumo
O DDS (desenvolvimento distribudo de software) uma realidade presente nas
organizaes, que o utilizam para reduzir seus custos e tornar se mais competitivas. A
distribuio geogrfica ou temporal dos membros da equipe traz consigo, desafios
inerentes, tais como, a dificuldade ou impossibilidade de rastrear artefatos e suas
evolues com seus requisitos, devido falta de documentao entre as verses. Esse
trabalho prope o relacionamento entre as tarefas e revises, fornecendo rastreabilidade
entre as verses e gerando uma documentao de qualidade e automatizada. O resultado
obtido com este trabalho foi integrao de duas ferramentas CASE, uma de gerncia de
projetos e outra de controle de versionamento, por meio desta integrao foi possvel o
desenvolvimento de um mecanismo que relaciona automaticamente, as tarefas existentes
na ferramenta de apoio a gerncia, com as revises de artefatos, armazenadas no
repositrio, fornecendo assim rastreabilidade entre tarefas e artefatos.
Palavras chaves: Desenvolvimento distribudo de software (DDS), Gerncia de
projetos, Rastreabilidade, Gerncia de configurao.




Sumrio
1. Introduo 8
1.1. OBJETIVO GERAL 9
1.2. OBJETIVOS ESPECFICOS 9
1.3. PROCEDIMENTO METODOLGICOS 9
1.3.1. Reviso Bibliogrfica 9
1.3.2. Proposta do mecanismo 10
1.3.3. Desenvolvimento da proposta 10
2. Reviso Bibliogrfica 11
2.1. PROCESSO DE GERNCIA 11
2.2. AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE 11
2.3. DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE (DDS) 12
2.4. GERNCIA DE CONFIGURAO 12
2.5. FERRAMENTAS DE APOIO GERNCIA DE PROJETOS 13
2.6. RASTREABILIDADE 14
2.7. SISTEMAS DE CONTROLE DE VERSO (SVC) 14
2.8. AVALIAO E SELEO DE FERRAMENTAS CASE ISO 14102. 14
2.9. FERRAMENTA CASE 16
3. Proposta do mecanismo de rastreabilidade. 17
3.1. FUNCIONAMENTO DO MECANISMO DE AUXLIO A RASTREABILIDADE. 17
3.1.1. Relacionamento entre a reviso e a tarefa 21
3.1.2. Rastreabilidade de tarefa para revises 22
3.1.3. Rastreabilidade de reviso para tarefas 23
3.1.4. Consideraes sobre a rastreabilidade fornecida pelo mecanismo 24
4. Desenvolvimento da proposta. 25
4.1. ANLISE DAS FERRAMENTAS DE GERNCIAMENTO DE PROJETOS 25
4.1.1. Iniciao 25
4.1.1.1. Objetivo a ser atendido pela ferramenta CASE 25
4.1.1.2. Requisitos para avaliao da ferramenta 25
4.1.2. Estruturao 27
4.1.2.1. Atribuio de pesos aos requisitos 27
4.1.2.2. Escolha das ferramentas candidatas 27
4.1.2.2.1. RedMine 28
4.1.2.2.2. RedMine. 29
4.1.2.2.3. DotProject. 32
4.1.2.2.4. Trac. 33
4.1.2.2.5. VastoFuncionrio. 34
4.1.3. Avaliao das ferramentas CASE. 43
4.1.4. Seleo da ferramenta CASE 43
4.2. ANLISE DOS SISTEMAS DE CONTROLE DE VERSO 45
4.2.1. Coleta de informaes 45
4.2.1.1. Versionamento centralizado 47
4.2.1.2. Versionamento distribudo 48
4.2.2. Subversion 49
4.2.3. Git 50
4.2.4. Mercurial 50
4.2.5. Seleo sistema de controle de versionamento. 51
4.3. DESCRIO DAS FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO 51
4.4. INTEGRAO DAS FERRAMENTAS CASE. 52
4.4.1. A Implementao do mecanismo de rastreabilidade. 53
4.4.1.1. Consulta para rastreabilidade entre tarefa para reviso. 53
4.4.1.2. Consulta para rastreabilidade reviso para tarefa. 53
4.4.2. Analise dos resultados 54
4.4.2.1. Testes com a rastreabilidade tarefa para reviso. 55
4.4.2.2. Testes com a rastreabilidade reviso tarefa 57
5. Concluso 59
6. Referncias Bibliogrficas 60


Lista de Figuras
FIGURA 3. 1 CLIENTE TORTOISESVN . ............................................................................................. 20
FIGURA 3. 2 - TABELA QUE RELACIONA ENTRE TAREFA E REVISO. ..................................... 21
FIGURA 3. 3 - PROTTIPO DA RASTREABILIDADE A PARTIR DAS TAREFAS DO PROJETO. ... 23
FIGURA 3. 4 - PROTTIPO DE RASTREABILIDADE REVISO PARA TAREFAS. ......................... 24
FIGURA 4. 1 - CONFIGURAO DE MDULOS DE UM PROJETO REDMINE. ................................ 30
FIGURA 4. 2 - GRFICO DE GRANTT REDMINE. ................................................................................. 31
FIGURA 4. 3 - LISTA DE TAREFAS ATRIBUDAS A UM MEMBRO DO PROJETO. ......................... 31
FIGURA 4. 4- FERRAMENTA DOTPROJETC .......................................................................................... 32
FIGURA 4. 5: GRFICO DE GRANTT NO DOTPROJECT...................................................................... 33
FIGURA. 4. 6 - INTERFACE DA FERRAMENTA TRAC. ........................................................................ 34
FIGURA 4. 7 - DER FERRAMENTA VASTOFUNCIONRIO. ............................................................... 36
FIGURA 4. 8 - VASTOFUNCIONRIO, TELA INICIAL, COM MENSAGEIRO AO LADO................. 37
FIGURA 4. 9 INTERFACE DE EXIBIO DE PROJETOS. .................................................................. 38
FIGURA 4. 10 - MDULO DE TESTES AUTOMATIZADOS.................................................................. 39
FIGURA 4. 11 - DIAGRAMA DE COMPONENTES DA FERRAMENTA VASTOFUNCIONRIO ..... 40
FIGURA 4. 12 - DIAGRAMA DE CLASSES DA APLICAO VASTOFUNCIONRIO. ..................... 42
FIGURA 4. 13 - EXEMPLO DAS REVISES DE ARETEFATOS. .......................................................... 45
FIGURA 4. 14 ILUSTRAO DA ORGANIZAO DO VERSIONAMENTO EM UM PROJETO. .. 46
FIGURA 4. 15 - SISTEMAS DE CONTROLE DE VERSO CENTRALIZADOS. .................................. 47
FIGURA 4. 16 ENVIO DE UMA REVISO AO REPOSITRIO LOCAL DO CLIENTE. ................... 49
FIGURA 4. 17 - SINCRONIZAO ENTRA REPOSITRIOS DE CLIENTES. ..................................... 49
FIGURA 4. 18 - FUNCIONAMENTO REPOSITRIO DISTRIBUDO. ................................................... 51
FIGURA 4. 19 TABELA QUE RELACIONA TAREFA E REVISO. .................................................. 53
FIGURA 4. 20 - TESTE RASTREABILIDADE TAREFA REVISO, COM TAREFA=1. ....................... 56
FIGURA 4. 21 - TESTE RASTREABILIDADE TAREFA REVISO, COM TAREFA=2. ..................... 56
FIGURA 4. 22 - TESTE RASTREABILIDADE TAREFA REVISO, COM TAREFA=3 ........................ 56
FIGURA 4. 23 - TESTE RASTREABILIDADE TAREFA REVISO, COM TAREFA=4 ........................ 56
FIGURA 4. 24 - TESTE RASTREABILIDADE TAREFA PARA REVISO, COM TAREFA=5. ........... 56
FIGURA 4. 25 - TESTE RASTREABILIDADE REVISO PARA TAREFAS, COM REVISO=1. ....... 57
FIGURA 4. 26 - TESTE RASTREABILIDADE REVISO PARA TAREFAS, COM REVISO=2 ........ 57
FIGURA 4. 27 - TESTE RASTREABILIDADE REVISO PARA TAREFAS, COM REVISO=3 ........ 58
FIGURA 4. 28 - TESTE RASTREABILIDADE REVISO PARA TAREFAS, COM REVISO=9 ........ 58
FIGURA 4. 29 - TESTE RASTREABILIDADE REVISO PARA TAREFAS, COM REVISO=11 ...... 58


1. Introduo
Cada vez mais o software tem se tornado um componente de uso estratgico para
as empresas (HERBSLEB e MOITRA, 2001). Devido importncia do software nas
organizaes, mudanas so continuamente solicitadas, para atender o mercado
globalizado e altamente competitivo, as empresas de desenvolvimento tm buscado
reduzir seus custos e assim se tornarem mais competitivas, reduzindo custos com a
utilizao de DDS, pois cada vez mais tem se tornado custoso e menos competitivo
realizar o desenvolvimento em um mesmo espao fsico (ALDO e PRIKLADINICK,
2008).
O DDS permite que grupos distribudos com diferentes expectativas possam
formar equipes, para trabalharem em um mesmo projeto. Segundo Sengupta et al. (2006)
e Sangwan et al. (2007), as tcnicas de desenvolvimento distribudo representam um
progresso na maneira que se desenvolve software. No entanto, ao acrescentar fatores
como disperso geogrfica, temporal, cultural o DDS traz consigo outros desafios, a
serem superados, alguns destes desafios a falta de comunicao entre os membros,
dificuldades para realizao de gerncia de configurao e dificuldade na coordenao
controle e independncia. A dificuldade no controle e interdependncia devido
distncia imposta entre os membros, logo o gernciamento do projeto, no pode ser
realizado por observao ou pela troca informal de informao no ambiente de trabalho.
Com o objetivo de fornecer uma ferramenta de auxlio que possibilite a gerncia
de configurao dos projetos DDS, nesse trabalho, apresentado proposta de integrao
entre duas ferramentas CASE, uma de gesto de projetos e outra controle de verso. Essa
integrao possibilitar ao gerente um controle efetivo automatizado sobre as revises do
projeto, tambm possibilitar a rastreabilidade entre os requisitos e documentos
armazenados no repositrio. Desta forma, fornecer ao gerente do projeto uma viso
ampla da evoluo das tarefas e reviso de artefatos.

1.1. Objetivo geral
O objetivo deste trabalho, propor um mecanismo que possibilite a
rastreabilidade entre tarefa de um projeto e suas revises armazenadas no repositrio em
um ambiente DDS.
1.2. Objetivos especficos
Como objetivo desse trabalho espera-se:
Obter a rastreabilidade entre tarefa e reviso, sendo assim, possvel a
identificao dos motivos que levaram ao desenvolvimento de cada
reviso armazenada no repositrio de forma automatizada.
Obter a rastreabilidade entre revises e tarefa, sendo assim possvel a
identificao de todas as tarefas relacionadas com uma reviso.
Um ambiente de engenharia de software DDS, onde a informao sobre o
andamento de cada tarefa esteja disponvel automaticamente, por meio
das revises relacionadas a cada tarefa.

1.3. Procedimento metodolgicos
Para o desenvolvimento desse trabalho primeiramente foi realizado o
levantamento dos conceitos relacionados proposta, feita uma reviso bibliogrfica
sobre os conceitos envolvidos, incluindo artigos, livros e documentaes de ferramentas
de gerncia de projeto e de sistemas de controle de verso. Com base nas pesquisas, foi
desenvolvida a proposta da integrao entre duas ferramentas CASE. Aps a definio
da metodologia utilizada na integrao das ferramentas CASE, foi realizado a coleta de
informaes sobre algumas ferramentas de gerncia de projetos e controle de
versionamento, com intuito de se identificar as ferramentas mais adequadas a integrao
da proposta, contida no capitulo 3.
1.3.1. Reviso Bibliogrfica
Durante a reviso bibliogrfica foi feita a fundamentao terica dos conceitos
envolvidos no trabalho, proposta essa disponvel no Capitulo 3. Diversos livros e artigos
foram consultados, para a construo de uma base terica consistente e que aborda todos
os conceitos envolvidos com a elaborao da proposta.
1.3.2. Proposta do mecanismo
Aps o a construo da base terica, foi os construda a proposta de um
mecanismo que fornece se a rastreabilidade por meio da integrao entre duas
ferramentas CASE, a proposta de integrao segue descrita no Capitulo 3.
1.3.3. Desenvolvimento da proposta
Para o desenvolvimento da proposta foi feito uma pesquisa, sobre as ferramentas
CASE mais adequadas ao desenvolvimento do mecanismo proposto. A avaliao das
ferramentas foi feita conforme a especificao da Norma ISO14102-2008.
Aps a adoo de duas ferramentas CASE, apropriadas ao desenvolvimento da
proposta, a integrao entre as ferramentas foi desenvolvidas e diversos cenrios de testes
foram criados para analise da rastreabilidade fornecida pelo mecanismo proposto.
Por fim foi feita a analise dos resultados e a concluso sobre a rastreabilidade
fornecida pelo mecanismo proposto.

2. Reviso Bibliogrfica
Os conceitos descritos abaixo fornecem base terica para o desenvolvimento do
trabalho proposto.
2.1. Processo de gerncia
Rezende (2005) define o processo de gerncia com uma atividade administrativa
responsvel pela alocao e controles de recursos existentes sejam esses humanos,
materiais e financeiro.
2.2. Ambiente de desenvolvimento de Software
A expanso do setor de desenvolvimento de software trouxe o aumento da
complexidade dos produtos, aumentando a necessidade de se dispor de um ambiente de
desenvolvimento mais automatizado que apoiem o desenvolvimento, possibilitando uma
maior qualidade dos produtos. Ambientes de desenvolvimento de software (ADS) surgem
nesse contexto para suprir a necessidade de integrao entre as diferentes ferramentas
construdas para propsitos especficos. Essa integrao fundamental para fornecer o
controle do conhecimento (NUNES, 2005).
Segundo Falbo, (1998) conceitua se como um ADS a integrao entre
ferramentas individuais utiliadas no processo de desenvolvimento, essa integrao ocorre
principalmente em trs dimensses:
Integrao entre ferramentas individuais.
Controle, das atividades.
Interface com o usurio.
Idealmente a informo no deve ficar presas a uma nica ferramenta, mas sim ,
ficar diponivel para utilizao em todas ferramentas de apoio utilizadas no
desenvolvimento.
ADS procuram fornecer no somente apoio individual a cada membro da equipe,
mas busca dar apoio ao grupo de trabalho do projeto de desenvolvimento como um todo,
aumentando a produtividade e a qualidade dos produtos, alm de permitir, que o
engenheiro de software acompanhar e mensurar a evoluo do tarefas. Em ambientes
com caractristicas DDS, o ADS devem coordenar as atividades realizadas pelos
membros das equipes e fornecer mecnismos para troca de informao adequado
(HUZITA at al. , 2007).
2.3. Desenvolvimento Distribudo de Software (DDS)
Nos ltimos anos, podemos perceber uma mudana no processo de
desenvolvimento de software, mudana essa direcionada a globalizao de negcios, o
software tem se tornado um componente importante para diversas reas de negcios
(PRIKLADNICKI, 2008). Segundo Prikladnick, (2004) o DDS tem sido caracterizado
principalmente pela colaborao e cooperao entre departamentos de organizaes e
pela criao de grupos de pessoas que trabalham em conjunto, mas esto localizados em
cidades ou pases diferentes, distantes temporal e fisicamente. Para Carmel, (1999), o
desenvolvimento distribudo de software se diferencia do desenvolvimento de software
tradicional, pois os membros das equipes se encontram dispersos geograficamente ou
temporalmente.
A utilizao de DDS, nas empresas de desenvolvimento de software as torna mais
competitivas no mercado global, possibilitando que essas trabalhem 24 horas com
equipes dispersas temporalmente. No entanto, esse novo modelo de desenvolvimento
trouxe algumas dificuldades de comunicao, dificuldades impostas pela falta de
comunicao.
Segundo a (IDC - International Data Group, 2006), a utilizao de DDS nas
organizaes em projetos de grande porte pode refletir em uma diminuio de custos de
25% a 50%. No somente a reduo de custos no projeto atrativa para as organizaes
utilizarem desenvolvimento distribudo, outros atrativos, tais como, profissionais
qualificados e com fluncia em lngua estrangeira, outra vantagem, a reduo do custo
em horas extras, alm do incentivo de governos locais a o desenvolvimento de projetos.
Ainda algumas empresas j tiveram experincia com projetos DDS, relatando melhora no
processo de desenvolvimento.
2.4. Gerncia de configurao
O ambiente de desenvolvimento de software dinmico composto por
documentos de requisitos, cdigos fonte, diagramas, documentao, aplicativos e at
mesmo a prpria legislao. Controlar a evoluo de todos os artefatos envolvidos no
ambiente de desenvolvimento se faz necessrio para que se possa ter controle sobre
desenvolvimento de software. O controle de versionamento dos componentes, que
compe o ambiente de desenvolvimento de software o que chamamos de Gerncia de
Configurao, que proporciona a capacidade de reconstruo de qualquer verso da
aplicao, alm de permitir, o entendimento dos motivos que levaram a cada modificao
na aplicao, o controle de todas as componentes ainda possibilita a rastreabilidade no
desenvolvimento. Pressman (2001) define a gerncia de configurao como:
conjunto de atividades projetadas para controlar as mudanas
pela identificao dos produtos do trabalho que sero alterados,
estabelecendo um relacionamento entre eles, definindo o
mecanismo para o gernciamento de diferentes verses destes
produtos, controlando as mudanas impostas, e auditando e
relatando as mudanas realizadas.
A gerncia de configurao tambm pode ser definida como o conjunto de
tcnicas, padres e procedimentos utilizados para gernciar as verses criadas durante o
ciclo de vida de um software, verses que incorporam correes e solicitaes de
mudanas. possvel que existam diversas verses do sistema sendo utilizadas, assim se
faz necessrio o controle das revises, bem como os motivos e toda documentao
envolvida com a evoluo da aplicao. A gerncia de configurao faz parte da
definio de qualidade estipulada na ISO-12207, que descreve a necessidade da gerncia
de configurao para manter a integridade entre todos os artefatos do desenvolvimento de
um projeto (SOMMERVILLE, 2007).
Ter controle sobre as verses de um projeto possibilita, a capacidade de
reconstruir de forma integra qualquer artefato relacionado ao projeto, alm de possibilitar
a rastreabilidade de cada elemento da aplicao.

2.5. Ferramentas de apoio gerncia de projetos
Ferramentas para auxlio ao processo de gesto so ferramentas direcionadas ao
planejamento, organizao e controle das tarefas, essas ferramentas contribuem as
respectivas atividades, facilitando a administrao dos recursos e tarefas (REZENDE,
2005).
A gesto de projetos uma tarefa administrativa, que pode ser facilitada com a
utilizao de sistemas de informao que forneam suporte adequado s atividades de
planejamento e gesto realizadas pela gerncia (HAROLD KERZNER, 2004).
2.6. Rastreabilidade
A rastreabilidade pode ser definida como sendo a tcnica usada para prover
relacionamento entre requisitos, arquitetura e implementao do projeto de
desenvolvimento de software (EDWARDS, MICHAELV; HOWELL, STEVEN L,
1991). Para Palmer, (1997) rastreabilidade permite a compreenso dos relacionamentos
existentes entre requisitos do software e entre artefatos de requisitos, arquitetura e
implementao. Esses relacionamentos permitem aos projetistas mostrar que o projeto
atende aos requisitos. Os relacionamentos existentes na rastreabilidade permitem a
deteco precoce de requisitos no atendidos pelo software.
Prikladnicki (2007) destaca a importncia de se acompanhar evoluo dos
requisitos do projeto, mantendo a rastreabilidade dos documentos e a evoluo dos
mesmos no processo de desenvolvimento de software distribudo (DDS).
2.7. Sistemas de controle de verso (SVC)
Sussnab, (2007) descreve um sistema de controle de verso como uma aplicao
que permite a criao de um local utilizado para armazenamento das revises de
documentos, armazenando no somente a reviso atual dos documentos, mas todas as
enviadas a ele. Segundo Auvray, (2012), um sistema de controle de verso responsvel
por manter diversas revises de uma mesma unidade de informao, garantindo a
recuperao de qualquer uma das revises.
Prikladnick, (2007) destaca a importncia de haver o controle das revises dos
artefatos criados no processo de desenvolvimento e a importncia de existir o histrico
das evolues dos requisitos desses artefatos. Esse controle permite que toda equipe
trabalhe sobre uma verso consistente dos documentos.

2.8. Avaliao e Seleo de Ferramentas CASE ISO 14102.
Segundo a especificao da norma ISO14102-2008, os sistemas que fornecem
apoio engenharia de software utilizada no processo de desenvolvimento, so parte vital
para o desenvolvimento e manuteno de sistemas. A norma ISO / IEC 14102-2008
define um conjunto de processos e caractersticas para a avaliao tcnica de ferramentas
CASE
1
que envolvem todo ou parcialmente o ciclo de vida da engenharia de software. O
objetivo dos processos descritos nesta norma fornecer resultados quantitativos para
avaliao das ferramentas CASE.
A norma ISO define um processo de quatro fazes para adoo de uma ferramenta
CASE, so eles:
Iniciao No processo de iniciao segundo a Norma, feita a escolha
dos objetivos que uma ou mais ferramentas analisadas devem atingir,
tambm estabelecido os critrios de seleo a serem utilizados no
processo de avaliao. Por fim no processo de iniciao deve ser feito o
planejamento geral para execuo da avaliao.
Estruturao Segundo a Norma de processo estruturao se divide em
trs fazes, sendo elas:
1. Adoo de valores ou pesos, utilizados para cada critrio de
avaliao especificado na fase de iniciao.
2. Escolha das ferramentas CASE candidatas avaliao.
3. Coleta de informao sobre as ferramentas CASE candidatas.
Avaliao Atribuio dos valores aos critrios estabelecidos no processo
de iniciao.
Seleo Na fase de seleo so calculadas as notas finais de cada
requisito utilizado para avaliao das ferramentas CASE, com seus pesos,
por fim feita a recomendao da ferramenta com melhor pontuao.


1
Do ingls Computer-Aided Software Engineering, que corresponde h uma classificao que
abrange todas as ferramentas baseadas em computadores que auxiliam atividades de engenharia de
software.
2.9. Ferramenta CASE
Dentro de um ambiente de desenvolvimento de software so utilizadas diversas
ferramentas para fornecer suporte a cada fase do ciclo de desenvolvimento do software,
esses produtos de software quem compe o ambiente de desenvolvimento de software so
conhecidos como ferramentas CASES. Segundo Imeses, (2006) as ferramentas CASE
podem ser classificadas com base na abrangncia de fases do ciclo de desenvolvimento
que essas fornecem suporte, conforme apresentado a seguir:
Horizontais ferramentas que fornecem apoio ao todas as fases do ciclo de
desenvolvimento de software;
Verticais- fornecem apoio fases especficas do processo de software, como
exemplo de ferramentas verticais podemos citar ferramentas case de gerncia, controle de
versionamento.

3. Proposta do mecanismo de rastreabilidade.
O mecanismo de auxlio rastreabilidade proposto dever fornecer a
rastreabilidade entre as tarefas do projeto e suas revises armazenadas no repositrio, o
mecanismo tambm possibilitar a rastreabilidade no sentido inverso, ou seja, a
rastreabilidade de uma reviso para todas as tarefas relacionadas a est. Nos tpicos a
seguir, descrito todo o funcionamento do mecanismo de auxlio rastreabilidade
proposta.
3.1. Funcionamento do mecanismo de auxlio a rastreabilidade.
A seguir temos a Figura 3. 1 onde est ilustrado o funcionamento do mecanismo
de auxlio rastreabilidade proposto neste trabalho. Na ilustrao os membros que podem
estar distribudos geograficamente, acessam o repositrio e a ferramenta de gerncia de
projetos. No diagrama ilustrado tambm possvel visualiza a comunicao entre a
ferramenta CASE de gerncia e o repositrio.
Ao realizar uma submisso de uma reviso de artefatos ao repositrio, o membro
deve informar o nmero da tarefa executada na reviso submetida, no comentrio da
submisso, a identificao do nmero da tarefa deve ser feita entre colchetes como o
exemplo: [1], essa marcao padro no comentrio permite que o mecanismo de
rastreabilidade associe automaticamente reviso a tarefa correspondente.

Figura 3. 1 - Esquema de funcionamento do mecanismo de auxlio a rastreabilidade
Fonte - Autor

A seguir segue a descrio dos componentes do diagrama esquemtico anterior:
Membros do projeto Desenvolvedores, analistas, engenheiros ou
qualquer outro membro do projeto que necessite acessar ou submeter
revises ao repositrio, ou necessite acessar a ferramenta de gerncia de
projeto. Esses membros podem estar distribudos geograficamente ou
temporalmente como descrito no tpico 2.3, pois tanto a ferramenta de
gerncia de projetos quanto o sistema de controle de verso, acessvel pela
web, no havendo a necessidade dos membros estarem fisicamente no
mesmo local em um mesmo horrio.
Ferramenta de gerncia de projetos Ferramenta de apoio gesto de
projetos, que fornece interface web para acesso pela internet.
Repositrio de dados local para armazenamento dos artefatos do projeto
e suas revises explicado de forma detalhada no tpico 4.2, Na proposta
do mecanismo de auxlio rastreabilidade o repositrio acessado por
suas interfaces, a API sua interface de acesso padro, as funcionalidades
de cada uma dessas descrita a seguir:
o Acesso padro ao repositrio o meio de acesso para envio de
aquisio de artefatos do repositrio, em geral os sistemas de
controle verso oferecem clientes CLI (Command Line Interface)
ou GUI (Graphical user interface). Como exemplo de cliente GUI
para o sistema de controle verso Subversion analisado no
Captulo 4.2 o TortoiseSVN que possibilita o acesso ao
repositrio por meio de uma interface grfica no Windows como
pode ser visto na Figura 3. 1 a seguir.

Figura 3. 1 Cliente TortoiseSVN .
Fonte Autor.
o API do sistema de controle verso essa interface fornecida
pelo sistema de controle de verso para que outras aplicaes
possam comunicar com o repositrio sem que haja conhecimento
interno das rotinas do repositrio.
.
Mecanismo de auxlio rastreabilidade Esse mdulo que pode ser
adicionado ferramenta de controle de projetos, responsvel por realizar
a associao entre as tarefas cadastradas na ferramenta de controle de
projetos e o sistema de controle de verso. Esse mecanismo proposto
possui uma comunicao com o repositrio e outra comunicao com o
mdulo de controle de projetos explicado a seguir:
o Comunicao com o mdulo de projetos Essa interface de
comunicao o meio, pelo qual o mecanismo de auxlio
rastreabilidade adquire o cdigo das tarefas cadastras.
o Comunicao com o sistema de controle de verso Essa a
interface de comunicao que permite o mecanismo de auxlio a
rastreabilidade solicitar as informaes das ltimas revises
enviadas ao repositrio. As informaes que necessitam serem
adquiridas por essa comunicao so os nmeros das submisses
enviadas ao repositrio e o comentrio enviado nas submisso.
3.1.1. Relacionamento entre a reviso e a tarefa
O mdulo de auxlio rastreabilidade proposto relaciona as revises e tarefas por
meio da tabela ilustrada na Figura 3. 2, essa tabela pro_atividade_revisao possui trs
campos, fk_revisao que armazena o nmero da reviso, fk_pro_atividade armazena
o nmero da tarefa que corresponde reviso, assim relacionando tarefa a reviso,
tambm fornecido um campo observao para consideraes em caso de ajuste
manual da relao.

Figura 3. 2 - Tabela que relaciona entre tarefa e reviso.
Fonte - Autor
A associao entre tarefa e reviso o relacionamento que possibilita a
rastreabilidade entre uma tarefa e suas revises e possibilita tambm a rastreabilidade
partir de uma reviso, para todas as tarefas relacionadas reviso. O mapeamento
relacionando tarefas e suas revises podem ser criadas manualmente, por meio do
mecanismo de auxlio rastreabilidade que deve se integrado com a interface da
ferramenta de gerncia de projeto.
O mdulo de auxlio rastreabilidade proposto tambm pode criar o
relacionamentos na tabela exibida na Figura 3. 2 automaticamente, para isso, o
mecanismo possui um sub mdulo que verifica frequentemente se existem novas revises
armazenadas no repositrio, isso feito pela API do repositrio como pode ser visto no
Figura 3. 1. Quando o mecanismo encontra no repositrio uma reviso que no possui ao
menos um relacionamento na tabela pro_atividade_revisao, ele ento realiza uma
busca no comentrio da reviso encontrada, durante essa busca ele toma a ao de criar
um registro na tabela pro_atividade_revisao relacionando a reviso encontrada. Com
base no e resultado da busca do cdigo da tarefa, realizada no comentrio da reviso o
mecanismo toma as seguintes aes:
Nenhum cdigo de tarefa encontrado no comentrio O mecanismo
cria um relacionamento com o nmero da reviso no campo fk_revisao
e NULL no campo fk_pro_atividade.
Uma ou mais cdigo de tarefas encontrado no campo comentrio
Nesse caso criado um registro para cada tarefa encontra, relacionando a
tarefa a o nmero da reviso.
O cdigo encontrado no corresponde a uma tarefa existente no
projeto criado um registro com o nmero da reviso e NULL no
campo fk_pro_atividade.
Como pode ser observado sempre que uma nova reviso no enviada ao
repositrio, o sistema cria um registro relacionado reviso, mesmo que no seja
informado nenhum cdigo de tarefa no campo comentrio. Isso permite que em caso de
uma falha realizada por um membro da equipe, a relao possa ser arrumada. As falhas
possveis de serem realizadas por um membro da equipe so: a no insero o cdigo da
tarefa no comentrio da reviso ou inserir o cdigo de uma tarefa inexistente.
3.1.2. Rastreabilidade de tarefa para revises
Com a criao do relacionamento entre tarefa e reviso, possvel realizar a
rastreabilidade proposta pelo mecanismo, ou seja, a partir de uma tarefa possvel
identificar todas as revises que esto relacionadas com a tarefa em questo. Para melhor
ilustrar esse cenrio da rastreabilidade fornecida pela ferramenta, foi criado o prottipo
exibido na Figura 3. 3 a seguir.

Figura 3. 3 - Prottipo da rastreabilidade a partir das tarefas do projeto.
Fonte - Autor.
Como possvel visualizar na Figura 3. 3, ao visualizar uma tarefa do lado direito
da figura, possvel ver todas as revises e artefatos das respectivas revises gerados pela
tarefa submetida ao repositrio relacionado tarefa.
3.1.3. Rastreabilidade de reviso para tarefas
A rastreabilidade de reviso para tarefa permite que ao selecionar uma reviso
sejam buscadas todas as tarefas relacionadas com est reviso. A rastreabilidade de
reviso para tarefa feita por meio da consulta a tabela ilustrada na Figura 3. 2. A seguir
na Figura 3. 4, est ilustrado um prottipo construdo, onde possvel observar a
rastreabilidade reviso para tarefa.

Figura 3. 4 - Prottipo de rastreabilidade reviso para tarefas.
Fonte - Autor
O prottipo exibido na Figura 3. 4, ilustra a situao onde aps selecionar o
artefato de uma reviso, so exibidas todas as tarefas relacionadas com a reviso
selecionada.
3.1.4. Consideraes sobre a rastreabilidade fornecida pelo
mecanismo
Com a rastreabilidade fornecida pelo mecanismo proposto possvel compreender
todas as tarefas envolvidas com a evoluo de um artefato dentro do repositrio do
projeto de forma automatizada. Alm disso, como os relacionamentos entre a tarefa e a
reviso so armazenados no repositrio possvel editar o relacionamento entre uma
tarefa e uma reviso, mesmo que o comentrio de uma reviso esteja referenciando
incorretamente uma tarefa.

4. Desenvolvimento da proposta.
Para o desenvolvimento da proposta foi feito uma pesquisa e anlise das
ferramentas de gerncia de projetos e sistemas de controle de verso contidos
respectivamente nos tpicos 4.1 e 4.2. Para realizar a escolha das ferramentas CASE
utilizadas no desenvolvimento da proposta foram seguidas as recomendaes previstas
na norma ISO 14102-2008.
Aps a seleo das ferramentas CASE a serem utilizadas no desenvolvimento da
proposta, foi definido integrao das ferramentas CASE selecionadas com mecanismo de
auxlio rastreabilidade proposto no capitulo 3.
4.1. Anlise das ferramentas de gernciamento de projetos
Para realizar adoo da ferramenta CASE mais adequada ao desenvolvimento do
mecanismo de auxlio rastreabilidade proposto no capitulo 3, foi utilizada a Norma
ISO14102-2008, apresentada no tpico 2.8, que define a avaliao de ferramentas CASE
em quatro fases : iniciao, estruturao, avaliao e seleo. Nos tpicos a seguir, esto
execuo de cada uma das fases.
4.1.1. Iniciao
Na fase de iniciao estabelecido o objetivo esperados para a ferramenta CASE
a ser adotado, objetivo esse apresentado no item 4.1.1.1, com base na finalidade para a
qual a ferramenta ser utilizada, criada uma lista de requisitos que devem ser satisfeitos,
apresentados no item 4.1.1.2. Nas fases a seguir do processo de adoo da ferramenta
CASE, esses requisitos so utilizados para avaliao das ferramentas candidatas.
4.1.1.1. Objetivo a ser atendido pela ferramenta CASE
O objetivo da ferramenta CASE de gerncia de projetos, adotada ao final do
processo de avaliao, possibilitar que a integrao entre a ferramenta CASE de apoio
gerncia e controle de versionamento descritas no Capitulo 3 seja realizada.
4.1.1.2. Requisitos para avaliao da ferramenta
A ferramenta CASE a ser adotada no projeto deve atender alguns requisitos,
escolhidos com base nas restries impostas pela proposta realizada no Capitulo 3, e
restries imposta pelo autor para construo do mecanismo, a seguir so apresentados os
requisitos:
Interface Web O mecanismo de auxlio rastreabilidade deve atender
membros de projetos DDS citado no tpico 2.3. Para que esse requisito
seja atendido com flexibilidade espera-se que a ferramenta possua
interface web.
Base de dados relacional Devido necessidade da criao do
relacionamento descrito no item 3.1.1, para o funcionamento da
ferramenta de auxlio rastreabilidade necessrio que o banco de dados
utilizado pela ferramenta seja relacional.
Banco de dados PostgreSQL Devido a licena gratuita desse SGBD
(Sistema Gernciador de Banco de Dados) , sua grande comunidade de
apoio foi definido essa restrio.
Linguagem PHP A ferramenta proposta dever possuir interface web,
sendo preferencialmente desenvolvida em PHP, essa restrio estabelecida
devida a experincia e conhecimento prvio do autor nessa linguagem.
Disponibilidade do cdigo fonte ou API Devido necessidade de
integrao entre a ferramenta de gerncia de projetos e o mecanismo de
auxlio rastreabilidade, a ferramenta deve disponibilizar API para
comunicao com outras aplicaes, ou existir a disponibilidade do cdigo
para integrao.
Integrao com repositrio Para realizar a integrao desejvel que a
ferramenta possua integrao com o repositrio, preferencialmente com a
ferramenta SubVersion devido prvia experincia do autor com esse
repositrio.
As restries imposta a seguir no so impedimento tcnico para o
desenvolvimento da proposta, mas so esperadas em uma ferramenta de gerncia de
projetos.
Suporte a mltiplos projetos.
Suporte controle delegao de tarefa a membro.
Definio de prazo nas tarefas.
Suporta a marcos nos projetos.
Conhecimento prvio do autor no cdigo fonte e arquitetura da aplicao.

4.1.2. Estruturao
Nesta fase do processo proposto pela norma ISO14102-2008 descrito todos os
pesos relacionados aos requisitos estabelecidos na fase de iniciao. Os pesos foram
atribudos aos requisitos com base na importncia definida pelo autor para elaborao do
desenvolvimento da proposta deste trabalho. Nesta fase tambm feita a seleo das
ferramentas candidatas.
4.1.2.1. Atribuio de pesos aos requisitos
Os pesos foram atribudos aos requisitos estabelecidos no tpico 4.1.1.2, com
domnio [1..10] , sendo 1 baixo grau de importncia e 10 alto grau de importncia para o
desenvolvimento do projeto, a seguir apresenta-se a Tabela 4.1.
Tabela 4. 1 - Pesos atribudos aos requisitos
Requisitos Peso
Interface web 10
Base de dados relacional 10
Banco de dados PostgreSQL 10
Linguagem PHP 10
Disponibilidade de Cdigo fonte ou API 8
Suporte a mltiplos projetos 2
Suporte controle e delegao de tarefa a membro. 2
Definio de prazo nas tarefas. 2
Suporta a marcos nos projetos. 3
Integrao com Repositrio 10
Fonte Autor.

4.1.2.2. Escolha das ferramentas candidatas
As ferramentas candidatas escolhidas para o processo de seleo foram: RedMine,
DotProject, Trac e VastoFuncionrio, essa ltima uma ferramenta desenvolvida pelo
prprio autor para a gerncia de projetos. Nos itens a seguir 4.1.2.2.1 4.1.2.2.5, foi feita
uma coleta de informaes sobre cada uma das ferramentas candidatas.
4.1.2.2.1. RedMine
A ferramenta RedMine foi analisada na sua verso 1.8.7 , todas as informaes
sobre a ferramentas foram obtidas no site oficial da ferramenta www.redmine.org.
Desenvolvida em um projeto opensource uma ferramenta CASE vertical, que tem como
objetivo fornecer apoio gerncia de projeto. uma ferramenta com interface web
desenvolvida em Ruby on Rails, a interface web da aplicao est disponvel na Figura a
seguir.

Figura 4.1- Interface web do RedMine (obtida em demo.readmine.org)
Fonte - (RedMine, 2009).

A verso da ferramenta analisada foi a 1.87, adquirida na pagina oficial do
projeto entre as caractersticas apresentadas pela ferramenta possui suporte a mltiplos
projetos A Ferramenta RedMine (REDMINE, 2012) ,distribuda sob a licena GNU GPL
v3, desenvolvida pela comunidade em linguagem Ruby on Rails, a ferrementa fornece
suporte a os banco de dados Postgres, Mysql. Entre as funcionalidades existentes
descritas na documentao do projeto (REDMINE, 2012) esto:
Suporte a controle de mltiplos projetos;
Controles flexveis de acesso;
Flexibilidade no rastreamento de tarefas no projeto;
Grfico de Grantt e Calendrio;
Configurao do fluxo de trabalho;
Notificaes para acompanhamento da evoluo do pedido;
Relatrios personalizados;
Integrao com o Subversion, Git, Mercurial, Bazzar e Darcs;
Criao de tarefa por e-mail;
Suporte a autenticao por LDAP;
Suporte ao auto registro de Usurio;
Suporte a multi-linguagem;
Suporte aos bancos de dados Postgress e Mysql.
A ferramenta necessita de outras aplicaes para seu funcionamento, a seguir so
apresentados os requisitos necessrios:
Plataforma Windows XP ,Vista,2003 e 2008 ou Linux >2.4;
Ruby 1.8;
Rails 3.2.8;
Apache 2.2;
Banco de dados:
o Mysql 5.0 ou superior;
o Postgres 8.4.0;
o Sqlite 3.



4.1.2.2.2. RedMine.
Durante a coleta de informaes foi instalada e testada, a fim de se analisar as
funcionalidades da ferramenta. Foram feitas consideraes sobre a instalao e utilizao
das ferramentas.
A instalao da ferramenta foi realizada em um servidor Linux Ubuntu 1204, a
instalao da ferramenta requer a previa instalao de diversas bibliotecas para
funcionamento do dos mdulos Ruby do Apache2.
A instalao da ferramenta dividida em diversos passos e requer conhecimento
tcnico sobre o banco de dados e sobre o servidor Apache, para o correto funcionamento
da aplicao tambm necessrio configurao SSL do apache e banco de dados
utilizado e ainda necessrio ativar os manualmente os mdulos Ruby do apache.
Sobre a utilizao da ferramenta foi observado que a ferramenta possui uma
interface padronizada e com um menu simples e objetivo, tornando fcil a utilizao. A
configurao dos mdulos disponveis em cada projeto apresentada no momento da
criao do projeto como ilustrado pela Figura 4. 1

Figura 4. 1 - Configurao de mdulos de um projeto RedMine.
Fonte - (RedMine, 2009)
Ao visualizar um projeto a ferramenta j exibe o resumo sobre o projeto e o
grfico de Grant exibido na figura a Figura 4. 2 a seguir.

Figura 4. 2 - Grfico de Grantt RedMine.
Fonte - (RedMine, 2009).
Ao entrar no menu tarefa visvel na Figura 4. 3, so exibidas todas tarefas
relacionadas a um membro do projeto e seus prazos sendo de fcil visualizao a
delegao de tarefas.

Figura 4. 3 - Lista de tarefas atribudas a um membro do projeto.
Fonte (RedMine, 2009).

A ferramenta apresenta diversos mdulos j implementados e como foi
apresentado na Figura 4. 1, a ativao deles simples.
Aps a anlise da ferramenta foi possvel concluir que a instalao da ferramenta
um processo extenso e complexo com diversas dependncias. Os controles de projetos e
tarefas so feitos de maneira simples e a interface no apresentou problemas na sua
utilizao.
4.1.2.2.3. DotProject.
DotProject um projeto opensource desenvolvido em uma ambiente de DDS,
sobre a licena GNU-GPL., desenvolvido sobre uma linguagem PHP. A ferramenta
possui interface web exibida ilustrada na Figura 4. 4 a seguir

Figura 4. 4- Ferramenta DotProjetc
Fonte - (Dot Project , 2001)

Entre as caractersticas funcionais da ferramenta ela possui suporte a mltiplos
projetos, suporte a tarefas e marcos. Analisando as caractersticas funcionais da
ferramenta, pode-se observar que ela tem maior foco na gesto da organizao,
fornecendo cadastro de fornecedores e cliente, gernciamento de mltiplos projetos,
controle de recursos, controle de contatos de clientes e fornecedores, administrao de
grupo de usurios, grfico de grantt, exibido na Figura 4. 5, log de tarefas e suporte para
um frum dentro da ferramenta.

Figura 4. 5: Grfico de Grantt no DotProject.
Fonte - (Dot Project , 2001)
4.1.2.2.4. Trac.
Trac uma ferramenta de gerncia de projeto e configurao, uma ferramenta
opensource e que possui documentao extensa, o projeto desenvolvido em Python,
com interface web a ferramenta apresenta uma interface simples vista na Figura. 4. 6 a
seguir:

Figura. 4. 6 - Interface da ferramenta Trac.
Fonte - (The Trac Project, 2008).
O projeto Trac tem como foco o desenvolvimento de uma ferramenta livre que
possua integrao entre o projeto e o repositrio. Apesar da integrao entre o repositrio
ser bem limitada, a ferramenta utilizada por grandes projetos de desenvolvimento
distribudo de software tais como: Cake PHP, Jelix e Synfony. Sendo desenvolvida para
gesto de projetos, e aprimorada para o gernciamento de projetos de software, o objetivo
da ferramenta trac diminuir a complexidade existente na gerncia de grandes projetos
DDS. A ferramenta oferece suporte comunicao com o SubVersion e outros sistemas
de controle de verso centralizados, mas apenas para visualizao e revises enviadas ao
repositrio, no sendo relacionadas automaticamente as tarefas.
Apesar do nmero de funcionalidades existentes no projeto ainda serem pequenos
essa ferramenta foi construda com uma interface bem documentada com o intuito de que
sejam desenvolvidos plug-ins para adicionar recursos ferramenta.
4.1.2.2.5. VastoFuncionrio.
uma ferramenta CASE que fornece apoio a gerncia, desenvolvida pelo autor
recebeu o nome da empresa onde foi desenvolvida, uma ferramenta proprietria ainda
no distribuda ao pblico. O desenvolvimento da ferramenta foi feito em linguagem
PHP com banco de dados postgres. A ferramenta possui interface web e diversas
caractersticas listadas a seguir:
Calendrio de tarefas;
Controles flexveis de acesso;
Notificaes para acompanhamento da evoluo do pedido por e-mail;
Integrao com o Subversion;
Integrao com Selenium HQ
2
para testes automatizados;
Suporte a mltiplos projetos;
Suporte a marcos em projetos;
Suporte a internacionalizao nativo;
Controle de visualizao de rascunho de tarefas;
Comunicador instantneo integrado;
Suporte aos bancos de dados Postgres.

A ferramenta fornece suporte a mais de uma fase do ciclo de desenvolvimento de
software , pois fornece suporte a gerncia e a testes automatizados por meio da integrao
com o SeleniumHQ.
O bando de dados da aplicao desenvolvida possui oito tabelas, com os
relacionamentos exibidos no DER (Diagrama Entidade-Relacionamento) ilustrado na
Figura 4. 7.

2
Selenium HQ, uma plataforma de testes de aplicaes web, (Selenium HQ Web Application
Testing System, 2009)

Figura 4. 7 - DER Ferramenta VastoFuncionrio.
Fonte Autor

As tabelas exibidas no DER seguem uma padronizao onde o prefixo no nome
de cada tabela identifica o mdulo ao qual essa tabela faz parte do sistema. Dessa forma
pode-se observar a existncia de trs mdulos no sistema, sendo eles:
1) O mdulo sistema identificado pelo prefixo sis_, que so tabelas referentes a
estrutura bsica da ferramenta como por exemplo o cadastro de um usurio;
2) O prefixo pro_ que identifica as tabelas do mdulo de projetos da aplicao;
3) As tabelas com o prefixo sel_, que so referentes ao mdulo de teste
integrados com Selenium HQ.
A descrio dos dados armazenados em cada uma dessas tabelas :
sis_usurio dados do cadastro dos usurios;
sis_char armazena dados do comunicador instantneo interno da aplicao, que
permite a comunicao entre os membros do projeto;
pro_atividade Dados das atividades, tais como responsvel, data de incio e
trmino e a descrio da atividade e seu cdigo nico;
pro_atividade_tipo Armazena os tipos de atividades existentes no sistema;
pro_atividade_hist Armazenamento do status de uma tarefa, esses dados esto
mapeados com um relacionamento 1-n para a pro_atividade, para que se possa ter
diversas revises de cada atividade;
pro_marco Identifica o marco de cada projeto, todas as tarefas possuem um
marco, cada projeto possui inmeros marcos;
pro_projeto Armazena dados do projeto como nome e descrio do projeto.
Na Figura 4. 8 apresentada uma interface do sistema Vasto Funcionrio, que foi
desenvolvida e j est em funcionamento. No lado direito da figura pode-se observar o
comunicador instantneo interno da ferramenta.

Figura 4. 8 - VastoFuncionrio, tela inicial, com mensageiro ao lado.
Fonte - Autor

A ferramenta possui classificao da relevncia de projetos por funcionrio, como
pode ser visto na Figura 4. 9, onde possvel ver os projetos ordenados pela importncia
do mesmo para cada usurio.

Figura 4. 9 Interface de Exibio de projetos.
Fonte - Autor

Outra funcionalidade existente na ferramenta o suporte a testes automatizados
dos projetos desenvolvidos, o mdulo de teste funciona por meio de uma integrao com
o repositrio SubVersion e SeleniumHQ. Esse mdulo de teste realiza check-out do
repositrio e roda os testes pr-programados existentes no repositrio de dados, os
resultados dos testes so exibidos dentro da ferramenta como pode ser observado na
Figura 4. 10 a seguir.


Figura 4. 10 - Mdulo de testes automatizados
Fonte - Autor
Os erros encontrados na execuo dos testes, tambm so enviados para os
programadores pelo chat interno do sistema, evitando assim que esses rodem os testes
manualmente. Essa soluo reduz o tempo de teste gasto no desenvolvimento, pois os
testes de pr e ps-condies, previamente programados, podem ser executados
automaticamente pela aplicao, evitando que cada desenvolvedor tenha que rodar os
testes.
Na Figura 4. 11 apresentada o diagrama de componentes da aplicao
VastoFuncionrio.

Figura 4. 11 - Diagrama de componentes da ferramenta VastoFuncionrio
Fonte - Autor
No diagrama de componente acima ilustrado na Figura 4. 11, os mdulos da
aplicao esto destacados em cor azul, enquanto os mdulos externos esto em cor
cinza, s funcionalidades de cada um desses mdulos internos foi descrita a seguir:
Sistema Base Mdulo responsvel pelo controle de informaes
fundamentais da aplicao, como o controle de usurio.
Mdulo projetos Responsvel pelo controle de projeto, internamente ele
composto pelos componentes Controlador Projetos e o Controlador
Tarefas que gerenciam os demais componentes internos como: projetos,
marcos e tarefas, sendo que controlador de tarefas depende do Mdulo
Base para seu funcionamento pois toda tarefa esta relacionada a um
usurio.
Mdulo de teste Responsvel pelos testes automatizados com
SeleniumHQ, internamente esse mdulo possui os componentes
Controlador Testes, Controlador API Selenium e Controler API
Subversion , sendo que, o componente Controler Testes responsvel
pela gerncia dos demais componentes do desse mdulo. Os componentes
Controler API Subversion e Controler API Selenium so responsveis
pela comunicao com os componentes externos API SubVersion e API
Selenium respectivamente.
Na Figura 4. 12, esta ilustrado o diagrama de classe da aplicao, nesse diagrama
esto as seguintes classes controladoras :
Controler_Usuarios Classe controladora da entidade usurio e controle
de acesso a aplicao.
Controler_Atividades Controladora da classe atividade, responsvel
pelo controle de cadastros edio e alteraes nas tarefas dos projetos,
possui dependncia da classe Controler_Usuarios, pois cada atividade
possui um usurio criador e um ou mais responsveis.
Controler_Projetos Controladora da classe projetos e marcos, a
classe responsvel pelo controle das funes de cadastro, edio e
alterao em projetos, a classe projetos possui dependncia da classe
Controler_Usuarios pois os projetos sempre esto relacionados a um
usurio ou mais usurios, sendo que ao menos um usurio deve estar
gernciado o projeto.
Controler_Tarefas Controladora da classe tarefas , responsvel pelo
controle de criao e alteraes nas tarefas. Essa classe possui
dependncia da classe de controladora de usurios, pois as tarefas devem
ser atribudas a um usurio.
Controler_Testes Classe controladora responsvel pela execuo de
testes automatizados com SeleniumHQ, essa classe controladora possui
dependncia da classes Controler_APISubversion e
Controler_APISelenium, utilizadas para a comunicao com
SubVersion e SeleniumHQ respectivamente.
Controler_APISubversion Controladora responsvel pelo controle da
comunicao com o mdulo externo Subversion.
Controler_APISelenium Controladora da responsvel pelo controle da
comunicao com o SeleniumHQ.

Figura 4. 12 - Diagrama de Classes da aplicao VastoFuncionrio.
Fonte - Autor


.


43


4.1.3. Avaliao das ferramentas CASE.
Durante a fase de avaliao das ferramentas CASE foi feita a atribuio de notas
a cada requisito estabelecido no item 4.1.1, a atribuio de notas aos requisitos das
ferramentas, foram realizadas com na coleta de informaes das ferramentas feitas no
item 4.1.2.2. Na Tabela 4. 2 a seguir, so exibidas as notas atribudas a cada objetivo
esperado das ferramentas candidatas.
Tabela 4. 2- Notas atribudas cada ferramentas de gerncia de projetos avaliada.
Requisitos Peso RedMine Trac DotProject VastoFuncionario
Interface web 10 10 7 6 9
Base de dados relacional 10 10 10 10 10
Banco de dados PostgreSQL 10 7 7 0 10
Linguagem PHP 10 0 0 10 10
Disponibilidade de Cdigo fonte
ou API
8 7 7 8 10
Suporte a mltiplos projetos 2 10 0 10 10
Suporte controle e delegao de
tarefa a membro.
2 10 7 7 8
Definio de prazo nas tarefas. 2 10 10 10 10
Suporta a marcos nos projetos. 3 7 7 7 10
Integrao com Repositrio 10 10 10 0 10
Fonte Autor.
As notas atribudas na Tabela 4. 2, apenas refletem o quando as ferramentas
candidatas atendem cada requisito, no levando em considerao a importncia de cada
requisito para o desenvolvimento da integrao proposta. Para adequar nota final de
cada ferramenta ao grau de importncia do requisito aplicado o peso estabelecido no
item 4.1.2.1 .
4.1.4. Seleo da ferramenta CASE
A seleo das ferramentas CASE consiste em duas etapas, sendo a primeira
contabilizao das notas e pesos atribudos a cada ferramenta candidata, obtendo se uma
nota final a cada uma das ferramentas, Aps a contabilizao das notas, feita a
indicao da ferramenta a ser utilizada no desenvolvimento da proposta contida no
capitulo 3. A seguir na Tabela 4. 3 so exibido os requisitos estabelecidos para a


44

avaliao das ferramentas e as notas finais das ferramentas em cada um dos requisitos
apresentados.

Tabela 4. 3 - Tabela com as notas finais das ferramentas e notas para cada requisito.
Requisitos Nota
RedMine
Nota
Trac
Nota
DotProject
Nota
VastoFuncionario
Interface web 100 70 60 90
Base de dados relacional 100 100 100 100
Banco de dados PostgreSQL 70 70 0 100
Linguagem PHP 0 0 100 100
Disponibilidade de Cdigo fonte ou
API
56 56 64 80
Suporte a mltiplos projetos 20 0 20 20
Suporte controle e delegao de
tarefa a membro.
20 14 14 16
Definio de prazo nas tarefas. 20 20 20 20
Suporta a marcos nos projetos. 21 21 21 30
Integrao com Repositrio 100 10 0 100
Nota final da ferramenta 507 399 656
Fonte Autor.
Como pode ser observado na Tabela 4. 3, as notas aqui apresentadas em cada
requisito so o produto entre as notas atribudas a cada requisito atendido pela
ferramenta, pelo peso do requisito, peso esse apresentado na Tabela 4. 1. Essas
multiplicaes entre os pesos e as notas atribudas s ferramentas, realizada para
adequar a nota atribuda ferramenta em cada requisito, com o grau de importncia para
cada requisito do desenvolvimento da proposta, evitando assim que ferramentas sejam
selecionadas por possurem inmeras caractersticas mesmo no sendo a mais adequada
ao desenvolvimento do projeto.
Analisando as notas finais, obtidas por cada uma das ferramentas candidatas na
Tabela 4. 3, podemos observar que a ferramenta que obteve maior pontuao, sendo
assim a mais adequada para o desenvolvimento da proposta de integrao, com base nos
requisitos apresentados no item 4.1.1, foi a ferramenta VastoFuncionrio apresentada no
item 4.1.2.2.5.



45

4.2. Anlise dos sistemas de controle de verso
A avaliao dos sistemas de controle de verso foi desenvolvida para se definir a
ferramenta mais adequada para o desenvolvimento da proposta exposta no tpico 3, foi
feita em dois passos. Inicialmente foram coletadas as informaes sobre os sistemas de
controle de versionamento, e posteriormente feita a seleo da ferramenta a ser utilizada
que ficou condicionada a escolha da ferramenta de gerncia de projetos adotada no tpico
4.1.4.
4.2.1. Coleta de informaes
A utilizao de sistemas de controle de versionamento permite colaborao
mltipla em projetos de desenvolvimento, permitindo gerncia a edio simultnea de
artefatos ou componentes do sistema. Os sistemas de versionamento analisados foram
CSV, Subversion , Git e Mercurial. Sendo os dois primeiros sistemas classificados como
centralizados e os demais como distribudo.
A utilizao de sistemas de controle de verso permite o compartilhamento
organizado dos artefatos gerados em um projeto de software, permitindo a gerncia das
revises de maneira clara, alm de possibilitar a edio simultnea de artefatos sem
grandes prejuzos para projeto.
Em geral sistemas de controle de verso possuem no somente a cpia de
trabalho, mas todas as demais revises geradas do projeto, como ilustrado na Figura 4.
13.

Figura 4. 13 - Exemplo das revises de aretefatos.
Fonte - http://tortoisesvn.net/docs/nightly/TortoiseSVN_pt_BR/images/ch02dia6.png



46

Como pode ser observado na Figura 4. 13, cada verso est disposta em uma das
colunas, sendo que cada nova reviso do projeto no apaga a verso anterior, podendo se
adquirir qualquer verso de um determinado arquivo. Alm da manuteno de todas as
revises do projeto, os sistemas de controle de verso permitem a separao das verses
do projeto, que em geral so separadas em trs categorias abaixo.
Trunk Verso utilizada no desenvolvimento, tronco do projeto, aqui deve ficar
todo o projeto atual, essa verso a que os desenvolvedores realizam downloads
para desenvolvimento de novas funcionalidades.
Tag Revises estveis do projeto, so verses geradas a cada fim de um
marco/baseline, dependendo da poltica de manuteno, cada tag uma baseline
do projeto ou ponto de partida para um novo tronco.
Branches So revises utilizadas apenas para se fazer uma correo em uma
tag, aps o trmino na baseline corrente essas modificaes devem ser unidas
com o tronco do projeto afim de se gerar uma nova baseline ou tag.

Figura 4. 14 Ilustrao da organizao do versionamento em um projeto.
Fonte: http://www.sonatype.com/people/wp-content/uploads/2011/04/spice-svn.png
Mesmo separando e mantendo todas as verses estveis de um projeto e suas
correes, ainda possvel ocorrer problemas de edio simultnea de um mesmo de um
artefatos ou de artefatos dependentes. Para solucionar esse problema cada vez que um
usurio envia uma nova reviso para o repositrio, esse por sua vez identifica os conflitos


47

dos artefatos alterados e que j possuem verso mais nova do que a envida pelo usurio,
e assim pede para que o usurio solucione o conflito.
Para trabalhar, o usurio no edita diretamente o arquivo do repositrio, ele fica
com a cpia de trabalho, que a verso corrente do repositrio, cujo processo de
aquisio dessa verso chamado de checkout . Dessa forma, o usurio edita sua cpia
e ao trmino de seus trabalhos, envia as alteraes para o repositrio e esse processo de
envio chamado de commit.
Embora as funcionalidades gerais fornecidos pelos sistemas de controle de verso
sejam similares, possvel classific-los da em centralizados e distribudos.
4.2.1.1. Versionamento centralizado
So sistemas baseados na arquitetura cliente-servidor, que possuem apenas
repositrio central que mantm armazenado todos os artefatos e todas os seus revises.
Os clientes por sua vez mantm apenas uma cpia dos artefatos, a essa chamada de
cpia de trabalho. Ao trmino de uma edio na sua cpia de trabalho os clientes
enviam as alteraes feitas na sua cpia de trabalho ao sistema de controle de verso, que
verifica as diferenas entre cpia de trabalho e o repositrio, armazenando apenas as
diferenas entre esses, um esquema simplificado pode est apresentado na Figura 4. 15;

Figura 4. 15 - Sistemas de controle de verso centralizados.
Fonte - http://www.pronus.eng.br/images/dvcs/area_trabalho_repositorio.png



48

4.2.1.2. Versionamento distribudo
So sistemas de versionamento onde cada cliente possui uma cpia do repositrio
e uma cpia de trabalho. Nesse modelo os clientes submetem as suas reas de trabalho ao
seu repositrio local que posteriormente se sincroniza com outros repositrios por meio
de operaes push e pull, esquema simplificado est apresentado na Figura 4. 15.



49


Figura 4. 16 Envio de uma reviso ao repositrio local do cliente.
Fonte -http://www.pronus.eng.br/images/dvcs/operacoes_basicas_distribuido.png

Figura 4. 17 - Sincronizao entra repositrios de clientes.
Fonte - http://www.pronus.eng.br/images/dvcs/operacoes_basicas_distribuido.png
4.2.2. Subversion
O subversion uma ferramenta de controle de versionamento centralizada descrita
no tpico 4.2.1.1, lanada em 2004, apesar de nova possui amplo suporte das ferramentas


50

de desenvolvimento, permitindo o versionamento de diretrio e arquivos e controle de
permisso individual para cada um desses. Uma caracterstica importante no Subversion
seu extenso suporte a diversos protocolos acima do TCP na camada de transporte,
podendo ser acessodo pelos protocolos inclusive WebDAV/DetaV(HTTP1.1), SSH e
SVN.
Por ser um sistema centralizado de controle de verso, existe clara distino entre
e o servidor, cliente. O servidor svn responsvel por gernciar os artefatos e revises no
repositrio, enquanto o aplicativo cliente responsvel por gernciar as copias de
trabalho e permitir o acesso ao servidor svn.
O aplicativo cliente svn disponvel na instalao do pacote oficial, apenas oferece
interface CLI, mas existem diversos como Tortoise que fornecem interface grfica ao
cliente snv.
4.2.3. Git
Git um sistema de controle de verso distribudo explicado no tpico 4.2.1.2,
licenciado com a licena GPL explicada no tpico Erro! Fonte de referncia no
encontrada. . O desenvolvedor que iniciou o desenvolvimento do GIT foi Linus
Torvalds, que na poca se inspirou em outros dois sistemas de versionamento
(BitKeeper e Monotone). No projeto do kernel do Linux o Git necessitava atender a duas
premissas:
Fornecer suporte ao desenvolvimento distribudo;
Possibilitar a utilizao de grandes volumes de arquivos em junes
(merge) com eficincia.
Um repositrio Git pode ter repositrios filhos, e cada utilizador dos repositrios
filhos podem ter suas copias de trabalho como ilustrado na Erro! Fonte de referncia
no encontrada..

4.2.4. Mercurial
Sistema de controle de versionamento distribudo e originado do Git descrito no
tpico 4.2.3 , licenciado com a licena GPLv2, desenvolvido principalmente em


51

Python, no entanto o seu utilitrio fundamental o diff escrito em C. As principais
caractersticas so a escalabilidade e alta performance, Os sistemas de controle de
verso distribudos so fundamentalmente semelhantes com os centralizados, os clientes
no preciso estar on-line com o servidor central para conseguirem realizar envio das
suas verses, pois possvel submeter a copia de trabalho diretamente para o repositrio
local como ao repositrio central como ilustrado na Figura 4. 18.

Figura 4. 18 - Funcionamento repositrio distribudo.
Fonte - http://img.vivaolinux.com.br/imagens/artigos/comunidade/img3.PNG acessado em 09/11/2012.

4.2.5. Seleo sistema de controle de versionamento.
Para o desenvolvimento deste trabalho foi feita a adoo do sistema de controle
de verso, que foi condicionada a escolha da ferramenta de apoio gerncia adotada no
tpico 0, pois como a ferramenta escolhida fornece suporte ao SubVersion apresentado
no tpico 4.2.2 , o desenvolvimento da proposta tambm deve utiliza-lo.
4.3. Descrio das ferramentas utilizadas no
desenvolvimento
Para o funcionamento das ferramentas CASE integradas e do mecanismo de
auxlio a rastreabilidade proposto, foi utilizado o seguinte ambiente plataforma Linux


52

Ubuntu 10.04, os softwares utilizados seguem a seguir listados na sequncia de
instalao, todos foram adquiridos a partir do repositrio apt
3
da distribuio utilizada.
Servidor apache 2.2 Utilizado como servidor de aplicao.
libapache2-mod-php5 Mdulo do servidor apache responsvel pela
interpretao do cdigo php.
Servidor postgres8.4 Servidor de banco de dados utilizado pela ferramenta
VastoFuncionario e pelo mecanismo de auxlio a rastreabilidade.
SubVersion server 1.6.6 - sistema de controle de verso.
libapache-svn biblioteca utilizada para estabelecer a comunicao com a API do
repositrio SubVersion.

4.4. Integrao das ferramentas CASE.
O desenvolvimento do mecanismo de auxlio rastreabilidade proposto no
Capitulo 3, fornece a rastreabilidade entre tarefas e revises descritas no 3.1.2 e 3.1.3.
Por meio da integrao entre as ferramentas CASE. Para o desenvolvimento do
mecanismo de auxlio a rastreabilidade na ferramenta CASE VastoFuncionrio, foi
necessrio estabelecer a comunicao entre o repositrio SubVersion por meio da API
disponvel.
Para possibilitar o relacionamento entre tarefa e reviso dentro da ferramenta
VastoFuncionrio, foi adicionada no seu banco de dados a tabela
pro_atividade_reviso ilustrada na Figura 4. 19 .

3
APT (Advanced Packaging) um gerenciador disponvel nos sistemas operacionais Linux
Debian e derivados (FERREIRA, 2006).


53


Figura 4. 19 Tabela que relaciona tarefa e reviso.

Com a adio desta tabela foi possvel o desenvolvimento da rastreabilidade
proposta nos itens 3.1.2 e 3.1.3.
4.4.1. A Implementao do mecanismo de rastreabilidade.
A implementao do mecanismo de auxlio rastreabilidade proposto no Captulo
3 deste trabalho, foi implementada com a criao da tabela ilustrada na Figura 4. 19, no
banco da ferramenta VastoFuncionrio. E com a adio do mdulo responsvel pelo
mecanismo de rastreabilidade, que se comunica com o repositrio.
As consultas necessrias para efetiva rastreabilidade foram descritas nos itens
abaixo.
4.4.1.1. Consulta para rastreabilidade entre tarefa para reviso.
A rastreabilidade entre uma tarefa e uma reviso proposta no item 3.1.2, permite
que a partir de uma se identifique todas as revises que esto relacionadas com essa
tarefa. A consulta implementada para realizao dessas rastreabilidade segue abaixo e
exprime exatamente a ideia de selecionar todas as informaes existentes na tabela
pro_atividade_revisao que possuam associao com uma determinada tarefa na.
SELECT * FROM pro_atividade_revisao WHERE fk_pro_atividade = $tarefa.
4.4.1.2. Consulta para rastreabilidade reviso para tarefa.
A rastreabilidade proposta no item 3.1.3, permite que a partir de uma reviso
identifique todas as tarefas, que esto relacionadas a essa reviso. A consulta
implementada para realizao dessas rastreabilidade segue abaixo e exprime exatamente
a ideia de selecionar todas as informaes existentes na tabela pro_atividade_revisao
que possuam associao com uma determinada reviso.


54

SELECT * FROM pro_atividade_revisao WHERE fk_revisao = $revisao
4.4.2. Analise dos resultados
Para analisarmos um cenrio pratico da rastreabilidade do mecanismo proposto
neste trabalho, foi feito uma base de teste com cadastro de tarefas fictcias, e foi
construdo um repositrio com os comentrios adequados. Nesta base de dados de teste
feitos os seguintes cadastros
Tarefas 5 Tarefas.
o Tarefa 1 com as revises 1 ,2,4,
o Tarefa 2 com revises 3,6 ,9
o Tarefa 3 com revises 5,7, 9
o Tarefa 4 com as revises 8, 10,11
o Tarefa 5 com as revises 9,11, 12,13,14
Repositrios No repositrio de teste foram feitas 14 revises, sendo que
os comentrios inseridos em cada uma delas pode ser visto na Tabela 4. 4,
a seguir .
Tabela 4. 4 - Revises e comentrios do repositrio de teste.
Reviso Autor Pasta submetida
Comentrio Enviado
Reviso
14 rbeninca /Configuraes
/Configuraes/Cinema7D.identcache
/Configuraes/Cinema7D.res
/Configuraes/ProjectGroup1.groupproj.local
/Configuraes/edit.dcu
/Configuraes/exemplo.csv
[5]
13 rbeninca / [5]
12 rbeninca / [5]
11 rbeninca /Tcc/ [5] [4]
10 rbeninca /Configuraes/ [4]
9 rbeninca / [2] [3] [5]
8 rbeninca / [4]
7 rbeninca /Branch/ [3]
6 rbeninca / [2]
5 rbeninca / [3]
4 rbeninca / [1]
3 rbeninca / [2]
2 rbeninca / [1]
1 rbeninca / [1]


55

Fonte: Autor
Aps o abastecimento da base de dados de teste e do repositrio foi, verificada a
rastreabilidade do mecanismo proposto,
4.4.2.1. Testes com a rastreabilidade tarefa para reviso.
Para o teste da rastreabilidade tarefa para reviso, foi feita a consulta de todas as
tarefas cadastradas na base de testes, o resultado do esto disponveis nas figuras a seguir
Figura 4. 20, Figura 4. 21, Figura 4. 22, Figura 4. 23 e Figura 4. 24.



56


Figura 4. 20 - Teste Rastreabilidade Tarefa reviso, com tarefa=1.
Fonte Autor


Figura 4. 21 - Teste Rastreabilidade Tarefa reviso, com tarefa=2.
Fonte Autor.

Figura 4. 22 - Teste Rastreabilidade Tarefa reviso, com tarefa=3
Fonte Autor

Figura 4. 23 - Teste Rastreabilidade Tarefa reviso, com tarefa=4
Fonte Autor

Figura 4. 24 - Teste Rastreabilidade Tarefa para reviso, com tarefa=5.
Fonte Autor


57

Como pode ser observada nas figuras 4.21 4.24, em todos os casos de teste a
ferramenta foi capaz de identificar as revises relacionadas com cada tarefa, alm de
identificar a hora, usurio que submeteu as alteraes e a lista de artefatos alterados na
reviso.



4.4.2.2. Testes com a rastreabilidade reviso tarefa
Para a realizao do teste da rastreabilidade uma reviso para tarefas relacionadas,
foi consultado ferramenta desenvolvida as revises 1, 2, 3, 9 e 11, nessa rastreabilidade o
rastreabilidade o mecanismo deveria nos retornar as tarefas relacionadas com a reviso
consultada, a seguir nas figuras Figura 4. 25 a Figura 4. 29, esto os resultados dos
testes realizados.


Figura 4. 25 - Teste Rastreabilidade reviso para tarefas, com reviso=1.
Fonte Autor

Figura 4. 26 - Teste Rastreabilidade reviso para tarefas, com reviso=2
Fonte Autor



58


Figura 4. 27 - Teste Rastreabilidade reviso para tarefas, com reviso=3
Fonte Autor

Figura 4. 28 - Teste Rastreabilidade reviso para tarefas, com reviso=9
Fonte Autor

Figura 4. 29 - Teste Rastreabilidade reviso para tarefas, com reviso=11
Fonte Autor
Como pode ser observada nas figuras 4.25 a 4.29, em todos os casos de teste a
ferramenta foi capaz de identificar as tarefas relacionadas com a reviso, fornecendo a
rastreabilidade proposta no item 3.1.3.


59

5. Concluso
Com a globalizao dos mercados locais, ocorreu uma crescente demanda por
software, nesse mercado atual o software tem se tornado um componente estratgico para
diversas reas de negcio. Contudo, o progresso das economias e a sofisticao dos meios
de comunicao, aumentou a concorrncia que imps a reduo de custos. Nesse
contexto, o desenvolvimento distribudo de software, surge como uma soluo
estratgica. Porm, a distribuio do processo de desenvolvimento de software, trouxe
novos desafios inerentes disperso, entre os problemas provenientes da utilizao de
DDS, temos a dificuldade da gesto devida falta de contato direto entre os membros da
equipe (AUDY e PRIKLADINICK, 2008).
O objetivo deste trabalho foi propor uma soluo para os problemas relacionados
falta da rastreabilidade existente em ambientes DDS. A soluo proposta neste trabalho
foi integrao entre as ferramentas CASE, uma de apoio a gerncia e um sistema de
controle de versionamento. Aps, a elaborao da proposta foi desenvolvido a integrao
entre as ferramentas e realizao de testes prticos do mecanismo proposto. A anlise
dos testes nos revelou que a proposta do mecanismo de rastreabilidade valida e fornece
as informaes necessrias para uma melhor gesto de projetos DDS.
Uma srie de trabalhos futuros pode ser realizada a partir do mecanismo proposto,
um destes trabalhos seria a expanso das rastreabilidades suportadas pelo mecanismo,
fornecendo rastreabilidade da evoluo de cada artefato, contido no repositrio e suas
diferenas.
Um trabalho futuro ainda mais ambicioso seria a integrao do mecanismo
proposto com a IDE utilizada pelos desenvolvedores, fornecendo a rastreabilidade da
evoluo dos artefatos e das tarefas, dentro do ambiente de desenvolvimento.


A seguir apresentadas as atividades realizadas durante a construo do trabalho.


60

6. Referncias Bibliogrficas
AUDY, J.; PRIKLADINICK, R. Desenvolvimento Distribuido de Software. Rio
de Janeiro: Campus, 2008.
DOT Project , 2001. Disponivel em: <www.dotproject.org/demo>. Acesso em: 25
maio 2012.
EDWARDS, MICHAELV; HOWELL, STEVEN L. A Methodology for Systems
Requirements Specification and Traceability for Large Real Time Complex
Systems", technical report, u.s. naval surface warfare center-dahlgren division, dahlgren,
p. 60, 27 setembro 1991.
FALBO, R. D. A. Integrao de Conhecimento em um Ambiente de
Desenvolvimento de Software. COPPE/UFRJ. Rio de Janeiro. 1998.
FERREIRA, R. E. Gerenciamento de Pacotes de Software no Linux. So
Paulo: Novatec Editora, 2006.
HERBSLEB, J. D.; MOITRA, D. Guest Editors introduction: Global Software
Development. [S.l.]: [s.n.], 2001.
HUZITA, ELISA H. M., TAIT ,TANIA F. C., COLAZI, THELMA E. ,
QUITANA ,MARCOS A. , 2007. Um Ambiente de Desenvolvimento Distribudo de
Software- Disen, Maring,, ago. 2007. 28.
NUNES, B. B. Integrando a gerncia de configurao de
software,documenrntao gerncia de conhecimento em um ambiente de
desenvolvimento de software. UFES. Vitria, p. 200. 2005.
PRESSMAN, R. S. Software Engineering - A practitioner's Approach. 5. ed.
[S.l.]: Hill, 2001.
PRONUS Eng. Pronus Eng. Disponivel em: <http://www.pronus.eng.br >. Acesso
em: 2012 jun. 20.
REDMINE. demo.redmine.org, 2009. Disponivel em: <demo.redmine.org>.
Acesso em: 26 maio 2012.


61

REZENDE, D. A. Engenharia de Software e Sistemas de Informao. 3. ed.
So Paulo: Brasport, 2005. 316 p. ISBN: 8574522155.
SELENIUM HQ Web Application Testing System. Selenium HQ Documents,
2009. Disponivel em: <http://seleniumhq.org/docs/book/Selenium_Documentation.pdf>.
Acesso em: 10 nov. 2012.
SOMMERVILLE, I. Engenharia de Software. 8. ed. [S.l.]: PEARSON
EDUCATION , 2007.
THE Trac Project, 2008. ISSN http://trac.edgewall.org/demo-0.13. Disponivel
em: <http://trac.edgewall.org/demo-0.13>. Acesso em: 15/06/2012 jun. 2012.
TORTOISE SVN, 2004. Disponivel em: <http://tortoisesvn.net/docs/>. Acesso
em: 20 jun. 2012.


62





















Universidade Estadual de Maring
Departamento de Informtica
Av. Colombo 5790, Maring-PR, CEP 87020-900
Tel: (44) 3261-4324 Fax: (44) 3263-5874
www.din.uem.br


63