A modelagem colaborativa de software requer mais que somente compartilhar arquivos dos modelos em um repositório online. É necessário que as ferramentas providenciem recursos para que as equipes de desenvolvimento trabalhem de forma mais eficiente. Para isso, foi utilizado os 10 requerimentos para colaboração com base no estudo de Dullemond, Gameren e Solingen (2014) ilustrados na tabela A do referido estudo.
Está ciente do quê está ocorrendo em volta em um ambiente distribuído é uma tarefa difícil, porque toda informação precisar ser manualmente processada em comparação ao espaço de trabalho local. Pensando nisso, os três primeiros requerimentos foram elaborados com o foco em permitir a troca de informações sobre o ambiente de forma não intrusiva, isto é, sem distrair o desenvolvedor e sem atrapalhar suas atividades:
• R01: Rastrear alterações realizadas pelos desenvolvedores. Identificar o autor das altera- ções em um projeto e manter o histórico de cada alteração. Na prática, realizar este pro- cedimento seria implementar um sistema automático de controle de versão, que é muito útil em um ambiente colaborativo, seja para comparar modelos, realizar merge e reverter alterações quando necessário. Na UMLCollab é contemplado o histórico das alterações para permitir a consulta dos merges automáticos realizados e da aceitação ou rejeição de alterações remotas conflitantes com alterações locais.
• R02: Notificar usuários sobre alterações em tempo real. Semelhante aos conflitos de có- digo, conflitos nos modelos são difíceis de serem detectados e resolvidos. A literatura
corrente ainda considera que a detecção e resolução de tais conflitos seja uma tarefa su- jeita a erros e que consomem muito tempo (BANG et al, 2010). A colaboração síncrona ou em tempo real ajuda a evitar conflitos, pois cada usuário é notificado e recebe as mu- danças dos demais usuários em tempo real. Na UMLCollab é mantido a notificação dos usuários a cada alteração remota recebida de forma discreta através de destaque em cores. • R03: Identificar se um membro do projeto pode ser interrompido. Saber o que o usuário está fazendo (R06) e seu humor (R07) ajuda o sistema a decidir, ou ser configurado para saber quando um membro do projeto pode ser interrompido, para que os usuários possam receber informações relevantes no tempo certo.
Receber atualizações relacionadas ao projeto que o usuário está trabalhando é importante, mas informações fora do contexto do projeto são valiosas. Os próximos dois requerimentos objetivam tornar dados básicos relacionados ao trabalho mais acessíveis:
• R04: Notificar usuários sobre mudanças enquanto se encontra fora do sistema. Este re- querimento pode ajudar os usuários identificar as alterações que estão sendo realizadas no projeto enquanto eles estão fora do sistema, alterações que possivelmente podem impactar no trabalho deles. Essa aplicação pode ser feita através de e-mail, SMS ou notificações de smartphones, ou seja, o desenvolvedor iria receber um resumo das alterações ou as notificações consideradas importantes.
• R05: Notificar usuários sobre atualizações da organização. Apesar de atualizações sobre o projeto serem importantes para cada membro da equipe, atualizações da organização são úteis, ainda que não relacionadas ao projeto que o usuário participa (DULLEMOND; GAMEREN; SOLINGEN, 2014). A semelhança do requisito R04, isto pode ser alcan- çado por e-mail, SMS ou notificações de smartphones.
Os seguintes cinco requerimentos a seguir, expandem os recursos de colaboração par tornar os desenvolvedores de software mais efetivos.
• R06: Saber o que o usuário está fazendo. É útil que o sistema saiba se o usuário está revisando código, escrevendo e-mail ou atendendo ao telefone. Além disso, é importante saber se o usuário está fazendo está relacionado ao trabalho. Estas informações são úteis para saber quando o usuário pode ser interrompido.
• R07: Identificar o humor do usuário. Esse requisito pode ajudar a conectar pessoas em um nível social (ALHO; SULONEN, 1998) e ser definido manualmente pelo usuário, como é feito nas mídias sociais. Outra forma é o reconhecimento de imagens através de técnicas de inteligência artificial usando a webcam do usuário, o que apesar de possuir suas próprias limitações, pode ser mais precisa que a configuração manual pelo usuário.
• R08: Filtrar atualizações de informações do usuário. Com base nos requisitos R03, R06 e R07, o sistema pode filtrar as atualizações de informações por categoria e atividade atual do usuário e humor, evitando assim sobrecarregar o usuário com informações irrelevan- tes. As informações filtradas podem ser definidas automaticamente ou configuráveis pelo usuário como filtros presentes nos emails. Na UMLCollab se a alteração remota não é conflitante, ela é imediatamente aplicada, sem atrapalhar o usuário e apenas indicando na cor verde o merge automático. Se ocorre o conflito, o mesmo é destacado na cor verme- lha. Se o conflito deixa de existir pela modificação do elemento remoto, a UMLCollab deixa de indicar o conflito. Dessa forma é realizado o filtro das informações que o usuário recebe.
• R09: Suporte a grupos abertos de conversas. O objetivo principal é permitir que qualquer um inicie um grupo, entre, pesquise por tópicos estáticos ou dinâmicos definidos, apenas escute, feche e convide outros. O sistema pode deixar automaticamente o usuário escu- tando uma conversa se o tópico lhe interessar ou puder contribuir com o projeto. Embora existam aplicativos de vídeo e bate-papo no mercado, como o Skype for Business, para atender a esse requisito, esses aplicativos não têm recursos automáticos para convidar o usuário a participar de uma conversa de seu interesse e pesquisa por tópicos estáticos ou dinâmicos.
• R10: Integração com outras ferramentas. Integração de sistemas com outras ferramen- tas como controle de versão de código, gerenciamento de mudanças (erros, melhorias, tarefas), gerenciamento de projetos, cronograma e wiki podem melhorar a colaboração e aumentar a produção da equipe.