1、2021年軟件開發管理流程制度（附全套表格模板及填寫指引）58頁2021年軟件開發管理流程制度（附全套表格模板及填寫指引）58頁2021年軟件開發管理流程制度（附全套表格模板及填寫指引）58頁X X X X X X有限公司軟件開發管理制度文件編號：MC-SRD-I-01版 本：A0編制:審核:批準:生效日期：2020-06-012020-06-01Ywo2020-5-19冋 Qslfrx X X X X X目錄 TOC o 1-5 h z 1總則4立項管理4需求分析54項目計劃和監控55 系統設計66系統實現67系統測試和用戶測試78 試運行7 HYPERLINK l bookmark40 o

2、 Current Document 9系統驗收810系統上線911合作開發管理912外包開發管理1013外包服務管理1114附則11附件一立項分析報告12附件二業務需求說明書15 HYPERLINK l bookmark4 o Current Document 附件三系統需求規格說明書18附件四需求變更申請29附件五項目計劃書31附件六項目計劃變更說明35附件七概要設計說明書36附件八單元測試用例40附件九設計評審報告42 HYPERLINK l bookmark32 o Current Document 附件十系統/用戶測試計劃45附件十一系統/用戶測試報告48附件十二試運行計劃49附件十三

3、數據遷移計劃51附件十四數據遷移報告53附件十五試運行報告54附件十六系統驗收報告55附件十七系統上線計劃56附件十八系統驗收評估報告58軟件開發管理制度1總則為規范自有軟件研發以及外包軟件的管理工作，特制定本制度。本制度適用 于公司軟件研發與管理。本制度中軟件開發指新系統開發和現有系統重大改造。軟件開發遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項 目計劃和監控、配置管理、合作開發管理和結項管理。軟件工程涉及需求管 理、系統設計、系統實現、系統測試、用戶接受測試、試運行、系統驗收、 系統上線和數據遷移。除特別指定，本制度中項目組包括業務組（或需求提出組）、IT組（可能包 括網絡管

4、理員和合作開發商）。2立項管理提出開發需求的信息技術部門參與公司層面立項，進行立項的技術可行性分 析，編寫立項分析報告（附件一），開展前期籌備工作。立項分析報告 應明確項目的范圍和邊界。應用系統主要使用部門將立項分析報告上交公司總裁室進行立項審批， 以保證系統項目與公司整體策略相一致。立項分析報告得到批準后，成立項目組（如果是外包開發，則成立外包 商項目組；如果是合作開發，則與外包商共同成立合作開發項目組，以下統 稱“項目組”），項目組應包括業務組（由公司相關業務部門組成）和IT組（自行開發為辦公室網絡管理員；外包開發為外包商成員；合作開發為網絡 管理員和外包商成員）。公司委派一名員工負責監督

5、項目的進度，進行項目 管理工作，確保開發能及時完成并能滿足業務需要。項目組人員的選擇應滿 足項目對業務及技術要求，項目組人員應有足夠的業務和IT技術方面的專 業知識來勝任項目各方面的工作。3需求分析立項后業務組對用戶需求進行匯總整理，出具業務需求說明書（附件二）， 并確保業務需求說明書中包含了所有的業務需求。經系統使用部門審批 確認，作為業務需求基線。IT組在獲得業務需求說明書后，提出技術需求和解決方案，并對系統進 行定義，出具系統需求規格說明書（附件三）。系統需求規格說明書 需詳細列出業務對系統的要求（界面、輸入、輸出、管理功能、安全需求、 運作模式、關鍵指標（KPI）等）。系統需求規格說明

6、書需要由業務組提交 給相關業務流程負責人確認。對于合作開發的項目，當業務需求發生變更時，業務組應提交需求變更申 請（附件四），IT組組長審批后交給合作開發商實施。項目組應對需求變更影響到的文檔及時更新。4項目計劃和監控軟件開發采用項目形式進行管理。項目經理負責整個項目的計劃、組織、領 導和控制。需求分析過程中，項目經理組織制定詳細的項目計劃書（附件五），包括 具體任務描述和項目進度表等。在項目的各個階段，業務組組長和IT組組長需配合項目經理制定階段性項 目計劃。業務組組長和IT組組長需配合項目經理對項目計劃執行情況進行 監控，確保項目按計劃完成。項目計劃需要變更時，項目經理填寫項目計劃變更說明

7、（附件六），并提 交公司主管領導審批，通過審批后，交給業務組組長和IT組組長執行。5系統設計系統設計應分為概要設計和詳細設計，系統設計要遵循完備性、一致性、擴 展性、可靠性、安全性、可維護性等原則。在系統設計階段中，用戶應充分參與，確保系統設計能滿足系統需求。項目組進行詳細設計，出具設計說明書（附件七）和單元測試用例（附件八）。設計說明書中需要定義系統輸入輸出說明和接口設計說明。公司 主管領導組織相關人員對概要設計進行評審，出具設計評審報告（附件 九）。業務組組長和IT組組長應參加此評審并對評審意見簽字確認。設計評審均以業務需求說明書和系統需求規格說明書為依據，確保 系統設計滿足全部需求。對已

8、確認通過的系統設計進行修改需獲得管理部門、業務組組長和IT組組 長的審批后方可進行。對系統設計的修改的文檔須由文檔管理人員進行歸檔管理。6系統實現項目組根據設計說明書制定系統實現計劃，并提交項目經理對計劃可行 性進行審批。系統實現包括程序編碼、單元測試和集成測試。項目組保證開發、測試和生產環境獨立，為各環境建立訪問權限控制機制，并明確項目成員的職責分工。對開發環境、測試環境與生產環境在物理或邏 輯方面應該做到隔離；如果環境的分隔是通過邏輯形式實現的，應定期檢查 網絡設置。項目組對已授權訪問生產環境的人員進行詳細記錄，并對該記錄 進行定期檢查，確保只有經授權的人員才能訪問到生產環境。項目組進行單

9、元測試和集成測試，測試人員簽字確認測試結果。7系統測試和用戶測試項目組制定系統/用戶測試計劃（附件十），并提交項目經理對計劃可行 性進行審批。系統/用戶測試計劃必須定義測試標準，并明確各種測試的測試步驟和 需要的系統設置要求。項目組向數據擁有部門申請獲取測試用業務數據的使用權，對獲取的數據進 行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。項目組負責測試數據準備，測試用數據要足夠模擬生產環境中的實際數據。 對己評定為敏感信息的數據進行敏感性處理和保護。IT組或合作開發商建立測試環境進行系統測試。在系統測試中對新系統內部 各模塊之間的接口和與其他系統的接口進行充分測試。出具系統測試報告（附

10、件十一），測試人員簽字確認測試結果。系統測試通過后，IT組配合業務組建立用戶測試環境，業務組根據用戶測試 用例進行用戶測試，出具用戶測試報告（附件十一），業務組組長和IT 組組長應在用戶測試報告中簽字確認。項目組完成系統幫助文檔（其中包括用戶操作手冊和安裝維護手冊）。 凡涉及應用系統的變更，應對系統幫助文檔及時更新。8試運行系統主要使用部門根據項目規模及影響決定試運行策略。項目組制定試運行計劃（附件十二），并制定試運行驗收指標，上報公司 主管領導審批。試運行計劃中應包含問題應對機制，明確問題溝通渠道 和職責分工。項目組聯合試運行單位進行相關系統部署工作，準備培訓資料，對相關用戶 和信息技術人員

11、進行培訓。用戶培訓的完成度應為實施后評估的指標之一。項目組根據試運行計劃進行系統轉換和數據遷移。系統轉換前，檢查系 統環境，確保運行環境能滿足新應用系統的需要。系統轉換時必須詳細記錄 原系統中的重要參數、設置等系統信息，并填寫試運行報告相關內容。系統 參數、設置的轉換工作作為系統上線的驗收的評估指標之一。數據遷移前，應制定詳細的數據遷移計劃（附件十三），數據遷移計劃 中應包含遷移方案、測試方案、數據定義，新舊數據對照表、遷移時間、回 退計劃等信息。數據遷移計劃需經項目經理和主管領導簽字審批。數據遷移后，項目組對數據遷移的完整性和準確性作出檢查，出具數據遷 移報告（附件十四），其中包括數據來源、

12、轉換前狀態、轉換后狀態，數據 遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗 收轉換結果后在該報告上簽字確認。系統轉換和數據遷移由試運行單位業務部門和公司主管領導共同監督并進 行驗收。系統轉換和數據遷移驗收通過后，正式啟動試運行。在試運行過程中，試運 行單位辦公室把系統運行情況（系統資源使用，反應速度等）記錄到試運行 報告中。必要時，項目組應根據系統運行情況對應用系統進行優化。試運行達到試運行計劃規定的終止條件時，項目組編寫試運行報告（附 件十五）。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導 審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。9系統驗收系

13、統主要使用部門及信息技術部門聯合組成獨立系統驗收小組，也可授權原 項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統進行綜合 評估。驗收小組應根據驗收情況整理形成系統驗收報告（附件十六）提交系統 主要使用部門和信息技術部門審閱。系統主要使用部門和信息技術部門負責人根據系統測試、試運行情況簽署驗 收意見。10系統上線系統上線應遵循穩妥、可控、安全的原則。通常情況下，系統上線包含數據遷移工作。項目組制定系統上線計劃（附件十七），上報公司主管領導審批。在上線 計劃得到批準后才能開始部署上線工作。系統上線計劃內容應包括但不限于：部署方式和資源分配（包括人力資源及服務器資源）；上線工作時間表；上

14、線操作步驟以及問題處理步驟；項目階段性里程碑和成果匯報（項目執行狀態的審閱、進度安排等）；數據遷移的需求和實施計劃；完整可行的應急預案和“回退”計劃；用戶培訓計劃（包括：培訓計劃、培訓手冊、培訓考核等）；公司下發的系統標準參數配置。上線單位在上線初期需加強日常運行狀態監控，出現問題時應及時處理，對 重大問題應啟動緊急預案。在完成上線后要填寫系統驗收評估報告（附件十八），上報公司項目組匯 總整理。系統驗收評估報告內容包括：數據準確性、系統性能及穩定性、 接口問題、權限問題、業務操作影響度、問題處理情況、備份、批處理等。上線單位管理層要對系統驗收評估報告進行審批簽字。公司主管領導批準結項后，業務組

15、和IT組將整理的文檔提交各自部門統一 管理。11合作開發管理合作開發商的選擇應遵循公司相關規定，合作商資質認定參見第三方管理制 度。合作開發商必須遵循公司軟件開發管理制度。項目經理同合作開發商明確規定項目變更的范圍和處理方式，重點關注需求 和設計變更。項目經理負責監控合作開發商的項目管理及軟件開發活動。合作開發商應按 計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題 時，合作開發商需及時向項目經理匯報。IT組組長派專人監控合作開發商的質量保證過程。項目組同合作開發商商定驗收的標準和方法。以上各要求需要在開發合同中明確。12外包開發管理立項申請得到公司主管領導的審批后，選定開發

16、商，確保承包方有相應資質， 簽訂外包開發合同。與選定開發商簽訂保密協議，明確其保密責任。要求選定開發商提供所有必要的軟件配置項。應確保所有軟件配置項為最新，與實際運行環境配套。應確保所有軟件配置項安全，由專人負責管理。應在軟件安裝之前根據開發要求檢測軟件質量，包括功能、性能和安全的各 個方面，檢測軟件包中可能存在的惡意代碼，并審查其中可能存在的后門。核心業務系統或模塊宜由委托方（即本機構）自主開發。項目經理負責監控外包開發商的項目管理及軟件開發活動。外包開發商應按 計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題 時，外包開發商需及時向項目經理匯報。項目經理監控外包開發商的質

17、量保證過程。項目組同外包開發商商定驗收的標準和方法。以上各要求需要在開發合同中明確。13外包服務管理機房托管服務的受托方必須滿足征信管理機構等相關管理部門規定的資質 要求。機房托管服務的受托方及其法定代表人在征信系統中必須無不良信用記錄。應與外包服務的受托方簽訂正規的外包服務合同，明確其權利和責任。應確保外包服務的受托方的系統訪問權限受到約束，涉及敏感操作（如輸入 用戶口令等）應由委托方人員進行操作。外包服務的受托方進行現場技術支持服務時，應事先提交計劃操作內容。委 托方應在現場陪同服務外包人員，核對操作內容并準確記錄實際操作內容。 外包服務的受托方人員不得查看、復制或帶離任何敏感信息。外包服

18、務的受托方應嚴格履行服務外包合同（協議）中的各項安全承諾，在 提供技術服務期間，應嚴格遵守委托方相關安全規定與操作規程。14附則本制度由公司總部信息技術部負責解釋和修訂。本制度自發布之日起開始執行。附件一立項分析報告立項分析報告文件狀態：文件標識：ProjectName-V草稿當前版本：X. Y正式發布作者：L J止在修改完成日期：Year-Month-Day版本歷史版木/狀態作者參與者起止日期備注1項目介紹1.1項目目的提示:用簡練的語言說明本項目“是什么”,“實現什么目的”。描述簡練且清 晰。1.2項目背景提示:闡述項目背景,重點說明“為什么”會產生本項目。公司的短期、長期發展戰略;業務需

19、求及發展趨勢;技術狀況及發展趨勢;特殊的業務需求等。3項目范圍提示:根據對現有需求的了解來確定項目基本范圍,說明本系統“應當包含的 內容和“不包含的內容2項目計劃1.4項目團隊提示:說明項目團隊的角色、知識技能要求、建議人選、人數、工作時間,如 下表所示。角色知識技能要求建議人選、人數工作時間項目經理需求開發人員系統設計人員編程人員測試人員質量保證人員配置管理人員服務與維護人員1.5成本估計內容成本（人民幣）備注人力資源軟硬件資源差旅費會議費接待費1.6進度表提示:制定項目開發的進度表（建議給出項目里程碑計劃）。例如:編號里程碑名稱預計結束時間備注需求調研完成項目計劃完成需求分析完成概要設計完

20、成詳細設計完成實現完成集成測試完成系統測試完成用戶驗收測試完成試運行結束項目驗收3總結提示:給出清晰的建議結論,便于上級領導決策。附件二業務需求說明書文件狀態：J草稿正式發布正在修改文件標識：ProjectName-當前版本：X. Y作者：完成日期：Year-Month-Day版本歷史版本/狀態作者參與者起止日期備注業務需求說明書1概述1.1業務調研人員名單【可選】序號職能部門姓名主管聯系電話備注1.2業務范圍此處描寫總、體業務的概要分類并。1.3業務目標從高層或商務利益的角度提出本業務系統的期望目標,以及評價標準。4相關文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物）,包括現有規范、

21、標準、 批文、引用到的文件、資料等。5業務詞匯表說明:列岀木文檔的所引用的專屬領域詞匯、術語等,以便于業務需求的提供者和 接收者是建立在一致的業務理解基礎之上的。2組織結構及業務2.1業務相關組織結構、人員組織結構說明:如果客戶崗位設置復雜可分別設置,業務組織結構和人員組織結構2組織機構描述2.3角色職責說明:將業務涉及的具體人員進行一定程度的分類和抽象,描述該抽象角色的操作 職責。2.4管理綜述【可選】說明:主要描述該業務的管理特點和管理模式。例如:典型按庫存生產模式。生產計劃以年度銷售計劃為指導,并綜合考慮設備能力、 生產天數、庫存、歷史銷售記錄。采購計劃的制訂以生產計劃為依據。5現有業務

22、流程清單【可選】說明:現有業務流程需要考慮,很多新的業務是在已有業務流程基礎上進行重組的。流程編號流程名稱責任部門輔助部門3業務流程及業務處理描述說明:針對每一項具體的目標業務,描述具體的業務流程,以及相關業務的具體描 述。3.1具體業務流程（系統名稱+編號）對于具體業務流程的命名有規范,對具體流程進行編號,便于形成需求矩陣,同時 形成需求的管理和跟蹤。3.1.1業務流程1.2業務描述說明:描述具體的業務流程。1.3相關業務對象說明:業務對象:業務流程中涉及的單據、報表等。業務對象使用部門對應電子檔案編號3. 1.4業務規則及關鍵算法說明:描述業務環節關鍵算法體系。4假定和約束說明：列出進行本

23、軟件開發工作的假定和約束,例如開發期限等。4.1運行環境約束4.2設計約束【可選】說明:開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、 第三方產品等。4.3產品應當遵循的標準或規范【可選】說明:闡述木產品應當遵循什么標準、規范或業務規則,違反標準、規范或業務規 則的產品通常不太可能被接受。5其他5.1目前核心問題和困難5.2業務對項目實施的需求和期望【可選】5.3其他未盡事宜附件三系統需求規格說明書文件狀態：J草稿正式發布正在修改文件標識：ProjectName-當前版本：X. Y作者：完成日期：Year-Month-Day版本歷史版本/狀態作者參與者起止日期備注系統需求

24、規格說明書1引言1.1目的例如:規定系統的邊界和目標,描述系統的功能性需求和非功能性需求。1.2讀者對象及閱讀建議說明:指明本文檔面向的讀者群，及相應的閱讀意見。1.3文檔范圍【可選】說明:對本文的范圍做闡述,本文檔改動時,受到影響的范圍,例如,木:文引用到 的用例模型,系統原型,系統測試用例等文檔。1.4參考文檔說明：列岀本文檔的所有參考文獻（可以是非正式出版物）,包括計劃任務書、合同、 批文、引用到的文件、資料及軟件開發標準等。5術語與縮寫解釋說明:列出木文件中用到的專門術語的定義和縮寫詞的原詞組,并給予解釋,以便 于所有讀者達成共識。2綜合描述1系統背景【可選】說明:介紹系統的預期效果、

25、歷史原因。2.2問題說明【可選】提供一段說明，總結此項目需要解決的問題。可以采用以下格式:問題是對問題進行說明影響問題影響的干系人問題的后果該問題會導致什么后果成功的解決方案應列出成功解決方案的一些主要優點2. 3系統范圍說明:闡述木項目“適用的業務領域”和“不適用的業務領域”,本產品“應當包含 的內容”和“不包含的內容”。說清楚系統范圍的好處是:(1)有助于判斷什么是需 求,什么不是需求;(2)可以將開發精力集中在產品范圍之內;(3)有助于控制需 求的變更。完整而準確的定義本產品的干系人；明確本產品所影響到的部門和業務；用圖表或者文字描述產品的范圍，概要的定義產品的功能。2.4干系人與用戶說

26、明【可選】4.1用戶環境【可選】詳細說明目標用戶的工作環境。以下是幾項建議：該任務由多少人來完成?是否總在變化?一個任務周期需要多長時間?執行每項活動要用多長時間?是否總在變化?是否有特殊的環境約束:移動、戶外、乘機旅行等?目前使用的是哪些系統平臺?以后會使用哪些平臺?還在使用哪些應用程序?您的應用程序是否需要和這些應用程序集成?在此處可以從業務模型中摘錄一些內容來概述所涉及的任務和角色等等。2.4.2干系人簡檔【可選】通過在下表中填寫各干系人的相關信息來說明系統中的各個干系人,詳盡的簡檔應 包括各種干系人在以下方面的信息:代表誰是此產品的干系人代表？（如在他處已作記錄，則此處為可 選。）此處

27、只需填寫姓名。說明對干系人類型的簡要說明。類型介紹干系人的技能特長、技術背景和熟練程度（即權威用戶、業 務用戶、專家用戶、初級用戶等）職責列出干系人對所開發的系統負有的關鍵職責，即他們作為干系人 的利益。使用頻率該干系人使用系統的頻率意見/問題在此處列出會阻礙成功的問題以及任何其他相關信息。4. 3關鍵的干系人/用戶需要列出干系人認為現有解決方案存在的關鍵問題。對于列出的每個問題,需澄清以下 要點:為什么會出現這一問題？目前如何解決該問題？干系人需要什么樣的解決方案？ 務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法表 明，必須解決的問題與干系人或用戶希望解決的問題大有不

28、同。2.5目標業務模型【可選】說明:新系統業務模型描述,如有相應業務模型材料了,可作為需求規格說明書的 輸入參考資料。2.6功能摘要總結該產品將提供的主要優點和特性,而不必涉及每個功能的細節。對功能加以組 織,使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。2.7功能清單及重要程度說明說明:功能名稱、功能描述、重要程度。重要程度，以ABC三類來表示：A：核心功能；B：輔助功能；C：外圍功能；級別，按照繼承關系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注2.8功能與*上務對照關系表說明:業務組為主編寫業務需求,業務需求提交至信息技術組后,由信息技術組建 立目標系統業務模型并與業

29、務組進行確認（本操作可選,也可由信息技術組與開發 商合作建立）,目標業務模型作為系統需求的輸入,由信息技術組與開發商合作撰寫 和評審系統需求規格書明書。業務需求目標系統業務活動（可選）功能名稱2.9假定和約束說明:列出進行本軟件開發工作的假定和約束,例如:開發語言、開發期限等。 格式限制說明:本項將指定由現有的標準或規則派生的要求。例如:報表格式;數據命名;財務處理;審計追蹤,等等。硬件限制說明:本項包括在各種硬件約束下運行的軟件要求,例如,應該包括: 硬件配置的特點（接口數,指令系統等）;內存儲器和輔助存儲器的容量。2.9. 1運行環境約束說明：硬件設備、支持軟件、接口、控制等方面的約束名稱

30、詳細要求2. 9. 2設計約束【可選】說明:開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、 第三方產品等。9. 3產品應當遵循的標準或規范說明:闡述本產品應當遵循什么標準、規范或業務規則,違反標準、規范或業務規 則的產品通常不太可能被接受。3具體需求1功能需求1. 1具體功能1. 1. 1 內容說明:對于每一類功能或者有時對于每一個功能,需要具體描述其輸入、加工和輸 出的需求。3.2非功能需求1外部接口1.1用戶接口說明:提供用戶使用軟件產品時的接口需求。例如,如果系統的用戶通過顯示終端 進行操作,就必須指定如下要求:a 對屏幕格式的要求說明:對界面上的各對象、類型、寬度

31、、取值范圍、數據來源、能否為空等屬 性進行描述。b 報表或菜單的頁面打印格式和內容c 輸入輸出的需求說明:解釋各輸入輸出數據類型,并逐項說明其媒體、格式、數值范圍、精度 等。對軟件的數據輸出及必須標明的控制輸出量進行解釋并舉例,包括對硬拷 貝報告（正常結果輸出、狀態輸出及異常輸岀）以及圖形或顯示報告的描述。d 程序功能鍵的可用性說明:快捷鍵定義等。1.2硬件接口【可選】說明:要指出軟件產品和系統硬部件之間每一個接口的邏輯特點。還可能包括如下 事宜:支撐什么樣的設備,如何支撐這些設備,有何約定。1.3軟件接口【可選】說明:在此要指定需使用的其他軟件產品（例如,數據管理系統、操作系統或數學 軟件包

32、）,以及同其他應用系統之間的接口。對每一個所需的軟件產品,要提供如下 內容:名字、助記符、規格說明號、版本號、來源。對于每一個接口,這部分應說明與軟件產品相關的接口軟件的目的,并根據信息的 內容和格式定義接口,但不必詳細描述任何已有完整文件的接口,只要引用定義該 接口的文件即可。【接口定義】下表是對一些接口的具體描述:接口名稱接口描述填寫接口完成的任務接口類型填寫是輸入接口(inbound)還是輸出接口 (outbound)源系統填寫接口輸入方系統或部件目標系統填寫接口輸出方系統或部件廠商提供/客戶化開發文件類型填寫文件類型；若通過數據庫表來交互，請指明數據庫 及表名文件數量峰值數據量頻度填寫

33、數據處理的頻度復雜度批處理/人工填寫接口數據的驅動模式是人工(nianual)還是自動 (automatic),還是都支持接口類型填寫是實時接口還是批量接口等【其他系統詳細信息】說明:列出所有與接口交互的外圍系統的詳細信息。包括輸入、輸出系統等系統填寫與接口交互的系統名稱系統類型填寫是接口的數據源系統(source)還是目標系統 (object)數據庫填寫交互系統使用的數據庫及版本軟件填寫交互系統的軟件名稱架構類型交互系統的架構類型是B/S還是C/S。位置填寫該軟件在交互軟件體系中所出的位置技術支持填寫交互系統的開發商和支持商功能支持填寫具體的支持商或技術團隊數據歸屬【接口隸屬系統的詳細信息可

34、選】系統填寫接口隸屬系統的名稱模塊隸屬于具體的模塊名稱數據庫隸屬系統的數據庫及版本負責人控制報告【接口配置】接口基礎信息配置說明:接口基礎信息的配置項目,描述配置的方式。接口運行參數配置說明:接口運行參數的配置方式和步驟。【其他配置可選】說明:外圍系統或相關模塊的配置。1.4通信接口【可選】說明:指定各種通信接口。例如,局部網絡的協議等等。3.2.2其他非功能性需求說明:下表中的各種需求,可根據實際情況進行選擇其中的一種或者幾種進行描述, 在表的后面是各種需求的詳細解釋。名稱詳細要求靜態數值需求動態數值需求精度時間特性要求可用性可靠性可維護性安全性可移植性可擴展性兼容性3. 2. 2. 1靜態

35、數值需求說明:支持的終端數;支持并行操作的用戶數。2動態數值需求說明:欲處理的事務和任務的數量,以及在正常情況下和峰值工作條件下一定時間 周期中處理的數據總量。2. 2. 3 精度說明:對該軟件的輸入、輸出數據精度的要求,可能包括傳輸過程中的精度。3. 2.2. 4時間特性要求說明:對于該軟件的時間特性要求,如對:響應時間；更新處理時間；數據的轉換和傳送時間；解題時間等要求。3. 2. 2. 5數據管理要求【可選】說明:需要管理的文卷和記錄的個數、表和文卷的大小規模,要按可預見的增長對 數據及其分量的存儲要求做出估算。3. 2. 2. 6可用性指出普通用戶和高級用戶要高效地執行特定操作所需的培

36、訓時間,指出典型任務的 可評測任務次數或根據用戶已知或喜歡的其他系統確定新系統的可用性需求性能3. 2. 2. 7可靠性指出可用時間百分比(XX. XX%).使用小時數、維護訪問權、降級模式操作等。平 均故障間隔時間(MTBF)O平均修復時間(MTTR)系統在發生故障后可以暫停運行 的時間。指出系統輸出要求具備的精密度(分辨率)和精確度(按照某一已知的標 準)。3.2.3文檔需求說明:主要是在線用戶手冊與幫助系統,也包括其他的文檔3.2.4第三方產品【可選】說明:使用到的第三方產品相關的使用許可、使用限制、接口標準。3.3數據字典說明:把相關的數據抽取出來統一維護,在其他章節如有類似信息描述,

37、則關聯到 數據字典的相關部分并加輔助說明,如:引用到的字段等。4補充資料【可選】1待確定的問題列表【可選】需求標題1調查方式調查人調查對象時間、地點需求信息記錄附件四需求變更申請需求變更申請記錄號:項目：類型：開發項目項目負責人：變更申請人：申請部門：申請日期：變更內容變更的內容及其理由說明變更的內容及變更的理由,如果變更為業務組提出,則業務組填寫;如果變更為信息技術組提出,則信息技術組填寫;變更的系統及版本說明變更所涉及的工作產品及其當前版本, 如果變更為業務組提出,則業務組填寫;如果變更為信息技術組提出,則信息技術組填寫;對業務及其接口的影響分析需求變更引起的業務變更、業務接口的變更,業務

38、組填寫業務負責人意見同意不同意簽字：日期：變更結果變更分析對相關的資源影響分析需求變更對人員、開發設備和目標設備的影響, 僅信息技術組填寫風險分析分析需求變更的風險, 僅信息技術組填寫對其他系統或接口 的影響分析需求變更引起的系統變更、其他系統或接口的變更, 僅信息技術組填寫對開發工作量、進 度和成本影響估計需求變更對開發工作量和進度的影響,需說明本次變更工作量/ 成本是否超過本項目總開發工作量/總成本的1%?僅信息技術組填寫信息技術部審批意見信息技術組負責人 意見：同意不同意指定驗證人員：簽字：日期：處經理意見：同意不同意匯報上級簽字：日期：上級經理意見：同意不同意簽字：日期：變更結果變更的

39、系統及版本說明變更后的工作產品簽字：日期：變更驗證驗證變更結果完整性是否正確性是否附加變更是否版本和名稱是否驗證人意見符合要求不符合要求簽字：日期：附件五項目計劃書密級：內部項目計劃書編號：CE-Q/JL-002- (1205) - (001)版本：VI. 0 項目名稱: 提交人： 提交日期:總頁數正文附錄生效日期：年 月 日編制：審核：批準：文件變化記錄單版本編號變化狀態簡要說明變更人變更日期批準人批準日期VI. 0C初始創建注：變化狀態：C-初始創建；A增加內容；M修改內容；D刪除內容。1項目概述2項目名稱3用戶介紹4項目背景5項目目標6項目范圍7項目組織8項目組成員結構TaskRoles

40、P0SMTeamQACM需求確認概要設計編碼實現系統部署過程與產品質量保證項目整體監控風險與問題管理外部接口人事務內容接口人接口方式電話E-mail工作匯報北大老師郵件，會議9技術路線一般網站架構，出于性能考慮，采用memcache.10系統集成計劃關聯系統名稱是否為本 期計劃計劃開始 日期計劃結束日期關聯系統 接口人備注無/本期無集成 計劃11 Sprint Planning序號計劃開始日期計劃結束日期產出物估算（速率）12評審計劃序號評審活動評審方式評審對象預計評審時間評審負責人1213風險管理暫無14培訓計劃需培訓內容培訓時間需參加培訓人員培訓講師暫無/15下屬計劃序號計劃名稱負責人Sp

41、rirrt Planning （project 計劃）SM&Team總體測試計劃測試負責人系統部署計劃運維負責人度量計劃SM&QA質量保證計劃QA配置管理計劃CM16項目產出物序號產出物名稱是否裁剪裁剪理由說明附件六項目計劃變更說明項目名稱申請日期項目計劃變更申請申請變更的 項目計劃輸入名稱，版本，完成日期等信息變更的內容 及其理由評估計劃變更將對 項目造成的影響項目負責人簽字變更申請的審批意見處經理審批審批意見：簽字，日期信息技術部負責人 審批審批意見：簽字，日期業務部門意見審批意見：簽字，日期更改項目計劃變更后的項目計劃輸入名稱，版本，完成日期等信息項目負責人簽字附件七概要設計說明書文件狀

42、態：V草稿正式發布正在修改文件標識：ProjectName-ModuleDesign當前版本：X. Y作者：完成日期：YearMonthDay版本歷史版本/狀態作者參與者起止日期備注保密級別：機密概要設計說明書項目/產品: 版本號： 編寫者： 審核者： 批準者： 二O二O年五月十九日引言1.1編寫目的1.2背景暫略去。1-3定義參考資料GB/T 9385-2008計算機軟件需求規格說明規范總體設計2. 1需求規定2. 1. 1系統功能2. 1. 2系統性能要求系統初期能夠支撐千萬級的數據量。至少200人同時在線操作平臺數據的負載 里。2. 1.2. 1良好的用戶界面2. 1.2.2可維護性2.

43、 1.2.4可擴展性2. 1.2.5安全性原則2. 1.2. 6穩定性2. 1.2.7數據完備性2. 1. 3輸入輸出要求2. 1.4數據管理能力要求2. 1.5故障處理要求2. 1.5. 1硬件故障2. 1.5.2軟件故障2. 1.6其他專門要求2. 2運行環境1設備要求2. 2. 2支持軟件2. 2. 3遠程接口。2. 2. 4控制3基本設計概念和處理流程2. 3. 1總體流程描述2. 3. 2標準功能處理流程2. 3. 3權限控制2. 3. 4數據模型2. 4功能結構2.4.1會員信息管理模塊2.4.2貸款客戶信息查詢2.4.3從業人員不良信息管理2. 5人工處理過程6尚未解決的問題接口

44、設計1數據字典描述3.2外部接口1軟件接口3.2.2硬件接口3.3內部接口運行設計1運行組合服務2運行控制3運行時間系統數據結構設計1邏輯結構設計要點2物理結構設計要點3數據結構與程序的關系暫無。系統出錯處理設計1出錯信息2補救措施3系統維護設計附件八單元測試用例1測試范圍說明:本用例測試的功能點。2測試環境環境1：硬件環境： 服務器端: 客戶端:軟件環境： 服務器端: 客戶端:網絡環境:環境2：3數據準備說明:可以引用適當的附件,如EXCEL文件、文本文件等扁平文件等,這些文件內 存放著測試準備的數據。測試用例功能1測試編號功能模塊一子模塊一編號測試項目模塊功能一子模塊功能用例描述描述測試上

45、述功能的測試點依賴描述無環境及初 始數據環境1,填寫用到的各種測試數據的名稱依賴樣例測試本用例依賴的相關用例名稱序號前置條件測試子項執行步驟預期結果實際結果備注測試序號填寫本用 例運行的 前置條 件。如登 陸、權限、 設備就緒 等；說明測試 的基本流 還是備選 流；要求 測試遍歷 所有的備 選流；詳細列出 各個用例 角色的操 作的動 作。對應每一 步的預測 結果；對應每一 個執行步 驟的實際 結果；填寫與測 試相關聯 的核對 點、檢查 點。附件九設計評審報告文件狀態：J草稿正式發布正在修改文件標識：ProjectName-當前版本：X. Y作者：完成日期：Year-Month-Day版本歷史版

46、本/狀態作者參與者起止日期備注設計評審報告基本信息提示:由評審主持人或評審員填寫此表格。待評審的工作成果工作成果名稱，標識符，版本，作者，時間技術評審方式（正式評審）或者（走查）評審時間評審地點參加技術評審的人員類別名字工作單位職稱、職務：主持人評審 小組 成員記錄員缺陷識別和跟蹤評審問題跟蹤表編號問題描述問題類型嚴重性提交者提交日期問題 處理 負責 人解決 措施 /原 因說明問題解決狀態實際關閉日期問題 關閉 驗證 人備注123評審結論與意見提示:由主持人或評審員填寫此表格。評審結論工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。 J工作成果基本合格，需要作少量的修改，之后通過審

47、核即可。工作成果不合格，需要作比較大的修改，之后必須重新對其評 審。意見負責人簽字：簽字日期：附件十 系統/用戶測試計劃文件狀態：V草稿正式發布正在修改文件標識：當前版本：作者：完成日期：YearMonthDay版本歷史版本/狀態作者參與者起止日期備注系統/用戶測試計劃測試范圍與主要內容提示：系統測試小組應當根據項目的特征確定測試范圍與內容。一般地，系統 測試的主要內容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性 (security)測試、安裝與反安裝測試等。測試方法提示：例如黑盒測試和白盒測試。測試環境與測試輔助工具環境設備配置名稱/類型備注服務器軟件硬件客戶端軟件硬件網絡工具類

48、型工具開發商版本測試管理缺陷跟蹤用于功能性測試的工具用于性能測試的工具測試覆蓋監測器或評測器4.測試進度計劃任務人員任務開始日期結束日期制定測試計劃設計測試實施測試執行測試對測試進行評估5.測試完成準則提不：對于非嚴格系統可以采用“基于測試用例”的準則：功能性測試用例通過率達到100%；非功能性測試用例通過率達到95%時。對于嚴格系統，應當補充“基于BUG密度”的規則：相鄰n個CPU小時內“測試期BUG密度”全部低于某個值m。例如n大于10, m小于等于1。最后一次回歸測試二類缺陷數量為零，用例外非常規缺陷數量小于等于2個/萬行程序；測試用例功能點覆蓋率100%；BUG管理與改錯計劃提示：根據

49、所采用的BUG管理工具確定：（1） BUG管理流程，（2） BUG修改流 程。定義BUG修改約定，例如：不同級別的BUG必須在幾日內處理完成。附錄.本計劃審批意見項目經理審批意見:簽字日期附件十一系統/用戶測試報告1.基本信息測試依據例如：參照標準、客戶需求、需求規格說明書、測試用例等測試范圍測試驗收標準測試環境描述測試驅動程序描述提示：可以把測試驅動程序當作附件測試人員測試時間須注明每次回歸測試 的時間測試工具2.實況記錄模塊測試用例編號期望結果測試結果缺陷密度是否執行了回歸測試3.測訶Q總評價根據對測試結果提出一個關于軟件能力的全面分析，需標明遺留的主要缺陷、局限性 和軟件的約束限制等，并

50、提出軟件測試過程中程序中的不足。根據測試標準及測試結果，綜合評價軟件的開發是否已達到預定目標。缺陷修改記錄提示：如果采用了缺陷管理工具，能自動產生缺陷報表的話，則無需本表。缺陷名稱缺陷類型嚴重程度模塊原因駐留時間解決方案測試人員簽字/日期:附件十二試運行計劃文件狀態：V草稿正式發 布正在修 改文件標識：ProjectName-TestRun-PLAN當前版本：X. Y作者：完成日期：Year-MonthDay版本歷史版本/狀態作者參與者起止日期備注試運行目標提示：說明本次試運行的主要內容與目標（必須是可以驗證的）。工作條件提示：說明試運行地點、參加人員、軟硬件設施、經費等要求。3.應遞交的工作

51、成果工作成果名稱預計完成時間試運行報告報錯趨勢分析報告4.進度表提示：（1）用Microsoft Project制作進度表（Gantt Chart）插入此處或者參照此表制作一份進度表。任務名稱及其描述開始時間結束時間參加人員任務1任務25.可能存在的困難與風險提示：指出可能存在的困難和風險，制定應急計劃以應對突發事件。附錄：本計劃審批意見提示：項目經理或者技術負責人根據項目計劃以及現實情況（如可以支配的人 力資源），審批該試運行計劃。項目經理或試運行負責人審批意見:日期簽字附件十三數據遷移計劃數據遷移的重要事件和里程碑日期數據遷移前的備份要求數據遷移測試結果清單轉換工作進度表提示：（1）用Microsoft Project制作進度表（Gantt Chart）,插入此處或作 為附件。（2）或者在此處用表格制作一份進度表，例如：任務名稱及其描述開始時間結束時間參加人員任務1任務2轉換操作步驟以及問題處理步驟數據核對計劃數據遷移的需求和實施計劃應急預案及回退計劃1）分析引發轉換失敗的潛在原因提示：說明轉換失敗的幾類原因，考慮人員、軟硬件設施、經費等因素。2）預防措施提示：針對轉換失敗的幾類原因，制定預防措施。3）事件處理及回退計劃提示