1.前言
參與過大型軟件項目的人都會認識到許多事情都可能出錯，一但出錯可能給項目帶來危害、損失或其它不利影響。風險是在項目中發生的一系列事件或不利結果的可能性。軟件開發是一項高風險的活動，在項目開發過程的任何一個階段都可能存在風險。采取積極的風險管理方式，可以使項目進程更加平穩，可以獲得很高的跟蹤和控制項目的能力，可以規避、轉移風險，或緩解風險帶來的不利影響。風險管理是對項目風險進行識別、分析、應對和監控的過程，是項目管理中很重要的管理活動，有效的實施軟件風險管理是軟件項目開發工作順利完成的保證。風險管理的達成必須包括三個要素：首先，在項目開發計劃中必須制定風險管理計劃；第二，在項目預算中必須包含解決風險所需的經費；第三，評估風險時，風險的影響也必須納入項目計劃中。
下面軟件開發過程中經常發生的風險，談談我們采取的預防措施。
2.需求不明確
需求不明確是軟件開發過程中經常可能遇到的問題，這類問題往往表現在需求范圍未界定、需求未細化、需求描述不清楚、需求遺漏、需求互相矛盾等多個方面。在軟件開發過程的生命周期各階段中，需求不明確所造成的浪費是大的，必須盡早盡可能解決。確定用戶需求是件非常困難的事情，我們常常從以下幾個方面著手處理需求不明確問題：
(1) 讓用戶參與開發
提供一個協作開發環境，讓用戶參與開發過程。如果條件不允許，至少應該在每次迭代的需求分析和系統測試階段，讓客戶能夠參與開發。
在選擇參與開發過程的用戶時，一方面，要盡可能爭取精通業務或計算機技術的用戶參與。另一方面，如果開發的產品要在不同規模、不同類型的企業應用，應該選擇具有代表性的用戶參與。
僅僅讓用戶參與是不夠的，應該采取一定的激勵措施，提高用戶參與的積極性。
(2) 開發用戶界面原型
用戶通常不善于精確描述自己的業務需求，系統分析員需要借助白板、白紙等溝通方式，幫助用戶清楚表述需求。然后，開發一個用戶界面原型，以便用戶確認需求。用戶界面原型的作用僅僅是收集用戶需求，不應該再作它用，也不要給用戶造成系統快要實現的錯覺。
(3) 需求討論會議
對于用戶分布廣、用戶量大的項目，要全面收集用戶需求，往往很困難，通常采取需求研計會議方式進行需求確認。通過在會議前幾周調查各地、各部門用戶需求意見，然后集中各地或各部門的用戶代表，舉辦一次需求研討會，通過會議方式收集需求。本方法適合于具有一定信息系統使用經驗的用戶。
(4) 強化需求分析與評審
首先，需求分析是項目成功的基礎，需要引起足夠的重視，并分配充足的時間和人力，要讓有經驗的系統分析員負責，切忌讓項目新手或程序員負責。其次，要進行需求評審，盡可能讓用戶參與需求評審，不要讓需求評審流于行式。第三，也是重要的一點，通過評審的需求規格說明書，要讓用戶方簽字，并作為項目合同的附件，對雙方都具有約束力。在公司內部要將通過評審的需求規格說明書，納入配置管理。
3.項目缺少可見性
當一個項目經理或一名開發者說已經完成了80%的任務，您必須保持審慎的態度。因為剩下的20%可能還需要80%的時間，甚至永遠都不能完成[1]。軟件開發項目，往往在項目進度和軟件質量方面缺少可見性，項目越缺少可見性，項目越難以控制，項目越有可能失敗。我們可以通過迭代開發、技術評審、持續集成來增強項目的可見性。
(1) 迭代開發
采用迭代的開發模型，將產品的交付過程分為多個階段，按照功能遞增式交付。以下是一些典型的迭代：
一次簡短的先期迭代，以建立規模和前景并確定商業理由；
一次精化迭代，其間將為穩定的構架劃定基線；
一次構建迭代，其間將實現用例并充實構架；
幾次產品化迭代，將產品轉移到用戶群。
每次迭代，都要充分接收用戶的評審意見，以便為自我糾正。漸近式的功能交付，有利于降低開發人員的壓力，增加用戶的滿意度，有利于增強項目的可見性，是好的進展報告。
(2) 技術評審
技術評審是確保軟件質量的重要環節，技術評審包括代碼走查、會議評審和同行專家評審。代碼走審可以是開發人員之間的交叉審查，或者是高級開發人員對普通開發人員的審查；會議評審一般應至少每兩周進行一次，每次評審時間不宜太長；同行專家評審包括技術和業務兩個方面的專家，經常性地讓精通業務的用戶專家參與項目評審，是項目成功的重要保證。
另外，充分利用質量審查的工具軟件，也有利于提高代碼質量。例如：在Eclipse開發環境中，可以集成Findbug、Checkstyle、PMD插件檢查代碼編寫質量。
