第73頁，共73頁軟件開發的完整步驟目錄1問題定義 41.1用戶調查 41.2編寫《系統目標與范圍說明》 42可行性研究 42.1確定項目的規模和目標 42.2研究正在運行的系統 42.3建立新系統的高層邏輯模型 52.4重新定義問題 52.5導出和評價各種方案 52.6推薦可行方案 52.7編寫《可行性研究報告》 52.8提交審查 53需求分析 63.1制定需求分析計劃 63.2需求獲取 63.3分析和綜合 63.4協商與溝通 63.5編寫《需求規格說明書》 63.6需求驗證 73.7修改完善開發計劃 73.8技術審查和管理復審 74概要設計 74.1制定規范 74.2設想供選擇的方案 74.3推薦最佳方案 84.4功能分解 84.5軟件結構設計 84.6數據設計 84.7制定測試計劃 84.8編寫《概要設計規格說明書》 84.9其他文檔編寫 84.10技術審查和管理復審 95詳細設計 95.1數據結構設計 95.2物理設計 95.3算法設計 95.4界面設計 95.5其他設計 105.6編寫《詳細設計規格說明書》 105.7技術審查和管理復審 106編碼 106.1選擇合適的程序設計語言 106.2制定編碼規范 106.3建立數據庫系統 106.4程序編碼 117測試 117.1測試用例設計 117.2單元測試 117.3集成測試 117.4系統測試 117.5編寫《測試分析報告》 12

1問題定義 問題定義指在項目初期，從客戶或用戶處獲取需求，弄清用戶需要計算機解決的問題根本所在，以及項目所需的經費和資源的文檔，最終使開發人員與客戶就所構建的系統的范圍達成一致意見1.1用戶調查對用戶進行訪談，調查，初步了解項目范圍，需要解決的問題以及項目經費的重要信息。1.2編寫《系統目標與范圍說明》將本階段的結果寫成相應的文檔，即《系統目標與范圍說明》2可行性研究軟件可行性分析最根本的任務是用最少的代價，對以后的行動方針提出建議。如果問題沒有可行的解釋，分析員應該建議停止這項開發工程，以避免時間、資源、人力和金錢的浪費；如果問題值得解，分析員應該推薦一個較好的解決方案，并且為工程制定一個初步的計劃。2.1確定項目的規模和目標分析員對有關人員進行調查訪問，仔細閱讀和分析有關的材料，對項目的規模和目標進行定和確認，清晰地描述項目的一切限制和約束，確保分析員正在解決的問題確實是要解決的問題。2.2研究正在運行的系統收集，研究，分析現有系統的文檔資料和使用手冊，實地考察現有系統，在考察的基礎上，訪問有關人員，確定目標系統必須完成的基本功能。2.3建立新系統的高層邏輯模型根據對現有系統的分析研究，逐步明確了新系統的功能，處理流程以及所受約束，然后使用數據流圖和數據字典，概括的描述高層的數據處理和流動。2.4重新定義問題將新系統的高層邏輯模型與項目的問題及目標進行比較，重新復查問題定義，工程規模和目標。2.5導出和評價各種方案分析員建立了新系統的高層邏輯模型，并進行復查后，要從技術的角度出發，提出高層邏輯模型的不同方案，即導出若干較高層次的物理解法。根據技術可行性，經濟可行性，社會可行性對各種方案進行評估，去掉行不通的解法，得到可行的解法。2.6推薦可行方案根據之前可行性研究的結構，應該決定該項目是否值得去開發。若值得開發，那么可行的解決方案是什么，并且說明該方案可行的原因和理由。草擬開發計劃初步確定工程進度表，開發人員，所需要的資源以及對項目所需要的時間進行估計。2.7編寫《可行性研究報告》將該階段的可行性研究過程的結果寫成相應的文檔，即《可行性研究報告》2.8提交審查用戶和使用部門對《可行性研究報告》進行仔細審查，從而決定該項目是否進行開發，是否接受可行的實現方案。3需求分析需求分析要求開發人員準確理解用戶的需求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉化到相應的形式功能規約（需求規格說明）的過程。需求分析是軟件定義階段中的最后一步，是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。3.1制定需求分析計劃需求分析是一項重要的工作，也是最困難的工作，這個階段可能會耗費相當的時間，人力以及物力。若有明確的計劃進行指導，將使得需求分析工作更加有條不紊的進行。3.2需求獲取需求獲取是一個對準備建立的系統和正在使用的系統進行信息收集并從這些信息中提取用戶需求和系統需求的過程。可以通過用戶面談，實地考察，用例，需求專題討論會等方式發現，獲取需求。3.3分析和綜合分析人員根據導出的需求，進行移植的分析檢查，在分析，綜合中逐步細化軟件功能，劃分成各個子功能，找出各元素之間的聯系，接口特性和設計上的限制。導出軟件的邏輯模型根據分析與綜合的結果，細化可行性研究階段形成的高層邏輯模型，包括數據流圖和數據字典，E-R圖，狀態轉換圖等,以圖文的形式建立起性系統的邏輯模型。3.4協商與溝通在有多個項目相關人員（信息持有者）參與的地方，需求將不可避免的發生沖突，在這個階段需要對需求的優先權進行排序并通過協商發現并解決這些沖突。3.5編寫《需求規格說明書》把雙發共同的理解與分析的結果用規范的方式描述出來，形成《需求規格說明書》，并向下一階段提交，作為今后各項工作的基礎。3.6需求驗證為保障軟件質量，確保軟件開發成，一旦對系統提出一組要求之后，必須嚴格驗證這些需求的正確性，一般從一致性，完整性，現實性，有效性四個方面進行驗證。在這個階段，系統客戶和系統開發人員必須詳細地閱讀需求文檔并檢查其中的錯誤，一旦檢查出任何問題必須記錄下來，接著客戶就需要和開發人員協商如何解決問題。3.7修改完善開發計劃在需求分析階段對待開發的系統有了更進一步的了解，所以能更準確的估計開發成本，進度以及資源要求，因此，對原計劃要進行適當修正。3.8技術審查和管理復審用戶和使用部門對《需求規格說明書》進行仔細的審查，通過后該文檔將作文今后工作的基礎。4概要設計概要設計也成為總體設計，在這個極端需要確定軟件的總體結構，也就是軟件應該由哪些模塊組成，以及模塊與模塊之間的接口關系，軟件系統主要的數據結構，同時還要制定測試計劃，形成概要設計說明書。4.1制定規范盡管每個開發組織都有概要設計規范，但是不同的應有有些特殊性，所以應該針對具體的軟件特點，制定出合適的規范。包括設計文檔的編制標準，編碼的信息形式，與硬件、操作系統的接口規約，命名規則等。4.2設想供選擇的方案在概要設計時，設計人員應該考慮各種可能的實現方案，并且力求從中選出最佳方案。此時設計人員有充分的自由比較不同的實現方案，一旦選出了最佳方案，將能大大提高系統的性價比。4.3推薦最佳方案綜合分析對比各種合理方案的利弊，推薦一個最佳方案，并為最佳方案制定詳細的實現計劃。用戶和有關技術專家應該認真審查，若符合需求并且完全能夠實現，則提請負責人審批。方案被接受后者進入下一階段。4.4功能分解為確定軟件結構，首先需要從現實角度把復雜的功能進一步分解。分析員結合算法描述仔細分析數據流圖中的每個處理，將復雜的功能分解成一系列比較簡單的功能。經過分解細化之后，通常一個模塊只完成一個適當的功能，每個模塊對于大多數程序員都是易于理解的。4.5軟件結構設計設計軟件模塊的結構就是要把軟件模塊組成良好的層次系統，描述各模塊之間的關系。頂層模塊調用它下層模塊，每個下層模塊再調用更下層的模塊，最下層的模塊完成最具體的功能，這樣自頂向下實現一個完整的功能。4.6數據設計數據設計包括數據結構設計，文件設計和數據庫設計。根據需求分析階段獲得的數據要求，確定實現系統所必須的數據，數據之前的關系，存儲數據的實體。4.7制定測試計劃為了保證軟件的可測試性，軟件在一開始就要考慮軟件的測試問題，但是這個階段的測試計劃應該是針對軟件結構的測試和系統測試。4.8編寫《概要設計規格說明書》將本階段的成果編制為相應的文檔，即《概要設計規格說明書》。4.9其他文檔編寫需要提交審查的文檔還包括用戶手冊，測試計劃，實現計劃等，還需要對這些文檔進行編寫。4.10技術審查和管理復審最后應該對總體設計的結果進行嚴格的技術審查，在技術審查通過之后再由客戶從管理角度進行復審。5詳細設計詳細設計階段的根本目的是確定應該怎樣具體地實現所要求的系統，經過這個階段的設計工作，應該得出對目標系統的精確描述，從而在編碼階段可以吧這個描述直接翻譯成用某種程序設計語言書寫的程序。5.1數據結構設計數據結構設計指的是對需求分析，概要設計階段確定的概念性的數據進行確切的定義。5.2物理設計對數據庫進行物理設計，即確定數據庫的物理結構。物理結構主要是指數據庫的存儲記錄格式，存儲記錄安排和存儲方法，這些都依賴于具體使用的數據庫系統。5.3算法設計在總體設計的結構完成之后，結構各個環節的實現是多解的。這就需要用系統設計與分析的技術來描述。可以使用某些圖形、表格、語言等工具將每個模塊處理過程的詳細算法表示出來。5.4界面設計用戶界面的設計現在顯得比較重要，可以采用字符用戶界面設計，圖形用戶界面和多媒體人機界面設計。這就要結合具體的系統來處理。5.5其他設計根據軟件系統的類型，可能還要進行其他設計，例如：代碼設計，輸入/輸出格式設計，人機對話設計，網絡設計等。5.6編寫《詳細設計規格說明書》將本階段的成果編制為相應的文檔，即《詳細設計規格說明書》。5.7技術審查和管理復審最后應該對詳細設計的結果進行嚴格的技術審查，所有處理過程的算法和數據庫的物理結構等都要進行評審。6編碼編碼即把軟件設計的結果翻譯成用某種程序設計語言書寫的程序。作為軟件工程中的一個階段，編碼是對設計的進一步具體化，因此，程序的質量主要取決于軟件設計的質量。但程序設計語言的選擇以及編碼風格也對程序的可靠性，可讀性，可測試性和可維護性產生深遠的影響。6.1選擇合適的程序設計語言編程語言在軟件活動中處于中心地位，選擇一門適合的編程語言十分重要。通常從應用領域，算法與計算復雜性，數據結構的復雜性，效率等幾個方面考慮某一語言是否可選作編碼語言。6.2制定編碼規范良好的代碼風格和編碼規范可以降低程序出錯的幾率，提高程序的易讀性和質量，利于構造大軟件所必須的團隊開發，同時也可以有效降低程序的維護成本。6.3建立數據庫系統根據之前數據與數據流程分析以及數據庫設計的結果建立數據庫結構。6.4程序編碼使用選定的程序設計語言，將詳細設計中的過程性描述翻譯成用該語言編寫的源程序（源代碼）。技術審查和管理復審最后應該對編碼的生成的源程序進行嚴格的技術審查，確保程序運行結果正確有效，滿足要求。7測試測試是為了發現錯誤而執行程序的過程，即根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例，并利用這些測試用例去運行程序，以發現程序錯誤的過程。7.1測試用例設計是以發現錯誤為目的而精心設計的一組測試數據，測試用例＝{輸入數據＋期望結構}。測試用例將用于之后的測試。7.2單元測試單元測試針對程序模塊，進行正確性檢驗的測試。其目的在于發現各模塊內部可能存在的各種差錯，驗證它們是否符合模塊功能說明的需求。單元測試需要從程序內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。7.3集成測試集成測試是組裝軟件的系統技術，即在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統，并在此過程中進行測試，其主要目標是發現與接口有關的問題。確認測試確定所開發的軟件是否符合軟件需求規格說明書的要求。7.4系統測試把新開發的軟件安裝到系統中，檢查它能否與系統的其余部分協調運行。7.5編寫《測試分析報告》將本階段的成果編制為相應的文檔，即《測試分析報告》。軟件開發管理制度總則為規范自有軟件研發以及外包軟件的管理工作，特制定本制度。本制度適用于公司總公司軟件研發與管理，分公司參照執行。本制度中軟件開發指新系統開發和現有系統重大改造。本制度中自行開發是指主要依賴公司自身的管理、業務和技術力量進行系統設計、軟件開發、集成和相關的技術支持工作，一般僅向外購置有關的硬件設備和支撐軟件平臺；合作開發是公司與專業IT公司（合作商）共同協作完成IT應用的項目實施和技術支持工作，一般形式是公司負責提供業務框架，合作商提供技術框架，雙方組成開發團隊進行項目實施，IT系統的日常支持由研發部和合作商共同承擔，研發負責內部支持，合作商負責外部支持；外包開發是指將IT應用項目的設計、開發、集成、培訓等任務承包給某家專業公司（可以是專業的IT公司或咨詢公司等），由該公司（承包商）負責應用項目的實施。軟件開發遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監控、配置管理、合作開發管理和結項管理。軟件工程涉及需求管理、系統設計、系統實現、系統測試、用戶接受測試、試運行、系統驗收、系統上線和數據遷移。除特別指定，本制度中項目組包括業務組（營銷部、運維部）、IT組（研發部和合作開發商）。第二節立項管理提出開發需求的營銷部、運維部等業務部門參與公司層面立項，研發部進行立項的技術可行性分析，共同編寫《立項分析報告》（附件一），開展前期籌備工作。《立項分析報告》應明確項目的范圍和邊界。應用系統主要使用部門將《立項分析報告》上交公司進行立項審批，以保證系統項目與公司整體策略相一致。《立項分析報告》得到批準后，成立項目組（如果是外包開發，則成立外包商項目組；如果是合作開發，則與外包商共同成立合作開發項目組，以下統稱“項目組”），項目組應包括業務組（由公司相關業務部門組成）和IT組（自行開發為研發部；外包開發為外包商成員；合作開發為研發部和外包商成員）。公司委派一名員工負責監督項目的進度，進行項目管理工作，確保開發能及時完成并能滿足業務需要。項目組人員的選擇應滿足項目對業務及技術要求，項目組人員應有足夠的業務和IT技術方面的專業知識來勝任項目各方面的工作。第三節需求分析立項后業務組對用戶需求進行匯總整理，出具《業務需求說明書》（附件二），并確保《業務需求說明書》中包含了所有的業務需求。《業務需求說明書》經系統使用單位（用戶）確認，作為業務需求基線。IT組在獲得《業務需求說明書》后，提出技術需求和解決方案，并對系統進行定義，出具《系統需求規格說明書》（附件三）。《系統需求規格說明書》需詳細列出業務對系統的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關鍵指標等）。《系統需求規格說明書》需要由業務組提交給用戶相關業務流程負責人確認。當業務需求發生變更時，業務組應提交《需求變更申請》（附件四），IT組組長審批后交給業務組與用戶確認方可實施。項目組應對需求變更影響到的文檔及時更新。第四節項目計劃和監控軟件開發采用項目形式進行管理。項目經理（監理）負責整個項目的計劃、組織、領導和控制。需求分析過程中，項目經理（監理）組織制定詳細的《項目計劃書》（附件五），包括具體任務描述和項目進度表等。在項目的各個階段，業務組組長和IT組組長需配合項目經理（監理）制定階段性項目計劃。業務組組長和IT組組長需配合項目經理（監理）對項目計劃執行情況進行監控，確保項目按計劃完成。項目計劃需要變更時，項目經理（監理）填寫《項目計劃變更說明》（附件六），并提交公司主管領導審批，通過審批后，交給業務組組長和IT組組長執行。第五節系統設計系統設計應分為概要設計和詳細設計，系統設計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。在系統設計階段中，用戶應充分參與，確保系統設計能滿足系統需求。項目組進行詳細設計，出具《設計說明書》（附件七）和《單元測試用例》（附件八）。《設計說明書》中需要定義系統輸入輸出說明和接口設計說明。公司主管領導組織相關人員對概要設計進行評審，出具《設計評審報告》（附件九）。業務組組長和IT組組長應參加此評審并對評審意見簽字確認。設計評審均以《業務需求說明書》和《系統需求規格說明書》為依據，確保系統設計滿足全部需求。對已確認通過的系統設計進行修改需獲得管理部門、業務組組長和IT組組長的審批后方可進行。對系統設計的修改的文檔須由文檔管理人員進行歸檔管理。第六節系統實現項目組根據《設計說明書》制定系統實現計劃，并提交項目經理（監理）對計劃可行性進行審批。系統實現包括程序編碼、單元測試和集成測試。項目組保證開發、測試和訪問環境獨立，為各環境建立訪問權限控制機制，并明確項目成員的職責分工。對開發環境、測試環境與訪問環境在物理或邏輯方面應該做到隔離；如果環境的分隔是通過邏輯形式實現的，應定期檢查網絡設置。項目組對已授權訪問環境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經授權的人員才能訪問。項目組進行單元測試和集成測試，測試人員簽字確認測試結果。第七節系統測試和用戶測試項目組制定《系統/用戶測試計劃》（附件十），并提交項目經理（監理）對計劃可行性進行審批。《系統/用戶測試計劃》必須定義測試標準，并明確各種測試的測試步驟和需要的系統設置要求。項目組向數據擁有部門申請獲取測試用業務數據的使用權，對獲取的數據進行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。項目組負責測試數據準備，測試用數據要足夠模擬使用環境中的實際數據。對已評定為敏感信息的數據進行敏感性處理和保護。IT組或合作開發商建立測試環境進行系統測試。在系統測試中對新系統內部各模塊之間的接口和與其他系統的接口進行充分測試。出具《系統測試報告》（附件十一），測試人員簽字確認測試結果。系統測試通過后，IT組配合業務組建立用戶測試環境，業務組根據用戶測試用例進行用戶測試，出具《用戶測試報告》（附件十一），業務組組長和IT組組長應在用戶測試報告中簽字確認。項目組完成系統幫助文檔（其中包括《用戶操作手冊》和《安裝維護手冊》）。凡涉及應用系統的變更，應對系統幫助文檔及時更新。第八節試運行系統主要使用部門根據項目規模及影響決定試運行策略。項目組制定《試運行計劃》（附件十二），并制定試運行驗收指標，上報公司主管領導審批。《試運行計劃》中應包含問題應對機制，明確問題溝通渠道和職責分工。項目組聯合試運行單位進行相關系統部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。用戶培訓的完成度應為實施后評估的指標之一。項目組根據《試運行計劃》進行系統轉換和數據遷移。系統轉換前，檢查系統環境，確保運行環境能滿足新應用系統的需要。系統轉換時必須詳細記錄原系統中的重要參數、設置等系統信息，并填寫試運行報告相關內容。系統參數、設置的轉換工作作為系統上線的驗收的評估指標之一。數據遷移前，應制定詳細的《數據遷移計劃》（附件十三），《數據遷移計劃》中應包含遷移方案、測試方案、數據定義，新舊數據對照表、遷移時間、回退計劃等信息。數據遷移計劃需經項目經理（監理）和主管領導簽字審批。數據遷移后，項目組對數據遷移的完整性和準確性作出檢查，出具《數據遷移報告》（附件十四），其中包括數據來源、轉換前狀態、轉換后狀態，數據遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗收轉換結果后在該報告上簽字確認。系統轉換和數據遷移由試運行單位業務部門和公司主管領導共同監督并進行驗收。系統轉換和數據遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位辦公室把系統運行情況（系統資源使用，反應速度等）記錄到試運行報告中。必要時，項目組應根據系統運行情況對應用系統進行優化。試運行達到試運行計劃規定的終止條件時，項目組編寫《試運行報告》（附件十五）。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。第九節系統驗收系統主要用戶單位及公司項目組聯合組成獨立系統驗收小組，也可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統進行綜合評估。驗收小組應根據驗收情況整理形成《系統驗收報告》（附件十六）提交系統主要使用部門和公司審閱。系統主要使用部門和研發部負責人根據系統測試、試運行情況簽署驗收意見。第十節系統上線系統上線應遵循穩妥、可控、安全的原則。通常情況下，系統上線包含數據遷移工作。項目組制定《系統上線計劃》（附件十七），上報公司主管領導審批。在上線計劃得到批準后才能開始部署上線工作。《系統上線計劃》內容應包括但不限于：1、部署方式和資源分配（包括人力資源及服務器資源）；2、上線工作時間表；3、上線操作步驟以及問題處理步驟；4、項目階段性里程碑和成果匯報（項目執行狀態的審閱、進度安排等）；5、數據遷移的需求和實施計劃；6、完整可行的應急預案和“回退”計劃；7、用戶培訓計劃（包括：培訓計劃、培訓手冊、培訓考核等）；8、總公司下發的系統標準參數配置。上線單位在上線初期需加強日常運行狀態監控，出現問題時應及時處理，對重大問題應啟動緊急預案。在完成上線后要填寫《系統驗收評估報告》（附件十八），上報總公司項目組匯總整理。《系統驗收評估報告》內容包括：數據準確性、系統性能及穩定性、接口問題、權限問題、業務操作影響度、問題處理情況、備份、批處理等。上線單位管理層要對《系統驗收評估報告》進行審批簽字。公司主管領導批準結項后，業務組和IT組將整理的文檔提交各自部門統一管理。第十一節合作開發管理合作開發商的選擇應遵循公司相關規定，合作商資質認定參見第三方管理制度。合作開發商必須遵循公司《軟件開發管理制度》。項目經理同合作開發商明確規定項目變更的范圍和處理方式，重點關注需求和設計變更。項目經理負責監控合作開發商的項目管理及軟件開發活動。合作開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，合作開發商需及時向項目經理匯報。IT組組長派專人監控合作開發商的質量保證過程。項目組同合作開發商商定驗收的標準和方法。以上各要求需要在開發合同中明確。第十二節外包開發管理立項申請得到公司主管領導的審批后，選定開發商，簽訂外包開發合同。項目經理負責監控外包開發商的項目管理及軟件開發活動。外包開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，外包開發商需及時向項目經理匯報。項目經理監控外包開發商的質量保證過程。項目組同外包開發商商定驗收的標準和方法。以上各要求需要在開發合同中明確。第十三節角色與職責表主要角色及其職責如下表所示。企業在應用時，可以將各個角色映射到企業原有的崗位上，也可以依據角色建立新的崗位。一個人可以被賦予多個角色，視具體情況而定。常設角色職責簡述機構過程改進角色軟件工程過程組（SEPG）（1）制定適合于本機構的過程規范。（2）在機構范圍內推廣該規范（如培訓、考核），評估機構過程能力等。質量保證小組（QAG）（1）監督規范的實施，確保所有項目以及相關部門準照規范開展工作。（2）分析并解決機構內存在的共性質量問題，協組SEPG完善規范。項目管理過程角色機構領導（1）是機構內所有項目的主管，對立項管理和結項管理有最終決策權。（2）監督項目經理的工作，審批項目經理的各種申請。項目經理（1）向機構領導匯報工作。（2）是項目規劃、項目監控、風險管理和需求管理過程域的負責人。（3）監督項目成員的工作，審批項目成員的各種申請。項目研發過程角色需求分析員調查、分析并定義需求，撰寫相應的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。系統設計師根據需求文檔設計軟件系統的體系結構、用戶界面、數據庫、模塊等，并撰寫相應的設計文檔。程序員（1）根據系統設計文檔，編寫軟件系統的代碼。（2）隨時測試和檢查自己的代碼，及時消除代碼中的缺陷。測試員從事單元測試、集成測試和系統測試，主要工作包括制定測試計劃、設計測試用例、執行測試和撰寫測試報告。機構支撐過程角色配置管理員（1）為項目制定《配置管理計劃》。（2）創建并維護配置庫，如分配權限、清除垃圾文件、備份配置庫等。質量保證員（即QAG成員）（1）為項目制定《質量保證計劃》。（2）周期性的開展“過程與產品質量檢查”。（3）跟蹤質量問題，給出質量改進措施。外包管理員（1）挑選最合適的承包商，簽訂外包開發合同。（2）監控外包開發過程，驗收外包開發成果。采購管理員（1）挑選最合適的供應商，簽訂采購合同。（2）驗收采購物品。培訓管理員制定機構（或項目）的《培訓計劃》，監督該計劃的實施，撰寫《培訓評估報告》。客戶服務人員為客戶提供與產品相關的服務（如技術咨詢），快速響應客戶的要求，給客戶一個滿意的解答。產品維護人員（1）糾錯性維護：及時解決用戶遇到的技術故障和消除產品中的缺陷。（2）完善性維護：在資源允許的情況下，不斷改善產品功能與質量。臨時角色職責說明立項建議小組（1）開展立項調查、產品構思和可行性分析，撰寫相應文檔。（2）申請立項，并在立項評審會議上答辯。立項評審委員會由機構領導、各級經理、市場人員、技術專家、財務人員等組成，委員會按少數服從多數原則投票決定是否同意立項。結項評審委員會對項目的有形資產和無形資產進行清算，對項目進行綜合評估，總結經驗教訓等。結項委員會的人員組成與立項評審委員會的類似。技術評審委員會對工作成果進行正式技術評審，盡早地發現工作成果中的缺陷，并幫助開發人員及時消除缺陷。該委員會由項目內外的技術專家組成。配置控制委員會對配置管理各項活動擁有決策權（例如審批計劃，審批變更請求等）。第十四節附則本制度由公司研發部負責解釋和修訂。本制度自發布之日起開始執行。立項分析報告文件狀態：[√]草稿[]正式發布[]正在修改文件標識：當前版本：作者：完成日期：版本歷史版本/狀態作者參與者起止日期備注項目介紹項目目的提示：用簡練的語言說明本項目“是什么”，“實現什么目的”。描述簡練且清晰。項目背景提示：闡述項目背景，重點說明“為什么”會產生本項目。（1）公司的短期、長期發展戰略；（2）業務需求及發展趨勢；（3）技術狀況及發展趨勢；（4）特殊的業務需求等。項目范圍提示：根據對現有需求的了解來確定項目基本范圍，說明本系統“應當包含的內容”和“不包含的內容”。項目計劃項目團隊提示：說明項目團隊的角色、知識技能要求、建議人選、人數、工作時間，如下表所示。角色知識技能要求建議人選、人數工作時間項目經理需求開發人員系統設計人員編程人員測試人員質量保證人員配置管理人員服務與維護人員……成本估計內容成本（人民幣）備注人力資源軟硬件資源差旅費會議費接待費…項目時限：根據用戶要求和公司研發能力設定計劃研發完成時間總結提示：給出清晰的建議結論，便于上級領導決策。

業務需求說明書（業務組編制）文件狀態：[√]草稿[]正式發布[]正在修改文件標識：當前版本：作者：完成日期：版本歷史版本/狀態作者參與者起止日期備注1概述1.1業務調研人員名單【可選】序號職能部門姓名主管聯系電話備注1.2業務范圍此處描寫總體業務的概要分類。1.3業務目標從高層或商務利益的角度提出本業務系統的期望目標，以及評價標準。1.4相關文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括現有規范、標準、批文、引用到的文件、資料等。1.5業務詞匯表說明：列出本文檔的所引用的專屬領域詞匯、術語等，以便于業務需求的提供者和接收者是建立在一致的業務理解基礎之上的。2組織結構及業務2.1業務相關組織結構、人員組織結構說明：如果客戶崗位設置復雜可分別設置，業務組織結構和人員組織結構2.2組織機構描述2.3角色職責說明：將業務涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。2.4管理綜述【可選】說明：主要描述該業務的管理特點和管理模式。例如：2.5現有業務流程清單【可選】說明：現有業務流程需要考慮，很多新的業務是在已有業務流程基礎上進行重組的。流程編號流程名稱責任部門輔助部門3業務流程及業務處理描述說明：針對每一項具體的目標業務，描述具體的業務流程，以及相關業務的具體描述。3.1具體業務流程（系統名稱+編號）對于具體業務流程的命名有規范，對具體流程進行編號，便于形成需求矩陣，同時形成需求的管理和跟蹤。3.1.1業務流程3.1.2業務描述說明：描述具體的業務流程。3.1.3相關業務對象說明：業務對象：業務流程中涉及的單據、報表等。業務對象使用部門對應電子檔案編號3.1.4業務規則及關鍵算法說明：描述業務環節關鍵算法體系。4假定和約束說明：列出進行本軟件開發工作的假定和約束，例如開發期限等。4.1運行環境約束4.2設計約束【可選】說明：開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、第三方產品等。4.3產品應當遵循的標準或規范【可選】說明：闡述本產品應當遵循什么標準、規范或業務規則，違反標準、規范或業務規則的產品通常不太可能被接受。5其他5.1目前核心問題和困難5.2業務對項目實施的需求和期望【可選】5.3其他未盡事宜

系統需求規格說明書（IT組編制）文件狀態：[√]草稿[]正式發布[]正在修改文件標識：當前版本：作者：完成日期：版本歷史版本/狀態作者參與者起止日期備注1引言1.1目的例如：規定系統的邊界和目標，描述系統的功能性需求和非功能性需求。1.2讀者對象及閱讀建議說明：指明本文檔面向的讀者群，及相應的閱讀意見。1.3文檔范圍【可選】說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統原型，系統測試用例等文檔。1.4參考文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括計劃任務書、合同、批文、引用到的文件、資料及軟件開發標準等。1.5術語與縮寫解釋說明：列出本文件中用到的專門術語的定義和縮寫詞的原詞組，并給予解釋，以便于所有讀者達成共識。2綜合描述2.1系統背景【可選】說明：介紹系統的預期效果、歷史原因。2.2問題說明【可選】提供一段說明，總結此項目需要解決的問題。可以采用以下格式：問題是[對問題進行說明]影響[問題影響的干系人]問題的后果[該問題會導致什么后果]成功的解決方案[應列出成功解決方案的一些主要優點]2.3系統范圍說明：闡述本項目“適用的業務領域”和“不適用的業務領域”，本產品“應當包含的內容”和“不包含的內容”。說清楚系統范圍的好處是：（1）有助于判斷什么是需求，什么不是需求；（2）可以將開發精力集中在產品范圍之內；（3）有助于控制需求的變更。完整而準確的定義本產品的干系人；明確本產品所影響到的部門和業務；用圖表或者文字描述產品的范圍，概要的定義產品的功能。2.4干系人與用戶說明【可選】2.4.1用戶環境【可選】詳細說明目標用戶的工作環境。以下是幾項建議：該任務由多少人來完成？是否總在變化？一個任務周期需要多長時間？執行每項活動要用多長時間？是否總在變化？是否有特殊的環境約束：移動、戶外、乘機旅行等？目前使用的是哪些系統平臺？以后會使用哪些平臺？還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？在此處可以從業務模型中摘錄一些內容來概述所涉及的任務和角色等等。2.4.2干系人簡檔【可選】通過在下表中填寫各干系人的相關信息來說明系統中的各個干系人，詳盡的簡檔應包括各種干系人在以下方面的信息：代表[誰是此產品的干系人代表？（如在他處已作記錄，則此處為可選。）此處只需填寫姓名。]說明[對干系人類型的簡要說明。]類型[介紹干系人的技能特長、技術背景和熟練程度（即權威用戶、業務用戶、專家用戶、初級用戶等）]職責[列出干系人對所開發的系統負有的關鍵職責，即他們作為干系人的利益。]使用頻率[該干系人使用系統的頻率]意見/問題[在此處列出會阻礙成功的問題以及任何其他相關信息。]2.4.3關鍵的干系人/用戶需要列出干系人認為現有解決方案存在的關鍵問題。對于列出的每個問題，需澄清以下要點：? 為什么會出現這一問題？? 目前如何解決該問題？? 干系人需要什么樣的解決方案？務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法表明，必須解決的問題與干系人或用戶希望解決的問題大有不同。2.5目標業務模型【可選】說明：新系統業務模型描述，如有相應業務模型材料了，可作為需求規格說明書的輸入參考資料。2.6功能摘要總結該產品將提供的主要優點和特性，而不必涉及每個功能的細節。對功能加以組織，使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。2.7功能清單及重要程度說明說明：功能名稱、功能描述、重要程度。重要程度，以ABC三類來表示：A：核心功能；B：輔助功能；C：外圍功能；級別，按照繼承關系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注2.8功能與業務對照關系表說明：業務組為主編寫業務需求，業務需求提交至信息技術組后，由信息技術組建立目標系統業務模型并與業務組進行確認（本操作可選，也可由信息技術組與開發商合作建立），目標業務模型作為系統需求的輸入，由信息技術組與開發商合作撰寫和評審《系統需求規格書明書》。業務需求目標系統業務活動（可選）功能名稱2.9假定和約束說明：列出進行本軟件開發工作的假定和約束，例如：開發語言、開發期限等。格式限制說明：本項將指定由現有的標準或規則派生的要求。例如：報表格式；數據命名；財務處理；審計追蹤，等等。硬件限制說明：本項包括在各種硬件約束下運行的軟件要求，例如，應該包括：硬件配置的特點（接口數，指令系統等）；內存儲器和輔助存儲器的容量。2.9.1運行環境約束說明：硬件設備、支持軟件、接口、控制等方面的約束名稱詳細要求2.9.2設計約束【可選】說明：開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、第三方產品等。2.9.3產品應當遵循的標準或規范說明：闡述本產品應當遵循什么標準、規范或業務規則，違反標準、規范或業務規則的產品通常不太可能被接受。3具體需求3.1功能需求3.1.1具體功能3.1.1.1內容說明：對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需求。3.2非功能需求3.2.1外部接口3.2.1.1用戶接口說明：提供用戶使用軟件產品時的接口需求。例如，如果系統的用戶通過顯示終端進行操作，就必須指定如下要求：a 對屏幕格式的要求說明：對界面上的各對象、類型、寬度、取值范圍、數據來源、能否為空等屬性進行描述。b 報表或菜單的頁面打印格式和內容c 輸入輸出的需求說明：解釋各輸入輸出數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對軟件的數據輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。d 程序功能鍵的可用性說明：快捷鍵定義等。3.2.1.2硬件接口【可選】說明：要指出軟件產品和系統硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什么樣的設備，如何支撐這些設備，有何約定。3.2.1.3軟件接口【可選】說明：在此要指定需使用的其他軟件產品（例如，數據管理系統、操作系統或數學軟件包），以及同其他應用系統之間的接口。對每一個所需的軟件產品，要提供如下內容：名字、助記符、規格說明號、版本號、來源。對于每一個接口，這部分應說明與軟件產品相關的接口軟件的目的，并根據信息的內容和格式定義接口，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。【接口定義】下表是對一些接口的具體描述:接口名稱接口描述填寫接口完成的任務接口類型填寫是輸入接口（inbound）還是輸出接口（outbound）源系統填寫接口輸入方系統或部件目標系統填寫接口輸出方系統或部件廠商提供/客戶化開發文件類型填寫文件類型；若通過數據庫表來交互，請指明數據庫及表名文件數量峰值數據量頻度填寫數據處理的頻度復雜度批處理/人工填寫接口數據的驅動模式是人工（manual）還是自動(automatic)，還是都支持接口類型填寫是實時接口還是批量接口等【其他系統詳細信息】說明：列出所有與接口交互的外圍系統的詳細信息。包括輸入、輸出系統等系統填寫與接口交互的系統名稱系統類型填寫是接口的數據源系統(source)還是目標系統(object)數據庫填寫交互系統使用的數據庫及版本軟件填寫交互系統的軟件名稱架構類型交互系統的架構類型是B/S還是C/S。位置填寫該軟件在交互軟件體系中所出的位置技術支持填寫交互系統的開發商和支持商功能支持填寫具體的支持商或技術團隊數據歸屬【接口隸屬系統的詳細信息[可選]】系統填寫接口隸屬系統的名稱模塊隸屬于具體的模塊名稱數據庫隸屬系統的數據庫及版本負責人控制報告【接口配置】（1）接口基礎信息配置說明：接口基礎信息的配置項目，描述配置的方式。（2）接口運行參數配置說明：接口運行參數的配置方式和步驟。【其他配置[可選]】說明：外圍系統或相關模塊的配置。3.2.1.4通信接口【可選】說明：指定各種通信接口。例如，局部網絡的協議等等。3.2.2其他非功能性需求說明：下表中的各種需求，可根據實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細解釋。名稱詳細要求靜態數值需求動態數值需求精度時間特性要求可用性可靠性可維護性安全性可移植性可擴展性兼容性…3.2.2.1靜態數值需求說明：支持的終端數；支持并行操作的用戶數。3.2.2.2動態數值需求說明：欲處理的事務和任務的數量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數據總量。3.2.2.3精度說明:對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。3.2.2.4時間特性要求說明：對于該軟件的時間特性要求，如對：a．響應時間；b．更新處理時間；c．數據的轉換和傳送時間；d．解題時間等要求。3.2.2.5數據管理要求【可選】說明：需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求做出估算。3.2.2.6可用性指出普通用戶和高級用戶要高效地執行特定操作所需的培訓時間，指出典型任務的可評測任務次數或根據用戶已知或喜歡的其他系統確定新系統的可用性需求性能3.2.2.7可靠性指出可用時間百分比(xx.xx%)、使用小時數、維護訪問權、降級模式操作等。平均故障間隔時間(MTBF)。平均修復時間(MTTR)—系統在發生故障后可以暫停運行的時間。指出系統輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。3.2.3文檔需求說明：主要是在線用戶手冊與幫助系統，也包括其他的文檔3.2.4第三方產品【可選】說明：使用到的第三方產品相關的使用許可、使用限制、接口標準。3.3數據字典說明：把相關的數據抽取出來統一維護，在其他章節如有類似信息描述，則關聯到數據字典的相關部分并加輔助說明，如：引用到的字段等。4補充資料【可選】4.1待確定的問題列表【可選】需求標題1調查方式調查人調查對象時間、地點需求信息記錄

需求變更申請記錄號：項目：類型：開發項目項目負責人：變更申請人：申請部門：申請日期：變更內容變更的內容及其理由說明變更的內容及變更的理由，如果變更為業務組提出，則業務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；變更的系統及版本說明變更所涉及的工作產品及其當前版本，如果變更為業務組提出，則業務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；對業務及其接口的影響分析需求變更引起的業務變更、業務接口的變更，業務組填寫業務負責人意見：同意不同意簽字：日期：

變更結果變更分析對相關的資源影響分析需求變更對人員、開發設備和目標設備的影響，僅信息技術組填寫風險分析分析需求變更的風險，僅信息技術組填寫對其他系統或接口的影響分析需求變更引起的系統變更、其他系統或接口的變更，僅信息技術組填寫對開發工作量、進度和成本影響估計需求變更對開發工作量和進度的影響，需說明本次變更工作量/成本是否超過本項目總開發工作量/總成本的1%？僅信息技術組填寫研發部審批意見研發部負責人意見：同意不同意指定驗證人員：簽字：日期：處經理意見：同意不同意匯報上級簽字：日期：上級經理意見：同意不同意簽字：日期：變更結果變更的系統及版本說明變更后的工作產品簽字：日期：變更驗證驗證變更結果完整性是否正確性是否附加變更是否版本和名稱是否驗證人意見：符合要求不符合要求簽字：日期：

項目計劃書文件狀態：[√]草稿[]正式發布[]正在修改文件標識：當前版本：作者：完成日期：版本歷史版本/狀態作者參與者起止日期備注1文檔介紹1.1文檔目的1.2文檔范圍1.3參考文獻提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：[標識符]作者，文獻名稱，出版單位（或歸屬單位），日期例如：[AAA]作者，《立項建議書》，機構名稱，日期1.5術語與縮寫解釋縮寫、術語解釋2項目介紹2.1項目范圍提示：（1）用簡練的語言說明本項目“是什么”，“說明用途”。（2）說明本項目“應當包含的內容”和“不包含的內容”。2.2項目目標提示：給出“清晰的”、“可實現”、“可驗證”的目標。2.3客戶與最終用戶介紹提示：請說明本項目的客戶、用戶及其相關責任人是誰，描述最終用戶的特征。2.4約束提示：（1）請說明在項目開發過程中應當遵循的標準或規范（2）請說明相關項目可能對本項目造成的影響。（3）說明一些假設和依賴。3項目過程定義3.1軟件生命周期模型提示：簡要描述、繪制本項目的軟件生命周期模型。3.2項目規范提示：描述項目需遵循的規范，例如：編碼規范。此處可以表現為編碼規范的鏈接。3.3方法與工具提示：說明在過程中將采用的方法與工具。例如采用RationalRose進行面向對象分析與設計，采用VisualSourceSafe進行配置管理，采用MicrosoftOffice制作文檔。方法與工具用途VisualSourceSafe配置管理…4里程碑計劃序號里程碑名稱開始日期結束日期工作成果備注5資源計劃5.1人力資源計劃提示：制定本項目的角色職責表，并為已知的項目成員分配角色（一個人可以兼多個角色）。角色職責人員姓名工作說明高層領導項目經理需求分析員系統設計員程序員測試員…5.2軟硬件資源計劃提示：分析項目開發、測試、運行所需的軟硬件資源和關鍵計算機資源（會影響軟件產品的性能的CPU、內存、帶寬等內容），主要內容包括：資源級別（分為“關鍵”、“普通”兩種）詳細配置獲取方式（如“已經存在”、“可以借用”或“需要購買”等）與獲取時間使用說明（如“誰”在“什么”時候使用）軟硬件資源名稱級別詳細配置獲取方式與時間使用說明關鍵關鍵普通…6文檔交付列表序號交付文檔名稱交付日期備注7風險管理計劃提示：以下是各個列標題的解釋。約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。風險級別：確定風險的嚴重性、可能性、風險系數風險描述：緩解方案或者應急計劃。風險編號風險級別風險描述緩解方案應急計劃嚴重性(1-5)可能性(%)風險系數(嚴重性*可能性)8溝通計劃甲方代表乙方代表溝通方式溝通頻率/時間期望結果9附件項目進度計劃進度表提示：制定項目開發的進度表（建議給出項目里程碑計劃）。例如：編號里程碑名稱預計結束時間備注需求調研完成項目計劃完成需求分析完成概要設計完成詳細設計完成實現完成集成測試完成系統測試完成用戶驗收測試完成試運行結束項目驗收

項目計劃變更說明項目名稱申請日期項目計劃變更申請申請變更的《項目計劃》輸入名稱，版本，完成日期等信息變更的內容及其理由評估計劃變更將對項目造成的影響項目負責人簽字變更申請的審批意見處經理審批審批意見：簽字，日期研發部負責人審批審批意見：簽字，日期業務部門意見審批意見：簽字，日期更改項目計劃變更后的《項目計劃》輸入名稱，版本，完成日期等信息項目負責人簽字

設計說明書文件狀態：[√]草稿[]正式發布[]正在修改文件標識：當前版本：作者：完成日期：版本歷史版本/狀態作者參與者起止日期備注1引言1.1編寫目的說明編寫這份詳細設計說明書的目的，指出預期的讀者。1.2背景說明：待開發軟件系統的名稱；本項目的任務提出者、開發者、用戶和運行該程序系統的計算中心。1.3定義列出本文件中用到專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出有關的參考資料，如：本項目的經核準的計劃任務書或合同、上級機關的批文；屬于本項目的其他已發表的文件；本文件中各處引用到的文件資料，包括所要用到的軟件開發標準。列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠取得這些文件的來源。2程序系統的結構用一系列圖表列出本程序系統內的每個程序（包括每個模塊和子程序）的名稱、標識符和它們之間的層次結構關系。3程序1（標識符）設計說明從本章開始，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對一般情況的。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內容往往與它所隸屬的上一層模塊的對應條目的內容相同，在這種情況下，只要簡單地說明這一點即可。3.1程序描述給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，并且，還要說明本程序的特點（如是常駐內存還是非常駐？是否子程序？是可重人的還是不可重人的？有無覆蓋要求？是順序處理還是并發處理等）。3.2功能說明該程序應具有的功能，可采用IPO圖（即輸入一處理一輸出圖）的形式。3.3性能說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。3.4輸人項給出對每一個輸入項的特性，包括名稱、標識、數據的類型和格式、數據值的有效范圍、輸入的方式。數量和頻度、輸入媒體、輸入數據的來源和安全保密條件等等。3.5輸出項給出對每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效范圍，輸出的形式、數量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。3.6算法詳細說明本程序所選用的算法，具體的計算公式和計算步驟。3.7流程邏輯用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。3.8接口用圖的形式說明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序，說明參數賦值和調用方式，說明與本程序相直接關聯的數據結構（數據庫、數據文卷）。3.9存儲分配根據需要，說明本程序的存儲分配。3.10注釋設計說明準備在本程序中安排的注釋，如：加在模塊首部的注釋；加在各分枝點處的注釋；對各變量的功能、范圍、缺省條件等所加的注釋；對使用的邏輯所加的注釋等等。3.11限制條件說明本程序運行中所受到的限制條件。3.12測試計劃說明對本程序進行單體測試的計劃，包括對測試的技術要求、輸入數據、預期結果、進度安排、人員職責、設備條件驅動程序及樁模塊等的規定。3.13尚未解決的問題說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。4程序2（標識符）設計說明用類似F．3的方式，說明第2個程序乃至第N個程序的設計考慮。

單元測試用例1測試范圍說明：本用例測試的功能點。2測試環境環境1：硬件環境：服務器端：客戶端：軟件環境：服務器端：客戶端：網絡環境：環境2：3數據準備說明：可以引用適當的附件，如EXCEL文件、文本文件等扁平文件等，這些文件內存放著測試準備的數據。測試用例功能1測試編號功能模塊－子模塊－編號測試項目模塊功能－子模塊功能用例描述描述測試上述功能的測試點依賴描述無環境及初始數據環境1，填寫用到的各種測試數據的名稱依賴樣例測試本用例依賴的相關用例名稱序號前置條件測試子項執行步驟預期結果實際結果備注測試序號填寫本用例運行的前置條件。如登陸、權限、設備就緒等；說明測試的基本流還是備選流；要求測試遍歷所有的備選流；詳細列出各個用例角色的操作的動作。對應每一步的預測結果；對應每一個執行步驟的實際結果；填寫與測試相關聯的核對點、檢查點。

設計評審報告文件狀態：[√]草稿[]正式發布[]正在修改文件標識：ProjectName-當前版本：X.Y作者：完成日期：Year-Month-Day版本歷史版本/狀態作者參與者起止日期備注基本信息提示：由評審主持人或評審員填寫此表格。待評審的工作成果工作成果名稱，標識符，版本，作者，時間…技術評審方式（正式評審）或者(走查)評審時間評審地點參加技術評審的人員類別名字工作單位職稱、職務：主持人評審小組成員記錄員缺陷識別和跟蹤評審問題跟蹤表編號問題描述問題類型嚴重性提交者提交日期問題處理負責人解決措施/原因說明問題解決狀態實際關閉日期問題關閉驗證人備注123評審結論與意見提示：由主持人或評審員填寫此表格。評審結論[]工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。[√]工作成果基本合格，需要作少量的修改，之后通過審核即可。[]工作成果不合格，需要作比較大的修改，之后必須重新對其評審。意見負責人簽字簽字：日期：系統/用戶測試計劃文件狀態：[√]草稿[]正式發布[]正在修改文件標識：當前版本：作者：完成日期：版本歷史版本/狀態作者參與者起止日期備注1.測試范圍與主要內容提示：系統測試小組應當根據項目的特征確定測試范圍與內容。一般地，系統測試的主要內容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性（security）測試、安裝與反安裝測試等。2.測試方法提示：例如黑盒測試和白盒測試。3.測試環境與測試輔助工具環境設備配置名稱/類型備注服務器軟件硬件客戶端軟件硬件網絡工具類型工具開發商版本測試管理缺陷跟蹤用于功能性測試的工具用于性能測試的工具測試覆蓋監測器或評測器4.測試進度計劃任務人員任務開始日期結束日期制定測試計劃設計測試實施測試執行測試對測試進行評估5.測試完成準則提示：對于非嚴格系統可以采用“基于測試用例”的準則：（1）功能性測試用例通過率達到100％；（2）非功能性測試用例通過率達到95％時。對于嚴格系統，應當補充“基于BUG密度”的規則：相鄰n個CPU小時內“測試期BUG密度”全部低于某個值m。例如n大于10，m小于等于1。最后一次回歸測試二類缺陷數量為零，用例外非常規缺陷數量小于等于2個/萬行程序；測試用例功能點覆蓋率100%；6.BUG管理與改錯計劃提示：根據所采用的BUG管理工具確定：（1）BUG管理流程，（2）BUG修改流程。定義BUG修改約定，例如：不同級別的BUG必須在幾日內處理完成。7.附錄.本計劃審批意見項目經理審批意見：簽字日期

系統/用戶測試報告1.基本信息測試依據例如：參照標準、客戶需求、需求規格說明書、測試用例等測試范圍測試驗收標準測試環境描述測試驅動程序描述提示：可以把測試驅動程序當作附件測試人員測試時間須注明每次回歸測試的時間測試工具2.實況記錄模塊測試用例編號期望結果測試結果缺陷密度是否執行了回歸測試3.測試總評價根據對測試結果提出一個關于軟件能力的全面分析，需標明遺留的主要缺陷、局限性和軟件的約束限制等，并提出軟件測試過程中程序中的不足。根據測試標準及測試結果，綜合評價軟件的開發是否已達到預定目標。4.缺陷修改記錄提示：如果采用了缺陷管理工具，能自動產生缺陷報表的話，則無需本表。缺陷名稱缺陷類型嚴重程度模塊原因駐留時間解決方案…測試人員簽字/日期：試運行計劃文件狀態：[√]草稿[]正式發布[]正在修改文件標識：ProjectName-TestRun-PLAN當前版本：X.Y作者：完成日期：Year-Month-Day版本歷史版本/狀態作者參與者起止日期備注1.試運行目標提示：說明本次試運行的主要內容與目標（必須是可以驗證的）。2.工作條件提示：說明試運行地點、參加人員、軟硬件設施、經費等要求。3.應遞交的工作成果工作成果名稱預計完成時間試運行報告報錯趨勢分析報告……4.進度表提示：（1）用MicrosoftProject制作進度表（GanttChart）插入此處或者參照此表制作一份進度表。任務名稱及其描述開始時間結束時間參加人員任務1任務2…5.可能存在的困難與風險提示：指出可能存在的困難和風險，制定應急計劃以應對突發事件。附錄：本計劃審批意見提示：項目經理或者技術負責人根據項目計劃以及現實情況（如可以支配的人力資源），審批該《試運行計劃》。項目經理或試運行負責人審批意見：簽字日期

數據遷移計劃1.數據遷移的重要事件和里程碑日期2.數據遷移前的備份要求3.數據遷移測試結果清單