Embed Size (px)
Citation preview
CENTRO UNIVERSITÁRIO UNIVATES
CURSO DE SISTEMAS DE INFORMAÇÃO
COLLABCODE: FERRAMENTA PARA APOIO AO DESENVOLVIMENTO DISTRIBUÍDO E COLABORATIVO DE
SOFTWARE
Maurício Severo da Silva
Lajeado, junho de 2013
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Maurício Severo da Silva
COLLABCODE: FERRAMENTA PARA APOIO AO DESENVOLVIMENTO DISTRIBUÍDO E COLABORATIVO DE
SOFTWARE
Monografia apresentada ao Centro de Ciências Exatas e Tecnológicas do Centro Universitário UNIVATES, como parte dos requisitos para a obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Ms. Alexandre Stürmer
Wolf
Lajeado, junho de 2013
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Maurício Severo da Silva
COLLABCODE: FERRAMENTA PARA O APOIO AO
DESENVOLVIMENTO DISTRIBUÍDO E COLABORATIVO DE
SOFTWARE
A Banca examinadora abaixo aprova a Monografia apresentada na disciplina
Trabalho de Conclusão de Curso, do Centro Universitário UNIVATES, como parte da
exigência para a obtenção do grau de Bacharel em Sistemas de Informação:
Prof. Ms. Alexandre Stürmer Wolf - orientador
Centro Universitário UNIVATES
Prof. Ms. _____________________________
Centro Universitário UNIVATES
Prof. Ms. _____________________________
Centro Universitário UNIVATES
Lajeado, junho de 2013
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Dedico este trabalho aos meus pais, que sempre me incentivaram e me
encorajaram nas horas em que eu mais precisei.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
AGRADECIMENTOS
Agradeço primeiramente a Deus e a todos os seres de luz, por permitirem que
após tanto tempo dedicado a este trabalho eu pudesse apreciar sua conclusão. Não
menos importante é o agradecimento aos meus pais, Valter e Mara, que sempre
acreditaram que a educação é o melhor caminho e me oportunizaram cursar uma
graduação.
À minha amada namorada Itamony, que sempre foi paciente, atenciosa e me
incentivou e acalmou nos momentos difíceis desta trajetória.
A todos os colegas e professores, que de alguma forma contribuíram para o
aperfeiçoamento deste trabalho.
Para finalizar, um agradecimento especial ao meu professor orientador
Alexandre Stürmer Wolf, que é uma pessoa incrível, um profissional atencioso e
sempre disposto a ajudar. É a ele que devo o prazer de ter baseado meu trabalho
em uma área tão interessante.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
RESUMO
O atual cenário da economia mundial exige que as empresas de desenvolvimento de software adaptem seus processos de forma a absorver as novas demandas que o mundo globalizado traz. Essa adaptação perpassa pelo processo de desenvolvimento de software, que está se tornando cada vez mais distribuído e dinâmico. O presente trabalho apresenta uma solução que atenderá de forma equilibrada às necessidades do desenvolvimento de software de forma distribuída, sem perder a colaboração e a cooperação existentes nas equipes presenciais. Neste contexto, o trabalho apresenta o embasamento teórico para uma definição clara das ferramentas necessárias para o desenvolvimento distribuído e colaborativo de software utilizando metodologias ágeis. Palavras-chave: Ferramenta web. Desenvolvimento colaborativo. Desenvolvimento distribuído de software. Metodologias ágeis.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
ABSTRACT
The current scenario of the global economy requires companies to adapt their software development processes in order to absorb the new demands that the globalized world behind. This adaptation goes through the process of software development, which is becoming increasingly distributed and dynamic. This paper presents a solution that will meet evenly the needs of software development in a distributed way, without losing the existing cooperation and collaboration teams in attendance. In this context, the paper presents the theoretical background for a clear definition of the necessary tools for the development of distributed and collaborative software using agile methodologies. Keywords: Web tool. Development collaborative. Distributed software development. Agile methodologies.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE FIGURAS
Figura 1 - Exemplos de ciclo de desenvolvimento de software ..................................... 20
Figura 2 - Comunicação cliente/servidor utilizando o protocolo HTTP ......................... 21
Figura 3 - Processo de comunicação cliente/servidor em uma aplicação web ........... 22 Figura 4 - Comunicação intermediada pelo sistema operacional .................................. 23
Figura 5 - Modelo de colaboração 3C ................................................................................ 25
Figura 6 - Principais razões envolvidas no DDS .............................................................. 31
Figura 7 - Níveis de dispersão em DDS ............................................................................. 33
Figura 8 - Relacionamento do sistema com o meio ambiente ....................................... 35 Figura 9 - Ciclo de vida do sistema ..................................................................................... 37
Figura 10 - Ciclo de vida clássico no modelo cascata ..................................................... 39 Figura 11 - Organização do sistema RAD ......................................................................... 39
Figura 12 - Ciclo de vida do desenvolvimento de software no modelo espiral ............ 41 Figura 13 - Desenvolvimento utilizando XP ....................................................................... 43
Figura 14 - Fluxo de trabalho no modelo Scrum .............................................................. 45 Figura 15 - Modelo de definição de característica ........................................................... 47
Figura 16 - Exemplo de funcionamento de um servidor de correio eletrônico ............ 50
Figura 17 - Terceirização no ciclo de vida do software ................................................... 51
Figura 18 - Tecnologias colaborativas ............................................................................... 52
Figura 19 - Gráfico de Gantt ................................................................................................ 54 Figura 20 - Página inicial da ferramenta CloudForge ...................................................... 56
Figura 21 - Interface de edição de código-fonte do Kodingen ....................................... 57 Figura 22 - Interface do NetBeans com a ferramenta IdDE ativada ............................. 59
Figura 23 - Lista de atividades do RedMine ...................................................................... 61
Figura 24 - Visualização da página Milestones ................................................................ 62 Figura 25 - Comparação entre as ferramentas analisadas............................................. 64
Figura 26 - Ferramentas disponíveis no CollabCode ...................................................... 68 Figura 27 - Caso de uso - Gerente ..................................................................................... 69
Figura 28 - Interface de gerenciamento de usuários ....................................................... 70
Figura 29 - Interface de vinculação de usuários ao projeto ............................................ 71 Figura 30 - Lista de projetos e ações disponíveis ............................................................ 71
Figura 31 - Interface de criação de projetos ...................................................................... 72
Figura 32 - Interface de criação de atividade .................................................................... 73
Figura 33 – Parte da lista de atividades de um projeto ................................................... 74 Figura 34 - Gráficos de Gantt por projeto e por atividade ............................................... 74
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 35 - Caso de uso - Desenvolvedor ......................................................................... 76
Figura 36 - Área de codificação ........................................................................................... 77
Figura 37 - Funcionamento simplificado da edição simultânea ..................................... 78 Figura 38 - Interface do bate-papo ..................................................................................... 79 Figura 39 - Sala de reunião com o BigBlueButton ........................................................... 80
Figura 40 - Interface de banco de dados ........................................................................... 80 Figura 41 - Interface de gerenciamento de arquivos ....................................................... 81
Figura 42 - Interface do sistema de controle de versões ................................................ 82 Figura 43 - Modelo de base de dados ................................................................................ 87
Figura 44 - Script utilizado para a criação de projetos .................................................... 90 Figura 45 - Funcionamento do servidor de edição colaborativa .................................... 93
Figura 46 – Funcionamento da edição colaborativa no navegador............................... 94
Figura 47 - Diagrama de componentes da interface do CollabCode ............................ 95
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE ABREVIATURAS E SIGLAS
CERN - European Organization for Nuclear Research
CVS - Concurrent Versions System
DDS - Desenvolvimento Distribuído de Software
DGS - Desenvolvimento Global de Software
DNS - Domain Name System
ER - Entidade Relacionamento
ERP - Enterprise Resource Planning
FFD - Feature Driven Development
FTP - File Transfer Protocol
GIT - Global Information Tracker
GPL - General Public License
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol
IdDE - Integrated and Distributed Development Environment
IDE - Integrated Development Environment
IMAP - Internet Message Access Protocol
MTA - Mail Transfer Agent
MUA - Mail User Agent
PC - Personal Computer
PDA - Personal Digital Assistant
POP - Post Office Protocol
RAD - Rapid Application Development
RD - Requisitos de Desenvolvedor
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
RoR - Ruby on Rails
RU - Requisitos de Usuário
SIP - Session Initiation Protocol
SMTP - Simple Mail Transfer Protocol
SO - Sistema Operacional
SVN - Subversion
TCP/IP - Transmission Control Protocol/Internet Protocol
UML - Unified Modeling Language
URL - Uniform Resource Locator
XMPP - Extensible Messaging and Presence Protocol
XP - eXtreme Programing
WWW - World Wide Web
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................... 14
2 DESENVOLVIMENTO DE SOFTWARE ................................................................... 17
2.1 Conceituação ............................................................................................................ 17
2.1.1 Software ..................................................................................................................... 17
2.1.2 Aplicação web .......................................................................................................... 20
2.1.3 Sistema operacional ............................................................................................... 22
2.1.4 Sistema distribuído/Software distribuído ......................................................... 23
2.1.5 Colaboração .............................................................................................................. 24
2.1.6 Software colaborativo (groupware) .................................................................... 26
2.1.7 Desenvolvimento distribuído de software (DDS) ............................................ 29
2.1.8 Desenvolvimento colaborativo ............................................................................ 34
2.1.9 Sistema ....................................................................................................................... 34
2.2 Metodologias de desenvolvimento ..................................................................... 37
2.2.1 Metodologias tradicionais ou pesadas .............................................................. 38
2.2.2 Metodologias ágeis ................................................................................................. 41
2.3 Recursos para o desenvolvimento distribuído e colaborativo ................... 47 2.3.1 Versionamento ......................................................................................................... 47
2.3.2 Servidor web ............................................................................................................. 48
2.3.3 Linguagens de programação web ....................................................................... 49
2.3.4 Servidor de correio eletrônico ............................................................................. 49
2.3.5 Edição colaborativa – escrita de código ........................................................... 50
2.3.6 Comunicação ............................................................................................................ 51
2.3.7 Gerenciamento de atividades ............................................................................... 53
3 TRABALHOS RELACIONADOS ............................................................................... 55
3.1 CloudForge ................................................................................................................ 55 3.2 Kodingen .................................................................................................................... 57 3.3 IdDE ............................................................................................................................. 58
3.4 RedMine ..................................................................................................................... 60 3.5 ProjectPier ................................................................................................................. 61
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3.6 Análise das ferramentas existentes ................................................................... 63
4 IMPLEMENTAÇÃO DO SISTEMA ............................................................................. 65
4.1 Tecnologias utilizadas ........................................................................................... 65 4.1.1 Ambiente de desenvolvimento ............................................................................ 66
4.1.2 Sistema operacional Linux ................................................................................... 66
4.1.3 Linguagens de programação ............................................................................... 66
4.1.4 Banco de dados ....................................................................................................... 67
4.1.5 Servidores web ......................................................................................................... 67
4.1.6 Versionamento do código-fonte .......................................................................... 67
4.2 Visão geral ................................................................................................................. 68 4.3 Gerente ....................................................................................................................... 69
4.3.1 Gerenciamento de Usuários ................................................................................. 70
4.3.2 Gerenciamento de projetos .................................................................................. 71
4.3.3 Gerenciamento de atividades ............................................................................... 73
4.3.4 Gerenciamento de bases de dados .................................................................... 75
4.4 Desenvolvedor ......................................................................................................... 75
4.4.1 Área de codificação ................................................................................................ 76
4.4.2 Edição colaborativa ................................................................................................ 77
4.4.3 Ferramentas de comunicação .............................................................................. 78
4.4.4 Manipulação de banco de dados ......................................................................... 80
4.4.5 Gerenciamento de arquivos ................................................................................. 81
4.5 Requisitos do sistema ............................................................................................ 82
4.6 Arquitetura do sistema ........................................................................................... 86
4.6.1 Banco de dados do CollabCode .......................................................................... 86
4.6.2 Criação de projetos ................................................................................................. 89
4.6.3 Criação de bases de dados para projetos ........................................................ 92
4.6.4 Edição colaborativa ................................................................................................ 93
4.6.5 Componentes utilizados ........................................................................................ 95
4.7 Configurações de segurança ............................................................................... 96
5 CONCLUSÃO ................................................................................................................ 98
5.1 Trabalhos Futuros ................................................................................................... 99
REFERÊNCIAS ................................................................................................................... 101
APÊNDICES ......................................................................................................................... 107
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
14
1 INTRODUÇÃO
Com o mundo cada vez mais conectado e com as tecnologias cada vez mais
acessíveis, os processos empresariais precisaram ser adaptados. Grandes
empresas vislumbraram seus produtos sendo comercializados e fabricados em
âmbito global, e geraram modificações em seus processos para que sobrevivessem
nesta nova realidade. A competitividade e a ambição por novos mercados fez com
que estas empresas aderissem a modelos de negócios onde a descentralização do
processo de fabricação dos produtos representava um ganho muito grande na
logística e na venda.
Esse processo de adaptação a um ambiente globalizado e dinâmico gera
implicações também em empresas de desenvolvimento de software. O processo de
globalização dos negócios empresariais gera novos desafios para o processo de
desenvolvimento, uma vez que o cliente pode estar em outro estado, país ou até
continente. Essa dispersão faz com que cada vez mais o trabalho destas equipes
ocorra de forma distribuída e descentralizada, tornando a área de desenvolvimento
de software cada vez mais interdisciplinar e requerendo conhecimentos e a
aplicação de técnicas de outras áreas como administração, psicologia, educação,
sociologia, dentre outros (AUDY; PRIKLADNICKI, 2008, p. 1).
Gärtner (2011, p. 19) afirma que um número significativo de empresas está
começando a adotar o modelo de Desenvolvimento Distribuído de Software (DDS).
Segundo o autor, o desenvolvimento geograficamente distribuído de software
tornou-se uma necessidade, uma vez que os modelos de negócios empresariais
tornaram-se globais. O autor afirma ainda que o DDS tem causado um grande
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
15
impacto na forma como o software é modelado, construído, testado e entregue, uma
vez que os modelos tradicionais de desenvolvimento não foram projetados para
atender a essa emergente realidade.
Ambler (2004, p. 1) afirma que o desenvolvimento de software encontra-se
aquém do ideal. Segundo o autor, os projetos são entregues com atraso ou com o
orçamento estourado, isso quando são entregues. Para enfrentar estes desafios,
foram criadas metodologias de desenvolvimento ágeis, que modificam a forma como
o software é desenvolvido. Apesar disso, não foram encontradas ferramentas que
propiciem aos desenvolvedores uma solução unificada para o desenvolvimento de
software e que utilize metodologias ágeis com enfoque no desenvolvimento
distribuído de software.
Motivado pela inexistência/escassez de tal solução, o presente trabalho tem
por objetivo apresentar uma solução que seja capaz de suprir as necessidades das
equipes de desenvolvimento nas grandes áreas: suporte, gerenciamento,
coordenação, comunicação e cooperação. Quando atendidas adequadamente, estas
grandes áreas são capazes de fornecer o ferramental necessário para que equipes
de desenvolvimento possam trabalhar de forma ágil e distribuída.
De forma a atender os conceitos, tecnologias, modelos e todos os assuntos
que de alguma forma permeiam o presente trabalho, ele foi dividido em cinco
capítulos, conforme segue:
Capítulo 1 – Introdução: É apresentada uma visão geral sobre o atual
cenário de desenvolvimento de sistemas no mundo, além de
apresentar a problemática e objetivos referentes a este trabalho;
Capítulo 2 – Desenvolvimento de software: são apresentados os
conceitos, as metodologias de desenvolvimento e os recursos
necessários para o desenvolvimento distribuído de software;
Capítulo 3 – Trabalhos relacionados: são apresentadas cinco
ferramentas que possuem recursos importantes para o
desenvolvimento distribuído e para o gerenciamento das atividades;
Capítulo 4 – Implementação do sistema: neste capítulo é apresentada
a solução proposta neste trabalho, seus requisitos técnicos, as
tecnologias utilizadas e sua estrutura de funcionamento;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
16
Capítulo 5 – Conclusão: por fim, este capítulo apresenta as conclusões
do trabalho e a lista de trabalhos futuros;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
17
2 DESENVOLVIMENTO DE SOFTWARE
Neste capítulo são apresentados temas relacionados ao desenvolvimento de
software com vistas a formar o referencial teórico necessário para melhor
compreensão deste trabalho. Inicialmente são apresentados os principais conceitos
referentes à área de desenvolvimento de software e, após, as metodologias de
desenvolvimento e os recursos necessários para a programação colaborativa.
2.1 Conceituação
Nas próximas seções são apresentados alguns conceitos relacionados ao
desenvolvimento de software. Esses conceitos foram extraídos da literatura
existente e fazem parte da fundamentação teórica deste trabalho.
2.1.1 Software
Autores como Pressman (2010, p. 1) e Sommerville (2007, p. 4) definem o
software como sendo o produto que os profissionais da informática e computação
constroem e mantêm ao longo do tempo. Segundo os autores, a definição de
software abrange programas que trabalham em computadores de todos os
tamanhos e arquiteturas. Os autores vão além, defendendo que software engloba
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
18
toda a documentação, as configurações e tudo que é necessário para que o
programa funcione corretamente.
Para Sommerville (2007, p. 3), existem dois tipos de produtos de software:
Produtos genéricos: são sistemas do tipo stand-alone, produzidos em
uma empresa de desenvolvimento e vendidos para todos os clientes
que quiserem adquirir. Como exemplo desse tipo de produto pode-se
citar programas para PCs como banco de dados, processadores de
texto e editores de imagens;
Produtos sob encomenda/personalizados: são sistemas
encomendados por um determinado cliente e todo o processo de
desenvolvimento é voltado para as especificidades do cliente
solicitante. Como exemplo deste modelo de produto pode-se citar os
sistemas para controle de dispositivos eletrônicos, que são
desenvolvidos para apoiar determinado processo de negócio e
sistemas de controle de tráfego aéreo.
Sommerville (2007, p. 3) afirma que a linha entre estes dois produtos está
cada vez mais tênue. O autor cita como exemplo o caso de sistemas Enterprise
Resource Planning (ERP), que são desenvolvidos de forma genérica, mas podem
ser adaptados de acordo com o modelo de negócios da empresa contratante.
Pressman (2010, p. 6) divide os softwares quanto à sua natureza. Segundo o
autor, são sete as categorias nas quais os softwares podem se enquadrar:
Software de sistema: são programas escritos para servir outros
programas. Esse tipo de software é caracterizado pela interação
intensa com o hardware, uso intenso por múltiplos usuários, operação
concorrente que requer ordenação, dentre outros. Exemplo:
compiladores, editores, componentes de sistemas operacionais;
Software de aplicação: são programas isolados que resolvem um
problema específico do negócio. Exemplo: processamento de
transações no ponto de venda e controle de processo de fabricação em
tempo real;
Software científico e de engenharia: a aplicação desse tipo de software
vai da astronomia à vulcanologia, da biologia molecular à manufatura
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
19
automatizada. Este tipo de software atualmente apresenta
características de tempo real e de sistemas;
Software embutido: são softwares que estão dentro de produtos ou
sistemas. Exemplo: software que controla o teclado do forno micro-
ondas, função digital de controle de combustível em automóveis ou
sistemas de frenagem;
Software para linha de produtos: esse tipo de software tem como
característica a venda para muitos usuários. Atende a um determinado
nicho de mercado ou ao consumo em massa. Exemplos: software de
controle de estoque, gestão de banco de dados e aplicações
financeiras pessoais e empresariais;
Software para inteligência artificial: esse tipo de software faz uso de
algoritmos não numéricos para resolver problemas complexos que não
podem ser analisados nem mesmo computados de forma direta.
Exemplo: redes neurais, sistema de reconhecimento de padrões em
imagens e voz, jogos;
Aplicações web: são apresentadas detalhadamente na seção 2.1.2,
uma vez que seu entendimento é de fundamental importância para o
escopo deste trabalho.
Sommerville (2007, p. 37) descreve uma série de modelos genéricos de
processos de desenvolvimento de software. Esses processos são abordagens de
desenvolvimento que podem ser utilizadas no projeto, implementação e manutenção
de software. Não cabe no escopo deste trabalho detalhar cada um deles, mas cabe
salientar que todos os modelos possuem embasamento teórico e metodológico. A
Figura 1 apresenta o ciclo de desenvolvimento em alguns dos modelos descritos por
Sommerville.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
20
Figura 1 - Exemplos de ciclo de desenvolvimento de software
Fonte: adaptado de Sommerville (2007, p. 37-40).
2.1.2 Aplicação web
Em 1989, Tim Berners-Lee, como forma de solucionar os problemas de
informações em projetos da CERN (European Organization for Nuclear Research),
desenvolveu um conjunto de ferramentas que formam a World Wide Web (WWW,
popularmente conhecida como web), que é a base da Internet conhecida hoje. Estas
ferramentas formam uma aplicação cliente/servidor e, no cliente, um programa
chamado browser ou navegador é responsável por requisitar as informações
solicitadas pelo usuário a um servidor. Ao servidor cabe a função de receber essa
requisição, processá-la e responder ao cliente solicitante. Além disso, servidores
podem ser clientes de outros servidores e cada servidor pode processar informações
de vários clientes (WINCKLER; PIMENTA, 2002, p. 10; SÁ, 2000, p. 12).
Como forma de amarrar essa comunicação entre clientes e servidores, Tim
Berners-Lee desenvolveu o protocolo HTTP (HyperText Transfer Protocol), a
linguagem de hipertexto1 HTML (HyperText Markup Language) e o sistema de
endereçamento URL (Uniform Resource Locator) (WINCKLER; PIMENTA, 2002, p.
10). HTTP é um protocolo de transferência de arquivos de hipertexto que trabalha
1 Hipertexto - é uma estrutura não linear de ligação de várias informações (textos, imagens),
possibilitando ao usuário seguir diferentes caminhos de leitura de documentos (SÁ, 2000, p. 87).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
21
sobre o protocolo TCP/IP2 e é responsável por efetuar a comunicação entre clientes
e servidores. O HTML é uma linguagem para a criação de documentos em formato
texto, baseado no encadeamento de elementos chamados tags, que são utilizados
para delimitar o escopo das partes estruturais do documento (parágrafos, imagens,
tabelas, dentre outros). URL é um método de endereçamento de objetos utilizado
para identificar o caminho até o objeto ou documento destino (SÁ, 2000, p. 14;
WINCKLER; PIMENTA, 2002, p. 11). A Figura 2 ilustra o funcionamento da
comunicação criada por Berners-Lee.
Figura 2 - Comunicação cliente/servidor utilizando o protocolo HTTP
Fonte: criado pelo autor.
A visão geral sobre o funcionamento da web apresentada nos parágrafos
anteriores é fundamental para o entendimento do funcionamento das aplicações
web. Conallen (2002, p. 22) define aplicação web como sendo um sistema dinâmico,
que permite ao seu utilizador modificar a lógica de negócio na camada do servidor,
ou seja, o cliente que antes era capaz apenas de requisitar documentos estáticos ao
servidor, com as aplicações web é capaz de solicitar informações que precisam ser
geradas dinamicamente. Segundo Pressman (2010, p. 379), esse tipo de aplicação
não fornece apenas funções de computação e conteúdo aos usuários, elas podem
ser interligadas ao banco de dados da empresa e alinhadas às suas regras de
negócio. Na Figura 3 é possível ver um exemplo genérico do processo de
comunicação quando existe uma aplicação web no servidor.
2 TCP/IP (Transmission Control Protocol/Internet Protocol) – conjunto de protocolos que permite a
computadores de diferentes tipos, tamanhos, fabricantes, com diferentes sistemas operacionais, comunicarem-se uns com os outros (STEVENS, 1994, p. 1).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
22
Figura 3 - Processo de comunicação cliente/servidor em uma aplicação web
Fonte: criado pelo autor.
Cabe salientar que o processo de comunicação ilustrado na Figura 3 não
exemplifica o funcionamento de todas as aplicações web. Muitas aplicações
dinâmicas podem não fazer uso de bases de dados, podem de maneira simplificada
processar as informações e devolvê-las ao cliente. Além disso, o exemplo utiliza o
protocolo HTTP, que é o principal protocolo utilizado na web, mas não o único
(GONÇALVES, 2007, p. 1).
2.1.3 Sistema operacional
Alguns autores (DEITEL; DEITEL; CHOFFNES, 2005, p.4, TANENBAUM,
2003, p. 1) definem Sistema Operacional (SO) como um software que habilita as
aplicações a interagir com o hardware do computador. Segundo os autores,
Sistemas Operacionais podem ser encontrados em telefones celulares, automóveis
e computadores. Em sua obra, Tanenbaum (2003, p. 3) explica que a grande
maioria dos usuários de computador já utilizou de alguma forma os recursos do
Sistema Operacional, mas não sabe reconhecê-lo.
Tanenbaum (2003, p. 1) afirma que os Sistemas Operacionais devem
“interfacear” os dispositivos de entrada e saída, tais como: monitor, teclado, mouse e
impressora. Além disso, o autor expõe que o gerenciamento de recursos de
hardware interno à máquina também devem ser gerenciados pelo sistema
operacional. Como exemplos desses recursos podem-se citar processadores,
memórias e discos rígidos. Por meio das definições apresentadas, é possível afirmar
que o Sistema Operacional é uma camada intermediária entre o hardware e as
aplicações (DEITEL; DEITEL; CHOFFNES, 2005, p. 4). Esta comunicação por meio
das camadas pode ser visualizada na Figura 4.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
23
Figura 4 - Comunicação intermediada pelo sistema operacional
Fonte: criado pelo autor.
Tanenbaum (2003, p. 13) apresenta vários tipos de Sistemas Operacionais e,
segundo suas definições, o que se enquadra no escopo deste trabalho é o SO para
servidores. Segundo o autor, SO para servidores caracterizam-se por atender
diversos usuários em uma rede de uma só vez, permitindo o compartilhamento de
hardware e software entre eles. O autor afirma que este tipo de SO é especializado
em fornecer serviços tais como: impressão, arquivos e web. Nemeth, Snyder e Hein
(2007, p. 296) afirmam que os Sistemas Operacionais mais utilizados em servidores
são o Microsoft Windows e o Linux. Segundo eles, o SO Linux tornou-se a
plataforma mais popular em servidores devido à sua flexibilidade, confiabilidade,
velocidade e baixo custo.
2.1.4 Sistema distribuído/Software distribuído
Segundo Shatz e Wang (1989, p. 1), um sistema distribuído é caracterizado
por um conjunto de computadores (nodos) que estão interconectados por meio de
uma rede de comunicação. Afirmam ainda ser comum, em arquiteturas distribuídas,
o compartilhamento de memória entre um grupo de computadores.
Segundo Coulouris, Dollimore e Kindberg (2007, p. 17), um sistema
distribuído é aquele no qual os componentes estão localizados em computadores
interligados por meio de uma rede de comunicação e gerenciam suas ações
somente por mensagens. Os autores afirmam ainda que esse tipo de sistema tem
como objetivo compartilhar recursos, os quais devem ser gerenciados por um
servidor e acessados por clientes.
Os conceitos sobre software distribuído apresentados nesta seção são
apenas para reforçar que o presente trabalho não possui vínculo com essa área da
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
24
ciência da computação. O presente trabalho aborda a distribuição do processo de
desenvolvimento de software, assunto este que é apresentado na seção 2.1.7.
2.1.5 Colaboração
A colaboração entre membros de uma equipe é um fator que pode produzir
melhores resultados do que cada membro trabalhando de forma individual (FUKS;
RAPOSO; GEROSA, 2002, p. 4). Segundo Fuks, Raposo e Gerosa (2002, p. 4), a
colaboração entre membros da equipe pode prover a complementação de
capacidades e conhecimentos individuais. Além disso, segundo os autores, a
colaboração pode minimizar inconsistências e falhas. Na medida em que o trabalho
é desenvolvido, os membros em colaboração podem trocar ideias e encontrar
soluções mais eficientes para a resolução de problemas.
Segundo Benbunan-Fich e Hiltz (1999, p. 415), trabalhar em grupo também
traz motivação para os membros da equipe. O trabalho de cada um é observado,
comentado e avaliado por pessoas da comunidade da qual ele faz parte. Além disso,
a colaboração permite que individualmente cada membro da equipe refine seus
conhecimentos e conceitos à medida que argumentam suas ideias com os demais.
2.1.5.1 Modelo de colaboração 3C
Fuks, Raposo e Gerosa (2003, p. 1) afirmam que, para colaborar, os
indivíduos precisam trocar informações (comunicação), organizar-se (coordenação)
e trabalhar em conjunto (cooperação). Segundo os autores, “as trocas ocorridas
durante a comunicação geram compromissos que são gerenciados pela
coordenação, que por sua vez organiza e dispõe as tarefas que são executadas na
cooperação”. A Figura 5, extraída de Gerosa et al. (2005, p. 2), apresenta o modelo
de colaboração 3C, que baseia-se na comunicação, coordenação e cooperação
entre os membros da equipe.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
25
Figura 5 - Modelo de colaboração 3C
Fonte: Gerosa et al. (2005, p. 2).
Os elementos apresentados na Figura 5 (comunicação, coordenação e
cooperação) estão interligados pela percepção. Uma breve explicação sobre cada
um destes elementos e suas inter-relações:
Comunicação: a comunicação necessária para desempenhar as
atividades no trabalho normalmente envolvem negociação e firmação
de compromissos. Esses compromissos transformam-se em ações a
serem executadas. Um indício de ruptura do canal de comunicação é a
discordância entre as intenções do emissor e as ações do receptor
para realizar os compromissos (FUKS; RAPOSO; GEROSA, 2003, p.
3);
Coordenação: para garantir o cumprimento dos compromissos gerados
pela comunicação é necessário coordenação. A coordenação tem
objetivo de organizar o grupo e articular as tarefas, a fim de evitar
retrabalho por tarefas repetidas ou conflitantes. Além disso, cabe à
coordenação a função de distribuir as tarefas, selecionar os
participantes que trabalharão em colaboração, análise das tarefas
realizadas e documentação do processo de colaboração (FUKS;
RAPOSO; GEROSA, 2003, p. 4);
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
26
Cooperação: “cooperação é a ação conjunta dos membros do grupo no
espaço compartilhado” (FUKS; RAPOSO; GEROSA, 2002, p.10). É
nesse espaço compartilhado que os membros da equipe interagem,
cooperam, manipulam e organizam informações gerando artefatos.
Pode-se dizer que esses artefatos são o produto da cooperação
(FUKS; RAPOSO; GEROSA, 2003, p. 5);
Percepção: segundo Fuks, Raposo e Gerosa (2002, p. 11), a
percepção é uma forma de adquirir informação por meio dos sentidos.
O ser humano é capaz de capturar informações por meio de gestos,
expressões faciais, ou seja, sem a necessidade de comunicar-se
diretamente com outras pessoas. Nesse sentido, a palavra percepção
apresentada na Figura 5 implica em fazer com que os membros do
grupo percebam as mudanças causadas ao ambiente pelas ações dos
participantes, de forma a reorganizarem suas atividades (FUKS;
RAPOSO; GEROSA, 2002, p. 11).
2.1.6 Software colaborativo (groupware)
Segundo Fuks, Raposo e Gerosa (2002, p. 4), software colaborativo ou
groupware é uma “tecnologia baseada em mídia digital que dá suporte às atividades
de pessoas organizadas em grupos que podem variar em tamanho, composição e
local de trabalho”. Esta definição pode ser traduzida como um software que
possibilite a colaboração, comunicação e cooperação entre os membros da equipe.
O software colaborativo é um modelo de software que mudou a forma como o
trabalho é visto nos escritórios (TOMMARELLO; DEEK, 2002, p. 2). Segundo
Nunamaker (1999, p. 67), o crescimento constante do teletrabalho e da utilização de
consultorias externas influencia na dispersão física dos membros das equipes de
trabalho em reuniões. Segundo o autor, a presença quase onipresente do acesso à
web acelerou ainda mais o processo de dispersão das equipes e, segundo ele, a
tendência é que cada vez mais as redes de comunicação e de trabalho, que antes
eram locais, migrem para redes de longa distância.
Apesar disso, Gerosa (2006, p. 16) afirma que na grande maioria das
empresas o suporte à colaboração limita-se ao armazenamento de arquivos e troca
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
27
de mensagens. Segundo o autor, a tecnologia de groupware ainda não atingiu seu
potencial máximo de utilização. A complexidade deste tipo de aplicação demanda
desenvolvedores qualificados capazes de trabalhar com protocolos, conexões,
compartilhamento de recursos, concorrência de acesso, distribuição, renderização,
gerenciamento de sessões, dentre outros. Gerosa (2006, p. 16) defende que essa
complexidade limita a criatividade dos desenvolvedores, que estão mais
preocupados em solucionar problemas de natureza técnica (baixo nível) do que
buscar novas soluções e fornecer o suporte necessário à colaboração.
Gerosa (2006, p. 18) sustenta a tese de que a utilização no modelo 3C de
colaboração no desenvolvimento de groupware proporciona os recursos necessários
para que o software desenvolvido evolua também no suporte à colaboração.
2.1.6.1 Requisitos de groupware
Gerosa (2006, p. 29) defende que não é possível especificar completamente
todos os requisitos para groupware e cita alguns autores que tentam, de forma
genérica, elencar uma série de requisitos que forneçam o ferramental necessário
para a colaboração. Apesar disso, entende que essa base de requisitos auxilia e
norteia o desenvolvimento deste tipo de aplicação.
Tietze (2001, p. 8) elencou uma série de requisitos e classificou-os em duas
categorias: requisitos de usuário e requisitos de desenvolvedor. Os requisitos de
usuário implicam diretamente em atividades que devem poder ser exercidas de
forma colaborativa pelo usuário final do sistema. Os requisitos de desenvolvedor
apresentam a estrutura de componentes que é necessária para o desenvolvimento
das atividades colaborativas. A lista de requisitos elaborada por Tietze e uma breve
explicação sobre cada um deles pode ser observada na Tabela 1 e na Tabela 2.
Tabela 1 - Requisitos de Usuário (RU)
ID Requisito Explicação
RU1 Acesso aos objetos compartilhados e às ferramentas de colaboração
Acesso a ferramentas que possibilitem a colaboração, acesso aos documentos compartilhados.
RU2 Orientação para a escolha da ferramenta a ser utilizada
A aplicação deve saber identificar a ferramenta correta para abrir os documentos compartilhados. Ex.: ao clicar sobre um documento no formato txt, o Sistema Operacional sabe que ele deve ser tratado por um editor de textos.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
28
ID Requisito Explicação
RU3 Prestação de consciência de grupo
Mostrar aos usuários que acessam a aplicação quem está on-line e disponível para colaboração. Também é necessário identificar os arquivos que estão sendo editados e por quem.
RU4 Suporte para colaboração síncrona e assíncrona
Fornecer ferramentas diversificadas de comunicação síncrona e assíncrona tais como: chat, fórum, mural de recados, mensagens de texto (e-mail), conferência por voz, videoconferência, dentre outros.
RU5 Acesso ubíquo ao ambiente de colaboração
O sistema deve poder ser acessado de diferentes pontos, restaurando o espaço de trabalho do usuário no local onde ele está acessando o sistema.
RU6 Fornecimento de espaço privativo e público e transição entre eles
A ferramenta deve proporcionar espaços de colaboração e espaços privados de edição. Um usuário deve poder escolher quando e o que compartilhar.
RU7 Extensões dinâmicas do ambiente de colaboração
Os usuários do sistema de colaboração que sentirem a necessidade de adicionar novas ferramentas para trabalhar devem poder fazê-lo sem a necessidade de reiniciar o sistema. As ferramentas adicionadas devem ser incorporadas ao sistema e devem ficar disponíveis para todos os usuários.
RU8 Acoplamento de ferramentas diferentes
Os usuários do sistema devem poder editar o mesmo arquivo com ferramentas diferentes. As alterações feitas em uma ferramenta devem ficar disponíveis automaticamente para o usuário que está utilizando a outra ferramenta.
RU9 Suporte para trabalho móvel A aplicação deve fornecer interface para dispositivos móveis como celulares, tablets
3 e
PDAs4. Essa interface deve ser uma versão enxuta
do sistema e precisa fornecer as funcionalidades básicas de colaboração.
RU10 Customização e combinação das ferramentas existentes
O sistema deve permitir que o usuário agrupe ferramentas e as disponibilize como um componente. Ao executar esse componente, as ferramentas nele contidas abrem e ficam disponíveis no formato em que foram configuradas pelo usuário.
RU11 Alto desempenho do sistema O sistema deve ter um baixo tempo de latência. As modificações feitas por um usuário devem ser replicadas instantaneamente para os demais. A natureza direta da interação entre os participantes exige resposta rápida do sistema.
Fonte: adaptado de Tietze (2001, p. 9-12).
Tabela 2 - Requisitos de Desenvolvedor (RD)
ID Requisito Explicação
RD1 Reutilização de conhecimento de Aproveitar o conhecimento e experiência dos novos
3 Tablet: dispositivo que pode ser usado para acesso à Internet, organização pessoal, visualização de
fotos, vídeos, leitura de livros, jornais e revistas e para entretenimento (BRUM, 2011, p. 10). 4 PDA (Personal Digital Assistant): dispositivo móvel considerado um computador de mão ou de bolso
(SILVA; SILVA; RABAIOLLI, 2012, p. 79).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
29
ID Requisito Explicação
programação existente e experiência
membros da equipe de desenvolvimento
RD2 Modelos de dados compartilhados e reutilizáveis
Os modelos de dados devem poder ser reutilizados e não devem ser reinventados a cada nova ferramenta desenvolvida. Isso facilita a comunicação entre as ferramentas já existentes e as que estão sendo desenvolvidas.
RD3 Compartilhamento transparente de dados
O ambiente de desenvolvimento deve prover recursos para o gerenciamento do acesso, alocação e compartilhamento das informações.
RD4 Suporte de dados locais e compartilhados
Os dados devem poder ser locais ou compartilhados. Cabe ao desenvolvedor decidir se compartilha ou não os dados.
RD5 Acesso a informações quando necessário
As informações sobre o funcionamento da colaboração em cada uma das ferramentas implementadas devem estar disponíveis sempre que necessário para os desenvolvedores. Essas informações são especialmente importantes para a manutenção do sistema.
RD6 Implantação de novos componentes
A implantação de novos componentes deve ser fácil e deve ocorrer para todos os utilizadores ao mesmo tempo, evitando assim problemas quando um usuário solicitar a colaboração de outro em uma ferramenta que não está disponível a todos.
RD7 Escalabilidade Conforme o número de usuários utilizando o sistema cresce, o desempenho da aplicação vai se degradando. É preciso documentar o número de usuários que cada ferramenta suporta e a quantidade de usuários que o sistema suporta.
RD8 Suporte para integração em sistemas externos
Ambientes de trabalho modernos frequentemente utilizam aplicações complexas e separadas. Os sistemas colaborativos devem permitir a integração entre estas ferramentas e facilitar a interoperabilidade.
RD9 Suporte a ferramentas no servidor
Sistemas colaborativos são melhor gerenciados caso haja um ambiente centralizado. Muitas vezes o sistema deve funcionar independente de o usuário estar ou não "logado". O acesso a recursos centralizados também é facilitado por este tipo de arquitetura.
Fonte: adaptado de Tietze (2001, p. 13-14).
2.1.7 Desenvolvimento distribuído de software (DDS)
Audy e Prikladnicki (2008, p. 43) afirmam que assim como as áreas de
negócios estão convergindo para globalização como diferencial estratégico, a área
de desenvolvimento de software também está transformando-se a fim de apropriar-
se dos benefícios trazidos pela globalização. Segundo eles, é cada vez mais custoso
e menos competitivo desenvolver software no mesmo espaço físico, organização ou
país. Para eles, o avanço da economia, a pressão por custos e a sofisticação dos
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
30
meios de comunicação têm incentivado o investimento maciço no desenvolvimento
distribuído de software. Acreditam ainda que as melhorias feitas nos últimos anos
nas ferramentas e métodos presentes na engenharia de software permitem que
grupos distribuídos formem equipes de trabalho em âmbito global (desenvolvimento
global de software - DGS), diminuindo custos e agregando qualidade ao processo de
desenvolvimento de software.
Prikladnicki (2002, p. 13) afirma que são três os atores envolvidos no DDS:
Equipe de desenvolvimento: são todas as pessoas envolvidas no
desenvolvimento de um determinado projeto. Essa equipe pode ser
formada por subequipes, cada qual responsável por uma parte do
projeto. Podem estar envolvidos na equipe ou subequipes os
responsáveis pela área de negócio, gerentes de projetos,
desenvolvedores, testadores, responsáveis pelo suporte da ferramenta,
dentre outros;
Cliente: é quem contrata o projeto de desenvolvimento de software,
podendo ser pessoa física ou jurídica;
Usuário: tem a função de fornecer informações (requisitos) para o
correto desenvolvimento do projeto e de utilizar o produto gerado. Em
alguns casos, cliente e usuário podem ser as mesmas pessoas, e,
neste caso, representam os dois papéis.
Para Prikladnicki e Audy (2006, p. 3), as características que diferenciam o
DDS do processo normal de desenvolvimento estão diretamente ligadas aos atores
envolvidos neste processo. Segundo eles, as características são: a dispersão
geográfica (distância física); a dispersão temporal (diferença de fuso-horário); as
diferenças culturais (idioma, tradições, normas, dentre outros).
2.1.7.1 Motivação para utilizar DDS
São vários os fatores que motivam as organizações a adotar o DDS. Em seu
trabalho, Lopes (2004, p. 30) apresenta um conjunto com as principais razões que
levam as empresas a adotar o DDS, esquematizadas na Figura 6.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
31
Figura 6 - Principais razões envolvidas no DDS
Fonte: Lopes (2004, p. 30).
Segundo Lopes (2004, p. 30), cada uma das razões pode ser definida
conforme:
Demanda e custos: nos últimos anos, a demanda por serviços superou
o número de recursos humanos capacitados na área de
desenvolvimento de software. Essa demanda impacta diretamente no
custo dos profissionais e faz com que as empresas precisem competir
por eles (LOPES, 2004, p. 31);
Time-to-market: para reduzir o tempo da colocação do produto no
mercado (time-to-market), empresas distribuem suas equipes de
desenvolvimento ao redor do globo. Desta forma, sempre haverá uma
equipe trabalhando, o que viabiliza o desenvolvimento do produto 24
horas por dia (ENAMI, 2006, p. 42);
Mercado e presença global: segundo Lopes (2004, p. 31), a diminuição
dos custos devido a incentivos econômicos e o aumento do poder
computacional geram um cenário favorável ao desenvolvimento de
software e uma grande demanda para este setor. Com isso, as
empresas buscam no DDS uma forma de aproximarem-se dos
consumidores e obter um diferencial competitivo, tornando-se global;
Rigor e experiência no desenvolvimento: as equipes centralizadas de
desenvolvimento tendem a utilizar técnicas informais e tendem a
descuidar tanto no uso de metodologias quanto na qualidade. Equipes
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
32
de DDS, por procurar a excelência em comunicação, tendem a
melhorar os processos relacionados à documentação (LOPES, 2004,
p. 32);
Sinergia cultural: segundo Audy e Prikladnicki (2008, p. 48), a
diversidade cultural amplia a criatividade e a inspiração nas
organizações que desenvolvem software. Uma equipe global é capaz
de encontrar novas formas de resolver problemas, projetar produtos e
pensar nos processos de desenvolvimento. Além de melhorar a
capacidade de aprendizado organizacional;
Escala: o difícil gerenciamento dos centros de desenvolvimento de
software é um fator que leva as empresas a adotarem o DDS. Equipes
menores estrategicamente localizadas são mais fáceis de serem
gerenciadas e coordenadas para atender as demandas (AUDY;
PRIKLADNICKI, 2008, p. 48) (LOPES, 2004, p. 31).
2.1.7.2 Níveis de dispersão em DDS
Audy e Prikladnicki (2008, p. 48) defendem que o nível de dispersão entre os
atores envolvidos no projeto (clientes, usuários e equipe de desenvolvimento) pode
facilitar a identificação das dificuldades encontradas no DDS. Segundo eles, os
problemas encontrados em uma dispersão local podem ser diferentes dos
encontrados quando a dispersão for global. Segundo Audy e Prikladnicki apud
Herbsleb et al. (2008, p. 61), “quando a distância entre colaboradores distribuídos
atinge 30 metros ou mais, a frequência de comunicação diminui para um nível
idêntico ao de colaboradores que estão distribuídos a milhares de metros”. Nesse
sentido, é importante compreender quais as implicações que cada nível de
dispersão pode ter na equipe.
Mesma localização física: é quando todos os atores estão fisicamente
no mesmo local e podem fazer reuniões sem dificuldade (ENAMI,
2006, p. 45). Não existe diferença de fuso horário e os obstáculos são
os existentes no desenvolvimento centralizado (AUDY;
PRIKLADNICKI, 2008, p. 48) (Figura 7 A);
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
33
Distância nacional: caracteriza-se por ter todos os atores dentro do
mesmo território nacional (ENAMI, 2006, p.45). As equipes podem
reunir-se em curtos espaços de tempo e a diferença de fuso horário
pode existir. Diferenças culturais podem ocorrer com maior frequência
(AUDY; PRIKLADNICKI, 2008, p. 49) (Figura 7 B);
Distância continental: caracteriza-se por ter os atores distribuídos em
diferentes países dentro do mesmo continente. Existe uma dificuldade
maior em conseguir reunir fisicamente o grupo para reuniões e o fuso
horário pode dificultar a comunicação e interação entre as equipes
(PRIKLADNICKI, 2003, p. 67) (Figura 7 C);
Distância global: os atores estão distribuídos em diversos países em
continentes distintos, formando, muitas vezes, uma distribuição global
(ENAMI, 2006 p. 45). Reuniões com a presença física dos participantes
passam a ser difíceis e normalmente ocorrem no início de novos
projetos (PRIKLADNICKI, 2003, p. 67). A diferença cultural passa a ser
um potencial problema e o fuso horário exerce um papel fundamental,
podendo impedir a interação entre as equipes (AUDY; PRIKLADNICKI,
2008, p. 49) (Figura 7 D).
Figura 7 - Níveis de dispersão em DDS
Fonte: adaptado de Audy e Prikladnicki (2008, p. 49).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
34
Prikladnicki (2003, p. 45) define ainda que a dispersão pode ser intra-atores,
na qual diferentes membros de um grupo de atores podem estar dispersos
geograficamente. Enami (2006, p. 45) afirma que os mesmos níveis de dispersão
existentes entre os atores podem ser aplicados na dispersão intra-atores.
2.1.8 Desenvolvimento colaborativo
Para Hildenbrand et al (2008, p. 526), o processo de colaboração no
desenvolvimento de software pode ser síncrono ou assíncrono. O processo síncrono
consiste em dois ou mais desenvolvedores compartilharem o mesmo espaço de
trabalho ou editando sincronamente o mesmo arquivo (edição
colaborativa/cooperativa). A colaboração assíncrona é feita por meio de sistemas de
controle de versões.
Segundo Hildenbrand et al (2008, p. 524), a metodologia para o
desenvolvimento de aplicações baseadas em processos colaborativos ainda é
negligenciada pelos pesquisadores. Para os autores, metodologias ágeis de
desenvolvimento como eXtreme Programing (XP), que é apresentada na seção
2.2.1.1, centradas em equipes de pequeno e médio porte, são a tendência e devem
ser tema de pesquisa.
2.1.9 Sistema
Silva (2001, p. 4) afirma que na sociedade em que vivemos utiliza-se muito o
termo sistema e que é comum ouvir as expressões: sistema respiratório, sistema
circulatório, sistema de navegação, sistema de folha de pagamento, contas a
receber, contabilidade e outros.
Para Silva (2001, p. 5), “sistema é um conjunto de partes que interagem
visando um objetivo específico e com alguma finalidade prática”. Segundo ele, os
sistemas construídos e administrados pelo homem possuem um objetivo específico,
que normalmente está explícito em seu próprio nome. Ele afirma ainda que um
sistema pode ser constituído de subsistemas e utiliza o corpo humano como
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
35
exemplo. Um sistema respiratório em conjunto com o sistema circulatório, digestivo,
nervoso, dentre outros, tem por objetivo manter uma pessoa viva.
Esta analogia feita com o corpo humano pode ser transportada para o mundo
empresarial. Segundo Audy, Andrade e Cidral (2005, p. 13), pode-se dizer que uma
empresa é um sistema formado por subsistemas, cada qual buscando objetivos
específicos, dos quais a soma de seus resultados visa alcançar o objetivo da
empresa.
Os conceitos apresentados sobre sistemas também podem ser migrados para
a área da informática. Sistema de pagamento de funcionários, sistema de contas a
pagar e receber e sistema financeiro são exemplos de sistemas que, em conjunto,
objetivam fornecer informações para o controle e gerenciamento de empresas
(SILVA, 2001, p. 5).
2.1.9.1 Ambiente do sistema
Segundo SILVA (2001, p. 8), o ambiente do sistema ou meio ambiente é um
conjunto de elementos que mesmo estando fora do sistema interage com ele e, por
vezes, são capazes de mudar seu comportamento. Audy, Andrade e Cidral (2005, p.
34) definem que o ambiente do sistema é algo sobre o qual o sistema não tem
controle e que os limites do sistema estão intimamente ligados ao seu ambiente. A
Figura 8 apresenta o relacionamento entre o sistema e o meio ambiente na visão de
Silva.
Figura 8 - Relacionamento do sistema com o meio ambiente
Fonte: Silva (2001, p. 8), adaptado pelo autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
36
2.1.9.2 Classificação do sistema
Para Audy, Andrade e Cidral (2005, p. 35), os sistemas podem ser
classificados quanto às suas diferenças e suas semelhanças. Segundo eles, os
sistemas podem ser classificados como:
Concretos x abstratos:
o Concreto: físico, formado por artefatos reais, objetos e
equipamentos;
o Abstratos: formado por símbolos ou objetos que expressam
pensamentos (teorias, modelos conceitos, dentre outros);
Naturais x artificiais:
o Naturais: sistemas que surgem de processos naturais, tais como
sistema solar, sistema ambiental (clima, solo);
o Artificiais: são sistemas projetados e construídos pelo homem;
Abertos x fechados:
o Abertos: são sistemas que interagem com o ambiente ao seu
redor trocando matéria, energia ou informação;
o Fechados: os sistemas fechados não sofrem influência e não
interagem com o ambiente;
Homem x máquina:
o Homem: são sistemas onde existe interação entre os seres
humanos, o sistema social é um exemplo deste tipo de sistema;
o Máquina: são sistemas em que a máquina tem papel de
processador, no qual é sempre o homem quem provê a entrada
inicial de dados e/ou informações.
Além disso, os autores defendem que os sistemas também podem ser
classificados quanto às suas propriedades. Para eles, as propriedades que um
sistema pode possuir são:
Adaptativo: o sistema se adapta ao ambiente pela troca de informações
entre eles;
Não-adaptativo: é quando o sistema não se adapta ao ambiente;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
37
Sinergia: é quando a soma das ações cooperativas dos agentes
independentes produz um resultado maior;
Entropia: a entropia mede o grau de desordem de um sistema. Está
diretamente ligada a sistemas administrativos e de informação.
2.1.9.3 Ciclo de vida do sistema
Audy, Andrade e Cidral (2005, p. 38) acreditam que o ciclo de vida de um
sistema está associado aos sistemas abertos “vivos”, já que interagem com o meio
ambiente trocando energia, material ou informação. Na visão dos autores, o ciclo de
vida do sistema é constituído de quatro fases: concepção, desenvolvimento, vida útil
e morte. A Figura 9 ilustra a visão dos autores sobre o ciclo de vida do sistema.
Figura 9 - Ciclo de vida do sistema
Fonte: Audy, Andrade e Cidral (2005, p. 39).
2.2 Metodologias de desenvolvimento
Na literatura existem várias metodologias que definem como deve ser o
processo de desenvolvimento de software. Esta seção apresenta algumas das
metodologias consideradas tradicionais e outras, ágeis.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
38
2.2.1 Metodologias tradicionais ou pesadas
Metodologias de desenvolvimento tradicionais ou pesadas são metodologias
que possuem o foco na documentação (SOARES, 2004, p. 2). Segundo Soares
(2004, p. 2), estas metodologias foram criadas em uma época em que o
desenvolvimento de software era diferente do que o presenciado hoje. Segundo o
autor, as metodologias foram criadas baseadas apenas em mainframes5 e terminais
burros6 e, na época, o custo de fazer alterações e correções era muito alto. O autor
afirma que nessa época o acesso a computadores era limitado e que não existiam
ferramentas de apoio ao desenvolvimento de software. Em virtude disso, o software
precisava ser planejado e documentado antes de ser implementado. Segundo o
autor, a principal metodologia de desenvolvimento continua sendo, ainda hoje, o
modelo clássico (em cascata).
2.2.1.1 Modelo em cascata
O modelo de desenvolvimento em cascata que, segundo Pressmann (2010, p.
39), pode ser chamado de ciclo de vida clássico, é uma abordagem sistemática e
sequencial. Pressmann (2010, p. 39) aponta que no modelo em cascata o
desenvolvimento do software segue as fases de comunicação, planejamento,
modelagem, construção e implantação, que podem ser visualizadas na Figura 10.
Segundo o autor, esse modelo de desenvolvimento de software é o mais
antigo da Engenharia de Software e apresenta uma série de problemas quando é
aplicado. Pressmann afirma que em projetos reais raramente é seguido o fluxo
sequencial proposto no modelo e isso pode gerar confusão à medida que os
projetistas trabalham. Outro ponto apontado por Pressmann é que, para o cliente, é
difícil elencar todos os requisitos explicitamente no início do projeto e a alteração ou
até mesmo adição de requisitos não é algo simples neste modelo.
5 Mainframes: computador de grande porte utilizado para processamento de grande volume de
informações. O termo mainframe refere-se ao gabinete que aloja a unidade central de processamento nos primeiros computadores (CRUZ; FLORES; GARCIA, 2011, p. 94). 6 Terminais burros: dispositivos de entrada e saída que foram criados para facilitar a interação com os
mainframes. O termo terminais burros é devido ao fato de não haver processamento nesta estação (CESAR; FARIAS, 2007, p. 7).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
39
Figura 10 - Ciclo de vida clássico no modelo cascata
Fonte: Pressmann (2010, p. 39).
2.2.1.2 Modelo RAD (Rapid Application Development)
Sommerville (2007, p. 268) elucida que o modelo RAD – Desenvolvimento
Rápido de Aplicações – surgiu das linguagens de programação de quarta geração
em 1980 e é uma metodologia utilizada para o desenvolvimento de aplicações
orientadas a dados. O autor explica que o ambiente de trabalho nesse modelo é um
conjunto de ferramentas que permite que os dados possam ser criados, pesquisados
e exibidos em relatórios. A Figura 11 extraída da obra de Sommerville ilustra a
organização do sistema RAD.
Figura 11 - Organização do sistema RAD
Fonte: Sommerville (2007, p. 268).
Pressmann (2010, p. 41) afirma que este é um modelo no qual o software é
produzido de forma incremental e trabalha com um ciclo de desenvolvimento curto.
Segundo o autor, o modelo RAD é uma adaptação do modelo em cascata que
possibilita o desenvolvimento rápido baseado na construção de componentes. O
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
40
autor afirma que esse modelo é capaz de fazer a equipe de desenvolvimento
entregar um sistema plenamente funcional em um curto espaço de tempo.
Segundo Sommerville (2007, p. 268), as ferramentas incluídas no ambiente
RAD são:
Linguagem de programação de banco de dados: possibilita a
manipulação de banco de dados. Exemplo: SQL;
Gerador de interface: utilizado para criar formulários;
Links: criação de atalhos para aplicações de manipulação de dados
como planilhas e editores de texto;
Gerador de relatórios: utilizados para criar e alterar relatórios baseados
em informações do banco de dados.
Pressmann (2010, p. 42) afirma que, como todos os modelos de
desenvolvimento de software, o RAD também possui problemas. Segundo o autor,
caso o projeto seja grande, o número de desenvolvedores precisará acompanhar o
tamanho do projeto para que o tempo de desenvolvimento continue sendo rápido.
Outro problema apresentado é a modularização errada dos componentes do
sistema. Isso pode fazer com que a construção dos componentes seja problemática
e leve mais tempo do que o planejado. Pressmann salienta ainda que, caso a
aplicação necessitar de alto desempenho, e a busca por esse desempenho implicar
em adaptações de interface, o modelo RAD pode não funcionar.
2.2.1.3 Modelo espiral
O modelo espiral, segundo Pressmann (2010, p. 44), é um modelo que
combina a utilização de protótipos com aspectos controlados e sistêmicos do modelo
em cascata. Segundo o autor, a utilização desse modelo é capaz de fornecer
versões cada vez mais rápidas e completas.
Nesse modelo, o software é construído evolutivamente. No início do projeto
as versões podem ser em modelos no papel ou protótipos e, perto da finalização do
processo de desenvolvimento, as versões vão ficando cada vez mais completas
(PRESSMANN, 2010, p. 44). Segundo Pressmann (2010, p. 45), o processo
evolutivo também segue as mesmas atividades do modelo em cascata, mas a
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
41
interação entre as atividades é em espiral. O modelo pode ser visualizado na Figura
12.
Pressmann (2010, p. 45) salienta que, ao utilizar este modelo de
desenvolvimento, o gerenciamento de riscos deve ser acompanhado de perto. Para
o autor, caso os riscos não sejam bem gerenciados, problemas fatalmente
aparecerão. Além disso, Pressmann (2010, p. 45) afirma que este modelo pode ser
de difícil aceitação por parte dos clientes, uma vez que a abordagem evolucionária
proposta por este modelo exige competência considerável na avaliação dos riscos, à
qual o sucesso do projeto está diretamente ligado.
Figura 12 - Ciclo de vida do desenvolvimento de software no modelo espiral
Fonte: Pressmann (2010, p. 45).
2.2.2 Metodologias ágeis
Segundo Gonçalves e Filho (2008, p. 148), as metodologias ágeis tornaram-
se populares quando um grupo de pesquisadores consolidou, em um momento de
troca de experiências, os valores que achavam ser importantes para atribuir
agilidade ao processo de desenvolvimento. Estes valores, que representam um
consenso entre os membros do grupo, foram descritos em um documento chamado
de “Manifesto Ágil”. Os valores descritos no manifesto, de modo geral, são:
Indivíduos e interações são mais importantes do que processos e
ferramentas;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
42
Software funcionando é mais importante que uma documentação
extensa;
O relacionamento com o cliente é mais importante que a negociação
do Contrato;
Responder às mudanças é mais importante que seguir o planejamento.
O processo ágil de desenvolvimento de software visa atender três
suposições-chave que são iguais para a maioria dos projetos de software
(PRESSMANN, 2010, p. 60). São elas:
1. Dificuldade em prever quais requisitos irão persistir e quais serão
modificados. Dificuldade em prever a mudança de prioridade dos
clientes ao longo do projeto;
2. Em alguns tipos de software, o projeto e a construção caminham
juntos. É difícil prever quanto de projeto deve haver antes do processo
de construção iniciar;
3. Análise, projeto, construção e testes não são tão previsíveis do ponto
de vista do planejamento.
Com base nas suposições, Pressmann (2010, p. 61) questiona: como criar um
processo que possa gerenciar a imprevisibilidade? Segundo o autor, a resposta está
na adaptação do processo. Os processos devem ser ágeis e as mudanças não
devem representar dor de cabeça para projetistas e desenvolvedores.
Pressmann (2010, p.62) afirma que existem muitos defensores tanto da
utilização de metodologias ágeis quanto das metodologias tradicionais. O autor
defende que a decisão deve sempre ser tomada levando em consideração fatos e
não crenças. Expõe ainda que nenhum dos modelos é contra a agilidade, mas
questiona qual o melhor modo de alcançar a agilidade. Pressmann defende que não
se deve optar entre a agilidade e a engenharia de software tradicional, deve-se
definir uma abordagem de engenharia de software que seja ágil.
2.2.2.1 eXtreme Programming
Sommerville (2007, p. 264) apresenta que todos os requisitos de software na
eXtreme Programming (XP) são expressos por histórias do usuário. Nessas histórias
são apresentadas todas as tarefas que o usuário desempenha relativas ao requisito.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
43
O autor explica ainda que o processo de codificação é feito em pares e que os casos
de teste devem ser feitos antes da implementação.
Pressmann (2010, p. 63) descreve a XP como uma abordagem que usa a
orientação a objetos como paradigma de desenvolvimento. Pressmann expõe ainda
que a XP é baseada em uma série de regras e práticas que ocorrem no
planejamento, projeto, codificação e testes. A Figura 13 apresenta as ideias e as
tarefas-chave do XP.
Figura 13 - Desenvolvimento utilizando XP
Fonte: Pressmann (2010, p. 64).
Audy e Prikladnicki (2008, p. 25) descrevem que a visão da XP é “entregar o
software que o cliente desejar quando ele desejar”. Segundo os autores, a XP é
baseada em quatro fatores:
Comunicação: a comunicação deve ser contínua entre cliente e equipe
de desenvolvimento, assim, o cliente está sempre acompanhando o
processo de desenvolvimento. Além disso, o cliente decide o que deve
ser construído e a ordem em que isso deve ocorrer;
Simplicidade: o menor número possível de artefatos deve ser
construído. Organizar o código para contemplar um possível novo
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
44
requisito é secundário. Além disso, o software é sempre liberado em
pequenas versões;
Feedback (melhorias): o usuário está continuamente testando,
validando e sugerindo melhorias do que está sendo e o que já foi
construído;
Coragem: significa fazer tudo corretamente mesmo que não seja a
tarefa mais sensata a ser feita. Os desenvolvedores devem ser
honestos, sabendo o que pode e o que não pode ser feito.
2.2.2.2 Scrum
O Scrum é uma metodologia de desenvolvimento que visa fornecer um
processo conveniente para o projeto e desenvolvimento Orientado a Objetos
(SOARES, 2004, p. 5). Para Soares (2004, p. 5), o Scrum apresenta ideias da teoria
de controle de processos industriais no desenvolvimento de software. Esta
metodologia tem como foco guiar o trabalho dos membros da equipe para que
produzam um software mais flexível em um ambiente em constante mudança.
Segundo Pressmann (2010, p. 69), os princípios do Scrum são:
Pequenas equipes: pequenas equipes de trabalho buscando maximizar
a comunicação e o conhecimento, além de minimizar a supervisão;
Processo adaptável: de forma a produzir o melhor produto, o processo
e o negócio devem ser facilmente adaptáveis;
Desenvolvimento incremental: o software é produzido de forma
incremental e pode ser documentado e testado sempre que
necessário;
Divisão de trabalho: o trabalho de codificação é dividido em equipes
que podem ser “em partições claras, de baixo acoplamento, ou em
pacotes”;
Testes e documentação: os testes e a documentação são construídos
juntamente com o processo de desenvolvimento;
Habilidade de declarar o produto pronto: o desenvolvimento do
software pode ser declarado como pronto sempre que for necessário.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
45
Exemplo: o cliente pode precisar de dinheiro; o cliente precisa das
funções; data prevista para o término.
Para Pressmann (2010, p. 69), as atividades fundamentais do Scrum são:
requisitos, análise, projeto, evolução e entrega. Segundo o autor, cada atividade
desenvolvida dentro do padrão Scrum é chamada Sprint. A quantidade de Sprints
necessários para a conclusão de uma atividade varia de acordo com a sua
complexidade e pode ser atualizado em tempo real pela equipe de trabalho
(PRESSMANN, 2010, p. 69). O fluxo de trabalho do Scrum pode ser visualizado na
Figura 14.
Figura 14 - Fluxo de trabalho no modelo Scrum
Fonte: Pressmann (2010, p. 70).
O fluxo de trabalho apresentado na Figura 14 apresenta os quatro elementos
pertencentes ao processo de desenvolvimento na metodologia Scrum: pendência,
Sprints, reuniões Scrum e demos (PRESSMANN, 2010, p. 70).
Pendência: a pendência é uma lista de requisitos ou características do
projeto. A lista está sempre aberta para modificações, seja para
adicionar ou remover requisitos. O gerente do projeto avalia e
reorganiza as prioridades sempre que for necessário;
Sprints: são unidades de trabalho com tempo predefinido para
satisfazer a um requisito ou pendência. Durante o processo de
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
46
desenvolvimento, os requisitos ou pendências referentes ao Sprint não
podem ser modificados. Uma característica dos Sprints é o curto prazo
de duração, normalmente 30 dias;
Reuniões Scrum: são reuniões rápidas (15 minutos) e diárias onde
cada membro da equipe responde a:
o O que você fez desde a última reunião da equipe?
o Que obstáculos você está encontrando?
o O que você planeja realizar até a próxima reunião da equipe?
Demos: entrega de forma incremental o software ao cliente,
possibilitando a demonstração e validação por parte do cliente.
2.2.2.3 FDD (Feature Driven Development)
O FFD – Desenvolvimento Guiado a Características – é uma abordagem que
procura abranger as principais vantagens de outras abordagens ágeis, que podem
ser utilizadas em projetos grandes. O FFD é caracterizado pela ênfase em qualidade
e monitoramento do progresso do desenvolvimento (GONÇALVES; FILHO, 2008, p.
151).
Segundo Pressmann (2010, p. 71), uma característica é uma função que o
cliente deseja e que pode ser implementada em uma ou duas semanas. Para o
autor, a ênfase na definição das características traz benefícios como: pequenos
blocos de funcionalidade passíveis de entrega facilitando a descrição e o
entendimento por parte do usuário; organizar as características hierarquicamente de
acordo com o negócio; desenvolvimento de características operacionais a cada duas
semanas; documentação de projeto e de código mais fáceis de inspecionar;
planejamento, cronograma e monitoramento guiado pela hierarquia de
características ao invés de tarefas.
Pressmann (2010, p. 71) apresenta um modelo de definição de característica
que foi sugerido por Coad, Lefebvre e DeLuca (1999, p. 184), criadores do FFD.
Esse modelo, que pode ser visualizado na Figura 15, traz como elementos a ação, o
resultado, o tipo de interação e o objeto. O objeto neste modelo pode ser uma
pessoa, lugar ou coisa (papéis, momentos no tempo, dentre outros). A seguir estão
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
47
alguns exemplos de características montados por Pressman pelo modelo sugerido
por Coad, Lefebvre e DeLuca:
Adiciona um produto a um carrinho de compras;
Exibe as especificações técnicas do produto;
Armazena as informações de remessa para um cliente.
Figura 15 - Modelo de definição de característica
Fonte: adaptado de Pressmann (2010, p. 71).
2.3 Recursos para o desenvolvimento distribuído e colaborativo
Nesta seção são apresentadas as definições dos principais recursos
computacionais necessários para o desenvolvimento distribuído e colaborativo de
software.
2.3.1 Versionamento
Segundo Oliveira (2005, p. 7), a mudança está presente em todas as fases do
ciclo de vida do software, seja na mudança de um requisito, na adição de novos
elementos ou na correção de bugs7. Segundo o autor, o controle de versões é
essencial para que estas modificações não representem um problema.
Para Murta (2004, p. 49), são muitos os artefatos de software que precisam
de mecanismos de controle de versão, podendo citar como exemplo o código-fonte
da aplicação, modelos de componentes, descritores de implementação, esquemas
de banco de dados, dentre outros. Ferramentas como CVS (Concurrent Versions
System), Subversion e GIT (Global Information Tracker) são exemplos de softwares
capazes de fazer esse controle de versões.
7 Bug: termo utilizado como sinônimo de defeito de software (REIS, 2002, p. 356).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
48
2.3.2 Servidor web
Segundo Teixeira (2004, p. 27), um servidor web é um processo que fica
permanentemente aguardando por solicitações de clientes. O autor explica que
quando uma requisição é recebida, o servidor interpreta, verifica se ela é válida e,
caso seja, encaminha o objeto HTML solicitado pelo cliente. Teixeira observa que
este documento HTML pode ser um arquivo estático que está armazenado em um
diretório ou um documento gerado dinamicamente por um programa ou script8
invocado pelo servidor.
Para Morimoto (2011, p. 347), os servidores web são a espinha dorsal da
Internet, são eles que hospedam todas as páginas e servem como base para todo o
tipo de aplicativo web. Segundo Morimoto, a tendência é que cada vez mais as
páginas web dinâmicas e aplicativos via web substituam os aplicativos desktop.
Alguns autores como Teixeira (2000, p. 35) e Marcelo (2005, p. 3) afirmam
que o servidor web mais utilizado no mundo é o Apache. O Apache é um servidor
web de código livre que trabalha com o protocolo HTTP e possui versão para
diversos Sistemas Operacionais. Para Teixeira (2000, p. 35), os fatores que fazem
com que o Apache seja largamente utilizado são:
Excelente performance;
Alto nível de personalização;
Confiabilidade;
Portabilidade;
Vasta documentação disponível;
Baixo custo.
Segundo Nemeth, Snyder e Hein (2007, p. 496), a complexidade das
tecnologias web parecem estar dobrando a cada ano. Apesar disso, essa
complexidade fica na camada programador/designer, e não nos softwares de
gerenciamento web. Para os autores, a grande maioria dos problemas dos softwares
de servidores web foi eliminada, tornando-os serviços seguros e confiáveis. Os
autores ainda destacam que a forma como hospedamos as informações nos
servidores não mudou muito nas últimas décadas.
8 Script: script é um arquivo que armazena uma sequência de comandos que podem ser executados
sempre que necessário (JARGAS, 2008, p. 24).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
49
2.3.3 Linguagens de programação web
Páginas dinâmicas utilizam lógica de programação no lado do servidor.
Quando uma página realiza uma requisição ao servidor, este repassa essa
solicitação a um programa que processa o pedido e retorna as informações
solicitadas (JÚNIOR, 2005, p. 4). Essa lógica é desenvolvida utilizando linguagens
de programação web, tais como PHP, C#, Java, dentre outras.
Essas linguagens de programação consistem em linguagens que executam
no lado do servidor, disponibilizando serviços dinâmicos aos usuários. Segundo
Júnior (2005, p. 5), com essa tecnologia é possível ler e gravar arquivos no servidor,
ler e gravar informações em banco de dados, executar regras de negócio, efetuar
comunicação com outros servidores, fazer processamento de imagens, dentre
outras funcionalidades.
Existem ainda linguagens de programação web que são interpretadas e
executadas no navegador do cliente, como é o caso do JavaScript. Com essa
linguagem é possível distribuir conteúdo executável na forma de scripts pela Internet
(FLANAGAN, 2002, p. 23). Segundo Flanagan (2002, p. 1), o JavaScript pode
dinamizar a interação com a página HTML, sendo possível incluir programas que
interagem com o usuário e controlam o navegador.
2.3.4 Servidor de correio eletrônico
Um servidor de correio eletrônico, mundialmente conhecido como e-mail, é
um serviço de troca de mensagens entre caixas postais eletrônicas de usuários
(SOUZA; 2006, p. 20). Seu funcionamento consiste em trocar mensagens entre
usuários utilizando o nome de usuário, seguido por @, e o endereço do servidor
como endereço.
Segundo Ball e Duff (2004, p. 459), o funcionamento por trás dos servidores
de e-mail é complexo. Segundo os autores, os servidores utilizam protocolos de
comunicação (POP, IMAP, SMTP) para fazer a comunicação entre servidores, além
disso, é necessário haver um emissor/receptor de mensagens denominado MTA
(Mail Transfer Agent) e um cliente de correio chamado MUA (Mail User Agent), que
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
50
faz a intermediação do usuário com o MTA. A Figura 16 apresenta o funcionamento
básico do processo de envio de e-mails.
Figura 16 - Exemplo de funcionamento de um servidor de correio eletrônico
Fonte: Souza (2006, p. 25).
2.3.5 Edição colaborativa – escrita de código
Segundo Gärtner (2011, p. 48), a atividade de desenvolvimento de software
raramente é solitária. Segundo o autor, os membros da equipe olham o código uns
dos outros buscando erros, padronizando códigos e buscando soluções para
correção de bugs. Essa cooperação entre os membros da equipe deve ser
explorada mesmo quando os membros estiverem dispersos fisicamente. Nesse
sentido, softwares colaborativos ou groupwares, apresentados na seção 2.1.6,
podem ser utilizados na descentralização do desenvolvimento de software (seção
2.1.7) sem perder o cooperativismo dos membros da equipe (TOMMARELLO;
DEEK, 2002, p. 2).
Uma pesquisa feita pela revista americana Software Development Magazine
em 2004 e posteriormente publicada por Carmel e Tjia (2005, p. 14) revelou que os
processos do desenvolvimento de software que mais são terceirizados são a
codificação, seguido por testes e manutenção. O gráfico apresentado por Carmel e
Tjia pode ser visto na Figura 17.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
51
Figura 17 - Terceirização no ciclo de vida do software
Fonte: adaptado e traduzido de Carmel e Tjia (2005, p.14).
No desenvolvimento distribuído de software, a edição colaborativa no
processo de codificação possui um papel fundamental tanto na otimização e
padronização quanto na qualidade do código (GÄRTNER, 2011, p. 48). Gärtner
(2011, p. 48) destaca que é importante a análise e revisão do código em tempo real.
2.3.6 Comunicação
Segundo Gärtner (2011, p. 49), em um processo de desenvolvimento
distribuído de software, a comunicação é um ponto crucial. O autor defende que uma
comunicação ineficiente pode reduzir significativamente o progresso do projeto.
Audy e Prikladnicki (2008, p. 80) afirmam que diferentes culturas e o estilo de
comunicação de cada membro da equipe podem influenciar negativamente no
processo de comunicação. Segundo os autores, a comunicação deve ser clara e
objetiva a fim de minimizar os problemas de comunicação.
Em equipes locais, a proximidade dos membros da equipe permite que
decisões sejam tomadas após uma pequena conversa no corredor ou café, o que
não é possível em equipes distribuídas (GÄRTNER, 2011, p. 49). Na Figura 18,
Carmel e Tjia (2005, p. 168) apresentam uma lista de tecnologias utilizadas em
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
52
sistemas colaborativos. Segundo os autores, a combinação destas ferramentas
permite uma colaboração eficaz.
Figura 18 - Tecnologias colaborativas
Fonte: adaptado e traduzido de Carmel e Tjia (2005, p.165).
Carmel e Tjia (2005, p. 168) defendem que deve existir uma sobreposição de
tempo nos turnos de trabalhado das equipes distribuídas para que a comunicação
seja feita de forma síncrona. Caso um grupo de desenvolvedores localizados nos
Estados Unidos quiser comunicar-se com uma equipe de desenvolvimento que está
na Europa e não houver uma janela de tempo em que estes grupos trabalhem
simultaneamente nos dois locais, a comunicação terá que ser feita por meio de
ferramentas assíncronas. Caso um dos grupos necessitar repassar informações ao
outro, terá que esperar até o outro dia para receber a confirmação ou sanar as
dúvidas que podem surgir. Esse processo seria muito mais rápido caso a
comunicação fosse realizada de forma síncrona. Segundo Carmel e Tjia (2005, p.
162), a comunicação síncrona diminui o tempo de resposta e permite que pequenos
problemas de comunicação não tomem um tempo desnecessário das equipes.
2.3.6.1 Comunicação síncrona
A comunicação síncrona promove uma série de benefícios às equipes
distribuídas. A seguir estão listadas algumas ferramentas de comunicação síncrona
com uma breve explicação sobre elas:
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
53
Audioconferência: esse tipo de ferramenta permite a conversação por
voz entre os membros da equipe. A comunicação pode ser de sentido
único, o que facilita a coordenação dos usuários (BRITO; PEREIRA,
2004, p. 5);
Videoconferência: permite a conversação por meio de chamadas de
vídeo entre dois ou mais membros de um grupo. Este tipo de
ferramenta permite que os interlocutores mostrem objetos, interajam
por meio de gestos ou expressões faciais (FUKS; GEROSA;
PIMENTEL, 2003, p. 17);
Bate-papo: ferramenta pela qual os membros de um grupo podem
trocar mensagens instantâneas e visualizar a lista de membros on-line
(BRITO; PEREIRA, 2004, p. 4).
2.3.6.2 Comunicação assíncrona
Ferramentas de comunicação assíncronas também são importantes para
equipes distribuídas. Abaixo estão listadas algumas ferramentas de comunicação
assíncronas e uma breve descrição sobre elas:
Correio eletrônico: ferramenta pela qual é possível trocar mensagens
de texto ou hipertexto e trocar arquivos (FUKS; GEROSA; PIMENTEL,
2003, p. 11);
Fórum: ferramenta de comunicação estruturada. Ao responder
mensagens de um fórum a resposta fica deslocada à direita, sendo
assim possível identificar as interações dos usuários (FUKS; GEROSA;
PIMENTEL, 2003, p. 11).
2.3.7 Gerenciamento de atividades
O gerenciamento de atividades em uma equipe distribuída é de fundamental
importância. Em equipes locais, é possível gerenciar por meio de observação. O
gerente de projetos ou analista responsável circula dentro da equipe ou faz reuniões
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
54
informais para manter a equipe alinhada. No DDS isso não é possível, o que torna
necessária a utilização de ferramentas que possibilitem esse gerenciamento (AUDY;
PRIKLADNICKI, 2008, p. 71).
Para um bom gerenciamento das atividades é necessário definir quem é o
responsável pela execução de cada tarefa, a data em que cada tarefa deve ser
iniciada e as datas em que devem ser entregues (VARGAS, 2007, p.66-67). De
posse dessas informações, o gerente de projetos pode estabelecer um cronograma
de atividades e manter sua equipe alinhada. Além disso, esse gerenciamento de
atividades permite ao gestor saber o percentual de conclusão do projeto e verificar
se o projeto está ou não atrasado.
Existem diversas ferramentas que auxiliam no gerenciamento de atividades.
Uma característica em comum é a possibilidade de acompanhar as tarefas por um
gráfico de Gantt (Figura 19). O gráfico de Gantt é uma representação gráfica de
cronogramas. O diagrama lista as atividades e mostra por barras horizontais o
cronograma das atividades em uma linha de tempo (VARGAS, 2007, p. 67).
Figura 19 - Gráfico de Gantt
Fonte: Vargas (2007, p. 67).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
55
3 TRABALHOS RELACIONADOS
Nas próximas seções são apresentadas algumas das ferramentas existentes
que de alguma forma estão relacionadas com este trabalho. Os materiais
encontrados foram obtidos por busca realizada pelo autor na Internet, já outras, em
Dissertações voltadas ao Desenvolvimento Distribuído de Software.
Ao final, é apresentada a análise comparativa entre todas as ferramentas
exploradas. Essa análise tem como objetivo demonstrar que cada aplicação atua em
uma determinada área do processo de desenvolvimento de software e que sozinhas
não conseguem atender a todas as demandas relacionadas a esse processo.
3.1 CloudForge
A ferramenta CloudForge é um serviço de gerenciamento de projetos e
desenvolvimento de software de forma distribuída. Para utilizar a ferramenta é
necessário acessar o site da empresa desenvolvedora e efetuar o cadastro. O login
e senha registrados fornecem acesso a apenas algumas funcionalidades, pois trata-
se de uma ferramenta que necessita de licenciamento. Esse cadastro preliminar
garante acesso por 30 dias e, após, é necessário optar por algum dos planos
disponíveis no site. Na Figura 20 é apresentada a página inicial do sistema.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
56
Figura 20 - Página inicial da ferramenta CloudForge
Fonte: figura obtida pelo autor.
É possível criar um novo projeto e escolher os serviços (ferramentas) que
estarão disponíveis para os membros do projeto. Esses serviços são na verdade
integrações feitas com softwares e serviços de diretórios disponíveis na web. Dentre
as ferramentas disponíveis pode-se citar Git, CSV e Subversion, que são softwares
de versionamento e têm seu funcionamento explicado na seção 2.3.1.
O CloudForge não oferece uma IDE de desenvolvimento. Para esta atividade,
os desenvolvedores devem possuir IDEs instaladas em um computador e configurá-
las para trabalhar com alguma das ferramentas de versionamento disponíveis para o
projeto. Além disso, é preciso realizar o download ou atualizar todo o código-fonte da
aplicação antes de começar a trabalhar.
Seu foco principal está no gerenciamento e versionamento de documentos. O
CloudForge possui uma interface de compartilhamento de documentos que permite
aos membros do projeto compartilhar arquivos, acompanhar versões e, em alguns
casos, visualizar as diferenças entre versões.
Em seu painel de gerenciamento (dashboard) é possível visualizar diversas
informações estatísticas do projeto tais como número de commits, usuários que mais
commits realizaram e espaço em disco utilizado. Estas informações são extraídas
das ferramentas escolhidas para compor o projeto.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
57
3.2 Kodingen
O Kodingen é um ambiente de desenvolvimento que pode ser acessado
diretamente pelo navegador. Seu principal objetivo é fornecer, dentro do navegador,
uma gama de ferramentas capaz de suprir todas as necessidades de um
desenvolvedor web. Com ele é possível criar novos projetos ou importá-los de
repositórios SVN e FTP.
Sua interface assemelha-se a de uma IDE de desenvolvimento convencional.
O menu lateral em forma de árvore possibilita a navegação pelos arquivos e
diretórios do projeto. Para começar a editar um arquivo é necessário dar um duplo
clique sobre seu nome. Em seguida, o código-fonte do arquivo selecionado aparece
na parte central do sistema (Figura 21), permitindo sua visualização e edição.
Enquanto o desenvolvedor escreve o código-fonte, o sistema analisa a sintaxe do
código e destaca elementos como variáveis e funções com cores, o que facilita a
visualização por parte dos desenvolvedores.
Figura 21 - Interface de edição de código-fonte do Kodingen
Fonte: criado pelo autor.
Uma das características do Kodingen é o armazenamento centralizado dos
arquivos de código-fonte dentro de seu repositório. Essa característica, em conjunto
com o sistema de DNS baseado no login do usuário, permite ao sistema
disponibilizar ao desenvolvedor uma interface de testes da aplicação. Essa função
está disponível por intermédio de um endereço eletrônico ou pelo botão preview.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
58
A IDE possui uma interface para a criação e gerenciamento de banco de
dados. Após selecionar um dos bancos de dados disponíveis, é necessário
preencher um formulário com os dados de conexão ou criar uma base de dados
nova. Nessa última opção, o desenvolvedor tem disponível para escolha os bancos
de dados PostgreSQL, Mysql e NoSql.
O Kodingen também permite a edição de imagens. O editor possui várias
funções de edição simples, mas em grande quantidade. Apesar de aparecer
integrado ao sistema, esse editor é uma ferramenta gratuita disponível na web e
pode ser acessada separadamente da plataforma de desenvolvimento.
Em sua versão de demonstração, o sistema exige autenticação a todo
momento e poucas funcionalidades podem ser exploradas. Ao buscar formas de
registro percebe-se que o software não está aceitando novos cadastros. Uma versão
beta está em testes, mas para acessá-la é necessário possuir um convite. O código-
fonte da aplicação não está disponível para download e não foram encontrados
dados referentes ao seu licenciamento.
3.3 IdDE9
Gärtner (2011) idealizou e implementou uma ferramenta chamada IdDE. Essa
ferramenta tem como objetivo diminuir os problemas relacionados ao
desenvolvimento distribuído de software. Para tanto, Gärtner optou por criar um
plugin para a IDE Netbeans que agregasse as funcionalidades de chat, conversação
por áudio e desenvolvimento colaborativo. A Figura 22 destaca a ferramenta IdDE
na interface do NetBeans.
Para implementar essas funcionalidades, Gärtner utilizou alguns protocolos
de comunicação. A ferramenta de chat foi implementada utilizando como base o
protocolo XMPP. Já a ferramenta de conversação via áudio utiliza o protocolo SIP
como base. Ambos os protocolos necessitam de um servidor centralizado para que
possam ser utilizados.
9 IdDE: acrônimo de Integrated and Distributed Development Environment.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
59
Figura 22 - Interface do NetBeans com a ferramenta IdDE ativada
Fonte: adaptado de Gärtner (2011, p. 100).
Outra característica implementada no IdDE é a possibilidades de dois ou mais
desenvolvedores trabalharem no mesmo arquivo. Esse desenvolvimento
colaborativo acontece quando um dos desenvolvedores compartilha um determinado
arquivo do código-fonte com outros programadores. Além de todos visualizarem as
modificações, o IdDE identifica o que foi editado e por quem.
Além disso, o IdDE possui outras características implementadas, tais como:
Controle de compromissos;
Transferência de arquivos;
Tradução automática de mensagens enviadas pelo chat;
Multiplataforma.
Existe pouca informação relacionada ao licenciamento dessa aplicação. O
único indicativo que pode ser encontrado está no momento em que é feita a
instalação e se resume ao aviso: “No momento este programa é de uso restrito e
NÃO deve ser distribuído sem autorização do autor”. Apesar disto, a versão
disponível para download não apresenta limitações de uso.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
60
3.4 RedMine
O objetivo do RedMine é auxiliar no gerenciamento de projetos de software. O
sistema possui uma série de ferramentas que simplificam a comunicação, a
documentação, o controle das atividades e a visualização do percentual do
andamento do projeto.
O acesso a seus recursos é feito por um browser, pois trata-se de uma
ferramenta web. O RedMine foi desenvolvido utilizando RoR (Ruby on Rails) e é
distribuído sob licença GPL (General Public License). Por ser multiplataforma, esse
gerenciador de projetos pode ser instalado em vários Sistemas Operacionais.
Seu controle de acesso é baseado em papéis. É possível cadastrar novos
papéis e atribuir permissões a estes novos perfis de usuários. Além disso, é possível
copiar as permissões de acesso de outros perfis.
No RedMine podem ser criados vários projetos e subprojetos. Cada projeto
possui uma wiki, um fórum e um calendário do projeto. A wiki tem função de manter
a base documental da aplicação ou sistema desenvolvido. Já o fórum tem o papel de
prover os recursos necessários para a comunicação entre os membros da equipe. O
calendário mostra as atividades que estão sendo desenvolvidas e seus prazos.
Outra funcionalidade do RedMine, que pode ser observada na Figura 23, é o
gerenciamento de atividades. As atividades estão classificadas em bugs,
característica (requisito de software) e suporte. Essa classificação possibilita que os
projetos gerenciados pelo RedMine tenham um tempo de vida maior do que os
sistemas que não implementam essa classificação (SILVA, 2001, p. 41).
Outra característica dessa ferramenta é a possibilidade de visualizar as
atividades do projeto em um gráfico de Gantt, apresentado na seção 2.3.7. Esse
recurso contempla todas as atividades que possuírem datas de início e de fim
definidas.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
61
Figura 23 - Lista de atividades do RedMine
Fonte: extraído do site do desenvolvedor.
3.5 ProjectPier
O ProjectPier é uma ferramenta open source de gerenciamento on-line de
projetos. Desenvolvida em PHP e com banco de dados MySQL, é uma aplicação
com o objetivo similar ao do RedMine. Em seu trabalho, Almeida e Azevedo (2011,
p. 11) descrevem o ProjectPier como uma ferramenta capaz de fornecer um
ambiente on-line de colaboração em projetos. Para tanto, o ProjectPier possui uma
série de ferramentas que, em forma de módulos, compõem a aplicação.
Logo após efetuar autenticação no sistema, o usuário depara-se com o
módulo denominado dashboard. Nesse módulo, que é a página inicial do sistema, é
possível visualizar as informações de todos os projetos em andamento. Em meio a
estas informações podem ser encontradas as atividades que estão sendo
desenvolvidas, a lista de atualizações (updates) feitas no projeto e uma sinalização
que identifica se a atividade e/ou projeto estão atrasados ou não.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
62
No módulo que gerencia as atividades (milestones), o usuário consegue
visualizar todas as tarefas relacionadas ao projeto e quais estão alocadas sob sua
responsabilidade. É por meio deste módulo que o desenvolvedor marca as
atividades como concluídas e pode visualizar o cronograma de tarefas agendadas e
os deadlines referentes a elas. Também é permitido aos membros envolvidos no
projeto adicionar anotações nas atividades. Além disso, este módulo possibilita a
visualização das tarefas já concluídas e as anotações referentes a elas. A Figura 24
apresenta um projeto chamado Finish Welcome com a atividade To-Do-List.
Figura 24 - Visualização da página Milestones
Fonte: extraído do site.
O ProjectPier possui um módulo de gerenciamento de links. Nesse módulo,
os colaboradores do projeto podem adicionar tags/links, adicionar uma descrição e
comentários sobre eles. Seu funcionamento é parecido com o de uma wiki, a
diferença é que os links que aparecem a cada vez que uma palavra-chave é digitada
necessitam ser colocados manualmente, processo esse que na wiki é automatizado.
Apesar disso, o módulo apresenta uma característica que não é comum a sistemas
similares. Os links, sejam eles internos ou externos ao site, abrem em uma janela
flutuante dentro da página, o que permite ao usuário continuar visualizando os
comentários referentes ao link sem a necessidade de abrir uma nova janela.
O sistema fornece uma interface para o acompanhamento dos projetos. Nela
pode ser visualizada a lista de projetos em andamento e encerrados. Ao selecionar
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
63
um projeto, algumas informações são apresentadas, tais como o logotipo que
identifica o projeto, um breve resumo de seus objetivos, a listagem das pessoas
envolvidas, as datas de início e de previsão de fim, um percentual de conclusão do
projeto, uma sinalização que identifica se o projeto está atrasado ou não e a
quantidade de atividades que estão concluídas, em andamento e não iniciadas. Por
meio dessa interface o membro do projeto tem acesso ao gráfico de Gantt, que pode
ser composto por todas as atividades do projeto ou somente pelas atividades em
andamento.
Além dos módulos já descritos, o ProjectPier possui módulos para
gerenciamento e compartilhamento de arquivos, gerenciamento de usuários,
gerenciamento de contatos e para o controle de horas trabalhadas em cada projeto.
Esse conjunto de ferramentas fornece um ambiente centralizado para o
gerenciamento de projetos e das atividades que os compõem.
3.6 Análise das ferramentas existentes
Atualmente não existem ferramentas que contemplem desde a parte de
projetos até a implementação dos sistemas. Assim direcionou-se a pesquisa por
ferramentas existentes em duas categorias: ferramentas de gerenciamento de
projeto e/ou atividades e IDEs de desenvolvimento colaborativo ou baseados na
web.
Como base para a análise, foi utilizado parte dos requisitos descritos na
seção 2.1.6.1, que são a base para qualquer sistema de colaboração. Foram
adicionados alguns recursos que são necessários tanto para o desenvolvimento
normal de software quanto para o DDS. A Figura 25 apresenta a comparação entre
as ferramentas.
É possível visualizar que todas as ferramentas contemplam parte dos
requisitos necessários para o gerenciamento de atividades e codificação. Cada uma
das ferramentas apresentadas concentra sua atuação em uma determinada área.
Redmine, ProjectPier e CloudForge apresentam como principais características a
coordenação, o gerenciamento e o suporte. Já o Kodingen apresenta como ponto
forte a comunicação. O IdDE, que foi criado com base no DDS, apresenta como
suas principais característica a cooperação e a comunicação.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
64
Nenhuma das ferramentas contemplou os requisitos relacionados a e-mail e
videoconferência. A ausência da ferramenta de e-mail justifica-se pelo fato de haver
uma grande quantidade de serviços de webmail disponíveis na Internet. Já a
ferramenta de videoconferência é uma perda significativa na interatividade e
colaboração. Como mencionado na seção 2.1.5.1, a percepção é um dos pilares da
comunicação e a ferramenta de videoconferência é capaz de trazer este elemento
para o processo.
Figura 25 - Comparação entre as ferramentas analisadas
Fonte: criado pelo autor com base no referencial teórico.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
65
4 IMPLEMENTAÇÃO DO SISTEMA
Os estudos realizados com base no Desenvolvimento Distribuído de Software,
no processo de comunicação e colaboração entre integrantes de equipes de
trabalho e demais assuntos abordados, contribuíram como base para a construção
deste trabalho e para o desenvolvimento do CollabCode. Nesta seção são
apresentadas as tecnologias que foram utilizadas para a implementação, uma visão
geral sobre o sistema desenvolvido, no qual são apresentados os principais atores e
como cada um interage com o sistema, além de apresentar as ferramentas
implementadas e algumas telas. Também estão descritos nesta seção os requisitos
que foram implementados, requisitos que ficarão para trabalhos futuros, pontos
importantes da arquitetura do CollabCode e as configurações de segurança exigidas
pela aplicação.
4.1 Tecnologias utilizadas
Nesta seção são apresentadas as tecnologias utilizadas para desenvolver o
CollabCode. São apresentadas as linguagens de programação que foram utilizadas,
o banco de dados escolhido, o sistema operacional e demais tecnologias
necessárias.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
66
4.1.1 Ambiente de desenvolvimento
O sistema foi desenvolvido utilizando o ambiente a seguir. Alguns dos itens
listados serão detalhados nas próximas seções:
Hardware: computador com acesso à Internet;
Sistema Operacional Linux;
Linguagens de programação PHP e JavaScript ;
Banco de dados PostgreSQL;
IDE NetBeans;
Servidores web Apache e ShareJS;
Versionamento do código-fonte com o Subversion.
4.1.2 Sistema operacional Linux
A escolha de um Sistema Operacional baseado em Linux para o
desenvolvimento deve-se ao fato de que o CollabCode envolve a integração e
utilização de diversas tecnologias, o que dificulta que o sistema seja multiplataforma.
A opção do autor então foi por utilizar o Sistema Operacional Linux, pois, como
apresentado na seção 2.1.3, é o sistema mais popular em servidores devido a sua
flexibilidade, confiabilidade, velocidade e baixo custo.
4.1.3 Linguagens de programação
A linguagem de programação que foi utilizada para desenvolver esta solução
foi a linguagem PHP. O PHP é uma linguagem de programação web de código livre.
A escolha dessa linguagem deve-se ao fato de o autor do presente trabalho possuir
experiência com ela.
Além da linguagem de programação PHP, foi utilizada a linguagem
JavaScript, que é responsável pela interação do usuário dentro do navegador. Esta
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
67
linguagem possui diversas bibliotecas disponíveis para auxiliar na construção de
interfaces dinâmicas e interativas.
4.1.4 Banco de dados
O CollabCode foi desenvolvido utilizando o banco de dados PostgreSQL. A
escolha por este banco de dados deve-se ao fato de o PostgreSQL ser código livre e
devido ao autor já possuir experiência na sua utilização. É possível que em trabalhos
futuros o sistema atenda a outros bancos de dados.
O PostgreSQL é um sistema gerenciador de banco de dados objeto-
relacional. Suporta grande parte do padrão SQL:2003, além de possuir diversos
recursos adicionais à linguagem (OLIVEIRA, 2007, p. 14).
4.1.5 Servidores web
A escolha do servidor web para esta ferramenta está diretamente associada à
linguagem de programação. O servidor web escolhido pelo autor foi o Apache, por
ser um servidor compatível com a linguagem de programação PHP. Outro fator que
influenciou na escolha é que, como mencionado na seção 2.3.2, o Apache é um
servidor web de código livre.
Além do servidor web Apache, o CollabCode também utiliza um servidor web
criado pelo próprio autor com base na API do ShareJS. Este servidor é utilizado na
codificação colaborativa, que, pelo grande volume de informações, requer um
servidor dedicado a esta função.
4.1.6 Versionamento do código-fonte
O versionamento do código-fonte é essencial em projetos de desenvolvimento
de software. Como visto na seção 2.3.1, existem vários softwares capazes de fazer
este trabalho. Para esta proposta, foi utilizado o Subversion pelo fato do autor
possuir mais experiência e de ser uma ferramenta livre.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
68
O Subversion é mantido pela fundação Apache e atualmente encontra-se na
versão 1.7.7. O aplicativo possui vasta documentação disponível na Internet e em
livros especializados.
4.2 Visão geral
O CollabCode fornece grande parte dos recursos necessários para que
equipes de desenvolvimento possam trabalhar de forma colaborativa e distribuída.
Para tanto, o autor desenvolveu um software que agrupa diversos recursos a uma
ferramenta baseada na web. Com isso, é possível abranger de forma equilibrada
todas as grandes áreas (suporte, gerenciamento, coordenação, comunicação e
cooperação) necessárias para o desenvolvimento de software de forma colaborativa
e distribuída.
A ferramenta permite que desenvolvedores trabalhem em espaços de
trabalho diferentes de forma colaborativa, sem a necessidade de instalações
específicas nem migração de infraestrutura. Assim, tudo que é necessário para
utilizar o sistema é um computador com acesso à Internet, uma vez que a aplicação
é executada dentro do navegador. Além disso, a equipe de trabalho utiliza uma
ferramenta centralizada e on-line para a codificação, o que possibilita um melhor
controle do andamento das atividades. A Figura 26 apresenta todas as ferramentas
disponíveis no CollabCode.
Figura 26 - Ferramentas disponíveis no CollabCode
Fonte: criado pelo autor.
Existem três atores fundamentais na estrutura deste sistema: a função do
gerente de projetos ou analista, neste documento chamado de gerente, a função do
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
69
desenvolvedor e o administrador. O gerente é o responsável por criar os projetos e
alimentá-los com as atividades. Estas atividades podem ser requisitos
(características) ou chamados para correção de problemas. Em geral, as atividades
podem ser qualquer tarefa que implique em alteração ou criação de código. O
desenvolvedor pode escolher dentre as atividades que o gerente lhe atribuiu ou
qualquer outra que esteja com status em aberto ou em andamento. Além disso,
existe uma terceira função denominada administrador. O administrador pode fazer
todas as atividades do sistema, além de poder ajustar alguns parâmetros de
configuração.
4.3 Gerente
Além de poder desempenhar todas as atividades relacionadas aos
desenvolvedores (apresentadas na seção 4.4), o gerente pode desempenhar muitas
outras atividades de gerenciamento e controle. O caso de uso expresso na Figura 27
apresenta todas as atividades que estão relacionadas com o gerente.
Figura 27 - Caso de uso - Gerente
Fonte: criado pelo autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
70
4.3.1 Gerenciamento de Usuários
Ao gerente cabe a função de manter o cadastro dos usuários do sistema. Por
meio da interface representada na Figura 28, o gerente é capaz de adicionar novos
usuários e editar sempre que necessário as informações a eles pertencentes. No
momento da criação do usuário, o gerente deve escolher a função que este usuário
terá no sistema. Uma vez atribuída uma função, esta será mantida em todos os
projetos a que este usuário estiver vinculado. Existe ainda a possibilidade de
desabilitar os usuários do sistema. Esta opção está disponível apenas para o
administrador, uma vez que isto implica na perda do acesso do usuário ao sistema.
Além disso, a opção por desabilitar os usuários e não excluí-los deve-se à
necessidade de manter o histórico das interações deste usuário com os projetos e
atividades.
Figura 28 - Interface de gerenciamento de usuários
Fonte: criado pelo autor.
Quando um usuário é adicionado pelo gerente, este usuário passa a ter
acesso ao sistema, mas não aos projetos. O gerente precisa escolher o projeto no
qual deseja vincular o usuário e só após o vínculo o usuário passa a ter acesso às
informações do projeto, atividades e código-fonte da aplicação. A Figura 29
apresenta a interface de gerenciamento de usuários vinculados ao projeto.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
71
Figura 29 - Interface de vinculação de usuários ao projeto
Fonte: criado pelo autor.
4.3.2 Gerenciamento de projetos
Um usuário com função de gerente é capaz de criar novos projetos e
acompanhar a execução das atividades inerentes a ele. O gerente possui acesso
limitado aos projetos que criou ou aos quais foi vinculado por outros gerentes. A
interface do CollabCode apresentada na Figura 30 possibilita uma visão da lista de
projetos relacionados ao gerente e uma visão geral das ações que o gerente pode
desempenhar dentro dos projetos.
Figura 30 - Lista de projetos e ações disponíveis
Fonte: criado pelo autor.
Para adicionar um projeto, o usuário deve atribuir um nome, um código
identificador e uma senha. O nome é apenas para facilitar a identificação do projeto
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
72
na lista. Já o código identificador será utilizado em diversas partes do sistema. Este
código deve ser único e pode ser formado por letras e números, além dos
caracteres ponto, underline e menos. A senha pode ser formada por quaisquer
caracteres.
O código identificador juntamente com a senha cadastrada formam o login e a
senha para todas as demais opções do sistema que necessitem de controle de
acesso. Dentre estas opções tem-se: possibilidade de commit e checkout do projeto
pelo Subversion, acesso às bases de dados do projeto e acesso à pré-visualização
do sistema que está sendo desenvolvido. O identificador também é utilizado como
nome do projeto no repositório SVN e como usuário no servidor Linux.
Além do nome, do código identificador e da senha, o cadastro de projetos
permite a inclusão de informações como: data de início do projeto, data de término
e importação do código-fonte de um repositório SVN externo. As datas de início e
término servem como parâmetros para o acompanhamento das atividades e para
verificar se o projeto está dentro do prazo ou atrasado. A opção de repositório
externo permite a importação de projetos preexistentes mantidos em outros
repositórios. Caso a opção de repositório externo não seja utilizada, o sistema
adicionará automaticamente o projeto no repositório SVN mantido pelo CollabCode.
Mais informações sobre como os projetos são criados no servidor são apresentadas
na seção 4.6. A Figura 31 apresenta a interface de criação de projetos.
Figura 31 - Interface de criação de projetos
Fonte: criado pelo autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
73
4.3.3 Gerenciamento de atividades
Uma vez que o projeto foi criado e os usuários vinculados, o gerente pode
iniciar o processo de cadastro de atividades. Ao adicionar uma nova atividade, o
gerente deve atribuir um nome, realizar a definição de uma “Nova característica”
(requisito) ou um problema (problema a ser corrigido), informar as datas previstas
para início e fim da atividade, escolher a prioridade (baixa, média ou alta), o status
inicial (em aberto, em andamento ou encerrada) e a descrição da atividade. Além
disso, o gerente pode atribuir ou não esta atividade a um usuário e anexar arquivos
referentes a esta atividade. Sempre que necessário, o gerente poderá editar estas
informações, reabrindo atividades ou mudando suas prioridades. A Figura 32
apresenta a interface de cadastramento de atividades.
Figura 32 - Interface de criação de atividade
Fonte: criado pelo autor.
Após o cadastro das atividades, é possível acompanhar sua execução por
meio da listagem de atividades. Esta lista, apresentada pela Figura 33, possibilita
uma rápida visão sobre as atividades que estão sendo realizadas, além das
atividades que estão concluídas ou em aberto. Esta listagem também permite a
alteração do percentual de conclusão, a visualização dos arquivos a ela
pertencentes e identifica para qual usuário a atividade está atribuída. É possível
organizar a lista por nome, tipo (nova característica ou problema), prioridade, status
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
74
e percentual de conclusão, o que garante ao gerente uma visualização do projeto
por diferentes pontos de vista.
Figura 33 – Parte da lista de atividades de um projeto
Fonte: criado pelo autor.
O gerente pode ainda acompanhar a realização das atividades por gráficos de
Gantt. Esta opção está disponível individualmente por atividade e por projeto. O
Gantt por atividade fornece uma visão detalhada do andamento da atividade e traz
informações específicas dela. Já o Gantt por projeto proporciona uma visão geral de
todas as atividades vinculadas ao projeto, estejam elas encerradas, em andamento
ou em aberto. A Figura 34 apresenta a interface do Gantt de projetos e por atividade.
Figura 34 - Gráficos de Gantt por projeto e por atividade
Fonte: criado pelo autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
75
4.3.4 Gerenciamento de bases de dados
É comum que as aplicações web possuam bases de dados para melhor
armazenamento de suas informações. Prevendo esta possibilidade, o CollabCode
possibilita ao gerente criar bases de dados para seus projetos. Inicialmente, o
CollabCode só permite a criação de bases de dados utilizando o banco PostgreSQL,
ficando para trabalhos futuros a adição de novas opções de banco.
O gerente pode criar quantas bases de dados forem necessárias para o
projeto. Estas bases utilizam o identificador e senha do projeto como usuário e
senha de acesso ao banco. O gerente pode ainda excluir as bases de dados
existentes no projeto. O processo de criação de bases de dados é apresentado na
seção 4.6.
4.4 Desenvolvedor
O caso de uso da Figura 35 detalha, de forma abrangente, todas as
atividades que o desenvolvedor pode desempenhar no sistema. A principal função
de um desenvolvedor é a codificação, mas, para que isso seja possível, é
necessário que ele escolha uma atividade na qual deve trabalhar. Estas atividades
são mantidas pelo gerente, que pode ou não atribuir as tarefas a um determinado
desenvolvedor. Após a escolha da atividade, o programador poderá iniciar a
codificação por uma interface que é semelhante a uma IDE convencional, possuindo
os recursos mínimos necessários para desempenhar esta função. Sempre que
necessário, o desenvolvedor pode atualizar o status de suas atividades diretamente
da interface de codificação, informando ao sistema o percentual de conclusão ou
marcando a atividade como concluída.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
76
Figura 35 - Caso de uso - Desenvolvedor
Fonte: criado pelo autor.
4.4.1 Área de codificação
O CollabCode possui uma área na qual é possível editar os arquivos de
código-fonte pertencentes ao projeto. Essa área foi construída utilizando o editor
CodeMirror. O CodeMirror é um editor de código livre, desenvolvido utilizando a
linguagem JavaScript, e que possui diversos plug-ins disponíveis para sua
personalização. Neste sistema, foram utilizados plug-ins para destacar o código-
fonte de acordo com a linguagem, para efetuar o agrupamento de tags, para
formatar o código-fonte, dentre outros.
Ao clicar duas vezes sobre o nome do arquivo a ser editado, uma aba na
parte superior do editor é adicionada. Esta aba auxilia na identificação do arquivo em
edição, possibilita verificar alterações ou não, sinalizando também caso algum
arquivo esteja com seção de edição colaborativa ativa. A interface da área de
codificação apresentada na Figura 36 demonstra a utilização da área de codificação
em funcionamento.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
77
Figura 36 - Área de codificação
Fonte: criado pelo autor.
A interface de codificação possui outros componentes JavaScript de código
livre que auxiliaram na construção da IDE: UI Layout e Dynatree. A biblioteca UI
Layout foi utilizada para construir as divisórias retráteis e redimensionáveis do editor.
Caso o desenvolvedor veja necessidade, pode utilizar as teclas F11 para maximizar
a área de codificação e ESC para reabrir a árvore de arquivos e as opções na parte
inferior do editor. Já a biblioteca Dynatree é utilizada para disponibilizar os arquivos
na área lateral esquerda do editor.
4.4.2 Edição colaborativa
Durante a codificação, é comum que desenvolvedores pertencentes a uma
mesma equipe troquem ideias e até mesmo trabalhem em conjunto para resolver um
determinado problema, como por exemplo, na programação em pares na
metodologia ágil XP (seção 2.2.2.1). Em um ambiente onde os desenvolvedores
podem trabalhar de forma distribuída, esta interação exige que o sistema seja capaz
de permitir que dois ou mais desenvolvedores editem de forma simultânea o mesmo
arquivo. Como forma de suprir esta necessidade, o sistema identifica os arquivos
que estão sendo editados em simultâneo e todas as alterações feitas por um
desenvolvedor são imediatamente replicadas para os demais membros que
compartilham desta seção de edição.
A edição colaborativa do CollabCode foi construída utilizando o ShareJS em
conjunto com o NodeJS. O ShareJS é uma biblioteca JavaScript que permite a
edição simultânea em diversos elementos HTML, tais como inputs e textareas. Esta
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
78
biblioteca roda no servidor e necessita do NodeJS para seu funcionamento. O
NodeJS é uma base para a execução de JavaScript no lado do servidor. Com estes
dois aplicativos, foi possível criar um servidor que atende exclusivamente à
necessidade de edição simultânea da IDE. No lado do cliente foi preciso estabelecer
a comunicação entre o Codemirror (apresentado na seção 4.4.1) e o ShareJS. Esta
comunicação é feita por meio de WebSockets, tecnologia que permite a criação de
conexões bidirecionais entre navegador e servidor. O diagrama apresentado na
Figura 37 exemplifica de forma simplificada a interação entre estas tecnologias e o
funcionamento da edição simultânea. Uma explicação mais detalhada sobre o
funcionamento do servidor e da interface dos participantes durante a colaboração
simultânea é apresentada na seção 4.6.
Figura 37 - Funcionamento simplificado da edição simultânea
Fonte: criado pelo autor.
4.4.3 Ferramentas de comunicação
O sistema fornece mecanismos para que a comunicação permita a
cooperação na solução de problemas. As ferramentas de comunicação
desenvolvidas ou incorporadas a esta solução são: adicionar comentários nas
atividades, ferramenta de bate-papo e ferramenta de videoconferência.
A possibilidade de adicionar comentários à atividade é um recurso importante
para a documentação dos problemas encontrados ao longo do desenvolvimento. É
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
79
uma forma de um desenvolvedor comunicar-se com os demais membros da equipe
de forma assíncrona. Este recurso permite a adição de trechos de código aos
comentários, trechos estes que são coloridos e formatados utilizando a biblioteca
JavaScript SyntaxHighlighter.
A ferramenta de bate-papo possibilita a comunicação entre os membros da
equipe de forma textual e síncrona. Possui uma interface dividida em abas, na qual é
possível separar a conversação por contextos:
Sistema: todos os usuários do sistema podem conversar entre si;
Projeto: para cada projeto que o usuário estiver inscrito, há uma aba
para a troca de mensagens com os demais membros do projeto;
Arquivo: somente os desenvolvedores que estiverem trabalhando no
mesmo arquivo poderão conversar entre si.
Uma visão da interface do bate-papo pode ser visualizada na Figura 38.
Figura 38 - Interface do bate-papo
Fonte: criado pelo autor.
A ferramenta de videoconferência de código livre BigBlueButton foi
incorporada ao sistema. O BigBlueButton é mantido pela empresa Blindside
Networks e é capaz de fornecer a comunicação por áudio e vídeo entre os
participantes, além de outros recursos como quadro branco e compartilhamento de
tela. A decisão por incorporar uma ferramenta pronta ao CollabCode deve-se ao fato
de que o BigBlueButton pode ser utilizado/customizado sem nenhuma restrição. A
ferramenta de videoconferência permite aos membros da equipe realizar reuniões
on-line, nas quais o alinhamento da equipe pode ser feito, além de permitir a tomada
de decisões em conjunto. Essa ferramenta serve de apoio para equipes que utilizam
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
80
metodologias ágeis como Scrum (seção 2.2.2.2), que requer reuniões rápidas e
diárias. É possível também manter uma seção de áudio aberta enquanto os
desenvolvedores codificam, recurso muito útil durante uma edição colaborativa. A
Figura 39 demonstra o BigBlueButton em funcionamento, integrado ao CollabCode.
Figura 39 - Sala de reunião com o BigBlueButton
Fonte: criado pelo autor.
4.4.4 Manipulação de banco de dados
O sistema fornece a possibilidade do desenvolvedor manipular informações
do banco de dados do projeto que está em desenvolvimento. Para isso, há uma
interface que está disponível na tela de codificação na qual é possível executar
comandos SQL e visualizar seus resultados. A Figura 40 apresenta a interface do
banco de dados.
Figura 40 - Interface de banco de dados
Fonte: criado pelo autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
81
4.4.5 Gerenciamento de arquivos
O desenvolvedor pode gerenciar os arquivos de código-fonte da aplicação por
meio de um componente em formato de árvore disponível na lateral esquerda da
área de codificação. Muitas IDEs adotam este formato de apresentação dos arquivos
por ser simples e permitir o acesso em níveis de profundidade aos diretórios do
projeto. Por meio das opções dispostas na parte superior da árvore é possível
adicionar, renomear e remover arquivos e diretório. A Figura 41 apresenta a
interface do gerenciamento de arquivos.
Figura 41 - Interface de gerenciamento de arquivos
Fonte: criado pelo autor.
Outra atividade relacionada ao gerenciamento de arquivos é o controle de
versão do código-fonte. Sempre que julgar pronta uma atividade, o desenvolvedor
poderá transmitir as modificações para um sistema de controle de versões, que é
monitorado pelo gerente. Com o controle de versões é possível restaurar, comparar
e desfazer alterações no código-fonte. No momento em que o desenvolvedor decidir
transmitir uma nova versão dos arquivos de código-fonte, será solicitado que ele
associe as modificações a alguma das atividades. Este processo permite a
rastreabilidade das modificações além de facilitar a criação da documentação de
cada versão. A Figura 42 apresenta a interface do sistema de controle de versões
adicionada à interface da IDE.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
82
Figura 42 - Interface do sistema de controle de versões
Fonte: criado pelo autor.
Além das funcionalidades já citadas, o desenvolvedor também pode adicionar
documentos às atividades. Esses documentos podem ser arquivos de imagem,
como diagramas e fluxogramas, ou até documentos textuais, que podem ser casos
de teste, descrição ou documentação inerente à atividade. Estes documentos podem
ser visualizados por todos os membros da equipe.
4.5 Requisitos do sistema
Para facilitar a classificação, foram estabelecidos dois níveis de prioridade
para os requisitos, Indispensável, identificados pela letra I, e Desejável, identificados
pela letra D. Além disso, os requisitos foram separados em requisitos funcionais e
não funcionais. Os requisitos classificados como indispensáveis formam o escopo
deste trabalho. Já os requisitos classificados como desejáveis serão implementados
somente se houver tempo hábil para tal.
Em um levantamento preliminar de requisitos, o sistema apresentou 58 macro
requisitos, alguns deles podem ser desmembrados em vários outros. Para esta
versão inicial do sistema, foram implementados todos os requisitos classificados
como indispensáveis e somente alguns dos classificados como dispensáveis, uma
vez que a quantidade de requisitos é elevada e a complexidade de alguns deles é
considerada alta. Os demais requisitos estão listados para identificar o desejável em
uma ferramenta ideal e podem vir a ser implementados em trabalhos futuros.
A seguir é apresentada a lista de requisitos funcionais (Tabela 3) e não
funcionais (Tabela 4) juntamente com suas classificações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
83
Tabela 3 - Requisitos Funcionais (RF)
ID Requisito Explicação Classificação
RF1 Manter cadastro de usuários
O sistema deverá permitir a inclusão e alteração dos usuários do sistema. Deverá haver também uma opção de desabilitar o usuário.
I
RF2 Definir níveis de acesso por função de usuário
Função de usuário: o sistema deverá permitir que usuários sejam classificados como desenvolvedor, gerente e administrador, com níveis de permissão diferentes.
I
RF3 Solicitar autenticação Todos os usuários devem autenticar-se para poder utilizar o sistema.
I
RF4 Manter projetos web O sistema deverá ser capaz de criar e gerenciar projetos web utilizando a linguagem de programação PHP.
I
RF5 Possibilitar a criação e administração de bases de dados
Cada projeto criado poderá administrar bases de dados relacionadas ao projeto em questão. I
RF6 Possibilitar a importação de projetos SVN
O sistema deverá permitir a importação de projetos existentes por meio de sistemas controladores de versão Subversion.
I
RF7 Exportação do projeto O projeto web poderá ser exportado por sistema de controle de versões.
I
RF8 Manter atividades do projeto
O sistema deve possibilitar a criação de atividades relacionadas ao projeto. Essas atividades podem ser a lista de requisitos/características a serem implementados ou correções a serem feitas.
I
RF9 Definir prioridade das atividades
Ao adicionar novas atividades, elas devem ser identificadas com prioridades baixa, média ou alta. O sistema deverá permitir que as prioridades sejam alteradas conforme a necessidade durante a execução do projeto.
I
RF10 Cadastrar data de início e fim em cada atividade
As atividades devem ter suas datas de início e de fim especificadas no momento da criação da atividade.
I
RF11 Possibilitar que documentos sejam anexados às atividades
Permitir que documentos possam ser anexados às atividades. Estes documentos poderão ser imagens contendo diagramas e fluxogramas ou documentos textuais, que podem ser casos de teste, descrição ou documentação de atividades ou processos.
I
RF12 Possibilitar o acompanhamento do projeto por meio de gráficos
O sistema deverá possibilitar a visualização do estado do projeto pelo gráfico de Gantt.
I
RF13 Possibilitar o acompanhamento das atividades por meio de gráficos
O sistema deverá possibilitar a visualização do estado de cada atividade pelo gráfico de Gantt.
I
RF14 Possuir interface de codificação
A aplicação deverá dispor de uma interface na qual os usuários poderão codificar diretamente dentro do navegador.
I
RF15 Identificar a sintaxe e colorir o código
A interface de codificação deverá identificar a linguagem que está sendo utilizada e colorir o código-fonte de acordo com o padrão da linguagem.
I
RF16 Gerenciar arquivos de código-fonte
O sistema deverá permitir o gerenciamento e organização dos arquivos de código-fonte.
I
RF17 Possibilitar pré-visualização do sistema
A interface de codificação deverá possuir uma funcionalidade que permita ao desenvolvedor testar o código por meio de uma pré-visualização.
I
RF18 Possibilitar a escolha O desenvolvedor poderá escolher as atividades em I
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
84
ID Requisito Explicação Classificação
de atividades para trabalhar
que quer trabalhar.
RF19 Atribuir atividades aos usuários
Os administradores e gerentes deverão poder atribuir atividades aos desenvolvedores.
I
RF20 Permitir edição colaborativa
Dois ou mais desenvolvedores deverão poder trabalhar de forma colaborativa no mesmo arquivo.
I
RF21 Permitir conversação por bate-papo
O sistema deverá possuir um bate-papo para que o usuário possa conversar com os usuários autenticados no sistema. A interface de interação do chat deverá ser a mesma para todos os canais de chat, que são: sistema, projetos e mesmo arquivo sendo editado.
I
RF22 Versionamento do código-fonte
A aplicação deverá possuir sistema de versionamento do código-fonte, permitindo aos administradores e analistas/projetistas controlar as versões. Além disso, o controle de versionamento deve permitir a visualização, comparação e a reversão de arquivos já transmitidos.
I
RF23 Possuir opção de desfazer
A interface de codificação deverá apresentar a opção de desfazer.
I
RF24 Possuir opção de salvar alterações
A interface de codificação deverá possuir uma opção onde o desenvolvedor poderá salvar as alterações feitas.
I
RF25 Atualizar status das atividades
O desenvolvedor poderá marcar as atividades como concluída ou em andamento, além de poder revertê-las ao estado inicial (em aberto).
I
RF26 Possibilitar a adição de observações às atividades
Os usuários devem poder adicionar observações nas atividades. I
RF27 Mostrar erros do servidor web
A interface de codificação deve mostrar os erros que estão sendo gerados no servidor web para o projeto que está sendo editado.
I
RF28 Disponibilizar interface para o banco de dados
O sistema deverá possuir uma interface na qual o usuário pode manipular o banco de dados.
I
RF29 Possuir uma ferramenta de quadro branco
O sistema deverá disponibilizar uma ferramenta de quadro branco onde os usuários poderão interagir de forma síncrona.
I
RF30 Possibilitar conversação por áudio e vídeo
O sistema deverá possuir uma interface onde os participantes poderão comunicar-se por áudio e vídeo.
I
RF31 Possibilitar a criação de novas funções de usuário
Permitir que o administrador do sistema crie novas funções de usuário, além das já existentes. D
RF32 Gerenciar permissões para cada usuário
Possibilitar que permissões específicas sejam atribuídas a usuários.
D
RF33 Permitir a geração de relatórios das atividades dos usuários
Permitir geração de relatórios personalizados com as ações dos usuários com filtros de data, hora, endereço IP, ação, usuário e função.
D
RF34 Possibilitar a utilização de outras linguagens de programação
O sistema poderá ser utilizado para desenvolver em diversas linguagens de programação. D
RF35 Possibilitar a importação de projetos Git e CVS
Possibilitar que projetos de outros controladores de versão como Git e CVS sejam importados. D
RF36 Possibilitar dependência entre atividades
Possibilitar que atividades sejam encadeadas por dependências. Uma atividade não poderá iniciar até que suas dependências tenham sido concluídas.
D
RF37 Possibilitar agrupamento de
Permitir que o gerente agrupe as atividades. Um agrupamento pode conter as atividades que
D
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
85
ID Requisito Explicação Classificação
atividades pertencem a um módulo ou funcionalidade RF38 Permitir a criação de
diagramas UML O sistema deverá possuir uma interface onde o usuário poderá criar diagramas UML referentes ao projeto.
D
RF39 Vincular atividades aos diagramas UML
Permitir que os diagramas UML possam ser associados às atividades já existentes.
D
RF40 Permitir a criação de diagramas de banco de dados
O sistema deverá fornecer uma interface para a criação de diagramas ER. D
RF41 Versionamento de diagramas
A aplicação deverá manter arquivadas as versões dos diferentes diagramas criados por meio dela.
D
RF42 Permitir anotações nos diagramas
Possibilitar que anotações sejam colocadas nos diagramas.
D
RF43 Possuir agenda O sistema deverá permitir o agendamento de compromissos e possuir uma interface para visualização. Ela deverá possuir duas interfaces, uma geral do projeto e outra individual do usuário.
D
RF44 Permitir a vinculação de usuários a compromissos
Permitir que os usuários possam ser vinculados a compromissos. O compromisso deverá aparecer na agenda pessoal do usuário, que deverá aceitá-lo ou não. Caso o usuário não aceite, uma marcação deverá destacar os usuários que não poderão estar presentes.
D
RF45 Configurar projeto para edição colaborativa
Possibilitar ao gerente a escolha na criação do projeto (e posteriormente na configuração do projeto) se os desenvolvedores poderão ou não editar ao mesmo tempo o mesmo arquivo. Caso esteja desabilitada a edição cooperativa, o programador poderá visualizar seu conteúdo que já está sendo editado como somente leitura.
D
RF46 Salvamento automático na edição do código
A interface de codificação deverá fornecer opção de salvamento automático.
D
RF47 Possibilitar a visualização de logs do banco de dados
Permitir que os desenvolvedores visualizem os logs do banco de dados por meio da interface do banco. D
RF48 Possibilitar a geração de pacotes
O gerente poderá de tempos em tempos gerar versões (pacote com o código-fonte) do projeto.
D
RF49 Gerar documentação dos pacotes gerados
O sistema deverá identificar as alterações feitas entre a geração do último pacote e criar um documento de release, contendo todas as correções e novos requisitos implementados.
D
RF50 Gerar relatórios estatísticos
Estatísticas de transmissões, de horas trabalhadas por usuário, de atividades que precisaram ser refeitas, total de transmissões, horas em cada requisito, total de horas no projeto, total de horas por usuário, gráfico de atividade de usuário no sistema, dentre outros.
D
Fonte: criado pelo autor.
Tabela 4 - Requisitos Não Funcionais (RNF)
ID Requisito Explicação Classificação
RNF1 Sistema deve ser web O sistema deverá ser web. I RNF2 Desenvolvido em PHP
e Javascript O sistema deverá ser desenvolvido utilizando as linguagens de programação PHP e Javascript.
I
RNF3 Deve rodar nos navegadores Firefox e Chrome
O sistema deverá rodar nos navegadores Google Chrome e Mozilla Firefox, em suas duas últimas versões.
I
RNF4 Restrição de acesso Garantir que todas as telas e transações do I
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
86
ID Requisito Explicação Classificação
por permissões sistema estejam condicionadas a uma permissão ou conjunto de permissões.
RNF5 Registrar modificações nos arquivos de código-fonte
O sistema deverá identificar o usuário, data e hora da modificação. I
RNF6 Garantir isolamento dos projetos
Garantir que os projetos estejam isolados uns dos outros e que nenhum usuário sem permissão tenha acesso a informações de outros projetos.
I
RNF7 Necessidades de internacionalização
O programa deverá ser estruturado de forma que o usuário possa escolher a língua em que quer trabalhar no sistema.
D
RNF8 Registrar ações dos usuários no sistema
Registrar data, hora, endereço IP e ação dos usuários em todas as ações feitas no sistema.
D
Fonte: criado pelo autor.
4.6 Arquitetura do sistema
Grande parte da arquitetura do sistema foi apresentada pelas seções
anteriores. Apesar disso, é importante destacar alguns pontos-chave na estrutura do
CollabCode. Nas próximas seções é apresentado o modelo de banco de dados
utilizado na aplicação e o detalhamento do funcionamento dos processos de criação
de projetos e de edição colaborativa. Ao final, são apresentados os componentes
que foram utilizados para construção da interface da aplicação.
4.6.1 Banco de dados do CollabCode
Com base no levantamento de requisitos apresentado na seção 4.5, foi criado
um modelo de base de dados que possibilitasse a implementação dos requisitos
considerados indispensáveis, além de garantir que a estrutura da base possibilite a
implementação dos requisitos desejáveis sem a necessidade de grandes
modificações. A Figura 43 apresenta o modelo de base de dados utilizado no
CollabCode.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
87
Figura 43 - Modelo de base de dados
Fonte: criado pelo autor.
Em conjunto, as tabelas “usuarios”, “funcoes” e “permissoes” controlam todas
as funcionalidades do sistema. A tabela “usuarios” é responsável por armazenar as
informações dos usuários cadastrados. Esta tabela está relacionada à tabela
“funcoes”, que por sua vez está relacionada à tabela “permissoes”. A tabela
“funcoes" armazena o nome dos atores que podem interagir com o sistema
(administrador, analista e desenvolvedor). Cada função possui uma série de
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
88
permissões, e são elas que determinam o que cada usuário do sistema poderá ou
não fazer.
A tabela “projetos” gerencia as informações sobre os projetos. É nesta tabela
que está armazenado o identificador do projeto, que deve ser único. Esta tabela
também armazena o usuário e a senha utilizados em diversas atividades, tais como:
pré-visualização do projeto, commit de SVN e criação de bases de dados. Além
disso, a tabela “projetos” está relacionada à tabela “bases_de_dados”, que
armazena as informações das bases de dados criadas para cada projeto.
A tabela “atividades” é responsável por armazenar todas as informações das
atividades que estão relacionadas a um determinado projeto. Esta tabela está
relacionada às tabelas “atividades_prioridades”, “atividades_status” e
“atividades_tipos”, que são tabelas auxiliares. A tabela “atividades_prioridades”
permite o cadastramento das prioridades que cada atividade pode ter. Inicialmente,
esta tabela possui três valores: baixa, média e alta. A tabela “atividades_status”
armazena os estados em que a atividade pode estar. Para esta implementação,
foram definidos os estados: em aberto, em andamento e encerrado. Já a tabela
auxiliar “atividades_tipos” é responsável por identificar as atividades quanto ao seu
tipo, que foram definidos como Nova característica e Problema. A tabela “atividades”
também possui relacionamento com a tabela “atividades_mensagens”. Esta tabela é
responsável por armazenar as mensagens trocadas entre os membros de um
projeto sobre uma determinada atividade.
Quando as modificações realizadas em arquivos de código-fonte precisam ser
transmitidas para o sistema de controle de versões, é necessário que o
desenvolvedor associe a estas modificações uma atividade. Esse registro de
modificações associado à atividade é registrado na tabela “svn_log”. Esta tabela
armazena a data e hora do commit, o usuário que transmitiu a modificação, além de
identificar a qual atividade e projeto esta modificação pertence.
As tabelas “batepapo_mensagens”, “salas_reuniao” e “edicoes_ativas” são
responsáveis por fornecer a base para a comunicação e colaboração síncrona entre
os usuários. Na tabela “batepapo_mensagens” estão armazenadas todas as
mensagens trocadas entre os usuários que utilizam a ferramenta de bate-papo. A
tabela “salas_reuniao” gerencia a criação de salas de videoconferência no
BigBlueButton. Já a tabela “edicoes_ativas” é responsável por armazenar
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
89
informações sobre os arquivos que estão sendo editados e por quem, informações
necessárias para que a edição colaborativa tenha início e fim.
4.6.2 Criação de projetos
A criação de projetos no CollabCode é um processo que precisa ter sua
arquitetura compreendida em virtude da forma como foi projetado. Para que o
projeto seja criado, o CollabCode precisa interagir com um script criado pelo autor,
que está no sistema operacional do servidor e é responsável pela criação dos
projetos no Subversion e pelas configurações de segurança. Além de criar os links
simbólicos e usuários no sistema operacional, necessários para que o sistema
funcione adequadamente. O diagrama de sequência que mostra todos os passos da
criação de projetos no CollabCode pode ser visualizado no Apêndice A.
Visualizando o diagrama é possível entender o funcionamento da criação de
projetos. O primeiro passo é verificar se o usuário está autenticado no sistema e se
ele possui permissão para criar projetos. Em seguida, é realizada a verificação das
informações recebidas pelo formulário de criação de projetos. Esta validação
garante que não existam dois projetos com o mesmo identificador e que as variáveis
correspondem às informações necessárias para a criação do projeto.
O passo seguinte é a criação do projeto na base de dados da aplicação e
criação dos diretórios. Um novo registro para este projeto é inserido na tabela
“projetos” e logo em seguida os diretórios onde ficam hospedados os arquivos de
código-fonte e arquivos referentes às atividades são criados.
O último passo é a execução do script que está em
“/usr/local/bin/create_project.sh”, encerrando o processo de criação. Este script é
responsável por:
Adicionar um usuário no Linux para o projeto: a necessidade de adicionar um
usuário no sistema operacional servidor é uma questão estratégica. O usuário
é adicionado para criar um home com o nome do identificador do projeto,
permitindo assim que, em trabalhos futuros, os arquivos de código-fonte
sejam acessados por FTP sem a necessidade de qualquer modificação na
estrutura de arquivos;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
90
Adicionar um link simbólico para o projeto em
/home/<identificador_do_projeto>/public_html: este link simbólico tem a
função de criar o local onde a aplicação será testada. Para acessar o preview
do projeto basta acessar no navegador
http://servidor/~<identificador_do_projeto>. As configurações que permitem
essa pré-visualização estão documentadas na seção 4.7;
Criar arquivos .htaccess e .htpasswd: o script cria para cada projeto um
arquivo .htaccess e um arquivo .htpasswd, que ficam armazenados em
/home/<identificador_do_projeto>/public_html/. Estes arquivos são
responsáveis pelas configurações de segurança de cada projeto, além de
permitir a separação dos logs de cada aplicação. Estas configurações estão
documentadas na seção 4.7;
Criar projeto no Subversion: caso o usuário que está criando o projeto tenha
selecionado a opção de repositório externo, o script buscará os arquivos de
código-fonte no repositório informado e os adicionará na pasta do projeto
(/home/<identificador_do_projeto>/public_html/). Mas caso o usuário tenha
optado pela criação de repositório local, um projeto no Subversion instalado
no servidor é adicionado, os arquivos de template são importados e logo após
é feito um checkout do projeto no diretório criado para receber os arquivos de
código-fonte.
O script utilizado para a criação de projetos pode ser visualizado no quadro
apresentado na Figura 44.
Figura 44 - Script utilizado para a criação de projetos
#!/bin/bash
# Maurício S. Silva
# 02/2013
#
#$1 = identificador_projeto
#$2 = caminho do diretório projects ex: /var/www/projetoTCC/projects
#$3 = senha do usuário do projeto
#$4 = criar svn? true or false
#$5 = local do arquivo de template ex. /var/www/projetoTCC/template_svn
#$6 = url do servidor
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
91
#Adicionar um usuário para o projeto
adduser --disabled-password --disabled-login --force-badname --gecos "" $1
#Fazer o link simbólico entre os diretórios (“projects”e “home”)
ln -s $2/$1/ /home/$1/public_html
#Adicionar o arquivo .htaccess no diretório public_html
echo "AuthUserFile /home/$1/public_html/.htpasswd">/home/$1/public_html/.htaccess
echo "AuthType Basic">>/home/$1/public_html/.htaccess
echo 'AuthName "Required Auth"'>>/home/$1/public_html/.htaccess
echo "Require valid-user">>/home/$1/public_html/.htaccess
echo 'php_value open_basedir "/home/'$1'/public_html"'>>/home/$1/public_html/.htaccess
echo 'php_flag log_errors on'>>/home/$1/public_html/.htaccess
echo "php_value error_log /home/$1/public_html/PHP_errors.log">>/home/$1/public_html/.htaccess
# o arquivo error.log precisa ser criado.
echo "## error log for project: $1 ##">>/home/$1/public_html/PHP_errors.log
#Criar o arquivo .htpasswd com o usuário e senha do usuário do projeto
htpasswd -b -c /home/$1/public_html/.htpasswd $1 $3
#caso seja para criar o projeto no subversion
if [ $4 == 'true' ]; then
#cria o repositório
svnadmin create /usr/local/svnprojects/$1
#busca arquivos no template
svn import $5 file:///usr/local/svnprojects/$1 -m "Release 1.0"
# remove a configuração padrão
rm -rf /usr/local/svnprojects/$1/conf/svnserve.conf
#cria um novo conf
echo '[general]'>/usr/local/svnprojects/$1/conf/svnserve.conf
echo 'anon-access = none'>>/usr/local/svnprojects/$1/conf/svnserve.conf
echo 'auth-access = write'>>/usr/local/svnprojects/$1/conf/svnserve.conf
echo 'password-db = passwd'>>/usr/local/svnprojects/$1/conf/svnserve.conf
echo '[sasl]'>>/usr/local/svnprojects/$1/conf/svnserve.conf
#adiciona usuário no arquivo de senhas do svn
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
92
echo "$1 = $3">>/usr/local/svnprojects/$1/conf/passwd
#faz o checkout do projeto
svn checkout svn://$6//usr/local/svnprojects/$1/ $2/$1 --username=$1 --password=$3
chown -R www-data:www-data $2/$1
chmod 775 $2/$1
fi
#Muda as permissões dos arquivos .htaccess, .htpasswd e PHP_errors.log
chown root:www-data /home/$1/public_html/.htaccess
chmod 440 /home/$1/public_html/.htaccess
chown root:www-data /home/$1/public_html/.htpasswd
chmod 440 /home/$1/public_html/.htpasswd
chown root:www-data /home/$1/public_html/PHP_errors.log
chmod 664 /home/$1/public_html/PHP_errors.log
Fonte: criado pelo autor.
4.6.3 Criação de bases de dados para projetos
A criação de bases de dados para os projetos gerenciados pelo CollabCode
trabalha diretamente com a criação de usuários e permissões do banco de dados
PostgreSQL. Quando uma nova base de dados é adicionada a um determinado
projeto, o CollabCode verifica a existência de um usuário para o projeto cadastrado
no PostgreSQL; caso o usuário exista, efetua o acesso com esse usuário e cria a
base de dados. Caso o usuário não exista, ele é criado com permissão de criar e
gerenciar bases de dados a ele pertencentes. Este processo é detalhado no
diagrama de sequência disponível no Apêndice B.
É importante compreender que o gerenciamento de usuários do banco de
dados é feito diretamente no PostgreSQL e não no CollabCode. A interface
disponível para manipulação das bases de dados no editor utiliza o usuário e a
senha do projeto para realizar as transações da aplicação hospedada, o que torna
as bases de dados dos demais projetos inacessíveis.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
93
4.6.4 Edição colaborativa
Entender como funciona o processo de colaboração entre dois ou mais
desenvolvedores utilizando o CollabCode é de fundamental importância para os
objetivos deste trabalho, uma vez que não se trata apenas de interações Homem x
Máquina, e sim Homem x Homem utilizando uma Máquina. Como forma de facilitar o
entendimento, foram criados dois diagramas. O primeiro detalha o funcionamento da
edição colaborativa no lado do servidor (Figura 45). O segundo detalha o
funcionamento da colaboração no navegador do desenvolvedor (Figura 46).
Figura 45 - Funcionamento do servidor de edição colaborativa
Fonte: criado pelo autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
94
Figura 46 – Funcionamento da edição colaborativa no navegador
Fonte: criado pelo autor.
Quando um desenvolvedor abre um arquivo que já está sendo editado por
outro desenvolvedor, o processo que permite a colaboração entre eles é iniciado. O
desenvolvedor que já estava com o arquivo aberto possui sua seção de edição
travada até que a colaboração inicie. Esta pequena pausa é necessária para
sincronizar o conteúdo do editor entre os desenvolvedores em colaboração. Em
seguida, o processo apresentado na Figura 46 é iniciado.
Quando o navegador do desenvolvedor abre a conexão, o servidor realiza
uma verificação no arquivo, pois este pode já estar sendo editado em simultâneo por
outros desenvolvedores. Caso já esteja, o servidor repassa o documento que está
em edição e começa a aguardar as modificações provenientes desta conexão. Caso
o arquivo não estiver sendo modificado, o servidor cria o documento com base nas
informações que recebeu, além disso, o servidor mantém uma listagem de conexões
vinculadas a cada um dos arquivos que está em edição simultânea. Esta listagem é
utilizada para fornecer as informações de quem deve receber as modificações de
cada arquivo.
No navegador do desenvolvedor, o editor começa a aguardar as modificações
do servidor e a enviar todas as modificações feitas localmente. Quando um
desenvolvedor pressiona uma tecla, antes mesmo que ela apareça no editor, é
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
95
encaminhada para o servidor. O servidor, por sua vez, propaga a modificação para
as demais conexões. Sempre que modificações provenientes de outros usuários são
aplicadas, uma checagem de sincronia entre o arquivo local e o que está no servidor
é feita. Esta checagem previne que os desenvolvedores tenham versões diferentes
do mesmo arquivo em edição, uma vez que é possível haver problemas de conexão
durante a edição simultânea.
4.6.5 Componentes utilizados
A interface do CollabCode foi construída utilizando diversas bibliotecas de
código livre disponíveis na Internet. O diagrama de componentes apresentado na
Figura 47 traz todos os componentes utilizados para a construção da interface
CollabCode. Na Tabela 5 são apresentadas as versões e uma pequena descrição
sobre cada componente.
Figura 47 - Diagrama de componentes da interface do CollabCode
Fonte: criado pelo autor.
Tabela 5 - Bibliotecas utilizadas na interface do CollabCode
Biblioteca Versão Descrição
JQuery 1.8.3 Framework JavaScript que permite que os desenvolvedores concentrem-se na lógica de construção dos sistemas e não nos problemas de compatibilidade entre navegadores.
JQuery UI 1.9.2 Framework para a construção de interfaces que utiliza o JQuery como base.
JQuery UI Layout 1.3 Componente que permite a criação de layouts dinâmicos. JQuery TE 1.3.2 Componente utilizado para fazer edições de texto simples. Dynatree 1.2.2 Componente que permite a construção dinâmica de árvores HTML
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
96
Biblioteca Versão Descrição
controladas por JavaScript. GanttView 0.8.8 Componente utilizado para criar gráficos de Gantt. Esta biblioteca
serviu como base para que o autor criasse sua própria biblioteca de geração de gráficos de Gantt.
CodeMirror 3 Componente utilizado como editor de código-fonte. Flexigrid 1.1 Componente que facilita a visualização de informações em forma
de tabela. SyntaxHighLighter 3.0.83 Componente utilizado para destacar trechos de código-fonte.
Fonte: criado pelo autor.
4.7 Configurações de segurança
O projeto do CollabCode precisou contemplar algumas medidas de segurança
que possibilitassem o isolamento de cada projeto hospedado. Este conjunto de
medidas permite que diversos projetos independentes trabalhem simultaneamente
sem a preocupação de ter seus dados ou informações disponibilizados para os
membros de outros projetos.
Grande parte deste isolamento é feito pela utilização do usuário e senha
criados juntamente com o projeto. Essas informações são utilizadas para autenticar
o usuário que efetuará commit das atividades no Subversion, para realizar
transações nas bases de dados dos projetos, para acessar a área de pré-
visualização do projeto, dentre outros. Apesar disso, em várias destas ações, o
CollabCode interage com o restante do sistema computacional utilizando esse
usuário e senha de forma transparente, sem a necessidade da digitação destas
informações repetidamente.
Outra medida de segurança adotada pelo CollabCode foi a adição dos
módulos “mod_auth”, “php5_module” e “userdir_module” no servidor web Apache. O
módulo “mod_auth” é utilizado para solicitar autenticação em alguns locais do
sistema, como acontece na área de pré-visualização do projeto. O módulo
“php5_module” permite a personalização das configurações do PHP por meio de
arquivos .htaccess. Já o módulo “userdir_module” é utilizado para separar cada
projeto em um diretório home do sistema operacional.
A personalização da configuração do PHP para cada projeto também foi uma
forma de garantir a integridade do sistema. Utilizando arquivos .htaccess foi possível
fazer a separação dos logs de erros de cada aplicação, evitando que os
participantes de um projeto tenham acesso às vulnerabilidades das outras
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
97
aplicações hospedadas. A personalização da configuração do PHP também permitiu
restringir o acesso das aplicações aos diretórios do sistema operacional. No mesmo
arquivo .htaccess que efetua a separação dos logs, foi adicionada uma linha que
altera a diretiva “open_basedir” do PHP. Essa diretiva é responsável por garantir que
o acesso dos scripts PHP (via fopen ou qualquer comando de varredura de
diretórios) seja limitado ao diretório home de sua aplicação. Qualquer tentativa de
acessar informações fora deste escopo será reportada e retornará em forma de
mensagem de erro no log da aplicação que está tentando efetuar esta ação.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
98
5 CONCLUSÃO
O atual cenário mundial, no qual as tecnologias estão cada vez mais
acessíveis e o mundo mais conectado, permite que empresas adaptem seus
processos de forma a torná-los globais. Essa postura adotada pelas empresas visa
explorar novos mercados e buscar diferenciais estratégicos que tornem seu produto
mais competitivo. Nesse sentido, a descentralização do processo de fabricação
representa vantagens tanto na logística quanto na venda de seus produtos.
Em empresas de desenvolvimento de software a realidade não é diferente. A
busca por diferenciais estratégicos tem feito as empresas de desenvolvimento de
software adotar o Desenvolvimento Distribuído de Software. Esta mudança impacta
diretamente na forma como o software é construído, uma vez que os métodos
tradicionais de engenharia de software não foram criados considerando esta
realidade emergente.
Os desafios gerados pelo DDS vão além das adaptações necessárias ao
desenvolvimento tradicional de software. Metodologias ágeis como eXtreme
Programming e Scrum também não foram projetadas para serem utilizadas em
ambientes distribuídos de desenvolvimento. Tanto as metodologias tradicionais
quanto as ágeis precisam ser foco de pesquisas que as qualifiquem de modo a
suprir as necessidades do Desenvolvimento Distribuído de Software.
Além disso, durante a elaboração do presente trabalho, não foram
encontradas ferramentas que atendam a todas as necessidades do DDS com
suporte a métodos ágeis de desenvolvimento. Foram encontradas apenas
ferramentas criadas/adaptadas a fim de suprir carências pontuais do DDS. Isso faz
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
99
com que as equipes distribuídas tenham que utilizar uma série de aplicativos sem
integração que, por vezes, dificulta a administração e cruzamento de informações
inerentes ao projeto, podendo impactar diretamente no seu prazo de entrega ou
orçamento.
Ao longo do presente trabalho, foram abordados diversos assuntos referentes
ao desenvolvimento de aplicações de forma colaborativa e distribuída. Em diversas
seções, as ferramentas necessárias a uma solução que atenda a este modelo de
desenvolvimento foram evidenciadas. O estudo realizado para construir o referencial
teórico e a análise de algumas ferramentas existentes facilitou a construção do
projeto e a implementação do CollabCode, que, na visão do autor, é capaz de
atender de forma equilibrada às necessidades inerentes ao desenvolvimento
colaborativo e distribuído de software, com suporte a metodologias ágeis de
desenvolvimento.
O estudo teórico também serviu como base para elucidar os principais
problemas enfrentados pelas equipes de desenvolvimento de software,
independente de metodologia utilizada ou nível de dispersão da equipe. A
identificação desses problemas contribui para que novas ferramentas sejam criadas
com foco na solução ou diminuição dos impactos por eles gerados.
A principal contribuição deste trabalho foi disponibilizar uma nova opção para
a crescente demanda do mercado por soluções que possibilitem tornar seus
processos mais ágeis e que facilitem a colaboração e comunicação. Neste contexto,
o CollabCode pode oferecer um ambiente de trabalho que permita a colaboração e
comunicação entre os membros da equipe que estão geograficamente distribuídos.
O CollabCode também pode agregar qualidade ao software nele
desenvolvido. A construção coletiva e dinâmica com o suporte correto é um
ambiente propício à inovação e à melhoria dos processos envolvidos.
5.1 Trabalhos Futuros
Durante o desenvolvimento do presente trabalho surgiram novas ideias e
recursos que poderiam compor a ferramenta desenvolvida. Estes recursos foram
adicionados aos requisitos do sistema como desejáveis, que não foram
implementados e formam a base para trabalhos futuros. Além disso, faz-se
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
100
necessária a avaliação da ferramenta em um ambiente real de produção, o que pode
ser feito por meio de um estudo de caso.
Também sugere-se como trabalho futuro a realização de uma pesquisa
envolvendo diferentes empresas de desenvolvimento de software que possuam
equipes geograficamente dispersas e utilizem metodologias ágeis em seu processo
de desenvolvimento. Além de validar a ferramenta, com este estudo será possível
identificar novas funcionalidades que devem ser adicionadas ao CollabCode.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
101
REFERÊNCIAS
ALMEIDA, Ricardo; AZEVEDO, Américo. Collaborative business networks : evaluation of
technological tools for decision support making. e-LP Engineering and Technology
Journal, Porto, v. 2 , 2011. Disponível em:
<http://recil.grupolusofona.pt/handle/10437/2860> . Acesso em: 22 set. 2012.
AMBLER, Scott W. Modelagem ágil: práticas eficazes para a programação extrema e o
processo unificado. Porto Alegre: Bookman, 2004.
AUDY, Jorge L. N.; ANDRADE, Gilberto Keller de.; CIDRAL, Alexandre. Fundamentos
de Sistemas de Informação. Porto Alegre: Bookman, 2005. E-book. Disponível
em:<http://www.univates.br/biblioteca>. Acesso em: 7 set. 2012.
AUDY, Jorge L. N.; PRIKLADNICKI, Rafael. Desenvolvimento distribuído de software:
desenvolvimento de software com equipes distribuídas. Rio de Janeiro: Elsevier, 2008.
BALL, Bill; DUFF, Hoyt. Dominando Linux red hat e fedora. São Paulo: Pearson Makron
Books, 2004. E-book. Disponível em: <http://www.univates.br/biblioteca >. Acesso em: 6
out. 2012.
BENBUNAN-FICH, R.; HILTZ, S.R. Impacts of Asynchronous Learning Networks on
Individual and Group Problem Solving: A Field Experiment, Group Decision and
Negotiation, Vol.8, p. 409-426, Netherlands, 1999. Disponível em: <
http://www.seedwiki.com/accounts/dolansky_sara_24405/AsynchronousImpactOnDecisionm
aking.pdf >. Acessado em: 15 mai. 2013.
BRITO, Ronnie F.; PEREIRA, Alice T. C. Um estudo para ambientes colaborativos e suas
ferramentas. Congresso Nacional de Ambiente Hipermídia para Aprendizagem.
Florianópolis, 2004. Disponível em:<
http://www.avaad.ufsc.br/moodle/prelogin/publicarartigos/artigos04/ronnieconahpa.pdf >.
Acesso em: 19 ago. 2012.
BRUM, Larissa C. C. Do table ao tablete: O avanço das novas tecnologias no ensino de
línguas estrangeiras. V Encontro Nacional de Professores de Letras e Artes
(ENLETRART). Campos do Goytacazes, 2011. Disponível em:<
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
102
http://www.essentiaeditora.iff.edu.br/index.php/enletrarte/article/view/2054>. Acesso em: 16
nov. 2012.
CARMEL, Erran; TJIA, Paul. Offshoring Information Technology: Sourcing and
Outsourcing to a Global Workforce. Cambridge: Cambridge University Press, 2005. E-book.
Disponível em:< http://books.google.com.br >. Acesso em: 6 out. 2012.
CESAR, Paulo; FARIAS, Bento. Cursos essencial de Redes: Tudo que você precisa saber
sobre redes de computadores. São Paulo: Digerati Editorial, 2006. E-book. Disponível em:
<http://books.google.com.br >. Acesso em: 16 nov. 2012.
COAD, Peter; LEFEBVRE, Eric; DELUCA, Jeff. Java Modeling in color with UML. Upper
Saddle River: Prentice Hall, 1999.
CONALLEN, Jim. Building Web Applications with UML. 2.ed. San Francisco: Addison-
Wesley Professional, 2002. E-book. Disponível em: <http://books.google.com.br >. Acesso
em: 09 out. 2012.
COULOURIS, George; DOLLIMORE, Jean; Kindberg, Tim. Sistemas distribuídos:
conceitos e projetos. Porto Alegre: Bookman, 2007. E-book. Disponível em:<
http://books.google.com.br >. Acesso em: 7 set. 2012.
CRUZ, Jorge A. S; FLORES, Daniel; GARCIA, Olga M. C. O Prontuário Eletrônico de
Paciente (PEP) como memória, patrimônio documental e cultural. Em Questão, vol. 17,
2011. Disponível em:
<http://revistas.univerciencia.org/index.php/revistaemquestao/article/viewArticle/7890>.
Acesso em 16 nov. 2012.
DEITEL, Harvey M.; DEITEL, Paul J.; CHOFFNES, David R. Sistemas Operacionais. 3.ed.
São Paulo: Pearson, 2005. E-book. Disponível em: <http://www.univates.br/biblioteca>.
Acesso em: 25 ago. 2012.
ENAMI, Lúcia N. M. Um modelo de gerenciamento de projetos para um ambiente de
desenvolvimento distribuído de software. 2006. 217 f. Dissertação (Mestrado) – Ciência da
Computação, Universidade Estadual de Maringá, Maringá, 19 jul.2006. Disponível em:
<http://www.din.uem.br/~mestrado/diss/2006/enami.pdf>. Acesso em: 26 set. 2012.
FLANAGAN, David. JavaScript: O guia definitivo. 4ª ed. São Paulo: Bookman, 2002.
FUKS, H.; GEROSA, M.A.; PIMENTEL, M. Projeto de Comunicação em Groupware:
Desenvolvimento, Interface e Utilização. Anais do XXIII Congresso da Sociedade
Brasileira de Computação, Campinas, Cap 7, p. 295-338, 2003. Disponível em:
<http://ritv.les.inf.puc-rio.br/work.jsf?p1=2090#ixzz29OWODRoc >. Acesso em: 01 set.
2012
FUKS, H.; RAPOSO, A.B.; GEROSA, M.A. Do Modelo de Colaboração 3C à Engenharia de
Groupware. Simpósio Brasileiro de Sistemas Multimídia e Web, Salvador, 2003.
Disponível em: <http://pcgerosa.ime.usp.br/public/papers/Webmedia2003.pdf >. Acesso em:
20 set. 2012.
FUKS, H.; RAPOSO, A.B.; GEROSA, M.A. Engenharia de Groupware: Desenvolvimento de
Aplicações Colaborativas. XXI Jornada de Atualização em Informática Anais do XXII
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
103
Congresso da Sociedade Brasileira de Computação, Florianópolis, p. 89-128, 2002.
Disponível em: < http://www.tecgraf.puc-rio.br/~abraposo/pubs/JAI2002/JAI2002.pdf>.
Acesso em: 20 set. 2012.
GÄRTNER, Vilson C. Um ambiente integrado para apoio ao desenvolvimento
distribuído de software. 2011. 161 f. Dissertação (Mestrado) – Computação Aplicada,
Universidade do Vale do Rio dos Sinos (UNISINOS), São Leopoldo. Disponível em: <
http://bdtd.unisinos.br/tde_arquivos/1/TDE-2011-10-19T111011Z-
1541/Publico/VilsonGartnerComputacao.pdf>. Acesso em: 20 ago. 2012.
GEROSA, Marco A. Desenvolvimento de Groupware Componentizado com Base no
Modelo 3C de Colaboração. 2006. 276 f. Tese (Doutorado) – Pós-Graduação em
Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), Rio de Janeiro.
Disponível em: < http://www.maxwell.lambda.ele.puc-rio.br/8665/8665_1.PDF >. Acesso
em: 25 ago. 2012.
GEROSA, M.A.; PIMENTEL, M.G.; FILIPPO, D.; BARRETO, C.G.; RAPOSO, A.B.;
FUKS, H. ; LUCENA, C.J.P. Componentes Baseados no Modelo 3C para o Desenvolvimento
de Ferramentas Colaborativas. Anais do 5º Workshop de Desenvolvimento Baseado em
Componentes, Juiz de Fora, p.109-112, 2005. Disponível em:
<http://groupware.secondlab.inf.puc-rio.br/public/papers/WDBC.2005.Gerosa.pdf >. Acesso
em: 08 set. 2012.
GONÇALVES, Edson. Desenvolvendo aplicações web com jsp, servelets, javaserver
faces, hibernate, ejb 3 persistence e ajax. Rio de Janeiro: Ciência Moderna, 2007.
GONÇALVES, Eduardo dos S; FILHO, Heitor B. R. Ferramenta para Gerenciamento de
Requisitos em Metodologias Ágeis. HÍFEN, Uruguaiana, v. 32, 2008. Disponível em:
<http://revistaseletronicas.pucrs.br/ojs/index.php/hifen/article/view/4593 >. Acesso em: 28
set. 2012.
HILDENBRAND, Tobias; ROTHLAUF, Franz; GEISSER, Michael; HEINZL, Armin;
KUDE, Thomas. Approaches to Collaborative Software Development. International
Conference on Complex, Intelligent and Software Intensive Systems, Mannheim, p. 523-
528, 2008. Disponível em: < http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4606729
>. Acesso em: 28 set. 2012.
JARGAS, Aurélio M. Shell Script Profissional. São Paulo: Novatec, 2008.
JÚNIOR, José H. C. R. Linguagens de Programação para a Internet: estudo comparativo.
2005. 87 f. Monografia (Especialização) – Análise de Sistemas, Pontífica Universidade
Católica de Minas Gerais (PUC-MG), Belo Horizonte, 31 mai. 2005. Disponível em:
<https://www.jhcruvinel.com/index.php?option=com_docman&task=doc_view&gid=59>.
Acesso em: 20 set. 2012.
LOPES, Leandro T.; Um modelo de processo de engenharia de requisitos para ambientes
de desenvolvimento distribuído de software. 2004. 142 f. Dissertação (Mestrado) – Ciência
da Computação, Universidade Católica do Rio Grande do Sul (PUCRS), Porto Alegre, 28 jun.
2006. Disponível em: < http://tede.pucrs.br/tde_arquivos/4/TDE-2006-10-31T182548Z-
95/Publico/384394.pdf >. Acesso em: 20 ago. 2012.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
104
MARCELO, Antonio. APACHE: Configurando o servidor WEB para Linux. 3.ed. Rio de
Janeiro: Brasport, 2005. E-book. Disponível em: <http://books.google.com.br >. Acesso em: 7
out. 2012.
MORIMOTO, Carlos E. Servidores linux: guia prático. Porto Alegre: Sul Editores, 2011.
MURTA, Leonardo G. P. ODYSSEY-SCM: uma abordagem de gerência de configuração de
software para o desenvolvimento baseado em componentes. 2004. 111 f. Dissertação
(Mestrado) - Engenharia de Sistemas e Computação, Universidade Federal do Rio de Janeiro,
Rio de Janeiro. Disponível em: <http://www.ic.uff.br/~leomurta/papers/murta2004b.pdf> .
Acesso em: 31 ago. 2012.
NEMETH, Evi; SNYDER, Garth; HEIN, Trent R. Manual completo do Linux guia do
administrador. 2.ed. São Paulo: Pearson Prentice Hall, 2007. E-book. Disponível em:<
http://www.univates.br/biblioteca >. Acesso em: 27 out 2012.
NUNAMAKER, Jay F.. Collaborative Computing: The Next Millennium. Computer, p.66-
71, set. 1999. Disponível em:
<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=789753>. Acesso em: 09 set.
2012.
OLIVEIRA, Halley P. Documentação do PostgreSQL 8.0.0: Projeto de Tradução para o
Português do Brasil. Rio de Janeiro: 2007. E-book. Disponível em:
<http://pgdocptbr.sourceforge.net/>. Acesso em: 02 nov. 2012.
OLIVEIRA, Hamilton L. R. de. ODYSSEY-VCS: Uma Abordagem de Controle de Versões
para Elementos da UML. 2005. 94 f. Dissertação (Mestrado) – Ciências em engenharia de
sistemas e computação, Universidade Federal do Rio de Janeiro (UFRJ), Rio de Janeiro.
Disponivel em:
<http://reuse.cos.ufrj.br/files/publicacoes/mestrado/Mes_OliveiraHamilton_OdysseyVCS.pdf
>. Acesso em: 31 ago. 2012.
PRESSMAN, Roger S. Engenharia de software. 6.ed. Porto Alegre: AMGH, 2010.
PRIKLADNICKI, Rafael. Desenvolvimento distribuído de software e processos de
desenvolvimento de software. 2002. 66 f. Trabalho (Mestrado) – Ciência da Computação,
Universidade Católica do Rio Grande do Sul (PUCRS), Porto Alegre, 30 ago. 2002.
Disponível em: < http://www.inf.pucrs.br/munddos/docs/TI2.pdf>. Acesso em: 20 ago. 2012.
PRIKLADNICKI, Rafael. MuNDDoS Um modelo de referência para desenvolvimento
distribuído de software. 2003. 144 f. Dissertação (Mestrado) – Ciência da Computação,
Universidade Católica do Rio Grande do Sul (PUCRS), Porto Alegre. Disponível em: <
http://www.igor.pro.br/utfpr/arquivos/CSCW/Diss_prikladnick.pdf >. Acesso em: 25 ago.
2012.
PRIKLADNICKI, Rafael; AUDY, Jorge L. N. Uma Análise Comparativa de práticas de
Desenvolvimento Distribuído de Software no Brasil e no exterior. XX Simpósio Brasileiro
de Engenharia de Software, Florianópolis, p.255-270, 2006. Disponível em:
<http://www.lbd.dcc.ufmg.br/colecoes/sbes/2006/017.pdf>. Acesso em: 20 set. 2012.
REIS, Cristian R. Uma Visão Geral do Bugzilla, uma Ferramenta de Acompanhamento de
Alterações. XVI Simpósio Brasileiro de Engenharia de Software. Gramado, 2002.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
105
Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/sbes/2002/022.pdf>. Acesso em: 16
nov. 2012.
SÁ, Paulo S. S. Gerador Automático de Arquivos HTML de Ajuda para Aplicação em
Educação a Distância (GAAHA). 2000. 89 f. Dissertação (Mestrado) – Ciências da
Computação e Matemática Computacional, Universidade de São Paulo (USP), São Carlos.
Disponível em: <http://www.java.icmc.sc.usp.br/wiki/images/2/29/Paulo_Sa_Tese.pdf>.
Acesso em: 25 ago. 2012.
SHATZ, Sol M.; WANG Jia-Ping. Distributed-Software Engineering. New York: IEEE
Computer Society Press, 1989. E-book . Disponível em: <http://books.google.com.br >.
Acesso em: 15 set. 2012.
SILVA, Lucas da; SILVA, Maurício S. da; RABAIOLLI, Nataniel. Sistema de inventário
baseado em dispositivos móveis. VII WET Workshop de Engenharia e Tecnologia – VI
CCTEC Congresso de Ciência e Tecnologia do Vale do Taquari, Lajeado, 2012.
Disponível em:< http://www.univates.br/editora-univates/media/publicacoes/3/pdf_3.pdf >.
Acesso em: 16 nov. 2012.
SILVA, Nelson P. da. Projeto e desenvolvimento de sistemas. 9.ed. São Paulo: Érica, 2001.
SOARES, Michel dos S. Metodologias Ágeis Extreme Programming e Scrum para o
Desenvolvimento de Software. Revista Eletrônica de Sistemas de Informação (RESI), v.3,
2004. Disponível
em:<http://revistas.facecla.com.br/index.php/reinfo/article/viewArticle/146>. Acesso em: 28
set. 2012.
SOMMERVILLE, Ian. Engenharia de software. 8.ed. São Paulo: Pearson Addison-Wesley,
2007.
SOUZA, Marcel F. Segurança em servidores de correio eletrônico. 2006. 78 f. Monografia
(Especialização) – Segurança da Informação, Faculdade de Ciências Aplicadas de Minas
Gerais da União Educacional Minas Gerais (UNIMINAS), Uberlândia, 13 mai. 2006.
Disponível em: <http://www.si.lopesgazzani.com.br/TFC/monografias/marcel_mono_Pos
46.pdf>. Acesso em: 20 set. 2012.
STEVENS, Richard W. TCP/IP Illustrated: The protocols. USA: Addison-Wesley, 1994. E-
book. Disponível em:< http://books.google.com.br >. Acesso em: 7 set. 2012.
TANENBAUM, Andrew S. Sistemas operacionais modernos. 2.ed. São Paulo: Prentice
Hall, 2003.
TEIXEIRA, Mário A. M. Suporte a serviços diferenciados em servidores web: modelos e
algoritmos. 2004. 140 f. Tese (Doutorado) - Ciências de Computação e Matemática
Computacional, o Instituto de Ciências Matemáticas e de Computação (ICMC-USP), São
Carlos, 13 mai. 2004. Disponível em:
<http://www.deinf.ufma.br/~mario/producao/tese_swds.pdf>. Acesso em 20 set. 2012.
TEIXEIRA, Roberto. Guia prático do servidor Linux. Curitiba: Conectiva, 2000.
TIETZE, Daniel A. A Framework for Developing Component-based Co-operative
Applications. 2001. 173 f. Dissertação (Mestrado) – Engenharia, Technischen Universität,
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
106
Darmstadt. Disponível em: <ftp://dmz02.kom.e-technik.tu-darmstadt.de/papers/Tie01-1-
paper.pdf >. Acesso em: 29 set. 2012.
TOMMARELLO, Joana D; DEEK, Fadi P. Collaborative Software Development: A
Discussion of Problem Solving Models and Groupware Technologies. 35th Hawaii
International Conference on System Sciences, Hawaii, p. 568 – 577, 2002. Disponível em:
< http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=993937>. Acesso em: 28 set. 2012.
VARGAS, Ricardo V. Manual prático do plano de projeto: utilizando o PMBOK Guide.
3.ed. Rio de janeiro: Brasport, 2007. E-book. Disponível em:< http://books.google.com.br >.
Acesso em: 6 out. 2012.
WINCKLER, Marco Antônio; PIMENTA, Marcelo Soares. Avaliação de Usabilidade de
Sites Web. Escola de Informática da SBC Sul, Porto Alegre, v. 1, p. 336-347, 2002.
Disponível em: <http://www.irit.fr/~Marco.Winckler/2002-winckler-pimenta-ERI-2002-
cap3.pdf >. Acesso em: 29 set. 2012.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
107
APÊNDICES
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
108
Apêndice A – Diagrama de sequência da criação de projetos
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
109
Apêndice B - Diagrama de sequência da criação de bases de dados para projetos
