RUP之風險管理(摘自RUP)

簡介 “有備無患。”－ Hamlet V:ii:215 項目就像生活一樣，是不確定的。我們不是為了識別風險而識別風險，而是儘可能要預見和降低風險，或在我們的降低策略不足時響應風險。 風險推動了反覆項目計劃；迭代是圍繞著處理特定風險而計劃的，嘗試限制風險或減少風險。定期複審風險列表可評估風險降低策略的效用，這反過來又推動了專案計劃的修訂及隨後反覆項目計劃的修訂。 管理風險的關鍵不是等到風險成為事實（並成為問題或故障）後才決定如何處理。就像在洲際飛行中失之毫釐則謬以千裡一樣，較早地管理風險幾乎總是比事後清理代價更低，麻煩更小。 風險管理策略 有三種主要策略 [BOE91]： 避開風險。重新組織項目，使其不會受該風險的影響。 轉移風險。重新組織項目，使其他人或事承擔該風險（客戶、供應商、銀行、另一元素等）。一種特定的避開風險策略。 接受風險。決定忍受風險，作為一種偶然情況。監視風險癥狀並確定一個出現風險時的應急計劃。 如果決定接受該風險，您仍可能希望降低該風險，即採取某種直接措施來減少其影響。 風險的類型 區分直接風險和間接風險是很重要的。簡而言之，直接風險是我們能在某種程度上控制的風險；間接風險是我們無法控制的風險。 儘管不應該對間接風險一無所知，但它們在實踐意義上是無關緊要的：既然無法更改它們，對它們有所顧慮也無濟於事。儘管可能明天就是世界末日， 但也可能不是世界末日，如果不是的話，我們最好繼續做好手上的事情！ 有時，間接風險可能實際上是偽裝起來的直接風險。例如，我們可能依靠某個外部供應商提供一個組件或一組組件。這似乎是間接風險，但通過針對這些組件的應急計劃，我們可以控制該風險：我們可以選擇替代供應商，或我們可以選擇自行開發功能。在許多情況下，我們比想像中的更有控制權！ 對於間接風險，您要麼必須找出如何對這些風險獲得某種程度的控制的辦法，要麼只是記下它們並繼續。對您無法改變的東西牽腸掛肚是沒什麼意義的。 資源風險 組織 對此項目是否有足夠的投入（包括管理層、測試人員、QA 和其他的外部相關各方）？ 這是否是該組織曾嘗試過的最大項目？ 是否有明確定義的軟體工程流程？是否有明確定義的需求捕獲和管理？ 撥款 撥款是否到位、可以完成項目？ 是否分配了用於培訓和指導的撥款？ 是否有預算限制，這樣系統就必須按固定的成本交付、否則取消？ 成本估計是否精確？ 人員 是否有足夠的人員？ 他們是否有適當的技能和經驗？ 他們以前是否合作過？ 他們是否相信該項目可以取得成功？ 是否有使用者代表進行複審？ 是否有領域專家？ 時間 時間表是否現實？ 是否可按時間表管理功能的範圍？ 交付日期的緊急程度如何？ 是否有時間“正確行事”？ 業務風險 如果競爭者先進入市場，怎麼辦？ 如果項目撥款受到威脅，怎麼辦（看待這個問題的另一方式是詢問“怎樣確保撥款充足”）？ 系統的計劃價值是否大於規劃成本？（務必考慮到金錢的現值和投資的成本）。 如果無法與主要供應商簽訂合約，怎麼辦？ 技術風險 範圍風險 是否可以度量成功？ 是否有關於如何度量成功的一致意見？ 需求是否相當穩定並得到清楚的理解？ 專案範圍是固定的還是一直在擴充？ 項目開發時間範圍是否短暫而不靈活？ 工藝風險 該技術是否已得到證明？ 重用目標是否合理？ 工件必須在使用一次後才能重用。 一個組件能需要發行好幾個發行版，然後其穩定性才足以重用而不需要重大更改。 需求中的事務量是否合理？ 事務率估計值是否可信？是否過於樂觀？ 資料量是否合理？它們是否可儲存在當前可用的大型主機中，或者，如果需求讓您相信工作站或部門系統將是設計的一部分，資料是否可在那裡合理儲存？ 是否有不常見的或挑戰性的技術需求，要求項目團隊處理他們不熟悉的問題？ 成功取決於新的或未經嘗試的產品、服務或技術、新的或未經證明的硬體、軟體還是工藝？ 是否有對其它系統（包括企業外的系統）介面的外部依賴性？必需的介面是否存在還是必須建立它們？ 是否有極不靈活的可用性和安全性需求（例如，“系統必須永不失敗”）？ 系統的使用者是否對正在開發的系統的類型沒有經驗？ 是否由於應用程式的規模或複雜性或者技術的新穎性而增加了風險？ 是否要求本地語言支援？ 是否可能設計、實施和運行此系統？有些系統只是由於過於龐大或複雜而無法正常工作。 外部依賴性風險 項目是否依賴於其它（並行的）開發項目？ 成功是否依賴於成品產品或外部開發的組件？ 成功是否依賴於開發工具（設計工具、編譯器等）、實施技術（作業系統、資料庫、流程間溝通機制等）的成功整合。您是否有在沒有這些技術的情況下交付項目的備份計劃？ 時間表風險 經驗表明，85% 的風險對時間表有著直接或間接影響，因此肯定對成本有影響。可能其中的 5% 僅有成本影響。其餘部分對成本或時間表沒有任何直接影響，但對品質（舉例）有直接影響。 如果截止期限是大敵，則在平穩接近該期限的過程中進行遞增的交付。避免為了努力符合時間表而進行一次性大量交付。 某些項目具有真正的“突然死亡”截止期限。例如，要在選舉之夜“現場”分析選舉結果的軟體，如果在選舉後的一周才開發出來，那就沒什麼價值了。或者您的軟體可能被競爭者所超越：它們將一個更好的產品投放市場，而您還處在構建過程中。突然之間，您出局了 － 並且您對這種情況無能為力。但總的來說，很少有項目具有這樣緊迫的截止期限。延遲通常影響到成本。 總的來說，您承諾的時間表應等於您的最佳估計情況加上一些合理的偶然情況。 承諾 = 估計 + 偶然 其他人曾建議將時間表期望設定為相當於您的退路策略，即，基於您的應急計劃設定時間表期望，但這有點過於悲觀了，因為並不是所有風險都將成為事實。 時間表風險集中在一些估計和成本計算工具中。例如，在 COCOMO 模型中，有許多成本驅動因素，例如： 複雜性（cplx） 即時約束（time） 儲存約束（stor） 經驗（Vexp） 好工具的可用性（tool） 時間表壓力（sced） 是實際的風險因素。