Métricas e Indicadores para Auxiliar na Distribuição das Etapas do Processo de Desenvolvimento Distribuído de Software: Uma Revisão Sistemática

Métricas e Indicadores para Auxiliar na Distribuição

das Etapas do Processo de Desenvolvimento

Distribuído de Software: Uma Revisão Sistemática

Euclides Alfredo Matusse

Programa de Pós-Graduação em Ciência da Computação Universidade Estadual de Maringá - UEM

Maringá, Brasil ematusse27@gmail.com

Elisa H. M. Huzita,Tania F. C. Tait

Universidade Estadual de Maringá - UEM Maringá, Brasil

{emhuzita, tait}@din.uem.br

Abstract— The use of indicators provides several benefits among which the effective evaluation of process optimization in Software Development and also supporting the project manager in making strategic decisions. Despite the importance of using metrics in the distribution of the process steps in Distributed Software Development (DSD) given the diversity of existing business model, organizations have neglected their practice. Reasons for this include: (i) processes are poorly defined and controlled and are not mature enough to make use of measurements and (ii) there are no standards for metrics and therefore support is limited to tools for data collection and analysis data. In this context, this paper aims to conduct a systematic review to gather evidence about the existence of metrics and indicators that are specific to development software distributed.

Keywords-Distributed Software Development; indicators; metrics; process; systematic review.

Resumo— O uso de indicadores proporciona diversos benefícios

dentre os quais a avaliação eficaz da otimização de processos no Desenvolvimento de Software e, também, o apoio ao gerente de projeto na tomada de decisões estratégicas. Apesar da relevância da utilização de métricas na distribuição das etapas do processos no Desenvolvimento Distribuído de Software (DDS) dada à diversidade de modelo de negócios existentes, as organizações têm negligenciado a sua prática. Razões para esse fato incluem: (i) processos são precariamente definidos e controlados e não são suficientemente maduros para fazer uso de medições e (ii) não existem padrões para métricas e, por isso, um apoio é limitado a ferramentas para coleta e análise de dados. Nesse contexto, este artigo tem como objetivo realizar uma revisão sistemática para coletar evidências sobre a existência de métricas e indicadores que são específicos de desenvolvimento distribuído de software.

Palavras-chave – Desenvolvimento Distribuído de Software; indicadores; métricas; processo; revisão sistemática.

I. INTRODUÇÃO

O Desenvolvimento Distribuído de Software (DDS) tem tido um impacto significativo no desenvolvimento de software, e grandes empresas tem adotado o DDS [1] [2] distribuindo os seus processos ao redor do mundo [3]. No DDS, as equipes

estão geralmente separadas por fusos horários diferentes [4], e os recursos dispersos em várias localidade geográficas [5]. Esta estratégia possibilita vários benefícios tais como proximidade de mercados e acesso ao conhecimento local sobre os clientes [6], flexibilidade para responder às oportunidades locais [7] e maior disponibilidade de recursos humanos a um custo menor [8] [9]. Porém, para atingir tais benefícios, é necessário a execução de um planejamento rigoroso, pois os riscos advindos dessa estratégia podem afetar a comunicação, coordenação e controle de projetos [10]. No entanto, a natureza dinâmica do DDS, impõe uma série de desafios causados pela distância temporal, a distância geográfica e sócio cultural. Esses desafios foram classificados como técnicos, não técnicos, e híbridos [10]. Fatores técnicos estão relacionados com o conhecimento técnico de desenvolvimento de software [11]; desafios não-técnicos estão relacionados com fatores sociais e culturais [12] [11] a comunicação [13] e, diferença de fusos horários [13] e fatores híbridos são desafios que se relacionam com uma combinação de desafios técnicos e não técnicos.

Apesar de os termos métricas e indicadores serem frequentemente usadas alternadamente, é importante notar as diferenças sutis entre eles, pois existe uma sequencia lógica na forma que os indicadores são obtidos [45]: métrica é a correlação de medidas individuais com o objetivo de se ter uma idéia da eficácia da entidade que está a ser medida e, indicador é a combinação de métricas que podem ser utilizadas para se ter uma compreensão da entidade a ser medida.

No planejamento, a distribuição de processos em DDS se configura como uma importante decisão e, dependendo da estratégia de negócio adotada [14], pode otimizar ganhos de eficiência das equipes de desenvolvimento em várias localidades geográficas com a redução de esforços e aumento de produtividade [6]. Nesse sentido, é importante oferecer às organizações apoio que permitam uma análise de critérios que possam guiá-los por meio de indicadores que apoiem no entendimento da distribuição sistemática das etapas do processo de software a equipes geograficamente dispersas, considerando-se as características da dispersão geográfica e temporal [15].

Diante desses desafios visando dar suporte à distribuição das etapas do processos de software a equipes em várias

localidades geográficas, realizou-se a condução da revisão sistemática de soluções existentes na literatura, que permitiu identificar as abordagens e modelos de alocação das etapas do processo às equipes em várias localidades geográficas em projetos de DDS e analisar as suas particularidades. Assim, o presente artigo objetiva apresentar e analisar os resultados desta revisão, considerando os aspectos técnicos, não-técnicos, e híbridos de cada abordagem.

O trabalho está organizado da seguinte forma: a Seção 2 apresenta uma caracterização da distribuição das etapas do processo de software em projetos de DDS; na Seção 3 é descrita a metodologia da revisão e sua utilização no presente estudo; na Seção 4 são apresentados os resultados do estudo: os mapas das questões e as soluções identificadas a partir desta literatura; a Seção 5 analisa as abordagens identificadas, comparando suas características; na Seção 6 apresentam-se as conclusões, e, por fim discorre sobre as oportunidades de trabalhos futuros e as referências bibliograficas.

II. DISTRIBUIÇÃO DAS ETAPAS DO PROCESSOS DE SOFTWARE EM PROJETOS DE DDS

A distribuição das etapas do processo de software em projetos de DDS consiste em alocar as etapas do processo às equipes em várias localidades geográficas para execução das atividades, tarefas e recursos inerentes ao processo de um determinado projeto. O objetivo é prever e avaliar como os aspectos do comportamento humano, comunicação, e fatores não técnicos afetam a qualidade na distribuição das etapas do processo a membros da equipe em projetos geograficamente distribuídos. Esta definição deve basear-se nos objetivos de negócio das organizações respondendo à seguinte questão: “Quem deve fazer isso?” [16]. O estudo da distribuição de processo em ambiente distribuído (físico e temporal) continua sendo um desafio à comunidade de engenharia de software, por influenciar significativamente na qualidade de software determinado pelo modelo de negócio no DDS [17]. A arquitetura de software diminui o esforço de alocação de processos à equipes em várias localidades geográficas por se basear no princípio de modularidade e possuir os critérios fundamentais de um software que são: o acoplamento e coesão (organização modular) [18]. Acoplamento é a medida da interconexão entre os módulos em uma estrutura de software; e coesão está relacionada com a medida pela qual um módulo realiza uma tarefa funcional bem definida [19]. Buscando-se uma representação que define o nível da distribuição das etapas do processo de software, a Figura ilustra o cenário (distribuição das etapas do processo de software às equipes distribuídas) e a relação entre eles, considerando a distância geográfica das equipes, atores (stakeholders) genéricos.

A representação das equipes completas são compostas por membros localizados em três lugares diferentes (ressalve a equipe III e IV localizados no mesmo pais, embora em espaço físico diferente) para produzir software em configurações globais. Assim, cada equipe é responsável por uma etapa do processo e/ou atividades, tarefas que compõe um subsistema: a equipe I é responsável pela etapa do processo I e parte das atividades das etapas II e III do processo; a equipe II é responsável pela etapa do processo III e parte das atividades das etapas do processo II; a equipe III é responsável pela etapa

do processo II e parte das atividades das etapas do processo I e, por fim, a equipe IV, gerente global tem uma visão geral das regras do negócio do subsistema do projeto a ser implementado e a competência de reatribuir as etapas do processo, atividades e tarefas do subsistema. Os gerentes de projeto estão preocupados com as etapas inicias do projeto por envolver as regras de negócio aliado à descrição funcional do sistema, que são: especificação de requisitos, que se refere à extração dos requisitos de um desejado produto de software e projeto de sistema (especificação), envolve a tradução destes requisitos em uma descrição de todos os componentes necessários para codificar o sistema.

Figure 1. Visão do nível de distribuição/ processo no DDS Dessa forma, observa-se que identificar e distribuir as etapas do processo de software às equipes geograficamente dispersas com critério adequado não é uma solução trivial. È necessário, levar em consideração algumas particularidades que vão além das questões técnicas, que não podem ser ignoradas, tais como a confiança [20] [32], distância geográfica [21], a gestão da diversidade cultural [22], diferentes fusos horários [4] e sócio-cultural [23]. Em projetos de DDS, características especificas da socialização devem ser medidas e avaliadas, servindo como um filtro para encontrar boas soluções [24].

III. PROCESSO DA REVISÃO SISTEMÁTICA

Revisão sistemática da literatura surge como um meio de avaliar e interpretar todas as pesquisas disponíveis relevantes para uma questão de pesquisa particular, área temática, ou fenômeno de interesse com certo valor científico [25]. A revisão sistemática pretende apresentar uma justa avaliação de um tópico de investigação, usando uma metodologia confiável, rigorosa e auditável [25]. Assim, o objetivo dessa revisão é identificar as soluções existentes para apoiar os gerentes de projetos e portfólio na distribuição das etapas do processo de software às equipes geograficamente distribuídas em projetos de DDS. A avaliação da qualidade dos estudos foi classificada de acordo com a proposta em Dyba e Dingsoyr [27].

A. Definição das questões de pesquisa

A formulação das questões e strings de pesquisa apresentada é adaptada de Santos [28] inclui os elementos definidos a seguir:

• População (population): qual conjunto de elementos será alvo da revisão. Trabalhos que discutem a combinação de técnicas para distribuir as etapas do processo de software em DDS; avaliação e recomendações da avaliação utilizando métricas e indicadores;

• Intervenção (intervention): o que será avaliado neste conjunto de elementos da população. Trata-se das abordagens técnicas e métodos de avaliação da distribuição das etapas do processo de software em projetos de DDS;

• Comparação (comparison): elementos que servirão como base de comparação, considerando as similaridades de objetivos, apresentada na Seção 5;

• Resultado (outcomes): informações de saída esperadas com a pesquisa. Estudo comparativo das abordagens e análise dos métodos utilizados na distribuição das etapas do processo de software direcionado à investigação das limitações e potencialidade das abordagens de avaliação existentes.

Buscando direcionar esforços durante a execução e compreensão do estado das pesquisas sobre questões relacionadas com métricas e indicadores para apoio no entendimento da distribuição das etapas do processo de software à equipes em várias localidades geográficas em projetos de DDS, as seguintes questões de investigação conduziram este estudo:

Q1: Baseado nas evidências encontradas, que informação é

utilizada para medir a distribuição das etapas do processo de software às equipes geograficamente distribuidas?

Q2: Que métodos de pesquisa empírica são usados?

Q3: Quais os tipos de contribuição para a investigação são

encontrados?

B. Descrição das estratégias de busca

A pesquisa bibliográfica consistiu em duas etapas. No estágio 1, foram pesquisadas bases de dados eletrônicas com as palavras-chave que norteiam a pesquisa para responder às questões. As strings de busca foram geradas a partir da combinação dos termos chave e sinônimos usando OR (ou) e AND (e), e possíveis peculiaridades das bibliotecas digitais e adaptações a serem registradas. Portanto, a busca foi feita no idioma inglês, através da combinação dos sinônimos definidos na Tabela I. Assim os estudos foram obtidos a partir das seguintes fontes:

− IEEE Xplore (http://ieeexplore.ieee.org/) − ACM Digital Library (http://portal.acm.org) − Elsevier ScienceDirect (www.sciencedirect.com) − Google Scholar (http://scholar.google.com) − CITESEERX (http://citeseer.ist.psu.edu/index) − Compendex EI (http://www.engineeringvillage2.org)

No segundo estágio, realizou-se uma condução manual em workshop de WDDS, SBQS (Simpósio Brasileiro de Qualidade de Software). SBES (Simpósio Brasileiro de Engenharia de Software) e Evento ICEIS (International Conference on Enterprise Information Systems) com a finalidade de encontrar artigos relevantes às pesquisas publicadas entre 2004 e 2011. É importante destacar a busca por artigos no workshop WDDS, SBQS, SBES para saber o estágio da evolução e suas abordagens. Estes são eventos importantes da área no Brasil. Os eventos têm mantido um bom número de artigos submetidos e apresentados, o que tem acentuado significativamente a presença de pesquisadores estrangeiros, por artigos serem recentemente indexados nas bibliotecas digitais da área [46]. Nesses casos específicos, a busca dos artigos será conduzida em português e inglês de forma a cobrir o maior número de artigos relevantes a responder às questões de pesquisa. Os tipos de documentos selecionados com base em consultas com especialistas estão representados na Tabela II.

TABELA I.PALAVRAS-CHAVES UTILIZADAS NO ESTUDO

String

População “distributed software development” OR “global software development” OR “geographically distributed software development” OR “globally distributed development” OR “collaborative software engineering” OR “collaborative software development” OR “globally distributed work” OR “global Software engineering” OR “ distributed team” OR “global software teams” OR “offshore software development” OR “offshoring” OR “offshore” OR “offshore outsourcing” OR “dispersed team”

Intervenção “process” OR “process distribution” Resultados "metric" OR "indicator"

Estratégia de Busca: População AND Intervenção AND Resultado

TABELA II.WORKSHOP, SIMPÓSIOS E EVENTOS

Tipo Fonte Sigla

Workshop Workshop Desesvolvimento Distribuído de Softwre WDDS Simpósio

SimpósioBrasileiro Qualidade Software SBQS SimpósioBrasileiro Engenharia de Software SBES Eventos International Conference on Enterprise Information

Systems

ICEIS

C. Critério de seleção de estudos

A busca inicial de artigos retorna uma grande quantidade de estudos que não são relevantes [25]. Assim, critérios de inclusão [I] e exclusão [E] devem ser baseados na pesquisa tendo relação com o tópico tratado. Por conseguinte, estudos totalmente irrelevantes são descartados no início. A inclusão do documento é determinada pela relevância em relação às questões de investigação pela análise do título, resumo, palavras–chave, introdução e conclusão. Artigos classificados como [I] são candidatos a tornar-se em estudo primário e artigos classificados

como [E] indicam artigos irrelevantes e descartados, baseado na análise do título, resumo não relacionados com métricas e indicadores para distribuição das etapas do processo de software no DDS. Segundo a classificação abaixo:

[I1]. Os trabalhos publicados devem se relacionar diretamente com métricas e indicadores para distribuição das etapas do processo de software e os estudos devem ter algum foco no contexto de DDS.

[I2]. Artigos que consistem em opiniões, recomendações da avaliação utilizando métricas e indicadores para apoio no entendimento da distribuição das etapas do processo no contexto de DDS.

[E1]. Estudos repetidos. Se o mesmo estiver disponível em diferentes fontes de busca, a primeira é considerada.

IV. RESULTADOS DO ESTUDO A. Visão geral dos estudos

A revisão foi conduzida no período de Fevereiro à Abril 2012, de acordo com o plano apresentado na Seção 3. A Figura 2 ilustra o percurso efetuado para os estudos encontrados no conjunto com a string de busca nas fontes utilizadas e pesquisa manual.

Figure 2. Filtro de pesquisa e escolha dos estudos primários O procedimento de busca produziu 279 estudos iniciais. Destes 266 não foram repetidos, 45 destes foram selecionados por serem relevantes, e 12 foram selecionados como estudos primários (a lista completa de estudos primários selecionados para análise é mostrada no apêndice A). Após o filtro inicial (seleção preliminar), 45 artigos foram pré-selecionados para identificar os potenciais estudos primários mediante a leitura do título, resumo e conclusão. A partir da seleção, obteve-se um novo subconjunto pelo critério de leitura em profundidade mediante a leitura total do artigo. Permaneceram aqueles que apresentavam informações consistentes acerca de métricas e indicadores para distribuição das etapas do processo de software à equipes em várias localidades geográficas em DDS. Neste segundo passo (seleção final) 12 artigos foram selecionados para uma análise comparativa detalhada (Tabela X).

Estudos sobre métricas em projetos de DDS tem aumentado nos últimos anos, particularmente a partir de 2006. O número de

publicações em 2012 é provável que seja discreto, uma vez que os dados foram coletados em abril de 2012. A Tabela III mostra a frequência de publicação dos trabalhos selecionados a partir de 2004 até 2012.

TABELA III.TENDÊNCIA DE PUBLICAÇÃO (POR ANO)

Ano Porcentagem (%) Frequência

2004 0 0 2005 8 1 2006 17 2 2007 8 1 2008 8 1 2009 8 1 2010 8 1 2011 42 5 2012 0 0

A Figura 3 mapeia a fonte das publicações, a maioria dos estudos são de workshops (50%). A distribuição está da seguinte forma: Journal (21%), conferências (21%), e Simpósios (7%).

Figure 3. Publicação por tipo de fonte B. Classificação de estudos

O processo de extração de informações realizou-se à partir do foco de estudos apresentados na Tabela IV. Assim, foi estabelecida uma categorização entre objetivo e subjetividade dos resultados. Os artigos revelaram problemas ou soluções, onde 25% tratam sobre alocação de tarefas e 8% aborda sobre configuração das etapas do processo de DDS, o foco de 42% sobre estratégias para resolver problemas de alocação de equipes geograficamente distribuídas, 8% práticas para orientar a definição do processo de software global e questões de destaque 8% sobre evidências para propor soluções da utilização de métricas para as questões da pesquisa.

Dessa forma, seguiu-se a classificação de cada publicação de acordo com a configuração do estudo: industrial, acadêmico ou misto conforme apresentada na Tabela V, quase 58% dos estudos são industriais, 25% são acadêmicas, e 17% estão no cenários do estudo misto.

TABELA IV.FOCO DE ESTUDO

Resultados do artigo Percentual (%) Frequência

Questões 17 2

Misto 25 3

Estratégias 58 7

TABELA V.DISTRIBUIÇÃO DE ESTUDOS

Configuraçao do estudo Percentual (%) Frequência

Industrial 58 7

Acadêmico 25 3

Misto 17 2

C. Baseado nas evidências encontradas, que informação é utilizada para medir a distribuição das etapas do processo de software às equipes geograficamente distribuídas? (Q1) Nos estudos primários realizados e, também, da literatura corrente foram identificadas algumas métricas, e critérios de alocação de tarefas nas Tabela VI e VII respectivamente.. Por exemplo, no trabalho de Jalote [33] utilizam fatores como período de trabalho e habilidade, tendo como características dependência entre as tarefas e esforço de execução, enquanto modelo de simulação GSD [34] [35] considera as etapas do processo de desenvolvimento, localização, fuso horários e meios de comunicação. Em um outro estudo Gotel [24] monitoram cinco equipes de estudantes, Camboja, EUA (New York City e Pleasantiville (Nova Iorque)), Tailândia e Índia para produção de software e percebem, de forma distinta, que os níveis de estresse dos estudantes, aumentam juntamente com os padrões de comunicação de cada equipe de desenvolvimento devido a falta de habilidades sociais necessárias. Gotel et al [24] concluirão que fatores de socialização das equipes dispersas e comunicação são capazes de influenciar o sucesso de programas de melhoria. No modelo proposto por Y. Lu [36], considera os fatores: pessoas, tarefas e tecnologias a partir da teoria da coordenação e sociotécnica. Na abordagem proposta por Varzin [37], um conjunto de praticas para orientar a definição de processo de software geograficamente distribuído, aborda os fatores de infraestrutura de comunicação, diferença de fusos horários, cultural, confiança e tamanho de equipe através da técnica de algoritmo de mineração tradicional. O estudo experimental de Ramasubbu [38], considera os fatores: dispersão geográfica, produtividade, qualidade e lucro por meio da técnica do modelo econométrico. Foram identificados alguns critérios consoante a classificação proposta por Lamersdorf [42] apresentadas na Tabela VII.

TABELA VI.MÉTRICAS IDENTIFICADAS

Métricas Autores Esforço para realizar tarefas de DDS [33]

Habilidade e recursos de requisitos requerido de DDS [33], [42] Quantidade de mensagens usando tecnologia de coordenação [24]

TABELA VII.CRITÉRIOS DE ALOCAÇÃO

Classificação Critérios Outsourcing Custo, confiança, perícia, proximidade a usuários,

contatos pessoais, relação estabelecida Desenvolvimento de

Software Personalizado

Perícia, disponibilidade, proximidade ao cliente, custo do trabalho, planejamento estratégico, razões pessoais, decisões políticas

Desenvolvimento de Software Padrão

Perícia, proximidade ao mercado, custos trabalhistas, diferenças cultural e temporal, taxa de rotatividade, disponibilidade, confiança pessoal, arquitetura do produto , maturidade site

Os dados presentes nas tabelas VI e VII mostram que ainda não existem definidos indicadores derivados da correlação entre as métricas.

D. Que métodos de pesquisa empírica são usados? (Q2) Os artigos foram classificados de acordo com o método utilizado por Tonella [30], que consiste em cinco métodos de pesquisa: 1) revisão sistemática (meio de avaliar e interpretar pesquisas existentes); 2) experimental (estudos que se aplicam para medir qualquer efeito e controles específicos); 3) estudo observacional; 4) relatos de experiência (registro de lições aprendidas e experiência industrial); e 5) estudo de caso (investigação de situações do mundo real). Embora o método de simulação não faça parte do método utilizado por Tonella [30], foi incluido na Tabela VIII por constar no método utilizado na pesquisa, nesta pesquisa, 42% foram de estudo experimetal; (25%) simulação; (8%) utilizou o método de estudo de caso; (8%) eram revisão sistemática; (8%) não são claros, e (8%) abordou relatos de experiência.

TABELA VIII.MÉTODO DE PESQUISA UTILIZADO

Método Pesquisa Frequência Porcentagem (%)

Experimental 5 42% Simulação 3 25% Estudo de Caso 1 8% Obscuro 1 8% Revisão Sistemática 1 8% Relato de Experiência 1 8%

E. Quais os tipos de contribuição para a investigação são encontrados? (Q3)

De acordo com a classificação desenvolvido para as necessidades de pesquisa em engenharia de software [29] , a Tabela IX ilustra a contribuição para a investigação primária dos estudos. Assim, a distribuição esta da seguinte forma 33% dos artigos tratam sobre proposta de solução; pesquisa de avaliação (50%); artigos de opinião (17%), e; não foi encontrado artigo de validação de investigação.

TABELA IX. CONTRIBUIÇÃO TIPOS DE PESQUISA

Tipo de Pesquisa Frequência Porcentagem (%)

Proposta de solução 4 33%

Pesquisa de validação 0 0

Pesquisa de avaliação 6 50%

Pesquisa de opinião 2 17%

V. ANÁLISE DE SOLUÇÕES EXISTENTES PARA O APOIO À DISTRIBUIÇÃO DAS ETAPAS DO PROCESSO ÀS EQUIPES

DISPERSAS EM DDS

Durante a extração de dados, não foi possível identificar a distribuição das etapas do processo às equipes dispersas a nível global, mas utilizou-se critérios de execução das atividades, tarefas e recursos inerentes ao processo que compõe um determinado projeto. O processo é um arcabouço para as

tarefas que são necessárias para construir software de qualidade, facilitando a coordenação e acompanhamento das atividades [31]. Baseado na suposição de que existe uma relação entre a natureza das tarefas que compõe o processo e a natureza da distribuição das equipes de desenvolvimento dispersos geograficamente, foram incluídos no estudo os modelos de alocação de tarefas [39] [40] e análise de desempenho das equipes distribuídas globalmente [38], buscando produtividade de projetos. A classificação do desenvolvimento distribuído interfere na característica da alocação de tarefas, equipes e recursos em projetos de DDS. No entanto, observa-se que no trabalho de Lamersdorf [42], foram identificados e analisados os tipos de classificação que se referem à terceirização, desenvolvimento de software padrão e desenvolvimento de software personalizado [42]. A Tabela X, apresenta as principais características dos modelos identificados.

TABELA X.MODELOS PROPOSTOS E IDENTIFICADOS DURANTE A REVISÃO SISTEMÁTICA

Modelo de distribuição Artigos relacionados

Método de pesquisa Técnicas Características Tipo pesquisa

Modelo para o desenvolvimento 24 horas:O modelo considera um GAD (Grafo Acíclico Direcionado), onde os vértices representam as tarefas e as arestas representam as dependências operacionais existentes (tarefas com restrições de precedência). Este modelo realiza a alocação buscando a redução na duração do projeto.

Jalote e Jain (2006) Simulação Método do Caminho

Crítico Esforço para execução de tarefas, dependências

entre tarefas, habilidades requeridas e

recursos requeridos

Nível de alocação: membros de uma equipe; Fatores considerados: habilidades; período de trabalho

Conjunto de práticas para orientar a definição de processos de software global em ambientes geograficamente distribuídos.

O modelo identifica e analisa os aspectos que impactam na sua execução Vanzin et al,. (2005) Survey, pesquisa exploratória algoritmo mineração tradicional Habilidades e conhecimentos do processo.

Nível de alocação: locais distribuídos. Fatores considerados:

infraestrutura de comunicação, estrutura organizacional, confiança da equipe, diferenças fusos horários, cultural e tamanho da equipe.

Modelo alocação de equipes de desenvolvimento para módulos de software, detalhando os atributos utilizados na análise não técnica e como eles são obtidos. Este modelo captura os aspectos não-técnicos das equipes distribuídas e as dependências entre módulos de software. Ribeiro et al.(2011) Santos et al, (2011) Estudo teórico, Estudo experimental Algoritmos genéticos Lógica Nebulosa Habilidades de aspectos não-técnicos das equipes distribuídas e dependências entre módulos de software.

Nível de alocação: locais distribuídos; Fatores considerados: temporal, cultural e de afinidade das equipes.

Modelo de simulação GSD

(Global Software Development): O modelo

configura seus processos com diferentes etapas e estratégias de alocação, permitindo identificar a melhor alternativa quanto às estratégias de alocação. Este modelo fornece informações relacionadas à produtividade, recursos Setamanit et al,. (2006) Setamanit et al. (2007)

Simulação Simulação - Nível de alocação: locais

remotos; Fatores considerados: etapas do processo de desenvolvimento; atividades desenvolvidas; estratégia de alocação; fuso horário; localização; meios de comunicação.

alocados, comunicação e coordenação durante o projeto. Estudo alocação de tarefas em projetos de Desenvolvimento Distribuído de Software: Análise das Soluções Existentes

Marques et al.(2011)

Mapeamento sistemático

Coleta de evidências - Nível de alocação: híbridos (remoto e distribuído)

Estudo para identificar os critérios que são utilizados na prática de atribuição de tarefas a equipes distribuídas. Este modelo é baseado em entrevistas com gerentes selecionado das organizações e critérios atualmente aplicados na indústria são identificados.

Lamersdorf et al,(2009) Survey, Estudo qualitativo, Relato de Experiência Método de comparação constante Habilidades técnica e de aspectos de coordenação

Nível de alocação: locais híbridos (remoto e distribuído)

Modelo para apoiar o processo de gerenciamento de defeitos que inclui a prevenção de defeitos, descoberta, resolução e melhoria de processos no programa de desenvolvimento de software

Korhonen et al, (2008)

Estudo de caso Método Goal Question Metric

Habilidades de aspectos de coordenação

Nível de alocação: locais distribuídos e Fatores considerados: requisitos técnicos dos módulos de software.

Modelo de práticas para analisar o desempenho das equipes de desenvolvimento a partir da perspectiva da teoria sociotécnica combinada e a teoria de coordenação. Este modelo é baseado no estudo de três aspectos da teoria sociotécnico: pessoas, tecnologia e tarefas.

Y. Lu et al, (2010) Estudo quantitativo, Estudo experimental

Teoria da coordenação e sócio técnico

Habilidades de aspectos de coordenação e não-técnicos das equipes distribuídas e dependências entre módulos de software

Nível de alocação: locais distribuídos; Fatores considerados: pessoas, tarefas e tecnologia.

Modelo analítico de desenvolvimento de software com equipes em projetos globalmente distribuídos. Este modelo é baseado em técnicas de modelagem de análise, a fim de prever a avaliação como os aspectos de comunicação afetam a produtividade dos membros da equipe em projetos geograficamente distribuídos Czekster et al. (2010) Estudo quantitativo, Estudo Experimental Técnicas de modelagem de análise Habilidades técnica e de aspectos de coordenação

Nível de alocação: locais híbridos (remoto e distribuído) e Fatores considerados: habilidades de gestão e o conhecimento das equipes

O modelo configura equipes distribuídas globalmente, buscando produtividade de projetos, qualidade e lucros. Este modelo captura os aspectos dinâmicos e discretos de um ambiente de desenvolvimento distribuído de software e fornece informações relacionadas ao impacto de várias configurações e dimensões da dispersão geográfica Ramasubbu et al (2011)

Estudo Experimental Modelos econométrico - Nível de alocação: locais distribuídos e Fatores considerados: dispersão geográfica, produtividade, qualidade e lucro

A. Avaliação da qualidade dos estudos

A avaliação da qualidade dos estudos foi nos critérios estabelecidos para avaliação de estudos experimentais em engenharia de software presentes em Dyba [27]. Os critérios da triagem foram relacionados com qualidade da comunicação de

raciocínio de um estudo, objetivos e contexto avaliados de acordo com a legenda abaixo.

Legenda:

√ - Esta questão está dentro desta área de responsabilidade

Questões:

''lições aprendidas ", relatório com base em opinião de especialistas? 2] As metas e objectivos foram claramente relatados (incluindo uma justificativa de por que o estudo foi realizado) ?

3] Havia uma descrição adequada do contexto no qual a pesquisa foi realizada?

4] O projeto da pesquisa foi adequado para atacar os objetivos da pesquisa? 5] Havia uma descrição adequada da amostra utilizada e os métodos para identificar e recrutar as amostras?

6] Nenhum grupo de controle foi usado para comparar tratamentos? 7] Métodos adequados de coleta de dados foram utilizados e descritos? 8] Havia uma descrição adequada dos métodos utilizados para analisar os dados e se métodos adequados para assegurar que a análise dos dados foram fundamentadas nos dados?

9] A relação entre o pesquisador e os participantes da pesquisa foi considerado adequado?

10] O estudo forneceu resultados claramente com credibilidade resultados e conclusões justificadas?

11] Eles forneceram o valor para pesquisa ou prática?

A partir da Tabela XI, pode ser vist a avaliação do estudo que consiste em verificar a adequabilidade do enquadramento dos artigos na área de responsabilidades consoante às questões pré estabelecidas pelo critério adotado por Dyba [27].

TABELA XI.AVALIAÇÃO DA QUALIDADE DOS ESTUDOS

Artigos Critérios 1] 2] 3] 4] 5] 6] 7] 8] 9] 10] 11] [33] √ √ √ √ √ √ √ √ √ √ [34] √ √ √ √ √ √ √ √ √ √ [35] √ √ √ √ √ √ √ √ √ √ [36] √ √ √ √ √ √ √ √ √ √ [37] √ √ √ √ √ √ √ √ √ √ [38] √ √ √ √ √ √ √ √ √ √ [39] √ √ √ √ √ √ √ √ √ [40] √ √ √ √ √ √ √ √ √ √ [41] √ √ √ √ √ √ √ √ √ √ [42] √ √ √ √ √ √ √ √ √ [43] √ √ √ √ √ √ √ √ √ √ [44] √ √ √ √ √ √ VI. CONCLUSÃO

Neste artigo analisamos os resultados da revisão sistemática de 12 artigos em ambiente de DDS que explora os problemas enfrentados pela alocação de tarefas, equipes, configuração de processos às equipes distribuídas. A pesquisa apresenta a relação das características de estudos de pesquisa publicados por ano, tipo de pesquisa utilizado, características e técnicas abordadas. Esta pesquisa é importante porque destaca as lacunas e oportunidades em evidências sobre utilização de

indicadores para distribuição das etapas do processo de software às equipes distribuídas em ambientes de DDS. Com base nos dados coletados é possível identificar as seguintes conclusões:

Conclusão # 1: A maioria dos estudos está relacionada com alocação de equipes no DDS e contextos são baseados em estudos acadêmicos.

A maioria de estudos está relacionada a problemas de alocação de equipes geograficamente distribuída, o que significa que pesquisadores tendem a descobrir os problemas enfrentados pelos membros das equipes pelo estudo experimental ao invés de propor um estudo observacional. Conclusão # 2: Há uma carência de pesquisas com foco na distribuição das etapas do processo de software às equipes em várias localidades geográficas em DDS.

Há duas razões plausíveis para a falta desse foco de pesquisa: 1) apesar do processo ser um fator importante no desenvolvimento de software, eles geralmente não são suficientemente maduros para fazer uso de medições e pode não ser capaz de ser prontamente aplicada na alocação a equipes devido às diferenças significativas no contexto do projeto e, portanto, pesquisadores da área tendem a utilizar a prática da alocação de tarefas, com as técnicas que se referem a métodos de caminho crítico [33], simulação [34] [35], método de comparação constante [42], ou 2) os investigadores ainda não estão amplamente conscientes da necessidade de estudos exploratórios que identifica um mecanismo que permite propor uma estratégia de alocação baseada em indicadores por meio de análise de conjunto de métricas, a fim de prever e avaliar como os aspectos técnicos, não técnicos, comportamento humano e comunicação afetam a qualidade na distribuição das etapas do processo a membros da equipe em projetos geograficamente distribuídos.

Conclusão # 3: Existe uma necessidade de mais estudos com foco em métricas de qualidade e indicadores para inferir um índice total de qualidade.

Os resultados da revisão mostrados na Tabela X indicam que a maioria das propostas até agora é, em grande parte, alocação de equipes e tarefas em locais distribuídos, considerando os fatores técnicos e não técnicos separadamente com base na análise de variáveis de associação. Os resultados dos artigos não sugerem estudos da relação entre as métricas de qualidade e indicadores analisando os fatores de qualidade tais como confiabilidade, eficiência, manutenibilidade, funcionalidade e portabilidade. Nesse contexto acredita-se que a avaliação de métricas de qualidade relacionadas à indicadores torna-se necessário para garantir que a qualidade da distribuição das etapas do processo de software esteja disponível para equipes em várias localidades geográficas oferecendo uma perspectiva ao gerente de projeto medir e

monitorar os resultados no cumprimento de melhoria continua do processo.

VII. TRABALHOS FUTUROS

O resultado do trabalho identificou uma série de dificuldades para abordar a distribuição das etapas do processo de software às equipes dispersas em nível global. As causas dessas dificuldades estão relacionadas aos aspectos de coordenação, sócio técnicos, dispersão geográfica das equipes, diferenças culturais, tecnológicos e de comportamento humano. Sua complexidade aumenta no contexto distribuído, tornando-se fundamental a compreensão dos fatores críticos em iniciativas de implementação de melhores práticas para apoiar a gestão de projetos, e gerentes de portfólio na tomada de decisões baseada em indicadores. Como trabalho futuro, pretende-se elaborar uma estratégia para auxiliar na distribuição da etapa de especificação de requisitos de Desenvolvimento Distribuído de Software (DDS). Esta investigação está sendo conduzida por meio da aplicação de métodos quantitativos e qualitativos de análise de dados. A estratégia é baseada nos conceitos de aspectos técnicos, não técnicos, e da coordenação, visando a melhoria continua de processos de software.

AGRADECIMENTOS

Os autores agradecem o apoio financeiro do CNPq sob o processo 190607/2010-6.

REFERENCIAS

[1] R. Kommeren and P. Parviainen, "Philips experiences in global distributed software development," Empirical Software Engineering, vol. 12, pp. 647-660, 12/01. 2007.

[2] R.D. Battin, R. Crocker, J. Kreidler and K. Subramanian, "Leveraging resources in global software development," IEEE Software, vol. 18, pp. 70-77, 2001.

[3] E.Carmel and P.Tija, “Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce”, UK: Cambridge, 282p,(2005) [4] J.D. Herbsleb and D. Moitra, "Global software development," IEEE

Software, vol. 18, pp. 16-20, 2001.

[5] J.A. Espinosa and E. Carmel, "The impact of time separation on coordination in global software teams: a conceptual foundation," Software Process: Improvement and Practice, vol. 8, pp. 249-266, 2003. [6] J. Audy and R. Prikladnicki, “Desenvolvimento Distribuído de

Software: Desenvolvimento de software com equipes distribuídas”. Rio de Janeiro, Elsevier.(2007).

[7] J.D. Herbsleb "Global software engineering: the future of social-tecnical coordination. Proceedings of the 29th Internacional Conference

on Software Engineering(ICSE), p. 188-98. Minneapolis, 2007.

[8] G.C.L. Leal, C.A. DA Silva, E.H.M. Huzita and T.F.C. Tait, “Recomendações para a Gestão do Desenvolvimento de Software com Equipes Distribuídas”, IV Workshop de Desenvolvimento Distribuído de Software (WDDS), 2010, pp. 26-33.

[9] A. Lamersdorf, J. Munch and D. Rombach, “A Survey on the State of the Practice in Distributed Software Development: Criteria for Task Allocation,”, IEEE Int. Conf. on Global Software Engineering, ICGSE 2009, pp. 41-50.

[10] R. Prikladnicki, J.L.N. Audy and R. Evaristo, "Global software development in practice lessons learned," Software Process: Improvement and Practice, vol. 8, pp. 267-281, 2003.

[11] K.E. Nidiffer and D. Dolan, "Evolving distributed project management," Software, IEEE, vol. 22, pp. 63-72, 2005.

[12] S. Komi-Sirviö, P. Abrahamsson and T. Huomo, "Guest editorial for the special section on distributed software development," Information and Software Technology, vol. 48, pp. 765-766, 9. 2006.

[13] A. Begel and N. Nagappan, "Global Software Development: Who Does It?" IEEE International Conference on Global Software Engineering, pp. 195-199, 2008.

[14] M. Robinson and R. Kalakota, Offshore outsourcing: Business models, roi and best practices.In: . EUA: Mivar Press, 2007. p. 336.

[15] R.Sangwan, M. Bass, N. Mullick, D. Paulish, J. Kazmeier, Global software development handbook (auerbach series on applied software engineering series).Boston: Auerbach Publications, 2006.

[16] D.K.M. Mak and P.B Kruchten, “Task coordination in an agile distributed software development environment,” Canadian Conf. on Electrical and Computer Engineering, Ottawa, ON, Canada: 2007, pp. 606-611.

[17] S.L Pfleeger, Engenharia de Software : teoria e prática, 2. ed. São Paulo: Person/Prentice Hall, 2004.

[18] R. Prikladnick and J. Audy, Desenvolvimento Distribuído de Software. 1. ed. Rio de janeiro: Elsevier, 2008.

[19] M. Fowler, Refactoring, Addison-Wesley, 1999.

[20] N.B. Moe and D. Scaronmite, "Understanding a lack of trust in Global Software Teams: a multiple-case study," Software Process: Improvement and Practice, vol. 13, pp. 217-231, 2008.

[21] E. Carmel and R. Agarwal, "Tactical approaches for alleviating distance in global software development," IEEE Software, vol. 18, pp. 22-29, 2001.

[22] A. Avritzer, "Coping with Cultural Diversity in GSE Environments," International Conference on Global Software Engineering , pp. 199-199, 2006.

[23] H. Holmstrom, E. O Conchuir, P. J Agerfalk and B. Fitzgerald, "Global Software Development Challenges: A Case Study on Temporal, Geographical and sócio-Cultural Distance," International Conference on Global Software Engineering, pp. 3-11, 2006.

[24] O. Gotel,V. Kulkarni and C. Scharff. From student to software engineer in the Indian IT industry: A survey of training. Proceedings of the 23rd Conference on Software Engineering Education and Training (CSEET’10). IEEE-CS Press: Silver Spring MD, March 2010.

[25] B. Kitchenham, Guidelines for performing systematic literature reviews in software engineering. In: . [S.l.]: EBSE Technical Report EBSE-2007-01, Keele University., 2007.

[26] K. Petersen, R. Feldt, S. Mujtaba and M. Mattsson, "Systematic mapping studies in software engineering," in 12th International Conference on Evaluation and Assessment in Software Engineering (EASE), 2008.

[27] T. Dyba and T. Dingsoyr, Empirical studies of agile software development: A systematic review. information and software technology. In:. [S.l.]: ScienceDirect:Elsevier, 2008.

[28] C.M.C. Santos, C.A.M Pimenta and M.R.C. ; Nobre, A estratégia PICO para a construção da pergunta de pesquisa e busca de evidências. Revista Latino-Americana de Enfermagem, v.15, n.3, pp. 508-511,2007 [29] R. Wieringa, N. Maiden, N. Mead and C. Rolland, "Requirements

engineering paper classification and evaluation criteria: a proposal and a discussion," Requirements Engineering, vol. 11, pp. 102-107, 2006. [30] P. Tonella, M. Torchiano, B. Du Bois and T. Systä, "Empirical studies in

reverse engineering: state of the art and future trends," Empirical Software Engineering, vol. 12, pp. 551-571, 10/01. 2007.

[31] H. Jr. Baetjer. Software as Capital, IEEE Computer Society Press, 1998, p.85.

[32] E. H. M. Huzita, C. A. Silva, I. S. Wiese, T. F. C. Tait, M. Quinaia and F. L. Schiavoni. "Um Conjunto de Soluções para Apoiar o Desenvolvimento Distribuído de Software”, II Workshop de Desenvolvimento Distribuído de Software (WDDS). 2008.

[33] P. Jalote, G. Jain. "Assigning tasks in a 24-h software development model". In:. [S.l.]: ScienceDirect:Elsevier, 2006.

[34] S. Setamanit,W. Wakeland and D. Raffo. "Planning and Improving Global Software Development Process Using Simulation". ACM Digital Library, 2006.

[35] S. Setamanit,W. Wakeland and D. Raffo. "Using Simulation to Evaluate Global Software Development Task Allocation Strategies". ACM Digital Library, 2007.

[36] Y. Lu, C. Xiang, B. Wang, X. Wangc. "What affects information systems development team performance? An exploratory study from the perspective of combined socio-technical theory and coordination theory". In:. [S.l.]: ScienceDirect:Elsevier, 2010.

[37] M. Vanzin, M.s Ribeiro, R. Prikladnicki,I. Ceccato and D. Antunes. "Global Software Processes Definition in a Distributed Environment". 29th Annual IEEE/NASA Software Engineering Workshop (SEW’05), 2005.

[38] N. Ramasubbu,M. Cataldo,R. K. Balan and J. D. Herbsleb. "Configuring Global Software Teams: A Multi-Company Analysis of Project Productivity, Quality, and Profits",[36] ACM Digital Library, ICSE, 2011.

[39] B. Ribeiro and G. Elias. "Uso de Atributos Não-técnicos na Alocação de Equipes em Projetos de Desenvolvimento Distribuído de Software",V Workshop de Desenvolvimento Distribuído de Software (WDDS), 2011. [40] R. M. Czekster, P. Fernandes, A. Sales and T. Webber. "Analytical

Modeling of Software Development Teams in Globally Distributed Projects". IEEE, International Conference on Global Software Engineering, 2010.

[41] V. S. Santos, G. Elias. "Uma Abordagem Baseada em Lógica Nebulosa para Seleção de Equipes Distribuídas Tecnicamente Qualificadas". V Workshop de Desenvolvimento Distribuído de Software (WDDS), 2011. [42] A. Lamersdorf and J. Münch. "A Survey on the State of the Practice in Distributed Software Development:Criteria for Task Allocation".Fourth IEEE International Conference on Global Software Engineering, 2009. [43] A. B. Marques, R. Rodrigues, R. Prikladnicki and T. Conte. "Alocação

de Tarefas em Projetos de Desenvolvimento Distribuído de Software:

Análise das Soluções Existentes" V Workshop de Desenvolvimento Distribuído de Software (WDDS). 2011.

[44] K. Korhonen and O. Salo. "Exploring Quality Metrics to Support Defect Management Process in a Multi-site Organization – a Case Study", IEEE 19th International Symposium on Software Reliability Engineering, 2008.

[45] R. S. Pressman, Engenharia de Software. 6. ed. São Paulo: McGraw-Hill l, 2006.

[46] R. Prikladnicki, S. Marczak, T. Conte, C. DE Souza, J. L. N. Audy, J. Kroll, A. B. Marques, and R. A. D. Orsoletta. A Evolução e o Impacto da Pesquisa em Desenvolvimento Distribuído de Software no Brasil. In: XXV Simpósio Brasileiro de Engenharia de Software, São Paulo, 2011.

Apêndice A: Lista de artigos primários utilizado neste estudo

Artigo Ano Fonte Tipo publicação Configuração de estudo Metódo usado Tipo pesquisa

1 2010 ScienceDirect journal indústria experimental proposta de solução

2 2011 WDDS workshop acadêmico experimental proposta de solução

3 2010 IEEE Xplore conferência indústria experimental pesquisa de

avaliação

4 2011 WDDS workshop acadêmico experimental proposta de solução

5 2005 IEEE Xplore workshop misto Survey, pesquisa

exploratória

pesquisa de avaliação 6 2011 ACM Digital Library conferência indústria experimental pesquisa de

avaliação 7 2008 IEEE Xplore simpósio indústria estudo de caso proposta de solução 8 2009 IEEE Xplore conferência indústria entrevistas artigo de opinião

9 2011 WDDS workshop acadêmico revisão sistemática artigo de opinião

10 2006 ScienceDirect journal indústria simulação pesquisa de

avaliação

11 2007 ACM Digital Library journal indústria simulação pesquisa de

avaliação

12 2006 ACM Digital Library workshop misto simulação pesquisa de