參與過大型宜昌軟件開發項目的人都會認識到許多事情都可能出錯，一但出錯就可能給項目帶來危害、損失或其它不利影響。風險是在項目中發生的一系列事件或不利結果的可能性。軟件開發是一項高風險的活動，在項目開發過程的任何一個階段都可能存在風險。采取積極的風險管理方式，可以使項目進程更加平穩，可以獲得很高的跟蹤和控制項目的能力，可以規避、轉移風險，或緩解風險帶來的不利影響。風險管理是對項目風險進行識别、分析、應對和監控的過程，是項目管理中很重要的管理活動，有效的實施軟件風險管理是軟件項目開發工作順利完成的保證。風險管理的達成必須包括三個要素:

首先，在項目開發計劃中必須制定風險管理計劃;

第二，在項目預算中必須包含解決風險所需的經費;

第三，評估風險時，風險的影響也必須納入項目計劃中。

下面就軟件開發過程中經常發生的風險，談談我們采取的預防措施。

1、需求不明确

需求不明确是軟件開發過程中經常可能遇到的問題，這類問題往往表現在需求範圍未界定、需求未細化、需求描述不清楚、需求遺漏、需求互相矛盾等多個方面。在軟件開發過程的生命周期各階段中，需求不明确所造成的浪費是Z大的，必須盡早盡可能解決。确定用戶需求是件非常困難的事情，我們常常從以下幾個方面着手處理需求不明确問題:

(1) 讓用戶參與開發

提供一個協作開發環境，讓用戶參與開發過程。如果條件不允許，至少應該在每次疊代的需求分析和系統測試階段，讓客戶能夠參與開發。

在選擇參與開發過程的用戶時，一方面，要盡可能争取精通業務或計算機技術的用戶參與。另一方面，如果開發的産品要在不同規模、不同類型的企業應用，應該選擇具有代表性的用戶參與。

僅僅讓用戶參與是不夠的，應該采取一定的激勵措施，提高用戶參與的積極性。

(2) 開發用戶界面原型

用戶通常不善于精确描述自己的業務需求，系統分析員需要借助白闆、白紙等溝通方式，幫助用戶清楚表述需求。然後，開發一個用戶界面原型，以便用戶确認需求。用戶界面原型的作用僅僅是收集用戶需求，不應該再作它用，也不要給用戶造成系統快要實現的錯覺。

(3) 需求讨論會議

對于用戶分布廣、用戶量大的項目，要全面收集用戶需求，往往很困難，通常采取需求研計會議方式進行需求确認。通過在會議前幾周調查各地、各部門用戶需求意見，然後集中各地或各部門的用戶代表，舉辦一次需求研讨會，通過會議方式收集需求。本方法适合于具有一定信息系統使用經驗的用戶。

(4) 強化需求分析與評審

首先，需求分析是項目成功的基礎，需要引起足夠的重視，并分配充足的時間和人力，要讓有經驗的系統分析員負責，切忌讓項目新手或程序員負責。其次，要進行需求評審，盡可能讓用戶參與需求評審，不要讓需求評審流于行式。第三，也是Z重要的一點，通過評審的需求規格說明書，要讓用戶方簽字，并作為項目合同的附件，對雙方都具有約束力。在公司内部要将通過評審的需求規格說明書，納入配置管理。

2、項目缺少可見性

當一個項目經理或一名開發者說已經完成了80%的任務，您必須保持審慎的态度。因為剩下的20%可能還需要80%的時間，甚至永遠都不能完成。軟件開發項目，往往在項目進度和軟件質量方面缺少可見性，項目越缺少可見性，項目就越難以控制，項目就越有可能失敗。我們可以通過疊代開發、技術評審、持續集成來增強項目的可見性。

(1) 疊代開發

采用疊代的開發模型，将産品的交付過程分為多個階段，按照功能遞增式交付。以下是一些典型的疊代:

一次簡短的先期疊代，以建立規模和前景并确定商業理由;

一次精化疊代，其間将為穩定的構架劃定基線;

一次構建疊代，其間将實現用例并充實構架;

幾次産品化疊代，将産品轉移到用戶群。

每次疊代，都要充分接收用戶的評審意見，以便為自我糾正。漸近式的功能交付，有利于降低開發人員的壓力，增加用戶的滿意度，有利于增強項目的可見性，是Z好的進展報告。

(2) 技術評審

技術評審是确保軟件質量的重要環節，技術評審包括代碼走查、會議評審和同行專家評審。代碼走審可以是開發人員之間的交叉審查，或者是高級開發人員對普通開發人員的審查;會議評審一般應至少每兩周進行一次，每次評審時間不宜太長;同行專家評審包括技術和業務兩個方面的專家，經常性地讓精通業務的用戶專家參與項目評審，是項目成功的重要保證。

另外，充分利用質量審查的工具軟件，也有利于提高代碼質量。例如:在Eclipse開發環境中，可以集成Findbug、Checkstyle、PMD插件檢查代碼編寫質量。

(3) 持續集成

持續集成能夠把Z終的一次大規模的集成調試過程分散到項目開發時間表的每一周、每一天、甚至每個小時。讓項目中的各個人員都能夠随時掌握當前的整體進度，并迅速發現集成過程中出現的問題并進行解決[1]。

開發小組應制定持續集成的制度，一般情況下每日構建一次，可以利用Ant等構建工具進行Java應用程序的構建。小組成員應在每個功能開發完成後，及時向版本控制系統(如CVS)提交代碼，而且不應該向版本控制系統提交有問題(編譯通不過)的代碼。

每日構建、持續集成，讓項目進度跟蹤工作更加容易。當項目小組每天重新編譯系統時，已完成與未完成的功能清楚可見，小組成員能夠簡單地從軟件的表現知道距離整體完成還有多遠。

3、新技術引入

技術創新是一種具有探索性、創造性的技術經濟活動。在開發過程中引入新技術，不可避免地要遇到各種風險。通過T形軟件開發、充分論證、多階段評審、同行經驗等措施可降低新技術風險。

(1) T形軟件開發

在項目開發早期，開發小組應該建立系統的架構，解決關鍵技術難題、開發系統的基礎構件，并對系統所需要應用的技術做深度探索。例如:基于JavaEE5構建全國聯網售票系統，涉及到分布式事務處理、海量數據存儲、異構平台互連等關鍵問題，應該優先處理這些問題;對開發所涉及到的EJB3、JSF、 JBoss Seam、Eclipse RCP等技術，要做深度探索。

越是技術複雜度高的項目，就越應該早地處理技術難題。如果在項目開發的中期或後期才發現架構有問題或是關鍵技術難題不能解決，則為時已晚。

(2) 充分論證

新技術開發是探索性很強的工作，潛在着許多失敗的風險。在可行性分析階段，要廣泛搜集相關信息，設計多種可行方案，進行充分論證。在制定決策時，情報的數量和質量緻關重要。掌握的信息越多、越準确，才能作出正确的的決策，項目失敗的風險也就相對減少;反之，承擔的風險就會增大。

(3) 同行經驗

針對新技術，由于沒有經驗可借鑒，因此在探索過程中要充分利用互聯網，通過搜索同行經驗，往往事半功倍。要充分利用世界日益平坦化的優勢，對于不能盡快解決的問題，可以先放一放，可能過不了幾天，網上就有相類似問題的解決方案了。

4、技術兼容性風險

硬件産品之間、系統軟件(操作系統、中間件、數據庫管理系統)與主機設備之間、系統軟件之間、應用軟件與系統軟件之間以及應用軟件之間，都可能存在兼容性問題。往往系統集成的項目越複雜，兼容性問題就越有可能存在。

(1) 設計先行

在做系統的總體設計方案時，務必把好相關産品的選型關，确保網絡、主機、系統軟件與應用軟件之間不要存在較大的技術兼容性問題。在網絡平台建設方案中，明确相關設備的技術參數和配置要求。

(2) 售前産品測試

在做項目招投标工作時，要求投标方在售前提供産品兼容性測試，以避免在項目實施過程中才暴露技術兼容性問題。涉及應用軟件開發的集成項目，要在開發工作的早期，做技術兼容性測試，以避免在項目開發後期才暴露技術兼容性問題。

由于先期設計不足，性能問題往往在系統切換或新系統使用一段時間後暴露。出現性能問題往往要進行大量的優化工作，甚至局部的或全面的重新設計。無論是用戶還是開發者，誰都不希望出現性能問題。

(1) 性能規劃

在系統設計時，應做好前期做性能規劃，對可能出現性能問題的環節做到充足的估計。在做數據庫設計時，應争取DBA參與。

另外，在技術方法方面，盡可能采取一些性能優化模式，如DTO、AJAX、延遲加載等，盡可能在開發過程中解決了性能問題。不至于到了項目後期才解決性能問題，既費錢又費時。

(2) 性能測試

在開發過程中，要重視性能測試和壓力測試，盡可能模拟現實使用環境，搭建測試平台。另外，由于開發環境的計算機往往比生産環境的計算機配置高，在做測試時應盡量找一些配置低的機器、較小的網絡帶寬進行測試。

(3) 充足的調試時間

在項目開發計劃中，為後期性能優化留有餘地。在對系統進行性能優化後，要進行性能測試和壓力測試，可能還要做幾次回歸測試。因此，應該留有充足的時間和人力。

6、倉促上線

在項目實施過程中，系統切換上線環節Z容易出纰漏。項目好不容易開發完成了，卻在Z後Z後時刻功潰一匮。如果項目小，影響面窄倒不怎麼重要;如果是影響面大的項目，則千萬不可出現問題。在系統切換前，應充分考慮各種可能出現的問題，做好風險對策。

(1) 應急預案

面對各種不可預知的風險，要做好應急預案。正常運行的車站售票系統在春運、旅遊黃金周，都會做好應急預案。新系統切換時，更應該做好應急預案。應急預案中應做好Z壞的打算，售票系統不能正常工作時，準備手工票就是Z壞的打算。

(2) 分步切換

為了減少風險的影響，可以做系統分步切換的方案。例如:售票系統在切換時，往往用新系統售預售票，或者是用新系統售長途車站，用舊系統暫時售短程票。待新系統運行穩定後，再全面切換到新系統。針對多個用戶單位的系統切換，也可分單位進行。

(3) 交叉培訓

新舊系統切換過程中，用戶都存在适應過程。除了在切換前做好操作培訓外，還要在新舊系統切換過程中做好交叉培訓。讓用戶提前一些時間上班，讓早班的用戶在交班時培訓中班的用戶，中班的用戶培訓晚班的用戶。做好交叉培訓能夠讓系統平衡過渡。

7、可用性問題

軟件的可用性包括軟件的使用是不是高效、是否容易學習、是否容易記憶、是否令人愉快、是否不易出錯等諸多因素。往往由于軟件的可用性差，導緻用戶不滿意，甚至被市場淘汰。在項目開發中應注意可用性問題，避免軟件出現可用性方面的風險。

(1) 了解用戶

到用戶工作現場，了解目标用戶使用軟件的真實目的，從用戶的角度、從用戶的立場出發，了解如何通過軟件系統替代用戶的業務處理流程中，Z繁瑣、Z容易出問題、或者是大量重複勞動的環節，讓軟件提高用戶的工作效能和效率。

(2) 參與型設計

與用戶協作，讓用戶參與用戶界面的設計、評審與測試，确保用戶能夠全面地、及早地發現可用性等方面的問題，并及時糾正。

讓客戶參與設計，而不要讓客戶設計，項目經理或高級設計人員應該主導設計。

(3) 競争性分析

通過對市場上同類競争性産品進行分析，或者對這些産品進行實驗性測試，了解這些産品的用戶界面問題，從而對新系統的開發提供啟發。競争性分析并不意味着可以剽竊别人的設計，而是通過分析競争産品的優勢和弱點，能夠比以前的設計做得更好。

(4) 一緻性

如果用戶知道同樣的命令或同樣的操作總會産生同樣的效果，那麼他們在使用系統時就會更加自信，同時也鼓勵他們進行探索性學習，因為他們已經具備了使用系統新部分的基礎知識。

開發團隊應遵循公司或小組制定的用戶界面标準，就可以在很多方面保持一緻性，切忌不要一個系統存在多種不同的界面風格。

8、結論

在信息系統集成項目中，風險是多種多樣的，是無處不在的。在項目管理活動中，要積極面對風險，要培養。越早識别風險、越早管理風險，就越有可能規避風險，或者在風險發生時能夠降低風險帶來的影響。特别是在項目參與方多、涉及面廣、影響面大、技術含量高的複雜項目，應加強風險管理。如果不主動駕馭風險，就會面臨風險。