Gestão de riscos aplicada a projetos de desenvolvimento de software em empresas de base tecnológica incubadas: revisão, classificação e análise da literatura

Resumo:

Projetos de software estão sujeitos a uma série de riscos e identificá-los auxilia os gestores a tomar decisões de forma sistemática. O objetivo deste artigo é apresentar uma revisão, classificação e análise da literatura sobre o gerenciamento de riscos em projetos de desenvolvimento de software com ênfase em empresas de base tecnológica incubadas. O estudo, de cunho teórico-conceitual, é justificado pela existência de lacunas na literatura e por um diagnóstico realizado em empresas de base tecnológica incubadas ter indicado a importância do tema para as mesmas. As publicações selecionadas foram localizadas por meio de consultas nas bases de dados dos periódicos da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) e foram classificadas de acordo com o ano de publicação, local onde as pesquisas foram realizadas, filiação, tipo de estudo, abordagem, objetivo e foco da pesquisa. Realizou-se também um levantamento dos principais resultados de pesquisas atuais sobre gerenciamento de riscos em projetos de desenvolvimento de software, cujos resultados mostram que trabalhos relativos ao tema e direcionados a empresas de base tecnológica incubadas ainda são escassos, necessitando de pesquisas empíricas que possam auxiliar essas empresas a identificar os seus principais fatores de riscos e a reduzir ou eliminar a probabilidade de falhas nos projetos.

Palavras-chave:
Gerenciamento de riscos; Desenvolvimento de software; Empresas de base tecnológica incubadas

Abstract:

Software projects are subjected to several risk analyses, since risk related information can improve managers’ decision making. This paper aimed at performing a review, classification, and analysis of the literature on risk management applied to software development projects, with an emphasis on incubated technology based companies. This theoretical-conceptual research is justified for two reasons: first, because the bulk of the research literature has not sufficiently addressed this subject; and second, because a diagnostic study carried out with incubated technology based companies emphasized the importance of this subject to them. The literature used as the grounds for this study was selected from Brazil’s Coordination of Improvement for Higher Education Personnel (CAPES) database of periodicals, and classified by year of publication, place where research was conducted, type of study and approach, research aim, and research focus. We also conducted a survey of the most relevant current studies on risk management for software development projects, which revealed that studies on this issue, aimed at incubated technology based companies, are scarce. This indicates the need for empirical research to assist incubated companies in the identification of main risk factors for their business while reducing or eliminating the likelihood of failures.

Risk management; Software development; Incubated technology based company

1 Introdução

Projetos de software são empreendimentos complexos em qualquer contexto e são particularmente susceptíveis a falhas (Bannerman, 2008). Um dos motivos para essas falhas pode advir do não gerenciamento dos riscos presentes no âmbito do projeto de desenvolvimento de software. Para Pinna & Carvalho (2008), riscos não gerenciados de forma adequada podem comprometer a qualidade do produto final, a expectativa do cliente pode não ser atendida e a equipe, que precisa conviver com ansiedades e conflitos durante a vida do projeto, pode ter sua produtividade reduzida. Conceitualmente, a partir de uma perspectiva organizacional, o risco surge quando as organizações perseguem oportunidades, face às incertezas, condicionadas pela capacidade e custos (Bannerman, 2008).

Muitos desenvolvedores de software e gestores de projetos percebem as atividades e processos de gerenciamento de riscos como trabalho extra e gastos, sendo que o processo de gerenciamento de riscos é a primeira atividade a ser removida das atividades do projeto quando ocorrem falhas no cronograma (Kwak & Stoddard, 2004). Afirmam também os autores que muitos profissionais em desenvolvimento de software percebem o gerenciamento de riscos e o controle como inibidores da criatividade. As elevadas taxas de insucesso associadas a projetos de sistemas de informação sugerem que as organizações precisam melhorar não só a sua capacidade de identificar, mas também de gerir os riscos associados a esses projetos (Jiang et al., 2001).

Baseando-se nessas informações, este artigo tem como objetivo apresentar uma revisão, classificação e análise da literatura atual sobre o gerenciamento de riscos em projetos de desenvolvimento de software, permitindo assim avaliar tendências e a existência de lacunas na literatura referentes à aplicação do gerenciamento de riscos em micro e pequenas empresas de base tecnológica incubadas. Este trabalho é de cunho teórico-conceitual, trata-se de uma discussão decorrente da análise da literatura, tendo como resultado o levantamento de uma série de pontos relevantes (Miguel, 2007; Wacker, 2004). Para o desenvolvimento do estudo foi realizada uma revisão da literatura sobre o processo de gerenciamento de riscos. Essa revisão buscou identificar na literatura trabalhos cujo tema principal ou secundário abordasse o gerenciamento de riscos em projetos de desenvolvimento de software. Utilizou-se para essa pesquisa a base de dados da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), o que se justifica devido à sua grande abrangência e facilidade de acesso para a maioria dos pesquisadores brasileiros (Carnevalli & Miguel, 2007).

O artigo está estruturado da seguinte forma: A Seção 1 apresentou a introdução, objetivos e justificativas. Na Seção 2 é apresentada a relevância das pesquisas realizadas em empresas de base tecnológica incubadas e o gerenciamento de riscos em projetos de desenvolvimento de software. Na Seção 3 apresenta-se o levantamento dos dados e, na Seção 4, as análises e os resultados obtidos. Finalmente, na Seção 5 são apresentadas as discussões e conclusões, assim como as sugestões para pesquisas futuras.

2 Relevância de pesquisas em empresas de base tecnológica incubadas

Segundo Kendrick (2003), todos os projetos apresentam riscos, mas projetos de alta tecnologia apresentam riscos particulares, como alta variação. Embora haja aspectos nos projetos que lembrem trabalhos anteriores, cada projeto tem aspecto único e objetivos que o diferem de trabalhos anteriores de forma substancial, assim como desafios para alcançá-los cada vez mais rapidamente. Dahlstrand (2007) define empresa de base tecnológica como aquela que depende da tecnologia para o seu crescimento e sobrevivência, não significando, na maioria das vezes, que a tecnologia deva ser nova ou uma inovação.

De acordo Costa et al. (2007), a gestão de riscos vem ganhando importância no gerenciamento de projetos de software e as incertezas enfrentadas nesses projetos deveriam ser levadas em conta no momento do seu planejamento e controle. Lahorgue & Hanefeld (2004) destacam a importância das empresas de base tecnológica (EBT) ao afirmar que as EBT, apoiadas pelas incubadoras, tiram tecnologia de pesquisas universitárias e a coloca no mercado, beneficiando empresas preexistentes ou consumidores finais. O gerenciamento de riscos como estrutura formal, apesar da sua relevância, ainda é considerado pequeno nas organizações.

No Brasil, uma pesquisa realizada em 2001 pela Secretaria de Planejamento em Informática (SEPIN) sobre práticas de engenharia de software adotadas nas fases de desenvolvimento e manutenção, concluiu que apenas 11,8% das 446 organizações participantes realizavam gerenciamento de risco em seus projetos, sendo que, com relação à documentação adotada, apenas 9,7% realizavam a identificação de risco (Brasil, 2002). Destaca-se que, considerando a força de trabalho total das organizações participantes, 61,5% eram micro e pequenas empresas. Encontra-se comumente na literatura a gestão de projetos e, em seu contexto, a gestão de riscos, aplicada a grandes empresas (White & Fortune, 2002; Bryde, 2003), mas pesquisas publicadas sobre o gerenciamento de projetos em pequenas e médias empresas ainda são incipientes (Murphy & Ledwith, 2007).

Em um diagnóstico realizado pelo Núcleo de Desenvolvimento de Produtos (NDP) da Incubadora de Base Tecnológica de Itajubá (INCIT) em 13 micro e pequenas Empresas de Base Tecnológica Incubadas (EBTI) identificou-se que muitos projetos, senão a quase totalidade, são conduzidos sem o uso de metodologias de gerenciamento de riscos, sendo que 70% dessas empresas consideram ser a análise de riscos uma oportunidade de melhoria (Figura 1), visto que poderiam evitar, mitigar, transferir ou até mesmo aceitar os riscos, desde que devidamente gerenciados.

Figura 1
Resultado diagnóstico EBTI – 2008/2009.

Após realizar uma revisão sobre riscos no processo de desenvolvimento de software, Bannerman (2008) concluiu que existe a necessidade de uma melhor gestão de riscos, tanto em pesquisas como na prática.

Infelizmente, apesar dessas recomendações, existem relativamente poucas ferramentas disponíveis para ajudar os gestores de projetos a identificar e categorizar os fatores de risco, com o objetivo de desenvolver estratégias eficazes (Wallace et al., 2004a, p. 115).

Para as EBTI avaliadas, o processo de análise de riscos permitiria realizar um processo de prevenção de falhas, possibilitando a tomada de decisões com base em dados organizados, e uma revisão apropriada sobre riscos no processo de desenvolvimento de software pode indicar perspectivas para pesquisas futuras, identificando lacunas e permitindo a condução de pesquisas no ambiente de incubadoras de empresas de base tecnológica.

3 Gerenciamento de riscos em projetos de desenvolvimento de software

Projetos de software são atividades de alto risco, gerando resultados de desempenho variáveis (Charette, 2005). Segundo Kerzner (2006, p. 10), os aliados da gestão de projetos começaram a aparecer em 1985, sendo que a gestão de riscos surgiu em 1996, quando

[...] as empresas percebem que o gerenciamento do risco implica mais do que proteger uma estimativa ou a programação e planos de gerenciamento de riscos passam a ser incluídos no planejamento dos projetos [...]

Um risco pode ser composto por dois componentes: a probabilidade de que uma perda irá ocorrer e a importância ou magnitude associada a essa possível perda (Barki et al., 1993).

Para o PMBoK (PMI, 2008, p. 194),

O risco do projeto é um evento ou condição incerta que, se ocorrer, provocará um efeito positivo ou negativo em um ou mais objetivos do projeto tais como escopo, cronograma, custo e qualidade.

Riscos em projetos de softwares são uma série de fatores ou condições que podem representar uma séria ameaça para o êxito da realização do projeto (Wallace et al., 2004a) e implicam em quantificar a sua importância, avaliando-se a probabilidade de ocorrência desse risco e seu possível impacto no desempenho do projeto, assim como o desenvolvimento de estratégias para controlá-lo (Huang & Han, 2008).

Estudo conduzido pelo The Standish Group (2000) mostra, por meio do Chaos Report, o resultado final sobre projetos de software, onde 28% dos projetos do referido ano foram projetos de sucesso, entregues no tempo e com o custo previstos com todas as funcionalidades especificadas; 49% foram entregues com atraso, fora do custo ou não atendendo as funcionalidades previstas; 23% foram cancelados antes de sua finalização. Segundo Emam & Koru (2008), alguns pesquisadores questionam essas pesquisas por não divulgarem a sua metodologia, por não passarem por revisão entre pares e pelos relatórios inconsistentes sobre a definição das falhas. Em pesquisa similar, realizada pelos mesmos autores com o objetivo de avaliar taxas de cancelamento e de sucesso, obtiveram-se taxas de cancelamento de 15,52% e de 11,54%, em 2005 e em 2007, respectivamente; de 48% a 55% de taxa de sucesso, respectivamente, e de 17% a 22% de taxa de insucesso, respectivamente. A taxa combinada de insucessos e cancelamentos corresponde a 34% e 26%, em 2005 e 2007, respectivamente, existindo assim, uma sugestão de tendência a decréscimo. Apesar das melhorias já alcançadas, muitos projetos de desenvolvimento de software ainda usam mais recursos do que o planejado, levam mais tempo para ser concluídos e fornecem menos qualidade e funcionalidade do que o esperado (Barros et al., 2004). Mas por que projetos de softwares falham com tanta frequência?

• •

  Para Kwak & Stoddard (2004), falhas em projetos são resultado de uma multiplicidade de riscos inerentes em ambientes de projetos de software;

• •

  Segundo Charette (2005), entre os fatores mais comuns estão: metas irrealistas; estimativas imprecisas dos recursos necessários; requisitos de sistema mal definidos; má apresentação do status do projeto; riscos não gerenciados; falhas de comunicação entre clientes desenvolvedores e usuários; uso de tecnologia imatura; incapacidade de lidar com a complexidade do projeto; práticas mal desenvolvidas; má gestão do projeto; política com os stakeholders e pressões comerciais;

• •

  Apesar de alguns gestores afirmarem que gerenciam os riscos em seus projetos, há evidências de que não o gerenciam sistematicamente; da mesma forma, avaliam riscos técnicos, em detrimento dos riscos de mercado e financeiros, vitais para o sucesso de desenvolvimento de software (Dey et al., 2007);

• •

  Para Barros et al. (2004), a maioria das técnicas aplicadas aos projetos de desenvolvimento de software requer objetivos claros e delimitados, tempo e recursos definidos antes do início do projeto, métricas de qualidade definidas, dentre outras, o que geralmente não ocorre em grandes projetos;

• •

  As mudanças de requisitos e escopo são as principais razões para cancelamento de projetos (Emam & Koru, 2008).

Autores como Raz et al. (2002), Jiang et al. (2001), Wallace et al. (2004a) consideram que os riscos podem ser gerenciados com sucesso. Segundo Saarinen (1996), os fatores de sucesso em projetos devem abranger quatro dimensões: sucesso no processo de desenvolvimento; sucesso referente ao uso; qualidade do produto e impacto do sistema de informação sobre a organização. Para Dey et al. (2007), o sucesso no desenvolvimento de software depende de critérios como funcionalidade, qualidade e atualidade.

Identificar os riscos associados com a implementação de Tecnologia da Informação (TI) pode se tornar um grande desafio para os gestores, visto que existem inúmeras formas para descrevê-los e classificá-los (Baccarini et al., 2004). No PMBoK (PMI, 2008), as etapas para o gerenciamento de riscos em projetos consistem em planejamento do gerenciamento de riscos, identificação de riscos, análise qualitativa, análise quantitativa, planejamento de respostas a riscos e monitoramento e controle. Os riscos podem variar em natureza, gravidade e consequência, derivando desses fatores a importância de que aqueles considerados de alto nível sejam identificados, entendidos e geridos (Baccarini et al., 2004).

O processo de identificar e estimar riscos de sistemas pode ser realizado por uma variedade de técnicas, dentre as quais citam-se análise de regressão, sistema especialista (Expert Systems) e modelos estocásticos (Houston et al., 2001), Diagrama de Influência, Simulação de Monte Carlo, PERT, Análise de Sensibilidade, Multiple Criteria Decision Making (MCDM), Fuzzy Set Approach (FSA), Redes Neurais, Árvore de decisão e Análise de árvore de falhas, Checklist de riscos, Mapa de riscos, Diagrama de causa/efeito, Técnica Delphi e uma combinação de árvore de decisão com o AHP (Dey & Ogunlana, 2004), entretanto essas técnicas não serão tratadas nesta pesquisa. Dentre as abordagens para o gerenciamento de riscos em projetos de software destacam-se o Capability Maturity Model Integration – CMMI (SEI, 2006), elaborado pelo Software Engineering Institute (SEI), o Rational Unified Process – RUP (IBM, 2003), O Microsoft Solutions Framework – MSF (Microsoft, 2002), a norma AS/NZS 4360 (Standards Australia & Standards New Zealand, 2004), a norma ISO/IEC 15.504-5 (ISO, 1999), Boehm (1988) e a abordagem segundo a ISO 10.006 (ISO, 2003). Gusmão (2007) apresenta a cronologia das abordagens que tratam da gerência de riscos em projetos de software (Figura 2) até o ano de 2001, sendo que essas foram complementadas com abordagens mais recentes como MPS.BR (SOFTEX, 2006) e ISO 31.000 (ISO, 2009).

Figura 2
Distribuição das publicações por foco. Fonte: Gusmão (2007), complementado pelos autores.

Dessa forma, foi realizado um comparativo entre as principais abordagens (Neves et al., 2014), de modo a facilitar a visualização das etapas que compõem a gestão de riscos em projetos de desenvolvimento de software (Quadro 1). O comparativo teve como base as etapas da área de conhecimento de gerenciamento de riscos do projeto descritas pelo guia PMBoK (PMI, 2008) e acrescidas das etapas “resolver riscos”, “comunicar riscos” e “aprender” parte integrante de outras abordagens (Microsoft, 2002; Standards Australia & Standards New Zealand, 2004).

Quadro 1
Comparativo abordagens de gerenciamento de riscos em projetos de software.

Etapas	Boehm (1988)	ISO/IEC 15.504 (1999)	MSF (2002)	RUP (2003)	ISO 10006 (2003)	AS/NZS 4360 (2004)	CMMI (2006)	MPS. BR (2006)	PMBOK (2008)
Planejar gerenciamento de riscos		✓	✓	✓		✓	✓	✓	✓
Identificar riscos	✓	✓	✓	✓	✓	✓	✓	✓	✓
Preparar análise qualitativa de riscos	✓	✓	✓	✓	✓	✓	✓	✓	✓
Preparar análise quantitativa	✓	✓	✓	✓	✓	✓	✓	✓	✓
Planejar respostas para riscos	✓	✓	✓	✓	✓	✓	✓	✓	✓
Resolver riscos	✓	✓	✓	✓	✓	✓	✓	✓	✓
Monitorar e controlar riscos	✓	✓	✓	✓	✓	✓	Implícito	✓	✓
Comunicar riscos			Implícito		Implícito	✓	Implícito		Implícito
Aprender			✓		Implícito	Implícito	Implícito		Implícito

• Fonte: Neves et al. (2014).

Com relação às abordagens de gerenciamento de riscos apresentadas, pode-se observar que são muito semelhantes em seu contexto. Algumas abordagens fornecem um maior detalhamento na descrição das etapas, como PMBoK (PMI, 2008) e CMMI (SEI, 2006), no entanto aquelas que não proporcionam esse detalhamento, ao se avaliar o contexto percebe-se que estão incluídas as etapas constantes nas demais abordagens de forma implícita. Na sequência apresenta-se o levantamento dos dados para a composição da pesquisa.

4 Levantamento dos dados

Por meio da Figura 3 visualiza-se o resultado das consultas realizadas nos periódicos da CAPES nas bases de dados Science Direct, Emerald, Wiley, Springer, Wilson, IEEE e Informs, de acordo palavras-chave previamente definidas (“Risk and Project”, “Risk and Software” “Risk and Incubated Technology-Based Companies”) e de acordo com os principais periódicos em gerenciamento de projetos, desenvolvimento de software e micro e pequenas empresas. O período da análise considera a data inicial de cada periódico até o dia 9/7/2009.

Figura 3
Resultados das pesquisas por base de dados.

Utilizando as palavras-chaves “Risk and Incubated Technology-Based Companies” poucos resultados foram obtidos, sendo que, após a análise individual, os mesmos não estavam relacionados diretamente ao tema desta pesquisa. Na sequência foi realizada a avaliação dos 326 artigos encontrados de acordo com a palavra-chave “Risk and Software”, sendo que, desses, 44 foram selecionados de acordo com a sua relevância para a pesquisa. Os periódicos onde foram localizados os artigos selecionados podem ser visualizados no Quadro 2. As principais bases de dados referentes aos periódicos são contempladas na Figura 4.

Quadro 2
Relação de periódicos de acordo pesquisas selecionadas.

Periódicos
Decision Science	IEEE Transactions on Software Engineering	Journal of Management Information Systems
Decision Support Systems	IEEE Transactions on Systems	Journal of Systems and Software
IEEE Computer	Industrial Management & Data Systems	Software Engineering Journal
IEEE Security & Privacy	Information & Management	Software Maintenance: Research and Practice
IEEE Software	Information Management & Computer Security	Technovation
IEEE Spectrum	Information and Software Technology
IEEE Transactions on Engineering Management	Information Systems Research

Figura 4
Relação de bases de dados pesquisadas.

Visando trabalhar com dados mais atuais, os artigos foram divididos considerando um horizonte de análise de 10 anos, correspondendo a 27 artigos (Figura 5).

Figura 5
Distribuição percentual do número de publicações por década.

Após a seleção de acordo com a década, os artigos foram analisados e classificados.

5 Análises e resultados obtidos

O Quadro 3 apresenta uma seleção dos principais resultados das pesquisas sobre gerenciamento de riscos em projetos de software de acordo com os artigos analisados.

Quadro 3
Pesquisas sobre gerenciamento de riscos em projetos de software.

Objeto de estudo	Foco da pesquisa/Resultados
Ropponen & Lyytinen (2000)
83 gestores de projeto da Finlândia membros do Finnish Information Processing Association (FIPA)	Foram identificados 6 principais componentes de riscos em software. Utilizado Principal Component Analysis (PCA) para reduzir o número de itens. Contemplados 1.100 projetos.
Jiang et al. (2001)
194 gerentes de projetos do Project Management Institute (PMI)	Elaboração de um modelo que relaciona as fontes de risco e estratégias para o sucesso. Constatação de que as organizações estão mais propensas a serem bem-sucedidas com relação a projetos quando são capazes de minimizar os riscos conhecidos com estratégias adequadas.
Schmidt et al. (2001)
41 gestores de projetos de organizações em Hong Kong (9), Finlândia (13) e USA (19)	53 fatores de riscos agrupados em 14 categorias. Identificação dos fatores de risco mais significativos para projetos de desenvolvimento de software. Embora exista uma área de concordância entre as diferentes culturas com relação a alguns dos principais riscos, também existem diferenças discerníveis na identificação e percepção da importância de determinados riscos.
Houston et al. (2001)
I) 36 gestores de projetos de software de 22 organizações; II) 458 gestores	Abordagem para modelar fatores de riscos e simular seus efeitos como uma forma de apoiar atividades de gerenciamento de riscos em atividades de desenvolvimento de software.
Boehm & Turner (2003)
Empresa de software (Supply Chain)	Método utilizando análise de risco. Uso de um processo de cinco etapas para determinar qual é a melhor abordagem para o projeto: se abordagem baseada em métodos ágeis (Scrum, Extreme Programming, Agile software), em métodos planejados (ex., Capability Maturity Model – CMM) ou em uma estrutura de processos unificados que se completam de forma balanceada, para que juntos possam reduzir falhas.
Barros et al. (2004)
2 projetos de software de 2 grandes empresas brasileiras	Abordagem que permite desenvolver, recuperar e reutilizar o conhecimento e experiência na gestão de projetos por meio de cenários utilizados para modelar impacto do risco e resolução de estratégias.
Wallace et al. (2004a)
507 gestores de projetos de software membros do Information Systems Special Interest Group (ISSIG) do Project Management Institute (PMI)	Apresentadas 6 dimensões de risco. Introdução de um modelo conceitual. Evidências empíricas de que o mais proeminente dos riscos associados a projetos de alto risco diferem daqueles de médio e baixo risco. Para projetos de alto risco, requisito, planejamento e controle de riscos e risco organizacional são os riscos mais proeminentes, enquanto que para projetos de baixo risco, complexidade do projeto é o mais proeminente.
Baccarini et al. (2004)
18 gestores de projetos de TI de empresas públicas e privadas australianas	Identificados 27 principais fatores de riscos derivados da literatura. Ordenados os 10 principais fatores de risco de acordo com probabilidade de ocorrência e consequência, assim como sugerido tratamento.
Charette (2005)
Projetos de grandes empresas que falharam	Considerações sobre por que os projetos de software falham e suas implicações.
Costa et al. (2007)
34 gestores de projetos e 16 analistas (11 do meio acadêmico e 39 de empresas) de 26 empresas	Técnica de avaliação de riscos para projetos de software baseada em uma visão econômica dos elementos que constituem fatores de risco para esses projetos. 211 questões classificadas em 10 fatores de riscos.
Dey et al. (2007)
Projetos de software de uma organização do setor público em Barbados	Elaboração de uma estrutura para gerenciamento de riscos em projetos de software sob a perspectiva dos desenvolvedores. A estrutura consiste em sete etapas.
Na et al. (2007)
3 grandes empresas de desenvolvimento de software da Coréia.	Desenvolver e testar um modelo baseado em riscos que prevê simultaneamente o desempenho objetivo (quantitativo: custos, prazos etc.) e subjetivo (mede o desempenho das pessoas envolvidas) em TI de países em desenvolvimento. Elaborados três modelos conceituais. 11 hipóteses testadas e aprovadas.
Du et al. (2007)
118 especialistas em TI e 140 iniciantes (estudantes)	Investigaram empiricamente como condições específicas impactam na percepção de riscos de TI e na decisão subsequente de continuar o projeto. Foco em três elementos: ferramentas, competência individual e percepção de controle. Hipóteses foram testadas via fatorial.
Han & Huang (2007)
115 gestores de projetos	6 dimensões de riscos – 27 fatores de risco. Selecionados os 10 principais fatores de riscos de acordo com 115 projetos de software avaliados, informando sua probabilidade de ocorrência e grau de impacto. A dimensão “requisitos” é a que mais afeta o desempenho dos projetos avaliados.
Keil et al. (2008)
149 profissionais de desenvolvimento de software de quatro empresas de tamanho médio a grande	Comprovada uma das hipóteses testadas de que profissionais de software que usam checklist de riscos conseguem identificar mais riscos do aqueles que não usam o checklist. É sugerido que a ausência de um checklist conduz os profissionais de software a distinguir entre os riscos que estão realmente no cenário e os riscos que não estão. Ou seja, o checklist leva os profissionais de software a identificar riscos que não estão presentes no cenário. O valor do checklist de riscos é ajudar a identificar riscos que poderiam passar despercebidos.
Emam & Koru (2008)
Gestores de projeto de departamentos de TI. Sendo 232 em 2005 e 156 em 2007	Avaliada a taxa de projetos de software cancelados e os resultados da entrega daqueles que não foram cancelados. Resultado: taxa de cancelamento em 2005, 15,52%, e, em 2007, 11,54%.
Huang & Han (2008)
97 gestores de projeto	Utilizando análise de cluster, os resultados revelaram que a exposição aos riscos associados com as dimensões de risco “usuários”, “requisitos”, “planejamento e controle” e “equipe” foi afetada pela duração do projeto, mas também mostrou como gerenciar efetivamente riscos de software por meio da observação de tendências nos componentes de riscos.
Bannerman (2008)
23 gerentes de projetos de agências do governo australiano	Identificados 10 fatores de riscos. Projetos divididos em quatro categorias (projetos de forma pura, forma híbrida, atividade operacional e evento avançado). Defasagem de estudos sobre riscos na prática.
Nakatsu & Iacovou (2009)
57 gestores de projetos de TI membros do PMI	Principais fatores de riscos associados ao desenvolvimento de software terceirizado (doméstico e offshore), utilizando o método Delphi.

Percebe-se que, quanto ao objeto de estudo, as pesquisas são, em sua maioria, em grandes empresas do setor público e privado ou em institutos como o PMI. Empresas de base tecnológica incubadas não foram citadas diretamente nos artigos avaliados.

Quanto à classificação das pesquisas, utilizou-se como referência os dados apresentados no Quadro 4.

Quadro 4
Classificação das pesquisas.

Item	Descrição	Referência
Local	País onde as pesquisas foram realizadas	-
Foco	Informações sobre o foco da pesquisa (principal assunto)	-
Método de pesquisa	Os artigos foram catalogados e classificados de acordo com os procedimentos técnicos utilizados, como: “teórico-conceitual”, “simulação”, “modelagem teórica, “survey”, “estudo de caso”, “pesquisa-ação” e “pesquisa experimental”	Bertrand & Fransoo (2002), Gil (2009), Yin (2009), Bryman & Bell (2007), Miguel (2007), Miguel et al. (2009)
Objetivo	”Exploratória”, ”Descritiva” e ”Explicativa”	Gil (2009), Bryman & Bell (2007)
Abordagem	“Qualitativa”, “Quantitativa” e ”Combinada”	Creswell & Plano Clark (2007), Bryman & Bell (2007)
Filiação dos autores	“Universidade”, “Centro de Pesquisa” e “Empresa”	-

Os principais resultados abrangem, além dos resumos apresentados no Quadro 3, os trabalhos publicados por Wallace et al. (2004b), Li et al. (2008), Verdon & McGraw (2004), Barki et al. (2001), Zhou et al. (2008), Sanders & Kelly (2008), Keil et al. (2000) e Kwak & Stoddard (2004).

A Figura 6 apresenta o resultado da classificação dos artigos quanto ao local de realização das pesquisas.

Figura 6
Distribuição das publicações por local.

A maioria dos estudos foram realizadas nos Estados Unidos (45%), sendo apenas dois realizados no Brasil (7%).

A Figura 7 mostra a concentração das pesquisas de acordo com o seu foco.

Figura 7
Distribuição das publicações por foco.

O foco das pesquisas mostra uma tendência na literatura para análise de fatores de riscos ou taxonomias de riscos. Segundo Prieto-Díaz (2002), uma taxonomia é uma estrutura categorizada e a classificação é a ação de atribuição de entidades às categorias definidas dentro da taxonomia. É o agrupamento de itens semelhantes, tomando-se por base critérios estabelecidos. Muitos autores enfatizam a questão referente a fatores de riscos na literatura (McFarlan, 1981; Boehm, 1991; Barki et al., 1993; Sumner, 2000; Longstaff et al., 2000; Cule et al., 2000; Kliem, 2000; Schmidt et al., 2001; Houston et al., 2001; Murthi, 2002; Addison, 2003; Wallace et al., 2004a; Charette, 2005; Han & Huang, 2007; Keil et al., 2008; Bannerman, 2008). Nesse sentido, Schmidt et al. (2001, p. 7) definem fatores de risco como “[...] uma condição em que pode estar presente uma grave ameaça para o completo sucesso de um projeto de desenvolvimento de software”. Defensores do gerenciamento de riscos em projetos de software sugerem que gerentes de projeto deveriam identificar e controlar esses fatores para reduzir as chances de falha do projeto (Wallace et al., 2004a). Entender a natureza dos diferentes riscos envolvidos no processo de desenvolvimento de software e sua relação com o desempenho do projeto tornou-se muito importante uma vez que o plano e a estratégia de gerenciamento de riscos depende disso (Han & Huang, 2007). Segundo Keil et al. (2008), embora esses riscos apresentem variações em seu grau de consistência e do domínio do risco, existem similaridades em temas como riscos relacionados ao suporte da alta direção, incerteza quanto aos requisitos e falta de envolvimento do usuário, dentre outros. Entretanto, algumas críticas com relação a fatores de risco ou abordagens similares são apresentadas na literatura. Para Murthi (2002), taxonomias de risco podem guiar a equipe de projeto na identificação. Entretanto, apesar de muito trabalho ter sido realizado no sentindo de desenvolver essas taxonomias, elas tendem a ignorar os riscos que afetam normalmente projetos atuais. Para Rovai (2005), uma vantagem de se construir listas de riscos é a identificação rápida e simples dos riscos, mas é pouco provável que se construa uma lista exaustiva dos riscos, desvantagem que pode limitar o usuário efetivamente às categorias da lista.

Na Figura 8 apresentam-se as publicações de acordo com o método de pesquisa.

Figura 8
Distribuição das publicações de acordo com o método de pesquisa.

Os métodos de pesquisa se dividem, em sua maioria, entre Estudo de Caso (41%) e Survey (37%). Sendo que o survey foi o método mais utilizado nas pesquisas realizadas nos Estados Unidos.

A Figura 9 mostra a classificação das pesquisas de acordo com o objetivo.

Figura 9
Distribuição das publicações de acordo com o objetivo.

Com relação à distribuição das publicações de acordo com a abordagem utilizada, 56% correspondem a pesquisas qualitativas (Figura 10).

Figura 10
Distribuição das publicações por abordagem.

A maioria dos pesquisadores que abordaram o gerenciamento de riscos no processo de desenvolvimento de software são da universidade, correspondendo a 85% (Figura 11).

Figura 11
Distribuição das publicações por filiação dos autores.

Finalmente, elaborou-se uma análise bibliométrica dos principais artigos sobre Riscos e Projetos de Software, considerando todos os períodos e o número de citações que foram realizadas do documento original. A bibliometria permite que se realize uma medida quantitativa essencialmente objetiva da produção científica (Okubo, 1997). A principal fonte de informação para a realização da pesquisa foi a base do Institute for Scientific Information (ISI), a Web of Science, que abrange três bancos de dados: o Science Citation Index (SCI), o Social Science Citation Index (SSCI) e o Arts and Humanities Citation Index (AHCI), sendo esse desconsiderado.

A Figura 12 apresenta a relação dos autores dos artigos mais citados, considerando aqueles que apresentaram acima de 15 citações.

Figura 12
Autores mais citados sobre riscos e projetos de software.

Os dados foram quantificados pelos softwares Sitkis e UCINET, que transformaram as informações textuais em dados numéricos, de forma a permitir a realização das análises estatísticas, gerando listas, tabelas e matrizes. Considerou-se que os autores citaram artigos que entendiam como importantes para o desenvolvimento de suas pesquisas. Dessa forma, Boehm, Charette e Keil aparecem como autores que mais apresentam citação dos seus artigos. Dos 13 autores mais citados, 10 foram considerados nesta pesquisa, indicando a relevância dos trabalhos selecionados, sendo que os artigos dos autores Haimes e Nidumolu não foram contemplados devido ao ano de publicação (décadas de 1970, 1980 e 1990), e as citações do autor Jones se referem, em sua maioria, ao livro Assessment and Control of Software Risks, de 1994.

A análise da cocitação de artigos permite avaliar a citação entre os pares, de modo a se perceber a similaridade de conteúdo entre os artigos. Para Marshakova (1981), a cocitação mede o grau de ligação de dois ou mais artigos pelo número de documentos onde esses artigos são citados, simultaneamente. A análise considerou alguns dos principais artigos da pesquisa, incluindo o artigo do autor mais citado, Boehm (Figura 13).

Figura 13
Análise de cocitação dos principais artigos.

Percebe-se uma convergência de todos os autores para o artigo de Boehm de 1991, assim como a existência de relacionamento entre os demais.

Com o objetivo de avaliar a produção científica relacionada ao tema no Brasil, realizou-se consulta nos principais periódicos em Engenharia de Produção (Qualis B2), considerando as palavras-chave “Riscos and Software” no campo resumo. O período da análise considerou a data inicial de cada periódico até o dia 9/7/2009. Os resultados podem ser observados por meio do Quadro 5.

Quadro 5
Pesquisas no Brasil sobre gestão de riscos e projetos de desenvolvimento de software.

Periódicos	Total de artigos publicados
Gestão & Produção	0
Produção	0
Pesquisa Operacional	0

Percebe-se que, no Brasil, o tema “riscos e projetos de software” ainda não é tão explorado para publicação nas revistas de Engenharia de Produção. Mesmo pesquisando em toda a base de dados da Scielo Brasil, essas palavras-chave também não foram encontradas. Entretanto, são temas de pesquisas nas universidades brasileiras considerando, por exemplo, áreas da Administração (Leopoldino, 2004) e, principalmente, Engenharia de Sistemas e Computação (Gusmão, 2007).

6 Discussões e conclusões

Devido ao número de artigos analisados, não é possível generalizar as conclusões, no entanto, algumas considerações podem ser inferidas a partir do estudo:

• •

  Concentração de publicações na base de dados do IEEE, com 48%;

• •

  A maioria dos pesquisadores são americanos (45%);

• •

  Encontrou-se uma certa dificuldade na classificação da pesquisa, visto que, principalmente nos artigos mais antigos, não se obtinha claramente essa informação; identifica-se uma predominância do estudo de caso (41%) e survey (37%) como método de pesquisa; outra informação nem sempre clara era quanto ao objeto de estudo;

• •

  Os trabalhos sobre gerenciamento de riscos ainda são, em sua maioria, teóricos (acadêmicos – 85%), tendo em 44% objetivos exploratórios, em 41% descritivos e, em apenas 15%, explicativos, o que corrobora críticas referentes ao fato de que embora algumas técnicas e práticas sobre gerenciamento de riscos tenham sido propostas na literatura, a aplicação e os seus resultados ainda são pouco explorados;

• •

  O autor mais citado nas pesquisas (Boehm), avaliado por meio da análise bibliométrica, pode ser considerado um autor clássico sobre o tema gerenciamento de riscos em projetos de software, sendo inclusive autor de uma das abordagens mais antigas, o modelo em espiral, apresentado no Quadro 1.

Com relação às tendências da literatura avaliada, verifica-se que os estudos estão mais focados na identificação de fatores de riscos (52%), tema recorrente. Entretanto, percebe-se uma preocupação dos autores em colocar, como requisitos a serem considerados, a dinâmica do ambiente de desenvolvimento de software, que pode tornar rapidamente obsoletos trabalhos nessa área, e a cultura do país onde foram realizados os estudos, o que permite a condução de novos estudos sobre essa temática. A escassez de pesquisas referente ao tema em determinados periódicos que concentram pesquisas relacionadas a micro e pequenas empresas também sugere a condução de estudos nessa área. Outro fator motivador para novas pesquisas em micro e pequenas empresas de base tecnológica incubadas é que, em sua maioria, os objetos de estudo se referiam a grandes empresas ou projetos do setor público e privado, sendo que em nenhum dos trabalhos avaliados houve referência a empresas incubadas. Identificar e classificar riscos em uma empresa incubada pode representar um avanço em seu processo de gerenciamento, permitindo que novas pesquisas possam contribuir para que os gestores dessas empresas possam avaliar quais atividades necessitam de maior atenção com relação aos seus riscos e quais decisões tomar caso a situação detectada venha a ocorrer.

Agradecimentos

A CAPES e à FAPEMIG pelos financiamentos que possibilitaram esta pesquisa.

• Suporte financeiro: CAPES e Fapemig.

Referências

• Addison, T. (2003). E-commerce project development risks: evidence from a Delphi survey. International Journal of Information Management, 23(1), 25-40. http://dx.doi.org/10.1016/S0268-4012(02)00066-X
  » http://dx.doi.org/10.1016/S0268-4012(02)00066-X
• Associação para Promoção da Excelência do Software Brasileiro – SOFTEX. (2006). Melhoria de processo do software brasileiro, versão 1.1. Brasília: Softex. Recuperado em 19 de setembro de 2009, de www.softex.br
• Baccarini, D., Salm, G., & Love, P. E. D. (2004). Management of risks in information technology projects. Industrial Management & Data Systems, 104(4), 286-295. http://dx.doi.org/10.1108/02635570410530702
  » http://dx.doi.org/10.1108/02635570410530702
• Bannerman, P. L. (2008). Risk and risk management in software projects: a reassessment. Journal of Systems and Software, 81(12), 2118-2133. http://dx.doi.org/10.1016/j.jss.2008.03.059
  » http://dx.doi.org/10.1016/j.jss.2008.03.059
• Barki, H., Rivard, S., & Talbot, J. (1993). Toward an assessment of software development risk. Journal of Management Information Systems, 10(2), 203-225. http://dx.doi.org/10.1080/07421222.1993.11518006
  » http://dx.doi.org/10.1080/07421222.1993.11518006
• Barki, H., Rivard, S., & Talbot, J. (2001). An integrative contingency model of software project risk management. Journal of Management Information Systems, 17(4), 37-69.
• Barros, M. O., Werner, C. M. L., & Travassos, G. H. (2004). Supporting risks in software project management. Journal of Systems and Software, 70(1-2), 21-35. http://dx.doi.org/10.1016/S0164-1212(02)00155-3
  » http://dx.doi.org/10.1016/S0164-1212(02)00155-3
• Bertrand, J. W. M., & Fransoo, J. C. (2002). Modeling and simulation: operations management research methodologies using quantitative modeling. International Journal of Operations & Production Management, 22(2), 241-264. http://dx.doi.org/10.1108/01443570210414338
  » http://dx.doi.org/10.1108/01443570210414338
• Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61-72. http://dx.doi.org/10.1109/2.59
  » http://dx.doi.org/10.1109/2.59
• Boehm, B. W. (1991). Software risk management: principles and practices. IEEE Software, 8(1), 32-41. http://dx.doi.org/10.1109/52.62930
  » http://dx.doi.org/10.1109/52.62930
• Boehm, B., & Turner, R. (2003). Using risk to balance agile and plan-driven methods. IEEE Computer, 36(6), 57-66. http://dx.doi.org/10.1109/MC.2003.1204376
  » http://dx.doi.org/10.1109/MC.2003.1204376
• Brasil. Ministério da Ciência, Tecnologia e Inovação. Secretaria de Política de Informática – SEPIN. (2002). Qualidade e Produtividade no Setor de Software Brasileiro. Brasília: Ministério da Ciência e Tecnologia. Recuperado em 13 de fevereiro de 2010, de http://www.mct.org.br
  » http://www.mct.org.br
• Bryde, D. J. (2003). Project management concepts, methods and application. International Journal of Operations & Production Management, 23(7), 775-793. http://dx.doi.org/10.1108/01443570310481559
  » http://dx.doi.org/10.1108/01443570310481559
• Bryman, A., & Bell, E. (2007). Business research methods (2 ed.). NewYork: Oxford University Press.
• Carnevalli, J. A., & Miguel, P. A. C. (2007). Revisão, análise e classificação da literatura sobre o QFD – tipos de pesquisa, dificuldades de uso e benefícios do método. Gestão & Produção, 14(3), 557-579. http://dx.doi.org/10.1590/S0104-530X2007000300011
  » http://dx.doi.org/10.1590/S0104-530X2007000300011
• Charette, R. N. (2005). Why software fails. IEEE Spectrum, 42(9), 42-49. http://dx.doi.org/10.1109/MSPEC.2005.1502528
  » http://dx.doi.org/10.1109/MSPEC.2005.1502528
• Costa, H., Barros, M. O., & Travassos, G. H. (2007). Evaluating software project portfolio risks. Journal of Systems and Software, 80(1), 16-31. http://dx.doi.org/10.1016/j.jss.2006.03.038
  » http://dx.doi.org/10.1016/j.jss.2006.03.038
• Creswell, J. W., & Plano Clark, V. L. (2007). Designing and conducting mixed methods research, California: Sage Publications.
• Cule, P., Schmidt, R., Lyytinen, K., & Keil, M. (2000). Strategies for heading off IS project failure. Information Systems Management, 17(2), 65-73. http://dx.doi.org/10.1201/1078/43191.17.2.20000301/31229.8
  » http://dx.doi.org/10.1201/1078/43191.17.2.20000301/31229.8
• Dahlstrand, A. L. (2007). Technology-based entrepreneurship and regional development: the case of Sweden. European Business Review, 19(5), 373-386. http://dx.doi.org/10.1108/09555340710818969
  » http://dx.doi.org/10.1108/09555340710818969
• Dey, P. K., & Ogunlana, S. O. (2004). Selection and application of risk management tools and techniques for Build-operate-transfer Projects. Industrial Management & Data Systems, 104(4), 334-346. http://dx.doi.org/10.1108/02635570410530748
  » http://dx.doi.org/10.1108/02635570410530748
• Dey, P. K., Kinch, J., & Ogunlana, S. O. (2007). Managing risk in software development projects: a case study. Industrial Management & Data Systems, 107(2), 284-303. http://dx.doi.org/10.1108/02635570710723859
  » http://dx.doi.org/10.1108/02635570710723859
• Du, S., Keil, M., Mathiassen, L., Shen, Y., & Tiwana, A. (2007). Attention-shaping tools, expertise, and perceived control in IT project risk assessment. Decision Support Systems, 43(1), 269-283. http://dx.doi.org/10.1016/j.dss.2006.10.002
  » http://dx.doi.org/10.1016/j.dss.2006.10.002
• Emam, K. E., & Koru, A. G. (2008). A replicated survey of IT software project failures. IEEE Software, 25(5), 84-90. http://dx.doi.org/10.1109/MS.2008.107
  » http://dx.doi.org/10.1109/MS.2008.107
• Gil, A. C. (2009). Como elaborar projetos de pesquisa (4 ed.). São Paulo: Atlas.
• Gusmão, C. M. G. (2007). Um modelo de processo de gestão de riscos para ambientes de múltiplos projetos de desenvolvimento de software (Tese de doutorado), Centro de Informática, Universidade Federal de Pernambuco, Recife.
• Han, W.-M., & Huang, S.-J. (2007). An empirical analysis of risk components and performance on software projects. Journal of Systems and Software, 80(1), 42-50. http://dx.doi.org/10.1016/j.jss.2006.04.030
  » http://dx.doi.org/10.1016/j.jss.2006.04.030
• Houston, D., Mackulak, G., & Collofello, J. (2001). Stochastic simulation of risk factor potential effects for software development risk management. Journal of Systems and Software, 59(3), 247-257. http://dx.doi.org/10.1016/S0164-1212(01)00066-8
  » http://dx.doi.org/10.1016/S0164-1212(01)00066-8
• Huang, S.-J., & Han, W.-M. (2008). Exploring the relationship between software project duration and risk exposure: A cluster analysis. Information & Management, 45(3), 175-182. http://dx.doi.org/10.1016/j.im.2008.02.001
  » http://dx.doi.org/10.1016/j.im.2008.02.001
• International Business Machines – IBM. Rational Software Corporation. (2003). Rational unified process: best practices for software development teams (Rational Software White Paper, TP026B, Rev 11/01: IBM). Cupertino, CA: Rational Software Corporation. Recuperado em 12 de setembro de 2009, de http://www.ibm.com/developerworks/rational/library
  » http://www.ibm.com/developerworks/rational/library
• International Organization for Standardization – ISO. (1999). ISO/IEC 15.504-5:1999 – Information technology - Software process assessment — Part 5: An assessment model and indicator guidance. Genebra: ISO.
• International Organization for Standardization – ISO. (2003). ISO 10.006:2003 - quality management systems - guidelines for quality management in projects. Genebra: ISO.
• International Organization for Standardization – ISO. (2009). ISO 31.000:2009 - risk management - principles and guidelines on implementation. Genebra: ISO. Recuperado em 21 setembro de 2009, de http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43170
  » http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43170
• Jiang, J. J., Klein, G., & Discenza, R. (2001). Information System Success as Impacted by Risks and Development Strategies IEEE. Transactions on Engineering Management, 48(1), 46-55. http://dx.doi.org/10.1109/17.913165
  » http://dx.doi.org/10.1109/17.913165
• Keil, M., Li, L., Mathiassen, L., & Zheng, G. (2008). The influence of checklists and roles on software practitioner risk perception and decision-making. Journal of Systems and Software, 81(6), 908-919. http://dx.doi.org/10.1016/j.jss.2007.07.035
  » http://dx.doi.org/10.1016/j.jss.2007.07.035
• Keil, M., Wallace, L., Turk, D., Dixon-Randall, G., & Nulden, U. (2000). An investigation of risk perception and risk propensity on the decision to continue a software development project. Journal of Systems and Software, 53(2), 145-157. http://dx.doi.org/10.1016/S0164-1212(00)00010-8
  » http://dx.doi.org/10.1016/S0164-1212(00)00010-8
• Kendrick, T. (2003). Identifying and managing project risk: essential tools for failure-proofing your project. New York: Amacom.
• Kerzner, H. (2006). Gestão de projetos: as melhores práticas. Porto Alegre: Bookman.
• Kliem, R. (2000). Risk management for business process reengineering projects. Information Systems Management, 17(4), 71-73. http://dx.doi.org/10.1201/1078/43193.17.4.20000901/31256.12
  » http://dx.doi.org/10.1201/1078/43193.17.4.20000901/31256.12
• Kwak, Y. H., & Stoddard, J. (2004). Project risk management: lessons learned from software development environment. Technovation, 24(11), 915-920. http://dx.doi.org/10.1016/S0166-4972(03)00033-6
  » http://dx.doi.org/10.1016/S0166-4972(03)00033-6
• Lahorgue, M. A., & Hanefeld, A. O. (2004). A localização das incubadoras tecnológicas no Brasil: reforço ou quebra da tendência histórica de concentração das infra-estruturas de ciência, tecnologia e inovação. Estudos do CEPE (UNISC), 19, 7-21.
• Leopoldino, C. B. (2004). Avaliação de riscos em desenvolvimento de software (Dissertação de mestrado). Universidade Federal do Rio Grande do Sul, Porto Alegre.
• Li, J., Conradi, R., Slyngstad, O. P. N., Torchiano, M., & Morisio, M. (2008). A state-of-the-practice survey of risk management in development with off-the-shelf software components. IEEE Transactions on Software Engineering, 34(2), 271-286. http://dx.doi.org/10.1109/TSE.2008.14
  » http://dx.doi.org/10.1109/TSE.2008.14
• Longstaff, T. A., Chittister, C., Pethia, R., & Haimes, Y. Y. (2000). Are we forgetting the risks of information technology? IEEE Computer, 33(12), 43-51. http://dx.doi.org/10.1109/2.889092
  » http://dx.doi.org/10.1109/2.889092
• Marshakova, I. V. (1981). Citation networks in information science. Scientometrics, 31(1), 13-16. http://dx.doi.org/10.1007/BF02021861
  » http://dx.doi.org/10.1007/BF02021861
• McFarlan, F. (1981). Portfolio approach to information systems. Harvard Business Review, 59(5), 142-150.
• Microsoft. (2002). Microsoft Solutions Framework: MSF Risk Management Discipline v. 1.1. Recuperado em 18 de setembro de 2009, de http://www.microsoft.com/msf
  » http://www.microsoft.com/msf
• Miguel, P. A. C. (2007). Estudo de caso na engenharia de produção: estruturação e recomendações para sua condução. Produção, v. 17, n. 1, p. 216-229. http://dx.doi.org/10.1590/S0103-65132007000100015
  » http://dx.doi.org/10.1590/S0103-65132007000100015
• Miguel, P. A. C., Fleury, A., Mello, C. H. P., Nakano, D. N., Turrioni, J. B., Ho, L. L., Martins, R. A., Pureza, V. M. M., & Morabito, R. (2009). Metodologia de pesquisa em engenharia de produção e gestão de operações. Rio de Janeiro: Elsevier.
• Murphy, A., & Ledwith, A. (2007). Project management tools and techniques in high-technology SMEs. Management Research News, 30(2), 153-166. http://dx.doi.org/10.1108/01409170710722973
  » http://dx.doi.org/10.1108/01409170710722973
• Murthi, S. (2002). Preventive risk management for software projects. IT Professional, 4(5), 9-15. http://dx.doi.org/10.1109/MITP.2002.1041172
  » http://dx.doi.org/10.1109/MITP.2002.1041172
• Na, K.-S., Simpson, J. T., Li, X., Singh, T., & Kim, K.-Y. (2007). Software development risk and project performance measurement: evidence in Korea. Journal of Systems and Software, 80(4), 596-605. http://dx.doi.org/10.1016/j.jss.2006.06.018
  » http://dx.doi.org/10.1016/j.jss.2006.06.018
• Nakatsu, R. T., & Iacovou, C. L. (2009). 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), 57-68. http://dx.doi.org/10.1016/j.im.2008.11.005
  » http://dx.doi.org/10.1016/j.im.2008.11.005
• Neves, S. M., Silva, C. E. S., Salomon, V. A. P., Silva, A. F., & Sotomonte, B. E. P. (2014). Risk management in software projects through Knowledge Management techniques: cases in Brazilian Incubated Technology-Based Firms. International Journal of Project Management, 32(1), 125-138.
• Okubo, Y. (1997). Bibliometric indicators and analysis or research systems: methods and examples. Paris: OCDE.
• Pinna, C. C. A., & Carvalho, M. M. (2008). Gestão de escopo em projetos de aplicações web. Revista Produção OnLine, v. 8, n. 1, p. 1-8. http://dx.doi.org/10.14488/1676-1901.v8i1.25
  » http://dx.doi.org/10.14488/1676-1901.v8i1.25
• Prieto-Díaz, R. (2002). A faceted approach to building ontologies. In Proceedings of the 21st International Conference on Conceptual Modeling-ER2002 (pp. 1-18). Tampere, Finland. Recuperado em 12 de setembro de 2009, de http://www.cs.uu.nl/docs/vakken/ks/0809/BulidOntologiesRPD-ER2002.pdf
  » http://www.cs.uu.nl/docs/vakken/ks/0809/BulidOntologiesRPD-ER2002.pdf
• Project Management Institute – PMI. (2008). A guide to the Project Management Body of Knowledge (PMBoK® Guide). Pennsylvania: PMI.
• Raz, T., Shenhar, A. J., & Dvir, D. (2002). Risk management, project success, and technological uncertainty. R & D Management, 32(2), 101-109. http://dx.doi.org/10.1111/1467-9310.00243
  » http://dx.doi.org/10.1111/1467-9310.00243
• Ropponen, J., & Lyytinen, K. (2000). Components of software development risk: how to address them? A project manager survey. IEEE Transactions on Software Engineering, 26(2), 98-112. http://dx.doi.org/10.1109/32.841112
  » http://dx.doi.org/10.1109/32.841112
• Rovai, R. L. (2005). Modelo para gestão de riscos em projetos: estudo de múltiplos casos (Tese de doutorado). Escola Politécnica, Universidade de São Paulo, São Paulo.
• Saarinen, T. (1996). An expanded instrument for evaluating information system success. Information & Management, 31(2), 103-118. http://dx.doi.org/10.1016/S0378-7206(96)01075-0
  » http://dx.doi.org/10.1016/S0378-7206(96)01075-0
• Sanders, R., & Kelly, D. (2008). Dealing with risk in scientific software development. IEEE Software, 25(4), 21-28. http://dx.doi.org/10.1109/MS.2008.84
  » http://dx.doi.org/10.1109/MS.2008.84
• Schmidt, R., Lyytinen, K., Keil, M., & Cule, P. (2001). Identifying software project risks: an international delphi study. Journal of Management Information Systems, 17(4), 5-36.
• Software Engineering Institute – SEI. (2006). CMMI® for development. staged representation, version 1.2, technical report (06tr008). Pittsburgh: Software Engineering Institute, Carnegie Mellon University. Recuperado em 12 de setembro de 2009, de http://www.sei.cmu.edu/reports/06tr008.pdf
  » http://www.sei.cmu.edu/reports/06tr008.pdf
• Standards Australia & Standards New Zealand. (2004). AS/NZS 4360:2004: risk management. Sydney: Standards Australia; Standards New Zealand.
• Sumner, M. (2000). Risk factors in enterprise-wide/ERP projects. Journal of Information Technology, 15(4), 317-327. http://dx.doi.org/10.1080/02683960010009079
  » http://dx.doi.org/10.1080/02683960010009079
• The Standish Group. (2000). Extreme chaos. Recuperado em 13 de julho de 2009, de www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf
• Verdon, D., & McGraw, G. (2004). Risk analysis in software design. IEEE Security and Privacy, 2(4), 79-84. http://dx.doi.org/10.1109/MSP.2004.55
  » http://dx.doi.org/10.1109/MSP.2004.55
• Wacker, J. G. (2004). A theory of formal conceptual definition: developing theory-building measurement instruments. Journal of Operations Management, 22(6), 629-650. http://dx.doi.org/10.1016/j.jom.2004.08.002
  » http://dx.doi.org/10.1016/j.jom.2004.08.002
• Wallace, L., Keil, M., & Rai, A. (2004a). Understanding software project risk: a cluster analysis. Information & Management, 42(1), 115-125. http://dx.doi.org/10.1016/j.im.2003.12.007
  » http://dx.doi.org/10.1016/j.im.2003.12.007
• Wallace, L., Keil, M., & Rai, A. (2004b). How software project risk afects project performance: an investigation of the dimensions of risk and an exploratory model. Decision Sciences, 35(2), 289-321. http://dx.doi.org/10.1111/j.00117315.2004.02059.x
  » http://dx.doi.org/10.1111/j.00117315.2004.02059.x
• White, D., & Fortune, J. (2002). Current practice in project management - an empirical study. International Journal of Project Management, 20(1), 1-11. http://dx.doi.org/10.1016/S0263-7863(00)00029-6
  » http://dx.doi.org/10.1016/S0263-7863(00)00029-6
• Yin, R. K. (2009). Case study research: design and methods (4 ed.). Thousand Oaks: Sage Publications, Inc.
• Zhou, L., Vasconcelos, A., & Nunes, M. (2008). Supporting decision making in risk management through an evidence-based information systems project risk checklist. Information Management & Computer Security, 16(2), 166-186. http://dx.doi.org/10.1108/09685220810879636
  » http://dx.doi.org/10.1108/09685220810879636

Datas de Publicação

• Publicação nesta coleção
  Oct-Dec 2016

Histórico

• Recebido
  10 Abr 2015
• Aceito
  20 Jan 2016