軟件開發(fā)的具體流程和管理制度匯編詳解

1、WORD 完美格式軟件開發(fā)管理制度第一節(jié)總則第一條為規(guī)范自有軟件研發(fā)以及外包軟件的管理工作，特制定本制度。本制度適用于公司總公司軟件研發(fā)與管理，分公司參照執(zhí)行。第二條本制度中軟件開發(fā)指新系統(tǒng)開發(fā)和現(xiàn)有系統(tǒng)重大改造。第三條本制度中自行開發(fā)是指主要依賴公司自身的管理、業(yè)務和技術力量進行系統(tǒng)設計、軟件開發(fā)、集成和相關的技術支持工作，一般僅向外購置有關的硬件設備和支撐軟件平臺；合作開發(fā)是公司與專業(yè)IT 公司（合作商）共同協(xié)作完成 IT 應用的項目實施和技術支持工作，一般形式是公司負責提供業(yè)務框架，合作商提供技術框架，雙方組成開發(fā)團隊進行項目實施，IT 系統(tǒng)的日常支持由研發(fā)部和合作商共同承擔，研發(fā)負責內

2、部支持，合作商負責外部支持；外包開發(fā)是指將IT 應用項目的設計、開發(fā)、集成、培訓等任務承包給某家專業(yè)公司（可以是專業(yè)的IT 公司或咨詢公司等） ，由該公司（承包商）負責應用項目的實施。第四條軟件開發(fā)遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監(jiān)控、配置管理、合作開發(fā)管理和結項管理。軟件工程涉及需求管理、系統(tǒng)設計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、用戶接受測試、試運行、系統(tǒng)驗收、系統(tǒng)上線和數(shù)據(jù)遷移。第五條除特別指定，本制度中項目組包括業(yè)務組（營銷部、運維部）、 IT 組（研發(fā)部和合作開發(fā)商） 。第二節(jié)立項管理第六條提出開發(fā)需求的營銷部、運維部等業(yè)務部門參與公司層面立項，研發(fā)部進行立項的技

3、術可行性分析，共同編寫立項分析報告（附件一），開展前期籌備工作。立項分析報告應明確項目的范圍和邊界。.整理分享 .WORD 完美格式第七條應用系統(tǒng)主要使用部門將立項分析報告上交公司進行立項審批，以保證系統(tǒng)項目與公司整體策略相一致。第八條立項分析報告得到批準后，成立項目組（如果是外包開發(fā)，則成立外包商項目組；如果是合作開發(fā)，則與外包商共同成立合作開發(fā)項目組，以下統(tǒng)稱“項目組” ），項目組應包括業(yè)務組（由公司相關業(yè)務部門組成）和IT 組（自行開發(fā)為研發(fā)部；外包開發(fā)為外包商成員；合作開發(fā)為研發(fā)部和外包商成員） 。公司委派一名員工負責監(jiān)督項目的進度，進行項目管理工作，確保開發(fā)能及時完成并能滿足業(yè)務需要

4、。項目組人員的選擇應滿足項目對業(yè)務及技術要求，項目組人員應有足夠的業(yè)務和IT 技術方面的專業(yè)知識來勝任項目各方面的工作。第三節(jié)需求分析第九條立項后業(yè)務組對用戶需求進行匯總整理，出具業(yè)務需求說明書（附件二），并確保業(yè)務需求說明書中包含了所有的業(yè)務需求。業(yè)務需求說明書經(jīng)系統(tǒng)使用單位（用戶）確認，作為業(yè)務需求基線。第十條IT 組在獲得業(yè)務需求說明書后，提出技術需求和解決方案，并對系統(tǒng)進行定義，出具系統(tǒng)需求規(guī)格說明書（附件三）。系統(tǒng)需求規(guī)格說明書需詳細列出業(yè)務對系統(tǒng)的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關鍵指標等）。系統(tǒng)需求規(guī)格說明書需要由業(yè)務組提交給用戶相關業(yè)務流程負責人確認。第十

5、一條當業(yè)務需求發(fā)生變更時，業(yè)務組應提交需求變更申請（附件四）， IT 組組長審批后交給業(yè)務組與用戶確認方可實施。第十二條項目組應對需求變更影響到的文檔及時更新。第四節(jié)項目計劃和監(jiān)控第十三條軟件開發(fā)采用項目形式進行管理。項目經(jīng)理（監(jiān)理）負責整個項目的計劃、組織、領導和控制。第十四條需求分析過程中，項目經(jīng)理（監(jiān)理）組織制定詳細的項目計劃書（附件.整理分享 .WORD 完美格式五），包括具體任務描述和項目進度表等。第十五條在項目的各個階段，業(yè)務組組長和IT 組組長需配合項目經(jīng)理（監(jiān)理）制定階段性項目計劃。業(yè)務組組長和IT 組組長需配合項目經(jīng)理（監(jiān)理）對項目計劃執(zhí)行情況進行監(jiān)控，確保項目按計劃完成。第

6、十六條項目計劃需要變更時，項目經(jīng)理（監(jiān)理）填寫項目計劃變更說明（附件六），并提交公司主管領導審批，通過審批后，交給業(yè)務組組長和IT 組組長執(zhí)行。第五節(jié)系統(tǒng)設計第十七條系統(tǒng)設計應分為概要設計和詳細設計，系統(tǒng)設計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。第十八條在系統(tǒng)設計階段中，用戶應充分參與，確保系統(tǒng)設計能滿足系統(tǒng)需求。第十九條項目組進行詳細設計，出具設計說明書（附件七）和單元測試用例（附件八） 。設計說明書中需要定義系統(tǒng)輸入輸出說明和接口設計說明。公司主管領導組織相關人員對概要設計進行評審，出具設計評審報告（附件九）。業(yè)務組組長和 IT 組組長應參加此評審并對評審意見簽字確

7、認。第二十條設計評審均以業(yè)務需求說明書和系統(tǒng)需求規(guī)格說明書為依據(jù)，確保系統(tǒng)設計滿足全部需求。第二十一條對已確認通過的系統(tǒng)設計進行修改需獲得管理部門、業(yè)務組組長和IT 組組長的審批后方可進行。第二十二條對系統(tǒng)設計的修改的文檔須由文檔管理人員進行歸檔管理。第六節(jié)系統(tǒng)實現(xiàn)第二十三條項目組根據(jù)設計說明書制定系統(tǒng)實現(xiàn)計劃，并提交項目經(jīng)理（監(jiān)理）對計劃可行性進行審批。第二十四條系統(tǒng)實現(xiàn)包括程序編碼、單元測試和集成測試。第二十五條項目組保證開發(fā)、測試和訪問環(huán)境獨立，為各環(huán)境建立訪問權限控制機.整理分享 .WORD 完美格式制，并明確項目成員的職責分工。對開發(fā)環(huán)境、測試環(huán)境與訪問環(huán)境在物理或邏輯方面應該做到隔

8、離；如果環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應定期檢查網(wǎng)絡設置。項目組對已授權訪問環(huán)境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經(jīng)授權的人員才能訪問。第二十六條項目組進行單元測試和集成測試，測試人員簽字確認測試結果。第七節(jié)系統(tǒng)測試和用戶測試第二十七條項目組制定系統(tǒng)/ 用戶測試計劃（附件十），并提交項目經(jīng)理（監(jiān)理）對計劃可行性進行審批。第二十八條系統(tǒng) / 用戶測試計劃必須定義測試標準，并明確各種測試的測試步驟和需要的系統(tǒng)設置要求。第二十九條項目組向數(shù)據(jù)擁有部門申請獲取測試用業(yè)務數(shù)據(jù)的使用權，對獲取的數(shù)據(jù)進行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。第三十條項目組負責測試數(shù)據(jù)準備，

9、測試用數(shù)據(jù)要足夠模擬使用環(huán)境中的實際數(shù)據(jù)。對已評定為敏感信息的數(shù)據(jù)進行敏感性處理和保護。第三十一條IT 組或合作開發(fā)商建立測試環(huán)境進行系統(tǒng)測試。在系統(tǒng)測試中對新系統(tǒng)內部各模塊之間的接口和與其他系統(tǒng)的接口進行充分測試。出具系統(tǒng)測試報告（附件十一），測試人員簽字確認測試結果。第三十二條系統(tǒng)測試通過后，IT 組配合業(yè)務組建立用戶測試環(huán)境，業(yè)務組根據(jù)用戶測試用例進行用戶測試，出具用戶測試報告（附件十一） ，業(yè)務組組長和IT 組組長應在用戶測試報告中簽字確認。第三十三條項目組完成系統(tǒng)幫助文檔（其中包括用戶操作手冊和安裝維護手冊）。凡涉及應用系統(tǒng)的變更，應對系統(tǒng)幫助文檔及時更新。第八節(jié)試運行第三十四條系統(tǒng)

10、主要使用部門根據(jù)項目規(guī)模及影響決定試運行策略。第三十五條項目組制定試運行計劃（附件十二），并制定試運行驗收指標，上報公司主管領導審批。 試運行計劃中應包含問題應對機制，明確問題溝通渠.整理分享 .WORD 完美格式道和職責分工。第三十六條項目組聯(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ù)、設置的轉換工作作為系

11、統(tǒng)上線的驗收的評估指標之一。第三十八條數(shù)據(jù)遷移前，應制定詳細的數(shù)據(jù)遷移計劃（附件十三） ，數(shù)據(jù)遷移計劃中應包含遷移方案、測試方案、數(shù)據(jù)定義，新舊數(shù)據(jù)對照表、遷移時間、回退計劃等信息。數(shù)據(jù)遷移計劃需經(jīng)項目經(jīng)理（監(jiān)理）和主管領導簽字審批。第三十九條數(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ù)遷移驗收通過后，正式啟動

12、試運行。在試運行過程中，試運行單位辦公室把系統(tǒng)運行情況（系統(tǒng)資源使用，反應速度等）記錄到試運行報告中。必要時，項目組應根據(jù)系統(tǒng)運行情況對應用系統(tǒng)進行優(yōu)化。第四十二條試運行達到試運行計劃規(guī)定的終止條件時，項目組編寫試運行報告（附件十五）。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。第九節(jié)系統(tǒng)驗收第四十三條系統(tǒng)主要用戶單位及公司項目組聯(lián)合組成獨立系統(tǒng)驗收小組，也可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統(tǒng)進行綜.整理分享 .WORD 完美格式合評估。第四十四條驗收小組應根據(jù)驗收情況整理形成系統(tǒng)驗收報告（附件十

13、六）提交系統(tǒng)主要使用部門和公司審閱。第四十五條系統(tǒng)主要使用部門和研發(fā)部負責人根據(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、完整可行的應急預

14、案和“回退”計劃；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è)務組和IT 組將整理的文檔提交各自部門統(tǒng)一.整理分享 .WORD 完美格式管理。第十一節(jié)

15、合作開發(fā)管理第五十四條合作開發(fā)商的選擇應遵循公司相關規(guī)定，合作商資質認定參見第三方管理制度。第五十五條合作開發(fā)商必須遵循公司軟件開發(fā)管理制度。第五十六條項目經(jīng)理同合作開發(fā)商明確規(guī)定項目變更的范圍和處理方式，重點關注需求和設計變更。第五十七條項目經(jīng)理負責監(jiān)控合作開發(fā)商的項目管理及軟件開發(fā)活動。合作開發(fā)商應按計劃定期向項目經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，合作開發(fā)商需及時向項目經(jīng)理匯報。第五十八條IT 組組長派專人監(jiān)控合作開發(fā)商的質量保證過程。第五十九條項目組同合作開發(fā)商商定驗收的標準和方法。第六十條以上各要求需要在開發(fā)合同中明確。第十二節(jié)外包開發(fā)管理第六十一條立項申請得到公

16、司主管領導的審批后，選定開發(fā)商，簽訂外包開發(fā)合同。第六十二條項目經(jīng)理負責監(jiān)控外包開發(fā)商的項目管理及軟件開發(fā)活動。外包開發(fā)商應按計劃定期向項目經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，外包開發(fā)商需及時向項目經(jīng)理匯報。第六十三條項目經(jīng)理監(jiān)控外包開發(fā)商的質量保證過程。第六十四條項目組同外包開發(fā)商商定驗收的標準和方法。第六十五條以上各要求需要在開發(fā)合同中明確。第十三節(jié)角色與職責表第六十六條主要角色及其職責如下表所示。企業(yè)在應用時，可以將各個角色映射到企業(yè)原有的崗位上，也可以依據(jù)角色建立新的崗位。一個人可以被賦予多個角色，視具體情況而定。常設角色職責簡述.整理分享 .WORD 完美格式機構

17、過程改進角色項目管理過程角色項 目研發(fā)過程角色機構支撐過程角色（ 1）制定適合于本機構的過程規(guī)范。軟件工程過程組（ 2）在機構范圍內推廣該規(guī)范（如培訓、考核），評估機構（ SEPG）過程能力等。1）監(jiān)督規(guī)范的實施，確保所有項目以及相關部門準照規(guī)范質量保證小組開展工作。（ QAG ）（ 2）分析并解決機構內存在的共性質量問題，協(xié)組SEPG 完善規(guī)范。（ 1）是機構內所有項目的主管，對立項管理和結項管理有最機構領導終決策權。2）監(jiān)督項目經(jīng)理的工作，審批項目經(jīng)理的各種申請。1）向機構領導匯報工作。2）是項目規(guī)劃、項目監(jiān)控、風險管理和需求管理過程域的項目經(jīng)理負責人。（ 3）監(jiān)督項目成員的工作，審批項目

18、成員的各種申請。需求分析員調查、分析并定義需求，撰寫相應的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。系統(tǒng)設計師根據(jù)需求文檔設計軟件系統(tǒng)的體系結構、用戶界面、數(shù)據(jù)庫、模塊等，并撰寫相應的設計文檔。程序員（ 1）根據(jù)系統(tǒng)設計文檔，編寫軟件系統(tǒng)的代碼。（ 2）隨時測試和檢查自己的代碼，及時消除代碼中的缺陷。測試員從事單元測試、集成測試和系統(tǒng)測試，主要工作包括制定測試計劃、設計測試用例、執(zhí)行測試和撰寫測試報告。（ 1）為項目制定配置管理計劃 。配置管理員（ 2）創(chuàng)建并維護配置庫，如分配權限、清除垃圾文件、備份配置庫等。質量保證員（ 1）為項目制定質量保證計劃 。（即 QAG成（

19、2）周期性的開展“過程與產(chǎn)品質量檢查”。員）（ 3）跟蹤質量問題，給出質量改進措施。外包管理員（ 1）挑選最合適的承包商，簽訂外包開發(fā)合同。（ 2）監(jiān)控外包開發(fā)過程，驗收外包開發(fā)成果。采購管理員（ 1）挑選最合適的供應商，簽訂采購合同。（ 2）驗收采購物品。培訓管理員制定機構（或項目）的培訓計劃 ，監(jiān)督該計劃的實施，撰寫培訓評估報告 ?？蛻舴杖藛T為客戶提供與產(chǎn)品相關的服務（如技術咨詢），快速響應客戶的要求，給客戶一個滿意的解答。（ 1）糾錯性維護：及時解決用戶遇到的技術故障和消除產(chǎn)品中的缺陷。產(chǎn)品維護人員2）完善性維護：在資源允許的情況下，不斷改善產(chǎn)品功能與質量。臨時角色職責說明立項建議小組

20、（ 1）開展立項調查、產(chǎn)品構思和可行性分析，撰寫相應文.整理分享 .WORD 完美格式檔。（ 2）申請立項，并在立項評審會議上答辯。立項評審委員會由機構領導、各級經(jīng)理、市場人員、技術專家、財務人員等組成，委員會按少數(shù)服從多數(shù)原則投票決定是否同意立項。對項目的有形資產(chǎn)和無形資產(chǎn)進行清算，對項目進行綜合評結項評審委員會估，總結經(jīng)驗教訓等。結項委員會的人員組成與立項評審委員會的類似。對工作成果進行正式技術評審，盡早地發(fā)現(xiàn)工作成果中的缺技術評審委員會陷，并幫助開發(fā)人員及時消除缺陷。該委員會由項目內外的技術專家組成。配置控制委員會對配置管理各項活動擁有決策權（例如審批計劃，審批變更請求等）。第十四節(jié)附則

21、第六十七條本制度由公司研發(fā)部負責解釋和修訂。第六十八條本制度自發(fā)布之日起開始執(zhí)行。附件一立項分析報告文件狀態(tài)：文件標識： 草稿當前版本： 正式發(fā)布作 者： 正在修改完成日期：版本歷史版本 / 狀態(tài)作者參與者起止日期備注.整理分享 .WORD 完美格式項目介紹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)“應當包含

22、的內容”和“不包含的內容”。項目計劃2.1.項目團隊提示：說明項目團隊的角色、知識技能要求、建議人選、人數(shù)、工作時間，如下表所示。角色知識技能要求建議人選、人數(shù)工作時間項目經(jīng)理需求開發(fā)人員系統(tǒng)設計人員編程人員測試人員質量保證人員配置管理人員服務與維護人員2.2.成本估計內容成本（人民幣）備注.整理分享 .WORD 完美格式人力資源軟硬件資源差旅費會議費接待費2.3.項目時限：根據(jù)用戶要求和公司研發(fā)能力設定計劃研發(fā)完成時間總結提示：給出清晰的建議結論，便于上級領導決策。.整理分享 .WORD 完美格式附件二業(yè)務需求說明書（業(yè)務組編制）文件狀態(tài)：文件標識： 草稿當前版本： 正式發(fā)布作 者： 正在修

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

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

25、.1.1 業(yè)務流程3.1.2 業(yè)務描述說明：描述具體的業(yè)務流程。3.1.3 相關業(yè)務對象說明：業(yè)務對象：業(yè)務流程中涉及的單據(jù)、報表等。業(yè)務對象使用部門對應電子檔案編號.整理分享 .WORD 完美格式3.1.4 業(yè)務規(guī)則及關鍵算法說明：描述業(yè)務環(huán)節(jié)關鍵算法體系。假定和約束說明：列出進行本軟件開發(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)品通常不太可能被接受。

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

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

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

29、哪些平臺？還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？在此處可以從業(yè)務模型中摘錄一些內容來概述所涉及的任務和角色等等。.整理分享 .WORD 完美格式2.4.2 干系人簡檔【可選】通過在下表中填寫各干系人的相關信息來說明系統(tǒng)中的各個干系人，詳盡的簡檔應包括各種干系人在以下方面的信息：代表 誰是此產(chǎn)品的干系人代表？（如在他處已作記錄，則此處為可選。）此處只需填寫姓名。說明 對干系人類型的簡要說明。類型 介紹干系人的技能特長、技術背景和熟練程度（即權威用戶、業(yè)務用戶、專家用戶、初級用戶等）職責 列出干系人對所開發(fā)的系統(tǒng)負有的關鍵職責，即他們作為干系人的利益。 使用頻率 該干系人使

30、用系統(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é)。對功能加以組織，使客

31、戶或初次閱讀該文檔的其他人能夠理解此功能列表。.整理分享 .WORD 完美格式2.7 功能清單及重要程度說明說明：功能名稱、功能描述、重要程度。重要程度，以ABC 三類來表示： A ：核心功能； B：輔助功能； C ：外圍功能；級別，按照繼承關系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注2.8 功能與業(yè)務對照關系表說明：業(yè)務組為主編寫業(yè)務需求，業(yè)務需求提交至信息技術組后，由信息技術組建立目標系統(tǒng)業(yè)務模型并與業(yè)務組進行確認（本操作可選，也可由信息技術組與開發(fā)商合作建立），目標業(yè)務模型作為系統(tǒng)需求的輸入，由信息技術組與開發(fā)商合作撰寫和評審系統(tǒng)需求規(guī)格書明書。業(yè)務需求目標系統(tǒng)業(yè)務活

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

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

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

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

36、 .WORD 完美格式(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ù)庫

37、隸屬系統(tǒng)的數(shù)據(jù)庫及版本負責人控制報告【接口配置】1 ）接口基礎信息配置說明：接口基礎信息的配置項目，描述配置的方式。2 ）接口運行參數(shù)配置說明：接口運行參數(shù)的配置方式和步驟。【其他配置 可選 】.整理分享 .WORD 完美格式說明：外圍系統(tǒng)或相關模塊的配置。 通信接口【可選】說明：指定各種通信接口。例如，局部網(wǎng)絡的協(xié)議等等。3.2.2 其他非功能性需求說明：下表中的各種需求，可根據(jù)實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細解釋。名稱詳細要求靜態(tài)數(shù)值需求動態(tài)數(shù)值需求精度時間特性要求可用性可靠性可維護性安全性可移植性可擴展性兼容性 靜態(tài)數(shù)值需

38、求說明：支持的終端數(shù)；支持并行操作的用戶數(shù)。 動態(tài)數(shù)值需求說明：欲處理的事務和任務的數(shù)量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數(shù)據(jù)總量。 精度說明 :對該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。 時間特性要求.整理分享 .WORD 完美格式說明：對于該軟件的時間特性要求，如對：響應時間；更新處理時間；數(shù)據(jù)的轉換和傳送時間；解題時間等要求。 數(shù)據(jù)管理要求【可選】說明：需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預見的增長對數(shù)據(jù)及其分量的存儲要求做出估算。 可用性指出普通用戶和高級用戶

39、要高效地執(zhí)行特定操作所需的培訓時間，指出典型任務的可評測任務次數(shù)或根據(jù)用戶已知或喜歡的其他系統(tǒng)確定新系統(tǒng)的可用性需求性能 可靠性指出可用時間百分比( 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)一維護，在

40、其他章節(jié)如有類似信息描述，則關聯(lián)到數(shù)據(jù)字典的相關部分并加輔助說明，如：引用到的字段等。補充資料【可選】4.1 待確定的問題列表【可選】.整理分享 .WORD 完美格式需求標題 1調查方式調查人調查對象時間、地點需求信息記錄.整理分享 .WORD 完美格式附件四需求變更申請記錄號：項目：類型：開發(fā)項目項目負責人：變更申請人：申請部門：申請日期：變更內容變更的內容說明變更的內容及變更的理由，及其理由如果變更為業(yè)務組提出，則業(yè)務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；變更的系統(tǒng)及說明變更所涉及的工作產(chǎn)品及其當前版本，版本如果變更為業(yè)務組提出，則業(yè)務組填寫；如果變更為為信息技術組提出，則

41、信息技術組填寫；對業(yè)務及其接分析需求變更引起的業(yè)務變更、業(yè)務接口的變更，口的影響業(yè)務組填寫.整理分享 .WORD 完美格式業(yè)務負責人意同意不同意見：簽字：日期：.整理分享 .WORD 完美格式變更結果變更分析對相關的資源影響分析需求變更對人員、開發(fā)設備和目標設備的影響，僅信息技術組填寫風險分析分析需求變更的風險，僅信息技術組填寫對其他系統(tǒng)或接口分析需求變更引起的系統(tǒng)變更、其他系統(tǒng)或接口的變更，的影響僅信息技術組填寫對開發(fā)工作量、進估計需求變更對開發(fā)工作量和進度的影響，需說明本次變更工作量 /度和成本影響成本是否超過本項目總開發(fā)工作量 / 總成本的 1%？僅信息技術組填寫研發(fā)部審批意見研發(fā)部負責

42、人意同意不同意見：指定驗證人員：簽字：日期：處經(jīng)理意見：同意不同意匯報上級簽字：日期：上級經(jīng)理意見：同意不同意簽字：日期：變更結果變更的系統(tǒng)及版本說明變更后的工作產(chǎn)品簽字：日期：.整理分享 .WORD 完美格式變更驗證完整性是否正確性是否驗證變更結果附加變更是否版本和名稱是否驗證人意見：符合要求不符合要求簽字：日期：.整理分享 .WORD 完美格式附件五項目計劃書文件狀態(tài)：文件標識： 草稿當前版本： 正式發(fā)布作 者： 正在修改完成日期：版本歷史版本 / 狀態(tài)作者參與者起止日期備注文檔介紹1.1文檔目的1.2文檔范圍1.3參考文獻提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：標

43、識符 作者，文獻名稱，出版單位（或歸屬單位），日期例如：AAA作者，立項建議書，機構名稱，日期1.5術語與縮寫解釋縮寫、術語解 釋項目介紹2.1 項目范圍.整理分享 .WORD 完美格式提示：1）用簡練的語言說明本項目“是什么” ，“說明用途” 。2）說明本項目“應當包含的內容”和“不包含的內容”。2.2 項目目標提示：給出“清晰的” 、“可實現(xiàn)”、“可驗證”的目標。2.3 客戶與最終用戶介紹提示：請說明本項目的客戶、用戶及其相關責任人是誰，描述最終用戶的特征。2.4 約束提示：1）請說明在項目開發(fā)過程中應當遵循的標準或規(guī)范2）請說明相關項目可能對本項目造成的影響。3）說明一些假設和依賴。項目

44、過程定義3.1軟件生命周期模型提示：簡要描述、繪制本項目的軟件生命周期模型。3.2項目規(guī)范提示：描述項目需遵循的規(guī)范，例如：編碼規(guī)范。此處可以表現(xiàn)為編碼規(guī)范的鏈接。3.3方法與工具提示：說明在過程中將采用的方法與工具。例如采用Rational Rose 進行面向對象分析與設計，采用Visual SourceSafe 進行配置管理，采用Microsoft Office制作文檔。方法與工具用途Visual SourceSafe配置管理里程碑計劃序號里程碑名稱開始日期結束日期工作成果備注.整理分享 .WORD 完美格式資源計劃5.1 人力資源計劃提示：制定本項目的角色職責表，并為已知的項目成員分配角

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

46、管理方案，例如：風險識別頻度、風險跟蹤頻度等。風險級別：確定風險的嚴重性、可能性、風險系數(shù)風險描述：緩解方案或者應急計劃。風險級別風險編號嚴重性可能性風險系數(shù)風險描述緩解方案應急計劃(1-5)(%)( 嚴重性 * 可能性 )溝通計劃甲方代表乙方代表溝通方式溝通頻率 / 時間期望結果附件項目進度計劃進度表提示：制定項目開發(fā)的進度表（建議給出項目里程碑計劃） 。例如：編號里程碑名稱預計結束時間備注需求調研完成項目計劃完成需求分析完成.整理分享 .WORD 完美格式概要設計完成詳細設計完成實現(xiàn)完成集成測試完成系統(tǒng)測試完成用戶驗收測試完成試運行結束項目驗收.整理分享 .WORD 完美格式附件六項目計劃

47、變更說明項目名稱申請日期項目計劃變更申請申請變更的輸入名稱，版本，完成日期等信息項目計劃變更的內容及其理由評估計劃變更將對項目造成的影響項目負責人簽字變更申請的審批意見審批意見：處經(jīng)理審批簽字，日期審批意見：研發(fā)部負責人審批簽字，日期審批意見：業(yè)務部門意見簽字，日期更改項目計劃變更后的輸入名稱，版本，完成日期等信息項目計劃項目負責人簽字.整理分享 .WORD 完美格式附件七設計說明書文件狀態(tài)：文件標識： 草稿當前版本：正式發(fā)布作者： 正在修改完成日期：版本歷史版本 / 狀態(tài)作者參與者起止日期備注引言1.1 編寫目的說明編寫這份詳細設計說明書的目的，指出預期的讀者。1.2 背景說明：待開發(fā)軟件系

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

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

50、出對每一個輸入項的特性，包括名稱、標識、數(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ù)

51、結構（數(shù)據(jù)庫、數(shù)據(jù)文卷）。3.9 存儲分配.整理分享 .WORD 完美格式根據(jù)需要，說明本程序的存儲分配。3.10 注釋設計說明準備在本程序中安排的注釋，如：加在模塊首部的注釋；加在各分枝點處的注釋；對各變量的功能、范圍、缺省條件等所加的注釋；對使用的邏輯所加的注釋等等。3.11 限制條件說明本程序運行中所受到的限制條件。3.12 測試計劃說明對本程序進行單體測試的計劃，包括對測試的技術要求、輸入數(shù)據(jù)、預期結果、進度安排、人員職責、設備條件驅動程序及樁模塊等的規(guī)定。3.13 尚未解決的問題說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。4 程序 2（標識符）設計說明用類似

52、F 3 的方式，說明第2 個程序乃至第N 個程序的設計考慮。.整理分享 .WORD 完美格式附件八單元測試用例測試范圍說明：本用例測試的功能點。測試環(huán)境環(huán)境 1：硬件環(huán)境：服務器端：客戶端：軟件環(huán)境：服務器端：客戶端：網(wǎng)絡環(huán)境：環(huán)境 2：數(shù)據(jù)準備說明：可以引用適當?shù)母郊?，如EXCEL 文件、文本文件等扁平文件等，這些文件內存放著測試準備的數(shù)據(jù)。測試用例功能 1測試編號功能模塊子模塊編號測試項目模塊功能子模塊功能用例描述描述測試上述功能的測試點依賴描述無環(huán) 境 及 初環(huán)境 1， 填寫用到的各種測試數(shù)據(jù)的名稱始數(shù)據(jù)依賴樣例測試本用例依賴的相關用例名稱序號前置條件測試子項執(zhí)行步驟預期結果實際結果備注

53、.整理分享 .WORD 完美格式測試序號填寫本用說明測試詳細列出對應每一對應每一填寫與測例運行的的基本流 各個用例步的預測個執(zhí)行步試相關聯(lián)前 置 條還是備選角色的操結果；驟的實際的 核 對件。如登流；要求作 的 動結果；點、檢查陸 、 權測試遍歷作。點。限、設備所有的備就緒等；選流；.整理分享 .WORD 完美格式附件九設計評審報告文件狀態(tài)：文件標識：ProjectName- 草稿當前版本：X.Y 正式發(fā)布作 者： 正在修改完成日期：Year-Month-Day版本歷史版本 / 狀態(tài)作者參與者起止日期備注基本信息提示：由評審主持人或評審員填寫此表格。待評審的工作成果工作成果名稱，標識符，版本，

54、作者，時間 技術評審方式（正式評審）或者(走查 )評審時間評審地點參加技術評審的人員類別名字工作單位職稱、職務：主持人評審小組成員.整理分享 .WORD 完美格式記錄員缺陷識別和跟蹤評審問題跟蹤表編 問題問題嚴重提交提交問題解決措施 /問實問備號 描述類型性者日期處理原因說明題際題注負責解關關人決閉閉狀日驗態(tài)期證人123評審結論與意見提示：由主持人或評審員填寫此表格。 工作成果合格， “無需修改”或者“需要輕微修改但不必再審核”。評審結論 工作成果基本合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。意見負責人簽字簽字：.整理分享 .WORD

55、 完美格式日期：附件十系統(tǒng) / 用戶測試計劃文件狀態(tài)：文件標識： 草稿當前版本：正式發(fā)布作者： 正在修改完成日期：版本歷史版本 / 狀態(tài)作者參與者起止日期備注測試范圍與主要內容提示：系統(tǒng)測試小組應當根據(jù)項目的特征確定測試范圍與內容。一般地，系統(tǒng)測試的主要內容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性（security ）測試、安裝與反安裝測試等。測試方法提示：例如黑盒測試和白盒測試。測試環(huán)境與測試輔助工具環(huán)境設備配置名稱/類型備注服務器軟件硬件客戶端軟件硬件.整理分享 .WORD 完美格式網(wǎng)絡工具類型工具開發(fā)商版本測試管理缺陷跟蹤用于功能性測試的工具用于性能測試的工具測試覆蓋監(jiān)測

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

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

58、限性和軟件的約束限制等，并提出軟件測試過程中程序中的不足。根據(jù)測試標準及測試結果，綜合評價軟件的開發(fā)是否已達到預定目標。缺陷修改記錄提示：如果采用了缺陷管理工具，能自動產(chǎn)生缺陷報表的話，則無需本表。缺陷名稱缺陷類型嚴重程度模塊原因駐留時間解決方案.整理分享 .WORD 完美格式測試人員簽字 / 日期：附件十二試運行計劃文件狀態(tài)：文件標識：ProjectName-TestRun-PLAN 草稿當前版本：X.Y 正式發(fā)布作 者： 正在修改完成日期：Year-Month-Day版本歷史版本 / 狀態(tài)作者參與者起止日期備注試運行目標提示：說明本次試運行的主要內容與目標（必須是可以驗證的）。工作條件提示

59、：說明試運行地點、參加人員、軟硬件設施、經(jīng)費等要求。應遞交的工作成果工作成果名稱預計完成時間試運行報告報錯趨勢分析報告4. 進度表提示：（ 1）用 MicrosoftProject制作進度表（ GanttChart ）插入此處或者參照此表制作一份進度表。任務名稱及其描述開始時間結束時間參加人員任務 1.整理分享 .WORD 完美格式任務 2可能存在的困難與風險提示：指出可能存在的困難和風險，制定應急計劃以應對突發(fā)事件。附錄：本計劃審批意見提示：項目經(jīng)理或者技術負責人根據(jù)項目計劃以及現(xiàn)實情況（如可以支配的人力資源），審批該試運行計劃 。項目經(jīng)理或試運行負責人審批意見：簽字日期.整理分享 .WOR

60、D 完美格式附件十三數(shù)據(jù)遷移計劃數(shù)據(jù)遷移的重要事件和里程碑日期數(shù)據(jù)遷移前的備份要求數(shù)據(jù)遷移測試結果清單4.轉換工作進度表提示：（ 1）用 MicrosoftProject制作進度表（ GanttChart ），插入此處或作為附件。（ 2）或者在此處用表格制作一份進度表，例如：任務名稱及其描述開始時間結束時間參加人員任務 1任務 2轉換操作步驟以及問題處理步驟6數(shù)據(jù)核對計劃7數(shù)據(jù)遷移的需求和實施計劃8應急預案及回退計劃1). 分析引發(fā)轉換失敗的潛在原因提示：說明轉換失敗的幾類原因，考慮人員、軟硬件設施、經(jīng)費等因素。2). 預防措施提示：針對轉換失敗的幾類原因，制定預防措施。3). 事件處理及回退