Embed Size (px)
DESCRIPTION
a
Citation preview
Universidade Estadual de Maringá
Centro de Tecnologia
Departamento de Informática
Proposta de um mecanismo de auxílio à rastreabilidade no processo de
desenvolvimento distribuído de software
Romulo de Aguiar Beninca
TCC 11-12
Maringá – Paraná
2012
Universidade Estadual de Maringá
Centro de Tecnologia
Departamento de Informática
Proposta de um mecanismo de auxílio à rastreabilidade no processo de
desenvolvimento distribuído de software
Romulo de Aguiar Beninca
TCC 11-12
Trabalho de conclusão de curso apresen-
tado ao Curso de Ciência da computação,
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 possível devido ao apoio dos meus
pais e amigos e professores, por isso agradeço a meus Pais que pelo apoio fornecido, que
me possibilitam a conclusão deste trabalho. Agradeço minha namora Kárita, que esteve
disposta a ler, reler os textos diversas vezes nas madrugadas.
Agradeço o apoio técnico e amigo fornecido pelos meus professores orientadores
Dr Elisa, Msr Raqueline e ao Dr Renato O apoio técnico o desenvolvimento técnico desse
trabalho agradeço o Dr Renato Balancieri.
Resumo
O DDS (desenvolvimento distribuído de software) é uma realidade presente nas
organizações, que o utilizam para reduzir seus custos e tornar se mais competitivas. A
distribuição geográfica ou temporal dos membros da equipe traz consigo, desafios
inerentes, tais como, a dificuldade ou impossibilidade de rastrear artefatos e suas
evoluções com seus requisitos, devido à falta de documentação entre as versões. Esse
trabalho propõe o relacionamento entre as tarefas e revisões, fornecendo rastreabilidade
entre as versões e gerando uma documentação de qualidade e automatizada. O resultado
obtido com este trabalho foi à integração de duas ferramentas CASE, uma de gerência de
projetos e outra de controle de versionamento, por meio desta integração foi possível o
desenvolvimento de um mecanismo que relaciona automaticamente, as tarefas existentes
na ferramenta de apoio a gerência, com as revisões de artefatos, armazenadas no
repositório, fornecendo assim rastreabilidade entre tarefas e artefatos.
Palavras chaves: Desenvolvimento distribuído de software (DDS), Gerência de
projetos, Rastreabilidade, Gerência de configuração.
Sumário
1. Introdução 8
1.1. OBJETIVO GERAL 9
1.2. OBJETIVOS ESPECÍFICOS 9
1.3. PROCEDIMENTO METODOLÓGICOS 9
1.3.1. Revisão Bibliográfica 9
1.3.2. Proposta do mecanismo 10
1.3.3. Desenvolvimento da proposta 10
2. Revisão Bibliográfica 11
2.1. PROCESSO DE GERÊNCIA 11
2.2. AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE 11
2.3. DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE (DDS) 12
2.4. GERÊNCIA DE CONFIGURAÇÃO 12
2.5. FERRAMENTAS DE APOIO GERÊNCIA DE PROJETOS 13
2.6. RASTREABILIDADE 14
2.7. SISTEMAS DE CONTROLE DE VERSÃO (SVC) 14
2.8. AVALIAÇÃO E SELEÇÃO DE FERRAMENTAS CASE ISO 14102. 14
2.9. FERRAMENTA CASE 16
3. Proposta do mecanismo de rastreabilidade. 17
3.1. FUNCIONAMENTO DO MECANISMO DE AUXÍLIO A RASTREABILIDADE. 17
3.1.1. Relacionamento entre a revisão e a tarefa 21
3.1.2. Rastreabilidade de tarefa para revisões 22
3.1.3. Rastreabilidade de revisão para tarefas 23
3.1.4. Considerações sobre a rastreabilidade fornecida pelo mecanismo 24
4. Desenvolvimento da proposta. 25
4.1. ANÁLISE DAS FERRAMENTAS DE GERÊNCIAMENTO DE PROJETOS 25
4.1.1. Iniciação 25
4.1.1.1. Objetivo a ser atendido pela ferramenta CASE 25
4.1.1.2. Requisitos para avaliação da ferramenta 25
4.1.2. Estruturação 27
4.1.2.1. Atribuição 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. VastoFuncionário. 34
4.1.3. Avaliação das ferramentas CASE. 43
4.1.4. Seleção da ferramenta CASE 43
4.2. ANÁLISE DOS SISTEMAS DE CONTROLE DE VERSÃO 45
4.2.1. Coleta de informações 45
4.2.1.1. Versionamento centralizado 47
4.2.1.2. Versionamento distribuído 48
4.2.2. Subversion 49
4.2.3. Git 50
4.2.4. Mercurial 50
4.2.5. Seleção sistema de controle de versionamento. 51
4.3. DESCRIÇÃO DAS FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO 51
4.4. INTEGRAÇÃO DAS FERRAMENTAS CASE. 52
4.4.1. A Implementação do mecanismo de rastreabilidade. 53
4.4.1.1. Consulta para rastreabilidade entre tarefa para revisão. 53
4.4.1.2. Consulta para rastreabilidade revisão para tarefa. 53
4.4.2. Analise dos resultados 54
4.4.2.1. Testes com a rastreabilidade tarefa para revisão. 55
4.4.2.2. Testes com a rastreabilidade revisão tarefa 57
5. Conclusão 59
6. Referências Bibliográficas 60
Lista de Figuras
FIGURA 3. 1 – CLIENTE TORTOISESVN . ............................................................................................. 20
FIGURA 3. 2 - TABELA QUE RELACIONA ENTRE TAREFA E REVISÃO. ..................................... 21
FIGURA 3. 3 - PROTÓTIPO DA RASTREABILIDADE A PARTIR DAS TAREFAS DO PROJETO. ... 23
FIGURA 3. 4 - PROTÓTIPO DE RASTREABILIDADE REVISÃO PARA TAREFAS. ......................... 24
FIGURA 4. 1 - CONFIGURAÇÃO DE MÓDULOS DE UM PROJETO REDMINE. ................................ 30
FIGURA 4. 2 - GRÁFICO DE GRANTT REDMINE. ................................................................................. 31
FIGURA 4. 3 - LISTA DE TAREFAS ATRIBUÍDAS A UM MEMBRO DO PROJETO. ......................... 31
FIGURA 4. 4- FERRAMENTA DOTPROJETC .......................................................................................... 32
FIGURA 4. 5: GRÁFICO DE GRANTT NO DOTPROJECT...................................................................... 33
FIGURA. 4. 6 - INTERFACE DA FERRAMENTA TRAC. ........................................................................ 34
FIGURA 4. 7 - DER FERRAMENTA VASTOFUNCIONÁRIO. ............................................................... 36
FIGURA 4. 8 - VASTOFUNCIONÁRIO, TELA INICIAL, COM MENSAGEIRO AO LADO................. 37
FIGURA 4. 9 – INTERFACE DE EXIBIÇÃO DE PROJETOS. .................................................................. 38
FIGURA 4. 10 - MÓDULO DE TESTES AUTOMATIZADOS.................................................................. 39
FIGURA 4. 11 - DIAGRAMA DE COMPONENTES DA FERRAMENTA VASTOFUNCIONÁRIO ..... 40
FIGURA 4. 12 - DIAGRAMA DE CLASSES DA APLICAÇÃO VASTOFUNCIONÁRIO. ..................... 42
FIGURA 4. 13 - EXEMPLO DAS REVISÕES DE ARETEFATOS. .......................................................... 45
FIGURA 4. 14 – ILUSTRAÇÃO DA ORGANIZAÇÃO DO VERSIONAMENTO EM UM PROJETO. .. 46
FIGURA 4. 15 - SISTEMAS DE CONTROLE DE VERSÃO CENTRALIZADOS. .................................. 47
FIGURA 4. 16 – ENVIO DE UMA REVISÃO AO REPOSITÓRIO LOCAL DO CLIENTE. ................... 49
FIGURA 4. 17 - SINCRONIZAÇÃO ENTRA REPOSITÓRIOS DE CLIENTES. ..................................... 49
FIGURA 4. 18 - FUNCIONAMENTO REPOSITÓRIO DISTRIBUÍDO. ................................................... 51
FIGURA 4. 19 – TABELA QUE RELACIONA TAREFA E REVISÃO. .................................................. 53
FIGURA 4. 20 - TESTE RASTREABILIDADE TAREFA REVISÃO, COM TAREFA=1. ....................... 56
FIGURA 4. 21 - TESTE RASTREABILIDADE TAREFA REVISÃO, COM TAREFA=2. ..................... 56
FIGURA 4. 22 - TESTE RASTREABILIDADE TAREFA REVISÃO, COM TAREFA=3 ........................ 56
FIGURA 4. 23 - TESTE RASTREABILIDADE TAREFA REVISÃO, COM TAREFA=4 ........................ 56
FIGURA 4. 24 - TESTE RASTREABILIDADE TAREFA PARA REVISÃO, COM TAREFA=5. ........... 56
FIGURA 4. 25 - TESTE RASTREABILIDADE REVISÃO PARA TAREFAS, COM REVISÃO=1. ....... 57
FIGURA 4. 26 - TESTE RASTREABILIDADE REVISÃO PARA TAREFAS, COM REVISÃO=2 ........ 57
FIGURA 4. 27 - TESTE RASTREABILIDADE REVISÃO PARA TAREFAS, COM REVISÃO=3 ........ 58
FIGURA 4. 28 - TESTE RASTREABILIDADE REVISÃO PARA TAREFAS, COM REVISÃO=9 ........ 58
FIGURA 4. 29 - TESTE RASTREABILIDADE REVISÃO PARA TAREFAS, COM REVISÃO=11 ...... 58
1. Introdução
Cada vez mais o software tem se tornado um componente de uso estratégico para
as empresas (HERBSLEB e MOITRA, 2001). Devido à importância do software nas
organizações, mudanças são continuamente solicitadas, para atender o mercado
globalizado e altamente competitivo, as empresas de desenvolvimento têm buscado
reduzir seus custos e assim se tornarem mais competitivas, reduzindo custos com a
utilização de DDS, pois cada vez mais tem se tornado custoso e menos competitivo
realizar o desenvolvimento em um mesmo espaço físico (ALDO e PRIKLADINICK,
2008).
O DDS permite que grupos distribuídos com diferentes expectativas possam
formar equipes, para trabalharem em um mesmo projeto. Segundo Sengupta et al. (2006)
e Sangwan et al. (2007), as técnicas de desenvolvimento distribuído representam um
progresso na maneira que se desenvolve software. No entanto, ao acrescentar fatores
como dispersão geográfica, temporal, cultural o DDS traz consigo outros desafios, a
serem superados, alguns destes desafios é a falta de comunicação entre os membros,
dificuldades para realização de gerência de configuração e dificuldade na coordenação
controle e independência. A dificuldade no controle e interdependência é devido à
distância imposta entre os membros, logo o gerênciamento do projeto, não pode ser
realizado por observação ou pela troca informal de informação no ambiente de trabalho.
Com o objetivo de fornecer uma ferramenta de auxílio que possibilite a gerência
de configuração dos projetos DDS, nesse trabalho, é apresentado à proposta de integração
entre duas ferramentas CASE, uma de gestão de projetos e outra controle de versão. Essa
integração possibilitará ao gerente um controle efetivo automatizado sobre as revisões do
projeto, também possibilitará a rastreabilidade entre os requisitos e documentos
armazenados no repositório. Desta forma, fornecerá ao gerente do projeto uma visão
ampla da evolução das tarefas e revisão de artefatos.
1.1. Objetivo geral
O objetivo deste trabalho, é propor um mecanismo que possibilite a
rastreabilidade entre tarefa de um projeto e suas revisões armazenadas no repositório em
um ambiente DDS.
1.2. Objetivos específicos
Como objetivo desse trabalho espera-se:
Obter a rastreabilidade entre tarefa e revisão, sendo assim, possível a
identificação dos motivos que levaram ao desenvolvimento de cada
revisão armazenada no repositório de forma automatizada.
Obter a rastreabilidade entre revisões e tarefa, sendo assim possível a
identificação de todas as tarefas relacionadas com uma revisão.
Um ambiente de engenharia de software DDS, onde a informação sobre o
andamento de cada tarefa esteja disponível automaticamente, por meio
das revisões relacionadas a cada tarefa.
1.3. Procedimento metodológicos
Para o desenvolvimento desse trabalho primeiramente foi realizado o
levantamento dos conceitos relacionados à proposta, feita uma revisão bibliográfica
sobre os conceitos envolvidos, incluindo artigos, livros e documentações de ferramentas
de gerência de projeto e de sistemas de controle de versão. Com base nas pesquisas, foi
desenvolvida a proposta da integração entre duas ferramentas CASE. Após a definição
da metodologia utilizada na integração das ferramentas CASE, foi realizado a coleta de
informações sobre algumas ferramentas de gerência de projetos e controle de
versionamento, com intuito de se identificar as ferramentas mais adequadas a integração
da proposta, contida no capitulo 3.
1.3.1. Revisão Bibliográfica
Durante a revisão bibliográfica foi feita a fundamentação teórica dos conceitos
envolvidos no trabalho, proposta essa disponível no Capitulo 3. Diversos livros e artigos
foram consultados, para a construção de uma base teórica consistente e que aborda todos
os conceitos envolvidos com a elaboração da proposta.
1.3.2. Proposta do mecanismo
Após o a construção da base teórica, foi os construída a proposta de um
mecanismo que fornece se a rastreabilidade por meio da integração entre duas
ferramentas CASE, a proposta de integração 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 avaliação das
ferramentas foi feita conforme a especificação da Norma ISO14102-2008.
Após a adoção de duas ferramentas CASE, apropriadas ao desenvolvimento da
proposta, a integração entre as ferramentas foi desenvolvidas e diversos cenários de testes
foram criados para analise da rastreabilidade fornecida pelo mecanismo proposto.
Por fim foi feita a analise dos resultados e a conclusão sobre a rastreabilidade
fornecida pelo mecanismo proposto.
2. Revisão Bibliográfica
Os conceitos descritos abaixo fornecem base teórica para o desenvolvimento do
trabalho proposto.
2.1. Processo de gerência
Rezende (2005) define o processo de gerência com uma atividade administrativa
responsável pela alocação e controles de recursos existentes sejam esses humanos,
materiais e financeiro.
2.2. Ambiente de desenvolvimento de Software
A expansão 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 integração entre as diferentes ferramentas
construídas para propósitos específicos. Essa integração é fundamental para fornecer o
controle do conhecimento (NUNES, 2005).
Segundo Falbo, (1998) conceitua se como um ADS a integração entre
ferramentas individuais utiliadas no processo de desenvolvimento, essa integração ocorre
principalmente em três dimenssões:
Integração entre ferramentas individuais.
Controle, das atividades.
Interface com o usuário.
Idealmente a informção não deve ficar presas a uma única ferramenta, mas sim ,
ficar diponivel para utilização em todas ferramentas de apoio utilizadas no
desenvolvimento.
ADS procuram fornecer não 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, além de permitir, que o
engenheiro de software acompanhar e mensurar a evolução do tarefas. Em ambientes
com caractéristicas DDS, o ADS devem coordenar as atividades realizadas pelos
membros das equipes e fornecer mecânismos para troca de informação adequado
(HUZITA at al. , 2007).
2.3. Desenvolvimento Distribuído de Software (DDS)
Nos últimos anos, podemos perceber uma mudança no processo de
desenvolvimento de software, mudança essa direcionada a globalização de negócios, o
software tem se tornado um componente importante para diversas áreas de negócios
(PRIKLADNICKI, 2008). Segundo Prikladnick, (2004) “o DDS tem sido caracterizado
principalmente pela colaboração e cooperação entre departamentos de organizações e
pela criação de grupos de pessoas que trabalham em conjunto, mas estão localizados em
cidades ou países diferentes, distantes temporal e fisicamente”. Para Carmel, (1999), o
desenvolvimento distribuído de software se diferencia do desenvolvimento de software
tradicional, pois os membros das equipes se encontram dispersos geograficamente ou
temporalmente.
A utilização 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 comunicação, dificuldades impostas pela falta de
comunicação.
Segundo a (IDC - International Data Group, 2006), a utilização de DDS nas
organizações em projetos de grande porte pode refletir em uma diminuição de custos de
25% a 50%. Não somente a redução de custos no projeto é atrativa para as organizações
utilizarem desenvolvimento distribuído, outros atrativos, tais como, profissionais
qualificados e com fluência em língua estrangeira, outra vantagem, é a redução do custo
em horas extras, além do incentivo de governos locais a o desenvolvimento de projetos.
Ainda algumas empresas já tiveram experiência com projetos DDS, relatando melhora no
processo de desenvolvimento.
2.4. Gerência de configuração
O ambiente de desenvolvimento de software é dinâmico composto por
documentos de requisitos, códigos fonte, diagramas, documentação, aplicativos e até
mesmo a própria legislação. Controlar a evolução de todos os artefatos envolvidos no
ambiente de desenvolvimento se faz necessário para que se possa ter controle sobre
desenvolvimento de software. O controle de versionamento dos componentes, que
compõe o ambiente de desenvolvimento de software é o que chamamos de Gerência de
Configuração, que proporciona a capacidade de reconstrução de qualquer versão da
aplicação, além de permitir, o entendimento dos motivos que levaram a cada modificação
na aplicação, o controle de todas as componentes ainda possibilita a rastreabilidade no
desenvolvimento. Pressman (2001) define a gerência de configuração como:
“conjunto de atividades projetadas para controlar as mudanças
pela identificação dos produtos do trabalho que serão alterados,
estabelecendo um relacionamento entre eles, definindo o
mecanismo para o gerênciamento de diferentes versões destes
produtos, controlando as mudanças impostas, e auditando e
relatando as mudanças realizadas”.
A gerência de configuração também pode ser definida como o conjunto de
técnicas, padrões e procedimentos utilizados para gerênciar as versões criadas durante o
ciclo de vida de um software, versões que incorporam correções e solicitações de
mudanças. É possível que existam diversas versões do sistema sendo utilizadas, assim se
faz necessário o controle das revisões, bem como os motivos e toda documentação
envolvida com a evolução da aplicação. A gerência de configuração faz parte da
definição de qualidade estipulada na ISO-12207, que descreve a necessidade da gerência
de configuração para manter a integridade entre todos os artefatos do desenvolvimento de
um projeto (SOMMERVILLE, 2007).
Ter controle sobre as versões de um projeto possibilita, a capacidade de
reconstruir de forma integra qualquer artefato relacionado ao projeto, além de possibilitar
a rastreabilidade de cada elemento da aplicação.
2.5. Ferramentas de apoio gerência de projetos
Ferramentas para auxílio ao processo de gestão são ferramentas direcionadas ao
planejamento, organização e controle das tarefas, essas ferramentas contribuem as
respectivas atividades, facilitando a administração dos recursos e tarefas (REZENDE,
2005).
A gestão de projetos é uma tarefa administrativa, que pode ser facilitada com a
utilização de sistemas de informação que forneçam suporte adequado às atividades de
planejamento e gestão realizadas pela gerência (HAROLD KERZNER, 2004).
2.6. Rastreabilidade
A rastreabilidade pode ser definida como sendo a técnica usada para prover
relacionamento entre requisitos, arquitetura e implementação do projeto de
desenvolvimento de software (EDWARDS, MICHAELV; HOWELL, STEVEN L,
1991). Para Palmer, (1997) rastreabilidade permite a compreensão dos relacionamentos
existentes entre requisitos do software e entre artefatos de requisitos, arquitetura e
implementação. Esses relacionamentos permitem aos projetistas mostrar que o projeto
atende aos requisitos. Os relacionamentos existentes na rastreabilidade permitem a
detecção precoce de requisitos não atendidos pelo software.
Prikladnicki (2007) destaca a importância de se acompanhar evolução dos
requisitos do projeto, mantendo a rastreabilidade dos documentos e a evolução dos
mesmos no processo de desenvolvimento de software distribuído (DDS).
2.7. Sistemas de controle de versão (SVC)
Sussnab, (2007) descreve um sistema de controle de versão como uma aplicação
que permite a criação de um local utilizado para armazenamento das revisões de
documentos, armazenando não somente a revisão atual dos documentos, mas todas as
enviadas a ele. Segundo Auvray, (2012), um sistema de controle de versão é responsável
por manter diversas revisões de uma mesma unidade de informação, garantindo a
recuperação de qualquer uma das revisões.
Prikladnick, (2007) destaca a importância de haver o controle das revisões dos
artefatos criados no processo de desenvolvimento e a importância de existir o histórico
das evoluções dos requisitos desses artefatos. Esse controle permite que toda equipe
trabalhe sobre uma versão consistente dos documentos.
2.8. Avaliação e Seleção de Ferramentas CASE ISO 14102.
Segundo a especificação da norma ISO14102-2008, os sistemas que fornecem
apoio à engenharia de software utilizada no processo de desenvolvimento, são parte vital
para o desenvolvimento e manutenção de sistemas. A norma ISO / IEC 14102-2008
define um conjunto de processos e características para a avaliação técnica de ferramentas
CASE 1que envolvem todo ou parcialmente o ciclo de vida da engenharia de software. O
objetivo dos processos descritos nesta norma é fornecer resultados quantitativos para
avaliação das ferramentas CASE.
A norma ISO define um processo de quatro fazes para adoção de uma ferramenta
CASE, são eles:
Iniciação – No processo de iniciação segundo a Norma, é feita a escolha
dos objetivos que uma ou mais ferramentas analisadas devem atingir,
também é estabelecido os critérios de seleção a serem utilizados no
processo de avaliação. Por fim no processo de iniciação deve ser feito o
planejamento geral para execução da avaliação.
Estruturação – Segundo a Norma de processo estruturação se divide em
três fazes, sendo elas:
1. Adoção de valores ou pesos, utilizados para cada critério de
avaliação especificado na fase de iniciação.
2. Escolha das ferramentas CASE candidatas à avaliação.
3. Coleta de informação sobre as ferramentas CASE candidatas.
Avaliação – Atribuição dos valores aos critérios estabelecidos no processo
de iniciação.
Seleção – Na fase de seleção são calculadas as notas finais de cada
requisito utilizado para avaliação das ferramentas CASE, com seus pesos,
por fim é feita a recomendação da ferramenta com melhor pontuação.
1 Do inglês Computer-Aided Software Engineering, que corresponde há uma classificação 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 são utilizadas diversas
ferramentas para fornecer suporte a cada fase do ciclo de desenvolvimento do software,
esses produtos de software quem compõe o ambiente de desenvolvimento de software são
conhecidos como ferramentas CASES. Segundo Imeses, (2006) as ferramentas CASE
podem ser classificadas com base na abrangência 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 específicas do processo de software, como
exemplo de ferramentas verticais podemos citar ferramentas case de gerência, controle de
versionamento.
3. Proposta do mecanismo de rastreabilidade.
O mecanismo de auxílio à rastreabilidade proposto deverá fornecer a
rastreabilidade entre as tarefas do projeto e suas revisões armazenadas no repositório, o
mecanismo também possibilitará a rastreabilidade no sentido inverso, ou seja, a
rastreabilidade de uma revisão para todas as tarefas relacionadas a está. Nos tópicos a
seguir, é descrito todo o funcionamento do mecanismo de auxílio à rastreabilidade
proposta.
3.1. Funcionamento do mecanismo de auxílio a rastreabilidade.
A seguir temos a Figura 3. 1 onde está ilustrado o funcionamento do mecanismo
de auxílio à rastreabilidade proposto neste trabalho. Na ilustração os membros que podem
estar distribuídos geograficamente, acessam o repositório e a ferramenta de gerência de
projetos. No diagrama ilustrado também é possível visualiza a comunicação entre a
ferramenta CASE de gerência e o repositório.
Ao realizar uma submissão de uma revisão de artefatos ao repositório, o membro
deve informar o número da tarefa executada na revisão submetida, no comentário da
submissão, a identificação do número da tarefa deve ser feita entre colchetes como o
exemplo: [1], essa marcação padrão no comentário permite que o mecanismo de
rastreabilidade associe automaticamente à revisão a tarefa correspondente.
Figura 3. 1 - Esquema de funcionamento do mecanismo de auxílio a rastreabilidade
Fonte - Autor
A seguir segue a descrição dos componentes do diagrama esquemático anterior:
Membros do projeto – Desenvolvedores, analistas, engenheiros ou
qualquer outro membro do projeto que necessite acessar ou submeter
revisões ao repositório, ou necessite acessar a ferramenta de gerência de
projeto. Esses membros podem estar distribuídos geograficamente ou
temporalmente como descrito no tópico 2.3, pois tanto a ferramenta de
gerência de projetos quanto o sistema de controle de versão, acessível pela
web, não havendo a necessidade dos membros estarem fisicamente no
mesmo local em um mesmo horário.
Ferramenta de gerência de projetos – Ferramenta de apoio à gestão de
projetos, que fornece interface web para acesso pela internet.
Repositório de dados – local para armazenamento dos artefatos do projeto
e suas revisões explicado de forma detalhada no tópico 4.2, Na proposta
do mecanismo de auxílio à rastreabilidade o repositório é acessado por
suas interfaces, a API é sua interface de acesso padrão, as funcionalidades
de cada uma dessas é descrita a seguir:
o Acesso padrão ao repositório – É o meio de acesso para envio de
aquisição de artefatos do repositório, em geral os sistemas de
controle versão oferecem clientes CLI (Command Line Interface)
ou GUI (Graphical user interface). Como exemplo de cliente GUI
para o sistema de controle versão Subversion analisado no
Capítulo 4.2 é o TortoiseSVN que possibilita o acesso ao
repositório por meio de uma interface gráfica 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 versão – essa interface é fornecida
pelo sistema de controle de versão para que outras aplicações
possam comunicar com o repositório sem que haja conhecimento
interno das rotinas do repositório.
.
Mecanismo de auxílio à rastreabilidade – Esse módulo que pode ser
adicionado à ferramenta de controle de projetos, é responsável por realizar
a associação entre as tarefas cadastradas na ferramenta de controle de
projetos e o sistema de controle de versão. Esse mecanismo proposto
possui uma comunicação com o repositório e outra comunicação com o
módulo de controle de projetos explicado a seguir:
o Comunicação com o módulo de projetos – Essa interface de
comunicação é o meio, pelo qual o mecanismo de auxílio à
rastreabilidade adquire o código das tarefas cadastras.
o Comunicação com o sistema de controle de versão – Essa é a
interface de comunicação que permite o mecanismo de auxílio a
rastreabilidade solicitar as informações das últimas revisões
enviadas ao repositório. As informações que necessitam serem
adquiridas por essa comunicação são os números das submissões
enviadas ao repositório e o comentário enviado nas submissão.
3.1.1. Relacionamento entre a revisão e a tarefa
O módulo de auxílio à rastreabilidade proposto relaciona as revisões e tarefas por
meio da tabela ilustrada na Figura 3. 2, essa tabela “pro_atividade_revisao” possui três
campos, “fk_revisao” que armazena o número da revisão, “fk_pro_atividade” armazena
o número da tarefa que corresponde à revisão, assim relacionando à tarefa a revisão,
também é fornecido um campo “observação” para considerações em caso de ajuste
manual da relação.
Figura 3. 2 - Tabela que relaciona entre tarefa e revisão.
Fonte - Autor
A associação entre tarefa e revisão é o relacionamento que possibilita a
rastreabilidade entre uma tarefa e suas revisões e possibilita também a rastreabilidade
partir de uma revisão, para todas as tarefas relacionadas à revisão. O mapeamento
relacionando tarefas e suas revisões podem ser criadas manualmente, por meio do
mecanismo de auxílio à rastreabilidade que deve se integrado com a interface da
ferramenta de gerência de projeto.
O módulo de auxílio à rastreabilidade proposto também pode criar o
relacionamentos na tabela exibida na Figura 3. 2 automaticamente, para isso, o
mecanismo possui um sub módulo que verifica frequentemente se existem novas revisões
armazenadas no repositório, isso é feito pela API do repositório como pode ser visto no
Figura 3. 1. Quando o mecanismo encontra no repositório uma revisão que não possui ao
menos um relacionamento na tabela “pro_atividade_revisao”, ele então realiza uma
busca no comentário da revisão encontrada, durante essa busca ele toma a ação de criar
um registro na tabela “pro_atividade_revisao” relacionando a revisão encontrada. Com
base no e resultado da busca do código da tarefa, realizada no comentário da revisão o
mecanismo toma as seguintes ações:
Nenhum código de tarefa é encontrado no comentário– O mecanismo
cria um relacionamento com o número da revisão no campo “fk_revisao”
e NULL no campo “fk_pro_atividade”.
Uma ou mais código de tarefas é encontrado no campo comentário –
Nesse caso é criado um registro para cada tarefa encontra, relacionando a
tarefa a o número da revisão.
O código encontrado não corresponde a uma tarefa existente no
projeto – É criado um registro com o número da revisão e NULL no
campo “fk_pro_atividade”.
Como pode ser observado sempre que uma nova revisão não é enviada ao
repositório, o sistema cria um registro relacionado à revisão, mesmo que não seja
informado nenhum código de tarefa no campo comentário. Isso permite que em caso de
uma falha realizada por um membro da equipe, a relação possa ser arrumada. As falhas
possíveis de serem realizadas por um membro da equipe são: a não inserção o código da
tarefa no comentário da revisão ou inserir o código de uma tarefa inexistente.
3.1.2. Rastreabilidade de tarefa para revisões
Com a criação do relacionamento é entre tarefa e revisão, é possível realizar a
rastreabilidade proposta pelo mecanismo, ou seja, a partir de uma tarefa é possível
identificar todas as revisões que estão relacionadas com a tarefa em questão. Para melhor
ilustrar esse cenário da rastreabilidade fornecida pela ferramenta, foi criado o protótipo
exibido na Figura 3. 3 a seguir.
Figura 3. 3 - Protótipo da rastreabilidade a partir das tarefas do projeto.
Fonte - Autor.
Como é possível visualizar na Figura 3. 3, ao visualizar uma tarefa do lado direito
da figura, é possível ver todas as revisões e artefatos das respectivas revisões gerados pela
tarefa submetida ao repositório relacionado à tarefa.
3.1.3. Rastreabilidade de revisão para tarefas
A rastreabilidade de revisão para tarefa permite que ao selecionar uma revisão
sejam buscadas todas as tarefas relacionadas com está revisão. A rastreabilidade de
revisão para tarefa é feita por meio da consulta a tabela ilustrada na Figura 3. 2. A seguir
na Figura 3. 4, está ilustrado um protótipo construído, onde é possível observar a
rastreabilidade revisão para tarefa.
Figura 3. 4 - Protótipo de rastreabilidade revisão para tarefas.
Fonte - Autor
O protótipo exibido na Figura 3. 4, ilustra a situação onde após selecionar o
artefato de uma revisão, são exibidas todas as tarefas relacionadas com a revisão
selecionada.
3.1.4. Considerações sobre a rastreabilidade fornecida pelo
mecanismo
Com a rastreabilidade fornecida pelo mecanismo proposto é possível compreender
todas as tarefas envolvidas com a evolução de um artefato dentro do repositório do
projeto de forma automatizada. Além disso, como os relacionamentos entre a tarefa e a
revisão são armazenados no repositório é possível editar o relacionamento entre uma
tarefa e uma revisão, mesmo que o comentário de uma revisão esteja referenciando
incorretamente uma tarefa.
4. Desenvolvimento da proposta.
Para o desenvolvimento da proposta foi feito uma pesquisa e análise das
ferramentas de gerência de projetos e sistemas de controle de versão contidos
respectivamente nos tópicos 4.1 e 4.2. Para realizar a escolha das ferramentas CASE
utilizadas no desenvolvimento da proposta foram seguidas as recomendações previstas
na norma ISO 14102-2008.
Após a seleção das ferramentas CASE a serem utilizadas no desenvolvimento da
proposta, foi definido integração das ferramentas CASE selecionadas com mecanismo de
auxílio à rastreabilidade proposto no capitulo 3.
4.1. Análise das ferramentas de gerênciamento de projetos
Para realizar adoção da ferramenta CASE mais adequada ao desenvolvimento do
mecanismo de auxílio à rastreabilidade proposto no capitulo 3, foi utilizada a Norma
ISO14102-2008, apresentada no tópico 2.8, que define a avaliação de ferramentas CASE
em quatro fases : iniciação, estruturação, avaliação e seleção. Nos tópicos a seguir, estão
à execução de cada uma das fases.
4.1.1. Iniciação
Na fase de iniciação é 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 adoção da ferramenta
CASE, esses requisitos são utilizados para avaliação das ferramentas candidatas.
4.1.1.1. Objetivo a ser atendido pela ferramenta CASE
O objetivo da ferramenta CASE de gerência de projetos, adotada ao final do
processo de avaliação, é possibilitar que a integração entre a ferramenta CASE de apoio à
gerência e controle de versionamento descritas no Capitulo 3 seja realizada.
4.1.1.2. Requisitos para avaliação da ferramenta
A ferramenta CASE a ser adotada no projeto deve atender alguns requisitos,
escolhidos com base nas restrições impostas pela proposta realizada no Capitulo 3, e
restrições imposta pelo autor para construção do mecanismo, a seguir são apresentados os
requisitos:
Interface Web – O mecanismo de auxílio à rastreabilidade deve atender
membros de projetos DDS citado no tópico 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 criação do
relacionamento descrito no item 3.1.1, para o funcionamento da
ferramenta de auxílio à rastreabilidade é necessário que o banco de dados
utilizado pela ferramenta seja relacional.
Banco de dados PostgreSQL – Devido a licença gratuita desse SGBD
(Sistema Gerênciador de Banco de Dados) , sua grande comunidade de
apoio foi definido essa restrição.
Linguagem PHP – A ferramenta proposta dever possuir interface web,
sendo preferencialmente desenvolvida em PHP, essa restrição estabelecida
devida a experiência e conhecimento prévio do autor nessa linguagem.
Disponibilidade do código fonte ou API – Devido à necessidade de
integração entre a ferramenta de gerência de projetos e o mecanismo de
auxílio à rastreabilidade, a ferramenta deve disponibilizar API para
comunicação com outras aplicações, ou existir a disponibilidade do código
para integração.
Integração com repositório – Para realizar a integração é desejável que a
ferramenta possua integração com o repositório, preferencialmente com a
ferramenta SubVersion devido à prévia experiência do autor com esse
repositório.
As restrições imposta a seguir não são impedimento técnico para o
desenvolvimento da proposta, mas são esperadas em uma ferramenta de gerência de
projetos.
Suporte a múltiplos projetos.
Suporte controle delegação de tarefa a membro.
Definição de prazo nas tarefas.
Suporta a marcos nos projetos.
Conhecimento prévio do autor no código fonte e arquitetura da aplicação.
4.1.2. Estruturação
Nesta fase do processo proposto pela norma ISO14102-2008 é descrito todos os
pesos relacionados aos requisitos estabelecidos na fase de iniciação. Os pesos foram
atribuídos aos requisitos com base na importância definida pelo autor para elaboração do
desenvolvimento da proposta deste trabalho. Nesta fase também é feita a seleção das
ferramentas candidatas.
4.1.2.1. Atribuição de pesos aos requisitos
Os pesos foram atribuídos aos requisitos estabelecidos no tópico 4.1.1.2, com
domínio [1..10] , sendo 1 baixo grau de importância e 10 alto grau de importância para o
desenvolvimento do projeto, a seguir apresenta-se a Tabela 4.1.
Tabela 4. 1 - Pesos atribuídos aos requisitos
Requisitos Peso
Interface web 10
Base de dados relacional 10
Banco de dados PostgreSQL 10
Linguagem PHP 10
Disponibilidade de Código fonte ou API 8
Suporte a múltiplos projetos 2
Suporte controle e delegação de tarefa a membro. 2
Definição de prazo nas tarefas. 2
Suporta a marcos nos projetos. 3
Integração com Repositório 10
Fonte – Autor.
4.1.2.2. Escolha das ferramentas candidatas
As ferramentas candidatas escolhidas para o processo de seleção foram: RedMine,
DotProject, Trac e VastoFuncionário, essa última é uma ferramenta desenvolvida pelo
próprio autor para a gerência de projetos. Nos itens a seguir 4.1.2.2.1 à 4.1.2.2.5, foi feita
uma coleta de informações sobre cada uma das ferramentas candidatas.
4.1.2.2.1. RedMine
A ferramenta RedMine foi analisada na sua versão 1.8.7 , todas as informações
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 à gerência de projeto. É uma ferramenta com interface web
desenvolvida em Ruby on Rails, a interface web da aplicação está disponível na Figura a
seguir.
Figura 4.1- Interface web do RedMine (obtida em demo.readmine.org)
Fonte - (RedMine, 2009).
A versão da ferramenta analisada foi a 1.87, adquirida na pagina oficial do
projeto entre as características apresentadas pela ferramenta possui suporte a múltiplos
projetos A Ferramenta RedMine (REDMINE, 2012) ,distribuída sob a licença 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 documentação do projeto (REDMINE, 2012) estão:
Suporte a controle de múltiplos projetos;
Controles flexíveis de acesso;
Flexibilidade no rastreamento de tarefas no projeto;
Gráfico de Grantt e Calendário;
Configuração do fluxo de trabalho;
Notificações para acompanhamento da evolução do pedido;
Relatórios personalizados;
Integração com o Subversion, Git, Mercurial, Bazzar e Darcs;
Criação de tarefa por e-mail;
Suporte a autenticação por LDAP;
Suporte ao auto registro de Usuário;
Suporte a multi-linguagem;
Suporte aos bancos de dados Postgress e Mysql.
A ferramenta necessita de outras aplicações para seu funcionamento, a seguir são
apresentados os requisitos necessários:
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 informações foi instalada e testada, a fim de se analisar as
funcionalidades da ferramenta. Foram feitas considerações sobre a instalação e utilização
das ferramentas.
A instalação da ferramenta foi realizada em um servidor Linux Ubuntu 1204, a
instalação da ferramenta requer a previa instalação de diversas bibliotecas para
funcionamento do dos módulos Ruby do Apache2.
A instalação da ferramenta é dividida em diversos passos e requer conhecimento
técnico sobre o banco de dados e sobre o servidor Apache, para o correto funcionamento
da aplicação também é necessário à configuração SSL do apache e banco de dados
utilizado e ainda é necessário ativar os manualmente os módulos Ruby do apache.
Sobre a utilização da ferramenta foi observado que a ferramenta possui uma
interface padronizada e com um menu simples e objetivo, tornando fácil a utilização. A
configuração dos módulos disponíveis em cada projeto é apresentada no momento da
criação do projeto como ilustrado pela Figura 4. 1
Figura 4. 1 - Configuração de módulos de um projeto RedMine.
Fonte - (RedMine, 2009)
Ao visualizar um projeto a ferramenta já exibe o resumo sobre o projeto e o
gráfico de Grant exibido na figura a Figura 4. 2 a seguir.
Figura 4. 2 - Gráfico de Grantt RedMine.
Fonte - (RedMine, 2009).
Ao entrar no menu tarefa visível na Figura 4. 3, são exibidas todas tarefas
relacionadas a um membro do projeto e seus prazos sendo de fácil visualização a
delegação de tarefas.
Figura 4. 3 - Lista de tarefas atribuídas a um membro do projeto.
Fonte– (RedMine, 2009).
A ferramenta apresenta diversos módulos já implementados e como foi
apresentado na Figura 4. 1, a ativação deles é simples.
Após a análise da ferramenta foi possível concluir que a instalação da ferramenta
é um processo extenso e complexo com diversas dependências. Os controles de projetos e
tarefas são feitos de maneira simples e a interface não apresentou problemas na sua
utilização.
4.1.2.2.3. DotProject.
DotProject é um projeto opensource desenvolvido em uma ambiente de DDS,
sobre a licença 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 características funcionais da ferramenta ela possui suporte a múltiplos
projetos, suporte a tarefas e marcos. Analisando as características funcionais da
ferramenta, pode-se observar que ela tem maior foco na gestão da organização,
fornecendo cadastro de fornecedores e cliente, gerênciamento de múltiplos projetos,
controle de recursos, controle de contatos de clientes e fornecedores, administração de
grupo de usuários, gráfico de grantt, exibido na Figura 4. 5, log de tarefas e suporte para
um fórum dentro da ferramenta.
Figura 4. 5: Gráfico de Grantt no DotProject.
Fonte - (Dot Project , 2001)
4.1.2.2.4. Trac.
Trac é uma ferramenta de gerência de projeto e configuração, é uma ferramenta
opensource e que possui documentação 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 integração entre o projeto e o repositório. Apesar da integração entre o repositório
ser bem limitada, a ferramenta é utilizada por grandes projetos de desenvolvimento
distribuído de software tais como: Cake PHP, Jelix e Synfony. Sendo desenvolvida para
gestão de projetos, e aprimorada para o gerênciamento de projetos de software, o objetivo
da ferramenta trac é diminuir a complexidade existente na gerência de grandes projetos
DDS. A ferramenta oferece suporte à comunicação com o SubVersion e outros sistemas
de controle de versão centralizados, mas apenas para visualização e revisões enviadas ao
repositório, não sendo relacionadas automaticamente as tarefas.
Apesar do número de funcionalidades existentes no projeto ainda serem pequenos
essa ferramenta foi construída com uma interface bem documentada com o intuito de que
sejam desenvolvidos plug-ins para adicionar recursos à ferramenta.
4.1.2.2.5. VastoFuncionário.
É uma ferramenta CASE que fornece apoio a gerência, desenvolvida pelo autor
recebeu o nome da empresa onde foi desenvolvida, é uma ferramenta proprietária ainda
não distribuída ao público. O desenvolvimento da ferramenta foi feito em linguagem
PHP com banco de dados postgres. A ferramenta possui interface web e diversas
características listadas a seguir:
Calendário de tarefas;
Controles flexíveis de acesso;
Notificações para acompanhamento da evolução do pedido por e-mail;
Integração com o Subversion;
Integração com Selenium HQ2 para testes automatizados;
Suporte a múltiplos projetos;
Suporte a marcos em projetos;
Suporte a internacionalização nativo;
Controle de visualização de rascunho de tarefas;
Comunicador instantâneo 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 gerência e a testes automatizados por meio da integração
com o SeleniumHQ.
O bando de dados da aplicação 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 aplicações web, (Selenium HQ Web Application
Testing System, 2009)
Figura 4. 7 - DER Ferramenta VastoFuncionário.
Fonte – Autor
As tabelas exibidas no DER seguem uma padronização onde o prefixo no nome
de cada tabela identifica o módulo ao qual essa tabela faz parte do sistema. Dessa forma
pode-se observar a existência de três módulos no sistema, sendo eles:
1) O módulo sistema identificado pelo prefixo “sis_”, que são tabelas referentes a
estrutura básica da ferramenta como por exemplo o cadastro de um usuário;
2) O prefixo “pro_” que identifica as tabelas do módulo de projetos da aplicação;
3) As tabelas com o prefixo “sel_”, que são referentes ao módulo de teste
integrados com Selenium HQ.
A descrição dos dados armazenados em cada uma dessas tabelas é:
sis_usuário – dados do cadastro dos usuários;
sis_char – armazena dados do comunicador instantâneo interno da aplicação, que
permite a comunicação entre os membros do projeto;
pro_atividade – Dados das atividades, tais como responsável, data de início e
término e a descrição da atividade e seu código único;
pro_atividade_tipo – Armazena os tipos de atividades existentes no sistema;
pro_atividade_hist – Armazenamento do status de uma tarefa, esses dados estão
mapeados com um relacionamento 1-n para a pro_atividade, para que se possa ter
diversas revisões de cada atividade;
pro_marco – Identifica o marco de cada projeto, todas as tarefas possuem um
marco, cada projeto possui inúmeros marcos;
pro_projeto – Armazena dados do projeto como nome e descrição do projeto.
Na Figura 4. 8 é apresentada uma interface do sistema Vasto Funcionário, que foi
desenvolvida e já está em funcionamento. No lado direito da figura pode-se observar o
comunicador instantâneo interno da ferramenta.
Figura 4. 8 - VastoFuncionário, tela inicial, com mensageiro ao lado.
Fonte - Autor
A ferramenta possui classificação da relevância de projetos por funcionário, como
pode ser visto na Figura 4. 9, onde é possível ver os projetos ordenados pela importância
do mesmo para cada usuário.
Figura 4. 9 – Interface de Exibição de projetos.
Fonte - Autor
Outra funcionalidade existente na ferramenta é o suporte a testes automatizados
dos projetos desenvolvidos, o módulo de teste funciona por meio de uma integração com
o repositório SubVersion e SeleniumHQ. Esse módulo de teste realiza check-out do
repositório e roda os testes pré-programados existentes no repositório de dados, os
resultados dos testes são exibidos dentro da ferramenta como pode ser observado na
Figura 4. 10 a seguir.
Figura 4. 10 - Módulo de testes automatizados
Fonte - Autor
Os erros encontrados na execução dos testes, também são enviados para os
programadores pelo chat interno do sistema, evitando assim que esses rodem os testes
manualmente. Essa solução reduz o tempo de teste gasto no desenvolvimento, pois os
testes de pré e pós-condições, previamente programados, podem ser executados
automaticamente pela aplicação, evitando que cada desenvolvedor tenha que rodar os
testes.
Na Figura 4. 11 é apresentada o diagrama de componentes da aplicação
VastoFuncionário.
Figura 4. 11 - Diagrama de componentes da ferramenta VastoFuncionário
Fonte - Autor
No diagrama de componente acima ilustrado na Figura 4. 11, os módulos da
aplicação estão destacados em cor azul, enquanto os módulos externos estão em cor
cinza, às funcionalidades de cada um desses módulos internos foi descrita a seguir:
Sistema Base – Módulo responsável pelo controle de informações
fundamentais da aplicação, como o controle de usuário.
Módulo projetos – Responsável 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 “Módulo
Base” para seu funcionamento pois toda tarefa esta relacionada a um
usuário.
Módulo de teste – Responsável pelos testes automatizados com
SeleniumHQ, internamente esse módulo possui os componentes
“Controlador Testes”, “Controlador API Selenium” e “Controler API
Subversion” , sendo que, o componente “Controler Testes” é responsável
pela gerência dos demais componentes do desse módulo. Os componentes
“Controler API Subversion” e “Controler API Selenium” são responsáveis
pela comunicação com os componentes externos API SubVersion e API
Selenium respectivamente.
Na Figura 4. 12, esta ilustrado o diagrama de classe da aplicação, nesse diagrama
estão as seguintes classes controladoras :
“Controler_Usuarios” – Classe controladora da entidade usuário e controle
de acesso a aplicação.
“Controler_Atividades” – Controladora da classe atividade, é responsável
pelo controle de cadastros edição e alterações nas tarefas dos projetos,
possui dependência da classe “Controler_Usuarios”, pois cada atividade
possui um usuário criador e um ou mais responsáveis.
“Controler_Projetos” – Controladora da classe projetos e marcos, é a
classe responsável pelo controle das funções de cadastro, edição e
alteração em projetos, a classe projetos possui dependência da classe
“Controler_Usuarios” pois os projetos sempre estão relacionados a um
usuário ou mais usuários, sendo que ao menos um usuário deve estar
gerênciado o projeto.
“Controler_Tarefas” – Controladora da classe tarefas , é responsável pelo
controle de criação e alterações nas tarefas. Essa classe possui
dependência da classe de controladora de usuários, pois as tarefas devem
ser atribuídas a um usuário.
“Controler_Testes – Classe controladora responsável pela execução de
testes automatizados com SeleniumHQ, essa classe controladora possui
dependência da classes “Controler_APISubversion” e
“Controler_APISelenium”, utilizadas para a comunicação com
SubVersion e SeleniumHQ respectivamente.
“Controler_APISubversion” – Controladora responsável pelo controle da
comunicação com o módulo externo Subversion.
“Controler_APISelenium” – Controladora da responsável pelo controle da
comunicação com o SeleniumHQ.
Figura 4. 12 - Diagrama de Classes da aplicação VastoFuncionário.
Fonte - Autor
.
43
4.1.3. Avaliação das ferramentas CASE.
Durante a fase de avaliação das ferramentas CASE foi feita a atribuição de notas
a cada requisito estabelecido no item 4.1.1, a atribuição de notas aos requisitos das
ferramentas, foram realizadas com na coleta de informações das ferramentas feitas no
item 4.1.2.2. Na Tabela 4. 2 a seguir, são exibidas as notas atribuídas a cada objetivo
esperado das ferramentas candidatas.
Tabela 4. 2- Notas atribuídas à cada ferramentas de gerência 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 Código fonte
ou API
8 7 7 8 10
Suporte a múltiplos projetos 2 10 0 10 10
Suporte controle e delegação de
tarefa a membro.
2 10 7 7 8
Definição de prazo nas tarefas. 2 10 10 10 10
Suporta a marcos nos projetos. 3 7 7 7 10
Integração com Repositório 10 10 10 0 10
Fonte – Autor.
As notas atribuídas na Tabela 4. 2, apenas refletem o quando as ferramentas
candidatas atendem cada requisito, não levando em consideração a importância de cada
requisito para o desenvolvimento da integração proposta. Para adequar à nota final de
cada ferramenta ao grau de importância do requisito é aplicado o peso estabelecido no
item 4.1.2.1 .
4.1.4. Seleção da ferramenta CASE
A seleção das ferramentas CASE consiste em duas etapas, sendo a primeira à
contabilização das notas e pesos atribuídos a cada ferramenta candidata, obtendo se uma
nota final a cada uma das ferramentas, Após a contabilização das notas, é feita a
indicação da ferramenta a ser utilizada no desenvolvimento da proposta contida no
capitulo 3. A seguir na Tabela 4. 3 são exibido os requisitos estabelecidos para a
44
avaliação 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 Código fonte ou
API
56 56 64 80
Suporte a múltiplos projetos 20 0 20 20
Suporte controle e delegação de
tarefa a membro.
20 14 14 16
Definição de prazo nas tarefas. 20 20 20 20
Suporta a marcos nos projetos. 21 21 21 30
Integração com Repositório 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 são o produto entre as notas atribuídas a cada requisito atendido pela
ferramenta, pelo peso do requisito, peso esse apresentado na Tabela 4. 1. Essas
multiplicações entre os pesos e as notas atribuídas às ferramentas, é realizada para
adequar a nota atribuída à ferramenta em cada requisito, com o grau de importância para
cada requisito do desenvolvimento da proposta, evitando assim que ferramentas sejam
selecionadas por possuírem inúmeras características mesmo não 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 pontuação, sendo
assim a mais adequada para o desenvolvimento da proposta de integração, com base nos
requisitos apresentados no item 4.1.1, foi a ferramenta VastoFuncionário apresentada no
item 4.1.2.2.5.
45
4.2. Análise dos sistemas de controle de versão
A avaliação dos sistemas de controle de versão foi desenvolvida para se definir a
ferramenta mais adequada para o desenvolvimento da proposta exposta no tópico 3, foi
feita em dois passos. Inicialmente foram coletadas as informações sobre os sistemas de
controle de versionamento, e posteriormente feita a seleção da ferramenta a ser utilizada
que ficou condicionada a escolha da ferramenta de gerência de projetos adotada no tópico
4.1.4.
4.2.1. Coleta de informações
A utilização de sistemas de controle de versionamento permite à colaboração
múltipla em projetos de desenvolvimento, permitindo gerência a edição simultânea 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 distribuído.
A utilização de sistemas de controle de versão permite o compartilhamento
organizado dos artefatos gerados em um projeto de software, permitindo a gerência das
revisões de maneira clara, além de possibilitar a edição simultânea de artefatos sem
grandes prejuízos para projeto.
Em geral sistemas de controle de versão possuem não somente a cópia de
trabalho, mas todas as demais revisões geradas do projeto, como ilustrado na Figura 4.
13.
Figura 4. 13 - Exemplo das revisões de aretefatos.
Fonte - http://tortoisesvn.net/docs/nightly/TortoiseSVN_pt_BR/images/ch02dia6.png
46
Como pode ser observado na Figura 4. 13, cada versão está disposta em uma das
colunas, sendo que cada nova revisão do projeto não apaga a versão anterior, podendo se
adquirir qualquer versão de um determinado arquivo. Além da manutenção de todas as
revisões do projeto, os sistemas de controle de versão permitem a separação das versões
do projeto, que em geral são separadas em três categorias abaixo.
Trunk – Versão utilizada no desenvolvimento, tronco do projeto, aqui deve ficar
todo o projeto atual, essa versão é a que os desenvolvedores realizam downloads
para desenvolvimento de novas funcionalidades.
Tag – Revisões estáveis do projeto, são versões geradas a cada fim de um
marco/baseline, dependendo da política de manutenção, cada tag é uma baseline
do projeto ou ponto de partida para um novo tronco.
Branches – São revisões utilizadas apenas para se fazer uma correção em uma
tag, após o término na baseline corrente essas modificações devem ser unidas
com o tronco do projeto afim de se gerar uma nova baseline ou tag.
Figura 4. 14 – Ilustração da organização 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 versões estáveis de um projeto e suas
correções, ainda é possível ocorrer problemas de edição simultânea de um mesmo de um
artefatos ou de artefatos dependentes. Para solucionar esse problema cada vez que um
usuário envia uma nova revisão para o repositório, esse por sua vez identifica os conflitos
47
dos artefatos alterados e que já possuem versão mais nova do que a envida pelo usuário,
e assim pede para que o usuário solucione o conflito.
Para trabalhar, o usuário não edita diretamente o arquivo do repositório, ele fica
com a cópia de trabalho, que é a versão corrente do repositório, cujo processo de
aquisição dessa versão é chamado de “checkout” . Dessa forma, o usuário edita sua cópia
e ao término de seus trabalhos, envia as alterações para o repositório e esse processo de
envio é chamado de “commit”.
Embora as funcionalidades gerais fornecidos pelos sistemas de controle de versão
sejam similares, é possível classificá-los da em centralizados e distribuídos.
4.2.1.1. Versionamento centralizado
São sistemas baseados na arquitetura cliente-servidor, que possuem apenas
repositório central que mantém armazenado todos os artefatos e todas os seus revisões.
Os clientes por sua vez mantém apenas uma cópia dos artefatos, a essa é chamada de
“cópia de trabalho”. Ao término de uma edição na sua cópia de trabalho os clientes
enviam as alterações feitas na sua cópia de trabalho ao sistema de controle de versão, que
verifica as diferenças entre à cópia de trabalho e o repositório, armazenando apenas as
diferenças entre esses, um esquema simplificado pode está apresentado na Figura 4. 15;
Figura 4. 15 - Sistemas de controle de versão centralizados.
Fonte - http://www.pronus.eng.br/images/dvcs/area_trabalho_repositorio.png
48
4.2.1.2. Versionamento distribuído
São sistemas de versionamento onde cada cliente possui uma cópia do repositório
e uma cópia de trabalho. Nesse modelo os clientes submetem as suas áreas de trabalho ao
seu repositório local que posteriormente se sincroniza com outros repositórios por meio
de operações push e pull, esquema simplificado está apresentado na Figura 4. 15.
49
Figura 4. 16 – Envio de uma revisão ao repositório local do cliente.
Fonte -http://www.pronus.eng.br/images/dvcs/operacoes_basicas_distribuido.png
Figura 4. 17 - Sincronização entra repositórios 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 tópico 4.2.1.1, lançada em 2004, apesar de nova possui amplo suporte das ferramentas
50
de desenvolvimento, permitindo o versionamento de diretório e arquivos e controle de
permissão individual para cada um desses. Uma característica 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 versão, existe clara distinção entre
e o servidor, cliente. O servidor svn é responsável por gerênciar os artefatos e revisões no
repositório, enquanto o aplicativo cliente é responsável por gerênciar as copias de
trabalho e permitir o acesso ao servidor svn.
O aplicativo cliente svn disponível na instalação do pacote oficial, apenas oferece
interface CLI, mas existem diversos como Tortoise que fornecem interface gráfica ao
cliente snv.
4.2.3. Git
Git é um sistema de controle de versão distribuído explicado no tópico 4.2.1.2, é
licenciado com a licença GPL explicada no tópico Erro! Fonte de referência não
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 distribuído;
Possibilitar a utilização de grandes volumes de arquivos em junções
(merge) com eficiência.
Um repositório Git pode ter repositórios filhos, e cada utilizador dos repositórios
filhos podem ter suas copias de trabalho como é ilustrado na Erro! Fonte de referência
não encontrada..
4.2.4. Mercurial
Sistema de controle de versionamento distribuído e originado do Git descrito no
tópico 4.2.3 , é licenciado com a licença GPLv2, desenvolvido principalmente em
51
Python, no entanto o seu utilitário fundamental o diff é escrito em C. As principais
características são a escalabilidade e alta performance, Os sistemas de controle de
versão distribuídos são fundamentalmente semelhantes com os centralizados, os clientes
não precisão estar on-line com o servidor central para conseguirem realizar envio das
suas versões, pois é possível submeter a copia de trabalho diretamente para o repositório
local como ao repositório central como ilustrado na Figura 4. 18.
Figura 4. 18 - Funcionamento repositório distribuído.
Fonte - http://img.vivaolinux.com.br/imagens/artigos/comunidade/img3.PNG acessado em 09/11/2012.
4.2.5. Seleção sistema de controle de versionamento.
Para o desenvolvimento deste trabalho foi feita a adoção do sistema de controle
de versão, que foi condicionada a escolha da ferramenta de apoio à gerência adotada no
tópico 0, pois como a ferramenta escolhida fornece suporte ao SubVersion apresentado
no tópico 4.2.2 , o desenvolvimento da proposta também deve utiliza-lo.
4.3. Descrição das ferramentas utilizadas no
desenvolvimento
Para o funcionamento das ferramentas CASE integradas e do mecanismo de
auxílio a rastreabilidade proposto, foi utilizado o seguinte ambiente plataforma Linux
52
Ubuntu 10.04, os softwares utilizados seguem a seguir listados na sequência de
instalação, todos foram adquiridos a partir do repositório apt 3da distribuição utilizada.
Servidor apache 2.2 – Utilizado como servidor de aplicação.
libapache2-mod-php5 – Módulo do servidor apache responsável pela
interpretação do código php.
Servidor postgres8.4 – Servidor de banco de dados utilizado pela ferramenta
VastoFuncionario e pelo mecanismo de auxílio a rastreabilidade.
SubVersion server 1.6.6 - sistema de controle de versão.
libapache-svn – biblioteca utilizada para estabelecer a comunicação com a API do
repositório SubVersion.
4.4. Integração das ferramentas CASE.
O desenvolvimento do mecanismo de auxílio à rastreabilidade proposto no
Capitulo 3, fornece a rastreabilidade entre tarefas e revisões descritas no 3.1.2 e 3.1.3.
Por meio da integração entre as ferramentas CASE. Para o desenvolvimento do
mecanismo de auxílio a rastreabilidade na ferramenta CASE VastoFuncionário, foi
necessário estabelecer a comunicação entre o repositório SubVersion por meio da API
disponível.
Para possibilitar o relacionamento entre tarefa e revisão dentro da ferramenta
VastoFuncionário, foi adicionada no seu banco de dados a tabela
“pro_atividade_revisão” ilustrada na Figura 4. 19 .
3 APT (Advanced Packaging) é um gerenciador disponível nos sistemas operacionais Linux
Debian e derivados (FERREIRA, 2006).
53
Figura 4. 19 – Tabela que relaciona tarefa e revisão.
Com a adição desta tabela foi possível o desenvolvimento da rastreabilidade
proposta nos itens 3.1.2 e 3.1.3.
4.4.1. A Implementação do mecanismo de rastreabilidade.
A implementação do mecanismo de auxílio à rastreabilidade proposto no Capítulo
3 deste trabalho, foi implementada com a criação da tabela ilustrada na Figura 4. 19, no
banco da ferramenta VastoFuncionário. E com a adição do módulo responsável pelo
mecanismo de rastreabilidade, que se comunica com o repositório.
As consultas necessárias para efetiva rastreabilidade foram descritas nos itens
abaixo.
4.4.1.1. Consulta para rastreabilidade entre tarefa para revisão.
A rastreabilidade entre uma tarefa e uma revisão proposta no item 3.1.2, permite
que a partir de uma se identifique todas as revisões que estão relacionadas com essa
tarefa. A consulta implementada para realização dessas rastreabilidade segue abaixo e
exprime exatamente a ideia de selecionar todas as informações existentes na tabela
“pro_atividade_revisao” que possuam associação com uma determinada tarefa na.
SELECT * FROM ´pro_atividade_revisao´ WHERE ´fk_pro_atividade´ = $tarefa.
4.4.1.2. Consulta para rastreabilidade revisão para tarefa.
A rastreabilidade proposta no item 3.1.3, permite que a partir de uma revisão
identifique todas as tarefas, que estão relacionadas a essa revisão. A consulta
implementada para realização dessas rastreabilidade segue abaixo e exprime exatamente
a ideia de selecionar todas as informações existentes na tabela “pro_atividade_revisao”
que possuam associação com uma determinada revisão.
54
SELECT * FROM ´pro_atividade_revisao´ WHERE ´fk_revisao´ = $revisao
4.4.2. Analise dos resultados
Para analisarmos um cenário pratico da rastreabilidade do mecanismo proposto
neste trabalho, foi feito uma base de teste com cadastro de tarefas fictícias, e foi
construído um repositório com os comentários adequados. Nesta base de dados de teste
feitos os seguintes cadastros
Tarefas – 5 Tarefas.
o Tarefa 1 com as revisões 1 ,2,4,
o Tarefa 2 com revisões 3,6 ,9
o Tarefa 3 com revisões 5,7, 9
o Tarefa 4 com as revisões 8, 10,11
o Tarefa 5 com as revisões 9,11, 12,13,14
Repositórios – No repositório de teste foram feitas 14 revisões, sendo que
os comentários inseridos em cada uma delas pode ser visto na Tabela 4. 4,
a seguir .
Tabela 4. 4 - Revisões e comentários do repositório de teste.
Revisão Autor Pasta submetida Comentário Enviado
Revisão
14 rbeninca /Configurações /Configurações/Cinema7D.identcache
/Configurações/Cinema7D.res /Configurações/ProjectGroup1.groupproj.local
/Configurações/edit.dcu /Configurações/exemplo.csv
[5]
13 rbeninca / [5]
12 rbeninca / [5]
11 rbeninca /Tcc/ [5] [4]
10 rbeninca /Configurações/ [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
Após o abastecimento da base de dados de teste e do repositório foi, verificada a
rastreabilidade do mecanismo proposto,
4.4.2.1. Testes com a rastreabilidade tarefa para revisão.
Para o teste da rastreabilidade tarefa para revisão, foi feita a consulta de todas as
tarefas cadastradas na base de testes, o resultado do estão disponíveis 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 revisão, com tarefa=1.
Fonte – Autor
Figura 4. 21 - Teste Rastreabilidade Tarefa revisão, com tarefa=2.
Fonte – Autor.
Figura 4. 22 - Teste Rastreabilidade Tarefa revisão, com tarefa=3
Fonte – Autor
Figura 4. 23 - Teste Rastreabilidade Tarefa revisão, com tarefa=4
Fonte – Autor
Figura 4. 24 - Teste Rastreabilidade Tarefa para revisão, 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 revisões relacionadas com cada tarefa, além de
identificar a hora, usuário que submeteu as alterações e a lista de artefatos alterados na
revisão.
4.4.2.2. Testes com a rastreabilidade revisão tarefa
Para a realização do teste da rastreabilidade uma revisão para tarefas relacionadas,
foi consultado ferramenta desenvolvida as revisões 1, 2, 3, 9 e 11, nessa rastreabilidade o
rastreabilidade o mecanismo deveria nos retornar as tarefas relacionadas com a revisão
consultada, a seguir nas figuras Figura 4. 25 a Figura 4. 29, estão os resultados dos
testes realizados.
Figura 4. 25 - Teste Rastreabilidade revisão para tarefas, com revisão=1.
Fonte – Autor
Figura 4. 26 - Teste Rastreabilidade revisão para tarefas, com revisão=2
Fonte – Autor
58
Figura 4. 27 - Teste Rastreabilidade revisão para tarefas, com revisão=3
Fonte – Autor
Figura 4. 28 - Teste Rastreabilidade revisão para tarefas, com revisão=9
Fonte – Autor
Figura 4. 29 - Teste Rastreabilidade revisão para tarefas, com revisão=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 revisão, fornecendo a
rastreabilidade proposta no item 3.1.3.
59
5. Conclusão
Com a globalização dos mercados locais, ocorreu uma crescente demanda por
software, nesse mercado atual o software tem se tornado um componente estratégico para
diversas áreas de negócio. Contudo, o progresso das economias e a sofisticação dos meios
de comunicação, aumentou a concorrência que impôs a redução de custos. Nesse
contexto, o desenvolvimento distribuído de software, surge como uma solução
estratégica. Porém, a distribuição do processo de desenvolvimento de software, trouxe
novos desafios inerentes à dispersão, entre os problemas provenientes da utilização de
DDS, temos a dificuldade da gestão devida falta de contato direto entre os membros da
equipe (AUDY e PRIKLADINICK, 2008).
O objetivo deste trabalho foi propor uma solução para os problemas relacionados
à falta da rastreabilidade existente em ambientes DDS. A solução proposta neste trabalho
foi à integração entre as ferramentas CASE, uma de apoio a gerência e um sistema de
controle de versionamento. Após, a elaboração da proposta foi desenvolvido a integração
entre as ferramentas e realização de testes práticos do mecanismo proposto. A análise
dos testes nos revelou que a proposta do mecanismo de rastreabilidade é valida e fornece
as informações necessárias para uma melhor gestão de projetos DDS.
Uma série de trabalhos futuros pode ser realizada a partir do mecanismo proposto,
um destes trabalhos seria a expansão das rastreabilidades suportadas pelo mecanismo,
fornecendo rastreabilidade da evolução de cada artefato, contido no repositório e suas
diferenças.
Um trabalho futuro ainda mais ambicioso seria a integração do mecanismo
proposto com a IDE utilizada pelos desenvolvedores, fornecendo a rastreabilidade da
evolução dos artefatos e das tarefas, dentro do ambiente de desenvolvimento.
A seguir é apresentadas as atividades realizadas durante a construção do trabalho.
60
6. Referências Bibliográficas
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. Integração 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. São
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 Distribuído de
Software- Disen, Maringá,, ago. 2007. 28.
NUNES, B. B. Integrando a gerência de configuração de
software,documenrntação gerência de conhecimento em um ambiente de
desenvolvimento de software. UFES. Vitória, 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 Informação. 3. ed.
São 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 Informática
Av. Colombo 5790, Maringá-PR, CEP 87020-900
Tel: (44) 3261-4324 Fax: (44) 3263-5874
www.din.uem.br
63
![IX FESTIVAL de SOPAS 10 |11 Novembro · Passagem do ano na Amendoeira-2012/2013 Ver notícia Completa [+] Até aos reis ofereça sabores. Ofereça tradição. Ofereça saber. Ofereça](https://img.document.onl/doc/110x75/5d37288088c99342678c3a5a/ix-festival-de-sopas-10-11-passagem-do-ano-na-amendoeira-20122013-ver-noticia.jpg)
