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.

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.

1 Introdução

Projetos de software são empreendimentos complexos em qualquer contexto e são particularmente susceptíveis a falhas (Bannerman, 2008Bannerman, P. L. (2008). Risk and risk management in software projects: a reassessment. Journal of Systems and Software, 81(12), 2118-2133.

). 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)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.

, 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, 2008Bannerman, P. L. (2008). Risk and risk management in software projects: a reassessment. Journal of Systems and Software, 81(12), 2118-2133.

).

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, 2004Kwak, Y. H., & Stoddard, J. (2004). Project risk management: lessons learned from software development environment. Technovation, 24(11), 915-920.

). 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., 2001Jiang, 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.

).

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, 2007Miguel, 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.

; Wacker, 2004Wacker, J. G. (2004). A theory of formal conceptual definition: developing theory-building measurement instruments. Journal of Operations Management, 22(6), 629-650.

). 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, 2007Carnevalli, 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.

).

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)Kendrick, T. (2003). Identifying and managing project risk: essential tools for failure-proofing your project. New York: Amacom., 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)Dahlstrand, A. L. (2007). Technology-based entrepreneurship and regional development: the case of Sweden. European Business Review, 19(5), 373-386.

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)Costa, H., Barros, M. O., & Travassos, G. H. (2007). Evaluating software project portfolio risks. Journal of Systems and Software, 80(1), 16-31.

, 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)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. 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, 2002Brasil. 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

). 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, 2002White, D., & Fortune, J. (2002). Current practice in project management - an empirical study. International Journal of Project Management, 20(1), 1-11.

; Bryde, 2003Bryde, D. J. (2003). Project management concepts, methods and application. International Journal of Operations & Production Management, 23(7), 775-793.

), mas pesquisas publicadas sobre o gerenciamento de projetos em pequenas e médias empresas ainda são incipientes (Murphy & Ledwith, 2007Murphy, A., & Ledwith, A. (2007). Project management tools and techniques in high-technology SMEs. Management Research News, 30(2), 153-166.

).

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)Bannerman, P. L. (2008). Risk and risk management in software projects: a reassessment. Journal of Systems and Software, 81(12), 2118-2133.

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., 2004aWallace, L., Keil, M., & Rai, A. (2004a). Understanding software project risk: a cluster analysis. Information & Management, 42(1), 115-125.

, 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, 2005Charette, R. N. (2005). Why software fails. IEEE Spectrum, 42(9), 42-49.

). Segundo Kerzner (2006Kerzner, H. (2006). Gestão de projetos: as melhores práticas. Porto Alegre: Bookman., 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., 1993Barki, H., Rivard, S., & Talbot, J. (1993). Toward an assessment of software development risk. Journal of Management Information Systems, 10(2), 203-225.

).

Para o PMBoK (PMI, 2008, p. 194Project Management Institute – PMI. (2008). A guide to the Project Management Body of Knowledge (PMBoK® Guide). Pennsylvania: PMI.),

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., 2004aWallace, L., Keil, M., & Rai, A. (2004a). Understanding software project risk: a cluster analysis. Information & Management, 42(1), 115-125.

) 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, 2008Huang, 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.

).

Estudo conduzido pelo The Standish Group (2000)The Standish Group. (2000). Extreme chaos. Recuperado em 13 de julho de 2009, de 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)Emam, K. E., & Koru, A. G. (2008). A replicated survey of IT software project failures. IEEE Software, 25(5), 84-90.

, 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., 2004Barros, 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.

). Mas por que projetos de softwares falham com tanta frequência?

• Para Kwak & Stoddard (2004) Kwak, Y. H., & Stoddard, J. (2004). Project risk management: lessons learned from software development environment. Technovation, 24(11), 915-920.

, falhas em projetos são resultado de uma multiplicidade de riscos inerentes em ambientes de projetos de software ;

• Segundo Charette (2005) Charette, R. N. (2005). Why software fails. IEEE Spectrum, 42(9), 42-49.

, 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 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.

);

• Para Barros et al. (2004) 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.

, 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, 2008Emam, K. E., & Koru, A. G. (2008). A replicated survey of IT software project failures. IEEE Software, 25(5), 84-90.

).

Autores como Raz et al. (2002)Raz, T., Shenhar, A. J., & Dvir, D. (2002). Risk management, project success, and technological uncertainty. R & D Management, 32(2), 101-109.

, Jiang et al. (2001)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.

, Wallace et al. (2004a)Wallace, L., Keil, M., & Rai, A. (2004a). Understanding software project risk: a cluster analysis. Information & Management, 42(1), 115-125.

consideram que os riscos podem ser gerenciados com sucesso. Segundo Saarinen (1996)Saarinen, T. (1996). An expanded instrument for evaluating information system success. Information & Management, 31(2), 103-118.

, 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)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.

, 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., 2004Baccarini, D., Salm, G., & Love, P. E. D. (2004). Management of risks in information technology projects. Industrial Management & Data Systems, 104(4), 286-295.

). No PMBoK (PMI, 2008Project Management Institute – PMI. (2008). A guide to the Project Management Body of Knowledge (PMBoK® Guide). Pennsylvania: PMI.), 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., 2004Baccarini, D., Salm, G., & Love, P. E. D. (2004). Management of risks in information technology projects. Industrial Management & Data Systems, 104(4), 286-295.

).

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., 2001Houston, 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.

), 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, 2004Dey, 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.

), 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, 2006Software 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

), elaborado pelo Software Engineering Institute (SEI), o Rational Unified Process – RUP (IBM, 2003International 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

), O Microsoft Solutions Framework – MSF (Microsoft, 2002Microsoft. (2002). Microsoft Solutions Framework: MSF Risk Management Discipline v. 1.1. Recuperado em 18 de setembro de 2009, de

), a norma AS/NZS 4360 (Standards Australia & Standards New Zealand, 2004Standards Australia & Standards New Zealand. (2004). AS/NZS 4360:2004: risk management. Sydney: Standards Australia; Standards New Zealand.), a norma ISO/IEC 15.504-5 (ISO, 1999International 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.), Boehm (1988)Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61-72.

e a abordagem segundo a ISO 10.006 (ISO, 2003International Organization for Standardization – ISO. (2003). ISO 10.006:2003 - quality management systems - guidelines for quality management in projects. Genebra: ISO.). Gusmão (2007)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. 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, 2006Associaçã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) e ISO 31.000 (ISO, 2009International 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

).

Figura 2

Distribuição das publicações por foco. Fonte: Gusmão (2007) 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. , complementado pelos autores.

Dessa forma, foi realizado um comparativo entre as principais abordagens (Neves et al., 2014Neves, 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.), 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, 2008Project Management Institute – PMI. (2008). A guide to the Project Management Body of Knowledge (PMBoK® Guide). Pennsylvania: PMI.) e acrescidas das etapas “resolver riscos”, “comunicar riscos” e “aprender” parte integrante de outras abordagens (Microsoft, 2002Microsoft. (2002). Microsoft Solutions Framework: MSF Risk Management Discipline v. 1.1. Recuperado em 18 de setembro de 2009, de

; Standards Australia & Standards New Zealand, 2004Standards Australia & Standards New Zealand. (2004). AS/NZS 4360:2004: risk management. Sydney: Standards Australia; Standards New Zealand.).

Thumbnail Quadro 1

Comparativo abordagens de gerenciamento de riscos em projetos de software.

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, 2008Project Management Institute – PMI. (2008). A guide to the Project Management Body of Knowledge (PMBoK® Guide). Pennsylvania: PMI.) e CMMI (SEI, 2006Software 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

), 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.

Thumbnail Quadro 2

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

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.

Thumbnail Quadro 3

Pesquisas sobre gerenciamento de riscos em projetos de software.

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.

Thumbnail Quadro 4

Classificação das pesquisas.

Os principais resultados abrangem, além dos resumos apresentados no Quadro 3, os trabalhos publicados por Wallace et al. (2004b)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.

, Li et al. (2008)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.

, Verdon & McGraw (2004)Verdon, D., & McGraw, G. (2004). Risk analysis in software design. IEEE Security and Privacy, 2(4), 79-84.

, Barki et al. (2001)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., Zhou et al. (2008)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.

, Sanders & Kelly (2008)Sanders, R., & Kelly, D. (2008). Dealing with risk in scientific software development. IEEE Software, 25(4), 21-28.

, Keil et al. (2000)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.

e Kwak & Stoddard (2004)Kwak, Y. H., & Stoddard, J. (2004). Project risk management: lessons learned from software development environment. Technovation, 24(11), 915-920.

.

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)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

, 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, 1981McFarlan, F. (1981). Portfolio approach to information systems. Harvard Business Review, 59(5), 142-150.; Boehm, 1991Boehm, B. W. (1991). Software risk management: principles and practices. IEEE Software, 8(1), 32-41.

; Barki et al., 1993Barki, H., Rivard, S., & Talbot, J. (1993). Toward an assessment of software development risk. Journal of Management Information Systems, 10(2), 203-225.

; Sumner, 2000Sumner, M. (2000). Risk factors in enterprise-wide/ERP projects. Journal of Information Technology, 15(4), 317-327.

; Longstaff et al., 2000Longstaff, T. A., Chittister, C., Pethia, R., & Haimes, Y. Y. (2000). Are we forgetting the risks of information technology? IEEE Computer, 33(12), 43-51.

; Cule et al., 2000Cule, P., Schmidt, R., Lyytinen, K., & Keil, M. (2000). Strategies for heading off IS project failure. Information Systems Management, 17(2), 65-73.

; Kliem, 2000Kliem, R. (2000). Risk management for business process reengineering projects. Information Systems Management, 17(4), 71-73.

; Schmidt et al., 2001Schmidt, 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.; Houston et al., 2001Houston, 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.

; Murthi, 2002Murthi, S. (2002). Preventive risk management for software projects. IT Professional, 4(5), 9-15.

; Addison, 2003Addison, T. (2003). E-commerce project development risks: evidence from a Delphi survey. International Journal of Information Management, 23(1), 25-40.

; Wallace et al., 2004aWallace, L., Keil, M., & Rai, A. (2004a). Understanding software project risk: a cluster analysis. Information & Management, 42(1), 115-125.

; Charette, 2005Charette, R. N. (2005). Why software fails. IEEE Spectrum, 42(9), 42-49.

; Han & Huang, 2007Han, 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.

; Keil et al., 2008Keil, 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.

; Bannerman, 2008Bannerman, P. L. (2008). Risk and risk management in software projects: a reassessment. Journal of Systems and Software, 81(12), 2118-2133.

). Nesse sentido, Schmidt et al. (2001, p. 7)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. 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., 2004aWallace, L., Keil, M., & Rai, A. (2004a). Understanding software project risk: a cluster analysis. Information & Management, 42(1), 115-125.

). 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, 2007Han, 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.

). Segundo Keil et al. (2008)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.

, 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)Murthi, S. (2002). Preventive risk management for software projects. IT Professional, 4(5), 9-15.

, 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)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., 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, 1997Okubo, Y. (1997). Bibliometric indicators and analysis or research systems: methods and examples. Paris: OCDE.). 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)Marshakova, I. V. (1981). Citation networks in information science. Scientometrics, 31(1), 13-16.

, 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.

Thumbnail Quadro 5

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

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, 2004Leopoldino, C. B. (2004). Avaliação de riscos em desenvolvimento de software (Dissertação de mestrado). Universidade Federal do Rio Grande do Sul, Porto Alegre.) e, principalmente, Engenharia de Sistemas e Computação (Gusmão, 2007Gusmã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.).

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.