Trabalhos futuros

Alguns aspectos não contemplados no escopo deste trabalho demandam outros esforços no sentido de otimizar o CVSyn. A primeira sugestão é o melhoramento da

interface do CVSyn para permitir que o cadastro das fontes, objetos e consumidores de informação possa ser realizado através da interface desta ferramenta. Não foi possível atender este requisito nesta versão da ferramenta.

O CVSyn consegue atender às demandas em se tratando de contextos em que a ferramenta de controle de versão adotada é o CVS. Dependendo do cenário em questão, pode haver necessidade de múltiplos repositórios de artefatos, sendo que estes não necessariamente precisam ser do mesmo tipo. Um trabalho futuro poderia ser orientado à construção de um framework que possibilite o monitoramento de outras ferramentas de controle de versão.

Atualmente, a solução permite que a estratégia de monitoramento dos eventos possa ser modificada, contudo, é necessário que o cliente implemente a estratégia de escuta. Um trabalho importante seria na direção de generalizar a tarefa de monitorar os eventos, independente da ferramenta de controle de versão em questão. Este fator retiraria do cliente a responsabilidade de qualquer implementação.

Também é possível extrapolar a utilização de um mecanismo de notificação para outros cenários. É importante considerar a possibilidade de que regras de negócio possam ser definidas, permitindo assim que a ocorrência das notificações automatize determinados aspectos do processamento.

Para horizontalizar a solução é necessário melhorar o formato das notificações que são propagadas, atualmente, apenas na forma de mensagens de texto, cujos formatos são pré-determinados pelo servidor de notificação. É interessante definir o formato da notificação de acordo com o cenário considerado, já que em algumas situações poderia ser útil notificar os consumidores utilizando outros meios além de texto, como vídeo ou áudio.

A utilização do ambiente em um projeto real que envolva usuários distribuídos, os quais possuem diferentes idiomas, poderia ser de grande valia para o melhoramento da solução.

O CVSyn é uma ferramenta adequada para propagar informações. Embora projetada para isso, diversos componentes poderiam ser acoplados para que outros aspectos referentes ao ambiente do projeto pudessem ser auxiliados, a exemplo da análise de métricas e riscos, mediante as informações que chegam ao servidor e podem ser transformadas em conhecimento para a gerência do projeto.

A inclusão de outras ferramentas para visualização das notificações que contemplem a mobilidade dos colaboradores é um outro aspecto a ser visto em trabalhos

Anexo A - A IMPORTÂNCIA DE TECNOLOGIA COLABORATIVA NO CONTEXTO DE DESENVOLVIMENTO

A.1. Formação de Parcerias

Ao atuar globalmente, muitas organizações se percebem incapazes de realizar projetos em outros domínios ou alocar recursos extras, como tempo ou novas pessoas. Ao atuar em projetos de grande porte, é comum o envolvimento de um maior número de empresas no desenvolvimento, tendo uma organização como líder do projeto e unidades virtuais representam outras organizações com direitos iguais (KÖTTING,2001).

Ao optar pelo desenvolvimento baseado em parceiras, a dificuldade em encontrar as pessoas certas, responsáveis por desenvolver um conjunto de tarefas ou até mesmo, gerenciar a colaboração dos times pode comprometer o sucesso do projeto. A etapa de negociação, nem sempre uma atividade onde os parceiros podem estar presentes fisicamente, envolve interesses diversos incluindo desde a forma de gestão da propriedade intelectual, o cumprimento de prazos, até o modelo de participação nos lucros do projeto. Na maioria das vezes, os custos com viagens são altos e os parceiros podem possuir compromissos em períodos complementares.

A.2. Modelo de desenvolvimento

Na instalação de um novo projeto é comum a sua segmentação em partes, de forma que as várias atividades sejam realizadas por empresas (ou grupos) diferentes. A negociação de aspectos dos projetos, muitas vezes, requer mecanismos automatizados que possam reduzir a conflitos gerados durante as negociações, assim como, permitir a reusabilidade de contratos (Statement of Work), de forma que haja maior agilidade quanto à atribuição das responsabilidades de cada parte.

As organizações também precisam fazer uso de soluções que confiram mais segurança no momento em que optam por realizar outsourcing22_{, de forma que possam}

balancear a carga de trabalho (workload, concentrado anteriormente em apenas uma organização); estruturar as informações das tarefas permitindo que os times decidam mais rápido se podem realmente realizar tais atividades; e se concentrar nas competências

22 _{Outsourcing acontece quando uma organização contrata uma outra empresa para realizar partes do projeto.}

principais (core competencies) das parceiras, fundamentalmente, permitindo escalonar os times certos para as tarefas certas.

A.3. Análise do Problema

Um aspecto marcante no Desenvolvimento Global de Software é o alto nível de mudanças de requisitos. Devido ao dinamismo do mercado que receberá o produto de software, os colaboradores devem ter acesso às informações sempre que alguma mudança seja requisitada pelo cliente ou pelo próprio mercado.

A grande contribuição desta fase para a construção do produto é o modelo arquitetural. No entanto, sabendo da possibilidade dos requisitos serem alterados com uma freqüência bem maior que uma aplicação destinada a um único mercado, é imprescindível que haja um local de acesso central onde os colaboradores possam acessar as informações, assim como, serem notificados de qualquer mudança.

É importante que outras informações também sejam compartilhadas. A disponibilização de métricas adequadas permite que a evolução do trabalho seja acompanhada. A divulgação dos resultados dos testes de aceitação estimula que valores sejam mantidos entre os times, como coesão, confiança e o espírito de equipe. É através de suporte tecnológico que informações técnicas e de propósito mais específico aproximam os times de um ambiente de trabalho mais integrado e produtivo.

A.4. Decisões de projeto

Uma vez estabelecida a arquitetura inicial da aplicação, o próximo passo é decidir como o trabalho será alocado entre os times. A escolha da estratégia de escalonamento dependerá, principalmente, do arranjo de negócios feito entre as empresas e da localização das competências necessárias (DANTAS,2003).