泽井芽衣番号,国产高清视频在线播放www色,dasd409

軟件開發(fā)基本原則（四）—— 風險管理

admin

2012年4月9日 10:39 本文熱度 2648

　　1988年，Peat Marwick針對600家成功公司的調(diào)查結(jié)果顯示，35%的公司有過軟件項目失控的經(jīng)歷。（Rothfeder 1988）

　　1982年，Allstate公司宣布其公司運營全部要實行自動化。他們啟動了一個將耗時5年投資800萬美元的大型項目，而在花費了6年和1500萬美元后，Allstate公司重新調(diào)整了目標和最終期限，重新調(diào)整后的預(yù)算大約1億美元。

　　1988年，Westpac Banking公司決定重新設(shè)計他們的信息系統(tǒng)。他們做了5年、8500萬美元的計劃。3年后，在花費了1.5億美元卻依然收效甚微時，Westpac Banking公司為了減少損失，取消了這個項目，并為此裁員500人。（Glass 1992）

　　從項目管理的角度來看，有五大硬性知識領(lǐng)域：范圍管理、進度管理、成本管理、質(zhì)量管理和風險管理。風險會出現(xiàn)在前面四個領(lǐng)域的各個過程中，只有有效地消除可能發(fā)生的危險因素，才能確保項目順利推進。項目的風險貫穿于整個項目過程，因此整個項目的生命周期都應(yīng)該堅持有效的風險管理。

　　根據(jù)風險的內(nèi)容，可以把風險歸為以下幾類：

產(chǎn)品規(guī)模風險：與軟件的總體規(guī)模相關(guān)的風險
商業(yè)影響風險：商業(yè)風險影響到軟件開發(fā)的生存能力
客戶特性風險：與客戶的素質(zhì)以及開發(fā)者和客戶溝通能力相關(guān)的風險
過程定義風險：與軟件過程定義相關(guān)的風險
開發(fā)環(huán)境風險：與開發(fā)工具的可用性及質(zhì)量相關(guān)的風險
技術(shù)風險：技術(shù)風險是指在設(shè)計、實現(xiàn)、接口、驗證、維護、規(guī)約的二義性、技術(shù)的不確定性、陳舊的技術(shù)等方面存在的風險
人員數(shù)目及經(jīng)驗帶來的風險：與參與工作的軟件工程師的總體技術(shù)水平及項目經(jīng)驗相關(guān)的風險

　　軟件項目的風險主要體現(xiàn)在四個方面：需求、技術(shù)、成本、進度。風險管理是一個相當重要的話題，但涉及的問題太多，很難在本章中全部囊括，本章主要講述進度相關(guān)的風險管理。

風險管理要素

　　軟件風險管理就是在風險成為影響軟件項目成功的威脅之前，識別、處理并消除風險。可以在幾個層次上定位風險管理：

1、危機管理 — 救火模式，即在風險已經(jīng)造成麻煩后才著手處理它們

2、失敗處理 — 覺察到了風險并迅速做出反應(yīng)，但只是在風險發(fā)生之后

3、風險環(huán)節(jié) — 事先制定好風險發(fā)生后的補救措施，但不做任何防范措施

4、著力預(yù)防 — 將風險識別與風險防范作為軟件項目的一部分加以規(guī)劃和執(zhí)行

5、消滅根源 — 識別和消除可能發(fā)生的風險的根源

　　本章描述如何定位第4、5個層面上的進度風險管理。

　　總體來講，風險管理由風險評估和風險控制組成：

圖 5.1-1 風險管理由風險評估和風險控制組成

1. 風險評估

風險識別：建立一個潛在破壞項目進度的風險列表
風險分析：評估每一個風險出現(xiàn)可能性及其影響，判定風險的級別
風險優(yōu)先級：按風險影響大小排出一個風險優(yōu)先級列表，這個列表將作為風險控制的基礎(chǔ)

2. 風險控制

風險管理計劃：定制一個應(yīng)對每個重要風險的方案，同時應(yīng)確保每一個單獨的風險管理計劃相互之間以及與項目計劃之間保持一致
風險化解：執(zhí)行每一個重要風險所對應(yīng)管理計劃
風險監(jiān)控：對解決風險的過程進行監(jiān)控。還包括：識別新的風險，并將其加入到正在進行的風險管理進程；在風險列表中移除已經(jīng)化解的風險等工作

風險識別

1. 最常見的進度計劃風險

功能蔓延
需求鍍金或開發(fā)人員鍍金
質(zhì)量不穩(wěn)定
計劃過于樂觀
設(shè)計欠佳
銀彈綜合癥
研究導向的開發(fā)
人員薄弱
承包人導致的失敗
開發(fā)人員與客戶之間發(fā)生摩擦

2. 進度計劃風險列表

　　下面列出了詳盡的可能對軟件進度有負面影響的潛在風險。除了這里所列出的風險，大多數(shù)項目都有其特定的風險，如：

　　“Joe要退出項目組，除非可以允許他帶自己的小狗來上班，而管理層還沒有決定是否同意他這樣做”—— 這樣的風險就要靠自己識別了！

　　潛在的進度計劃風險： （資料來源：Gilb 1988、Boehm 1989 Pressman 1993、Thomsett 1993、Jones 1994）

類型	風險
1、計劃編制	1) 計劃、資源和產(chǎn)品定義全憑客戶或上層領(lǐng)導口頭指令，而且不完全一致 2) 計劃是優(yōu)化的，是“最佳狀態(tài)”（但不現(xiàn)實，只能算是“期望狀態(tài)”） 3) 計劃忽略了必要的任務(wù) 4) 計劃基于使用特定的小組成員，而那個小組成員其實指望不上 5) 在限定時間內(nèi)無法建成已定規(guī)模大小的產(chǎn)品 6) 產(chǎn)品規(guī)模比估計的要打（代碼行數(shù)、功能點或與前一產(chǎn)品規(guī)模的百分比） 7) 工作量大于估計數(shù)（代碼行數(shù)、功能點、模塊等） 8) 進度已經(jīng)拖延的項目在重新評估時過于優(yōu)化或忽略項目歷史 9) 過度的進度壓力造成生產(chǎn)力下降 10) 目標日期提前，但沒有相應(yīng)地調(diào)整產(chǎn)品范圍或可用資源 11) 一個任務(wù)的延時導致相關(guān)任務(wù)的連鎖反應(yīng) 12) 涉足不熟識的產(chǎn)品領(lǐng)域，花費在設(shè)計和實現(xiàn)上的時間比預(yù)期要多
2、組織和管理	1) 項目缺乏一個用凝聚力的最高領(lǐng)導人 2) 由于前期乏力，項目長時間被擱置 3) 解雇和削減開支導致項目小組能力下降 4) 僅由管理層或市場人員進行技術(shù)決策，導致計劃進度延長 5) 低效的項目組織結(jié)構(gòu)降低生產(chǎn)率 6) 管理層審查或決策的周期比預(yù)期的時間長 7) 預(yù)算削減打亂項目計劃 8) 管理層作出了打擊項目組積極性的決定 9) 非技術(shù)的第三方的工作比預(yù)期延長（預(yù)算批準、設(shè)備采購、法律審查等） 10) 計劃性太差，無法達到期望的開發(fā)速度 11) 項目計劃由于壓力而放棄，導致開發(fā)混亂低效 12) 管理層強調(diào)英雄主義而忽略客觀確切的狀態(tài)報告，錯過發(fā)現(xiàn)和改正問題的機會
3、開發(fā)環(huán)境	1) 設(shè)施沒有及時到位 2) 設(shè)施到位但不配套 3) 設(shè)施擁擠、雜亂或破損 4) 開發(fā)工具沒能及時到位 5) 開發(fā)工具不如期望的那樣有效 6) 開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計劃要求的性能 7) 開發(fā)人員需要長時間創(chuàng)建工作環(huán)境或切換新開發(fā)工具 8) 新開發(fā)工具的學習周期比預(yù)期的長，內(nèi)容繁多
4、最終用戶	1) 最終用戶堅持新的需求 2) 最終用戶對于最后交付的產(chǎn)品不滿意，要求重新設(shè)計或重做 3) 最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持 4) 最終用戶的意見未被采納，造成產(chǎn)品無法滿足最終用戶的期望而必須重做
5、客戶	1) 客戶堅持新的需求 2) 客戶對規(guī)則、原型和規(guī)格的審核和決策周期比預(yù)期的長 3) 客戶沒有或不能參與規(guī)劃和原型審查工作，導致需求不穩(wěn)定和耗時的變更 4) 客戶溝通或答復(fù)的時間比預(yù)期長 5) 客戶堅持技術(shù)決策而導致進度計劃延長 6) 客戶對開發(fā)進度管理過細，導致實際進展緩慢 7) 客戶提供的組件無法與開發(fā)的產(chǎn)品匹配，導致額外的設(shè)計和集成工作 8) 客戶提供的組件質(zhì)量欠佳，導致額外的設(shè)計、測試、集成和客戶關(guān)系管理工作 9) 客戶要求的支持工具和環(huán)境不兼容、性能差或功能不完善，導致生產(chǎn)率降低 10) 客戶不接受交付的軟件，盡管它滿足合同的條款要求 11) 客戶期望的開發(fā)速度無法達到
6、承包商	1) 承包商沒有按承諾交付組件 2) 承包商遞交的組件質(zhì)量低下無法滿足要求，必須再花時間改進 3) 承包商沒有買進項目開發(fā)需要的工具，進而無法提供需要的性能水平
7、需求	1) 需求已經(jīng)成為項目的基準，但變化仍在繼續(xù) 2) 需求定義欠佳，但進一步的定義會擴展項目的范疇 3) 添加額外的需求 4) 需求定義含糊的部分需要的處理時間比預(yù)期多
8、產(chǎn)品	1) 錯誤發(fā)生率高的模塊需要比預(yù)期更多的設(shè)計、實現(xiàn)和測試工作 2) 校正質(zhì)量低下的產(chǎn)品需要比預(yù)期更多的設(shè)計、實現(xiàn)和測試工作 3) 在一個或多個新興領(lǐng)域推過產(chǎn)品技術(shù)使得進度延長或不可預(yù)期 4) 由于軟件的功能錯誤使得需要重新設(shè)計和實現(xiàn) 5) 開發(fā)額外不需要的功能（鍍金）延長了計劃進度 6) 要滿足產(chǎn)品規(guī)模的要求，需要比預(yù)期長的時間，包括重新計劃、設(shè)計和實現(xiàn) 7) 嚴格要求與原有系統(tǒng)兼容，需要進行比預(yù)期更多的計劃、設(shè)計、實現(xiàn)和測試 8) 要與不受項目組控制的其他系統(tǒng)集成，導致無法預(yù)料的設(shè)計、實現(xiàn)和測試工作 9) 要求在不同操作系統(tǒng)或軟硬件環(huán)境下運行將花費比預(yù)期更長的時間 10) 在不熟識或未經(jīng)檢驗的軟件環(huán)境中運行，產(chǎn)生未預(yù)料到的問題 11) 在不熟識或未經(jīng)檢驗的硬件環(huán)境中運行，產(chǎn)生未預(yù)料到的問題 12) 開發(fā)一些全新的功能模塊比預(yù)期花費更長時間 13) 依賴未成熟的技術(shù)，使得進度延長或不可預(yù)期
9、外部環(huán)境	1) 產(chǎn)品依賴政府的政策或制度，而政策或制度不可預(yù)期 2) 產(chǎn)品依賴草擬中的技術(shù)標準，而最后的標準不可預(yù)期
10、人員	1) 招聘人員所花時間比預(yù)期長 2) 培訓、工作許可證或其他項目的收尾等作為先決條件的任務(wù)不能按時完成 3) 開發(fā)人員和管理層之間關(guān)系不佳導致決策緩慢影響進度 4) 項目組成員沒有全身心投入項目，進而無法達到要求的產(chǎn)品質(zhì)量水平 5) 缺乏激勵措施，士氣低下，降低生產(chǎn)力 6) 缺乏必要的規(guī)范，增加了工作失誤幾率和重復(fù)工作 7) 某些人需要更多時間適應(yīng)新的軟件工具和環(huán)境 8) 某些人需要更多時間適應(yīng)新的硬件工具和環(huán)境 9) 項目結(jié)束前，成員調(diào)離團隊或離職 10) 項目后期加入新開發(fā)人員，額外的培訓和溝通降低現(xiàn)有成員的生產(chǎn)率 11) 項目成員不能有效地一起工作 12) 項目組成員間有沖突，導致溝通不暢、設(shè)計欠佳、接口錯誤和額外的重復(fù)工作 13) 有問題的成員沒有調(diào)離項目組，損害了其他成員的積極性 14) 項目的最佳人選沒有加入項目組 15) 項目的最佳人選已加入項目組，但因政治或其它原因未能合理使用 16) 沒有找到項目急需的，具有特殊技能的人 17) 關(guān)鍵人物只能兼職參與 18) 項目人員不足 19) 任務(wù)的分配與人員技能不匹配 20) 人員工作的進度比預(yù)期的慢 21) 項目管理人員怠工導致計劃的進度失效 22) 技術(shù)人員怠工導致工作遺漏和質(zhì)量低下
11、設(shè)計和實現(xiàn)	1) 設(shè)計過于簡單，無法確定主要事件，并導致重新設(shè)計和實現(xiàn) 2) 設(shè)計過于復(fù)雜，導致一些不必要的工作，影響實現(xiàn)效率 3) 設(shè)計質(zhì)量低下，導致重復(fù)設(shè)計和實現(xiàn) 4) 使用不熟識的方法和技術(shù)，導致額外的培訓時間 5) 使用低級語言開發(fā)產(chǎn)品，導致生產(chǎn)率比預(yù)期低 6) 一些必要的功能無法使用現(xiàn)有的代碼或庫實現(xiàn)，必須采用新庫或重新實現(xiàn) 7) 代碼和庫質(zhì)量低下導致需要額外的測試、錯誤修正或重做 8) 過高估計了工具對計劃進度的節(jié)省量 9) 獨立開發(fā)的模塊無法有效集成，需要重新設(shè)計或重做
12、過程	1) 大量的書面工作導致進度比預(yù)期慢 2) 進度跟蹤不準確，導致無法預(yù)知項目是否已落后于計劃進度 3) 前期的質(zhì)量保證行為不真實，導致后期重復(fù)工作 4) 質(zhì)量跟蹤不準確，導致無法得知影響進度的質(zhì)量問題 5) 不夠正規(guī)（缺乏對軟件開發(fā)標準和策略的遵循），導致溝通不足和質(zhì)量問題 6) 過于正規(guī)（教條地遵循軟件開發(fā)標準和策略），導致過多耗時于無用的工作 7) 向管理層撰寫進度報告占用開發(fā)人員的時間比預(yù)期多 8) 風險管理不夠重視，導致沒有發(fā)現(xiàn)重大的項目風險 9) 軟件項目風險管理花費的時間比預(yù)期多

風險分析

1. 風險暴露量

　　一種很有用的風險分析方法就是風險暴露量。風險暴露量就是風險發(fā)生的概率乘以損失的程度。舉例來說：如果你認為“完成需求分析比原計劃延長4周的概率是30%”，那么風險暴露量就是4周*30%=1.2周。

風險	*發(fā)生概率*	*損失程度（周）*	風險暴露量（周）
計劃過于樂觀	50%	5	2.5
由于要完全支持自動從主機更新數(shù)據(jù)而造成的額外需求	5%	20	1.0
由于市場變化而增加額外的功能	35%	8	2.8
圖形格式子系統(tǒng)接口不穩(wěn)定	25%	4	1.0
設(shè)計欠佳——需要重新設(shè)計	15%	15	2.25
項目審批超過預(yù)計時間	25%	4	1.0
設(shè)施未能及時到位	10%	2	0.2
為管理層撰寫進程報告占用開發(fā)人員的時間比預(yù)期的多	10%	1	0.1
承包商的圖形格式子系統(tǒng)推遲交付	10~20%	4	0.4~0.8
新的編程工具沒有節(jié)省預(yù)期的時間	30%	5	1.5

表 5.3.1-1 風險暴露量

　　1) 評估損失程度

　　損失程度常常比發(fā)生概率更容易估算，在表5.3.1-1中，完全可能很精確地估計出由于增加“完全支持自動從主機更新數(shù)據(jù)”而增加的研發(fā)時間是20個月。如果有時損失程度不容易直接估算出來，還可以把損失分解為更小的部分分別進行估算，之后將各個小的獨立評估結(jié)果累加得出合計估算值。

　　2) 評估發(fā)生概率

　　估算發(fā)生概率比估算損失程度更具主觀性。有許多實踐方法可以提高主觀評估的精確度，例如：

由最熟識系統(tǒng)的人評估每個風險的發(fā)生概率，然后保留一份風險評估審核文件
每個人對風險進行獨立評估，然后討論評估的合理性，直到達成共識
使用“形容詞標準”，如非常可能、很可能、可能、或許、不大可能和不可能等，然后把口頭評估轉(zhuǎn)換成量化的評估

2. 項目的延期和緩沖

　　由于我們只談?wù)撨M度風險，所以可以累加所有的風險暴露量來得到項目總風險暴露量。這個項目的總風險暴露量為12.8~13.2周，這意味著，如果不做任何風險管理的話計劃可能要延期12.8~13.2周。如果例子中的項目歷時25周，那么超出預(yù)計值12.8~13.2周就很顯然要進行風險管理了。

風險優(yōu)先級

　　項目通常花費80%的金錢解決20%的問題，所以風險管理的重點是關(guān)注那最重要的20%的部分。（Boehm 1989）

　　如果只關(guān)注進度計劃風險而不是關(guān)注所有的風險，確定風險優(yōu)先級的工作就變得比較容易了。在風險評估表中按風險暴露量從大到小排序看看會得到什么結(jié)果：

序號	風險	*發(fā)生概率*	*損失程度（周）*	風險暴露量（周）
1	由于市場變化而增加額外的功能	35%	8	2.8
2	計劃過于樂觀	50%	5	2.5
3	設(shè)計欠佳——需要重新設(shè)計	15%	15	2.25
4	新的編程工具沒有節(jié)省預(yù)期的時間	30%	5	1.5
5	圖形格式子系統(tǒng)接口不穩(wěn)定	25%	4	1.0
6	由于要完全支持自動從主機更新數(shù)據(jù)而造成的額外需求	5%	20	1.0
7	項目審批超過預(yù)計時間	25%	4	1.0
8	承包商的圖形格式子系統(tǒng)推遲交付	10~20%	4	0.4~0.8
9	設(shè)施未能及時到位	10%	2	0.2
10	為管理層撰寫進程報告占用開發(fā)人員的時間比預(yù)期的多	10%	1	0.1

表 5.4-1 排序后的風險暴露量

　　排序后的風險評估表實際上就形成了一個粗略的風險優(yōu)先級列表。如果能成功地處理風險列表中的前5個風險，就有希望將超出預(yù)期計劃的時間減少10.05周，如果能成功地處理后5個風險，則只能將超出預(yù)期計劃的時間減少2.7~3.1周。一般情況下，你的時間最好花在風險列表中靠前的風險上。

　　表5.4-1的排序只是粗略的，你可能想將損失更大的風險排在優(yōu)先級更高的位置，確保他們不會發(fā)生（如：上表第6個風險）。

你也可以把一些關(guān)聯(lián)的風險排在比各自優(yōu)先級更高的位置，如表5.4-1中第5和第8個風險。讓承包商開發(fā)圖形格式子系統(tǒng)接口，其組合風險要遠大于它們各自的風險。

　　這里確定的風險優(yōu)先級是比較粗糙的，因為用于確定風險的數(shù)據(jù)都是估計的，因此優(yōu)先級本身也就是個相對主觀的值。所以，對風險的客觀公正態(tài)度，是風險管理必要的組成部分。

風險管理計劃

　　編制風險管理計劃的重點是制定一個計劃，以處理風險分析中確定的高優(yōu)先級風險。風險管理計劃可以簡單地理解為一段一段的風險管理描述，如：每個風險的起因，表現(xiàn)形式，可能發(fā)生的時間、地點，為什么發(fā)生以及怎樣發(fā)生等。風險管理計劃同時也包含：監(jiān)控風險，處理新風險，關(guān)閉已化解的風險等計劃內(nèi)容。

風險化解

　　特定風險的化解在許多情況下都決定于特定風險本身，下面列出一些化解風險的一般方法：

　　1、 避免風險

　　不要做冒險的活動。例如，你的項目進度比較緊，有一個工具提供商聲稱它的工具能提高你的開發(fā)速度，但是你的團隊成員從來沒使用過這個工具，這時你就不應(yīng)該冒險采用這個工具。首先該工具不一定像它聲稱的那樣好，其次對工具的學習和熟識需要一個過程，如果冒險用它很可能會得不償失。

　　2、 轉(zhuǎn)移風險

　　有時，項目某部分的風險對項目另一部分來說卻不是風險，因此可以將它轉(zhuǎn)移到另一部分。例如，可以負責大部分的系統(tǒng)設(shè)計工作，但不要承擔不熟識的部分的設(shè)計工作，讓比較有把握的人負責設(shè)計這部分。

　　3、 購買風險相關(guān)信息

　　如果不能確切知道風險的嚴重性，可以做一些調(diào)研。也可以請外面的咨詢顧問幫你進行評估。

　　4、 消除產(chǎn)生風險的根源

　　例如，系統(tǒng)中某部分的設(shè)計可能面臨嚴重的問題，可將其作為一個研究項目徹底重新設(shè)計。

　　5、 接受風險

　　如果風險的后果較小，而處理它的成本太高，那么可以接受這個風險，不做任何處理。

　　6、 發(fā)布風險

　　讓上級領(lǐng)導、市場人員、客戶知道有關(guān)的風險以及可能的后果。這樣，即使風險真的發(fā)生了，他們也不會感到太驚訝。

　　7、 控制風險

　　定制計劃應(yīng)對風險無法化解的情形。例如分配額外的資源來測試設(shè)計中令人擔心的那部分系統(tǒng)，并留出額外時間處理測試發(fā)現(xiàn)的問題。

　　8、 記住風險

　　總結(jié)項目相關(guān)的風險及其處理辦法、處理效果等，為未來的項目建立一組風險管理計劃。

風險	控制方法
1、功能蔓延	a) 使用基于用戶的實踐 b) 使用增量開發(fā)實踐 c) 控制功能集 d) 采取針對變更的設(shè)計
2、需求鍍金或開發(fā)人員鍍金	a) 修正需求 b) 時間鎖定開發(fā) c) 控制功能集 d) 使用舍棄原型實踐 e) 基于進度表的開發(fā)
3、質(zhì)量低劣	a) 給QA留出時間，注重質(zhì)量保證基礎(chǔ)
4、計劃過于樂觀	a) 采用多估算實踐 b) 多個估算員和自動估算工具有原則地進行談判 c) 基于進度表的開發(fā) d) 使用增量開發(fā)實踐
5、設(shè)計低劣	a) 要有清晰的設(shè)計活動和足夠的設(shè)計時間 b) 進行設(shè)計檢查
6、銀彈綜合癥	a) 要有一定的生成率要求 b) 建立軟件量度計劃 c) 建立軟件工具庫
7、研究導向的開發(fā)	a) 不要試圖進行研究的同時強調(diào)加快開發(fā)速度 b) 使用基于風險的生命周期模型警惕地進行風險管理
8、人員薄弱	a) 招募頂尖人才 b) 項目開始前招聘或預(yù)定關(guān)鍵成員 c) 培訓 d) 團隊建設(shè)
9、承包商失敗	a) 檢查參考資料 b) 外包前分析承包商能力 c) 積極管理承包商
10、開發(fā)人員與客戶發(fā)生摩擦	a) 采用面向進度的實踐