【正文】 史版本/狀態(tài)作者參與者起止日期備注1 文檔介紹 文檔目的提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：[標識符] 作者，文獻名稱，出版單位（或歸屬單位），日期例如：[AAA] 作者，《立項建議書》，機構名稱，日期 術語與縮寫解釋縮寫、術語解 釋2 項目介紹提示：（1）用簡練的語言說明本項目“是什么”，“說明用途”。 約束提示：（1）請說明在項目開發(fā)過程中應當遵循的標準或規(guī)范（2）請說明相關項目可能對本項目造成的影響。此處可以表現(xiàn)為編碼規(guī)范的鏈接。角色職責人員姓名工作說明高層領導項目經(jīng)理需求分析員系統(tǒng)設計員程序員測試員… 軟硬件資源計劃提示：分析項目開發(fā)、測試、運行所需的軟硬件資源和關鍵計算機資源（會影響軟件產(chǎn)品的性能的CPU、內存、帶寬等內容），主要內容包括：l 資源級別（分為“關鍵”、“普通”兩種）l 詳細配置l 獲取方式（如“已經(jīng)存在”、“可以借用”或“需要購買”等）與獲取時間l 使用說明（如“誰”在“什么”時候使用）軟硬件資源名稱級別詳細配置獲取方式與時間使用說明關鍵關鍵普通…6 文檔交付列表序號交付文檔名稱交付日期備注7 風險管理計劃提示：以下是各個列標題的解釋。例如：編號里程碑名稱預計結束時間備注需求調研完成項目計劃完成需求分析完成概要設計完成詳細設計完成實現(xiàn)完成集成測試完成系統(tǒng)測試完成用戶驗收測試完成試運行結束項目驗收附件六 項目計劃變更說明項目名稱申請日期項目計劃變更申請申請變更的《項目計劃》輸入名稱，版本，完成日期等信息變更的內容及其理由評估計劃變更將對項目造成的影響項目負責人簽字變更申請的審批意見處經(jīng)理審批審批意見：簽字，日期研發(fā)部負責人審批審批意見：簽字，日期業(yè)務部門意見審批意見：簽字，日期更改項目計劃變更后的《項目計劃》輸入名稱，版本，完成日期等信息項目負責人簽字附件七 設計說明書文件狀態(tài)：[√] 草稿[ ] 正式發(fā)布[ ] 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1引言說明編寫這份詳細設計說明書的目的，指出預期的讀者。列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠取得這些文件的來源。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內容往往與它所隸屬的上一層 模塊的對應條目的內容相同，在這種情況下，只要簡單地說明這一點即可。給出對每一個輸入項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效范圍、輸入的方式。用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。說明本程序運行中所受到的限制條件。附件八 單元測試用例1 測試范圍說明：本用例測試的功能點。對應每一步的預測結果；對應每一個執(zhí)行步驟的實際結果；填寫與測試相關聯(lián)的核對點、檢查點。[√] 工作成果基本合格，需要作少量的修改，之后通過審核即可。2. 測試方法提示：例如黑盒測試和白盒測試。 最后一次回歸測試二類缺陷數(shù)量為零，用例外非常規(guī)缺陷數(shù)量小于等于2 個/萬行程序；測試用例功能點覆蓋率100%；6. BUG管理與改錯計劃提示：根據(jù)所采用的BUG管理工具確定：（1）BUG管理流程，（2）BUG修改流程。4. 缺陷修改記錄提示：如果采用了缺陷管理工具，能自動產(chǎn)生缺陷報表的話，則無需本表。任務名稱及其描述開始時間結束時間參加人員任務1任務2…5. 可能存在的困難與風險提示：指出可能存在的困難和風險，制定應急計劃以應對突發(fā)事件。2). 預防措施提示：針對轉換失敗的幾類原因，制定預防措施。：本計劃審批意見項目負責人審批意見：簽字 日期研發(fā)部審批意見簽字 日期業(yè)務部門審批意見簽字 日期附件十四 數(shù)據(jù)遷移報告1. 背景介紹提示：介紹系統(tǒng)轉換的背景情況。6. 數(shù)據(jù)異常/差異處理提示：數(shù)據(jù)遷移過程中，形成的數(shù)據(jù)異常/差錯/數(shù)據(jù)修改所進行的處理過程記錄，以及處理后的結論。4. 報錯趨勢分析報告提示：建議制作趨勢圖5. 試運行經(jīng)驗總結6. 下一階段工作安排附件十六 系統(tǒng)驗收報告版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1. 基本信息項目名稱甲方乙方合同甲方驗收人員角色職責乙方人員角色職責2. 成果審查報告應交付成果的名稱、版本甲方審核人乙方協(xié)助人時間地點審查結論3. 問題處理提示：如果甲方發(fā)現(xiàn)工作成果中存在缺陷，雙方應當視問題的嚴重性給出合適的處理措施。（2）如果工作成果存在一些輕微的缺陷，則乙方應當給出糾正缺陷的措施，雙方協(xié)商是否需要第二次驗收。提示：（1）用Microsoft Project制作進度表（Gantt Chart），插入此處或作為附件。2). 預防措施提示：針對上線失敗的幾類原因，制定預防措施。附錄：本計劃審批意見項目負責人審批意見：簽字 日期研發(fā)部審批意見簽字 日期業(yè)務部門審批意見簽字 日期附件十八 系統(tǒng)驗收評估報告1. 背景介紹提示：介紹系統(tǒng)上線的背景情況。8. 備份以及批處理設置情況提示：可將設置情況作為附件9．問題和建議提示：對系統(tǒng)上線過程的問題進行總結，提出意見，并就上線及運行維護情況提出自己的建議。3. 系統(tǒng)上線實錄提示：回顧系統(tǒng)上線各階段工作，大體步驟及異常處理情況。4). 組織機制提示：建立應急處理小組成員，明確職責到人。5系統(tǒng)的功能測試計劃6．數(shù)據(jù)遷移的需求和實施計劃提示：此處可以直接說明請見附件“數(shù)據(jù)遷移實施計劃”。（2）雙方的責任人簽字認可。乙方應當給出糾正缺陷，雙方協(xié)商第二次驗收的時間。2. 試運行目標提示：說明本次試運行的主要內容與目標（必須是可驗證的）。3. 數(shù)據(jù)準備提示：所準備進行轉換的數(shù)據(jù)情況描述以及數(shù)據(jù)來源部門的審批結果4. 數(shù)據(jù)遷移實錄提示：回顧系統(tǒng)上線各階段工作，大體步驟5．數(shù)據(jù)遷移后數(shù)據(jù)核對過程和結論提示：說明本次數(shù)據(jù)遷移后進行數(shù)據(jù)核對的過程以及結論。4). 組織機制提示：建立應急處理小組成員，明確職責到人。項目經(jīng)理或試運行負責人審批意見：簽字 日期附件十三 數(shù)據(jù)遷移計劃1. 數(shù)據(jù)遷移的重要事件和里程碑日期2. 數(shù)據(jù)遷移前的備份要求3. 數(shù)據(jù)遷移測試結果清單提示：（1）用Microsoft Project制作進度表（Gantt Chart），插入此處或作為附件。2. 工作條件提示：說明試運行地點、參加人員、軟硬件設施、經(jīng)費等要求。7. 附錄. 本計劃審批意見項目經(jīng)理審批意見：簽字 日期附件十一 系統(tǒng)/用戶測試報告1. 基本信息測試依據(jù)例如：參照標準、客戶需求、需求規(guī)格說明書、測試用例等測試范圍測試驗收標準測試環(huán)境描述測試驅動程序描述提示：可以把測試驅動程序當作附件測試人員測試時間須注明每次回歸測試的時間測試工具2. 實況記錄模塊測試用例編號期望結果測試結果缺陷密度是否執(zhí)行了回歸測試3. 測試總評價根據(jù)對測試結果提出一個關于軟件能力的全面分析，需標明遺留的主要缺陷、局限性和軟件的約束限制等，并提出軟件測試過程中程序中的不足。對于嚴格系統(tǒng)，應當補充“基于BUG密度”的規(guī)則：相鄰n個CPU小時內“測試期BUG密度”全部低于某個值m。意見負責人簽字簽字：日期： 附件十 系統(tǒng)/用戶測試計劃文件狀態(tài)：[√] 草稿[ ] 正式發(fā)布[ ] 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1. 測試范圍與主要內容提示：系統(tǒng)測試小組應當根據(jù)項目的特征確定測試范圍與內容。待評審的工作成果工作成果名稱，標識符，版本，作者，時間…技術評審方式（正式評審）或者(走查)評審時間評審地點參加技術評審的人員類別名字工作單位職稱、職務：主持人評審小組成員記錄員2. 缺陷識別和跟蹤 評審問題跟蹤表編號問題描述問題類型嚴重性提交者提交日期問題處理負責人解決措施/原因說明問題解決狀態(tài)實際關閉日期問題關閉驗證人備注1　　　　　　　　　　233. 評審結論與意見提示：由主持人或評審員填寫此表格。測試用例功能1測試編號功能模塊