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