額外工作量。
出現(xiàn)概率：高
影響程度：中
處理建議：實施方要科學控制需求變更，通過項目組集體決策的方式確定變更，除了嚴重影響使用外，細節(jié)變更要批量修改，不要一事一改。
8、需求變更缺乏管理風險：業(yè)主缺少有效的需求變化管理。
出現(xiàn)概率：中
影響程度：中
處理建議：實施方協(xié)助業(yè)主加強對需求變更的管理，責任到人，簽字確認。
9、文檔管理風險：實施方缺乏有效的文檔管理體系。
出現(xiàn)概率：高
影響程度：低
處理建議：應(yīng)建立嚴格的文檔管理制度，包含對錯誤的管理，建立完善的錯誤追蹤管理系統(tǒng)。
10、需求變更缺乏分析風險：實施方對需求的變化缺少象原始需求一樣的分析過程。
出現(xiàn)概率：高
影響程度：低
處理建議：實施管理者要對所有需求的變更與原始需求一樣重視，要逐條進行詳細分析，確定對原設(shè)計的影響，全面變更實施計劃后再進行變更實施。
B、設(shè)計階段
1、項目團隊經(jīng)驗風險：實施方項目隊伍缺乏經(jīng)驗，或缺乏有經(jīng)驗的核心技術(shù)人員。
出現(xiàn)概率：中
影響程度：高
處理建議：業(yè)主加強對開發(fā)團隊的審核，包括團隊合作、組成人員資質(zhì)和經(jīng)驗等。
2、實施者自行變更風險：實施者根據(jù)自己的經(jīng)驗或考慮自身成本利益等原因在未得到業(yè)主允許的情況下私自變更需求或需求的實現(xiàn)方式。
出現(xiàn)概率：低
影響程度：中
處理建議：要明確約定實施者不得隨意變更用戶需求，如需變更需得到需求者認可方可實施。
3、計劃風險：倉促計劃，盲目制定工期，造成進度無法按計劃控制。
出現(xiàn)概率：低
影響程度：中
處理建議：科學制定詳細的開發(fā)計劃，并經(jīng)過共同論證后再嚴格實施。
4、漏項風險：由于設(shè)計人員的疏忽某個功能沒有考慮進去。
出現(xiàn)概率：低
影響程度：中
處理建議：設(shè)計后需要多方復(fù)核，仔細對比需求說明書與設(shè)計說明書的各相關(guān)項。
C、實施階段
1、開發(fā)環(huán)境風險：開發(fā)軟件環(huán)境沒有準備好或與實際環(huán)境不同，導(dǎo)致產(chǎn)品無法裝載到運行環(huán)境。
出現(xiàn)概率：低
影響程度：低
處理建議：需要雙方技術(shù)人員共同確認環(huán)境的一致性，要精確到產(chǎn)品的版本號及補丁情況。
2、整合風險：所實施的項目中涉及對舊有異構(gòu)數(shù)據(jù)和系統(tǒng)的整合。
出現(xiàn)概率：中
影響程度：低
處理建議：在實施前應(yīng)做充分調(diào)查，了解相關(guān)系統(tǒng)的所有技術(shù)細節(jié)，采用比較成熟和穩(wěn)定的整合方案，并制定接口規(guī)范，規(guī)劃時盡量減少新系統(tǒng)的異構(gòu)。
3、布署風險：運行環(huán)境和產(chǎn)品開發(fā)環(huán)境差異，尤其是開發(fā)機器與服務(wù)器硬件配置差異等原因造成布署困難。
出現(xiàn)概率：低
影響程度：低
處理建議：盡量保證開發(fā)時使用與最終布署環(huán)境相同的硬件條件，如果布署環(huán)境硬件條件過高則應(yīng)事先與廠商了解硬件相關(guān)特性，確保布署可能性。
4、設(shè)計風險：由于系統(tǒng)設(shè)計錯誤帶來實施困難。
出現(xiàn)概率：低
影響程度：高
處理建議：系統(tǒng)設(shè)計方案完成后，需要業(yè)主方組織成立技術(shù)專家組共同確認設(shè)計方案，及時發(fā)現(xiàn)設(shè)計漏洞。
5、人員能力風險：程序員開發(fā)能力差，或程序員對開發(fā)工具不熟。
出現(xiàn)概率：高
影響程度：低
處理建議：所有的項目組成員要做預(yù)先業(yè)務(wù)能力審核，如遇更替人員也要進行相應(yīng)的審核，確保人員具備足夠的業(yè)務(wù)能力。
6、項目范圍改變風險：已經(jīng)開始實施后用戶突然要增加或變更一些結(jié)構(gòu)性的功能，需要重新考慮架構(gòu)設(shè)計。
出現(xiàn)概率：低
影響程度：高
處理建議：架構(gòu)設(shè)計盡量靈活，采用構(gòu)件開發(fā)等方式增加應(yīng)變能力，同時要加強前期的靜態(tài)原型細度并將可能存在的問題及時提交給業(yè)主，避免實施過程中發(fā)生結(jié)構(gòu)性修改。
7、項目進度改變風險：由于特殊事件或得到上級領(lǐng)導(dǎo)指示，業(yè)主方要求提前完