Requisitos

O Presley visa promover uma melhor colaboração entre os desenvolvedores ao ser capaz de identificar os especialistas em determinadas áreas do código-fonte do projeto, pois não basta apenas ter conhecimento do domínio do problema. A falta de conhecimento profundo e seguro da aplicação em si, isto é, do código-fonte que está sendo escrito, afeta negativamente a produtividade das equipes, principalmente em DDS, provocando

28 necessidade de comunicação extra entre os membros das equipes distribuídas (de Souza et al, 2004).

Para alcançar os objetivos, o Presley foi desenvolvido com base nas deficiências e nos requisitos importantes encontrados na literatura. A seguir são listados os requisitos funcionais (RF) e os não funcionais (RNF) identificados e a próxima seção descreve como esses foram desenvolvidos.

(RF1) Analisar as contribuições no projeto: os atores envolvidos, direta ou

indiretamente, em dada atividade dão indícios dos detentores dos conhecimentos necessários para sua realização (Ganesan et al., 2006). A relação entre a execução das atividades do projeto com seus respectivos artefatos fornecem parte do suporte necessário para inferir quem é o especialista em cada parte (pacote, classe, método) do software.

Em DDS, a interação entre os desenvolvedores pode ser evidenciada através de e- mails, na comunicação assíncrona, ou logs de conversas em outros meios de comunicação, inclusive síncronos. Já a participação na implementação dos códigos-fonte do projeto pode ser extraída pelos registros contidos na ferramenta de controle de versão.

Se estas informações forem bem manuseadas, há grandes chances de suprir uma importante parte da percepção e do compartilhamento de conhecimento necessários em uma comunicação eficiente em DDS através da recomendação de membros dos times mais capazes.

(RF2) Diminuir o custo da atenção coletiva: as pessoas, ao receberem uma solicitação

de ajuda por e-mail, gastam tempo considerável em sua leitura e na postagem de uma resposta. Neste custo, também deve ser adicionada à atenção perdida na decisão de responder ou não a solicitação e a interrupção na atividade realizada pelos participantes. O custo de interrupções envolve perda do contexto e de fluxo de trabalho (Ye, 2007).

Em projetos que utilizam listas de e-mails, o custo de atenção coletiva é multiplicado pelo número de participantes envolvidos. Para evitar esse problema é importante as pessoas apenas receberem solicitações de ajuda referentes a sua área de conhecimento no projeto.

29

(RF3) Evitar exposição dos usuários com problemas: como exposto no capítulo 2, os

participantes das equipes distribuídas não se sente confortáveis quando estão em contato com pessoas desconhecidas, pois suas dúvidas demonstram desconhecimento no assunto discutido. Por isto, os participantes apenas devem ser revelados quando existir uma troca de informações, ou seja, o usuário com problema somente ter conhecimento das pessoas que respondem a sua solicitação e estes só conhecem aqueles ao responderem as dúvidas recebidas.

(RF4) Cadastrar os conhecimentos envolvidos no projeto: os repositórios centrais de

informação, apresentados no capítulo 2, mantém dados que podem ser utilizados por todos os membros das equipes (Moe e Smite, 2007).

Os documentos criados durante a execução do projeto e mantidos nos repositórios contêm informações sobre os vários conhecimentos envolvidos na implementação do software e necessário para identificar os assuntos tratados na comunicação que ocorre durante as atividades. Isto traz a necessidade de registrar os conhecimentos envolvidos nos projetos e suas fontes de informação (a documentação).

(RF5) Gerenciar a troca de mensagens: por ser uma ferramenta de comunicação

assíncrona, o Presley deve permitir a troca de mensagens entre seus usuários. No contexto abordado pelo sistema, estas mensagens são tratadas como problemas, relacionadas às dúvidas enviadas, e soluções, respostas as solicitações.

(RF6) Gerenciar o perfil dos usuários: é importante para os SRE conhecerem as

preferências e os gostos dos seus usuários. A partir da comunicação realizada é possível obter os assuntos ou os conhecimentos de interesse de cada participante. Outra informação significante para a construção dos perfis, o histórico de modificações dos artefatos (códigos- fonte) manipulados pelos usuários fornece conhecimento sobre as atividades executadas pelos desenvolvedores.

(RF7) Identificar os especialistas nos conhecimentos envolvidos no projeto: durante a

fase de construção surgem, em alguns momentos, dúvidas não relacionadas diretamente ao código-fonte desenvolvido e sim a outros conhecimentos atrelados à implementação, como os requisitos ou as decisões dobre os códigos a serem implementados.

30 Dúvidas com essas características também devem ser consideradas pelo sistema e atreladas aos especialistas do conhecimento tratado, pois são parte importante da comunicação realizada pelas equipes.

(RF8) Identificar os especialistas no código-fonte: um dos aspectos mais prejudicados

no DDS com o enfraquecimento das várias percepções - evidente nos problemas das percepções de atividade, proximidade e presença - está na identificação de especialistas no código-fonte tornando vagarosa e não muito eficiente a escolhas das pessoas mais qualificadas (Herbsleb, 2007).

O objetivo deste requisito é selecionar as pessoas (especialistas) capazes de ajudar os demais membros do time quando surgem dúvidas na fase de construção de software.

(RF9) Reduzir o tempo gasto na localização dos especialistas: como as equipes

distribuídas podem ter um tempo de sobreposição de horário de trabalho muito curto, a identificação da pessoa mais provável a responder as mensagens de dúvidas dobre o projeto aponta ser uma grande oportunidade para reduzir os atrasos gerados na comunicação, principalmente assíncrona.

(RNF1) Usabilidade: a ferramenta deve ser de fácil compreensão e utilização por

parte dos usuários.

(RNF2) Integração e transparência ao trabalho do usuário: muitas ferramentas, como

os chats, retiram o foco dos seus usuários das atividades em execução, por isso é importante obter informações de forma transparente e sem retirar sua atenção sobre o código-fonte a ser implementado.

Os requisitos descritos abrangem todas as funcionalidades desenvolvidas no Presley e influenciaram na sua arquitetura, implementação e interface apresentados nas próximas seções.