1、信息系統(tǒng)開發(fā)項目管理指導書1、 項目建設總體目標 系統(tǒng)應該根據甲方用戶的現有業(yè)務需求及發(fā)展規(guī)劃的擴延要求，提供功能完善、界面友好、流程清晰、智能高效，配置維護方便的系統(tǒng)功能，滿足系統(tǒng)運行穩(wěn)定、安全、可靠、高效等技術要求。提供電腦版和手機版2個版本。2、 項目開發(fā)建設過程及要求 為了確保項目能按照甲乙雙方達成的目標要求順利開展，甲乙雙方應該聯合成立項目組，由乙方編制項目執(zhí)行計劃（式樣見附件1）并有甲方確認同意。2.1 系統(tǒng)需求分析 1、開發(fā)商必須對甲方公司的業(yè)務需求進行深入調研，收集匯總客戶的具體需求，出具業(yè)務需求說明書（式樣見附件2），并確保業(yè)務需求說明書中包含了所有的業(yè)務需求。業(yè)務需求說明書

2、經甲方公司（用戶）負責人簽字確認，作為業(yè)務需求基線。 2、開發(fā)商在獲得甲方簽字確認的業(yè)務需求說明書后，提出技術需求和解決方案，并對系統(tǒng)進行定義，出具系統(tǒng)需求規(guī)格說明書（式樣見附件3）。系統(tǒng)需求規(guī)格說明書需詳細列出業(yè)務對系統(tǒng)的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關鍵指標等）。系統(tǒng)需求規(guī)格說明書需經甲方公司（用戶）負責人簽字確認。 3、當業(yè)務需求發(fā)生變更時，應由甲方公司提交需求變更申請（式樣見附件4）給乙方開發(fā)商實施。2.2 系統(tǒng)設計為簡化流程，本項目建議將概要設計和詳細設計合二為一，統(tǒng)一遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。1、在該階段確定總體結構和軟件開

3、發(fā)架構，文件命名規(guī)范，編碼規(guī)范。按軟件需求劃分成子系統(tǒng)，定義目標系統(tǒng)的功能模塊及各個功能模塊的關系。2、確定軟件模塊結構，給出每個功能模塊的功能描述、數據接口描述，各模塊之間的詳細接口信息，并完成系統(tǒng)設計說明書(式樣見附件5)。3、系統(tǒng)設計說明書應該包括所有用戶界面的原型圖。4、完成數據庫的設計，并編寫數據庫設計說明書。5、在設計階段，用戶應充分參與，確保設計能滿足系統(tǒng)需求。 6、甲方應對組織對開發(fā)商提交的系統(tǒng)設計說明書進行評審，設計評審均以業(yè)務需求說明書和系統(tǒng)需求規(guī)格說明書為依據，確保系統(tǒng)設計滿足全部需求，并出具系統(tǒng)設計評審報告（式樣見附件6）。2.3 系統(tǒng)開發(fā) 1、系統(tǒng)開發(fā)包括程序編碼、單

4、元測試和集成測試。開發(fā)商根據系統(tǒng)設計說明書制定系統(tǒng)開發(fā)計劃，并提交給甲方對計劃進行監(jiān)督。 2、開發(fā)商有條件的情況下盡可能開發(fā)、測試和生產環(huán)境獨立。選擇軟件工具，明確項目成員的職責分工，按照編碼規(guī)范和詳細設計實現軟件功能。3、代碼應滿足結構良好，清晰易讀，且與設計一致，符合編碼規(guī)范。4、開發(fā)人員需要軟件實現過程中編寫軟件功能說明，源代碼說明。軟件功能說明文檔應說明項目名稱、編號、軟件名稱和版本號，軟件功能、主要功能實現過程。源代碼說明應說明項目編號、軟件名稱、功能，全局變量、數據庫字典、函數功能、接口。該文檔包含在源代碼文件中，以注釋形式存在。5、開發(fā)商進行單元測試和集成測試。開發(fā)人員處理測試人

5、員反饋的測試問題，并以書面形式反饋主要問題及解決辦法，直至系統(tǒng)運行穩(wěn)定。測試組出具系統(tǒng)測試報告，測試人員簽字確認測試結果。2.4 用戶測試 1、開發(fā)商編制用戶測試計劃（式樣見附件7），測試計劃必須定義測試標準，并明確各種測試的測試步驟和需要的系統(tǒng)設置要求，并提交甲方準備。 2、甲方應該按照開發(fā)商測試組要求配合標準測試數據，測試用數據要足夠模擬使用環(huán)境中的實際數據。對已評定為敏感信息的數據進行敏感性處理和保護。 3、按照測試計劃完成用戶測試后，測試組應該出具用戶測試報告（式樣見附件8），甲乙雙方必須在用戶測試報告中簽字確認。4、完成測試后，開發(fā)商完成系統(tǒng)幫助文檔（其中包括用戶操作手冊和安裝維護手

6、冊）的編寫。凡涉及應用系統(tǒng)的變更，應對系統(tǒng)幫助文檔及時更新。2.5 系統(tǒng)試運行 1、項目組必須制定試運行計劃（式樣見附件9），并制定試運行驗收指標。試運行計劃中應包含問題應對機制，明確問題溝通渠道和職責分工。 2、項目組聯合甲方公司進行相關系統(tǒng)部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。 3、項目組根據試運行計劃負責對用戶的老舊系統(tǒng)進行系統(tǒng)轉換和數據遷移。系統(tǒng)轉換前，檢查系統(tǒng)環(huán)境，確保運行環(huán)境能滿足新應用系統(tǒng)的需要。系統(tǒng)轉換時必須詳細記錄原系統(tǒng)中的重要參數、設置等系統(tǒng)信息，并填寫試運行報告相關內容。 4、系統(tǒng)轉換和數據遷移完成后，正式啟動試運行。在試運行過程中，項目組應把系統(tǒng)運行

7、情況（系統(tǒng)資源使用，反應速度等）記錄到試運行報告中。必要時，項目組應根據系統(tǒng)運行情況對應用系統(tǒng)進行優(yōu)化。5、試運行達到試運行計劃規(guī)定的終止條件時，開發(fā)商編寫試運行報告（式樣見附件10）。此報告應由開發(fā)商和甲方單位簽字確認，試運行結束。2.6 系統(tǒng)驗收與正式上線 1、系統(tǒng)驗收主要用戶單位及開發(fā)商聯合組成獨立系統(tǒng)驗收小組，由驗收小組共同商定驗收的標準和方法。驗收小組從功能需求及技術需求層面對系統(tǒng)進行綜合評估，系統(tǒng)驗收內容包括但不限于移交給甲方的系統(tǒng)測試報告、系統(tǒng)安裝文檔、配置文檔、源代碼、操作手冊、維護手冊、系統(tǒng)應急預案、系統(tǒng)“回退”計劃等。 2、驗收小組應根據驗收情況整理形成系統(tǒng)驗收報告（式樣見

8、附件11），驗收報告必須甲乙雙方簽字，并提交甲方作為付款依據。 3、系統(tǒng)驗收合格且問題整改完成并經甲乙雙方主要領導同意后系統(tǒng)轉入正式上線運行。3 售后服務及保密要求 開發(fā)商應該保證系統(tǒng)技術支持人員隊伍的穩(wěn)定，明確售后服務內容與責任，按照合同要求安排維護人員對系統(tǒng)進行技術支持。系統(tǒng)需求變更或調整，記錄變更原因和軟件及源代碼的版本控制，按照軟件變更要求對系統(tǒng)進行維護。為了保護甲乙雙方的商業(yè)、技術秘密等權益，開發(fā)商與甲方、開發(fā)商與其相關員工必須簽訂保密協(xié)議。附件1：項目執(zhí)行計劃文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1

9、文檔介紹1.1 文檔目的1.2文檔范圍1.3參考文獻提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：標識符 作者，文獻名稱，出版單位（或歸屬單位），日期例如：AAA 作者，立項建議書，機構名稱，日期1.5 術語與縮寫解釋縮寫、術語解 釋2 項目介紹2.1項目范圍提示：（1）用簡練的語言說明本項目“是什么”，“說明用途”。（2）說明本項目“應當包含的內容”和“不包含的內容”。2.2項目目標提示：給出“清晰的”、“可實現”、“可驗證”的目標。2.3客戶與最終用戶介紹提示：請說明本項目的客戶、用戶及其相關責任人是誰，描述最終用戶的特征。2.4 約束提示：（1）請說明在項目開發(fā)過程中應

10、當遵循的標準或規(guī)范（2）請說明相關項目可能對本項目造成的影響。（3）說明一些假設和依賴。3 項目過程定義3.1軟件生命周期模型提示：簡要描述、繪制本項目的軟件生命周期模型。3.2項目規(guī)范提示：描述項目需遵循的規(guī)范，例如：編碼規(guī)范。此處可以表現為編碼規(guī)范的鏈接。3.3方法與工具提示：說明在過程中將采用的方法與工具。例如采用Rational Rose進行面向對象分析與設計，采用Visual SourceSafe進行配置管理，采用Microsoft Office制作文檔。方法與工具用途Visual SourceSafe配置管理4 里程碑計劃序號里程碑名稱開始日期結束日期工作成果備注5 資源計劃5.1

11、人力資源計劃提示：制定本項目的角色職責表，并為已知的項目成員分配角色（一個人可以兼多個角色）。角色職責人員姓名工作說明高層領導項目經理需求分析員系統(tǒng)設計員程序員測試員5.2 軟硬件資源計劃提示：分析項目開發(fā)、測試、運行所需的軟硬件資源和關鍵計算機資源（會影響軟件產品的性能的CPU、內存、帶寬等內容），主要內容包括：l 資源級別（分為“關鍵”、“普通”兩種）l 詳細配置l 獲取方式（如“已經存在”、“可以借用”或“需要購買”等）與獲取時間l 使用說明（如“誰”在“什么”時候使用）軟硬件資源名稱級別詳細配置獲取方式與時間使用說明關鍵關鍵普通6 文檔交付列表序號交付文檔名稱交付日期備注7 風險管理計

12、劃提示：以下是各個列標題的解釋。約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。風險級別：確定風險的嚴重性、可能性、風險系數風險描述：緩解方案或者應急計劃。風險編號風險級別風險描述緩解方案應急計劃嚴重性(1-5)可能性(%)風險系數(嚴重性*可能性)8 溝通計劃甲方代表乙方代表溝通方式溝通頻率/時間期望結果9 附件l 項目進度計劃n 進度表提示：制定項目開發(fā)的進度表（建議給出項目里程碑計劃）。例如：編號里程碑名稱預計結束時間備注需求調研完成項目計劃完成需求分析完成系統(tǒng)設計完成 .開發(fā)完成集成測試完成系統(tǒng)測試完成用戶驗收測試完成試運行結束項目驗收附件2：業(yè)務需求說明書文件狀態(tài)：

13、草稿 正式發(fā)布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1概述1.1 業(yè)務調研人員名單【可選】序號職能部門姓名主管聯系電話備注1.2業(yè)務范圍此處描寫總體業(yè)務的概要分類。1.3 業(yè)務目標從甲方高層或商務利益的角度提出本業(yè)務系統(tǒng)的期望目標，以及評價標準。1.4 相關文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括現有規(guī)范、標準、批文、引用到的文件、資料等。1.5 業(yè)務詞匯表說明：列出本文檔的所引用的專屬領域詞匯、術語等，以便于業(yè)務需求的提供者和接收者是建立在一致的業(yè)務理解基礎之上的。2 組織結構及業(yè)務2.1 業(yè)務相關組織結構、人員組

14、織結構說明：如果用戶崗位設置復雜可分別設置，業(yè)務組織結構和人員組織結構2.2 組織機構描述2.3 角色職責說明：將業(yè)務涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。2.4 管理綜述【可選】說明：主要描述該業(yè)務的管理特點和管理模式。例如：2.5 現有業(yè)務流程清單【可選】說明：現有業(yè)務流程需要考慮，很多新的業(yè)務是在已有業(yè)務流程基礎上進行重組的。流程編號流程名稱責任部門輔助部門3 業(yè)務流程及業(yè)務處理描述說明：針對每一項具體的目標業(yè)務，描述具體的業(yè)務流程，以及相關業(yè)務的具體描述。3.1 具體業(yè)務流程（系統(tǒng)名稱+編號）對于具體業(yè)務流程的命名有規(guī)范，對具體流程進行編號，便于形成需求矩陣

15、，同時形成需求的管理和跟蹤。3.1.1業(yè)務流程3.1.2業(yè)務描述說明：描述具體的業(yè)務流程。3.1.3相關業(yè)務對象說明：業(yè)務對象：業(yè)務流程中涉及的單據、報表等。業(yè)務對象使用部門對應電子檔案編號3.1.4業(yè)務規(guī)則及關鍵算法說明：描述業(yè)務環(huán)節(jié)關鍵算法體系。4 假定和約束說明：列出進行本軟件開發(fā)工作的假定和約束，例如開發(fā)期限等。4.1 運行環(huán)境約束4.2 設計約束【可選】說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術、第三方產品等。4.3 產品應當遵循的標準或規(guī)范【可選】說明：闡述本產品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則，違反標準、規(guī)范或業(yè)務規(guī)則的產品通常不太可能被接受。5 其

16、他5.1 目前核心問題和困難5.2 業(yè)務對項目實施的需求和期望【可選】5.3 其他未盡事宜附件3：系統(tǒng)需求規(guī)格說明書文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1 引言1.1 目的例如：規(guī)定系統(tǒng)的邊界和目標，描述系統(tǒng)的功能性需求和非功能性需求。1.2讀者對象及閱讀建議說明：指明本文檔面向的讀者群，及相應的閱讀意見。1.3文檔范圍【可選】說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。1.4 參考文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物），包

17、括計劃任務書、合同、批文、引用到的文件、資料及軟件開發(fā)標準等。1.5 術語與縮寫解釋說明：列出本文件中用到的專門術語的定義和縮寫詞的原詞組，并給予解釋，以便于所有讀者達成共識。2 綜合描述2.1 系統(tǒng)背景【可選】說明：介紹系統(tǒng)的預期效果、歷史原因。2.2 問題說明【可選】提供一段說明，總結此項目需要解決的問題?？梢圆捎靡韵赂袷剑簡栴}是對問題進行說明影響問題影響的干系人問題的后果該問題會導致什么后果成功的解決方案應列出成功解決方案的一些主要優(yōu)點2.3系統(tǒng)范圍說明：闡述本項目“適用的業(yè)務領域”和“不適用的業(yè)務領域”，本產品“應當包含的內容”和“不包含的內容”。說清楚系統(tǒng)范圍的好處是：（1）有助于判

18、斷什么是需求，什么不是需求；（2）可以將開發(fā)精力集中在產品范圍之內；（3）有助于控制需求的變更。l 完整而準確的定義本產品的干系人；l 明確本產品所影響到的部門和業(yè)務；l 用圖表或者文字描述產品的范圍，概要的定義產品的功能。2.4 干系人與用戶說明【可選】2.4.1用戶環(huán)境【可選】詳細說明目標用戶的工作環(huán)境。以下是幾項建議：該任務由多少人來完成？是否總在變化？一個任務周期需要多長時間？執(zhí)行每項活動要用多長時間？是否總在變化？是否有特殊的環(huán)境約束：移動、戶外、乘機旅行等？目前使用的是哪些系統(tǒng)平臺？以后會使用哪些平臺？還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？在此處可以從業(yè)務模

19、型中摘錄一些內容來概述所涉及的任務和角色等等。2.4.2 干系人簡檔【可選】通過在下表中填寫各干系人的相關信息來說明系統(tǒng)中的各個干系人，詳盡的簡檔應包括各種干系人在以下方面的信息：代表誰是此產品的干系人代表？（如在他處已作記錄，則此處為可選。）此處只需填寫姓名。說明對干系人類型的簡要說明。類型介紹干系人的技能特長、技術背景和熟練程度（即權威用戶、業(yè)務用戶、專家用戶、初級用戶等）職責列出干系人對所開發(fā)的系統(tǒng)負有的關鍵職責，即他們作為干系人的利益。使用頻率該干系人使用系統(tǒng)的頻率意見/問題在此處列出會阻礙成功的問題以及任何其他相關信息。2.4.3關鍵的干系人/用戶需要列出干系人認為現有解決方案存在的

20、關鍵問題。對于列出的每個問題，需澄清以下要點：為什么會出現這一問題？目前如何解決該問題？干系人需要什么樣的解決方案？務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法表明，必須解決的問題與干系人或用戶希望解決的問題大有不同。2.5 目標業(yè)務模型【可選】說明：新系統(tǒng)業(yè)務模型描述，如有相應業(yè)務模型材料了，可作為需求規(guī)格說明書的輸入參考資料。2.6 功能摘要總結該產品將提供的主要優(yōu)點和特性，而不必涉及每個功能的細節(jié)。對功能加以組織，使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。2.7 功能清單及重要程度說明說明：功能名稱、功能描述、重要程度。重要程度，以ABC三類來表示：A：

21、核心功能；B：輔助功能；C：外圍功能；級別，按照繼承關系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注2.8 功能與業(yè)務對照關系表說明：業(yè)務組為主編寫業(yè)務需求，業(yè)務需求提交至信息技術組后，由信息技術組建立目標系統(tǒng)業(yè)務模型并與業(yè)務組進行確認（本操作可選，也可由信息技術組與開發(fā)商合作建立），目標業(yè)務模型作為系統(tǒng)需求的輸入，由信息技術組與開發(fā)商合作撰寫和評審系統(tǒng)需求規(guī)格書明書。業(yè)務需求目標系統(tǒng)業(yè)務活動（可選）功能名稱2.9 假定和約束說明：列出進行本軟件開發(fā)工作的假定和約束，例如：開發(fā)語言、開發(fā)期限等。格式限制說明：本項將指定由現有的標準或規(guī)則派生的要求。例如：報表格式；數據命名；財務

22、處理；審計追蹤，等等。硬件限制說明：本項包括在各種硬件約束下運行的軟件要求，例如，應該包括：硬件配置的特點（接口數，指令系統(tǒng)等）；內存儲器和輔助存儲器的容量。2.9.1運行環(huán)境約束說明：硬件設備、支持軟件、接口、控制等方面的約束名稱詳細要求2.9.2設計約束【可選】說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術、第三方產品等。2.9.3產品應當遵循的標準或規(guī)范說明：闡述本產品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則，違反標準、規(guī)范或業(yè)務規(guī)則的產品通常不太可能被接受。3 具體需求3.1功能需求3.1.1具體功能3.1.1.1內容說明：對于每一類功能或者有時對于每一個功能，需要具

23、體描述其輸入、加工和輸出的需求。3.2 非功能需求3.2.1 外部接口3.2.1.1用戶接口說明：提供用戶使用軟件產品時的接口需求。例如，如果系統(tǒng)的用戶通過顯示終端進行操作，就必須指定如下要求：a對屏幕格式的要求說明：對界面上的各對象、類型、寬度、取值范圍、數據來源、能否為空等屬性進行描述。b報表或菜單的頁面打印格式和內容c輸入輸出的需求說明：解釋各輸入輸出數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對軟件的數據輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告的描述。d程序功能鍵的可用性說明：快捷鍵定義等。3.2.1.2

24、硬件接口【可選】說明：要指出軟件產品和系統(tǒng)硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什么樣的設備，如何支撐這些設備，有何約定。3.2.1.3軟件接口【可選】說明：在此要指定需使用的其他軟件產品（例如，數據管理系統(tǒng)、操作系統(tǒng)或數學軟件包），以及同其他應用系統(tǒng)之間的接口。對每一個所需的軟件產品，要提供如下內容：名字、助記符、規(guī)格說明號、版本號、來源。對于每一個接口，這部分應說明與軟件產品相關的接口軟件的目的，并根據信息的內容和格式定義接口，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可?！窘涌诙x】下表是對一些接口的具體描述:接口名稱接口描述填寫接口完成的任務接口

25、類型填寫是輸入接口（inbound）還是輸出接口（outbound）源系統(tǒng)填寫接口輸入方系統(tǒng)或部件目標系統(tǒng)填寫接口輸出方系統(tǒng)或部件廠商提供/客戶化開發(fā)文件類型填寫文件類型；若通過數據庫表來交互，請指明數據庫及表名文件數量峰值數據量頻度填寫數據處理的頻度復雜度批處理 /人工填寫接口數據的驅動模式是人工（manual）還是自動(automatic)，還是都支持接口類型填寫是實時接口還是批量接口等【其他系統(tǒng)詳細信息】說明：列出所有與接口交互的外圍系統(tǒng)的詳細信息。包括輸入、輸出系統(tǒng)等系統(tǒng)填寫與接口交互的系統(tǒng)名稱系統(tǒng)類型填寫是接口的數據源系統(tǒng)(source)還是目標系統(tǒng)(object)數據庫填寫交互系統(tǒng)

26、使用的數據庫及版本軟件填寫交互系統(tǒng)的軟件名稱架構類型交互系統(tǒng)的架構類型是B/S 還是C/S。位置填寫該軟件在交互軟件體系中所出的位置技術支持填寫交互系統(tǒng)的開發(fā)商和支持商功能支持填寫具體的支持商或技術團隊數據歸屬【接口隸屬系統(tǒng)的詳細信息可選 】系統(tǒng)填寫接口隸屬系統(tǒng)的名稱模塊隸屬于具體的模塊名稱數據庫隸屬系統(tǒng)的數據庫及版本負責人控制報告【接口配置】（1）接口基礎信息配置說明：接口基礎信息的配置項目，描述配置的方式。（2）接口運行參數配置說明：接口運行參數的配置方式和步驟?！酒渌渲每蛇x 】說明：外圍系統(tǒng)或相關模塊的配置。3.2.1.4通信接口【可選】說明：指定各種通信接口。例如，局部網絡的協(xié)議等等

27、。3.2.2 其他非功能性需求說明：下表中的各種需求，可根據實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細解釋。名稱詳細要求靜態(tài)數值需求動態(tài)數值需求精度時間特性要求可用性可靠性可維護性安全性可移植性可擴展性兼容性3.2.2.1 靜態(tài)數值需求說明：支持的終端數；支持并行操作的用戶數。3.2.2.2 動態(tài)數值需求說明：欲處理的事務和任務的數量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數據總量。3.2.2.3 精度 說明:對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。3.2.2.4時間特性要求 說明：對于該軟件的時間特性要求，如對：a響應時間；b更

28、新處理時間；c數據的轉換和傳送時間；d解題時間等要求。3.2.2.5 數據管理要求【可選】說明：需要管理的文卷和記錄的個數、表和文卷的大小規(guī)模，要按可預見的增長對數據及其分量的存儲要求做出估算。3.2.2.6 可用性指出普通用戶和高級用戶要高效地執(zhí)行特定操作所需的培訓時間，指出典型任務的可評測任務次數或根據用戶已知或喜歡的其他系統(tǒng)確定新系統(tǒng)的可用性需求性能3.2.2.7可靠性指出可用時間百分比 ( xx.xx%)、使用小時數、維護訪問權、降級模式操作等。平均故障間隔時間 (MTBF)。平均修復時間 (MTTR)系統(tǒng)在發(fā)生故障后可以暫停運行的時間。指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（

29、按照某一已知的標準）。3.2.3文檔需求說明：主要是在線用戶手冊與幫助系統(tǒng)，也包括其他的文檔3.2.4 第三方產品【可選】說明：使用到的第三方產品相關的 使用許可、使用限制、接口標準。3.3 數據字典說明：把相關的數據抽取出來統(tǒng)一維護，在其他章節(jié)如有類似信息描述，則關聯到數據字典的相關部分并加輔助說明，如：引用到的字段等。4 補充資料【可選】4.1待確定的問題列表【可選】需求標題1調查方式調查人調查對象時間、地點需求信息記錄 附件4：需求變更申請記錄號： 項 目：類 型：開發(fā)項目項目負責人：變更申請人：申請部門：申請日期：變更內容變更的內容及其理由說明變更的內容及變更的理由，如果變更為業(yè)務組提

30、出，則業(yè)務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；變更的系統(tǒng)及版本說明變更所涉及的工作產品及其當前版本，如果變更為業(yè)務組提出，則業(yè)務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；對業(yè)務及其接口的影響分析需求變更引起的業(yè)務變更、業(yè)務接口的變更，業(yè)務組填寫甲方業(yè)務負責人意見：同意 不同意 簽字： 日期：變更結果變更分析對相關的資源影響分析需求變更對人員、開發(fā)設備和目標設備的影響，僅信息技術組填寫風險分析分析需求變更的風險，僅信息技術組填寫對其他系統(tǒng)或接口的影響分析需求變更引起的系統(tǒng)變更、其他系統(tǒng)或接口的變更，僅信息技術組填寫對開發(fā)工作量、進度和成本影響估計需求變更對開發(fā)工作量

31、和進度的影響，需說明本次變更工作量/成本是否超過本項目總開發(fā)工作量/總成本的1%？僅信息技術組填寫開發(fā)商意見開發(fā)商負責人意見：同意 不同意 指定驗證人員：簽字： 日期：變更結果變更的系統(tǒng)及版本說明變更后的工作產品簽字： 日期：變更驗證驗證變更結果完整性是 否正確性是 否附加變更是 否版本和名稱是 否甲方驗證人意見： 符合要求 不符合要求簽字： 日期：附件5：系統(tǒng)設計說明書文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1引言1.1編寫目的說明編寫這份詳細設計說明書的目的，指出預期的讀者。1.2背景說明：待開發(fā)軟件系統(tǒng)的名稱

32、；本項目的任務提出者、開發(fā)者、用戶和運行該程序系統(tǒng)的計算中心。1.3定義列出本文件中用到專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出有關的參考資料，如：本項目的經核準的計劃任務書或合同、上級機關的批文；屬于本項目的其他已發(fā)表的文件；本文件中各處引用到的文件資料，包括所要用到的軟件開發(fā)標準。列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠取得這些文件的來源。2程序系統(tǒng)的結構用一系列圖表列出本程序系統(tǒng)內的每個程序（包括每個模塊和子程序）的名稱、標識符和它們之間 的層次結構關系。3程序1（標識符）設計說明從本章開始，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針

33、對一般情況的。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內容往往與它所隸屬的上一層 模塊的對應條目的內容相同，在這種情況下，只要簡單地說明這一點即可。3.1程序描述給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，并且，還要說明本程序的特點（如 是常駐內存還是非常駐？是否子程序？是可重人的還是不可重人的？有無覆蓋要求？是順序處理還是并發(fā)處理等）。3.2功能說明該程序應具有的功能，可采用IPO圖（即輸入一處理一輸出圖）的形式。3.3性能說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。3.4輸人項給出對每一個輸入項的特性，包括名稱、標識、數據的類型和格

34、式、數據值的有效范圍、輸入的方式。數量和頻度、輸入媒體、輸入數據的來源和安全保密條件等等。3.5輸出項給出對每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效范圍，輸出的形式、數量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。3.6算法詳細說明本程序所選用的算法，具體的計算公式和計算步驟。3.7流程邏輯用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。3.8接口用圖的形式說明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序，說明參數賦值和調用方式，說明與本程序相直接關聯的數據結構（數據庫、數據文卷）。3.9 界面原型圖 按照系統(tǒng)各功能模

35、塊的邏輯順序，提供界面原型圖的跳轉展示，各項人機互動組件及數據顯示必須基本完善，界面直觀友好。3.10存儲分配根據需要，說明本程序的存儲分配。3.11注釋設計說明準備在本程序中安排的注釋，如：加在模塊首部的注釋；加在各分枝點處的注釋；對各變量的功能、范圍、缺省條件等所加的注釋；對使用的邏輯所加的注釋等等。3.12限制條件說明本程序運行中所受到的限制條件。3.13尚未解決的問題說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。4程序2（標識符）設計說明用類似F3的方式，說明第2個程序乃至第N個程序的設計考慮。附件6 ：系統(tǒng)設計評審報告文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標識

36、：ProjectName-當前版本：X.Y作 者：完成日期：Year-Month-Day版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1. 基本信息提示：由評審主持人或評審員填寫此表格。待評審的工作成果工作成果名稱，標識符，版本，作者，時間技術評審方式（正式評審）或者(走查)評審時間評審地點參加技術評審的人員類別名字工作單位職稱、職務：主持人評審小組成員記錄員2. 缺陷識別和跟蹤 評審問題跟蹤表編號問題描述問題類型嚴重性提交者提交日期問題處理負責人解決措施/原因說明問題解決狀態(tài)實際關閉日期問題關閉驗證人備注1233. 評審結論與意見提示：由主持人或評審員填寫此表格。評審結論 工作成果合格，“無

37、需修改”或者“需要輕微修改但不必再審核”。 工作成果基本合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。意見負責人簽字簽字：日期： 附件7：用戶測試計劃文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1. 測試范圍與主要內容提示：系統(tǒng)測試小組應當根據項目的特征確定測試范圍與內容。一般地，系統(tǒng)測試的主要內容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性（security）測試、安裝與反安裝測試等。2. 測試方法提示：例如黑盒測試和白盒測試。3. 測試環(huán)境與測試輔

38、助工具環(huán)境設備配置名稱/類型備注服務器軟件硬件客戶端軟件硬件網絡工具類型工具開發(fā)商版本測試管理缺陷跟蹤用于功能性測試的工具用于性能測試的工具測試覆蓋監(jiān)測器或評測器4. 測試進度計劃任務人員任務開始日期結束日期制定測試計劃設計測試實施測試執(zhí)行測試對測試進行評估5. 測試完成準則提示：對于非嚴格系統(tǒng)可以采用“基于測試用例”的準則： （1）功能性測試用例通過率達到100；（2）非功能性測試用例通過率達到95時。對于嚴格系統(tǒng)，應當補充“基于BUG密度”的規(guī)則：相鄰n個CPU小時內“測試期BUG密度”全部低于某個值m。例如n大于10，m小于等于1。 最后一次回歸測試二類缺陷數量為零，用例外非常規(guī)缺陷數量小于等于2 個/萬行程序；測試用例功能點覆蓋率100%；6. BUG管理與改錯計劃提示：根據所采用的BUG管理工具確定：（1）BUG管理流程，（2）BUG修改流程。定義BUG修改約定，例如：不同級別的BUG必須在幾日內處理完成。7. 附錄. 本計劃審批意見測試組審批意見：簽字 日期附件8：用戶測試報告1. 基本信息測試依據例如：參照標準、客戶需求、需求規(guī)格說明書、測試用例等測試范圍測試驗收標準測試環(huán)境描述測試驅動程序描述提示：可以把測試驅動程序當作