Gest5o do Risco e Qualidade

no

Desenvolvimento de Software

Ant6nio Soares comes Miguel

antonio.miuel@mail.telepac.pt

gestAo do risco e, em dltima inst&ncia da qualidade dosoftware desenvolvido.

A qualidade, como 6 discutida por Juran, apresenta umsignificado duplo: caractensticas do produto satisfazendoas necessidades do utilizador e isenAo de defici8ncias[Juran 19891. Desenvolver o produto certo, do modocerto, conscituem factores necessarios e compZementares,no sentido da satisfao do cliente. Satisfazer asexig8ncias do prazo de disponibiliza5o (me-tomarket), revela-se igualmente importance para a satisfa80do cliente/utilizador e critico para a sobrevivBncia daorganizao.

No entanto, no domfnio dos projectos de desenvolvimentode software, o panorama mio 6 animador. De acordo comas conclus6es de um estudo conduzido nos EUA, em1995, pelo Standish Group [Standish Group International19961, 3J,I% dos novos projectos de Sistemas deInforma5o foram cancelados antes do sen t6rmino,acarretando custos calculados em cerca de 81 mil milh6esde d6lares. Para al6m disso, 52,7% dos projectoscompletados, custaram J89%, das estimativas originais,com custos adicionais de cerca de 59 mil milh6es ded6lares para as organiza6es. 0 custo das oportunidadesperdidas mio sdo mensurdveis, mas poderiam serfacilmente de triJi5es de d6lares [Standish GroupInternational J996].

A literatura cientifica mostra que estes casos nAoconstituem incidentes isolados, antes ocorrem comaJannante frequ8ncia em organiza6es de todos os tipos edimens6es [Keil and Montealegre 20001 [Lyytinen et al.J998] [Walkerden and Jeffrey 19971 [King 19971[Anthes, 19961 [Keil et al. 19951 [Ewusi-Mensah andPrzasnyski 1995} [Ewusi-Mensah and Przasnyski 1994][Ellis 19942 [Gibbs 19942 [Kinde2 19922 [McPart2in 19922[Betts 19921 [Mehler 19911 [Kull 19861, tornando assimevidente que tais casos constituem um problema de toda ainddstria, apesar dos significativos progressos realizadosem metodologias e ferramentas de desenvolvimento. aolongo dos dltimos 20 anos.

Resumo: Esta comunicaAo discute o papel daBeso do risco e da qualidade em projectos dedesenvolvimento de software. Discute, especificamente, aimport&ncia da gest&o do risco na satisfao dosobjectivos de qualidade no desenvolvimento do produtoadequado, num momento em que o mercado exige temposde desenvolvimento cada vez mais curtos.

S-ao apresentados os elementos de umametodologia de Gestiio Integrada do Risco, incluindo osprocessos centrals de identifica2o, avaliaAo,pZaneamento, monitorizao e controlo, bem como a suaintegrao na geso de projectos. Esta metodologia foidesenvolvida no bito da tese de doutoramento emSistemas de InformaAo, em que o autor Se encontraenvolvido.

PaIavms Chavez Gestiio do risco, projectos dedesenvolvimento de software, equipas, qualidade.

lutrodooNo ambiente econ6mico actual, a corrida pela qualidade 6a corrida pela sobreviv&ncia, tendo a marca da qualidadeemergido como uma vantagem competitiva para o sucessodas organiza96es.

Para complicar os desafios da competiBo, a rapidez damudana do pr6prio ambiance econ6mico 6 cada vez maisaceJerada. Esta acelera98o da mudana resultou nuxn'time-to-market" mais curto [Vesey 1992} [Akao 1990) eexige um e5tilO de gestdo cada vez mais preventivo nossens processos de deciso.

Reconhecer a incerteza, antecipar as potenciaisconsequncias adversas e iniciar prances de Besoproactive conduz a menos problemas, menos crises emats sucesso, ao longo do ciclo de Vida dodesenvolvimento de software~ Esta caracteristicapreventiva constitui um elemento chave de uma eficaz

QuaTIC'2001 / 155

Os recursos despendidos deste modo uilo apresentamqualquer retomo, a n5o ser que Os projectos possam serrecuperados, completados ou, de qualquer outro modo,terrmnados, no podendo os sistemas inforn::ldticoscontribuir para o desempenho das organizaJes, se agoforem disponibilizados ou utilizados em tempo d61[Markus and Keil I994].

A constantBo de que a maioria das causes dosdeslizamentos dos projectos de software, em termos deprazos e custos, est relacionada com a sua BestAo,conduziu a uma intensa pesquisa no Ambito das ac6es deBesto rnais adequadas para a resoluAo deste problema[Ropponen 1999} [Baccarini 19991 [Griffiths andNewman 1996} [Karolak 1996} [Ewusi-Mensah andPrzanyski 1995} [Keil 1995} [Charette 2989} [vanGenuchten 1988}[March and Shapira 1987}.

Tern vindo assim a ganhar corpo, nos meios cientificos,empresariais e governamentais, a noo de que a unicaforma de obviar ou, pelo menos, minimizer estassitua95es dramdticas d instituir e implementer uma gestSodo risco proactiva, entrosada com a Beso de projectos, semelhanga do que Vern acontecendo, desde ha muitotempo, em outras areas do conhecimento, como aengenharia civil [Coho and Cruz 1998) [Curtis et al. 1991}[Hayes et al 19861, a engenharia financeira [Scoy 1992}[Kaplan and Garrick 1981} [Denenberg et al. 1974], aengenharia aerondutica [Rosenberg et al. 1999} [Franklin1996} e a industria da defesa [Defense SystemsManagement College 2000} [Neitzel 19991 [USA AirForce 19881.

A gest5o do risco fornece um veto de atingir Os trobjectivos principais do desenvolvimento: construir oproduto "certo", do modo "certo" e entrega-lo no tempo"certo" e constitui, fundamentalmente, um processo dedecis&o informada, que envolve a antecipaAo conscientedaquilo que pode correr mal, a avalia9Ao dos perdaspotenciais (severidade do impacto) e a incorpora50 destaperspectiva roais abrangente nas varias lases dos projectosde desenvolvimento de software: planeamento, gesmo dasactividades e processo de decisAo.

A presente comunica50 apresenta uma metodologia deGestilo Integrada do Risco de projectos dedesenvolvimento de software, desenvolvida no kmbito detuna teses de doutoramento em sistemas de informs50, emostra a sum coer8ncia com os princfpios da qualidade.

A Gest5o do II;iiisco de Projectos de SoftwareNo Corao da gestijo do risco encontra-se a tomada dedecis6es informadas, em tempo oportuno, atrav6s daavalia5o consciente de tudo aquilo pode correr mal(riscos), hem como da probabilidade e severidade dorespectivo impacto.

As tornadas de decis2o, suportadas por uma informa5ocorrecta, envolvem a avaliaAo das estratdgias e pollticas

de mi6gaVo dos riscos, em termos dos sens custos ebeneffcios, hem como a avalia95o do impacto dosdecis6es actuais nas opV5es futures [Scoy 19921.

Se os projectos de desenvolvimento de softwarecontinuam a softer grandes deslizamentos nos custos enos prazos e a apresentar seriOs problemas dedesempenho e de qualidade, isto resulta, regra geral, dofacto de nAo se lidar adequadamente com a incerteza e orisco inerentes a esta actividade. Um obsuiculo Chane 6 aincapacidade de encarar Os problemas de deslizamentodos prazos e custos como sintomas de um problema maisfundamental, a eles subjacente: o o reconhecimento daexist6ncia de riscos e a consequente nAo tornado demedidas mitigadoras, em tempo oportuno.

O risco faz parte de qualquer actividade hurnana, miiopodendc nunca ser eliminado. O risco, em Si, no 6 man;o risco 6 essencial ao progresso e o insucesso muitasvezes, uma componente Chane da aprendizagem. Noentanto, devemos aprender a balancear as possiveisconsequ8Reins negatives do risco, com os beneffciospotenciais da respectiva oportunidade associada [Scoy,1992].

Teer?egia_

Hardwar Seftwar

| SISTEMA I/

Pesseas Praze

Custe

Figural I - Riscos num contexto do desenvolvimentode sistemas inforrruificos

O insucesso na gest5o dos riscos dos projectos torna asempresas menos produrivas e competitivas, devido moscompromissos desnecessdn"os Que se t8m de efectuar naquail;/e, nos prazos e nas funcionalidades - e tudo issocom custos adicionais [Higuera and Naives I996].

A produtividade e a qualidade dos projectos dedesenvolvimento de software o influenciadas pormdltiplos factores, podendo varier de projecto para

156 / QuaTIC2001

projecto, dentro da mesma organiza5o e mesmo dentrodas vas fases do ciclo de Vida de um mesmo projecto[Burdick et al. 19981.

O motivo para esta varia6es na qualidade e naprodutividade, 6 que elas so afectadas por muitos ediferentes factores (ver Figura 2). Muitos desses factoress50 directamente influenciados por decis6es de gesmo(por exemplo, poRticas de recrutamento e de adoAo demetodologias), embora muitas vezes de mdltiplas formasdificilmente rastreaveis.

AmtIiSar: transformer os dados dos riscos eminforrna9Ao dtil para o processo de decis&o.

Planear: traduzir a informa5o sobre os riscosem decis6es e ac5es (quer actuals, quer futures)e implementer essas acJes.

Momtorizar: monitorizar os indicadores de riscoe Os riscos conhecidos.

CODtFOWr; cortigir OS desvios as acJesplaneadas.

prcs$5O 8 Comunicar: fornecer informa20, interna edos pmzos externa, de "feedback" e �feedforward", para o

| projecto, sobre as actividades de gesnio dosCostde I ~ Qualidade dz infomn riscoS, SO

\ I / ontLmia de ou(:IaS equipas emergenuTmbalho fom ,

Moral da epa tn

'lf CIal- e estabilidade >'1Ir".. das especifzcaJes

. - pencia

tabllzeal .lfl|alzdade das zmtslas Alt I _ s t,tocesso

o, V

Flgura 2- uQuahdadeen

No 5mbito da disserta80 de doutoramento em Que o autorest comprometido, lot desenvo2nido um Mode2o deGeso Integrada do Risco, Que tern como objectivo Figttta 3 - Modelo da Gesdo Integrada do mscofornecer uma estrutura holistica de gasn1o do risco em -projectos de desenvolvimento de software, estruturada,eficaz e perfeitamence enquave2 Ra Besnio clsica de O modelo refzresentado na figura como um "loop", paraprojectos. reflectir o facto de Que a Beso do risco deve constituir

Esse modelo, mostrado graficamente na Figura 3, e mVi amenCe aPresenta muitos Paralelos com Os trs Processos riscos� emer2em de folma igua)mente dimimica. Uma"universals" de Juran Para a gestAo da qualidade: gesnlo eflc dos riscos exig uma vigilancia cons(ante,Planeamento da qualidade, controlo da qualidade e o resfleitante k satisfaVgo do cliente/utilizador e melhoria da qualidade [Juran 19891' Uma estrat6gia muta do ambiente [Sco 19921.concorrente da gestdo da qualidade e da gastilo do risco, ` -fomece os alicerces e uma estrutura abrangentes para o Pol outro lado, a fun50 comnnicur, coma graficarnentesucesso dos projectos de desenvolvimento de software. refzresentada na Figure 3, existe ao longo de todo o

O modelo proposta par a Oes Integrada do Risco u uieso loans "Wdaqu asasIntegra as segulntes funoes, ou fases liga e tolna eficazes.

Idenflficar: Pesquisar e.localizer Os factores de A Gos(go Integrada do Risco dos projectos derisco, antes Que estes se tomem Problemas e desenvolvimento de software assenta em trgs pilaresafectem o Projecto, de forma adversa' fundamentals (ver Figura 4), Que constituem os sous

alicerces:

's

QuaTIC 2001 / 157

Avaliar. Os riscos devem ser identificados eavaliados enquanto ainda 1:ui tempo de tomarmedidas mitigadoras, ou mesmo de Os eliminar~Isto implies olhar para o fnturo e considerer ocaminho Que foi escolhido, Burns perspective dorisco.

- CommdcaF. Devemos aceitar que os riscosexistem e devemos comunica-los a quern tern acapacidade de Os resolver.

Resolver. Devemos agir, de forma consciente,face aos riscos. Ism signifies transformar urnrisco numa oportunidade de melhorar aspossibilidades de sucesso.

Figura 4 - Os trs pilares da Gestilo Integrada dosco

Urna gest&o eficaz dos riscos deve possibilitar urnsharmoniosa interacV&o das varias funJes deidentificao, avaliaAo, mitigaAo e controlo, para Blewde permitir um sistema de aviso antecipado dos riscosnovos que v5o sendo detectados como fruto do processode geso (ver Figura 5).

Conceito de EquipaUm factor que desempenha um papel chave no sucesso dodesenvolvimento de software e na qualidade, d o conceitode equipa. Varias termos m sido utilizados paradescrever este processo de trabalhar em colectivo comobjectivos comuns, como a .�engenharia concorrente", Queenvolve a integra5o do desenho do sistema e do processo[Winner et al. 19881.

Este conceito de equipa constitui igualmente umaestratdgia vital para o atingimento dos objectivos deentrega do produto no tempo oportuno (`time"tomarketdeliv ') e constitui um elemento chane na gesto dorisco.

A caracteristica "equips" da qualidade evidence naabordagem de Deming, no Ponto 4 dos sens 14 Pontospara a Geso, o qua! diz especificamente:

"4" Termine com a pratica de adjudicao de neg6cios,com base no preo. Em vez disso, minimize o custototal. Escolha um fornecedor l:mico para qualquer itemisolado, on estabela uma reino duradoira delealdade e confiana." [Deming 1982)

Juran encara a rela5o de trabalho em equips, entrefomecedor e cliente, como urns relao continua eplaneada, em Que ambas as partes �trabalhamconjuntamente como se pertencessern il mesmacompanhia" [Juran, 1988]. Este trabalho em equipa ebaseado em:

e con&ana mdcua

e planeamento conjunto

e visitas mutuns

e ansEncia de segredos

--u Ao longo das fundsJes e da implementa8o das|| prdticas da qualidade, o conceito de trabalho em|| equipa e essencial para uma perce&o e Beso|| eficazes da qualidade, nos ambientes empresariais.

|| Quando aplicada ao desenvolvimento de softvare,|| uma organizSo orientada-para-a-equips preocupa-|| se, mio apenas os objectivos de prazos, custos eu desempenho de urn projecto, atravs de aspectos de|| geso tdcnica e programdtica, mas igualmente com

as quest5es de comunica50 e relaJes interpessoais[Kesbom et al. 1989)" A comunicaV5o que caracteriza

estas relas interpessoais constitui um elemento chavena implementso da equips de geso do risco, numa

Figura 5 - FunJes da geso do risco funcionando organiza80 e entre organiza5es, hem como na rela20harrnoniosarnente entre contratante contratado ou contratado-subcontratado.

Este aspecto da comumca5o tern-se tornadoprogressivamente mats importance no contexto actual deglobalizko, em que se recorre cada vez com mais

frequ8ncia frequente, quer a solo6es tipo "applicationpackage" adquiridas a empresas transnacionais, quer aempresas de consultoria para efectuarem odesenvolvimento e integraAo de sistemas informticoscomplexos. Isto tern conduzido a situa6es complexas decontratos com rndltiplos fornecedores e aodesenvolvimento de projectos por equipas Que, muitasnezes, Se encontram dispersas por localiza6esgeogrdficas distintas e, por vezes, muito distantes.

Neste contexto, d fundamental Que a gestilo do risco dosprojectos seja efectuada por uma equips conjuntacZiente/fomecedor(es). Este conceito de equips de Best5odo risco constitui urns extensAo do conceito de equips detrabalho da qualidade, de modo a incluir, n5o apenas aqualidade dos produtos ou servios, mas igualmente agestiio do pr6prio processo de desenvolvimento dosistema informdtico e dos factores de risco a e2e inerentes.

Especificamente, a implementa5o da equips de gesnio dorisco, entre cliente e fornecedor(es)2 ou entre contratado esubcontratado, a spitesAo do conceito de trabalho emequips nas Feta6es comprador-fornecedor, para a gestiiodas incertezas (riscos) no processo de desenvolvimento doproduto~

O conceito de equips de goso do risco constitui urnsamIgama de mdtodos de gesto, metodos da qualidade econceitos de gest5o participativa (orientados para equipas)[Higuera and Gluch 1993].

A Gest5o do Risen em EquipsUma abordagem integrada de equips, alicerada emcomunicaJes eficazes, e um dos mais importantesaspectos da gesto integrada do risco. A comunicaq&ofacilita a dinica e a sinergia Que caracteriza a gestAoeficaz do risco e results numa introvis5o colectiva e numaeficdcia global substancialmente maior que a soma dascontribuiJes separadas de cada individuo [Dorofee1993].

O Modelo de GestAo Integrada do Risco funda-se nosnone princfpios assinalados na Figura 6.

Figura 6 - Princi"pios da gesl:ilo do Risco

Colectivamente, os principios acima identificados formama base para os processos, metodos e ferramentas Que c[iiocorpo a geso do risco em equipa. Os m6todos eferramentas da gostAo do risco em equips maiscomummente preconizados e utilizados [Dorofee 1993}[SEI 1992} [FitzGeraldl eso indicados na Figura 7, emQue Se definem Os mais aplicveis para cads uma dasfunJes da Gestiio Integrada do Risco.

Cada um dos none princfpios atr enunciados, d descritode seguida, com mais detalhe.

Vis5o Partilllada

A Geso do Risco em equips deve slicerar-se numavisilo partilhada, Que abranja todos os aspectos doprojecto de desenvolvimento e no desejo de atingir, comsucesso, essa vis5o, atraves dos esforOs colectivos daequipa.

Esta visRo deve ser partilhada por todos os membros daequips e exige urns compree,ns5o comum da natureza edos resultados do projecto. E baseada nos conceitos deequipa [Katzenbach and Smith 19938} [Deming 1982]:

* pFop6sitO comum,2 - O concerto de relao cliente-fornecedor aplica-se emduas situaJes: (1) no caso de um desenvolvimentointerno pela equips de 5.1. da organizao, esta serd ofornecedor do software aplicacional e o utilizador finalserd o cliente. (2) no caso de um contrato da organizaocom uma empress extema, esta serd o fornecedor e aquelao cliente. Em qualquer das duas situa6es, a gest5o dorisco devem erectuada por urns equips mista.

QuaTIC'2OOI / 159

Figura 7 - M6todos e ferramentas da GestoIntegrada do Risco em equipa

. senso de responsabilidade colectiva,fundamentais para a gest8o do risco em equipa.

* compromisso colectivo

e numa relaAo de trabalho interpessoal cooperativa,caracterizada pela partilha mdtua e individual daresponsabilidade.

Embora a natureza especifica da personalidade e dosobjectivos de cada membro individual da equipa possamvarier, colectivamente codas os membros da equipadevem partilhar o mesmo interesse no sucesso dosresultados do projecto.

Esta vis&o partilhada deve ser {armada com base emacordos contratuais e assenter nurna compreeno mdtuadas necessidades do cliente/utilizador. Acima de tudo,esta visBo deve constituir a evid8ncia de uma consninciade prop6sitos comum, no sentido de Deming [Deming1982], e de urns compromisso colectivo para com asucesso mdtuo do projecto de desenvolvimento.

Vis5o de FuWroA geso do risco exige a gesmo da incerteza queincorpore uma pesquisa activa e um controlo eficaz dasincertezas e do respectivo potencial de perdas [Charette19902 [Rowe 1988]. O pensamento no amanidentificando incertezas e antecipando potenciaisresultados, hem como a geso dos recursos e actividadesdo projecto, tendo em atenV5o essas incertezas, o

a e eficaz constitui o ndcleo daGest&o Integrada do Risco e inclui discuss5es em grupo,trocas de informao "ad hoc", em pequenos grupos cuindividualmente, hem coma processes e ferramentasformats de dissemina8o da informaAo.Devem existirmecanismos formats de relato dos riscos para a gesnio edesta para o pessoal do projecto. Tades as f6runs paraidentifica&o, resoluo e Beso dos riscos deverAoenvolver um livre fluxo de informs80. A comunicaodove ser cultivada dentro das etapas Chane de decio daequipa de gest&o do risco, atraves de processes de tornadade decisAo baseados no consenso.

Valoriza!;;5o da ?creepo IndividualUm principio Chane do conceito de Geso do Integradado Risco em equipa 6 Que 6 vital valorizar e encorajar ascontribui6es individuals, para se obter uma interac3oeficaz Que promova a sinergia resultante das percepJescolectivas e das mtiItiRIas vis6es de cada membro daequips [Dorofee 1993}. E a voz individual Que pode trazero conhecimento, a introvis2o e a perspectiva dnicos para aidentificaiio e geso dos riscos.

Fundamentalmente, o processo da geso do risco emequips deve valorizar a percepAo individual e encorajaras individuos, a todos os niveis do projecto, acontribuirem para todas as etapas do processo. Enquantoparte do processo de geso do risco, centrado na

160 / QuaTIC'2OOI

comunica20, 6 a perspectiva de cada individuo quefomece o conhecimento e a introvis8o accessOs parareconhecer Os problernas e riscos potenciais para oprojecto, e a capacidade para suportar os esforosdestinados a lidar eficazmente com esses riscos.

Perspectiva SismicaEmbora o loco da gesto do risco se centre, muitas vezes,nas eas t6cnicas do software, fundamental possuir umaperspectiva global do projecto enquanto esforVo integradonum sistema organizacional.

Dentro da equipa, a avaliao dos riscos e respectivasdecies de gesnlo devem ser optirnizadas com base numconceito alargado de sistema, ao longo de todo oprograma de desenvolvimento da organiza5o, em vez deSe centrarem na perspectiva isolada dos riscos tnicos dosoftware.

Esta perspectiva inclui, n5o apenas as quest5esfundamentais relativas il necessidades docliente/utilizador, mas tambm as quest6es t6cnicas, deprazos, de custos, de desempenho, de qualidade e outrasrelacionadas com o esforo de desenvolvimento[Chittister and Halves 19931.

Integra50 ma Gestdo do ProjectoUm dos elementos cruciais do Modelo da GesnioIntegrada do Risco, e o princ!pio de que a Beso do riscodeve constituir uma parte integrante e vital da gestSo doprojecto. A geso de projectos pode ser consideradacomo um conjunto de actividades integradas deplaneamento, controlo, organiza50 e direc80 [ PMEOK19961, orientadas para equipas, como pode se encontrarepresentado na Figura 8.

A gest5o do risco n&o pode ser vista como um ap8ndicedas actividades de rotina da geso do projecto. Esteconceito ilustrado na Figura 9. em Que o modelobasico de gestgo do risco se encontra embebido noconjunto de processos e mtodos utilizados para agesl[ilo do projecto, os quais se integram nas funsprilnarias da gestdo de projectos organi planear,dirigir e controlar (Charette 19891.

Especificamente, a gestiio do risco providencia, n8oapenas processos sisternaticos e despersonalizadospara gerir o risco, mas igualmente processos emetodos associados que Se integram perfeitarnentenas prdticas estabelecidas para a gestdo do projecto.

Figura 9 -Integra8o da GestAo do Risco na Gestode Projectos

Proactividade das Estratkgias0 caracter proactivo da antecipa8o, planeamento eexecu8o das actividades do projecto, constitui a marcacaracteristica do Modelo de Geso Integrada do Risco, aqual culmina, em ti1tima instAncia, em tornadas dedecisBo. A gest5o do risco fomece os fundamentos paraum processo de decis5o informado, atrav6s de tunaavalia2o consciente das incertezas, das perdas potenciais

QuaTIC'2001 / 161

e das oportunidades proporcionadas pelo facto de Se exemplo, ao implementar a monitorizaVAo e o controloanteciparem (em vez de apenas se reagir a) Os bicos dos riscos, as organizaJes podem empregar Os

sens mtodos habituais de monitorizaAo e controlo deproblemas,

XI? XYlT 0 D O HP O XE S S O XO NT Y O E G E S T p0 D O P IS XO efectuandoalgumas

modificaJesde modo aincluir a

informaq5odos riscos nos

formulariOse/ou

ferramentas desoftware

existentes.

Figura 10 - Processo da Cest&o do Risco em Equipa

acontecimentos [Dowd 1998]. Os m6todos de geso dorisco propostos.. personificam esta abordagem proactivaao incorporarem a consciencia das perdas potenciais,directamente nos processos de decis2o do pr6prioprojecto.

Metodologia Sisll:erxl;iSca e AdaptdvexUm elemento Chane da Gesto Integrada do Risco, 6 aadopVo de uma abordagem sistematica e adapt5nel ainfraestrutura e it cultura do projecto e da organiza5o. Aestrutura dos processos, metodos e ferramentas 6 modulare constituida por unidades de processo fundamentals.Cada modulo do processo 6 adapnineS as especificidadesde qualquer organiza50: suas prticas, dimensSo,dominio aplicacional e prazo do projecto.

Embora propondo m6todos e ferramentas abrangentes Quepodem coexistir com as praticas estabelecidas, a estruturabdsica do modelo e Os respectivos m6todos associadosforam desenhados para se adaptarem as prcas, m6todose ferramentas utilizadas por qualquer projecto. Por

Reguladdade e Continnidade dos ProcessosUma geo eflcaz do risco exige uma vigilAncia continuae, como ilustrado na Figura 7, a equip& de geso dorisco dcne adopter este conceito sob a forma de umprocesso continuo, caracterizado pelas actividadesregulates de identificao e gestAo Que 520 evidentes aolongo do ciclo de Vida do projecto.

Na pr;itica da gesuio do risco, estes principios soexemplificados ao longo de codas as actividades do

` projecto. For exemplo, os riscos scmo itens da agenda dasreuni6es regulates da equipa de projecto, as discuss5essobre riscos ocorrer regularmente e, ii medida Que monosriscos emergem, ou os riscos actuajis madam, os pianos eacJes o modificados. sendo as decis5es baseadasnestes riscos novos, ou alterados.

A Prdtica da GestSo Integrada do RiscoEste capitulo discute a aplica5o do processo da gest5o dorisco, em equipa, como d mostrada na Figura 10 no casode um projecto de desenvolvimento de softwareaplicacional adjudicado a um fomecedor especializado,que actua como �prime contractor".

162 / QuaTIC2001

AvalLal In clal d o s P taco s

Figura II - Passos da avaliaV5o inicial dos riscos

Os passos iniciais do processo ennolvem oestabelecimento de um conjunto inicial de riscos para oprojecto. Cada um dos parceiros envolvidos (cliente efomecedor) realiza urna analia50 inicial dos riscos, paradefinir os riscos associados com as respectivasorganizaJes.

AcNvidades de AvaBao Inicial dos RiscosOs passos Chane envolvidos numa avalia&o inicial dosriscos so mostrados na Figura 11. Estas actividades deavalia20 devem ser levadas acabo por uma equipa deavalia2o treinada ou, se no fiver a adequada preparao,deve ser orientada por um consulter em gest&o do risco.

O primeiro passo numa avalia5o inicial dos riscos, 6 arealizaVo de uma Fannio de orientaVo dos participantes,liderada pelo Chere de projecto, destinada a fomecer urnavis2o global do processo a todos os participantes e aprepar:i-los para Os respectivos papis no processo.

O passo seguinte a realizaq2o de mtiltiplas sess6es degrupo, para a avalia5o dos riscos. Para esse efeito deve

utilizar"se um questioruirio taxin6mico3 de riscos. Astrocas Que ocorrem Rastus 5e55665 providenciam uma basepara uma comunicaBo adicional, fora do 5mbito dassess6es. Em grandes projectos, este f6rum constitui,muitas vezes, a primeira oportunidade para oestabelecimento de contactos entre muitos dosparticipantes, apesar do facto de muitos deles teremtrabalhado, num mesmo projecto, durante vOs meses.

0 funcionarnentO desta reuni6es devem obedecer aosseguintes princfpios [Defense Systems ManagementCollege 20001(Carr et aI. 19931:

Agrnpamento par afmidade (�peergrauplng'): Agrupar as pessoas por afinidadesprofissionais, facilita a comunicao entre osparticipantes. Como resultado disso, cria-Se umalinguagem e uma perspectiva comuns e umacompreens&o mdtua dentro do grupo, em Quecada participante Se pode identificar com�problemas' e quest8es'similares~

AnsSncia de julgamenta: Os membros daequipa de avaliao nAo devem directa onindirectamente, razer julgamentos sobre asdiscuss6es Que ocorrem, ou riscos Que sdo

3 - NO krnbito da tese de doutoramento do autor, foiigualmente elaborado um questionario taxin6mico deriscos de projectos, adaptado a realidade portuguesa~

QuaTIC 2001 / 163

identificados. Em vez disso, deve prevalecer umsenso nartilhado de "obter a verdade dos factos[Higuera and G!uch 19931.

. N5o respousabili7 ao: A responsabilidadepelos riscos e inform&Ao relacionada, Queemergem destas sessJes, n2o deve ser atribufdaao grupo, ou a qualquer indivfduo do grupo,nesta fase. A conversa deve aflorar toda ainforma5o importante (e, muitas vezes,suprimida)~

,iPTC Buxo de infonmo: Embora estejaestruturada em torno do questioniotaxin6ruico, a sess5o deve permitir um livrefluxo de informao, em que as respostas quest5es sAo as respostas devidas e no asrespostas "politicamente correctas" [Carr 1993].

A criaV:o de uma atmosfera profissional, em que seconjugam a estrutura e as caracteristica mencionadas,permite u!trapassar as yetic8ncias e a ansiedade, muitasvezes evidentes em entrevistas de auditoria ou deavaliao [Gemmer 1995]. Este processo da poder a cadagrupo para desafiar a sua compreensAo co!ectiva sobre Osriscos associados ao seu projecto. 0 conhecimentocontido no questiono taxin6mico, combinado com ocardcter no personalizado das sess6es, habilitam osparticipantes a explorer esta incertezas, enquantoprofissionais.

Em contraste com as auditorias extemas, em que hajulgamentos e recomenda5es por parte da equipa deauditoria, este processo de avalia&o dos riscos deve serconstrufdo com base na cooperaAo mdtua. Dene existiruma senso de apoio construtivo, fomecido pela orientaAodos responsaveis pela gest5o do risco, e um forte sentidode trabalhar em conjunto para um objectivo comum~

A actividade de avaliaV5o, dentro da sess&o de grupo,deve incluir a avaliaSo individua1 da impornincia,probabilidade e data de ocorr8ncia, associadas a cadarisco identificado na sessAo. Estas avalia6es constituemos passos iniciais da ana1ise do processo de gesto dorisco; a inform&Bo Que delas results serd usada parafacilitar as decis6es de gest&o sobre os riscos doprograma.

0 terceiro passo do processo e a consolidao dainform&ilo resultante dos varios grupos, num pacoteconsistente, destinado ao estabelecirnento das prioridadesdo projecto, para os riscos identificados. As decis6esnecessfas para a compi!a5o dos riscos, devem serbaseadas no consenso entre os membros a equipa deavalia&o~

0 quarto passo 6 a realiza2o de reuni6es de gesu]o, emQue se processam duas importantes actividades: (1)

revisio e (2) compara&o dos riscos identificados~ Estasactividades constituem o mecanismo colectivo Que

::olocaSo numa escala de prioridadedefinida pela gest&o.

[FitzGera!d 1990], em Que cada risco da Esta 6 comparado

relativarnente ao crit6rio de "importiincia para o projecto",

qua! dos riscos devem ser atribuidos recursos, a qua! dosriscos a gest3o deve prestar atenV2o, etc.. Artaves dadiscuss&o de cada um dos pares de riscos, a decis5o sobrequa! o risco do par Que 6 considerado mais importantepara o projecto, deve ser tomada por consenso entre osgestores. Este processo continua ao longo de coda a lista,sendo os riscos priorilizados, com base no total de todasas comparaBes. Os efeitos agregados de riscos e os riscosextremos (baixa probabilidade mas elevado impacto),hem como todos os riscos identificados, so tratadoscomo parte do processo continuo de Zesto(planeamento). Novos risco sero adicionados a lista, iimedida Que for sendo necessario, ao !ongo do ciclo deVida do projecto.

0s processos de decis8o consensual preconizados,constituem m6todos eficazes de incentivar a visAoparti!hada, a perspectiva sist6mica a comunica5o abertae a formulao de estrat( gias proactivas, entre todos ose!ementos do projecto com responsabilidades de geso.No entanto, e born recordar, os resultados de todo esteprocesso so, em dltirna insnincia, da responsabilidade doChere de Projecto.

O passo final deste processo 6 urna apresentao dosresultados, sem atribui8o a nenhum grupo ou indivfduo.Esta apresenta5o deve ser conduzida, de um modoformal, a todo o pessoal do projecto Que participou noprocesso de avalia20. Embora esta reuni&o seja aconclusAo da avalia&o inicial dos riscos, ela constituiigualmente o f6rum para iniciar o processo continuo degeso do risco em equipa.

Passos do Processo CondnuoComo i!ustrado na Figura 10, os resultados das avalia6esiniciais dos riscos sSo u1:ilizados na actividade dereclassifica50 dos riscos, a qual6 conduzida em conjuntocom as revis5es mensais do projecto. O processo dereclassificaAo resultarli na prioritiza&o, oureprioritizaAo, daqueles riscos Que, embora em reduzidondmero, o vitais para o projecto. Esta lista, a nine! doprojecto, e representativa da abordagem tipo Pareto degesnio dos ..poucos vitals" [Juran, 1989} aos nfveis maiselevados de geso do projecto.

O processo de compara&o das classificaV6es dos riscos,que e inicialmente conduzido ap6s as actividades de

164 / QuaTIC2001

identificao inicial e, aproximadamente todos Os mesesap6s isso, 6 representativo do importante papel Que umambiente de equipa, fundado numa comunicaqAo eficaz,joga na implementa95o da Besto do risco. Este f6rumconstitui uma mecanismo eficaz para a troca deperspectivas e prioridades individuals Que cada parceiro,cliente ou fornecedor, trazem para o processo dedesenvolvimento do sistema inforr0atico.

Antes da se5s8o inicial de compara3o das c!assificaJesdos riscos, os riscos mais importantes Que foramidentificados mas 5655565 de identificaiio inicial de cadaparceiro, so postos em comum para format a lista dos�Top N riscos mais importantes, a nine! do projecto. Aselec9Ao desses op N", partilhados por ambos Osparceiros, devera ser felts com base nos criteriosestabelecidos pe!o chafe de projecto, pe!o c!iente e pelofomecedor, adoptando-se Os mesmos crit6rios deconsenso anteriormente utilizados.

Os restantes passos do processo continuo da Beso dorisco em equipa, s2o conduzidos dentro da organizaAo decada parceiro e incluem Os processos conn-Duos deidentificaVo e avaliao, hem como Os passos deplaneamento, monitorizaAo e contro!o defmidos noModelo de Gaso Integrada do Risco- Para alem disso, osriscos e as actividades do projecto com etas re!acionados,SerAo revistos periodicamente, durante revis5es t6cnicas,trocas- de informaQAo entre gestores e, formalmente, nasrevlsoes mensals.

Este processo de identifica9&o regular dos riscos deveenvolver o pessoal a todos os niveis da organiza9Ao e, emconjunto com os outros passos do processo continuomostrado na Figura 10, 6 representativo de uma cultura deconsciencializag2o dos riscos, tomando'-se a Besocontfnua dos riscos uma parte integrante de todas asactividades de desenvolvimento do projecto- A medidaQue emergam eventualmente novos riscos, ou os riscosconhecidos evoluam, devem ser tomadas novas decis6es,com base nessa informa50, e Os pianos e respectivasac6es devero ser modificados. Os processos demonitorizaAo e controlo, utilizados na Besto cldssica deprojectos, fomecem m6todos Que possibilitam ac96espreventivas sobre os riscos.

Desaffos da Implementao do Modelo. ObseFvaBesE especialmente evidente Que os riscos da implementa80de sistemas inforrmiticos Se encontram entre Os menosmedidos ou geridos [Higuera and Cinch 19933, e Queexistem outras areas, desde a tecnologia militar [Cornow20001 [Rosenberg et al. 1999)] at6 il area financeira[Caouette et al. 1998) [Schwartz and Smith 1993)passando pela engenharia de construgBo [CaHo and Cruz19981 (Skogen and Jacobsen 19861, em Que Os riscos s5ohem geridos.

De um modo geral, os gestores 580 6ficazes na Beso dosriscos associados com as tecnologias Que conhecem e,

consequentemente, a actividade global de gesnio do riscoestd fortemente dependente do julgamento e experiSnciaindividuals [Kirkpatrick et al- 1992].

Existem muitos desafios na aplicaAo do processo deBeso do risco em equipa numa organiza980, mas aqueso central e a do estabelecimento de um ambiente deequipa caracterizado por uma dtica do risco (Kirkpatricket al. 19921-

Nos muitos estudos Que t8m sido realizados nos EUA e naEuropa, sobre a eficaz implementa8o da gaso do riscoem projectos de desenvolvimento de sistemasinformgticos [Link et al 1999) [Rosenberg et al. 1999}[Arno 19971 (Kuhn et a!. 1996) [Karolak 19961 [Clark1995) [Kirkpatrick et aI. 1992) [SEI 1992], o efeito matsdramd6co Que tern sido observado e o processo deabertura dos canals de comunica8o para o didlogo dentrodas organizaJes, no respeitante aos riscos e respectivaBeso. Quando se verificam, nas metodologias de gesodos riscos, os pressupostos defendidos neste trabalho, osprocessos empregues t8m provado ser extremamenteeficazes na minimizaAo e, mesrno elimina98o, da quasetotalidade dos riscos considerados classicos nodesenvolvimento de software [Higuera and Gluch 1993].

A implementa95o das modernas prdticas de Best3o deequipas, tern provado fornecer, aos elementos da equipade projecto, metodos e ferramentas Que capitalizam acaracteristica de Que, colectivamente, as equipaspossuem, na realidade, rnais conhecimento, pensam de umndmero mats variado de maneiras e 580 mais eficazes Quea totalidade dos seus membros trabalhando isoladamente(efeito sinergtico das equipas) [Kulik 1994) (William19941 [Katzenbach and Smith 199381 (Katzenbach andSmith 1993b].

Resumo0 modelo proposto para a Gesnio Integrada do Risco visafomecer uma estrutura eficaz para a tomada racional dedecis5es, atrav6s de processos proactivos, com visBo defuturo e baseados no trabalho em equipa- As pr:iticaspreconizadas visam permitir as organiza96es quedesenvolvem sistemas informaticos (sejam elas umDepartamento de Sistemas de Inforrna95o interno, ou umaempresa actuando como fomecedor externo desseproduto/servio) lidar, de forma eficaz, com a exposi&o aperigos Que podem conduzir no satisfaV5o dasnecessidades dos clientes/uti!izadores, hem como adeflci8ncias na qualidade do sistema inforrndtico finale/ou a atrasos na entrega. A gest5o do risco em equipaconstitui um ingrediente vital para assegurar a satisfa9&oglobal do cliente/utilizador e a qualidade total do produtode software final.

No ritmo acelerado do actual ambiente empresarial,caracterizado pela mudana constante e rdpida, peloscurtos prazos de disponibilizag5o de produtos no mercado

QuaTIC,2001 / 165

e, muitas vezes, pela curta dura80 das janelas deoportunidade de mercado [Rohner 1998], e imperativoavailer, em simultiineo, as oportunidades e as ameaas~

Para tomar decis6es informadas e lidar com a incerteza,Burn ambiente economicamente competitivo etecnicamente desafiante, e necessario gerir eficazmente osriscos associados ao desenvolvimento de software. Aperspectiva abrangente e o efeito sinergetico trazidos pelagest5o do risco em equipa, constituem uma base eficazpara alcanar o sucesso no actual ambiente competitivo,atravds do desenvolvimento do produto "certo", do modo"certo" e da sua disponibiliza5o no momento "certo".

REFENCIASAkao, Yoji (1990). QuaL!ty Function Deployment:Integrating Customer Requirements into Product Design.Cambridge, Massachussets: Productivity Press.

Anthes, Gary H. (1996). "IRS Project Failures CostTaxpayers $50B Annually." CompterworLd, 30:42, pp.1-5.

ArttO, K.A. (1997). Feen Years of Project RiskManagement Applications - Where Are We Going?. In

hk6nen K., Arno K.A. (eds.), Managing Risks inProjects, E & FN Spon, an Imprint of ThomsonProfessional ITP, London, UK, pgs. 3-14.

Baccarini, David (1999). "The Logical FrameworkMethod for Defining Project Success." ProjectManagement JournaL, 30:4, pg.25.

Betts, M. (1992). "Feds Debate Handling of Failing ISProjects", ComputerworLd, November 2, p.103.

Boehrn, Barry W. (1991). �Software Risk Management:Principles and Practices." /EEE Sofiware, 8:1, pg.32-41.

Burdick, R. B.; Mullen, Thomas W. and Rodrigues A.(1998). �The Impact of Software Project Management onQuality." CUTl".ER /T Journal, 11:19, pg.30.

Caho,, A. and Cruz, MP. (1998). �.On the Management ofRisks in Construction Projects." Project ManagementReview, 4:I, pg.54.

Caouette, John B.; Altman, Edward I. and Narayanan,Paul (1998). Managing Credit Risks. New York, NY:Jonh Wiley & Sons.

Carr, Marvin; Ronda, Suresh; Monarch, Ira; Ulrich, Caroland Walker, Clay (1993). Tonomy Based RiskIdentification. (CMUISEI-93-TR-6). Pittsburgh, Pa.:Software Engineering Institute, Carnegie MellonUniversity.

Charette, R (1989). Software Engineering Risk Analysisand Management, Intertext, New York, NY.

Charette, Robert N. (1990) Application Strategies for RiskAnalysis. New York: Multiscience Press.

Chittister, Clyde and naives, Yacov (1993). "RiskAssociated with Software Development: A HolisticFramework for Assessment and Management" /EEETransactions on Systems, Man, and Cybernetz.cs. 23:3,pg.710-732.

Clark, Bill (1995) �Technical Performance Measurementin the Risk Management of Systems." Papar presented atthe 4th SKI Conference on Sofhvare Risk. Monterey, Ca.,November 6 8~

Conrow, Edmond H. (2000). Eective Risk Management:Some Keys to Success. American Institute of Aeronauticsand Astronautics.

Curtis, B.; Krasner, H. and Iscoe, N. (1988). �.A FieldStudy of the Software Design Process for LargeSystems." Communications of the ACM, 31:11.. pg.1268.

Defense Systerns Management College (2000). RiskManagement Guide for DOD Aquisitions. United StatesDepartment of Defense, Defense Aquisition University,Defense Systems Management College Press, WashingtonDC.

Deming, W. Edwards (1982). Out of Crisis.Massachussets Institute of Technology, Center forAdvanced Engineering Study, Cambridge, MA.

Denenberg, H.S.; Eilers, R~D.; Melone, JJ. and Zelten,R.A. (1974). Risk and Insurance (2nd edition).Englewood Cliffs, New Jersey: Prentice Hall.

Dorofee, Audrey (1993). Team Risk Management: A NewParadigm. Paper presented at the Software EngineeringSyrnposium, Pittsburg, PA., August 23-26.

Dowd, Kevin (1998). Beyond Value of Risk.'Understanding Risk Management. New York, NY: JohnWiley & Sons.

Ellis, V. (1994). "Audit Says DMV Ignored Warning."sAngeLes T'zmes, August 18, pg. A3.

Ewusi-Mensah, K. and Przasnyski, Z. H. (1995)."Learning from Abandoned Information SystemsDevelopment Projects', JournaL of InformationTechnologies, nr 10, pg. 3.

Ewusi-Mensah, Kweku (1994). Why /S DeveLopmentProjects Are Abandoned.' A Diagnosis j:iom UserPerspect!ves. Working Paper, CBA, Loyola MarymountUniversity.

FitzGerald, Jerry and FitzGerald, Ardra F. (1990). AMethodology for Conducting a Risk Assessment.Designing Controls into Computerized Systems. 2ndEdition, Redwood City, CA: Jerry FitzGerald &Associates.

Franklin, C.E. (1996). Risk Management. Memorandumfor ESC Program Managers, ESCICC, Risk Management

166 / QuaTIC2001

Department of the Air Force, Headquarters ESC (AFMC)Hanscom Air Force Base, MA.

Gernmer, Art (1995)" Engineering a Culture for RiskManagement. Paper presented at the Fourth SEIConference on Software Risk, Monterey, CA SoftwareEngineering Institute, Carnegie Mellon University,Pittsburgh, PA, November.

Gemrner, Art and Rock Philip (1997). "EncouragingWinning Risk Management Behavior: The Exercise Leftto the Student." In Proceedings of the 1997 SKIConference on Risk Management, "Managing Uncertaintyin a Changing World", April 7-9, Virginia Beach, VA.

Griffiths, C. and Newman, M (eds) (1996)" Journal ofInformation Technology. Special Issue on Sofi"ware RiskManagement, l1:4.

Hayes, R.W.; Perry, J.G.; Thomson, P.A" and Willmer, G.(1986). Risk Management in Engineering Construction -Implz.catz.ons for ProJ.ect Managers. The ProjectManagement Group UMfST, SERC Repot"t, ThomasTelford, UK.

Higuera, Ronald and Cinch, David P. (1993)" "RiskManagement and Quality in Software Development"Presentation at the Eleventh Annual Paczfic NorthwestSofiware Quailty Conference, Portland, Oregon, October18-20.

Higuera, Ronald P. and Haimes, Yacov Y- (1996).Sofiware Risk Management. Software EngineeringInstitute, Carnegie Mellon University, Pittsburg, PA.

Juran, J.M. (1988). Juran Quality Control Handbook:Fourth Edition" New York NY: McGraw-Hill BookCompany.

Juran, J.M (1989). Juran on Leadershipfor Quality. NewYork, NY: The Free Press, A Division of Macmillan, Inc.

Kaplan, S. and Garrick, J.B" (1981). "On the QuantitativeDefinition of Risk" Rz.sk Analysis, 1:1, pg.II.

Karolak Dale W. (1996)" Soare Engineering RiskManagement. Los Alamitos, CA: IFFF Computer SocietyPress.

Katzenbach, Jon R. and Smith, Douglas K. (1993a)- �TheDiscipline of Teams." Harvard Business Review, XXX,(March-April), pg-111-120.

Katzenbach, Jon R. and Smith, Douglas K. (1993b)" 7heWisdom of Teams. New York: Harper Business.

Keil, Mark (1995)" "Pulling the Plug: Software ProjectManagement and the Problem of Project Escalation" M/SQuarterly, 19:4, pg. 421.

Keil, Mark and Montealegre, Ramiro (2000). "Cuttingyour Losses: Extricating your Organization when Big

Project Goes Away." Sloan Management Revz.ew, Spring2000, pg.55.

Keil, Mark; Mixon, R.; Saarinen, T. and Tuunainen, V-(1995). "Understanding Runaway InformationTechnology Projects: Results from an InternationalResearch Program Based on Escalation Theory." Journalof Management Information Systems, Vol.11, Winter,pp.67-78.

Kesbom, Deborah; Schilling, Donald and EdwardKatherine A (1989). A Dynamic Project Management"New York, NY: John Wiley & Sons.

Kindel, S. (1992). "The Computer that Ate the Company."Fz.nancial World, 161:7, pg. 96.

King, Julia (1997). "IS Reins in Runaway Projects."Computerworld, 31:8, pp.1-2.

Kirkpatrick Robert J.; Walker, Julie A. and Firth, Robert(1992). Sofhvare DeveLopment Rz"sk Management.. An SEIAppraisal. Software Engineering Institute, CarnegieMellon University, Pittsburgh, Pa.

Kuhn, Dorothy A.; Wells, Curtis; Armitage, James;CusiK, Kerinia; Hanna, Mark and Pierson, Hal (1996). ADescription of the Systems Engineering Capabilz"tyMaturity Model Appraz.sal Method. Software EngineeringInstitute, Carnegie Mellon University, Pittsburg, PA.

Kull, D. (1986). "Anatomy of a 4GL Disaster." ComputerDecisz.ons, February II, pg. 58.

Link, Lee Loveland; Barbour, Rick; Krum, Al andNeitzel, August C. (1999). Ro//out and Instalation of RiskManagement at the [MINT Oz"rectorate Natz"onalReconaissance 0Ce. Software Engineering Institute,Carnegie Mellon University, Pittsburg, PA

Lyytinen, Kalle, Mathiassen, Lars and Ropponen, Janne(1998). "Attention Shaping and Software Risk: ACategorical Analysis of Four Classical Risk ManagementApproaches." Information Systems Research, 9:3, pg.233"

March, J. and Shapira, Z" (1987)" "ManagerialPerspectives on Risk and Risk taking." ManagementScience, 33:II, pg.1404.

Markus, M. L. and Keil, M (1994). "If we Bulid it, TheyWill Come: Designing Information Sistems that UsersWant to Use." S/oan Management Review, 35:4, pg. II.

McPartlin, J. P. (1992). "The Collapse of CONFIRM."/nformation Week, October 19, pg. 12.

Mehler, M. (1991). "Reining in Runaways." InformationWeek, December 16, pg. 20.

Neitzel, August C., Jr. (1999). "Managing RiskManagement" Cross Talk: The Journal of DefenseSystems Engineering. Hill Air Force Base, Utah: OgdenALC, July.

QuaTIC'2OOI i 167

R-338), Institute for Defense Analysis,Rohner, Kurt (1998). Marketing in The Cyber Age: TheWhy, The What and The How. Chichester, UK: JohnWiley & Sons, Ltd.

Ropponen. J. (1999). Software Risk Management:Foundations, Principles and Empirical FindingsJyvaskyla: Jyvaskyla University Printing House, Finland.

Rosenberg, I inda H.; Hammer, Theodore and Oallo,Albert (1999). �Continuous Risk Management at NASA."Poceedings of the Applied SofiwareManagement/Solhvare Management Conference, S. Jose,CA February.

Rowe, William D. (1988). An Anatomy of Risk. Malabar,Fla: Robert E Krieger.

Schulles, Peter R. (1988). The Team Hadbook.- How toUse Teams to Improve QuaLizy. Joiner Associates, Inc.~

Schwartz, Robert J. and Smith, Clifford (1993). AdvancedStrategies in Financial Risk Management. New Jersey;Prentice Hall.

Scoy, Roger L" Van (1992). Sofhvare Development Risk..Opportunity. Not Problem. Software EngineeringInstitute, Carnegie Mellon University, Pittsburg, PA.

SEI Software Engineering Insdtute (1992). "The SEIApproach to Mansging Software Technical Risks".Bridge, October, pg.l9-21.

Skogen, S.; Helge2and, A. and Jacobsen, A. (1986)."Integrated Risk Analysis of Estimates and Schedules."Transactions of the 9th International Cost EngineeringCongress, International Cost Engineering Council ICEC,Oslo, Norway, August.

Standish Group International (1996). Chaos Chartz"ng theSeas of Information Technology. The Standish GroupInternational, West Yarmouth, MA.

USA Air Force (1988). Sofiware Risk Abatement. AirForce Systems Command/Air Force Logistics CommandPamphlet 80045, September.

Van Genuchten, M. (1991). "Why is Software Late? AnEmpirical Study of the Reason for Delay in SoftwareDevelopment" IEEE Transactions on SofnvareEngineering, 17:6, pg.582.

Vesey, Joseph T. (1992). �Time-to-Market: Put Speed inProduct Development " /ndustria/ MarketingManagement, Vol. 21, pg.151-158.

Walkerden, F~ and Jeffery, R. (1997). "Software CostEstimation: A Review of Models. Processes andFractice." Advances in Computers, Vol.44. San Diego:Academic Press, pg.62.

Winner, Robert I.; Fennel, James P.; Bertrand, Harold E.and Slusarczu, Marko M.G. (1988)" The Role ofConcurrent Engineering in Weapons Systems Acquisition.

(IDA ReportDecember.

168 / QuaTIC2001