XXXX公司XXXX公司軟件設計編碼過程XXXXXX有限公司文件編號GF_TS_PROC_TS當前版本V3.0機密等級20XX編制者審核者批準者批準日期20XX-3-4XXXXXX有限公司對本文件資料享受著作權及其它專屬權利，未經書面許可，不得將該等文件資料（其全部或任何部分）披露予任何第三方，或進行修改后使用。

文件更改摘要：日期版本號修訂說明修訂人審核人批準人20XX-5-15V1.0正式發布早車20XX-3-4V3.0優化設計編碼過程20XX-5-31V4.1裁剪單元測試過程目錄TOC\o"1-5"\h\z目的32適用范圍3玄術語和縮寫3職責3入口準則3輸入37過程流程圖4&過稈描述4選擇設計解決方案5設計原則583設計方法5開發的復用及外包6概要設計及評審6851概要設計68.5.2概要設計評審8詳細設計及評審8詳細設計8詳細設計評審9建立和維護技術資料包9編碼1089單元測試108.10代碼走杳11輸出11出口準則11引用文檔1112.使用模板11目的軟件設計編碼的目的在于設計和實現關于需求的解決方案。本過程規定了項目開發設計工作應遵循的步驟和原則，保證《軟件需求說明書》中的各項要求在設計時都能夠得到滿足；對項目的編碼實現進行質量控制，保證編碼實現活動按計劃順利完成并與設計相一致。適用范圍適用于公司所有項目的軟件設計及編碼工作。術語和縮寫術語或縮略語解釋無職責角色職責項目經理組織人員對可選解決方案進行決朿分析參與過程文檔的編寫和評審協調項目組內各角色之間的協同合作關系設計工程師根據《軟件需求說明書》進行系統整體架構的分析和設計編寫《軟件概要設計說明書》及《軟件詳細設計說明書》參加設計評審研發中心經理/總監參加設計評審開發工程師根據《軟件概要設計說明書》及《軟件詳細設計說明書》完成代碼編寫和代碼走查參與代碼評審參加設計評審項目推進部監督軟件設計編碼過程檢查設計編碼文檔參與文檔評審入口準則《用戶需求說明書》《軟件需求說明書》已通過評審《項目總體計劃》及《項目進度安排》已通過評審

輸入《用戶需求說明書》《軟件需求說明書》技術資料需求跟蹤矩陣過程流程圖軟件設計編碼過程>選可{案方決解計設輸入用戶需求說明書/軟件需求說明書計設要概需求跟蹤矩陣1剪裁可{計設細詳概要設計說明書概要設計說明書/詳

細設計說明書/

數據庫設計說明書建立技術數據包<開始丿11選擇設計解決方案1>選可{案方決解計設輸入用戶需求說明書/軟件需求說明書計設要概需求跟蹤矩陣1剪裁可{計設細詳概要設計說明書概要設計說明書/詳

細設計說明書/

數據庫設計說明書建立技術數據包<開始丿11選擇設計解決方案1概要設計輸出決策分析報告概要設計說明書詳細設計說明書/數據庫設計說明書評審報告技術數據包清單、圖1系統設計編碼過程示意圖過程描述軟件設計編碼過程包括軟件設計和系統實現。軟件設計是指設計軟件系統的體系結構、數據庫、模塊等，在需求和代碼之間建立橋梁，一般分概要設計和詳細設計兩個階段；系統實現是指軟件工程師按照系統設計去編碼開發，并進行代碼評審。選擇設計解決方案設計工程師根據對需求的理解，制定多個針對需求的解決方案。項目經理組織項目組內的工程師以及需求工程師對各解決方案優缺點進行分析，并挑選最佳的技術解決方案。如必要時，可邀請項目組以外的工程師參與方案選擇。并非所有項目都要求提供多個技術解決方案，但為保證項目質量和公司商業利益，大型項目至少應提供兩套以上技術解決方案。小型項目和中型項目提供一個技術決策方案，對于項目的級別較小或是公司內部項目或對技術性要求不大的項目技術解決方案可以適當的裁剪，但對于其中某些重要部分需要提供兩個以上解決方案。具體過程參見《決策分析過程》。設計原則設計工作應該遵循以下原則：正確、完整地反映《軟件需求說明書》的各項要求，充分考慮其功能、性能、安全保密、出錯處理及其它需求。保證設計的易理解性、可追蹤性、可測試性、接口的開放性和兼容性，考慮健壯性（易修改、可擴充、可移植）、重用性。采用適合本項目的設計方法。若系統使用了新工具和新技術，為了確認新工具和新技術，可以采用快速原型法進行技術預研。考慮選用合適的編程語言和開發工具，制定編碼規范和系統約定等。吸取以往設計的經驗教訓，避免重新出現同樣或類似的問題。對于重要的和復雜度較高的部分要求有相當經驗的設計人員擔任。接口設計準則：提高模塊獨立性保持接口簡潔，降低接口復雜程度保持公司接口設計習慣便于重用設計方法設計時要使用有效的方法進行軟件設計。主要的軟件設計方法包含但不限于：結構化設計方法：結合《軟件需求說明書》及系統不同層次的數據流圖，把整個系統分解為模塊并確定各模塊功能，確定每個功能模塊的輸入、轉換和輸出數據流，并考慮各方面數據接口、存儲方式等。迭代逐步分解各系統模塊，直到確定每個功能模塊只執行一個行為為止，同時細化數據結構設計，完善數據字典以確保系統能獲得所需的輸出結果，從而完成系統構架設計。面向對象設計方法：結合《軟件需求說明書》和系統選用的編程語言，確定客戶類（包括子類）及類的各種行為，并使用設計模型及相應的列表，確定每個對象的客戶（模塊）關聯，并給予必要的方法設計。迭代逐步檢查對象及其方法，直到系統中每個對象擁有所有必需的方法，從而完成系統構架設計。開發的復用及外包設計過程中應考慮是否可以復用以往項目或公用組件庫的設計及編碼，并遵循以下重用原則：不確定已有產品是否可以重用時，應深思熟慮重用前應了解相關產品是否已發布給客戶使用，并通過一定時間驗證，確保不存在嚴重問題如果在當前的時間、技術的約束下無法實現項目目標，方可考慮外包。概要設計及評審概要設計是分析各種設計方案和定義軟件體系結構的過程。軟件設計工程師在充分了解需求的基礎上，依據《軟件需求說明書》選用適當的設計方法，分析與設計軟件的結構、模塊功能。通過系統分解，確定子系統的功能和子系統之間的關系，以及模塊的功能和模塊之間的關系，編寫《概要設計說明書》。《概要設計說明書》必須經過技術評審。如果詳細設計活動被裁剪，那么在《概要設計說明書》中必須包含數據庫結構設計內容，下一活動則進行編碼。8.5.1概要設計概要設計是建立整個軟件的體系結構，包括子系統、模塊以及相關層次的說明、每一模塊的接口定義等。包括：總體架構設計>接口設計界面總體設計數據結構設計系統出錯處理設計（可選）系統安全設計系統部署等概要設計的工作步驟：項目經理確定系統分析員，并討論確定階段出口準則，通盤考慮并跟蹤上游順延下來的進度、技術難度等風險、問題，與相關人員溝通。必要時，請高層參與問題解決；評估、確認需求分析結果，并考慮是否可以復用以往項目或項目經驗庫的設計及編碼，通盤考慮整個系統結構、功能擴展性；系統體系結構設計：a）用選定的工具（如需求功能矩陣表等）和開發計劃設定的交付方式（如小版本漸進交付）及設計方法，結合設計原則（如功能模塊化等），將系統分解為若干子系統、功能模塊，并確定子系統、功能模塊及其間的關系；b）確定子系統、功能模塊間的約束、假設和依賴（如系統運行環境和開發、測試環境等，并考慮系統并發性和分布性要求）；c）結合以上內容，對系統的模塊邏輯實現和集成方法進行設計，降低使軟件難于實現、測試（必要時測試人員參與討論）、維護的因素，形成高內聚、低耦合的系統體系結構；d）定義錯誤處理和恢復策略，對可能出現的故障進行分解，確定處理對策；數據庫設計：a）確定項目數據庫設計規則以便于系統統一，其中包括：庫命名，邏輯設計，物理設計，安全性設計及優化，管理規則等；b）數據庫設計一般要經過“邏輯設計一物理設計一安全性設計一優化”等步驟，通常要迭代進行：?邏輯設計分析軟件系統模塊及其之間的數據操作，使用抽象數據類型設計，轉換數據對象的屬性及其關聯、接口等內容，設計并完善數據字典及其約束條件，實現數據的變量封裝結構設計。面向結構設計方法中為創建與數據庫相關的數據流圖或實體關系圖；若采用面向對象方法，則分析類信息傳遞內容，并創建類圖；物理設計設計表結構，與實體關系圖或類圖相結合；對表結構進行規范化處理；安全性設計考慮數據庫的登陸訪問限制，用戶密碼加密，操作訪問權限等系統安全設計；c）優化分析并優化數據庫的“時-空”（即性能，容量等）效率，盡可能“提高處理速度”并且“降低數據占用空間”。分析“時-空”效率的瓶頸，找出優化對象（目標），并確定優先級；消除對象（目標）間的對抗性，必要時給出折中方案；給出優化的具體措施，如逐步評估、優化數據庫環境參數，對表格進行反規范化處理等，堅持信息隱蔽等原則，加強數據設計可維護性；8.5.2概要設計評審為保證概要設計的正確性、完整性和與需求的一致性，應對概要設計說明書以及相關文檔進行技術評審。選用技術評審會議的方式，提請評審管理部門組織評審，具體過程參見《評審過程》。評審組成員包括但不限于：項目經理、需求工程師、系統分析員、開發工程師、質量保證工程師、技術或業務專家輸入：《概要設計說明書》、《軟件需求說明書》、《數據庫設計說明書》輸出：《概要設計說明書》、《軟件需求說明書》、《數據庫設計說明書》、《評審報告》、《評審問題跟蹤表》概要設計評審通過后，概要設計說明書及其評審記錄納入受控庫管理。負責概要設計的系統分析員填寫《需求跟蹤矩陣》的相關設計項。詳細設計及評審對于項目規模較小、技術難度較低的項目，可以對設計過程進行裁剪。概要設計評審通過后，如果詳細設計過程沒有被裁剪，依據《軟件需求說明書》及《概要設計說明書》，系統分析員進一步細化系統的設計。針對每個子系統從功能、性能、輸入輸出、流程、接口、用戶界面等方面實施具體的詳細設計，編寫《詳細設計說明書》。《詳細設計說明書》必須經過技術評審。8.6.1詳細設計根據確定的設計方法，并考慮是否可以復用以往項目或項目經驗庫的設計及編碼，通盤考慮整個系統結構、功能擴展性；選擇適當工具進行詳細設計，以獲得關于處理邏輯、數據結構和數據定義的更加詳盡的描述，最終產生開發工程師可用的模塊說明。可以包含：描述功能參數說明性能（可選）用戶界面?流程邏輯?算法等詳細設計輸出《詳細設計說明書》、細化的《數據庫設計說明書》等。《數據庫設計說明書》可裁剪，裁剪的話需要在《概要設計說明書》中數據庫結構中填寫相關內容。8.6.2詳細設計評審為保證詳細設計的正確性、完整性和與概要設計和需求的一致性，項目經理應組織人員對詳細設計說明書以及相關文檔進行技術評審。具體過程參見《評審過程》。?評審組成員包括但不限于：項目經理、系統分析員、開發工程師、質量保證工程師、技術或業務專家；?輸入：《詳細設計說明書》；?輸出：《詳細設計說明書》、《評審報告》、《評審問題跟蹤表》；詳細設計評審通過后，詳細設計說明書及其評審記錄納入受控庫管理。負責詳細設計的系統分析員填寫《需求跟蹤矩陣》的相關設計項。建立和維護技術資料包TDP：TechnicalDataPackage，技術資料包是一些元素的集合，這些元素和一種類型的產品或產品組件相關，技術資料包可能包括：產品總體結構描述、確定的需求、產品組件描述、產品相關生命周期過程描述（如果沒有在獨立的產品組件中描述）、關鍵產品特性、必須的物理特性和約束關系、接口需求、保證需求被滿足的驗收條件、可操作性場景等。項目組需要把這些相關工作產品（概要設計、詳細設計、用戶提供的技術資料、公司開發所需的技術資料）納入到技術資料包（TDP）進行管理，填寫《技術數據包清單》并明確各角色人員對相關資料的訪問權限，記錄于《配置管理計劃》中。編碼系統設計完成后，進入編碼階段。項目組在系統設計時開始制定編碼規范，在進入編碼階段之前，必須確定項目的編碼規范：直接使用公司現有的編碼規范，請參見“編碼規范”文件夾。引用公司現有的編碼規范，在設計階段開始此基礎上進行修改，生成項目的編碼規范，必須經過EPG審批后使用。公司沒有的，項目組應在設計階段開始建立新的編碼規范，經過EPG審批后使用。編碼是把系統設計轉換為程序代碼的過程。軟件工程師：依據設計說明書，開展具體的程序代碼的編寫。嚴格項目的編程規范及項目組的系統約定。借鑒以往編碼的經驗和代碼復用。編碼完成后系統進行單元測試或者代碼評審，具體根據《項目過程定義裁剪表》選擇相關活動（可以二選一，也可以全部進行）。單元測試單元測試分為單元測試用例設計及單元測試執行兩個工作。單元測試用例的設計可以使用工具生成或人工設計，輸出可以是文檔化的測試用例《單元測試用例及記錄》或者測試源代碼。項目組可根據實際情況進行裁剪。單元測試需要關注以下幾個方面：源代碼編譯測試代碼是否通過編譯。SQL腳本測試數據庫腳本、存儲過程運行是否正常。模塊接口對被測模塊，信息是否能正確地流入和流出。局部數據結構在模塊的工作過程中，其內部的數據能否保持其完整性。邊界條件在邊界上模塊是否能正常工作。覆蓋條件模塊的運行是是否滿足設計的邏輯要求。?出錯處理——檢查模塊的錯誤處理設施是否有效。單元測試伴隨著缺陷修改的工作，模塊通過測試后，應在《單元測試報告》中記錄單元測試的結果以及遺留問題，作為集成測試開始的依據。完成各模塊的單元測試后，負責編碼的軟件工程師填寫《需求跟蹤矩陣》的相關編碼模塊。單元測試活動可根據項目特征進行裁剪。代碼走查項目經理安排評審人員進行程序代碼檢查，檢查發現的問題納入缺陷管理（參見《缺陷管理規程》），直到問題解決。代碼評審采用個人復查方式執