Revisão sistemática sobre a comunicação dentro do processo de ...

Revisão sistemática sobre a comunicação dentro

do processo de desenvolvimento de software

T. M. Moraes A. S. de Souza

J. L. de Oliveira

Technical Report - RT-INF_004-11 - Relatório TécnicoFebruary - 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

www.inf.ufg.br

Revisão sistemática sobre a comunicação dentro doprocesso de desenvolvimento de software

Taciano Messias Moraes ∗

[email protected]

Adriana Silveira de Souza †

[email protected]

Juliano Lopes de Oliveira ‡

[email protected]

Abstract. Effective communication has always been of fundamental importance inprojects of all kinds and areas. For software development projects, this concern isequally valid. And even in Computing, an area that counts on the assistance of nu-merous 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, bestpractices, 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 howimportant this issue is being considered in academic and corporate environment.

Keywords: Software Development, Communication, Systematic Review, SoftwareEngineering.

Resumo. Uma comunicação eficaz sempre foi de importância fundamental em proje-tos das mais variadas naturezas e áreas. Para projetos específicos à construção desoftware, esta preocupação é igualmente válida. E mesmo na Computação, área queconta com o auxílio de inúmeras tecnologias e metodologias específicas para isto, asdificuldades parecem persistir.

Este trabalho se propõe a realizar um estudo sistematizado sobre a comunicação nodesenvolvimento de software, a fim de identificar as etapas e formas em que estaocorre, os meios utilizados, suas boas práticas, os principais problemas ocorridos esuas possíveis soluções.

Para isto, foi utilizada a metodologia de Revisão Sistemática, que levantou os maisimportantes artigos científicos publicados sobre este tema, possibilitando assim aanálise do quão importante esta questão está sendo considerada no meio acadêmicoe 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

Revisão Sistemática 2

1 IntroduçãoDesde o surgimento da Computação até os dias atuais, percebe-se que a maioria das

pesquisas 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 SoftwareEngineering Institute desenvolveu um modelo de maturidade e capacitação para gerência depessoas (PM-CMM - People Management Capability Maturity Model)"[16].

As próprias IEEE e ACM já elaboraram um documento guia [11] para programas de grad-uação, que foca especialmente no ensino destes aspectos humanos, geralmente menosprezados.Nele, é sugerido que os cursos de computação deveriam abordar atividades como: trabalho emequipe, gerenciamento, comunicação (oral e escrita), etc. E mais, é recomendado que o tempoempregado nestes aspectos humanos seja de 15% a 20% do total de horas curriculares, o quedenota 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. Deacordo com o estudo publicado em [8], os vice-presidentes de três das maiores companhias detecnologia, quando perguntados sobre qual era o fator de maior relevância para o sucesso de umprojeto, todos responderam que o mais importante eram as pessoas por trás deste.

Por estes motivos, este trabalho centra justamente neste lado indiscutivelmente importantee 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ãoem [1]: "Uma das principais máximas de uma boa engenharia de software é que deve haverboa comunicação entre os usuários do software e os engenheiros deste software". O mesmo seaplica à 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 doprocesso executado e, consequentemente, a qualidade do produto final gerado pelo projeto.

"Pesquisas indicam que falhas de comunicação são as fontes mais freqüentementecitadas de conflitos interpessoais. Como as pessoas passam cerca de 70% de suashoras de vigília se comunicando - escrevendo, lendo, falando, escutando -, parecerazoá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 emailspodem comprometer seriamente a produtividade dos empregados. Apesar dos inúmeros apelospró-comunicativos às organizações, é importante deixar evidente que o seu excesso pode ser tãoprejudicial 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 grandescorporações. Deste fato deriva um dos axiomas fundamentais da Engenharia de Software quedetermina 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á-loainda 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 deprojetos 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 dosprojetos citados nas estatísticas anteriores acabam sendo: uma equipe fragmentada com visõescompletamente divergentes sobre o mesmo produto e um cliente que acaba pagando bem maispor algo totalmente diferente do que ele precisava.

Figura 1: Caricatura do projeto de desenvolvimento de software, retirada de [17]


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 quemais tem influência sobre as outras é a comunicação. Mesmo havendo casos (raros) de projetoscuja 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çãoPartindo 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ãoexiste se o ouvinte não entender de fato a mensagem.

Analisando, portanto, o Processo Comunicativo tradicional de acordo com a perspectivacomputacional 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 causaralguma 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 men-sagem, se esta causou ou não a reação esperada.


Como dito anteriormente, o modelo apresentado é apenas uma visão simplificada emecanizada 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 dapeça". Da mesma forma ele considera a influência de cada um dos fatores anteriores, alterandoa responsabilidade ú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 emseguida discutir uma proposta de categorização que permitiu abranger todas as comunicaçõesocorridas 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 é bastanteimprecisa e poucos estudos a abordam em profundidade. Portanto, esta e suas subdivisões ficamsomente à título de informação.

Baseando-se nas várias classificações existentes e com a intenção específica de melhorabranger os vários tipos de comunicação existentes durante o processo de desenvolvimento desoftware, 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 simplesde Feedback e deve ser interpretada da forma em que está disponível; como no caso daimplementaçã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 dificuldadede determinadas pessoas a se comunicar.


• Organizacional - Considerando a comunicação de forma mais ampla, verificando a ex-istê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 acada aspecto, onde o linguístico pode englobar a classificação em síncrona e assíncrona; oindividual realiza a classificação entre verbal e não-verbal; e o organizacional classifica emformal 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 permitiuuma 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 é utilizadauma 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 meioda 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 umamera 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, modeladaem uma linguagem gramatical. A partir desta idéia, pode-se concluir que sempre que uma Es-trutura Profunda se transforma em uma Estrutura Superficial (e vice-versa) ocorre algum tipode perda de informação, classificada da seguinte forma:

• Eliminação - A supressão de alguma informação considerada não fundamental para darlugar 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íremalgum elemento em comum

Aplicando estes conceitos à Engenharia de Requisitos, pode-se imaginar um exemplosimples 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 EstruturaProfunda pode ser muito mais abrangente que o que foi passado ao Engenheiro de Requisitosatravé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 autenticarpara 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 porparte do emissor pela ocorrência de transformações que causam Eliminações, Distorções ouGeneralizações. Desta forma, sem recorrer diversas vezes ao cliente, dificilmente o engenheirode requisitos conseguiria chegar à mesma Estrutura Profunda deste, o que provavelmente acar-retaria 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 deperda 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 escritaou falada. Portanto, é necessário ressaltar que este mesmo cuidado linguístico deve ser aplicadoa 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 defeedback 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 dacomunicação, ou ansiedade."[18]

Mesmo que este medo ou ansiedade não sejam tão extremos a ponto de anular todas asformas de comunicação possíveis, é muito comum este tipo de problema afetar justamente asoutras pessoas que não têm receio de se comunicar, pois estas acabam não sendo informadas dequestões ou alterações importantes do sistema.

Na Computação, foi verificado que esta taxa é ainda mais alta [3]. Por este motivo, serãoinvestigadas técnicas de terapia e comunicação em grupo com o intuito de desinibir os membrosda 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 possuemum clima de desconfiança e apatia em que os empregados se sentem ameaçados e injustiçadospelos 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 empresainteira, tanto dos empregados como dos gerentes. Modificar o comportamento organizacionalde uma corporação é algo extremamente trabalhoso e caro, porém, que pode trazer resultadossignificativos a longo prazo, melhorando não somente a lucratividade da empresa como tambémo bem estar de seus funcionários.


1.2 Sobre a Revisão SistemáticaComo 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 to-das 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 contribuempara uma revisão sistemática são chamados estudos primários; uma revisão sis-temática é uma forma de estudo secundário." [14]

Como foi explicado acima, a Revisão Sistemática se propõe a bem mais que somenteendossar a fundamentação teórica deste projeto, o que implica num trabalho de maior extensãoe numa maior dificuldade de realização. Apesar disso, existem algumas fortes razões para seutilizá-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, estapermite verificar evidências empíricas que suportam ou refutam hipóteses teóricas, permitindoainda a elaboração de novas hipóteses.

Aplicando ao escopo deste trabalho então, a revisão sistemática fornecerá uma formaestruturada de pesquisa e catalogação do material disponível sobre a Comunicação dentro doProcesso 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 permitemnovas publicações acadêmicas.

1.3 Estrutura do DocumentoNesta 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çãodas 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 deBusca, 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 classificadosos resultados selecionados pela seleção final.

Finalizada a execução da Revisão Sistemática, foi feita uma análise sobre os estudosprimá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áticaNesta 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ériose 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 de-scrito todo o processo de revisão, permitindo assim, que outros pesquisadores repitam estamesma pesquisa e obtenham resultados similares.

2.1 ObjetivosBaseando-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 oprocesso de desenvolvimento de software.

III. Identificar as ferramentas, tecnologias, processos e metodologias existentes específicospara a melhoria da comunicação neste processo.

2.2 Questões de PesquisaA 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 desoftware?

2. Quais formas de comunicação estão sendo mais enfatizadas e em quais etapas do processode 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 utilizadasfocadas 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 out-ras 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 maiordetalhamento 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 dacomunicaçã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 eGestão da Comunicação.


2.3 Estratégias de BuscaEsta 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 in-dexados, máquinas de busca eletrônica e bibliotecas digitais.

– ACM Digital Library 1

– Google Scholar 2

– ScienceDirect 3

– SpringerLink 4

– IEEEXplore 5

– CiteSeer 6

– Scirus 7

• Palavras-chave: Baseando-se nas questões de pesquisa levantadas anteriormente, foramdefinidas 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 omáximo possível de resultados não desejados, as strings de busca foram definidas daseguinte 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 "Engen-haria de Requisitos"OR "Gerência de Projetos"OR "Gerenciamento de Projetos"OR"Gestão de Projetos"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çãoDepois 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 desconsid-erados. 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 destetrabalho

• 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çãoForam 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 resulta-dos retornados e depois contabilizando quantos destes foram repetidos, quantos passaram pe-los critérios de inclusão e quantos foram previamente excluídos por não obedecerem a estescrité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 serlido 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 deanálise da qualidade e extração dos resultados, descritas a seguir.

2.6 Análise da QualidadeOs trabalhos tiveram a sua qualidade analisada pelo cálculo da média aritmética da pre-

cisã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 assuntosrelacionados à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 umpesquisador 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 depesquisadores para que ele possa ser considerado como seguro quanto à seus resultados.


2.7 Extração dos ResultadosTerminada 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, quantidadede páginas, palavras-chave, resumo, fonte e uma nota referente à sua qualidade. Um modelo dorelató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 parafiltrar aqueles que atingiam os critérios de exclusão, restando, portanto, somente os estudosprimá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 discursivasobre 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áticaDe 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 eexaminando uma quantidade limitada de resultados.

Por este motivo, juntamente com o andamento da condução, foram realizados diversostestes de 09/06/2010 a 26/08/2010 com diferentes strings de busca a fim de identificar aquelaque teve a melhor taxa de aceitação para então ser definida no protocolo. A contrução destastring 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 encontramdisponíveis os resultados destas buscas.

Paralelamente à execução das buscas, foi realizado um processo de seleção preliminarbaseado 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 BuscaPara 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 poderiamincrementar 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 debusca 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 quaisdestas tiveram as melhores taxas de aceitação e se a quantidade de resultados retornados eracabível para a execução deste trabalho.

Para facilitar a execução destes testes, foram selecionadas as duas fontes que não exigiamadaptações na string de busca: Scirus e CiteSeer. Além disso, elas foram escolhidas tambémpelo fato da primeira ser uma das que indexam mais sites, tendo sido utilizada como base parao máximo, enquanto a outra é uma das mais restritas, tendo sido utilizada como base para omínimo de resultados retornados.

Depois de realizada cada busca, os seus dez primeiros resultados eram analisados de modoa estimar uma taxa de aceitação para cada uma das fontes. As tabelas a seguir demonstram osresultados de um dos testes iniciais e em seguida o resultado do teste final, evidenciando amelhora 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 mo-tivo, foram feitos novos testes com alterações quanto à busca por resumo e por palavras-chave,visando 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 decididoeliminar a busca por resumo ou por palavras-chave.

As dez palavras-chave sinônimas que eram buscadas no resumo, que verificavam arelevância do artigo quanto à comunicação, foram condensadas em apenas uma palavra-chavebuscada no título. Já que todas elas possuíam a palavra ’communication’, esta foi utilizada pararepresentar todos os sinônimos, assim, a busca seria mais abrangente e ao mesmo tempo maisrelacionada 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 buscaque verificava apenas o título dos trabalhos, como mostrado na Tabela 2, o que reduziu em cercade uma ordem de grandeza a quantidade de resultados e aumentou em quase duas vezes a taxade aceitação (para a amostragem analisada).

A desvantagem desta redução na quantidade de resultados seria a baixa amostragem dotrabalho, o que poderia levar a uma certa parcialidade (bias) nos resultados, caso a string debusca fosse mal definida. Entretanto, como os resultados foram lidos e analisados a fundo, estaescolha foi preferível ao invés de uma alta amostragem mas uma análise superficial.

3.2 Execução das BuscasUma 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 descrevecomo foi a busca de cada língua de forma geral, sem se ater nas fontes uma por uma, citandoapenas as ocorrências de casos especiais.

As buscas nas fontes ACM, ScienceDirect e CiteSeer transcorreram sem nenhuma dificul-dade ou anormalidade. Entretanto, nas outras fontes houveram algumas questões que merecemser destacadas:

IEEEXploreO site apresentou diversos problemas pela busca padrão, de forma que só foi possível asua utilização através da busca avançada.

SpringerLinkGrande parte dos resultados eram capítulos de livros e só estavam disponíveis para seremcomprados.


Google Scholar e ScirusAlgumas configurações extras tiveram de ser adotadas a fim de tornar a quantidade deresultados 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 configu-raçõ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 umadas 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 202resultados, um número ainda significativo, sendo 31% provenientes da fonte IEEEXplore e19% do Google Scholar, enquanto que todas as outras fontes foram responsáveis por apenasmetade 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 edepois das configurações citadas anteriormente, para que seja possível ter uma noção da reduçãodrá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 caiupara apenas 46, lembrando que a diferença entre estes números são de documentos em outrosformatos que não o Pdf, de outras áreas que não a computação ou que não possuíam o ano depublicaçã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 devidasconfiguraçõ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 pelofato da língua padrão de publicação internacional ser o inglês. Entretanto, ainda assim foramretornados 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 duaslínguas foi de 230, sendo que apenas 14% destes estão em português, enquanto que 86% estãoem inglês.

3.3 Seleção PreliminarTerminada 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 queestava em inglês ou português; que estava diponível para download; e que continha relação como tema no título e no resumo.

Após esta fase, os artigos selecionados foram coletados, (parcialmente) lidos e analisadosquanto aos critérios de exclusão. Porém, tal discussão cabe à etapa de documentação, abordadana 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 aostrê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, com69%, sendo que a pior foi a do SpringerLink, com 13%. Entretanto, vale ressaltar que tal taxafoi afetada pelo fato desta fonte disponibilizar alguns artigos somente para compra, o que a fezdespencar de segunda melhor (65%) para última.

Em relação à taxa de repetição, a fonte Google Scholar se sobressaiu, tendo mais dametade (58%) de seus resultados repetidos, o que claramente se deve ao fato deste ser umindexador de fontes.

3.3.2 Português

Similarmente à seleção anterior, mais da metade dos resultados em português tambémforam 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 buscaotimizada. Considerando que 41 eram repetidos e que 79 foram incluídos, pode-se verificar quea 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 deexclusão, porém desta vez contando com os dados extraídos dos resultados. A Seção 4 descrevecomo foi realizada esta outra iteração e faz uma visão geral sobre os artigos finais selecionadospor esta revisão sistemática.

4 Documentação da Revisão SistemáticaNa 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ãomais necessitando de ter a sua qualidade avaliada. Por este motivo, a classificação das Seções4.1 e 4.2 foi realizada com base nos 67 resultados que passaram pelos dois primeiros critériosde exclusão.

Para que a avaliação fosse a mais imparcial possível, foram definidos dez assuntos rela-cionados às questões de pesquisa que seriam desejáveis, conforme representa a Figura 3. Assimfoi dada uma nota a cada aspecto e assunto presente no trabalho, fazendo com que uma notaseja 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. Porexemplo, um artigo pode tratar de uma ferramenta (1) e receber nota 7 para este assunto, poresta não auxiliar tanto na comunicação. Apesar disso, seu conteúdo pode indicar as vantagensdesta (9) e receber nota 10 por tê-las descrito de forma bastante satisfatória. Isto significa queas notas dos assuntos, mesmo quando referenciados, não necessariamente possuem o mesmovalor, 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 asclassificaçõ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 aseleção final dos resultados, bem como com uma explicação completa sobre a seleção dos doisprimeiros critérios de exclusão que precedeu as classificações das seções anteriores.

4.1 Classificação quanto aos Aspectos4.1.1 Inglês

Como pode ser verificado pela Figura 8, apenas um dentre os 58 artigos em inglês abordatodos 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.

Figura 8: Resultados em inglês analisados quanto a seus aspectos


4.1.2 Português

Analisando, então, os resultados em português em relação aos seus aspectos (conformea 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, umavez que um dos aspectos estava presente em todos os trabalhos, enquanto outro foi encontradoem um só trabalho. Tal desigualdade também foi encontrada na classificação em relação aosassuntos contemplados, conforme pode ser verificado a seguir.

4.2 Classificação quanto aos Assuntos4.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 edinâ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; eformas de comunicação), com 67% e dois menos abordados (técnicas ou dinâmicas e metodolo-gias) com 11%.

A evidência de melhoria esteve presente em 33% dos artigos. Embora tal porcentagemnão signifique que os trabalhos realmente forneçam formas testadas e comprovadas de melhoriana comunicação, fica evidente a preocupação com esta avaliação, mesmo que realizada de formaempírica.


4.3 Seleção FinalSobre 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-seem consideração os critérios de exclusão. Destes, 4 foram eliminados pelo primeiro critériode exclusão, ou seja, por não tratarem específicamente do tema da comunicação. Outros 11não eram específicos ao contexto do desenvolvimento de software, tendo sido reprovados pelosegundo critério de exclusão.

Verificados estes dois primeiros critérios, restaram 67 resultados para serem analisadosquanto à sua qualidade e classificados quanto a seus aspectos e assuntos, conforme exibido nasseções anteriores.

Findada a etapa de avaliação da qualidade, estes resultados foram submetidos ao terceiroe último critério de exclusão, de forma que os avaliados com qualidade superior a 7,0 foramaprovados por todos os critérios de seleção.

Dos 67 resultados avaliados, 31 obtiveram nota maior que a exigida e, portanto, foramconsiderados como estudos primários desta revisão, sendo que destes, 26 se encontram eminglê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 foi7,02. Levando-se em consideração apenas os selecionados, a média dos em inglês foi 8,18 e ados em português foi 8,34.

No Apêndice 7 pode ser conferida uma relação com todos os resultados repetidos (Tabela10), excluídos (Tabela 9) e incluídos nesta fase (Tabela 8). Por meio destas tabelas pode-severificar 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, umaa uma, as questões de pesquisa estabelecidas para esta revisão e apresentando os principaisachados destes artigos.

5 Análise dos ResultadosNesta fase da revisão, os trabalhos colhidos foram analisados de acordo com as questões

que estes contemplaram. Desta forma, nas seções seguintes as questões de pesquisa serão nova-mente 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>, ondeX é 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 11. 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 aindaquais aspectos e assuntos tiveram maior e menor crescimento.

Uma vez que esta primeira pergunta se baseia em uma análise basicamente quantitativaque verifica apenas o aumento da quantidade de artigos com o decorrer dos anos, faz-se inter-essante considerar também os trabalhos analisados, porém que não foram incluídos apenas pornão atenderem ao terceiro critério de exclusão.


Apesar de não terem atingido a nota mínima exigida, ainda assim estes artigos podemser considerados como interessantes para esta análise, já que obedecem a todos os outroscrité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 naamostragem, o crescimento pode ser verificado mais facilmente.

5.1.1 Aspectos

A partir da análise temporal acerca dos aspectos investigados é possível verificar qualdeles 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 porpermitir verificar qual dos aspectos estão sendo menos discutidos, o que permite identificardeficiê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ívelverificar que, dentre todos os aspectos, o organizacional foi o que apresentou o crescimentomais 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 difi-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, ofato de os primeiros 15 anos não terem apresentado resultados pode indicar a exploração desteaspecto como sendo uma tendência recente.

Português

Para os resultados em português, a Figura 13 indica um cenário bastante semelhante aoanterior, com o aspecto organizacional liderando o crescimento enquanto os outros dois aspec-


tos apresentam crescimentos menores, com resultados somente nos intervalos de tempo maisrecentes.

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 detempo de quase duas décadas sem pesquisas em português nesta área, o que denota um certoatraso das pesquisas brasileiras neste campo. Apesar deste atraso em relação ao exterior, foramencontrados artigos em português de extrema relevância para este trabalho, como se encontradiscutido adiante na Seção 5.3.6.

5.1.2 Assuntos

Em relação aos assuntos abordados pelos artigos, esta mesma análise temporal permitea verificação de quais foram os temas mais pesquisados dentro deste campo de estudo. Alémdisso, 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 objetode 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 ouprocessos; 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, asmetodologias e as técnicas ou dinâmicas utilizadas especificamente na melhoria da comuni-cação. Como tais assuntos foram poucos explorados até o presente momento, esta análise podeservir 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 evidenciammelhorias na comunicação, uma vez que com o movimento da Engenharia de Software Exper-imental este crescimento tende a se acentuar cada vez mais, gerando novos métodos empíricosque permitam avaliar estas melhorias.

Português

Assim como no caso dos aspectos, a Figura 15 mostra que os artigos selecionados foramreferentes somente à ultima década analisada, o que novamente demonstra um crescimentotardio 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 decomunicação; problemas e dificuldades; modelos e processos; diferindo apenas em ferramentase tecnologias.

Já os grupos de artigos sobre metodologias e habilidades apresentaram praticamente nen-hum 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 artigosque evidenciam melhorias na comunicação, já que este foi ainda mais baixo para os trabalhosem português. Tal fato pode ser utilizado para indicar a baixa adoção de métodos empíricospara engenharia de software nacionalmente, o que mostra que tal área também possui bastanteespaç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 uti-lizadas.

Embora a organização por fonte não permita tirar conclusões específicas sobre estas, aindaassim ela foi adotada por facilitar a visualização acerca da colaboração de cada fonte para osdiferentes 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 omeio acadêmico mundial, fato atenuado ainda mais nestas duas últimas décadas e que volta asustentar 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 oGoogleScholar, que tiveram nesta década um aumento superior a três vezes o que foi apre-sentado na década passada.

Já a fonte ACM foi única com resultados na primeira década analisada e a mais estáveldurante todo este período, exibindo pouca variação no seu número de artigos dentre os váriosintervalos de tempo exibidos.

Português

A análise sobre o crescimento dos trabalhos em português se apresenta um pouco menosprecisa por somente ter resultados nos dois últimos intervalos. Apesar disso, a Figura 17 mostrade forma bastante clara que nesta última década o crescimento foi significativo, atingindo, de2006 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 oGoogleScholar 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 22. 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 emconsideração a sua utilização dentro do processo de desenvolvimento de software e fornecendoexemplos 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

• Classificação por formalidade


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 emprojetos ágeis em que a comunicação face a face com o cliente raramente ocorre, a incidênciade 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 osclientes: - A comunicação face a face deve ser utilizada sempre que possível - Caso o clientenã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 serutilizados somente para assuntos já esclarecidos

Uma das boas práticas identificadas para a comunicação formal escrita é a utilização detemplates, como apresenta o artigo <Ing-20>. Através do uso de templates, pode-se chegar aum entendimento mais rápido de documentos de especificação de requisitos, uma vez que estes


fornecem a estrutura necessária e explicitam as informações incompletas para que a especifi-cação esteja completa.

Entretanto, também existem dificuldades na utilização de templates que merecem sercitadas. Uma delas é a dificuldade de entendimento dos comentários disponíveis ou a nãoleitura destes, uma vez que estes fornecem instruções essenciais para a integralização do docu-mento. 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>, queapontou 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ídiasbaseadas 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 deriqueza de mídia (Media Richness Theory), mostrando que as pessoas preferem se comunicarpor texto quando as tarefas possuem alto grau de certeza e baixo grau de equívoco. O opostotambé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 oprocesso 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 influenciamna escolha destas mídias. Pela grande importância de sua contribuição, foram adicionadas noAnexo 7 as Tabelas 11 e 12 referentes, respectivamente, a estes dois assuntos.

5.3 Questão 33. 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 todosestes, 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 eCoordinator) constroem em cima do modelo de comunicação por email, uma plataforma para acoordenaçã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 outrasferramentas (Grove e Quilt) para a edição em grupo, que possibilitam a construção colaborativade documentos e até códigos-fonte por diversas pessoas simultâneas.

No artigo <Ing-173> foram encontradas quatro ferramentas especificamente para proje-tos distribuídos (VIMEE, TeamSpace, MILOS e CVW), que criam um ambiente virtual e dis-tribuído para reuniões, permitindo comunicação síncrona ou assíncrona, formal e informal entreos 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 edesvantagens, 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 naTabela 13 do Apêndice 7.

Outro tipo de ferramenta que teve seu uso defendido em dois artigos, <Ing-184> e <Ing-33>, foi o Issue Tracker (rastreador de defeitos ou bugs), que não só permite a catalogação eo armazenamento dos defeitos a serem corrigidos, mas serve também como forma de comuni-cação e coordenação entre a equipe para a implementação de futuras funcionalidades.

Além disso, estes também podem ser utilizados como uma lista global dos afazeres dosmembros, como uma forma de atribuição e priorização de tarefas, como um meio para soluçãode conflitos ou ainda como um repositório de conhecimento, através de discussões, documentose imagens que complementam a solução de um defeito.

Talvez devessem ser considerados como tipos de ferramentas também, apesar de nãoserem 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 osdesenvolvedores e os gerentes de projeto, aumentando assim, a visibilidade dos objetivos decurto prazo para toda a equipe.

A ferramenta mais exótica encontrada, mas que ainda assim merece destaque, foi umplugin para a IDE Eclipse que permite integração com o Twitter, transformando a popular formade comunicação Microblogging em algo útil ao contexto do desenvolvimento de software. Oartigo <Ing-179> explica que, através do uso de tags específicas para tópicos do projeto emquestão, a ferramenta possibilita uma comunicação rápida entre a equipe, o compartilhamentodo 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 comuni-cação documentada, o que promove um maior compartilhamento de informações entre a equipee aumenta a agilidade das mudanças, conforme o artigo <Ing-139>.

Esta melhoria se daria basicamente pela modificação da comunicação formal dirigida aplanos para a discussão informal entre indivíduos, que poderia ocorrer através de reuniões empé, 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 produtosde qualidade significantemente superior.

Outra alteração importante que ocorre com o uso de metodologias ágeis é a aproximaçãodos clientes, que, através das stories, são obrigados a estar em constante comunicação coma equipe de desenvolvimento, sempre confirmando ou corrigindo os requisitos o mais cedopossível.

A única desvantagem relatada em relação às metodologias ágeis é a de que, quando acomplexidade 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-senecessá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é dis-tribuí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, RUPou qualquer outra com esta adaptação.


5.3.3 Dinâmicas

Os artigos encontrados sobre este tema tratam especificamente sobre técnicas aplicadasno 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 emequipe, a escrita de memorandos empresariais e documentos de gerência de projeto, reuniõescom o professor e apresentações.

Outro trabalho, <Ing-8>, sugeriu o ensino destas habilidades por meio de relatórios oraisou escritos, que seriam através de apresentações, especificações de requisitos, documentaçãodo 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 parauma comunicação eficiente.

5.3.4 Habilidades

O artigo <Ing-60> faz uma importante comparação entre as diferentes visões do meioacadê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 estascaracterísticas, foi identificado que, enquanto a habilidade de comunicação fica em primeirolugar 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 dediversos aspectos humanos e sociais, que assim, complementariam os cursos de engenharia desoftware para as reais necessidades do mercado.

Já o trabalho <Ing-42>, conseguiu ainda a modelagem de um framework de habilidadesque garantem um bom trabalho em equipe. Dentre os vários aspectos e habilidades propos-tos, 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 - Trabalhoem equipe - Escuta efetiva - Compartilhamento de idéias - Liderança de equipe - Negociação esolução de conflitos

Houve ainda o artigo <Ing-138>, abordando também esta questão, que fez um trabalhoainda mais aprofundado. Além de ter comparado estas e diversas outras habilidades, e verificadoo quão benéficas elas foram, ele ainda identificou quais os pontos positivos e negativos de cadauma delas.

No trabalho <Ing-50> foram descritas habilidades comunicativas específicas de líderes deequipe. 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 nacomunicação.

5.3.5 Modelos

Quanto à modelagem da comunicação, a maior parte dos artigos abrangeu o aspectolingüístico especificamente aplicado à etapa de engenharia de requisitos. Dentre eles, doismerecem destaque.

O primeiro, <Ing-174>, descreve técnicas de modelagem de requisitos baseadas na análiseda comunicação. Utilizando-se de diagramas de eventos comunicativos (entre os diversos atoresenvolvidos 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ópriade requisitos.

O segundo artigo, <Ing-54>, faz uma análise quanto aos padrões de conversação durantereuniões de levantamento de requisitos. Dentre suas mais importantes contribuições está ummodelo 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 umpadrão canônico de conversação entre um engenheiro de requisitos e um cliente durante aaquisição de tarefas. Como este foi representado através de um grafo orientado, é possívelidentificar 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çãode 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 boasprá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 completafoi pelo trabalho brasileiro <Pt-3>, uma vez que este se trata de uma dissertação exatamentesobre 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 dificuldadesde aplicação deste.

Em relação ao aspecto individual, houve um artigo, <Ing-1>, que fez uma abordagemum tanto psicológica e emocional da comunicação, defendendo que além de todos os quesitosdiscutidos anteriormente, também se deve prestar atenção a questões como a percepção própriae 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 aface, foi verificado como sentimentos como a frustração e a satisfação são criados a partir dosilêncio em cada um dos casos. O artigo conclui que desentendimentos são mais recorrentes nacomunicação remota, indicando que a comunicação não verbal, presente face a face, é funda-mental na solução de problemas deste tipo.

O artigo mais aprofundado no aspecto lingüístico foi o <Ing-136>, que aborda um modelopara a identificação e a correção de definições fracas. Através da verificação de fraquezas naforma 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 dosartigos encontrados em português foram bastante completos nos assuntos e aspectos que estesabordaram.

A maior contribuição deles para este trabalho foi a verificação do nível de preocupaçãodas empresas brasileiras com a questão da comunicação. No artigo <Pt-17>, é citada umapesquisa da ABERJE (Associação Brasileira de Comunicação Empresarial) que mostra que


67% das empresas nacionais não possuem nenhuma forma de medição e avaliação formal dacomunicação interna.

Vale a pena destacar também o artigo <Pt-6>, que realizou uma revisão sistemática bas-tante próxima a esta (sendo a única revisão encontrada dentre os resultados), entretanto, focandoapenas na comunicação em equipes distribuídas.

6 ConclusãoA partir da fundamentação teórica inicial deste trabalho, foi possível elaborar uma catego-

rização de três grandes aspectos da comunicação capaz de abranger todo e qualquer contexto decomunicação durante o processo de desenvolvimento de software, e, posteriormente, abrangeros diversos estudos primários obtidos por esta revisão.

O aspecto lingüístico permitiu a obtenção de artigos que visam uma comunicação efetivamesmo quando um mecanismo adequado de re-alimentação (ou feedback) é inexistente. Pormeio da análise de padrões de conversação, técnicas como eliminações de redundâncias e outrastransformações gramaticais, este aspecto visa obter uma comunicação clara, completa e nãoambígua.

Já o aspecto individual se baseia no fato de que as pessoas são o elemento essencial doprocesso de comunicação e, portanto, devem ser instruídas de modo a conseguir manter umacomunicação eficaz. Para isso, este aspecto fornece uma base para o desenvolvimento das habil-idades básicas de leitura, escrita, fala, escuta, e algumas extras de linguagem não-verbal, comogesticulação e postura, para que, assim, a pessoa esteja preparada para transmitir eficazmente edetectar quando não receber da mesma forma, para então requerer uma retransmissão.

Por fim, o aspecto organizacional mostra que fatores culturais e sociais são também deter-minantes para a qualidade e efetividade da comunicação de uma equipe ou corporação. Destaforma, a preocupação dos artigos que abrangem este aspecto são técnicas de coordenação edinâmicas de grupo que permitam o crescimento tanto do líder da equipe para que este saibamotivar e gerenciar sua equipe, quanto do grupo como um todo, aumentando sua coesão.

Através das conclusões obtidas desta revisão sistemática, pode-se perceber que o estadoda arte sobre a questão da comunicação dentro do processo de desenvolvimento de softwareainda se encontra pouco desenvolvido e possui bastante espaço para crescimento, principal-mente no cenário nacional.

O resultado desta revisão indica, ainda, que existe uma enorme carência de estudos sobreos aspectos linguístico e individual da comunicação, já que a maior parte dos trabalhos focano aspecto organizacional. Tal fato pode indicar ainda uma deficiência inerente às habilidadesdos pesquisadores de engenharia de software, visto que um maior contato com o meio cor-porativo permite um maior desenvolvimento do aspecto organizacional, enquanto que para sedesenvolver os outros aspectos, talvez seja necessário o apoio de pesquisadores de áreas comoa Linguística e a Psicologia.

Analogamente, foram encontrados poucos estudos relacionados aos assuntos metodolo-gias, habilidades de comunicação e técnicas ou dinâmicas, tanto para os resultados em inglêsquanto para os em português. Mesmo com sua significativa importância para a melhoria nacomunicação, ainda assim as pesquisas nestes ramos estão carentes, o que novamente pode teralguma relação com alguma deficiência própria dos pesquisadores destas áreas.

Além disso, o número de artigos que apresentou uma comprovação de melhoria foi igual-mente baixo, sendo importante destacar que, com o crescimento da adoção de práticas empíricasqualitativas por parte da Engenharia de Software Experimental, este cenário tende a se alterar,tanto internacionalmente quanto nacionalmente, em um curto espaço de tempo.


Uma vez investigados e detectados estes nichos pouco explorados, esta revisão poderáservir como base e motivação para futuros pesquisadores desenvolverem pesquisas nestas áreasainda carentes, podendo servir também para busca de fontes bibliográficas específicas sobredeterminado assunto ou determinado aspecto.

Como trabalho futuro, pode-se cogitar uma re-avaliação do protocolo aqui proposto porparte de um profissional da área de revisão sistemática. Consequentemente, isto resultaria emuma nova etapa de condução e posteriormente uma nova seleção com um maior número depesquisadores, o que permitiria uma maior amostragem e, inevitavelmente, traria maior segu-rança e confiabilidade quanto aos resultados deste trabalho.

7 AgradecimentoAo Prof. Ronaldo Lopes de Oliveira pela avaliação do presente texto e pelas sugestões

feitas, as quais muito contribuiram para a melhoria do texto original.

Referências[1] Abran, A.; Bourque, P.; Dupuis, R. Guide to the software engineering body of knowl-

edge (swebok), 2004.

[2] Apud Eveleens, J.; Verhoef, C. The rise and fall of chaos report figures. Standish Group(2009) - Chaos Report, p. 30–36, jan 2010.

[3] Becker, J. D.; Insley, R. G.; Endres, M. L. Communication skills of technical profes-sionals. Computer Personnel, 1997.

[4] BIOLCHINI, J.; MIAN, P.; NATALI, A.; TRAVASSOS, G. Systematic review in soft-ware engineering. Technical report, COPPE / UFRJ, Rio de Janeiro, 2005.

[5] Brereton, P.; Kitchenham, B. A.; Budgen, D.; Turner, M.; Khalil, M. Lessons fromapplying the systematic literature review process within the software engineeringdomain. Technical report, 2007.

[6] BROOKS, F. P. O mítico homem-mes: Ensaios sobre engenharia de software. Elsevier,Rio de Janeiro, 2009.

[7] CHOMSKY, N. Estruturas Sintáticas. Ed. 70, Lisboa, 1980.

[8] Curtis, B.; Krasner, H.; Iscoe, N. A field study of the software design process for largesystems. Communications of the ACM, 1988.

[9] DA SILVA, E. L. Metodologia da Pesquisa e Elaboração de Dissertação. UFSC, Flori-anópolis, 2001.

[10] da Silva, F. Q. B.; Santos, A. L. M.; Soares, S. C. B.; França, A. C. C.; Monteiro, C. Acritical appraisal of systematic reviews in software engineering from the perspectiveof the research questions asked in the reviews. In: Succi, G.; Morisio, M.; Nagappan,N., editors, ESEM. ACM, 2010.

[11] for Computing Curricula 2005, T. J. T. F. Computing curricula 2005. ACM Journal onEducational Resources in Computing (JERIC), sep 2005.


[12] Jackson, T. W.; Dawson, R.; Wilson, D. Understanding email interaction increasesorganizational productivity. Communications of the ACM, 46(8):80–84, aug 2003.

[13] Jost, A. C. What we’ve got here is: Failure to communicate. CrossTalk - The Journalof Defense Software Engineering, 19(06):10–12, jun 2006.

[14] Kitchenham, B.; Charters, S. Guidelines for performing systematic literature re-views in software engineering. Technical Report EBSE 2007-001, Keele University andDurham University Joint Report, 2007.

[15] LATIN-DICTIONARY. Definition of: Communicare. Disponível em: http://www.latin-dictionary.org/, Acessado em agosto de 2010.

[16] PRESSMAN, R. Engenharia de Software. McGraw-Hill, Rio de Janeiro, 5a edição,2002.

[17] PROJECT-CARTOON. Como projetos realmente funcionam. Disponível em: http://www.projectcartoon.com/, Acessado em agosto de 2010.

[18] ROBBINS, S. P. Comportamento Organizacional. Pearson Prentice Hall, São Paulo,11a edição, 2005.

[19] SANTAELLA, L. Semiótica aplicada. Pioneira Thomson Learning, São Paulo, 2004.

[20] SHANNON, C. W. W. Teoria matemática da comunicação. Difel, Rio de Janeiro, 1975.

[21] WINKIN, Y. A Nova comunicação. Da teoria ao trabalho de campo. Papirus, SãoPaulo, 1998.


Apêndice A - Modelos

Tabela 4: Modelo de Documentação de Busca


Tabela 5: Modelo de Relatório de Extração de Dados


Apêndice B - Lista dos Trabalhos

Tabela 6: Trabalhos Selecionados


Tabela 7: Continuação dos Trabalhos Selecionados


Tabela 8: Trabalhos Incluídos


Tabela 9: Trabalhos Excluídos


Tabela 10: Trabalhos Repetidos


Apêndice C - Contribuições Relevantes

Tabela 11: Mídias indicadas para determinados contextos, retirado de <Ing-31>.


Tabela 12: Fatores que influenciam a escolha da mídia, retirado de <Ing-31>.


Tabela 13: Ferramentas para equipes distribuídas, retirado de <Ing-9>.

Revisão sistemática sobre a comunicação dentro do processo de ...

Documents

Transcript of Revisão sistemática sobre a comunicação dentro do processo de ...