軟件項目風險管理的協同過程模型

摘要：軟件項目的開發有很高的失敗率。從20世紀80年代后期開始，軟件理論界和產業界開始重視軟件的風險管理，并產生了一系列的風險管理過程模型，這些模型對風險管理的規范有積極的意義。文章回顧了風險管理模型的發展，發現目前的軟件項目開發風險管理模型只強調承包工程方過程，而較少關注建設方的參與。這將帶來二方面的不足：第一，建設方對項目的參與是成功的重要保證，沒有建設方的參與的管理過程是不完整的。第二，在信息不對稱的情況下，軟件項目的開發風險被轉移到建設方身上。為了有效解決目前模型的不足，文章在原有的風險管理模型基礎上建立軟件項目的建設方和承包商風險管理的協同過程模型，并設計了相關的數據結構和項目干系人在項目周期的不同階段的參與情況。

關鍵詞：軟件項目；風險管理；協同；過程

一、 引言

軟件產業是全球發展最快的產業，對國家發展力影響深遠。全球的軟件產值從1985年的1 400億美元，增長到1995年的4 500億美元，到2005年達到14 000億美元，成為最大的產業。軟件是信息化產品中是最具有知識密集和核心競爭力的部分，是信息化的核心工作和前提，對增強國家綜合競爭力的意義十分重大。然而，軟件項目的開發卻有很高的失敗率。根據Standish Group對美國超過8 000個民用軍用的各種軟件項目的調查，1996年，2000年和2004年的軟件成功率分別為27%，28%和29%，其他則是部分或者完全失敗的。世界銀行的統計表明：在發展中國家的政府信息系統項目中，只有15%是完全成功的。因此，加強軟件項目開發中的風險管理是軟件開發中的最重要的工作之一，尤其對于大型的軟件項目，軟件風險管理的奠基人之一，Charatte認為大型軟件項目的管理就是風險管理。Microsoft的量化研究表明，在風險管理中投入5%的項目工作可以獲取50%~75%的如期完成的機會。可見風險管理在軟件開發中的重要性。風險管理的研究在起源于20世紀80年代末，經過二十多年的發展，產生了大量的理論成果并對軟件項目的開發起到積極的作用。其中，風險管理的過程研究是風險管理的框架和基礎，為風險管理提供規范的模式。本文在分析現有研究的基礎上建立軟件項目的建設方和承包商風險管理的協同過程模型，以實現更加完整的規范的風險管理。

二、 風險管理過程模型的比較

1． Boehm模型：Boehm于1991年詳細描述了他的思想體系。Boehm認為：軟件風險管理這門學科的出現就是試圖將影響項目成功的風險形式化為一組易用的原則和實踐的集合，是在風險成為軟件項目返工的主要因素并由此威脅到項目的成功運作前，識別、描述并消除這些風險項。他將風險管理過程歸納成二個基本步驟：風險評估和風險控制。其中風險評估包括風險識別、風險分析、風險排序；風險控制包括制定風險管理計劃、解決風險、監控風險。

Boehm風險管理理論的核心是維護和更新十大風險列表。他通過對一些大型項目進行調查總結出了軟件項目十大風險列表，其中包括人員短缺、不切實際的工期和預算、不合時宜的需求、開發了錯誤的軟件功能、開發了錯誤的用戶界面、過高的非實質性能要求、接連不斷的需求改變、可外購部件不足、外部已完成任務不及時、實時性能過低和計算機能力有限。在軟件項目開始時歸納出現在項目的十大風險列表，在項目的生命周期中定期召開會議去對列表進行更新、評比。十大風險列表是讓高層經理的注意力集中在項目關鍵成功因素上的有效途徑，可以有效地管理風險并由此減少高層的時間和精力。

2． Charette模型：1989年Charette設計的風險分析和管理的體系分為兩大階段，分別為分析階段和管理階段，每個階段內含三個過程，這是一個相互重疊和循環的模型。Charette同時為各個過程提供了相應的戰略思路、方法模型和技術手段。

3． CMU/SEI的CRM（Continuous Risk Management）持續風險管理模型：CMU/SEI的軟件風險管理原則包括：（1）全局觀點；（2）積極的策略；（3）開放的溝通環境；（4）綜合管理；（5）持續的過程；（6）共同的目標；（7）協調工作。具體來說是要不斷地評估可能造成惡劣后果的因素；決定最迫切需要處理的風險；實現控制風險的策略；評測并確保風險策略實施的有效性。CRM模型要求在項目生命期的所有階段都關注風險識別和管理，它將風險管理劃分為五個步驟：風險識別、分析、計劃、跟蹤、控制。它強調的是對風險管理的各個組成部分的溝通。

4． IEEE風險管理標準：IEEE風險管理標準定義了軟件開發生命周期中的風險管理過程。這個風險管理過程系統地描述和管理在產品或服務的生命周期中出現的風險。包括以下活動：計劃并實施風險管理、管理項目風險列表、分析風險、監控風險、處理風險、評估風險管理過程。

5． CMU/SEI的CMMI（Capability Maturity Model Integration）風險管理過程：CMMI是由SEI在CMM基礎上發展而來。目前，CMMI是全球軟件業界的管理標準。風險管理過程域在CMMI的第三級，即已定義級中建立一個關鍵過程域（KPA，Key Practice Area）。CMMI認為風險管理是一種連續的前瞻性的過程。它要識別潛在的可能危及關鍵目標的因素，以便策劃應對風險的活動和在必要時實施這些活動，緩解不利的影響最終實現組織的目標。CMMI的風險管理被清晰地描述為實現三個目標，每個目標的實現又通過一系列的活動來完成，如圖1示。

該模型的核心是風險庫，實現各個目標的每個活動都會更新這個風險庫。其中活動“制訂并維護風險管理策略”與風險庫的聯系是一個雙向的交互過程，即通過采集風險庫中相應的數據并結合前一活動的輸入來制訂風險管理策略。

6． Microsoft的MSF風險管理模型：MSF（Microsoft Solutions Framework）的風險管理思想是，風險管理必須是主動的，它是正式和系統的過程，風險應被持續評估、監控、管理，直到被解決或問題被處理。該模型最大的特點是將學習活動溶入風險管理，強調了學習以前項目經驗的重要性。

它的風險管理原則是：（1）持續的評估；（2）培養開放的溝通環境：所有組成員應參與風險識別與分析；領導者應鼓勵建立沒有責備的文化；（3）從經驗中學習：學習可以大大降低不確定性；強調組織級或企業級的從項目結果中學習的重要性；（4）責任分擔：組中任何成員都有義務進行風險管理。

7． Riskit模型：Maryland大學的Kontio提出Riskit方法，該方法對于風險管理中的每個活動都提供了詳細的活動執行模板，包括活動描述、進入標準、輸入、輸出、采用的方法和工具、責任、資源、退出標準。Riskit方法包括以下內容。（1）提供風險的明確定義：損失的定義建立在期望的基礎上，即項目的實際結果沒有達到項目相關者對項目的期望的程度；（2）明確定義目標、限制和其它影響項目成功的因素；（3）采用圖形化的工具Riskit分析圖對風險建模，定性地記錄風險；（4）使用應用性損失的概念排列風險的損失；（5）不同相關者的觀點被明確建模。

8． SoftRisk風險管理模型：Keshlaf和Hashim提出SoftRisk模型，其主要思想是，記錄并將注意力集中在高可能性和高破壞性的風險上是進行風險管理的有效途徑。目標是在有效地減輕風險的破壞性的前提基礎上，節省軟件開發過程中的時間成本和人力成本。該模型包括以下步驟：（1）風險識別；（2）風險發生的可能性和由此造成的損失估計；（3）文檔化識別的風險；（4）風險評估，依據公式：RE=風險發生的概率*風險造成的損失；（5）排序，按照上述公式對風險排序，找出十大風險；（6）監控，利用圖形表示風險的級別、狀態；（7）控制，再估計——再評估——再排序；（8）統計操作，如果有新的風險，則再轉到步驟1。

三、 軟件項目風險管理協同過程模型

1． 風險管理模型的對比較。以上八個軟件項目風險管理模型雖然在表達形式上有所不同，但基本按照風險的識別，估計，分析，計劃，控制和監督六步來完成的。在這個共同的基礎上，有些模型強調量化的數據庫的建立，有些則強調溝通和學習的重要性。各模型特點比較分析如表1示。

表1經典風險管理模型比較

另外，從上述軟件項目風險管理模型的比較當中，我們不難發現，目前這些風險管理模型只是強調承包工程方的努力，而比較少關注建設方的參與。這將帶來二方面的不足：第一，建設方對項目的參與是成功的重要保證，沒有建設方的參與的管理過程是不完整的。第二，在信息不對稱的情況下，軟件項目的開發風險被轉移到建設方身上。這種風險的轉移是隱秘的，在軟件項目中容易被忽略，難以被識別、控制與消除，由此可能導致軟件項目只有產出沒有效益。聯合國在2003年“處于十字路口的電子政務”的報告中，把電子政務劃分為三類：第一類，浪費的電子政務，即“有投入，無產出”；第二類，無目標的電子政務，即“有產出，無效益”；第三類，有意義的電子政務，即“有產出，有效益”。造成第二類無目標的電子政務的一個根本原因就在于缺乏從建設方的角度考慮軟件項目的風險管理。

2． 軟件項目風險管理的協同過程模型。為了從項目的風險管理過程上解決以上問題，使軟件項目既有產出又有效益，我們對廣州地區的二十位項目經理和軟件產業界專家，包括軟件承包方項目經理，軟件客戶方項目領導和第三方咨詢顧問。其中包括完整的三方參與即包括承建方、建設方和第三方的項目實例共有九個，其余由于項目太小沒有第三方參與。這些軟件項目產出在系統質量，用戶滿意度，組織影響和按計劃的時間和費用交付都比較令人滿意。這些成功的項目有共同的特征，即強調項目三方協同與溝通。我們嘗試根據訪談建立軟件項目風險管理協同的過程模型。

在風險管理的基本過程中，協同過程模型與現有模型是一致的，分識別、估計、分析、計劃、控制和監督六步，但是，協同模型與現有模型的一個重要區別在地強調建設方，承包方和第三方的介入。其模型如圖2所示。

圖2風險管理協同過程概念模型

被訪問項目在整個軟件項目的風險管理過程中，項目的參與者包括建設方、開發承包商，實施顧問公司，管理顧問公司，監理公司。項目的全流程和各個項目參與者在項目的生命周期如表5所示。在這九個項目中全部為外包項目，其中有九個項目有八個引入了項目顧問，八個項目進行了項目監理，如表2所示。

四、 結論

本文在回顧目前的軟件項目風險管理過程模型的基礎上，發現其不足，并建立了軟件項目風險管理的協同過程模型。協同過程模型由關鍵風險域、關鍵風險域的表達特征以及項目干系人三個維度組成。協同過程模型的建立，對軟件項目承建方、建設方以及第三方實現全方位的風險管理，一方面，有利于建設方在信息更完全的條件下進行項目建設，利于項目的成功；另一方面風險管理協同過程模型可以打破組織內外和組織部門之間的邊界，在信息更加充分和透明條件下進行項目的管理，有利于利益的協調，實現軟件項目的雙贏。此外，協同過程模型的建立有利于管理資源的整合，以保證風險管理的效率，項目風險管理的參與者可以在全盤的視角對項目的風險進行識別和管理，利于項目的交流，利于資源的整合和風險的管理。

表2項目干系人在項目周期的不同階段的參與

參考文獻：

1．John Mcmanus，Risk Management in Software Development Projects．Elservier，2004．

2．The Standish Group，extreme chaos．www．Standishgroup．com，2001．

3．The Standish Group，2004 Third Quarter Research Report．www．standishgroup．com，2004．

4．Robert N．Charette，Large—Scale Project Management Is risk Management，IEEE Software，1996，（7）：110-117．

5．Steve McConnell．Software Project Survival Guide，Microsoft Press，1997．

6．IEEE Computer Society，IEEE Standard for Software Life Cycle Processes—Risk Management，2001．

7．CMU/SEI CMMI Product Team，CMMI for Systems Engineering，Software Engineering，Integrated Product and Process Development，and Supplier Sourcing （CMMI—SE/SW/IPPD/SS，V1．1），CMU/SEI—2002—TR—011，March 2002．

8．Microsoft Solutions Framework White Paper．MSF Risk Management Discipline．V1．1．2002．

重點項目：廣東省軟科學研究項目（批準號2005B70101096）階段性成果。

作者簡介：謝康，中山大學管理學院副院長、教授、博士生導師；胡勇，中山大學管理學院博士生；肖靜華，中山大學嶺南學院副教授，中山大學管理學院博士生。

收稿日期：2007-02-18。

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”