UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ CAMPUS CORNÉLIO PROCÓPIO
DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA
JOSÉ ANTONIO GONÇALVES
ESTRUTURAÇÃO DE UM PROTOCOLO DE COMUNICAÇÃO PARA
AMBIENTES DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE
DISSERTAÇÃO - MESTRADO
CORNÉLIO PROCÓPIO 2015
JOSÉ ANTONIO GONÇALVES
ESTRUTURAÇÃO DE UM PROTOCOLO DE COMUNICAÇÃO PARA
AMBIENTES DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE
Dissertação apresentada ao Programa de Pós-Graduação em Informática da Universidade Tecnológica Federal do Paraná – UTFPR como requisito parcial para a obtenção do título de “Mestre Profissional em Informática”
Orientador: Prof. Dr. Alexandre L’Erario
CORNÉLIO PROCÓPIO 2015
Dados Internacionais de Catalogação na Publicação
G635 Gonçalves, José Antonio
Estruturação de um protocolo de comunicação para ambientes de desenvolvimento distribuído de software / José Antonio Gonçalves. – 2015.
127 f. : il. ; 30 cm
Orientador: Alexandre L’Erario.
Dissertação (Mestrado) – Universidade Tecnológica Federal do Paraná. Programa de Pós- graduação em Informática. Cornélio Procópio, 2015.
Bibliografia: p. 80-84.
1. Software - Desenvolvimento. 2. Comunicação e tecnologia.3. Software de comunicação. 4. Informática – Dissertações. I. L’Erario, Alexandre, orient. II. Universidade Tecnológica Federal do Paraná. Programa de Pós-graduação em Informática. III. Título.
CDD (22. ed.) 004 Biblioteca da UTFPR, Câmpus Cornélio Procópio
Av. Alberto Carazzai, 1640 - 86.300-000- Cornélio Procópio – PR.
Tel. +55 (43) 3520-4055 / e-mail: [email protected] / www.utfpr.edu.br/cornelioprocopio/ppgi Título da Dissertação Nº 08:
“
Estruturação de um Protocolo de Comunicação Para
Ambientes de Desenvolvimento Distribuído de Software
”.
por
José Antônio Gonçalves
Orientador: Prof. Dr. Alexandre L'Erário
Esta dissertação foi apresentada como requisito parcial à obtenção do grau de MESTRE EM INFORMÁTICA – Área de Concentração: Computação Aplicada, pelo Programa de Pós-Graduação em Informática – PPGI – da Universidade Tecnológica Federal do Paraná – UTFPR – Câmpus Cornélio Procópio, às 14h00 do dia 24 de agosto de 2015. O trabalho foi APROVADO pela Banca Examinadora, composta pelos professores:
__________________________________
Prof. Dr. Alexandre L'Erário
(Presidente)
__________________________________
Prof. Dr. Elias Canhadas Genvigir
(UTFPR-LD)
_________________________________
Prof. Dr. Osmar Aparecido Machado
(FEMA-SP)
Visto da coordenação: __________________________________ Carlos Nascimento Silla Junior
Coordenador do Programa de Pós-Graduação em Informática UTFPR Câmpus Cornélio Procópio
Dedico este trabalho a minha esposa Joelma e aos meus filhos Rafael e Júlia.
AGRADECIMENTOS
A Deus, por ter me cercado de amigos, sem os quais não teria conseguido concluir este trabalho.
Ao meu orientador neste trabalho, Professor Dr. Alexandre L´Erario, pelas palavras de incentivo, orientações e confiança depositada em mim.
Aos Professores Dr. José Augusto Fabri e Dr. Elias Canhadas Genvigir, pelas valiosas contribuições.
Aos amigos Alessandro Silveira Duarte e Gabriel Canhadas Genvigir, pelas várias discussões e incentivos, durante todas as fases que compuseram este desafio chamado Mestrado Profissional em Informática.
Aos alunos de graduação José Antonio Ponqueli Contó, William Simão de Deus, Allan Victor Mori, Matheus Alberto Sossai e aos alunos do Programa de Pós-Graduação em Informática (PPGI) que, direta ou indiretamente, me ajudaram neste trabalho.
Agradecendo a estes amigos, estendo os meus agradecimentos a todos os outros que diretamente ou indiretamente também fizeram parte deste processo.
"Se falares a um homem numa linguagem que ele compreenda, a tua mensagem entra na sua cabeça. Se lhe falares na sua própria linguagem, a tua mensagem entra-lhe diretamente no coração".
Resumo
GONÇALVES, José Antonio. Estruturação de um protocolo de comunicação
para ambientes de desenvolvimento distribuído de software. 2015. 127 f.
Dissertação de Mestrado (Mestrado Profissional em Informática), Programa de Pós-Graduação em Informática, Universidade Tecnológica Federal do Paraná. Cornélio Procópio, 2015.
A gestão da comunicação em ambientes distribuídos para o desenvolvimento de software (DDS) é um tema que tem sido investigado a fim de garantir a consistência dos cenários de colaboração. Como este assunto é relativamente recente, e envolve questões técnicas e humanas, é comum que novos conceito e características do processo de comunicação em DDS sejam levantadas. Neste sentido, este trabalho objetivou criar um protocolo a fim de estruturar a comunicação em ambientes DDS. A validação das hipóteses que o subsidiaram se deu por meio de experimentação, que foi realizada por meio de atividades realizadas por alunos do curso de pós-graduação em informática (PPGI) da Universidade Tecnológica Federal do Paraná- Campus Cornélio Procópio. Para experimento configurou-se o ambiente de modo que este tivesse as características de um ambiente distribuído. Propôs-se uma atividade que consistia em um conjunto de subatividades, que deveriam ser realizadas por cada grupo de alunos, que estavam fisicamente separados, que os obrigou a utilizarem ferramentas de comunicação síncronas e assíncronas. Ao final do experimento, atingiu-se as expectativas, pois conseguiu-se estruturar a comunicação em camadas hierárquicas, que configurou e definiu o protocolo de comunicação em projetos de DDS.
Palavras-chave: Desenvolvimento Distribuído de Software. Comunicação em
Desenvolvimento Distribuído de Software. Protocolo de Comunicação em Desenvolvimento Distribuído de Software.
Abstract
GONÇALVES, José Antonio. Estruturação de um protocolo de comunicação
para ambientes de desenvolvimento distribuído de software. 2015. 127 f.
Dissertação de Mestrado (Mestrado Profissional em Informática), Programa de Pós-Graduação em Informática, Universidade Tecnológica Federal do Paraná. Cornélio Procópio, 2015.
The communication management in environments for distributed software development (DSD) has been investigated to ensure the consistency of collaboration scenarios. As a recent topic that involves technical and human issues, new concepts and processes of communication in DSD have been raised. Thus, this study presents a protocol to structure communication in DSD environments. The protocol was defined using the validation of hypotheses in an experiment, which was conducted by means of activities performed by master students in computer science. In the experiment, we set up the environment that had the characteristics of a distributed environment. It was proposed an project consisting of a set of activities to be carried out by groups of students. Each group was physically separated, forcing them to use synchronous and asynchronous communication tools. At the end, the expectations were met since we were able to structure the communication in hierarchical layers, setting up and defining the communication protocol in DSD projects.
Keywords: Distributed Software Development. Communication in Distributed
Software Development. Communication Protocol for Distributed Software Development.
LISTA DE FIGURAS
FIGURA 1 - MODELOS DE NEGÓCIO EM DDS ... 23
FIGURA 2 - CLASSIFICAÇÃO DAS APLICAÇÕES BASEADAS NO MODELO 3C ... 29
FIGURA 3 - PROCESSO DE MAPEAMENTO SISTEMÁTICO ... 31
FIGURA 4 - CONSTRUÇÃO DO ESQUEMA DE CLASSIFICAÇÃO ... 32
FIGURA 5 - PROTOCOLO DE COMUNICAÇÃO EM DDS ... 38
FIGURA 6 - COMUNICAÇÃO ENTRE SITES ... 39
FIGURA 7 - COMUNICAÇÃO ENTRE SITES ... 39
FIGURA 8 - UMA INSTÂNCIA DO PROTOCOLO DE COMUNICAÇÃO ... 42
FIGURA 9 – SEGUNDO EXEMPLO DE UMA INSTÂNCIA DO PROTOCOLO ... 43
FIGURA 10 - SEQUÊNCIA DOS PASSOS PARA DESENVOLVIMENTO DO PROJETO. ... 51
FIGURA 11 - PROCESSO DE EXECUÇÃO DO EXPERIMENTO ... 54
FIGURA 12 - PROCESSO DE EXTRAÇÃO E PADRONIZAÇÃO DOS DADOS ... 60
FIGURA 13 - FLUXO DAS COMUNICAÇÕES DA UC 1 ... 65
FIGURA 14 - FLUXO DAS COMUNICAÇÕES DA UC 110 ... 67
FIGURA 15 - FLUXO DAS COMUNICAÇÕES DA UC 23 ... 69
FIGURA 16 - ÍNDICE E MENSURAÇÃO DA COMUNICAÇÃO DA UC 23 ... 70
LISTA DE QUADROS
QUADRO 1 - COMPOSIÇÕES DOS MODELOS DE NEGÓCIOS ... 23
QUADRO 2 - CLASSE DE TRANSMISSÕES CONVENCIONAIS ... 26
QUADRO 3 - CLASSE DE TRANSMISSÕES APOIADAS POR GROUPWARES ... 27
QUADRO 4 - PROPÓSITOS DE COMUNICAÇÃO EM AMBIENTES DE DDS ... 30
QUADRO 5 - ETAPAS DO MAPEAMENTO SISTEMÁTICO ... 32
QUADRO 6 - APLICAÇÃO DAS ETAPAS DO MAPEAMENTO SISTEMÁTICO ... 33
QUADRO 7 - RESULTADOS DA BUSCA NO SITE DA IEEE ... 34
QUADRO 8 - RESULTADOS DA BUSCA NO SITE DA ACM ... 34
QUADRO 9 - MENSURAÇÃO DA COMUNICAÇÃO ... 40
QUADRO 10 - CONFIGURAÇÃO DAS CAMADAS DE ESTRUTURAÇÃO DO PROTOCOLO ... 41
QUADRO 11 - APLICAÇÃO DA PLANILHA GQM ... 48
QUADRO 12 - PROPÓSITOS DO PROJETO ... 51
QUADRO 13 - CONJUNTO DE ARTEFATOS OBRIGATÓRIOS ... 52
QUADRO 14 - PERGUNTAS INVESTIGADAS PARA A HIPÓTESE 0 – H0 ... 55
QUADRO 15 - DEFINIÇÕES DAS VARIÁVEIS ... 55
QUADRO 16 - TRECHO DOS REGISTROS GERADOS NO MOODLE ... 61
QUADRO 17 - TRECHO DOS REGISTROS GERADOS NO GMAIL ... 62
QUADRO 18 - TRECHO DOS REGISTROS GERADOS NO HANGOUT ... 63
QUADRO 19 - LAYOUT DO ARQUIVO USADO PARA EXTRAÇÃO E ESTRATIFICAÇÃO DOS DADOS ... 63
QUADRO 20 - INTERAÇÕES ENTRE VL E G1 - UC 1... 65
QUADRO 21 - INTERAÇÃO ENTRE G2 E O SERVIDOR MOODLE - UC 110 ... 66
QUADRO 22 - FLUXO DAS COMUNICAÇÕES DA UC 23 ... 68
QUADRO 23 - EXEMPLO DE RUÍDO NA COMUNICAÇÃO ... 71
QUADRO 24 - RELAÇÃO DE PROPÓSITOS PARA O EXPERIMENTO ... 72
QUADRO 25 - NOVO LAYOUT DO ARQUIVO USADO PARA EXTRAÇÃO E ESTRATIFICAÇÃO DOS DADOS ... 73
LISTA DE SIGLAS
ACM Association for Computing Machiner CSCW Computer Support Cooperative Work DDS Desenvolvimento Distribuído de Software DGS Desenvolvimento Global de Software FIE Frontiers In Education
FTS Follow the Sun GQM Goal, Question, Metric
GTI Gestão da Tecnologia da Informação
IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol
ISO International Organization for Standardization OSI Open Systems Interconnection
PMBOK Project Management Body of Knowledge PPGI Programa de Pós-Graduação em Informática RFC Request For Comments
TCP Transmission Control Protocol TI Tecnologia da Informação
UC Unidade de Comunicação
UTFPR Universidade Tecnológica Federal do Paraná XML Extensible Markup Language
SUMÁRIO 1 INTRODUÇÃO ... 13 1.1 MOTIVAÇÃO ... 15 1.2 OBJETIVOS ... 16 1.3 ESTRUTURA DO TRABALHO ... 18 2 REVISÃO BIBLIOGRÁFICA ... 20
2.1 DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE ... 20
2.2 MODELOS E AMBIENTES EM DDS ... 21
2.3 COMUNICAÇÃO EM DDS ... 25
2.4 PROPÓSITOS PARA A COMUNICAÇÃO EM DDS ... 28
2.5 TRABALHOS RELACIONADOS ... 30
3 PROTOCOLO DE COMUNICAÇÃO EM DDS ... 36
3.1 PROTOCOLO DE COMUNICAÇÃO ... 36
3.2 ESTRUTURAÇÃO DO PROTOCOLO DE COMUNICAÇÃO... 37
3.3 INSTÂNCIA DO PROTOCOLO ... 41
4 MÉTODOS E PROCEDIMENTOS DE PESQUISA ... 45
4.1 MÉTODOS DE PESQUISA ... 45
4.2 MÉTODO ADOTADO ... 46
4.3 PROTOCOLO DE PESQUISA ... 48
5 RESULTADOS ... 59
5.1 EXECUÇÃO DO EXPERIMENTO ... 59
5.2 RESULTADOS OBTIDOS E TRATAMENTO DE DADOS ... 60
5.3 ANÁLISE E INTERPRETAÇÃO DOS DADOS ... 64
6 CONCLUSÕES ... 77
6.1 TRABALHOS FUTUROS ... 79
REFERÊNCIAS ... 80
ANEXO I ... 85
1 INTRODUÇÃO
A historicidade da construção de software mostra a necessidade de processos cada vez mais criteriosos para a produção e que atendam a demanda e também seus vários quesitos como qualidade, eficiência, eficácia, prazo e preço, que devem ser conduzidos de forma técnica e harmoniosa. Destas necessidades surgiu a Engenharia de Software que tenta gerir todas as etapas do processo de desenvolvimento de software (PRESSMAN, 2011; SUMMERVILLE, 2007).
A dinâmica evolutiva do desenvolvimento de sistemas de informação, que agrega tecnologias de hardware e de software, as novas e crescentes demandas da sociedade, incrementa a complexidade da gestão no desenvolvimento de software. Consequência esta, dentre outros fatores, oriundo do processo de globalização, que, em grande, parte é suportada pela internet (LI; MATHUR; KANOUN, 2004).
Das necessidades empresariais em um mundo globalizado junto à convergência de novas tecnologias de interação entre pessoas fisicamente distantes, emergiu um ambiente para desenvolvimento de software denominado Desenvolvimento Distribuído de Software (DDS), no qual pessoas trabalham em um mesmo projeto, porém geográfica e/ou temporalmente distantes (HUZITA et al., 2007; PRIKLADNICKI, 2009). Segundo Carmel (1999), esta forma de trabalho tem causado um impacto significativo no mercado pela maneira como os produtos são modelados, desenvolvidos, testados e entregues aos clientes.
Segundo L´Erario (2009) a redução de tempo de construção de um software, redução de custo, proximidade dos clientes e mão de obra qualificada compõem os principais motivos para se dividir as tarefas entre equipes distribuídas.
Em um ambiente de DDS as tarefas são particionadas e repassadas às equipes geográfica e temporalmente distantes, porém, em algum momento estas devem ser integralizadas para comporem o produto final. Neste caso a comunicação, análoga a uma corrente, representa o aglomerado de elos que interligam as equipes e, consequentemente, o conjunto de tarefas, outrora particionadas, que foram executadas durante as fazes de laboração e integralização dos resultados parciais e finais (GONCALVES et al., 2013). Pressuposta a
importância da comunicação, sua ineficiência ou ineficácia pode gerar anomalias durante o processo de integralização do resultado/produto final (YASSINE et al., 2003).
Em detrimento às dificuldades geradas pelas dispersões geográficas e temporais e pelas diferenças socioculturais (LINGS et al., 2007), o crescimento do DDS é uma realidade, segundo relatório Gartner (F. KARAMOUZIS, 2011 apud LEE; ESPINOSA; DELONE, 2013) mais 90% das empresas da Global Fortune 500, que classifica as 500 maiores corporações do planeta de acordo com suas receitas, usaram recursos externos para entrega de serviços de Tecnologia da Informação (TI). Ainda de acordo com este relatório, em 2010 as empresas gastaram 31% com TI em serviços externos. Lee, Espinosa e Delone (2013) relatam que, ao entrevistarem um engenheiro de uma grande empresa de serviços de TI, este disse: “É quase impossível nos dias de hoje encontrar uma equipe de software que está completamente co-alocada”.
O processo de software é constituído por várias etapas que vão desde o levantamento de requisitos até a entrega do produto final. Todas estas etapas são regidas por políticas (modelos de processos) e comunicam informações e/ou artefatos entre elas (PRESSMAN, 2011; SUMMERVILLE, 2007). Martins (2010) afirma que a comunicação é essencial a qualquer tipo de projeto, independentemente de sua complexidade, que nestes deve haver um fluxo constante de informações sobre o andamento e repasse das atividades entre os
stakeholders (envolvidos ou afetados por um projeto ou por seus resultados, seja
uma pessoa, grupo ou organização).
Ehrlich e Cataldo (2012) dizem que, a gerência das comunicações interpessoais e entre pessoas e processos, é um dos fatores preponderantes ao se trabalhar com DDS e Lee, Espinosa e Delone (2013) apresentam uma característica agravante ao classificar o DDS como um ambiente complexo e volátil e que oferece muitos desafios e riscos para a coordenação de tarefas interdependentes que, eventualmente, influenciam o sucesso do desenvolvimento de software.
Este trabalho destina-se a profissionais que atuam em projetos de softwares desenvolvidos em ambientes distribuídos. Àqueles que procuram compreender este ambiente e que buscam aumentar a sinergia entre os stakeholders de projetos em DDS , a fim de torná-los cada vez mais colaborativos. Para isto, este trabalho aposta
na gestão da comunicação entre estes subambientes, pois acredita-se no modelo 3C de Ellis, Gibbis e Rein (1991), que afirma que a comunicação, junto com a cooperação e coordenação, é uma das dimensões da colaboratividade.
1.1 MOTIVAÇÃO
A comunicação executada entre os participantes de um projeto é efetiva e necessária. A comunicação ruidosa tem consequências negativas na exequibilidade do projeto, uma vez que se criam compreensões distintas em sites distintos para um mesmo elemento, dentro de um projeto de software.
Os estudos utilizados como referencial teórico, apresentados no capítulo 2, expõem questões que abordam a comunicação em projetos distribuídos e a relevância do tema. Os trabalhos de Ellis, Gibbis e Rein (1991), Fuks et al. (2008), Goncalves et al. (2013, 2014) e Prikladnicki (2009), que abordam a comunicação em ambientes de DDS, reforçam esta relevância. Diante deste fato, notou-se a importância em desenvolver uma pesquisa sobre comunicação em ambientes de DDS. Tal pesquisa tem o intuito de estruturar um protocolo de comunicação em ambientes de DDS. Os estudos preliminares a esta pesquisa são refletidos em três trabalhos, descritos a seguir:
O primeiro, apresentado por Goncalves et al. (2013), trata-se de um experimento cujo resultado foi a possibilidade de se classificar a comunicação. Neste primeiro estudo percebeu-se que, mesmo adotando um modelo de processo
ad hoc para gestão do projeto, a comunicação entre os stakeholders limitou-se
exclusivamente no momento de repasse dos artefatos desenvolvidos. Em decorrência disto as pessoas envolvidas identificaram imperfeições nos artefatos após estes já terem sido confeccionados.
A consequência das imperfeições, geradas nos artefatos, implicou em novas iterações, a reflexão deste fato pôde ser observado no processo de comunicação, devido à necessidade de se fazer uma nova solicitação para a adequação do artefato, ou seja, um retrabalho, que gerava um atraso nas atividades e no projeto como um todo.
O segundo trabalho trata-se de um estudo de caso que buscou mapear a comunicação que ocorreu em ambientes de DDS, com o intuito de definir a relação entre quantidade e qualidade da comunicação e criar um conjunto de cenários para definição da comunicação em sites de DDS (GONCALVES; DOS SANTOS; L’ERARIO, 2013).
Por fim, no terceiro Goncalves et al. (2014), apresenta uma proposta de criação de um meta-protocolo em ambientes de DDS. Por meio deste meta-protocolo seria possível, de maneira sistematizada, identificar, mapear e analisar a comunicação em projetos de DDS, a fim de, se necessário, fazer adequações de acordo com as peculiaridades do projeto ou dos stakeholders.
Em comum estes três trabalhos (GONCALVES; DOS SANTOS; L’ERARIO, 2013; GONCALVES et al., 2013, 2014) identificaram a persistência dos problemas relacionados a comunicação, como a adoção correta de técnicas e tecnologias adequadas que equacione questões como as dispersões geográfica e temporal, comuns ao ambiente de DDS.
Para Ramasubbu et al. (2011) problemas na comunicação, entre outros, causam lentidão no fluxo de execução de tarefas, aumento da taxa de erros, que resulta em uma maior quantidade de defeitos no software refletindo sobre os custos de desenvolvimento.
1.2 OBJETIVOS
1.2.1 Objetivos Gerais
Por meio deste trabalho busca-se estruturar um protocolo de comunicação existente em projetos de DDS. Assim procura-se identificar, em projetos reais, a viabilidade de mapear a comunicação em um formato estruturado. Acredita-se que esta estrutura possa viabilizar recursos similares de gerenciamento, disponíveis na área de redes de computadores.
Entende-se por protocolo uma referência para se criar ou adaptar as regras de comunicação existente em ambientes de DDS. Pode-se comparar este protocolo
aos, já existentes, modelos de referência ISO/OSI e TCP/IP, utilizados para definir regras de comunicação na área de Redes de Computadores.
Na vertente de redes de computadores, os protocolos são compostos por regras de comunicação, pacotes e quadros. São estes conceitos, apresentados por Tanenbaum (2003), que tornam viáveis um estudo mais preciso sobre a interação entre dois dispositivos eletrônicos. Inicialmente, antes mesmo da abordagem da regra de comunicação, os dispositivos trocam dados pelo considerado mais baixo nível de unidade de comunicação denominado quadro (frame).
Segundo Tanenbaum (2003) o frame é um conjunto delimitado de bits que contempla a carga útil que é a informação propriamente dita e, também, os campos adicionais que garantem a integridade da comunicação, como os campos origem, destino, sequência, ack, checksum e outros.
A comunicação que ocorre em projetos é, de certa forma, semelhante a esta, porém tais campos são subentendidos no processo de comunicação e compreensão humana. Neste sentido, este trabalho aborda a comunicação no intuito de estruturar um protocolo, para isso segmenta a comunicação de um projeto em partes significativas, análogas aos frames, permeados pela área de redes de computadores.
Em seu trabalho anterior Goncalves et al. (2014) o autor desta pesquisa apresentou a proposta de um meta-protocolo, por meio do qual seria possível identificar, mapear a comunicação em ambiente de DDS e, caso fosse detectada alguma anomalia que comprometesse o processo de comunicação, a possibilidade de intervir a fim de corrigi-lo ou adaptá-lo. Com o intuito de garantir uma contribuição mais consistente à comunidade, este trabalho apresenta um escopo mais objetivo, mantendo-se na identificação e estruturação de fragmentos de comunicação em DDS. Acredita-se também que desta forma se garanta a exequibilidade da pesquisa. Entende-se que os fragmentos de comunicação identificados são comparáveis às unidades singulares, uma vez que os projetos distribuídos de software incorporam a comunicação humana derivada da habilidade de cada um dos participantes.
1.2.2 Objetivos Específicos
Para que a proposta deste projeto possa ser atendida, os seguintes objetivos específicos, em complemento aos objetivos gerais, serão realizados:
a) buscar na Literatura as principais concepções sobre o assunto, sejam conceitos, técnicas e etc.;
b) elaborar um experimento que simule um ambiente de DDS, no qual será possível: b.1) identificar e compreender os comportamentos das variáveis, independentes e dependentes;
b.2) validar o modelo do protocolo proposto; e b.3) aceitar a hipótese apresentada.
1.3 ESTRUTURA DO TRABALHO
Este trabalho foi estruturado em 6 capítulos. Na Introdução, apresentou-se uma breve explanação sobre DDS, a comunicação existente neste tipo de ambiente e alguns de seus percalços. Ainda explanou-se sobre os objetivos e a motivação para execução deste trabalho. O capítulo 2 mostra a revisão bibliográfica sobre DDS, modelos e ambientes de DDS. Neste capítulo também se conceitua genericamente a comunicação e especificam-se suas características no DDS; e apresentam-se também ostrabalhos relacionados. O capítulo 3 expõe a proposta do protocolo, também apresenta os conceitos sobre este e apresenta o modelo proposto. No capítulo 4 são apresentadas algumas metodologias de pesquisa e detalha a que foi adotada para este projeto, bem como a justificativa da sua escolha. O capítulo 5 apresenta o planejamento das atividades do projeto: as atividades que serão executadas, os riscos identificados a este, os resultados esperados e o cronograma de execução das atividades. O capítulo 6 apresenta as conclusões deste trabalho e aponta os trabalhos futuros. Por fim, os anexos I, que apresenta os artigos publicados pelo autor; e o II, contendo 10 páginas dos dados coletados durante o experimento que compõe este trabalho.
Neste trabalho definiu-se que a autoria será do próprio autor (autoria própria) quando houver algum elemento gráfico no texto como figuras, tabelas ou quadros e,
que para estes, não forem indicadas as citações de suas fontes. Ainda, as siglas, acrônimos e palavras estrangeiras serão explicados no mesmo parágrafo da sua primeira ocorrência.
2 REVISÃO BIBLIOGRÁFICA
Este capítulo apresenta a revisão bibliográfica sobre os conceitos utilizados como alicerce para a elaboração e desenvolvimento deste projeto de pesquisa. O mesmo encontra-se dividido em 5 seções, descritas a seguir:
2.1 DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE
Esta seção define DDS e aborda as condições atenuantes e agravantes que permeiam as atividades de software desenvolvidas em um ambiente distribuído.
Segundo Audy e Prikladnicki (2007) o DDS é caracterizado como um cenário no qual pessoas envolvidas em processo de desenvolvimento de um mesmo projeto se encontram dispersas geográfica ou temporalmente. Estas dispersões são resultados da configuração feita pela empresa gestora do projeto, que gera unidades de produção independentes e cada unidade desta é chamada de site (L’ERARIO, 2009). Slack, Chambers e Johnston (2009) corroboram esta afirmação ao considerar que estes arranjos ocorrem por meio da definição de onde colocar ou alocar recursos para uma operação produtiva.
Ivček e Galinac (2008) afirmam que no DDS as equipes de desenvolvimento de software estão distribuídas globalmente em mais de um local e, por vezes, em mais de um continente. Esta condição implica em pessoas que se localizam a distâncias tão grandes que seus cronogramas de atividades são afetados pelos fusos horários (LINGS et al., 2007). Prikladnicki (2009) considera natural que estas dispersões atinjam grandes amplitudes, internacionais ou intercontinentais, e classifica este cenário de trabalho como Desenvolvimento Global de Software (DGS).
Mesmo se apresentando como um ambiente no qual a gerência de atividades tende a ser mais complexas, são vários os motivos que impulsionam o DDS. Ågerfalk et al. (2005), Herbsleb e Moitra (2001) e Jabangwe e Smite (2011) afirmam que a busca por mão de obra bem qualificada e de menor custo, proximidade com mercados locais, são necessidades e atrativos advindos com o processo da globalização que transformou os mercados locais em internacionais e
geraram um ambiente com novas condições de competitividade, por consequência exigindo das empresas de alta tecnologia, novos modelos de produção que sejam mais colaborativos. Consoante a estes fatos Meyer (2006) afirma que a produção distribuída torna-se cada vez mais comum em um mundo globalizado.
Carmel e Tjia (2005) reforçam a teoria de que estes arranjos produtivos são fomentados por questões como a proximidade com o mercado local e, por decorrência, a obtenção de informações mais precisas sobre clientes e oportunidades de negócios em qualquer região do planeta. Segundo L´Erario (2009), a construção destes novos modelos de produção podem ocorrer, entre outros motivos, quando as empresas não dominam as técnicas ou tecnologias necessárias aos seus projetos, isto as induzem a buscarem parcerias a fim de suprir tais déficits.
No DDS, a possibilidade de acessar recursos globais em tempo integral é um conceito apresentado por Carmel e Tjia (2005) como "follow the sun" (FTS), que traduzido significa: siga o sol. Para estes autores, este conceito busca converter uma situação desfavorável, decorrente das dispersões geográficas e temporais do DDS, que podem prejudicar o ambiente colaborativo ao afetar a comunicação entre os stakeholders, propiciando condições vantajosas no arranjo produtivo, ao permitir um ciclo contínuo de produtividade, no qual se tem pessoas trabalhando 24 horas por dia.
L´Erario (2009) afirma que o conceito FTS viabiliza divisões mais flexíveis das tarefas de desenvolvimento, reduzindo assim o tempo de produção. Cataldo e Herbsleb (2008) afirmam que a divisão de tarefas - ou modularização de tarefas -, é uma forma de minimizar as dependências técnicas e tornar as complexidades gerenciáveis, permitindo trabalhos paralelos e tolerantes as incertezas.
2.2 MODELOS E AMBIENTES EM DDS
Como afirmado por Carmel e Tjia (2005), no atual cenário mundial, em que os empreendimentos acontecem em nível global, é natural que as indústrias do setor produtivo apresentem uma crescente busca por recursos em qualquer região do planeta a fim de suprir demandas humanas, tecnológicas, econômicas e outros. Por vezes esta busca é representada por meio da transferência de operações para outras regiões em que uma empresa possui uma filial ou, até mesmo, para outras
empresas, terceirizando parcial ou totalmente, uma atividade (L’ERARIO, 2009). Segundo Carmel e Agarwal (2001) e L’Erario (2009), a indústria da TI segue esta ordeme adota modelos de relações de negócios intra e inter empresariais.
De acordo com suas aplicações no DDS, esta seção apresenta os principais conceitos e modelos de negócios, definidos por Robinson e Kalakota (2004, apud
AUDY; PRIKLADNICKI, 2007). Estes conceitos foram abordados sob os aspectos das relações entre os stakeholders e às dimensões geográficas.
Para este trabalho, as relações entre os stakeholders ocorrem durante o desenvolvimento de projetos de softwares e são constituídas por meio de trocas dos artefatos gerados nas etapas existentes nos modelos de processos que gerenciam este desenvolvimento ou, ainda, pelas comunicações casuais que ocorrem de maneira informal, mas que interferem nos projetos. Todavia estas relações estão embasadas nos modelos de negócios presentes no DDS e que definem se as soluções serão ou não provenientes da própria empresa. Tais relações são classificadas como outsourcing ou insourcing.
O outsourcing trata-se da terceirização do desenvolvimento ou da compra de um produto de software, enquanto que em uma relação insourcing a empresa instala um centro próprio para desenvolver o produto de software.
Além das características inerentes às relações de negócio entre entidade de desenvolvimento de software e cliente, outra característica singular do DDS está centrada nas dimensões geográficas entre as unidades de produção de software. Neste sentido, Robinson e Kalakota (2004, apud AUDY; PRIKLADNICKI, 2007) as
classificam como:
a) Offshore: a empresa contratada, ou uma filial, localizada em um país diferente da empresa contratante ou matriz. No uso deste modelo é imprescindível que todos os envolvidos tenham uma boa compreensão dos requisitos do projeto de software e o plano deste deve ser bem elaborado e definido; e
b) Onshore: as empresas, contratante e contratada; ou a contratante e sua filial localizam-se em um mesmo país. Neste caso também se pode encontrar duas situações em relação às estas empresas. A primeira, offsite denomina-se quando a contratante e contratada - ou a filial da contratante – encontram-se no mesmo país, mas fisicamente distantes e o desenvolvimento do projeto se dá na empresa contratada, mantendo a proximidade com o cliente e com o projeto. A segunda,
onsite, a empresa contratada trabalha, fisicamente, junto ao cliente. Desta forma
permite ao cliente maior controle sobre o projeto. Indicado quando o projeto necessita de atenção constante por parte da cliente, por exemplo, projetos sensíveis ao cenário de trabalho da cliente.
A Figura 1 sintetiza as possíveis situações entre os pontos apresentados sobre os modelos de negócios:
Figura 1 - Modelos de negócio em DDS
Fonte: Robinson e Kalakota (2004,apud AUDY; PRIKLADNICKI, 2007)
Considera-se que as atividades e demandas deste trabalho estão associadas a produção de software e, atentando-se para as definições dos modelos de negócios apresentados por meio da Figura 1, o Quadro 1 demonstra a existência das seguintes composições dos modelos de negócios, segundo Audy e Prikladnicki (2007):
Atividades desempenhadas dentro do mesmo país (Onshore) Modelo de Negócio Descrição
Onshore Insourcing Um departamento da empresa, ou sua filial, atende as necessidades da própria empresa (projetos internos);
Onshore Outsourcing Para atender suas demandas a empresa terceiriza serviços de outra empresa.
Em países distintos (Offshore) Modelo de Negócio Descrição
Offshore Insourcing ou Captive/Internal Offshoring
A empresa cria uma subsidiária em outro país e, por meio dela, desenvolve projetos para atender suas demandas;
Offshore Outsourcing A empresa terceiriza serviços de outra empresa para atender suas demandas.
Ramasubbu et al. (2011) afirma que o DDS tornou-se um modelo operacional dominante para desenvolvimento e fornecimento de sistemas intensivos de software. Assim pressupõe-se que os modelos de negócio, apresentados neste trabalho, são conformações naturais que surgiram das necessidades comerciais, entre elas, a competitividade. Esta competitividade também é um dos fatores que levam empresas a aderirem ao DDS, pois este permite que as empresas busquem vantagens por meio de estratégias que são atendidas pelo DDS, como a melhor qualidade de mão de obra, redução de custos e do tempo de produção (ÅGERFALK et al., 2005; HERBSLEB; MOITRA, 2001; JABANGWE; SMITE, 2011).
Pode-se exemplificar por meio de estudos que mostram que a redução do tempo de produção, que impacta no custo geral do desenvolvimento de software, pode ser obtida por meio da estratégia de divisão de tarefas (L’ERARIO, 2009). Todavia a estratégia de dividir tarefas, a fim de reduzir o tempo, não é uma novidade advinda com o DDS, mas devido às características deste ambiente. A dispersão geográfica pode contemplar diversos fusos horários e a divisão de tarefas pode ser aprimorada ao ponto de ter-se um processo produtivo ininterrupto, como afirmam Carmel e Tjia (2005) na apresentação do conceito "follow the sun".
Os modelos de negócios apresentados servem como base para as relações inter e intra empresarias, se tratam de possibilidades a serem utilizadas no direcionamento de um determinado projeto, tendo em vista o real potencial da empresa e após estudos que respondam questões como: se será produzido pela própria empresa ou por uma terceira? Isso ocorrerá em um mesmo ou em muitos países? Estas respostas devem nortear a escolha do modelo de negócios que ofereça maiores vantagens de competitividade e subsidie quesitos como qualidade, prazo e custo.
Além dos modelos de negócio, segundo L’Erario (2012), o DDS segue uma dinâmica de evolução que se inicia na concepção do projeto para a produção distribuída, ou seja, no preparo para que as tarefas sejam particionadas e encaminhadas para as unidades de produção, seguindo pela integração até a entrega do produto final. Analogamente, os sites de produção tangem um processo similar, no momento em que precisam se preparar para a produção distribuída, produzem artefatos simultaneamente com demais sites. O fim da respectiva atividade, não havendo outra atividade sequente ou simultânea, indica que o site
pode se desassociar da produção em um projeto distribuído até que sua atuação seja novamente necessária.
2.3 COMUNICAÇÃO EM DDS
Esta seção define o que é comunicação bem como os aspectos técnicos que permitem que ela ocorra em um projeto de software, aborda as características relacionadas à sua sincronia e, por esta perspectiva, associa-a ao meio utilizado para estabelecer uma comunicação eficaz, denominado classes de transmissão. Para tanto, considera fatores comuns aos projetos distribuídos como as dispersões geográficas ou temporais.
Dentre as definições dadas por Ferreira (1986 - p. 443 - 444) à comunicação se encontra esta:
“... 2. Ato ou efeito de emitir, transmitir e receber mensagens por meio de métodos e/ou processos convencionados, quer da linguagem falada ou escrita, quer de outros sinais, signos ou símbolos, que de aparelhamento técnico especializado, sonoro ou visual. 3. P. ext. A ação de utilizar os meios necessários para realizar tal comunicação. ...”
Fuks et al. (2008) não difere da definição de Ferreira (1986) ao descrever a comunicação como trocas de mensagens e negociações entre as pessoas em processos de softwares. Consoante às definições anteriores sobre comunicação o PMBOK (2013) pontua a relevância da gerência de comunicação ressaltando o processo desde a geração a recuperação apropriada de informações.
A comunicação é como os elos de uma corrente que interligam os
stakeholders durante os processos de divisão e integralização dos resultados
obtidos em desenvolvimentos de softwares, principalmente no DDS (GONCALVES et al., 2013). Junior et al. (2012) explica que o exercício da comunicação fortalece e desenvolve a coesão entre as equipes.
Contudo, deve-se ponderar as condições peculiares existentes ao se construir um processo de comunicação em projetos distribuídos. A predisposição dos stakeholders de um projeto distribuído em se comunicar, permeia um conjunto de configurações que advém de técnicas e tecnologias utilizadas na execução das interações entre as unidades produtivas. Ao abordarem os desafios do DDS
relacionados à tecnologia Audy e Prikladnicki (2007) afirmam que a configuração mais evidente, quanto a estas tecnologias em um cenário de desenvolvimento distribuído, trata-se da sincronia na comunicação.
A comunicação síncrona ocorre quando os participantes têm acesso às mensagens transmitidas em tempo real. Exemplo disto são as conversas ou reuniões presenciais ou por meio de ligações telefônicas ou, ainda, softwares que permitam o uso de uma gama de tecnologias, que podem ou não estar agregadas em uma única forma de comunicação, como as trocas de textos, áudios e vídeos. Esta forma indica que os participantes utilizam o mesmo meio de comunicação ao mesmo tempo.
A comunicação assíncrona se desenvolve quando seus participantes utilizam o mesmo meio de comunicação, porém não ao mesmo tempo. Exemplo desta forma são as correspondências físicas, os correios eletrônicos e postagens em
sites de relacionamentos. Todos eles permitem acessos após seus envios.
A sincronia da comunicação é uma característica determinada pelo meio utilizado para a execução da comunicação. Neste aspecto, este meio representa as tecnologias utilizadas para prover a comunicação e se dividem em categorias, denominadas Classes de Transmissão. Os Quadros 2 e 3 apresentam, respectivamente, as classes de transmissões convencionais e as apoiadas por softwares, denominadas groupwares:
Tipo Descrição Sincronismo
Reuniões presenciais
Reuniões nas quais pessoas ocupam o mesmo espaço físico
ao mesmo tempo. Síncrona
Reunião distribuída
Reuniões nas quais os participantes estão fisicamente distantes uns dos outros e usam como suporte, sistemas analógicos de comunicação telefonia ou sistema convencional de vídeo conferência.
Síncrona
Correspondência Cartas e malotes (físicos). Assíncrona
Tipo Descrição Sincronismo
Reunião distribuída
Nesta os participantes estão fisicamente distantes, como nos sistemas de conferências por áudio ou vídeo conferência convencional. Porém difere da reunião distribuída convencional por utilizar sistemas digitais de comunicação e, também, pelo fato das informações de áudio e vídeo se serem processadas por computador. Estas formas de reuniões também são suportadas por groupwares (GoogleTalk, FaceTalk, Skype, Adobe Connect e etc).
Síncrona
Mensagens instantâneas
Aplicativos que apoiam mensagens que são enviadas em
tempo real de forma virtual. Síncrona
Correio eletrônico Software que sustentam mensagens que são postadas e
armazenadas de forma virtual. Assíncrona
Sites de
relacionamentos
Local virtual no qual as mensagens são armazenadas
(Facebook, Orkut, Linkedin e etc). Assíncrona
Quadro 3 - Classe de transmissões apoiadas por groupwares
Paula Filho (2011) apresenta uma gama de groupwares e os chama de aplicativos de produtividade pessoal. Entre eles, inclui redes sociais como Twitter, Facebook e Linkedin, ainda, as Wikis, bibliotecas digitais como a Wikipédia ou aplicativos que permitem a criação destas bibliotecas e, por fim, os portais web e os seus serviços. Ainda, Paula Filho (2011), relaciona as possibilidades que os
groupwares, como tecnologia digital, oferecem e que, por vezes, acabam se
sobrepondo, de forma positiva, às características dos sistemas convencionais de comunicação. Este fato pode ser exemplificado por meio da possibilidade da geração, armazenamento e gestão, em tempo real, do material derivado da comunicação. Em um cenário como o DDS, no qual reuniões presenciais se tornam menos frequentes, devido a seus custos de forma geral (PERRY et al., 2002), há um aumento expressivo da necessidade de tecnologias que facilitem a comunicação entre os stakeholders e, por conseguinte, aumentem o nível de coordenação dos projetos (JIMÉNEZ; PIATTINI; VIZCAÍNO, 2009). Junior et al. (2012) afirma que esta comunicação pode ser utilizada para restabelecer a harmonia e a confiança entre os participantes no DDS, também ajuda a resolver questões das diversidades socioculturais, comuns em um ambiente que pode agregar pessoas de toda parte do mundo.
Ao se considerar o DDS sob a perspectiva de um ambiente necessariamente colaborativo (FUKS et al., 2008) e, em detrimento das dispersões geográficas e temporais, as atividades desenvolvidas neste ambiente podem sofrer interferências, decorrentes da qualidade da comunicação. Neste trabalho se definiu que a principal
classe de transmissões para o DDS é a apoiada por groupwares, apresentada por meio do Quadro 3. Ellis, Gibbs e Rein (1991) corroboram esta definição ao afirmarem que os groupwares são subprodutos dos CSCW1 e se tratam de softwares colaborativos, utilizados tanto por pequenos grupos de pessoas quanto por organizações.
Com base em seus experimentos, Ali Babar, Kitchenham e Jeffery (2006) propõem que sistemas groupwares permitem aos stakeholders participarem de atividades relacionadas ao desenvolvimento de software no DDS.
Em uma abordagem mais técnica sobre groupwares, ao se tratar de sua aplicabilidade, Gutwin, Penner e Schneider (2004) afirmam que os groupwares são meios de comunicação que reunem características muito relevantes para o desenvolvimento distribuído de software. Como a possibilidade de se configurar perfis de usuários, determinando restrições de acesso a conteúdos e, também, por existirem uma significativa quantidade deste tipo de software de uso gratuito. Isto possibilita que os stakeholders se tornem participantes em todas as conversas nas quais estão envolvidos.
A adoção das técnicas e tecnologias para se efetuar a comunicação no DDS, deve primar pelo esclarecimento dos participantes em conhecer além de seus respectivos, também os papéis dos outros colaboradores, tanto intra quanto inter grupos. Porém, as particularidades do DDS impõem muitos desafios relacionados à conscientização destes papéis e suas reais importâncias em projetos distribuídos (STEINMACHER; CHAVES; GEROSA, 2012). Entre estes desafios cita-se, como fator agravante, a volatilidade dos requisitos que, em um cenário global, carece de uma atenção maior da coordenação do projeto, afim não resultarem na perda de qualidade do software produzido (LEE; ESPINOSA; DELONE, 2013).
2.4 PROPÓSITOS PARA A COMUNICAÇÃO EM DDS
Nesta seção são abordadas as questões motivacionais para ocorrer comunicação no DDS, que neste trabalho chama-se de propósitos. Aqui definiu-se, _____________
1
Computer Supported Cooperative Work (CSCW): trabalho cooperativo auxiliado por computador.
por meio dos trabalhos apresentados, que a comunicação ocorre a fim de atender estes propósitos.
Ellis, Gibbs e Rein (1991) afirmam que o DDS é caracterizado como um ambiente colaborativo de trabalho; e Borghoff e Schlichter (2000) representam esta característica por meio de uma figura geométrica triangular convencionalmente chamado de Modelo 3C. Este modelo associa as 3 dimensões da colaboratividade definidas por Ellis, Gibbs e Rein (1991): comunicação, cooperação e coordenação. Borghoff e Schlichter (2000) explicam que, embora cada uma destas dimensões apresente um conjunto de atividades e características própria, existe uma interdependência entre elas. Compreende-se que a falha em qualquer uma implicará sobre o funcionamento das outras dimensões afetando o sistema colaborativo do ambiente.
Em uma visão taxionômica, cada C do modelo 3C descreve uma das três dimensões de colaboração. Fuks et al. (2008), por meio da Figura 2, apresenta uma adaptação do Modelo 3C de Borghoff e Schlichter (2000). Neste também são definidas as interdimensões de Borghoff e Schlichter (2000), porém nesta adaptação são agregados alguns propósitos como: conversa que visa ação, fluxo adaptativo de trabalho, sites em rede, espaço de mídia, calendário familiar e comando e controle. O Quadro 4 explica cada um dos propósitos de comunicação em ambientes de DDS (FUKS et al., 2008).
Figura 2 - Classificação das aplicações baseadas no modelo 3C Fonte: Fuks et al. (2008)
Propósitos Ações
Conversa que visa ação
Propicia as negociações das decisões enquanto ocorre a Comunicação entre os stakeholders; enquanto Coordenam, as pessoas resolvem os conflitos e organizam suas atividades evitando esforços desnecessários. A Cooperação é um trabalho conjunto dos stakeholders que gerem ou gerenciam objetos de cooperação em um espaço compartilhado. Durante a cooperação situações inesperadas podem ocorrer surgindo a necessidade de renegociar e tomar novas decisões. Isso pode exigir uma nova rodada de comunicação, também uma nova coordenação no intuito de acomodar rearranjar as atividades que serão realizadas durante a cooperação.
Fluxo adaptativo de trabalho
Possibilita aos stakeholders alterar algo relacionado ao fluxo de trabalho que estava preestabelecido.
Sites em rede
Redes sociais como Linkedin, Facebook e outras, nos quais os stakeholders colocam informações pessoais e profissionais em uma área comum. Quando alguém se interessa pelo perfil entra em contato e organizam atividades. Neste modelo também a possibilidade de se convidar novos membros.
Espaço de mídias
Definição dos meios de comunicação multimídia para gerar um ambiente para encontros de trabalho casuais e informais, gerenciados pelo protocolo social convencionado. Nesta modalidade pode-se citar o RAVE (Ravenscroft Audio Vídeo Environment) da EuroSPARC (www.europarc.org).
Calendário familiar
Manutenção do senso comum quanto às programações ajustadas em um ambiente colaborativo. Stakeholders podem ter interesses conflitantes ao ponto de tornar inútil um acordo feito anteriormente. A coordenação é mantida por meio de rotinas de verificação das atividades agendadas e negociação de atribuições, datas e horários e outras. Sempre que houver uma negociação o calendário é atualizado e as atividades e cronograma recomeçam.
Comando e controle
Supervisão do ambiente colaborativo a fim de manter a hegemonia e a harmonia. Para isso observa os fluxos de trabalho e produção.
Quadro 4 - Propósitos de comunicação em ambientes de DDS
Embora nesta seção mostrou-se a existência de propósitos bem definidos para a comunicação, cabe apontar que a relação destes propósitos pode ser mais ampla e especializada, à medida das necessidades do projeto.
2.5 TRABALHOS RELACIONADOS
Esta seção apresenta os trabalhos relacionados, bem como a metodologia de Mapeamento Sistemático, definida por Petersen et al. (2008), utilizada para fazer o levantamento destes.
2.5.1 Metodologia Utilizada para o Levantamento
Em seu trabalho Petersen et al. (2008) afirma que a metodologia Revisão Sistemática da literatura é inspirada nas pesquisas médicas e apresenta vantagens no uso desta forma de pesquisa como metodologia bem definida, que ajuda a reduzir vieses, conclusões mais generalizadas diante de uma quantidade maior de
situações e contextos; e a detecção de estudos individuais ou isolados por meio do estudo de meta-análises. Porém, Petersen et al. (2008) também afirma que, em detrimento das vantagens, este tipo metodologia apresenta como principal desvantagem o alto grau de esforço despendido nesta forma de pesquisar.
Em contrapartida à metodologia de Revisão Sistemática, Petersen et al. (2008) expõe a metodologia Mapeamento Sistemático, que tem como principal objetivo oferecer um entendimento geral de uma área de pesquisa, pra isso identifica quantitativa e qualitativamente o tipo de pesquisa bem como os resultados encontrados nela. Esta forma de pesquisa também apresenta, como objetivo secundário, outros locais que publicaram pesquisas da área.
Segundo Petersen et al. (2008), assim como a Revisão Sistemática, a forma de pesquisa Mapeamento Sistemático também é utilizada na medicina, mas pouco difundida na área da engenharia de software. Petersen et al. (2008) afirma que, da mesma maneira que a Revisão Sistemática, o Mapeamento Sistemático também gera artefatos passíveis de checagens e análises, contudo, segundo o autor, esta metodologia exige menor grau de esforço. A Figura 3 apresenta o processo de mapeamento sistemático definido por Petersen et al.(2008).
Figura 3 - Processo de mapeamento sistemático Fonte: Petersen et al. (2008)
Os quadros apresentados na Figura 3, separados pela linha pontilhada, parte superior da Figura, denotam as etapas do processo e os mostrados na parte inferior os resultados esperados com a execução de cada etapa. A setas verticais, têm o sentido partindo de uma etapa para um resultado, indicam os resultados esperados ao concluir determinada etapa. As setas diagonais, partindo dos resultados, indicam qual será a próxima etapa no processo. Segundo Petersen et al. (2008) estas etapas são primordiais para a execução do processo, pois cada etapa gera subsídios - resultados - para as posteriores e permitem a busca e triagem de
documentos relevantes. Exemplifica-se isso quando o processo determina a busca por palavras chaves em resumos de trabalhos e, também, a extração de dados que, ao final do processo, reproduzem o Mapa Sistemático. O Quadro 5, baseado no trabalho de Petersen et al. (2008), apresenta uma explanação sobre estas etapas e o Quadro 6, como cada etapa foi aplicada neste trabalho.
Etapas / Resultados Descrição Definição das Questões de Pesquisa/ Revisão de Escopo.
De acordo com os objetivos principais e secundários da metodologia de Mapeamento Sistemático, as questões de pesquisa devem ser construídas a fim de refletir, da mesma forma, a finalidade da pesquisa em todos os artefatos e locais. As questões também devem definir a amplitude da pesquisa.
Conduta de Pesquisa/ Todos os Documentos.
Consiste em escolher bases de dados, como periódicos, anais e conferências, confiáveis e relevantes à área da pesquisa. Também na construção de sequências de palavras chaves que se deseja encontrar e que contemplem as questões de pesquisa. A construção destas sequências pode contar com conectivos lógicos como "E", "OU" e outros
Triagem de Documentos/ Documentos relevantes.
Etapa na qual são definidos os critérios de relevância dos documentos para a pesquisa, a fim de incluí-los ou excluí-los. Pode-se citar, como exemplo, a exclusão de documentos que apresentem o foco principal da pesquisa apenas em seu resumo, sem tratar do assunto de maneira consistente.
Keywording (busca por palavras chaves) usando resumos/ Esquema de classificação.
Procura por palavras chaves em resumos de documentos com o intuito de reduzir esforço para construção do Esquema de Classificação (vide Figura 4) e garantir a relevância dos documentos. Segundo Petersen et al. (2008), esta etapa pode ser executada em duas fases:
a) leitura dos resumos em busca de palavras chaves relevantes para a pesquisa e procura-se identificar o contexto do assunto apresentado no documento, a fim de relacioná-lo com o que se procura.
b) caso os resumos dos documentos indiquem uma relevância, porém não apresentem qualidade aceitável pode-se ler outras seções do documento como introdução ou conclusão.
Extração de dados e Mapeamento de Processos/ Mapa Sistemático.
Ao ter-se o esquema de classificação (vide Figura 4) bem definido, ao ponto de se conseguir classificar os documentos, faz-se a efetiva extração dos dados, gerando o Mapa Sistemático. Pode-se perceber um processo recursivo durante a construção do esquema de classificação (vide Figura 4). Esta recursividade permite um refinamento por meio de adição de novas categorias de documentos, ou, ainda, a cisão ou fusão das categorias existentes no esquema.
Quadro 5 - Etapas do Mapeamento Sistemático
Figura 4 - Construção do esquema de classificação Fonte: Petersen et al. (2008)
O Quadro 6 demonstra a aplicação da metodologia Mapeamento Sistemático: Etapas / Resultados Descrição Definição das Questões de Pesquisa/ Revisão de Escopo.
Questão de Pesquisa: Existe um protocolo de comunicação para projetos distribuídos de software?
Conduta de Pesquisa/ Todos os Documentos.
Ao escolher as bases de dados para pesquisas considerou-se a natureza técnica do assunto e buscou-se documentos em periódicos e anais de eventos, armazenados em bases de dados referenciadas pela comunidade acadêmica e, portanto, fidedignas e relacionados à área da engenharia de software.
Também desconsiderou-se sites que ofereciam "motores de busca" sem bases de dados próprias, como:
a) Web of Science: disponível em: <http://apps.webofknowledge.com>. Acesso em: 01/07/2015; e
b) Google Acadêmico: disponível em: <https://scholar.google.com.br/>. Acesso em: 01/07/2015.
Optou-se pelas bases de dois sites:
a) IEEE: disponível em: <http://ieeexplore.ieee.org/>. Acesso em: 01/07/2015; b) ACM: disponível em: <http://dl.acm.org/>. Acesso em: 01/07/2015.
Ao considerar-se as possíveis construção das sequências de palavras percebeu-se que a amplitude da busca, necessária para este trabalho, poderia ser alcançada em uma única construção utilizando o conectivo lógicos "E":
"Distributed Software Development" and protocol and communication
Triagem de Documentos/ Documentos relevantes.
Para determinar a relevância dos documentos utilizou-se dois filtros de classificação, existentes nos sistemas de busca dos sites utilizados como base de dados:
a) por relevância; e b) mais citados.
Após aplicação dos filtros foram considerados os 3 primeiros colocados em suas seleções. Além dos filtros também considerou-se se o documento foi publicado em periódicos ou anais da área de DDS.
Keywording (busca por palavras chaves) usando resumos/ Esquema de classificação.
Neste item fez-se uma adaptação do seu equivalente, apresentado no Quadro 5. A busca por palavras chaves nos documentos fez-se a partir da leitura na seguinte ordem:
a) Título; b) Resumo; c) Introdução; d) Resultados; e e) Conclusão.
A necessidade da leitura dos itens "c", "d" e "e" se deu quando os itens "a" e "b" apontavam como trabalho relevante à pesquisa, porém não apresentava com clareza os pontos que interessavam.
Extração de dados e Mapeamento de Processos/ Mapa Sistemático.
De acordo com seu item equivalente no Quadro 5. Os Quadros 7 e 8, resultantes do processo de classificação de documentos, apresentam de maneira estratificada o Mapa Sistemático.
Fonte: IEEE
String de busca: "Distributed Software Development" and protocol and communication Filtro do sistema de busca do site: mais relevantes
Citação DOI / ISBN Título
(DE FARIAS JUNIOR; DE MOURA;
MARCZAK, 2013)
10.1109/ICGSEW.2013.18
Towards a Communication Maturity Model for Distributed Software Development
(CONG; KANG, 2014) 10.1109/ICGSE.2014.28 The Effects of Continuous Awareness on Distributed Software Development (PRIPUZIC;
GJENERO; BELANI, 2006)
10.1109/SOFTCOM.2006.329764 Improving Virtual Team Communication
Filtro do sistema de busca do site: mais citados
Citação DOI / ISBN Título
(BEECHAM et al.,
2010) 10.1109/ICGSE.2010.15
Crafting a Global Teaming Model for Architectural Knowledge
(PRIPUZIC;
GJENERO; BELANI, 2006)
10.1109/SOFTCOM.2006.329764 Improving Virtual Team Communication
(CONG; KANG, 2014) 10.1109/ICGSE.2014.28 The Effects of Continuous Awareness on Distributed Software Development
Quadro 7 - Resultados da busca no site da IEEE
Fonte: ACM
String de busca: "Distributed Software Development" and protocol and communication Filtro do sistema de busca do site: mais relevantes
Citação DOI / ISBN Título
(STOL; FITZGERALD, 2014)
10.1145/2568225.2568249
Two’s Company, Three’s a Crowd: A Case Study of Crowdsourcing Software Development
(ESBENSEN;
BJØRN, 2014) 10.1145/2660398.2660413
Routine and Standardization in Global Software Development
(HOSSAIN; BANNERMAN; JEFFERY, 2011)
10.1145/1987875.1987894
Towards an Understanding of Tailoring Scrum in Global Software Development: A Multi-case Study
Filtro do sistema de busca do site: mais citados
Citação DOI / ISBN Título
(HERBSLEB, 2007) 10.1109/FOSE.2007.11 Global Software Engineering: The Future of Socio-technical Coordination
(FROEHLICH;
DOURISH, 2004) 0-7695-2163-0
Unifying Artifacts and Activities in a Visual Tool for Distributed Software
Development Teams (HERBSLEB;
PAULISH; BASS, 2005)
10.1145/1062455.1062550 Global Software Development at
Siemens: Experience from Nine Projects
Quadro 8 - Resultados da busca no site da ACM
Embora os trabalhos relevantes relacionados, vide Quadros 7 e 8, apresentem constructos comuns, como o ambiente do DDS, suas vantagens e desvantagens peculiares, nenhum destes propõe uma ferramenta que possa, de forma genérica, ser aplicada a projetos de DDS para estruturar a comunicação a fim
de aumentar o grau de cooperação entre os stakeholders e a coordenação do projeto. Este fato é corroborado pelo PMBOK (2008) ao determinar os tipos de processos para comunicação, porém não definindo, de forma específica, os meios para isto. Tal fato indica que ainda existe um viés no DDS que persiste e deve se investigado e tratado. Contudo, acredita-se que a proposta deste trabalho é pertinente ao apresentar um protocolo de comunicação que busca estruturar a comunicação, com a expectativa que isto reflita positivamente em todo o processo de DDS.
3 PROTOCOLO DE COMUNICAÇÃO EM DDS
Neste capítulo são abordadas as definições dos conceitos sobre protocolo. Também é apresentada a proposta da estruturação que constitui o objeto de aplicação da pesquisa deste trabalho.
3.1 PROTOCOLO DE COMUNICAÇÃO
Neste projeto a ideia é identificar como a comunicação em projetos de DDS pode ser estruturada. Neste contexto esta estrutura de comunicação é chamada de protocolo. Este conceito de protocolo de comunicação advém da área de redes de computadores e sistemas multi-agentes, que é definido como um conjunto de regras utilizadas para que seja possível ocorrer uma comunicação, ou seja, um acordo entre as partes que devem se comunicar (ABDULLAH; MENASCÉ, 2013; TANENBAUM, 2003).
Análogo a teoria da segmentação arquitetônica em camadas, presente na área de redes de computadores, este trabalho, procura identificar se existem componentes de comunicação, estruturados em níveis, durante a execução de um projeto. A estruturação em níveis presentes nas redes de computadores, viabilizam o tratamento isolado e específico dos problemas de cada camada que consequentemente resulta em otimizações relacionadas às questões de gerenciamento.
Neste sentido os problemas relativos a uma determinada camada são tratados por ferramentas, técnicas e até mesmo por profissionais específicos e especializados. Na área de redes de computadores é possível a existência, em um mesmo ambiente de profissionais diferentes que lidam com as camadas física, enlace, rede e aplicações (SOULÉ et al., 2013).
3.2 ESTRUTURAÇÃO DO PROTOCOLO DE COMUNICAÇÃO
Nos projetos de pesquisa já realizados (GONCALVES et al., 2013) conseguiu-se definir a possibilidade de mapear a comunicação existente em um ambiente de DDS, classificá-la em níveis e identificar sua quantidade e qualidade em ambientes de desenvolvimento distribuído de softwares (vide Quadro 9, desta seção). Estes estudos concluem que se pode investigar, mapear e classificar a comunicação em um ambiente de DDS e, em decorrência disto, é possível compor uma estruturação que permite a definição do processo de comunicação que um projeto de DDS adota, ou ainda uma intervenção no processo de comunicação, caso ele já esteja instalado, no sentido de investigar, mapear, classificar e adequar esta comunicação com as características do projeto (GONCALVES et al., 2014).
O amparo gerado nas pesquisas de Deus, Goncalves e L’Erario (2013); Duarte et al.(2014); Goncalves; Dos Santos; L’Erario (2013); Goncalves et al.(2013, 2014) e Ponqueli Contó et al. (2013), apresentadas no Anexo I, norteou a organização e permeou indícios de que um protocolo de comunicação em projetos de DDS possa ser segmentado em elementos. Tais elementos são distribuídos em níveis e a proposta de sua organização está explicita na Figura 5.
A Figura 5, apresenta a estruturação do protocolo de comunicação em 3 níveis: sendo que o primeiro trata-se do propósito, o segundo da classe de transmissão e, o terceiro nível, representa a execução da comunicação em vias de fato.
A camada de propósito, indicado na pelo item 1 da Figura 5, associa um conjunto de tipos de intervenções que podem ser executadas durante um projeto. Os tipos de intervenções foram baseados nas atividades definidas por Fuks et al. (2008) para a geração da conscientização sobre os papeis dos stakeholders e o andamento de projeto em um ambiente colaborativo, descritos neste trabalho no capítulo 2, Figura 2 e descritos no Quadro 4, do mesmo capítulo.
Figura 5 - Protocolo de comunicação em DDS
Na camada denominada classes de transmissão, camada 2 da Figura 5, são resolvidas questões tecnológicas sobre a comunicação nos projetos. Esta camada é provida de informações advindas da camada de propósito, sua camada anterior. Ainda nesta camada são consideradas as dispersões temporais e geográficas para escolha do tipo de comunicação, que poderá ser síncrona ou assíncrona. Um dos critérios para a escolha de um destes tipos é a dispersão temporal. Caso esta não influencie demasiadamente os horários de trabalhos dos sites envolvidos, a comunicação pode ser síncrona, entretanto caso a dispersão temporal afete os horários das atividades dos sites a escolha tende a ser do tipo assíncrona.
Na camada de execução, item 3 da Figura 5, a comunicação efetivamente acontece. Nela são relacionados os sites existentes no projeto e as comunicações são executadas, quantificadas e classificadas.
Ainda na camada 3 da Figura 5, estão presentes os mecanismos de mensuração da comunicação que compreendem um conjunto de tarefas baseadas nos estudos realizado por Goncalves, Dos Santos e L´Erario (2013); e Goncalves et al. (2013), que têm por finalidade classificar, quantificar e qualificar a comunicação entre os sites. Em um de seus trabalhos, que tem como questão de pesquisa: "É possível classificar a comunicação em um ambiente de DDS?", Goncalves et al. (2013) apresenta uma estrutura gradativa de 5 níveis que visa mensurar a comunicação em ambientes de DDS. Para tanto, neste trabalho, Goncalves et al.
(2013) considera um cenário onde há comunicação entre 2 sites e apresenta a estrutura simulando esta comunicação entre eles. A Figura 6 apresenta esta situação:
Figura 6 - Comunicação entre sites Fonte: Goncalves et al. (2013)
O processo de avaliação do nível é baseado no artefato de trabalho resultante desta interação. Este processo é ilustrado por meio da Figura 7:
Figura 7 - Comunicação entre sites Fonte: Goncalves et al. (2013)