（2015年2月6日項目報竣總結）
一、 項目組織架構
根據我們以往在項目管理和實施方面的經驗，建議項目的組織機構如下設置：
圖4-1項目組結構示意圖
二、 項目過程管理
2.1 項目進度控制辦法
本項目中我們將采用下列進度控制辦法：
（1）. 合理劃分項目任務
（2）. 根據技術人員情況進行合理分工
（3）. 采用并行開發和施工，本地化開發與工程實施并行進行。
（4）. 關注關鍵任務的進展
（5）. 每周進展分析報告
（6）. 里程碑進展狀態評審
（7）. 加強原型技術預研
（8）. 計劃提前評審和測試，盡早發現問題
（9）. 風險識別、跟蹤與規避。
三、 需求變更管理
3
3.1 需求變更控制原則
（1）及時、反復、全面地評審需求，及早發現需求問題。
（2）測試盡可能早的參與項目需求工程。
（3）對于不能明確的需求可以進行原型探索。
（4）需求的變更盡量控制在早期階段，需求階段和概要設計階段可以進行大量反復的需求變更，詳細設計階段可以進行部分需求變更，在編碼階段一般不能允許需求變更，需要實施嚴格控制。
（5）定量目標：需求階段，需求變更率可以控制在20%左右，設計階段控制在5%左右，編碼及測試階段控制在0%，即不能進行變更。如果一定要變更則根據變更流程可以改簽或續簽協議合同。
3.2 需求變更管理流程
（1）項目的需求變更分兩級控制：項目經理、CCB，項目經理可以直接決定影響輕微的需求變更。如果需求變更將引起資源、進度或軟件質量的變化，則需要CCB共同協商確定、并由雙方高級經理確認批準，否則不予變更。
（2）從變更申請到變更分析、確認、批準、處理直至完成，遵循公司NSP的變更處理規程，流程圖如下圖所示。
（3）首先對于發現的任何有關需求的問題，都必須形成文檔化的變更申請，提交項目經理
（4）項目經理初步確認，如果風險很小，則可以直接決定是否變更，否則提交CCB。
（5）CCB評審討論，進行影響分析，確定是否引起資源與約定的變更，如果沒有影響，則協調項目組內部和相關組資源，進行變更。否則提交雙方高級經理。
（6）雙方高級經理協商考慮資源與約定的影響，決定是否批準變更。對于允許的變更需要簽定增補合同，協調外部資源，并更新計劃和約定。
（7）項目組和相關組處理并跟蹤需求變更。
圖4-2 需求變更申請流程示意圖
3.3 項目溝通管理
（1）溝通的順暢和有效是保證項目進度按計劃實施的關鍵，因此做好項目的溝通管理非常重要。
（2）在項目實施過程中建立項目溝通管理的目的是：
（10）. 識別項目實施過程中需要的信息；
（11）. 定義信息收集需要的資源；
（12）. 把信息流向、時間跨度、接收信息者和發生的頻率進行文檔化；
（13）. 選擇信息有效流動的技術方法和載體。
（3）項目溝通管理主要包括：項目計劃、溝通媒介、定期會議、報告、進度表、假設、依賴、風險和成本，以及其它。
3.4 項目文檔管理
為了使項目信息更好地共享，我們將根據局方情況設定項目文檔電子化管理，使項目成員和有關人員能夠依權限從中獲得項目管理、項目成果、項目問題、變更、項目消息、聯絡信息、外來參考資料等信息和文檔，同時在其權限范圍內發布項目信息和輸入項目文檔、工作計劃等。
為了有序的管理項目電子文檔，這里規定項目文檔按照以下方式進行管理。
（1）項目文檔分類
我們把項目文檔劃分為以下類別：
（14）. 項目管理文檔（項目管理標準、程序、狀態報告、階段總結、問題、變更等）
（15）. 質量報告
（16）. 需求報告
（17）. 測試文檔（測試計劃、案例、測試結果、測試接受等）
（18）. 培訓文檔
（19）. 開發文件（含源代碼）
（20）. 系統設計與分析
（21）. 接口文檔
（22）. 系統管理
（23）. 合同等
（24）. 會議安排和記錄
（2）項目階段
為了把項目文檔與項目發生的時間或階段聯系起來，需要明確項目的階段如下：
（25）. 項目準備
（26）. 需求分析
（27）. 系統設計
（28）. 應用開發
（29）. 測試
（30）. 部署與運行
（3）項目文檔機密級別
定義項目文檔機密級別如下：
保密、機密、絕密和公開
對項目文檔機密的管理，要求此類文檔必須記錄機密級別，項目經理對查閱人員進行授權。對保密要求，見開發商與用戶簽署的保密協議。
（4）項目文檔電子化管理處理說明
在項目組中設置項目行政管理人員，其職責之一是管理項目文檔。各方把其交付的文檔同意交付到項目行政管理人員，由其傳至各個審核人員，得到批準或審核完畢，由項目行政管理人員發布到網絡上，并根據瀏覽權限進行設置，注明機密級別、版本等。
對于絕密文件，不進行瀏覽授權，查閱文件需要得到用戶方項目經理的特別批準。
如果項目文檔存在更新版本，發布最新版本，并注明其有效性，同時說明以前版本作廢。
不允許任何個人私自發布項目文檔。
3.5 系統測試和驗收方案
3.5.1系統測試方案
為了確保該系統的質量，我們將采用科學的方法和業界最先進的測試技術與工具，對該系統進行嚴格、規范的系統測試。在系統正式交付用戶使用前，我們將組織專業測試團隊，分別對該系統的應用功能、應用性能進行測試。
本節描述了各項測試的目標、測試環境和我們將采用的測試工具、測試方法、測試指標體系、測試實施計劃、測試報告形式和測試結果確認方式，系統測試實施前，我們將根據系統實施的實際情況和用戶需求，確定最后的測試內容和制定更詳細的測試實施方案，在經用戶方審核同意后，實施具體的測試。
3.5.2項目驗收方案
（1）驗收標準
以招標文件、總體設計為基礎，根據實際情況，從系統性能、系統功能兩個方面，對應用軟件制定相應的驗收標準草案，經過評審通過后，形成正式的驗收標準。
（2）驗收環境準備
驗收環境準備包括：
（31）. 驗收數據的準備
（32）. 驗收運行環境準備
（33）. 驗收用例準備
（3）驗收內容
系統完成測試運行后，我公司將擬制初驗計劃和驗收內容，供用戶確認。
1) 應用軟件。
2) 應用軟件源程序。
3) 相關文檔。
應用軟件驗收項目包括
（34）. 系統功能度；
（35）. 界面友好性；
（36）. 系統可靠性和安全性；
（37）. 容錯性；
（38）. 可伸縮性。
應用系統文檔驗收包括：
（39）. 應用軟件需求分析說明書；
（40）. 應用軟件概要設計說明書；
（41）. 應用軟件詳細設計說明書；
（42）. 應用軟件功能說明書；
（43）. 應用軟件用戶手冊；
（44）. 應用軟件安裝手冊；
（45）. 系統管理手冊；
（46）. 系統安裝手冊；
（47）. 系統維護手冊；
（48）. 應用系統源程序。
（4）驗收程序
對系統的驗收包括工程組內部驗收、用戶初步驗收（初驗）和用戶最終驗收（終驗）三個階段。工程組對應用軟件的內部驗收應按照相關規定，組織我公司技術委員會、行業咨詢專家等對應用軟件進行內部評審和驗收。內部驗收完成后，應用軟件的初驗和終驗應履行正式手續，雙方成立專門的驗收委員會，負責組織、監督和裁決整個應用軟件的驗收過程。
依據甲方單位授予合同的相關條款要求，組織項目的用戶最終驗收。
四、 項目風險分析
1、對于項目風險管理的定義：
內部風險管理計劃是為了確定項目風險，定義出規避或縮小這些風險所采取的行動。為此，必須定義出所有已知的和潛在的項目風險，充分評估這些風險發生的可能性，并且指定出規避和管理這些風險的行動。
2、風險管理計劃：
針對本項目，項目組經過對項目的技術，進度，預算等多方面內容的分析，初步定義以下的項目風險管理表：
表4-1 風險管理計劃
| 序號 |
風險內容 |
風險概率 |
對項目的影響 |
規避風險行動 |
| 1 |
客戶業務需求更改 |
50% |
延誤開發進度。 |
需求階段確認需求，并進行協議控制，遵循需求變更流程； |
| 2 |
人員流動性不可預測 |
30% |
延誤開發進度， 影響開發質量。 |
加強項目后勤管理；人力資源管理；充分考慮后備人力資源；關鍵工作安排兩人以上執行。 |
| 3 |
開發過程中新的業務需求出現 |
20% |
延誤開發進度。 |
系統框架具有好的擴展性和適應性。 |
| 4 |
開發機器設備、運行主機設備不到貨 |
5% |
項目延后 |
提早規劃，準備應急臨時設備 |
| 5 |
開發環境故障 |
20% |
項目數據丟失 |
數據備份，統一配置管理 |
| 6 |
天災人禍等人力不可抗拒因素 |
0.1% |
項目失敗 |
與甲方協商處理方法 |
