互聯(lián)網(wǎng)事業(yè)部業(yè)務管理辦法

互聯(lián)網(wǎng)事業(yè)部業(yè)務管理辦法智慧民生業(yè)務管理辦法1、 軟件保密管理辦法2、 軟件研發(fā)管理辦法3、 軟件升級管理辦法4、 工業(yè)品招商管理辦法5、 農產(chǎn)品招商管理辦法6、 加盟商加盟管理辦法7、 縣級運營中心管理辦法8、 鄉(xiāng)鎮(zhèn)物流配送中心加盟管理辦法9、 村級信息服務站加盟管理辦法10、 平臺商戶結算管理辦法（事業(yè)部與財務部共同編制）11、 加盟商分成結算管理辦法（事業(yè)部與財務部共同編制）12、 平臺與子公司分成結算管理辦法（事業(yè)部與財務部共同編制）13、 村級信息服務站分成結算管理辦法（事業(yè)部與財務部共同編制）版 本 頁標 題：研發(fā)部保密管理制度文檔編號：版本說明：版本號版本日期作者備注V1.02016.4.10吳訓波創(chuàng)建V1.0審批第一章總則第一條凡研發(fā)部的內部資料和信息均屬研發(fā)部秘密，所有成員均負有保密的責任和義務。為維護公司利益，特制定本制度。第二條本制度適合研發(fā)部全體員工，包括在編、社會招聘和實習期人員。第二章保密內容第三條 研發(fā)部秘密分為兩類：技術秘密、內部管理秘密。第四條技術秘密（一）研發(fā)部為開發(fā)項目購買的各種設計方案、技術資料等文檔。（二）研發(fā)部的發(fā)展戰(zhàn)略、前景規(guī)劃和實施步驟等涉及研發(fā)部技術走向類文檔。（三）研發(fā)部各種產(chǎn)品的開發(fā)計劃、需求分析、調研報告、立項報告等開發(fā)前期類文檔。（四）研發(fā)部各種系統(tǒng)的方案設計、功能說明書、數(shù)據(jù)結構、系統(tǒng)參數(shù)說明、接口規(guī)范、程序設計規(guī)范、系統(tǒng)其它各種規(guī)范和清單、測試方案、測試報告等開發(fā)測試期間形成的各類文檔。（五）研發(fā)部各種系統(tǒng)的集成方案、移植方案、上點試運行方案、版本維護方案、操作和排錯手冊、培訓教材等開發(fā)后期類文檔。（六）合作單位提供的各種技術資料。（七）其它內部技術資料。第五條研發(fā)部內部管理秘密（一）研發(fā)部辦公會議紀要。（二）技術討論會議紀要。第六條以上保密內容，既指以文件、報表、圖紙、協(xié)議及各種資料等形式存在的紙質文檔，又包括以磁盤（硬盤和U盤）、光盤等介質形式保存的電子文檔。第三章保密原則第七條研發(fā)部員工不得采用各種手段了解或獲取不屬自己工作范圍內或未經(jīng)研發(fā)部許可接觸的秘密。未經(jīng)研發(fā)部書面允許，不得擅自向研發(fā)部其他員工和研發(fā)部外其他人員透露、提供、拷貝自己所掌握的研發(fā)部機密資料。第八條未經(jīng)研發(fā)部書面同意，任何員工不得以方便使用或其它任何理由自行復制、拷貝自己所掌握的研發(fā)部機密材料。第九條在開發(fā)過程中形成的正式文檔、圖紙、程序、各種資料、合同協(xié)議及各種成果均要及時上交相關管理部門，并要上交原件。第十條因工作需要使用屬于研發(fā)部機密的有關資料時，要通過文檔管理部門領取，并嚴格履行登記手續(xù)，任何人不得擅自拷貝或向其他員工索取。第十一條研發(fā)部員工所掌握的所有涉及秘密的資料，在到達規(guī)定使用期限或因辭職、辭退離開研發(fā)部時必須向有關文檔管理部門辦理續(xù)借或退還手續(xù)，并負有繼續(xù)保密的責任。第十二條擁有研發(fā)部機密資料的員工，必須認真保管使用資料，不得遺失、轉借，不經(jīng)允許，不得帶出研發(fā)部。版 本 頁標 題：研發(fā)部軟硬件研發(fā)管理制度文檔編號：版本說明：版本號版本日期作者備注V1.02016.4.10吳訓波創(chuàng)建V1.0審批第一章總則第一條為規(guī)范軟硬件研發(fā)的管理工作，特制定本制度。本制度適用于公司軟件及硬件的研發(fā)與管理。第二條 軟硬件開發(fā)遵循項目管理和軟硬件工程的基本原則。項目管理涉及立項管理、項目計劃和監(jiān)控、配置管理、開發(fā)管理和結項管理。軟硬件工程涉及需求管理、系統(tǒng)設計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、用戶接受測試、試運行、系統(tǒng)驗收、系統(tǒng)上線和數(shù)據(jù)遷移。第二章 立項管理第三條 提出項目需求的部門參與公司層面立項，進行立項的技術可行性分析，編寫立項分析報告（附件一），開展前期籌備工作。立項分析報告應明確項目的范圍和邊界。第四條 需求提出部門將立項分析報告提交相關部門會簽后，上交公司總經(jīng)理與董事長進行立項審批，以保證系統(tǒng)項目與公司整體策略相一致。第五條立項分析報告得到批準后，成立項目組，項目組應包括業(yè)務組（由公司需求管理組和相關業(yè)務部門組成）和開發(fā)組。公司研發(fā)部委派一名PM負責監(jiān)督項目的進度，進行項目管理工作，確保開發(fā)能及時完成并能滿足業(yè)務需要。項目組人員的選擇應滿足項目對業(yè)務及技術要求，項目組人員應有足夠的業(yè)務和 IT 技術方面的專業(yè)知識來勝任項目各方面的工作。第三章 需求分析第六條 立項后業(yè)務組對用戶需求進行匯總整理，出具業(yè)務需求說明書（附件二），并確保業(yè)務需求說明書中包含了所有的業(yè)務需求。經(jīng)系統(tǒng)使用部門審批確認，作為業(yè)務需求基線。第七條 業(yè)務組在獲得業(yè)務需求說明書后，提出技術需求和解決方案，并對系統(tǒng)進行定義，出具系統(tǒng)需求規(guī)格說明書（附件三）。系統(tǒng)需求規(guī)格說明書需詳細列出業(yè)務對系統(tǒng)的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關鍵指標(KPI)等），最好是采用原型方式表達。系統(tǒng)需求規(guī)格說明書需要由業(yè)務組提交給相關業(yè)務部門負責人確認。第八條 項目組應對需求變更影響到的文檔及時更新。第四章 項目計劃和監(jiān)控第九條 軟硬件開發(fā)采用項目形式進行管理。項目經(jīng)理負責整個項目的計劃、組織、領導和控制。第十條 需求分析過程中，項目經(jīng)理組織制定詳細的項目計劃書（附件四），包括具體任務描述和項目進度表等。第十一條 在項目的各個階段，業(yè)務組組長和開發(fā)組組長需配合項目經(jīng)理制定階段性項目計劃。業(yè)務組組長和開發(fā)組組長需配合項目經(jīng)理對項目計劃執(zhí)行情況進行監(jiān)控，確保項目按計劃完成。第十二條 項目計劃需要變更時，項目經(jīng)理填寫項目計劃變更說明（附件五），并提交事業(yè)部領導審批，通過審批后，交給業(yè)務組組長和開發(fā)組組長執(zhí)行。第五章 系統(tǒng)設計第十三條 系統(tǒng)設計應分為概要設計和詳細設計，系統(tǒng)設計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。第十四條 在系統(tǒng)設計階段中，用戶或使用部門應充分參與，確保系統(tǒng)設計能滿足系統(tǒng)需求。第十五條 項目組進行設計，出具設計說明書（附件六）和單元測試用例（附件七）。設計說明書中需要定義系統(tǒng)輸入輸出說明和接口設計說明。公司主管領導組織相關人員對概要設計進行評審，出具設計評審報告（附件八）。業(yè)務組組長和開發(fā)組組長應參加此評審并對評審意見簽字確認第十六條 設計評審均以業(yè)務需求說明書和系統(tǒng)需求規(guī)格說明書為依據(jù)，確保系統(tǒng)設計滿足全部需。第十七條 對已確認通過的系統(tǒng)設計進行修改需獲得項目經(jīng)理、業(yè)務組組長和開發(fā)組組長的審批后方可進行。第十八條 對系統(tǒng)設計的修改的文檔須由文檔管理人員進行歸檔管理。第六章 系統(tǒng)實現(xiàn)第十九條 開發(fā)組根據(jù)設計說明書制定系統(tǒng)實現(xiàn)計劃，并提交項目經(jīng)理對計劃可行性進行審批。第二十條 系統(tǒng)實現(xiàn)包括程序編碼、單元測試。第二十一條 開發(fā)組保證開發(fā)、測試和生產(chǎn)環(huán)境獨立，為各環(huán)境建立訪問權限控制機制，并明確項目成員的職責分工。對開發(fā)環(huán)境、測試環(huán)境與生產(chǎn)環(huán)境在物理或邏輯方面應該做到隔離；如果環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應定期檢查網(wǎng)絡設置。項目組對已授權訪問生產(chǎn)環(huán)境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經(jīng)授權的人員才能訪問到生產(chǎn)環(huán)境。第七章 系統(tǒng)測試和用戶測試第二十二條 測試組制定系統(tǒng)測試計劃（附件九），并提交項目經(jīng)理對計劃可行性進行審批。第二十三條 系統(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)測試報告（附件十），測試人員簽字確認測試結果。第二十七條 系統(tǒng)測試通過后，開發(fā)組配合業(yè)務組建立用戶測試環(huán)境，業(yè)務組根據(jù)用戶測試用例進行用戶測試，出具用戶測試報告（附件十），業(yè)務組組長和開發(fā)組組長應在用戶測試報告中簽字確認。第二十八條 項目組完成系統(tǒng)幫助文檔（其中包括用戶操作手冊和安裝維護手冊）。凡涉及應用系統(tǒng)的變更，應對系統(tǒng)幫助文檔及時更新。第八章 試運行第二十九條 系統(tǒng)主要使用部門根據(jù)項目規(guī)模及影響決定試運行策略。第三十條 項目組制定試運行計劃（附件十一），并制定試運行驗收指標，上報公司主管領導審批。試運行計劃中應包含問題應對機制，明確問題溝通渠道和職責分工。第三十一條 項目組聯(lián)合試運行單位或部門進行相關系統(tǒng)部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。用戶培訓的完成度應為實施后評估的指標之一。第三十二條 項目組根據(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)上線的驗收的評估指標之一。第三十三條 數(shù)據(jù)遷移前，應制定詳細的數(shù)據(jù)遷移計劃（附件十二），數(shù)據(jù)遷移計劃中應包含遷移方案、測試方案、數(shù)據(jù)定義，新舊數(shù)據(jù)對照表、遷移時間、回退計劃等信息。數(shù)據(jù)遷移計劃需經(jīng)項目經(jīng)理和主管領導簽字審批。第三十四條 數(shù)據(jù)遷移后，項目組對數(shù)據(jù)遷移的完整性和準確性做出檢查，出具數(shù)據(jù)遷移報告（附件十三），其中包括數(shù)據(jù)來源、轉換前狀態(tài)、轉換后狀態(tài)，數(shù)據(jù)遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗收轉換結果后在該報告上簽字確認。第三十五條 系統(tǒng)轉換和數(shù)據(jù)遷移由試運行單位業(yè)務部門和公司主管領導共同監(jiān)督并進行驗收。第三十六條 系統(tǒng)轉換和數(shù)據(jù)遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位把系統(tǒng)運行情況（系統(tǒng)資源使用，反應速度及其他量化指標等）記錄到系統(tǒng)試運行報告中。必要時，項目組應根據(jù)系統(tǒng)運行情況對應用系統(tǒng)進行優(yōu)化。第三十七條 試運行達到試運行計劃規(guī)定的終止條件時，項目組編寫試運行報告（附件十四）。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。第九章 系統(tǒng)驗收 第三十八條 系統(tǒng)主要使用部門及技術研發(fā)部聯(lián)合組成獨立系統(tǒng)驗收小組，也可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統(tǒng)進行綜合評估。 第三十九條 驗收小組應根據(jù)驗收情況整理形成系統(tǒng)驗收報告（附件十五）提交系統(tǒng)主要使用部門和技術研發(fā)部審閱。 第四十條 系統(tǒng)主要使用部門和信息技術部門負責人根據(jù)系統(tǒng)測試、試運行情況簽署驗收意見。第十節(jié) 系統(tǒng)上線第四十一條 系統(tǒng)上線應遵循穩(wěn)妥、可控、安全的原則。第四十二條 通常情況下，系統(tǒng)上線包含數(shù)據(jù)遷移工作。第四十三條 項目組制定系統(tǒng)上線計劃（附件十六），上報公司主管領導審批。在上線計劃得到批準后才能開始部署上線工作。第四十四條 系統(tǒng)上線計劃內容應包括但不限于： 1、部署方式和資源分配（包括人力資源及服務器資源）； 2、上線工作時間表； 3、上線操作步驟以及問題處理步驟； 4、項目階段性里程碑和成果匯報（項目執(zhí)行狀態(tài)的審閱、進度安排等）； 5、數(shù)據(jù)遷移的需求和實施計劃；6、完整可行的應急預案和“回退”計劃； 7、用戶培訓計劃（包括：培訓計劃、培訓手冊、培訓考核等）； 8、公司下發(fā)的系統(tǒng)標準參數(shù)配置。第四十五條 上線單位在上線初期需加強日常運行狀態(tài)監(jiān)控，出現(xiàn)問題時應及時處理，對重大問題應啟動緊急預案。第四十六條 在完成上線后要填寫系統(tǒng)驗收評估報告（附件十七）。系統(tǒng)驗收評估報告內容包括：數(shù)據(jù)準確性、系統(tǒng)性能及穩(wěn)定性、接口問題、權限問題、業(yè)務操作影響度、問題處理情況、備份、批處理等。第四十七條 上線單位管理層要對系統(tǒng)驗收評估報告進行審批簽字。第四十八條 公司主管領導批準結項后，業(yè)務組和開發(fā)組將整理的文檔提交各自部門統(tǒng)一管理。第十二章 系統(tǒng)交付 第四十九條 在系統(tǒng)驗收通過后，項目組對運營部門或使用單位進行系統(tǒng)維護培訓。 第五十條 項目組提交全部經(jīng)審批的交付資料給 PMO(項目管理辦公室) 存檔。 第五十一條 項目組填寫系統(tǒng)交付申請（附件十八），提交公司技術總監(jiān)審批后，交付運營部門或使用單位。第十三章 軟件版本命名規(guī)范第五十二條 版本命名規(guī)范軟件版本號有四部分組成，第一部分為主版本號，第二部分為次版本號，第三部分為修訂版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有五種，分別為base、alpha、beta、RC、release。如：2.1.1.20160410_betaBase：此版本表示該軟件僅僅是一個假頁面鏈接，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實現(xiàn)，只是作為整體網(wǎng)站的一個基礎架構。Alpha： 軟件的初級版本，表示該軟件在此階段以實現(xiàn)軟件功能為主，通常只在軟件開發(fā)者內部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改，是測試版本。測試人員提交Bug經(jīng)開發(fā)人員修改確認之后，發(fā)布到測試網(wǎng)址讓測試人員測試，此時可將軟件版本標注為alpha版。Beta：該版本相對于Alpha版已經(jīng)有了很大的進步，消除了嚴重錯誤，但還需要經(jīng)過多次測試來進一步消除，此版本主要的修改對象是軟件的UI。修改的的Bug經(jīng)測試人員測試確認后可發(fā)布到外網(wǎng)上，此時可將軟件版本標注為beta版。RC：該版本已經(jīng)相當成熟了，基本上不存在導致錯誤的Bug，與即將發(fā)行的正式版本相差無幾。Release：該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會有一個正式的版本，是最終交付用戶使用的一個版本。該版本有時也稱標準版。第五十三條 版本號修改規(guī)則1、主版本號：當功能模塊有較大的變動，比如增加模塊或是整體架構發(fā)生變化。此版本號由項目研發(fā)部經(jīng)理決定是否修改。2、次版本號：相對于主版本號而言，次版本號的升級對應的只是局部的變動，但該局部的變動造成程序和以前版本不能兼容，或者對該程序以前的協(xié)作關系產(chǎn)生了破壞，或者 是功能上有大的改進或增強。此版本號由項目經(jīng)理決定是否修改。3、修訂版本號：一般是Bug的修復或是一些小的變動或是一些功能的擴充，要經(jīng)常發(fā)布修訂版，修復一個嚴重Bug即可發(fā)布一個修訂版。此版本號由項目經(jīng)理決定是否修改。4、日期版本號：用于記錄修改項目的當前日期，每天對項目的修改都需要更改日期版本號。此版本號由開發(fā)人員決定是否修改。5、希臘字母版本號：此版本號用于標注當前版本的軟件處于哪個開發(fā)階段，當軟件進入到另一個階段時需要修改此版本號。此版本號由項目經(jīng)理決定是否修改。6、主版本號、次版本號及修訂版本號中，上一級版本有變動時，下級要歸零。第五十四條 版本發(fā)布周期1、非緊急情況：首先由測試人員測試并提交Bug，其次開發(fā)人員會盡量在當天修復Bug并在第二天發(fā)布該版本的alpha版，然后由測試人員測試驗證關閉Bug之后在第三天會發(fā)布該版本的beta版。2、緊急情況：如果Bug比較緊急可跳過一般流程，由開發(fā)人員盡快修復Bug，測試確認之后直接發(fā)布該版本的beta版，日期為發(fā)布版本當天的日期。第五十五條 升級發(fā)布流程。按照升級的版本號，由開發(fā)人員、測試人員、項目經(jīng)理及研發(fā)部經(jīng)理填寫軟件升級提交表（附件十九）。附件一 立項分析報告文件狀態(tài)： 草稿 正在修改 正式發(fā)布文件標識：ProjectName當前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1. 項目介紹 1.1. 項目目的 提示：用簡練的語言說明本項目“是什么”，“實現(xiàn)什么目的”。描述簡練且清晰。 1.2. 項目背景 提示：闡述項目背景，重點說明“為什么”會產(chǎn)生本項目。 （ 1 ）公司的短期、長期發(fā)展戰(zhàn)略； （ 2 ）業(yè)務需求及發(fā)展趨勢； （ 3 ）技術狀況及發(fā)展趨勢； （ 4 ）特殊的業(yè)務需求等。 1.3. 項目范圍 提示：根據(jù)對現(xiàn)有需求的了解來確定項目基本范圍，說明本系統(tǒng)“應當包含的內容”和“不包含的內容”。 2. 項目計劃 2.1. 項目團隊 提示：說明項目團隊的角色、知識技能要求、建議人選、人數(shù)、工作時間，如下表所示。角 色知識技能要求建議人選、人數(shù)工作時間項目經(jīng)理需求開發(fā)人員系統(tǒng)設計人員研發(fā)人員測試人員質量保證人員配置管理人員服務與維護人員2.2. 成本估計內容成本（人民幣 萬元）備注人力資源軟硬件資源差旅費會議費接待費2.3. 進度表編號進度名稱預計結束時間備注需求調研項目計劃需求分析概要設計詳細設計研發(fā)及單元測試系統(tǒng)測試用戶驗收測試試運行項目驗收3. 總結 提示：給出清晰的建議結論，便于上級領導決策附件二 業(yè)務需求說明書文件狀態(tài)： 草稿 正在修改 正式發(fā)布文件標識：ProjectName當前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 概述 1.1 業(yè)務調研人員名單 1.2 業(yè)務范圍 此處描寫總體業(yè)務的概要分類。 1.3 業(yè)務目標 從高層或商務利益的角度提出本業(yè)務系統(tǒng)的期望目標，以及評價標準。 1.4 相關文檔 說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括現(xiàn)有規(guī)范、標準、批文、引用到的文件、資料等。 1.5 業(yè)務詞匯表 說明：列出本文檔的所引用的專屬領域詞匯、術語等，以便于業(yè)務需求的提供者和接收者是建立在一致的業(yè)務理解基礎之上的。 2 組織結構及業(yè)務 2.1 業(yè)務相關組織結構、人員組織結構 說明：如果客戶崗位設置復雜可分別設置，業(yè)務組織結構和人員組織結構2.2 組織機構描述 2.3 角色職責 說明：將業(yè)務涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。 2.4 管理綜述【可選】 說明：主要描述該業(yè)務的管理特點和管理模式。 2.5 現(xiàn)有業(yè)務流程清單 【可選】 說明：現(xiàn)有業(yè)務流程需要考慮，很多新的業(yè)務是在已有業(yè)務流程基礎上進行重組的。 流程編號流程名稱責任部門輔助部門3 業(yè)務流程及業(yè)務處理描述 針對每一項具體的目標業(yè)務，描述具體的業(yè)務流程，以及相關業(yè)務的具體描述。 3.1 具體業(yè)務流程（系統(tǒng)名稱+編號） 對于具體業(yè)務流程的命名有規(guī)范，對具體流程進行編號，便于形成需求矩陣，同時形成需求的管理和跟蹤。 3.1.1 業(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)境約束4.2 設計約束 【可選】 說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術、第三方產(chǎn)品等。 4.3 產(chǎn)品應當遵循的標準或規(guī)范 【可選】 說明：闡述本產(chǎn)品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則，違反標準、規(guī)范或業(yè)務規(guī)則的產(chǎn)品通常不太可能被接受。 5 其他 5.1 目前核心問題和困難 5.2 業(yè)務對項目實施的需求和期望 【可選】 5.3 其他未盡事宜附件三 系統(tǒng)需求規(guī)格說明書文件狀態(tài)： 草稿 正在修改 正式發(fā)布文件標識：ProjectName當前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 引言 1.1 目的 例如：規(guī)定系統(tǒng)的邊界和目標，描述系統(tǒng)的功能性需求和非功能性需求。 1.2 讀者對象及閱讀建議 說明：指明本文檔面向的讀者群，及相應的閱讀意見。 1.3 文檔范圍 【可選】 說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。 1.4 參考文檔 說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括計劃任務書、合同、批文、引用到的文件、資料及軟件開發(fā)標準等。 1.5 術語與縮寫解釋 說明：列出本文件中用到的專門術語的定義和縮寫詞的原詞組，并給予解釋，以便于所有讀者達成共識。 2 綜合描述 2.1 系統(tǒng)背景 【可選】 說明：介紹系統(tǒng)的預期效果、歷史原因。2.2 問題說明 【可選】 提供一段說明，總結項目需要解決的問題。可以采用以下格式：問題是對問題進行說明影響問題影響的干系人問題的后果該問題會導致什么后果成功的解決方案應列出成功解決方案的一些主要優(yōu)點2.3 系統(tǒng)范圍 說明：闡述本項目“適用的業(yè)務領域”和“不適用的業(yè)務領域”，本產(chǎn)品“應當包含的內容”和“不包含的內容”。說清楚系統(tǒng)范圍的好處是：（1）有助于判斷什么是需求，什么不是需求；（2）可以將開發(fā)精力集中在產(chǎn)品范圍之內；（3）有助于控制需求的變更。 l l 完整而準確的定義本產(chǎn)品的干系人； l l 明確本產(chǎn)品所影響到的部門和業(yè)務； l l 用圖表或者文字描述產(chǎn)品的范圍，概要的定義產(chǎn)品的功能。 2.4 干系人與用戶說明 【可選】 2.4.1 用戶環(huán)境 【可選】 詳細說明目標用戶的工作環(huán)境。以下是幾項建議： 該任務由多少人來完成？是否總在變化？ 一個任務周期需要多長時間？執(zhí)行每項活動要用多長時間？是否總在變化？ 是否有特殊的環(huán)境約束：移動、戶外、乘機旅行等？ 目前使用的是哪些系統(tǒng)平臺？以后會使用哪些平臺？ 還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？ 在此處可以從業(yè)務模型中摘錄一些內容來概述所涉及的任務和角色等等。 2.4.2 干系人簡要情況 【可選】 通過在下表中填寫各干系人的相關信息來說明系統(tǒng)中的各個干系人，詳盡的簡要情況應包括各種干系人在以下方面的信息：代表誰是此產(chǎn)品的干系人代表？（如在他處已作記錄，則此處為可選。）此處只需填寫姓名。說明對干系人類型的簡要說明。類型介紹干系人的技能特長、技術背景和熟練程度（即權威用戶、業(yè)務用戶、專家用戶、初級用戶等）職責列出干系人對所開發(fā)的系統(tǒng)負有的關鍵職責，即他們作為干系人的利益。使用頻率該干系人使用系統(tǒng)的頻率意見/問題在此處列出會阻礙成功的問題以及任何其他相關信息。2.4.3 關鍵的干系人/用戶需要 列出干系人認為現(xiàn)有解決方案存在的關鍵問題。對于列出的每個問題，需澄清以下要點： 為什么會出現(xiàn)這一問題？ 目前如何解決該問題？ 干系人需要什么樣的解決方案？ 務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法表明，必須解決的問題與干系人或用戶希望解決的問題大有不同。 2.5 目標業(yè)務模型 【可選】 說明：新系統(tǒng)業(yè)務模型描述，如有相應業(yè)務模型材料了，可作為需求規(guī)格說明書的輸入?yún)⒖假Y料。 2.6 功能摘要 總結該產(chǎn)品將提供的主要優(yōu)點和特性，而不必涉及每個功能的細節(jié)。對功能加以組織，使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。 2.7 功能清單及重要程度說明 說明：功能名稱、功能描述、重要程度。 重要程度，以 ABC 三類來表示：A：核心功能；B：輔助功能；C：外圍功能； 級別，按照繼承關系分為：一級，二級，三級； 編號級別重要程度功能名稱功能描述備注2.8 功能與業(yè)務對照關系表 說明：業(yè)務組為主編寫業(yè)務需求，業(yè)務需求提交至開發(fā)組后，由開發(fā)組建立目標系統(tǒng)業(yè)務模型并與業(yè)務組進行確認（本操作可選，也可由開發(fā)組與外協(xié)單位合作建立），目標業(yè)務模型作為系統(tǒng)需求的輸入，由開發(fā)組與外協(xié)單位合作撰寫和評審系統(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ā)工具、核心技術、第三方產(chǎn)品等。 2.9.3 產(chǎn)品應當遵循的標準或規(guī)范 說明：闡述本產(chǎn)品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則，違反標準、規(guī)范或業(yè)務規(guī)則的產(chǎn)品通常不太可能被接受。 3 具體需求 3.1 功能需求 3.1.1 具體功能 3.1.1.1 內容 說明：對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需求。3.2 非功能需求 3.2.1 外部接口 3.2.1.1 用戶接口 說明：提供用戶使用軟件產(chǎn)品時的接口需求。例如，如果系統(tǒng)的用戶通過顯示終端進行操作，就必須指定如下要求： a 對屏幕格式的要求 說明：對界面上的各對象、類型、寬度、取值范圍、數(shù)據(jù)來源、能否為空等屬性進行描述。 b 報表或菜單的頁面打印格式和內容 c 輸入輸出的需求 說明：解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等。對軟件的數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告的描述。 d 程序功能鍵的可用性 說明：快捷鍵定義等。 3.2.1.2 硬件接口 【可選】 說明：要指出軟件產(chǎn)品和系統(tǒng)硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什么樣的設備，如何支撐這些設備，有何約定。 3.2.1.3 軟件接口 【可選】 說明：在此要指定需使用的其他軟件產(chǎn)品（例如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)或其他軟件包），以及同其他應用系統(tǒng)之間的接口。對每一個所需的軟件產(chǎn)品，要提供如下內容：名字、助記符、規(guī)格說明號、版本號、來源。 對于每一個接口，這部分應說明與軟件產(chǎn)品相關的接口軟件的目的，并根據(jù)信息的內容和格式定義接口，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。 【接口定義】 下表是對一些接口的具體描述:接口名稱接口描述填寫接口完成的任務接口類型填寫是輸入接口（inbound）還是輸出接口（outbound）源系統(tǒng)填寫接口輸入方系統(tǒng)或部件目標系統(tǒng)填寫接口輸出方系統(tǒng)或部件廠商提供/客戶化開發(fā)文件類型填寫文件類型；若通過數(shù)據(jù)庫表來交互，請指明數(shù)據(jù)庫及表名文件數(shù)量峰值數(shù)據(jù)量頻度填寫數(shù)據(jù)處理的頻度復雜度批處理/人工填寫接口數(shù)據(jù)的驅動模式是人工（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)的數(shù)據(jù)庫及版本 負責人控制報告【接口配置】 （1）接口基礎信息配置 說明：接口基礎信息的配置項目，描述配置的方式。 （2）接口運行參數(shù)配置 說明：接口運行參數(shù)的配置方式和步驟。 【其他配置可選 】 說明：外圍系統(tǒng)或相關模塊的配置。 3.2.1.4 通信接口【可選】 說明：指定各種通信接口。例如，局部網(wǎng)絡的協(xié)議等等。 3.2.2 其他非功能性需求 說明：下表中的各種需求，可根據(jù)實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細解釋名稱 詳細要求靜態(tài)數(shù)值需求 動態(tài)數(shù)值需求 精度 時間特性要求 可用性 可靠性 可維護性 安全性 可移植性 可擴展性 兼容性 3.2.2.1 靜態(tài)數(shù)值需求 說明：支持的終端數(shù)；支持并行操作的用戶數(shù)。 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í)行特定操作所需的培訓時間，指出典型任務的可評測任務次數(shù)或根據(jù)用戶已知或喜歡的其他系統(tǒng)確定新系統(tǒng)的可用性需求性能 3.2.2.7 可靠性 指出可用時間百分比 ( xx.xx%)、使用小時數(shù)、維護訪問權、降級模式操作等。平均故障間隔時間 (MTBF)。平均修復時間 (MTTR)系統(tǒng)在發(fā)生故障后可以暫停運行的時間。指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。 3.2.3 文檔需求 說明：主要是在線用戶手冊與幫助系統(tǒng)，也包括其他的文檔 3.2.4 第三方產(chǎn)品 【可選】 說明：使用到的第三方產(chǎn)品相關的 使用許可、使用限制、接口標準。 3.3 數(shù)據(jù)字典 說明：把相關的數(shù)據(jù)抽取出來統(tǒng)一維護，在其他章節(jié)如有類似信息描述，則關聯(lián)到數(shù)據(jù)字典的相關部分并加輔助說明，如：引用到的字段等。 4 補充資料 【可選】4.1 待確定的問題列表【可選】 需求標題1 調查方式 調查人 調查對象 時間、地點 需求信息記錄 附件四 項目計劃書文件狀態(tài)： 草稿 正在修改 正式發(fā)布文件標識：ProjectName當前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 文檔介紹 1.1 文檔目的 1.2 文檔范圍 1.3 參考文獻 提示： 列出本文檔的所有參考文獻（可以是非正式出版物），格式如下： 標識符 作者，文獻名稱，出版單位（或歸屬單位），日期 例如： AAA 作者，立項建議書，機構名稱，日期 1.5 術語與縮寫解釋縮寫、術語解 釋 2 項目介紹 2.1 項目范圍 提示： （1）用簡練的語言說明本項目“是什么”，“說明用途”。 （2）說明本項目“應當包含的內容”和“不包含的內容”。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 方法與工具 提示：說明在過程中將采用的方法與工具。例如采用 Rational Rose 進行面向對象分析與設計，采用 Visual SourceSafe 進行配置管理，采用 Microsoft Office 制作文檔。方法與工具用途 Visual SourceSafe配置管理 4 里程碑計劃 序號里程碑名稱開始日期結束日期工作成果備注 5 資源計劃 5.1 人力資源計劃 提示：制定本項目的角色職責表，并為已知的項目成員分配角色（一個人可以兼多個角色）。角色職責人員姓名工作說明高層領導 項目經(jīng)理 需求分析員 系統(tǒng)設計員 程序員 測試員 5.2 軟硬件資源計劃 提示：分析項目開發(fā)、測試、運行所需的軟硬件資源和關鍵計算機資源（會影響軟件產(chǎn)品的性能的 CPU、內存、帶寬等內容），主要內容包括： l 資源級別（分為“關鍵”、“普通”兩種） l 詳細配置 l 獲取方式（如“已經(jīng)存在”、“可以借用”或“需要購買”等）與獲取時間 l 使用說明（如“誰”在“什么”時候使用）軟硬件資源名稱級別詳細配置獲取方式與時間使用說明 關鍵 關鍵 普通 6 文檔交付列表序號交付文檔名稱交付日期備注7 風險管理計劃 提示：以下是各個列標題的解釋。 約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。 風險級別：確定風險的嚴重性、可能性、風險系數(shù) 風險描述：緩解方案或者應急計劃風險編號風險級別風險描述緩解方案應急計劃嚴重性(1-5)可能性(%)風險系數(shù) (嚴重性*可能性)8 溝通計劃甲方代表乙方代表溝通方式溝通頻率/時間期望結果9 附件 l 項目進度計劃附件五 項目計劃變更說明項目名稱申請日期 項目計劃變更申請申請變更的項目計劃輸入名稱，版本，完成日期等信息 變更的內容及其理由 評估計劃變更將對項目造成的影響 項目負責人簽字變更申請的審批意見產(chǎn)品經(jīng)理審批審批意見： 簽字 日期研發(fā)部經(jīng)理審批審批意見： 簽字 日期使用部門意見審批意見： 簽字 日期更改項目計劃變更后的項目計劃輸入名稱，版本，完成日期等信息項目負責人簽字附件六 設計說明書文件狀態(tài)： 草稿 正在修改 正式發(fā)布文件標識：ProjectName當前版本：X.Y作 者：完成日期：Year-Month-Day版本歷史版本/狀態(tài)作 者參與者起止日期備注1 引言 1.1 編寫目的 說明編寫這份詳細設計說明書的目的，指出預期的讀者。 1.2 背景 說明： 待開發(fā)軟件系統(tǒng)的名稱； 本項目的任務提出者、開發(fā)者、用戶和運行該程序系統(tǒng)的應用環(huán)境。 1.3 定義 列出本文件中用到專門術語的定義和外文首字母組詞的原詞組。 1.4 參考資料 列出有關的參考資料，如： 本項目的經(jīng)核準的計劃任務書或合同、上級機關的批文； 屬于本項目的其他已發(fā)表的文件； 本文件中各處引用到的文件資料，包括所要用到的軟件開發(fā)標準。列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠取得這些文件的來源。 2 程序系統(tǒng)的結構 用一系列圖表列出本程序系統(tǒng)內的每個程序（包括每個模塊和子程序）的名稱、標識符和它們之間 的層次結構關系。 3 程序 1（標識符）設計說明 從本章開始，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對一般情況的。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內容往往與它所隸屬的上一層 模塊的對應條目的內容相同，在這種情況下，只要簡單地說明這一點即可。 3.1 程序描述 給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，并且說明本程序的特點（如 是常駐內存還是非常駐？是否子程序？是可重入的還是不可重入的？有無覆蓋要求？是順序處理還是并發(fā)處理等）。 3.2 功能 說明該程序應具有的功能，可采用 IPO 圖（即輸入處理輸出圖）的形式。 3.3 性能 說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。3.4 輸入項 給出對每一個輸入項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效范圍、輸入的方式。數(shù)量和頻度、輸入媒體、輸入數(shù)據(jù)的來源和安全保密條件等等。 3.5 輸出項 給出對每一個輸出項的特性，包括名稱、標識、數(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 注釋設計 說明準備在本程序中安排的注釋，如： 加在模塊首部的注釋； 加在各分枝點處的注釋； 對各變量的功能、范圍、缺省條件等所加的注釋； 對使用的邏輯所加的注釋等等。 3.11 限制條件 說明本程序運行中所受到的限制條件。 3.12 測試計劃 說明對本程序進行單體測試的計劃，包括對測試的技術要求、輸入數(shù)據(jù)、預期結果、進度安排、人員職責、設備條件驅動程序及樁模塊等的規(guī)定。 3.13 尚未解決的問題 說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。 4 程序 2（標識符）設計說明 用類似上述3的方式，說明第個程序乃至第N個程序的設計考慮。附件七 單元測試用例1 測試范圍