J. L. de Oliveira
Technical Report - RT-INF_004-11 - Relatório Técnico February - 2011 - Fevereiro
The contents of this document are the sole responsibility of the authors. O conteúdo do presente documento é de única responsabilidade dos autores.
Instituto de Informática Universidade Federal de Goiás
Taciano Messias Moraes
∗taciano@inf.ufg.br
Adriana Silveira de Souza
†adrianasouza@inf.ufg.br
Juliano Lopes de Oliveira
‡juliano@inf.ufg.br
Abstract. Effective communication has always been of fundamental importance in projects of all kinds and areas. For software development projects, this concern is equally valid. And even in Computing, an area that counts on the assistance of nume-rous technologies and methodologies specific to this, the difficulties seem to persist. The purpose of this paper is to perform a systematic study on communication in soft-ware development, to identify the stages and ways that it occurs, means used, best practices, main problems and possible solutions.
For this, it was used the systematic review methodology, which raised the most impor-tant scientific articles published on this subject, thereby enabling the analysis of how important this issue is being considered in academic and corporate environment.
Keywords: Software Development, Communication, Systematic Review, Software Engineering.
Resumo. Uma comunicação eficaz sempre foi de importância fundamental em proje-tos das mais variadas naturezas e áreas. Para projeproje-tos específicos à construção de software, esta preocupação é igualmente válida. E mesmo na Computação, área que conta com o auxílio de inúmeras tecnologias e metodologias específicas para isto, as dificuldades parecem persistir.
Este trabalho se propõe a realizar um estudo sistematizado sobre a comunicação no desenvolvimento de software, a fim de identificar as etapas e formas em que esta ocorre, os meios utilizados, suas boas práticas, os principais problemas ocorridos e suas possíveis soluções.
Para isto, foi utilizada a metodologia de Revisão Sistemática, que levantou os mais im-portantes artigos científicos publicados sobre este tema, possibilitando assim a aná-lise do quão importante esta questão está sendo considerada no meio acadêmico e no meio corporativo.
Palavras-Chave: Desenvolvimento de Software, Comunicação, Revisão Sistemática, Engenharia de Software.
∗Instituto de Informática, UFG – Orientando †Instituto de Informática, UFG – Orientadora ‡Instituto de Informática, UFG – Co-Orientador
1
Introdução
Desde o surgimento da Computação até os dias atuais, percebe-se que a maioria das pes-quisas acadêmicas é concentrada no desenvolvimento de ferramentas e tecnologias [6].
Apesar de relativamente novos, já existem alguns ramos de estudo da computação que focam especificamente no desenvolvimento e na gestão humana, defendendo que a maior difi-culdade desta área atualmente não é mais lidar com máquinas e sim com pessoas.
Dos 4 P’s da Gerência de Projetos de Software, são vários os autores que destacam a im-portância do primeiro P (Pessoas): "Na verdade o fator Pessoas é tão importante que o Software Engineering Institute desenvolveu um modelo de maturidade e capacitação para gerência de pessoas (PM-CMM - People Management Capability Maturity Model)"[16].
As próprias IEEE e ACM já elaboraram um documento guia [11] para programas de gra-duação, que foca especialmente no ensino destes aspectos humanos, geralmente menospreza-dos. Nele, é sugerido que os cursos de computação deveriam abordar atividades como: trabalho em equipe, gerenciamento, comunicação (oral e escrita), etc. E mais, é recomendado que o tempo empregado nestes aspectos humanos seja de 15% a 20% do total de horas curriculares, o que denota uma evidente preocupação com o ensino destas habilidades no meio acadêmico.
O mercado também já percebeu a importância deste lado humano da computação. De acordo com o estudo publicado em [8], os vice-presidentes de três das maiores companhias de tecnologia, quando perguntados sobre qual era o fator de maior relevância para o sucesso de um projeto, todos responderam que o mais importante eram as pessoas por trás deste.
Por estes motivos, este trabalho centra justamente neste lado indiscutivelmente importante e frequentemente esquecido: as pessoas.
Quanto à gerência e interação destas pessoas em projetos, a principal forma de realizá-la (senão a única) é através da comunicação. Explicando assim, a preocupação com esta questão em [1]: "Uma das principais máximas de uma boa engenharia de software é que deve haver boa comunicação entre os usuários do software e os engenheiros deste software". O mesmo se aplica à comunicação entre gerentes, projetistas e desenvolvedores.
Uma vez que a comunicação é utilizada durante todo o projeto e por todos os seus mem-bros sem exceção, a eficácia da comunicação influencia de forma determinante a qualidade do processo executado e, consequentemente, a qualidade do produto final gerado pelo projeto.
"Pesquisas indicam que falhas de comunicação são as fontes mais freqüentemente citadas de conflitos interpessoais. Como as pessoas passam cerca de 70% de suas horas de vigília se comunicando - escrevendo, lendo, falando, escutando -, parece razoável afirmar que uma das principais forças que podem impedir o bom desem-penho de um grupo é a falta de uma comunicação eficaz." [18]
Paradoxalmente, a comunicação em grande quantidade também pode atrapalhar um pro-jeto. Como mostrado em [12], interrupções freqüentes para atender ligações ou verificar emails podem comprometer seriamente a produtividade dos empregados. Apesar dos inúmeros apelos pró-comunicativos às organizações, é importante deixar evidente que o seu excesso pode ser tão prejudicial quanto a sua escassez.
É importante notar que as dificuldades de comunicação tendem a se agravar com o au-mento do número de pessoas envolvidas no projeto, se tornando um fator crítico em grandes corporações. Deste fato deriva um dos axiomas fundamentais da Engenharia de Software que determina que o esforço (quantidade de pessoas) e o tempo (quantidade de meses, por exemplo) não são recursos intercambiáveis em projetos de software, ou nas palavras da célebre frase:
"A adição de recursos humanos a um projeto de software atrasado irá atrasá-lo ainda mais."[6]
De acordo com [2], 24% dos projetos de desenvolvimento de software falham completa-mente, sendo cancelados ou entregando produtos que nunca serão utilizados. O percentual de projetos que terminam com desvios no orçamento ou cronograma chega a 44%, e apenas 32% dos projetos termina com sucesso.
Apesar de cômica, a Figura 1 retrata de forma bastante trágica como grande parte dos projetos citados nas estatísticas anteriores acabam sendo: uma equipe fragmentada com visões completamente divergentes sobre o mesmo produto e um cliente que acaba pagando bem mais por algo totalmente diferente do que ele precisava.
Mesmo que todos os profissionais citados na figura fossem extremamente competentes, sem uma comunicação eficaz, dificilmente o fim do projeto seria diferente.
Como apontado em [13], dentre todas as causas que podem fazer um projeto falhar, a que mais tem influência sobre as outras é a comunicação. Mesmo havendo casos (raros) de projetos cuja falha ocorreu devido a uma única causa, com uma comunicação eficaz entre a equipe, certamente o prejuízo teria sido menor.
Por este motivo, a próxima seção trata especificamente sobre a questão da comunicação, fazendo uma introdução ao seus principais fatores e classificações.
1.1
Sobre a Comunicação
Partindo de sua morfologia, tem-se que a palavra Comunicação teve sua origem do latim, Communicatio, do verbo Communicare, que significa: "Fazer comum. Compartilhar, dividir, receber, participar"[15]. Apenas por seu significado já se pode perceber que a comunicação não existe se o ouvinte não entender de fato a mensagem.
Analisando, portanto, o Processo Comunicativo tradicional de acordo com a perspectiva computacional de [20], que analisa a comunicação entre apenas um emissor e um receptor, pode-se chegar a um modelo geral deste processo:
Figura 2: Representação do Processo Comunicativo, retirada de [18]
Esta mesma representação pode ser utilizada de forma análoga para a comunicação hu-mana, chegando-se assim aos seguintes fatores básicos ao processo comunicativo:
• Emissor: É aquele que produz, codifica e então transmite a mensagem, a fim de causar alguma reação ao receptor.
• Receptor: Aquele que recebe, decodifica e interpreta a mensagem. • Mensagem: Informação a ser transmitida.
• Canal: Meio pelo qual a mensagem é transmitida.
• Código: Conjunto estruturado de signos utilizados na codificação da mensagem. • Contexto: A situação referente à transmissão da mensagem.
• Ruído: Perturbação ocorrida com algum dos elementos anteriores que, de alguma forma, causa alguma interferência na comunicação.
• Feedback (Realimentação): permite ao emissor acompanhar o resultado de sua mensa-gem, se esta causou ou não a reação esperada.
Como dito anteriormente, o modelo apresentado é apenas uma visão simplificada e me-canizada da comunicação. Quando observando tal processo no âmbito de uma organização ou para um grupo de pessoas, faz mais sentido analisar a comunicação como proposto em [21]. Para ele, a comunicação pode ser representada metaforicamente como uma orquestra, onde vá-rias pessoas estão envolvidas, cada uma influenciando à sua forma na "execução da peça". Da mesma forma ele considera a influência de cada um dos fatores anteriores, alterando a respon-sabilidade única do emissor e a atribuindo a todos eles.
1.1.1 Categorização da Comunicação
Uma vez que a temática da comunicação é extremamente abrangente e diversificada, não é de se estranhar que sejam igualmente diversificadas as formas em que esta é categorizada.
Portanto, faz-se importante apresentar as principais classificações existentes, para em se-guida discutir uma proposta de categorização que permitiu abranger todas as comunicações ocorridas no desenvolvimento de software e que foi utilizada no decorrer deste trabalho.
• Classificação por sincronia
Síncrona: Permite resposta ou feedback instantâneo.
Assíncrona: Quando o momento da resposta é indeterminado.
• Classificação por formalidade
Formal: Comunicação planejada, oficializada e controlada. Informal: Espontânea, desordenada e não gerenciável.
• Classificação por código/canal
Verbal: Quando o código da comunicação se baseia em palavras. Oral - Se utiliza do canal da fala.
Escrita - Se utiliza do canal da escrita.
Não-Verbal: Quando o código se baseia em símbolos, gestos e sons. Visual - Se utiliza do canal das imagens.
Sonora - Se utiliza do canal dos sons. Cinestésica - Se utiliza do canal do tato.
A comunicação não-verbal foi pouco explorada neste trabalho uma vez que esta é bastante imprecisa e poucos estudos a abordam em profundidade. Portanto, esta e suas subdivisões ficam somente à título de informação.
Baseando-se nas várias classificações existentes e com a intenção específica de melhor abranger os vários tipos de comunicação existentes durante o processo de desenvolvimento de software, este trabalho propõe uma divisão da comunicação em três aspectos:
• Linguístico - Uma vez que em alguns casos a comunicação não possui uma forma simples de Feedback e deve ser interpretada da forma em que está disponível; como no caso da implementação de funcionalidades de uma especificação de requisitos de software.
• Individual - Abordando o lado psicológico da comunicação, a fim de cobrir a dificuldade de determinadas pessoas a se comunicar.
• Organizacional - Considerando a comunicação de forma mais ampla, verificando a exis-tência de problemas gerenciais ou com um determinado grupo.
Esta divisão permite ainda a atribuição de um tipo de classificação da comunicação a cada aspecto, onde o linguístico pode englobar a classificação em síncrona e assíncrona; o individual realiza a classificação entre verbal e não-verbal; e o organizacional classifica em formal e informal.
Embora estas classificações não estejam obrigatoriamente relacionadas a estes aspectos, pode-se verificar uma grande compatibilidade entre eles, de forma que esta correlação permitiu uma grande simplificação na diferenciação das várias classificações e suas aplicações.
1.1.2 Aspecto Linguístico
A teoria da Gramática Transformacional [7], afirma que para a comunicação é utilizada uma linguagem que, após uma série de "transformações gramaticais", converte nossos pensa-mentos em frases.
Para explicar melhor este raciocínio, são utilizados dois conceitos, o de Estrutura Pro-funda e o de Estrutura Superficial, que podem ser resumidamente descritos como:
• Estrutura Profunda - Representa nossas idéias e pensamentos abstratos
• Estrutura Superficial - É o resultado da transformação destas idéias em frases, por meio da linguagem, através de um processo chamado "derivação"
Provavelmente estes dois termos foram adaptações do par da semiótica Significado e Sig-nificante [19], que podem ser comparados à Estrutura Profunda e Superficial, respectivamente, com a única diferença que o Significante é um objeto físico do mundo real, ao invés de uma mera representação linguística.
Por definição, pode-se afirmar que uma Estrutura Profunda jamais seria igual à sua Es-trutura Superficial, uma vez que a primeira é uma representação mental, modelada em uma "linguagem do pensamento", enquanto que a segunda é uma representação verbal, modelada em uma linguagem gramatical. A partir desta idéia, pode-se concluir que sempre que uma Es-trutura Profunda se transforma em uma EsEs-trutura Superficial (e vice-versa) ocorre algum tipo de perda de informação, classificada da seguinte forma:
• Eliminação - A supressão de alguma informação considerada não fundamental para dar lugar a outra considerada fundamental
• Distorção - A substituição ou adequação de informações para ajustá-las a uma determi-nada necessidade
• Generalização - O agrupamento de experiências consideradas semelhantes por possuírem algum elemento em comum
Aplicando estes conceitos à Engenharia de Requisitos, pode-se imaginar um exemplo simples de um requisito funcional passado pelo cliente através da seguinte Estrutura Superficial:
"O sistema deve possuir um gerenciador de usuários."
À primeira vista, este requisito pode parecer simples e bem definido, porém, sua Estrutura Profunda pode ser muito mais abrangente que o que foi passado ao Engenheiro de Requisitos através da linguagem, como se pode ver:
"O sistema deve possuir uma forma de cadastrar, editar e remover seus usuários. Além disso, deve possuir uma tela de abertura onde estes deverão se autenticar
para acessar o sistema. Ele deve também ser devidamente personalizado para cada usuário, apresentando diferentes funcionalidades com diferentes permissões.
O administrador do sistema, por sua vez, é quem deve definir previamente estas permissões."
Com este exemplo, pode-se ter uma idéia de quanta informação pode ser perdida por parte do emissor pela ocorrência de transformações que causam Eliminações, Distorções ou Gene-ralizações. Desta forma, sem recorrer diversas vezes ao cliente, dificilmente o engenheiro de requisitos conseguiria chegar à mesma Estrutura Profunda deste, o que provavelmente acarreta-ria num software incompatível com os desejos deste cliente. Há ainda o problema inverso, por parte do receptor, em que o próprio Engenheiro de Requisitos tem estes mesmos tipos de perda de informação ao realizar o seu entendimento da comunicação.
Apesar de o exemplo anterior tratar especificamente de um caso da Engenharia de Requi-sitos, este problema se aplica a qualquer outra área na qual a comunicação exista, seja ela escrita ou falada. Portanto, é necessário ressaltar que este mesmo cuidado linguístico deve ser aplicado a todas as outras formas de comunicação ocorridas no desenvolvimento de um software.
Em relação à classificação da comunicação em síncrona e assíncrona, é importante lem-brar o modelo da Figura 2, uma vez que a sua diferença está justamente na possibilidade de feedback simultâneo. Para ilustrar melhor, alguns exemplos de cada uma:
1.1.3 Aspecto Individual
Outra abordagem explorada por este trabalho consiste na dificuldade de comunicação, porém, sob um aspecto mais psicológico:
"Um outro grande obstáculo à comunicação eficaz é que algumas pessoas - estima-se que entre 5 e 20 por cento da população - sofrem de um debilitante medo da comunicação, ou ansiedade."[18]
Mesmo que este medo ou ansiedade não sejam tão extremos a ponto de anular todas as formas de comunicação possíveis, é muito comum este tipo de problema afetar justamente as outras pessoas que não têm receio de se comunicar, pois estas acabam não sendo informadas de questões ou alterações importantes do sistema.
Na Computação, foi verificado que esta taxa é ainda mais alta [3]. Por este motivo, serão investigadas técnicas de terapia e comunicação em grupo com o intuito de desinibir os membros da equipe com este problema, aumentando, assim, o rendimento de todo o grupo.
1.1.4 Aspecto Organizacional
Há também casos em que o problema não se encontra em um só indivíduo ou processo, como citado, mas em toda a cultura da empresa. Exemplos disso são empresas que possuem um clima de desconfiança e apatia em que os empregados se sentem ameaçados e injustiçados pelos gerentes enquanto os gerentes se sentem criticados e ironizados pelos empregados.
Em casos de complexidade mais séria como este, deve-se trabalhar a cultura da empresa inteira, tanto dos empregados como dos gerentes. Modificar o comportamento organizacional de uma corporação é algo extremamente trabalhoso e caro, porém, que pode trazer resultados significativos a longo prazo, melhorando não somente a lucratividade da empresa como também o bem estar de seus funcionários.
1.2
Sobre a Revisão Sistemática
Como foi adotada a metodologia de revisão sistemática para este trabalho, esta seção e a seguinte servirão como forma de apoio para a utilização de tal técnica.
Antes de qualquer coisa, faz-se necessária a definição do que é uma revisão sistemática e de quais são os seus propósitos, como se pode ver no seguinte texto:
"Uma revisão literária sistemática é um meio de identificar, avaliar e interpretar todas as pesquisas disponíveis relevantes a uma determinada questão de pesquisa, ou área de um tópico, ou fenômeno de interesse. Estudos individuais que contri-buem para uma revisão sistemática são chamados estudos primários; uma revisão sistemática é uma forma de estudo secundário."[14]
Como foi explicado acima, a Revisão Sistemática se propõe a bem mais que somente endossar a fundamentação teórica deste projeto, o que implica num trabalho de maior extensão e numa maior dificuldade de realização. Apesar disso, existem algumas fortes razões para se utilizá-la que merecem ser destacadas:
• "Identificar as soluções propostas para resolver os problemas levantados;
• Identificar os métodos de pesquisa usados para investigar as soluções propostas; • Provir um framework para o posicionamento de novas atividades de pesquisa; • Identificar lacunas nas atuais pesquisas." [5]
Além disso, analisando os diversos estudos disponíveis de um determinado tema, esta permite verificar evidências empíricas que suportam ou refutam hipóteses teóricas, permitindo ainda a elaboração de novas hipóteses.
Aplicando ao escopo deste trabalho então, a revisão sistemática fornecerá uma forma estruturada de pesquisa e catalogação do material disponível sobre a Comunicação dentro do Processo de Desenvolvimento de Software. Através desta metodologia, este trabalho servirá também como base para futuras pesquisas, mostrando as possíveis lacunas da área que permitem novas publicações acadêmicas.
1.3
Estrutura do Documento
Nesta seção, são apresentadas as fases de uma revisão sistemática, os passos de cada uma destas e como será sua organização e disposição dentro da estrutura deste trabalho.
A Figura 3 mostra que uma Revisão Sistemática pode ser dividida em três fases: Planeja-mento, Condução e Documentação.
Figura 3: Ilustração do Processo de Revisão Sistemática, retirada de [5]
Desta forma, a Seção 2, aborda a fase de Planejamento, começando a partir da elaboração das questões de pesquisa relativas ao tema até a produção do Protocolo de Revisão.
A Seção 3 descreve como foi a fase de Condução, envolvendo a construção da String de Busca, a execução das buscas e uma seleção preliminar feita em cima dos resultados obtidos.
A fase de Documentação se encontra descrita na Seção 4, onde se encontram classificados os resultados selecionados pela seleção final.
Finalizada a execução da Revisão Sistemática, foi feita uma análise sobre os estudos primários obtidos, que se encontra disponível na Seção 5.
Por fim, a Seção 6 conta com algumas considerações finais acerca deste trabalho, indi-cando quais as conclusões obtidas e possíveis trabalhos futuros.
2
Planejamento da Revisão Sistemática
Nesta primeira fase de planejamento, faz-se definido o Protocolo de Revisão, informando o propósito e os objetivos do trabalho; as fontes, estratégias e questões de pesquisa; os critérios e procedimentos de seleção dos resultados; e a forma de extração dos dados destes resultados.
Por meio deste protocolo, que foi baseado nos modelos disponíveis em [4, 14], fica descrito todo o processo de revisão, permitindo assim, que outros pesquisadores repitam esta mesma pesquisa e obtenham resultados similares.
2.1
Objetivos
Baseando-se no estudo prévio sobre o tema do trabalho e utilizando-se das orientações para pesquisa presentes em [9], foram definidos os seguintes objetivos para esta revisão:
I. Identificar a importância da comunicação para o processo de desenvolvimento de soft-ware.
II. Identificar as formas de comunicação que ocorrem e quando estas ocorrem durante o processo de desenvolvimento de software.
III. Identificar as ferramentas, tecnologias, processos e metodologias existentes específicos para a melhoria da comunicação neste processo.
2.2
Questões de Pesquisa
A partir dos objetivos estabelecidos anteriormente e das recomendações contidas em [5], foram elaboradas as seguintes questões de pesquisa primárias (1, 2 e 3) e secundárias (a e b):
1. Qual importância está sendo dada à comunicação no processo de desenvolvimento de software?
2. Quais formas de comunicação estão sendo mais enfatizadas e em quais etapas do processo de desenvolvimento de software elas são utilizadas?
a. Quais as suas possíveis boas práticas e dificuldades?
3. Quais ferramentas, técnicas, habilidades, processos e metodologias estão sendo utilizadas focadas nesta questão?
b. Quais delas possuem estudos empíricos que evidenciam melhorias na comunicação?
É importante ressaltar o caráter basicamente causal da primeira questão, enquanto as ou-tras duas são mais amplas e possuem um caráter mais exploratório.
Apesar de questões com esta amplitude serem próprias para Estudos de Mapeamento, como defendido em [10], aqui elas foram empregadas com o intuito de possibilitar um maior detalhamento e abrangência à resposta da primeira questão.
Existem ainda, como citado em [4], alguns outros itens relacionados ao escopo e especi-ficidades das questões de pesquisa que merecem destaque:
• Intervenção: A comunicação dentro do processo de desenvolvimento de software. • Controle: Coleção de livros, revistas, jornais e artigos levantados que abordam o tema da
comunicação e do processo de desenvolvimento de software
• População: Estudos e pesquisas abordando a comunicação no desenvolvimento de soft-ware.
• Resultados: Dificuldades, problemas, boas práticas, ferramentas, processos e metodolo-gias específicas à comunicação dentro do processo de desenvolvimento de software.
• Aplicação: Estudos posteriores sobre este mesmo tema, bem como ferramentas, proces-sos e metodologias específicas para a melhoria da comunicação; equipes de desenvolvi-mento de software; podendo ter aplicação também para as áreas Gerência de Projetos e Gestão da Comunicação.
2.3
Estratégias de Busca
Esta seção descreve onde e como foram realizadas as buscas, bem como as palavras-chave que geraram a string de busca e as línguas aceitas para os resultados selecionados.
• Fontes: Foram selecionadas como fontes de pesquisa deste trabalho bases de dados inde-xados, máquinas de busca eletrônica e bibliotecas digitais.
– ACM Digital Library1 – Google Scholar2 – ScienceDirect3 – SpringerLink4 – IEEEXplore5 – CiteSeer6 – Scirus7
• Palavras-chave: Baseando-se nas questões de pesquisa levantadas anteriormente, foram definidas as seguintes palavras-chave:
– Communication {Good Practices, Difficulties, Tools, Skills, Process, Methodolo-gies, Improvement}
– Information Technology
– Software {Development, Engineering} – Project Management
• Strings de busca: Visando abordar todas as palavras-chave anteriores e eliminando o máximo possível de resultados não desejados, as strings de busca foram definidas da seguinte forma:
– Title: (("Software Development"OR "Software Engineering"OR "Requirements En-gineering"OR "Project Management"OR "Information Technology") AND "Com-munication")
– Título: (("Desenvolvimento de Software"OR "Engenharia de Software"OR "En-genharia de Requisitos"OR "Gerência de Projetos"OR "Gerenciamento de Proje-tos"OR "Gestão de ProjeProje-tos"OR "Tecnologia da Informação") AND "Comunica-ção")
Estas strings poderão ser adaptadas de acordo com o mecanismo de busca de cada Fonte, porém sempre de forma que não altere o seu sentido lógico.
• Línguas: Inglês, por ser a língua padrão para publicações internacionais;
Português, para ser possível verificar o andamento do assunto em questão nacionalmente, através de possíveis trabalhos realizados no Brasil;
1http://portal.acm.org/ 2http://scholar.google.com/ 3http://www.sciencedirect.com/ 4http://www.springerlink.com/ 5http://ieeexplore.ieee.org/ 6http://citeseer.ist.psu.edu/ 7http://www.scirus.com/
2.4
Critérios de Seleção
Depois de obtidos os resultados das buscas, estes foram analisados quanto à sua relevân-cia, de forma a determinar se deveriam ser considerados como estudos primários ou desconsi-derados. Esta relevância foi analisada de acordo com os seguintes critérios:
• Critérios de Inclusão:
– O resultado deve estar em uma das línguas definidas – O resultado deve estar disponível integralmente
– O resultado deve conter no título e no resumo alguma relação com o tema deste trabalho
• Critérios de Exclusão
– O resultado não trata sobre o tema da comunicação
– O resultado não está no contexto do desenvolvimento de software – O resultado não atinge o critério mínimo exigido de qualidade (nota 7,0)
2.5
Procedimentos de Seleção
Foram realizadas ao menos duas buscas (em inglês e em português) em cada uma das fontes definidas, utilizando-se para isso a String de Busca estabelecida e sua versão traduzida. As execuções destas buscas se encontram disponíveis de forma detalhada na Seção 3.
Cada vez realizada cada busca, esta foi documentada coletando-se todos os resultados retornados e depois contabilizando quantos destes foram repetidos, quantos passaram pelos cri-térios de inclusão e quantos foram previamente excluídos por não obedecerem a estes cricri-térios. Um exemplo desta documentação encontra-se disponível na Tabela 4 do Apêndice 7.
Quando obedecendo a todos os critérios de inclusão, o resultado foi selecionado para ser lido e analisado, de forma a verificar se este não cai em nenhum dos critérios de exclusão. Os resultados selecionados se encontram disponíveis no Apêndice 7, separados por repetidos, incluídos ou excluídos (e nestes últimos, informando qual o critério de seleção que o excluiu).
Tendo o resultado passado com sucesso por todos os critérios de seleção (inclusão e ex-clusão), este foi considerado como um estudo primário, sendo então encaminhado à etapa de análise da qualidade e extração dos resultados, descritas a seguir.
2.6
Análise da Qualidade
Os trabalhos tiveram a sua qualidade analisada pelo cálculo da média aritmética da preci-são das respostas em relação aos aspectos e assuntos estabelecidos pelas questões de pesquisa.
Foi atribuída uma nota de 0 a 10 para cada aspecto dentre os três possíveis e para cada assunto dentre os dez possíveis, quando estes foram abordados na obra. Os aspectos e assuntos relacionados às questões de pesquisa se encontram na Tabela 3 e discutidos na Seção 4.
Aqui é importante ressaltar que o fato desta análise ter sido realizada por apenas um pesquisador pode significar em uma baixa segurança em relação à validade das avaliações feitas. Portanto, fica evidente que este trabalho carece de uma segunda etapa com um grupo maior de pesquisadores para que ele possa ser considerado como seguro quanto à seus resultados.
2.7
Extração dos Resultados
Terminada a leitura de cada um dos trabalhos selecionados, foi preenchido um relatório de extração de dados (em forma de tabela) contendo: título, autores, ano de publicação, quantidade de páginas, palavras-chave, resumo, fonte e uma nota referente à sua qualidade. Um modelo do relatório utilizado encontra-se disponível na Tabela 5 contida no Apêndice 7.
Após a extração dos resultados de todos os trabalhos, foi feita uma segunda seleção para filtrar aqueles que atingiam os critérios de exclusão, restando, portanto, somente os estudos primários deste trabalho, ou seja, aqueles que obedeceram a todos os critérios de seleção.
Na última etapa da extração dos resultados, foi realizada uma análise crítica discursiva sobre todos os estudos primários, fazendo uma comparação sobre o resultado geral obtido, conforme pode ser conferido na Seção 5.
3
Condução da Revisão Sistemática
De acordo com [4], uma das formas de avaliação do protocolo estabelecido é na etapa de condução, através de testes de execução, escolhendo para isto apenas algumas das fontes e examinando uma quantidade limitada de resultados.
Por este motivo, juntamente com o andamento da condução, foram realizados diversos testes de 09/06/2010 a 26/08/2010 com diferentes strings de busca a fim de identificar aquela que teve a melhor taxa de aceitação para então ser definida no protocolo. A contrução desta string de busca se encontra descrita na Seção 3.1.
Após um longo período de iterações e melhorias, as buscas foram concluídas, tendo ocor-rido no período compreendido entre 15/08/2010 e 29/10/2010. Na Seção 3.2 se encontram disponíveis os resultados destas buscas.
Paralelamente à execução das buscas, foi realizado um processo de seleção preliminar baseado no atendimento dos critérios de inclusão definidos. O resultado desta seleção encontra-se descrito na Seção 3.3.
3.1
Construção da String de Busca
Para a fabricação da string de busca, foram escolhidas palavras-chaves relacionadas às questões de pesquisa e, a partir destas, foram elaborados alguns outros sinônimos que poderiam incrementar a pesquisa, como já mostrado nas Seções 2.2 e 2.3.
A partir das várias combinações possíveis das palavras-chave, foram montadas strings de busca através das operações booleanas AND e OR, disponíveis em quase todas as fontes.
Após a realização de alguns testes com estas strings de busca, foram verificadas quais destas tiveram as melhores taxas de aceitação e se a quantidade de resultados retornados era cabível para a execução deste trabalho.
Para facilitar a execução destes testes, foram selecionadas as duas fontes que não exigiam adaptações na string de busca: Scirus e CiteSeer. Além disso, elas foram escolhidas também pelo fato da primeira ser uma das que indexam mais sites, tendo sido utilizada como base para o máximo, enquanto a outra é uma das mais restritas, tendo sido utilizada como base para o mínimo de resultados retornados.
Depois de realizada cada busca, os seus dez primeiros resultados eram analisados de modo a estimar uma taxa de aceitação para cada uma das fontes. As tabelas a seguir demonstram os resultados de um dos testes iniciais e em seguida o resultado do teste final, evidenciando a melhora da string de busca.
Tabela 1: Teste da String de Busca
Conforme pode ser observado na Tabela 1, inicialmente a string de busca abrangia tam-bém o resumo do texto, o que retornava uma enorme quantidade de resultados. Por este motivo, foram feitos novos testes com alterações quanto à busca por resumo e por palavras-chave, vi-sando alterar este quadro.
Entretanto, como estas alterações não surtiram efeito significativo na quantidade de re-sultados ou na taxa de aceitação, mesmo nos testes feitos com as outras fontes, foi decidido eliminar a busca por resumo ou por palavras-chave.
As dez palavras-chave sinônimas que eram buscadas no resumo, que verificavam a re-levância do artigo quanto à comunicação, foram condensadas em apenas uma palavra-chave buscada no título. Já que todas elas possuíam a palavra ’communication’, esta foi utilizada para representar todos os sinônimos, assim, a busca seria mais abrangente e ao mesmo tempo mais relacionada ao tema central, já que todas elas seriam verificadas diretamente no título.
Tabela 2: Teste da String de Busca Otimizada
Depois de uma série de testes com estas novas alterações, foi definida uma string de busca que verificava apenas o título dos trabalhos, como mostrado na Tabela 2, o que reduziu em cerca de uma ordem de grandeza a quantidade de resultados e aumentou em quase duas vezes a taxa de aceitação (para a amostragem analisada).
A desvantagem desta redução na quantidade de resultados seria a baixa amostragem do trabalho, o que poderia levar a uma certa parcialidade (bias) nos resultados, caso a string de busca fosse mal definida. Entretanto, como os resultados foram lidos e analisados a fundo, esta escolha foi preferível ao invés de uma alta amostragem mas uma análise superficial.
3.2
Execução das Buscas
Uma vez definida a string de busca final a ser utilizada, foram realizadas as buscas em inglês e em português em cada uma das fontes determinadas pelo protocolo. Esta seção descreve como foi a busca de cada língua de forma geral, sem se ater nas fontes uma por uma, citando apenas as ocorrências de casos especiais.
As buscas nas fontes ACM, ScienceDirect e CiteSeer transcorreram sem nenhuma dificul-dade ou anormalidificul-dade. Entretanto, nas outras fontes houveram algumas questões que merecem ser destacadas:
IEEEXplore
O site apresentou diversos problemas pela busca padrão, de forma que só foi possível a sua utilização através da busca avançada.
SpringerLink
Grande parte dos resultados eram capítulos de livros e só estavam disponíveis para serem comprados.
Google Scholar e Scirus
Algumas configurações extras tiveram de ser adotadas a fim de tornar a quantidade de resultados passível de ser analisada:
- Obrigatoriedade do formato em PDF
- Busca somente nas áreas relacionadas à Computação - Intervalo do ano de publicação entre 1970 e 2010
3.2.1 Inglês
Como as buscas em inglês eram a prioridade deste trabalho, todos os testes e configura-ções para a otimização da string de busca foram efetuados tomando por base estes resultados.
De forma geral, o resultado final obtido da execução da busca em inglês para cada uma das fontes definidas se encontra representado na Figura 4.
Figura 4: Resultado da execução da busca em inglês
Como pode ser verificado, para a execução da busca em inglês foram retornados 202 resultados, um número ainda significativo, sendo 31% provenientes da fonte IEEEXplore e 19% do Google Scholar, enquanto que todas as outras fontes foram responsáveis por apenas metade dos resultados. A fonte Scirus foi a de menor contribuição, representando apenas 4% do total, seguida pela ACM com 8%.
Neste momento, é importante fazer uma comparação dos resultados das fontes antes e depois das configurações citadas anteriormente, para que seja possível ter uma noção da redução drástica ocorrida.
Anteriormente, as fontes Scirus e Google Scholar somadas retornavam 596 resultados, o que representa quase três vezes o total de resultados. Após as alterações, esta soma caiu para apenas 46, lembrando que a diferença entre estes números são de documentos em outros formatos que não o Pdf, de outras áreas que não a computação ou que não possuíam o ano de publicação.
Da mesma forma pode-se comparar a fonte IEEEXplore, que sozinha retornava 726 re-sultados com a utilização da busca simples, enquanto que com a busca avançada, e as devidas configurações, este número se reduziu para 63 (1052% a menos).
3.2.2 Português
Na execução das buscas em português, quase todas as fontes não tiveram resultados pelo fato da língua padrão de publicação internacional ser o inglês. Entretanto, ainda assim foram retornados 28 resultados, onde a maioria (23) foi do Google Scholar e a minoria (5) do Scirus, como pode exibe a Figura 5.
Figura 5: Resultado da execução da busca em português
Como conclusão desta fase, pode-se verificar que o total retornado pelas buscas das duas línguas foi de 230, sendo que apenas 14% destes estão em português, enquanto que 86% estão em inglês.
3.3
Seleção Preliminar
Terminada a execução das buscas, os resultados retornados foram submetidos aos critérios de inclusão definidos na Seção 2.4. Portanto, foi previamente selecionado todo resultado que estava em inglês ou português; que estava diponível para download; e que continha relação com o tema no título e no resumo.
Após esta fase, os artigos selecionados foram coletados, (parcialmente) lidos e analisados quanto aos critérios de exclusão. Porém, tal discussão cabe à etapa de documentação, abordada na Seção 4.
3.3.1 Inglês
Já na seleção preliminar, mais da metade (97) dos resultados em inglês foram eliminados, sendo que destes, 35 eram repetidos. Conforme mostra a Figura 6, apenas 70 atenderam aos três critérios de inclusão.
Figura 6: Seleção dos resultados em inglês
Verificando a taxa de aceitação das fontes, tem-se que a de melhor taxa foi a ACM, com 69%, sendo que a pior foi a do SpringerLink, com 13%. Entretanto, vale ressaltar que tal taxa foi afetada pelo fato desta fonte disponibilizar alguns artigos somente para compra, o que a fez despencar de segunda melhor (65%) para última.
Em relação à taxa de repetição, a fonte Google Scholar se sobressaiu, tendo mais da metade (58%) de seus resultados repetidos, o que claramente se deve ao fato deste ser um indexador de fontes.
3.3.2 Português
Similarmente à seleção anterior, mais da metade dos resultados em português também foram rejeitados, onde 6, dos 19 que foram descartados, eram repetidos.
Conforme pode ser conferido na Figura 7, dos 28 resultados retornados, somente 9 de-les atenderam aos critérios de inclusão. Novamente a taxa de aceitação do Google Scholar (30%) foi prejudicada pelo número de repetições (tendo obtido todos os resultados repetidos), enquanto que a do Scirus foi de 40%.
Figura 7: Seleção dos resultados em português
Analisando o resultado geral das seleções, inglês e português, tem-se que dos 230 resul-tados retornados, 110 não atenderam aos critérios de inclusão, mesmo com a string de busca otimizada. Considerando que 41 eram repetidos e que 79 foram incluídos, pode-se verificar que a taxa de aceitação total da seleção preliminar foi de 34%.
Na etapa de documentação foi realizada uma nova iteração de seleção para os critérios de exclusão, porém desta vez contando com os dados extraídos dos resultados. A Seção 4 descreve como foi realizada esta outra iteração e faz uma visão geral sobre os artigos finais selecionados por esta revisão sistemática.
4
Documentação da Revisão Sistemática
Na etapa de documentação, os resultados selecionados foram lidos e submetidos a análise de conteúdo, realizando-se, então, uma nova seleção, agora em relação aos critérios de exclusão. Como a verificação dos dois primeiros critérios não necessita da avaliação da qualidade do resultado, uma vez reprovado nestes critérios, o resultado já é prontamente descartado, não mais necessitando de ter a sua qualidade avaliada. Por este motivo, a classificação das Seções 4.1 e 4.2 foi realizada com base nos 67 resultados que passaram pelos dois primeiros critérios de exclusão.
Para que a avaliação fosse a mais imparcial possível, foram definidos dez assuntos relaci-onados às questões de pesquisa que seriam desejáveis, conforme representa a Figura 3. Assim foi dada uma nota a cada aspecto e assunto presente no trabalho, fazendo com que uma nota seja atribuída independentemente das outras.
Tabela 3: Parte do relatório de extração de dados
Vale destacar que os assuntos de 6 a 10 podem fazer referência aos cinco primeiros. Por exemplo, um artigo pode tratar de uma ferramenta (1) e receber nota 7 para este assunto, por esta não auxiliar tanto na comunicação. Apesar disso, seu conteúdo pode indicar as vantagens desta (9) e receber nota 10 por tê-las descrito de forma bastante satisfatória. Isto significa que as notas dos assuntos, mesmo quando referenciados, não necessariamente possuem o mesmo valor, o que garante uma maior imparcialidade à média final entre estas notas.
Com base na etapa de extração dos dados, as Seções 4.1 e 4.2 descrevem como foram as classificações dos resultados quanto a seus aspectos e quanto a seus assuntos, respectivamente. Por fim, a Seção 4.3 finaliza a fase de documentação com uma descrição sobre como foi a seleção final dos resultados, bem como com uma explicação completa sobre a seleção dos dois primeiros critérios de exclusão que precedeu as classificações das seções anteriores.
4.1
Classificação quanto aos Aspectos
4.1.1 Inglês
Como pode ser verificado pela Figura 8, apenas um dentre os 58 artigos em inglês aborda todos os três aspectos da comunicação, sendo que 78% deles trata do aspecto organizacional, 19% trata do aspecto individual e 14% trata do aspecto linguístico.
4.1.2 Português
Analisando, então, os resultados em português em relação aos seus aspectos (conforme a Figura 9), pode-se verificar que todos eles abordam o aspecto organizacional, enquanto 44% aborda o individual e apenas 11% aborda o linguístico.
Figura 9: Resultados em português analisados quanto a seus aspectos
Os resultados em português apresentaram uma maior desigualdade na distribuição, uma vez que um dos aspectos estava presente em todos os trabalhos, enquanto outro foi encontrado em um só trabalho. Tal desigualdade também foi encontrada na classificação em relação aos assuntos contemplados, conforme pode ser verificado a seguir.
4.2
Classificação quanto aos Assuntos
4.2.1 Inglês
Pela Figura 10 pode-se notar que distribuição de assuntos foi relativamente balanceada, uma vez que os dois assuntos empatados como menos abordados (habilidades e metodologias) ainda estiveram presentes em 14% dos artigos, sendo que o mais abordado (modelos e proces-sos) nem chegou a ultrapassar a metade do total, com 45%.
Figura 10: Resultados em inglês analisados quanto a seus assuntos
Vale destacar também que destes artigos, 17% evidencia uma melhoria na comunicação, seja pelo uso de ferramentas e tecnologias, modelos e processos, metodologias, técnicas e dinâ-micas ou pelo desenvolvimento de habilidades.
4.2.2 Português
O resultado em português pode ser representado pela Figura 11.
Figura 11: Resultados em português analisados quanto a seus assuntos
Neste caso, houve um duplo empate: dois mais abordados (problemas e dificuldades; e formas de comunicação), com 67% e dois menos abordados (técnicas ou dinâmicas e metodo-logias) com 11%.
A evidência de melhoria esteve presente em 33% dos artigos. Embora tal porcentagem não signifique que os trabalhos realmente forneçam formas testadas e comprovadas de melhoria na comunicação, fica evidente a preocupação com esta avaliação, mesmo que realizada de forma empírica.
4.3
Seleção Final
Sobre os 79 resultados selecionados pela fase anterior, inicialmente incluídos por obede-cerem aos critérios de inclusão, foi realizada uma nova etapa de seleção, desta vez levando-se em consideração os critérios de exclusão. Destes, 4 foram eliminados pelo primeiro critério de exclusão, ou seja, por não tratarem específicamente do tema da comunicação. Outros 11 não eram específicos ao contexto do desenvolvimento de software, tendo sido reprovados pelo segundo critério de exclusão.
Verificados estes dois primeiros critérios, restaram 67 resultados para serem analisados quanto à sua qualidade e classificados quanto a seus aspectos e assuntos, conforme exibido nas seções anteriores.
Findada a etapa de avaliação da qualidade, estes resultados foram submetidos ao terceiro e último critério de exclusão, de forma que os avaliados com qualidade superior a 7,0 foram aprovados por todos os critérios de seleção.
Dos 67 resultados avaliados, 31 obtiveram nota maior que a exigida e, portanto, foram considerados como estudos primários desta revisão, sendo que destes, 26 se encontram em inglês e 5 em português.
A média geral dos resultados em inglês foi 6,48, enquanto que a dos em português foi 7,02. Levando-se em consideração apenas os selecionados, a média dos em inglês foi 8,18 e a dos em português foi 8,34.
No Apêndice 7 pode ser conferida uma relação com todos os resultados repetidos (Tabela 10), excluídos (Tabela 9) e incluídos nesta fase (Tabela 8). Por meio destas tabelas pode-se verificar ainda quais foram as notas de cada um e os critérios de exclusão que os eliminaram.
A Seção 5 faz uma análise geral sobre os estudos primários obtidos, respondendo, uma a uma, as questões de pesquisa estabelecidas para esta revisão e apresentando os principais achados destes artigos.
5
Análise dos Resultados
Nesta fase da revisão, os trabalhos colhidos foram analisados de acordo com as ques-tões que estes contemplaram. Desta forma, nas seções seguintes as quesques-tões de pesquisa serão novamente retomadas e agora respondidas de acordo com o resultado extraído da análise dos artigos.
Para uma diferenciação mais clara entre as referências bibliográficas e os trabalhos con-siderados como estudos primários, será utilizada a seguinte notação: <Ing-X> ou <Pt-X>, onde X é o número identificador que possibilita localizar o artigo dentre os resultados incluídos pre-sentes na Tabela 8 do Apêndice 7.
5.1
Questão 1
1. Qual importância está sendo dada à comunicação no processo de desenvolvimento de software?
Para responder esta questão, será feita uma análise temporal sobre os trabalhos analisados, exibindo o crescimento da quantidade de pesquisas em torno deste assunto, evidenciando ainda quais aspectos e assuntos tiveram maior e menor crescimento.
Uma vez que esta primeira pergunta se baseia em uma análise basicamente quantitativa que verifica apenas o aumento da quantidade de artigos com o decorrer dos anos, faz-se
inte-ressante considerar também os trabalhos analisados, porém que não foram incluídos apenas por não atenderem ao terceiro critério de exclusão.
Apesar de não terem atingido a nota mínima exigida, ainda assim estes artigos podem ser considerados como interessantes para esta análise, já que obedecem a todos os outros cri-térios de inclusão e ainda tratam do tema da comunicação no desenvolvimento de software. Além disso, vale destacar que com o acréscimo destes, e consequentemente um aumento na amostragem, o crescimento pode ser verificado mais facilmente.
5.1.1 Aspectos
A partir da análise temporal acerca dos aspectos investigados é possível verificar qual deles está atualmente recebendo maior e menor importância, o que será aferido aqui pela quan-tidade de publicações que abordaram estes.
No contexto de uma revisão sistemática tal análise é de fundamental importância por permitir verificar qual dos aspectos estão sendo menos discutidos, o que permite identificar deficiências e dificuldades que podem ser inerentes de determinado aspecto da comunicação.
Inglês
Pela representação cronológica dos resultados em inglês presente na Figura 12 é possível verificar que, dentre todos os aspectos, o organizacional foi o que apresentou o crescimento mais significativo, chegando a quadruplicar a quantidade de artigos escritos na década passada.
Figura 12: Análise temporal dos apectos dos resultados em inglês
O aspecto individual também obteve um certo crescimento neste período, apesar da culdade de visualização deste crescimento pela baixa amostragem destes resultados. Tal difi-culdade também prejudica uma observação do crescimento do aspecto linguístico, entretanto, o fato de os primeiros 15 anos não terem apresentado resultados pode indicar a exploração deste aspecto como sendo uma tendência recente.
Para os resultados em português, a Figura 13 indica um cenário bastante semelhante ao anterior, com o aspecto organizacional liderando o crescimento enquanto os outros dois aspec-tos apresentam crescimenaspec-tos menores, com resultados somente nos intervalos de tempo mais recentes.
Figura 13: Análise temporal dos apectos dos resultados em português
Comparando-se o crescimento de ambas as línguas, é possível verificar um intervalo de tempo de quase duas décadas sem pesquisas em português nesta área, o que denota um certo atraso das pesquisas brasileiras neste campo. Apesar deste atraso em relação ao exterior, foram encontrados artigos em português de extrema relevância para este trabalho, como se encontra discutido adiante na Seção 5.3.6.
5.1.2 Assuntos
Em relação aos assuntos abordados pelos artigos, esta mesma análise temporal permite a verificação de quais foram os temas mais pesquisados dentro deste campo de estudo. Além disso, através desta análise é possível acompanhar do crescimento da preocupação de se eviden-ciar uma melhoria na comunicação (assunto 10 da Tabela 3) por meio da utilização do objeto de estudo do artigo em questão.
Inglês
Apesar da taxa de amostragem por assunto ser ainda menor, mesmo assim pode-se veri-ficar pela Figura 14 que os maiores crescimentos foram dos artigos que discutem modelos ou processos; formas de comunicação; problemas e dificuldades; e vantagens e boas práticas.
Figura 14: Análise temporal dos assuntos dos resultados em inglês
Os assuntos que apresentaram os menores crescimentos foram as habilidades, as meto-dologias e as técnicas ou dinâmicas utilizadas especificamente na melhoria da comunicação. Como tais assuntos foram poucos explorados até o presente momento, esta análise pode servir como motivação para que futuras pesquisas preencham esta deficiência.
Também é importante ressaltar o tênue crescimento do número de artigos que evidenciam melhorias na comunicação, uma vez que com o movimento da Engenharia de Software Experi-mental este crescimento tende a se acentuar cada vez mais, gerando novos métodos empíricos que permitam avaliar estas melhorias.
Português
Assim como no caso dos aspectos, a Figura 15 mostra que os artigos selecionados foram referentes somente à ultima década analisada, o que novamente demonstra um crescimento tardio destas pesquisas no Brasil.
Figura 15: Análise temporal dos assuntos dos resultados em português
De forma semelhante, os assuntos que tiveram maior crescimento foram as formas de comunicação; problemas e dificuldades; modelos e processos; diferindo apenas em ferramentas e tecnologias.
Já os grupos de artigos sobre metodologias e habilidades apresentaram praticamente ne-nhum crescimento, o que serve para representar, portanto, fortes possibilidades de pesquisas em âmbito nacional.
Além disso, faz-se interessante destacar novamente o crescimento do grupo de artigos que evidenciam melhorias na comunicação, já que este foi ainda mais baixo para os trabalhos em português. Tal fato pode ser utilizado para indicar a baixa adoção de métodos empíricos para engenharia de software nacionalmente, o que mostra que tal área também possui bastante espaço para crescimento no Brasil.
5.1.3 Geral
Terminada a análise em relação ao crescimento dos aspectos e assuntos, faz-se interes-sante demonstrar como foi a evolução desta questão em geral ao longo das últimas três décadas, aproveitando os gráficos das seções a seguir para organizar este crescimento pelas fontes utili-zadas.
Embora a organização por fonte não permita tirar conclusões específicas sobre estas, ainda assim ela foi adotada por facilitar a visualização acerca da colaboração de cada fonte para os diferentes intervalos de tempo.
Inglês
Através da Figura 16 pode-se então ter uma evidência precisa de que a questão da co-municação no desenvolvimento de software tem ganhado uma importância crescente para o meio acadêmico mundial, fato atenuado ainda mais nestas duas últimas décadas e que volta a sustentar a motivação deste trabalho.
Figura 16: Análise temporal dos resultados em inglês
As fontes que mais colaboraram para este crescimento foram o IEEEXplorer e o Goo-gleScholar, que tiveram nesta década um aumento superior a três vezes o que foi apresentado na década passada.
Já a fonte ACM foi única com resultados na primeira década analisada e a mais estável durante todo este período, exibindo pouca variação no seu número de artigos dentre os vários intervalos de tempo exibidos.
Português
A análise sobre o crescimento dos trabalhos em português se apresenta um pouco menos precisa por somente ter resultados nos dois últimos intervalos. Apesar disso, a Figura 17 mostra de forma bastante clara que nesta última década o crescimento foi significativo, atingindo, de 2006 a 2010, quase quatro vezes o número encontrado entre 2001 a 2005.
Figura 17: Análise temporal dos resultados em português
Como neste caso apenas duas fontes retornaram resultados significativos, tem-se que o GoogleScholar foi a fonte que permitiu verificar o crescimento desta questão nacionalmente, já que o Scirus manteve um número constante.
5.2
Questão 2
2. Quais formas de comunicação estão sendo mais enfatizadas e em quais etapas do processo de desenvolvimento de software elas são utilizadas?
a. Quais as suas possíveis boas práticas e dificuldades?
Para a análise em torno desta segunda questão, serão retomadas as várias formas de comu-nicação e suas diversas categorizações, introduzidas na Seção 1.1.1, porém agora levando-se em consideração a sua utilização dentro do processo de desenvolvimento de software e fornecendo exemplos específicos deste contexto para cada uma das classificações.
• Classificação por sincronia
Síncrona: Indicada para diálogos importantes e urgentes. – Conversas informais
– Instant Messenger
– Reuniões (presenciais, por telefone ou vídeo-conferência) Assíncrona: Indicada para recados e afazeres.
– Email, Voice-mail – Grupos de discussão – Fóruns
Formal: Utilizada no planejamento, na organização, na direção. Impessoal e pouco in-terativa. – Especificações de requisitos – Documentos de projeto – Reuniões planejadas – Cronogramas de entrega – Relatórios de progresso – Rastreador de defeitos
– Encontros formais por vídeo/áudio conferência
Informal: Utilizada no controle, na motivação, na integração. Pessoal e mais interativa. – Discussão em pares
– Email não estruturado
– Requisitos representados por esboços – Telefone
– Video/áudio conferência informal
• Classificação por código/canal
Verbal: Usada em praticamente todos os casos.
Oral - Preferível em diálogos com o cliente e tomadas de decisões. – Reuniões
– Palestras – Entrevistas – Apresentações
Escrita - Indicada entre a própria equipe ou para documentos oficiais. – Documentos internos
– Contratos – Memorandos – Relatórios técnicos – Resumos de gestão
Não-Verbal: Importante em acordos e negociações.
Especificamente sobre a comunicação com o cliente, o artigo <Ing-27> mostra que em projetos ágeis em que a comunicação face a face com o cliente raramente ocorre, a incidência de tarefas de correção de defeitos é significativamente maior que em projetos que a comunicação é predominantemente face a face.
Este artigo fez ainda algumas sugestões de boas práticas para a comunicação com os clientes: - A comunicação face a face deve ser utilizada sempre que possível - Caso o cliente não esteja disponível e o assunto seja extenso e complexo, o preferível é a videoconferência - Para discussões simples, o telefone é preferível pelo rápido feedback - Emails devem ser utilizados somente para assuntos já esclarecidos
Uma das boas práticas identificadas para a comunicação formal escrita é a utilização de templates, como apresenta o artigo <Ing-20>. Através do uso de templates, pode-se chegar a um
entendimento mais rápido de documentos de especificação de requisitos, uma vez que estes for-necem a estrutura necessária e explicitam as informações incompletas para que a especificação esteja completa.
Entretanto, também existem dificuldades na utilização de templates que merecem ser ci-tadas. Uma delas é a dificuldade de entendimento dos comentários disponíveis ou a não leitura destes, uma vez que estes fornecem instruções essenciais para a integralização do documento. A outra é em relação à organização do trabalho, uma vez que apenas pelos comentários, pode ser possível que as relações entre os artefatos não fiquem tão claras.
Um importante achado a respeito das formas de comunicação foi o artigo <Ing-26>, que apontou que a escolha da mídia é diretamente influenciada pelo papel ou profissão do comu-nicador. Foi identificado também que pessoas da área técnica costumam utilizar mais mídias baseadas em texto, enquanto que gerentes costumam usar mais mídias baseadas em áudio.
Neste trabalho foi estabelecida também uma importante correlação com a teoria de ri-queza de mídia (Media Richness Theory), mostrando que as pessoas preferem se comunicar por texto quando as tarefas possuem alto grau de certeza e baixo grau de equívoco. O oposto também foi identificado, mostrando que a comunicação por áudio é preferível quando os con-ceitos são complexos ou as idéias são novas, de modo a possibilitar um rápido feedback.
Outro artigo <Ing-31>, discutiu este mesmo assunto fazendo um exame apurado sobre o processo de seleção da mídia apropriada para cada contexto dentro do desenvolvimento de soft-ware. Além disso, este também promoveu a identificação dos principais fatores que influenciam na escolha destas mídias. Pela grande importância de sua contribuição, foram adicionadas no Anexo 7 as Tabelas 11 e 12 referentes, respectivamente, a estes dois assuntos.
5.3
Questão 3
3. Quais ferramentas, tecnologias, processos e metodologias estão sendo utilizadas focadas nesta questão?
b. Quais delas possuem estudos empíricos que evidenciam melhorias na comunicação?
Uma vez que a terceira pergunta aborda uma série de assuntos diferentes, esta será respon-dida na forma de várias seções, cada uma específica para um assunto. Após explorados todos estes, a Seção 5.3.6 faz uma análise geral em relação aos aspectos e aos resultados nacionais, encerrando-se, então, esta questão.
5.3.1 Ferramentas
Dentre as diversas ferramentas citadas pelo artigo <Ing-58>, duas delas (Object Lens e Coordinator) constroem em cima do modelo de comunicação por email, uma plataforma para a coordenação e o gerenciamento de mensagens. Através desta alteração, os sistemas citados pos-sibilitam a criação de regras e a utilização de templates para uma comunicação mais estruturada, tornando formal um meio de comunicação inicialmente informal.
Em se tratando de ambientes compartilhados, este mesmo trabalho relata duas outras ferramentas (Grove e Quilt) para a edição em grupo, que possibilitam a construção colaborativa de documentos e até códigos-fonte por diversas pessoas simultâneas.
No artigo <Ing-173> foram encontradas quatro ferramentas especificamente para projetos distribuídos (VIMEE, TeamSpace, MILOS e CVW), que criam um ambiente virtual e distri-buído para reuniões, permitindo comunicação síncrona ou assíncrona, formal e informal entre os seus participantes, além do compartilhamento de arquivos e tomada de decisões em grupo.
Ainda no ambiente distribuído, o artigo <Ing-9> fez uma compilação de inúmeras fer-ramentas utilizadas para a comunicação e a troca de informações, citando suas vantagens e desvantagens, modos sensoriais utilizados, usos de banda e imediatismo (síncrona ou assín-crona). Por sua enorme extensão e relevância a este trabalho, esta compilação foi inserida na Tabela 13 do Apêndice 7.
Outro tipo de ferramenta que teve seu uso defendido em dois artigos, 184> e <Ing-33>, foi o Issue Tracker (rastreador de defeitos ou bugs), que não só permite a catalogação e o armazenamento dos defeitos a serem corrigidos, mas serve também como forma de comunica-ção e coordenacomunica-ção entre a equipe para a implementacomunica-ção de futuras funcionalidades.
Além disso, estes também podem ser utilizados como uma lista global dos afazeres dos membros, como uma forma de atribuição e priorização de tarefas, como um meio para solução de conflitos ou ainda como um repositório de conhecimento, através de discussões, documentos e imagens que complementam a solução de um defeito.
Talvez devessem ser considerados como tipos de ferramentas também, apesar de não se-rem necessariamente digitais, os storyboards e taskboards. Conforme o artigo <Ing-139>, estes possibilitam a criação de um canal direto de compartilhamento de informação entre os desen-volvedores e os gerentes de projeto, aumentando assim, a visibilidade dos objetivos de curto prazo para toda a equipe.
A ferramenta mais exótica encontrada, mas que ainda assim merece destaque, foi um plugin para a IDE Eclipse que permite integração com o Twitter, transformando a popular forma de comunicação Microblogging em algo útil ao contexto do desenvolvimento de software. O artigo <Ing-179> explica que, através do uso de tags específicas para tópicos do projeto em questão, a ferramenta possibilita uma comunicação rápida entre a equipe, o compartilhamento do conhecimento e o seu armazenamento em uma base de dados confiável.
5.3.2 Metodologias
As práticas ágeis defendem o predomínio da comunicação face-a-face sobre a comunica-ção documentada, o que promove um maior compartilhamento de informações entre a equipe e aumenta a agilidade das mudanças, conforme o artigo <Ing-139>.
Esta melhoria se daria basicamente pela modificação da comunicação formal dirigida a planos para a discussão informal entre indivíduos, que poderia ocorrer através de reuniões em pé, planning games, revisões de projeto ou na programação em pares. Por meio destas técnicas, a equipe consegue uma maior coesão e compartilhamento de conhecimento, além de produtos de qualidade significantemente superior.
Outra alteração importante que ocorre com o uso de metodologias ágeis é a aproximação dos clientes, que, através das stories, são obrigados a estar em constante comunicação com a equipe de desenvolvimento, sempre confirmando ou corrigindo os requisitos o mais cedo possível.
A única desvantagem relatada em relação às metodologias ágeis é a de que, quando a complexidade do sistema e a quantidade de stakeholders aumentam, os mecanismos de comu-nicação e as reuniões de tempo fechado disponíveis não são suficientes. Desta forma, fazem-se necessárias novas opções de comunicação formal a fim de solucionar tal deficiência.
Apesar de estas metodologias serem mais utilizadas em equipes locais e de pequeno porte, já existem adaptações destas metodologias escaláveis para equipes de grande porte e até distri-buídas. O artigo <Ing-180> defende que esta melhoria é também aplicável a grandes equipes, bastando que se utilize a versão distribuída da metodologia desejada, seja ela Scrum, XP, RUP ou qualquer outra com esta adaptação.
5.3.3 Dinâmicas
Os artigos encontrados sobre este tema tratam especificamente sobre técnicas aplicadas no ensino de habilidades comunicativas, sejam elas escritas ou faladas.
Em um deles <Ing-11>, foi sugerida a utilização de dinâmicas como o Role-play ("inter-pretação de papéis"), o Brainstorming ("tempestade de idéias"), treinamentos de trabalho em equipe, a escrita de memorandos empresariais e documentos de gerência de projeto, reuniões com o professor e apresentações.
Outro trabalho, <Ing-8>, sugeriu o ensino destas habilidades por meio de relatórios orais ou escritos, que seriam através de apresentações, especificações de requisitos, documentação do sistema e manuais de usuário.
Como os meios destas técnicas são bastante próximos de seus fins, este assunto será com-plementado na seção seguinte, onde serão identificadas algumas das habilidades essenciais para uma comunicação eficiente.
5.3.4 Habilidades
O artigo <Ing-60> faz uma importante comparação entre as diferentes visões do meio acadêmico e do meio corporativo acerca das várias características desejadas de recém gradua-dos. Numa pesquisa conduzida para identificar o nível de prioridade que cada meio dá a estas características, foi identificado que, enquanto a habilidade de comunicação fica em primeiro lugar para o mercado, para a universidade esta habilidade fica somente em sétimo lugar.
Por meio da comparação realizada é possível verificar a grande incompatibilidade de pri-oridades entre os dois, de forma que este artigo apresenta uma proposta de incorporação de diversos aspectos humanos e sociais, que assim, complementariam os cursos de engenharia de software para as reais necessidades do mercado.
Já o trabalho <Ing-42>, conseguiu ainda a modelagem de um framework de habilidades que garantem um bom trabalho em equipe. Dentre os vários aspectos e habilidades propostos, vale destacar os que possuem maior relação com a comunicação: Escrita de relatórios -Comunicação inter-cultural - Entrevistas - Reuniões - Habilidades de apresentação - Trabalho em equipe - Escuta efetiva - Compartilhamento de idéias - Liderança de equipe - Negociação e solução de conflitos
Houve ainda o artigo <Ing-138>, abordando também esta questão, que fez um trabalho ainda mais aprofundado. Além de ter comparado estas e diversas outras habilidades, e verificado o quão benéficas elas foram, ele ainda identificou quais os pontos positivos e negativos de cada uma delas.
No trabalho <Ing-50> foram descritas habilidades comunicativas específicas de líderes de equipe. Nele, foi apresentado que líderes podem atuar sob os papéis de corretor, coordenador, monitor e integrador, sendo que, para cada papel, ele se utiliza de uma função diferente na comunicação.
5.3.5 Modelos
Quanto à modelagem da comunicação, a maior parte dos artigos abrangeu o aspecto lingüístico especificamente aplicado à etapa de engenharia de requisitos. Dentre eles, dois merecem destaque.
O primeiro, <Ing-174>, descreve técnicas de modelagem de requisitos baseadas na análise da comunicação. Utilizando-se de diagramas de eventos comunicativos (entre os diversos atores envolvidos ao negócio) e de uma descrição da estrutura da comunicação (que permite a criação
de outras primitivas) o método descrito modela o domínio do negócio em uma estrutura própria de requisitos.
O segundo artigo, <Ing-54>, faz uma análise quanto aos padrões de conversação durante reuniões de levantamento de requisitos. Dentre suas mais importantes contribuições está um modelo que correlaciona os tipos de reuniões, os artefatos utilizados para desenvolver os requi-sitos, as ações físicas e os papéis dos participantes.
Outra contribuição de extrema importância deste artigo foi um modelo que retrata um padrão canônico de conversação entre um engenheiro de requisitos e um cliente durante a aqui-sição de tarefas. Como este foi representado através de um grafo orientado, é possível identificar claramente quando cada um faz uma pergunta ou resposta, concorda ou discorda, introduz ou encerra um tópico.
Houve ainda o trabalho <Ing-41> próprio ao aspecto organizacional, com a preocupação de modelar um processo para as alterações ocorridas nos requisitos durante esta etapa. Nele, foram especificados modelos de workshops, identificando os stakeholders e os documentos en-volvidos, e uma série de diretrizes para ambientes com vários projetos simultâneos.
A partir dos modelos presentes nestes artigos, é possível reunir um bom conjunto de boas práticas e diretrizes para auxiliar na comunicação ocorrida na etapa de engenharia de requisitos, o que, por si só, já é bastante relevante para o desenvolvimento de um software.
5.3.6 Aspectos e Brasil
Foram inúmeras as contribuições ao aspecto organizacional, entretanto, a mais completa foi pelo trabalho brasileiro <Pt-3>, uma vez que este se trata de uma dissertação exatamente sobre o tema da comunicação na gestão de projetos.
Neste trabalho, foram descritos todos os processos e etapas de acordo com o modelo pro-posto pelo PMI (Project Management Institute) para a gerência da comunicação e, em seguida, este modelo foi aplicado a uma empresa brasileira para então serem exploradas as dificuldades de aplicação deste.
Em relação ao aspecto individual, houve um artigo, <Ing-1>, que fez uma abordagem um tanto psicológica e emocional da comunicação, defendendo que além de todos os quesitos discutidos anteriormente, também se deve prestar atenção a questões como a percepção própria e do outro, o humor, o respeito e a má interpretação na comunicação.
Através de uma correlação com estas questões e com a comunicação remota e a face a face, foi verificado como sentimentos como a frustração e a satisfação são criados a partir do silêncio em cada um dos casos. O artigo conclui que desentendimentos são mais recorren-tes na comunicação remota, indicando que a comunicação não verbal, presente face a face, é fundamental na solução de problemas deste tipo.
O artigo mais aprofundado no aspecto lingüístico foi o <Ing-136>, que aborda um modelo para a identificação e a correção de definições fracas. Através da verificação de fraquezas na forma ou no conteúdo, o modelo descreve diretrizes para a escrita de definições consistentes, clarificando o processo através de um exemplo de uso.
No Brasil a questão da comunicação ainda é pouco explorada, o que pode ser inicial-mente verificado pela quantidade ínfima de estudos em português. Ainda assim, alguns dos artigos encontrados em português foram bastante completos nos assuntos e aspectos que estes abordaram.
A maior contribuição deles para este trabalho foi a verificação do nível de preocupação das empresas brasileiras com a questão da comunicação. No artigo <Pt-17>, é citada uma pesquisa da ABERJE (Associação Brasileira de Comunicação Empresarial) que mostra que
