=Paper=
{{Paper
|id=Vol-1284/paper19
|storemode=property
|title=Gestão do Risco e Qualidade no Desenvolvimento de Software
|pdfUrl=https://ceur-ws.org/Vol-1284/paper19.pdf
|volume=Vol-1284
|dblpUrl=https://dblp.org/rec/conf/quatic/Miguel01
}}
==Gestão do Risco e Qualidade no Desenvolvimento de Software==
https://ceur-ws.org/Vol-1284/paper19.pdf
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 do
Resumo: Esta comunicaAo discute o papel da software desenvolvido.
Beso do risco e da qualidade em projectos de
desenvolvimento de software. Discute, especificamente, a A qualidade, como 6 discutida por Juran, apresenta um
import&ncia da gest&o do risco na satisfao dos significado duplo: caractensticasdo produto satisfazendo
objectivos de qualidade no desenvolvimento do produto as necessidades do utilizador e isenAo de defici8ncias
adequado, num momento em que o mercado exige tempos [Juran 19891. Desenvolver o produto certo, do modo
de desenvolvimento cada vez mais curtos. certo, conscituemfactores necessarios e compZementares,
no sentido da satisfao do cliente. Satisfazer as
S-ao apresentados os elementos de uma exig8ncias do prazo de disponibiliza5o (me-to
metodologia de Gestiio Integrada do Risco, incluindo os market),revela-se igualmenteimportancepara a satisfa80
processos centrals de identifica2o, avaliaAo, do cliente/utilizador e critico para a sobrevivBncia da
pZaneamento,monitorizao e controlo, bem como a sua
organizao.
integrao na geso de projectos. Esta metodologia foi
desenvolvida no bito da tese de doutoramento em No entanto,no domfnio dos projectos de desenvolvimento
Sistemas de InformaAo, em que o autor Se encontra de software, o panoramamio 6 animador.De acordo com
envolvido. as conclus6es de um estudo conduzido nos EUA, em
1995, pelo Standish Group [Standish Group International
19961, 3J,I% dos novos projectos de Sistemas de
PaIavms Chavez Gestiio do risco, projectos de Informa5o foram cancelados antes do sen t6rmino,
desenvolvimento de software, equipas, qualidade. acarretandocustos calculados em cerca de 81 mil milh6es
de d6lares. Para al6m disso, 52,7% dos projectos
completados, custaram J89%, das estimativas originais,
lutrodoo com custos adicionais de cerca de 59 mil milh6es de
No ambiente econ6mico actual, a corridapela qualidade6 d6lares para as organiza6es. 0 custo das oportunidades
a corrida pela sobreviv&ncia,tendo a marca da qualidade perdidas mio sdo mensurdveis, mas poderiam ser
emergido como uma vantagem competitivapara o sucesso facilmente de triJi5es de d6lares [Standish Group
das organiza96es. InternationalJ996].
Para complicar os desafios da competiBo, a rapidez da A literatura cientifica mostra que estes casos nAo
mudana do pr6prio ambianceecon6mico 6 cada vez mais constituem incidentes isolados, antes ocorrem com
aceJerada. Esta acelera98o da mudana resultou nuxn aJannantefrequ8nciaem organiza6es de todos os tipos e
'time-to-market"mais curto [Vesey 1992} [Akao 1990) e dimens6es [Keil and Montealegre 20001 [Lyytinen et al.
exige um e5tilOde gestdo cada vez mais preventivo nos J998] [Walkerden and Jeffrey 19971 [King 19971
sens processos de deciso. [Anthes, 19961 [Keil et al. 19951 [Ewusi-Mensah and
Przasnyski 1995} [Ewusi-Mensah and Przasnyski 1994]
Reconhecer a incerteza, antecipar as potenciais [Ellis 19942 [Gibbs 19942[Kinde219922 [McPart2in19922
consequncias adversas e iniciar prances de Beso [Betts 19921 [Mehler 19911 [Kull 19861, tornando assim
proactive conduz a menos problemas, menos crises e evidente que tais casos constituem um problema de toda a
mats sucesso, ao longo do ciclo de Vida do inddstria, apesar dos significativos progressos realizados
desenvolvimento de software~ Esta caracteristica em metodologias e ferramentas de desenvolvimento. ao
preventiva constitui um elemento chave de uma eficaz longo dos dltimos 20 anos.
QuaTIC'2001
/ 155
Os recursos despendidos deste modo uilo apresentam de mi6gaVo dos riscos, em termos dos sens custos e
qualquer retomo, a n5o ser que Os projectos possam ser beneffcios, hem como a avalia95o do impacto dos
recuperados, completados ou, de qualquer outro modo, decis6es actuais nas opV5esfutures [Scoy 19921.
terrmnados, no podendo os sistemas inforn::ldticos
Se os projectos de desenvolvimento de software
contribuir para o desempenho das organizaJes, se ago
continuam a softer grandes deslizamentos nos custos e
forem disponibilizados ou utilizados em tempo d61
nos prazos e a apresentar seriOs problemas de
[Markusand Keil I994].
desempenho e de qualidade, isto resulta, regra geral, do
A constantBo de que a maioria das causes dos facto de nAose lidar adequadamentecom a incerteza e o
deslizamentos dos projectos de software, em termos de risco inerentes a esta actividade. Um obsuiculo Chane6 a
prazos e custos, est relacionada com a sua BestAo, incapacidade de encarar Os problemas de deslizamento
conduziu a uma intensa pesquisa no Ambito das ac6es de dos prazos e custos como sintomas de um problema mais
Besto rnais adequadas para a resoluAo deste problema fundamental,a eles subjacente: o o reconhecimento da
[Ropponen 1999} [Baccarini 19991 [Griffiths and exist6ncia de riscos e a consequente nAo tornado de
Newman 1996} [Karolak 1996} [Ewusi-Mensah and medidasmitigadoras, em tempo oportuno.
Przanyski 1995} [Keil 1995} [Charette 2989} [van
O risco faz parte de qualquer actividade hurnana, miio
Genuchten 1988}[March and Shapira 1987}.
podendc nunca ser eliminado. O risco, em Si, no 6 man;
Tern vindo assim a ganhar corpo, nos meios cientificos, o risco 6 essencial ao progresso e o insucesso muitas
empresariaise governamentais, a noo de que a unica vezes, uma componente Chane da aprendizagem. No
forma de obviar ou, pelo menos, minimizer estas entanto, devemos aprender a balancear as possiveis
situa95es dramdticasd instituire implementeruma gestSo consequ8Reins negatives do risco, com os beneffcios
do risco proactiva, entrosadacom a Beso de projectos, potenciais da respectiva oportunidade associada [Scoy,
semelhanga do que Vern acontecendo, desde ha muito 1992].
tempo, em outras areas do conhecimento, como a
engenhariacivil [Coho and Cruz 1998) [Curtis et al. 1991}
[Hayes et al 19861, a engenhariafinanceira [Scoy 1992}
[Kaplan and Garrick 1981} [Denenberg et al. 1974], a
engenhariaaerondutica[Rosenberg et al. 1999} [Franklin
1996} e a industria da defesa [Defense Systems
Teer?egia_
Management College 2000} [Neitzel 19991 [USA Air
Force 19881.
A gest5o do risco fornece um veto de atingir Os tr Hardwar Seftwar
objectivos principais do desenvolvimento: construir o
produto "certo", do modo "certo"e entrega-lo no tempo
"certo" e constitui, fundamentalmente,um processo de | SISTEMA I/
decis&oinformada,que envolve a antecipaAo consciente
daquilo que pode correr mal, a avalia9Ao dos perdas
potenciais (severidade do impacto) e a incorpora50 desta Praze
Pesseas
perspectivaroais abrangentenas varias lases dos projectos
de desenvolvimento de software: planeamento, gesmo das
actividadese processo de decisAo. Custe
A presente comunica50 apresenta uma metodologia de
Gestilo Integrada do Risco de projectos de
desenvolvimento de software, desenvolvida no kmbito de Figural I - Riscos num contexto do desenvolvimento
tuna teses de doutoramentoem sistemas de informs50, e de sistemas inforrruificos
mostra a sumcoer8ncia com os princfpios da qualidade.
A Gest5o do II;iiisco
de Projectos de Software O insucesso na gest5o dos riscos dos projectos torna as
No Corao da gestijo do risco encontra-se a tomada de empresas menos produrivas e competitivas, devido mos
decis6es informadas, em tempo oportuno, atrav6s da compromissos desnecessdn"os Que se t8m de efectuar na
avalia5o consciente de tudo aquilo pode correr mal quail;/e, nos prazos e nas funcionalidades - e tudo isso
(riscos), hem como da probabilidade e severidade do com custos adicionais [Higuera and Naives I996].
respectivo impacto.
A produtividade e a qualidade dos projectos de
As tornadas de decis2o, suportadas por uma informa5o desenvolvimento de software o influenciadas por
correcta, envolvem a avaliaAo das estratdgiase pollticas mdltiplos factores, podendo varier de projecto para
156 / QuaTIC2001
projecto, dentro da mesma organiza5o e mesmo dentro AmtIiSar: transformer os dados dos riscos em
das vas fases do ciclo de Vida de um mesmo projecto inforrna9Aodtil parao processo de decis&o.
[Burdick et al. 19981.
Planear: traduzir a informa5o sobre os riscos
O motivo para esta varia6es na qualidade e na em decis6es e ac5es (quer actuals, quer futures)
produtividade, 6 que elas so afectadas por muitos e e implementeressas acJes.
diferentes factores (ver Figura 2). Muitos desses factores
Momtorizar: monitorizaros indicadores de risco
s50 directamente influenciados por decis6es de gesmo
e Osriscos conhecidos.
(por exemplo, poRticas de recrutamentoe de adoAo de
metodologias), emboramuitas vezes de mdltiplas formas CODtFOWr; cortigir OS desvios as acJes
dificilmente rastreaveis. planeadas.
prcs$5O 8 Comunicar: fornecer informa20, interna e
dos pmzos externa, de "feedback" e feedforward", para o
| projecto, sobre as actividades de gesnio dos
Costde II ~ Qualidade dz infomn riscoS, SO
\ / ontLmia de ou(:IaS equipas emergenu
Tmbalhofom , 's
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 doutoramentoem Queo autor
est comprometido, lot desenvo2nido um Mode2o de
Geso Integrada do Risco, Que tern como objectivo Figttta 3 - Modelo da Gesdo Integrada do msco
fornecer uma estrutura holistica de gasn1o do risco em -
projectos de desenvolvimento de software, estruturada,
eficaz e perfeitamenceenquave2 Ra Besnio clsica de O modelo refzresentadona figura como um "loop", para
projectos. reflectir o facto de Quea 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.
concorrenteda gestdo da qualidade e da gastilo do risco, ` -
fomece os alicerces e uma estruturaabrangentes para o Pol outro lado, a fun50 comnnicur, coma graficarnente
sucesso dos projectos de desenvolvimento de software. refzresentadana Figure 3, existe ao longo de todo o
O modelo proposta par a Oes Integrada do Risco u uieso loans "Wdaqu
asas
Integraas segulntes funoes, ou fases liga e tolna eficazes.
Idenflficar: Pesquisar e.localizer Os factores de A Gos(go Integrada do Risco dos projectos de
risco, antes Que estes se tomem Problemas e desenvolvimento de software assenta em trgs pilares
afectem o Projecto, de forma adversa' fundamentals (ver Figura 4), Que constituem os sous
alicerces:
QuaTIC 2001 / 157
Avaliar. Os riscos devem ser identificados e Conceito de Equipa
avaliados enquanto ainda 1:uitempo de tomar Um factor que desempenhaum papel chave no sucesso do
medidas mitigadoras, ou mesmo de Os eliminar~ desenvolvimento de software e na qualidade,d o conceito
Isto implies olhar para o fnturo e considerer o de equipa. Varias termos m sido utilizados para
caminho Que foi escolhido, Burnsperspective do descrever este processo de trabalhar em colectivo com
risco. objectivos comuns, como a .engenharia concorrente",Que
- CommdcaF. Devemos aceitar que os riscos envolve a integra5o do desenho do sistema e do processo
existem e devemos comunica-los a quern terna [Winneret al. 19881.
capacidadede Osresolver. Este conceito de equipa constitui igualmente uma
Resolver. Devemos agir, de forma consciente, estratdgia vital para o atingimento dos objectivos de
face aos riscos. Ism signifies transformarurn entrega do produto no tempo oportuno (`time"tomarket
risco numa oportunidade de melhorar as deliv ') e constitui um elemento chane na gesto do
possibilidades de sucesso. risco.
A caracteristica "equips" da qualidade evidence na
abordagem de Deming, no Ponto 4 dos sens 14 Pontos
para a Geso, o qua! diz especificamente:
"4" Termine com a pratica de adjudicao de neg6cios,
com base no preo. Em vez disso, minimize o custo
total. Escolha um fornecedor l:micopara qualquer item
isolado, on estabela uma reino duradoira de
lealdade e confiana." [Deming 1982)
Juran encara a rela5o de trabalho em equips, entre
fomecedor e cliente, como urns relao continua e
planeada, em Que ambas as partes trabalham
conjuntamente como se pertencessern il mesma
Figura4 - Os trs pilares da Gestilo Integradado companhia" [Juran, 1988]. Este trabalho em equipa e
sco baseado em:
e con&ana mdcua
Urna gest&o eficaz dos riscos deve possibilitar urns
harmoniosa interacV&o das varias funJes de e planeamento conjunto
identificao, avaliaAo, mitigaAo e controlo, para Blew e visitas mutuns
de permitir um sistema de aviso antecipado dos riscos
novos que v5o sendo detectados como fruto do processo
de geso (ver Figura 5). e ansEnciade 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-equipspreocupa-
|| se, mio apenas os objectivos de prazos, custos e
udesempenho 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 comunicaV5oque caracteriza
estas relas interpessoais constitui um elemento chave
na implementso da equips de geso do risco, numa
Figura 5 - FunJes da geso do risco funcionando organiza80 e entre organiza5es, hem como na rela20
harrnoniosarnente entre contratantecontratadoou contratado-subcontratado.
Este aspecto da comumca5o tern-se tornado
progressivamente mats importanceno contexto actual de
globalizko, em que se recorre cada vez com mais
frequ8ncia frequente, quer a solo6es tipo "application
package" adquiridas a empresas transnacionais, quer a
empresas de consultoria para efectuarem o
desenvolvimento e integraAo de sistemas informticos
complexos. Isto tern conduzido a situa6es complexas de
contratos com rndltiplos fornecedores e ao
desenvolvimento de projectos por equipas Que, muitas
nezes, Se encontram dispersas por localiza6es
geogrdficas distintase, por vezes, muito distantes.
Neste contexto, d fundamental Que a gestilo do risco dos
projectos seja efectuada por uma equips conjunta
cZiente/fomecedor(es).Este conceito de equips de Best5o
do risco constitui urns extensAodo conceito de equips de
trabalho da qualidade, de modo a incluir, n5o apenas a
qualidade dos produtos ou servios, mas igualmente a
gestiio do pr6prio processo de desenvolvimento do
sistema informdticoe dos factores de risco a e2einerentes.
Especificamente, a implementa5o da equips de gesnio do
risco, entre cliente e fornecedor(es)2ou entre contratadoe
subcontratado, a spitesAo do conceito de trabalho em
equips nas Feta6es comprador-fornecedor,para a gestiio Figura6 - Princi"piosda gesl:ilodo Risco
das incertezas(riscos) no processo de desenvolvimento do
produto~
Colectivamente, os principios acima identificados formam
O conceito de equips de goso do risco constitui urns a base para os processos, metodos e ferramentas Que c[iio
amIgama de mdtodos de gesto, metodos da qualidade e corpo a geso do risco em equipa. Os m6todos e
conceitos de gest5o participativa (orientados para equipas) ferramentas da gostAo do risco em equips mais
[Higuera and Gluch 1993]. comummente preconizados e utilizados [Dorofee 1993}
[SEI 1992} [FitzGeraldl eso indicados na Figura 7, em
A Gest5o do Risen em Equips
Uma abordagem integrada de equips, alicerada em Que Se definem Os mais aplicveis para cads uma das
funJes da Gestiio Integrada do Risco.
comunicaJes eficazes, e um dos mais importantes
aspectos da gesto integrada do risco. A comunicaq&o Cada um dos none princfpios atr enunciados, d descrito
facilita a dinica e a sinergia Que caracteriza a gestAo de seguida, com mais detalhe.
eficaz do risco e results numa introvis5o colectiva e numa
eficdcia global substancialmente maior que a soma das Vis5o Partilllada
contribuiJes separadas de cada individuo [Dorofee
1993]. A Geso do Risco em equips deve slicerar-se numa
O Modelo de GestAo Integrada do Risco funda-se nos visilo partilhada, Que abranja todos os aspectos do
none princfpios assinalados na Figura 6. projecto de desenvolvimento e no desejo de atingir, com
sucesso, essa vis5o, atraves dos esforOs colectivos da
equipa.
Esta visRo deve ser partilhadapor todos os membros da
equips e exige urns compree,ns5ocomum da natureza e
dos resultados do projecto. E baseada nos conceitos de
equipa [Katzenbachand Smith 19938} [Deming 1982]:
* pFop6sitO comum,
2 O concerto de relao cliente-fornecedor aplica-se em
-
duas situaJes: (1) no caso de um desenvolvimento
interno pela equips de 5.1. da organizao, esta serd o
fornecedor do software aplicacional e o utilizador final
serd o cliente. (2) no caso de um contrato da organizao
com uma empress extema, esta serd o fornecedor e aquela
o cliente. Em qualquer das duas situa6es, a gest5o do
risco devem erectuada por urns equips mista.
QuaTIC'2OOI/ 159
Figura 7 - M6todos e ferramentas da Gesto
Integrada do Risco em equipa
. senso de responsabilidadecolectiva,
fundamentaispara a gest8o do risco em equipa.
* compromisso colectivo a e eficaz constitui o ndcleo da
e numa relaAo de trabalho interpessoal cooperativa, Gest&o Integrada do Risco e inclui discuss5es em grupo,
caracterizada pela partilha mdtua e individual da trocas de informao "ad hoc", em pequenos grupos cu
responsabilidade. individualmente, hem coma processes e ferramentas
formats de dissemina8o da informaAo.Devem existir
Embora a natureza especifica da personalidade e dos mecanismos formats de relato dos riscos para a gesnio e
objectivos de cada membro individual da equipa possam desta para o pessoal do projecto. Tades as f6runs para
varier, colectivamente codas os membros da equipa identifica&o, resoluo e Beso dos riscos deverAo
devem partilhar o mesmo interesse no sucesso dos envolver um livre fluxo de informs80. A comunicao
resultados do projecto. dove ser cultivada dentro das etapas Chane de decio da
Esta vis&o partilhada deve ser {armada com base em equipa de gest&odo risco, atraves de processes de tornada
acordos contratuaise assenter nurnacompreeno mdtua de decisAobaseados no consenso.
das necessidades do cliente/utilizador. Acima de tudo, Valoriza!;;5oda ?creepo Individual
esta visBo deve constituir a evid8ncia de uma consnincia Um principio Chane do conceito de Geso do Integrada
de prop6sitos comum, no sentido de Deming [Deming do Risco em equipa 6 Que 6 vital valorizar e encorajar as
1982], e de urns compromisso colectivo para com a contribui6es individuals, para se obter uma interac3o
sucesso mdtuo do projecto de desenvolvimento. eficaz Que promova a sinergia resultante das percepJes
Vis5o de FuWro colectivas e das mtiItiRIas vis6es de cada membro da
A geso do risco exige a gesmo da incerteza que equips [Dorofee 1993}.E a voz individual Que pode trazer
o conhecimento, a introvis2o e a perspectiva dnicos para a
incorpore uma pesquisa activa e um controlo eficaz das
incertezas e do respectivo potencial de perdas [Charette identificaiio e geso dos riscos.
19902 [Rowe 1988]. O pensamento no aman Fundamentalmente,o processo da geso do risco em
identificando incertezas e antecipando potenciais equips deve valorizar a percepAo individual e encorajar
resultados, hem como a geso dos recursos e actividades as individuos, a todos os niveis do projecto, a
do projecto, tendo em atenV5oessas incertezas, o contribuirempara todas as etapas do processo. Enquanto
parte do processo de geso do risco, centrado na
160 / QuaTIC'2OOI
comunica20, 6 a perspectiva de cada individuo que
fomece o conhecimento e a introvis8o accessOs para
reconhecer Os problernas e riscos potenciais para o
projecto, e a capacidade para suportar os esforos
destinados a lidar eficazmente com esses riscos.
Perspectiva Sismica
Embora o loco da gesto do risco se centre, muitas vezes,
nas eas t6cnicas do software, fundamental possuir uma
perspectiva global do projecto enquanto esforVo integrado
num sistema organizacional.
Dentro da equipa, a avaliao dos riscos e respectivas
decies de gesnlo devem ser optirnizadascom base num
conceito alargado de sistema, ao longo de todo o
programade desenvolvimento da organiza5o, em vez de
Se centraremna perspectiva isolada dos riscos tnicos do
software.
Esta perspectiva inclui, n5o apenas as quest5es
fundamentais relativas il necessidades do
cliente/utilizador, mas tambm as quest6es t6cnicas, de
prazos, de custos, de desempenho, de qualidade e outras
relacionadas com o esforo de desenvolvimento
[Chittister and Halves 19931.
Integra50 ma Gestdo do Projecto
Um dos elementos cruciais do Modelo da Gesnio
Integrada do Risco, e o princ!pio de que a Beso do risco
deve constituir uma parte integrante e vital da gestSo do
projecto. A geso de projectos pode ser considerada
como um conjunto de actividades integradas de
planeamento, controlo, organiza50 e direc80 [ PMEOK
19961, orientadas para equipas, como pode se encontra
representado na Figura 8.
A gest5o do risco n&opode ser vista como um ap8ndice
das actividades de rotina da geso do projecto. Este
conceito ilustrado na Figura 9. em Que o modelo
basico de gestgo do risco se encontra embebido no
conjunto de processos e mtodos utilizados para a
gesl[ilo do projecto, os quais se integram nas funs
prilnarias da gestdo de projectos organi planear,
dirigir e controlar (Charette 19891.
Especificamente, a gestiio do risco providencia, n8o
apenas processos sisternaticos e despersonalizados Figura9 -Integra8o da GestAodo Risco na Gesto
para gerir o risco, mas igualmente processos e de Projectos
metodos associados que Se integram perfeitarnente
nas prdticasestabelecidas paraa gestdo do projecto.
Proactividade das Estratkgias
0 caracter proactivo da antecipa8o, planeamento e
execu8o das actividades do projecto, constitui a marca
caracteristica do Modelo de Geso Integrada do Risco, a
qual culmina, em ti1tima instAncia, em tornadas de
decisBo. A gest5o do risco fomece os fundamentos para
um processo de decis5o informado, atrav6s de tuna
avalia2o consciente das incertezas, das perdas potenciais
QuaTIC'2001/ 161
e das oportunidades proporcionadas pelo facto de Se exemplo, ao implementar a monitorizaVAoe o controlo
anteciparem(em vez de apenas se reagir a) Os bicos dos riscos, as organizaJes podem empregar Os
sens mtodos habituais de monitorizaAo e controlo de
problemas,
XI? XYlT 0 D O HP OXE S S O XO NT Y O E GE S T p0 D O P IS XO efectuando
algumas
modificaJes
de modo a
incluir a
informaq5o
dos riscos nos
formulariOs
e/ou
ferramentas de
software
existentes.
Figura 10 - Processo da Cest&odo Risco em Equipa
Reguladdade e Continnidade dos Processos
Uma geo eflcaz do risco exige uma vigilAncia continua
e, como ilustrado na Figura 7, a equip& de geso do
acontecimentos [Dowd 1998]. Os m6todos de geso do risco dcne adopter este conceito sob a forma de um
risco propostos..personificam esta abordagem proactiva processo continuo, caracterizado pelas actividades
ao incorporarem a consciencia das perdas potenciais, regulates de identificao e gestAo Que 520 evidentes ao
directamente nos processos de decis2o do pr6prio longo do ciclo de Vida do projecto.
projecto.
Na pr;itica da gesuio do risco, estes principios so
Metodologia Sisll:erxl;iSca e Adaptdvex exemplificados ao longo de codas as actividades do
Um elemento Chane da Gesto Integrada do Risco, 6 a `projecto. For exemplo, os riscos scmo itens da agenda das
adopVo de uma abordagem sistematica e adapt5nel a reuni6es regulates da equipa de projecto, as discuss5es
infraestruturae it cultura do projecto e da organiza5o. A sobre riscos ocorrer regularmentee, ii medida Quemonos
estruturados processos, metodos e ferramentas6 modular riscos emergem, ou os riscos actuajismadam, os pianos e
e constituida por unidades de processo fundamentals. acJes o modificados. sendo as decis5es baseadas
Cada modulo do processo 6 adapnineSas especificidades nestes riscos novos, ou alterados.
de qualquer organiza50: suas prticas, dimensSo,
dominio aplicacional e prazo do projecto. A Prdtica da GestSo Integrada do Risco
Este capitulo discute a aplica5o do processo da gest5o do
Emborapropondo m6todos e ferramentasabrangentesQue risco, em equipa, como d mostrada na Figura 10 no caso
podem coexistir com as praticas estabelecidas, a estrutura de um projecto de desenvolvimento de software
bdsica do modelo e Os respectivos m6todos associados aplicacional adjudicado a um fomecedor especializado,
foram desenhadospara se adaptaremas prcas, m6todos que actua como prime contractor".
e ferramentas utilizadas por qualquer projecto. Por
162 / QuaTIC2001
AvalLal In clal d o s P taco s
Figura II - Passos da avaliaV5oinicial dos riscos
utilizar"se um questioruirio taxin6mico3 de riscos. As
trocas Queocorrem Rastus5e55665providenciamuma base
Os passos iniciais do processo ennolvem o para uma comunicaBo adicional, fora do 5mbito das
estabelecimento de um conjunto inicial de riscos para o sess6es. Em grandes projectos, este f6rum constitui,
projecto. Cada um dos parceiros envolvidos (cliente e muitas vezes, a primeira oportunidade para o
fomecedor) realiza urna analia50 inicial dos riscos, para estabelecimento de contactos entre muitos dos
definir os riscos associados com as respectivas participantes, apesar do facto de muitos deles terem
organizaJes. trabalhado,num mesmo projecto, durantevOs meses.
AcNvidades de AvaBao Inicial dos Riscos 0 funcionarnentOdesta reuni6es devem obedecer aos
Os passos Chaneenvolvidos numa avalia&o inicial dos seguintes princfpios [Defense Systems Management
riscos so mostrados na Figura 11. Estas actividades de College 20001(Carr et aI. 19931:
avalia20 devem ser levadas acabo por uma equipa de Agrnpamento par afmidade (peer
avalia2o treinadaou, se no fiver a adequadapreparao, grauplng'): Agrupar as pessoas por afinidades
deve ser orientadapor um consulter em gest&odo risco. profissionais, facilita a comunicao entre os
O primeiro passo numa avalia5o inicial dos riscos, 6 a participantes.Como resultado disso, cria-Seuma
realizaVo de umaFannio de orientaVo dos participantes, linguagem e uma perspectiva comuns e uma
liderada pelo Cherede projecto, destinada a fomecer urna compreens&omdtua dentro do grupo, em Que
vis2o global do processo a todos os participantes e a cada participante Se pode identificar com
prepar:i-losparaOs respectivos papis no processo. problemas' e quest8es'similares~
O passo seguinte a realizaq2o de mtiltiplas sess6es de AnsSncia de julgamenta: Os membros da
grupo, para a avalia5o dos riscos. Para esse efeito deve equipa de avaliao nAo devem directa on
indirectamente, razer julgamentos sobre as
discuss6es Que ocorrem, ou riscos Que sdo
3 - NO krnbitoda tese de doutoramentodo autor,foi
igualmente elaboradoum questionariotaxin6mico de
riscos de projectos, adaptadoa realidadeportuguesa~
QuaTIC 2001 / 163
revisio e (2) compara&o dos riscos identificados~Estas
actividades constituem o mecanismo colectivo Que
identificados. Em vez disso, deve prevalecer um
senso nartilhado de "obter a verdade dos factos
::olocaSo numa escala de prioridade
[Higuera and G!uch 19931.
definidapela gest&o.
. N5o respousabili7 ao: A responsabilidade
pelos riscos e inform&Ao relacionada, Que
emergem destas sessJes, n2o deve ser atribufda
[FitzGera!d1990], em Quecada risco da Esta6 comparado
ao grupo, ou a qualquer indivfduo do grupo,
nesta fase. A conversa deve aflorar toda a
relativarnenteao crit6rio de "importiinciaparao projecto",
informa5o importante (e, muitas vezes,
suprimida)~
qua! dos riscos devem ser atribuidos recursos, a qua! dos
,iPTC Buxo de infonmo: Embora esteja riscos a gest3o deve prestar atenV2o, etc.. Artaves da
estruturada em torno do questionio discuss&ode cada um dos pares de riscos, a decis5o sobre
taxin6ruico, a sess5o deve permitir um livre qua! o risco do par Que 6 considerado mais importante
fluxo de informao, em que as respostas para o projecto, deve ser tomada por consenso entre os
quest5es sAo as respostas devidas e no as gestores. Este processo continua ao longo de coda a lista,
respostas "politicamente correctas" [Carr 1993]. sendo os riscos priorilizados, com base no total de todas
as comparaBes. Os efeitos agregados de riscos e os riscos
A criaV:o de uma atmosfera profissional, em que se
extremos (baixa probabilidade mas elevado impacto),
conjugam a estrutura e as caracteristica mencionadas,
hem como todos os riscos identificados, so tratados
permite u!trapassaras yetic8ncias e a ansiedade, muitas
como parte do processo continuo de Zesto
vezes evidentes em entrevistas de auditoria ou de
(planeamento). Novos risco sero adicionados a lista, ii
avaliao [Gemmer 1995]. Este processo da poder a cada medida Que for sendo necessario, ao !ongo do ciclo de
grupo para desafiar a sua compreensAoco!ectiva sobre Os Vida do projecto.
riscos associados ao seu projecto. 0 conhecimento
contido no questiono taxin6mico, combinado com o 0s processos de decis8o consensual preconizados,
cardcter no personalizado das sess6es, habilitam os constituem m6todos eficazes de incentivar a visAo
participantes a explorer esta incertezas, enquanto parti!hada,a perspectivasist6mica a comunica5o aberta
profissionais. e a formulao de estrat(gias proactivas, entre todos os
e!ementos do projecto com responsabilidades de geso.
Em contraste com as auditorias extemas, em que ha
No entanto, e born recordar, os resultados de todo este
julgamentos e recomenda5es por parte da equipa de processo so, em dltirnainsnincia, da responsabilidadedo
auditoria,este processo de avalia&o dos riscos deve ser Chere deProjecto.
construfdo com base na cooperaAo mdtua. Dene existir
uma senso de apoio construtivo,fomecido pela orientaAo O passo final deste processo 6 urna apresentao dos
dos responsaveis pela gest5o do risco, e um forte sentido resultados,sem atribui8o a nenhum grupo ou indivfduo.
de trabalharem conjuntopara um objectivo comum~ Esta apresenta5o deve ser conduzida, de um modo
formal, a todo o pessoal do projecto Que participou no
A actividade de avaliaV5o, dentro da sess&o de grupo, processo de avalia20. Embora esta reuni&o seja a
deve incluir a avaliaSo individua1 da impornincia,
conclusAo da avalia&o inicial dos riscos, ela constitui
probabilidade e data de ocorr8ncia, associadas a cada igualmente o f6rum para iniciar o processo continuo de
risco identificado na sessAo. Estas avalia6es constituem
geso do risco em equipa.
os passos iniciais da ana1ise do processo de gesto do
risco; a inform&Bo Que delas results serd usada para Passos do Processo Condnuo
facilitar as decis6es de gest&o sobre os riscos do Como i!ustrado na Figura 10, os resultados das avalia6es
programa. iniciais dos riscos sSo u1:ilizados na actividade de
reclassifica50 dos riscos, a qual6 conduzida em conjunto
0 terceiro passo do processo e a consolidao da
com as revis5es mensais do projecto. O processo de
inform&ilo resultante dos varios grupos, num pacote reclassificaAo resultarli na prioritiza&o, ou
consistente, destinado ao estabelecirnentodas prioridades reprioritizaAo, daqueles riscos Que, embora em reduzido
do projecto, para os riscos identificados. As decis6es
ndmero, o vitais para o projecto. Esta lista, a nine! do
necessfas para a compi!a5o dos riscos, devem ser projecto, e representativa da abordagem tipo Pareto de
baseadas no consenso entre os membros a equipa de
gesnio dos ..poucos vitals" [Juran, 1989} aos nfveis mais
avalia&o~ elevados de geso do projecto.
0 quarto passo 6 a realiza2o de reuni6es de gesu]o, em O processo de compara&o das classificaV6es dos riscos,
Que se processam duas importantes actividades: (1)
que e inicialmente conduzido ap6s as actividades de
164 / QuaTIC2001
identificao inicial e, aproximadamentetodos Os meses consequentemente,a actividade global de gesnio do risco
ap6s isso, 6 representativo do importantepapel Que um estd fortemente dependente do julgamento e experiSncia
ambiente de equipa, fundado numa comunicaqAoeficaz, individuals[Kirkpatricket al- 1992].
joga na implementa95o da Besto do risco. Este f6rum Existem muitos desafios na aplicaAo do processo de
constitui uma mecanismo eficaz para a troca de Beso do risco em equipa numa organiza980, mas a
perspectivas e prioridades individuals Que cada parceiro, queso centrale a do estabelecimento de um ambiente de
cliente ou fornecedor, trazem para o processo de equipa caracterizadopor uma dtica do risco (Kirkpatrick
desenvolvimentodo sistema inforr0atico. et al. 19921-
Antes da se5s8o inicial de compara3o das c!assificaJes Nos muitos estudos Quet8m sido realizados nos EUA e na
dos riscos, os riscos mais importantes Que foram Europa, sobre a eficaz implementa8o da gaso do risco
identificados mas5655565de identificaiio inicial de cada em projectos de desenvolvimento de sistemas
parceiro, so postos em comum para format a lista dos informgticos [Link et al 1999) [Rosenberg et al. 1999}
Top N riscos mais importantes, a nine! do projecto. A [Arno 19971 (Kuhn et a!. 1996) [Karolak 19961 [Clark
selec9Ao desses op N", partilhados por ambos Os 1995) [Kirkpatricket aI. 1992) [SEI 1992], o efeito mats
parceiros, devera ser felts com base nos criterios dramd6co Que tern sido observado e o processo de
estabelecidos pe!o chafe de projecto, pe!o c!iente e pelo aberturados canals de comunica8o para o didlogo dentro
fomecedor, adoptando-se Os mesmos crit6rios de das organizaJes, no respeitante aos riscos e respectiva
consenso anteriormenteutilizados. Beso. Quando se verificam, nas metodologias de geso
Os restantes passos do processo continuo da Beso do dos riscos, os pressupostos defendidos neste trabalho, os
risco em equipa, s2o conduzidos dentro da organizaAo de processos empregues t8m provado ser extremamente
cada parceiro e incluem Os processos conn-Duos de eficazes na minimizaAo e, mesrno elimina98o, da quase
identificaVo e avaliao, hem como Os passos de totalidade dos riscos considerados classicos no
planeamento, monitorizaAo e contro!o defmidos no desenvolvimentode software [Higuera and Gluch 1993].
Modelo de Gaso Integrada do Risco- Para alem disso, os A implementa95o das modernas prdticas de Best3o de
riscos e as actividadesdo projecto com etas re!acionados, equipas, tern provado fornecer, aos elementos da equipa
SerAorevistos periodicamente, duranterevis5es t6cnicas, de projecto, metodos e ferramentas Que capitalizam a
trocas-de informaQAoentre gestores e, formalmente, nas caracteristica de Que, colectivamente, as equipas
revlsoes mensals. possuem, na realidade, rnaisconhecimento, pensam de um
Este processo de identifica9&o regular dos riscos deve ndmero mats variadode maneiras e 580 mais eficazes Que
envolver o pessoal a todos os niveis da organiza9Aoe, em a totalidade dos seus membros trabalhandoisoladamente
conjunto com os outros passos do processo continuo (efeito sinergtico das equipas) [Kulik 1994) (William
mostrado na Figura 10, 6 representativode uma culturade 19941 [Katzenbach and Smith 199381 (Katzenbach and
consciencializag2o dos riscos, tomando'-se a Beso Smith 1993b].
contfnua dos riscos uma parte integrante de todas as
actividades de desenvolvimento do projecto- A medida Resumo
Que emergam eventualmente novos riscos, ou os riscos 0 modelo propostopara a Gesnio Integrada do Risco visa
fomecer uma estruturaeficaz para a tomada racional de
conhecidos evoluam, devem ser tomadas novas decis6es,
com base nessa informa50, e Os pianos e respectivas decis5es, atrav6s de processos proactivos, com visBo de
futuro e baseados no trabalho em equipa- As pr:iticas
ac6es devero ser modificados. Os processos de
monitorizaAo e controlo, utilizados na Besto cldssica de preconizadas visam permitir as organiza96es que
desenvolvem sistemas informaticos (sejam elas um
projectos, fomecem m6todos Que possibilitam ac96es
Departamentode Sistemas de Inforrna95ointerno, ou uma
preventivassobre os riscos.
empresa actuando como fomecedor externo desse
Desaffos da Implementao do Modelo. ObseFvaBes produto/servio) lidar, de forma eficaz, com a exposi&o a
E especialmente evidente Queos riscos da implementa80 perigos Que podem conduzir no satisfaV5o das
de sistemas inforrmiticos Se encontram entre Os menos necessidades dos clientes/uti!izadores, hem como a
medidos ou geridos [Higuera and Cinch 19933, e Que deflci8ncias na qualidade do sistema inforrndtico final
existem outras areas, desde a tecnologia militar [Cornow e/ou a atrasos na entrega. A gest5o do risco em equipa
20001 [Rosenberg et al. 1999)] at6 il area financeira constitui um ingrediente vital para assegurar a satisfa9&o
[Caouette et al. 1998) [Schwartz and Smith 1993) global do cliente/utilizadore a qualidade total do produto
passando pela engenharia de construgBo[CaHoand Cruz de software final.
19981 (Skogen and Jacobsen 19861, em QueOs riscos s5o
No ritmo acelerado do actual ambiente empresarial,
hem geridos.
caracterizado pela mudana constante e rdpida, pelos
De um modo geral, os gestores 580 6ficazes na Beso dos curtos prazos de disponibilizag5o de produtosno mercado
riscos associados com as tecnologias Que conhecem e,
QuaTIC,2001 / 165
e, muitas vezes, pela curta dura80 das janelas de Chittister, Clyde and naives, Yacov (1993). "Risk
oportunidade de mercado [Rohner 1998], e imperativo Associated with Software Development: A Holistic
availer, em simultiineo,as oportunidadese as ameaas~ Framework for Assessment and Management" /EEE
Transactions on Systems, Man, and Cybernetz.cs. 23:3,
Para tomar decis6es informadas e lidar com a incerteza,
pg.710-732.
Burn ambiente economicamente competitivo e
tecnicamente desafiante,e necessario gerir eficazmente os Clark, Bill (1995) Technical Performance Measurement
riscos associados ao desenvolvimento de software. A in the Risk Managementof Systems." Papar presented at
perspectiva abrangentee o efeito sinergetico trazidos pela the 4th SKI Conference on Sofhvare Risk. Monterey, Ca.,
gest5o do risco em equipa, constituem uma base eficaz November 6 8~
para alcanar o sucesso no actual ambiente competitivo,
Conrow,Edmond H. (2000). Eective Risk Management:
atravdsdo desenvolvimento do produto "certo", do modo
Some Keys to Success. American Instituteof Aeronautics
"certo"e da sua disponibiliza5o no momento "certo".
and Astronautics.
REFENCIAS Curtis, B.; Krasner, H. and Iscoe, N. (1988). .A Field
Akao, Yoji (1990). QuaL!ty Function Deployment: Study of the Software Design Process for Large
Integrating Customer Requirements into Product Design. Systems." Communications of the ACM, 31:11..pg.1268.
Cambridge,Massachussets:Productivity Press.
Defense Systerns Management College (2000). Risk
Anthes, Gary H. (1996). "IRS Project Failures Cost Management Guide for DOD Aquisitions. United States
Taxpayers $50B Annually." CompterworLd, 30:42, pp.1- Department of Defense, Defense Aquisition University,
5. Defense Systems ManagementCollege Press, Washington
ArttO, K.A. (1997). Feen Years of Project Risk DC.
Management Applications - Where Are We Going?. In Deming, W. Edwards (1982). Out of Crisis.
hk6nen K., Arno K.A. (eds.), Managing Risks in Massachussets Institute of Technology, Center for
Projects, E & FN Spon, an Imprint of Thomson AdvancedEngineering Study, Cambridge,MA.
Professional ITP, London, UK, pgs. 3-14.
Denenberg, H.S.; Eilers, R~D.; Melone, JJ. and Zelten,
Baccarini, David (1999). "The Logical Framework R.A. (1974). Risk and Insurance (2nd edition).
Method for Defining Project Success." Project Englewood Cliffs, New Jersey: Prentice Hall.
Management JournaL,30:4, pg.25.
Dorofee, Audrey (1993). Team Risk Management: A New
Betts, M. (1992). "Feds Debate Handling of Failing IS Paradigm. Paper presented at the Software Engineering
Projects", ComputerworLd,November 2, p.103. Syrnposium,Pittsburg,PA., August 23-26.
Boehrn, Barry W. (1991). Software Risk Management: Dowd, Kevin (1998). Beyond Value of Risk.'
Principles andPractices."/EEE Sofiware, 8:1, pg.32-41. Understanding Risk Management. New York, NY: John
Burdick, R. B.; Mullen, Thomas W. and Rodrigues A. Wiley & Sons.
(1998). The Impact of Software Project Managementon Ellis, V. (1994). "Audit Says DMV Ignored Warning."
Quality." CUTl".ER
/T Journal, 11:19, pg.30. sAngeLes T'zmes,August 18, pg. A3.
Caho,,A. and Cruz, MP. (1998). .On the Managementof Ewusi-Mensah, K. and Przasnyski, Z. H. (1995).
Risks in Construction Projects." Project Management "Learning from Abandoned Information Systems
Review, 4:I, pg.54. Development Projects', JournaL of Information
Caouette, John B.; Altman, Edward I. and Narayanan, Technologies, nr 10, pg. 3.
Paul (1998). Managing Credit Risks. New York, NY: Ewusi-Mensah, Kweku (1994). Why /S DeveLopment
Jonh Wiley & Sons. Projects Are Abandoned.' A Diagnosis j:iom User
Carr,Marvin;Ronda, Suresh;Monarch,Ira; Ulrich, Carol Perspect!ves. Working Paper, CBA, Loyola Marymount
and Walker, Clay (1993). Tonomy Based Risk University.
Identification. (CMUISEI-93-TR-6). Pittsburgh, Pa.: FitzGerald, Jerry and FitzGerald, Ardra F. (1990). A
Software Engineering Institute, Carnegie Mellon Methodology for Conducting a Risk Assessment.
University. Designing Controls into Computerized Systems. 2nd
Charette, R (1989). Software Engineering Risk Analysis Edition, Redwood City, CA: Jerry FitzGerald &
and Management, Intertext,New York, NY. Associates.
Charette,RobertN. (1990) Application Strategies for Risk Franklin, C.E. (1996). Risk Management. Memorandum
Analysis. New York: Multiscience Press. for ESC ProgramManagers, ESCICC, Risk Management
166 / QuaTIC2001
Departmentof the Air Force, HeadquartersESC (AFMC) Project Goes Away." Sloan Management Revz.ew,Spring
Hanscom Air Force Base, MA. 2000, pg.55.
Gernmer, Art (1995)" Engineering a Culture for Risk Keil, Mark; Mixon, R.; Saarinen, T. and Tuunainen, V-
Management. Paper presented at the Fourth SEI (1995). "Understanding Runaway Information
Conference on Software Risk, Monterey, CA Software Technology Projects: Results from an International
Engineering Institute, Carnegie Mellon University, Research Program Based on Escalation Theory."Journal
Pittsburgh,PA, November. of Management Information Systems, Vol.11, Winter,
pp.67-78.
Gemrner, Art and Rock Philip (1997). "Encouraging
Winning Risk Management Behavior: The Exercise Left Kesbom, Deborah; Schilling, Donald and Edward
to the Student." In Proceedings of the 1997 SKI Katherine A (1989). A Dynamic Project Management"
Conference on Risk Management, "ManagingUncertainty New York, NY: John Wiley & Sons.
in a Changing World",April 7-9, Virginia Beach, VA. Kindel, S. (1992). "TheComputerthat Ate the Company."
Griffiths, C. and Newman, M (eds) (1996)" Journal of Fz.nancialWorld, 161:7, pg. 96.
InformationTechnology. Special Issue on Sofi"wareRisk King, Julia (1997). "IS Reins in Runaway Projects."
Management, l1:4. Computerworld, 31:8, pp.1-2.
Hayes, R.W.; Perry, J.G.; Thomson, P.A"and Willmer, G. Kirkpatrick Robert J.; Walker, Julie A. and Firth, Robert
(1986). Risk Management in Engineering Construction - (1992). Sofhvare DeveLopmentRz"skManagement.. An SEI
Implz.catz.ons for ProJ.ect Managers. The Project Appraisal. Software Engineering Institute, Carnegie
Management Group UMfST, SERC Repot"t,Thomas Mellon University, Pittsburgh,Pa.
Telford, UK.
Kuhn, Dorothy A.; Wells, Curtis; Armitage, James;
Higuera, Ronald and Cinch, David P. (1993)" "Risk CusiK, Kerinia; Hanna, Mark and Pierson, Hal (1996). A
Management and Quality in Software Development" Description of the Systems Engineering Capabilz"ty
Presentation at the Eleventh Annual Paczfic Northwest Maturity Model Appraz.sal Method. Software Engineering
Sofiware Quailty Conference, Portland, Oregon, October Institute,Carnegie Mellon University, Pittsburg,PA.
18-20.
Kull, D. (1986). "Anatomyof a 4GL Disaster." Computer
Higuera, Ronald P. and Haimes, Yacov Y- (1996). Decisz.ons,February II, pg. 58.
Sofiware Risk Management. Software Engineering
Institute, CarnegieMellon University, Pittsburg,PA. Link, Lee Loveland; Barbour, Rick; Krum, Al and
Neitzel, August C. (1999). Ro//out and Instalation of Risk
Juran, J.M. (1988). Juran Quality Control Handbook: Management at the [MINT Oz"rectorate Natz"onal
Fourth Edition" New York NY: McGraw-Hill Book Reconaissance 0Ce. Software Engineering Institute,
Company. CarnegieMellon University, Pittsburg,PA
Juran,J.M (1989). Juran on Leadershipfor Quality. New Lyytinen, Kalle, Mathiassen, Lars and Ropponen, Janne
York, NY: The Free Press, A Division of Macmillan, Inc. (1998). "Attention Shaping and Software Risk: A
Kaplan, S. and Garrick,J.B"(1981). "Onthe Quantitative CategoricalAnalysis of Four Classical Risk Management
Definition of Risk" Rz.skAnalysis, 1:1, pg.II. Approaches."Information Systems Research, 9:3, pg.233"
Karolak Dale W. (1996)" Soare Engineering Risk March, J. and Shapira, Z" (1987)" "Managerial
Management. Los Alamitos, CA: IFFF ComputerSociety Perspectives on Risk and Risk taking." Management
Press. Science, 33:II, pg.1404.
Katzenbach, Jon R. and Smith, Douglas K. (1993a)- The Markus,M. L. and Keil, M (1994). "If we Bulid it, They
Discipline of Teams." Harvard Business Review, XXX, Will Come: Designing Information Sistems that Users
(March-April),pg-111-120. Wantto Use." S/oan Management Review, 35:4, pg. II.
Katzenbach, Jon R. and Smith, Douglas K. (1993b)" 7he McPartlin, J. P. (1992). "The Collapse of CONFIRM."
Wisdom of Teams. New York: Harper Business. /nformation Week, October 19, pg. 12.
Keil, Mark (1995)" "Pulling the Plug: Software Project Mehler, M. (1991). "Reining in Runaways." Information
Managementand the Problem of Project Escalation" M/S Week, December 16, pg. 20.
Quarterly, 19:4, pg. 421. Neitzel, August C., Jr. (1999). "Managing Risk
Keil, Mark and Montealegre, Ramiro (2000). "Cutting Management" Cross Talk: The Journal of Defense
your Losses: Extricating your Organization when Big Systems Engineering. Hill Air Force Base, Utah: Ogden
ALC, July.
QuaTIC'2OOI i 167
Rohner, Kurt (1998). Marketing in The Cyber Age: The (IDA Report R-338), Institute for Defense Analysis,
Why, The What and The How. Chichester, UK: John December.
Wiley & Sons, Ltd.
Ropponen. J. (1999). Software Risk Management:
Foundations, Principles and Empirical Findings
Jyvaskyla: JyvaskylaUniversity PrintingHouse, Finland.
Rosenberg, I inda H.; Hammer, Theodore and Oallo,
Albert (1999). Continuous Risk Managementat NASA."
Poceedings of the Applied Sofiware
Management/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 to
Use Teams to Improve QuaLizy.Joiner Associates, Inc.~
Schwartz, RobertJ. and Smith, Clifford (1993). Advanced
Strategies in Financial Risk Management. New Jersey;
Prentice Hall.
Scoy, Roger L" Van (1992). Sofhvare Development Risk..
Opportunity. Not Problem. Software Engineering
Institute, CarnegieMellon University, Pittsburg,PA.
SEI Software Engineering Insdtute (1992). "The SEI
Approach 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 Engineering
Congress, InternationalCost Engineering Council ICEC,
Oslo, Norway, August.
Standish Group International(1996). Chaos Chartz"ngthe
Seas of Information Technology. The Standish Group
International,West Yarmouth,MA.
USA Air Force (1988). Sofiware Risk Abatement. Air
Force Systems Command/Air Force Logistics Command
Pamphlet80045, September.
Van Genuchten, M. (1991). "Why is Software Late? An
Empirical Study of the Reason for Delay in Software
Development" IEEE Transactions on Sofnvare
Engineering, 17:6, pg.582.
Vesey, Joseph T. (1992). Time-to-Market: Put Speed in
Product Development " /ndustria/ Marketing
Management, Vol. 21, pg.151-158.
Walkerden, F~ and Jeffery, R. (1997). "Software Cost
Estimation: A Review of Models. Processes and
Fractice." Advances in Computers, Vol.44. San Diego:
Academic Press, pg.62.
Winner, RobertI.; Fennel, James P.; Bertrand,Harold E.
and Slusarczu, Marko M.G. (1988)" The Role of
Concurrent Engineering in Weapons Systems Acquisition.
168 / QuaTIC2001