POR KELDJAN ALVES DE OLIVEIRA

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO PROPOSTA DE ESTRUTURA ANALÍTICA DE RISCOS PARA PROJET...
1 downloads 0 Views 969KB Size
UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

PROPOSTA DE ESTRUTURA ANALÍTICA DE RISCOS PARA PROJETOS DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE

POR KELDJAN ALVES DE O LIVEIRA

DISSERTAÇÃO DE MESTRADO

Recife Agosto de 2011

Universidade Federal de Pernambuco CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Keldjan Alves de Oliveira

“Proposta de Estrutura Analítica de Riscos para Projetos de Desenvolvimento Distribuído de Software"

Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestrado em Ciência da Computação.

ORIENTADOR(A): Prof. Edson Costa de Barros Carvalho Filho, PhD CO-ORIENTADOR(A): Profa. Cristine Martins Gomes de Gusmão, Doutora

RECIFE, AGOSTO/2011

Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571

Oliveira, Keldjan Alves de

Proposta de estrutura analítica de riscos para projetos de desenvolvimento distribuído de software / Keldjan Alves de Oliveira - Recife: O Autor, 2011. xiv, 67 folhas : il., fig., tab. Orientador: Edson Costa de Barros Carvalho Filho. Dissertação (mestrado) - Universidade Federal Pernambuco. CIn, Ciência da Computação, 2011.

de

Inclui bibliografia e apêndices. 1. Ciência da Computação. 2. Gerência de projetos. 3. Gerência de risco. 4. Identificação de risco. I. Carvalho Filho, Edson Costa de Barros (orientador). II. Título. 004

CDD (22. ed.)

MEI2011 – 147

AGRADECIMENTOS Primeiramente a Deus por tudo que tem me proporcionado em minha vida. Aos meus pais, Hosana e Luiz, os quais me apóiam e incentivam em todos os instantes da minha vida. À minha irmã Karla e ao marido João pelo apoio à conclusão desta outra etapa em minha vida. A minha co-orientadora e amiga Cristine Gusmão pela oportunidade de trabalho e pelo suporte durante toda a jornada de elaboração desta pesquisa. Sua inteligência, paciência e ensinamentos foram de suma importância para a concretização desta dissertação. Ao meu orientador Edson Carvalho que aceitou me orientar em momentos difíceis. Ao Júlio Venâncio pelo inestimável apoio neste trabalho e pela paciência durante todo o trajeto. Seu apoio é intangível para este trabalho e para o grupo PROMISE do qual somos membros. A todos os meus colegas e amigos que de várias formas ajudaram na conclusão deste trabalho de forma mais direta ou indiretamente. Muito obrigado.

“A melhor maneira de prever o futuro é criá-lo” (Peter Drucker)

Proposta de Estrutura Analítica de Riscos para Projetos de Desenvolvimento Distribuído de Software

RESUMO Progressivamente,

projetos

de

software

estão

se

tornando

distribuídos

geograficamente, com interação face a face limitada entre os participantes. Estes projetos enfrentam desafios particulares que requerem uma atenção cuidadosa em seu gerenciamento. A identificação dos riscos e de seus fatores significa a compreensão das origens de cada incerteza. Deve-se, portanto, buscar responder por que as incertezas existem no ambiente e quais são as condições que potencializam a concretização do evento estudado. Esta dissertação tem por objetivo propor uma Estrutura Analítica de Riscos (EAR) a qual cataloga os fatores de

riscos

identificados

no

gerenciamento

de

riscos

em

projetos

de

Desenvolvimento Distribuído de Software (DDS) a fim de permitir o entendimento da distribuição de riscos no projeto e apoiar seu gerenciamento. Para alcançar este objetivo, um Mapeamento Sistemático de Estudos da literatura dos Fatores de Riscos em DDS foi executado. Através do mapeamento, um total de 390 estudos foi identificado. Destes, vinte e três (23) estudos primários foram identificados como relevantes e classificados de acordo com a pergunta da pesquisa. A principal contribuição deste trabalho é permitir uma melhor compreensão dos fatores de riscos originados neste tipo específico de projeto gerando informações que possam auxiliar na estruturação e processos das empresas que lidam com este tipo de projeto. Palavras-chave:

Estrutura

Analítica

de Riscos;

Desenvolvimento Distribuído de Software.

VIII

Identificação

de

Riscos;

Risk Breakdown Structure for Distributed Software Development Projects ABSTRACT Increasingly, software projects are becoming distributed geographically, generating limited face to face interaction among its participants. These projects face particular challenges which require careful attention when managing them. Identifying risks and its factors means understanding the origins of each uncertainty. This way, it is important try to answer why uncertainties exist in the environment and what are the conditions which potentialize the completion of the event under study. This dissertation aims proposing a Risk Breakdown Structure (RBS) which catalogs the factors risks identified in Risk Management for Distributed Software Development (DSD) projects in order to allow understanding the distribution of risks in the project and support their management. In order to achieve this goal, a Systematic Mapping of published studies of Risk Factors in DSD was performed. By means of this mapping, a total of 390 studies were obtained. However, only twenty-three (23) primary studies were identified as relevant and classified according to the research question. The main contribution of this work is allowing a better understanding of the risk factors arisen from this specific type of project aiming generating information that can support companies in their structures and processes when dealing with this sort of project. Keywords: Risk Breakdown Structure; Risk Identification; Distributed Software Development.

IX

LISTA DE FIGURAS Figura 1 – Exemplo de uma Estrutura Analítica de Riscos (EAR) [PMI 2004]. .................................................. 20 Figura 2 – Modelo de Leavitt e o desenvolvimento de software [Leavitt 1964]. ............................................. 23 Figura 3 – String utilizada na base Scopus. ................................................................................................... 25 Figura 4 – Procedimento de Seleção dos Trabalhos no Mapeamento Sistemático. ......................................... 27 Figura 5 – Estrutura Analítica de Riscos Proposta.......................................................................................... 38

X

LISTA DE TABELAS Tabela 1 – Resumo dos conceitos adotados. ................................................................................................. 14 Tabela 2 – Estudos primários incluídos. ........................................................................................................ 28 Tabela 3 – Parte da classificação utilizada. ................................................................................................... 31 Tabela 4 – Fatores de Riscos Identificados no Mapeamento Sistemático da Literatura. ................................. 33

XI

LISTA DE ABREVIATURAS E SIGLAS CAPES – Coordenação de Aperfeiçoamento de Pessoal de Ensino Superior CASP – Critical Appraisal Skills Programme DDS – Desenvolvimento Distribuído de Software EAR – Estrutura Analítica de Riscos PMP – Project Management Professional PROMISE – Process Management and Improvements in Software Engineering RBS – Risk Breakdown Structure SEI – Software Engineering Institute UFPE – Universidade Federal de Pernambuco WBS – Work Breakdown Structure

XII

SUMÁRIO 1

INTRODUÇÃO ......................................................................................................................... 1 1.1

DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE ........................................................................ 2

1.1.1. 1.2

GERÊNCIA DE RISCOS ........................................................................................................... 4

1.3

PROBLEMA TRATADO........................................................................................................... 5

1.4

MOTIVAÇÃO ...................................................................................................................... 6

1.5

OBJETIVOS E CONTRIBUIÇÕES ................................................................................................. 8

1.6

METODOLOGIA DO TRABALHO ............................................................................................... 8

1.6.1. 1.7 2

Fases e Atividades .................................................................................................... 9

ORGANIZAÇÃO DA DISSERTAÇÃO .......................................................................................... 10

GERENCIAMENTO DE RISCOS NA ENGENHARIA DE SOFTWARE ............................................ 11 2.1

RISCOS E A ENGENHARIA DE SOFTWARE ................................................................................... 11

2.2

RISCO VERSUS INCERTEZA VERSUS FATORES DE RISCOS ............................................................... 13

2.3

MÉTODOS DE IDENTIFICAÇÃO DOS RISCOS ................................................................................ 14

2.3.1.

Brainstorming ........................................................................................................ 15

2.3.2.

Listas de Verificação .............................................................................................. 16

2.3.3.

Comparação por Analogia ...................................................................................... 16

2.3.4.

Análise de Premissas .............................................................................................. 16

2.3.5.

Entrevistas com Especialistas ................................................................................. 17

2.3.6.

Análise Causal ........................................................................................................ 17

2.3.7.

Técnica Delphi........................................................................................................ 18

2.3.8.

Análise SWOT ........................................................................................................ 18

2.3.9.

Estrutura Analítica de Riscos (EAR) ......................................................................... 19

2.4

O MODELO DE LEAVITT PARA OS RISCOS DE SOFTWARE .............................................................. 21

2.4.1. 2.5 3

Definições ................................................................................................................ 2

Riscos de Software segundo Leavitt ........................................................................ 21

RESUMO DO CAPÍTULO ....................................................................................................... 23

PROPOSTA DE ESTRUTURA ANALÍTICA DE RISCOS ................................................................ 24 3.1

3.1.1.

Questão da Pesquisa .............................................................................................. 25

3.1.2.

Estratégia e Processo de Busca............................................................................... 25

3.1.3.

Critérios de Inclusão e Exclusão e Procedimentos de Seleção................................... 28

3.1.4.

Processo de Extração dos Dados ............................................................................. 28

3.2

XIII

MAPEAMENTO SISTEMÁTICO DA LITERATURA ............................................................................ 24

ESTRUTURA ANALÍTICA DE RISCOS PROPOSTA .......................................................................... 33

3.2.1.

Fatores de Riscos Identificados ............................................................................... 33

3.2.2.

Disposição conforme Modelo de Riscos de Software de Leavitt ............................... 37

3.3

3.3.1.

Primeiro Momento ................................................................................................. 39

3.3.2.

Segundo Momento ................................................................................................ 41

3.4 4

AVALIAÇÃO DA EAR .......................................................................................................... 38

RESUMO DO CAPÍTULO ....................................................................................................... 43

CONTRIBUIÇÕES E TRABALHOS FUTUROS ............................................................................. 44 4.1

PRINCIPAIS CONTRIBUIÇÕES ................................................................................................ 44

4.2

LIMITAÇÕES ENCONTRADAS................................................................................................. 45

4.3

TRABALHOS FUTUROS ........................................................................................................ 46

REFERÊNCIAS BIBLIOGRÁFICAS.................................................................................................... 47 APÊNDICE A................................................................................................................................. 59 APÊNDICE B................................................................................................................................. 60 APÊNDICE C ................................................................................................................................. 63

XIV

1

INTRODUÇÃO

Ao gerenciarmos um projeto de software, o planejamento é relevante no sentido de ser considerado como um fator primordial para o sucesso de um projeto. Em contrapartida, o mau planejamento implica em atrasos e aumento dos custos, ou ainda em cancelamento do projeto. Assim, o mau planejamento tem como um resultado direto o provável insucesso do projeto em questão. Atualmente, para obter sucesso, muitas empresas perceberam que elas tinham de mudar a partir de empresas monolíticas, isoladas e centralizadas para organizações diversificadas, distribuídas globalmente e cooperativas [Prikladnicki e Yamaguti 2004, Tiako 2005]. Essa globalização propicia muitas vantagens tais como: (i) tempo de colocação no mercado (time-to-market) reduzido, (ii) aumento da produtividade, (iii) diminuição dos custos, (iv) aumento da qualidade, (v) aumento da flexibilidade, (vi) melhor distribuição dos recursos, (vii) melhor utilização das competências e (viii) acesso a novos mercados globais. Porém, para que isso seja verdade, o projeto distribuído em locais distintos precisa ser gerenciado com sucesso. Utilizando-se metodologias específicas a DDS (Desenvolvimento Distribuído de Software) a probabilidade de sucesso é maior uma vez que estes ambientes possuem características particulares que requerem um gerenciamento diferenciado [Herbsleb e Moitra 2001]. O objetivo dos gerentes de projetos junto aos stakeholders é realizar a entrega dos produtos e serviços dentro das expectativas de tempo, custo e qualidade. Porém, times distribuídos em projetos de software globais têm de lidar com novos desafios, tais como organização do projeto, controle do progresso, comunicação diária, além do gerenciamento das diferenças culturais. Dessa forma, esta pesquisa tem como foco propor uma Estrutura Analítica de Riscos (EAR) em projetos distribuídos de software com o objetivo de catalogar os fatores de riscos bem como permitir o entendimento da distribuição de riscos no projeto e apoiar seu gerenciamento. A pesquisa busca identificar os fatores de riscos mais comuns em projetos DDS (Desenvolvimento Distribuído de Software) através do mapeamento da literatura existente. Espera-se que esta 1

pesquisa proporcione uma melhor compreensão dos fatores de riscos originados neste tipo específico de projeto gerando informações que possam auxiliar na estruturação e processos das empresas que lidam com este tipo de projeto.

1.1 DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE

O Desenvolvimento Distribuído de Software (DDS) consegue dividir o trabalho espalhando as tarefas relacionadas ao desenvolvimento de software em distintos centros de desenvolvimento. Este modelo de software tem se tornado um modelo de negócio popular relacionado às organizações de software. Existem várias razões que encorajam a adoção desta forma de desenvolvimento de software como, (i) diminuição dos custos de desenvolvimento de software em locais offshore [Nasscom-McKinsey 2002], (ii) aprimoramento expressivo da mão-de-obra especializada em locais remotos [Carmel e Agarwal 2002] e o (iii) progresso nas tecnologias de comunicação que tem facilitado a colaboração entre os trabalhadores distribuídos [Cairncross 1997, Carmel 1999]. Por outro lado, pesquisas existentes demonstram que o trabalho distribuído pode levar mais tempo para finalizar do que projetos similares onde todo o trabalho é colocalizado [Sarker e Sahay 2004]. Pesquisas anteriores sobre como a distribuição geográfica afeta as atividades do desenvolvimento de software foram executados na Lucent Technologies [Herbsleb e Moitra 2001]. As principais conclusões foram que a distância afeta negativamente os custos, tempo e qualidade. Contudo, este estudo, em particular, foi conduzido em um contexto de uma aplicação no domínio de telecomunicação e envolveu tarefas complexas.

1.1.1. DEFINIÇÕES

A área de DDS traz diversos conceitos, porém muitas vezes são considerados sinônimos. Com o intuito de esclarecer as diferenças, nesta pesquisa considera-se DDS como sendo uma área geral. Contudo, quatro terminologias podem ser destacadas: (i) Times Virtuais (Virtual Teams) [Powell et al. 2004, 2

Gibson e Gibbs 2006]; (ii) Terceirização Offshore (Offshore Outsourcing) [Kaiser e Hawk 2004, Pfannenstein e Tsai 2004]; (iii) Desenvolvimento Global de Software (Global Software Development) [Herbsleb e Moitra 2001, Damian e Moitra 2006] e (iv) Organizações Virtuais (Virtual organizations) [Bleecker 1994, Markus et al. 2000]. Time Virtual é uma terminologia comum e frequentemente utilizada em diversos estudos [Martins et al. 2004, Hertel et al. 2005, Gillam e Oppenheim 2006,Schiller e Mandviwalla 2007, Curseu et al. 2008]. Times virtuais são times funcionais que dependem da comunicação mediada por tecnologias enquanto cruzam diversas fronteiras diferentes como as geográficas, temporais e organizacionais [Martins et al. 2004]. Além disso, o termo time sugere um grupo de indivíduos que colaboram e apresentam um alto nível de interdependência e integração [Powell et al. 2004]. Quando times virtuais são compostos de diferentes organizações, são conhecidos como terceirização offshore. O conceito de Terceirização Offshore sugere uma ênfase nas transações externas à organização. O termo offshore refere-se ao uso de representantes externos para realizar uma ou mais atividades da organização [Dibbern et al. 2004], além de enfatizar o cruzamento das fronteiras do país. O surgimento de organizações com grande dependência na Tecnologia da Informação e Comunicação (TIC) e organizações independentes de empresa têm sido caracterizadas como organizações virtuais. Organizações Virtuais são definidas como redes flexíveis de entidades independentes e distribuídas globalmente (pessoas ou instituições) que compartilham conhecimento e recursos e trabalham voltadas a um objetivo comum [Ripeanu et al. 2008]. Times virtuais são diferentes de organizações virtuais, pois são limitados a grupos com membros distribuídos que apresentam um alto nível de interdependência e integração. Organizações virtuais também são diferentes de terceirização offshore por serem limitadas a transações independentes de empresa. As organizações virtuais se inspiram particularmente no movimento de software de código aberto (opensource) [Markus et al., 2000]. O desenvolvimento de software por colaboradores distribuídos conceituado 3

por

Desenvolvimento

Global

de

Software

(Global

é

Software

Development). Este conceito é baseado na observação que o desenvolvimento de software está se tornando progressivamente uma tarefa multicultural, multilocalizada e distribuída globalmente [Herbsleb e Moitra 2001]. Assim, o Desenvolvimento Global de Software é compatível com os conceitos descritos anteriormente. Contudo, em geral, esta definição não aparece como um conceito definido ou claramente estabelecido como Time Virtual, Terceirização Offshore e Organizações Virtuais. Assim, a definição usada neste trabalho é Desenvolvimento Distribuído de Software (DDS) o qual pode ser entendido como um Time Virtual, uma terceirização Offshore, uma Organização Virtual e um esforço de Desenvolvimento Global de Software. A terminologia DDS foi escolhida, uma vez que o escopo do desenvolvimento está restrito a software e porque o time de desenvolvimento não está necessariamente distribuído ao redor do planeta, mas num outro prédio ou apenas numa cidade diferente. Segundo o Guia PMBOK [PMI 2004], um projeto é um empreendimento temporário com o objetivo de criar um produto ou serviço único. Por Temporário, entende-se que cada projeto tem um começo e um fim bem definidos. Por Único, entende-se que o produto ou serviço produzido é de alguma forma diferente de todos os outros produtos ou serviços semelhantes. Já o Desenvolvimento Distribuído de Software é para Carmel um modelo de desenvolvimento de software onde os envolvidos em um determinado projeto estão dispersos [Carmel 1999]. Dessa forma, um Projeto de Desenvolvimento Distribuído de Software pode ser caracterizado como um empreendimento temporário com o objetivo de criar um produto ou serviço único cujos envolvidos estão dispersos.

1.2 GERÊNCIA DE RISCOS

É notável a crescente necessidade do uso de produtos de software pelas organizações, sendo muitas vezes essencial à sobrevivência delas. Da mesma forma as empresas que desenvolvem software estão sempre buscando estar alinhadas às necessidades de negócio das organizações de modo que seus produtos gerados atendam às necessidades dos seus clientes, dentro de restrições 4

de escopo, tempo, custo e qualidade. Diante destes desafios, as empresas que produzem software precisam gerenciar de maneira eficiente seus projetos, caso contrário podem perder competitividade. Dentro da área de Gerência de Projetos de Software, existem diversos elementos a serem gerenciados. Um deles são os riscos, considerados parte fundamental dentro da Gerência de Projetos de Software. Inclusive alguns autores consideram que gerenciar projetos é gerenciar riscos [De Marco 1997]. Em Engenharia de Software este argumento é válido, uma vez que projetos de software normalmente envolvem incertezas de diversas naturezas durante todo seu processo de desenvolvimento, normalmente relacionadas a fatores como inovação, mudanças constantes, custos, entre outros. Além do mais, o próprio software possui alguns atributos que contribuem para aumentar o nível de incerteza dos projetos que visam sua construção. São eles [Brooks 1987]: i) complexidade, ii) conformidade com o ambiente, iii) instabilidade e iv) invisibilidade. Logo, podemos dizer que projetos de software são empreendimentos de risco. Apesar da relevância do uso do gerenciamento de riscos de projetos de software, dada à diversidade de abordagens e processos propostos nos últimos 20 anos – tais como [Boehm 1989, Carr et al. 1993, Karolak 1996, Charette 2001, Kontio 2001, Gusmão 2007] –, a Gerência de Riscos acaba sendo muitas vezes negligenciada pelas organizações que desenvolvem software. Um dos motivos para isto é que o conceito de risco é abstrato e subjetivo, e a sua gerência não traz nenhum resultado prático aparente de imediato [Trigo et al. 2008].

1.3 PROBLEMA TRATADO

A necessidade de entender e apoiar o gerenciamento de projetos de desenvolvimento distribuído de software integrando o conhecimento existente e desenvolvendo abordagens compreensíveis, estimulam o uso do gerenciamento de riscos. Contudo, ainda que a Gerência de Riscos seja um processo saudável para as organizações, sua utilização ainda está aquém das expectativas [Gusmão 2007].

5

Um problema evidente também é que as abordagens de gerenciamento de riscos tradicionais fracassam quando enfrentam os desafios inerentes aos projetos de desenvolvimento distribuído de software. Além disto, a necessidade de atenção no gerenciamento de riscos em ambientes distribuídos é refletida pela quantidade significante de pesquisas recentes [Erickson e Evaristo 2006, Prikladnicki et al. 2006, Ebert et al. 2008, Iacovou e Nakatsu 2008, Nakatsu e Iacovou 2009]. Neste cenário, surge a pergunta: como ajudar os gerentes de projetos a identificar os riscos que incidem em projetos de desenvolvimento distribuído de software e apresentá-los de uma forma compreensível? Em seu trabalho, Persson oferece um guia abrangente da literatura publicada no gerenciamento distribuído de software [Persson et al. 2009]. Os autores analisam 117 artigos a partir de várias fontes categorizando os vários riscos identificados e construindo uma matriz de correspondência entre os riscos e a bibliografia que descrevem as abordagens e técnicas no gerenciamento destes riscos. Isto permitiu encontrar rapidamente qual trabalho tem uma determinada ideia para um problema específico no gerenciamento de projeto. Contudo, a disposição das informações poderia ser organizada mais intuitivamente para ajudar os stakeholders na identificação dos riscos.

1.4 MOTIVAÇÃO

Este trabalho foi motivado a partir da realização de entrevistas com profissionais da área de gerenciamento de projetos em empresas do âmbito federal de estadual em Pernambuco. Segundo Silva e Menezes, a Entrevista é a obtenção de informações de um entrevistado, sobre determinado assunto ou problema [Silva e Menezes 2001]. Para Lakatos e Marconi, a entrevista consiste numa conversa face a face, através da qual se busca obter informações sobre determinado assunto [Lakatos e Marconi 1996]. A entrevista como coleta de dados sobre um determinado tema científico é a técnica mais utilizada no processo de trabalho de campo.

6

A preparação da entrevista é uma das etapas mais importantes da pesquisa a qual requer tempo e exige alguns cuidados, dentre os quais se destacam: o planejamento da entrevista focando o objetivo a ser alcançado; a escolha do entrevistado, o qual deve ser alguém que tenha familiaridade com o tema pesquisado; a oportunidade da entrevista, ou seja, a disponibilidade do entrevistado em fornecer a entrevista que deverá ser marcada com antecedência para que o pesquisador se assegure de que será recebido; as condições favoráveis que possam garantir ao entrevistado o segredo de suas confidências e de sua identidade e, por fim, a preparação específica que consiste em organizar o roteiro ou formulário com as questões importantes [Lakatos e Marconi 1996]. Com o objetivo de coletar dados e informações acerca da área de gerenciamento de riscos na prática, os benefícios e os desafios de sua implementação, foram realizadas entrevistas com profissionais chaves que gerenciam projetos no âmbito do Estado de Pernambuco e também na esfera federal. O questionário utilizado como guia na entrevista está presente no Apêndice A deste trabalho. As entrevistas foram realizadas com dois profissionais certificados PMP (Project Management Professional) e dois não certificados. Contudo, todos os entrevistados possuíam mais de 3 anos gerenciando projetos e no mínimo 7 anos trabalhando na área de Gerenciamento de Projetos de Software. As idades variaram de 28 a 34 anos. Com as entrevistas, foi possível verificar que a Gerência de Riscos ainda não é aplicada formalmente nas empresas, embora sua importância seja conhecida. Quando os riscos são levados em consideração, apenas uma forma de identificação ad-hoc é adotada por meio de planilhas eletrônicas. Dessa forma, nenhum profissional especializado no gerenciamento de riscos é designado dentro das empresas em que os entrevistados trabalham. Considerando o gerenciamento de projetos distribuídos, apenas as duas empresas federais possuem este tipo de desenvolvimento. Contudo, a Gerência de Riscos é tratada da mesma forma adhoc neste tipo ambiente. As duas demais empresas, não utilizam esta abordagem em seus projetos não podendo ser avaliadas nesse aspecto.

7

Neste cenário, evidencia-se que uma forma fácil e intuitiva de identificação de riscos poderia auxiliar os interessados na aplicação de um processo de gerenciamento de riscos de forma mais efetiva.

1.5 OBJETIVOS E CONTRIBUIÇÕES

O principal objetivo desta dissertação é propor uma Estrutura Analítica de Riscos (EAR) para Projetos de Desenvolvimento Distribuído de Software visando à identificação dos riscos que podem incidir neste tipo de ambiente. O objeto da estrutura proposta é agrupar os fatores de riscos identificados na literatura com a finalidade de auxiliar os gerentes de projeto na identificação dos riscos.

Desta forma, para o alcance efetivo deste objetivo principal desenvolveuse: 1. Entrevistas com profissionais chaves da esfera estadual e federal. 2. Um mapeamento sistemático da literatura. 3. Criação da EAR. 4. Avaliação da EAR desenvolvida. Com a estrutura criada espera-se aprimorar a identificação de riscos em estágios mais iniciais do desenvolvimento de software em ambiente distribuídos reduzindo perdas e possíveis falhas.

1.6 METODOLOGIA DO TRABALHO

Essa seção irá apresentar a metodologia utilizada para conseguir finalizar a pesquisa com sucesso, mostrando os passos com seus respectivos objetivos.

8

1.6.1. FASES E ATIVIDADES

A metodologia de pesquisa adotada para esta dissertação de mestrado foi, primeiramente, a revisão bibliográfica para conhecer o estado atual da Gerência de Riscos nos projetos de desenvolvimento distribuído de software. Esta fase foi importante para decisão do tema a ser desenvolvido na pesquisa. O passo seguinte foi realizar entrevistas com gerentes de projetos de empresas do âmbito estadual e federal. Esta atividade foi importante para identificar como a disciplina de Gerência de Riscos é tratada e percebida por esses profissionais de forma a criar um ambiente mais seguro no desenvolvimento de seus projetos. Com estes insumos, foi desenvolvido um estudo mais detalhado acerca do dos fatores de riscos que surgem no desenvolvimento distribuído de software. O estudo foi dividido em 6 fases, conforme detalhamento a seguir: Fase 1 – Estudo inicial: Esta fase contemplou revisão bibliográfica e estudo do estado da arte do gerenciamento de riscos através de buscas manuais, leitura de artigos e documentos acadêmicos, como dissertações e teses. Fase 2 – Entrevistas: Realização de entrevistas com profissionais chaves da área de gerenciamento de projetos das esferas estadual e federal, com o objetivo de identificar a percepção dos mesmos sobre como está sendo tratada a Gerência de Riscos em algumas empresas no Brasil. Fase 3 – Estudo detalhado: Com base nos achados obtidos nas fases 1 e 2, um mapeamento sistemático da literatura foi realizado. A finalidade estava em identificar trabalhos que abordam a identificação de fatores de riscos que incidem ambientes de desenvolvimento distribuídos de software. Fase 4 – Criação da EAR: Esta fase promoveu o compilamento das informações coletadas em uma árvore de Fatores de Riscos culminando na criação da EAR agrupando todos os fatores inter-relacionados. Fase 5 – Avaliação da EAR: Aplicação de avaliações não presenciais junto a profissionais da área de gerenciamento de projetos e pesquisadores no âmbito acadêmico para avaliar a relevância e qualidade da EAR.

9

1.7 ORGANIZAÇÃO DA DISSERTAÇÃO

Este documento está organizado em quatro capítulos. Após este capítulo introdutório, os capítulos subsequentes foram estruturados da seguinte forma: Capítulo 2 – Gerenciamento de Riscos na Engenharia De Software Apresenta os riscos na Engenharia de Software e apresenta os conceitos de riscos, fator de risco e incerteza obtidos na literatura. Este capítulo também mostra os principais métodos de identificação de riscos que podem ser utilizados na Gerência de Riscos além da EAR. Por fim, o modelo de Leavitt utilizado na organização da EAR proposta é apresentado junto à sua visão de riscos. Capítulo 3 – Proposta de Estrutura Analítica de Riscos Este capítulo discute a metodologia de Mapeamento Sistemático adotado na condução do trabalho e apresenta a construção da EAR proposta junto a seu resultado. No final, as avaliações realizadas na EAR proposta são relatadas junto às suas considerações. Capítulo 4 – Contribuições e Trabalhos Futuros Este capítulo final apresenta as conclusões, principais contribuições identificadas, limitações e perspectivas de progresso da estrutura proposta. Ao final da dissertação, as referências bibliográficas utilizadas na construção deste trabalho e os apêndices desenvolvidos foram disponibilizados.

10

2

GERENCIAMENTO DE RISCOS NA ENGENHARIA DE SOFTWARE

Risco é um tema que possui uma ampla literatura, abrangendo diversas áreas como ciências econômicas, matemática e administração financeira. A maioria dos sistemas desenvolvidos ainda apresenta atrasos no desenvolvimento, custos acima do planejado e funcionalidades aquém das expectativas devido a riscos inesperados, não planejados ou simplesmente ignorados mesmo com a adoção das novas tecnologias, modelos de processos, técnicas, métodos e ferramentas disponíveis [Rios 2005]. A gerência de projetos, em especial, a Gerência de Riscos, procura monitorar todo o processo de desenvolvimento do software identificando riscos, suas probabilidades de manifestação, estimando os prejuízos e orientando quanto aos procedimentos a serem adotados. O objetivo deste capítulo, através das próximas seções, é apresentar os riscos na Engenharia de Software na seção 2.1. Ainda, permite definir os conceitos de riscos, incerteza, fator de risco e oportunidade na seção 2.2. Na Seção 2.3 métodos de identificação de riscos são tratados. Na Seção 2.4, a estrutura para identificação de riscos utilizada neste trabalho é apresentada. Por fim, na seção 2.5 é apresentado o modelo de Leavitt [Leavitt 1964] utilizado na organização da EAR proposta.

2.1 RISCOS E A ENGENHARIA DE SOFTWARE

O Risco na área de software foi representado de forma sistemática por Barry W. Boehm, em 1988, através do Modelo Espiral [Boehm et al 2004], cujo princípio é ser incremental e dirigido à análise de riscos. O desenvolvimento incremental é uma estratégia para a obtenção de progresso em pequenos passos, pela divisão de um problema em subproblemas e a posterior combinação das soluções encontradas. Atualmente, a área que trata riscos na Engenharia de Software evoluiu, passando de uma análise dentro das fases do modelo de desenvolvimento de software para se tornar uma gerência que permeia todos os processos do ciclo de vida do software [Gusmão 2007]. 11

Hall define que os riscos de software podem ser caracterizados como [Hall 1998]: 

Riscos

de

Projeto

de

Software.

Define

os

parâmetros

operacionais, organizacionais e contratuais do desenvolvimento de software. Inclui limites de recursos, interfaces, relacionamentos com fornecedores ou restrições de contratos. 

Riscos de Processo de Software. Relacionam-se os problemas técnicos e de gerenciamento. Nos procedimentos de gerência podem-se encontrar riscos em atividades como: planejamento, definição e contratação de equipe de trabalho, garantia de segurança e configuração de gerência. Nos procedimentos técnicos, podem-se encontrar riscos nas atividades: análise de requisitos, projeto, codificação e testes, por exemplo.



Riscos de Produto de Software. Contém as características intermediárias e finais do produto. Estes tipos de riscos têm origens nos

requisitos

de

estabilidade

do

produto,

desempenho,

complexidade de codificação e especificação de testes. Muitas classificações são encontradas na literatura relacionada à Gerência de Projetos [Carr et al 1993, Sommerville 2003, PMI 2009], uma delas é o uso de taxonomia de riscos (Taxonomy-Based Risk Identification) como a apresentada pelo Instituto de Engenharia de Software (SEI - Software Engineering Institute) onde os riscos são classificados dentro de categorias para melhor entendimento de sua natureza. Alguns estudos e abordagens na literatura, que tratam a área de Gerência de Riscos, evoluíram, ou mesmo adaptaram, as categorias de riscos inicialmente apresentadas na taxonomia proposta pelo SEI [Costa et al 2005, Gusmão et al 2005, Webster et al 2005]. As categorias de riscos favorecem a identificação dos riscos em um ambiente promovendo uma classificação e organização dos riscos identificados em grupos lógicos. De forma geral, nos modelos de processos de gerenciamento de riscos é solicitada à definição das categorias ou classes de riscos (classificações) de acordo com as características do ambiente de desenvolvimento em questão. 12

2.2 RISCO VERSUS INCERTEZA VERSUS FATORES DE RISCOS

O Guia PMBOK (Project Management Body of Knowledge) [PMI 2004] define um risco de projeto como um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade. O objetivo da Gerência de Riscos do projeto é aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos negativos no projeto. O Instituto de Engenharia de Software (SEI) define risco como a possibilidade de sofrer perdas nos objetivos do projeto como impactar na qualidade do produto final, atrasar cronograma, aumentar custos ou mesmo falhar o projeto. Considerando que a noção de risco associada à possibilidade de dano, perda ou estrago é de conhecimento claro e direto, alguns autores definem risco como resultados que, embora não certos possuem probabilidades quantificáveis pela experiência ou dados estatísticos e para a qual é possível fazer uma estimativa [Knight 1921; Marshall 2002]. Já incerteza é a impossibilidade de quantificar adequadamente o resultado considerando a ausência de experiências ou ocorrências anteriores [Gusmão 2007]. De acordo com Schmidt [Schmidt et al 2001], um fator de risco pode ser definido como uma condição que pode gerar uma séria ameaça a finalização com sucesso de um projeto de desenvolvimento de software. Brasiliano [Brasiliano 2009] define fator de risco como a origem ou causa de cada perigo. Já perigo é definido como a origem da perda. Por exemplo, incêndio de uma caixa de papelão é um perigo cujos riscos podem ser as condições de armazenagem, carga de incêndio e cultura de funcionários. Em outras palavras, podemos considerar que os Fatores de Riscos são condições "certas", "concretas" existentes na organização que irão potencializar ou facilitar a ocorrência ou concretização de uma incerteza – o perigo. O gerenciamento de riscos de projeto tem como meta principal o afastamento das incertezas relacionadas aos riscos direcionando os projetos para oportunidades. Outra forma de tratamento dos riscos é listar fatores de riscos os 13

quais são variáveis que podem tornar-se riscos em um baixo, médio ou alto grau de incidência no ambiente [Gusmão 2007]. Ao longo deste trabalho, os conceitos adotados como base são apresentados na Tabela 1. Tabela 1 – Resumo dos conceitos adotados.

Elemento

Conceito

Risco

Resultados não certos que possuem probabilidade quantificável.

Fator de Risco

Condição que pode gerar uma séria ameaça a finalização com sucesso de um projeto

Incerteza

Impossibilidade de quantificar adequadamente o resultado

Assim, conforme apresentando na Tabela 1, o conceito de Risco utilizado nesta dissertação é entendido como resultados não certos que possuem uma probabilidade expressa através de um valor e Incerteza como a impossibilidade de quantificar tais resultados. Já Fator de Riscos é utilizado como uma condição que pode criar uma ameaça que impacta na finalização com sucesso de um projeto.

2.3 MÉTODOS DE IDENTIFICAÇÃO DOS RISCOS

Atualmente, diversos métodos disponíveis na literatura permitem a identificação de riscos [Boehm 1991; Higuera 1994; Moynihan 1997; Machado 2002; Pressman 2006]. O guia PMBOK [PMI 2004] referencia alguns destes métodos que incluem Brainstorming, listas de verificação (checklist), comparação por analogia, análise de premissas, decomposição, técnicas de diagramação, técnica Delphi, revisão de documentação (plano e modelo de projeto) e entrevistas. Esta Seção define quais os principais métodos de identificação de riscos utilizados atualmente incluindo o uso da EAR. Contudo, este trabalho restringe-se a proposição de uma EAR apenas.

14

2.3.1. BRAINSTORMING

Brainstorming é uma técnica de geração de ideias em grupo que se divide em duas fases: (1) fase criativa, onde os participantes apresentam o maior número possível de ideias (2) fase crítica, onde cada participante defende sua ideia com o objetivo de convencer os demais membros do grupo. Na segunda fase são filtradas as melhores ideias, permanecendo somente aquelas aprovadas pelo grupo. A técnica é composta de quatro regras básicas: (1) As críticas devem ser banidas – a avaliação das ideias deve ser guardada para momentos posteriores; (2) A geração livre de ideias deve ser encorajada; (3) Foco na quantidade – quanto maior o número de ideias, maiores as chances de se ter ideias válidas; (4) Combinação e aperfeiçoamento de ideias geradas pelo grupo. A meta do brainstorming é obter uma lista abrangente de riscos do projeto. A equipe do projeto normalmente realiza o brainstorming, frequentemente com um conjunto multidisciplinar de especialistas que não fazem parte da equipe. Ideias sobre os perigos, riscos e fatores de riscos do projeto são geradas sob a liderança de um facilitador. O Brainstorming é popular por uma série de razões, dentre as quais podemos citar que todos se sentem envolvidos com a oportunidade de compartilhar suas opiniões abertamente. A técnica permite aos envolvidos usar a criatividade, além de encorajar o trabalho em equipe criando um senso de responsabilidade compartilhada sobre os resultados. Brasiliano reforça a utilização do Brainstorming para identificar e listar os perigos (as incertezas) da organização em seu método de análise de risco [Brasiliano 2009]. Contudo, existem alguns pontos que podem levar à sua ineficiência, como por exemplo, a dificuldade de conseguir as pessoas corretas para participar podendo levar a falta de consideração de riscos importantes e a imposição da visão de indivíduos poderosos podendo também inibir a contribuição dos demais.

15

2.3.2. LISTAS DE VERIFICAÇÃO

Listas de verificação (checklists) são geralmente usadas para identificar os riscos associados a um processo e para assegurar a concordância entre as atividades desenvolvidas e os procedimentos operacionais padronizados. Através deste método, diversos aspectos do sistema são analisados por comparação com uma lista de itens pré-estabelecidos, criada com base em processos similares, objetivando descobrir e documentar possíveis deficiências do sistema. Contudo, algumas desvantagens estão associadas à impossibilidade de listar todos os riscos e a limitação da identificação aos itens pertencentes à lista do usuário (categorias e fatores de risco). Em seu trabalho, Barry Boehm fornece uma tabela que lista os 10 riscos mais prováveis que podem resultar na falha de um projeto de desenvolvimento de software [Boehm 1991].

2.3.3. COMPARAÇÃO POR ANALOGIA

Este método tem por base a comparação entre projetos, identificando projetos similares para a efetiva comparação de acordo com os critérios determinados. É um método de simples aplicação, mas devido à subjetividade na determinação das características para a comparação entre projetos, possui dependência na análise e interpretação dos dados históricos e no nível de detalhamento descrito.

2.3.4. ANÁLISE DE PREMISSAS

Além dos riscos envolvidos na execução de um projeto, existem os riscos associados às hipóteses e premissas utilizadas na definição do plano de projeto e no próprio ambiente organizacional. Estas premissas são identificadas e validadas ao longo do desenvolvimento, como forma de prevenção dos riscos (imprecisão, 16

inconsistência, incompletude), evitando a execução de um projeto baseado em premissas irreais [PMI 2004].

2.3.5. ENTREVISTAS COM ESPECIALISTAS

A entrevista com especialistas é um método de coleta de informações, utilizada no levantamento e na identificação de riscos. Inicialmente os especialistas são identificados, selecionados, a agenda é criada e o questionário é desenvolvido. A aplicação dos questionários pode ser desenvolvida através de entrevistas individuais ou da formação de grupos focais (formados por profissionais com perfis similares e existe a figura do facilitador para coletar as informações definidas) [Victoria et al. 2000]. Grupo focal é uma forma de identificação de conteúdos através de entrevistas coletivas muito utilizadas nas ciências humanas. Os grupos são formados por profissionais com perfis similares e existe a figura do facilitador para coletar as informações definidas. A vantagem deste método é a obtenção de diversas visões de riscos, dentro do contexto escolhido, pela participação de profissionais de perfis e experiências distintas. Entre as desvantagens pode-se associar a criação do questionário, não limitando as respostas dos entrevistados, e a forte dependência existente entre entrevistado e entrevistador.

2.3.6. ANÁLISE CAUSAL

Este método é baseado na análise entre um efeito e sua possível causa para que seja identificada a origem do risco. Entre os métodos que empregam a análise causal estão: Diagrama de Causa e Efeito, também conhecido com Espinha de Peixe (fishbone) ou Diagrama de Ishikawa [Brasiliano 2009], e a técnica dos 6 W´s (Who, Why, What, Whichway, Wherewithal, When) [De Marco 1997]. Ambos os métodos estão descritos no Guia PMBOK [PMI 2004], na fase de identificação de riscos, porém Elaine Hall os endereça na atividade de análise de riscos, uma vez que têm por base a análise das lições aprendidas [Hall 1998]. 17

2.3.7. TÉCNICA DELPHI

Esta técnica é utilizada quando existe a necessidade de obter o consenso sobre determinado assunto, entre um grupo de especialistas. É uma variação dos grupos focais, onde especialistas são identificados, mas participam anonimamente [Victoria et al 2000]. Um facilitador usa um questionário para levantar idéias sobre os riscos mais importantes de um projeto em questão. As respostas são apresentadas e circulam entre o grupo para que sejam inseridos comentários, caso desejem. O consenso é atingido através de diversas rodadas. Ao final um grupo de riscos avaliados e aprovados pelo grupo é apresentado e consolidado. Como vantagem desta técnica, tem-se a redução dos desvios nos dados e o equilíbrio mantido entre as influências dos especialistas [PMI 2004]. Como desvantagem, igualmente a entrevista com especialistas, tem dependência direta com as questões apresentadas (questionário), limitando a troca de idéias.

2.3.8. ANÁLISE SWOT

A análise SWOT (Strength, Weakness, Opportunity and Threats) está mais voltada para uma avaliação organizacional do que para um projeto individualmente [Brasiliano 2009; PMI 2009; Heldman 2005]. Dessa forma, como o acrônimo especifica, é uma análise que procura aferir questões positivas e negativas da organização através dos pontos fortes e fracos encontrados. A finalidade é identificar na organização onde existem vulnerabilidades e como potencializar e fortalecer determinado tipo de atividade realizada com perfeição. Como exemplo, pode-se citar uma situação em que uma organização desenvolvedora de software tem em seu histórico de atuação, sucesso em projetos de desenvolvimento, mas fracassos em projetos de montagem de laboratórios. Ora, se um novo projeto a ser executado é para montar um laboratório, o impacto dos riscos associados às atividades para execução deste projeto têm maiores consequências para a organização. De imediato devem ser tratados os pontos falhos neste cenário [Gusmão 2005]. 18

No trabalho de Brasiliano [Brasiliano 2009], a análise SWOT foi adaptada para a área de Gestão de Riscos e sua utilização tem por objetivo ranquear fraquezas, oportunidades, ameaças e forças: os fatores facilitadores dos perigos identificados.

2.3.9. ESTRUTURA ANALÍTICA DE RISCOS (EAR)

Risco é uma dimensão complexa dos projetos que surge de diversas fontes e tem um amplo escopo de efeitos possíveis, mas pode ser controlado de forma apropriada se for identificado de forma apropriada. No processo de identificação de riscos, várias técnicas podem ser usadas, porém as técnicas mais comuns tendem a gerar uma lista de riscos pouco estruturada que em muitos casos não ajuda diretamente os gerentes de projetos. Contudo, alguns autores avançaram na estruturação de riscos além de apenas listar os tipos de riscos enfrentados no projeto [Hillson 2002]. A EAR (Estrutura Analítica de Riscos) ou RBS (Risk Breakdown Structure) foi descrita pela primeira vez por David Hillson como uma ferramenta útil para estruturar o processo de risco [Hillson et al. 2006]. A estrutura é um agrupamento orientado à origem do risco, que organiza de forma estruturada, classifica e define a exposição aos riscos identificados do projeto ou negócio. Cada nível descendente representa uma definição mais detalhada dos fatores de riscos para o projeto [Hillson 2002]. Assim, ela é uma estrutura hierárquica de fontes de riscos potenciais. Identificam-se como seus principais benefícios e uso a identificação dos riscos, avaliação dos riscos, comparação de alternativas, relato dos riscos e também obtenção de lições para projetos futuros através do uso da EAR como uma estrutura comum para projetos similares [Hillson et al. 2006]. Esta estrutura é semelhante à Estrutura Analítica do Projeto (EAP) [PMI 2004]. A Figura 1 apresenta um exemplo desta estrutura listando categorias e subcategorias nas quais os riscos podem surgir em um projeto típico.

19

Figura 1 – Exemplo de uma Estrutura Analítica de Riscos (EAR) [PMI 2004].

Existem diversas abordagens para a classificação em uma EAR dos riscos identificados.

Algumas

abordagens

propõem

um

conceito

genérico

de

categorização dos riscos de forma a empregá-los em projetos de qualquer área de negócio. Outras abordagens são orientadas à indústria oferecendo uma lista de categorias pré-definidas relacionadas ao negócio central para tipos específicos de projetos. Embora uma EAR genérica possa parecer útil, a estrutura geralmente não inclui o escopo completo dos possíveis riscos para cada projeto. Dessa forma, uma alternativa mais comum é produzir uma EAR específica relacionando uma dada indústria ou os tipos de projetos realizados por uma organização em particular.

20

2.4 O MODELO DE LEAVITT PARA OS RISCOS DE SOFTWARE

Na literatura são identificados alguns trabalhos sobre aplicações da teoria da organização nos estudos de desenvolvimento de software [Swanson e Beath 1990; Saarinen e Vepsalainen 1993; Nidumolu 1994]. Contudo, nenhum destes trabalhos examina em detalhes as fontes e formas de riscos de software, nem os conteúdos das intervenções sugeridas nas situações de desenvolvimento. O modelo de sistemas abertos de Leavitt de troca organizacional [Leavitt 1964] é bastante usado em classificação na literatura de gerenciamento. O uso deste modelo é motivado por várias razões, como, por exemplo: 1. Ter sido originalmente desenvolvido na teoria organizacional como uma tentativa de atingir uma síntese das principais dimensões e dinâmicas de mudança organizacional. Procurou-se a cobrir todas as principais escolas da teoria e simultaneamente eliminar as suas diferenças. 2. Ser suficientemente amplo, levando em conta os aspectos mais essenciais no desenvolvimento de software que estão no foco das abordagens de gestão de riscos de software. 3. Possuir virtudes de um bom modelo organizacional: é simples e razoavelmente bem definido para ser aplicado na classificação de fontes de riscos. 4. Poder ser estendido para acomodar novas dimensões, se surgir essa necessidade [Rockart e Scott 1984; Yetton et al 1994].

2.4.1. RISCOS DE SOFTWARE SEGUNDO LEAVITT

O modelo de Leavitt define a organização como um sistema complexo onde quatro variáveis interagem: tarefas, atores, tecnologia e estrutura. A visão de riscos de software a partir do modelo de Leavitt pode ter o seu surgimento a partir da interação entre essas variáveis que estão definidas a seguir. Tarefa - correspondem às atividades fim de uma organização ou às operações que levam à produção de bens e serviços. Leavitt usa o termo Tarefa para descrever a razão de viver da organização. No desenvolvimento de software 21

uma tarefa é normalmente definida através dos artefatos e funcionalidades do processo, ie. uma tarefa de desenvolvimento diz “O QUE” o software deve realizar e “COMO”. Várias tarefas relacionadas a funcionalidades que aumentam a exposição ao risco têm sido identificadas: tamanho da tarefa, complexidade, incerteza da tarefa, a estabilidade da tarefa, a ambiguidade e a existência da descrição da tarefa. Estrutura - Está ligada aos processos organizacionais, aos sistemas de comunicação organizacionais e ao fluxo dos processos de trabalho. Por Estrutura, Leavitt denota sistemas de comunicação e sistemas de fluxo de trabalho. Embora não torne explícito, Leavitt denota estrutura a dimensão padronizada, ie. valores e normas, e a dimensão comportamental, ie. padrões reais de comportamento conforme atores se comunicam, exercem autoridade ou trabalham. Ator - São todas as pessoas que estão envolvidas na realização das tarefas organizacionais. Atores representam indivíduos ou grupos de stakeholders que podem promover demandas ou se beneficiar do desenvolvimento do software. Atores incluem clientes, gerentes, mantenedores, desenvolvedores e usuários. Exemplos fatores de riscos de software relacionados a atores são: deficiências pessoais, falta de compromisso e conhecimento, diferenças entre stakeholders, expectativas erradas, crenças erradas, profissionais não éticos, troca de funcionários, políticas pessoais e oportunismo. Tecnologia - Está ligada ao conjunto de elementos capazes de resolver os problemas na organização de forma direta. Por exemplo, a técnicas de mensuração da produtividade, sistemas computacionais e computadores. Leavitt também chama a atenção que existem “algumas incertezas sobre a ligação entre estrutura e tecnologia”. De acordo com o conceito de “invenções para resolução de problemas” foi incluído métodos tecnológicos, ferramentas e infraestrutura para desenvolver e programar sistemas de software. Estas tecnologias podem criar riscos consideráveis especialmente se elas são não confiáveis, ineficientes, nãopadronizadas, incompatíveis ou têm limitações funcionais. O alinhamento estratégico entre Tecnologia da Informação e o negócio, pelo modelo de Leavitt, se dá por meio da definição das quatro variáveis, interagindo entre si. Por isso, para atingir-se o alinhamento, não bastaria a sua 22

definição, mas deve ser levado em consideração que elas são interdependentes, onde a modificação de itens em uma das variáveis poderia causar modificações em uma ou em todas as demais. O modelo de Leavitt é apresentado na Figura 2.

Figura 2 – Modelo de Leavitt e o desenvolvimento de software [Leavitt 1964].

Dessa forma, a conexão entre o modelo de Leavitt e o conceito de riscos de software pode ser definida da seguinte forma: uma mudança em qualquer componente do modelo de Leavitt nos processos de desenvolvimento de sistemas pode criar distúrbios que em condições extremas podem levar à falha do software.

2.5 RESUMO DO CAPÍTULO

Este capítulo teve a finalidade de apresentar os riscos na Engenharia de Software, além de delinear os conceitos de riscos, incerteza, fator de risco e oportunidade obtidos na literatura. Também, foram apresentados os principais métodos de identificação de riscos que podem ser utilizados na Gerência de Riscos incluindo EAR. Por fim, o modelo de Leavitt utilizado na organização da EAR proposta é apresentado junto à sua visão de riscos.

23

3

PROPOSTA DE ESTRUTURA ANALÍTICA DE RISCOS

De acordo com Webster e Watson, o objetivo básico do estudo da literatura é conseguir um resultado completo focado em conceitos [Webster e Watson 2002]. Assim, duas tarefas importantes são decidir como identificar a literatura relevante e como estruturar conceitualmente a análise [Weill e Olson 1989; Mathiassen et al. 2007]. Então, a análise deve resultar finalmente em uma síntese e avaliação fortes [Webster e Watson 2002]. Este capítulo discute a metodologia utilizada para conduzir a pesquisa e a Estrutura Analítica de Riscos proposta junto aos resultados alcançados. A Seção 3.1 apresenta a etapa inicial composta pelo mapeamento sistemático que foi conduzido na pesquisa. A Seção 3.2 apresenta a construção da EAR proposta. Por fim, a Seção 3.3 relata as avaliações realizadas na EAR proposta e as considerações.

3.1 MAPEAMENTO SISTEMÁTICO DA LITERATURA

O mapeamento sistemático, também conhecido como revisão de escopo, envolve uma pesquisa da literatura para determinar quais os tipos de estudo que direcionam a questão da revisão sistemática da literatura que têm sido realizados, onde eles foram publicados, em quais bancos de dados foram organizados, quais os tipos de saídas que eles foram avaliados e em quais populações [Roberts e Petticrew 2006]. Segundo Kitchenham e Charters, o mapeamento sistemático fornece uma visão geral da área de pesquisa para estabelecer se existem evidências da área sobre um tópico e fornece uma indicação da quantidade de evidências [Kitchenham e Charters 2007]. Os resultados do estudo de mapeamento podem identificar áreas adequadas à condução de Revisões Sistemáticas da Literatura e também áreas onde estudos primários são mais apropriados.

24

3.1.1. QUESTÃO DA PESQUISA

O problema central desta pesquisa pode ser definido pela seguinte pergunta: “como ajudar os gerentes de projetos a identificar os riscos que incidem em projetos de desenvolvimento distribuído de software e apresentálos de uma forma compreensível?” Baseado nesta ideia, este trabalho buscou identificar na literatura os trabalhos que definem ou tratam os fatores de riscos que surgem em ambientes DDS – Desenvolvimento Distribuído de Software. Assim, a pesquisa baseou-se na identificação dos fatores de riscos que pudesse ser extraídos a partir dos projetos de desenvolvimento distribuídos de software nos últimos 10 anos.

3.1.2. ESTRATÉGIA E PROCESSO DE BUSCA

A construção da string de busca utilizada na biblioteca digital selecionada Scopus [Scopus 2011] seguiu a estratégia definida por Kitchenham que identifica as principais palavras-chaves a partir das perguntas de pesquisa, e utiliza o conector OR para combinar sinônimos e termos alternativos de cada palavra-chave e o conector AND para combinar as palavras-chave [Kitchenham 2006]. O processo de extração foi realizado através de uma pesquisa por trabalhos relevantes na base Scopus. Como resultado da estratégia e restrições da ferramenta de busca Scopus, a string de busca apresentada na Figura 3 foi obtida.

Figura 3 – String utilizada na base Scopus.

A pesquisa foi limitada a publicações datadas a partir do ano 2001 ou posteriores, uma vez que este trabalho visa complementar os trabalhos existentes de identificação de riscos a exemplo da identificação de riscos baseado em taxonomia proposta pelo SEI (Software Engineering Institute) [Carr et al. 1993]. 25

Foram recuperados 390 estudos primários que, mais adiante, foram restritos aos trabalhos onde os fatores de riscos poderiam surgir dos seus resumos. Neste passo inicial, apenas título, palavras-chave e resumos foram levados em consideração. A área de pesquisa também se restringiu a trabalhos apenas da subárea computação. A Figura 4 apresenta o fluxo de trabalho (workflow) adotado na identificação dos trabalhos encontrados na literatura. Este fluxo foi modelado na ferramenta Bizagi disponível gratuitamente na internet [Bizagi 2011]. Abaixo, é descrito cada passo do fluxo de trabalho: 1. Pesquisar na web através da fonte listada – Este primeiro passo compreendeu aplicar a string de busca na base de dados escolhida. Neste trabalho, foi utilizada a base de dados Scopus devido a sua abrangência e coleta em bases como, por exemplo, IEEE Xplore [IEEE Xplore 2011], Biblioteca Digital da ACM [ACM 2011], SpringerLink [SpringerLink 2011] e JATIT [JATIT 2011]. 2. Salvar para fazer a triagem – Uma vez que os trabalhos estivessem acessíveis

através

do

portal

da

CAPES

(Coordenação

de

Aperfeiçoamento de Pessoal de Ensino Superior), estes arquivos eram salvos localmente em um disco rígido para a triagem subseqüente conforme os critérios adotados à aceitação ou recusa do trabalho. Caso algum trabalho não estivesse acessível pelo portal da CAPES, o trabalho era descartado. 3. Ler título e ler resumo – Uma vez que os trabalhos estavam salvos localmente, seu título e resumo eram lidos e conforme apresentassem fatores de riscos relevantes ao desenvolvimento de DDS, o trabalho estava elegível para uma leitura completa. Caso o trabalho não estivesse escrito em Português ou Inglês, o trabalho era descartado. 4. Ler texto completo – Uma vez filtrados pelos resumos e títulos, os trabalhos eram lidos completamente. Caso o título ou resumo não apresentasse uma abordagem explícita sobre fatores de riscos em DDS, o trabalho era descartado. 5. Classificar o estudo e extrair as informações sintetizando-as – Neste passo os trabalhos eram classificados de acordo com o modelo 26

de Leavitt e sintetizados de acordo com seus Fatores de Riscos abordados. A Seção 3.1.4 descreve os detalhes de como essa classificação foi realizada. 6. Gravar todas as informações em um template – Com a finalidade de organizar as informações extraídas, os Fatores de Riscos eram salvos e dispostos numa planilha eletrônica conforme exemplo na Tabela 3Tabela . 7. Contabilizar os estudos

relevantes – O

passo

final

deste

Mapeamento da Literatura foi contabilizar os estudos relevantes à criação da EAR.

Figura 4 – Procedimento de Seleção dos Trabalhos no Mapeamento Sistemático.

27

3.1.3. CRITÉRIOS DE INCLUSÃO E EXCLUSÃO E PROCEDIMENTOS DE SELEÇÃO

A inclusão de um trabalho no mapeamento sistemático se dá pela sua relevância em relação às questões investigadas [Trigueiro et al. 2011]. Neste trabalho, os critérios de inclusão adotados pelo estudo foram os seguintes: Critérios de Inclusão: (1) O trabalho está escrito em inglês ou português; (2) o trabalho apresenta fatores de riscos em projetos de desenvolvimento distribuído de software; (3) o trabalho deve estar disponível na internet; (4) o trabalho deve estar em formato eletrônico; e (5) o trabalho deve estar acessível através do portal da CAPES. Critérios de Exclusão: (1) O trabalho não pode ser uma apresentação de slides; (2) o trabalho não pode ser duplicado; (3) o trabalho não apresenta fatores de riscos relacionados à questão da pesquisa; e (4) o trabalho não esteja relacionado à Engenharia de Software.

3.1.4. PROCESSO DE EXTRAÇÃO DOS DADOS

É importante enfatizar que apenas trabalhos que estavam claramente fora do escopo foram excluídos nesta fase, mantendo todos os estudos primários em potencial para a análise posterior. O conjunto final de estudos primários somou 28 trabalhos dos quais apenas 23 apresentavam fatores de riscos relacionados à DDS. Este conjunto final está apresentado na Tabela 2Tabela . Tabela 2 – Estudos primários incluídos.

ID Título

Ano

Referência

Tipo do Trabalho Fonte

Software risks and 1 mitigation in global software development

2010

[Khan e Ghayyur 2010]

Artigo

A rule-based model for customized risk 2 identification in distributed software development projects

2010

[Lamersdorf et al. 2010]

Conference Paper

Journal of Theoretical and Applied Information Technology Proceedings - 5th International Conference on Global Software Engineering, ICGSE 2010

28

Knowledge transfer in IT offshore outsourcing 3 projects: An analysis of the current state and best practices

2010 [Betz et al. 2010]

A new perspective on 4 GDSD risk management; Agile risk management

2010

Conference Paper

Proceedings - 5th International Conference on Global Software Engineering, ICGSE 2010

[Mudumba e Lee Conference 2010] Paper

Proceedings - 5th International Conference on Global Software Engineering, ICGSE 2010

Limitations and measures in outsourcing projects to [Akhbar e Hassan Conference 5 2010 geographically distributed 2010] Paper offshore teams

Proceedings 2010 International Symposium on Information Technology - System Development and Application and Knowledge Society, ITSim'10

Project risk differences 6 between virtual and colocated teams Virtual software team project management A multi-criteria distribution model for 8 global software development projects Distributed software development projects: Work breakdown 9 approaches to overcome key coordination challenges 7

2010

[Reed e Knight 2010]

2010 [Casey 2010]

Artigo

Journal of Computer Information Systems

Artigo

Journal of the Brazilian Computer Society Journal of the Brazilian Computer Society

2010

[Lamersdorf e Münch 2010]

Artigo

2010

[Mohan e Fernandez 2010]

Conference Paper

Risk analysis of global 10 software development and proposed solutions

2010

[Yu L. e Mishra 2010]

Artigo

Risk identification and mitigation processes for 11 using scrum in global software development: A conceptual framework

2009

[Hossain et al. 2009]

Conference Paper

Proceedings - Asia-Pacific Software Engineering Conference, APSEC

[Wattanapokasin Conference 2009 e Rivepiboon Paper 2009]

2009 International Conference on Signal Processing Systems, ICSPS 2009

12

Cross-cultural risk assessment model

Risks and safeguards for the requirements 13 engineering process in global software development

2009

[Lopez et al. 2009]

An empirical approach for the assessment of [Avritzer e Lima 14 scheduling risk in a large 2009 2009] globally distributed industrial software project

29

ISEC'10 - Proceedings of the 2010 India Software Engineering Conference

Automatika

Conference Paper

Proceedings - 2009 4th IEEE International Conference on Global Software Engineering, ICGSE 2009

Conference Paper

Proceedings - 2009 4th IEEE International Conference on Global Software Engineering, ICGSE 2009

A coordination risk analysis method for multiConference 15 2009 [Bass et al. 2009] site projects: Experience Paper report

Proceedings - 2009 4th IEEE International Conference on Global Software Engineering, ICGSE 2009

A comparative study of important risk factors involved in offshore and 16 domestic outsourcing of software development projects: A two-panel Delphi study

2009

[Nakatsu e Iacovou 2009]

Artigo

A framework for supporting management 17 in distributed information systems development

2008

[Ralyté et al. 2008]

Conference Paper

Proceedings of the 2nd International Conference on Research Challenges in Information Science, RCIS 2008

Towards a multi-criteria development distribution 18 model: An analysis of existing task distribution approaches

2008 [Gruber 2008]

Conference Paper

Proceedings - 2008 3rd IEEE International Conference Global Software Engineering, ICGSE 2008

Project outcome predictions: Risk 19 barometer based on historical data

2007 [Smite 2007]

Conference Paper

Proceedings - International Conference on Global Software Engineering, ICGSE 2007

2007 [Sakthivel 2007]

Review

20

Managing risk in offshore systems development

Project management 21 within virtual software teams

2006

Making connections: An intercultural virtual team 22 project in professional communication

[Andrews e 2005 StarkeMeyerring 2005]

Trust in virtual teams: 23 Towards an integrative model of trust formation

2004

[Casey e Conference Richardson 2006] Paper

[Hung et al. 2004]

Information and Management

Communications of the ACM Proceedings - 2006 IEEE International Conference on Global Software Engineering, ICGSE 2006

Conference Paper

IEEE International Professional Communication Conference

Conference Paper

Proceedings of the Hawaii International Conference on System Sciences

O processo de extração dos fatores de riscos foi organizado através de uma planilha eletrônica que agrupou os 23 trabalhos em colunas e dispôs os fatores de riscos identificados em linhas conforme o exemplo da Tabela 3Tabela .

30

Tabela 3 – Parte da classificação utilizada.

[Nakatsu e CLASSIFICAÇÃO Iacovou 2009] Falta de especificação precisa e detalhada TAREFA (objetivos e artefatos)

[Ralyté. et al. [Bass et al. 2009] 2008]

FATOR DE RISCO RESULTANTE

Alocação da Funcionalidade não clara

Formalidade e transparência das tarefas

Funcionalidade entrelaçadas

Acoplamento das Tarefas Tratamentos dos requisitos não funcionais Dúvida nos requisitos funcionais Distância Temporal Diferenças nas Leis Distância Geográfica Divergências no processo de desenvolvimento Diferenças da língua

Requisitos não funcionais Incerteza sobre os requisitos funcionais

ESTRUTURA (organização do projeto e disposição institucional)

Diferença de Fuso-horário Diferenças de Leis

Barreiras da língua ATOR (usuários, gerentes e designers)

Diferenças culturais

Falta de tecnologias de segurança TECNOLOGIA (ferramentas de adequadas (e.g., desenvolvimento firewalls, criptografia, etc.) e plataforma técnica) Ferramentas de desenvolvimento incompatíveis

Fuso-horário

Distância temporal

Distância Distância geográfica geográfica Processos de desenvolvimento divergentes Habilidades linguísticas Diferenças na cultura nacional e coorporativa Experiência em projetos distribuídos

Diferenças Diferenças socioculturais socioculturais Experiência no domínio do projeto Distância do Distância do conhecimento conhecimento

Infraestrutura de TI/Telecom inadequadas Ambiente de Diferença de desenvolvimento plataformas divergentes de trabalho

Inadequação das tecnologias de segurança Incompatibilidade Tecnológica

A Tabela exemplifica o processo de organização utilizado para agrupar os fatores de risco através de 3 dos 23 trabalhos que foram triados para a identificação destes fatores. Por exemplo, o fator de risco Distância Temporal 31

resulta da identificação nos trabalhos de Nakatsu, Bass e Ralyté. Já o fator de risco Diferenças da Língua é identificado apenas em Nakatsu e Bass. Estes fatores de riscos elencados a partir dos 23 trabalhos identificados foram organizados conforme os elementos propostos no modelo de Leavitt. Os fatores de riscos relacionados à Tarefa foram agrupados com relação aos objetivos, artefatos e funcionalidades provenientes dos projetos de DDS. Na Tabela , tem-se Formalidade e Transparência das Tarefas e Dúvida nos Requisitos Funcionais como exemplos de fatores de riscos que influenciam neste tipo de projeto. Com a divisão e distribuição das tarefas em locais diferentes, dúvidas nos requisitos funcionais podem surgir por falta de formalidade e transparência gerando estes fatores de riscos. Os fatores de riscos relacionados à Estrutura foram agrupados com relação aos processos organizacionais, disposição da instituição e organização do projeto. Na Tabela Tabela , Distância Temporal e Distância Geográfica são fatores de riscos que se aplicam a esta definição, pois podem gerar esperar improdutivas ou aumentar os custos com viagens. Os fatores de riscos relacionados a Ator foram agrupados com relação a todas as pessoas que estão envolvidas na realização das tarefas organizacionais (stakeholders), eg. usuários, gerentes e designers. Na Tabela Tabela , Diferenças da Língua e Diferenças Socioculturais são fatores de riscos que se adéquam a esta classificação, pois estão relacionados às características de grupos específicos dos stakeholders. Os fatores de riscos relacionados à Tecnologia foram agrupados com relação ao conjunto de elementos tecnológicos capazes de resolver os problemas na organização, eg. computadores e meio de comunicação. Na Tabela Tabela , Inadequação das Tecnologias de Segurança e Incompatibilidade Tecnológica são fatores de riscos adequados a esta classificação, pois tratam de quais ferramentas são utilizadas na organização e como as tecnologias relacionadas à segurança podem impactar negativamente o projeto que estão sendo utilizadas. Com relação à quantidade de fatores de riscos identificados no trabalho, podemos ressaltar os seguintes fatores como mais comuns: Distância Temporal 32

teve identificação em 14 trabalhos, Distância Cultural em 13 trabalhos, Distância Linguística 11 trabalhos, Distância do Conhecimento em 8 trabalhos, Dúvida nos Requisitos Funcionais e Distância Geográfica em 7 trabalhos. Os demais fatores de riscos estavam presentes em trabalhos cuja quantidade não passavam de 5 trabalhos simultâneos.

3.2 ESTRUTURA ANALÍTICA DE RISCOS PROPOSTA

Esta seção apresenta a Estrutura Analítica de Riscos resultante do mapeamento sistemático realizado neste trabalho.

3.2.1. FATORES DE RISCOS IDENTIFICADOS

Através do processo de extração apresentado na Seção 3.1.4, foi criada a Tabela Tabela 4 que apresenta os fatores de riscos que foram identificados juntamente com as indicações de cada nível de riscos (baixo, médio e alto) que também ajudam na análise futura dos riscos proposta no PMBOK [PMI 2004]. Tabela 4 – Fatores de Riscos Identificados no Mapeamento Sistemático da Literatura.

Tarefa Indicação de Risco Baixo

Indicação de Risco Médio Indicação de Risco Alto

1

Formalidade e Transparência das tarefas

As atividades de cada local estão bem definidas

Alguns locais necessitam ter suas atividades explicitamente alocadas

2

Tratamento dos Requisitos NãoFuncionais

A maioria das restrições são conhecidas, porém algumas precisam de uma maior atenção.

3

Dúvida nos requisitos funcionais

As restrições de segurança, desempenho e disponibilidade são conhecidas e capturadas de forma efetiva A equipe entende a funcionalidade e não tem dúvidas na tarefa a ser executada

ID do Fator

Fatores de Riscos

33

A equipe possui dúvidas isoladas na tarefa a ser executada

As atividades dos locais estão sobrepostas com quase nenhuma organização modularizada. Existem restrições de segurança, desempenho e disponibilidade que impactam diretamente o projeto desenvolvido

A equipe não consegue compreender bem a tarefa a ser executada

4

Acoplamento das Quase não existe tarefas necessidade de coordenação entre os locais de desenvolvimento

Existe uma certa necessidade de coordenação entre os locais de desenvolvimento

Existe uma necessidade significativa para coordenar os locais de desenvolvimento

5

Criticidade da tarefa

Algumas falhas podem impactar momentaneamente o projeto, mas não encerram o projeto

As falhas encontradas ameaçam o sucesso do projeto

6

Complexidade da Não há grande tarefa necessidade de documentação da tarefa por ser de fácil compreensão

É recomendado documentar a funcionalidade para parte do seu desenvolvimento

7

Estabilidade dos requisitos

A tarefa em si possui um nível de detalhamento que precisa ser documentado para que se possa entender seus relacionamentos. Os requisitos mudam freqüentemente

Falhas na tarefa são bem toleradas, permitindo o seu conserto.

Os requisitos raramente Os requisitos mudam eventualmente mudam

Estrutura 8

Distancia temporal

Os fusos horários não causam nenhum problema de coordenação

9

Diferença nas leis

As leis são similares

10 Distância geográfica

Os fusos horários requerem Existem muitos fusosum tratamento restrito para horários que impactam algumas localidades negativamente o desenvolvimento do projeto As leis diferem um pouco, As leis possuem mas o projeto pode ser diferenças que podem desenvolvido sem causar a finalização do problemas projeto

Distância entre os locais Distância entre os locais é não é significativa para grande, porém os impactos causar problemas se restringem a casos pequenos e isolados

Distância significativa entre os locais causando diversos problemas, eg. Problemas de comunicação e custos de locomoção Os processos são diferentes em todas as localidades envolvidas

11 Divergências no Os processos nas processo de diferentes localidades desenvolvimento não variam, uma vez que todos utilizam o mesmo padrão

Os processos variam, mas possuem um padrão parcialmente comum

12 Maturidade do processo

O nível de maturidade do processo entre os locais são iguais com os trabalhos alinhados aos objetivos de negócio da empresa

O nível de maturidade dos processos nos locais distribuídos é semelhante com pouca variação

Existem diferentes maturidades do processo e inconsistências no trabalho realizado considerando os diversos locais distribuídos

13 Quantidade de locais de distribuição

O projeto está distribuído em poucos locais

O projeto está distribuído em alguns locais

O projeto está distribuído em vários locais

Ética e normas são similares nos locais de desenvolvimento

Ética e normas possuem algumas variações nos locais de desenvolvimento

Ética e normas são divergentes nos locais de desenvolvimento

Ator 14 Diferenças socioculturais

34

15 Diferenças culturais de trabalho

As pessoas compartilham e entendem as informações nos locais distribuídos

As pessoas conhecem as diferenças culturais entre os locais distribuídos e se comunicam sem problemas significantes

As pessoas não conhecem as diferenças culturais e possuem diferente entendimento de conceitos

16 Diferenças da língua

As pessoas falam a mesma língua e possuem regras de comunicação iguais

As pessoas utilizam um língua comum e possuem regras de comunicação similares

17 Distância do conhecimento

Não existem lacunas de Algumas especificações conhecimento entre os são criadas com erros locais distribuídos devido a falta de conhecimento específico

As pessoas se comunicam em línguas diferentes entre si com regras de comunicação distintas Existem grandes problemas relacionados às habilidades necessárias ao desenvolvimento do projeto nos locais distribuídos Os conhecimentos ficam isolados em cada local distribuído

18 Transferência do Os conhecimentos conhecimento gerados são compartilhados e integrados nos locais distribuídos

Existem conhecimentos pontuais que não são compartilhados e integrados

19 Relacionamento pessoal

As pessoas se relacionam pessoalmente A equipe está motivada para trabalhar de forma distribuída

As pessoas as vezes se relacionam pessoalmente

As pessoas não se relacionam pessoalmente

Parte da equipe está motivada a trabalhar num ambiente distribuído

A equipe não está motivada a interagir neste tipo de ambiente

21 Experiência no domínio do projeto

A equipe tem experiência anterior no domínio do projeto

A equipe possui parte do conhecimento necessário ao desenvolvimento das funcionalidades

O domínio do projeto é totalmente novo para os participantes envolvidos

22 Falta de confiança

Existe sinergia e relacionamento físico entre as equipes

Existe um certo relacionamento físico entre as equipes distribuídas

Existem rivalidades entre as equipes distribuídas e receio de contatos

20 Motivação da equipe

Tecnologia 23 Inadequação das Os dados do projeto são tecnologias de inteligíveis apenas para segurança os membros envolvidos no projeto protegidos por restrições de acesso

24 Incompatibilidade Todas as localidades tecnológica utilizam os mesmos hardware e software no desenvolvimento do projeto 25 Adequação das ferramentas de apoio

35

As ferramentas de apoio utilizadas no desenvolvimento correspondem às expectativas de utilização em projetos distribuídos

Existem algumas restrições de acesso às informações para os participantes do projeto

Os dados dos projetos podem ser compreendidos por qualquer pessoa interessada havendo falta de padrão nas restrições de acesso Existem algumas Cada localidade usa a divergências entre as ferramenta de sua ferramentas de escolha no desenvolvimento do projeto desenvolvimento do projeto Algumas exceções não correspondem às expectativas de utilização em projetos distribuídos

Ferramentas chaves para apoio no desenvolvimento do projeto são aquém do desempenho esperado

26 Canal de comunicação

A rede é confiável e possui uma capacidade adequada para comunicação entre as equipes

A rede geralmente está disponível com uma capacidade de comunicação disponível adequada

A rede é instável com restrições na capacidade de comunicação entre as equipes distribuídas

Como no desenvolvimento de software tradicional, a Tarefa possui fatores de risco em projetos de DSD, porém com razões ligeiramente diferentes. Quando o projeto é dividido e distribuídos em distintos locais dúvidas nos requisitos funcionais podem surgir devido a falta de formalidade e transparência ou seu propósito [Smite 2007; Nakatsu e Iacovou 2009; Bass et al. 2009; Lamersdorf et al. 2010; Mudumba e Lee 2010; Betz et al. 2010; Akhbar e Hassan 2010; Khan e Ghayyur 2010]. Com a distribuição das tarefas, também pode ocorrer o aumento de comunicação e integração entre os locais de distribuição devido ao acoplamento das tarefas [Lamersdorf e Münch 2010; Lamersdorf et al. 2010]. Fatores de riscos também são relacionados à Estrutura que agrupa dimensões temporais, geográficas e colaborativas em ambientes de DDS. A distância geográfica complica o monitoramento do progresso das equipes, enfraquece relações sociais, além de aumentar os custos com viagens e restringir contatos face a face [Smite 2007; Ralyté et al. 2008; Nakatsu e Iacovou 2009; Bass et al. 2009; Betz et al. 2010; Lopez et al. 2009; Khan e Ghayyur 2010]. A distância temporal aumenta a complexidade de planejamento e causando esperas improdutivas e atrasos em respostas, além de complicar configurações de horas [Sakthivel 2007; Ralyté et al. 2008; Nakatsu e Iacovou 2009; Bass et al. 2009; Lamersdorf e Münch 2010; Mudumba e Lee 2010; Hossain et al. 2009; Casey 2010]. Na distribuição geográfica, diversos problemas considerando os Atores podem surgir uma vez que os stakeholders não necessariamente utilizam a mesma língua e cultura organizacionais [Ralyté et al. 2008; Nakatsu e Iacovou 2009; Bass et al. 2009; Wattanapokasin e Rivepiboon 2009; Mudumba e Lee 2010; Lamersdorf et al. 2010; Betz et al. 2010; Akhbar e Hassan 2010; Reed e Knight 2010]. A falta de interação entre os participantes face a face, também podem gerar problemas na transferência do conhecimento adquirido, experiência no domínio do projeto, além

36

da falta de confiança [Hung et al. 2004; Ralyté et al. 2008; Lopez et al. 2009; Mohan e Fernandez 2010; Lamersdorf e Münch 2010; Khan e Ghayyur 2010]. Diversos problemas em projetos de DDS surgem a partir da Tecnologia. Problemas de segurança podem surgir causando a falha do projeto como, por exemplo, falta de criptografia e padrão de acesso às informações nas diversas localidades [Nakatsu e Iacovou 2009, Bass et al. 2009, Lamersdorf e Münch 2010]. A capacidade e confiabilidade do canal de comunicação também assumem um papel importante uma vez que este fator pode gerar uma baixa eficiência além de ser critico para o sucesso deste tipo de projeto [Hossain et al. 2009; Lamersdorf et al. 2010; Akhbar e Hassan 2010]. Na colaboração entre estes locais, a incompatibilidade de tecnologias utilizada no desenvolvimento é provadamente um fator crucial para o sucesso do projeto [Hossain et al. 2009; Nakatsu e Iacovou 2009; Bass et al. 2009; Mudumba e Lee 2010; Khan e Ghayyur 2010].

3.2.2. DISPOSIÇÃO CONFORME MODELO DE RISCOS DE SOFTWARE DE LEAVITT

A Estrutura Analítica de Riscos (EAR) foi criada para auxiliar os gerentes de projetos na identificação mais cedo dos riscos imediatos. Sua estruturação segue a ideia de uma Estrutura Analítica de Projetos (EAP), contudo a EAR é orientada às fontes de riscos ao contrário da orientação da EAP que é orientada a artefatos. No trabalho desenvolvido, criamos uma EAR dos fatores de riscos para projetos de desenvolvimento distribuído de software utilizando a visão de riscos de software de Leavitt o qual define os riscos que podem surgir da interação entre Ator, Tarefa, Estrutura e Tecnologia, conforme Seção 2.5.1. A estrutura da Figura 5 organiza os 26 fatores de riscos em níveis descendentes conforme o foco definido no modelo de Leavitt. É importante destacar que os fatores dispostos nesta EAR têm o objetivo de ajudar os gerentes na identificação dos fatores de riscos provenientes de ambientes de DDS. Dessa forma, outros fatores comuns a ambientes co-localizados não foram foco deste

37

trabalho, embora alguns dos fatores de riscos identificados, como os de Tarefa, por exemplo, sejam comuns a ambos ambientes. O ponto mais importante desta EAR na Figura 5 é apresentar os 26 fatores de riscos agrupados na Tabela 4Tabela de uma forma concisa e simples. Isto facilita a consulta dos Fatores de Riscos e possibilita uma visão geral de quais fatores incidem no projeto de DDS gerenciado na organização.

Figura 5 – Estrutura Analítica de Riscos Proposta.

3.3 AVALIAÇÃO DA EAR

Os grupos para avaliação visam a uma discussão informal e de tamanho reduzido, com o propósito de obter informações de caráter qualitativo. Apesar da importância destes grupos salienta-se que os mesmos não são úteis para 38

inferências precisas a respeito de toda a população. Contudo, de acordo com sociólogo Theodore Mills, entende-se que os pequenos grupos não são microssistemas isolados do sistema social, mas são microcosmos das sociedades maiores com as mesmas características societárias, o que, em essência, possibilita tirar conclusões mais abrangentes [Mills 1968]. Assim, tratar de questões por meio de pequenos grupos é usar o pequeno universo como referência para se pensar as grandes questões. A coleta de dados através da metodologia qualitativa tem como diretriz basear-se na tendência de formar opiniões com a intenção de colher dados a partir da leitura focada em um trabalho específico. Com a realização sistemática dos grupos de avaliação, emerge a possibilidade de identificar tendências e padrões na percepção daquilo que temos como nosso objetivo principal. A ideia inicial para a avaliação deste trabalho era realizar uma avaliação da EAR e sua adequação, juntamente com profissionais especialistas da área de gerenciamento de projetos, utilizando uma adaptação da formação Grupo Focal. Esta avaliação seria dividida em duas fases: uma virtual e outra presencial. Contudo, o resultado virtual foi muito homogêneo o que resultaria numa avaliação presencial semelhante. Dado que reunir todos esses profissionais também se mostrou uma tarefa difícil, optou-se por fazer outra avaliação virtual de acordo com os critérios de qualidade propostos pelo CASP (Critical Appraisal Skills Programme) [CASP 2011]. Dessa forma, a avaliação da EAR proposta neste trabalho foi conduzida em dois momentos distintos: i) um virtual com profissionais especialistas da área de Gerência de Projetos e ii) outro virtual com especialistas na área de Gerenciamento de Riscos dentro da academia. A seguir, cada um desses momentos é descrito detalhadamente.

3.3.1. PRIMEIRO MOMENTO

O

objetivo

desta

etapa

foi

permitir

aos

participantes

avaliarem

individualmente a EAR por meio de critérios pré-definidos em questionário

39

disponível através da internet. O questionário utilizado nesta etapa encontra-se no Apêndice B deste trabalho. A equipe de especialistas escolhida para esta etapa da avaliação foi composta por três (3) profissionais certificados PMP (Project Management Professional) junto a três (3) outros que não eram certificados. Os profissionais certificados eram todos mestres. Já o grupo dos profissionais não certificados possuía dois (2) com o título de mestre em Ciências da Computação e um (1) é mestrando em Engenharia da Computação. Com a primeira etapa da avaliação foi possível verificar que a estrutura é clara e ajuda na identificação dos riscos em ambientes DDS. Contudo, foi questionada a abrangência da EAR. Neste sentido, o trabalho continua adequado, pois a EAR proposta visa focar o desenvolvimento distribuído de software e não todas as formas de gestão de negócio que se necessitam neste tipo de ambiente. Os principais pontos positivos destacados nesta avaliação foram que o modelo proposto está claro, conciso e autoexplicativo, além de abranger diversos fatores inerentes ao Desenvolvimento Distribuído de Software. Os principais pontos de melhoria destacados nesta avaliação foram: 

“Outras dimensões deveriam ser consideradas” – De certo modo sim. Porém este trabalho visa complementar estruturas existentes, como a identificação de riscos baseado em taxonomia proposta pelo SEI [Carr et al. 1993], baseando-se no mapeamento sistemático da literatura. Assim, com o escopo bem definido, espera-se que o trabalho tenha atingido seu propósito com sucesso.



“Alguns dos seus fatores são aplicáveis não apenas a DDS, mas também em outros tipos de projetos” – Este trabalho teve foco em DDS, porém alguns estudos presentes na literatura apresentaram fatores de riscos que assumiam papel importante mesmo não sendo exclusivos aos ambientes de Desenvolvimento Distribuído de Software. O resultado desta etapa foi importante, pois não gerou modificações de

impacto na EAR que continuou a mesma apresentada na Figura 5.

40

3.3.2. SEGUNDO MOMENTO

Para avaliar especificamente a qualidade da EAR proposta, seis (6) especialistas na área de Gerenciamento de Riscos dentro da academia fizeram uma análise de forma independente, de acordo com nove (9) critérios definidos no formulário de avaliação da qualidade anexo no Apêndice C. Estes critérios foram propostos pelo Critical Appraisal Skills Programme (CASP) [CASP 2011] como forma de avaliar a qualidade das pesquisas qualitativas, seguindo a orientação dos princípios de boas práticas na condução de pesquisa empírica em engenharia de software. O grupo de especialistas foi composto de três (3) mestres e três (3) mestrandos. Três grandes questões relacionadas a rigor, credibilidade e relevância foram levadas em consideração quando foi realizada esta avaliação: 

Rigor: Uma abordagem completa e apropriada tem sido aplicada nos métodos de pesquisa principais no estudo?



Credibilidade: as conclusões são bem apresentadas e significativas?



Relevância: o quão úteis são as descobertas para o pesquisador e sua pesquisa?

O questionário subdivide-se em duas partes: a primeira sendo sobre Questões de Rastreamento onde são relacionados à qualidade do trabalho, objetivos e contexto. Já a segunda, nomeada como Detalhamento, está relacionada às três questões descritas anteriormente (rigor, credibilidade e relevância). O formulário de avaliação de qualidade está disponível no Apêndice C deste trabalho. Com relação às Questões de Rastreamento, todos os 6 especialistas concordam com a estrutura criada e adequação da metodologia adotada em sua criação. Os participantes concordaram com a relevância, importância e objetivo da EAR. Com relação ao Detalhamento, abaixo é mostrado as conclusões a partir de cada questão:

41

Relevância da EAR e suas justificativas (A EAR está adequada para resolver os motivos do seu desenvolvimento?) - obteve 100% de concordância por parte dos 6 especialistas e nenhum comentário adicional foi fornecido. Amostragem junto à definição dos Fatores de Risco (A estratégia de recrutamento foi adequada aos objetivos da EAR?) – obteve 100% de concordância por parte dos 6 especialistas e um especialista apenas comentou que requisitos não-funcionais poderiam ser considerados mais abrangentes que apenas segurança, desempenho e disponibilidade. Coleta dos Dados (Os dados foram colhidos de forma a proporcionar a construção da EAR?) – Apenas 1 especialista discordou comentando que o documento não justificava o método de coleta que foi escolhido. Reflexividade (A relação entre o pesquisador e a EAR foi considerada de forma adequada?) – 3 especialistas discordaram comentando que o documento não apresentava claramente uma análise crítica do seu próprio papel, o viés potencial e a influência durante a formulação das questões de pesquisa. Resultados (Há uma declaração clara dos resultados?) – 4 especialistas discordaram comentando que o documento não apresentava conclusões explícitas nem discussão das limitações. Valor da EAR (A EAR tem valor para pesquisa ou prática?) – obteve 100% de concordância por parte dos 6 especialistas. Conforme descrito, todas as discordâncias que ocorreram nesta etapa da avaliação restringiram-se a problemas relacionados à documentação resumida. O documento foi criado de forma sucinta a partir desta dissertação onde não incluía os principais pontos discordados como analise de viés e resultados explicitamente. Este documento foi resumido com o intuito de obter uma adesão completa dos avaliadores com relação aos pontos principais da análise da EAR como, por exemplo, Relevância e Amostragem. Contudo, os pontos discordados estão presentes na dissertação permitindo que a EAR possa ser avaliada com sucesso de acordo com os critérios definidos pelo CASP com relação à Relevância, Rigor e Credibilidade. 42

3.4 RESUMO DO CAPÍTULO

O principal objetivo deste capítulo foi discutir a metodologia de Mapeamento Sistemático utilizado na condução da pesquisa, além de apresentar a construção da EAR proposta junto a seu resultado. Por fim, foram relatadas as avaliações realizadas na EAR proposta junto às suas considerações.

43

4

CONTRIBUIÇÕES E TRABALHOS FUTUROS

Este capítulo apresenta as principais contribuições identificadas a partir do trabalho desenvolvido na Seção 4.1. A Seção 4.2. descreve as limitações encontradas. Por fim, a Seção 4.3 discute alguns trabalhos futuros que podem ser desenvolvidos a partir desta dissertação.

4.1 PRINCIPAIS CONTRIBUIÇÕES

Este trabalho mapeou os trabalhos recentes que identificam fatores de riscos na área de desenvolvimento distribuído de software. Como resultado, foi obtido uma EAR que tenta ajudar os gerentes de projetos e stakeholders na identificação dos riscos neste tipo de ambiente. Para a organização da EAR proposta, era necessário um modelo organizacional de desenvolvimento e riscos de software que fosse simples, porém suficientemente rico. Dessa forma, o modelo de Leavitt foi utilizado se adaptando perfeitamente aos conceitos utilizados neste trabalho. O mapeamento da literatura foi relatado o que torna mais fácil para outros pesquisadores avaliar o trabalho realizado além de facilitar a sua evolução. Considerando-se os 23 trabalhos encontrados na literatura, os demais trabalhos acadêmicos e as buscas manuais, não foi identificado nenhum trabalho que apresentasse uma EAR específica a ambientes de DDS. Estes trabalhos apenas abordam fatores de riscos isoladamente ou, no máximo, inter-relacionaram alguns. Neste sentido, este trabalho possui uma característica de apoio relevante a projetos neste tipo específico de ambiente. O trabalho foi avaliado qualitativamente através da ferramenta de análise crítica para pesquisa qualitativa do CASP [CASP 2011] visando ajudar a tornar conhecimento obtido em prática. Além disso, o trabalho também foi avaliado por profissionais de empresas que lidam diariamente com o gerenciamento de projetos.

44

Essa etapa de avaliação foi importante, pois demonstra que o objetivo de ajudar os gerentes de projetos a identificar os riscos que incidem em projetos de desenvolvimento distribuído de software e apresentá-los

de uma forma

compreensível, proposto inicialmente neste trabalho, foi atingido. Embora alguns pontos de melhorias tenham sido alertados durante a primeira avaliação, esta etapa foi importante, pois não gerou modificações na EAR que continuou a mesma. Já na segunda avaliação, verifica-se que todos os pontos de melhoria levantados foram devido ao fornecimento da documentação resumida. Contudo, as considerações realizadas nesta etapa foram todas consideradas ao longo da escrita desta dissertação.

4.2 LIMITAÇÕES ENCONTRADAS

Com relação ao mapeamento sistemático da literatura, uma limitação foi a estratégia de pesquisa adotada. Os dados foram extraídos por apenas um pesquisador, que configura uma ameaça [Kitchenham e Charters 2007]. Contudo, esta fase foi supervisionada pela co-orientadora do pesquisador para reduzir os viés e as ameaças. A realização do processo de busca apenas na base Scopus também representa uma limitação na aplicação da metodologia, porém a capacidade de busca cruzada em várias bases de dados a partir desta ferramenta respalda sua relevância e escolha de utilização neste trabalho. Embora tenha sido dedicado certo tempo para identificar as palavraschaves relevantes à pesquisa, estudos relevantes que usem termos diferentes podem ter sido omitidos. Alguns estudos recentes podem ter sido omitidos também devido à falta de catalogação destes. Já a EAR proposta poderia ter sido avaliada de uma forma mais controlada. Mais participantes poderiam ter avaliado, contudo por restrições de tempo, esta atividade pode ser realizada futuramente.

45

Outra limitação com relação aos participantes das análises foi que apenas alguns deles trabalharam efetivamente com projetos distribuídos na prática. Isso representa uma limitação importante que deve ser destacada.

4.3 TRABALHOS FUTUROS

Os resultados alcançados neste trabalho permitirão outros pesquisadores evoluir ou até mesmo refinar a EAR proposta e facilitar a aplicação da disciplina de Gerência de Riscos em ambientes de desenvolvimento distribuído de software. É importante ampliar o Mapeamento Sistemático para outras bases com a finalidade de contribuir com a EAR apresentada confirmando suas conclusões e resultados. Um trabalho que está sendo definido é a criação de um protocolo único de pesquisa dentro do grupo PROMISE (Process Management and Improvements in Software Engineering) [PROMISE 2011] no Centro de Informática da UFPE (Universidade Federal de Pernambuco). Este protocolo de pesquisa será adotado como metodologia específica para a construção de árvores de fatores de riscos dentro do grupo de pesquisa PROMISE. Outro trabalho futuro é que a estrutura proposta nesta dissertação pode ser utilizada junto a outros trabalhos complementando outras estruturas de identificação de riscos que não possui foco em projetos de DDS, como por exemplo, o questionário baseado em taxonomia proposta pelo SEI [Carr et al. 1993]. Aplicar a EAR em um ambiente real para avaliar a sua eficácia neste ambiente mostrando sua relevância na prática também pode ser definido como um trabalho importante a ser desenvolvido.

46

REFERÊNCIAS BIBLIOGRÁFICAS [ACM 2011] Biblioteca Digital ACM. Disponível na URL: http://portal.acm.org/ Acesso em: 02/04/2011 [Andrews e Starke-Meyerring 2005] Andrews, D., e Starke-Meyerring, D., (2005). Making connections: an intercultural virtual team project in professional communication.

IPCC

2005

Proceedings

International

Professional

Communication Conference 2005, 26-31. Ieee. [Akhbar e Hassan 2010] Akhbar, R. and Hassan, M. (2010) Limitations and Measures in Outsourcing Projects to Geographically Distributed Offshore Teams. In: International Symposium on Information Technology 2010, ITSim, June 2010, Kuala Lumpur. [Avritzer e Lima 2009] Avritzer, A. and Lima, A. (2009) An Empirical Approach for the Assessment of Scheduling Risk in a Large Globally Distributed Industrial Software Project. In Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE '09). IEEE Computer Society, Washington, DC, USA, 341-346. [Bass et al. 2009] Bass, M., Herbsleb, J., and Lescher, C. (2009) A Coordination Risk Analysis Method for Multi-site Projects: Experience Report. In Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE '09). IEEE Computer Society, Washington, DC, USA, 31-40 [Betz et al. 2010] Betz S., Oberweis A., and Stephan R. 2010. Knowledge Transfer in IT Offshore Outsourcing Projects: An Analysis of the Current State and Best Practices. In Proceedings of the 2010 5th IEEE International Conference on Global Software Engineering (ICGSE '10). IEEE Computer Society, Washington, DC, USA, 330-335. [Bizagi 2011] BizAgi – Ferramenta de gerenciamento de processos de negócio. Disponível na URL: http://www.bizagi.com/ Acesso em: 10/01/2011. [Boehm 1989] Boehm, B. W. (1989) Tutorial: Software Risk Management. IEEE Computer Society Press. 47

[Boehm 1991] Boehm, B. W. (1991) Software Risk Management: Principles and Practices, IEEE Software, Volume 8. No1. pp 32-40. [Boehm et al 2004] Boehm, B. W.; Brown, A. W; Basili, V; Turner, R. (2004) Spiral Acquisition of Software-Intensive Systems of Systems, Cross talh – The Journal of Defense Software Engineering, DoD – Department of Defense. pp 4-9. [Bleecker 1994] Bleecker, S.E. "The virtual organization," Futurist (28:2), Mar-Apr 1994, pp 9-14. [Brasiliano 2009] BRASILIANO, C. Antonio. (2009) Método Brasiliano Avançado – Gestão e Análise de Risco Corporativo. Sicurezza. [Brooks 1987] Brooks, F. P. (1987) No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer. Vol. 20, 4. [Cairncross 1997] Cairncross, F. The Death of Distance: How the Communications Revolution Will Change Our Lives. Boston, MA: Harvard Business School Press, 1997 [Carmel e Agarwal 2002] Carmel, E. and R. Agarwal, “The maturation of offshore sourcing of information technology work,” MIS Quarterly Executive, vol. 1, pp. 65-76, 2002 [Carmel 1999] Carmel, E. Global software teams: Collaborating across borders and time zones. Upper Saddle River, NJ: Prentice Hall, 1999 [Carr et al. 1993] Carr, M. J., Konda, S.L., Monarch, I., Ulrich, F. C., Walker, C. F. (1993) Taxonomy Based Risk Identification. Tecnical Report CMU/SEI-93TR-6. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. USA. [Casey 2010] Casey, V. (2010). Virtual software team project management. Journal of the Brazilian Computer Society, 16(2), 1-14. Springer. [Casey e Richardson 2006] Casey, V., e Richardson, I. (2006). Project Management Within Virtual Software Teams. 2006 IEEE International Conference on Global Software Engineering ICGSE06, 16(2), 33-42. Ieee. 48

[CASP 2011] Critical Appraisal Skills Programme Tools. Disponível na URL: http://www.sph.nhs.uk/ Acesso em: 01/05/2011. [Charrete 2001] Charette, R. (2001) Implementing Risk Management Best Practices. [Cervo 2002] CERVO, Amado Luiz; BERVIAN, Pedro Alcino. Metodologia científica. 5ª ed. São Paulo: Pearson Prentice Hall, 2002. [Costa et al 2005] Costa, H. R.; Barros, M. O.; Travassos, G.H. (2005) Uma Abordagem Econômica baseada em Riscos para Avaliação de uma Carteira de Projetos de Software. In 19º Simpósio Brasileiro de Engenharia de Software. Uberlândia – MG – Brazil. [Curseu 2008] Curseu, P.L., Schalk, R., and Wessel, I. "How do virtual teams process information? A literature review and implications for management," Journal of Managerial Psychology (23:6), 2008, pp 628-652. [Damian e Moitra 2006] Damian, D., and Moitra, D. "Global software development: How far have we come," IEEE Software (23:5), 2006, pp 17–19. [De Marco 1997] De Marco, (1997) T. The Deadline: A Novel About Project Management. Nova Iorque. Dorset House Publishing. [Dibbern et al. 2004] Dibbern, J., Goles, T., Hirschheim, R., and Jayatilaka, B. "Information systems outsourcing: a survey and analysis of the literature," The DATA BASE for Advances in Information Systems (35:4), 2004, pp 6102. [Ebert et al. 2008] Ebert, C., Murthy, B.K., and Jha, N.N. "Managing risks in global software engineering: principles and practices," 3rd IEEE International Conference on Global Software Engineering, IEEE Computer Soc, Bangalore, INDIA, 2008, pp. 131-140. [Erickson e Evaristo 2006] Erickson, J.M., e Evaristo, R. "Risk factors in distributed projects," Proceedings of the 39th Annual Hawaii International Conference on System Sciences, 2006.

49

[Gibson e Gibbs 2006] Gibson, C. B., J. L. Gibbs. 2006. Unpacking the concept of virtuality: The effects of geographic dispersion, electronic dependence, dynamic structure, and national diversity on team innovation. Administrative Science Quarterly 51(3) 451–495. [Gillam e Oppenheim 2006] Gillam, C., and Oppenheim, C. "Review article: reviewing the impact of virtual teams in the information age," Journal of Information Science (32:2), 2006, pp 160-175. [Gruber 2008] Gruber, T. (2008) Towards a Multi-criteria Development Distribution Model: An Analysis of Existing Task Distribution Approaches. Global Software Engineering 2008 ICGSE 2008 IEEE International Conference on (pp. 109-118). [Gusmão 2007] Gusmão, C (2007) Um Modelo de Processo de Gestão de Riscos para Ambientes de Múltiplos Projetos de Desenvolvimento de Software. Tese de Doutorado. Universidade Federal de Pernambuco. Recife – PE, Brasil. [Gusmão et al 2005] Gusmão, C.M.G. et al. (2005) “Ontologia de Domínio de Riscos”, In Suppera Solutions Relatório Técnico, Centro de Informática, Universidade Federal de Pernambuco, Recife, Brasil. [Hall 1998] Hall, E. M. (1998) Managing Risk – Methods for Software Systems Development. Addison-Wesley. pp 88-103. [Herbsleb e Moitra 2001] Herbsleb, J.D., and Moitra, D. "Global software development," IEEE Software (18:2), Mar- Apr 2001, pp 16-20. [Hertel et al. 2005] Hertel, G., Geister, S., and Konradt, U. "Managing Virtual teams: a review of current empirical research," Human Resource Management Review (15:1), 2005, pp 69-95. [Higuera 1994] Higuera, P.R. (1994) An Introduction to Team Risk Management, Technical Report. Software Engineering Institute, Carnegie Mellon University. USA.

50

[Hillson 2002] Hillson D. A. (2002) “The Risk Breakdown Structure (RBS) as an aid to effective risk management”, Proceedings of the 5th European Project Management Conference (PMI Europe 2002), presented in Cannes France, 19-20 June 2002. [Hillson et al. 2006] D. Hillson, S. Grimaldi, and C. Rafele “Managing Project Risks Using a Cross Risk Breakdown Matrix,” Risk management, Vol 8, pp. 6176, 2006. [Hossain et al. 2009] Hossain, E., Babar, M., Paik, H., and Verner, J. (2009). Risk Identification and Mitigation Processes for Using Scrum in Global Software Development: A Conceptual Framework. In Proceedings of the 2009 16th Asia-Pacific

Software Engineering Conference (APSEC

'09). IEEE

Computer Society, Washington, DC, USA, 457-464. [Hung et al. 2004] Hung, Y., Dennis, A., and Robert, L. (2004) Trust in Virtual Teams: Towards an Integrative Model of Trust Formation. In Proceedings of the Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS'04) - Track 1 - Volume 1 (HICSS '04), Vol. 1. IEEE Computer Society, Washington, DC, USA. [Iacovou e Nakatsu 2008] Iacovou, C.L., and Nakatsu, R. "A risk profile of offshoreoutsourced development projects," Communications of the ACM (51:6), 2008, pp 89-94. [IEEE Xplore 2011] Biblioteca Digital IEEE Xplore. Disponível na URL: http://ieeexplore.ieee.org Acesso em: 02/04/2011. [JATIT 2011] Journal of Theoretical and Applied Information Technology. Disponível na URL: http://www.jatit.org/ Acesso em: 02/04/2011 [Khan e Ghayyur 2010] Khan Q. e Ghayyur S. (2010) Software risks and mitigation in global software development, Journal of Theoretical and Applied Information Technology, Vol 22. No. 1, December 2010. [Kaiser e Hawk 2004] Kaiser, K.M., and Hawk, S. "Evolution of offshore software development: from outsourcing to cosourcing," MIS Quarterly Executive (3:2), 2004, pp 69-81. 51

[Karolak 1996] Karolak, D.W. (1996) Software Engineering Risk Management. IEEE. [Kitchenham 2006] Kitchenham, B. (2006). Empirical paradigm - the role of experiments. In Proceedings of the 2006 international conference on Empirical software engineering issues: critical assessment and future directions, pages 25–32, Berlin, Heidelberg. Springer-Verlag. [Kitchenham e Charters 2007] Kitchenham, B. e Charters, S. (2007) “Guidelines for performing systematic literature reviews in Software Engineering” Software Engineering Group, School of Computer Sciences and Mathematics, Keele University, and Department of Computer Science, University of Durham. [Knight 1921] Knight, F.H. (1921) Risk, Uncertainty and Profit. Houghton Mifflin Company, Boston. pp 22-24. [Kontio 2001] Kontio, J. (2001) Software Engineering Risk Management: A Method, Improvement Framework, and Empirical Evaluation. Tese de Doutorado. Helsinki University of Technology. [Lakatos e Marconi 1991] LAKATOS, E. e MARCONI, M. Metodologia do trabalho científico. São Paulo: Atlas, 1991. [Lamersdorf e Münch 2010] Lamersdorf, A., e Münch, J. (2010). A multi-criteria distribution model for global software development projects. Journal of the Brazilian Computer Society, 16(2), 1-19. Springer. [Lamersdorf et al. 2010] Lamersdorf A., Münch J., Torre F., Sánchez C., Heinz M., Rombach D., "A Rule-Based Model for Customized Risk Identification in Distributed Software Development Projects," icgse, pp.209-218, 2010 5th IEEE International Conference on Global Software Engineering, 2010. [Leavitt 1964] Leavitt, J. (1964): Applied Organization Change in Industry: Structural,

Technical,

and

Human

approaches.

(55–71)

in:

New

Perspectives in Organizational Research. Chichester: Wiley. [Lopez et al. 2009] Lopez, A., Nicolas, J., and Toval, A. (2009) Risks and Safeguards for the Requirements Engineering Process in Global Software 52

Development. In Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE '09). IEEE Computer Society, Washington, DC, USA, 394-399. [Machado 2002] MACHADO, F. A. Cristina (2002). A-RISK: Um Método para Identificar e Quantificar Riscos de Prazo em Projetos de Software. Dissertação de Mestrado. Curso de pós-graduação em Informática Aplicada - PPGIA, Centro de Ciências Exatas e de Tecnologia - CCET, Pontifícia Universidade Católica do Paraná - PUCPR. [Markus et al. 2000] Markus, M.L., Manville, B., and Agres, C.E. "What makes a virtual organization work?" Sloan Management Review (42:1), 2000, pp 1326. [Marshall 2002] Marshall, C. (2002) Medindo e gerenciando riscos operacionais em instituições financeiras. Rio de Janeiro: Qualitymark. [Mathiassen et al. 2007] Mathiassen, L., Saarinen, T., Tuunanen, T., and Rossi, M. "A contingency model for requirements development," Journal of the Association for Information Systems (8:11), 2007, pp 570-598. [Martins et al. 2004] Martins, L.L., Gilson, L.L., and Maynard, M.T. "Virtual teams: what do we know and where do we go from here?," Journal of Management (30:6), 2004, pp 805-835. [Mills 1968] Mills, T. (1968) "A Sociologia dos Pequenos Grupos". In: Parsons, Talcott (org.). A Sociologia Americana: perspectivas/ problemas métodos. São Paulo: Cultrix. [Mohan e Fernandez 2010] Mohan, S. and Fernandez, J. 2010. Distributed software development projects: work breakdown approaches to overcome key coordination challenges. In Proceedings of the 3rd India software engineering conference (ISEC '10). ACM, New York, NY, USA, 173-182. [Moynihan 1997] Moynihan, T. (1997) How experienced Project Managers Access Risk. IEEE Software. Volume 14. Nº 3. 35-41.

53

[Mudumba e Lee 2010] Mudumba V. and Lee D. 2010. A New Perspective on GDSD Risk Management: Agile Risk Management. In Proceedings of the 2010 5th IEEE International Conference on Global Software Engineering (ICGSE '10). IEEE Computer Society, Washington, DC, USA, 219-227. [Nakatsu e Iacovou 2009] Nakatsu, R.T., and Iacovou, C.L. "A comparative study of important risk factors involved in offshore and domestic outsourcing of software development projects: a two-panel Delphi study," Information & Management (46:1), Jan 2009, pp 57-68 [Nasscom-McKinsey 2002] Nasscom-McKinsey, “NASSCOM-McKinsey Report,” National Association of Software and Service Companies, New Delhi 2002. [Nidumolu 1994] Nidumolu, S. (1994): The Effect of Coordination and Uncertainty on Software Project Performance: Residual Performance Risk as an Intervening Variable. Information Systems Research, Vol. 36, No. 3 (191– 219). [Persson et al. 2009] Persson, J. S., Mathiassen, L., Boeg, J., Madsen, T. S., & Steinson, F. (2009). Managing Risks in Distributed Software Projects: An Integrative Framework. IEEE Transactions on Engineering Management, 56(3), 508-532. [Pfannenstein e Tsai 2004] Pfannenstein, L.L., and Tsai, R.J. "Offshore outsourcing: current and future effects on American IT industry," Information Systems Management (21:4), 2004, pp 72-80. [PMI 2004] PMI - Project Management Institute. (2004) A Guide to the Project Management Body of Knowledge. – ANSI/PMI 99-01-2004. Project Management Institute. Four Campus Boulevard. Newtown Square. USA [PROMISE 2011] PROMISE Process Management and Improvements in Software Engineering. Disponível na URL: http://www.cin.ufpe.br/~promise/ Acesso em: 17/07/2011 [Powell et al. 2004] Powell, A., G. Piccoli, B. Ives. 2004. Virtual teams: A review of current literature and directions for future research. DATA BASE for Advances in Information Systems 35(1) 6–36. 54

[Pressman 2006] Pressman, R. S. (2006) Engenharia de Software. 6ª edição. São Paulo: McGraw-Hill. Pp 577-595. [Prikladnicki e Yamaguti 2004] Prikladnicki, R., Yamaguti, M. H (2004), Risk Management in Distributed Software Development: A Process Integration Proposal, 5th IFIP Working Conference on Virtual Enterprises at 18th IFIP World Computer Congress, Springer Boston. [Prikladnicki et al. 2006] Prikladnicki, R., Evaristo, R., Audy, J.L.N., e Yamaguti, M.H. "Risk management in distributed IT projects: integrating strategic, tactical, and operational levels," International Journal of e-Collaboration (2:4), 2006, pp 1-18. [Ralyté et al. 2008] Ralyté, J., Lamielle, X., Arni-Bloch, N., Léonard, M. (2008) A framework for supporting management in distributed information systems development. RCIS 2008: 381-392. [Ripeanu et al. 2008] Ripeanu, M., Singh, M.P., and Vazhkudai, S.S. "Virtual organizations [guest editors' introduction]," IEEE Internet Computing (12:2), 2008, pp 10-12. [Rockart e Scott 1984] Rockart, J. F., and Scott, M.M. S. (1984). Implications of Changes in Information Technology for Corporate Strategy. Interfaces, 14 (1), 84-95. [Saarinen e Vepsalainen 1993] Saarinen, T. and Vepsalainen, A. (1993): Procurement Strategies for Information Systems. (118–141) in T. Saarinen: Success of Information Systems— Evaluation of Development Projects and the Choice of Procurement and Implementation Strategies. Ph.D. thesis, Helsinki School of Economics and Business Administration. [Sakthivel 2007] Sakthivel, S., Managing risk in offshore systems development. Commun. ACM 50, 4 (April 2007), 69-75. [Sarker e Sahay 2004] Sarker, S. e Sahay, S. (2004) Implications of Space and Time for Distributed Work: An Interpretive Study of US-Norwegian System Development Teams. European Journal of Information Systems 13 (2004) 3-20. 55

[Schiller e Mandviwalla 2007] Schiller, S.Z., and Mandviwalla, M. "Virtual team research: an analysis of theory use and a framework for theory appropriation," Small Group Research (38:1), February 2007, pp 12-59. [Scopus 2011] SciVerse Scopus. Disponível na URL: http://www.scopus.com/ Acesso em 02/04/2011. [Schmidt et al. 2001] Schmidt, R., Lyytinen, K., Keil, M., and Cule, P., "Identifying Software Project Risks: An International Delphi Study," Journal of Management Information Systems, vol. 17, pp. 5-36, 2001. [Silva e Menezes 2001] Silva, L. e Menezes, E. (2001) Metodologia da Pesquisa e Elaboração de Dissertação 3ª ed. rev., Florianópolis: Laboratório de Ensino a Distância da UFSC. [Smite 2007] Smite, D. (2007) Project Outcome Predictions: Risk Barometer Based on Historical Data. In Proceedings of the International Conference on Global Software Engineering (ICGSE '07). IEEE Computer Society, Washington, DC, USA, 103-112. [Sommerville 2003] Sommerville, I. (2003) Engenharia de Software. São Paulo: Addison Wesley, Brasil. [SpringerLink 2011] SpringerLink. Disponível na URL: http://www.springerlink.com/ Acesso em: 02/04/2011 [Swanson e Beath 1990] Swanson, E. and Beath, C. (1990) Departmentalization in Software Development and Maintenance. In Proceedings of Commun. ACM. 658-667. [Reed e Knight 2010] Reed, A., e Knight, L. (2010). PROJECT RISK DIFFERENCES BETWEEN VIRTUAL AND CO-LOCATED

TEAMS.

Information Systems Journal, 51(1), 19-30. [Roberts e Petticrew 2006] Roberts, H. e Petticrew, M. (2006) Systematic Reviews in the Social Sciences: A Practical Guide. Oxford: Blackwell [Tiako 2005] Tiako P.F. (2005), "Collaborative Approach for Modeling and Performing Mobile Software Process Components", Proceedings of the 56

2005 International Symposium on

Collaborative Technologies

and

Systems, St Louis, MO, USA, pp. 40-47. [Trigo et al. 2008] Trigo, T. R, Gusmão, C. M. G. and Lins, A. V. (2008) CBR Risk – Risk Identification Method Using Case Based Reasoning. CONTECSI International

Conference

on Information

Systems

and

Technology

Management. [Trigueiro et al. 2011] Trigueiro A., Barreiros E., Saraiva J. e Soares S. (2011) Mecanismos para Guiar Estudos Empíricos em Engenharia de Software: Um Mapeamento Sistemático, ESELAW 2011 (Experimental Software Engineering Latin American Workshop), Rio de Janeiro. [Victoria et al 2000] Victoria, C.G. et al. (2000) Pesquisa Qualitativa em Saúde: uma introdução ao tema. Porto Alegre: Tomo Editorial. pp. 33 – 78. [Wattanapokasin e Rivepiboon 2009] Wattanapokasin, W. and Rivepiboon, W. (2009) Cross-Cultural Risk Assessment Model. In Proceedings of the 2009 International Conference on Signal Processing Systems (ICSPS '09). IEEE Computer Society, Washington, DC, USA, 536-540. [Webster 2005] Webster, K. P. B. et al. (2005) Taxonomia de Riscos para Manutenção de Software. In Anais do IV Simpósio Brasileiro de Qualidade de Software. Porto Alegre – RS – Brasil. [Webster e Watson 2002] Webster, J., and Watson, R.T. "Analyzing the past to prepare for the future: writing a literature review," MIS Quarterly (26:2), Jun 2002, pp XIII-XXIII. [Weill e Olson 1989] Weill, P., and Olson, M.H. "An assessment of the contingency theory of management information systems," Journal of Management Information Systems (6:1), 1989, pp 59-85. [Yetton et al 1194] Yetton, P., Jonhston, K., and Craig, J. F. (1994). Computer Aided Architects: A Case Study of IT and Strategic Change. MIT Sloan Management Review, 35 (4), 57-67.

57

[Yu e Mishra 2010] Yu, L. e Mishra, A. (2010) Risk analysis of global software development and proposed solutions. Journal for Control, Measurement, Electronics, Computing and Communications, Vol.51 No.1 March 2010.

58

APÊNDICE A Este apêndice tem a finalidade de disponibilizar o guia utilizado na entrevista dos profissionais chaves que atuam como gerente de projetos em empresas estaduais e federais. Guia para a entrevista para mapeamento da maturidade da empresa com relação à Gerência de Riscos Entrevistado: Posição: Empresa: Formação: Tempo de atuação no mercado (como gerente): Faixa Etária: Começar com uma rápida conversa sobre: • Qual o entendimento do entrevistado sobre Riscos? • Por que eles acontecem? 1) A empresa tem ciência e trata direta ou indiretamente os Riscos sobre os projetos? Utiliza alguma técnica para identificação, análise e controle dos riscos? 2) A empresa tem algum projeto que utilize metodologias ágeis no desenvolvimento dos projetos? Se sim, qual a forma que utilizam para tratar os riscos? Quais atividades relacionadas à Gerência de Riscos são praticadas? 3) Existe algum processo definido para o gerenciamento de riscos? 4) É utilizada alguma ferramenta na Gerência de Riscos? Qual? 5) Existem profissionais especializados no gerenciamento de riscos na empresa? Quantos? 6) Como são gerenciados os riscos distribuídos em múltiplos projetos ou em projetos distribuídos da empresa?

59

APÊNDICE B Este apêndice tem a finalidade de disponibilizar o questionário utilizado na avaliação virtual da EAR proposta neste trabalho por profissionais especialista em Gerência de Projetos.

1. Na sua opinião, o modelo proposto por Leavitt utilizado na construção da EAR é suficientemente abrangente por levar em consideração os aspectos mais essenciais no desenvolvimento de software? Concordo Concordo parcialmente Indiferente Discordo Comentários:

2. A Estrutura Analítica de Riscos criada para Projetos de Desenvolvimento Distribuído de Software está clara? Concordo Concordo parcialmente Indiferente Discordo Comentários

60

3. Os fatores de riscos listados ajudariam você na identificação de riscos para um Projeto de Desenvolvimento Distribuído de Software? Concordo Concordo parcialmente Indiferente Discordo Comentários:

4. Quais os pontos positivos que você identifica na abordagem desta EAR na identificação dos fatores de riscos?

5. Quais os pontos de melhoria que você identifica na abordagem desta EAR na identificação dos fatores de riscos?

6. Quais fatores de riscos mapeados você NÃO acredita serem relevantes na identificação de riscos em projeto distribuídos de desenvolvimento de software? Nenhum dos fatores é irrelevante. Criticidade da tarefa 61

Distancia temporal Diferença nas leis Distância geográfica Divergências no processo de desenvolvimento Maturidade do processo Quantidade de locais de distribuição Transferência do conhecimento Distância do conhecimento Diferenças socio-culturais Diferenças culturais de trabalho Diferenças da língua Relacionamento pessoal Motivação da equipe Falta de confiança Formalidade e Transparência das tarefas Tratamento dos Requisitos Não-Funcionais Dúvida nos requisitos funcionais Acoplamento da tarefa Estabilidade dos requisitos Inadequação das Tecnologias de segurança Incompatibilidade tecnológica Adequação das ferramentas de apoio Canal de comunicação Complexidade da tarefa Experiência no domínio do projeto

62

APÊNDICE C Este apêndice tem a finalidade de disponibilizar o questionário utilizado na avaliação virtual qualitativa da EAR por especialistas na área de Gerenciamento de Riscos dentro da academia. 1. Qual o seu nome?

2. A EAR está clara? -------------------------------------------------------------Considere o seguinte: - A estrutura é relevante - Por que a estrutura é importante - Qual o objetivo da EAR Sim Não Comentários:

63

3. A metodologia de Mapeamento Sistemático é adequada? -------------------------------------------------------------Considere o seguinte: - A natureza da estrutura criada

Sim Não Comentários:

4. [EAR Apropriada] A EAR está adequada para resolver os motivos do seu desenvolvimento? -------------------------------------------------------------Considere o seguinte: -A EAR foi justificada Sim Não Comentários:

64

5. [Amostragem] A estratégia de recrutamento foi adequada aos objetivos da EAR? -------------------------------------------------------------Considere o seguinte: -Os fatores são definidos e explicados com precisão -Os fatores são representativos de uma população definida Sim Não Comentários:

6. [Coleta de Dados] Os dados foram colhidos de forma a proporcionar a construção da EAR? -------------------------------------------------------------Considere o seguinte: - Está claro como os dados foram coletados - O pesquisador justificou os métodos que foram escolhidos - O pesquisador deixou os métodos explícitos - O formulário de dados é claro Sim Não Comentários:

65

7. [Reflexividade: relações de parceria de investigação/reconhecimento de viés do pesquisador] A relação entre o pesquisador e a EAR foi considerada de forma adequada? -------------------------------------------------------------Considere o seguinte: - O pesquisador analisou criticamente seu próprio papel, o viés potencial e a influência durante a formulação das questões de pesquisa, o recrutamento da amostra, coleta de dados e análise e seleção e dados para apresentação - Como o pesquisador respondeu a eventos durante o estudo e se considerou implicações de quaisquer alterações no desenvolvimento da EAR Sim Não Comentários:

8. [Resultados] Há uma declaração clara dos resultados? -------------------------------------------------------------Considere o seguinte: - As conclusões são explícitas - Há uma discussão adequada das provas a favor e contra o desenvolvimento da EAR - O pesquisador discutiu a credibilidade da EAR - As limitações do estudo são discutidas explicitamente - A EAR é discutida em relação à questão de pesquisa - As conclusões são justificadas pelos resultados Sim Não

66

Comentários:

9. [Valor da EAR] A EAR tem valor para pesquisa ou prática? -------------------------------------------------------------Considere o seguinte: - O pesquisador discutiu a contribuição da EAR para o conhecimento existente ou compreensão dos fatores de riscos identificados - A pesquisa identifica novas áreas onde a pesquisa é necessária Sim Não Comentários:

67