專案驗收要求
目錄1 驗收流程 4
2 開發方申請階段 5
2.1 開發方qa審批 5
2.2 開發方專案經理申請 5
3 使用者確認階段 6
3.1 提交資料： 6
4 委託方驗收審核階段 7
4.1 委託方專案經理審核 7
4.2 委託方軟體設計師審核 7
4.2.1 1.提交資料 7
4.2.2 門戶整合整改： 8
4.2.3 編譯測試 11
4.2.4 上線部署 11
4.3 委託方質量保證員審核 11
4.3.1 需要提供的紙質材料： 11
4.3.2 電子文件 11
4.4 委託方開發經理審批 11
5 附錄一 13
5.1 驗收審批表 13
5.2 系統上線申請表 14
5.3 軟體上線部署報告 14
5.3.1 軟體清單檢查表 15
5.3.2 編譯測試報告 16
5.3.3 上線部署報告 17
6 附錄二輸出物命名規範 18
7 附錄三文件命名規則 19
8 附錄四版本歷史 19
驗收流程圖:
開發方qa審查人員，需嚴格通過qa審核，並在驗收審批表上寫明審核結果，簽字確認。
發方qa通過審核，則進入局方驗收審批環節；
開發方qa未通過審核，則驗收流程終止；
開發方專案經理在通過開發方qa審核後，根據專案情況，對專案是否符合驗收條件進行審核；審核後，需在驗收審批表上寫明審核結果，並簽字確認；
紙質需求用例。
使用者根據需求用例，對各項需求進行逐個測試驗證，並在列印的紙製需求用例上進行簽字確認是否通過。
所有需求用例測試驗證完畢，使用者在審批表中填寫使用者意見，並簽字。
使用者審批通過，提交委託方審核。
委託方專案經理根據專案當前現狀，綜合評審，並確認審批意見。
開發方提供《系統上線申請表》全部通過的紙質證明。
開發方提供《軟體上線部署報告》全部通過的紙質證明。
《系統上線申請表》參考附錄一 , 5.2 系統上線申請表；
《軟體上線部署報告》參考附錄二 5.3 軟體上線部署報告；
根據《軟體上線部署報告》提交相應的資料，資料報括以下兩類:
概述根據移動運營支撐系統整合要求，需要對各子系統的許可權進行整合。集中使用者許可權管理系統是基於角色的訪問控制的，在訪問控制中引入了角色的概念，把對資源的訪問許可權分配給相應的角色，根據使用者在組織內所承擔的角色進行訪問授權與控制。
根據應用系統的特點，我們把系統角色劃分了通用角色和系統角色。
通用角色：可以跨系統進行定義，對註冊到集中也就是說乙個通用角色，可以定義訪問不同子系統的選單許可權，主要考慮門戶系統的選單許可權
系統角色：包括了「流程角色」和「操作角色」，不能跨系統進行定義。
系統工作流程
流程操作許可權整合
流程和操作許可權，是通過角色和使用者資訊關聯來定位使用者所具備的許可權。在集中許可權管理系統定義角色，以及角色和使用者的對應關係，子系統從集中使用者許可權管理系統中進行同步，根據子系統中定義的許可權模型，驗證使用者所擁有的許可權。下面具體說明整合步驟。
第一步定義子系統所使用者的系統角色，具體模版請使用附錄「系統角色申請表」，舉例說明如下：
第二步定義系統角色申請樣列。申請樣列，定義了子系統流程或者操作角色的許可權模型，具體模版請使用附錄「系統角色申請表」，舉例說明如下，其中：
歸屬單位、歸屬部門、管理專業、管理跨度（管理部門，可以多選）是使用者的維度資訊，子系統根據角色和維度資訊組合，確定該使用者所擁有的許可權。
歸屬單位：包括省公司、分公司和縣公司，格式參考如下，『移動.省公司』、『移動.福州分公司』、『移動.福州分公司.平潭縣公司』
歸屬部門：根據不同的單位，具有不同的部門
管理專業：按照系統來分，不同的系統，管理的專業不同
管理跨度：和歸屬部門一下，可以進行多選
角色屬性：包括流程角色和操作角色
第三步系統角色和角色申請樣列提交給局方相關人員進行評審，審核通過後，通過「系統角色申請」流程，完成子系統流程或操作角色的申請。
第四步子系統許可權改造。子系統必須嚴格按照評審通過後的許可權模型進行許可權改造，通過角色和使用者的維度資訊，包括歸屬單位、歸屬部門、管理專業、管理跨度，來驗證使用者所擁有的流程和操作許可權。
注：子系統中所包含的角色必須和集中許可權的系統角色是一致的，不允許子系統中通過集中給出的角色再進行組合，定義新的角色。
整改注意點:
1. 許可權和錯誤頁面不能使用絕對位址，因為門戶可以由網和oa網訪問
編譯要求：不允許出現編譯錯誤（error）。
當出現編譯錯誤時，需要記錄錯誤原因並修改錯誤。
上線要求：能夠和正式環境中部署的程式版本相對應，沒有出現功能增加和減少。
質量保證員如發現需求用例與實際不符即可退回至使用者，重新驗收確認。
驗收證書（蓋章）、委託書（影印版）、驗收手冊、軟體上線申請書、軟體上線部署報告、
按照以下目錄樹提供電子文件，並按照文件的命名規範提供。
專案名稱
|_需求開發（需求規格說明書）
|_專案策劃（專案計畫、關鍵wbs檢查單、風險列表）
|_系統設計（概要設計、詳細設計、資料庫詳細設計說明文件）
|_實現與測試
|_測試（測試用例、測試報告）
|_源**（源**說明文件）
|_系統上線（上線申請表、上線計畫表、上線部署報告）
|_系統驗收
|_相關文件（驗收手冊、遺留問題、培訓手冊（課件）、使用者手冊、維護手冊、安裝手冊）
|_補丁包（補丁包、補丁載入記錄表）
圖1：宋體，小五，對中
注：電子文件命名規範見3命名規範
委託方開發經理根據所有驗收過程的結果，綜合評審，並確認審批意見。
注：1、該文件為紙質列印版文件，如需加頁，請雙面列印。
投資專案說明書
幾串幾前面數字表示比賽場數,後面數字表示投注的注數 6串1就是6場比賽串成一注 必須六場比賽全部猜對才中獎 6串7裡面包括了6個5串1和1個6串1 單場 一場算一場，沒有疑問 2串1 兩場比賽成一注，兩場都對算贏，錯一全輸。2串3 兩場比賽，單關兩注，2串1一注，允許錯一場 猜中那場派單場獎金 3串...
專案開發說明書
即使是剛剛學會使用電腦的使用者也同樣可以順利的操作該系統，它的介面直觀 一目了然 讓人能夠正確的作業系統，以達到對資料庫的新增 刪除 更新 查詢等。該軟體可以反覆的使用，而且它的使用週期是很適應大眾的要求，它的研發經費很低，即使就是最普通的家庭或公司都能夠承受相當少的軟體費用，而且它的研發週期適中，...
IT專案範圍說明書
版本號 1.0 基本資訊 專案名稱餐飲業資訊化點餐系統專案經理 一產品範圍描述 本專案旨在建設一台能夠完成資訊化點餐系統及前台控制，後台監控維護系統。最終的專案產品應該同時具備選單資訊化功能，點餐功能，收銀功能 呼叫服務功能，資料分析功能。最終的專案產品應該由以下十大系統構成 點餐系統 支付系統 包...