首先，必須在項目開發計劃中制定風險管理計劃；
第二，項目預算必須包括解決風險所需的資金；
第三，在評估風險時，風險的影響也必須包括在項目計劃中。
下面說說軟件開發過程中經常出現的風險以及我們采取的防範措施。
1，需求不明確
需求模糊是軟件開發過程中常見的問題，往往表現在需求範圍不明確、需求不明確、需求描述不清晰、需求缺失、需求矛盾等多個方面。在軟件開發過程生命周期的各個階段，需求不明確造成的浪費是最大的，必須盡快解決。確定用戶的需求是非常困難的，我們經常從以下幾個方面來處理需求不明確的問題:
(1)讓用戶參與開發。
為用戶參與開發過程提供壹個協作開發環境。如果條件不允許，至少在每個叠代的需求分析和系統測試階段，應該允許客戶參與開發。
在選擇用戶參與開發過程時，壹方面要盡可能爭取精通業務或計算機技術的用戶參與。另壹方面，如果所開發的產品要在不同規模和類型的企業中應用，則應選擇有代表性的用戶參與。
僅僅讓用戶參與是不夠的，要采取壹些激勵措施來提高用戶的積極性。
(2)開發用戶界面原型。
用戶通常不擅長準確描述自己的業務需求，系統分析師需要使用白板、白紙等溝通方式幫助用戶清晰地表達需求。然後，開發壹個原型用戶界面，以便用戶可以確認需求。用戶界面原型的作用只是收集用戶的需求，不應該用於其他用途，也不應該給用戶系統即將實現的錯覺。
(3)需求討論會
對於用戶分布廣、用戶數量多的項目，往往很難全面收集用戶需求，通常采用需求研究會的方式來確認需求。會前幾周，調研各地各部門用戶需求意見，然後召集各地或各部門用戶代表召開需求研討會，通過會議收集需求。這種方法適合有壹定信息系統使用經驗的用戶。
(4)加強需求分析和審查。
首先，需求分析是項目成功的基礎，需要引起足夠的重視，要分配足夠的時間和人力。有經驗的系統分析師應該負責，新手或者程序員不應該負責。其次，要進行需求評審，盡可能讓用戶參與到需求評審中來，不要讓需求評審流於形式。第三，也是最重要的壹點，通過評審的需求說明書要有用戶簽字，成為項目合同的附件，對雙方都有約束力。在公司內部，已經通過評審的需求規範應該包含在配置管理中。
2.這個項目缺乏知名度。
當壹個項目經理或者壹個開發人員說已經完成了80%的任務，妳壹定要謹慎。因為剩下的20%可能會占用80%的時間，甚至永遠無法完成[1]。軟件開發項目通常在項目進度和軟件質量方面缺乏可見性。項目的可見性越低，就越難控制，越有可能失敗。我們可以通過叠代開發、技術評審和持續集成來提高項目的可見性。
(1)叠代開發
使用叠代開發模型，將產品交付過程分為多個階段，根據功能以增量方式交付產品。以下是壹些典型的叠代:
建立規模和前景並確定業務原因的短期預叠代；
精化叠代，在此期間將為穩定的框架繪制基線；
壹個構建叠代，在此期間用例將被實現，架構將被豐富；
幾次產品化叠代，把產品轉移到用戶群。
每壹次叠代，都要充分接收用戶的評論，進行自我修正。漸進式的功能交付是最好的進度報告，有助於減輕開發人員的壓力，增加用戶的滿意度，增強項目的可視性。
(2)技術評審
技術評審是保證軟件質量的重要環節。技術評審包括代碼演練、會議評審和同行專家評審。代碼評審可以是開發者之間的交叉評審，也可以是資深開發者對普通開發者的評審；壹般每兩周至少進行壹次會議評審，每次評審時間不宜過長；同行專家評審既包括技術專家，也包括業務專家，定期讓懂業務的用戶專家參與項目評審是項目成功的重要保證。
另外，充分利用質量評審的工具軟件也有利於提高代碼質量。例如，在Eclipse開發環境中，您可以集成Findbug、Checkstyle和PMD插件來檢查代碼編寫的質量。
(3)持續集成
持續集成可以將最終的大規模集成調試過程分散到項目開發進度的每周、每天甚至每小時。以便項目中的所有人員能夠及時了解當前的整體進度，並在整合過程中快速發現和解決問題[1]。
開發團隊應該制定壹個持續集成的系統。通常，在每夜構建中，您可以使用Ant和其他構建工具來構建Java應用程序。團隊成員應在每個功能開發完成後及時將代碼提交給版本控制系統(如CVS)，不應將有問題(編譯失敗)的代碼提交給版本控制系統。
每夜構建和持續集成使得跟蹤項目進展更加容易。項目組每天重新編譯系統時，已完成和未完成的功能清晰可見，團隊成員從軟件的性能上也能簡單知道離整體完成還有多遠。
3.新技術的引入
技術創新是壹種探索性和創造性的技術經濟活動。在開發過程中引入新技術，難免會遇到各種風險。新技術的風險可以通過T型軟件開發、充分論證、多階段評估和同行經驗來降低。
(1) T形軟件的開發
在項目開發前期，開發團隊要建立系統架構，解決關鍵技術問題，開發系統的基本組件，對系統需要應用的技術進行深入探索。例如，基於JavaEE5構建全國在線售票系統，涉及分布式事務處理、海量數據存儲、異構平臺互聯等關鍵問題。，應優先考慮；開發中涉及到的技術，如EJB3、JSF、JBoss Seam、Eclipse RCP等都需要深入探討。
項目在技術上越復雜，技術問題就應該越早解決。如果在項目開發中後期發現有架構問題或者關鍵技術問題無法解決，那就太晚了。
(2)充分論證
新技術的開發是壹項探索性很強的工作，有很多潛在的失敗風險。在可行性分析階段，需要廣泛收集相關資料，設計多種可行方案，並進行充分論證。做決策時，信息的數量和質量非常重要。掌握的信息越多，就越能準確做出正確的決策，項目失敗的風險也會相對降低；相反，風險會增加。
(3)同伴經驗
針對新技術，由於沒有經驗可借鑒，在探索過程中要充分利用互聯網，通過搜索同行的經驗往往事半功倍。要充分利用這個日益扁平的世界，我們可以盡快把解決不了的問題放在壹邊，過幾天網上可能會有類似問題的解決方案。
4、技術兼容性風險
硬件產品、系統軟件(操作系統、中間件、數據庫管理系統)與主機設備、系統軟件、應用軟件與系統軟件、應用軟件之間可能存在兼容性問題。通常，系統集成項目越復雜，兼容性問題就越容易出現。
(1)設計優先
在制定系統總體設計方案時，壹定要保證相關產品的選型，確保網絡、主機、系統軟件、應用軟件之間不存在大的技術兼容性問題。在網絡平臺建設方案中，明確了相關設備的技術參數和配置要求。
(2)售前產品測試
投標項目時，要求投標人在銷售前提供產品兼容性測試，避免在項目實施過程中暴露技術兼容性問題。對於涉及應用軟件開發的集成項目，應在開發工作的早期進行技術兼容性測試，以避免在項目開發的後期暴露技術兼容性問題。
比如，在開發深圳汽車總站售票聯網調度系統時，為了保證技術兼容性，我們在硬件招標時，要求小型機設備廠商提供售前技術兼容性測試，並將測試結果作為考核指標。在深圳軟件測試中心對IBM、SUN和HP提供的小型機進行測試時，暴露出許多應用軟件、應用服務器、數據庫和操作系統之間的技術兼容性問題。如果在系統實施期間暴露或處理這些問題，項目進度將會延遲。
5.性能問題
由於前期設計不足，性能問題往往在系統切換或新系統使用壹段時間後暴露出來。性能問題往往需要大量的優化工作，甚至是部分或全面的重新設計。用戶和開發者都不希望出現性能問題。
(1)績效計劃
在設計系統時，要做好前期的性能規劃，對可能出現性能問題的環節進行充分的預估。設計數據庫時，要爭取DBA的參與。
此外，在技術方法上，我們嘗試采用壹些性能優化模式，如DTO、AJAX、延遲加載等。，盡可能解決開發過程中的性能問題。直到項目後期才解決性能問題，不會很貴，也不會很費時。
(2)性能測試
在開發過程中，要重視性能測試和壓力測試，盡可能模擬真實的使用環境，搭建測試平臺。另外，由於開發環境下的電腦往往比生產環境下的配置高，所以要盡量找壹些配置低、網絡帶寬小的機器進行測試。
(3)足夠的調試時間
在項目開發計劃中，有後期性能優化的空間。系統性能優化後，需要進行性能測試和壓力測試，可能還會做幾次回歸測試。所以要預留充足的時間和人力。
6、沖在線
在項目實施過程中，系統切換在線環節是最容易出錯的。項目終於開發出來了，但在最後壹刻崩潰了。如果項目小，影響面窄不是很重要；如果是影響比較大的項目，肯定沒有問題。系統切換前，應充分考慮所有可能出現的問題，並采取風險對策。
(1)應急預案
面對各種不可預知的風險，要做好應急預案。車站售票系統的正常運行將在春運高峰和旅遊黃金周期間制定應急計劃。當新系統切換時，應制定應急計劃。應急預案中要做好最壞的打算。當售票系統無法正常工作時，準備人工售票是最壞的打算。
(2)逐步切換
為了減少風險的影響，系統可以逐步切換。比如售票系統切換時，往往是用新系統發售預售票，或者用新系統發售長途車站，用舊系統臨時發售短途車票。新系統運行穩定後，完全切換到新系統。多個用戶單元的系統切換也可以按單元進行。
(3)交叉訓練
在新舊系統切換的過程中，用戶都有壹個適應的過程。除了切換前的操作培訓，還要做新舊系統切換過程中的交叉培訓。讓用戶提前壹段時間上班，讓早班用戶培訓中班用戶，中班用戶培訓晚班用戶。做好交叉訓練，可以讓系統均衡過渡。
7、可用性問題
軟件的可用性包括很多因素，比如軟件的使用是否高效、易學、易記、愉悅、易錯等。往往由於軟件的可用性差，導致用戶不滿，甚至被市場淘汰。在項目開發中，要註意可用性問題，避免軟件可用性風險。
(1)了解用戶
到用戶的工作現場，了解目標用戶使用軟件的真實目的，從用戶的角度和立場出發，了解如何用軟件系統代替用戶業務處理流程中最繁瑣、最容易出現問題，或者大量重復性的工作，讓軟件提高用戶的工作效率和效益。比如在售票系統中，最常使用的接口就是售票接口，列車員最關心的就是錢不要出差錯(沒收多賠償少)。因此，應收賬款的展示和變更字體要突出、醒目；同樣，票價和到站也要突出顯示。通過快捷鍵、壹鍵復位、數字小鍵盤等設計。，盡量減少指揮敲擊鍵盤的次數。否則在壹個日客流量七八萬的大型客運站，如果用戶界面設計得不好，列車員壹天的工作下來會把手指敲得麻木。
(2)參與式設計
與用戶合作，讓用戶參與用戶界面的設計、評審和測試，保證用戶能夠全面、早期發現可用性問題，並及時修正。
讓客戶參與設計，而不是讓客戶設計，應該由項目經理或者高級設計師來主導設計。
(3)競爭力分析
通過對市場上同類競爭產品的分析，或者對這些產品的實驗測試，了解這些產品的用戶界面問題，從而為新系統的開發提供啟示。競爭分析不是說妳可以偷別人的設計，而是通過分析競爭產品的優缺點，妳可以做的比之前的設計更好[5]。
(4)壹致性
如果用戶知道同樣的命令或同樣的操作總會產生同樣的效果，那麽他們在使用系統時會更加自信，同時鼓勵他們進行探索性學習，因為他們已經具備了使用系統新部分的基本知識[Lewis er al .1989]。
開發團隊要遵循公司或團隊制定的用戶界面標準，這樣才能在很多方面保持壹致性，禁止壹個系統有多種界面風格。
鄭州觀致電子商務，資源有效，成功案例多，制作水平專業，提供微期貨平臺建設、分銷系統開發、釣魚遊戲開發、第三方支付軟件開發、商城網站建設、電子商務網站建設、網站定制開發、手機app軟件開發、微信小程序開發、電子商務系統開發、辦公系統軟件開發等壹系列服務。精英團隊為妳的未來保駕護航！
8.結論
在信息系統集成項目中，風險是多種多樣且無處不在的。在項目管理活動中，我們應該積極面對風險，培養風險。越早識別和管理風險，就越有可能避免風險或降低風險發生時的影響。尤其是參與人員多、覆蓋面廣、影響大、科技含量高的復雜項目，更應加強風險管理。不主動控制風險，就會面臨風險。