集團軟件開發(fā)管理制度

1、軟件開發(fā)管理制度第一節(jié) 總則第一條 為規(guī)范自主軟件研發(fā)以及外包軟件的管理工作，特制定本制度。本制 度適用于集團軟件研發(fā)與管理。第二條本制度中軟件開發(fā)包含新系統(tǒng)開發(fā)和現(xiàn)有系統(tǒng)升級改造，此類工作均 需要以項目制管理.第三條本制度中自主開發(fā)是指主要依賴信息中心自身的管理、業(yè)務和技術力 量進行系統(tǒng)設計、軟件開發(fā)、集成和相關的技術支持工作；合作開發(fā)是信息中心與 專業(yè)IT公司（合作商）共同協(xié)作完成IT應用的項目實施和技術支持工作，雙方組 成開發(fā)團隊進行項目實施，IT系統(tǒng)的日常支持由信息中心軟件研發(fā)部承擔；外包開 發(fā)是指將IT應用項目的設計、開發(fā)、集成、培訓等任務承包給某家專業(yè)公司（可以是專業(yè)的IT公司或咨

2、詢公司等），由該公司（承包商）負責應用項目的實施。第四條 軟件開發(fā)遵循項目管理和軟件工程的基本原則。項目管理涉及立項管 理、項目計劃和監(jiān)控、配置管理、合作開發(fā)管理和結項管理。軟件工程涉及需求管 理、系統(tǒng)設計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、用戶接受測試、試運行、系統(tǒng)驗收、系統(tǒng)上 線。第五條 除特別指定，本制度中項目組包括業(yè)務組（或需求提出組 ）、開發(fā)組 （可能包括合作開發(fā)商）。第二節(jié)立項管理第六條 提出項目需求的部門參與立項，信息中心提供立項的技術可行性分 析，編寫立項分析報告（附件一），開展前期籌備工作。立項分析報告應明確 項目的范圍和邊界。第七條 信息中心將立項分析報告交相關部門會簽后，上交集團總經理

3、進 行立項審批，以保證系統(tǒng)項目與集團整體策略相一致。第/I條 立項分析報告得到批準后，成立項目組（如果是外包開發(fā)，則成立 外包商項目組；如果是合作開發(fā)，則與外包商共同成立合作開發(fā)項目組，以下統(tǒng)稱“項目組”），項目組應包括業(yè)務組（由信息中心需求管理組和相關業(yè)務部門組成）和開發(fā)組（自主開發(fā)為技術研發(fā)部開發(fā)組；外包開發(fā)為技術研發(fā)部指定的開發(fā)組長和外 包商成員；合作開發(fā)為技術研發(fā)部開發(fā)組指定人員和外包商成員）。信息中心委派一名項目經理負責監(jiān)督項目的進度，進行項目管理工作，確保開發(fā)能及時完成并能滿足 業(yè)務需要。項目組人員的選擇應滿足項目對業(yè)務及技術要求，項目組人員應有足夠 的業(yè)務和IT技術方面的專業(yè)知識

4、來勝任項目各方面的工作.第1頁，共40頁第三節(jié)需求分析第九條立項后業(yè)務組對單位具體需求進行匯總整理，出具業(yè)務需求說明 書（附件二），并確保業(yè)務需求說明書中包含了所有的業(yè)務需求。經系統(tǒng)使用 部門確認，作為業(yè)務需求基線。第十條 業(yè)務組在獲得業(yè)務需求說明書后，提出技術需求和解決方案，并 對系統(tǒng)進行定義，出具系統(tǒng)需求規(guī)格說明書（附件三）。系統(tǒng)需求規(guī)格說明書需詳細列出業(yè)務對系統(tǒng)的要求（界面、輸入、輸出、管理功能、安全需求、運作模 式、關鍵指標（KPI）等），最好是采用原型方式表達。系統(tǒng)需求規(guī)格說明書需要 由業(yè)務組提交給相關業(yè)務部門負責人確認。第H一條 業(yè)務需求發(fā)生變更時，業(yè)務組應提交需求變更申請（附件四

5、）， 需求部門簽字確認，項目經理確認技術方案后交給業(yè)務組組長和開發(fā)組組長執(zhí)行 .第十二條 項目組應對需求文檔及時更新.第四節(jié)項目計劃和監(jiān)控第十三條 軟件開發(fā)采用項目形式進行管理.項目經理負責整個項目的計劃、 組織、領導和控制。第十四條 需求分析過程中，項目經理組織制定詳細的項目計劃書（附件五），包括具體任務描述和項目進度表等。第十五條 在項目的各個階段，業(yè)務組組長和開發(fā)組組長需配合項目經理制 定階段性項目計劃.業(yè)務組組長和開發(fā)組組長需配合項目經理對項目計劃執(zhí)行情況進 行監(jiān)控，確保項目按計劃完成.第十六條 項目計劃需要變更時，項目經理填寫項目計劃變更說明（附件六），并提交集團相關領導審批后，交給

6、業(yè)務組組長和開發(fā)組組長執(zhí)行。第五節(jié)系統(tǒng)設計第十七條系統(tǒng)設計應分為概要設計和詳細設計，系統(tǒng)設計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。第十/I條在系統(tǒng)設計階段中，需求部門應充分參與，確保系統(tǒng)設計能滿足 系統(tǒng)需求。第十九條 項目組進行設計，出具設計說明書（附件七）和單元測試用例（附件八）.設計說明書中需要定義系統(tǒng)輸入輸出說明和接口設計說明。第二十條 設計說明書以業(yè)務需求說明書和系統(tǒng)需求規(guī)格說明書為依據(jù)，確保系統(tǒng)設計滿足全部需求。第二H一條 對已確認通過的系統(tǒng)設計進行修改需獲得項目經理、業(yè)務組組 長和開發(fā)組組長的審批后方可進行.第2頁，共40頁第二十二條對系統(tǒng)設計的修改的文檔須

7、由文檔管理人員進行歸檔管理第六節(jié)系統(tǒng)實現(xiàn)第二十三條 開發(fā)組根據(jù)設計說明書制定系統(tǒng)實現(xiàn)計劃，并提交項目經 理對計劃可行性進行審批。第二十四條 系統(tǒng)實現(xiàn)包括程序編碼、單元測試。第二十五條 開發(fā)組保證開發(fā)、測試和生產環(huán)境獨立，為各環(huán)境建立訪問權 限控制機制，并明確項目成員的職責分工。對開發(fā)環(huán)境、測試環(huán)境與生產環(huán)境在物理 或邏輯方面應該做到隔離；如果環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應定期檢查網 絡設置。項目組對已授權訪問生產環(huán)境的人員進行詳細記錄，并對該記錄進行定期 檢查，確保只有經授權的人員才能訪問到生產環(huán)境.第七節(jié) 系統(tǒng)測試和用戶測試第二十六條 測試組制定系統(tǒng)測試計劃（附件九），并提交項目經理對計

8、 劃可行性進行審批。第二十七條系統(tǒng)測試計劃必須定義測試標準，并明確各種測試的測試 步驟和需要的系統(tǒng)設置要求.第二十八條開發(fā)組向數(shù)據(jù)擁有部門申請獲取測試用業(yè)務數(shù)據(jù)的使用權，對 獲取的數(shù)據(jù)進行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。第二十九條開發(fā)組負責測試數(shù)據(jù)準備，測試用數(shù)據(jù)要足夠模擬生產環(huán)境中 的實際數(shù)據(jù)。對已評定為敏感信息的數(shù)據(jù)進行敏感性處理和保護。第三十條開發(fā)組或合作開發(fā)商協(xié)助技術研發(fā)部測試組建立測試環(huán)境進行系 統(tǒng)測試。在系統(tǒng)測試中對新系統(tǒng)內部各模塊之間的接口和與其他系統(tǒng)的接口進行充 分測試.技術研發(fā)部測試組出具系統(tǒng)/用戶測試報告（附件十），測試人員簽字確 認測試結果。第三H一條

9、 系統(tǒng)測試通過后，開發(fā)組配合業(yè)務組建立用戶測試環(huán)境，業(yè)務組根據(jù)用戶測試用例進行用戶測試，出具系統(tǒng) /用戶測試報告，業(yè)務組組長和開 發(fā)組組長應在用戶測試報告中簽字確認.第三十二條 項目組完成系統(tǒng)幫助文檔（其中包括用戶操作手冊和安 裝維護手冊）。凡涉及應用系統(tǒng)的變更，應對系統(tǒng)幫助文檔及時更新 .第八節(jié) 試運行第三十三條系統(tǒng)主要應用部門根據(jù)項目規(guī)模及影響決定試運行策略第3頁，共40頁第三十四條 項目組制定試運行計劃（附件十一），并制定試運行驗收指 標，試運行計劃中應包含問題應對機制，明確問題溝通渠道和職責分工。第三十五條 項目組聯(lián)合試運行單位進行相關系統(tǒng)部署工作，準備培訓資 料，對相關使用人和信息技

10、術人員進行培訓。培訓的完成度應為實施后評估的指標 之一.第三十六條 項目組根據(jù)試運行計劃進行系統(tǒng)轉換和數(shù)據(jù)遷移。系統(tǒng)轉 換前，檢查系統(tǒng)環(huán)境，確保運行環(huán)境能滿足新應用系統(tǒng)的需要。系統(tǒng)轉換時必須詳細 記錄原系統(tǒng)中的重要參數(shù)、設置等系統(tǒng)信息，并填寫試運行報告相關內容。系統(tǒng)參 數(shù)、設置的轉換工作作為系統(tǒng)上線的驗收的評估指標之一.第三十七條 試運行達到計劃規(guī)定的終止條件時，項目組編寫試運行報告（附件十二）。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導審 閱。公司主管領導審閱試運行結果，決定試運行結束或延期。第九節(jié) 系統(tǒng)驗收第三十/I條系統(tǒng)主要應用部門及技術研發(fā)部聯(lián)合組成獨立系統(tǒng)驗收小組， 也

11、可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統(tǒng)進行 綜合評估.第三十九條驗收小組應根據(jù)驗收情況整理形成系統(tǒng)驗收報告（附件十三）提交系統(tǒng)主要應用部門和技術研發(fā)部審閱。第四十條系統(tǒng)主要使用部門和信息中心負責人根據(jù)系統(tǒng)測試、試運行情況 簽署驗收意見。第四H一條 在系統(tǒng)驗收通過后，項目組對運維組進行系統(tǒng)維護培訓后交付 運維組。第十節(jié) 系統(tǒng)上線第四十二條 系統(tǒng)上線應遵循穩(wěn)妥、可控、安全的原則。第四十三條 項目組發(fā)起通知公告申請流程（集團），填寫系統(tǒng)上線內容 得到批準后才能開始部署上線工作。第四十四條 上線初期需加強日常運行狀態(tài)監(jiān)控，出現(xiàn)問題時應及時處理， 對重大問題應啟動緊急預案。第

12、四十五條 上線單位管理層要對系統(tǒng)驗收報告進行審批簽字。第四十六條 集團相關領導批準結項后，業(yè)務組和開發(fā)組將整理的系統(tǒng)文檔 提交各自部門統(tǒng)一管理。第4頁，共40頁第十一節(jié)合作開發(fā)管理第四十七條 合作開發(fā)商的選擇應遵循集團相關規(guī)定.第四十/I條 合作開發(fā)商必須遵循信息中心軟件開發(fā)管理制度。第四十九條 項目經理同合作開發(fā)商明確規(guī)定項目變更的范圍和處理方式， 重點關注需求和設計變更。第五十條 項目經理負責監(jiān)控合作開發(fā)商的項目管理及軟件開發(fā)活動 .合作 開發(fā)商應按計劃定期向項目經理報告進展狀態(tài) ，并提交階段性成果文檔.發(fā)生重大問 題時，合作開發(fā)商需及時向項目經理匯報。第五H一條開發(fā)組組長派專人監(jiān)控合作開

13、發(fā)商的質量保證過程。第五十二條項目組同合作開發(fā)商商定驗收的標準和方法。第五十三條 以上各要求需要在開發(fā)合同中明確。第十二節(jié)外包開發(fā)管理第五十四條 立項中請得到集團領導的審批后，選定開發(fā)商，簽訂外包開發(fā) 合同。第五十五條 項目經理負責監(jiān)控外包開發(fā)商的項目管理及軟件開發(fā)活動。外 包開發(fā)商應按計劃定期向項目經理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重 大問題時，外包開發(fā)商需及時向項目經理匯報。第五十六條 項目經理監(jiān)控外包開發(fā)商的質量保證過程。第五十七條 項目組同外包開發(fā)商商定驗收的標準和方法。第五十/I條 以上各要求需要在開發(fā)合同中明確.第十三節(jié)附則第五十九條本制度由信息中心負責解釋和修訂 第六十

14、條 本制度自發(fā)布之日起開始執(zhí)行。第5頁，共40頁附件一立項分析報告文件狀態(tài)：草稿正式發(fā)布止在修改文件標識：ProjectName 當前版本：X.Y作 者：完成日期：Year-Month -Day版本歷史版本/狀態(tài)作者參與后起止日期備注.項目介紹項目目的提示：用簡練的語言說明本項目“是什么”，“實現(xiàn)什么目的”。描述簡練且清晰。項目背景提示：闡述項目背景，重點說明“為什么”會提出本項目.(1)公司的短期、長期發(fā)展戰(zhàn)略；(2)業(yè)務需求及發(fā)展趨勢；(3)技術狀況及發(fā)展趨勢；(4 )特殊的業(yè)務需求等.項目范圍提示：根據(jù)對現(xiàn)有需求的了解來確定項目基本范圍,說明本系統(tǒng)“應當包含的內容” 和“不包含的內容”。

15、.項目計劃項目團隊提示：說明項目團隊的角色、知識技能要求、建議人選、人數(shù)、工作時間，如下表所 示.角色知識技能要求建議人選、人數(shù)工作時間項目經理需求開發(fā)人員系統(tǒng)設計人員第6頁，共40頁編程人員測試人員維護人員2.2.成本估計內容成本（人民幣）備注人力資源軟硬件資源.2.3.進度表提示:制定項目開發(fā)的進度表（建議給出項目里程碑計劃）。例如:編號里程碑名稱預計結束時間備注需求調研完成項目計劃完成需求分析完成概要設計完成詳細設計完成實現(xiàn)完成集成測試完成系統(tǒng)測試完成驗收測試完成試運行結束項目驗收3.總結提示：給出清晰的建議結論，便于集團領導決策。第7頁，共40頁附件二業(yè)務需求說明書文件狀態(tài)：草稿 正式

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

17、1業(yè)務相關組織結構、人員組織結構說明：如果單位崗位設置復雜可分別設置，業(yè)務組織結構和人員組織結構第8頁，共40頁2.2組織機構描述2。3角色職責說明：將業(yè)務涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。2。4管理綜述【可選】說明：主要描述該業(yè)務的管理特點和管理模式。例如：典型按庫存生產模式。生產計劃以年度銷售計劃為指導，并綜合考慮設備能力、生產天數(shù)、庫存、歷史銷售記錄。采購計劃的制訂以生產計劃為依據(jù)。2。5現(xiàn)有業(yè)務流程清單【可選】說明：現(xiàn)有業(yè)務流程需要考慮，很多新的業(yè)務是在已有業(yè)務流程基礎上進行重組的。流程編號流程名稱責任部門輔助部門3業(yè)務流程及業(yè)務處理描述說明：針對每一項

18、具體的目標業(yè)務，描述具體的業(yè)務流程，以及相關業(yè)務的具體描述。具體業(yè)務流程（系統(tǒng)名稱+編號）對于具體業(yè)務流程的命名有規(guī)范，對具體流程進行編號，便于形成需求矩陣，同時形成需求 的管理和跟蹤.業(yè)務流程3.1。2業(yè)務描述說明：描述具體的業(yè)務流程.3.1。3相關業(yè)務對象說明：業(yè)務對象：業(yè)務流程中涉及的單據(jù)、報表等。業(yè)務對象使用部門對應電子檔案編號3.1.4業(yè)務規(guī)則及關鍵算法說明：描述業(yè)務環(huán)節(jié)關鍵算法體系.4假定和約束說明：列出進行本軟件開發(fā)工作的假定和約束，例如開發(fā)期限等。4。1運行環(huán)境約束第9頁，共40頁4。2設計約束【可選】說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術、第

19、三方 產品等。4.3產品應當遵循的標準或規(guī)范【可選】說明：闡述本產品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則，違反標準、規(guī)范或業(yè)務規(guī)則的產 品通常不太可能被接受。5其他5。1目前核心問題和困難5。2業(yè)務對項目實施的需求和期望【可選】5。3其他未盡事宜第10頁，共40頁附件三系統(tǒng)需求規(guī)格說明書文件狀態(tài)：，草稿正式發(fā)布止在修改文件標識：ProjectName-當前版本：X.Y作 者：完成日期：YearMonth- Day版本歷史版本/狀態(tài)作者參與后起止日期備注1引言1。1目的例如：規(guī)定系統(tǒng)的邊界和目標，描述系統(tǒng)的功能性需求和非功能性需求讀者對象及閱讀建議說明：指明本文檔面向的讀者群，及相應的閱讀意見。文檔

20、范圍【可選】說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。1。4參考文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括計劃任務書、合同、批文、引用到的文件、資料及軟件開發(fā)標準等。1。5術語與縮寫解釋說明：列出本文件中用到的專門術語的定義和縮寫詞的原詞組，并給予解釋，以便于所有讀者達成共識。2綜合描述2。1系統(tǒng)背景【可選】說明：介紹系統(tǒng)的預期效果、歷史原因。第11頁，共40頁2。2問題說明【可選】提供一段說明，總結此項目需要解決的問題.可以采用以下格式:問題是對問題進行說明影響問題的影響問題的后果該問題會導致什么后果

21、成功的解決方案應列出成功解決方案的一些主要優(yōu)點2。3系統(tǒng)范圍說明：闡述本項目“適用的業(yè)務范圍”和“不適用的業(yè)務范圍”，本產品“應當包含的內容”和“不包含的內容”。說清楚系統(tǒng)范圍的好處是：（1）有助于判斷什么是需求，什么不 是需求；（2）可以將開發(fā)精力集中在需求范圍之內； （3）有助于控制需求的變更.完整而準確的定義本產品的相關人員；明確本產品所影響到的部門和業(yè)務；用圖表或者文字描述產品的范圍，概要的定義產品的功能。2.4干系人與用戶說明【可選】2。4。1用戶環(huán)境【可選】詳細說明目標用戶的工作環(huán)境.以下是幾項建議：該任務由多少人來完成？是否總在變化？一個任務周期需要多長時間？執(zhí)行每項活動要用多長

22、時間？是否總在變化？是否有特殊的環(huán)境約束：移動、戶外、乘機旅行等？目前使用的是哪些系統(tǒng)平臺？以后會使用哪些平臺？還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？在此處可以從業(yè)務模型中摘錄一些內容來概述所涉及的任務和角色等等。2。4.2干系人簡檔【可選】通過在下表中填寫各干系人的相關信息來說明系統(tǒng)中的各個干系人，詳盡的簡檔應包括各 種干系人在以下方面的信息：代表誰是此產品的干系人代表？（如在他處已作記錄，則此處為可選。） 此處只需填寫姓名。第12頁，共40頁說明對干系人類型的簡要說明?；亟榻B干系人的技能特長、技術背景和熟練程度（即權威用戶、業(yè)務用 戶、專家用戶、初級用戶等）職責列出

23、干系人對所開發(fā)的系統(tǒng)負有的關鍵職責，即他們作為干系人的 利益。使用頻率該干系人使用系統(tǒng)的頻率意見/問題在此處列出會阻礙成功的問題以及任何其他相關信息。3關鍵的干系人/用戶需要 TOC o 1-5 h z 列出干系人認為現(xiàn)有解決方案存在的關鍵問題。對于列出的每個問題，需澄清以下要點：?為什么會出現(xiàn)這一問題？?目前如何解決該問題？?干系人需要什么樣的解決方案 ？務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法表明，必須解決的問題與干系人或用戶希望解決的問題大有不同目標業(yè)務模型【可選】說明：新系統(tǒng)業(yè)務模型描述，如有相應業(yè)務模型材料了 ，可作為需求規(guī)格說明書的輸入?yún)⒖假Y料。功能摘

24、要總結該產品將提供的主要優(yōu)點和特性，而不必涉及每個功能的細節(jié)。對功能加以組織，使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。2。7功能清單及重要程度說明說明：功能名稱、功能描述、重要程度。重要程度，以ABC三類來表示：A :核心功能；B:輔助功能；C:外圍功能；級別，按照繼承關系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注2.8功能與業(yè)務對照關系表說明：業(yè)務組為主編寫業(yè)務需求，業(yè)務需求提交至信息技術組后，由信息技術組建立目標系第13頁，共40頁統(tǒng)業(yè)務模型并與業(yè)務組進行確認（本操作可選，也可由信息技術組與開發(fā)商合作建立），目標業(yè)務模型作為系統(tǒng)需求的輸入，由信息技術組與開發(fā)商合

25、作撰寫和評審系統(tǒng)需求規(guī)格 書明書.業(yè)務需求目標系統(tǒng)業(yè)務活動（可選）功能名稱2。9假定和約束說明：列出進行本軟件開發(fā)工作的假定和約束，例如：開發(fā)語言、開發(fā)期限等。格式限制說明：本項將指定由現(xiàn)有的標準或規(guī)則派生的要求。例如：報表格式；數(shù)據(jù)命名；財務處理；審計追蹤，等等。硬件限制說明：本項包括在各種硬件約束下運行的軟件要求，例如，應該包括 硬件配置的特點（接口數(shù)，指令系統(tǒng)等）；內存儲器和輔助存儲器的容量. 2。9。1運行環(huán)境約束說明：硬件設備、支持軟件、接口、控制等方面的約束名稱詳細要求2。9.2設計約束【可選】說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術、第三方 產品等

26、.2。9。3產品應當遵循的標準或規(guī)范說明：闡述本產品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則，違反標準、規(guī)范或業(yè)務規(guī)則的產品通常不太可能被接受.3具體需求3.1功能需求3.1 o 1具體功能3.1.1.1 內容說明：對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需求。第14頁，共40頁3。2非功能需求3。2。1外部接口3.2.1.1 用戶接口說明：提供用戶使用軟件產品時的接口需求。例如，如果系統(tǒng)的用戶通過顯示終端進行操作，就必須指定如下要求：a對屏幕格式的要求說明：對界面上的各對象、類型、寬度、取值范圍、數(shù)據(jù)來源、能否為空等屬性進行描述。b報表或菜單的頁面打印格式和內容c輸入輸

27、出的需求說明：解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等 .對軟件的數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告的描述。d程序功能鍵的可用性說明：快捷鍵定義等。3.2.1。2硬件接口【可選】說明：要指出軟件產品和系統(tǒng)硬部件之間每一個接口的邏輯特點.還可能包括如下事宜：支撐什么樣的設備，如何支撐這些設備，有何約定。3。2。1。3軟件接口【可選】說明：在此要指定需使用的其他軟件產品（例如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)或數(shù)學軟件包），以及同其他應用系統(tǒng)之間的接口.對每一個所需的軟件產品，要提供如下內容：名字、助記

28、符、規(guī)格說明號、版本號、來源 .對于每一個接口，這部分應說明與軟件產品相關的接口軟件的目的，并根據(jù)信息的內容和格式定義接口 ，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可?！窘涌诙x】下表是對一些接口的具體描述：接口名稱接口描述填寫接口完成的任務第15頁，共40頁接口類型填與是輸入接口( inbound )還是輸出接口( outbound )源系統(tǒng)填寫接口輸入方系統(tǒng)或部件目標系統(tǒng)填寫接口輸出方系統(tǒng)或部件廠商提供/客戶化開發(fā)文件類型填寫文彳性型；若通過數(shù)據(jù)庫表來交互，請指明數(shù)據(jù)庫及表名文件數(shù)量峰值數(shù)據(jù)量頻度填寫數(shù)據(jù)處理的頻度復雜度批處理/人工填寫接口數(shù)據(jù)的驅動模式是人工(

29、manual)還是自動(automatic ),還是都支持接口類型填寫是實時接口還是批量接口等【其他系統(tǒng)詳細信息】說明：列出所有與接口交互的外圍系統(tǒng)的詳細信息。包括輸入、輸出系統(tǒng)等系統(tǒng)填寫與接口交互的系統(tǒng)名稱系統(tǒng)類型填寫是接口的數(shù)據(jù)源系統(tǒng)(source)還是目標系統(tǒng)(object )數(shù)據(jù)庫填寫父互系統(tǒng)使用的數(shù)據(jù)庫及版本軟件填與交互系統(tǒng)的軟件名稱架構類型交互系統(tǒng)的架構類型是B/S還是C/S。的填寫該軟件在交互軟件體系中所出的位置技術支持填與交互系統(tǒng)的開發(fā)商和支持商功能支持填寫具體的支持商或技術團隊數(shù)據(jù)歸屬【接口隸屬系統(tǒng)的詳細信息可選系統(tǒng)填寫接口隸屬系統(tǒng)的名稱模塊隸屬于具體的模塊名稱數(shù)據(jù)庫隸屬系統(tǒng)

30、的數(shù)據(jù)庫及版本第16頁，共40頁負責人控制報【接口配置】(1)接口基礎信息配置說明：接口基礎信息的配置項目，描述配置的方式。(2)接口運行參數(shù)配置說明：接口運行參數(shù)的配置方式和步驟?！酒渌渲每蛇x說明：外圍系統(tǒng)或相關模塊的配置。3。2。1.4通信接口【可選】說明：指定各種通信接口。例如，局部網絡的協(xié)議等等3。2.2其他非功能性需求說明：下表中的各種需求，可根據(jù)實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細解釋。名稱詳細要求靜態(tài)數(shù)值需求動態(tài)數(shù)值需求精度時間特性要求可用性可靠性可維護性安全性可移植性可擴展性兼容性3.2.2 o 1靜態(tài)數(shù)值需求說明：支持的終端數(shù)；支持并行操作

31、的用戶數(shù)第17頁，共40頁3.2。2.2動態(tài)數(shù)值需求說明：欲處理的事務和任務的數(shù)量，以及在正常情況下和峰值工作條件下一定時間周期中 處理的數(shù)據(jù)總量。3。2.2.3 精度說明：對該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。3。2.2.4時間特性要求說明：對于該軟件白,時間特性要求，如對：a.響應時間；b.更新處理時間；c.數(shù)據(jù)的轉換和傳送時間；d.解題時間等要求。3。2。2。5數(shù)據(jù)管理要求【可選】說明：需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預見的增長對數(shù)據(jù)及其分量的存儲要求做出估算。3。2。2。6可用性指出普通用戶和高級用戶要高效地執(zhí)行特定操作所需的培訓時間，指出

32、典型任務的可評測任務次數(shù)或根據(jù)用戶已知或喜歡的其他系統(tǒng)確定新系統(tǒng)的可用性需求性能3。2。2。7可靠性指出可用時間百分比（xx.xx %）、使用小時數(shù)、維護訪問權、降級模式操作等。平均故障間隔時間（MTBF）。平均修復時間（MTTR）-系統(tǒng)在發(fā)生故障后可以暫停運行的時間。指 出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。3文檔需求說明：主要是在線用戶手冊與幫助系統(tǒng)，也包括其他的文檔3。2.4第三方產品【可選】說明：使用到的第三方產品相關的使用許可、使用限制、接口標準.數(shù)據(jù)字典說明：把相關的數(shù)據(jù)抽取出來統(tǒng)一維護，在其他章節(jié)如有類似信息描述，則關聯(lián)到數(shù)據(jù)字 典的相關部分并加輔助

33、說明，如：引用到的字段等.4補充資料第18頁，共40頁【可選】待確定的問題列表【可選】需求標題1調查方式調查人調查對象時間、地點需求信息記錄第19頁，共40頁附件四需求變更申請記錄號:項目：類 型：開發(fā)項目項目負責人：變更申請人：申請部門：申請日期：變更內咨變更的內咨及其理由說明變更的內容及變更的理由，如果變更為業(yè)務組提出，則業(yè)務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；變更的系統(tǒng)及版本說明變更所涉及的工作產品及其當前版本，如果變更為業(yè)務組提出，則業(yè)務組填寫；如果變更為為信息技術組提出,則信息技術組填寫；對業(yè)務及其接口的影響分析需求變更引起的業(yè)務變更、業(yè)務接口的變更, 業(yè)務組填寫業(yè)

34、務負責人意見：同意/、同意簽字：日期：第20頁，共40頁變更結果變更分析對相關的資源影響分析需求變更對人員、開發(fā)設備和目標設備的影響， 僅信息技術組填寫風險分析分析需求變更的風險， 僅信息技術組填寫對其他系統(tǒng)或接口的影響分析需求變更引起的系統(tǒng)變更、其他系統(tǒng)或接口的變更, 僅信息技術組填寫對開發(fā)工作量、進度和成本影響估計需求變更對開發(fā)工作量和進度的影響，需說明本次變更工作量/成本是否超過本項目總開發(fā)工作量/總成本的1%?僅信息技術組填寫信息技術部審批意見信息技術組負責人意見：同意小同意指定驗證人員：簽字：日期：信息中心主任意見：同意小同意簽字：日期：變更結果變更的系統(tǒng)及版本說明變更后的工作產品日

35、期:變更驗證驗證受更結果完整性是否正確性是否附加變更是否版本和名稱是否第21頁，共40頁驗證人意見：符合要求不符合要求簽字：日期：第22頁，共40頁附件五項目計劃書文件狀態(tài)：草稿 正式發(fā)布止在修改文件標識：ProjectName-當前版本：X.Y作 者：完成日期：YearMonth-Day版本歷史版本/狀態(tài)作者參與后起止日期備注1文檔介紹1.1文檔目的1。2文檔范圍1。3參考文獻提示：列出本文檔的所有參考文獻(可以是非正式出版物)，格式如下:標識符作者，文獻名稱，出版單位(或歸屬單位)，日期例如：AAA作者，立項建議書，機構名稱,日期1。5術語與縮寫解釋縮寫、術語解釋2項目介紹2。1項目范圍提

36、示：(1)用簡練的語言說明本項目“是什么”，“說明用途.(2)說明本項目“應當包含的內容 ”和“不包含的內容”第23頁，共40頁2。2項目目標提示：給出“清晰的”、“可實現(xiàn)”、“可驗證”的目標。2。3最終用戶介紹提示：請說明本項目的用戶及其相關責任人是誰，描述最終用戶的特征2。4約束提示：(1)請說明在項目開發(fā)過程中應當遵循的標準或規(guī)范(2)請說明相關項目可能對本項目造成的影響.(3)說明一些假設和依賴。3項目過程定義3.1軟件生命周期模型提示：簡要描述、繪制本項目的軟件生命周期模型。3。2項目規(guī)范提示：描述項目需遵循的規(guī)范，例如：編碼規(guī)范。此處可以表現(xiàn)為編碼規(guī)范的鏈接。3.3方法與工具5.1

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

38、理計劃提示：以下是各個列標題的解釋.約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。風險級別：確定風險的嚴重性、可能性、風險系數(shù)風險描述：緩解方案或者應急計劃.風險編號風險級別風險描述緩解方案應急計劃第25頁，共40頁嚴重性(1-5)可能性(%)風險系數(shù)(嚴重性*可能性)8溝通計劃信息中心代表需求申請單位代表溝通方式溝通頻率/時間期望結果9附件項目進度計劃第26頁，共40頁附件六項目計劃變更說明項目名稱申請日期項目計劃變更申請申請變更的項目計劃輸入名稱，版本，完成日期等信息變更的內容 及其理由評估計劃變更將對 項目造成的影響項目負責人簽字變更申請的審批意見信息中心主任審批審批意

39、見：簽字，日期業(yè)務部門意見審批意見：簽字，日期更改項目計劃變更后的項目計劃輸入名稱，版本，完成日期等信息項目負責人簽字第27頁，共40頁附件七設計說明書文件狀態(tài)：草稿 正式友布止在修改文件標識：ProjectName Module-Design當前版本：X。Y作 者：完成日期：Year-Month -Day版本歷史版本/狀態(tài)作者參與后起止日期備注第28頁，共40頁1引言1.1編寫目的說明編寫這份詳細設計說明書的目的，指出預期的讀者。1.2背景說明：待開發(fā)軟件系統(tǒng)的名稱；本項目的任務提出者、開發(fā)者、用戶和運行該程序系統(tǒng)的計算中心。1。3定義列出本文件中用到專門術語的定義和外文首字母組詞的原詞組。

40、1。4參考資料列出有關的參考資料，如：本項目的經核準的計劃任務書或合同、上級機關的批文；屬于本項目的其他已發(fā)表的文件；本文件中各處引用到的文件資料，包括所要用到的軟件開發(fā)標準。列出這些文件的標 題、文件編號、發(fā)表日期和出版單位，說明能夠取得這些文件的來源。2程序系統(tǒng)的結構用一系列圖表列出本程序系統(tǒng)內的每個程序（包括每個模塊和子程序）的名稱、標識 符和它們之間的層次結構關系。3程序1（標識符）設計說明從本章開始，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對 一般情況的.對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內 容往往與它所隸屬的上一層模塊的對應條目的內

41、容相同，在這種情況下，只要簡單地說明這一點即可。3.1程序描述給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，并且，還要說明本 程序的特點（如 是常駐內存還是非常駐？是否子程序？是可重人的還是不可重人的？有無覆蓋要求？是順序處理還是并發(fā)處理等）。3。2功能說明該程序應具有白功能，可采用 IPO圖（即輸入一處理一輸出圖）的形式 .3.3性能說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。第29頁，共40頁3.4輸入項給出對每一個輸入項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效范圍、輸入的方式。數(shù)量和頻度、輸入媒體、輸入數(shù)據(jù)的來源和安全保密條件等等。3。5輸出

42、項給出對每一個輸出項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式，數(shù)據(jù)值的有效范圍，輸出的形式、數(shù)量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等 等。3.6算法詳細說明本程序所選用的算法，具體的計算公式和計算步驟.3。7流程邏輯用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。3.8 接口用圖的形式說明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序 說明參數(shù)賦值和調用方式，說明與本程序相直接關聯(lián)的數(shù)據(jù)結構（數(shù)據(jù)庫、數(shù)據(jù)文卷）。3。9存儲分配根據(jù)需要，說明本程序的存儲分配。3.10注釋設計說明準備在本程序中安排的注釋，如：加在模塊首部的注釋；加在各分枝點處的

43、注釋；對各變量的功能、范圍、缺省條件等所加的注釋；對使用的邏輯所加的注釋等等.3。11限制條件說明本程序運行中所受到的限制條件。3。12測試計劃說明對本程序進行單體測試的計劃，包括對測試的技術要求、輸入數(shù)據(jù)、預期結果、進度安排、人員職責、設備條件驅動程序及樁模塊等的規(guī)定3.13尚未解決的問題說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。4程序2 （標識符）設計說明用類似F. 3的方式，說明第2個程序乃至第N個程序的設計考慮。第30頁，共40頁附件八單元測試用例1測試范圍說明：本用例測試的功能點。2測試環(huán)境環(huán)境1 :硬件環(huán)境:服務器端：客戶端：軟件環(huán)境:服務器端：客戶端：網

44、絡環(huán)境:環(huán)境2:3數(shù)據(jù)準備說明：可以引用適當?shù)母郊?，如EXCEL文件、文本文件等扁平文件等，這些文件內存放著測試準備的數(shù)據(jù)。測試用例功能1測試編號功能模塊-子模塊-編號測試項目模塊功能-子模塊功能用例描述描述測試上述功能的測試點依賴描述無環(huán)境及初始數(shù)據(jù)環(huán)境1,填寫用到的各種測試數(shù)據(jù)的名稱依賴樣例測試本用例依賴的相關用例名稱序號前置條件測試子項執(zhí)行驟預期結果實際結果備注第31頁，共40頁測試序號填寫本用例 運行的前置 條件.如登 陸、權限、 設備就緒 等；說明測試的 基本流還是 備選流；要求 測試遍歷所 有的備選 流；詳細列出各 個用例角色 的操作的動 作。對應每一步 的預測結 果；對應每一個

45、執(zhí)行步驟的 實際結果；填寫與測試 相關聯(lián)的核 對點、檢查點.第32頁，共40頁附件九系統(tǒng)/用戶測試計劃文件狀態(tài)：V草稿正式發(fā)布正在修改文件標識：當前版本：作 者：完成日期：YearMonth-Day版本歷史版本/狀態(tài)作者參與后起止日期備注1。測試范圍與主要內容提示：系統(tǒng)測試小組應當根據(jù)項目的特征確定測試范圍與內容。一般地 ，系統(tǒng)測試的主要內容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性(security)測試、安裝與反安裝測試等.2。測試方法提示：例如黑盒測試和白盒測試.3.測試環(huán)境與測試輔助工具環(huán)境設備配置名稱/類型備注服務器軟件硬件客戶端軟件一硬件網絡工具工具開發(fā)商版本測試管理缺陷跟蹤第33頁，共40頁用于功能性測試的工具用于性能測試的工具測試覆蓋監(jiān)測器或評測器4。測試進度計劃任務人員任務開始日期結束日期制定測試計劃設計測試實施測試執(zhí)行測試對測試進行評估5。測試完成準則提示：對于非嚴格系統(tǒng)可以采用“基于測試用例的準則：(1)功能性測試用例通過率達到 100%;(2)非功能性測試用例通過率達到95%時。對于嚴格系統(tǒng)，應當補充“基于BU儒度”的規(guī)則：相鄰n個CPU、時內“測試期 BU瑞度”全部低于某個值 s例如n大于10,