【正文】 關(guān)鍵 普通 … 6 文檔交付列表序號交付文檔名稱交付日期備注7 風險管理計劃 提示：以下是各個列標題的解釋。平均修復時間 (MTTR)—系統(tǒng)在發(fā)生故障后可以暫停運行的時間。 對于每一個接口，這部分應說明與軟件產(chǎn)品相關(guān)的接口軟件的目的，并根據(jù)信息的內(nèi)容和格式定義接口，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。業(yè)務需求目標系統(tǒng)業(yè)務活動（可選）功能名稱 假定和約束 說明：列出進行本軟件開發(fā)工作的假定和約束，例如：開發(fā)語言、開發(fā)期限等。 l 完整而準確的定義本產(chǎn)品的干系人； l 明確本產(chǎn)品所影響到的部門和業(yè)務； l 用圖表或者文字描述產(chǎn)品的范圍，概要的定義產(chǎn)品的功能。 具體業(yè)務流程（系統(tǒng)名稱+編號） 對于具體業(yè)務流程的命名有規(guī)范，對具體流程進行編號，便于形成需求矩陣，同時形成需求的管理和跟蹤。 （1）公司的短期、長期發(fā)展戰(zhàn)略； （2）業(yè)務需求及發(fā)展趨勢； （3）技術(shù)狀況及發(fā)展趨勢； （4）特殊的業(yè)務需求等。 第五十九條 以上各要求需要在開發(fā)合同中明確。 第四十七條 項目組制定《系統(tǒng)上線計劃》（附件十七），上報公司主管領(lǐng)導審批。數(shù)據(jù)遷移計劃需經(jīng)項目經(jīng)理和主管領(lǐng)導簽字審批。 第三十條 開發(fā)組或合作開發(fā)商協(xié)助技術(shù)研發(fā)部測試組建立測試環(huán)境進行系統(tǒng)測試?！对O(shè)計說明書》中需要定義系統(tǒng)輸入輸出說明和接口設(shè)計說明。 第三節(jié) 需求分析 第九條 立項后業(yè)務組對用戶需求進行匯總整理，出具《業(yè)務需求說明書》（附件二），并確?！稑I(yè)務需求說明書》中包含了所有的業(yè)務需求。本制度適用于公司軟件研發(fā)與管理。《系統(tǒng)需求規(guī)格說明書》需詳細列出業(yè)務對系統(tǒng)的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關(guān)鍵指標(KPI)等），最好是采用原型方式表達。 第二十條 設(shè)計評審均以《業(yè)務需求說明書》和《系統(tǒng)需求規(guī)格說明書》為依據(jù)，確保系統(tǒng)設(shè)計滿足全部需求。 第三十一條 系統(tǒng)測試通過后，開發(fā)組配合業(yè)務組建立用戶測試環(huán)境，業(yè)務組根據(jù)用戶測試用例進行用戶測試，出具《用戶測試報告》（附件十一），業(yè)務組組長和開發(fā)組組長應在用戶測試報告中簽字確認。第三十九條 系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移由試運行單位業(yè)務部門和公司主管領(lǐng)導共同監(jiān)督并進行驗收。 第四十九條 上線單位在上線初期需加強日常運行狀態(tài)監(jiān)控，出現(xiàn)問題時應及時處理，對重大問題應啟動緊急預案。 第六十二條 項目組填寫《系統(tǒng)交付申請》（附件十九），提交主管技術(shù)總裁審批后，交付運維組。角色知識技能要求建議人選、人數(shù)工作時間項目經(jīng)理 需求開發(fā)人員 系統(tǒng)設(shè)計人員 編程人員 測試人員 質(zhì)量保證人員 配置管理人員 服務與維護人員 ……. 成本估計 內(nèi)容成本（人民幣）備注人力資源 軟硬件資源 差旅費 會議費 接待費 … . 進度表 提示：制定項目開發(fā)的進度表（建議給出項目里程碑計劃）。業(yè)務對象使用部門對應電子檔案編號 說明：描述業(yè)務環(huán)節(jié)關(guān)鍵算法體系。 干系人簡檔 【可選】 通過在下表中填寫各干系人的相關(guān)信息來說明系統(tǒng)中的各個干系人，詳盡的簡檔應包括各種干系人在以下方面的信息：代表 [誰是此產(chǎn)品的干系人代表？（如在他處已作記錄，則此處為可選。 硬件限制說明：本項包括在各種硬件約束下運行的軟件要求，例如，應該包括： 硬件配置的特點（接口數(shù)，指令系統(tǒng)等）；內(nèi)存儲器和輔助存儲器的容量。 位置 填寫該軟件在交互軟件體系中所出的位置 技術(shù)支持 填寫交互系統(tǒng)的開發(fā)商和支持商 功能支持 填寫具體的支持商或技術(shù)團隊 數(shù)據(jù)歸屬 【接口隸屬系統(tǒng)的詳細信息[可選] 】系統(tǒng) 填寫接口隸屬系統(tǒng)的名稱 模塊 隸屬于具體的模塊名稱 數(shù)據(jù)庫 隸屬系統(tǒng)的數(shù)據(jù)庫及版本 負責人 控制報告 【接口配置】 （1）接口基礎(chǔ)信息配置 說明：接口基礎(chǔ)信息的配置項目，描述配置的方式。 數(shù)據(jù)字典 說明：把相關(guān)的數(shù)據(jù)抽取出來統(tǒng)一維護，在其他章節(jié)如有類似信息描述，則關(guān)聯(lián)到數(shù)據(jù)字典的相關(guān)部分并加輔助說明，如：引用到的字段等。風險編號風險級別風險描述緩解方案應急計劃嚴重性 (15) 可能性 (%) 風險系數(shù) (嚴重性*可能性) 8 溝通計劃甲方代表乙方代表溝通方式溝通頻率/時間期望結(jié)果9 附件 l項目進度計劃 附件六 項目計劃變更說明項目名稱 申請日期 項目計劃變更申請 申請變更的 《項目計劃》 輸入名稱，版本，完成日期等信息 變更的內(nèi)容 及其理由 評估計劃變更將對 項目造成的影響 項目負責人簽字 變更申請的審批意見 處經(jīng)理審批 審批意見： 簽字： 日期 開發(fā)部負責人審批 審批意見： 簽字： 日期 業(yè)務部門意見 審批意見： 簽字： 日期 更改項目計劃 變更后的 《項目計劃》 輸入名稱，版本，完成日期等信息 項目負責人簽字 附件七 設(shè)計說明書文件狀態(tài)： [√] 草稿 [ ] 正式發(fā)布 [ ] 正在修改 文件標識： ProjectName 當前版本： 作 者： 完成日期： YearMonthDay 版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1引言 說明編寫這份詳細設(shè)計說明書的目的，指出預期的讀者。 用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。 [√] 工作成果基本合格，需要作少量的修改，之后通過審核即可。任務名稱及其描述開始時間結(jié)束時間參加人員任務1 任務2 … 5. 可能存在的困難與風險 提示：指出可能存在的困難和風險，制定應急計劃以應對突發(fā)事件。 4. 報錯趨勢分析報告 提示：建議制作趨勢圖 5. 試運行經(jīng)驗總結(jié) 6. 下一階段工作安排附件十六 系統(tǒng)驗收報告版 本 歷 史版本/狀態(tài)作者參與者起止日期備注項目名稱 甲方 乙方 合同 甲方驗收人員 角色 職責 乙方人員 角色 職責 應交付成果的名稱、版本甲方審核人乙方協(xié)助人時間地點審查結(jié)論3. 問題處理 提示：如果甲方發(fā)現(xiàn)工作成果中存在缺陷，雙方應當視問題的嚴重性給出合適的處理措施。 附錄：本計劃審批意見項目負責人審批意見： 簽字： 日期信息技術(shù)部審批意見 簽字： 日期業(yè)務部門審批意見 簽字： 日期附件十八 系統(tǒng)驗收評估報告 1. 背景介紹 提示：介紹系統(tǒng)上線的背景情況。 2). 預防措施 提示：針對上線失敗的幾類原因，制定預防措施。 6. 數(shù)據(jù)異常/差異處理 提示：數(shù)據(jù)遷移過程中，形成的數(shù)據(jù)異常/差錯/數(shù)據(jù)修改所進行的處理過程記錄，以及處理后的結(jié)論。 4. 缺陷修改記錄 提示：如果采用了缺陷管理工具，能自動產(chǎn)生缺陷報表的話，則無需本表。 對應每一步的預測結(jié)果； 對應每一個執(zhí)行步驟的實際結(jié)果； 填寫與測試相關(guān)聯(lián)的核對點、檢查點。 給出對每一個輸入項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效范圍、輸入的方式。方法與工具用途Visual SourceSafe 配置管理 … 4 里程碑計劃序號里程碑名稱開始日期結(jié)束日期工作成果備注5 資源計劃 提示：制定本項目的角色職責表，并為已知的項目成員分配角色（一個人可以兼多個角色）。平均故障間隔時間 (MTBF)。對每一個所需的軟件產(chǎn)品，要提供如下內(nèi)容：名字、助記符、規(guī)格說明號、版本號、來源。 重要程度，以ABC三類來表示：A：核心功能；B：輔助功能；C：外圍功能； 級別，按照繼承關(guān)系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注 功能與業(yè)務對照關(guān)系表 說明：業(yè)務組為主編寫業(yè)務需求，業(yè)務需求提交至信息技術(shù)組后，由信息技術(shù)組建立目標技術(shù)開發(fā)管理制度 第 17 頁，共 53 頁 系統(tǒng)業(yè)務模型并與業(yè)務組進行確認（本操作可選，也可由信息技術(shù)組與開發(fā)商合作建立），目標業(yè)務模型作為系統(tǒng)需求的輸入，由信息技術(shù)組與開發(fā)商合作撰寫和評審《系統(tǒng)需求規(guī)格書明書》。說清楚系統(tǒng)范圍的好處是：（1）有助于判斷什么是需求，什么不是需求；（2）可以將開發(fā)精力集中在產(chǎn)品范圍之內(nèi)；（3）有助于控制需求的變更。流程編號流程名稱責任部門輔助部門3 業(yè)務流程及業(yè)務處理描述 說明：針對每一項具體的目標業(yè)務，描述具體的業(yè)務流程，以及相關(guān)業(yè)務的具體描述。 . 項目背景 提示：闡述項目背景，重點說明“為什么”會產(chǎn)生本項目。 第五十八條 項目組同合作開發(fā)商商定驗收的標準和方法。 第四十六條 通常情況下，系統(tǒng)上線包含數(shù)據(jù)遷移工作。 第三十七條 數(shù)據(jù)遷移前，應制定詳細的《數(shù)據(jù)遷移計劃》（附件十三），《數(shù)據(jù)遷移計劃》中應包含遷移方案、測試方案、數(shù)據(jù)定義，新舊數(shù)據(jù)對照表、遷移時間、回退計劃等信息。對已評定為敏感信息的數(shù)據(jù)進行敏感性處理和保護。 第十九條 項目組進行設(shè)計，出具《設(shè)計說明書》（附件七）和《單元測試用例》（附件八）。項目組人員的選擇應滿足項目對業(yè)務及技術(shù)要求，項目組人員應有足夠的業(yè)務和IT技術(shù)方面的專業(yè)知識來勝任項目各方面的工作。 第二條 本制度中軟件開發(fā)指新系統(tǒng)開發(fā)和現(xiàn)有系統(tǒng)重大改造，此類工作均需要以項目制管理?！断到y(tǒng)需求規(guī)格說明書》需要由業(yè)務組提交給相關(guān)業(yè)務部門負責人確認。 第二十一條 對已確認通過的系統(tǒng)設(shè)計進行修改需獲得項目經(jīng)理、業(yè)務組組長和開發(fā)組組長的審批后方可進行