Aumentando a Percepção no Desenvolvimento de Software:

Uma Abordagem baseada em Visualização de Informação

Aluno: Rafael da Silva Viterbo de Cepêda*
Orientadora: Cláudia Maria Lima Werner

Programa de Engenharia de Sistemas e Computação – COPPE/UFRJ

Caixa Postal 68.511, Rio de Janeiro, RJ, 21945-970
{rcepeda,werner}@cos.ufrj.br

Nível: Mestrado
Ano de Ingresso: 2008
Aprovação da Proposta: Maio de 2009
Previsão de Conclusão: Julho de 2010

Resumo. O desenvolvimento de software por ser uma atividade intensamente

humana e complexa necessita constantemente que seus participantes tenham
conhecimento e percepção das diferentes características inerentes a este
processo. este contexto, este artigo apresenta uma abordagem que visa a
aumentar a capacidade de percepção das diferentes características de um
projeto de software, através de um único mecanismo. O trabalho explora a
complementaridade de algumas informações do projeto para formar visões do
software, uma vez que técnicas de visualização de informação serão utilizadas
na apresentação destas características. Porém, em função da
imprevisibilidade do que pode ser relevante em cada cenário de
desenvolvimento, a abordagem também apresenta uma importante
propriedade de extensibilidade.

Palavras-Chave: Percepção, Visualização de Informação, CSCW.

*
Com auxílio financeiro da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES)
1. Introdução
Problemas de comunicação e de coordenação de atividades, no contexto do
desenvolvimento de software, têm sido, há tempos, importantes desafios enfrentados
pelos membros desta comunidade [Brooks, 1995]. Boa parte destes desafios decorrem
da falta de percepção sobre o projeto como um todo pela equipe de desenvolvimento
[Dourish e Belloti, 1992]. Além disto, a falta de percepção do projeto muitas vezes faz
com que a efetividade da comunicação entre os participantes seja prejudicada [Kraut e
Streeter, 1995].
Neste contexto, percepção sobre o projeto pode ser entendida como a capacidade
que atores (neste caso, desenvolvedores) tomam conhecimento das atividades do projeto
em andamento, bem como o conhecimento a respeito dos demais participantes do
projeto. Desta forma, diferentes estratégias, baseadas nas mais variadas informações,
podem ser elaboradas com o intuito de fornecer percepção sobre o estado atual do
projeto. Como será observado na seção 3, diferentes soluções já foram propostas neste
sentido, porém sempre adotando um único tipo de informação como provedora de
percepção. Entretanto, devido a grande complexidade e variedade de forma do processo
de desenvolvimento de software, estas soluções muitas vezes se tornam aplicáveis a um
pequeno conjunto de projetos com características bem definidas.
Seguindo esta introdução, o restante do artigo está organizado da seguinte forma:
a seção 2 apresenta a abordagem proposta; a seção 3 apresenta os trabalhos
relacionados; e, a seção 4 apresenta as conclusões deste trabalho, ressaltando seus
principais resultados esperados e uma proposta para a avaliação destes.

2. Abordagem Proposta
A abordagem proposta tem por objetivo aumentar a percepção sobre o projeto durante o
desenvolvimento de software, fornecendo um conjunto de informações pertinentes à
esta etapa de forma centralizada, consistente e uniforme (Figura 1). As informações
serão apresentadas na forma de visões do software, explorando o potencial das técnicas
de visualização para representar dados, já que, uma de suas vantagens é que esta
transfere do sistema cognitivo para o sistema perceptivo a carga despendida para uma
determinada tarefa, aproveitando, assim, a habilidade do ser humano no reconhecimento
de padrões e estruturas em informações visuais [Robertson et al., 1993].

Figura 1. Visão de alto nível da abordagem proposta.

 A abordagem é dita centralizada porque reúne em um único mecanismo
diferentes visões (ou abstrações) do software. Uma outra característica importante desta
abordagem é sua consistência com o software. Isto é, cada visão deverá refletir o estado
atual do projeto no que tange ao seu domínio de representação. Adicionalmente, a
abordagem é dita uniforme porque apresenta através de um único e compartilhado meio
as informações do projeto. Isto faz com que todos tenham uma percepção comum
relacionada às diferentes facetas do software. Entretanto, é importante observar que a
pertinência de um dado conjunto de informações é uma função das próprias
características do projeto em questão. Por exemplo, em projetos onde o
desenvolvimento ocorre de forma distribuída, informações relativas a dispersão
geográfica dos desenvolvedores se tornam pertinente, enquanto que em um projeto onde
desenvolvedores encontram-se co-localizados esta informação pode não apresentar
grande importância. Desta forma, faz-se necessária a criação de um modelo extensível
de percepção que possa ser aplicado em diferentes contextos de desenvolvimento de
software.
Apesar da ampla gama de informações que podem ser obtidas durante o processo
de desenvolvimento de software, um breve estudo da literatura [Ko et. al., 2007]
[Gutwin et. al., 2004] [Biehl et. al., 2007] [De Souza et. al., 2003] [LaToza et. al., 2006]
aponta para um conjunto essencial de informações que constantemente precisam ser
percebidas ao longo de um projeto de software, co-localizado ou distribuído, para que
este possa ser executado com sucesso. O conjunto engloba informações referentes às
pessoas, artefatos, atividades e localizações de pessoal. Apesar de representarem
informações pertinentes quando observadas de forma individual, a observação dos
relacionamentos entre estas diferentes entidades é que proporcionará uma maior
percepção sobre o projeto. Cada relacionamento deste tem por objetivo revelar uma
dada característica do projeto ou de sua dinâmica. A seguir, as informações relevantes
contempladas inicialmente por este trabalho são apresentadas.
(i) A informação de estrutura (design) apresentará como os artefatos (neste caso,
restringindo-se a classes ou pacotes) relacionam-se entre si. (ii) A informação de
especialistas, apresentará o relacionamento que existe entre uma pessoa (desenvolvedor)
e um artefato. Isto é, responderá, por exemplo, a seguinte pergunta: Quais são as classes
que uma dada pessoa possui maior experiência? Neste caso, a quantificação de
experiência será dada pela porcentagem do código atual que um dado desenvolvedor
implementou. (iii) A informação de concorrência tem por objetivo mostrar que uma
dada pessoa está trabalhando, em um momento do tempo, em um mesmo artefato que
uma outra pessoa. (iv) A informação de dispersão apresentará em um mapa o
relacionamento entre as pessoas e suas respectivas localizações, ou seja, preencherá o
mapa mostrando onde cada pessoa participante do projeto se encontra fisicamente. (v) A
rede social-geográfica é a rede social do projeto aplicada a um mapa. Quando um
desenvolvedor entrar em conflito (i.e. concorrência) com um outro desenvolvedor pela
primeira vez, uma aresta será criada na rede social. Posteriormente, cada vez que ambos
entrarem em conflito novamente, o peso de tal aresta será acrescido de uma unidade.
Portanto, esta rede refletirá o grau de concorrência entre os desenvolvedores,
implicando, possivelmente, em uma rede que apresente as necessidades de comunicação
do projeto. Esta informação aliada com a localização geográfica trará, então, uma
informação extremamente relevante no que tange a coordenação do projeto. Por
exemplo, um gerente ao perceber que está havendo a necessidade de comunicação entre
pessoas geograficamente dispersas, poderá tomar medidas para minimizar este
fenômeno, uma vez que o mesmo pode trazer atrasos e aumento de custos no projeto
[Herbsleb e Mockus, 2003]. (vi) A informação de tarefas deverá mostrar quem está
trabalhando em que, ou seja, relacionando pessoas a suas atividades no projeto.
Outro aspecto importante da abordagem proposta é que a mesma pretende
explorar a complementaridade das informações relevantes para formar as visões do
software. Desta forma, em uma única visão serão apresentadas as informações da
estrutura, especialista e concorrência, explorando a complementaridade em torno do
artefato. Note que, com isto, a interação com uma informação relevante deverá surtir
efeito nas demais informações. Por exemplo, ao se selecionar um dado artefato na
estrutura do projeto, a lista de especialistas deverá refletir apenas aqueles que o são para
este determinado artefato. Esta complementaridade também será explorada entre as
visões, utilizando uma entidade comum encontrada em ambas. A Figura 2 ilustra o
modelo proposto bem como a entidade utilizada para a navegação entre as visões.

Especialistas
Estrutura

Concorrência

Pessoas Pessoas

Dispersão
Tarefas
Rede Social-Geográfica Pessoas

Figura 2. Modelo de percepção proposto.

Além disto, repare que esta complementaridade também deverá apoiar o reúso
de estruturas visuais, predispostas a apresentar determinadas informações, para
visualizar outros tipos de informação relevante. Como é o caso, por exemplo, das
informações design e concorrência. Ambas utilizarão a mesma estrutura visual para
gerar percepção, a saber, um diagrama de classes ou pacotes. Neste exemplo, a
concorrência, ou ao menos uma parte desta, será apresentada juntamente com o design
através de uma estratégia de coloração de elementos (ex.: fundo vermelho para
elementos que estão em conflito e branco para elementos sem conflito).

3. Trabalhos Relacionados
A ferramenta Expertise Browser [Mockus e Herbsleb, 2002] utiliza dados de projeto
obtidos a partir de sistemas de controle de mudanças (SCM) e sistemas de controle de
versão (SCV) para identificação de especialistas. Esta classificação ocorre a partir de
uma abordagem baseada em quantificação de experiência, já que existem evidências
experimentais [Ackerman e Halverson, 1998] de que a experiência é o principal critério
utilizado por desenvolvedores no reconhecimento de especialistas. Por outro lado, a
ferramenta Expertise Recommender [McDonald e Ackerman, 2000] baseia-se em um
conjunto de heurísticas para realizar a identificação e seleção dos especialistas.
Diferentemente da ferramenta Expertise Browser, onde o usuário navega até o
especialista desejado, a abordagem Recommender utiliza um sistema de requisição e
resposta. Isto é, o usuário cria uma requisição contendo informações que indicam a sua
necessidade e a envia para um servidor Recommender. Em ambos os casos, apenas a
perspectiva dos especialistas é explorada.
A ferramenta Augur [Froehlich e Dourish, 2004] é um sistema de visualização
que tem como objetivo prover informações, ao longo do tempo, da estrutura de artefatos
de um projeto e de suas atividades relacionadas. Isto é, a ferramenta parte da premissa
de que, em um processo de desenvolvimento de software, existem basicamente dois
tipos de complexidade que os desenvolvedores costumam lidar. A primeira é inerente
aos artefatos gerados ao longo do processo, neste caso, trata-se de código fonte. A
segunda complexidade refere-se às atividades por meio das quais tais artefatos são
gerados. Assim, esta abordagem procura, além de apresentar a evolução dos elementos
de um projeto ao longo do tempo, correlacionar tais eventos geradores de mudança às
atividades estabelecidas ao longo do projeto. Já a ferramenta EvolTrack [Cepeda et. al.,
2008] apresenta de forma evolutiva o design do software. Sua arquitetura modular
possibilita que a abordagem possa ser customizada para diferentes cenários de uso. Por
exemplo, a ferramenta é capaz de visualizar, na forma de diagramas de classe UML,
toda a evolução de um dado projeto desenvolvido a partir da plataforma Eclipse. Repare
que estas ferramentas têm como foco principal apenas a estrutura de artefatos de um
projeto.

4. Considerações Finais
Sabe-se que os desenvolvedores de um projeto de software gastam grande parte do
tempo comunicando-se uns com os outros [DeMarco e Lister, 1987]. Entretanto, temos
que tal comunicação apenas ocorre de maneira eficaz quando aquele desenvolvedor sabe
a quem procurar e sabe corretamente sobre o que discutir. Entretanto, a falta de
percepção sobre o projeto pode consideravelmente dificultar estes requisitos ao longo de
um processo de desenvolvimento de software, causando muitas vezes o seu fracasso.
Neste contexto, diversas soluções já foram empregadas a fim de solucionar, ou ao
menos amenizar, uma dimensão do problema. Porém, nenhuma aborda o problema a
partir de várias perspectivas simultaneamente, desconsiderando assim o potencial de
percepção que pode ser gerado através da exploração de informações complementares.
Portanto, o principal resultado esperado por este trabalho é a criação de uma abordagem
unificada e extensível para o problema da percepção, onde a partir de um único meio
diferentes perspectivas do software poderão ser percebidas.
O trabalho foi dividido em quatro etapas. A primeira, parcialmente concluída,
consiste em uma revisão bibliográfica sobre as necessidades de percepção no
desenvolvimento de software. A segunda etapa, já iniciada, visa a pesquisar para cada
tipo de informação relevante a estrutura visual adequada de representação. A terceira
etapa envolve a construção do mecanismo necessário para materializar as idéias
propostas, sendo adotado um processo iterativo e evolutivo onde cada iteração será
responsável por adicionar uma nova informação a ser visualizada. Por fim, a quarta
etapa consiste na elaboração de uma avaliação desta abordagem. Neste contexto, a
percepção obtida por um individuo pode ser avaliada, a principio, a partir de duas
dimensões: tempo e qualidade. Isto é, pode-se observar se a introdução desta abordagem
reduz o tempo para perceber (time to perceive – TTP) uma determinada informação ou
se através desta o usuário consegue obter uma experiência perceptiva mais rica,
percebendo informações antes não percebidas diretamente. Desta forma, cada
informação relevante descrita anteriormente deverá ser avaliada, possivelmente
utilizando um experimento controlado, através de uma destas duas perspectivas.

Referências
Ackerman, M.S.; Halverson, C. (1998) “Considering an Organization’s Memory”, Em:
Proc. of the CSCW’98, pp. 39-48, ACM Press, Seattle, WA, EUA.
Biehl, J.T.; Czerwinski, M.; Smith, G. et. al. (2007) “FASTDash: A Visual Dashboard
for Fostering Awareness in Software Teams”, Em: Proc. of the CHI’07, pp. 1313-
1322, San Jose, EUA.
Brooks, F.P (1995) “The Mythical Man-Month: Essays on Software Engineering”,
Addison Wesley.
Cepeda, R.S.V.; Murta, L.G.P.; Werner, C.M.L. (2008) “Visualizando a Evolução de
Software no Desenvolvimento Distribuído”, Em: Anais do II WDDS, Campinas,
São Paulo, pp. 45-54.
DeMarco, T.; Lister, T. (1987) “Peopleware: productive projects and teams”, New
York: Dorset House Publishing.
De Souza, C. R. B.; Redmiles, D. F.; Mark, G. et. al. (2003) “Management of
Interdependencies in Collaborative Software Development”, 2003 Em: Proc. of
the ISESE’03, pp. 294-303, Itália, Setembro.
Dourish, P.; Belloti, V. (1992) “Awareness and Coordination in Shared Workspaces”,
Em: Proc. of the CSCW’92, pp. 107-114, Toronto, Canadá, Novembro.
Froehlich, J.; Dourish, P. (2004) “Unifying Artifacts and Activities in a Visual Tool for
Distributed Software Development Teams”, Em: Proc. of the 26th ICSE, pp. 387-
396, Edinburgh, Escócia, Maio.
Gutwin, C.; Penner, R.; Schneider, K. (2004) “Group Awareness in Distributed
Software Development”, Em: Proc. of the CSCW’04, pp. 72-81, Chicago, EUA.
Herbsleb, J.D.; Mockus, A. (2003) “An Empirical Study of Speed and Communication
in Globally-Distributed Software Development”, IEEE Transactions on Software
Engineering, vol. 29, no. 6, pp. 481-494, Junho.
Ko, A. J.; DeLine, R.; Venolia, G. (2007) “Information Needs in Collocated Software
Development Teams”, Em: Proc. of the 29th ICSE, pp. 344-353,Minneapolis,EUA.
Kraut, R.E.; Streeter, L.A. (1995) “Coordination in Software Development”, Comm. of
ACM, vol. 38, no. 3, pp. 69-81, Março.
LaToza, T. D.; Venolia, G.; DeLine, R. (2006) “Maintaining Mental Models: A Study of
Developer Work Habits”, Em: Proc. of the 28th ICSE,pp. 492-501, Shangai, China.
McDonald, D.W.; Ackerman, M.S. (2000) “Expertise Recommender: A Flexible
Recommendation System and Architecture”, Em: Proc. of the CSCW’00, pp. 231-
240, Philadelphia, PA, EUA.
Mockus, A.; Herbsleb, J.D. (2002) “Expertise Browser: A Quantitative Approach to
Identifying Expertise”, Em: Proc. of the 24th ICSE, pp. 503-512, Orlando, Florida.
Robertson, G.; Card, S.; Mackinlay, J. (1993) “Information visualization using 3-D
interactive animation”, Comm. of the ACM, vol. 36, n. 4, pp. 57-71, Abril.