互聯(lián)網(wǎng)事業(yè)部業(yè)務(wù)管理手冊

1、互聯(lián)網(wǎng)事業(yè)部業(yè)務(wù)治理方法智慧民生業(yè)務(wù)治理方法軟件保密治理方法軟件研發(fā)治理方法軟件升級治理方法工業(yè)品招商治理方法農(nóng)產(chǎn)品招商治理方法加盟商加盟治理方法縣級運營中心治理方法鄉(xiāng)鎮(zhèn)物流配送中心加盟治理方法村級信息服務(wù)站加盟治理方法平臺商戶結(jié)算治理方法（事業(yè)部與財務(wù)部共同編制）加盟商分成結(jié)算治理方法（事業(yè)部與財務(wù)部共同編制）平臺與子公司分成結(jié)算治理方法（事業(yè)部與財務(wù)部共同編制）村級信息服務(wù)站分成結(jié)算治理方法（事業(yè)部與財務(wù)部共同編制）版 本 頁標(biāo) 題：研發(fā)部保密治理制度文檔編號：版本講明：版本號版本日期作者備注V1.02016.4.10吳訓(xùn)波創(chuàng)建V1.0審批第一章總則第一條凡研發(fā)部的內(nèi)部資料和信息均屬研發(fā)部

2、秘密，所有成員均負(fù)有保密的責(zé)任和義務(wù)。為維護公司利益，特制定本制度。第二條本制度適合研發(fā)部全體職員，包括在編、社會招聘和實習(xí)期人員。第二章保密內(nèi)容第三條 研發(fā)部秘密分為兩類：技術(shù)秘密、內(nèi)部治理秘密。第四條技術(shù)秘密（一）研發(fā)部為開發(fā)項目購買的各種設(shè)計方案、技術(shù)資料等文檔。（二）研發(fā)部的進展戰(zhàn)略、前景規(guī)劃和實施步驟等涉及研發(fā)部技術(shù)走向類文檔。（三）研發(fā)部各種產(chǎn)品的開發(fā)打算、需求分析、調(diào)研報告、立項報告等開發(fā)前期類文檔。（四）研發(fā)部各種系統(tǒng)的方案設(shè)計、功能講明書、數(shù)據(jù)結(jié)構(gòu)、系統(tǒng)參數(shù)講明、接口規(guī)范、程序設(shè)計規(guī)范、系統(tǒng)其它各種規(guī)范和清單、測試方案、測試報告等開發(fā)測試期間形成的各類文檔。（五）研發(fā)部各種系

3、統(tǒng)的集成方案、移植方案、上點試運行方案、版本維護方案、操作和排錯手冊、培訓(xùn)教材等開發(fā)后期類文檔。（六）合作單位提供的各種技術(shù)資料。（七）其它內(nèi)部技術(shù)資料。第五條研發(fā)部內(nèi)部治理秘密（一）研發(fā)部辦公會議紀(jì)要。（二）技術(shù)討論會議紀(jì)要。第六條以上保密內(nèi)容，既指以文件、報表、圖紙、協(xié)議及各種資料等形式存在的紙質(zhì)文檔，又包括以磁盤（硬盤和U盤）、光盤等介質(zhì)形式保存的電子文檔。第三章保密原則第七條研發(fā)部職員不得采納各種手段了解或獵取不屬自己工作范圍內(nèi)或未經(jīng)研發(fā)部許可接觸的秘密。未經(jīng)研發(fā)部書面同意，不得擅自向研發(fā)部其他職員和研發(fā)部外其他人員透露、提供、拷貝自己所掌握的研發(fā)部機密資料。第八條未經(jīng)研發(fā)部書面同意，

4、任何職員不得以方便使用或其它任何理由自行復(fù)制、拷貝自己所掌握的研發(fā)部機密材料。第九條在開發(fā)過程中形成的正式文檔、圖紙、程序、各種資料、合同協(xié)議及各種成果均要及時上交相關(guān)治理部門，并要上交原件。第十條因工作需要使用屬于研發(fā)部機密的有關(guān)資料時，要通過文檔治理部門領(lǐng)取，并嚴(yán)格履行登記手續(xù)，任何人不得擅自拷貝或向其他職員索取。第十一條研發(fā)部職員所掌握的所有涉及秘密的資料，在到達規(guī)定使用期限或因辭職、辭退離開研發(fā)部時必須向有關(guān)文檔治理部門辦理續(xù)借或退還手續(xù)，并負(fù)有接著保密的責(zé)任。第十二條擁有研發(fā)部機密資料的職員，必須認(rèn)真保管使用資料，不得遺失、轉(zhuǎn)借，不經(jīng)同意，不得帶出研發(fā)部。版 本 頁標(biāo) 題：研發(fā)部軟硬

5、件研發(fā)治理制度文檔編號：版本講明：版本號版本日期作者備注V1.02016.4.10吳訓(xùn)波創(chuàng)建V1.0審批第一章總則第一條為規(guī)范軟硬件研發(fā)的治理工作，特制定本制度。本制度適用于公司軟件及硬件的研發(fā)與治理。第二條 軟硬件開發(fā)遵循項目治理和軟硬件工程的差不多原則。項目治理涉及立項治理、項目打算和監(jiān)控、配置治理、開發(fā)治理和結(jié)項治理。軟硬件工程涉及需求治理、系統(tǒng)設(shè)計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、用戶同意測試、試運行、系統(tǒng)驗收、系統(tǒng)上線和數(shù)據(jù)遷移。第二章 立項治理第三條 提出項目需求的部門參與公司層面立項，進行立項的技術(shù)可行性分析，編寫立項分析報告（附件一），開展前期籌備工作。立項分析報告應(yīng)明確項目的范圍和邊界。

6、第四條 需求提出部門將立項分析報告提交相關(guān)部門會簽后，上交公司總經(jīng)理與董事長進行立項審批，以保證系統(tǒng)項目與公司整體策略相一致。第五條立項分析報告得到批準(zhǔn)后，成立項目組，項目組應(yīng)包括業(yè)務(wù)組（由公司需求治理組和相關(guān)業(yè)務(wù)部門組成）和開發(fā)組。公司研發(fā)部委派一名PM負(fù)責(zé)監(jiān)督項目的進度，進行項目治理工作，確保開發(fā)能及時完成并能滿足業(yè)務(wù)需要。項目組人員的選擇應(yīng)滿足項目對業(yè)務(wù)及技術(shù)要求，項目組人員應(yīng)有足夠的業(yè)務(wù)和 IT 技術(shù)方面的專業(yè)知識來勝任項目各方面的工作。第三章 需求分析第六條 立項后業(yè)務(wù)組對用戶需求進行匯總整理，出具業(yè)務(wù)需求講明書（附件二），并確保業(yè)務(wù)需求講明書中包含了所有的業(yè)務(wù)需求。經(jīng)系統(tǒng)使用部門審

7、批確認(rèn)，作為業(yè)務(wù)需求基線。第七條 業(yè)務(wù)組在獲得業(yè)務(wù)需求講明書后，提出技術(shù)需求和解決方案，并對系統(tǒng)進行定義，出具系統(tǒng)需求規(guī)格講明書（附件三）。系統(tǒng)需求規(guī)格講明書需詳細(xì)列出業(yè)務(wù)對系統(tǒng)的要求（界面、輸入、輸出、治理功能、安全需求、運作模式、關(guān)鍵指標(biāo)(KPI)等），最好是采納原型方式表達。系統(tǒng)需求規(guī)格講明書需要由業(yè)務(wù)組提交給相關(guān)業(yè)務(wù)部門負(fù)責(zé)人確認(rèn)。第八條 項目組應(yīng)對需求變更阻礙到的文檔及時更新。第四章 項目打算和監(jiān)控第九條 軟硬件開發(fā)采納項目形式進行治理。項目經(jīng)理負(fù)責(zé)整個項目的打算、組織、領(lǐng)導(dǎo)和操縱。第十條 需求分析過程中，項目經(jīng)理組織制定詳細(xì)的項目打算書（附件四），包括具體任務(wù)描述和項目進度表等。第

8、十一條 在項目的各個時期，業(yè)務(wù)組組長和開發(fā)組組長需配合項目經(jīng)理制定時期性項目打算。業(yè)務(wù)組組長和開發(fā)組組長需配合項目經(jīng)理對項目打算執(zhí)行情況進行監(jiān)控，確保項目按打算完成。第十二條 項目打算需要變更時，項目經(jīng)理填寫項目打算變更講明（附件五），并提交事業(yè)部領(lǐng)導(dǎo)審批，通過審批后，交給業(yè)務(wù)組組長和開發(fā)組組長執(zhí)行。第五章 系統(tǒng)設(shè)計第十三條 系統(tǒng)設(shè)計應(yīng)分為概要設(shè)計和詳細(xì)設(shè)計，系統(tǒng)設(shè)計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。第十四條 在系統(tǒng)設(shè)計時期中，用戶或使用部門應(yīng)充分參與，確保系統(tǒng)設(shè)計能滿足系統(tǒng)需求。第十五條 項目組進行設(shè)計，出具設(shè)計講明書（附件六）和單元測試用例（附件七）。設(shè)計講明書

9、中需要定義系統(tǒng)輸入輸出講明和接口設(shè)計講明。公司主管領(lǐng)導(dǎo)組織相關(guān)人員對概要設(shè)計進行評審，出具設(shè)計評審報告（附件八）。業(yè)務(wù)組組長和開發(fā)組組長應(yīng)參加此評審并對評審意見簽字確認(rèn)第十六條 設(shè)計評審均以業(yè)務(wù)需求講明書和系統(tǒng)需求規(guī)格講明書為依據(jù)，確保系統(tǒng)設(shè)計滿足全部需。第十七條 對已確認(rèn)通過的系統(tǒng)設(shè)計進行修改需獲得項目經(jīng)理、業(yè)務(wù)組組長和開發(fā)組組長的審批后方可進行。第十八條 對系統(tǒng)設(shè)計的修改的文檔須由文檔治理人員進行歸檔治理。第六章 系統(tǒng)實現(xiàn)第十九條 開發(fā)組依照設(shè)計講明書制定系統(tǒng)實現(xiàn)打算，并提交項目經(jīng)理對打算可行性進行審批。第二十條 系統(tǒng)實現(xiàn)包括程序編碼、單元測試。第二十一條 開發(fā)組保證開發(fā)、測試和生產(chǎn)環(huán)境獨

10、立，為各環(huán)境建立訪問權(quán)限操縱機制，并明確項目成員的職責(zé)分工。對開發(fā)環(huán)境、測試環(huán)境與生產(chǎn)環(huán)境在物理或邏輯方面應(yīng)該做到隔離；假如環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應(yīng)定期檢查網(wǎng)絡(luò)設(shè)置。項目組對已授權(quán)訪問生產(chǎn)環(huán)境的人員進行詳細(xì)記錄，并對該記錄進行定期檢查，確保只有經(jīng)授權(quán)的人員才能訪問到生產(chǎn)環(huán)境。第七章 系統(tǒng)測試和用戶測試第二十二條 測試組制定系統(tǒng)測試打算（附件九），并提交項目經(jīng)理對打算可行性進行審批。第二十三條 系統(tǒng)測試打算必須定義測試標(biāo)準(zhǔn)，并明確各種測試的測試步驟和需要的系統(tǒng)設(shè)置要求。第二十四條 開發(fā)組向數(shù)據(jù)擁有部門申請獵取測試用業(yè)務(wù)數(shù)據(jù)的使用權(quán)，對獵取的數(shù)據(jù)進行嚴(yán)格的訪問操縱，確保只有相關(guān)項目人員才

11、能訪問及使用。第二十五條 開發(fā)組負(fù)責(zé)測試數(shù)據(jù)預(yù)備，測試用數(shù)據(jù)要足夠模擬使用環(huán)境中的實際數(shù)據(jù)。對已評定為敏感信息的數(shù)據(jù)進行敏感性處理和愛護。第二十六條 開發(fā)組或合作開發(fā)商協(xié)助技術(shù)研發(fā)部測試組建立測試環(huán)境進行系統(tǒng)測試。在系統(tǒng)測試中對新系統(tǒng)內(nèi)部各模塊之間的接口和與其他系統(tǒng)的接口進行充分測試。技術(shù)研發(fā)部測試組出具系統(tǒng)測試報告（附件十），測試人員簽字確認(rèn)測試結(jié)果。第二十七條 系統(tǒng)測試通過后，開發(fā)組配合業(yè)務(wù)組建立用戶測試環(huán)境，業(yè)務(wù)組依照用戶測試用例進行用戶測試，出具用戶測試報告（附件十），業(yè)務(wù)組組長和開發(fā)組組長應(yīng)在用戶測試報告中簽字確認(rèn)。第二十八條 項目組完成系統(tǒng)關(guān)心文檔（其中包括用戶操作手冊和安裝維護手

12、冊）。凡涉及應(yīng)用系統(tǒng)的變更，應(yīng)對系統(tǒng)關(guān)心文檔及時更新。第八章 試運行第二十九條 系統(tǒng)要緊使用部門依照項目規(guī)模及阻礙決定試運行策略。第三十條 項目組制定試運行打算（附件十一），并制定試運行驗收指標(biāo)，上報公司主管領(lǐng)導(dǎo)審批。試運行打算中應(yīng)包含問題應(yīng)對機制，明確問題溝通渠道和職責(zé)分工。第三十一條 項目組聯(lián)合試運行單位或部門進行相關(guān)系統(tǒng)部署工作，預(yù)備培訓(xùn)資料，對相關(guān)用戶和信息技術(shù)人員進行培訓(xùn)。用戶培訓(xùn)的完成度應(yīng)為實施后評估的指標(biāo)之一。第三十二條 項目組依照試運行打算進行系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移。系統(tǒng)轉(zhuǎn)換前，檢查系統(tǒng)環(huán)境，確保運行環(huán)境能滿足新應(yīng)用系統(tǒng)的需要。系統(tǒng)轉(zhuǎn)換時必須詳細(xì)記錄原系統(tǒng)中的重要參數(shù)、設(shè)置等系統(tǒng)信

13、息，并填寫試運行報告相關(guān)內(nèi)容。系統(tǒng)參數(shù)、設(shè)置的轉(zhuǎn)換工作作為系統(tǒng)上線的驗收的評估指標(biāo)之一。第三十三條 數(shù)據(jù)遷移前，應(yīng)制定詳細(xì)的數(shù)據(jù)遷移打算（附件十二），數(shù)據(jù)遷移打算中應(yīng)包含遷移方案、測試方案、數(shù)據(jù)定義，新舊數(shù)據(jù)對比表、遷移時刻、回退打算等信息。數(shù)據(jù)遷移打算需經(jīng)項目經(jīng)理和主管領(lǐng)導(dǎo)簽字審批。第三十四條 數(shù)據(jù)遷移后，項目組對數(shù)據(jù)遷移的完整性和準(zhǔn)確性做出檢查，出具數(shù)據(jù)遷移報告（附件十三），其中包括數(shù)據(jù)來源、轉(zhuǎn)換前狀態(tài)、轉(zhuǎn)換后狀態(tài)，數(shù)據(jù)遷移負(fù)責(zé)人、對完整性檢查情況、對準(zhǔn)確性檢查情況等內(nèi)容。各相關(guān)部門驗收轉(zhuǎn)換結(jié)果后在該報告上簽字確認(rèn)。第三十五條 系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移由試運行單位業(yè)務(wù)部門和公司主管領(lǐng)導(dǎo)共同監(jiān)督并

14、進行驗收。第三十六條 系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位把系統(tǒng)運行情況（系統(tǒng)資源使用，反應(yīng)速度及其他量化指標(biāo)等）記錄到系統(tǒng)試運行報告中。必要時，項目組應(yīng)依照系統(tǒng)運行情況對應(yīng)用系統(tǒng)進行優(yōu)化。第三十七條 試運行達到試運行打算規(guī)定的終止條件時，項目組編寫試運行報告（附件十四）。此報告應(yīng)由項目組和試運行單位簽字確認(rèn)，并提交公司主管領(lǐng)導(dǎo)批閱。公司主管領(lǐng)導(dǎo)批閱試運行結(jié)果，決定試運行結(jié)束或延期。第九章 系統(tǒng)驗收 第三十八條 系統(tǒng)要緊使用部門及技術(shù)研發(fā)部聯(lián)合組成獨立系統(tǒng)驗收小組，也可授權(quán)原項目組作為驗收小組。驗收小組從功能需求及技術(shù)需求層面對系統(tǒng)進行綜合評估。 第三十九條

15、 驗收小組應(yīng)依照驗收情況整理形成系統(tǒng)驗收報告（附件十五）提交系統(tǒng)要緊使用部門和技術(shù)研發(fā)部批閱。 第四十條 系統(tǒng)要緊使用部門和信息技術(shù)部門負(fù)責(zé)人依照系統(tǒng)測試、試運行情況簽署驗收意見。第十節(jié) 系統(tǒng)上線第四十一條 系統(tǒng)上線應(yīng)遵循穩(wěn)妥、可控、安全的原則。第四十二條 通常情況下，系統(tǒng)上線包含數(shù)據(jù)遷移工作。第四十三條 項目組制定系統(tǒng)上線打算（附件十六），上報公司主管領(lǐng)導(dǎo)審批。在上線打算得到批準(zhǔn)后才能開始部署上線工作。第四十四條 系統(tǒng)上線打算內(nèi)容應(yīng)包括但不限于： 1、部署方式和資源分配（包括人力資源及服務(wù)器資源）； 2、上線工作時刻表； 3、上線操作步驟以及問題處理步驟； 4、項目時期性里程碑和成果匯報（項

16、目執(zhí)行狀態(tài)的批閱、進度安排等）； 5、數(shù)據(jù)遷移的需求和實施打算；6、完整可行的應(yīng)急預(yù)案和“回退”打算； 7、用戶培訓(xùn)打算（包括：培訓(xùn)打算、培訓(xùn)手冊、培訓(xùn)考核等）； 8、公司下發(fā)的系統(tǒng)標(biāo)準(zhǔn)參數(shù)配置。第四十五條 上線單位在上線初期需加強日常運行狀態(tài)監(jiān)控，出現(xiàn)問題時應(yīng)及時處理，對重大問題應(yīng)啟動緊急預(yù)案。第四十六條 在完成上線后要填寫系統(tǒng)驗收評估報告（附件十七）。系統(tǒng)驗收評估報告內(nèi)容包括：數(shù)據(jù)準(zhǔn)確性、系統(tǒng)性能及穩(wěn)定性、接口問題、權(quán)限問題、業(yè)務(wù)操作阻礙度、問題處理情況、備份、批處理等。第四十七條 上線單位治理層要對系統(tǒng)驗收評估報告進行審批簽字。第四十八條 公司主管領(lǐng)導(dǎo)批準(zhǔn)結(jié)項后，業(yè)務(wù)組和開發(fā)組將整理的文

17、檔提交各自部門統(tǒng)一治理。第十二章 系統(tǒng)交付 第四十九條 在系統(tǒng)驗收通過后，項目組對運營部門或使用單位進行系統(tǒng)維護培訓(xùn)。 第五十條 項目組提交全部經(jīng)審批的交付資料給 PMO(項目治理辦公室) 存檔。 第五十一條 項目組填寫系統(tǒng)交付申請（附件十八），提交公司技術(shù)總監(jiān)審批后，交付運營部門或使用單位。第十三章 軟件版本命名規(guī)范第五十二條 版本命名規(guī)范軟件版本號有四部分組成，第一部分為主版本號，第二部分為次版本號，第三部分為修訂版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有五種，分不為base、alpha、beta、RC、release。如：2.1.1.20160410_betaBas

18、e：此版本表示該軟件僅僅是一個假頁面鏈接，通常包括所有的功能和頁面布局，然而頁面中的功能都沒有做完整的實現(xiàn)，只是作為整體網(wǎng)站的一個基礎(chǔ)架構(gòu)。Alpha： 軟件的初級版本，表示該軟件在現(xiàn)在期以實現(xiàn)軟件功能為主，通常只在軟件開發(fā)者內(nèi)部交流，一般而言，該版本軟件的Bug較多，需要接著修改，是測試版本。測試人員提交Bug經(jīng)開發(fā)人員修改確認(rèn)之后，公布到測試網(wǎng)址讓測試人員測試，現(xiàn)在可將軟件版本標(biāo)注為alpha版。Beta：該版本相關(guān)于Alpha版差不多有了專門大的進步，消除了嚴(yán)峻錯誤，但還需要通過多次測試來進一步消除，此版本要緊的修改對象是軟件的UI。修改的的Bug經(jīng)測試人員測試確認(rèn)后可公布到外網(wǎng)上，現(xiàn)在

19、可將軟件版本標(biāo)注為beta版。RC：該版本差不多相當(dāng)成熟了，差不多上不存在導(dǎo)致錯誤的Bug，與立即發(fā)行的正式版本相差無幾。Release：該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會有一個正式的版本，是最終交付用戶使用的一個版本。該版本有時也稱標(biāo)準(zhǔn)版。第五十三條 版本號修改規(guī)則1、主版本號：當(dāng)功能模塊有較大的變動，比如增加模塊或是整體架構(gòu)發(fā)生變化。此版本號由項目研發(fā)部經(jīng)理決定是否修改。2、次版本號：相關(guān)于主版本號而言，次版本號的升級對應(yīng)的只是局部的變動，但該局部的變動造成程序和往常版本不能兼容，或者對該程序往常的協(xié)作關(guān)系產(chǎn)生了破壞，或者 是功能上有大的改進或增強。此版本號由項目

20、經(jīng)理決定是否修改。3、修訂版本號：一般是Bug的修復(fù)或是一些小的變動或是一些功能的擴充，要經(jīng)常公布修訂版，修復(fù)一個嚴(yán)峻Bug即可公布一個修訂版。此版本號由項目經(jīng)理決定是否修改。4、日期版本號：用于記錄修改項目的當(dāng)前日期，每天對項目的修改都需要更改日期版本號。此版本號由開發(fā)人員決定是否修改。5、希臘字母版本號：此版本號用于標(biāo)注當(dāng)前版本的軟件處于哪個開發(fā)時期，當(dāng)軟件進入到另一個時期時需要修改此版本號。此版本號由項目經(jīng)理決定是否修改。6、主版本號、次版本號及修訂版本號中，上一級版本有變動時，下級要歸零。第五十四條 版本公布周期1、非緊急情況：首先由測試人員測試并提交Bug，其次開發(fā)人員會盡量在當(dāng)天修

21、復(fù)Bug并在第二天公布該版本的alpha版，然后由測試人員測試驗證關(guān)閉Bug之后在第三天會公布該版本的beta版。2、緊急情況：假如Bug比較緊急可躍過一般流程，由開發(fā)人員盡快修復(fù)Bug，測試確認(rèn)之后直接公布該版本的beta版，日期為公布版本當(dāng)天的日期。第五十五條 升級公布流程。按照升級的版本號，由開發(fā)人員、測試人員、項目經(jīng)理及研發(fā)部經(jīng)理填寫軟件升級提交表（附件十九）。附件一 立項分析報告文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)識：ProjectName當(dāng)前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1. 項目介紹 1.1. 項目目的

22、提示：用簡練的語言講明本項目“是什么”，“實現(xiàn)什么目的”。描述簡練且清晰。 1.2. 項目背景 提示：闡述項目背景，重點講明“什么緣故”會產(chǎn)生本項目。 （ 1 ）公司的短期、長期進展戰(zhàn)略； （ 2 ）業(yè)務(wù)需求及進展趨勢； （ 3 ）技術(shù)狀況及進展趨勢； （ 4 ）專門的業(yè)務(wù)需求等。 1.3. 項目范圍 提示：依照對現(xiàn)有需求的了解來確定項目差不多范圍，講明本系統(tǒng)“應(yīng)當(dāng)包含的內(nèi)容”和“不包含的內(nèi)容”。 2. 項目打算 2.1. 項目團隊 提示：講明項目團隊的角色、知識技能要求、建議人選、人數(shù)、工作時刻，如下表所示。角 色知識技能要求建議人選、人數(shù)工作時刻項目經(jīng)理需求開發(fā)人員系統(tǒng)設(shè)計人員研發(fā)人員測試

23、人員質(zhì)量保證人員配置治理人員服務(wù)與維護人員2.2. 成本可能內(nèi)容成本（人民幣 萬元）備注人力資源軟硬件資源差旅費會議費接待費2.3. 進度表編號進度名稱可能結(jié)束時刻備注需求調(diào)研項目打算需求分析概要設(shè)計詳細(xì)設(shè)計研發(fā)及單元測試系統(tǒng)測試用戶驗收測試試運行項目驗收3. 總結(jié) 提示：給出清晰的建議結(jié)論，便于上級領(lǐng)導(dǎo)決策附件二 業(yè)務(wù)需求講明書文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)識：ProjectName當(dāng)前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 概述 1.1 業(yè)務(wù)調(diào)研人員名單 1.2 業(yè)務(wù)范圍 此處描寫總體業(yè)務(wù)的概要分類。 1.3 業(yè)務(wù)

24、目標(biāo) 從高層或商務(wù)利益的角度提出本業(yè)務(wù)系統(tǒng)的期望目標(biāo)，以及評價標(biāo)準(zhǔn)。 1.4 相關(guān)文檔 講明：列出本文檔的所有參考文獻（能夠是非正式出版物），包括現(xiàn)有規(guī)范、標(biāo)準(zhǔn)、批文、引用到的文件、資料等。 1.5 業(yè)務(wù)詞匯表 講明：列出本文檔的所引用的專屬領(lǐng)域詞匯、術(shù)語等，以便于業(yè)務(wù)需求的提供者和接收者是建立在一致的業(yè)務(wù)理解基礎(chǔ)之上的。 2 組織結(jié)構(gòu)及業(yè)務(wù) 2.1 業(yè)務(wù)相關(guān)組織結(jié)構(gòu)、人員組織結(jié)構(gòu) 講明：假如客戶崗位設(shè)置復(fù)雜可分不設(shè)置，業(yè)務(wù)組織結(jié)構(gòu)和人員組織結(jié)構(gòu)2.2 組織機構(gòu)描述 2.3 角色職責(zé) 講明：將業(yè)務(wù)涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責(zé)。 2.4 治理綜述【可選】 講明

25、：要緊描述該業(yè)務(wù)的治理特點和治理模式。 2.5 現(xiàn)有業(yè)務(wù)流程清單 【可選】 講明：現(xiàn)有業(yè)務(wù)流程需要考慮，專門多新的業(yè)務(wù)是在已有業(yè)務(wù)流程基礎(chǔ)上進行重組的。 流程編號流程名稱責(zé)任部門輔助部門3 業(yè)務(wù)流程及業(yè)務(wù)處理描述 針對每一項具體的目標(biāo)業(yè)務(wù)，描述具體的業(yè)務(wù)流程，以及相關(guān)業(yè)務(wù)的具體描述。 3.1 具體業(yè)務(wù)流程（系統(tǒng)名稱+編號） 關(guān)于具體業(yè)務(wù)流程的命名有規(guī)范，對具體流程進行編號，便于形成需求矩陣，同時形成需求的治理和跟蹤。 3.1.1 業(yè)務(wù)流程 3.1.2 業(yè)務(wù)描述 講明：描述具體的業(yè)務(wù)流程。 3.1.3 相關(guān)業(yè)務(wù)對象 講明：業(yè)務(wù)對象：業(yè)務(wù)流程中涉及的單據(jù)、報表等。 業(yè)務(wù)對象使用部門對應(yīng)電子檔案編號

26、 3.1.4 業(yè)務(wù)規(guī)則及關(guān)鍵算法 講明：描述業(yè)務(wù)環(huán)節(jié)關(guān)鍵算法體系。 4 假定和約束 講明：列出進行本軟件開發(fā)工作的假定和約束，例如開發(fā)期限等。 4.1 運行環(huán)境約束4.2 設(shè)計約束 【可選】 講明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、要緊開發(fā)工具、核心技術(shù)、第三方產(chǎn)品等。 4.3 產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范 【可選】 講明：闡述本產(chǎn)品應(yīng)當(dāng)遵循什么標(biāo)準(zhǔn)、規(guī)范或業(yè)務(wù)規(guī)則，違反標(biāo)準(zhǔn)、規(guī)范或業(yè)務(wù)規(guī)則的產(chǎn)品通常不太可能被同意。 5 其他 5.1 目前核心問題和困難 5.2 業(yè)務(wù)對項目實施的需求和期望 【可選】 5.3 其他未盡事宜附件三 系統(tǒng)需求規(guī)格講明書文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)

27、識：ProjectName當(dāng)前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 引言 1.1 目的 例如：規(guī)定系統(tǒng)的邊界和目標(biāo)，描述系統(tǒng)的功能性需求和非功能性需求。 1.2 讀者對象及閱讀建議 講明：指明本文檔面向的讀者群，及相應(yīng)的閱讀意見。 1.3 文檔范圍 【可選】 講明：對本文的范圍做闡述，本文檔改動時，受到阻礙的范圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。 1.4 參考文檔 講明：列出本文檔的所有參考文獻（能夠是非正式出版物），包括打算任務(wù)書、合同、批文、引用到的文件、資料及軟件開發(fā)標(biāo)準(zhǔn)等。 1.5 術(shù)語與縮寫解

28、釋 講明：列出本文件中用到的專門術(shù)語的定義和縮寫詞的原詞組，并給予解釋，以便于所有讀者達成共識。 2 綜合描述 2.1 系統(tǒng)背景 【可選】 講明：介紹系統(tǒng)的預(yù)期效果、歷史緣故。2.2 問題講明 【可選】 提供一段講明，總結(jié)項目需要解決的問題。能夠采納以下格式：問題是對問題進行講明阻礙問題阻礙的干系人問題的后果該問題會導(dǎo)致什么后果成功的解決方案應(yīng)列出成功解決方案的一些要緊優(yōu)點2.3 系統(tǒng)范圍 講明：闡述本項目“適用的業(yè)務(wù)領(lǐng)域”和“不適用的業(yè)務(wù)領(lǐng)域”，本產(chǎn)品“應(yīng)當(dāng)包含的內(nèi)容”和“不包含的內(nèi)容”。講清晰系統(tǒng)范圍的好處是：（1）有助于推斷什么是需求，什么不是需求；（2）能夠?qū)㈤_發(fā)精力集中在產(chǎn)品范圍之內(nèi)

29、；（3）有助于操縱需求的變更。 完整而準(zhǔn)確的定義本產(chǎn)品的干系人； 明確本產(chǎn)品所阻礙到的部門和業(yè)務(wù)； 用圖表或者文字描述產(chǎn)品的范圍，概要的定義產(chǎn)品的功能。 2.4 干系人與用戶講明 【可選】 2.4.1 用戶環(huán)境 【可選】 詳細(xì)講明目標(biāo)用戶的工作環(huán)境。以下是幾項建議： 該任務(wù)由多少人來完成？是否總在變化？ 一個任務(wù)周期需要多長時刻？執(zhí)行每項活動要用多長時刻？是否總在變化？ 是否有專門的環(huán)境約束：移動、戶外、乘機旅行等？ 目前使用的是哪些系統(tǒng)平臺？以后會使用哪些平臺？ 還在使用哪些應(yīng)用程序？您的應(yīng)用程序是否需要和這些應(yīng)用程序集成？ 在此處能夠從業(yè)務(wù)模型中摘錄一些內(nèi)容來概述所涉及的任務(wù)和角色等等。

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

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

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

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

34、每一類功能或者有時關(guān)于每一個功能，需要具體描述其輸入、加工和輸出的需求。3.2 非功能需求 3.2.1 外部接口 3.2.1.1 用戶接口 講明：提供用戶使用軟件產(chǎn)品時的接口需求。例如，假如系統(tǒng)的用戶通過顯示終端進行操作，就必須指定如下要求： a 對屏幕格式的要求 講明：對界面上的各對象、類型、寬度、取值范圍、數(shù)據(jù)來源、能否為空等屬性進行描述。 b 報表或菜單的頁面打印格式和內(nèi)容 c 輸入輸出的需求 講明：解釋各輸入輸出數(shù)據(jù)類型，并逐項講明其媒體、格式、數(shù)值范圍、精度等。對軟件的數(shù)據(jù)輸出及必須標(biāo)明的操縱輸出量進行解釋并舉例，包括對硬拷貝報告（正常結(jié)果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告

35、的描述。 d 程序功能鍵的可用性 講明：快捷鍵定義等。 3.2.1.2 硬件接口 【可選】 講明：要指出軟件產(chǎn)品和系統(tǒng)硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什么樣的設(shè)備，如何支撐這些設(shè)備，有何約定。 3.2.1.3 軟件接口 【可選】 講明：在此要指定需使用的其他軟件產(chǎn)品（例如，數(shù)據(jù)治理系統(tǒng)、操作系統(tǒng)或其他軟件包），以及同其他應(yīng)用系統(tǒng)之間的接口。對每一個所需的軟件產(chǎn)品，要提供如下內(nèi)容：名字、助記符、規(guī)格講明號、版本號、來源。 關(guān)于每一個接口，這部分應(yīng)講明與軟件產(chǎn)品相關(guān)的接口軟件的目的，并依照信息的內(nèi)容和格式定義接口，但不必詳細(xì)描述任何已有完整文件的接口，只要引用定義該接口的文

36、件即可。 【接口定義】 下表是對一些接口的具體描述:接口名稱接口描述填寫接口完成的任務(wù)接口類型填寫是輸入接口（inbound）依舊輸出接口（outbound）源系統(tǒng)填寫接口輸入方系統(tǒng)或部件目標(biāo)系統(tǒng)填寫接口輸出方系統(tǒng)或部件廠商提供/客戶化開發(fā)文件類型填寫文件類型；若通過數(shù)據(jù)庫表來交互，請指明數(shù)據(jù)庫及表名文件數(shù)量峰值數(shù)據(jù)量頻度填寫數(shù)據(jù)處理的頻度復(fù)雜度批處理/人工填寫接口數(shù)據(jù)的驅(qū)動模式是人工（manual）依舊自動(automatic)，依舊都支持接口類型填寫是實時接口依舊批量接口等【其他系統(tǒng)詳細(xì)信息】 講明：列出所有與接口交互的外圍系統(tǒng)的詳細(xì)信息。包括輸入、輸出系統(tǒng)等系統(tǒng)填寫與接口交互的系統(tǒng)名稱

37、系統(tǒng)類型填寫是接口的數(shù)據(jù)源系統(tǒng)(source)依舊目標(biāo)系統(tǒng)(object) 數(shù)據(jù)庫填寫交互系統(tǒng)使用的數(shù)據(jù)庫及版本軟件填寫交互系統(tǒng)的軟件名稱 架構(gòu)類型交互系統(tǒng)的架構(gòu)類型是 B/S 依舊 C/S。 位置填寫該軟件在交互軟件體系中所出的位置 技術(shù)支持填寫交互系統(tǒng)的開發(fā)商和支持商 功能支持填寫具體的支持商或技術(shù)團隊 數(shù)據(jù)歸屬【接口隸屬系統(tǒng)的詳細(xì)信息可選 】系統(tǒng)填寫接口隸屬系統(tǒng)的名稱 模塊隸屬于具體的模塊名稱 數(shù)據(jù)庫隸屬系統(tǒng)的數(shù)據(jù)庫及版本 負(fù)責(zé)人操縱報告【接口配置】 （1）接口基礎(chǔ)信息配置 講明：接口基礎(chǔ)信息的配置項目，描述配置的方式。 （2）接口運行參數(shù)配置 講明：接口運行參數(shù)的配置方式和步驟。 【其

38、他配置可選 】 講明：外圍系統(tǒng)或相關(guān)模塊的配置。 3.2.1.4 通信接口【可選】 講明：指定各種通信接口。例如，局部網(wǎng)絡(luò)的協(xié)議等等。 3.2.2 其他非功能性需求 講明：下表中的各種需求，可依照實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細(xì)解釋名稱 詳細(xì)要求靜態(tài)數(shù)值需求 動態(tài)數(shù)值需求 精度 時刻特性要求 可用性 可靠性 可維護性 安全性 可移植性 可擴展性 兼容性 3.2.2.1 靜態(tài)數(shù)值需求 講明：支持的終端數(shù)；支持并行操作的用戶數(shù)。 3.2.2.2 動態(tài)數(shù)值需求講明：欲處理的事務(wù)和任務(wù)的數(shù)量，以及在正常情況下和峰值工作條件下一定時刻周期中處理的數(shù)據(jù)總量。 3.2.

39、2.3 精度 講明:對該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。 3.2.2.4 時刻特性要求 講明：關(guān)于該軟件的時刻特性要求，如對： a響應(yīng)時刻； b更新處理時刻； c數(shù)據(jù)的轉(zhuǎn)換和傳送時刻； d解題時刻等要求。 3.2.2.5 數(shù)據(jù)治理要求 【可選】 講明：需要治理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預(yù)見的增長對數(shù)據(jù)及其重量的存儲要求做出估算。 3.2.2.6 可用性 指出一般用戶和高級用戶要高效地執(zhí)行特定操作所需的培訓(xùn)時刻，指出典型任務(wù)的可評測任務(wù)次數(shù)或依照用戶已知或喜愛的其他系統(tǒng)確定新系統(tǒng)的可用性需求性能 3.2.2.7 可靠性 指出可用時刻百分比 ( xx.

40、xx%)、使用小時數(shù)、維護訪問權(quán)、降級模式操作等。平均故障間隔時刻 (MTBF)。平均修復(fù)時刻 (MTTR)系統(tǒng)在發(fā)生故障后能夠暫停運行的時刻。指出系統(tǒng)輸出要求具備的周密度（分辨率）和精確度（按照某一已知的標(biāo)準(zhǔn)）。 3.2.3 文檔需求 講明：要緊是在線用戶手冊與關(guān)心系統(tǒng)，也包括其他的文檔 3.2.4 第三方產(chǎn)品 【可選】 講明：使用到的第三方產(chǎn)品相關(guān)的 使用許可、使用限制、接口標(biāo)準(zhǔn)。 3.3 數(shù)據(jù)字典 講明：把相關(guān)的數(shù)據(jù)抽取出來統(tǒng)一維護，在其他章節(jié)如有類似信息描述，則關(guān)聯(lián)到數(shù)據(jù)字典的相關(guān)部分并加輔助講明，如：引用到的字段等。 4 補充資料 【可選】4.1 待確定的問題列表【可選】 需求標(biāo)題1

41、 調(diào)查方式 調(diào)查人 調(diào)查對象 時刻、地點 需求信息記錄 附件四 項目打算書文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)識：ProjectName當(dāng)前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 文檔介紹 1.1 文檔目的 1.2 文檔范圍 1.3 參考文獻 提示： 列出本文檔的所有參考文獻（能夠是非正式出版物），格式如下： 標(biāo)識符 作者，文獻名稱，出版單位（或歸屬單位），日期 例如： AAA 作者，立項建議書，機構(gòu)名稱，日期 1.5 術(shù)語與縮寫解釋縮寫、術(shù)語解 釋 2 項目介紹 2.1 項目范圍 提示： （1）用簡練的語言講明本項目“是什

42、么”，“講明用途”。 （2）講明本項目“應(yīng)當(dāng)包含的內(nèi)容”和“不包含的內(nèi)容”。2.2 項目目標(biāo) 提示：給出“清晰的”、“可實現(xiàn)”、“可驗證”的目標(biāo)。 2.3 客戶與最終用戶介紹 提示：請講明本項目的客戶、用戶及其相關(guān)責(zé)任人是誰，描述最終用戶的特征。 2.4 約束 提示： （1）請講明在項目開發(fā)過程中應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范 （2）請講明相關(guān)項目可能對本項目造成的阻礙。 （3）講明一些假設(shè)和依靠。 3 項目過程定義 3.1 軟件生命周期模型 提示：簡要描述、繪制本項目的軟件生命周期模型。 3.2 項目規(guī)范 提示：描述項目需遵循的規(guī)范，例如：編碼規(guī)范。此處能夠表現(xiàn)為編碼規(guī)范的鏈接。 3.3 方法與工具

43、提示：講明在過程中將采納的方法與工具。例如采納 Rational Rose 進行面向?qū)ο蠓治雠c設(shè)計，采納 Visual SourceSafe 進行配置治理，采納 Microsoft Office 制作文檔。方法與工具用途 Visual SourceSafe配置治理 4 里程碑打算 序號里程碑名稱開始日期結(jié)束日期工作成果備注 5 資源打算 5.1 人力資源打算 提示：制定本項目的角色職責(zé)表，并為已知的項目成員分配角色（一個人能夠兼多個角色）。角色職責(zé)人員姓名工作講明高層領(lǐng)導(dǎo) 項目經(jīng)理 需求分析員 系統(tǒng)設(shè)計員 程序員 測試員 5.2 軟硬件資源打算 提示：分析項目開發(fā)、測試、運行所需的軟硬件資源和

44、關(guān)鍵計算機資源（會阻礙軟件產(chǎn)品的性能的 CPU、內(nèi)存、帶寬等內(nèi)容），要緊內(nèi)容包括： 資源級不（分為“關(guān)鍵”、“一般”兩種） 詳細(xì)配置 獵取方式（如“差不多存在”、“能夠借用”或“需要購買”等）與獵取時刻 使用講明（如“誰”在“什么”時候使用）軟硬件資源名稱級不詳細(xì)配置獵取方式與時刻使用講明 關(guān)鍵 關(guān)鍵 一般 6 文檔交付列表序號交付文檔名稱交付日期備注7 風(fēng)險治理打算 提示：以下是各個列標(biāo)題的解釋。 約定在項目中的風(fēng)險治理方案，例如：風(fēng)險識不頻度、風(fēng)險跟蹤頻度等。 風(fēng)險級不：確定風(fēng)險的嚴(yán)峻性、可能性、風(fēng)險系數(shù) 風(fēng)險描述：緩解方案或者應(yīng)急打算風(fēng)險編號風(fēng)險級不風(fēng)險描述緩解方案應(yīng)急打算嚴(yán)峻性(1-5

45、)可能性(%)風(fēng)險系數(shù) (嚴(yán)峻性*可能性)8 溝通打算甲方代表乙方代表溝通方式溝通頻率/時刻期望結(jié)果9 附件 項目進度打算附件五 項目打算變更講明項目名稱申請日期 項目打算變更申請申請變更的項目打算輸入名稱，版本，完成日期等信息 變更的內(nèi)容及其理由 評可能劃變更將對項目造成的阻礙 項目負(fù)責(zé)人簽字變更申請的審批意見產(chǎn)品經(jīng)理審批審批意見： 簽字 日期研發(fā)部經(jīng)理審批審批意見： 簽字 日期使用部門意見審批意見： 簽字 日期更改項目打算變更后的項目打算輸入名稱，版本，完成日期等信息項目負(fù)責(zé)人簽字附件六 設(shè)計講明書文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)識：ProjectName當(dāng)前版本：X.Y作 者：

46、完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 引言 1.1 編寫目的 講明編寫這份詳細(xì)設(shè)計講明書的目的，指出預(yù)期的讀者。 1.2 背景 講明： 待開發(fā)軟件系統(tǒng)的名稱； 本項目的任務(wù)提出者、開發(fā)者、用戶和運行該程序系統(tǒng)的應(yīng)用環(huán)境。 1.3 定義 列出本文件中用到專門術(shù)語的定義和外文首字母組詞的原詞組。 1.4 參考資料 列出有關(guān)的參考資料，如： 本項目的經(jīng)核準(zhǔn)的打算任務(wù)書或合同、上級機關(guān)的批文； 屬于本項目的其他已發(fā)表的文件； 本文件中各處引用到的文件資料，包括所要用到的軟件開發(fā)標(biāo)準(zhǔn)。列出這些文件的標(biāo)題、文件編號、發(fā)表日期和出版單位，講明能夠取得這些文件的來

47、源。 2 程序系統(tǒng)的結(jié)構(gòu) 用一系列圖表列出本程序系統(tǒng)內(nèi)的每個程序（包括每個模塊和子程序）的名稱、標(biāo)識符和它們之間 的層次結(jié)構(gòu)關(guān)系。 3 程序 1（標(biāo)識符）設(shè)計講明 從本章開始，逐個地給出各個層次中的每個程序的設(shè)計考慮。以下給出的提綱是針對一般情況的。關(guān)于一個具體的模塊，尤其是層次比較低的模塊或子程序，其專門多條目的內(nèi)容往往與它所隸屬的上一層 模塊的對應(yīng)條目的內(nèi)容相同，在這種情況下，只要簡單地講明這一點即可。 3.1 程序描述 給出對該程序的簡要描述，要緊講明安排設(shè)計本程序的目的意義，同時講明本程序的特點（如 是常駐內(nèi)存依舊特不駐？是否子程序？是可重入的依舊不可重入的？有無覆蓋要求？是順序處理依

48、舊并發(fā)處理等）。 3.2 功能 講明該程序應(yīng)具有的功能，可采納 IPO 圖（即輸入處理輸出圖）的形式。 3.3 性能 講明對該程序的全部性能要求，包括對精度、靈活性和時刻特性的要求。3.4 輸入項 給出對每一個輸入項的特性，包括名稱、標(biāo)識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效范圍、輸入的方式。數(shù)量和頻度、輸入媒體、輸入數(shù)據(jù)的來源和安全保密條件等等。 3.5 輸出項 給出對每一個輸出項的特性，包括名稱、標(biāo)識、數(shù)據(jù)的類型和格式，數(shù)據(jù)值的有效范圍，輸出的形式、數(shù)量和頻度，輸出媒體、對輸出圖形及符號的講明、安全保密條件等等。 3.6 算法 詳細(xì)講明本程序所選用的算法，具體的計算公式和計算步驟。 3.7 流程

49、邏輯 用圖表（例如流程圖、判定表等）輔以必要的講明來表示本程序的邏輯流程。 3.8 接口 用圖的形式講明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序，講明參數(shù)賦值和調(diào)用方式，講明與本程序相直接關(guān)聯(lián)的數(shù)據(jù)結(jié)構(gòu)（數(shù)據(jù)庫、數(shù)據(jù)文卷）。 3.9 存儲分配 依照需要，講明本程序的存儲分配。 3.10 注釋設(shè)計 講明預(yù)備在本程序中安排的注釋，如： 加在模塊首部的注釋； 加在各分枝點處的注釋； 對各變量的功能、范圍、缺省條件等所加的注釋； 對使用的邏輯所加的注釋等等。 3.11 限制條件 講明本程序運行中所受到的限制條件。 3.12 測試打算 講明對本程序進行單體測試的打算，包括對測試的技術(shù)要

50、求、輸入數(shù)據(jù)、預(yù)期結(jié)果、進度安排、人員職責(zé)、設(shè)備條件驅(qū)動程序及樁模塊等的規(guī)定。 3.13 尚未解決的問題 講明在本程序的設(shè)計中尚未解決而設(shè)計者認(rèn)為在軟件完成之前應(yīng)解決的問題。 4 程序 2（標(biāo)識符）設(shè)計講明 用類似上述3的方式，講明第個程序乃至第N個程序的設(shè)計考慮。附件七 單元測試用例1 測試范圍 講明：本用例測試的功能點。 2 測試環(huán)境 環(huán)境 1： 硬件環(huán)境： 服務(wù)器端： 客戶端： 軟件環(huán)境： 服務(wù)器端： 客戶端： 網(wǎng)絡(luò)環(huán)境： 環(huán)境 2： 3 數(shù)據(jù)預(yù)備 講明：能夠引用適當(dāng)?shù)母郊?EXCEL 文件、文本文件等扁平文件等，這些文件內(nèi)存放著測試預(yù)備的數(shù)據(jù)。 測試用例 功能 1測試編號功能模塊子

51、模塊編號 測試項目模塊功能子模塊功能 用例描述描述測試上述功能的測試點 依靠描述無 環(huán)境及初始數(shù)據(jù)環(huán)境 1 ， 填寫用到的各種測試數(shù)據(jù)的名稱 依靠樣例測試本用例依靠的相關(guān)用例名稱 序號前置條件測試子項執(zhí)行步驟預(yù)期結(jié)果實際結(jié)果備注測試序號填寫本 用例運 行的前置條件。 如登陸、權(quán)限、設(shè) 備就緒等；講明測試的差不多流依舊備選流；要求測試遍歷所有的備選流；詳細(xì)列出各個用例角色的操作的動作；對應(yīng)每一步的預(yù)測結(jié)果；對應(yīng)每一個執(zhí)行步驟的實際結(jié)果；填寫與測試相關(guān)聯(lián)的核對點、檢查點；附件八 設(shè)計評審報告文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)識：ProjectName當(dāng)前版本：X.Y作 者：完成日期：Yea

52、r-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1. 差不多信息 提示：由評審主持人或評審員填寫此表格。待評審的工作成果工作成果名稱，標(biāo)識符，版本，作者，時刻 技術(shù)評審方式（正式評審）或者(走查) 評審時刻 評審地點 參加技術(shù)評審的人員類不名字工作單位職稱、職務(wù) 主持人 評審小組成員記錄員2. 缺陷識不和跟蹤評審問題跟蹤表編號問題描述問題類型嚴(yán)峻性提交者提交日期問題處理負(fù)責(zé)人解決措施/緣故講明問題解決狀態(tài)實際關(guān)閉日期問題關(guān)閉驗證人備注1 2 3 3. 評審結(jié)論與意見 提示：由主持人或評審員填寫此表格。評審結(jié)論 工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。 工作成

53、果差不多合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。 意見負(fù)責(zé)人簽字 簽字： 日期：附件九 系統(tǒng)/用戶測試打算文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)識：ProjectName當(dāng)前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1. 測試范圍與要緊內(nèi)容 提示：系統(tǒng)測試小組應(yīng)當(dāng)依照項目的特征確定測試范圍與內(nèi)容。一般地，系統(tǒng)測試的要緊內(nèi)容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性（security）測試、安裝與反安裝測試等。 2. 測試方法 提示：例如黑盒測試和白盒測試。

54、3. 測試環(huán)境與測試輔助工具 環(huán)境設(shè)備配置名稱/類型備注 服務(wù)器軟件硬件客戶端軟件硬件網(wǎng)絡(luò)工具類型工具開發(fā)商版本測試治理缺陷跟蹤用于功能性測試的工具用于性能測試的工具測試覆蓋監(jiān)測器或評測器4. 測試進度打算任務(wù)人員任務(wù)開始日期結(jié)束日期 制定測試打算 設(shè)計測試 實施測試 執(zhí)行測試 對測試進行評估 5. 測試完成準(zhǔn)則 提示： 關(guān)于非嚴(yán)格系統(tǒng)能夠采納“基于測試用例”的準(zhǔn)則： （1）功能性測試用例通過率達到 100； （2）非功能性測試用例通過率達到 95時。 關(guān)于嚴(yán)格系統(tǒng)，應(yīng)當(dāng)補充“基于 BUG 密度”的規(guī)則： 相鄰 n 個 CPU 小時內(nèi)“測試期 BUG 密度”全部低于某個值 m。例如 n 大于

55、10，m 小于等于 1。 最后一次回歸測試二類缺陷數(shù)量為零，用例外特不規(guī)缺陷數(shù)量小于等于 2 個/萬行程序； 測試用例功能點覆蓋率 100%； 6. BUG 治理與改錯打算 提示：依照所采納的 BUG 治理工具確定：（1）BUG 治理流程，（2）BUG 修改流程。 定義 BUG 修改約定，例如：不同級不的 BUG 必須在幾日內(nèi)處理完成。 7. 附錄. 本打算審批意見產(chǎn)品經(jīng)理審批意見： 簽字 日期附件十 系統(tǒng)/用戶測試報告1差不多信息測試依據(jù)例如：參照標(biāo)準(zhǔn)、客戶需求、需求規(guī)格講明書、測試用例等 測試范圍 測試驗收標(biāo)準(zhǔn) 測試環(huán)境描述 測試驅(qū)動程序描述提示：能夠把測試驅(qū)動程序當(dāng)作附件 測試人員 測試

56、時刻 須注明每次回歸測試的時刻 測試工具2. 實況記錄模塊測試用例編號期望結(jié)果測試結(jié)果缺陷密度是否執(zhí)行了回歸測試3. 測試總評價 依照對測試結(jié)果提出一個關(guān)于軟件能力的全面分析，需標(biāo)明遺留的要緊缺陷、局限性和軟件的約束限制等，并提出軟件測試過程中程序中的不足。 依照測試標(biāo)準(zhǔn)及測試結(jié)果，綜合評價軟件的開發(fā)是否已達到預(yù)定目標(biāo)。 4. 缺陷修改記錄 提示：假如采納了缺陷治理工具，能自動產(chǎn)生缺陷報表的話，則無需本表。缺陷名稱缺陷類型嚴(yán)峻程度模塊緣故駐留時刻解決方案 測試人員簽字： 日期：附件十一 試運行打算文件狀態(tài)： 草稿 正在修改 正式公布文件標(biāo)識：ProjectName當(dāng)前版本：X.Y作 者：完成日

57、期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1. 試運行目標(biāo) 提示：講明本次試運行的要緊內(nèi)容與目標(biāo)（必須是能夠驗證的）。 2. 工作條件 提示：講明試運行地點、參加人員、軟硬件設(shè)施、經(jīng)費等要求。 3. 應(yīng)遞交的工作成果工作成果名稱可能完成時刻 試運行報告 報錯趨勢分析報告 4. 進度表 提示：（1）用 Microsoft Project 制作進度表（Gantt Chart）插入此處或者參照此表制作一份進度表。任務(wù)名稱及其描述開始時刻結(jié)束時刻參加人員 任務(wù) 1 任務(wù) 2 5. 可能存在的困難與風(fēng)險 提示：指出可能存在的困難和風(fēng)險，制定應(yīng)急打算以應(yīng)對突發(fā)事件。附錄：本

58、打算審批意見 提示：產(chǎn)品經(jīng)理或者技術(shù)負(fù)責(zé)人依照項目打算以及現(xiàn)實情況（如能夠支配的人力資源），審批該試運行打算。項目經(jīng)理或試運行負(fù)責(zé)人審批意見： 簽字 日期附件十二 數(shù)據(jù)遷移打算1. 數(shù)據(jù)遷移的重要事件和里程碑日期 2. 數(shù)據(jù)遷移前的備份要求 3. 數(shù)據(jù)遷移測試結(jié)果清單 4.轉(zhuǎn)換工作進度表 提示：（1）用 Microsoft Project 制作進度表（Gantt Chart），插入此處或作為附件。（2）或者在此處用表格制作一份進度表，例如：任務(wù)名稱及其描述開始時刻結(jié)束時刻參加人員 任務(wù) 1 任務(wù) 2 5. 轉(zhuǎn)換操作步驟以及問題處理步驟 6數(shù)據(jù)核對打算 7數(shù)據(jù)遷移的需求和實施打算 8應(yīng)急預(yù)案及回

59、退打算 1). 分析引發(fā)轉(zhuǎn)換失敗的潛在緣故 提示：講明轉(zhuǎn)換失敗的幾類緣故，考慮人員、軟硬件設(shè)施、經(jīng)費等因素。 2). 預(yù)防措施 提示：針對轉(zhuǎn)換失敗的幾類緣故，制定預(yù)防措施。 3). 事件處理及回退打算 提示：在突發(fā)事件出現(xiàn)時的應(yīng)對策略，應(yīng)從人員組織、流程制定等方面考慮。 4). 組織機制 提示：建立應(yīng)急處理小組成員，明確職責(zé)到人。應(yīng)急處理人員角色職責(zé)8.培訓(xùn)打算 講明培訓(xùn)內(nèi)容，時刻，地點，培訓(xùn)講師等信息。 9.附錄：本打算審批意見產(chǎn)品經(jīng)理審批意見： 簽字 日期研發(fā)部經(jīng)理審批意見： 簽字 日期業(yè)務(wù)部門審批意見： 簽字 日期附件十三 數(shù)據(jù)遷移報告1. 背景介紹 提示：介紹系統(tǒng)轉(zhuǎn)換的背景情況。 2.

60、 數(shù)據(jù)遷移目標(biāo) 提示：講明本次數(shù)據(jù)遷移的要緊內(nèi)容與目標(biāo)。 3. 數(shù)據(jù)預(yù)備 提示：所預(yù)備進行轉(zhuǎn)換的數(shù)據(jù)情況描述以及數(shù)據(jù)來源部門的審批結(jié)果 4. 數(shù)據(jù)遷移實錄 提示：回憶系統(tǒng)上線各時期工作，大體步驟 5數(shù)據(jù)遷移后數(shù)據(jù)核對過程和結(jié)論 提示：講明本次數(shù)據(jù)遷移后進行數(shù)據(jù)核對的過程以及結(jié)論。包含主文件檢查、轉(zhuǎn)換前后數(shù)據(jù)記錄與余額核對、數(shù)據(jù)映射表、會計科目對比表、機構(gòu)對比表、內(nèi)部基礎(chǔ)數(shù)據(jù)對比表、賬務(wù)報表的核對結(jié)果等。 6. 數(shù)據(jù)異常/差異處理 提示：數(shù)據(jù)遷移過程中，形成的數(shù)據(jù)異常/差錯/數(shù)據(jù)修改所進行的處理過程記錄，以及處理后的結(jié)論。 7. 問題和建議 提示：對數(shù)據(jù)遷移過程的問題進行總結(jié)，提出意見，并就運行