所有風險分析活動都只有一個目的--輔助專案組建立處理風險的策略。一個有效的策略必須考慮三個問題：

· 風險避免
· 風險監控
· 風險管理及意外事件計劃

如果軟體專案組對於風險採取主動的方法，則避免永遠是最好的策略。這可以透過建立一個風險緩解計劃來達到。例如，頻繁的人員流動被標註為一個專案風險，基於以往的歷史和管理經驗，人員流動的機率為70％，而影響被預測為對於專案成本及進度有嚴重的影響。為了緩解這個風險，專案管理者必須建立一個策略來降低人員流動。可能採取的策略如下：

· 與現有人員一起探討一下人員流動的原因（如惡劣的工作條件，低報酬，競爭激烈）
· 在專案開始之前，採取行動以緩解那些在管理控制之下的原因。
· 一旦專案啟動，假設會發生人員流動並採取一些技術措施以保證當人員離開時的工作連續性。
· 對專案進行良好組織，使得每一個開發活動的資訊能被廣泛傳播和交流。
· 定義文件的標準，並建立相應的機制，以確保文件能被及時建立。
· 對所有工作進行詳細複審，使得不止一個人熟悉該項工作。
· 對於每一個關鍵的技術人員都指定一個後備人員。

隨著專案的進展，風險監控活動開始進行。專案管理者監控某些因素，這些因素可以提供風險是否正在變高或變低的指示。在上例中，應該監控下列因素：

· 專案組成員對專案壓力的一般態度。
· 專案組的凝聚力。
· 專案組成員彼此之間的關係。
· 與報酬和利益相關的潛在問題。
· 在公司內及公司外工作的可能性。

除了監控上述因素之外，專案管理者還應該監控風險緩解步驟的效力。例如：上例中，風險緩解步驟要求定義"文件的標準，並建立相應的機制，以確保文件能被及時建立"。如果有關鍵的人物離開了專案組，這是保證工作連續性的機制。專案管理者應該仔細地監控這些文件，以保證文件內容正確，當新員工加入該專案時，能為他們提供必要的資訊。

風險管理及意外事件計劃假設緩解工作已經失敗，風險變成了現實。繼續前面的例子，假定專案正在進行中，有一些人宣佈將要離開。如果按照緩解策略行事，則有後備人員可用，因為資訊已經文件化，有關知識已經在專案組中廣泛進行了交流。此外，專案管理者還可以暫時重新將資源調整到那些需要人的地方去，並調整專案進度，從而使新加入的成員能夠"趕上進度"。同時，要求那些要離開的人員停止工作，進入"知識交接模式"。

RMMM步驟將導致額外的專案開銷。因此，風險管理的部分任務是評估何時由RMMM步驟所產生的效益低於實現它們所花費的成本。本質上是講，專案計劃者執行一個典型的成本－效益分析來估算專案開銷變化情況。

對於一個大型專案，可能會標識出30－40種風險。如果為每種風險定義三至七個風險管理步驟，則風險管理本身就可能變成一個"專案"。經驗表明：整個軟體風險的80％（即可能導致專案失敗的80％潛在的因素）能夠由僅僅20％的已知風險來說明。早期風險分析步驟中所實現的工作能夠幫助計劃者確定哪些風險在所說的20％中。

1、安全性風險和危險

風險不僅限於軟體專案本身。在軟體已經能夠交付客戶之後，仍有可能發生風險。這些風險一般與領域中的軟體失敗相關。

雖然一個良好的系統發生錯誤的機率很小，但是基於計算機的控制及監督系統中未被發現的錯誤可能會導致巨大的經濟損失，或者更加嚴重

當軟體被用作控制系統的一部分時，複雜性會以數量級增加。由於人的錯誤所引起的微小的設計缺陷，在使用軟體時會變得難以發現。

軟體安全和危險分析是屬於軟體質量保證活動，它主要是用來標識和評估可能對軟體產生負面影響並使整個系統失敗的潛在危險。如果能夠在軟體工程的早期階段標出危險，則可以指定軟體設計特徵來消除或控制潛在地危險。

2、RMMM計劃

風險管理策略可以包含在軟體專案計劃中，或者風險管理步驟也可以組織成一個獨立的風險緩解、監控和管理計劃（RMMM計劃）。RMMM計劃將所有風險分析文件化，並由專案管理者作為整個專案計劃中的一部分來使用。RMMM計劃的大綱如下：

Ⅰ.引言

文件的範圍和目的
主要風險綜述
責任

a.管理者
b.技術人員

Ⅱ.專案風險表

終止線之上所有風險的描述
影響機率及影響的因素

Ⅲ.風險緩解、監控和管理

緩解
一般策略
緩解風險的特定步驟
監控
被監控的因素
監控辦法
管理
意外事件計劃
特殊的考慮

Ⅳ.RMMM計劃的迭代時間安排表

Ⅴ總結
[@more@]

專案風險緩解、監控和管理（轉）

相關文章