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