DGERT   APCER
Relações de compromisso

Ferramentas de Desenvolvimento Colaborativo


Ferramentas

As ferramentas que suportam o desenvolvimento colaborativo são uma área que está pronta para ideias novas e inovadoras. Se um aluno de uma licenciatura relacionada com informática se mostrar interessado em construir ferramentas para o desenvolvimento de software, um professor atento à realidade iria encorajá-lo certamente a considerar as ferramentas de desenvolvimento colaborativo e a forma como esta tecnologia pode responder às necessidades das equipas distribuídas em termos geográficos e temporais.

O que torna as ferramentas de desenvolvimento colaborativo tão interessantes é o facto de existirem oportunidades de curto e de longo prazo. No curto prazo, é necessário adaptar as ferramentas existentes para fazer com que permitam suportar a colaboração distribuída. Muitas ferramentas têm algum suporte para estes cenários nas suas capacidades para suportarem múltiplos utilizadores. As ferramentas de gestão de requisitos, de gestão de código fonte, e de controlo de versões disponibilizam um bom suporte para múltiplos utilizadores há vários anos.

O software de controlo de versão tem sido a principal abordagem para a partilha de artefactos em projectos criados com ferramentas que não suportam múltiplos utilizadores. Frequentemente, também se armazenam documentos, planos, desenhos e outros artefactos em algum tipo de repositório de equipa, de modo a disponibilizá-los de forma consistente a outros membros da equipa. O repositório central permite um acesso controlado aos materiais por parte de todos os membros da equipa, além de apresentar uma visão consistente do projecto para toda a gente. Os repositórios distribuídos tornaram-se uma realidade, mas ainda estão muito aquém dos repositórios centrais.

Actualmente, existem algumas ferramentas que são designadas pelos seus fornecedores como CDEs (collaborative development environments, ou ambientes de desenvolvimento colaborativos). No entanto, o desenvolvimento colaborativo incluído em algumas dessas ferramentas resume-se a uma repositório central para as equipas partilharem e comunicarem artefactos, incluindo código. Cada um desses ambientes utiliza uma base de dados para o armazenamento de artefactos e para algum tipo de ferramenta de controlo de versões para a gestão de código fonte. No entanto, têm extensões que lhes permitem utilizar ferramentas externas para criar e gerir os artefactos da equipa.

Continua a não existir uma boa solução

É interessante ter um CDE para trabalhar, mas continuam a existir várias coisas que inibem uma verdadeira colaboração ao nível de uma equipa. Podemos dizer que se costumam encontrar dois grandes problemas:

  • A utilização de ferramentas diferentes para propósitos diferentes força a mudança de contextos com demasiada frequência;
  • A utilização de diferentes ferramentas que tenham sobreposições funcionais cria confusão. 

Examinemos mais em pormenor cada uma destas questões. Considere o que acontecerá se estivermos a trabalhar no nosso ambiente de programação (IDE) e precisarmos de ver a última API ou diagrama UML para um módulo que iremos integrar através de algum serviço Web. É possível que a informação que precisamos esteja no sistema de gestão do código fonte que estamos a utilizar, ao qual o nosso IDE se pode ligar. Se fosse esse o caso, seria possível a visualização pretendida no IDE.

Mas o que aconteceria se o artefacto de que precisamos estivesse noutro tipo de repositório? Nesse caso, teríamos de sair do IDE, localizar o documento, importá-lo para a nossa máquina e tentar visualizá-lo. Possivelmente, a visualização ainda teria que ser realizada com a ajuda de uma terceira ferramenta. A solução ideal seria localizar o documento e visualizá-lo a partir do IDE.

Ocorre um problema mais sério quando se têm diferentes ferramentas com funcionalidades redundantes. É necessário mudar de contexto para aceder a cada um dos produtos e utilizar provavelmente diferentes entidades de login. Este problema agrava-se ainda mais se estivermos a trabalhar num projecto com equipas de desenvolvimento distribuídas, uma vez que cada uma delas poderá utilizar um conjunto diferente de ferramentas para determinadas funções. A colaboração entre as várias equipas só será possível de todas acordarem num ambiente uniforme para o projecto, ou se duplicarem artefactos e mantiverem ambientes distintos devidamente sincronizados, o que implica uma grande quantidade de esforço. Nenhuma destas opções é uma solução aceitável.

O futuro das ferramentas de desenvolvimento colaborativo

Se quisermos colaborar numa base global, temos que ser capazes de aliar culturas e ferramentas de desenvolvimento. Isto exigirá ambientes extremamente flexíveis, permitindo que as ferramentas trabalhem em conjunto de forma eficaz. É bastante fácil satisfazer preferências individuais para ferramentas como editores de texto. Na realidade, nada tem que ser feito a este propósito. No entanto, quando se está a trabalhar numa base de código que está armazenada parcialmente num repositório ClearCase e parcialmente num repositório Subversion, será necessária uma ferramenta que faça a ponte. Para isto, é necessário que aconteçam duas coisas:

  • As ferramentas individuais têm de ser abertas. Por "abertas" entenda-se aqui que precisam de ter uma API bem definida que permita a integração com outras ferramentas. As ferramentas não precisam de ser open source, mas precisam de ter interfaces abertas.
  • As ferramentas de colaboração têm de estar construídas de forma a permitirem abstrair facilmente os conceitos necessário pelas equipas de desenvolvimento distribuído, bem como resolver conflitos e representar esses conceitos sob a forma de artefactos no ambiente de cada equipa.

Algumas ferramentas satisfazem a primeira condição. O Eclipse e o NetBeans, por exemplo, são dois IDEs que são projectos open source e que têm uma API publicada para a construção de extensões para eles. De forma similar, o SourceForge e o Rally têm APIs para integração com eles. Contudo, as APIs variam consideravelmente em qualidade, devido principalmente à maturidade do produto. Consequentemente, este problema tende a melhorar ao longo do tempo.

Um problema mais difícil é a satisfação da segunda condição. Precisamos de uma ferramenta que permita a sincronização dos artefactos do projecto, mesmo que eles sejam bastante diferentes. Uma vez resolvidos estes problemas, estaremos no bom caminho para melhores ambientes de desenvolvimento colaborativo. As perspectivas relativamente às adições das ferramentas colaborativas são fantásticas. Iremos ver, por exemplo, tecnologia de comunicação integrada nos nossos IDEs. Veremos igualmente formas de anotações de vídeo e de áudio, de modo a fazer com que os requisitos sejam mais precisos e fáceis de compreender entre diferentes culturas.

Baseado num artigo intitulado "Collaboration in a flat world -- Part One: Collaboration development tools", da autoria de Gary Pollice e publicado na Rational Edge.

Topo
Pesquisa
Agenda
Destaques