iv wdds - laboratório de banco de dados · por fim, temas relacionados ao dds, propostos ao longo...

Volume 11

IV WDDS IV Workshop de Desenvolvimento

Distribuído de Software

27 de Setembro de 2010

Salvador • Bahia • Brasil

ANAIS

Coordenadores do Comitê de Programa

Heitor Augustus Xavier Costa

Leonardo Gresta Paulino Murta

Coordenadores Locais do SBES

Christina von Flach Garcia Chavez

Cláudio Nogueira Sant’Anna

Coordenador Geral do CBSOFT

Manoel Gomes de Mendonça Neto

Realização

LES • Laboratório de Engenharia de Software

DCC • Departamento de Ciência da Computação

UFBA • Universidade Federal da Bahia

Promoção

SBC • Sociedade Brasileira de Computação

ii

Apresentação do CBSOFT

A Sociedade Brasileira de Computação (SBC) tem um longo histórico de eventos de

sucesso nas áreas de engenharia de software e linguagens de programação. O Simpósio

Brasileiro de Engenharia de Software é talvez o melhor exemplo disto. Este evento

alcança agora sua 24ª edição desde a sua criação em 1987. Neste caminho, ele ajudou a

criar os Simpósios Brasileiros de Linguagens de Programação (SBLP), Métodos

Formais (SBMF), Qualidade de Software (SBQS) e Componentes, Arquitetura e

Reutilização de Software (SBCARS), além de pelo menos uma dúzia de outros eventos

de menor porte. A despeito de todos os seus efeitos positivos, esta expansão criou ao

menos um problema. Hoje é muito difícil para um pesquisador participar de todos os

eventos importantes da SBC na área de software.

Ano passado, membros da comunidade brasileira de software decidiram atacar este

problema com a criação do Congresso Brasileiro de Software: Teoria e Prática, ou

simplesmente CBSOFT. O objetivo do congresso não é ser um novo evento, mas uma

federação de eventos que já existem. Um congresso que reúna vários eventos

importantes sob um mesmo teto. Sua meta é ser, uma vez ao ano, o ponto focal da

comunidade brasileira de pesquisa em sistemas de software.

Neste ano de estréia, o CBSOFT reúne o SBES, o SBCARS, o SBLP, mais 12 eventos

satélites e um evento associado. Os eventos satélites são a Sessão de Ferramentas do

CBSOFT, o Fórum de Educação em Engenharia de Software (FEES), o Workshop de

Teses e Dissertações em Engenharia de Software (WTES), o Workshop de Diretrizes

para Jovens Pesquisadores em Engenharia de Software (WDJPS), a Trilha da Indústria

do CBSOFT (CIT), e os seguintes workshops técnicos: Desenvolvimento de Software

Dirigido por Modelos (WB-DSDM), Desenvolvimento de Software Orientado a

Aspectos (LA-WASP), Sistemas de Software Autônomos (AUTOSOFT),

Desenvolvimento Distribuído de Software (WDDS), Otimização em Engenharia de

Software (WOES), e Linguagens e Ferramentas para Programação Multi-thread,

Paralela e Distribuída (LTPD).

O evento associado é a Conferência Latino-Americana em Linguagens de Padrões para

Programação (SugarLoafPLoP). Ela ocorrerá antes das outras atividades do CBSOFT e

terá seus anais editados em separado. Ano que vem, o SBMF se juntará ao grupo para o

CBSOFT 2011 que acontecerá em São Paulo, capital.

Mais que o seu tamanho, muito me orgulha a qualidade do CBSOFT. Todas as suas

trilhas técnicas foram muito competitivas e produziram artigos muito bons. Nossos 12

mini-cursos e 6 tutoriais serão ministrados por pesquisadores e profissionais, do Brasil e

do exterior, com grande experiência na área. Eu agradeço a cada um deles por

disponibilizarem-se a transmitir seus conhecimentos para a nossa comunidade.

Mais que tudo, eu estou muito feliz por nossos palestrantes convidados. O congresso

terá 13 palestrantes de reconhecida capacidade, líderes em seus campos de atuação no

Brasil e no mundo. Eu agradeço profundamente a Alex Wolf, Jonathan Aldrich, Arndt

von Staa, Rebecca Wirfs-Brock, Daltro Nunes, Jon Whittle, Flavio Oquendo, Fábio

IV Workshop de Desenvolvimento Distribuído de Software

iii

Kon, Sérgio Soares, Joe Yoder, Eric Tanter, e Mauro Pezzè, por virem à Salvador para

o CBSOFT 2010.

O material de alta qualidade do Workshop de Desenvolvimento Distribuído de Software

(WTES) que você tem agora em suas mãos é um dos Treze Volumes dos Anais do

CBSOFT. Os Volumes do SBCARS e do SBES são publicados na Biblioteca Digital do

IEEE. Os outros onze contêm os anais dos eventos listados anteriormente e podem ser

obtidos através do sítio da Sociedade Brasileira de Computação (www.sbc.org.br).

Eu concluo esta mensagem agradecendo a todos os envolvidos no planejamento e na

execução do CBSOFT. Primeiramente, eu agradeço aos membros dos comitês técnicos

de todos os eventos federados pela pontualidade e qualidade do seu trabalho. Obrigado

a Thais Batista (Coordenadora do Comitê de Programa do SBES), Ricardo Lima e

Jonathan Aldrich (Coordenadores do Comitê de Programa do SBLP), Paulo Pires

(Coordenador do Comitê de Programa do SBCARS), Uirá Kulesza (Coordenador da

Sessão de Ferramentas e do SugarLoafPLoP), Rebeca Wirfs-Brock (também

Coordenadora do SugarLoafPLoP), Márcio Delamaro (Coordenador Geral dos

Workshops), Alessandro Garcia (Coordenador dos Tutoriais e do WB-DSDM), Leo

Murta (Coordenador do WTES e do WDDS), Heitor Costa (também Coordenador do

WDDS), Márcio Barros (Coordenador do FEES e do WOES); Jerffeson de Souza

(também Coordenador do WOES); Rafael Prikladnicki (Coordenador da Trilha com a

Indústria), Fernando Castor e Roberta Coelho (Coordenadores do LA-WASP), Anarosa

Brandão (Coordenadora do AutoSoft), Eduardo Almeida (Coordenador do SBCARS e

do WDJPS) e Paulo César Masiero (também Coordenador do WDJPS).

Por fim, eu agradeço a todos os envolvidos na organização do evento pela sua dedicação

e eficiência. Sem vocês o evento não teria ocorrido! Agradecimentos muito especiais

para Vaninha Vieira (Coordenadora de Organização do CBSOFT), Christina Chavez e

Cláudio Sant'Anna (Coordenadores de Organização do SBES e do SugarLoafPLoP),

Adolfo Duran (Coordenador de Organização SBCARS e das atividades sociais do

CBSOFT), Lais Salvador e Rita Suzana Maciel (Coordenadoras de Organização do

SBLP), todo o corpo de funcionários da SBC e da DAGAZ Eventos, e os estudantes do

LES-UFBA.

Tenho certeza que o CBSOFT produzirá muitas discussões interessantes e trará

excelentes oportunidades de interação para todos os seus participantes. Aproveitem o

congresso e a cidade!

Salvador, Setembro de 2010.

Manoel Mendonça

Coordenador Geral do CBSOFT 2010

iv

Apresentação do WDDS

É com grande satisfação que apresentamos a seleção de artigos do IV Workshop de

Desenvolvimento Distribuído de Software (IV WDDS), que acontece como um evento

co-alocado ao I Congresso Brasileiro de Software: Teoria e Prática (CBSOFT).

O desenvolvimento distribuído de software (DDS) é uma realidade no Brasil.

Atualmente, é comum encontrar empresas em um estado com filiais envolvidas em

desenvolvimento de software em outros Estados, e diversas multinacionais possuem

atividades de desenvolvimento de software no Brasil. Desta forma, o WDDS reúne

pesquisadores, professores, estudantes e profissionais com interesse em DDS e

consolida-se como um importante fórum para a comunidade nacional apresentar e

discutir problemas e soluções relacionados às técnicas, métodos, ferramentas e

processos de desenvolvimento distribuído de software.

Com a quarta edição do WDDS, é possível identificar diversos grupos de pesquisa

atuando neste tema, o que pode ser comprovado pelos 17 (dezessete) artigos

submetidos. O processo de avaliação garantiu que as submissões fossem avaliadas de

forma independente por 3 especialistas na área. Destes, 7 (sete) artigos foram

selecionados na categoria de artigos completos e 5 (cinco) na categoria de resumo

estendido. Os artigos selecionados incluem desde estudos empíricos até a construção de

ferramentas, incluindo também relatos de experiência da indústria.

A programação do evento se destaca pela inovação em relação aos anos anteriores

visando permitir discussões mais ricas e, principalmente, possibilitar uma maior

integração entre os participantes. O Dr. Eduardo Almeida, professor e pesquisador da

Universidade Federal da Bahia (UFBA), apresenta a palestra intitulada: "Global

Software Engineering e o seu impacto na área de Reuso de Software. Quais são as

Oportunidades e os Desafios?", destacando a viabilidade de reutilizar software no

contexto de DDS. A excelência dos trabalhos selecionados pode ser observada nas

sessões técnicas que incluem apresentações orais e pôsteres. Por fim, temas

relacionados ao DDS, propostos ao longo do workshop, serão apresentados a grupos de

trabalho compostos pela comunidade de DDS presente para discuti-los, identificando

desafios e propondo possíveis soluções para estes desafios. Como fechamento dos

trabalhos dos grupos, o resultado da discussão será apresentado à comunidade visando o

compartilhamento de experiências, geração de oportunidades de pesquisa e

identificação de desafios a serem explorados futuramente.

Finalmente, agradecemos o apoio recebido do CBSOFT por abrigar este evento, ao

Glêdson Elias, Gustavo Cavalcanti e Daniel Charles Ferreira Porto por hospedarem e

manterem o site do evento, aos autores pelo interesse e qualidade de suas contribuições

e aos membros do Comitê de Programa e avaliadores externos por seu auxílio na

avaliação dos artigos submetidos.

Salvador, 27 de setembro de 2010.

Heitor Augustus Xavier Costa

Leonardo Gresta Paulino Murta

Coordenadores do Comitê de Programa do IV WDDS


v

Biografia dos Chairs

Heitor Augustus Xavier Costa fez pós-doutorado (2009) na

Universidade Federal de São Carlos e é doutor (2005) pela Escola

Politécnica da Universidade de São Paulo e mestre (1997) pela

Pontifícia Universidade Católica do Rio de Janeiro. Ele é atualmente

professor do Departamento de Ciência da Computação da

Universidade Federal de Lavras. Seus principais campos de interesse

são Manutenção de Software, Qualidade de Software e Processos de

Software. Ele é membro da IEEE Computer Society, ACM e Sociedade Brasileira de

Computação. Mais informações podem ser obtidas em

http://lattes.cnpq.br/1320324289662918.

Leonardo Gresta Paulino Murta é doutor (2006) e mestre (2002)

em Engenharia de Sistemas e Computação pela Universidade

Federal do Rio de Janeiro e é atualmente professor do Instituto de

Computação da Universidade Federal Fluminense. Seus principais

campos de interesse são Gerência de Configuração, Arquitetura de

Software e Reutilização de Software. Ele publicou mais de 80

artigos em revistas e conferências e é bolsista nível 2 do CNPq. Ele é membro da IEEE

Computer Society, ACM e Sociedade Brasileira de Computação. Mais informações

podem ser obtidas em http://lattes.cnpq.br/1565296529736448.

vi

Palestrante Convidado

Eduardo Santana de Almeida possui graduação em Ciência da

Computação pela Universidade Salvador (2000), mestrado em

Ciência da Computação pela Universidade Federal de São Carlos

(2003), doutorado pela Universidade Federal de Pernambuco (2007)

com período sanduiche na University of Mannheim e Pós Doutorado

no Virginia Tech (2008), Software Reuse Lab, em cooperação com o

professor Dr. Bill Frakes. Atualmente é Professor Adjunto da

Universidade Federal da Bahia (UFBA) onde tem participado e coordenado diversos

projetos com financiamentos da FAPESB, FACEPE, FINEP, CNPq, CAPES e iniciativa

privada. Tem experiência na área de Ciência da Computação, com ênfase em

Engenharia de Software, atuando principalmente nos seguintes temas: métodos,

processos, ferramentas e métricas para o desenvolvimento de software reutilizável. É

também membro da Sociedade Brasileira de Computação (SBC), IEEE Computer

Society, Association for Computing Machinery (ACM), membro do comitê gestor do

Instituto Nacional de Ciência e Tecnologia para Engenharia de Software (INES) e IEEE

Computer Society Certified Software Development Professional (CSDP).


vii

Coordenadores do Comitê de Programa

Heitor Augustus Xavier Costa, UFLA

Leonardo Gresta Paulino Murta, UFF

Comitê de Programa

Alberto Avritzer, Siemens Corporate Research, USA

Alexander Boden, University of Siegen, Alemanha Antonio Maria Pereira de Resende, UFLA, Brasil

Cleidson Ronald Botelho de Souza, IBM, Brasil

Daniel Lucrédio, UFSCar, Brasil Eduardo Santana de Almeida, UFBA, Brasil

Elisa Hatsue Moriya Huzita, UEM, Brasil

Elisa Yumi Nakagawa, USP, Brasil

Gledson Elias da Silveira, UFPB, Brasil Heitor Augustus Xavier Costa, UFLA, Brasil

Jones Oliveira de Albuquerque, UFRPE, Brasil

Jorge Luis Nicolas Audy, PUC-RS, Brasil Marcelo Cataldo, Carnegie Mellon University, USA

Rafael Prikladnicki, PUC-RS, Brasil

Renata Potim de Mattos Fortes, ICMC-USP, Brasil

Rodrigo Quites Reis, UFPA, Brasil Sabrina Marczak, UVIC, Canada

Tania Fatima Calvi Tait, UEM, Brasil

Tayana Uchôa Conte, UFAM, Brasil

Avaliadores Externos

Yguaratã Cavalcanti, UFPE, Brasil Ernani Sales, UFPA, Brasil

Adailton Magalhães Lima, UFPA, Brasil

Frank José Affonso, UNICEP, Brasil

viii

Comitê Organizador

Coordenação Local SBES Christina von Flach Garcia Chavez (DCC/IM/UFBA)

Cláudio Nogueira Sant’Anna (DCC/IM/UFBA)

Coordenador Geral do CBSOFT Manoel Mendonça (DCC/IM/UFBA)

Coordenadora de Organização do CBSOFT Vaninha Vieira (DCC/IM/UFBA)

Coordenação Local SBES Christina Chavez (DCC/IM/UFBA)

Claudio Sant'Anna (DCC/IM/UFBA)

Coordenação Local SBCARS Eduardo Almeida (DCC/IM/UFBA)

Adolfo Almeida Duran (CPD/UFBA)

Coordenação Local SBLP Lais N. Salvador (DCC/IM/UFBA)

Rita Suzana P. Maciel (DCC/IM/UFBA)

Time de Organização

Antonio Terceiro (DMCC/UFBA)

Antonio Oliveira (DMCC/UFBA)

Bruno Carreiro (DMCC/UFBA)

Glauco Carneiro (DMCC/UFBA)

Ivan Machado (DMCC/UFBA)

Leandro Andrade (CC/UFBA)

Raphael Oliveira (DMCC/UFBA)

Renato Novais (DMCC/UFBA e IFBA)

Rodrigo Rocha (DMCC/UFBA)

Yguaratã Cavalcanti (CIn/UFPE)

Apoio Executivo

DAGAZ Eventos


ix

Índice – Table of Contents

PARTE I – Palestra Convidada (resumo)

Global Software Engineering e o seu impacto na área de Reuso de Software. Quais são

as Oportunidades e os Desafios? ................................................................................1

Eduardo Santana de Almeida (UFBA)

PARTE II – Artigos Completos

Modelos de Colaboração no Desenvolvimento Distribuído de Software: uma

Revisão Sistemática da Literatura................................................................................2

Rodrigo Rocha (UFPE), Catarina Costa (UFPE), Rafael Prikladnicki (PUCRS),

Ryan Ribeiro de Azevedo (UFPE, UFPI), Ivaldir H. F. Junior (UFPE),

Silvio Meira (UFPE)

OntoDiSEN: Uma Ontologia para Apoiar o Desenvolvimento Distribuído de

Software .....................................................................................................................10

Ana Paula Chaves (UTFPR), Igor Steinmacher (UTFPR),

Gislaine Camila L. Leal (UEM), Elisa H. M. Huzita (UEM)

Uso de Ontologia no Estabelecimento de Contratos Eletrônicos para Processos

Interorganizacionais em DDS ......................................................................................18

Yara Rosetto Mariano Silva (USP), Marcelo Fantinato (USP)

Recomendações para a Gestão do Desenvolvimento de Software com Equipes

Distribuídas.................................................................................................................26

Gislaine Camila Lapasini Leal (UEM), César Alberto da Silva (UEM),

Elisa Hatsue Moriya Huzita (UEM), Tania Fátima Calvi Tait (UEM)

Desafios nas Fases do Ciclo de Vida de Projetos Distribuídos .....................................34

Rodrigo Rocha (UFPE), Catarina Costa (UFPE), Rafael Prikladnicki (PUCRS),

Ryan Ribeiro de Azevedo (UFPE, UFPI), Ivaldir H. F. Junior (UFPE),

Silvio Meira (UFPE)

Um Framework de Recomendação para Alocação de Equipes de Desenvolvimento

em Projetos Distribuídos de Linhas de Produto de Software ........................................42

Vinicius S. dos Santos (UFPB), Thaís A. B. Pereira (UFPB),

Bruno Luna Ribeiro (UFPB), Glêdson Elias (UFPB)

M3DS: Um Modelo de Dinâmica de Desenvolvimento Distribuído de Software .........50

Alexandre L’Erario (UTFPR)

PARTE III – Resumos Estendidos

Alocando Equipes Distribuídas com Base em Aspectos Não-Técnicos ........................58

Bruno Ribeiro (UFPB), Glêdson Elias (UFPB)

x

Classificando Organizações de Desenvolvimento Distribuído de Software no

Modelo de Capacidade WAVE ...................................................................................62

Rafael A. Glanzner (PUCRS), Rafael Prikladnicki (PUCRS),

Jorge L. N. Audy (PUCRS)

Desafios e Boas Práticas para o Gerenciamento de Projetos no Desenvolvimento

Distribuído de Software ..............................................................................................66

Catarina Costa (UFPE), Rodrigo Rocha (UFPE), Fabio Q. B. da Silva (UFPE),

Rafael Prikladnicki (PUCRS)

Dificuldades, Fatores e Ferramentas no Gerenciamento da Comunicação em

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

da Literatura................................................................................................................70

Alinne C. Corrêa dos Santos (UFPE), Camila Cunha Borges (UFPE),

Fabio Q. B. da Silva (UFPE), David E. S. Carneiro (UFPE)

Os Princípios Ágeis na Dinâmica do Desenvolvimento Distribuído de Software .........74

Alexandre L’Erario (UTFPR)


1

Global Software Engineering e o seu impacto na

área de Reuso de Software. Quais são as

Oportunidades e os Desafios?

Eduardo Santana de Almeida

Universidade Federal da Bahia (UFBA)

[email protected]

Abstract. A long time ago, Software Engineering researchers discussed the

idea of mass customization for software development such as in other

industries inspiring directions and efforts related to Software Reuse.

Nowadays, software development companies are trying similar directions –

from other industries - in order to emulate the manufacturing process by

offshoring software development to other countries in order to decrease costs

and improve the productivity. In this context, can software reuse be a way to

achieve that? What are the Opportunities and Challenges?

Resumo. Durante muito tempo, pesquisadores em Engenharia de Software

têm discutido as ideias de desenvolvimento em massa para software inspirado

em outras indústrias. Esse aspecto tem servido para explorar novas direções e

esforços na área de reuso de software. Atualmente, empresas de

desenvolvimento de software estão tentando direções semelhantes visando

simular o processo de manufatura com o offshoring para diminuir os custos e

melhorar a produtividade. Neste contexto, reuso de software pode ser um meio

para obtenção desses benefícios?Quais são as oportunidades e desafios neste

cenário?

2

Modelos de Colaboração no Desenvolvimento Distribuído

de Software: uma Revisão Sistemática da Literatura

Rodrigo Rocha1, Catarina Costa

1, Rafael Prikladnicki

2, Ryan Ribeiro de

Azevedo1,3, Ivaldir H. F. Junior, Silvio Meira

1

1Centro de Informática – Universidade Federal de Pernambuco (UFPE) 50.732-970 – Recife – PE – Brasil

2Faculdade de Informática – Pontifícia Universidade Católica do Rio Grande do Sul 90.619-900 – Porto Alegre – RS – Brasil

3Universidade Federal do Piauí (UFPI) 64049-550 – Picos – PI – Brasil

{rgcr, csc, rra2, ihfj, srlm}@cin.ufpe.br, [email protected]

Abstract. With the rise of Distributed Software Development, software houses

attempt to find out the best strategy to improve the development of products

and services in a distribuited way, but without losing quality at a low cost.

This work proposes to identify what models of collaboration are used by

organizations to develop software within a distributed context, based on the

traditional development life cycle, where the phases thereof are performed

(onsite, distributed / offshore and multisite). The research method used to

investigate the forms of cooperation was a systematic literature review that

have examined 841 papers published from 2000 to 2009.

Resumo. Com a ascensão do Desenvolvimento Distribuído de Software as

organizações tentam distribuir da melhor maneira possível suas atividades de

desenvolvimento com interesse de melhorá-las. O objetivo deste trabalho é

identificar quais modelos de colaboração são utilizados pelas organizações

para desenvolver software no contexto distribuído, tendo como base o ciclo de

vida básico do desenvolvimento tradicional, e onde as fases do mesmo são

realizadas (onsite, distribuído/offshore e multi-site). O método de pesquisa

utilizado para levantar as formas de colaboração foi uma revisão sistemática

da literatura que analisou 841 trabalhos publicados desde 2000 até 2009.

1. Introdução

Diante da demanda por software e pelo crescimento do número de empresas que desenvolvem essas soluções, na década passada, como reflexo da globalização, empresas de software começaram a distribuir seus processos de desenvolvimento em lugares diferentes, criando o Desenvolvimento Distribuído de Software (DDS) (Herbsleb, 2007). Também conhecido como Desenvolvimento Global de Software (para projetos que envolvem outros países).

Diversos autores afirmam que o desenvolvimento de sistemas é uma atividade complexa (The Standish Group, 2001), já que desenvolver software envolve incertezas e diversos riscos. E, acrescentando-se a isso distância física e temporal entre os


3

participantes do processo, os desafios inerentes ao desenvolvimento tendem a ser acentuados e outras dificuldades podem surgir.

Dessa maneira, inúmeras empresas tentam adotar técnicas, metodologias e ferramentas para que possam lidar da melhor forma com as variáveis do contexto distribuído. Em diversos momentos, as empresas que utilizam esse modelo de desenvolvimento necessitam definir quais metodologias utilizarão em um determinado projeto e suas respectivas práticas, pois, estas não provêem de informações que sejam capazes de determinar qual metodologia é a mais adequada para um determinado tipo de projeto ou quais as práticas mais indicadas para o mesmo.

Com a descentralização das empresas e a produção de software acontecendo de forma distribuída, o desenvolvimento de software torna-se mais complexo, exigindo que as organizações necessitem buscar modelos de colaboração (ou formas de trabalho) que consigam satisfazer suas características e necessidades. Smite e Borzovs (2009) afirmam que os responsáveis pelo projeto devem estar cientes da maneira que a organização das equipes e do projeto podem ser feitas, no sentido de que as formas de trabalho das equipes possam levar o projeto a obter um melhor desempenho. Então, é necessário que haja mais conhecimento dos responsáveis pelo projeto sobre os modelos de colaboração, ou seja, como em seu projeto eles podem dividir as atividades em cada fase do desenvolvimento e onde cada atividade pode ser realizada.

Assim, o objetivo deste trabalho é identificar através de uma revisão sistemática da literatura quais modelos de colaboração são utilizados pela indústria e/ou academia para desenvolver software no contexto distribuído, tendo como base o ciclo de vida básico do desenvolvimento tradicional de software (requisitos, análise, implementação e testes), como também suas variações e se as fases do mesmo são realizadas onsite (no cliente), distribuído/offshore e multi-site (em ambos). Além de apresentar os passos realizados na revisão sistemática da literatura objetivando identificar tais modelos.

Este trabalho está organizado da seguinte maneira: na Seção 2 são apresentados os conceitos de Revisão Sistemática da Literatura; a Seção 3 descreve os passos adotados durante a revisão sistemática, como a questão de pesquisa, a estratégia de busca (chaves da pesquisa, string de busca, fontes de busca, entre outros), assim como seus resultados, logo, os modelos de desenvolvimento no DDS são também apresentados; e por fim, a Seção 4 aborda as considerações finais.

2. Revisão Sistemática da Literatura As revisões sistemáticas da literatura (Systematic Literature Review – SLR em inglês) são parte do paradigma de práticas baseadas em evidências. Muito utilizadas na medicina e ciências da saúde, as revisões sistemáticas estão se popularizando em outras áreas, mas ainda não estão bem estabelecidas na engenharia de software (OATES E CAPPER, 2009).

A essência do paradigma baseado em evidência é coletar e analisar sistematicamente todos os dados disponíveis sobre determinado fenômeno para obter uma perspectiva mais completa e mais ampla do que se pode captar através de um estudo individual. Um dos principais métodos da engenharia de software baseada em evidências são as revisões sistemáticas, classificadas como estudos secundários, já que,

4

dependem dos estudos primários utilizados para revelar evidências e construir conhecimento (OATES e CAPPER, 2009; TRAVASSOS e BIOLCHINI, 2007).

As Revisões Sistemáticas da Literatura (SLR) são estudos que atuam como norteador para o desenvolvimento de projetos, de forma a direcionar determinada pesquisa, sintetizando todos os estudos relevantes que respondam a determinada questão.

Segundo Travassos e Biolchini (2007) uma SLR é uma forma de realizar uma revisão da literatura de forma não tendenciosa e abrangente, fazendo com que seus resultados tenham cunho científico. Existem alguns aspectos que precedem o início de uma revisão sistemática, os quais devem ser levados em conta, como delimitar o objetivo da mesma, reconhecer a literatura e avaliar os estudos possíveis de serem incluídos. Estes três itens são essenciais ao pesquisador, pois os auxiliam a aperfeiçoar a questão norteadora da revisão, tornando-a bem formulada e clara. (DOMHOLDT, 2005)

O início da SLR se dá, primeiramente, pela determinação do protocolo que enumera as questões a serem pesquisadas e os métodos utilizados para guiar a revisão. Sendo assim, Travassos e Biolchini (2007) assinalam três fases essenciais para a construção da SLR, são elas: Planejamento, Execução e Análise dos Resultados, os quais são detalhados na Figura 1.

Figura 1 - Processo de Construção da Revisão Sistemática.

Fonte: Travassos e Biolchini (2007)

No Planejamento estão incluídos os objetivos principais da pesquisa, as questões e os critérios que influenciaram na inclusão ou exclusão dos achados, as estratégias de investigação, a escolha prévia dos artigos obtidos, a seleção final dos mesmos e o direcionamento da revisão. É nele que se define o protocolo de revisão, onde é sugerida a revisão do mesmo por especialistas ou até mesmo através de um teste de execução.

É na fase da Execução que se realiza a investigação nas fontes pré-estabelecidas prosseguindo, então, para o estudo dos trabalhos selecionados e classificação dos mesmos segundo os critérios de inclusão e exclusão determinados no protocolo. Caso haja restrições no decorrer das buscas, podem ser feitas adaptações para satisfazer quaisquer limitações.

Na última fase, a Análise de Resultados, é realizada a coleta dos dados extraídos dos artigos encontrados e selecionados segundo os critérios estabelecidos no protocolo. A partir disto, estes dados são analisados e sintetizados de acordo com o método


5

escolhido. Ao final de uma SLR obteremos um mapeamento da conjuntura real do conhecimento, facultando um melhor planejamento.

3. Processo de Identificação dos Modelos

Para dar início à descrição do processo da Revisão Sistemática que foi utilizado nesse trabalho, foi essencial a construção do protocolo, como forma de direcionamento da mesma buscando avaliar os escritos que respondessem à questão da pesquisa. Para tanto, seguem abaixo os principais tópicos do protocolo da revisão sistemática que foram utilizados nessa pesquisa.

Uma Revisão Sistemática tem o intuito de responder a uma questão de pesquisa, e neste caso a questão investigada foi: “Quais são os modelos de desenvolvimento para o DDS?”. Esta questão tem o objetivo de assimilar quais são os modelos utilizados pela indústria e/ou academia para desenvolver software no contexto distribuído. Tendo como base o ciclo de vida básico do desenvolvimento tradicional de software (requisitos, análise, implementação e testes) e suas variações, e também, onde cada fase do ciclo é realizada.

3.1. Estratégia de Busca

Ao se iniciar a pesquisa dos estudos primários, Kitchenham (2007) sugere que uma estratégia deve ser usada, através da definição das palavras chaves, bibliotecas digitais, jornais e conferências.

3.1.1. String de Busca

A partir de combinações feitas com palavras-chaves relevantes, foi construída a string de busca padrão direcionada. Os termos e sinônimos identificados são apresentados abaixo:

• Desenvolvimento Distribuído de Software: Distributed Software Development, Distributed Software Engineering, Distributed Software Teams, Global Software Development, Global Software Engineering, Global Software Teams, Collaborative Software Development, Collaborative Software Engineering, Collaborative software teams, Globally Distributed Work, Distributed Development, Distributed Teams, Global Software Teams, Globally Distributed Development, Geographically Distributed Software Development, Offshore Software Development, Offshore, Offshore Outsourcing, Dispersed Teams;

• Modelos de desenvolvimento: Collaboration models, Collaboration Model, Models of Collaboration, Model of Collaboration, Development Model*, Models of Development*, Collaboration form*, Form* of Collaboration, Development proces*, Process* of Development, Work form*, Form* of Work, Life Cycle Models*.

3.1.2. Definição das Fontes de Busca

Para fazer a seleção das fontes, foi definido alguns critérios: os artigos devem estar disponíveis na web, mecanismos de busca através de palavras-chave e com garantia de resultados únicos ao mesmo conjunto de palavras-chave. Os artigos também podem ser obtidos por pessoas com experiência no assunto. O idioma das fontes deve ser em inglês assim como o idioma dos artigos, por ser o idioma mais comum entre as principais conferências do tema investigado.

6

As fontes utilizadas foram: • IEEEXplore Digital Library (httt://ieeexplore.ieee.org/) • ACM Digital Library (http://portal.acm.org) • Elsevier ScienceDirect (www.sciencedirect.com) • EI Compendex (www.engineeringvillage2.org) Além das fontes supracitadas, foi incluído também no estudo o capítulo do livro

Infonomics for Distributed Business and Decision-Making Environments: Creating Information System Ecology (SMITE e BORZOVS, 2009), já que o mesmo trata diretamente das formas de colaboração para o DDS. 3.2. Definição dos Critérios de Inclusão de Estudos

A análise para inclusão de artigos foi feita por títulos, palavra-chave, resumo e conclusão do trabalho. Os seguintes critérios de inclusão para os artigos foram definidos:

a) estar disponível na internet; b) ser escrito em Inglês; c) ter sido publicado entre 2000 e 2009 (quando DDS começou a ser realmente

consolidado); d) estudos que apresentem, primária ou secundariamente, modelos de

desenvolvimento para projetos distribuídos de software relacionados ao ciclo básico de desenvolvimento (requisitos, projeto, codificação, testes);

e) possuir projetos comerciais/industriais/acadêmicos;

3.3 Tipos de Estudo

Os tipos de estudos são classificados como:

• Experimentais ou Empirical Studies (trabalhos onde dados empíricos coletados

e analisados);

• Teóricos (estudos conceituais baseados em um entendimento de uma área, referenciando outros trabalhos relacionados);

• Revisões Sistemáticas (trabalhos que usam uma metodologia bem definida para identificar, analisar e interpretar evidências relacionadas a uma questão de pesquisa específica);

• Relato de Experiência Industrial (Industrial Experience Report).

3.4 Resultados

A Tabela 1 descreve os resultados obtidos através da Revisão Sistemática, abordando desde a questão da pesquisa até a definição dos estudos primários. Após a busca nas 4 fontes definidas, os trabalhos encontrados foram selecionados, primeiramente, com base no título e palavra-chave Dos 95 trabalhos encontrados no IEEEXplore Digital Library, 58 estavam inseridos nos critérios de busca da pesquisa. No ACM Digital

Library, dos 443 resultados obtidos apenas 139 satisfizeram a questão da presente pesquisa. Foram encontrados 235 artigos no Elsevier ScienceDirect, dos quais somente 48 se encaixavam nas especificações estabelecidas e, dos 67 estudos do EI Compendex, 42 foram aceitos para a segunda fase da seleção.


7

Tabela 1 – Método de Busca e Escolha de Estudos Primários

Fontes

Método de Busca e Escolha de Estudos

Primários

Estudos

Primários

Busca

1ª Seleção

(Título e

Palavra-

chave)

2ª Seleção

(Resumo e Conclusão)

Irrelevante

Repetido/

Duplicado

Incompleto

Questão

de Pesquisa

IEEEXplore Digital Library 95 58 52 0 1 5

ACM Digital Library 443 139 134 0 4 1

Elsevier ScienceDirect 235 48 47 0 0 1

EI Compendex 67 42 31 2 9 0 Infonomics for Distributed Business

and Decision-Making Environments:

Creating Information System Ecology

1 1 0 0 0 1

TOTAL 841 288 264 2 14 8

Com a primeira seleção, os 841 trabalhos retornados na busca, se resumiram a 288 potenciais estudos que foram analisados novamente, agora através do resumo e da conclusão. A partir disto, os estudos que atendessem ao critérios de inclusão, era incluidos como estudos primários e os demais não aceitos eram subdivididos em Irrelevante, Repetido/Duplicado e Incompleto. Os trabalhos selecionados como Estudos Primários foram avaliados segundo seu ano de publicação. Dos 8 resultados retornados, 1 foi publicado no ano de 2001, nenhum foi datado entre os anos de 2002 e 2005 e em 2008, 2 foram de 2006, 4 de 2007 e 1 foi publicado em 2009.

Os tipos de estudo são classificados em: experimentais, teóricos, revisões sistemáticas ou relatos de experiências industriais. A maioria dos estudos selecionados foram estudos experimentais, no caso, cinco. O segundo tipo mais encontrado, com dois, foi de estudos teóricos. Relato de experiências industriais apareceu em um dos estudos, e nenhum trabalho utilizou uma revisão sistemática como tipo de estudo.

3.5 Modelos de Colaboração Identificados

Na Tabela 2 são apresentados os modelos de desenvolvimento dos trabalhos encontrados na revisão sistemática. Na coluna do lado esquerdo são expostas todas as fases de desenvolvimento que foram encontradas na SLR. Ao lado, os estudos e as formas de desenvolvimento são apresentados, onde é possível perceber, por exemplo, que o estudo 1 (T1 –significando Trabalho 1) possuiu cinco fases de desenvolvimento, sendo a fase de requisitos realizada multisite, a fase de projeto e codificação realizada distribuída ou offshore, os testes foram multisite, e a implantação onsite. Da mesma forma que T1 foi descrito, os outros estudos (T2, T3, T4, T5, T6, T7) podem ser, seguindo o mesmo entendimento, onde cada um pode realizar atividades e onde as mesmas são realizadas, no cliente ou de forma distribuída.

8

Tabela 2 – Modelos de desenvolvimento distribuídos de software encontrados na SLR

Fases Estudos T1 T2 T3 T4 T5 T6 T7

Formas On Dis On Dis On

Dis On Dis On Dis On Dis On Dis

Requisitos

Cron. Proj. e Plan. Releases

Seleção do Time e Contrato

Análise

Projeto

Codificação

Testes

Gar. Qualidade

Trein. Time Offshore

Avaliação Usabilidade

Implantação

Através dos resultados foi possível encontrar sete modelos de desenvolvimento distribuído, onde as fases do desenvolvimento e o local onde essas são realizadas variam de trabalho para trabalho.

O oitavo trabalho (T8) é o de Smite e Borzovs (2009), que pode ser considerado como um trabalho relacionado. Nessa pesquisa, foram identificados dezenove modelos de colaboração através de uma pesquisa de campo com trinta e oito projetos distribuídos, porém, diferentemente desta pesquisa, a pesquisa de Smite e Borzovs foca apenas em quatro fases de desenvolvimento (Análise, Projeto, Codificação e Testes). Isso pode limitar o estudo, uma vez que cada projeto é único, e seu contexto e características variam de projeto para projeto.

A maioria dos trabalhos encontrados na revisão sistemática diz respeito à descrição dos projetos e seus resultados. Ou seja, não são trabalhos que busquem identificar os modelos de desenvolvimento que existem e suas formas de colaboração. Dessa maneira, é possível afirmar que a inexistência de trabalhos nessa área e um incentivo para pesquisadores e organizações investirem nesse segmento, já que é um campo aberto e ainda sem muita exploração.

4. Considerações Finais Esta pesquisa apresenta os modelos de desenvolvimento para ambientes distribuídos que tanto a Indústria de Software como a Academia utilizam. Esses modelos foram identificados através de uma revisão sistemática da literatura realizada entre setembro de 2009 até janeiro de 2010, envolvendo 841 trabalhos, publicados entre 2000 e 2009. Embora este estudo tenha seguido uma metodologia rigorosa, o mesmo possui algumas limitações, como a quantidade de estudos da revisão sistemática da literatura, que tomou como base, apenas 8 trabalhos. Esse pequeno número de trabalhos pode se explicar pela imaturidade da área de DDS, tento em vista que ela ascendeu nas últimas duas décadas porém, pela academia, trabalhos sobre o tema só surgiram nos últimos dez ou doze anos. Alguns trabalhos podem ser desenvolvidos futuramente a partir deste estudo, como: pesquisas mais aprofundadas sobre os modelos de desenvolvimento, que possibilitem identificar qual modelo seria mais adequado para determinado contexto;


9

analisar melhor os resultados da SLR a fim de identificar alguns porquês, como o caso do modelo realizar mais tarefas distribuídas do que no cliente, embora algumas dessas questões tenham sido identificadas; procurar investigar outros modelos, a fim de classificá-los e caracterizando-os de uma melhor forma.

Referências

Domholdt E. (2005). Rehabilitation research: principles and applications. Missouri: Elsevier Saunders.

Herbsleb, J. D. (2007). Global Software Engineering: The Future of Socio-technical Coordination. IEEE Computer Science. p188-198.

Oates, J. B.; Capper G. (2009). Using systematic reviews and evidence-based software engineering with masters students. International Conference on Evaluation & Assessment in Software Engineering, EASE.

Pfleeger, S. and Kitchenham, B. (2001). Principles of survey research: part 1: turning lemons into lemonade. ACM SIGSOFT Software Engineering Notes, 26(6):44–45.

Prikladnicki, R.; Audy, J. (2004). Munddos: Um Modelo de Referência para Desenvolvimento Distribuído de Software. 18º Simpósio Brasileiro de Engenharia de Software.

Smite, Darja., Borzovs, Juris. (2009). New Forms of Work in the Light of Globalization in Software Development. Infoconomic for Distributed Business and Decision-Making Enviroments: Creating Information System Ecology. Business Science Reference – Blekinge Intitute of Technology, p346.

The Standish Group. (2001). CHAOS 2001: A Recipe for Success.

Travassos, G., Biolchini J. (2007). Revisões Sistemáticas Aplicadas a Engenharia de Software. In: XXI SBES - Brazilian Symposium on Software Engineering, João Pessoa, PB, Brasil.

Apêndice: Estudos Primários T1 Gaurav Caprihan. (2006) Managing Software Performance in the Globally Distributed Software

Development Paradigm, Proceedings of the IEEE international conference on Global Software Engineering, p.83-91, October 16-19.

T2 James Cusick, Alpana Prasad. (2006). A Practical Management and Engineering Approach to Offshore Collaboration, IEEE Software, v.23 n.5, p.20-29.

T3 Alvin W. Yeo. (2001). Global-software development lifecycle: an exploratory study, Proceedings of the SIGCHI conference on Human factors in computing systems, p.104-111.

T4 Rizwanjameelqureshi, M., Hussain, S. (2008). An adaptive software development process model. Advances in Engineering Software. Volume: 39, Issue: 8, Pages: 654-658.

T5 Setamanit, S., Wakeland, W., Raffo, D. (2007). Improving Global Software Development Project Performance Using Simulation. In: Portland Internacional Conference on Management of engineering and Technology Portland, OR, USA.

T6 Faiz, M. F., Qadri, U. Ayyubi, S.R. (2007). Offshore Software Development Models. Information and Emerging Technologies (IIET 2007). pp. 1-6.

T7 Leszak, Marek., Meier, Mandref. (2007). Successful Global Development of a Large-scale Embedded Telecommunications Product. International Conference on Global Software Engineering (ICGSE 2007). pp. 23-32.

T8 Smite, D., Borzovs, Juris. (2009). New Forms of Work in the Light of Globalization in Software Development. Infoconomic for Distributed Business and Decision-Making Enviroments: Creating Information System Ecology. Business Science Reference – Blekinge Intitute of Technology, p346.

10

OntoDiSEN: uma ontologia para apoiar o desenvolvimentodistribuıdo de software

Ana Paula Chaves1, Igor Steinmacher1, Gislaine Camila L. Leal2, Elisa H. M. Huzita3

1Coordenacao de Informatica – Universidade Tecnologica Federal do ParanaCampus Campo Mourao – Campo Mourao – PR – Brasil

2Departamento de Engenharia de Producao– Universidade Estadual de MaringaAvenida Colombo, 1648 – Maringa – PR – Brasil

3Departamento de Informatica – Universidade Estadual de MaringaAvenida Colombo, 1648 – Maringa – PR – Brasil

[email protected],[email protected]

[email protected],[email protected]

Abstract. Global Software Develoment brought competitive advantages to or-ganizations, but also imposed some drawbacks due to the physical distribution.A critical aspect of this approach is related to communication. In order to pro-vide the same semantic understanding about information exchanged on the en-vironment to all team members, a way to represent these information is neededto minimize the ambiguity. This paper presents OntoDiSEN, an application on-tology for a distributed software development environment. The goal of this on-tology is support communication among team members, allowing users to havethe same understanding about a given piece of information.

Resumo. O Desenvolvimento Distribuıdo de Software (DDS) trouxe vantagenscompetitivas, mas tambem trouxe novos desafios. Um dos fatores crıticos dessetipo de desenvolvimento e a comunicacao. Para que todos os indivıduos, in-dependente da sua localizacao geografica, possuam a mesma compreensaosemantica sobre as informacoes trocadas pelo ambiente, e necessaria umaforma de representar essas informacoes, aumentando a clareza e diminuindo asambiguidades. Este artigo apresenta a ontologia OntoDiSEN, uma ontologiade aplicacao para um ambiente de DDS. Seu objetivo e auxiliar a comunicacaoentre os indivıduos, possibilitando que as informacoes trocadas no ambientesejam compreendidas por todos os participantes do trabalho colaborativo.

1. IntroducaoO Desenvolvimento Distribuıdo de Software (DDS) e uma forma de desenvolvimento emque equipes atuantes em um mesmo projeto, trabalhando colaborativamente, encontram-se distribuıdas geograficamente. Entre suas vantagens estao a proximidade aos mercados,a reducao de custos, a distribuicao de recursos em ambito global e o desenvolvimentocontınuo [Prikladnicki and Audy 2004]. Entretanto, em contraposicao as vantagens apre-sentadas, o DDS traz novos desafios, relativos a coordenacao, cooperacao e comunicacao,entre outros fatores como diferencas culturais e temporais.

A comunicacao e um fator crıtico em projetos que envolvem equipes dispersas.Os participantes estao muito menos propensos a comunicacao informal com participantes


11

de outras localidades devido a ausencia de contato face-a-face e conversas de corredor[Mockus and Herbsleb 2001]. Os indivıduos nem sempre se conhecem pessoalmente, po-dendo haver falta de confianca em relacao aos demais ou ausencia de predisposicao emajudar outros membros da equipe, como pode ser observado em [Moe and Smite 2008].

O DiSEN (Distributed Software Engineering Environment) e um ambiente deDDS que tem como objetivo fornecer ferramentas de apoio a comunicacao, a per-sistencia e a cooperacao entre equipes dispersas. Diversos trabalhos foram desenvolvi-dos para este ambiente, como pode ser visto em [Huzita et al. 2007]. Dentre esses tra-balhos, [Chaves 2009] propos um modelo baseado em contexto para disseminacao deinformacoes, com o objetivo de facilitar o compartilhamento automatico de informacoessobre as interacoes que ocorrem no ambiente. Neste trabalho, o contexto de uma interacaoentre um agente e uma aplicacao, com o objetivo de realizar alguma tarefa, e um conjuntode elementos instanciados que sao necessarios para apoiar a execucao daquela tarefa,naquele momento [Vieira 2008].

Durante o desenvolvimento deste modelo, notou-se que, como as mensagens saoenviadas automaticamente pelo ambiente, havia a necessidade de diminuir as possıveisambiguidades e encontrar maneiras de possibilitar que todos os indivıduos que recebema mensagem tenham a mesma compreensao semantica sobre o que foi informado. Nesteartigo, portanto, e apresentado o projeto da OntoDiSEN, uma ontologia de aplicacao,voltada para o ambiente DiSEN, cujo objetivo e descrever os conceitos e os elementoscontextuais representados e compartilhados pelo modelo de disseminacao de informacoes.

Este artigo possui, alem desta, quatro secoes, organizadas da seguinte forma: aSecao 2 apresenta os conceitos relacionados a ontologia; a Secao 3 descreve o ambienteDiSEN e o modelo baseado em contexto de disseminacao de informacoes, para o quala ontologia foi desenvolvida; a Secao 4 apresenta a ontologia OntoDiSEN; e a Secao 5discute um cenario de aplicacao e descreve os proximos passos dessa pesquisa.

2. OntologiaO termo ontologia surgiu na Filosofia, para descrever as coisas do mundo real. Nosultimos anos, conquistou espaco no domınio da computacao em areas como InteligenciaArtificial e Linguıstica Computacional. Nessas areas, a definicao mais aceita para o termofoi cunhada por [Gruber 1993], que afirma que ontologia e uma especificacao formal eexplıcita de uma conceitualizacao. Para o autor, uma conceitualizacao corresponde a umavisao abstrata e simplificada do mundo que se deseja representar. Esta e a definicao uti-lizada neste artigo, ja que o objetivo da OntoDiSEN consiste em representar formal eexplicitamente os conceitos existentes no ambiente DiSEN, oferecendo semantica a essesconceitos e, consequentemente, diminuindo ambiguidades e incompreensoes.

Uma ontologia e um conjunto de entidades, tambem denominadas conceitos ouclasses, que representam os conceitos do domınio [Noy and McGuiness 2001] e podemser organizadas hierarquicamente. As entidades possuem propriedades, que correspon-dem as caracterısticas e atributos que as identificam. Alem disso, essas propriedadespodem ter restricoes, para aumentar a precisao da especificacao. Cada entidade possuiuma populacao de indivıduos, que representam as instancias dos conceitos.

Para [Nunes et al. 2007], a motivacao para usar ontologias esta em: comparti-lhar um entendimento comum sobre a estrutura da informacao, entre pessoas ou agentes

12

computacionais; analisar o conhecimento do domınio; e permitir o uso de mecanismosde inferencia para raciocinar sobre varios contextos. Outra vantagem do uso de ontolo-gias, destacada em [Neto 2006], e descrever um domınio modelando o conhecimento semqualquer compromisso com a implementacao de um sistema de software.

3. Ambiente DiSENO DiSEN e um ambiente que visa disponibilizar ferramentas de apoio a persistencia emanipulacao de informacoes e a comunicacao e cooperacao entre indivıduos de equipesde desenvolvimento geograficamente dispersas [Huzita et al. 2007]. No contexto desteambiente, um modelo baseado em contexto para disseminacao de informacoes foi pro-posto por [Chaves 2009]. Este modelo, denominado DiSEN-CSE (DiSEN-Context Sen-sitive Environment), tem como objetivo aumentar a percepcao dos membros das equipessobre acoes que ocorrem no ambiente e, de acordo com o contexto que envolve essasacoes e os indivıduos influenciados por ela, compartilha-las automaticamente.

As informacoes sobre a construcao dos objetos de colaboracao produzidas porequipes distantes, podem apresentar ambiguidades ou falta de clareza, o que pode provo-car falhas ou incertezas no desenvolvimento do software. A solucao proposta por[Chaves 2009] foi incluir no DiSEN-CSE um elemento responsavel pela representacaodas informacoes, que baseia-se em um modelo ontologico para promover a disseminacaodo contexto de forma uniforme e padrao. O objetivo e que, mesmo com entidades recep-toras diferentes, a compreensao semantica seja a mesma.

4. OntoDiSENA OntoDiSEN e uma ontologia de aplicacao, por ser desenvolvida especificamente parao ambiente DiSEN, no domınio do DDS. Existem diversas metodologias que tem comoobjetivo conduzir e auxiliar a construcao de ontologias [Simperl and Tempich 2006]. Ametodologia utilizada para a construcao da OntoDiSEN corresponde a uma interseccao,baseada em [Martimiano 2006], entre os passos seguidos em trabalhos encontrados naliteratura. Essa interseccao utiliza as abordagens propostas em [Fernandez et al. 1997]e [Noy and McGuiness 2001] de forma complementar. A primeira, define as fases dametodologia e a segunda auxilia o processo de conceituacao. Mais detalhes sobre ametodologia podem ser encontrados em [Martimiano 2006, Chaves 2009]. O desenvolvi-mento desta ontologia baseou-se no seguinte planejamento:

Definicao do domınio: ambiente de desenvolvimento distribuıdo de software;

Definicao da aplicacao: ambiente DiSEN;

Definicao do objetivo principal: representar de forma nao ambıgua asinformacoes relacionadas ao contexto das acoes de indivıduos, locais e ferramentas deum ambiente de DDS, mais especificamente, o DiSEN;

Definicao dos usuarios: os usuarios da ontologia sao os usuarios do ambienteDiSEN e as ferramentas disponıveis no proprio ambiente;

Definido o planejamento, o proximo passo foi a aquisicao de conhecimento. Paraisso, foi necessario pesquisar nas diversas fontes de conhecimento, informacoes relevantespara compor o contexto de acoes, sobre o domınio de DDS, e sobre as caracterısticas doDiSEN. As tecnicas utilizadas para essa aquisicao foram: brainstorming com integrantes


13

do projeto DiSEN, que possuem familiaridade com a regra de negocio do ambiente; entre-vistas com especialistas (coordenadora e 2 professores responsaveis pelo DiSEN); analisede textos formais contendo informacoes sobre o ambiente DiSEN (dissertacoes, trabalhosde conclusao de curso, relatorios tecnicos e artigos publicados em anais de eventos) comoos listados em [Huzita et al. 2007].

Com base no conhecimento adquirido por essas fontes, definiu-se questoes decompetencia, que representam questoes que a ontologia precisa responder, facilitandoa fase de definicao de conceitos. Para definir essas questoes, o estudo concentrou-senos elementos que auxiliam a definicao do contexto apresentada na Secao 1 (locali-dade, identidade, atividade, tempo e presenca) e nos elementos de percepcao (quem,o que, quando, onde, porque e como). Percepcao, neste artigo, refere-se a com-preensao das atividades dos outros, que oferece um contexto para sua propria atividade[Dourish and Belloti 1992]. Alem disso, as questoes estao centradas nas tres categoriasde recursos do ambiente: usuarios, locais e ferramentas. Exemplos dessas questoes sao:

Usuario: Em que local o usuario esta logado? (localidade); Que papeis ousuario desempenha? (identidade); Quais tarefas o usuario realiza? (atividade); Qual oestado do projeto do usuario? (atividade); Quando iniciou/concluiu um artefato? (tempo);Quais usuarios do mesmo projeto estao logados? (presenca)

Ferramenta: Em quais workspaces esta instalada? (localidade); Que tipo deartefatos gera? (identidade); Qual projeto inclui a utilizacao dessa ferramenta? (ativi-dade); Quem esta utilizando a ferramenta agora? (presenca)

Locais: Quem esta conectado? (identidade); Ha quanto tempo o local estadisponıvel? (tempo); Qual dos locais permanece mais tempo disponıvel? (tempo)

Alem das questoes de competencia, foi elaborado um mapa conceitual, apresen-tado na Figura 1, com o objetivo de facilitar a compreensao sobre os relacionamentosexistentes entre os conceitos identificados durante a etapa de aquisicao de conhecimento.

Com base na semantica descrita pela aquisicao de conhecimento, os conceitos erelacionamentos foram transcritos na forma de entidades e propriedades, utilizando a lin-guagem OWL-DL1 e a ferramenta Protege2. Em OWL, as propriedades sao divididasem propriedades de objetos e de dados. Nas propriedades de objeto, estabelece-se umarelacao entre duas entidades, sendo uma imagem (entidade que possui a propriedade) eum domınio (faixa de valores possıveis para a propriedade). Nas propriedades de da-dos, o domınio nao e uma entidade, mas um tipo de dado, como string, char, integer,entre outros. As Figuras 2, 3 e 4 apresentam, respectivamente, o conjunto de entidades,propriedades de dados e de objetos da OntoDiSEN. A seguir, sao descritas algumas dasprincipais entidades e suas propriedades. As demais estao descritas em [Chaves 2009]:

Usuario: especializacao de Recurso, sao indivıduos que possuem acessoao ambiente, podendo ser alocados a projetos, nesse caso, especializados emParticipantes. Possui nome, senha, login, custo por hora, email. Um usuario per-tence a uma localidade, pode ser responsavel pelo funcionamento de um local, baixar einstalar ferramentas no seu workspace e acessa o ambiente utilizando um workspace.

1http://www.w3.org/TR/owl-features2http://protege.stanford.edu

14

Figura 1. Principais conceitos e relacionamentos da OntoDiSEN.

Ferramenta: especializacao de Recurso, consiste nas ferramentas de soft-ware que podem ser instaladas e utilizadas para a geracao dos artefatos. Possui um con-ceito, que indica seu objetivo, uma data de atualizacao, fornecedor, nome, plataforma,tamanho e versao. Uma ferramenta e capaz de gerar artefatos de um tipo especıfico, podedepender de outra para seu funcionamento correto, esta disponıvel em algum repositoriode ferramentas, pode estar instalada em workspaces e utilizada por usuarios.

Local: especializacao de Recurso, sao maquinas ou equipamentos de hard-ware que oferecem servicos ao ambiente, por exemplo, para funcionar como repositoriode dados, artefatos ou ferramentas, para conectar workspaces, para interligar servidores.Cada local possui uma configuracao, um usuario responsavel por garantir sua disponi-bilidade e esta disponıvel em um lugar fısico (localidade). Um local pode constituir umrepositorio de artefatos ou de ferramentas, alem de poder possuir recursos materiais uti-lizados por um projeto (por exemplo, um servidor de impressao). Usuarios acessam oambiente conectando seu workspace em um local.

Workspace: espaco de trabalho que contem artefatos e ferramentas que osusuarios utilizam para realizar seu trabalho. Um workspace esta ativo quando esta conec-tado a um local e pertence ao usuario que esta conectado nele. Um workspace pode pos-suir copias dos artefatos, funcionando como um repositorio local, para que os usuariospossam modificar os artefatos. Alem disso, pode possuir ferramentas instaladas.


15

Figura 2. Entidades da OntoDiSEN

Figura 3. Propriedades de dados da OntoDiSEN

Processo: conjunto de acoes predeterminadas que devem ser seguidas parao desenvolvimento de um produto de software. Possui nome, descricao e versao. Osprocessos sao utilizados para guiar os projetos e e composto de fases.

Projeto: instancia de um processo que inclui detalhes especıficos da execucaodo processo, como os objetivos a serem atingidos, prazos e metas a serem cumpridos. Pos-sui nome, descricao, datas de inıcio e fim previstas, datas de inıcio e fim efetivas. Um pro-jeto possui participantes alocados para ele, e composto de fases e possui um estado, queindica se esta em planejamento, andamento, concluıdo, cancelado ou suspenso. O projetodeve ser conduzido por um processo, respeitar um fuso horario e, para sua concretizacao,serao necessarios participantes com habilidades e conhecimentos especıficos. A diferencaentre habilidades e conhecimentos foi definida, para o ambiente DiSEN, por [Lima 2004].

Em seguida, cada entidade foi formalmente definida, utilizando a logica descritivapara inserir restricoes. Como exemplo, definiu-se que acessar um workspace e possuirum login e uma senha sao condicoes necessarias e suficientes para uma entidade ser con-siderada um usuario. Alem disso, definiu-se que um usuario e um recurso que administraum local, esta em uma localidade, usa uma ferramenta e que possui apenas essas carac-

16

Figura 4. Propriedades de objetos da OntoDiSEN

terısticas. Essa definicao e apresentada, em logica descritiva, na forma

Usuario ≡ =1 acessaWorkspace.Workspace u =1 login.String u =1 senha.StringUsuario v Recurso u ∃administraLocal.Local u =1 estaEmLocalidade.Localidade u

∃usaFerramenta.Ferramenta u ∀acessaWorkspace.Workspace u ∀administraLocal.Local u∃estaEmLocalidade.Localidade u ∀usaFerramenta.Ferramenta

Para verificar a consistencia das entidades, propriedades e restricoes geradas, aOntoDiSEN foi submetida ao raciocinador Fact++, integrado a interface da ferramentaProtege, que nao encontrou quaisquer inconsistencias.

5. Consideracoes FinaisEste artigo apresentou a OntoDiSEN, uma ontologia de aplicacao voltada para o ambi-ente DiSEN. A motivacao para seu desenvolvimento foi a dificuldade de comunicacao emum ambiente de DDS, a qual e influenciada pelas diferencas de idioma, cultura e fuso-horario. O desenvolvimento da ontologia objetiva incorporar ao modelo de disseminacaode informacoes, DiSEN-CSE, uma forma de representacao que diminua as ambiguidadesnas mensagens enviadas pelo ambiente DiSEN aos participantes dos projetos, possibi-litando que todos os indivıduos tenham a mesma compreensao semantica sobre o queesta sendo informado. Apos a formalizacao do conhecimento do domınio, atraves daconstrucao da ontologia, as pesquisas que atualmente estao em andamento se concentramem aplicar as estrategias para a utilizacao da mesma no compartilhamento de informacoessobre o contexto, conforme o modelo DiSEN-CSE. Uma limitacao deste trabalho e quea OntoDiSEN foi desenvolvida especificamente para o ambiente DiSEN, o que limitaseu aproveitamento em outros ambientes. Dessa forma, trabalhos futuros envolvem ageneralizacao da ontologia para envolver conhecimentos relacionados a ambientes deDDS como um todo.

Conforme definido na Secao 2, um dos criterios para a escolha dessa forma derepresentacao de informacoes e a capacidade de inferencia. Assim, a ontologia esta sendoutilizada para representar o contexto atual do ambiente DiSEN. Conforme definido pelomodelo DiSEN-CSE, quando uma acao ocorre, esta deve ser processada pela ontologia.Assim, agentes de software capazes de capturar essas acoes e representar o novo estado


17

do sistema na ontologia estao sendo desenvolvidos. As mudancas no contexto serao entaoprocessadas, com base em regras de inferencia, transformando as informacoes de contextoem acoes de auxılio aos usuarios. Os usuarios do ambiente DiSEN recebem, entao, men-sagens automaticas sobre as acoes que influenciam seu trabalho, oferecendo percepcaosobre as acoes que ocorrem e facilitando a tomada de decisoes. Os resultados dessapesquisa serao publicados em trabalhos futuros.

ReferenciasChaves, A. P. (2009). DiSEN-CSE: Um modelo baseado em context-awareness para

disseminacao de informacoes em um ambiente de desenvolvimento distribuıdo de soft-ware. Master’s thesis, DIN, Universidade Estadual de Maringa.

Dourish, P. and Belloti, V. (1992). Awareness and coordination in shared workspaces. InACM Conference on Computer-Supported Cooperative Work, pages 107–114. ACM.

Fernandez, M., Gomez-Perez, A., and Juristo, N. (1997). Methontology: from ontologicalart towards ontological engineering. In Proceedings of the AAAI97 Spring Symposium,pages 33–40, Stanford, USA.

Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowl-edge Acquisition, 5:199–220.

Huzita, E. H. M., Tait, T. F. C., Colanzi, T. E., and Quinaia, M. A. (2007). Um ambiente dedesenvolvimento distribuıdo de software – DiSEN. In I Workshop de DesenvolvimentoDistribuıdo de Software, pages 31–38, Joao Pessoa - PB.

Lima, F. (2004). Mecanismo de apoio ao gerenciamento de recursos humanos no contextode um ambiente distribuıdo de software. Master’s thesis, DIN – UEM.

Martimiano, L. A. F. (2006). Sobre a estruturacao de informacao em sistemas deseguranca computacional: o uso de ontologia. PhD thesis, ICMC – USP.

Mockus, A. and Herbsleb, J. (2001). Challenges of global software development. InProceedings of the 7th International Symposium on Software Metrics. IEEE CS.

Moe, N. B. and Smite, D. (2008). Understanding a lack of trust in global software teams:a multiple-case study. Softw. Process, 13(3):217–231.

Neto, R. F. B. (2006). Um processo de software e um modelo ontologico para apoio aodesenvolvimento de aplicacoes sensıveis a contexto. PhD thesis, ICMC – USP.

Noy, F. N. and McGuiness, D. L. (2001). Ontology development 101: a guide to creatingyour first ontology. Tech. Report KSL-01-05, Stanford Knowledge Systems Lab.

Nunes, V. T., Santoro, F. M., and Borges, M. R. S. (2007). Um modelo para gestao deconhecimento baseado em contexto. In XXVII CSBC - SBSC, pages 1841–1854.

Prikladnicki, R. and Audy, J. (2004). Munddos: Um modelo de referencia para desen-volvimento distribuıdo de software. In XVIII SBES.

Simperl, E. P. B. and Tempich, C. (2006). Ontology engineering: A reality check. InOTM Conferences (1), volume 4275 of LNCS, pages 836–854. Springer.

Vieira, V. (2008). CEManTIKA: A Domain-Independent Framework for DesigningContext-Sensitive Systems. PhD thesis, CIn – Universidade Federal de Pernambuco.

18

Uso de Ontologia no Estabelecimento de Contratos

Eletrônicos para Processos Interorganizacionais em DDS

Yara Rosetto Mariano Silva, Marcelo Fantinato

Escola de Artes, Ciências e Humanidades – Universidade de São Paulo (USP),

São Paulo, SP – Brasil

[email protected], [email protected]

Resumo. O Desenvolvimento Distribuído de Software (DDS) envolve a

interação entre diferentes organizações, que pode ser representada por um

processo de negócio e implementada por meio de serviços Web. Esse cenário

envolve questões que devem ser descritas por contratos eletrônicos. O

estabelecimento de contratos eletrônicos é uma atividade que possui uma

considerável complexidade requerendo, portanto, mecanismos de reúso de

informações. Neste artigo, ontologias computacionais são exploradas para

esse fim no contexto de DDS. Um exemplo de aplicação ilustrativo é

apresentado, assim como uma comparação é realizada com outro mecanismo

comumente usada para fim semelhante – os modelos de características.

Abstract. Distributed Software Development (DSD) requires interaction

between different organizations, which can be represented by business

processes and implemented by Web services. This scenario involves issues that

must be described by electronic contracts. The establishment of electronic

contracts is an activity that has a significant complexity and hence requires

information reuse mechanisms. In this paper, computational ontologies are

explored with this objective in the DSD context. An illustrative application

example is presented, and a comparison with another mechanism commonly

used for this objective – the feature models – is presented.

1. Introdução

Atualmente, é comum que empresas de diversas áreas busquem parceiras que possam

apoiar suas estratégias de negócio. Diversos motivos podem ser apontados para esse

movimento, incluindo: redução de custo; melhoria de desempenho; aumento da

capacidade técnica; e, liberação de recursos para suas atividades principais [Foogooa

2008]. Para que uma parceria possa ser formada, um Processo de Negócio (PN) precisa

ser definido para promover a cooperação entre diferentes organizações [Weske 2007].

Um PN é um conjunto de atividades relacionadas usadas para realizar uma

estratégia de negócio [Weske 2007]. Em um ambiente eletrônico, as atividades de um

PN podem ser implementadas por meio de serviços Web. Um serviço Web é uma

unidade de software auto-contida que encapsula uma função de negócio [Papazoglou

2007], podendo ser invocada na internet. Assim, organizações podem explorar as

vantagens de diferentes parceiros sem a necessidade de considerar questões geográficas.

Nesse contexto, preocupações com a qualidade de serviço (QoS) prestado devem ser

tomadas para que ela não fique abaixo das expectativas dos parceiros.


19

Em função dessas características, é importante que todas essas informações –

PN, serviços Web, QoS – estejam bem especificadas em um contrato eletrônico entre as

organizações envolvidas na cooperação, preferencialmente por meio de linguagens de

especificação processáveis por computador [Grefen et al. 2006]. Porém, o

estabelecimento de contratos eletrônicos não é uma tarefa trivial, o que pode dificultar a

criação de novas parcerias. Assim, mecanismos que favorecem o reúso de informações

são úteis para seu estabelecimento.

O processo de engenharia de software é composto por atividades que englobam

desde a definição de requisitos até a implantação e a manutenção do software. Em um

cenário de Desenvolvimento Distribuído de Software (DDS), essas atividades são

delegadas a diferentes organizações que devem colaborar para o desenvolvimento de

software. Essa colaboração pode ser beneficiada com o uso da tecnologia de serviços

Web compostos em um PN específico para o desenvolvimento de software. Assim, nesse

cenário, as organizações atuam como fornecedoras e consumidoras de serviços aplicados

ao desenvolvimento de software. Neste cenário, os contratos eletrônicos mencionados

anteriormente são essenciais, para representar os detalhes do PN envolvendo todos os

envolvidos na subcontratação a ser realizada.

O DDS pode envolver a contratação de diversos fornecedores. Além disso,

vários projetos de desenvolvimento de diferentes sistemas podem envolver os mesmos

ou diferentes fornecedores. Os contratos estabelecidos em cada caso podem diferir entre

si, mas de modo geral são semelhantes. Portanto o uso de mecanismos de reúso de

informações e artefatos no estabelecimento de contratos eletrônicos é essencial para a

viabilização dessa abordagem no contexto de DDS. Este artigo explora o uso de

ontologias computacionais como um mecanismo para possibilitar o reúso de informações

nesse processo. A contribuição que se busca com este artigo é apresentar o potencial de

ontologias para reúso de informações no estabelecimento de contratos eletrônicos no

domínio de DDS, porém sem realizar análises de viabilidade e de aplicabilidade prática

para a abordagem proposta. Uma comparação é realizada com a técnica de modelagem

de características, um mecanismo similar para objetivos similares.

Este artigo apresenta os seguintes itens: contratos eletrônicos na Seção 2;

ontologias na Seção 3; um exemplo ilustrativo de ontologia para o contexto de DDS na

Seção 4; alguns trabalhos relacionados na Seção 5; e, a conclusão na Seção 6.

2. Contratos Eletrônicos para Serviços Eletrônicos

A tecnologia de serviços Web tem sido apontada como a mais promissora para a

implementação da computação orientada a serviços (Service-oriented Computing –

COS). Por meio de serviços Web, é possível implementar um PN, integrar sistemas –

inclusive legados, compor aplicações complexas por meio do agrupamento e

coordenação de serviços [Papazoglou 2007], e estabelecer parcerias para o DDS. Um

serviço Web possui uma interface definida em uma linguagem baseada em XML – a

WSDL (Web Service Description Language). PN são utilizados para compor serviços

Web e assim representar as restrições na ordem de execução dos serviços, bem como as

possíveis interações entre eles. WS-BPEL (Web Service – Business Process Execution

Language) tem sido a linguagem mais usada para representar PN. Ela fornece uma

sintaxe baseada em XML para que essas restrições sejam especificadas. PN e serviços

20

Web atuam em uma arquitetura orientada a serviços, na qual existem mecanismos para

registro e descoberta de serviços. Cada um desses mecanismos possui linguagens e

protocolos adequados para sua representação.

Para que um PN entre organizações seja realizado, é necessário o

estabelecimento de um contrato [Giambiagi et al. 2006] que contenha detalhes da

transação entre as partes. Contratos são amplamente usados para especificar detalhes

entre as partes em um processo de terceirização de serviços [Grefen et al. 2006], e como

instrumento para redução e gerenciamento de riscos. Segundo Fantinato, Toledo e

Gimenes (2008), um contrato é um documento eletrônico usado para representar um

acordo entre organizações parceiras que é composto basicamente de: i) definição de

produto ou serviço; ii) obrigações e proibições; e iii) ações que devem ser tomadas em

caso de discordâncias. Contratos podem ser complexos e, de forma geral, seu processo

de estabelecimento costuma ser complexo devido ao grande número de parâmetros

envolvidos na seleção de atributos de QoS [Grefen et al. 2006].

Para que as questões envolvidas no estabelecimento de um contrato eletrônico

sejam acordadas, existe a necessidade de uma negociação entre as partes [Grefen et al.

2006]. Para que essa negociação ocorra, é necessário que todas as partes envolvidas

definam claramente quais são os serviços que cada uma delas disponibilizam para fazer

parte de um futuro processo interorganizacional, ou seja, quais serviços que o

fornecedor tem a oferecer, assim como quais serviços o consumidor oferece para poder

ser comunicar com seus fornecedores e receber os artefatos de seus fornecedores. Além

disso, é importante que para todos os serviços disponibilizados, os atributos de QoS e

seus respectíveis níveis oferecidos também sejam definidos a priori.

3. Ontologias Computacionais

Ontologias podem ser definidas como um conjunto de termos ordenados

hierarquicamente para descrever um domínio que pode ser usado como um esqueleto

para uma base de conhecimento [Gómez-Pérez 1999]. Uma ontologia deve ser uma

especificação formal e explícita de um conceito compartilhado, sendo que “formal”

remete a processável por máquinas, “explícita” remete a conceitos determinados e

“compartilhado” remete a conhecimento comum [Borst 1997].

Os componentes básicos de uma ontologia normalmente são: classes (conjunto de

objetos); atributos (características que os objetos podem ter e compartilhar);

propriedades de objeto (relacionamentos entre objetos); e, indivíduos ou instâncias (os

objetos básicos propriamente ditos). As ontologias computacionais são normalmente

acompanhadas de mecanismos de inferência, que computam o que há de informação

explícita na ontologia e usam essas mesmas informações para inferir novas informações.

Um tipo especial de classe usada pelos mecanismos de inferência são as classes definidas,

que possuem regras explícitas (chamadas de condições necessárias e suficientes) para a

criação de relacionamentos inferidos de outras classes para elas.

Ontologias são comumente usadas na Ciência da Computação para capturar

conhecimento sobre certo domínio de interesse, possibilitando seu compartilhamento e

reúso como, por exemplo, em Web semântica [Gruber 1993]; podendo ser chamadas de

ontologias computacionais. Além de sua adoção em comunidades científicas, entidades


21

governamentais e comerciais já as usam em suas aplicações, como um artifício de

compartilhamento, processamento e reúso de conhecimento [Pacheco e Kern 2001].

Trazendo ontologias para o contexto abordado neste artigo, elas podem trazer

benefícios à representação de informações a serem usadas durante o estabelecimento de

contratos eletrônicos, tanto de uma forma genérica, quanto especificamente para o

contexto de DDS. Considerando como elemento básico cujo comportamento e regras de

relacionamento devem estar definidos em um contrato eletrônico, Burbeck (2000)

destaca as seguintes propriedades de descrições inerentes a um serviço eletrônico:

1. Devem ser legíveis a humanos, processáveis por programas e extensíveis;

2. Devem fornecer informação no aspecto semântico necessária aos clientes para

que possa ser verificada a satisfação dos requisitos e aos fornecedores para que

decidam sobre a classificação precisa do serviço em sua taxonomia;

3. Devem permitir a especificação de requisitos não-funcionais.

Assim, pressupõe-se que ontologias podem ser aplicadas no desenvolvimento de

um modelo-base de apoio ao estabelecimento de contratos eletrônicos. Elas podem,

portanto, ser usadas para representar os conceitos e relacionamentos envolvidos na

negociação entre as empresas envolvidas em uma possível subcontratação no processo

de desenvolvimento de software, incluindo serviços e QoS, de modo a facilitar o

processo de contratação eletrônica, principalmente por meio de reúso de informações.

4. Ontologia de Apoio a Contratação no Contexto de DDS

A ontologia foi criada com o uso da ferramenta Protégé, uma ferramenta amplamente

usada atualmente para o desenvolvimento de ontologias. As ontologias desenvolvidas

graficamente por meio dessa ferramenta são armazenadas internamente por meio de

arquivos usando a linguagem de especificação OWL (Web Ontology Language).

Para facilitar o entendimento do reúso de conceitos no contexto de negociação e

estabelecimento de contratos eletrônicos no contexto de DDS, a seguinte hierarquia de

classes foi estabelecida: há duas classes principais – template e instância. Na

classe template, estão localizadas as subclasses relacionadas à estrutura que

representa os meta-conceitos presentes na negociação e estabelecimento de contratos

eletrônicos. Na classe instância, estão localizadas as subclasses relacionadas aos

próprios conceitos a estarem presentes em tal negociação e contratação eletrônica e que

devem, portanto, encaixar-se em uma das subclasses da classe template. Para isso, a

maioria das classes dentro da hierarquia da classe template é do tipo definida.

Na Figura 1 é apresentada a hierarquia de classes declarada para o contexto de

DDS. A hierarquia de classes abaixo da classe template é comum para qualquer

contexto. Ela é usada para estruturar os demais conceitos por meio das seguintes regras:

há dois tipos principais de informações a serem usadas na negociação e contratação

eletrônica – serviços eletrônicos a serem contratados e atributos de QoS e seus

respectíveis níveis associados aos serviços a serem contratos. Os serviços eletrônicos são

apresentados em grupos e podem conter detalhes de propriedades associados a eles. As

classes dentro dessa hierarquia que vão ser usadas para classificar as classes da

hierarquia abaixo da classe instância são classes do tipo definida; as quais são

apresentadas em cor laranja (o tom mais escuro) na figura.

22

A hierarquia de subclasses abaixo de instância é específica para o contexto

de DDS. Ela é usada para representar exatamente quais são os serviços e os atributos de

QoS que podem fazer parte do processo interorganizacional envolvendo um cliente e

seus subcontratados. Para o exemplo ilustrativo apresentado aqui, três organizações

foram modeladas – a organização cliente e duas organizações fornecedoras – A e B.

Cada organização possui um conjunto de serviços eletrônicos a fazer parte do processo.

Cada um desses serviços pode possuir um conjunto de propriedades que detalham

alguma informação associada a ele; por exemplo, a atividade Desenvolver Artefatos em

relação à Interface Gráfica, tanto do fornecedor A quanto do B, possui algumas telas que

podem ser desenvolvidas associadas e representadas como propriedades do serviço.

Figura 1. Hierarquia de classes declarada da ontologia de apoio a contratação

eletrônica para DDS.

As classes da hierarquia instância foram criadas usando uma série de

propriedades de objeto que possibilitam que, uma vez executado o mecanismo de

raciocínio automático, elas sejam automaticamente classificadas nas classes definidas da

hierarquia template. As Figuras 2, 3 e 4 apresentam trechos da hierarquia de classes

inferida em que as classes que representam os conceitos associados às organizações

participantes da contratação eletrônica foram classificadas nas subclasses da classe

template. Diferentes partes são apresentadas em cada umas das figuras.

Na Figura 2, seis classes foram classificadas do tipo “grupo (de) serviços”: duas

para cada organização que fará parte do processo interorganizacional a ser regido pelo

contrato eletrônico a ser estabelecido. Na Figura 3, 16 classes foram classificadas do tipo

“serviço (eletrônico)” e seis do tipo “propriedade (de) serviço”. Essa classificação

permite ajudar no entendimento das partes de quais subclasses de instância são de

que tipo em relação às subclasses de template.


23

Figura 2. Hierarquia de classes inferida – grupo de serviços.

Figura 3. Hierarquia de classes inferida – serviço e propriedade de serviço.

Na Figura 6, seis classes foram classificadas do tipo “atributo (de QoS)”: três

para cada uma das organizações fornecedoras que farão parte do processo

interorganizacional. Como nenhum atributo foi declarado para a subclasse referente à

organização cliente, não há nenhum relacionamento inferido nessa hierarquia para ela. Os

níveis disponíveis para cada um dos atributos de QoS, classificados conforme a Figura 4,

não são apresentados graficamente nas figuras apresentadas no artigo, já que eles foram

modelados como indivíduos.

24

Figura 4. Hierarquia de classes inferida – atributo de QoS.

5. Trabalhos Relacionados

Modelos de características apresentam algumas propriedades oferecidas por ontologias

[Czarnecki et al. 2006]. Essa técnica foi apresentada no contexto de análise de domínio

[Kang et al. 1990]. Trata-se de uma hierarquia de propriedades com variabilidade, sendo

que o objetivo principal é organizar um número relativamente grande de características,

que podem ser obrigatórias, opcionais ou alternativas, em diversos níveis de

detalhamento. A partir de um modelo de características genérico, diferentes instâncias –

chamadas de configurações de modelos de características – podem ser geradas.

Ambas as abordagens – ontologias e modelos de características – são usadas para

representar conceitos em um domínio particular e seus relacionamentos. Entretanto,

linguagens e ferramentas de ontologias oferecem facilidades de raciocínio para a

verificação de consistência e completitude, e máquinas de inferência que permitem o

processamento de regras, o que não ocorre com modelos de características. Por outro

lado, modelos de características oferecem facilidades para capturar e gerenciar conceitos

comuns e variáveis, o que não é oferecido por ontologias. Apesar destas diferenças, cada

uma delas poderia ser estendida para incorporar facilidades oferecidas pela outra.

O trabalho aqui apresentado é derivado de outro apresentado na edição anterior

do WDDS, em que eram usados modelos de características como apoio ao processo de

negociação e estabelecimento de contratos eletrônicos no contexto de DDS [Silva 2009].

6. Conclusão

No DDS as atividades de engenharia de software são realizadas em parceria com outras

organizações, precisando definir claramente qual é o processo interorganizacional. Para

isso, cada organização envolvida deve apresentar as informações relacionadas aos

serviços que vão ser disponibilizados de sua parte para fazer parte do processo, com

todos os detalhes a respeito desses serviços. Esses detalhes darão subsídio para a

negociação e o posterior estabelecimento de um contrato eletrônico entre as partes.

Este artigo propôs uma forma de modelar esses detalhes como conceitos por

meio de ontologias computacionais de modo a favorecer o reúso de informações em um

processo que deve se repetir várias vezes durante a execução de diferentes projetos de

desenvolvimento envolvendo DDS. No caso específico deste artigo, foi apresentado um

exemplo ilustrativo de uma ontologia em que uma parte da hierarquia de classes – o

template – poderá ser reaproveitada para novas subclasses da instância,

considerando novos projetos a serem executados. Como trabalho futuro, pretende-se


25

trabalhar mais essa idéia e propor uma metodologia completa para a negociação e

estabelecimento de contratos eletrônicos para DDS com base em ontologias, além de

realizar análises de viabilidade e de aplicabilidade prática para a abordagem proposta.

7. Agradecimentos

Este trabalho foi apoiado pela FAPESP – Fundação de Amparo à Pesquisa do Estado de

São Paulo.

Referências

Borst, W. (1997). Construction of Engineering Ontologies for Knowledge Sharing and

Reuse. Tese de PhD, Universidade de Twente, Holanda. Disponível em:

http://doc.utwente.nl/17864/1/t0000004.pdf

Burbeck, S.(2000) “The Tao of E-business Services: The Evolution of Web Applications

into Service-oriented Components with Web Services”. IBM Software Group, 2000.

Czarnecki, K., Kim, C. and Kalleberg, K. (2006) “Feature Models are Views on

Ontologies”, In: Proc. of the 10th Int. Conf. on Software Product Lines (SPLC

2006), Baltimore, Inglaterra, pp. 41-51.

Foogooa, R. (2008) “IS outsourcing – A strategic perspective”, Business Process

Management Journal, v. 14, n. 6, pp. 858-864.

Giambiagi, P., Owe, O., Ravn, A.P. and Schneider, G. (2006) “Language-Based Support

for Service Oriented Architectures: Future Directions”, In: Proc. of the 1st Int. Conf.

on Software and Data Technologies (ICSOFT 2006), Setúbal, Portugal, pp. 11-14.

Gómes-Pérez, A. (1999) “Tutorial on Ontological Engineering”, In: Proc. of the 16th

Int. Joint Conf. on Artificial Intelligence (IJCAI 1999), Estocolmo, Suécia.

Grefen, P., Ludwig, H., Dan, A. and Angelov, S. (2006) “An Analysis of Web Services

Support for Dynamic Business Process Outsourcing”, Information and Software

Technology, v. 48, n. 11, pp. 1115-1134.

Gruber, T. (1993) “A Translation Approach to Portable Ontologies Specifications”,

Knowledge Acquisition, v. 5, n. 2, pp. 199-220.

Kang, K. et al. (1990) “Feature- Oriented Domain Analysis (FODA) Feasibility Study”,

Technical Report, CMU/SEI-90-TR-021.

Pacheco, R. and Kern, V. M. (2001) “Transparência e Gestão do Conhecimento por

meio de um Banco de Teses e Dissertações: A Experiência do PPGEP/UFSC”,

Ciência da Informação, v.30, n.3, pp. 64-72.

Papazoglou, M. P. (2007) Web Services: Principles and Technology. Prentice Hall.

Silva, G. C., Gimenes, I. M. S., Fantinato, M. e Toledo, M. B. F. (2009) “Aplicação de

Apoio Computacional Baseado em Processos de Negócio e Serviços Web para o

Desenvolvimento Distribuído de Software”, Em: Anais do III Workshop de

Desenvolvimento Distribuído de Software (WDDS 2009), Fortaleza, Brasil.

Weske, M. (2007) Business Process Management: Concepts, Languages, Architectures.

Springer.

26

Recomendacoes para a Gestao do Desenvolvimento deSoftware com Equipes Distribuıdas

Gislaine Camila Lapasini Leal1 2, Cesar Alberto da Silva2,Elisa Hatsue Moriya Huzita2, Tania Fatima Calvi Tait2

1Departamento de Engenharia de Producao – Universidade Estadual de Maringa (UEM)

2Departamento de Informatica - Universidade Estadual de Maringa (UEM)Maringa, PR – Brasil

[email protected], [email protected], {emhuzita, tait}@din.uem.br

Abstract. Distributed Software Development aims at increase productivity, re-duce costs and improve quality. However, this scenario adds new challenges tothe development process related to communication, coordination and control.These factors directly influence the quality of software produced. In this way, itis necessary to treat them properly. The purpose of this paper is to present a setof recommendations to offer support to the project manager when distributedsoftware development approach is adopted.

Resumo. O Desenvolvimento Distribuıdo de Software visa o aumento deprodutividade, reducao de custos e melhoria na qualidade. Porem, essecenario adiciona novos desafios ao processo de desenvolvimento relacionados acomunicacao, coordenacao e controle. Esses fatores influenciam diretamente aqualidade do software produzido, dessa forma, e necessario trata-los adequada-mente. Este artigo tem como objetivo apresentar um conjunto de recomendacoespara apoiar o gerente de projetos quando adotada a estrategia distribuıda parao desenvolvimento do software.

1. Introducao

A crescente globalizacao do ambiente de negocios e da economia, juntamente com oavanco tecnologico, alta competitividade, aumento do tamanho das equipes, dificuldadeem reunir especialistas e aumento da complexidade do software, tem afetado, direta-mente, o desenvolvimento de software. Em busca de vantagem competitiva, diversasorganizacoes optaram por distribuir o processo de desenvolvimento de software caracte-rizando o Desenvolvimento Distribuıdo de Software (DDS) [Huzita et al. 2008].

O principal objetivo dessa descentralizacao consiste em otimizar os recursos paradesenvolver produtos de maior qualidade e a um custo menor. No entanto, essa dispersaoadicionou novos desafios ao desenvolvimento relacionados a comunicacao, coordenacao econtrole, os quais podem afetar negativamente a produtividade e, por conseguinte, a qua-lidade do software. Esses fatores influenciam a maneira pela qual o software e projetado,desenvolvido, testado e entregue aos clientes, afetando assim os estagios correspondentesdo ciclo de vida do software.


27

De acordo com [Mockus and Herbsleb 2001] e [Damian 2002], os principais de-safios encontrados no DDS sao relacionados as diferencas culturais, dispersoes ge-ograficas, coordenacao e controle e comunicacao. A diversidade cultural implica em difi-culdades de compreensao da linguagem natural utilizada nos documentos de requisitos e aconvergencia entre diferentes interesses [Layman et al. 2006]. E as distancias geograficasagravam os problemas de coordenacao e controle, de forma direta ou indireta, por meiodos efeitos negativos que causam na comunicacao [Hargreaves and Damian 2004].

Segundo [Damian and Lanubile 2004] para minimizar esses efeitos e alcancarnıveis mais elevados de produtividade sao necessarias novas tecnologias, processos emetodos compatıveis com a abordagem de desenvolvimento distribuıdo.

Em [Jimenez et al. 2009] e possıvel observar a evolucao dessa abordagem de de-senvolvimento em funcao do aumento de trabalhos disponıveis na literatura. Alem disso,nota-se que os maiores esforcos estao centrados em processos organizacionais, os quaistratam dos recursos humanos, gestao organizacional, alinhamento de infraestrutura egestao de projetos. Isto evidencia uma lacuna em relacao ao nıvel de projetos e aspectostecnicos o que requer novos processos e ferramentas.

Os processos de engenharia de software possuem artefatos, responsabilidades eatividades bem definidas, possibilitando adequacao as necessidades especıficas. No en-tanto, estes processos sao, geralmente, voltados para o desenvolvimento de projetos coalo-cados, nao considerando as peculiaridades de coordenacao, controle e comunicacao dodesenvolvimento com equipes geograficamente dispersas. [Rocha et al. 2008] enfatizama necessidade de processos adequados a essa estrategia de desenvolvimento. De acordocom [Audy and Prikladnicki 2008], em um ambiente de desenvolvimento distribuıdo, efundamental um processo de desenvolvimento comum a equipe, visto que uma metodolo-gia auxilia diretamente na sincronizacao, fornecendo a todos os membros da equipe umanomenclatura comum de tarefas e atividades, e um conjunto comum de expectativas aoselementos envolvidos no processo.

Este trabalho apresenta um conjunto de recomendacoes relacionadas a processo dedesenvolvimento de software, quando da adocao da estrategia distribuıda, as quais podemnortear o Gerente de Projetos. O texto encontra-se estruturado em quatro secoes, alem daintroducao. Na Secao 3 sao tratados aspectos do processos de desenvolvimento. Na Secao4 sao apresentadas as recomendacoes relacionadas ao processo de desenvolvimento. Porfim, na Secao 5 sao realizadas as consideracoes finais.

2. Metodologia

A pesquisa conduzida neste trabalho se caracteriza como sendo do tipo exploratoria. Oestudo objetiva proporcionar uma maior familiaridade com o problema com vistas a torna-lo explıcito [Silva and Menezes 2000].

O objetivo principal deste trabalho foi identificar dificuldades, solucoes e fa-tores crıticos relacionados ao processo de desenvolvimento de software com equipes dis-tribuıdas. Desse modo, com base na literatura disponıvel, a principal finalidade foi elabo-rar um conjunto de recomendacoes que tem como objetivo a criacao de novas teorias ouamadurecimento das ja existentes.

28

3. Processos de DesenvolvimentoUm processo de software pode ser definido como um conjunto coerente de polıticas, estru-turas organizacionais, tecnologias, procedimentos e artefatos necessarios para conceber,desenvolver, implantar e manter um produto de software [Fuggetta 2000]. Envolve umaserie de etapas constituıdas por um conjunto de atividades, metodos, praticas e tecnolo-gias que sao utilizadas desde o desenvolvimento ate a manutencao do software e produtosrelacionados.

O processo de desenvolvimento de software tem passado por intensastransformacoes nos ultimos anos. E nesse contexto, novas abordagens de desenvolvi-mento tem surgido objetivando que muitos dos problemas encontrados nos projetos ante-riores nao sejam repetidos. Dentre os problemas mais comuns aos projetos de softwarepodem ser destacados: altos custos para evolucao, inconsistencia entre documentacaoe sistema final, pouca ou quase que total falta de portabilidade e baixa confiabilidade.E sabido que o sucesso de um projeto de desenvolvimento de software inicia-se no de-vido planejamento e na escolha de uma metodologia compatıvel com as caracterısticas domesmo, o que reforca a necessidade de um processo de desenvolvimento que contemplede forma efetiva as necessidades do DDS.

Segundo [Rocha et al. 2008], quando o contexto e Desenvolvimento Distribuıdo,o cenario muda com relacao ao desenvolvimento de software tradicional, pois as variaveise os riscos aumentam. Entao, se nao houver uma metodologia adequada para o processode desenvolvimento, o projeto tera boas chances de nao corresponder ao planejamentoinicial. Em sua primeira percepcao sobre o uso e estudo de DDS, [Rocha et al. 2008]ressaltam a necessidade de processos mais adequados, pois, com base nas pesquisas reali-zadas, nao foi facil a identificacao de modelos de referencia de processos para o ambienteDDS.

4. Conjunto de RecomendacoesEm [Leal et al. 2010] os processos RUP, XP, AUP, Extended Workbench e LAGPROforam analisados sob a perspectiva do DDS. Com isso, pode-se evidenciar algumas la-cunas em relacao as novas demandas geradas pela abordagem distribuıda.

Com base nessas lacunas identificadas apresenta-se um conjunto derecomendacoes que tem por objetivo auxiliar o processo de desenvolvimento dis-tribuıdo de software tanto no nıvel estrategico (aspectos de gerencia) como no nıvelde projetos e aspectos tecnicos. E, pretende-se permitir, no futuro, a elaboracao deum processo adequado as caracterısticas do DDS. Alem disso, essas recomendacoespodem ser facilmente empregadas durante um projeto dada a sua natureza pratica[Siqueira and Silva 2006].

As recomendacoes relacionadas aos aspectos gerenciais sao:

∙ definir a configuracao do desenvolvimento e teste (onshore insourcing, out-sourcing, offshoring ou internal offshoring) a ser adotada. De acordo com[L’Erario 2009] e importante explorar, estrategicamente, as aliancas entreorganizacoes para obter vantagem competitiva a partir da produtividade dis-tribuıda. Pode-se optar por terceirizar os testes de integracao, sistemas e deaceitacao para empresas que sejam especialistas na area.


29

Segundo [Bazman 2007] a terceirizacao da atividade de testes pode ser motivadapela reducao de custos, velocidade, melhoria dos testes e aquisicao de instalacoesde ambientes de teste. E como, benefıcios tem-se: retorno do investimento; me-lhoria da confiabilidade do software; realizacao de uma maior gama de testes;contratacao de equipe de teste eficiente e qualificada num curto perıodo de tempo;e, maior eficiencia.∙ identificar as equipes envolvidas no projeto, bem como seu lıder (Gerente de Pro-

jetos Local) para estimular a confianca e compromisso entre os membros. Naformacao das equipes deve-se considerar, alem do idioma, questoes de afinidadee habilidades dos membros. Segundo [Cibotto et al. 2009], sempre que possıvel,envolva no projeto equipes que possuem o mesmo idioma nativo para amenizar osproblemas de comunicacao. Deve-se, tambem, estabelecer a equipe central, quesera responsavel pela sincronizacao das atividades entre as diversas equipes;∙ definir uma infraestrutura para comunicacao e colaboracao, tanto interna (equipes

envolvidas no projeto) quanto externa (clientes). Para que essa comunicacaoocorra de forma adequada, e necessario que a infra-estrutura seja definida cor-retamente. Geralmente, sao necessarios diversos meios, tais como: viagens, tele-fone, e-mail, videoconferencia, ferramentas de gerencia de projetos on-line, in-stant messengers e wiki [Al-Asmari and Yu 2006];∙ definir um idioma para formalizacao do processo e interacao entre as equipes;∙ distribuir as atividades entre as equipes envolvidas e seus membros.

[Weissleder and Schlingloff 2008] apresentam duas estrategias que podem ser uti-lizadas para a distribuicao das atividades: minimizar a colaboracao necessaria en-tre as equipes, visto que isso minimiza os impactos negativos dos problemas decomunicacao e colaboracao; e, minimizar a diferenca entre as equipes, reduzindoo deslocamento de tempo (fuso horario) que afeta a comunicacao sıncrona ou asdiferencas culturais;∙ comunicar o que sera realizado por cada equipe, bem como a responsabilidade de

cada membro, para que todos tenham consciencia do que esta acontecendo, dasdependencias, quem esta realizando determinada atividade e em que local ela estasendo executada. [Audy and Prikladnicki 2008] destacam que essa conscienciae importante, principalmente, sob a perspectiva da documentacao e do codigofonte. Segundo [Carmel and Tija 2005], para aumentar a percepcao podem serutilizadas algumas tecnicas, tais como, o uso de repositorios comuns, sistemaspara controle de projetos, ambientes de desenvolvimento integrados, reunioes destatus, cronograma das equipes e descricao dos processos;∙ gerenciamento hıbrido (centralizado-descentralizado) em relacao ao controle das

atividades, com a definicao de um lıder para estimular a confianca e compromissoentre os membros ([Mullick et al. 2006] e [Avritzer et al. 2008]);∙ encorajar a comunicacao entre desenvolvimento e equipe de teste de integracao

oferecendo artefatos com informacoes relevantes para as duas equipes[Vanzin et al. 2005];∙ especificar a granularidade em que sera realizada a distribuicao (disciplina, com-

ponente, caso de uso, classe ou metodo). Para estabeler a estrategia de distribuicaoos Gerentes de Projeto Global e Local podem considerar alguns pontos, tais como:

1. uma arquitetura de software modular (baixo acomplamento e alta coesao)pode ser utilizada para distribuicao dos esforcos entre as equipes pois, re-

30

duz a complexidade e permite um desenvolvimento em paralelo simplifi-cado [Audy and Prikladnicki 2008];

2. a proximidade de uma equipe do cliente pode ser considerada para adistribuicao da disciplina, no caso Requisitos.

3. as habilidades e competencias das equipes envolvidas (modelagem, teste,implementacao).

Cabe ressaltar, que a estrategia de distribuicao adotada tem impacto direto sobre aintensidade, frequencia e o tipo de coordenacao necessaria entre os participantesdo projeto [Sangwan et al. 2006]∙ desenvolvimento iterativo e com entregas frequentes para fornecer uma

maior visibilidade do projeto aos gerentes ([Paasivaara and Lassenius 2004] e[Taylor et al. 2006]).∙ definir infraestrutura para o controle de versao dos artefatos e da documentacao;∙ definir um repositorio comum a todas as equipes envolvidas no projeto. Os Geren-

tes de Projeto Global e Local devem definir os nıveis de acesso de cada integrantecom base nas atividades que estes desempenham e na responsabilidade que lhe econferida;

O gerente de projetos em conjunto com os desenvolvedores, tambem deve:

∙ detalhar as especificacoes dos casos de uso por meio de restricoes utilizando a Ob-ject Constraint Language (OCL) que e uma linguagem de expressoes textuais pre-cisas, utilizada na descricao de restricoes em modelos orientados a objeto, comoforma de complementar a parte grafica dos modelos, para descrever restricoes, quenao conseguem ser diagramaticamente representadas. A OCL e uma linguagemformal baseada em modelos, que adota uma sintaxe simples, e que utiliza sımbolosmatematicos mais simples da teoria de conjuntos e logica, numa proposta de serprecisa, porem de facil compreensao (escrita-leitura) por quem nao possui conhe-cimento matematico aprofundado. Um dos mais importantes aspectos de OCL eque se tornou parte do padrao Unified Modeling Language (UML). No contextode DDS o uso de OCL permite reduzir a ambiguidade gerada nos artefatos devidoaos fatores culturais.∙ padronizar os artefatos para reduzir a comunicacao entre as equipes e

especificacao de templates para facilitar a efetiva comunicacao entre os membrosdas equipes.∙ adotar metodologias de especificacao de facil compreensao e que possuam

semantica para transmitir informacoes aos desenvolvedores, no caso a UML porser reconhecida tanto no meio academico como industrial [Sengupta et al. 2006];∙ especificar os casos de teste utilizando mecanismo formal para amenizar

os problemas de ambiguidade e reduzir a necessidade de comunicacao[[Mullick et al. 2006], e [Avritzer et al. 2008]]. Para tanto recomenda-se o uso doPerfil UML 2.0 de Testes (U2TP - UML 2.0 Testing Profile), que define uma lin-guagem para projetar, visualizar, especificar, analisar, construir e documentar osartefatos de teste de sistemas. O U2TP e uma linguagem de modelagem de testesque pode ser usada com tecnologias de componentes e linguagens orientadas aobjeto, aplicadas em diversos domınios de aplicacao. Alem disso, as restricoesOCL realizadas nos metodos das classes podem ser utilizadas como oraculo.


31

5. Consideracoes FinaisA busca por maior competitividade tem levado as empresas a adotarem o DDS. Tentandorealizar desenvolvimento a baixo custo, empresas tem atravessado fronteiras, formandoum mercado global. O desenvolvimento distribuıdo pode ser motivado, tambem, porquestoes de qualidade, gerenciamento do controle de producao, domınio de tecnologiasempregadas, reducao da necessidade de grandes contratacoes imediatas ou para transferirconhecimento a uma filial [L’Erario 2009].

Essa mudanca de paradigma tem causado impacto no marketing, na distribuicao ena forma de concepcao, de producao, de projeto, de teste e de entrega do software aosclientes [Sangwan et al. 2006]. Segundo [Damian and Lanubile 2004] para minimizaresses efeitos e alcancar nıveis mais elevados de produtividade sao necessarias novas tec-nologias, processos e metodos compatıveis com a abordagem de desenvolvimento dis-tribuıdo.

Neste trabalho foi identificado um conjunto de recomendacoes relacionados aoprocesso de desenvolvimento de software com equipes distribuıdas. Essas recomendacoestem como objetivo nortear os envolvidos em DDS no que se refere aos processos decomunicacao, coordenacao e controle por meio de atividades que contemplam as pecu-liaridades dessa estrategia de desenvolvimento. Como trabalhos futuros estao previstos:conducao de um estudo de caso; avaliacao experimental das recomendacoes; e, definicaode um processo de desenvolvimento que considere as caracterısticas do DDS.

ReferencesAl-Asmari, K. and Yu, L. (2006). Experiences in distributed software development with

wiki. In Software Engineering Research and Practice, pages 389–293.

Audy, J. and Prikladnicki, R. (2008). Desenvolvimento Distribuıdo de Software: Desen-volvimento de software com equipes distribuıdas. Elsevier, Rio de Janeiro, RJ.

Avritzer, A., Paulish, D., and Cai, Y. (2008). Coordination implications of software ar-chitecture in a global software development project. In WICSA ’08: Proceedings ofthe Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008),pages 107–116, Washington, DC, USA. IEEE Computer Society.

Bazman (2007). The benefits of outsourced testing.http://bazman.tripod.com/outsourced.html.

Carmel, E. and Tija, P. (2005). Offshoring Information Technology: Sourcing and Out-sourcing to a Global Workforce. Cambridge University Press, New York.

Cibotto, R. A. G., Pagno, R. T., Tait, T. F. C., and Huzita, E. H. M. (2009). Uma analise dadimensao socio-cultural no desenvolvimento distribuıdo de software. In V WorkshopUm Olhar Sociotecnico sobre a Engenharia de Software (WOSES), Ouro Preto, MG.

Damian, D. (2002). Workshop on global software development. In ICSE ’02: Proceedingsof the 24th International Conference on Software Engineering, pages 667–668, NewYork, NY, USA. ACM.

Damian, D. and Lanubile, F. (2004). The 3rd international workshop on global softwaredevelopment. In ICSE ’04: Proceedings of the 26th International Conference on Soft-ware Engineering, pages 756–757, Washington, DC, USA. IEEE Computer Society.

32

Fuggetta, A. (2000). Software process: a roadmap. In ICSE ’00: Proceedings of theConference on The Future of Software Engineering, pages 25–34, New York, NY,USA. ACM.

Hargreaves, E. and Damian, D. (2004). Can global software teams learn from militaryteamwork models? In Proc. of 3rd Int. Workshop on Global Software Development,ICSE’04.

Huzita, E. H. M., Silva, C. A., Wiese, I. S., Tait, T. F. C., Quinaia, M., and Schiavone,F. L. (2008). Um conjunto de solucoes para apoiar o desenvolvimento distribuıdo desoftware. In II Workshop de Desenvolvimento Distribuıdo de Software, pages 101–110,Campinas, SP.

Jimenez, M., Piattini, M., and Vizcaıno, A. (2009). Challenges and improvements indistributed software development: A systematic review. Advances in Software Engi-neering, vol. 2009.

Layman, L., Williams, L., Damian, D., and Bures, H. (2006). Essential communicationpractices for extreme programming in a global software development team. Informa-tion and Software Technology, 48(9):781–794.

Leal, G. C. L., Silva, C. A., Huzita, E. H. M., and Tait, T. F. C. (2010). Towards a pro-cess to information system development with distributed teams. In 12th InternationalConference on Enterprise Information Systems, Funchal-Madeira, Portugal.

L’Erario, A. (2009). As aliancas estrategicas no desenvolvimento distribuıdo de software.In XXIX Encontro Nacional de Engenharia de Producao - A Engenharia de Producaoe o Desenvolvimento Sustentavel: Integrando Tecnologia e Gestao, pages 756–757,Salvador, BA.

Mockus, A. and Herbsleb, J. (2001). Challenges of global software development. InMETRICS ’01: Proceedings of the 7th International Symposium on Software Metrics,page 182, Washington, DC, USA. IEEE Computer Society.

Mullick, N., Bass, M., Houda, Z., Paulish, P., and Cataldo, M. (2006). Siemens global stu-dio project: Experiences adopting an integrated gsd infrastructure. In Global SoftwareEngineering, 2006. ICGSE ’06. International Conference on, pages 203–212.

Paasivaara, M. and Lassenius, C. (2004). Using iterative and incremental processes inglobal software development. IEEE Seminar Digests, 2004(912):42–47.

Rocha, R., Arcoverde, D., Brito, D., Aroxa, B., Costa, C., Silva, F. Q. B., J., A., andMeira, S. R. L. (2008). Uma experiencia na adaptacao do rup em pequenas equipesde desenvolvimento distribuıdo. In II Workshop de Desenvolvimento Distribuıdo deSoftware, pages 81–90, Campinas, SP.

Sangwan, R., Bass, M., Mullick, N., Paulish, D. J., and Kazmeier, J. (2006). GlobalSoftware Development Handbook (Auerbach Series on Applied Software EngineeringSeries). Auerbach Publications, Boston, MA, USA.

Sengupta, B., Chandra, S., and Sinha, V. (2006). A research agenda for distributed soft-ware development. In ICSE ’06: Proceedings of the 28th international conference onSoftware engineering, pages 731–740, New York, NY, USA. ACM.


33

Silva, E. L. and Menezes, E. M. (2000). Metodologia da pesquisa e elaboracao dedissertacao. Laboratorio de Ensino a Distancia da UFSC.

Siqueira, F. and Silva, P. S. M. (2006). Recomendacoes para a gerencia de projetos nodesenvolvimento distribuıdo de software. In V Simposio Brasileiro de Qualidade deSoftware, Vila Velha, ES.

Taylor, P. S., Greer, D., Sage, P., Coleman, G., McDaid, K., and Keenan, F. (2006).Do agile gsd experience reports help the practitioner? In GSD ’06: Proceedings ofthe 2006 international workshop on Global software development for the practitioner,pages 87–93, New York, NY, USA. ACM.

Vanzin, M., Ribeiro, M., Prikladnicki, R., Ceccato, I., and Antunes, D. (2005). Globalsoftware processes definition in a distributed environment. In Software EngineeringWorkshop, 2005. 29th Annual IEEE/NASA, pages 57–65. IEEE Computer Society.

Weissleder, S. and Schlingloff, B.-H. (2008). Quality of automatically generated test casesbased on ocl expressions. In ICST ’08: Proceedings of the 2008 International Con-ference on Software Testing, Verification, and Validation, pages 517–520, Washington,DC, USA. IEEE Computer Society.

34

Desafios nas Fases do ciclo de vida de Projetos Distribuídos

Rodrigo Rocha1, Catarina Costa


2, Ryan Ribeiro de

Azevedo1,3, Ivaldir H. F. Junior, Silvio Meira

1

1Centro de Informática – Universidade Federal de Pernambuco (UFPE) 50.732-970 – Recife – PE – Brasil

2Faculdade de Informática – Pontifícia Universidade Católica do Rio Grande do Sul 90.619-900 – Porto Alegre – RS – Brasil

3Universidade Federal do Piauí (UFPI) 64049-550 – Picos – PI – Brasil

{rgcr, csc, rra2, ihfj, srlm}@cin.ufpe.br, [email protected]

Abstract. The Distributed Software Development inherited the problems

existent on the traditional development and for many reasons, added other

difficulties. This paper presents the challenges of each stage of the software

development life cycle on companies. To identify the challenges of the

development stages, a field research was performed on the domestic software

market, through a questionnaire the companies have cited the problems they

face. This way, it's possible to view some of the challenges the domestic

industry faces on each development stage.

Resumo. O Desenvolvimento Distribuído de Software herdou os problemas

existentes no desenvolvimento tradicional e por diversas razões acrescentou

outras dificuldades. Este artigo apresenta quais são os desafios de cada fase

do ciclo de vida do desenvolvimento de software das empresas. Para

identificar os desafios das fases do desenvolvimento foi realizada uma

pesquisa de campo no mercado nacional de software, que através de um

questionário as empresas citaram os problemas que enfrentam. Dessa forma,

é possível visualizar alguns desafios que a indústria nacional enfrenta para

cada fase do desenvolvimento.

1. Introdução

Nos últimos anos, o software se tornou um componente vital nos negócios, as empresas necessitam de software para gerenciar e controlar suas ações, lucros e ganho de competitividade entre seus concorrentes. Diante da demanda por software e pelo crescimento do número de empresas que desenvolvem essas soluções, na década passada, como reflexo da globalização, empresas de software começaram a distribuir seus processos de desenvolvimento em lugares diferentes, criando o desenvolvimento distribuído de software (DDS) (Herbsleb, 2007), também conhecido como desenvolvimento global de software (para projetos que envolvem outros países).

Diversos autores afirmam que o desenvolvimento de sistemas é uma atividade complexa (The Standish Group, 2001), dessa maneira, a abordagem distribuída herdou os problemas existentes na forma tradicional e por diversas razões acrescentou outras dificuldades (Prikladnicki, 2004). Existem vários fatores que podem prejudicar o


35

progresso dos projetos, e um deles é o desenvolvimento de software com equipes geograficamente distribuídas. Diante deste cenário, essa nova forma de fazer negócio ou software, demanda uma alta dependência de comunicação entre os stakeholders, ou mais especificamente os responsáveis pelo design das partes do software que serão desenvolvidas em diferentes localidades (Cataldo et al., 2006).

Inúmeras empresas tentam adotar técnicas, metodologias e ferramentas para que possam lidar da melhor forma com as variáveis do contexto distribuído, variáveis trazidas pela distância geográfica, temporal e cultural entre os membros da equipe global de software. Contudo, é necessário que existam mais estudos para que sejam concebidas novas técnicas, metodologias e ferramentas para ambientes distribuídos (Lopes et al, 2003) (Rocha et al, 2008). Em diversos momentos, as empresas que utilizam esse conceito de desenvolvimento necessitam definir quais metodologias utilizarão em um determinado projeto e suas respectivas práticas, pois estas não provêem de informações que sejam capazes de determinar qual metodologia é mais adequada para determinado tipo de projeto ou quais as práticas mais indicadas para o mesmo.

Além disso, as soluções que são utilizadas para o desenvolvimento tradicional visando diminuir os problemas não têm o resultado esperado quando os participantes do projeto estão separados geograficamente. Dessa maneira, a realização de um projeto distribuído se torna mais difícil pelos fatores que afetam o desenvolvimento tradicional e outros acrescentados pela distribuição geográfica e temporal. Tendo em vista isso, o objetivo principal deste trabalho é identificar quais são os desafios enfrentados pelas equipes distribuídas durantes as fases do ciclo de vida do desenvolvimento distribuído, para isto, este trabalho realizou uma pesquisa de campo com algumas empresas do cenário nacional. A pesquisa foi realizada em 8 empresas localizadas em 5 diferentes estados.

Este trabalho está dividido da seguinte forma: a Seção 2 descreve a metodologia utilizada; na Seção 3 são apresentados os resultados, e com isso os desafios das fases do ciclo de vida são expostos; e por fim, as considerações finais.

2. Metodologia Utilizada

Esta Seção descreve a metodologia utilizada para a realização da pesquisa de campo Pfleeger e Kitchenham (2001), a qual pode ser classificada como quanti-qualitativa (Flick, Kardorff e Steinke, 2000). Foi elaborada uma pesquisa de campo (exploratória) realizada nos meses de janeiro e fevereiro de 2010, através de um questionário com questões abertas, ou seja, do tipo não estruturado, no qual os participantes sabiam que o objetivo da pesquisa era identificar os modelos de colaboração que a indústria nacional utiliza e quais são os principais desafios enfrentados pelos desenvolvedores de software que trabalham no cenário distribuído. A amostra foi do tipo não probabilística (não aleatória) intencional, onde a mesma foi escolhida intencionalmente (Marconi e Lakatos, 1996).

Dez projetos foram analisados, no qual nove pessoas de oito empresas distintas responderam ao questionário. Um funcionário de uma determinada empresa respondeu a dois questionários, referente à sua participação nos dois últimos projetos distribuídos que participou naquela organização. Em uma outra empresa, dois funcionários que

36

participaram de projetos diferentes responderam às questões. Os seis outros projetos foram analisados com base nas respostas de seis funcionários de empresas diferentes.

Os participantes eram de matrizes ou filiais de cinco estados do país, tendo a predominância em Pernambuco (4) e Paraíba (3). Para obter os resultados, após os questionários serem aplicados, houve a tabulação e organização das respostas por afinidade de idéias, resultando como conclusão uma descrição sumária dos relatos de tais profissionais em relação aos problemas que enfrentaram em projetos distribuídos. 3. Resultados Obtidos Nesta seção são apresentados alguns dos resultados obtidos (dados quantitativos e qualitativos) com a realização da pesquisa. A respeito da participação dos entrevistados em projetos distribuídos, dos nove questionados, 7 participaram de um a três projetos e 2 fizeram parte de quatro a seis projetos. Nenhum dos questionados participou de mais do que seis projetos.

Quando questionados à respeito de quanto tempo durou o projeto que o funcionário participou, é possível visualizar que um projeto durou de 1 a 3 meses, três projetos foram entre 4 a 6 meses, e dois duraram de 6 a 12 meses, outros dois projetos tiveram duração de 13 a 24 meses e, os dois projetos restantes acima de 24 meses. Algumas pessoas relataram que seu projeto envolvia países diferentes, sendo 60% (6) dos projetos não envolveram outros países, enquanto 40% (4) foram realizados com a participação de equipes de outros países.

No que se refere às atividades básicas realizadas no desenvolvimento distribuído de software da empresa para o projeto, foi questionado quais atividades foram realizada(s) e se cada atividade foi feita onsite (no cliente), distribuído/offshore (no site distante) ou multisite (em ambos). A fase de Requisitos foi realizada, igualmente, 6 onsite e 6 distribuído; na fase seguinte, Cronograma do Projeto e Planejamento de Releases, 5 foram onsite e 6 distribuídos; em Seleção do Time e Contrato prevaleceu distribuído, com 5, sobre onsite com 4; a fase de Análise conta com 6 onsite e 5 distribuídos; a de Projeto contém 6 em ambos; a fase de Codificação apresentou 4 onsite e 8 distribuídos; a fase de Testes foi a mais referida, sendo 8 onsite e 6 distribuídos; a Garantia de Qualidade foi em sua maioria onsite, com 7, sendo 3 distribuídos; já no Treinamento do Time Distribuído/Offshore, foram 2 onsite e 5 distribuídos; a Avaliação de Usabilidade apresentou 4 onsite e 3 distribuídos e, finalmente, a Implantação, com 4 onsite e 2 distribuídos.

No Gráfico 1 estão descritas todas as fases citadas anteriormente, porém retratando apenas as atividades que foram realizadas multisite, ou seja, onsite e distribuído ao mesmo tempo. A fase de Testes foi a que apresentou mais projetos multisite, com 4; já as fases de Requisitos, Cronograma do Projeto e Planejamento de Releases e a de Projeto tiveram 3 cada uma; Análise e Codificação com 2 e Seleção do Time e Contrato, Garantia de Qualidade, Treinamento do Time Distribuído/Offshore e a Avaliação de Usabilidade apresentaram apenas 1, enquanto que a fase de Implantação não apresentou projetos multisite.

Gráfico 1 – Atividades realizadas Multisite


37

0 0,5 1 1,5 2 2,5 3 3,5 4

Imp.

Usab.

Trein.

Qual.

Testes

Codificação

Projeto

Análise

Sel. Time

Cron. Proj. e Plan. Rel.

Requisitos

Fases Multisite

3.1 Desafios das Fases do DDS

Numa pesquisa baseada em questionários abertos, é costume coordenar as respostas através de uma organização de idéias por temas afins, visto que o volume de informações retornado é grande. É uma forma de tipificar as respostas dos entrevistados. Portanto, uma vez definidos os temas, as idéias de cada entrevistado foram reorganizadas de acordo com o tema a que pertencem. Dessa maneira, as Tabelas 1, 2, 3, 4 e 5 apresentam os desafios encontrados (já classificados) em cada fase do desenvolvimento distribuído extraídos da pesquisa de campo. Tais desafios dizem respeito às atividades sendo executadas de forma onsite, distribuída e multisite.

A Tabela 1 apresenta os desafios encontrados durante a fase de Requisitos que é um momento importante do ciclo de vida, já que é a fase em que todos os objetivos e necessidades do cliente devem ficar bem claros. A maioria das respostas dos participantes citava a dificuldade na comunicação de uma forma geral, inclusive dificuldades entre a própria equipe. Um desafio interessante foi o fato de existirem clientes que não se comprometem ou que não dão prioridade ao projeto.

Tabela 1 – Fase Requisitos

Requisitos

Temas Afins Desafios

Comunicação Demora para resposta via e-mails Falhas na comunicação via áudio através de chats Custo de telefonemas Conferência via áudio não suportava muitos usuários Idioma utilizado

Encontros presenciais Necessidade de mais encontros presenciais para esclarecimento de dúvidas cruciais

Equipe Falta de entrosamento das equipes Concorrência entre os engenheiros do projeto Necessidade em alguns momentos que houvesse

38

uma decisão tomada por alguém mais experiente na equipe, para que não restassem dúvidas ou especulações

Cliente Falta de comprometimento e prioridade Aprovação dos requisitos por parte do cliente

demandava tempo que, em alguns momentos não existia

Durante a atividade de Cronograma e Planejamento de releases (Tabela 2) os maiores desafios foram encontrados na própria equipe, principalmente para conseguir um consenso geral sobre as datas que são acordadas entre os times. Durante a fase de Seleção do Time e Contrato, existiram problemas de mão de obra, tanto por profissionais qualificados como especialistas em determinadas tecnologias. Outro desafio é definir o time e as funções de cada um.

Tabela 2 – Fase Cronograma do Projeto e Planejamento de Releases

Cronograma do Projeto e Planejamento de Releases

Temas Afins Desafios Equipe Alinhamento de todos os stakeholders

Consenso geral sobre as datas acordadas Sincronizar releases entre sites que fossem integrar o software final

Dispersão Sequenciar atividades com equipes distribuídas

Durante a fase de análise (Tabela 3), os principais problemas eram de comunicação, principalmente na troca de informação das equipes e na forma como isso ocorria, como por exemplo a definição dos meios de comunicação e os procedimentos necessário para tal. Na fase do Projeto, como em outras fases a comunicação novamente foi o principal desafio. Outro desafio citado pelos participantes foi a interação do cliente com os desenvolvedores durante essa fase.

Tabela 3 – Fase Análise

Análise


Comunicação Demora para resposta via e-mails Falhas na comunicação via áudio através de chats Conferência via áudio não suportava muitos usuários Dificuldade para organizar uma conferência via áudio Idioma utilizado

Processo de Software Seguir adequadamente o processo O processo de software não abrangia momentos

específicos Cliente Demora para validar alguns diagramas e decisões

A fase de codificação (Tabela 4) apresentou diversos problemas, e muitos deles foram citados por quase todos os participantes, como o problema de código fonte, por exemplo, no sentido de padronização de código e a questão do tamanho e complexidade do projeto que também foi bastante citado.


39

Tabela 4 – Fase Codificação

Codificação


Comunicação Demora para respostas em geral Idioma utilizado

Equipe Falta de conhecimento por parte do time sobre quem é o maior especialista da equipe naquela parte do código fonte Falta de conhecimento, sobre quem está fazendo o que

Código fonte Dificuldade em padronização de código Problemas com o entendimento da arquitetura do software por partes dos membros da equipe Tamanho e complexidade do projeto

Motivação Falta de motivação dos membros das equipes Delegação de tarefas

Dificuldade em delegar atividades para perfis desconhecidos

A Tabela 5 apresenta os desafios encontrados durante a fase de testes. É possível afirmar que deve haver um maior planejamento dos testes e também da forma que eles serão executados. Já que essa não é uma tarefa trivial quando o projeto é distribuído.

Tabela 5 – Fase Testes

Testes


Comunicação Demora para resposta via e-mails Idioma utilizado

Stakeholders Definição de responsabilidades, difícil determinar a fronteira das atividades dos membros

Plano de Testes Definir planos de testes e executá-los, de forma que todos os envolvidos participassem efetivamente dos testes

Ambiente Problema de ambiente Complexidade Complexidade dos testes Equipes Dependência de equipes externas

Com relação à atividade de treinamento do time distribuído, os maiores problemas encontrados foram no idioma utilizado. Em alguns momentos, a documentação era incoerente com o treinamento e em certos pontos o treinamento era bastante superficial. Na fase de garantia de qualidade, os desafios encontrados foram a confiança, que vai diminuindo entre os stakeholders durante a execução do projeto, bem como problema para definir quais seriam os requisitos de qualidade e os parâmetros para a sua medição, já que muitas pessoas envolvidas geram muitos interesses diferentes. Durante a fase de implantação, um problema pode ser destacado, que é a dificuldade que existe para saber o contexto do cliente de forma remota, ou seja, quais são os recursos e tecnologias que eles possuem.

A partir dos resultados da pesquisa de campo, é possível afirmar que:

• Os fatores que afetam as fases do desenvolvimento distribuído de software são conhecidos pelas organizações e pelos pesquisadores do meio;

• A comunicação é um fator que gera problema em quase todas as fases do

40

desenvolvimento, o que pode tornar esse fator o mais importante; • Algumas fases como a de codificação, por exemplo, apresentaram muitos

problemas que na verdade não tem relação com o contexto distribuído, e sim com o próprio desenvolvimento de software. Tal como, o desafio: “Dificuldade em delegar atividades para perfis desconhecidos”;

• As fases que mais apresentaram desafios/problemas foram as de requisitos e codificação;

• Nas tabelas, algumas fases possuem menos problemas, isso porque as respostas foram repetidas/semelhantes e também pelo fato de que nem toda empresa utilizava aquela fase em seu(s) projeto(s);

• A fase de Testes é mais realizada de forma multisite, seguida das fases de Requisitos, Cronograma do Projeto e Planejamento de Releases e Projeto;

• Os fatores que afetam não são específicos de um projeto, eles são comuns entre projetos e empresas;

• Idioma se manteve como um problema constante nos projetos que envolviam outros países;

• Na fase de requisitos muitos participantes responderam que o time precisa de um melhor entrosamento;

Através da pesquisa algumas constatações foram feitas, como vistas acima. Essas constatações, assim como outras, servem como base para novas pesquisas e novos estudos, onde soluções podem ser propostas visando mitigar esses fatores. Como o caso do desafio “Falta de conhecimento por parte do time sobre quem é o maior especialista da equipe naquela parte do código fonte” que é um problema que pode ser auxiliado através da ferramenta Presley (Trindade et al, 2009), pois os stakeholders possuem conhecimento de quem fez tal rotina/funcionalidade, e assim podem trocar informações valiosas sobre o código fonte durante o projeto. Assim como esse, alguns desafios já possuem soluções, porém a maioria desses problemas ainda precisam ser solucionados.

4. Considerações Finais

No cenário distribuído, projetos de software assumem perspectivas diferentes e, consequentemente, novos riscos. Se não houver um bom conhecimento dos fatores que podem influenciar o projeto, o mesmo terá mais chances de não obter sucesso.

Seria ideal ter um número mais significativo de empresas participando, bem como de estados também. Dessa maneira, seria possível ter um panorama que representaria de fato a perspectiva nacional, no sentido dos problemas que projetos distribuídos de software enfrentam em suas fases de desenvolvimento. O questionário aberto se mostrou muito interessante, pois os participantes podem descrever suas respostas e isso torna de certa forma, as informações mais ricas. Por outro lado, quando os participantes visualizam um questionário aberto, eles percebem que terão que perder mais tempo, tentando lembrar e compilar todas as informações que vivenciaram, dessa forma, isso os inibe um pouco e pode também prejudicar a riqueza das respostas, já que os mesmos podem não se comprometer da melhor forma possível.

Os desafios encontrados nas atividades do desenvolvimento distribuído de software são diferentes do desenvolvimento tradicional de software, porém, conhecidos há algum tempo pela comunidade de DDS. Portanto, tais problemas, já conhecidos,


41

poderiam ter soluções já conhecidas, mas talvez por ser uma área ainda imatura, ainda está sendo explorada. Os resultados dessa pesquisa podem ser de grande relevância para que empresas nacionais e internacionais utilizem processos, técnicas, boas práticas e metodologias que se adequem às limitações identificadas. Espera-se também, com a realização da pesquisa, incentivar outros estudos que favoreçam a diminuição de falhas desses projetos. Alguns trabalhos podem ser desenvolvidos futuramente a partir deste estudo, como: estudos e pesquisas mais aprofundados sobre os fatores que influenciam cada fase do desenvolvimento distribuído, a fim de identificar maneiras para lidar com tais problemas; classificação de todos os fatores existentes que influenciam o DDS em fatores humanos, técnicos e organizacionais, com objetivo de estabelecer uma maior consolidação desses fatores.

Referências

Cataldo, Marcelo., Bass, Matthew., Herbsleb, James., Bass, Len. (2006). Managing Complexity in Collaborative Software Development: On the Limits of Modularity. Workshop on Supporting the Social Side of Large-Scale Software Development, Conference on Computer Supported Cooperative Work (CSCW'06), Banff, Alberta, Canada.

Flick, U., von Kardorff, E. e Steinke, I. (2000). Was ist qualitative Forschung? Einleitung und Uberblick. pp. 13-29. Reinbek: Rowolht.

Herbsleb, J. D. (2007). Global Software Engineering: The Future of Socio-technical Coordination. IEEE Computer Science. p188-198.

Lopes, Leandro; Prikladnicki, Rafael; Majdenbaum, Azriel; Audy, Jorge. (2003). Uma proposta para processo de requisitos em ambientes de desenvolvimento distribuído de software. In: 6th WER, Piracicaba. Brasil. p. 329-342.

Marconi, Mariana de Andrade; Lakatos, Eva Maria. (1996). Técnicas de pesquisa. 3 ed. São Paulo : Atlas. 231 p.

Pfleeger, S. and Kitchenham, B. (2001). Principles of survey research: part 1: turning lemons into lemonade. ACM SIGSOFT Software Engineering Notes, 26(6):44–45.

Prikladnicki, R.; Audy, J. (2004). Munddos: Um Modelo de Referência para Desenvolvimento Distribuído de Software. 18º Simpósio Brasileiro de Engenharia de Software.

Rocha, R. Arcoverde D. Brito, R. Aroxa, B. Costa, C. Silva, F. Q. B. Albuquerque, J. Meira, S. R. L. (2008). Uma experiência na adaptação do RUP para pequenas equipes de desenvolvimento distribuído. II Workshop de Desenvolvimento Distribuído de Software (SBES-SBBD). p. 87-96.

The Standish Group. (2001). CHAOS 2001: A Recipe for Success.

Trindade, C., Moraes, A., Barbosa, Y., Albuquerque, J., Meira, S. (2009). Presley: uma Ferramenta de Recomendação de Especialistas para Apoio à Colaboração em Desenvolvimento Distribuído de Software. XXIII Simpósio Brasileiro de Engenharia Software, Fortaleza. XXIII Simpósio Brasileiro de Engenharia Software, Sessão de Ferramentas.

42

Um Framework de Recomendação para Alocação de Equipes de Desenvolvimento em

Projetos Distribuídos de Linhas de Produto de Software

Vinicius S. dos Santos, Thaís A. B. Pereira, Bruno Luna Ribeiro, Glêdson Elias

COMPOSE – Component Oriented Software Engineering Group Departamento de informática, Universidade Federal da Paraíba

João Pessoa, Paraíba, Brasil

{vinicius, thais, bruno}@compose.ufpb.br, [email protected]

Abstract. Software Product Line (SPL) and Distributed Software Development (DSD) approaches have been adopted by many companies to improve software quality, finding more qualified manpower, and reduce development costs and time. However, in such a scenario, teams allocation is not a trivial task, because it has to take into account properties of the software project, the teams and the context in which they are immersed. Thus, the framework proposed in this paper aims to provide recommendations on how to allocate teams to software components in distributed SPL projects by considering technical and non-technical aspects.

Resumo. Abordagens de Linhas de Produto de Software (LPS) e de Desenvolvimento Distribuído de Software (DDS) vêm sendo adotadas pelas empresas a fim de melhorar a qualidade do software, encontrar mão-de-obra mais qualificada, e reduzir custos e tempo de desenvolvimento. Contudo, a alocação de equipes de desenvolvimento num cenário desse tipo não é trivial, pois deve levar em consideração características do projeto de software, das equipes e do contexto onde as mesmas se encontram. Assim, o framework proposto neste artigo tem o objetivo de prover recomendações sobre como alocar equipes aos componentes de software em um projeto distribuído de LPS, considerando aspectos técnicos e não técnicos.

1. Introdução

Nos últimos anos, a busca por melhores oportunidades de negócio, seja para reduzir custos de desenvolvimento ou alavancar vendas, bem como a escassez de profissionais qualificados, têm motivado a indústria de software a adotar abordagens de Desenvolvimento Distribuído de Software (DDS) [Gumm, 2006]. Nesse cenário caracterizado pela crescente complexidade dos produtos e do número de profissionais engajados, de acordo com [Paulish, 2003], Linhas de Produto de Software (LPS) contribuem para o planejamento e o gerenciamento de projetos distribuídos, uma vez que favorecem a definição de componentes de software bem estruturados, que podem ser paralelamente desenvolvidos por equipes geograficamente dispersas.

De fato, o desenvolvimento baseado em componentes promove a modularização da arquitetura, tornando o trabalho desempenhado pelas equipes de desenvolvimento menos dependente entre si [Ghezzi et al., 2003]. Apesar disso, componentes mantêm certa dependência com outros componentes, ainda que estes sejam realmente bem projetados, já que devem ser integrados para as aplicações serem instanciadas, o que exerce influência sobre a necessidade de interação (ou comunicação) entre suas respectivas equipes de desenvolvimento [Sosa et al., 2002]. Por sua vez, a comunicação


43

entre equipes geograficamente distribuídas pode não ser fácil, eficiente e efetiva, devido às inúmeras diferenças que podem existir entre elas, em termos de disponibilidade, recursos, conhecimento técnico e valores sócio-culturais [Herbsleb, 2007]. Assim, a qualidade dos produtos pode ser comprometida e o cronograma de atividades pode ser consideravelmente afetado, levando ao aumento de custos de desenvolvimento. Nesse contexto, estratégias para aprimorar a alocação de equipes às atividades de desenvolvimento de software exercem um papel de grande relevância.

Conforme observado em [Shen et al., 2002], processos de alocação de equipes em projetos de software geralmente se baseiam na capacidade técnica das equipes (ou pessoas) e nas exigências das tarefas a serem desenvolvidas. Contudo, essa estratégia não é suficiente, pois como evidenciado, não somente a habilidade técnica das equipes influi na qualidade do trabalho por elas desempenhado, mas também a qualidade da comunicação entre equipes. Dessa forma, estratégias de alocação também devem buscar minimizar a necessidade de comunicação entre as equipes, bem como mitigar a dificuldade destas em estabelecer comunicação efetiva, uma vez que inevitavelmente sempre existirá comunicação. Visando atender essa necessidade, o presente artigo propõe um framework de recomendação para a alocação de equipes de desenvolvimento para a implementação de projetos distribuídos de LPS, que levam em consideração características do software, das equipes e do contexto onde as mesmas se encontram.

O restante do artigo está estruturado da seguinte maneira. A Seção 2 apresenta o framework proposto. A Seção 3 aborda os trabalhos relacionados, ressaltando as principais contribuições do framework proposto. Por fim, a Seção 4 apresenta as considerações finais e os trabalhos futuros.

2. Framework de Recomendação

O framework proposto visa oferecer suporte à tomada de decisão por parte do gerente de projeto sobre como alocar equipes de desenvolvimento para implementar os componentes de software de um projeto de desenvolvimento de LPS. Para tal, considerando o conjunto de equipes de desenvolvimento � = {e1, e2, …, ex} que podem participar do projeto, o framework é constituído por quatro fases, conforme ilustrado na Figura 1, que geram três tipos de recomendações:

i. Recomendação de módulos: um conjunto de módulos de software � ={m1, m2, …, mn} fracamente acoplados entre si, mas constituídos por componentes fortemente acoplados, que podem ser implementados de forma independente;

ii. Recomendação de equipes: um mapeamento EM = {��, ��|� ∈ � ∧ �� ⊆ �} de cada módulo de software � para o subconjunto �� de equipes que são tecnicamente habilitadas a implementar cada módulo;

iii. Recomendação de alocação: um conjunto soluções de alocação � = {��, ��| � ∈ � ∧ � ∈ ��} de cada módulo de software � a uma equipe e pertencente ao conjunto de equipes tecnicamente habilitadas ��.

A fase de análise da arquitetura visa apoiar o engenheiro de software: (i) na definição do conjunto � = {m1, m2, …, mn} de módulos fracamente acoplados, constituídos por componentes fortemente acoplados entre si; e (ii) na avaliação da dependência entre módulos, identificando a necessidade de comunicação entre equipes. Para tal, essa fase recebe como entrada as descrições estática e dinâmica da arquitetura da LPS, que pode ser tanto o projeto do domínio quanto de uma aplicação específica. Para identificar os módulos e suas dependências, esta fase adota um algoritmo de agrupamento, que explora a técnica de DSM (Design Structure Matrix) juntamente com

44

métricas arquiteturais do projeto. Uma DSM consiste numa matriz que representa os componentes do projeto e as dependências existentes entre eles [Yassine 2004].

Uma vez que os módulos foram identificados na primeira fase, a fase de avaliação técnica deve: (i) caracterizar os módulos em termos dos requisitos técnicos necessários para implementá-los; (ii) caracterizar as equipes em termos de conhecimentos técnicos requisitados para implementar os módulos; e, (iii) recomendar o mapeamento �� = {��, ��| � ∈ � ∧ �� ⊆ �}, associando cada módulo de software � ao subconjunto de equipes �� que são tecnicamente habilitadas para implementá-lo. Nesta fase, algoritmos, regras e políticas baseadas em lógica nebulosa (fuzzy) [Zadeah 1965] são adotados para avaliar os aspectos técnicos de módulos e equipes, e, assim, recomendar as equipes tecnicamente habilitadas para cada módulo.

Considerando que as dependências entre módulos e as equipes tecnicamente habilitadas já foram identificadas na primeira e segunda fase, respectivamente, a fase de avaliação não-técnica tem o propósito de: (i) caracterizar as equipes candidatas � = {e1, e2, …, ex} segundo seus atributos não-técnicos, tais como localização, língua e disponibilidade, dentre outros atributos relevantes no contexto de DDS; (ii) identificar a necessidade de comunicação entre equipes segundo as dependências entre módulos e o mapeamento entre módulos e equipes; (iii) identificar a viabilidade de comunicação entre as equipes com base nos atributos não técnicos; e finalmente, (iv) gerar o conjunto de recomendações de alocação � = {��, ��|� ∈ � ∧ � ∈ ��}, que atribui cada equipe específica � à um módulo de software �. Para tal, esta fase fundamenta-se na heurística de algoritmos genéticos [Holland 1975] para recomendar soluções aproximadas, resultando em uma abordagem computacionalmente menos dispendiosa quando comparada com algoritmos que buscam a solução ótima.

Após a alocação das equipes e a conclusão da implementação do projeto, a fase de avaliação do desempenho das equipes deve qualificar o desempenho das equipes alocadas, tanto em termos técnicos, verificando se o trabalho que lhes foi designado foi realizado adequadamente, quanto em termos não técnicos, avaliando como se sucedeu o relacionamento entre as equipes. Com base em tal avaliação, as descrições técnicas e não-técnicas das equipes são refinadas, melhorando a qualidade das recomendações geradas pelo framework em projetos posteriores.

Recomendaçãode módulos

Recomendação de alocação de equipes

Recomendaçãotécnica de equipes

Análise da Arquitetura

Avaliação não-técnica

Avaliação técnica

IMPLEMENTAÇÃO DOS MÓDULOS

Avaliação do desempenho das equipes

Feedback

MódulosDependência entre módulos

Alocações

Mapeamento equipes x módulos

Descrição estática e/ou dinâmica da arquitetura

Figura 1. Visão geral do framework


45

2.1. Análise da arquitetura

Admitindo que dependências entre componentes de software exercem influência sobre a comunicação entre equipes de desenvolvimento, a fase de análise da arquitetura tem dois objetivos: identificar módulos fracamente acoplados, constituídos por componentes fortemente acoplados entre si; e medir o grau de dependência entre módulos.

A fim de atender a tais objetivos, nessa fase é empregada a técnica de DSM, que foi originalmente definida para apoiar o desenvolvimento de produtos na engenharia, como a indústria automotiva. A justificativa é que essa técnica facilita a visualização de dependências, bem como a realização de operações de agrupamento. Uma DSM consiste em uma matriz quadrada na qual as colunas revelam fontes de entrada para os componentes nas linhas e a existência de dependência entre pares de componentes é representada através de um símbolo ou valor binário (DSM binária), ou através de um valor numérico (DSM numérica), que consiste no peso da dependência.

Com base nisso, a fase de análise da arquitetura define métricas arquiteturais que devem ser utilizadas para mensurar o peso da dependência entre pares de componentes e assim construir a DSM do projeto (DSM numérica). Tais métricas estão baseadas na especificação estática e dinâmica da arquitetura, e expressam o acoplamento entre componentes sob diferentes perspectivas: a afinidade ou semelhança entre a funcionalidade oferecida pelos componentes, segundo as features que estes contemplam; a taxa de uso de um componente em termos de interfaces providas e requeridas e também de serviços providos e requeridos; o tipo de comunicação entre serviços (ex., síncrona ou assíncrona); e a intensidade de comunicação em termos do número de mensagens. A fim de que sejam consideradas as propriedades de variabilidade e opcionalidade de LPS, o uso das métricas deve ser feito de maneira coordenada, segundo as orientações também oferecidas nessa fase.

Além disso, esta fase define o algoritmo de agrupamento a ser empregado sobre a DSM para gerar módulos de componentes. Algoritmos de agrupamento para DSM em geral operam segundo a definição de uma função objetivo, que expressa o custo de uma configuração de componentes, e de uma estratégia de busca, que visa encontrar o menor valor possível para essa função. O algoritmo adotado consiste em uma adaptação do algoritmo de agrupamento de equipes, proposto em [Thebeau, 2001] para o contexto de componentes de software, através da reformulação da função de custo. A DSM agrupada resultante representa os módulos segundo os seus componentes constituintes e suas dependências internas (entre componentes em um mesmo módulo) e externas (entre componentes em módulos diferentes). Uma vez que os módulos são identificados, a dependência existente entre eles é mensurada, resultando no modelo de dependência entre módulos, que consiste em uma DSM cujas células representam a dependência entre pares de módulos de software, abstraindo os componentes internos aos módulos. O cálculo da dependência é realizado através de métricas similares àquelas usadas para medir a dependência entre componentes.

2.2. Avaliação técnica

A fase de avaliação técnica têm o objetivo de gerar um conjunto de recomendações de equipes que são tecnicamente hábeis para implementar os módulos de software identificados na primeira fase. Para alcançar tal objetivo, se faz necessário: descrever os módulos através dos requisitos técnicos necessários para sua implementação; descrever as equipes em termos de suas habilidades técnicas; e identificar as equipes mais capacitadas para implementar cada módulo com base na avaliação das informações destas e dos módulos.

46

A descrição dos módulos é feita com a criação do modelo de descrição técnica dos módulos. Esta atividade é realizada pelo arquiteto de software que descreve quais domínios e tecnologias (ferramentas, linguagens, etc.) estão envolvidas na implementação dos módulos, bem como os respectivos graus de conhecimento necessários para implementá-los. Por se tratar de uma LPS, também devem ser considerados aspectos sobre pontos de variação e componentes variantes, bem como identificar quais componentes do módulo fazem parte da arquitetura de referência e quais são de aplicações específicas.

Na descrição das equipes são utilizados formulários parar coletar informações sobre a experiência em projetos de DDS, bem como em projetos de LPS, englobando quantidade e complexidade dos projetos já realizados; conhecimento acerca do domínio dos projetos; habilidades tecnológica das equipes para atender aos requisitos definidos pelos módulos de software, tais como conhecimento em tecnologias, ferramentas, processos e certificações. A partir dessa descrição é gerado o modelo de descrição técnica das equipes. Como equipes se envolvem em vários projetos ao longo do tempo, esse modelo é atualizado cada vez que uma equipe se engaja em um projeto diferente.

Mensurar conhecimento ou experiência é uma tarefa subjetiva, uma vez que envolve aplicação de formulários, os quais são elaborados e respondidos segundo critérios humanos. Assim, um algoritmo de lógica nebulosa (fuzzy) é utilizado para lidar com tais imprecisões, já que o mesmo permite avaliar atributos por meio de termos com significado vago, como baixo, médio ou alto (termos difusos).

A avaliação técnica tem por base um conjunto de regras, representando políticas a serem adotadas para a seleção das equipes, que cruzam informações das equipes e módulos, produzindo uma métrica de adequabilidade técnica. Tais políticas são definidas numa matriz, onde as colunas representam os requisitos demandados pelos módulos e as linhas, as habilidades apresentadas pelas equipes. As células representam a adequabilidade técnica das equipes para implementar o módulo. Utilizando os termos difusos, o gerente de projeto pode alterar o conjunto de regras, refinando as políticas para atenderem às necessidades específicas de cada projeto. Por exemplo, se a política da organização é poupar equipes mais experientes para trabalhos mais difíceis, o processo de avaliação definirá como adequadas equipes que possuírem conhecimentos mais próximos aos demandados pelos módulos. Por outro lado, se o gerente deseja finalizar o projeto o mais rápido possível, o conjunto de regras é alterado de forma que equipes com qualificações mais altas sejam sempre mais adequadas.

2.3. Avaliação não-técnica

A fase de avaliação não-técnica é constituída por duas etapas, descrição não-técnica das equipes e alocação de equipes. A descrição não-técnica consiste na coleta de informações sobre o contexto em que se encontram as equipes, tais como os seus atributos geográfico, temporal, cultural e de reputação. Atributos geográficos representam a localização da equipe em diferentes perspectivas, como país, estado e cidade. Atributos temporais estão relacionados às horas de trabalho por dia e fuso horário, determinando segmentos de tempo de trabalho, que também são empregados para verificar a possibilidade de comunicação síncrona e assíncrona. Já os atributos culturais fazem referência aos idiomas que as equipes dominam e às características que representam costumes e padrões organizacionais de seus respectivos ambientes de trabalho. Por fim, a reputação especifica o quão boa é a interação entre equipes com base em trabalhos anteriores.


47

A etapa de alocação das equipes compreende a atividade de gerar recomendações sobre como alocar as equipes aos módulos de software, considerando a dependência existente entre os módulos (modelo de dependência entre módulos), a habilidade técnica das equipes em desenvolver cada módulo (modelo de mapeamento entre módulos e equipes) e o contexto do relacionamento entre as equipes (modelo de descrição não-técnica das equipes). Devido à grande quantidade de possíveis soluções, é usada a heurística de algoritmos genéticos. Dessa forma, inicialmente, as soluções são avaliadas com base nos atributos não-técnicos, sendo posteriormente melhoradas com operações de algoritmos genéticos, os quais também produzem mais soluções. O novo conjunto de solução é então avaliado com base no modelo de dependência entre módulos, a fim de que sejam comparadas as equipes que estão alocadas à módulos relacionados, realizando novas iterações até que o conjunto de soluções evolua e as mesmas sejam consideradas boas soluções de alocação.

Por exemplo, se módulos muito dependentes entre si são alocados às equipes A e B, é pressuposto que haverá maior necessidade de comunicação entre tais equipes. Assim, é preciso verificar a capacidade destas em estabelecer comunicação efetiva, conforme seus atributos não-técnicos. Se a equipe A só pode se comunicar em inglês e a equipe B apenas em espanhol, tais equipes provavelmente enfrentarão bastante dificuldade de comunicação, já que precisão aprender em curto prazo um novo idioma. No entanto, se a equipe A também conhece a língua espanhola, embora apenas em termos de leitura e escrita, as equipes podem estabelecer comunicação com relativa facilidade através de chat e e-mail. Nessa situação, a viabilidade da comunicação é então definida pela disponibilidade das equipes em termos de fuso-horário e horário de trabalho, já que chat exige que as equipes estejam conectadas no mesmo instante, ao contrário de e-mail. Uma vez geradas as recomendações, cabe ao gerente de projeto avaliá-las, modificá-las e escolher, com base em sua experiência e conhecimento, aquela mais adequada de acordo com os objetivos e características do projeto.

2.4. Avaliação do desempenho das equipes

A avaliação do desempenho das equipes tem o propósito de refinar as descrições técnica e não-técnica das equipes sempre que estas finalizam um projeto por intermédio do gerente do projeto, a fim de melhorar a qualidade das recomendações geradas pelo framework. Para tanto, essa etapa também introduz os atributos de reputação técnica e de interação, que são coletados através de questionários submetidos ao gerente de projeto e às equipes, respectivamente. A reputação técnica diz respeito à implementação dos módulos, e objetiva capturar aspectos como a qualidade final dos módulos implementados e o tempo gasto para desenvolvê-los. Já a reputação de interação diz respeito à satisfação das equipes ao se comunicarem com outras equipes em cada projeto, definida com base na dificuldade enfrentada por elas para estabelecer comunicação (devido às diferenças de horário e idioma, por exemplo).

3. Trabalhos correlatos

A alocação de equipes de desenvolvimento no contexto de DDS, e em particular de LPS, é algo que ainda é feito essencialmente com base na experiência do gerente do projeto, sendo escassas as abordagens que visam auxiliar nessa tarefa de forma realmente eficiente. Embora o framework proposto esteja focado na alocação de equipes geograficamente dispersas na atividade de implementação de uma LPS, aqui são considerados trabalhos de alocação de equipes no contexto de DDS em geral (ou numa perspectiva contrária, de alocação de atividades às equipes).

48

Em [Paulish, 2003] é apresentado um processo para desenvolvimento de LPS no qual somente a atividade de implementação é distribuída entre equipes geograficamente dispersas, que são coordenadas por uma equipe central. Nesse processo, a separação de unidades de implementação é feita na perspectiva de componentes de software, sendo definidas sobre eles algumas restrições em termos de tempo e esforço de desenvolvimento. A alocação das equipes aos componentes é feita considerando a habilidade técnica das equipes a cerca da funcionalidade dos componentes e as restrições definidas. Dessa forma, ao contrário do framework proposto, esse processo não considera as dependências entre componentes de software e os aspectos não técnicos das equipes, que são introduzidos pela separação geográfica.

Visando reduzir a necessidade de comunicação entre equipes de desenvolvimento, ocasionada por requisições de modificação de arquivos de implementação, em [Mockus e Weiss, 2001] é apresentado um algoritmo para encontrar a atribuição ótima de agrupamentos de arquivos em locais de desenvolvimento. Nesse modelo, o custo de uma configuração de agrupamento de arquivos é avaliado com base no fluxo de requisições de modificação entre locais. Contudo, não é discutida a alocação dos agrupamentos de arquivos aos locais, nem tampouco os atributos dos locais e dos arquivos que podem influir na quantidade de requisições de modificação, tornando o algoritmo insuficiente para ser adotado como base para definir boas soluções.

A fim de confrontar diferentes estratégias para alocação de tarefas em DDS, em [Setamanit et al., 2007] foi desenvolvido um modelo que simula a colaboração entre locais e os efeitos da comunicação distribuída, segundo os critérios de diferença de fuso-horário, freqüência de contato, recursos disponíveis, diferenças culturais e distância. Apesar disso, o modelo não considera as dependências entre as tarefas, e também não oferece um algoritmo que busque encontrar a solução ótima de alocação.

Por fim, tal como o framework proposto, em [Lamersdorf e Munch, 2009] é apresentada uma ferramenta que gera um conjunto de sugestões de alocação de tarefas (projeto, implementação e teste) de desenvolvimento de software à equipes distribuídas geograficamente. Nessa ferramenta, as sugestões levam em conta o custo de se executar uma tarefa em um local, o custo de comunicação entre tarefas em locais diferentes com base em diferenças culturais e de fuso-horário entre as equipes e o acoplamento entre tarefas. Além disso, sugestões são ordenadas de acordo com a prioridade definida pelo gerente (custo, tempo de desenvolvimento ou qualidade). O trabalho, contudo, não descreve como são derivados os valores no qual as sugestões estão baseadas, o que torna impossível a completa avaliação do mesmo.

4. Considerações finais

Em projetos de desenvolvimento distribuído de LPS, a alocação de equipes de desenvolvimento aos componentes de software é uma tarefa complexa, geralmente deixada a cargo do gerente do projeto, para o qual falta o suporte adequado para analisar as inúmeras possibilidades existentes. Dessa forma, o presente artigo descreve uma abordagem sistemática de recomendar alocações de equipes, que prioriza a redução da necessidade de comunicação e das dificuldades geralmente enfrentadas para se comunicar efetivamente nesse cenário, e que por sua vez afetam a qualidade dos componentes resultantes.

Um aspecto bastante interessante do framework proposto é a independência entre as quatro fases que o compõe. Levando em consideração que os artefatos de entrada e saída das várias fases são claramente definidos, é possível a evolução ou até mesmo a mudança das técnicas e algoritmos empregados em qualquer uma delas, sem


49

introduzir qualquer impacto nas demais. Além disso, também é possível acrescentar novas fases, por exemplo, para tratar aspectos de negócio com o objetivo de minimizar os custos ou o tempo de desenvolvimento.

Ao adotar o conceito do framework, a abordagem pode ser vista como uma orientação estruturante do processo de alocação de equipes, que deve ser instanciada e personalizada para cada projeto de LPS no contexto de DDS. Nesta direção, a instanciação do framework em um projeto real de desenvolvimento de LPS está sendo iniciada para refinar e validar as várias fases e etapas do framework. Após a validação da proposta, também é planejado o desenvolvimento de ferramentas para automatizar as suas fases e etapas, bem como a introdução de uma fase para tratar aspectos de negócio, incluindo custo e tempo de desenvolvimento.

Agradecimentos. Este trabalho foi apoiado pelo Instituto Nacional de Ciência e Tecnologia para Engenharia de Software (INES)1 e financiado pelo CNPq, processo 573964/2008-4.

Referências Ghezzi, C. et al. (2003) “Fundamentals of Software Engineering”, Prentice Hall PTR.

Gumm, D.C. (2006) Distribution Dimensions in Software Development Projects: A Taxonomy, IEEE Software, 23(5), pp. 45-51.

Herbsleb, J.D. (2007) “Global Software Engineering: The Future of Socio-technical Coordination”, International Conference on Software Engineering.

Holland, J. H. (1975). “Adaptation in natural and artificial systems”. Ann Arbor, MI: The University of Michigan Press.

Lamersdorf, A., Munch, J. (2009) “TAMRI: A Tool for Supporting Task Distribution in Global Software Development Projects”, 4th IEEE international Conference on Global Software Engineering, pp. 322-327.

Mockus, A., Weiss, D. M. (2001) “Globalization by Chunking: A Quantitative Approach”. IEEE Software, 18(2).

Paulish, D.J. (2003) “Product Line Engineering for Global Development”, International Workshop on Product Line Engineering: The Early Steps.

Setamanit, S. et al. (2007) “Using simulation to evaluate global software development task allocation strategies”, Software Process: Improvement and Practice, 12(5), pp. 491-503.

Shen, M. et al (2002) “Multi-Criteria Task Assignment in Workflow Management Systems” 36th Annual Hawaii International Conference on System Sciences.

Sosa, M. E. et al. (2002) “Factors that influence Technical Communication in Distributed Product Development: An Empirical Study in the Telecommunications Industry”, IEEE Transactions on Engineering Management, 49(1), pp. 45-58.

Thebeau, R. E. (2001) “Knowledge management of system interfaces and interactions for product development processes”, Master of Science Thesis, MIT.

Yassine, A. (2004) "An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method", Quaderni di Management (Italian Management Review), www.quaderni-di-management.it, No.9, 2004.

Zadeh, L. A. (1965) “Fuzzy sets”, Information and Control, 8, pp. 338-353

1 http://www.ines.org.br/

50

M3DS: um modelo de dinâmica de desenvolvimento distribuído de software

Alexandre L’Erario1

1Coordenação de Informática – Universidade Tecnológica Federal do Paraná (UTFPR) Cornélio Procópio, Paraná CEP 86300-000, Brasil

[email protected]

Abstract. This work presents a dynamic model of distributed development of software, whose objective is to represent the reality and the aspects of DDS environments. With this model it is possible to understand the operation of a distributed project, aiding in the effectiveness of the manager of the network production and people can obtain a precise positioning in network. The results presented in this work answer the question: how the development software organizations produce software in a distributed way. The originality of the research is the construction of a model of dynamics of the distributed development elaborated from data of six cases studies.

Resumo. Este trabalho apresenta um modelo de dinâmica de desenvolvimento distribuído de software, cujo objetivo é representar a realidade e os aspectos de ambientes de DDS (Desenvolvimento distribuído de software). Com este modelo, é possível compreender o funcionamento de um projeto distribuído e auxiliar na eficácia da gestão da rede de produção, além de auxiliar as demais entidades e pessoas envolvidas a obterem um posicionamento na rede mais preciso. Os resultados apresentados neste trabalho respondem a questão de como as organizações desenvolvedoras de software produzem software de maneira distribuída. A originalidade da pesquisa centra-se na construção de um modelo de dinâmica do desenvolvimento distribuído elaborado com os dados levantados a partir de seis estudos de casos.

1. Introdução

Uma maneira de estabelecer parceria entre as empresas que produzem software é constituir redes de produção. Segundo Alstyne (1997), uma rede pode ser definida a partir dos elementos envolvidos na sua estrutura, pelo seu processo e seu propósito.

As parcerias nem sempre são locais. São compostas por várias organizações distantes fisicamente umas das outras. Esse fato ocorre porque forças econômicas atualmente tendem a migrar para mercados globais, ultrapassando barreiras e desenvolvendo novas formas de competição e cooperação. O resultado, segundo Herbsleb e Grinter (1999), é a criação de organizações virtuais que podem operar com sucesso sobre as barreiras geográficas e culturais.

O desenvolvimento global de software, abordado neste trabalho com um tipo de desenvolvimento distribuído de software, tem tomado grandes proporções, pois as organizações das mais diversas categorias descobrem constantemente que o desenvolvimento distribuído de software pode aumentar a produtividade e reduzir o


51

custo. Por isso, segundo Carmel e Agarwal (2001), o número de entidades que se engajaram no GSD (Global Software Development) é crescente. O desenvolvimento distribuído de software agrega várias vantagens sobre o desenvolvimento centralizado, como ensinam Battin et al (2001), Carmel e Argawall (2001), L’Erario et al(2004) em seus estudos de caso.

O objetivo deste trabalho é elaborar um modelo da dinâmica de funcionamento de uma rede de produção de software. Este auxilia a compreensão de como a produção distribuída de software ocorre e identifica os principais pontos de possíveis impasses. Tal modelo é denominado neste trabalho como M3DS: modelo de dinâmica do desenvolvimento distribuído de software.

Este artigo está organizado da seguinte maneira: na seção 2 é apresentada uma revisão bibliográfica sobre DDS; na seção 3 é apresentada a metodologia; a seção 4 apresenta o M3DS; a seção 5 apresenta as conclusões e finalmente as referências bibliográficas.

2. Desenvolvimento Distribuído de Software

Segundo Audy e Prikladnicki (2007), o desenvolvimento distribuído de software é caracterizado quando um dos atores no envolvidos projeto estiverem fisicamente distante dos demais. Neste cenário, a complexidade do processo de desenvolvimento se amplia.

Dividir a produção de um software entre diversos nós envolve uma série de problemas. Alguns problemas que, localmente, são insignificantes ganham proporção quando uma tarefa é dividida entre organizações fisicamente distantes. Esses problemas são relacionados a atividades do desenvolvimento do software, como é o caso do levantamento de requisitos. Vários autores, como Edwards e Sridhar (2002) e Campbell e Van de Walle (2003) citam em seus trabalhos os problemas inerentes ao desenvolvimento distribuído.

Um ambiente de DDS agrega um conjunto de variáveis multidisciplinares que abordam desde a visão técnica de desenvolvimento até mesmo a visão de organização em rede. Por isso, para este trabalho foram consideradas variáveis como: a dispersão física, explicados por Audy e Prikladnicki (2007); o modelo de negócio de DDS, explicado por Robinson et. al. (2004); o modelo de coordenação, abordado sobre o ponto de vista gerencial - Mintzberg(2003) e Burton(1998) - e sobre o ponto de vista técnico - Cataldo(2007), Borden(2007) e Sinha (2007).

3. Metodologia

A metodologia empregada neste trabalho é o estudo de múltiplos casos – delineamento explanado por Yin (2005) - que consiste na aplicação do protocolo do delineamento estudo de caso em várias organizações que praticam o desenvolvimento distribuído de software. Segundo Yin (2005), o estudo de caso trabalha com o como e o porquê dos fenômenos, sem exigir controle sobre os eventos comportamentais. Avalia eventos contemporâneos e possibilita a replicação literal do estudo de caso, sobre o aspecto de resultados semelhantes. Os casos abordados neste projeto de pesquisa englobam grandes empresas e/ou grandes projetos distribuídos de software. Separar o contexto do projeto de software sem compreender a razão pela qual a empresa desenvolve de forma

52

distribuída pode fazer com que a veracidade do modelo final seja reduzida. Por isso, o estudo de caso foi o método de pesquisa que mais se alinhou com o problema deste trabalho.

Um protocolo de pesquisa foi elaborado, baseando-se nas teorias citadas na seção 2 deste trabalho. Este protocolo de pesquisa foi aplicado em vários casos, sendo que 3 destes são empresas com certificação CMMI nível 5; 2 destes casos são empresas com certificação CMMI nível 3 e último caso foi o desenvolvimento de um aplicativo open source.

A execução desta pesquisa consistiu em uma visita sistemática aos casos. Neste sentido, o protocolo foi investigado na organização, sem influência do pesquisador. Tal protocolo é composto em três partes. A primeira parte do protocolo investiga a organização da rede, por isso, explora os projetos distribuídos e a relação entre os sites. A segunda parte do protocolo explora o gerenciamento da produção que consiste em investigar e identificar os processos distribuídos e o distribuidor de tarefas. A última parte do protocolo investiga a produção, explorando a fabricação de artefatos e a interação/comunicação entre os sites.

Cada parte do protocolo foi composta por dois blocos. Cada bloco tem seu constructo teórico e um conjunto de item que foram investigados na organização. A aplicação do protocolo gerou conclusões, que consequentemente alimentaram a construção do modelo M3DS.

4. M3DS

A dinâmica de um ambiente de DDS revela o funcionamento da rede, de sua concepção inicial até seu encerramento. Porém, abordar individualmente os sites na rede pode não revelar a influência do projeto tem sobre sua existência na rede. Portanto, a dinâmica da rede, representada na figura 1, aborda conjuntamente dois componentes fundamentais em um ambiente de DDS.

Figura 1 - M3DS: modelo de dinâmica de DDS


53

O primeiro indica a dinâmica de uma unidade de produção de software. O segundo é atrelado ao projeto desenvolvido em uma rede de produção de software. Sobre essa dinâmica, há uma intersecção, que ocorre quando o site precisa desenvolver um subproduto de rede, e uma instância do projeto para vários sites. A seguir, serão explicados brevemente todos os estados do modelo e identificados quais estados existentes e quais condições necessárias para a mudança de estado. Toda seta (transição) da figura 1 é disparada quando as atividades atribuídas ao estado que a antecede sejam concluídas. P0: Novo Projeto

Este estado indica a concepção de um novo produto de software por alguma organização, seja ela em rede ou não. Nesta fase, além da concepção do projeto há a elaboração de uma visão compartilhada para que todos os nós envolvidos na produção possam compreender a razão do produto final. P1: Pronto para ser produzido

Para se alcançar o estado P1 é necessário que seja disparada a seta 1. Este disparo Indica que o plano gerencial do projeto em termos de componentização e divisão de tarefas foram realizados. Após esta seta, todos, ou parte dos artefatos estarão prontos para serem disponibilizados e distribuídos para que a rede e os sites possam desenvolvê-los. Este estado indica que um papel de distribuidor de tarefas entra em ação para gerenciar a distribuição das tarefas do projeto na rede. Representa a segmentação e alocação das tarefas nos diversos sites de produção. É neste estado que se inicia do processo de ruptura, ou seja, o projeto é segmentado e alocam-se a produção dos segmentos para sites distintos. P2: Em produção

Este estado representa uma tarefa que tem como resultado um subproduto de trabalho. Para almejar o estado P2, a seta 2 precisa ser disparada. Esta seta indica que o subproduto foi alocado em produção. Esta etapa implica em enviar para o site a tarefa e os dados sobre ela. Podem ser enviados, por exemplo, códigos mais atualizados, scripts de banco de dados, requisitos do software, etc. P3: Componente finalizado

O componente é finalizado quando sua construção é concluída. Neste caso, indica o fim do processo de codificação de um componente ou módulo de software. Este estado sinaliza que o componente está apto a ser integrado com outro. As operações de check-out são efetuadas após a conclusão do componente. A gestão de configurações está presente explicitamente nesta etapa. P4: Em integração

Após a codificação de dois ou mais componentes, o processo de integração é iniciado. Neste caso apenas um site é responsável em integrar dois ou mais componente, gerando outro produto de trabalho. A seta 7 indica o inicio deste estado. P5: Em teste

Quando a seta 8 é disparada inicia-se o procedimento de teste. Neste caso o teste em um ambiente de DDS é de integração do software. Após esta etapa, o projeto

54

pode ser finalizado, mudando seu estado para P6, ou o teste pode gerar outro produto de trabalho, realimentando o ciclo por meio do estado P1. P6: Finalizado

O projeto é concluído. Este estado representa que o projeto foi totalmente montado e concluído. P7: Em espera

As dependências funcionais entre artefatos gerados pelos sites podem ocasionar em bloqueio em uma determinada tarefa. Este estado representa o bloqueio da tarefa em relação a um projeto.As setas 4 e 16 ocorrerem paralelamente quando há uma dependência de produtos de trabalho. Se isso ocorrer, para o projeto, o subproduto fica bloqueado. Este estado ocorre juntamente com o estado P11. P8: Novo site

Indica que um novo nó da rede está pronto para associar-se a uma rede de produção de software. Para ser considerado um novo site, um mecanismo de coordenação, agrupamento e processo de software devem ser estipulados. Este estado indica que o site está apto a trabalhar em equipe com os demais sites. Um site pode ser criado a partir de um modelo já existente, importando processos e modelos de desenvolvimento. Os procedimentos de replicação são detalhados por Fabri (2004), Fabri (2007) e Trindade (2004). P9: Pronto para produzir

Para que o estado P9 seja alcançado é necessário que a transação indicada pela seta 13 seja disparada. A seta 13 representa os procedimentos iniciais de produção. P10: Produzindo

Este estado representa que o site está executando uma tarefa e retornará como resultado um subproduto. Pode ser alcançado após o disparo da seta 14. Neste caso, a produção inicia-se, ou seja, as atividades referentes ao desenvolvimento do produto que foram atribuídas para o site são executadas. Esta etapa ocorre paralelamente a seta 2. P11: Bloqueado

Podem ocorrer bloqueios na produção por dependências funcionais. Por exemplo, um site precisa de um produto de trabalho de outro site para prosseguir. Este estado representa que o site está bloqueado para uma determinada tarefa. Para tanto, as transições 4 e 16 ocorrem quando há uma dependência de produtos de trabalho. Se isso ocorrer, para o projeto, o subproduto fica bloqueado, pois, não pode ser desenvolvido pelo fato de sofrer dependência funcional. P12: Desassociado

A ação indicada pela seta 20 indica a desassociação do site à rede que é removido da mesma e deixa de fazer parte do ambiente de DDS. Esta transição ocorre quando o site deixa de atuar neste projeto/grupo. Há uma desassociação do site com relação aos demais sites e projeto.

5. Conclusões


55

As contribuições deste trabalho centra-se na construção um modelo de dinâmica de desenvolvimento distribuído de software. Para tanto, diversas teorias, como organização do trabalho (MINTZBERG, 2003), foram analisadas com o intuito de agregar valor ao modelo M3DS. Dessa maneira, o M3DS incorpora conceitos de organização do trabalho em produção de software. Assim, foi possível estabelecer uma posição mais precisa da rede de produção, mapeando-a em estados que podem ser analisados qualitativa e/ou quantitativamente. O modelo M3DS é um modelo geral de dinâmica com aplicação generalizada em outros casos, mas com restrições impostas pela metodologia de pesquisa empregada. Seu objetivo é demonstrar o funcionamento do desenvolvimento distribuído.

Nos casos aplicados em empresas, uma configuração rigorosa e especifica era aplicada sobre os projetos e os sites. Nesses casos, os projetos foram preparados para serem distribuídos. A elaboração da solução escolhida pelo arquiteto, junto com analistas de negócio, influencia altamente a distribuição de tarefas. Uma configuração de ambiente é determinada junto com o projeto e a distribuição de tarefas. Foi detectado que os sites eram homogêneos porque todos seguiam os mesmos processos. No caso do software livre, como não havia divisão sistemática do projeto e homogeneização dos sites, houve muitos impasses como dependência funcional e repúdio de tarefa.

A interação instantânea por meio de conferência, chat e VOIP entre os desenvolvedores, durante todo o projeto mostrou-se necessário em todos os casos. Embora os casos com processos mais sistemáticos, isto é, empresas do setor, tenham um processo de divisão de tarefas – processo de ruptura – formalizado, todos os desenvolvedores julgam necessária a interação entre os elementos dos times. Além disso, a coordenação, seja esta técnica ou gerencial, também se mostrou essencial por todo o ciclo de vida do produto.

Os casos apresentaram diferentes aspectos culturais que influenciaram na produção de software. Estes aspectos, que compreenderam a pronúncia de um mesmo idioma, o calendário referente a feriados, a religião e outros que compõem a cultura organizacional – explicado por Hofstede (2005) – diretamente impactaram na interação entre todos os indivíduos envolvidos em um projeto e foram acentuados pela distância física.

No desenvolvimento distribuído de software alguns problemas que localmente são sutis tornam-se mais acentuados em função da distância física. Entretanto, estes problemas não representam um empecilho para que as organizações desenvolvam software de maneira distribuída. Seja qual for o motivo e o modelo de negócios que a tornam viável – por aquisição, instalação de filial, parcerias, etc. – a distribuição da produção de software agrega muitos benefícios para a organização e para a região na qual o site é instalado.

Referencias

ALSTYNE, Marshall Van. The state of network organization: a survey in three

frameworks. in Journal of Organizational Computing & Electronic Commerce, 7(3);pp.83-151, 1997.

56

AUDY, Jorge Luis Nicolas; PRIKLADNICKI, Rafael . Desenvolvimento Distribuído de Software: Desenvolvimento de Software com Equipes Distribuídas. 1. ed. Rio de Janeiro: Campus/Elsevier, 2007. v. 1. 211 p.

BATTIN, Robert D. et al. Leveraging resources in Global Software Development. IEEE transactions on Software Engineering, v. 18, n. 2. Março/Abril 2001. p. 70-77.

BORDEN, Alexander, NETT, Bernhard e WULF Volker. Coordination Practices in Distributed Software Development of Small Enterprises, icgse,pp.235-246, INTERNATIONAL CONFERENCE ON GLOBAL SOFTWARE ENGINEERING (ICGSE 2007), 2007

BURTON R.M.; OBEL B. Strategic Organizational Diagnosis and Design. Kluwer Academic Publishers, 1998.

CAMPBELL, Catherine Lowry; VAN DE WALLE, Bartel. Asynchronous Requirements Engineering: Enhancing Distributed Software Development. In: INTERNATIONAL CONFERENCE ON INFORMATION TECHNOLOGY: RESEARCH ANDEDUCATION, 2003, Newark. ITRE 2003. Newark: ACM, 2003. p. 133 - 136.

CARMEL, Erran; AGARWAL, Ritu. Tactical Approaches for Alleviating Distance inGlobal Software Development. IEEE Software, v. 18, n. 2. março/abril 2001. p. 22-29.

CATALDO, et al. On Coordination Mechanisms in Global Software Development. IN PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON GLOBAL SOFTWARE ENGINEERING, ICGSE. IEEE Computer Society, 2007

EDWARDS, H. Keith; SRIDHAR, Varadharajam. Analysis of the Effectiveness of Gloval Virtual Teams in Software Engineering Projects. In: HAVAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, 36., 2003, Hawaii. Proceedings Hawaii: IEEE, 2003.

FABRI, J. A. et al. Tutorial: Desenvolvimento e Replicação de uma Fábrica de Software. In: IV Simpósio Internacional de Melhoria de Processo de Software, 2004,São Paulo. Anais do IV Simpósio Internacional de Melhoria de Processo de Software -Tutorial, 2004. v. 001. p. 3-1-3-50.

FABRI, J. A.; TRINDADE, A. L. ; A. L’ERARIO, A. ; PESSOA, M. S. P. . A Organização de uma Máquina de Processo e a Melhoria do Processo de Produçãode Software em um Ambiente de Fábrica. In: VI Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimento, 2007, Lima - Peru. Anais das VI Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimento,2007. v. 1. p. 229-236.

HERBSLEB, James D.; GRINTER, Rebecca E.. Architectures, Coordination, and Distance: Conway. IEEE Software, v. 16, n. 1, p.63-70, 1999.


57

HOFSTEDE, Geert; HOFSTEDE, Gert-Jan. Cultures and Organizations: Software of the Mind. New York: McGraw-Hill U.S.A., 2004.

L’ERARIO, Alexandre; et al. Desenvolvimento distribuído de software para sistemaspervasivos: um estudo de caso. In: SIMPÓSIO BRASILEIRO DE SISTEMA DEINFORMAÇÃO, 1., 2004, Porto Alegre. Simpósio. Porto Alegre: SBSI, 2004. p. 163 -170.

MINTZBERG, Henry. Criando organizações eficazes: Estruturas em cincoconfigurações. 2. ed. São Paulo: Atlas, 2003. 334 p.

PRIKLADNICKI, Rafael; AUDY, Jorge Luis Nicolas. Towards a Model of Software Development Process for a Physically Distributed Environment - Minimizing communication difficulties and adding planning and evaluation view to the softwaredevelopment life cycle. In: VIII CONGRESSO ARGENTINO DE CIENCIAS DE LACOMPUTACION, 2002, Buenos Aires: CACIC 2002 - Anais del VIII Congresso Argentino de Ciencias de la Computacion. 2002. v. I, p. 798-809.

ROBINSON, M., Kalakota, Offshore Outsourcing: Business Models, ROI and BestPractices. EUA: Mivar Press.2004

SINHA, V.S.; SENGUPTA, B.; GHOSAL, S., An Adaptive Tool Integration Framework to Enable Coordination in Distributed Software Development, GLOBAL SOFTWARE ENGINEERING, 2007. ICGSE 2007. Second IEEE International Conference on , vol., no., pp.151-155, 27-30 Aug. 2007

TRINDADE, André L P ; et al . Desenvolvimento e Replicação de uma Fábrica deSoftware. In: IV JORNADAS IBEROAMERICANAS DE INGENIERÍA DEL SOFTWARE E INGENIERÍA DEL CONOCIMIENTO, Madri. Anais del IV Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería delConocimiento, 2004

WOMACK, J. P., JONES, D. T., ROSS, D. A máquina que mudou o mundo. São Paulo, 1991.

YIN, Robert K.. Estudo de caso: planejamento e métodos. 3. ed. Porto Alegre: Bookman, 2005. 212 p.

58

Alocando Equipes Distribuídas com base em Aspectos Não-Técnicos

Bruno Ribeiro, Glêdson Elias

Departamento de Informática – Universidade Federal da Paraíba (UFPB) João Pessoa – PB – Brasil

[email protected], [email protected]

Abstract. Taking into account the benefits of distributed software development, many organizations allocate implementation tasks among globally distributed teams. However, their cultural, temporal and geographical differences reduce the communication effectiveness, directly affecting the project’s progress and success. In order to mitigate such communication issues, based on non-technical features of global distributed development teams and dependences among software modules, this article describes an approach for recommending the allocation of development teams to implementation tasks of software modules.

Resumo. Considerando os benefícios do desenvolvimento distribuído de software, muitas organizações alocam atividades de implementação para equipes de desenvolvimento globalmente distribuídas. No entanto, diferenças culturais, temporais e geográficas entre as equipes reduzem a efetividade da comunicação, afetando diretamente o progresso e o sucesso do projeto. A fim de mitigar os problemas de comunicação, esse artigo descreve uma abordagem para recomendação de alocação de equipes de desenvolvimento globalmente distribuídas para atividades de implementação de módulos de software, baseando-se em características não-técnicas das equipes e nas dependências entre os módulos de software.

1. Introdução A adoção de Desenvolvimento Distribuído de Software (DDS) traz benefícios como a redução do time-to-market, a melhoria da qualidade, a redução de custos e a proximidade com o mercado internacional (Audy and Prikladnicki 2007)(Herbsleb and Grinter 1999). Entretanto, a distância entre os envolvidos gera problemas de comunicação no desenvolvimento de software, afetando o projeto como um todo.

Segundo a norma NBR ISO 10006 (ABNT 2000), o fator humano é um ponto chave para determinar a qualidade de um projeto. Neste sentido, para encontrar os mais indicados para desempenhar as atividades de um projeto distribuído de software, deve-se adotar um processo de alocação de recursos humanos (RH), no qual devem ser analisados fatores técnicos e não técnicos requeridos para desempenhá-las.

Atualmente, boa parte dos processos de alocação de recursos leva em consideração apenas atributos técnicos, como é o caso de (Silva 2007), (Barreto 2005) e (Callegari, Foliatti and Bastos 2009). Dentre eles, apenas o último contempla retroalimentação das habilidades. Em relação a adaptação e configuração, o trabalho de (Silva 2007) é o que oferece maior flexibilidade.

Neste contexto, a fim de mitigar os problemas de comunicação enfrentados pela dispersão geográfica causada pela adoção de DDS, este artigo apresenta uma abordagem para alocação de equipes globalmente distribuídas para atividades de implementação de


59

módulos de software, onde são analisados aspectos não-técnicos das equipes e a dependência entre os módulos. Como premissa para avaliar o grau de comunicação requerido entre as equipes, a abordagem considera o grau de dependência existente entre os módulos de software e seus componentes constituintes, já que, segundo (Ghezzi, Jazayeri and Mandrioli 2002), a dependência dos componentes influencia na comunicação requerida entre suas respectivas equipes de desenvolvimento.

A abordagem aqui proposta compõe a terceira fase do framework de recomendações, inicialmente proposto em (Pereira, et al. 2010), mas que, por limitação de espaço, não apresenta detalhes da abordagem aqui descrita. Neste framework, a primeira fase mensura a dependência entre os módulos que compõem uma linha de produto de software. A segunda fase identifica e ranqueia as equipes tecnicamente qualificadas para implementá-los. Por fim, a terceira fase, detalhada neste artigo, recomenda a alocação de equipes para implementação dos módulos.

As próximas seções estão organizadas da seguinte forma. A seção 2 apresenta a descrição não-técnica das equipes. A seção 3 a alocação de equipes. E por fim, a seção 4 apresenta as considerações finais e trabalhos futuros.

2. Descrição não-técnica das equipes A abordagem proposta considera os resultados produzidos nas duas primeiras fases do framework e é dividida em duas etapas: descrição não-técnica das equipes e alocação de equipes. A etapa de descrição não-técnica tem como objetivo caracterizar informações das equipes que torne possível a previsão dos níveis de comunicação a serem estabelecidos entre as equipes distribuídas. Observe que a abordagem considera apenas informações de âmbito não técnico, pois se assume que a segunda fase do framework avalia os aspectos técnicos.

As informações não técnicas das equipes são caracterizadas na forma de atributos, que devem refletir não apenas a distância geográfica, mas também a distância temporal e cultural, conforme documentado na literatura de DDS (Audy and Prikladnicki 2007)(Huzita, et al. 2008)(Gumm 2006). Os atributos geográficos representam a distância física existente entre as equipes. Os atributos temporais identificam os intervalos de tempo que as equipes podem compartilhar com as demais. E os atributos culturais mostram as diferenças existentes entre as equipes em termos de idioma, costumes e padrões. Por fim, ainda existem os atributos de reputação que identificam o desempenho da equipe em projetos anteriores com relação à comunicação.

Alguns atributos podem ser obtidos com perguntas diretas e objetivas, como é o caso de atributos geográficos e temporais. Já atributos que dizem respeito a costumes e padrões, devem ser obtidos através de perguntas indiretas que detectam características das equipes que podem ser usadas para diferenciar culturas. Por sua vez, os atributos de reputação são obtidos na fase de avaliação de desempenho existente no framework de recomendações, onde cada equipe avalia a comunicação realizada com as demais.

3. Alocação de equipes A etapa de alocação de equipes é o momento em que os artefatos gerados em fases anteriores são utilizados para uma análise não-técnica. Esta etapa é dividida em três atividades: definição de termos, análise não-técnica e seleção de recomendação. A definição de termos é a atividade que calibra os pesos utilizados na abordagem, como é o caso do nível da dependência entre os módulos. A abordagem propõe um mapeamento default, mas provê a flexibilidade ao gerente para modificação.

60

A atividade de análise não-técnica é onde os atributos não-técnicos são usados para avaliar e prever a viabilidade da comunicação entre equipes. A avaliação é realizada com base nas dependências entre os módulos, considerada como um artefato de entrada. A dependência entre eles resulta em necessidades de comunicação entre as equipes responsáveis por implementá-los. Assim, esta atividade avalia se um par de equipes possui o nível de comunicação requisitado pela dependência de seus módulos.

Devido à grande quantidade de possíveis soluções, a avaliação fundamenta-se em algoritmos genéticos. Essa abordagem favorece a recomendação de várias boas soluções, resultando em uma abordagem computacionalmente menos dispendiosa quando comparada a algoritmos que buscam a solução ótima. Com base no princípio de funcionamento dos algoritmos genéticos, primeiramente, a abordagem gera uma população inicial de soluções, e em seguida, aplica operadores genéticos que tornam a população cada vez mais forte (Linden 2008). Na presente abordagem, a população inicial é criada com base no artefato de entrada mapeamento entre módulos e equipes, que fornece quais equipes são capacitadas tecnicamente para implementar cada módulo.

M1 M2 M3 M4 M5

E14

E10

E2

E5

E19

E3

E1

E12

E1

E5

E9

E10

E19

E11

E2

E1

E19

E3

E6

E7

E2

E13

E4

E8

E10

E2

E19

E6

E3

E9

E5

E12

E10

E11

E4

E5

E7

Módulos

Ad

eq

uab

ilid

ad

e

técn

ica

E5 E11 E19 E2 E7

Equipes capacitadas

por módulo

Dependências entre Módulos:

{M1, M3, alto}

{M2, M4, mediano}

{M1, M2, baixo}

{M3, M5, alto}

{M4, M5, mediano}

{M2, M3, baixo}

M1

E5

M2

E11

M3

E19

M4

E2

M5

E7

altoalto

mediano

mediano

baixo

baixo

Figura 1. Geração de população inicial e dependênci as entre equipes

A Figura 1 exemplifica a geração de uma solução usando a lista de equipes capacitadas para selecionar quais equipes irão implementar cada módulo. A operação é repetida de forma a gerar a população inicial. Cada solução é avaliada individualmente, de acordo com a base de regras de avaliação entre equipes. Em função da limitação de espaço, as regras de avaliação não são discutidas. Considerando o exemplo da Figura 1, a tabela de dependências entre módulos, obtida do artefato de entrada dependências entre módulos, identifica a dependência existente entre os módulos, que influencia diretamente no grau de comunicação requerido entre as equipes. Considerando que os módulos M1 e M3 possuem alta dependência, as equipes E5 e E19 necessitam alta viabilidade de comunicação. A avaliação deve acontecer em todas as dependências.

O resultado da avaliação gera o grau de viabilidade de comunicação das equipes, representado por C(En, Em, R), onde R é a dependência entre os módulos alocados às equipes En e Em. Após a avaliação de cada par de equipes, a métrica que define a adequabilidade da solução é a soma dos graus de viabilidade de comunicação dos pares de equipes alocados, que é definido pela função �� = {∑ C(En, Em, R) | En, Em ∈ S}. Assim, a função �� define a pontuação das soluções e é usada para ranquear as soluções. A cada iteração, operadores genéticos de cruzamento e mutação são usados para evoluir a população, favorecendo assim a obtenção de soluções mais fortes. Vale ressaltar que tais operadores são aplicados apenas nas soluções que apresentam métrica de adequabilidade superior ao ponto de corte definido pelo gerente de projeto. Ao final da etapa de análise não-técnica, a etapa de seleção de recomendação deve ser empregada pelo gerente, selecionando a recomendação que se mostra mais adequada ao problema. Note que a abordagem recomenda soluções, mas é o conhecimento e experiência do gerente que determinam a solução a ser adotada.


61

4. Considerações Finais A alocação de equipes é uma atividade muito complexa para ser realizada apenas baseada na experiência e conhecimento do gerente de projetos. Embora já existam na literatura algumas propostas para sistematizar a alocação de equipes, aspectos específicos de projetos de DDS não são considerados. Desta forma, a principal contribuição deste trabalho é apresentar uma abordagem sistemática para alocação de equipes em projetos de DDS, considerando os aspectos não técnicos das equipes.

A abordagem não substitui ou despreza a experiência e conhecimento do gerente de projetos. Porém, representa uma opção mais efetiva e eficiente de obter um conjunto de soluções com bom desempenho das equipes em termos de viabilidade de comunicação. Atualmente, as regras de avaliação estão sendo refinadas e em seguida a abordagem será instanciada e aplicada em estudos de caso. Além disso, pretende-se desenvolver ferramentas para automatização da abordagem.

Agradecimentos. Este trabalho foi apoiado pelo Instituto Nacional de Ciência e Tecnologia para Engenharia de Software (INES)1 e financiado pelo CNPq, processo 573964/2008-4.

Referências ABNT, NBR ISO 10006. Gestão da Qualidade – Diretrizes para a Qualidade no

Gerenciamento de Projetos. Rio de Janeiro, RJ - Brasil: Associação Brasileira de Normas Técnicas, 2000.

Audy, J., and R. Prikladnicki. Desenvolvimento distribuído de software. Rio de Janeiro: Campos/Elsevier, 2007.

Barreto, A. “Apoio à alocação de recursos humanos em projetos de software: uma abordagem baseada em satisfação de restrições.” Thesis, 2005.

Callegari, D. A., F. L. Foliatti, and R. M. Bastos. “MRES - Ferramenta para seleção de recursos para tarefas de projetos de software via abordagem difusa e multicritérios.” SBES. Fortaleza, 2009.

Ghezzi, C., M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. Upper Saddle River: Prentice Hall, 2002.

Gumm, D. C. “Distribution Dimmensions in Software Development Projects: A Taxonomy.” IEEE Software, vol3, issue 5, September & October 2006: 45-51.

Herbsleb, J. D., and R. E. Grinter. “Splitting the Organization and Integrating the Code: Conway's Law Revisited.” ICSE'99. Los Angeles, CA, 1999.

Huzita, E., C. Silva, I. Wiese, T. Tait, M. Quinaia, and F. Schiavoni. “Um Conjunto de Soluções para Apoiar o Desenvolvimento Distribuído de Software.” II WDDS. Campinas, 2008. 101-110.

Linden, R. Algoritmos Genéticos. Rio de Janeiro: Brasport, 2008.

Pereira, T., V. Santos, B. Ribeiro, and G. Elias. “A Recommendation Framework for Allocating Global Software Teams in Software Product Line Projects.” RSSE. 2010.

Silva, M. A. “WebAPSEE-Planner: Auxílio à Alocação de Pessoas em Projetos de Software através de políticas.” UFPA, 2007.

1 http://www.ines.org.br/

62

Classificando organizações de Desenvolvimento

Distribuído de Software no modelo de capacidade WAVE

Rafael A. Glanzner , Rafael Prikladnicki , Jorge L. N. Audy

Faculdade de Informática (FACIN) Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS)

90.619-900 – Porto Alegre – RS – Brasil

[email protected], [email protected], [email protected]

Abstract. The aim of this paper is to classify the Brazilian unit of two

companies with extensive experience in global software development in the

WAVE capability model. This work presents the artifacts and process designed

to make those assessments, the results and suggested improvements. Finally,

we evaluated the relevance of the WAVE model in the two chosen companies,

based on the outcome of the study.

Resumo. O objetivo desse artigo é classificar a unidade brasileira de duas

empresas com ampla experiência em desenvolvimento global de software no

modelo de capacidade WAVE. Nesse trabalho são apresentados os artefatos e

processo criados para viabilizar essas avaliações, os resultados das mesmas e

as melhorias sugeridas. Por fim é avaliada a relevância do modelo WAVE nas

duas empresas escolhidas, baseando-se no resultado do estudo.

1. Introdução

A crescente globalização das últimas décadas tem causado impacto em praticamente todos os ramos da indústria e, esse fenômeno, não foi diferente no desenvolvimento de software [Aspray, Mayadas e Vardi 2006] [Boehm 2006]. Com estas transformações, originou-se o GSD (Global Software Development), que se caracteriza quando um projeto de software é desenvolvido por uma equipe que fica dispersa em escala global.

No que diz respeito ao desenvolvimento distribuído de software na modalidade Internal Offshoring [Prikladnicki, Damian e Audy 2008], ainda não havia nenhum modelo de capacidade que tivesse como objetivo auxiliar as empresas a melhorar continuamente seus processos organizacionais, técnicos e não técnicos. O modelo de capacidade WAVE foi concebido para preencher esta lacuna, sugerindo melhorias nas áreas de pessoas, projetos, unidade e portfólio [Prikladnicki 2009]. Embora o modelo de capacidade WAVE tenha tido uma recepção positiva na área acadêmica, ele ainda não foi, de fato, aplicado e testado em nenhuma empresa [Prikladnicki e Audy 2009] [Prikladnicki, Damian e Audy 2008]. Este artigo tem como objetivo relatar a aplicação do modelo de capacidade WAVE em duas organizações que trabalham no modelo de Internal Offshoring, de forma a avaliar a sua relevância como guia na capacitação das empresas para desenvolver software em ambientes distribuídos com mais maturidade.


63

2. Método de avaliação para o WAVE

Para identificar o nível de capacidade de uma unidade de uma organização, no modelo de capacidade WAVE, é preciso analisar seus processos, artefatos e políticas. Estas informações demonstrarão quais práticas estão sendo implementadas na unidade e, a partir disso, pode-se mensurar o nível de capacidade da mesma.

Esta seção tem por objetivo descrever como os dados para avaliação foram obtidos e quais artefatos foram criados para auxiliar no processo de definição da capacidade no modelo WAVE das unidades das empresas.

2.1 Identificação dos dados para avaliação das empresas

Quando o modelo de avaliação WAVE estava em fase de elaboração, foram conduzidas entrevistas em cinco empresas que trabalhavam com DDS. A pauta dessas entrevistas tinha o intuito de cobrir praticamente todos os processos e ações que permeiam o DDS da unidade da organização. Sendo assim, identificou-se a oportunidade de utilizar estes dados para fazer uma classificação do nível de capacidade dessas empresas.

2.2 Criação de artefatos para auxiliar na definição de capacidade

Para realizar a avaliação destas unidades, com base nas entrevistas colhidas, foram criadas três planilhas, uma para cada nível de capacidade do modelo WAVE. Devido à limitação de espaço, a documentação completa está em [Glanzner, 2010].

3. Avaliação de duas empresas no modelo WAVE

A Empresa A faz parte de um grupo de empresas, sendo a responsável por prestar serviços de informática para as empresas deste grupo, caracterizando-se assim no modelo de Internal Offshoring¸ com desenvolvimento entre Brasil e Portugal. A empresa possui nível 3 no modelo CMMI-SW, e possui seis anos de operação e 300 funcionários. A empresa B é uma organização que possui diversos centros de desenvolvimento globais, tendo matriz nos EUA, e também atua no modelo de Internal

Offshoring. A unidade de desenvolvimento localizada no Brasil é nível 3 no modelo CMMI, possui oito anos de operação e conta com mais de 500 funcionários.

4.1 Processo de avaliação

Na fase de “Avaliação” foi desenvolvido um processo para avaliar as empresas escolhidas com os seguintes passos:

- a: Instanciar os artefatos de avaliação para a empresa a ser avaliada;

- b: Depurar as entrevistas realizadas;

- c: Preencher das planilhas de avaliação;

- d: Analisar as lacunas;

- e: Buscar outras fontes para complementar a avaliação;

- f: Propor melhorias.

É importante frisar que os passos “b”, “c” e “d” são iterativos, pois, caso se perceba a necessidade de repetição da depuração das entrevistas, estes processos podem

64

ser efetuados novamente. Se for identificado que as entrevistas não forneceram dados suficientes para inferir o nível de capacidade de determinado atributo de conhecimento no modelo WAVE, deve-se procurar um profissional que detenha conhecimento sobre os processos da empresa para que possa responder a mais perguntas.

4.2 Resultado da avaliação

A Tabela 1 apresenta os resultados encontrados em cada empresa avaliada. Percebe-se que a empresa A investiu mais nas áreas de capacidade relativas a “Projetos”, “Portfólio” e “Unidade”. A empresa B obteve um nível de capacidade maior no modelo WAVE. Isso é procedente pelo fato desta empresa ter maior experiência com DDS e por ela interagir com um maior número de unidades, provavelmente forçando-a a melhorar os seus processos. Na empresa A, a área de capacidade que recebeu menor atenção da empresa foi a de pessoas onde, embora os processos da mesma sejam abrangentes, seus esforços para conscientização e preparação dos seus funcionários para os desafios do DDS ainda é fraca ou de iniciativa exclusiva de alguns setores da empresa.

A área de capacidade de pessoas foi muito bem explorada pela empresa B. Esforços em nível global para integração do time distribuído e consciência da diversidade de culturas, entre outros fatores, colaboraram para o alto grau de capacidade da empresa nesta área. Embora a empresa B tenha visível cuidado na melhoria de suas práticas relacionadas à engenharia de software em nível global, ela ainda tem dificuldades em alguns fatores como: ferramentas de colaboração integradas em todas as unidades e estimativas de esforço sem definição ou padrão entre as unidades.

Tabela 1. Resultado da avaliação

Empresa A Empresa B

Práticas

existentes

Práticas

implementadas

Existentes /

Implementadas

Práticas

existentes

Práticas

implementadas

Existentes /

Implementadas

Pessoas

Nível 2 17 11 65% 17 14 82% Nível 3 10 1 10% 10 8 80% Nível 4 2 0 0 2 0 0% Total 29 12 41% 29 22 76% Projetos

Nível 2 11 10 91% 11 10 91% Nível 3 9 6 67% 9 7 78% Nível 4 8 3 38% 8 3 38% Total 28 19 68% 28 20 71% Portfólio

Nível 2 5 5 100% 5 5 100% Nível 3 4 2 50% 4 4 100% Nível 4 2 0 0% 2 2 100% Total 11 7 64% 11 11 100% Unidade

Nível 2 2 2 100% 2 2 100% Nível 3 2 2 100% 2 2 100% Nível 4 2 0 0% 2 2 100% Total 6 4 67% 6 6 100%


65

4.3 Melhorias sugeridas PELO e PARA modelo WAVE

A partir da avaliação de capacidade das empresas no modelo WAVE e das informações sobre o tipo de trabalho e objetivos das empresas avaliadas, é possível realizar uma série de sugestões de melhorias para auxiliar as unidades a trabalhar melhor dentro do contexto do desenvolvimento distribuído. Depois de realizada a avaliação foi possível, também, propor uma série de melhorias para o modelo de capacidade WAVE. Essas sugestões estão documentadas de forma completa em [Glanzner, 2010].

4. Considerações finais e perspectivas futuras

Embora grande parte dos artefatos necessários para a definição do nível de capacidade de uma empresa para o modelo WAVE já tenham sido gerados neste artigo, os mesmos não podem ser usados pelo mercado neste momento. Foram identificados alguns caminhos a serem seguidos, que envolvem evoluir o método de avaliação já proposto e disponibilizar para empresas (mas isto envolve necessariamente conhecimento prévio no modelo WAVE e em DDS, fazendo com que seja necessário o desenvolvimento de materiais de treinamento e guias de avaliação. Outra opção é alterar o método de avaliação para que o avaliador não necessite de conhecimento prévio sobre o WAVE ou DDS. Estes caminhos serão explorados em trabalhos futuros e posteriormente publicados.

Referências Bibliográficas

Aspray, W., Mayadas, F., Vardi, M. Y., Editors, “Globalization and Offshoring of Software,” A Reporto of the ACM Job Migration Task Force, Association for Computing Machinery, 2006.

Audy, J. L. N., Prikladnicki, R. “Desenvolvimento Distribuído de Software: Desenvolvimento de Software com Equipes Distribuídas,” Ed. Campus, 2007.

Boehm, B., “A View of 20th and 21st Century Software Engineering,” International Conference on Software Engineering, Shanghai, 2006.

Glanzner, R., “Classificação de Organizações de Desenvolvimento Distribuído de Software no Modelo de Capacidade WAVE,” Relatório Técnico, FACIN, 2010.

Ramamani, M., “Offshore Subsidiary Engagement Effectiveness: The Role of Subsidiary Capabilities and Parent – Subsidiary Interdependence,” Conference of Midwest United States Association for IS, pp. 7580, 2006.

Prikladnicki, R. “Padrões de Evolução na Prática de Desenvolvimento de Software em Ambientes de Internal Offshoring: Um Modelo de Capacidade.” Tese de Doutorado, PPGCC, Faculdade de Informática, PUCRS, 2009.

Prikladnicki, R., Audy, J. L. N. “Desenvolvimento Distribuído de Software com Captive

Centers,” III Workshop de Desenvolvimento Distribuído de Software (WDDS), Simpósio Brasileiro de Engenharia de Software, 2009.

Prikladnicki, R. Damian, D. Audy, J. L. N. “Patterns of Evolution in the Practice of Distributed Software Development in Wholly Owned Subsidiaries: A Preliminary Capability Model,” International Conference on Global Software Engineering, 2008.

66

Desafios e Boas Práticas para o Gerenciamento de Projetos

no Desenvolvimento Distribuído de Software

Catarina Costa1, Rodrigo Rocha

1, Fabio Q. B. da Silva


2

1Centro de Informática – Universidade Federal de Pernambuco (UFPE) Caixa Postal 7851, Cidade Universitária – 50.732-970 – Recife – PE – Brasil

2Faculdade de Informática - Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) 90.619-900 – Porto Alegre – RS – Brasil

{csc, rgcr, fabio}@cin.ufpe.br, [email protected]

Abstract. Distributed software development (DSD) has made even more

complex the problem of managing software projects. Additionally, in the

literature, there is not a widely recognized knowledge body supporting

distributed projects management. This research aims to collect and organize,

existing knowledge on the challenges and practices for distributed software

development, through a systematic literature review.

Resumo. O Desenvolvimento Distribuído de Software (DDS) acrescentou

desafios a já complexa atividade de gerenciar projetos de software. Além

disso, não existe um corpo de conhecimento amplamente reconhecido e aceito

para o gerenciamento nesse contexto. Desta forma, essa pesquisa objetiva

coletar e reunir desafios e boas práticas para o gerenciamento de projetos no

DDS através de uma revisão sistemática da literatura.

1. Introdução

Nas últimas décadas, evidências da prática industrial e da literatura científica têm deixado claro que o gerenciamento profissional de projetos é fundamental para o sucesso de projetos co-localizados de software. Com o aumento das práticas de desenvolvimento distribuído na indústria, novas variáveis, tais como comunicação virtual, diferenças culturais e de fuso horário, foram acrescentadas ao já bastante complexo problema de gerenciar projetos de software. Porém, boa parte dos guias de suporte ao gerenciamento de projetos foi criada para o desenvolvimento co-localizado e não existe um conhecimento amplamente reconhecido pela literatura que possa apoiar o gerenciamento de projetos distribuídos. Para McBride (2005), com o entendimento das diferenças na gestão distribuída é possível estabelecer práticas de gestão mais eficazes e direcionar para ferramentas de gestão que possam auxiliar projetos distribuídos.

Assim, este trabalho tem como objetivo investigar e reunir de forma sistemática um conjunto de desafios e melhores práticas para o gerenciamento de projetos no DDS. O método de pesquisa utilizado para isso é uma revisão sistemática da literatura baseada nas orientações de Kitchenham et al. (2007), que busca responder duas questões de pesquisa: Q1: Quais os principais desafios no gerenciamento de projetos no DDS? e Q2: Quais as melhores práticas a serem adotadas no gerenciamento de projetos no DDS?


67

2. Metodologia

Os termos de busca foram gerados a partir das estruturas das questões e da combinação dos termos chave e sinônimos (Tabela 1). As fontes de pesquisa utilizadas para a busca dos estudos primários foram: (1) IEEEXplore; (2) ACM; (3) ScienceDirect; (4) EI

Compendex; e, (5) 4th International Conference on Global Software Engineering (os

trabalhos dessa edição foram buscados posteriormente as buscas no portal IEEE). Na Tabela 2, as etapas do processo de seleção. Por falta de espaço, a avaliação da qualidade, assim como resultados mais completos e a lista de Estudos Primários da pesquisa podem ser acessados em [www.cin.ufpe.br/~csc/wdds/completo].

Tabela 1. Termos de Busca

Desenvolvimento Distribuído de Software (Distributed software development OR Global software development OR …)

Gerenciamento de Projeto AND (Project Management) Desafios AND (Challenge OR Difficult OR …) Boas Práticas AND (Best practice OR Good Practice OR …)

Tabela 2. Processo de Seleção

Etapa 1 Dois pesquisadores inicialmente realizam as buscas para identificar os potenciais estudos primários Etapa 2 Cada pesquisador chega então a uma lista de potenciais estudos primários e as comparam Etapa 3 Os trabalhos são avaliados por dois pesquisadores, a partir dos critérios de inclusão/exclusão Etapa 4 Cada estudo primário é lido e é realizada a extração dos dados e avaliação da qualidade.

3. Resultados

As buscas primárias retornaram um total de 1189 trabalhos, e 155 foram considerados potencialmente relevantes para a pesquisa. Com a leitura do resumo e conclusão, e utilizando-se os critérios de inclusão/exclusão, 101 estudos foram excluídos, chegando-se então ao total de 54 estudos primários (Tabela 3).

Tabela 3. Dados das Buscas

Fontes Resultados das

Buscas Iniciais

Potencialmente

Relevantes

Não

Relevante Repetidos Incompletos

Estudos

Primários

IEEEXplore 215 51 18 0 5 28 ACM 700 33 21 0 2 10 ScienceDirect 300 11 6 0 0 5 EI Compendex 713 19 9 8 0 2 ICGSE2009 64 41 28 0 4 9 TOTAL 1189 155 82 8 11 54

A relação entre as evidências quanto aos desafios no gerenciamento de projetos no DDS (Q1) e as boas práticas (Q2) é apresentada na Tabela 4.

Tabela 4. Desafios e Melhores Práticas no Gerenciamento de Projetos no DDS

Desafios Melhores Práticas EP: Estudos Primários

MP1. Disponibilização e Treinamento em Ferramentas de Comunicação e Colaboração

EP09, EP11, EP26, EP40, EP45, EP46, EP47, EP50

MP2. Disponibilização de múltiplos canais de comunicação/Ter mecanismos para comunicação síncrona face a face

EP02, EP04, EP11, EP17, EP30, EP31, EP46 EP50, EP52, EP53

MP3. Visitas entre sites EP31, EP38

MP6. Disponibilização de uma boa infraestrutura EP09

D1. Comunicação

MP7. Criação de Protocolo de Comunicação EP23, EP24, EP32, EP40, EP47

68

MP8. Padrões e processos comuns para todos os sites EP20, EP45 MP10. Implementação de Práticas Ágeis EP10, EP20, EP29, EP53 MP12. Sincronicidade - Reuniões com horários razoáveis para a maioria dos sites

EP46, EP53

MP14. Promover interações informais EP02, EP31 MP30. Face a face kickoff EP38 MP31. Um gerente outsourcing, parte das duas empresas envolvidas

EP14

MP3. Visitas entre sites EP45, EP52 MP5. Treinamentos sobre Culturas diferentes/Promover um sentimento de consciência cultural

EP24, EP26, EP30, EP32, EP42, EP46, EP47

MP16. Criar equipes com culturas e conhecimentos complementares

EP24, EP26, EP32, EP46 D2. Diferença Cultural

MP31. Um gerente outsourcing, parte das duas empresas envolvidas

EP14

MP8. Padrões e processos comuns para todos os sites EP45 MP9. Divisão do trabalho em módulos e integração progressiva.

EP02, EP30, EP31, EP36, EP40, EP41, EP45

D3. Coordenação

MP10. Implementação de Práticas Ágeis EP19, EP10, EP37

D4. Diferença Temporal MP12. Sincronicidade - Reuniões com horários razoáveis para a maioria dos sites

EP02, EP21, EP29, EP46


EP21

MP3. Visitas entre sites EP53 D5. Garantir a Cooperação/Colaboração

MP4. Estimular a Cooperação/Colaboração EP21, EP30, EP35, EP40, EP53


EP50

MP3. Visitas entre sites EP21, EP23, EP31 D6. Confiança

MP14. Promover interações informais EP21, EP24, EP29

MP8. Padrões e processos comuns para todos os sites EP09, EP14, EP40 D7. Diferença Organizacional/ Padrões, Processos, Metodologias e Políticas diferentes


EP14


EP46, EP53 D8. Infraestrutura

MP6. Disponibilização de uma boa infraestrutura EP30, EP40, EP45 MP15. Mecanismos de transferência de conhecimento EP02, EP04, EP30, EP43 D9. Diferentes níveis de

conhecimento/Transferência de conhecimento


EP14

D10. Idioma/Barreira Lingüísticas

MP2. Disponibilização de múltiplos canais de comunicação/Ter mecanismos para comunicação síncrona face a face

EP52

MP6. Disponibilização de uma boa infraestrutura EP50

MP8. Padrões e processos comuns para todos os sites EP09

MP19. Visibilidade do Trabalho EP02, EP09, EP40, EP41

D11. Visibilidade/Awareness (clareza sobre quem faz o quê e onde)

MP20. Definição clara dos papéis e responsabilidades EP40 D12. Distância física MP27. Espaços físicos para equipes locais EP53

MP8. Padrões e processos comuns para todos os sites EP45 D13. Monitoramento e Controle MP23. Implementação de sistema de acompanhamento EP30, EP32

MP11. Gerenciamento de pessoal EP14, EP30, EP35, EP40, EP43, EP45 D14. Gestão de

Pessoas/Gestão de Conflitos MP31. Um gerente outsourcing, parte das duas empresas envolvidas

EP14

MP9. Divisão do trabalho em módulos e integração progressiva.

EP30

MP20. Definição clara dos papéis e responsabilidades EP30 D15. Atribuição de tarefas

MP28. Critérios claros para atribuição de tarefas EP07, EP30

D16. Identificar papéis e MP20. Definição clara dos papéis e responsabilidades EP30, EP40, EP42


69

responsabilidades MP31. Um gerente outsourcing, parte das duas empresas envolvidas

EP14

MP21. Manter time comprometido e o espírito de equipe

EP21, EP46, EP54 D17. Manter espírito de equipe

MP30. Face a face kickoff EP38, EP54 D18. Sincronização do trabalho entre os sites

MP24. Sincronização do trabalho entre os sites EP01, EP22

MP18. Gestão de Configuração EP31, EP35, EP40 D19. Gestão do Escopo/ Gestão de Mudança MP23. Implementação de sistema de acompanhamento EP30, EP32 D20. Diferentes tecnologias -

MP6. Disponibilização de uma boa infraestrutura EP45 D21. Propriedade Intelectual/Garantir Confidencialidade e Privacidade

MP17. Garantir Confidencialidade e Privacidade e Propriedade Intelectual

EP04, EP35, EP43, EP45

D22. Diferentes Stakeholders

-

D23. Cumprimento de prazos/ Gerenciar cronograma

MP29. Gerenciar cronograma EP35, EP41

D24. Gestão de Riscos MP26. Gerenciamento dos riscos constante EP35, EP40 D25. Diferentes tipos de governos, leis, regras e regulamentos

MP13. Planejamento detalhado EP31

D26. Necessidade de um espaço físico

MP27. Espaços físicos para equipes locais EP53

D27. Gestão do conhecimento

MP25. Sistema de gestão do conhecimento EP22, EP34

D28. Planejamento MP13. Planejamento detalhado EP04, EP24, EP38, EP42 MP20. Definição clara dos papéis e responsabilidades EP35

D29. Qualidade/Métricas MP8. Padrões e processos comuns para todos os sites EP04, EP35

D30. Aplicação de um processo iterativo ágil

-

4. Conclusões

A pesquisa apresenta um conjunto de desafios e boas práticas para o gerenciamento de projetos de software. Pode-se perceber que a maioria das boas práticas sugeridas são para superar os desafios de comunicação em DDS. As evidências sobre os desafios mostram que a ênfase deve ser dada também às diferenças culturais, a coordenação, as diferenças de fuso horário, a colaboração e a confiança, entre outros. Assim, essa pesquisa contribui com uma melhor compreensão sobre como as equipes distribuídas devem ser gerenciadas e com uma combinação de desafios e possíveis soluções para o gerenciamento de projetos distribuídos, no qual a gerência, diante dos desafios intensificados pela dispersão da equipe, pode identificar possíveis boas práticas.

Referências

Kitchenham, B. et al. Guidelines for performing Systematic Literature Reviews in Software Engineering. Vol 2.3 EBSE Technical Report, EBSE-2007-01, 2007.

Mcbride, T. The use of project management mechanisms in software development and their relationship to organizational distance: An empirical. Dissertation. Department of Software Engineering Faculty of Information Technology University of Technology, Sydney, 2005.

70

Dificuldades, Fatores e Ferramentas no Gerenciamento da

Comunicação em projetos de Desenvolvimento Distribuído de

Software: uma Revisão Sistemática da Literatura

Alinne C. Corrêa dos Santos¹, Camila Cunha Borges¹, Fabio Q. B. da Silva¹,

David E. S. Carneiro¹,

1 Centro de Informática – Universidade Federal de Pernambuco (CIN – UFPE)

CEP 50732-970 – Recife – PE – Brasil

{accs,ccb2,fabio,desc}@cin.ufpe.br

Abstract. This paper presents the difficulties, factors and tools of

communication management in projects of Distributed Software Development

(DSD) identified by a systematic literature review, which can be especially

useful for project managers and distributed teams. This paper comprises a

description of the process of systematic literature review, and a

systematization and evaluation of results.

Resumo. Este artigo apresenta as dificuldades, os fatores e ferramentas da

gestão da comunicação em projetos de Desenvolvimento Distribuído de

Software (DDS), identificados por meio de uma Revisão Sistemática

Literatura, sendo especialmente útil para apoio aos gerentes de projeto e as

equipes distribuídas. Este artigo compreende uma descrição do processo da

Revisão Sistemática da Literatura, sistematização e avaliação dos resultados.

1. Contextualização

Nos últimos anos, pode-se perceber um grande avanço em direção à globalização dos

negócios, em particular, nos que estão relacionados com um intenso investimento no

desenvolvimento de software. Assim, para as organizações que buscam sucesso, é clara

a necessidade do uso da Tecnologia da Informação de forma mais estratégica, o que tem

estimulado o Desenvolvimento Distribuído de Software (DDS) em escala mundial

[Herbsleb e Moitra 2001]. Segundo com Binder (2007), embora muitas organizações

viessem executando projetos com equipes distribuídas, apenas algumas delas têm

eficácia nas práticas estabelecidas para apoiar os gestores e desenvolvedores que

trabalham neste novo ambiente. Portanto, com o objetivo de minimizar diversos

problemas como desafio de horários, a perda da qualidade e o aumento de custos, é

fundamental adotar um processo de comunicação bem definido para apoiar o trabalho

distribuído.

Inserido neste contexto, este artigo apresenta através de uma revisão sistemática

da literatura, as dificuldades na gestão da comunicação, os fatores identificados nas

equipes durante o processo de comunicação que influenciam os projetos de DDS e

ferramentas relatadas em comunidades científicas confiáveis. A revisão sistemática da

literatura segue as diretrizes definidas por Kitchenham (2007); Travassos e Biolchini

(2007), buscando responder às seguintes questões de investigação: (RQ1) Quais são as

principais dificuldades na gestão da comunicação em projetos de Desenvolvimento


71

Distribuído de Software? (RQ2) Quais são os principais fatores identificados nas

equipes que influenciam o processo de comunicação em projetos de Desenvolvimento

Distribuído de Software? (RQ3) Quais são as melhores ferramentas e práticas a serem

adotadas na comunicação das equipes em projetos de Desenvolvimento Distribuído de

Software?

2. Revisão Sistemática da Literatura

As revisões sistemáticas da literatura (Systematic Literature Review) são parte do

paradigma de práticas baseadas em evidências de uma forma sistemática e

transparente. Kitchenham (2007) resume as etapas de uma revisão sistemática da

literatura em três fases principais: Planejamento da revisão, Condução da revisão e

Apresentação dos resultados. O primeiro passo para realizar essa revisão foi a definição

do protocolo, que descreve o plano de pesquisa em detalhes nas seguintes subseções.

2.1 Termos de Pesquisa

As palavras-chaves utilizadas nesta revisão sistemática da literatura são as seguintes:

Communication, Software Teams, Distributed Software Development, Challenge,

Problem, Critical, Difficulty, Best Practice, Lessons Learned, Success Facotrs, Process,

Method, Tools, Techniques, Framework. A combinação destes termos resultou em uma

string de busca, a qual foi utilizada nesta revisão sistemática da literatura.

2.2 Fontes de Busca

A busca foi realizada apenas em fontes de busca e/ou bibliotecas digitais disponíveis na

Internet e que possui parceria com a Universidade Federal de Pernambuco: IEEEXplore

Digital Library, ACM Digital Library, ScienceDirect, EI Compendex e Scopus.

2.3 Processo de Seleção dos Estudos Primários

Após a execução da consulta, os documentos resultantes foram selecionados

independentemente por dois pesquisadores diferentes, de acordo com o procedimento

descrito a seguir:

Fase 1: Leitura independente dos títulos e resumos dos estudos por parte dos dois pesquisadores.

Fase 2: Leitura independente do resumo e da conclusão dos estudos selecionados na Fase 1.

Fase 3: Análise e validação dos artigos para eliminação de duplicações e leitura completa dos

estudos selecionados pelos pesquisadores. Fase 4: Preenchimento independente da ficha de avaliação de cada estudo pelos pesquisadores.

2.4 Extração dos Dados

A primeira pesquisa recuperou 6.835 estudos das fontes de busca e/ou bibliotecas

digitais. Após realizar o procedimento de seleção dos estudos durante 4 meses, 33

artigos considerados relevantes foram selecionados. A Tabela 1 mostra a distribuição

detalhada destes estudos, de acordo com as fontes de busca. Tabela 1. Seleção dos Estudos.

Fontes Resultados Relevantes Não Relevantes Repetidos Incompletos EP

IEEEXplore 114 22 8 0 0 14

ACM 51 11 4 2 1 4

ScienceDirect 2991 21 15 2 0 4

72

EI Compendex 3245 41 18 9 8 6

Scopus 434 23 12 1 5 5

TOTAL 6835 118 59 14 14 33

Esta revisão sistemática da literatura não restringiu o período de publicações,

embora todos os estudos selecionados foram realizados entre 1998 e 2008, retratando

assim a relevância desta abordagem. A partir dos 33 estudos selecionados, 27 (82%)

são Estudos Empíricos, 4 (12%) Estudos Teóricos e 2 (6%) são Relatos de Experiências

Industriais, dentre estes nenhuma revisão sistemática da literatura foi identificada.

A classificação final dos estudos (artigos) selecionados foi realizada por cada

pesquisador, de acordo com o grau de classificação: Ótimo (entre 73-90), Bom (entre

55-72), Regular (entre 37-54), Ruim (entre 19-36) e Péssimo (entre 0-18). A fim de

avaliar a qualidade dos artigos selecionados, foi projetada uma escala Likert,

abrangendo cinco características: validade da investigação, ameaças à validade,

pertinência, aplicabilidade e consistência das evidências. Estas características foram

avaliadas pelos pesquisadores por meio de um formulário, a fim de definir sua

respectiva classificação, bem como obter respostas para as questões de investigação. De

acordo com as avaliações 14 estudos foram classificados como ótimo, 17 estudos como

bom e 2 estudos como regular.

3. Resultados

Entre os estudos selecionados, foram encontradas evidências relevantes que respondem

de forma satisfatória às três questões de investigação. As dificuldades existentes na

gestão da comunicação no DDS foram discutidas em 25 dos 33 estudos selecionados.

Abaixo é detalhada cada dificuldade identificada nos estudos primários, onde as

principais dificuldades concentram-se em torno das Diferenças Culturais e Dispersão

Geográfica.

16 estudos apresentaram dificuldades nas Diferenças culturais

12 estudos apresentaram dificuldades na Dispersão geográfica

8 estudos apresentaram dificuldades na Diferença de fuso horário e Planejamento da

comunicação

7 estudos apresentaram dificuldades no Atraso da informação

4 estudos apresentaram dificuldades no Gerenciamento do time, Sobrecarga de informações e

Meio de comunicação

3 estudos apresentaram dificuldades na Reunião face-to-face

Os principais fatores identificados nas equipes que influenciam o processo de

comunicação no ambiente distribuído foram discutidos em 28 dos 33 estudos. Entre os

estudos selecionados, os fatores sociais foram os fatores citados com mais freqüência

como influência no processo de comunicação, os demais fatores são detalhados abaixo,

apesar deste estudo não ter identificado provas suficientes para discorrer sobre a

satisfação do trabalho bem como a personalidade.

19 estudos apresentaram como fator identificado os Fatores sociais

12 estudos apresentaram como fator identificado a Falta de confiança na língua nativa

8 estudos apresentaram como fator identificado a Dificuldade de expressão

5 estudos apresentaram como fatores identificados Conhecimentos técnicos e Personalidade

3 estudos apresentaram como fator identificado a Satisfação no Trabalho

2 estudos apresentaram como fator identificado os Preferência por meios de comunicação

baseado em texto


73

As principais ferramentas adotadas no processo de comunicação no ambiente

distribuído foram discutidas em 28 dos 33 estudos selecionados. Entre os artigos

selecionados, a ferramenta de audioconferência foi citada com mais freqüência na

comunicação síncrona e o email foi o mais citado na comunicação assíncrona, apesar

deste estudo não ter identificado provas suficientes referentes às melhores práticas a

serem adotadas para facilitar o processo de comunicação.

21 estudos apresentaram como ferramenta utilizada o Email

12 estudos apresentaram como ferramenta utilizada a Audioconferência

11 estudos apresentaram como ferramenta utilizada o Chat

7 estudos apresentaram como ferramenta utilizada o Telefone

7 estudos apresentaram como ferramenta utilizada a Videoconferência

6 estudos apresentaram como ferramenta utilizada o Compartilhamento de Documentos

5 estudos apresentaram como ferramenta utilizada a Intranet

3 estudos apresentaram como ferramentas utilizadas NetMeeting e Fóruns

2 estudos apresentaram como ferramentas utilizadas Conferência de Dados, Calendário, Power

Point e Voip

1 estudo apresentou como ferramenta utilizada o Wiki, Fax, Collanos, Bugzilla e Team Space

4. Considerações Finais

Este artigo realizou uma revisão sistemática para responder três questões de

investigação citadas na Seção 1. Esta pesquisa apresenta uma importante contribuição

referente aos 33 estudos que estão relacionados com o processo de comunicação em um

ambiente de DDS. A mesma apresentou as dificuldades identificadas na gestão da

comunicação, bem como com a melhoria dos fatores identificados nas equipes. Algumas

das dificuldades identificadas podem ser amenizadas por meio de ferramentas utilizadas

no processo de comunicação.

É importante notar que a maioria dos estudos sobre este tema é relativamente

recente. Assim, os estudos selecionados são considerados boas evidências de pesquisa,

no entanto, este estudo deve ser replicado, a fim de abranger uma amostra mais

significativa. Permitindo análises mais amplas e comparação entre os estudos. Como

trabalhos futuros pretende-se sugerir um conjunto de práticas para melhorar a gestão de

comunicação e a criação de ferramentas mais genéricas de comunicação para o DDS

bem como adicionar recursos que ainda não tenham sido utilizados por estes conjuntos

de ferramentas, a fim de tornar o processo de comunicação para o DDS ainda mais fácil

e mais consistente.

Referências Binder, J. (2007) “Global Project Management: Communication, Collaboration and

Management Across Borders”. Gower Publishing.

Herbsleb, J.; Moitra, D. (2001) “Global Software Development”. IEEE Software

Magazine, IEEE Computer Society, EUA.

Kitchenham, B. (2007) “Guidelines for performing Systematic Literature Reviews in

Software Engineering”, V 2.3 EBSE Technical Report, EBSE-01.

Travassos, G.; Biolchini J. (2007) “Revisões Sistemáticas Aplicadas a Engenharia de

Software” In: XXI SBES - Brazilian Symposium on Software Engineering, João

Pessoa, PB, BrasilFurther Reading.

74

Os princípios ágeis na dinâmica do desenvolvimento distribuído de software

Alexandre L’Erario1

1Coordenação de Informática – Universidade Tecnológica Federal do Paraná (UTFPR) Cornélio Procópio, Paraná CEP 86300-000, Brasil

[email protected]

Abstract. The objective of this paper is to show how agile processes can contribute to the dynamics of the distributed software development. In this research, the model M3DS, presented by L'Erario (2007) was configured in an organization of global software development. Thus it was possible to identify in which states of the model M3DS agile methods could be used. The result indicates the impact of using agile processes related to steps in the process of distributed development.

Resumo. O objetivo deste artigo é apresentar como os processos ágeis podem contribuir na dinâmica do desenvolvimento distribuído de software. Nesta pesquisa, o modelo M3DS, apresentado por L’Erario (2007) foi configurado em uma organização de desenvolvimento global de software. Desta maneira foi possível identificar em quais estados do modelo M3DS os métodos ágeis poderiam ser utilizados. O resultado indica o impacto do uso de processos ágeis relacionado a etapas do processo de desenvolvimento distribuído.

1. Introdução

O gerenciamento ágil (Agile Project Management – APM) pode ser considerado uma alternativa para a gestão projetos. Griffiths (2005) indica em sua publicação as diferenças básicas entre gestão ágil de projetos e o modelo tradicional de gestão. Estas diferenças centram-se, em sua maioria, em mecanismos sinérgicos de gerenciamento, propondo uma integração e interação mais eficaz entre os stakeholders de um determinado projeto. Alguns princípios, da metodologia ágil parecem que são incompatíveis com o desenvolvimento distribuído de software. Entretanto, pesquisas como apresentadas por Paasivaara (2006) e Smits (2007) sugerem que há compatibilidade com algumas restrições.

Este artigo tem o objetivo de explorar o gerenciamento ágil de projetos na dinâmica do desenvolvimento distribuído de software. Um estudo de caso foi configurado no M3DS (L’ERARIO, 2007) para que pudesse ser identificada em quais estados do desenvolvimento distribuído a metodologia ágil pode ser utilizada e quais os possíveis impactos.

2. O modelo de dinâmica M3DS

A dinâmica de um ambiente de DDS revela o funcionamento da rede de produção, da sua concepção inicial até seu encerramento. Porém, abordar individualmente os sites na rede pode não revelar a influência que o projeto tem sobre a existência na rede.


75

Portanto, a dinâmica da rede, representada na figura 1, aborda conjuntamente dois componentes fundamentais em um ambiente de DDS. O primeiro componente indica a dinâmica de uma unidade de produção de software (site). O segundo elemento é atrelado ao projeto desenvolvido em uma rede de produção de software. Sobre esta dinâmica, há uma intersecção que ocorre quando o site precisa desenvolver um subproduto de rede, e há uma instância do projeto para vários sites. Os estados são descritos com mais detalhes em L´Erario (2009).

Figura 1 - M3DS

3. Métodos ágeis

Em 2001, houve um marco neste estilo de gerenciamento de projetos, quando Kent Back e mais 16 signatários lançaram o movimento ágil denominado de “Manifesto for Agile Software Development”. Segundo Turk (2002), a organização agile aliance, mantém uma lista de princípios do desenvolvimento ágil de projetos. Estes princípios, citados na tabela 1, basicamente reduzem a documentação e estimulam a interação informal entre os membros do projeto.

Tabela 1 - Princípios dos processos ágeis

ID Princípio 1 Nossa maior prioridade é satisfazer o cliente, mediante a entrega rápida e contínua de software; 2 Empresários e desenvolvedores devem trabalhar juntos diariamente ao longo de todo o projeto. 3 As evoluções dos requisitos são bem vindas, mesmo durante o desenvolvimento. 4 Entregar software funcionando com mais frequência. 5 O trabalho de software é a principal medida do progresso 6 Construa os projetos em torno de pessoas motivadas. Dêem-lhes o ambiente e o apoio de que necessitam, e confie neles para

fazer o trabalho. 7 As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizadas. 8 O método mais eficiente e eficaz de transmitir informações entre os indivíduos em um projeto de desenvolvimento é a

conversa face-a-face. 9 Processos ágeis promovem o desenvolvimento sustentável.

10 Atenção contínua a excelência da técnica e bons designs aumentam a agilidade 11 Simplicidade é essencial 12 Equipes de projeto avaliam sua eficácia em intervalos regulares e ajustam as suas conformidades.

4. Metodologia

A metodologia empregada neste trabalho é o estudo de caso, baseado nos delineamentos apresentados por Yin (2005). O caso investigado foi uma organização multinacional, que desenvolve software para tecnologia embarcada. A revisão literária sobre APM e

76

DDS possibilitou a construção do protocolo de pesquisa - conceito norteado por Yin (2005) – que foi aplicado em campo com o objetivo de gerar o resultado final.

5. Estudo de caso

Antes da aplicação do estudo de caso, o modelo M3DS foi mapeado na organização em questão. Para tanto, mapeou-se as atividades do desenvolvimento distribuído de software utilizado pela organização, nos estados do modelo M3DS. Nesta etapa, cada estado agregou um conjunto de atividades do processo de desenvolvimento. Após este mapeamento, uma análise sobre a utilização dos princípios, na organização em questão foi efetuada.

Uma análise dos princípios do desenvolvimento ágil sobre a dinâmica do desenvolvimento distribuído de software revelou que para cada princípio, um conjunto de estados e consequentemente transações devem ser disparados sobre certas circunstancias. Estas circunstâncias revelaram as restrições do gerenciamento ágil em projetos distribuídos de software.

Para que o princípio 1 e 4, indicados na tabela 1, sejam almejados e o produto seja entregue a sequencia de estados P0, P1, P2, P3, P4, P5 e P6 precisa ser concluída. O ciclo de P0 a P6 é longo. Há uma grande trajetória constituída de um conjunto variado de atividades que aumentam a latência entre o pedido do software e sua entrega. Foi identificado que o estado P1 tem grande influencia na velocidade da entrega. Se as atividades desenvolvidas por P1 utilizarem as mesmas bases tecnológicas de projetos anteriores, o processo de desenvolvimento da arquitetura do software tende a fluir com maior naturalidade. Consequentemente, os estados P2, P3, P4 e P5 compartilham da mesma restrição.

A distribuição pode ter duas consequências do ponto de vista do desenvolvimento ágil. A primeira é acelerar o processo de desenvolvimento, caso as atividades alocadas em P1 a P5 sejam executadas por uma equipe com experiência. Entretanto pode acontecer o oposto, principalmente quando P1 precisa consolidar alguma plataforma de desenvolvimento ou consolidar uma tecnologia.

6. Conclusões

Neste caso, foi notado que quando o projeto atinge certo ponto de maturidade, após consolidação da arquitetura, os conceitos de gerenciamento ágil de projetos podem ser empregados. Após a definição da arquitetura, que já deve ter certo grau de estabilidade, os desenvolvedores praticamente excutam o restante do projeto com um grau maior de interação, sem muito formalismo.

As tecnologias, plataformas e arquitetura da solução precisam ser amplamente difundidas e conhecidas para que os desenvolvedores passem a utilizar alguns princípios de APM. A figura 2 ilustra como o APM pode ser utilizada. Somente após consolidação da arquitetura e da plataforma de desenvolvimento, em um novo projeto é possível que parte do desenvolvimento utilize métodos ágeis.


77

Figura 2 - Ciclo de vida dos projetos com o uso da APM

Este caso em particular, comprovou que a APM pode ser utilizada juntamente com o DDS sobre certas circunstancias. Entretanto, esta pesquisa pode restringir a generalização do modelo – fato constatado pela metodologia adotada - o que pode tornar inválido o esquema apresentado na figura 2 para outras organizações. Como trabalho futuro, este mesmo protocolo de pesquisa deverá ser aplicado em outras organizações.

Referências

GRIFFITHS, M., "Teaching agile project management to the PMI" Agile Conference, 2005. Proceedings , vol., no., pp. 318-322, 24-29 July 2005

L’ERARIO, Alexandre, PESSÔA, Marcelo Schneck de Paula. An Analysis of the Dynamics and Properties of the Distributed Development of Software Environments: A Case Study. Software Engineering Research and Practice 2007: 471-477

L'ERARIO, Alexandre, PESSÔA, M. S. P., LAURINDO, F. J. B. A gestão do conhecimento na ruptura e integração de componentes no processo de desenvolvimento distribuído de software In: ALTEC - Seminário Latino íbero-americano de Gestión Tecnológica, 2009, Cartagena de Indias.

PAASIVAARA, M. and Lassenius, C.Could Global Software Development Benefit from Agile Methods?,in Global Software Engineering, 2006. ICGSE'06. International Conference, p{109--113},2006.

SMITS, H. and Pshigoda, G. 2007. Implementing Scrum in a Distributed Software Development Organization. In Proceedings of the AGILE 2007 (August 13 - 17, 2007). AGILE. IEEE Computer Society, Washington, DC, 371-375. DOI= http://dx.doi.org/10.1109/AGILE.2007.34

TURK, D., R. France, and B. Rumpe (2002, May). Limitations of agile software processes. In Third International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP 2002), Alghero, Sardinia, Italy.

YIN, Robert K.. Estudo de caso: planejamento e métodos. 3. ed. Porto Alegre: Bookman, 2005. 212 p.

iv wdds - laboratório de banco de dados · por fim, temas relacionados ao dds, propostos ao longo...

Documents