Presley: uma ferramenta de recomendação de especialistas para apoio à colaboração em desenvolvimento distribuído de software

Texto

(1)Universidade Federal de Pernambuco – UFPE Centro de Informática – CIN Pós-Graduação em Ciência da Computação. PRESLEY: UMA FERRAMENTA DE RECOMENDAÇÃO DE ESPECIALISTAS PARA APOIO À COLABORAÇÃO EM DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE. CLEYTON CARVALHO DA TRINDADE. RECIFE Agosto, 2009.

(2) Universidade Federal de Pernambuco Centro de Informática Pós-Graduação em Ciência da Computação. CLEYTON CARVALHO DA TRINDADE. PRESLEY: UMA FERRAMENTA DE RECOMENDAÇÃO DE ESPECIALISTAS PARA APOIO À COLABORAÇÃO EM DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE. Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.. Orientador: Prof. Silvio Romero de Lemos Meira. RECIFE Agosto, 2009.

(3) Trindade, Cleyton Carvalho da Presley: uma ferramenta de recomendação de especialistas para apoio à colaboração em desenvolvimento distribuído de software / Cleyton Carvalho da Trindade. - Recife: O Autor, 2009. xii, 88 folhas : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2009. Inclui bibliografia, glossário e apêndice. 1. Engenharia de software. I. Título. 005.1. CDD (22. ed.). MEI2009 - 148.

(4)

(5) Agradecimentos Agradeço primeiramente a Deus pela oportunidade concebida e por todas as bênçãos que recebi durante o mestrado. Muito obrigado as mulheres da minha vida (minha mãe, minha irmã e minha noiva Bete) pelo amor, carinho e pela paciência dedicados durante essa jornada de sucesso. A meu pai, que Deus o tenha, que me ensinou o valor dos estudos. Obrigado Silvio Meira por ter acreditado neste trabalho e a Alan Kelon por todo empenho e orientações que foram além do âmbito da pesquisa, valeu amigo. Aos meus companheiros da FIR (Luciano Cabral, Carlos Brasil e Dalton Nicodemos) pelas conversas animadas sobre as nossas dificuldades, mostrando que eram possível superá-las. Também às professoras Cristine Gusmão e Sandra Siebra pelo incentivo a me escrever no mestrado ao termino da minha graduação. Ao departamento de informática no DER-PE por ter me liberado na reta final deste trabalho e pelos momentos de descontração que me faziam esquecer os problemas, como no dia que fui comentarista de uma partida de xadrez. Muito obrigado a todos, essa conquista também é de vocês.. III.

(6) Resumo Atualmente é comum encontrar empresas de software com equipes de desenvolvimento distribuídas em diferentes localizações; em vários casos esta divisão ocorre em escala global. O crescimento desta nova modalidade de organização e disposição dos times está ligado aos interesses das empresas em conseguir os profissionais mais capacitados, reduzir o custo de desenvolvimento, ter presença globalizada e alcançar maior proximidade com os seus clientes. Contudo, o Desenvolvimento Distribuído de Software (DDS) tem criado diversos desafios na comunicação entre seus colaboradores. Entre os aspectos mais prejudicados pela comunicação deficiente está a identificação dos especialistas no projeto. Por conta disso, o inicio do processo de comunicação torna-se lento, afetando o desempenho das atividades no projeto e gerando atrasos na execução do projeto. Como as equipes podem ter um tempo de sobreposição de horário de trabalho muito curto, a identificação da pessoa mais provável a responder mensagens de dúvidas aponta ser uma grande oportunidade para reduzir os atrasos gerados na comunicação, principalmente assíncrona, entre equipes distribuídas. O presente trabalho propõe a ferramenta Presley para identificar e recomendar os especialistas existentes em um projeto àquelas pessoas que buscam por ajuda durante a atividade de codificação, reduzindo o tempo de espera e evitando desperdício de esforço na localização dos especialistas. Isto é realizado através da análise das informações contidas nos registros de comunicação dos desenvolvedores e no histórico de alterações dos códigosfonte. O experimento realizado demonstrou que a ferramenta pode ajudar na colaboração entre equipes distribuídas e que a comunicação registrada pode fornecer informações valiosas na identificação dos especialistas. Palavras-chave:. Desenvolvimento. Distribuído. de. Software,. Sistemas. de. Recomendação de Especialistas. IV.

(7) Abstract Nowadays, it is common to find software companies with distributed development teams in different locations; in many cases, this division occurs in a global extent. The increase of this new mode of organization and arrangement of teams is connected to the companies’ interest in getting the most capable professionals, reducing the cost of developing, having a globalized presence and reaching a larger proximity with its clients. However, the Distributed Software Development has created several challenges in the communication among its collaborators. Amongst the aspects that were most damaged by deficient communication, there is the identification of experts in the project. Because of this, the beginning of the process of communication becomes slow, affecting the performance of the activities in the project and creating delays in the project’s accomplishment. As the teams may have a very short overlap of working hours, the identification of the most probable person to answer doubt messages seems tom be a great opportunity to reduce the delays created in the communication, mainly asynchronous, among distributed teams. The present work proposes the tool Presley to identify and recommend the experts existing in a project to those people who search for help during the encoding activity, reducing the waiting time and avoiding waste of effort in the localization of the expert. This is carried out through the analysis of the information enclosed in the records of communication of the developers and in the historical of alterations of the source codes. The experiment carried out demonstrated that the tool can be helpful in the collaboration between distributed teams and that the communication recorded can provide valuable information in the identification of the specialists. Key words: Distributed Software Development, Expert Recommendation Systems.. V.

(8) Sumário 1.. Introdução .......................................................................................................................... 1 1.1.. Definição do problema ................................................................................................ 2. 1.2.. Visão geral da solução proposta .................................................................................. 2. 1.2.1.. 2.. 1.3.. Fora do escopo............................................................................................................. 3. 1.4.. Contribuições realizadas .............................................................................................. 3. 1.5.. Organização da dissertação ......................................................................................... 4. Comunicação em Desenvolvimento Distribuído de Software ........................................... 5 2.1.. Comunicação em Equipes Distribuídas........................................................................ 7. 2.1.1. 2.2.. 4.. Percepção ............................................................................................................. 8. Resultados da Revisão Sistemática ............................................................................ 10. 2.2.1.. Conceitos e Dificuldades Encontradas na Comunicação .................................... 10. 2.2.2.. Frequência dos Conceitos nos Artigos Analisados ............................................. 12. 2.2.3.. Processos e práticas coletadas ........................................................................... 12. 2.2.4.. Ferramentas de Comunicação ............................................................................ 15. 2.3. 3.. Características ...................................................................................................... 2. Conclusão ................................................................................................................... 19. Sistemas de Recomendação de Especialistas ................................................................... 20 3.1.. Definição e Características dos SRE ........................................................................... 20. 3.2.. SRE Existentes ............................................................................................................ 22. 3.3.. Conclusão ................................................................................................................... 26. Presley .............................................................................................................................. 27 4.1.. Requisitos ................................................................................................................... 27. 4.2.. Arquitetura e Implementação ................................................................................... 30 VI.

(9) 5.. 4.2.1.. Framework Conceitual........................................................................................ 31. 4.2.2.. Arquitetura ......................................................................................................... 32. 4.2.3.. Cliente ................................................................................................................. 33. 4.2.4.. Componente Usuário.......................................................................................... 34. 4.2.5.. Componente Conhecimento .............................................................................. 35. 4.2.6.. Componente Mensagem .................................................................................... 36. 4.2.7.. Componente Inferência ...................................................................................... 37. 4.2.8.. Detalhes da Implementação............................................................................... 41. 4.3.. Uso do Presley ........................................................................................................... 41. 4.4.. Atendimento aos requisitos pelo Presley .................................................................. 44. 4.5.. Conclusão ................................................................................................................... 45. Experimento e Análise dos Resultados ............................................................................ 46 5.1.. 5.1.1.. Definição ............................................................................................................. 46. 5.1.2.. Planejamento...................................................................................................... 48. 5.1.3.. Projeto Utilizado no Experimento ...................................................................... 50. 5.1.4.. Instrumentação .................................................................................................. 51. 5.1.5.. Execução ............................................................................................................. 52. 5.1.6.. Análise e Interpretação ...................................................................................... 53. 5.2. 6.. 7.. Avaliação do Presley .................................................................................................. 46. Conclusão ................................................................................................................... 65. Conclusão.......................................................................................................................... 67 6.1.. Contribuições da pesquisa ......................................................................................... 68. 6.2.. Trabalhos futuros ....................................................................................................... 69. 6.3.. Contribuições acadêmicas ......................................................................................... 70. 6.4.. Conclusões finais........................................................................................................ 70. Referências Bibliográficas ................................................................................................. 72 VII.

(10) Apêndice A – Protocolo de Revisão Sistemática ...................................................................... 76 Apêndice B – Formulário de condução da revisão sistemática ................................................ 83. VIII.

(11) Lista de Figuras Figura 4-1: Rede de atores de um projeto de software, extraído de (Ye et al., 2007) ............ 32 Figura 4-2: Framework Arquitetural da Ferramenta ................................................................ 33 Figura 4-3: Tabelas Utilizadas pelo Componente Usuário ....................................................... 35 Figura 4-4: Tabelas Utilizadas pelo Componente Conhecimento ............................................ 36 Figura 4-5: Tabelas Utilizadas pelo Componente Mensagem .................................................. 37 Figura 4-6: Sub-Componentes da Inferência ............................................................................ 38 Figura 4-7: Fórmula do cálculo do grau de igualdade (Galho and Moraes, 2004) ................... 39 Figura 4-8: Fórmula da média por operadores "fuzzy" (Galho and Moraes, 2004) ................. 40 Figura 4-9: Cálculo de Participação dos Desenvolvedores nas Interações .............................. 40 Figura 4-10: Cálculo de Participação dos Desenvolvedores no Código-Fonte ......................... 41 Figura 4-11: Presley em destaque na IDE Eclipse ..................................................................... 42 Figura 4-12: Aba Tópicos de Domínio....................................................................................... 42 Figura 4-13: Aba Mensagem de Problema ............................................................................... 43 Figura 5-1: Comparativo da Precisão Geral (a) e de Sucesso (b) apenas com a Comunicação 54 Figura 5-2: Comparativo da Cobertura Geral (a) e de Sucesso (b) apenas com a Comunicação .................................................................................................................................................. 55 Figura 5-3: Comparativo da acurácia apenas com a Comunicação.......................................... 55 Figura 5-4: Comparativo da precisão geral (a) e de sucesso (b) apenas com o histórico do código-fonte ............................................................................................................................. 56 Figura 5-5: Comparativo da Cobertura Geral (a) e de Sucesso (b) apenas com o histórico do código-fonte ............................................................................................................................. 57 Figura 5-6: Comparativo da acurácia apenas com o histórico do código-fonte ...................... 57 Figura 5-7: Precisão Geral (a) e de Sucesso (b) das Recomendações de cada Fonte de Dados do Presley ................................................................................................................................. 59 Figura 5-8: Cobertura Geral (a) e de Sucesso (b) das Recomendações de cada Fonte de Dados do Presley ................................................................................................................................. 59 Figura 5-9: Acurácia das Recomendações de cada Fonte de Dados do Presley ...................... 60. IX.

(12) Figura 5-10: Precisão (a) e a Cobertura (b) gerais das Recomendações por Quantidade de Respostas dos E-mails............................................................................................................... 64 Figura 5-11: Precisão (a) e a Cobertura (b) nos casos de sucesso das Recomendações por Quantidade de Respostas dos E-mails ..................................................................................... 64 Figura 5-12: Acurácia das Recomendações por Quantidade de Respostas dos E-mails .......... 64. X.

(13) Lista de Tabelas Tabela 2-1: Adaptações as Práticas Propostas pelas Metodologias Ágeis ............................... 13 Tabela 5-1: Quantidade de e-mails por quantidade de respostas enviadas ............................ 52 Tabela 5-2: Quantidade de e-mails por Mês ............................................................................ 53 Tabela 5-3: Informações das versões do código fonte utilizado .............................................. 53 Tabela 5-4: Média comparativa das métricas coletas nas recomendações apenas com a comunicação ............................................................................................................................. 56 Tabela 5-5: Média comparativa das métricas coletas nas recomendações apenas com o histórico do código fonte.......................................................................................................... 57 Tabela 5-6: Média comparativa das métricas coletas nas recomendações com e sem comunicação ............................................................................................................................. 60 Tabela 5-7: Métricas coletadas dos artigos com modelos de descoberta de especialistas em código-fonte ............................................................................................................................. 61. XI.

(14) 1. Introdução A globalização da economia gerou várias oportunidades de negócios, o que conduziu diversas organizações a distribuírem seus recursos com o objetivo de reduzir custos, obter uma. equipe. mais. especializada. e. atender. a. novas. demandas. de. mercado.. Conseqüentemente, torna-se mais comum encontrar empresas de software com equipes de desenvolvimento distribuídas em diferentes localizações. Em vários casos esta divisão ocorre em escala global, com os times dispersos entre os continentes (Carmel, 1999). Porém, se o desenvolvimento de software já é uma atividade complexa quando realizada da forma tradicional (Curtis et al., 1988; Brooks, 1978; The Standish Group, 2001; Espinosa e Carmel, 2004), com equipes distribuídas, essa complexidade é ainda maior e elevada a níveis de complexidade mais difíceis de serem tratados (Ågerfalk et al., 2005). No desenvolvimento distribuído de software, as distâncias geográfica e temporal geram deficiências na comunicação e nos diversos níveis de percepção - proximidade, atividade, presença, processo e perspectiva - da equipe. A deficiência na percepção dificulta o reconhecimento rápido das pessoas capacitadas a ajudar outros desenvolvedores com problemas no momento da codificação. Este problema é evidente quando um membro do grupo necessita de ajuda de outro integrante, porque o acesso às pessoas de times remotos e as opções de comunicação síncrona são restritas. As limitações tornam lento o inicio do processo de colaboração entre os integrantes da equipe. Como conseqüência, projetos distribuídos têm custos adicionais de atrasos e retrabalhos (Espinosa e Pickering, 2006). Uma grande oportunidade para reduzir os atrasos gerados na comunicação entre equipes distribuídas está na identificação das pessoas mais capazes de ajudar os demais membros do time quando surgem dúvidas na fase de construção do software, ou seja, identificar os especialistas. Como as equipes podem ter poucas oportunidades de comunicação síncrona, a rápida identificação da pessoa mais provável a responder mensagens de dúvidas pode acelerar o processo de colaboração das equipes. 1.

(15) Os Sistemas de Recomendação de Especialistas permitem uma melhor colaboração entre os seus usuários através da identificação de especialistas que possam ajudá-los na realização das suas tarefas. Contudo, muitos desses sistemas não analisam o conteúdo da comunicação entre os desenvolvedores como forma de descobrir seus interesses e também não utilizam os relacionamentos existentes no código-fonte em dúvida durante a seleção dos especialistas.. 1.1. Definição do problema Motivado pelos problemas citados, o objetivo do trabalho descrito nesta dissertação pode ser apresentado como: Este trabalho tem como objetivo recomendar os especialistas na codificação de projetos fisicamente distribuídos àquelas pessoas que buscam por ajuda durante suas atividades de codificação do projeto, através dos registros de e-mails trocados entre os desenvolvedores e do histórico do código-fonte.. 1.2. Visão geral da solução proposta O objetivo deste trabalho foi atingido com o desenvolvimento do Presley, um Sistema de Recomendação de Especialistas que utiliza elementos geralmente encontrados no Desenvolvimento Distribuído de Software, como o histórico do código-fonte e os e-mails enviados pelos desenvolvedores, para diminuir os problemas causados pela comunicação assíncrona. Esta seção descreve as características da ferramenta proposta.. 1.2.1. Características O Presley utiliza o framework teórico descrito por Ye e colegas (2007). O framework constrói redes de relacionamentos entre os elementos envolvidos na realização do projeto, utilizando-as como entradas de uma heurística para selecionar os especialistas aptos a responderem os problemas enfrentados pelos desenvolvedores na fase de implementação. Os nós da rede, representando código-fonte, documento e desenvolvedor, mostram o relacionamento entre as pessoas e as informações geradas durante o projeto.. 2.

(16) Desta forma, o Presley igualmente recebe como parâmetros o código-fonte, os artefatos e registros de comunicação entre os pares no projeto. A ferramenta fornece um canal próprio e específico de comunicação que também será considerado na análise de identificação de especialistas.. 1.3. Fora do escopo Como a ferramenta proposta foca um contexto específico, vários aspectos relacionados à comunicação no Desenvolvimento Distribuído de Software foram deixados fora do escopo deste trabalho. Desta forma, as seguintes questões não foram abordadas neste trabalho: Especialistas em requisitos. Identificar especialistas nos requisitos que deram origem aos códigos implementados no projeto não está do escopo do trabalho por envolver pessoas fora do ambiente de desenvolvimento do projeto, como clientes e usuários do software a ser entregue. Padronização dos e-mails. Solicitar aos desenvolvedores que padronizem o conteúdo de suas mensagens facilitaria a identificação do conhecimento e dos códigos-fontes em questão, porém este procedimento influencia a rotina natural dos desenvolvedores na comunicação assíncrona, por isto foi excluso do escopo no trabalho. Processo de desenvolvimento. A ferramenta proposta utiliza informações geralmente existentes em projetos de software fisicamente distribuídos, independente do processo de desenvolvimento a ser seguido. Por isto, o trabalho não envolveu um estudo de identificação do processo mais indicado para o uso da ferramenta.. 1.4. Contribuições realizadas As seguintes contribuições podem ser listadas como resultado do trabalho apresentado: • A identificação, através da execução de uma Revisão Sistemática da Literatura, da baixa percepção entre os participantes de equipes distribuídas como a principal dificuldade enfrentada na comunicação assíncrona e da oportunidade em selecionar. 3.

(17) as pessoas mais qualificadas a participar do processo de colaboração como uma forma de reduzir os problemas gerados. • A definição dos requisitos, arquitetura e implementação de um Sistema de Recomendação de Especialistas, assim como a descrição do tratamento realizado nas fontes de informação utilizadas; • A descrição das fases de definição, planejamento, execução, análise, interpretação e apresentação de um experimento que avalia a qualidade das recomendações feitas pela ferramenta proposta.. 1.5. Organização da dissertação Além do capítulo de Introdução, o presente trabalho envolve outros cinco capítulos, organizados da seguinte forma: Capítulo 2.. Apresenta os problemas existentes na comunicação entre equipes. distribuídas e os resultados da execução de uma Revisão Sistemática da Literatura. Capítulo 3.. Apresenta os conceitos e as características envolvidas nos Sistemas de. Recomendação de Especialistas, como também a adoção de técnicas originalmente desenvolvidas pelos tradicionais Sistemas de Recomendação. Capítulo 4.. Descreve. a. ferramenta. Presley,. seus requisitos,. arquitetura,. implementação e uso da ferramenta. Capítulo 5.. Apresenta as fases realizadas durante a avaliação das recomendações. feitas pelo Presley a partir da execução de um experimento. Capítulo 6.. Resume as contribuições deste trabalho, apresenta os trabalhos. relacionados e direções para trabalhos futuros.. 4.

(18) 2. Comunicação em Desenvolvimento Distribuído de Software Impulsionada pelo crescente avanço tecnológico, a comunicação conseguiu ultrapassar diversas fronteiras e gerou novas oportunidades de cooperação entre as pessoas. Barreiras como a comunicação assíncrona, o envio de artefatos de trabalho (em formato digital) pelos indivíduos e a colaboração áudio-visual entre equipes separadas geograficamente foram vencidas a partir do advento da Internet e de seus vários meios de comunicação resultantes. Hoje, já é possível encontrar salas de aula virtuais, com alunos e professores separados por vários quilômetros de distância (Almeida, 2003), além de mudanças decorrentes da nova modalidade de trabalho chamado teletrabalho (Sakuda e Vasconcelos, 2005). Devido à vantagem do baixo custo de transporte dos seus produtos digitais, a indústria de software é considerada uma das pioneiras em projetos fisicamente distribuídos (Espinosa e Carmel, 2004). Com a crescente complexidade dos projetos de software atuais, muitas vezes, torna-se necessário formar equipes com as mais diferentes especialidades. O Desenvolvimento Distribuído de Software (DDS) traz a possibilidade da criação de grupos de trabalho virtuais, pois seria difícil e custoso para uma empresa localizar tais pessoas apenas em sua região. Muitas empresas de software investem no DDS em busca de novas oportunidades de negócio e pelo desejo de menores custos no desenvolvimento de seus projetos. Entre os benefícios dessa modalidade de desenvolvimento estão (Carmel, 1999): • acesso à mão-de-obra especializada: as empresas querem, em seus projetos, as pessoas o mais qualificadas possível, independentemente de sua localização geográfica;. 5.

(19) • redução do custo de desenvolvimento: contrata-se mão-de-obra mais barata em países emergentes para tarefas consideradas menos interessantes nos países industrializados; por exemplo, manutenção, teste e suporte ao usuário; • presença globalizada: de forma estratégica, muitas empresas buscam o rótulo de empresas globais como forma de demonstrar aos seus clientes sua grandeza e sua capacidade de atendimento às filiais espalhadas em vários pontos do planeta; • redução do tempo para alcançar o mercado: a diferença de horários pode acelerar o processo de desenvolvimento de um projeto através do chamado follow the Sun (seguindo o sol). Para isso, uma empresa deve ter centros de desenvolvimento espalhados em vários países com diferentes fusos horários. Sendo assim, uma atividade é executada por um centro e, ao término do seu dia de trabalho, essa é transferida para outra equipe, que inicia suas atividades (Parvathanathan et al., 2007). No trabalho distribuído, as equipes devem superar as dificuldades impostas pelas divisões geográfica, temporal e cultural (Parvathanathan et al., 2007). Na divisão geográfica, as equipes não interagem de forma presencial; entretanto, podem trocar informações em tempo real. Já na divisão temporal, existe pouca disponibilidade de horários de trabalho para interações síncronas; consequentemente, a comunicação não garante o tempo de resposta da outra parte; enquanto que, na divisão cultural, as equipes são afetadas pelas diferenças entre as línguas faladas, os costumes, os treinamentos, as políticas locais e outras questões regionais. Atualmente, as equipes não mais sentem a distância geográfica como o maior desafio a ser superado por duas razões (Gumm, 2006): (1) muitos dos membros estão próximos o suficiente para viajar e realizar regulares reuniões e (2) a atual tecnologia proporciona uma boa qualidade de comunicação nessa condição. Porém, a separação temporal restringe as opções de comunicação síncrona, aumenta o custo da realização de trabalhos colaborativos e dificulta a troca de informações (Espinosa e Pickering, 2006). Como as atividades realizadas durante um projeto de software são interdependentes, e a maioria dos meios de. 6.

(20) comunicação adotados são fortemente baseados em comunicação síncrona, os membros das equipes sentem dificuldades durante suas interações (Steinfield et al., 2002).. 2.1. Comunicação em Equipes Distribuídas Muitas das dificuldades ainda enfrentadas por equipes colocalizadas (nas quais os participantes estão todos no mesmo local) também são encontradas no Desenvolvimento Distribuído de Software (DDS), como por exemplo, o grande esforço para realizar mudanças. Contudo, ao se observar além desses sintomas e buscar as causas, graves falhas na comunicação são encontradas entre os usuários e os desenvolvedores e entre os próprios desenvolvedores (Ågerfalk e Fitzgerald, 2006). Em projetos nesse contexto, a comunicação é realizada em menor quantidade e com menor eficiência (Herbsleb, 2007). Equipes colocalizadas gastam boa parte do seu tempo em comunicação: em média, consomem 75 minutos do seu dia em interações não programadas. Contudo, as distâncias geográfica e temporal diminuem a frequência de comunicação entre as equipes, interferindo na forma de interagir das pessoas (Herbsleb e Mockus, 2003). Esse problema já pode ser sentido em ambientes separados por mais de trinta metros (Allen, 1977). Diante dessas dificuldades, as atividades relacionadas aos requisitos de software (definição de requisitos, negociação) são diretamente afetadas pela fraca comunicação, pois obter os requisitos de forma correta e compartilhar seu entendimento torna-se um sério problema para as equipes. Os desenvolvedores com incertezas nos requisitos necessitam de comunicação adicional para esclarecimento de dúvidas, podendo resultar em atrasos no cronograma do projeto caso a interação não ocorra em momentos de sobreposição de horários dos times (Espinosa e Carmel, 2004). Define-se aqui incerteza como a diferença entre a quantidade de informação necessária e a quantidade possuída sobre uma situação, enquanto que equívoco é a existência de múltiplas e conflitantes interpretações sobre uma situação (Damian et al., 2008). Muitas vezes os equívocos gerados pelos requisitos têm fortes impactos no cumprimento de prazos e aumento da quantidade de retrabalho, levando, em geral, um dia 7.

(21) a mais para ser notificado e corrigido quando existe grande separação temporal (Espinosa e Pickering, 2006). Para dificultar ainda mais o esclarecimento de equívocos, os desenvolvedores, ao perguntar, demonstram esquecimento sobre algum conhecimento. Agem de maneiras diferentes quando fazem uma pergunta em público (para estranhos) ou em privado (para um amigo), tornando-os, consequentemente, ignorantes no assunto e enfraquecendo seu relacionamento com a comunidade (Ye et al., 2007). Mesmo quando há resposta às perguntas, a interpretação não é simples devido às diferenças culturais, organizacionais, de treinamento etc. A falta de comunicação também afeta a confiança entre os integrantes das equipes distribuídas, pois os times precisam de constante confirmação da interação e dos trabalhos executados para manter um alto nível de confiança (Moe e Smite, 2007). A previsibilidade da comunicação evita a experiência da sensação de ansiedade e a diminuição da confiança decorrida da negativa impressão de silêncio ou dos atrasos associados à separação temporal. Somado a isso, o pobre compartilhamento de informações no DDS transfere aos participantes do projeto pouco conhecimento sobre as pessoas envolvidas, dificultando a difusão das tarefas realizadas, sua disponibilidade para comunicação e respectivas especializações. Do mesmo modo, os times sofrem com a falta de comunicação informal resultante dos baixos níveis de confiança, de percepção e de progresso dos locais remotos (Layman et al., 2006). A percepção e a compreensão do que está acontecendo no ambiente distribuído é um importante fator na sintonia das atividades. Sentimentos, como a frustração, podem ocorrer em equipes onde as informações sobre os eventos nas atividades não são compartilhadas (Steinfield et al. 2002).. 2.1.1. Percepção A percepção abrange o conhecimento sobre os objetivos, as atividades realizadas pelo grupo e os acontecimentos durante sua execução, assim como, onde estão os participantes e o que fazem. Contudo, neste trabalho, são enumerados os tipos específicos de percepção deficientes em equipes de DDS: 8.

(22) • Percepção de Atividade (O que eles estão fazendo?): é a importância de conhecer quem fez o que e quando, porque sem essa propriedade é difícil discernir quem tem conhecimento sobre determinados assuntos para esclarecer dúvidas, discutir melhores soluções e repassar conhecimento (Parvathanathan et al., 2007; Espinosa et al., 2007; Herbsleb e Mockus, 2003). Em DDS, é menos aparente quem são e o que fazem as pessoas em times remotos; • Percepção de Proximidade (Com quem minhas atividades se relacionam?): é a necessidade que os indivíduos possuem de saber quem são as pessoas mais próximas em termos de estrutura organizacional e de dependência nos artefatos das tarefas executadas, pois várias pessoas podem ser afetadas caso um determinado componente seja alterado (Espinosa et al., 2007). As distâncias física e temporal reduzem a percepção de proximidade; • Percepção de Presença (Quando posso contatá-lo?): é a possibilidade de saber qual o melhor momento de iniciar um contato com pessoas de outro time sem que interrompam suas atividades em momentos inapropriados (Espinosa et al., 2007; Herbsleb e Mockus, 2003). A percepção de presença é enfraquecida devido à predominância da comunicação assíncrona; • Percepção de Processo (Onde estamos no projeto?): é a capacidade de entender completamente quais foram os principais marcos de entrega, os requisitos das tarefas dos participantes remotos e como eles impactam na sua própria tarefa (Jang et al., 2002). Devido às peculiaridades das equipes envolvidas, os participantes têm dificuldades em compreender como outros times estão se desenvolvendo; • Percepção de Perspectiva (O que eles estão pensando e por quê?): é a compreensão e o entendimento de como as outras partes vêem o mesmo projeto; a cognição coletiva (Jang et al., 2002). Nos projetos distribuídos, está relacionada aos questionamentos pelos membros das equipes do porquê de seus colegas remotos falharem ao seguir uma sugestão ou o que eles pensarão sobre alguma contribuição (colaboração).. 9.

(23) Tendo em vista todas as dificuldades descritas na interação entre equipes distribuídas, uma Revisão Sistemática da Literatura (RSL) foi realizada com o objetivo de identificar os conceitos envolvidos na comunicação dos desenvolvedores, assim como as experiências nessa área relativas às técnicas, dificuldades encontradas, processos e ferramentas utilizadas. A partir dos resultados alcançados, foi identificado um importante fator para diminuir os custos provocados pelas falhas de comunicação decorrentes do DDS (Trindade et al., 2008). O apêndice A apresenta o protocolo elaborado para conduzir a revisão e o Apêndice B contém os artigos coletados durante sua execução.. 2.2. Resultados da Revisão Sistemática Os resultados apresentados, que tiveram o propósito de mostrar as descobertas relevantes da RSL conduzida, foram produzidos a partir das informações extraídas dos artigos coletados e contidas na matriz de conceitos produzida (Webster e Watson, 2002). As descobertas foram baseadas na discussão de aspectos significantes pertencentes aos conhecimentos na área de comunicação em equipes distribuídas.. 2.2.1. Conceitos e Dificuldades Encontradas na Comunicação Com a execução da RSL, vários tópicos e problemas envolvidos na comunicação em equipes distribuídas foram encontrados nos artigos selecionados. Entre esses estão: a fraca percepção no ambiente compartilhado, a dificuldade em coordenar as tarefas realizadas, a baixa frequência de comunicação, a dificuldade em estabelecer redes de contato, o baixo nível de confiança dos envolvidos e a diferença cultural entre as equipes. A percepção está relacionada à dificuldade de determinar quais dos integrantes da equipe têm experiência ou conhecimento sobre as diferentes partes do projeto, à incapacidade de realizar comunicação através das diferenças de fuso horário e à falta de conhecimento sobre o andamento das atividades executadas por outras pessoas e equipes remotas. A coordenação é conhecida como a gerência das dependências entre as tarefas para se alcançar um objetivo. Geralmente, na coordenação de trabalhos rotineiros, são utilizados mecanismos de programação de atividades, como cronogramas; contudo, a comunicação 10.

(24) exerce um importante papel na coordenação de trabalhos com aspectos incertos (Espinosa e Carmel, 2004). Dificuldades de iniciar um contato, saber quem contatar sobre algum determinado assunto e comunicar-se eficientemente através das separações física e temporal levam a sérios problemas de coordenação, a saber: • sobreposição de horários: muitas empresas costumam mudar ou expandir as horas de trabalho das equipes no intuito de aumentar a sobreposição de horas de trabalho com as localizadas remotamente; entretanto, essa prática prejudica os limites entre a vida profissional e pessoal dos empregados (Espinosa e Carmel, 2003); • duração do trabalho: o trabalho distribuído introduz atrasos na resolução de problemas em seu desenvolvimento 2.5 vezes maiores quando comparado aos colocalizados, o que está diretamente relacionado ao número de pessoas envolvidas no projeto (Herbsleb et al., 2001) e com a dificuldade de encontrar as pessoas mais qualificadas na equipe para iniciar uma colaboração. A causa pode estar no gasto de muito tempo, por parte dos indivíduos, em responder as questões de seus companheiros, que não é levada em consideração quando as tarefas são atribuídas; • configuração do trabalho: a comunicação e a separação exercem forte influência na escolha da configuração dos times no DDS. Por exemplo, é mais indicado distribuir as tarefas com baixa granularidade quando se adota o trabalho sem sobreposição de tempo, como nos call center. Porém, quando as tarefas são extensas, recomenda-se selecionar equipes em regiões onde a junção de seus horários de trabalho tenham sobreposição (Espinosa e Carmel, 2003). Outro tópico encontrado, a Frequência de Comunicação, está relacionado com a quantidade de interações ocorridas entre os membros das equipes. É importante manter comunicação frequente em ambientes distribuídos para evitar que ocorram mal entendidos, e para melhorar a compreensão cultural e a confiança da equipe (Ali Babar et al., 2001). As Redes de Contato descrevem com quem os indivíduos se relacionam dentro de uma comunidade. Tais indivíduos podem ser desde um membro principal (o líder do grupo) 11.

(25) até um periférico (que pouco se comunica). Conhecendo o relacionamento existente entre as pessoas é possível saber o quanto cada uma contribui na equipe e sua reputação social para os demais (Ye et al., 2007). A Confiança é a percepção compartilhada, pela maioria dos membros do time, de que suas ações serão importantes para todos, como também significa reconhecer e projetar os interesses corretos dos indivíduos engajados no esforço coletivo (Moe e Smite, 2007). O baixo nível de confiança das equipes distribuídas está relacionado com a baixa frequência de comunicação, que impede uma constante confirmação da qualidade do trabalho realizado e da presença dos integrantes no trabalho, somado à fraca percepção do trabalho e do progresso dos locais remotos. As Diferenças Culturais afetam as suposições das pessoas ocorridas durante as interações, tornando dúbio o entendimento de suas condutas, de suas expectativas sobre as práticas de liderança e de suas habilidades de trabalho, bem como o entendimento das ações realizadas pelos participantes e das necessidades para o desempenho de uma tarefa (Moe e Smite, 2007).. 2.2.2. Frequência dos Conceitos nos Artigos Analisados Dentre os artigos coletados, a percepção foi o tópico mais abordado, presente em 70% dos artigos analisados, e quase sempre apontada como fonte de problemas na comunicação. Em segundo lugar, a coordenação esteve entre 50% dos artigos. Também com forte influência sobre os artigos coletados, as redes de contatos e a frequência na comunicação tiveram 41% de presença. Os dois últimos tópicos encontrados, confiança, com 29%, e diferença cultural, com 33%, são barreiras encontradas na comunicação entre equipes distribuídas que também afetam a percepção.. 2.2.3. Processos e práticas coletadas Vários problemas afetam o desempenho da execução do processo de desenvolvimento em ambientes distribuídos, como a falta de percepção entre os membros envolvidos, o baixo nível de confiança, o longo tempo de resposta às solicitações feitas e a baixa frequência na 12.

(26) comunicação, principalmente quando as atividades exigem criatividade, inovação e consenso, ou quando os objetivos são incertos e necessitam de numerosas e complexas interações entre os participantes (Sakthivel, 2005). Atividades no DDS podem ser ainda mais sacrificadas porque os problemas das equipes remotas são facilmente esquecidos (Paasivaara e Lassenius, 2003). As solicitações recebidas podem não ser consideradas tão importantes ou urgentes para responder quanto as dos colegas locais ou pode existir um diferente entendimento da abordagem de colaboração entre os times (Smite, 2006; Canfora et al., 2006). Diante da problemática na execução das atividades, as práticas indicadas pelas metodologias ágeis estavam presentes em boa parte dos artigos com processos analisados. As práticas abaixo tiveram um efeito positivo no DDS: • entregas frequentes: impedem períodos de desenvolvimento longos e de forma independente, o que poderia gerar módulos difíceis ou impossíveis de integrar (Paasivaara e Lassenius, 2003); • pequenas releases e iterações: reduzem a complexidade e o tempo de validação pelo cliente nos requisitos entregues, garantem que os desenvolvedores sempre tenham trabalho suficiente para desenvolver e reduzem o impacto do DDS com comunicação periódica; • story cards: transferem os requisitos em pequenos pedaços de maneira menos formal (Xiaohu et al., 2004). Porém, houve forte necessidade de adaptações às práticas propostas pelas metodologias ágeis devido a várias dificuldades inerentes aos projetos de DDS.. As. adaptações encontradas nos artigos estão listadas na Tabela 2-1. Tabela 2-1: Adaptações as Práticas Propostas pelas Metodologias Ágeis. Autores. Adaptações. (Ramesh et al., 2006). 1.. 2.. Ajuste contínuo do processo (planejar as iterações para finalizar os requisitos críticos e desenvolver a arquitetura; documentar os requisitos em diferentes níveis de formalidade); facilidades para compartilhar conhecimento (manter um repositório de processo/produto; foco em funcionalidades bem entendidas em. 13.

(27) (Layman et al., 2006). (Ågerfalk e Fitzgerald, 2006). (Canfora et al., 2006). vez de novas funcionalidades críticas; pequenos ciclos, mas não com prazo de desenvolvimento fechado); 3. melhorar a qualidade de comunicação (horas de trabalho sincronizadas; comunicação informal, mas através de canais formais; coordenação balanceada; comunicação constante); 4. construir confiança (frequentes visitas entre os times envolvidos; visitas dos patrocinadores; construir um time de cultura coesa); 5. confiar, mas verificar (equipe de qualidade distribuída; suplementar a comunicação informal com documentação). 1. Definir uma pessoa para o papel de cliente; 2. definir uma pessoa que faça a "ponte" de comunicação entre os diferentes locais; 3. uso de ferramentas de gestão de projetos para armazenar e monitorar o andamento do projeto. 1. Consciência de tempo e esforço ao desenvolver a documentação, pois os documentos muitas vezes não precisam ser detalhados (apenas duas páginas pode ser o suficiente). Relacionada à programação em par. 1. 2. 3.. Treinamentos para os indivíduos conhecerem os seus papéis e responsabilidades; mix de mídias de comunicação (comunicação por voz e um blackboard); monitorar as modificações feitas pelos desenvolvedores para fornecer informações de percepção.. Além das práticas sugeridas pelas metodologias ágeis, outras abordagens foram encontradas nos trabalhos analisados. Uma dessas foi a prática de definir-se bem os papéis e divulgar seus representantes entre os grupos. Dois exemplos são os trabalhos realizados por Paasivaara e Lassenius (2003) e por Layman e colegas (2006). No primeiro, criaram-se papéis que foram atribuídos aos membros da equipe e indicou-se com quem eles deveriam se comunicar. Sua experiência mostrou uma estrutura de projeto mais clara e ajudou na busca da pessoa correta para contatar. No segundo trabalho, um membro chave da equipe foi responsável pelo papel do cliente. Esse indivíduo tomava decisões sobre as funcionalidades e sobre o escopo do projeto, sendo essencial na condução da comunicação entre os times e o cliente. Porém, deve-se ter cuidado ao direcionar a comunicação a um membro da equipe, pois isso pode sobrecarregá-lo e restringir o fluxo de informação em casos em que as atividades necessitam de contato direto com outra pessoa. Uma prática também bastante realizada foram as visitas entre os membros das equipes. Em alguns casos, integrantes de uma localização eram treinados em outra e, ao voltarem, traziam consigo conhecimentos que faziam pontes de contato entre os times (Espinosa e Carmel, 2003). Essa prática contribui bastante na construção de relacionamentos e no estabelecimento da confiança entre os times, pois as pessoas se sentem mais à vontade 14.

(28) para comunicar-se com quem já se encontraram ao menos uma vez (Paasivaara e Lassenius, 2003).. 2.2.4. Ferramentas de Comunicação Apesar da crescente melhora da qualidade e do menor custo para o projeto (comparado ao telefone), o simples uso de videoconferência dificulta a condução de ideias quando não se utilizam ferramentas adicionais (Espinosa e Carmel, 2003). Porém, a videoconferência tornase mais eficaz na busca de um acordo mútuo em momentos de negociação de requisitos quando ocorrem discussões prévias nas ferramentas textuais, que podem até servir de pauta para reuniões síncronas. As ferramentas assíncronas possibilitam processar a informação e examinar as questões fora das reuniões em tempo real, como também pesquisar e coletar informações antes de respondê-las (Damian et al., 2008). A contribuição feita pela combinação de meios de comunicação (síncrono e assíncrono) pode ser visto pela soma das seguintes características: • assíncrona: mais apropriada para comunicação em tarefas com mais incertezas; • síncrona: mais apropriada para comunicação em tarefas que contêm requisitos com equívocos. Os usuários de ferramentas de comunicação assíncrona precisam ter a preocupação de fornecer respostas o mais rapidamente possível aos seus remetentes para impactar positivamente na confiança e no compromisso de trabalho (Layman et al., 2006). Outra preocupação está na formulação das perguntas, pois essas devem ser cuidadosamente explicadas; caso contrário, os leitores podem não as entender e enviar vários e-mails com novas perguntas antes de responder a questão inicial (Paasivaara e Lassenius, 2003). Um meio bastante utilizado na comunicação assíncrona são os repositórios centrais de informação, que armazenam documentos, banco de dados, códigos fonte e outros artefatos com informações de produto ou processo. Esses ajudam a melhorar a eficiência no planejamento e no controle do desenvolvimento de software (Layman et al., 2006). Ao prover ao time contínuo acesso à informação da situação atual do projeto com possibilidade 15.

(29) de monitorar o histórico dos artefatos do projeto e das tarefas executadas, esse meio fornece percepção aos usuários sobre vários aspectos da execução do projeto, por exemplo: quem são os responsáveis pelas tarefas, quem já trabalhou com algum artefato e quais são as necessidades para o desempenho de uma tarefa. Contudo, ferramentas como repositórios de log contêm uma numerosa quantidade de registros de informações, consumindo tempo e esforço para consultas, além da questão da leitura ser tediosa (Gutwin et al., 2005). Outras ferramentas de comunicação assíncrona, como as listas de discussão, também possuem a desvantagem do grande volume de registros. Em compensação, esse mecanismo é o mais utilizado em projetos de código aberto na manutenção da percepção e na identificação dos especialistas. Participantes, mesmo aqueles passivos na interação, descobrem pelas discussões quem está falando sobre o que, quem está trabalhando (ou interessado) em alguma determinada área do projeto e quem são as referências nas áreas abordadas pelo projeto (Gutwin et al., 2005). Entre as aplicações de conversação em tempo real, o chat prejudica as pessoas ao forçá-las continuamente a colocarem atenção em sua janela, assim obrigando-as a tirar os olhos do código em implementação (Canfora et al., 2006). Em compensação, a comunicação resultante do chat é mais informal quando comparado a outras vias de comunicação, o que pode contribuir no aumento da frequência de comunicação e na quebra da barreira cultural (Gutwin et al., 2004). Com o passar do tempo, a comunicação através de ferramentas eletrônicas pode ser suficiente para estabelecer e manter o senso de comunidade. Thissen e colegas (2007) observaram ao longo da execução de projetos distribuídos o declínio da necessidade e desejo de reuniões presenciais. Além dos meios de comunicações popularmente já conhecidos, tais como chat, email, telefone e videoconferência, foram encontradas as seguintes abordagens nos artigos descritos:. 16.

(30) (Mangan et al., 2004) – Destaca um middleware para aplicações colaborativas que aumenta as informações sobre a percepção de grupo e de ambiente de trabalho disponíveis para os desenvolvedores. A arquitetura do middleware é composta por elementos para extração de dados sobre o uso de ferramentas CASE. O primeiro elemento, a ferramenta CASE, fornece um conjunto de operações e lida com a coleta e exibição das informações ao usuário. A partir deste elemento é possível obter um rico contexto das atividades, usado como uma fonte de informações de percepção. O segundo elemento, o coletor, monitora os eventos operacionais na ferramenta CASE. O coletor é responsável por extrair dados sobre o estado atual da aplicação e enviá-los para o sistema de notificação de eventos, que armazena e distribui as informações fornecidas. (Gutwin et al., 2005) – Apresenta o ProjectWacher, uma ferramenta que provê para as pessoas informações de percepção sobre os outros membros da equipe e tem a função de diminuir os problemas gerados com a falta de percepção encontrado em ambientes de desenvolvimento distribuído. Através da observação dos registros de alterações do código-fonte, o sistema prover visualizações de quem estar ativo no projeto, quais artefatos os desenvolvedores tem trabalhado e em que parte do projeto estão trabalhando. Estas informações são extraídas do histórico de alterações do código-fonte utilizado no projeto e de um segundo repositório com registros fornecidos pela ferramenta. O repositório criado recebe informações sempre que os desenvolvedores fazem alterações no código-fonte, por exemplo, ao salvar uma alteração do arquivo. A partir das informações contidas nos repositórios, a ferramenta identifica as entidades (pacotes, classes e métodos) e os relacionamentos do código-fonte, assim como as alterações feitas pelos desenvolvedores em cada método implementado no projeto. (Gilbert e Karahalios, 2007) – Apresenta o CodeSaw, uma ferramenta que proporciona uma visualização social do DDS através de informações contidas no repositório de código-fonte e na comunicação decorrente do desenvolvimento do projeto.. 17.

(31) A visualização social apresentada pelo sistema é composta por uma linha de tempo. No topo da linha, um gráfico demonstra a participação do desenvolvedor na implementação do código-fonte do projeto, enquanto na parte inferior um gráfico demonstra a participação do desenvolvedor na lista de discussão. Os gráficos são calculados a partir do número de linhas de código-fonte adicionados a cada revisão inserida no repositório do projeto e pelo número de palavras escritas nos emails enviados para a lista de discussão. (Ye et al., 2007) – Descreve uma ferramenta de comunicação que libera os desenvolvedores da sobrecarga de comunicação não interessante a eles, dessa forma reduzindo o custo total de comunicação e coordenação no desenvolvimento de software. A ferramenta foi baseada no framework com o objetivo de identificar os relacionamentos existentes entre os desenvolvedores, o código-fonte e os documentos produzidos durante um projeto. Esse relacionamento indica as ligações sociais entre as entidades envolvidas e possibilita identificar quem ajudou quem no projeto e as dependências sociais derivadas dos vínculos técnicos do código-fonte e dos documentos. O framework utilizado possibilita a busca por especialistas quando algum desenvolvedor necessita de informações durante a implementação do software. Primeiro, é realizado o processo de identificação dos especialistas através da análise do relacionamento entre os desenvolvedores e o artefato que gerou a dúvida (documento ou código-fonte). Após a identificação, é feita a seleção dos especialistas que mais se comunicou com o desenvolvedor solicitante. Ao termino da seleção é criada uma lista de discussão temporária entre os especialistas e o desenvolvedor com dúvidas para solucionar o problema encontrado. A análise das abordagens encontradas revelou uma forte preocupação em fornecer informações de percepção aos usuários através do processamento das fontes utilizadas, como e-mails trocados por listas e arquivos de código fonte. Porém, com exceção ao mecanismo descrito por Ye e colegas (2007), as ferramentas coletadas não informam quais os peritos em determinadas áreas do projeto e não utilizam a documentação gerada no projeto como fonte de informação. 18.

(32) 2.3. Conclusão O Desenvolvimento Distribuído de Software vem ganhando destaque em projetos de grande porte. Porém, a dispersão das equipes - principalmente a assíncrona temporal - dificulta a colaboração entre seus membros, ocasionando demora na resolução de problemas, pois nem sempre é claro quem é o especialista naquela porção do software, principalmente quando essa pessoa está localizada remotamente. Com a Revisão Sistemática, foi possível identificar várias dificuldades enfrentadas por equipes distribuídas, principalmente quando estão temporalmente separadas. Dentre os pontos destacados, a falta de percepção, nesse contexto, mostrou-se um fator de suma preocupação no DDS, já que esse tópico esteve presente em diversos aspectos na comunicação entre times. Um dos aspectos mais prejudicados com a fraca percepção entre os participantes das equipes está relacionado com a comunicação e, consequentemente, a identificação dos peritos no projeto. Por conta disso, a comunicação ineficiente afeta o desempenho das atividades no projeto e gera atrasos na execução do projeto. Como as equipes podem ter um tempo de sobreposição de horário de trabalho muito curto, a identificação da pessoa mais provável a responder estas mensagens de dúvidas aponta ser uma grande oportunidade para reduzir os atrasos gerados na comunicação, principalmente, assíncrona entre equipes distribuídas. No próximo capítulo, serão apresentados os principais conceitos que envolvem os Sistemas de Recomendação de Especialistas e como esses são utilizados na descoberta dos especialistas existentes em projetos de software.. 19.

(33) 3. Sistemas de Recomendação de Especialistas Como discutido anteriormente, as equipes distribuídas são duas vezes e meia mais lentas na resolução de problemas quando comparadas às co-localizadas. Parte desse problema está relacionada com a dificuldade de seus membros identificarem as pessoas mais qualificadas para iniciar uma colaboração. Outro fator está na dificuldade de formação de relacionamentos, pois a separação temporal cria a sensação de ansiedade e a diminuição da confiança decorrida da negativa impressão de silêncio ou dos atrasos associados à comunicação assíncrona. Os Sistemas de Recomendação de Especialistas (SRE), ao identificarem de forma automática os mais indicados para ajudar as solicitações fornecidas, aceleram a fase inicial de comunicação e incentivam a troca de informações entre os membros das equipes, fortalecendo os relacionamentos. Através das recomendações recebidas, os usuários identificam os detentores de conhecimento no projeto, que podem sentir-se mais motivados a colaborar ao serem indicados como especialistas pela ferramenta. Este capítulo apresenta os conceitos e as características envolvidas nos SRE, como também a adoção de técnicas originalmente desenvolvidas pelos tradicionais Sistemas de Recomendação. Por fim, são apresentados alguns exemplos de SRE.. 3.1. Definição e Características dos SRE Assim como na indústria de software, outros setores também se expandiram geograficamente. A dispersão tornou a colaboração entre as equipes mais virtual do que física e gerou dificuldades em saber quem são os detentores de conhecimento dentro das organizações. Isso contribuiu no desenvolvimento de sistemas responsáveis por adquirir e analisar o conhecimento dos indivíduos para selecionar aqueles mais indicados na solução de problemas específicos. 20.

(34) Os Sistemas de Recomendação de Especialistas (SRE) são sistemas aplicados na colaboração entre pessoas. Suas recomendações indicam e ajudam na atividade de localizar pessoas dentro de uma organização. Esses sistemas agem de forma similar a um membro chave na empresa, como um gerente de projetos ou um arquiteto de software, ao sugerir os mais qualificados para determinados assuntos (McDonald e Ackerman, 2000). Além do beneficio de localizar os especialistas, os SRE contribuem no aumento da percepção da atividade nas empresas e na união de pessoas que talvez nunca tivessem oportunidade de se conhecer pessoalmente (Petry, 2007). Nas empresas, os SRE ajudam a representar os conhecimentos adquiridos pelos funcionários durante a execução de suas atividades, contribuindo numa melhor percepção dos envolvidos sobre "quem sabe o que" dentro da equipe. Outra vantagem está na formação de capital social através de melhores relacionamentos entre pessoas que já se conhecem ou não, contribuindo num melhor comprometimento e cooperação entre os funcionários (Petry, 2007). Um método de obter conhecimento sobre os membros de uma organização está no monitoramento dos resultados de suas atividades. Como as pessoas acumulam conhecimento através da execução de atividades durante um projeto, os documentos gerados (e-mails, relatórios, memorandos, etc.) indicam os conhecimentos associados a um indivíduo (Sim e Crowder, 2004). Através das funcionalidades descritas por Sim e Crowder (2004), é possível exemplificar as fases executadas por um SRE até identificar as pessoas a serem recomendadas: • extrair conhecimento - identifica potenciais fontes de informação com evidências de conhecimento ou experiência. Essas fontes podem ser sistemas de armazenamento de arquivos, de arquivos de e-mail, de repositórios de código fonte, etc.; • modelar conhecimento - detalha o relacionamento entre uma fonte de conhecimento e um especialista, por exemplo: o sistema atribui uma maior importância aos termos encontrados no título de um documento do que no corpo; 21.

(35) • seleção dos especialistas - disponibiliza estratégias ou filtros para a seleção dos especialistas. Dados pessoais e outros tipos de informações (como departamento onde trabalha) podem ser utilizados como critério de seleção. Os especialistas que não se enquadram nos critérios e filtros escolhidos são retirados da lista a ser entregue ao usuário; • interface com o usuário - lista os especialistas e as evidências utilizadas para a modelagem do conhecimento, sendo essa lista submetida ao usuário. Os tradicionais sistemas de recomendação conseguem modelar os gostos, os interesses e as habilidades de seus usuários. Com perfil formado, o sistema identifica os artefatos (como documentos, livros, CDs etc.) que melhor atendem as necessidades dos usuários. Todo o processo e conceitos envolvidos, descritos na próxima seção, ajudam a entender como os conhecimentos podem ser extraídos e modelados pelos SRE.. 3.2. SRE Existentes De acordo com a proposta de utilizar elementos gerados durante a fase de implementação como fonte de entrada para localizar os especialistas envolvidos no DDS, foram extraídas da literatura abordagens que utilizassem ao menos uma fonte de informação derivada da codificação de software. A seguir são apresentados os trabalhos que descrevem as abordagens analisadas. (McDonald e Ackerman, 2000) – Apresenta o Expertise Recommender (ER) e segue a idéia que os relacionamentos guiam as pessoas ao selecionarem os especialistas dentro das organizações. Inicialmente, o sistema utiliza os registros de experiências entre as pessoas e o histórico dos artefatos para identificar os candidatos no projeto. O ER disponibiliza duas heurísticas para a identificação dos especialistas. A primeira busca selecionar todos os desenvolvedores que modificaram um arquivo e classifica-os de acordo com a data da modificação. Nos casos de vários arquivos serem selecionados, a lista de especialistas é formada pela interseção entre as classificações de cada arquivo. A segunda heurística consiste em anexar aos erros encontrados, o cliente relacionado, os módulos do 22.

(36) sistema envolvido e a pessoa que solucionou. Em seguida, é verificada a similaridade entre o novo problema identificado e as informações anexadas. Após a identificação, a recomendação é feita após filtragem dos candidatos por critérios organizacionais ou sociais. Para isto, a lista é filtrada de forma a selecionar os mais próximos do usuário na rede social ou no grupo de trabalho, ou seja, separados por no máximo x pessoas no modelo de relacionamentos sociais. O pronto forte do ER está na avaliação do contexto social do usuário e na flexibilidade das suas fontes de dados. O ponto negativo do sistema é o filtro realizado, pois a pessoa mais especializada nem sempre é retornada caso esteja muito distante da rede social do usuário. (Minto e Murphy, 2007) – Descreve o Emergent Expertise Locator (EEL), que baseado no histórico de alterações dos arquivos e das pessoas que participaram dessas alterações, encontra os especialistas para um dado conjunto de arquivos de interesse. O EEL utiliza duas matrizes com informações do histórico de alterações, a matriz de dependência dos arquivos e a matriz de autoria, para gerar a matriz de especialistas. A matriz de dependência representa a quantidade de vezes que um par de arquivos foi alterado no mesmo momento e a matriz de autoria representa a quantidade de alterações que os desenvolvedores fizeram em cada arquivo. A matriz resultante do cálculo das duas matrizes anteriores representa o nível de conhecimento dos desenvolvedores sobre os arquivos em dúvida. Esse sistema oferece um tratamento diferenciado aos dados armazenados nos repositórios de código-fonte, porém não é analisado se os arquivos têm dependências ou forte relacionamento com outros, o que poderia enriquecer a construção das matrizes. (Sindhgatta, 2008) – A abordagem proposta nesse trabalho busca extrair os conceitos presentes no código-fonte e associá-los aos desenvolvedores através dos registros de alterações do código. A identificação dos conceitos inicia-se pelo processamento dos arquivos de códigofonte, que gera uma representação com apenas os termos chaves presentes no arquivo. 23.