軟件開發(fā)工藝流程規(guī)程

1、受控狀態(tài)（章）： 受控號：*有限公司軟件開發(fā)工藝流程規(guī)程文件編號: &/TE750-2013 文件版本: V1.0編制：%審核：￥批準：#發(fā)布日期：2013/12/01實施日期：2013/12/01_*有限公司對本文件資料享受著作權及其他專屬權利，未經書面許可，不得將該等文件資料（其全部或任何部分）披露予任何第三方，或進行修改后使用。文件編號：&/TE750-2013 文件名稱：軟件開發(fā)工藝流程規(guī)程修訂履歷版本變更履歷變更人/變更日期審核人/審核日期批準人/批準日期V1.0初次發(fā)布% 2013/11/28￥ 2013/11/29# 2013/12/011. 目的為了規(guī)范軟件研發(fā)各個階段的開發(fā)行

2、為，特制定此規(guī)范。2. 范圍 本規(guī)范適用于研發(fā)中心軟件產品研發(fā)從立項，到開發(fā)實施、測試、結項的各個階段，規(guī)定了各開發(fā)階段的文檔編制、代碼編寫和資料備份內容與要求。3. 術語和縮寫 研發(fā)項目干系人：公司內部與研發(fā)項目有關聯的任何人。項目計劃周期：從項目立項到計劃完成時間的實際工作日數。項目實際周期：從項目立項到實際完成時間的實際工作日數。項目質量目標：項目允許出現的總的缺陷數的加權平均值。 項目實際質量：項目實際出現的總的缺陷數的加權平均值。軟件缺陷：在測試過程中被發(fā)現的軟件bug，按照不同的嚴重程度分為四級； 一級，系統(tǒng)崩潰，無法自動恢復，加權系數為100。 二級，系統(tǒng)功能無法實現或性能指標無

3、法達到，但不影響其他功能的使用，加權系數為2。 三級，系統(tǒng)功能實現不完整，加權系數為1。 四級，不影響系統(tǒng)功能和性能的小錯誤，忽略此錯誤系統(tǒng)可正常運行，加權系數為0.5。加權缺陷數量：測試中出現的各種缺陷的數量乘以其對應的加權系數，求和。4. 職責和權限 4.1 軟件研發(fā)部經理負責本規(guī)范的編制、發(fā)布、維護與解釋。4.2 軟件研發(fā)部經理負責推動和監(jiān)督本規(guī)范的實施。4.3公司所有員工可對本規(guī)范提出修改意見。5. 內容和要求5.1 研發(fā)立項5.1.1 立項申請，產品研發(fā)經過申請后才能立項，立項申請人可以是公司員工，也可以是公司各職能部門。5.1.2 立項申請人或委托其部門負責人召集相關人員討論通過，

4、確定項目經理并初步確定項目組成員。5.2 研發(fā)5.2.1 研發(fā)立項確定后，項目經理需編寫軟件開發(fā)任務與職責分配表。5.2.1.1 軟件開發(fā)任務與職責分配表初步制定項目開發(fā)的任務列表和模塊劃分，以及項目組人員的模塊歸屬和工作時間安排。5.2.1.2 軟件開發(fā)任務與職責分配表由項目組成員簽字認可。5.2.1.3 項目經理可根據實際情況和設計的深入，隨時變更軟件開發(fā)任務與職責分配表。5.2.1.4 研發(fā)部經理可抽查軟件開發(fā)任務與職責分配表的編制和實施情況，并給出改進建議。5.2.2 研發(fā)設計5.2.2.1 研發(fā)設計階段確定整個系統(tǒng)的物理結構和部署要求，并根據系統(tǒng)的物理結構進行模塊劃分，確定各個模塊的

5、功能范圍和模塊間的接口方式。詳細說明系統(tǒng)規(guī)模要求和運行環(huán)境限制，并指出系統(tǒng)運行所需資源的要求。明確開發(fā)和系統(tǒng)運行所需軟硬件資源的要求。確定項目進行一次全面測試所需要的測試人員人數和測試周期。5.2.3 軟件研發(fā)設計階段，軟件項目需編制軟件概要設計說明書。5.2.3.1 軟件項目概要設計說明書由項目經理或其委托人編制。5.2.3.2 軟件項目概要設計說明書確定整個系統(tǒng)的邏輯結構，并對需求分析中各物理模塊進行邏輯模塊劃分，詳細描述各邏輯模塊的業(yè)務規(guī)則和模塊之間的接口以及重要的內部接口，確定系統(tǒng)級的全局變量和數據結構，確定各邏輯模塊所包含的程序文件名稱和使用的開發(fā)工具，描述每個文件中所包含的函數功能

6、。確定數據庫的類型和所有數據表名稱及數據表的用途，確定數據庫的訪問方式。詳細描述系統(tǒng)的配置方式。如果軟件有用戶界面，要對界面進行詳細設計，確定所有界面的名稱、規(guī)格及界面上的元素類型及功能，界面設計可在開發(fā)工具中直接繪制，也可采用其他繪圖方式，但在概要設計文檔中要保留圖示并進行詳細說明。5.2.3.3 軟件項目概要設計說明書由項目組全體成員認可，軟件研發(fā)部經理最終確認。5.2.3.4 軟件項目概要設計說明書的變更，在開發(fā)過程中，項目組成員可提出對軟件項目概要設計說明書的變更申請。軟件項目概要設計說明書變更的主要目的是修正其中的錯誤，或者經過變更可提高產品的品質或性能指標或縮短產品的研發(fā)周期。概要

7、設計說明書的變更需得到項目經理的同意，必要是由項目經理召集相關技術人員和項目組成員召開簡短的技術會議進行論證。項目經理將變更后的內容寫入新版本的軟件項目概要設計說明書，主管軟件的研發(fā)經理最終簽字確認。5.2.4 軟件詳細設計5.2.4.1 軟件詳細設計由項目經理指派，項目組成員分擔完成。5.2.4.2 軟件項目詳細設計的內容及格式要求，軟件項目的詳細設計根據軟件項目概要設計說明書劃分的各個邏輯模塊包含的程序文件，確定每個程序文件中所包含的函數的詳細描述，要求有函數的功能描述、輸入輸出說明、使用規(guī)則和限制，如有必要，還可以描述函數的實現流程。詳細描述軟件中所有全局變量的格式、初始值、用途和使用規(guī)

8、則。詳細描述軟件中所有的數據結構和類結構。詳細描述數據庫中的數據表，確定數據表的的每個字段，以及數據表之間的關系，確定所有的視圖、觸發(fā)器和存儲過程。詳細設計文檔不做具體的格式要求，為了提高研發(fā)效率，可以把詳細設計作為代碼的一部分，直接在程序中編寫。5.2.4.3 項目經理負責組織對詳細設計進行審核，審核方式可采用項目經理主審和項目成員互審相結合的方式，主要審核詳細設計和概要設計及需求分析的符合性，及詳細設計的正確性。軟件研發(fā)部經理可組織相關技術人員對詳細設計情況進行抽查。5.2.4.4 詳細設計的變更，可在項目開發(fā)的任何時段進行，由項目成員在得到項目經理的口頭同意后進行，要在變更處做好變更記錄

9、。5.2.5質量控制5.2.5.1 項目組內部互審，在項目的開發(fā)過程中，項目經理可組織項目組成員對編制的代碼進行互相審核，目的是審查代碼是否符合研發(fā)中心軟件編碼標準的要求，并在聯調前找到代碼中的缺陷，審核時要做好審核記錄，內容為代碼的編寫人、審核人、缺陷位置、缺陷描述和改進建議，格式由項目經理決定。根據項目的具體情況，項目經理有權決定不進行代碼的互審。5.2.5.2 研發(fā)中心內部抽查審核，在項目的開發(fā)過程中，軟件研發(fā)部經理可組織相關人員對項目組的開發(fā)質量進行抽查審核，被審核的代碼模塊由研發(fā)經理確認，審核的主要目的是驗證的代碼書寫的規(guī)范性和與設計的符合性。在評審中發(fā)現問題，軟件研發(fā)部經理可口頭通

10、知項目經理進行整改，問題嚴重時，可對項目組下達軟件整改通知單，通知項目組進行整改。具體使用何種方式由軟件研發(fā)部經理確定。5.2.5.3 項目組內部集成驗證測試，項目經理可在代碼完成后組織內部集成測試，并同時指派項目組成員進行軟件使用說明書的編制，在內部集成測試結束，軟件使用說明書完成后，項目經理可申請?zhí)峤卉浖y試人員進行測試。5.2.5.4 測試人員在測試結束后，測試人員出具測試記錄表。項目組對測試出的問題進行修改，然后再申請新一輪的測試，新的一輪測試由項目經理決定是進行驗證性測試還是完整測試，如果是驗證性測試，可由項目經理確定測試內容范圍并和測試經理協商測試周期，循環(huán)上述過程直到項目經理認為

11、可以結束測試。為了保證測試質量，要求最后一次測試必須是完整測試。測試結束后，測試人員要編制測試分析報告。5.3 研發(fā)結項 5.3.1測試結束后，項目經理可決定對項目進行結項提交。5.4 技術資料的管理與備份5.4.1 項目經理負責技術資料的管理與備份，備份內容包括項目所涉及的文檔、代碼和其他相關技術資料。5.4.2 項目立項后，項目組要在代碼管理服務器上建立專門的項目目錄。5.4.3在研發(fā)過程中，項目組不定期的向代碼管理服務器進行代碼備份，備份時機由項目經理決定。5.4.4項目提交測試前要進行一次完整備份。5.4.5項目結項后，要進行一次完整備份，并將最終項目內容刻錄光盤備檔。5.4.6備檔后的光盤由軟件研發(fā)部經理統(tǒng)一管理。5.4.7在研發(fā)過程中，紙質文檔由項目經理負責管理，項目結項后提交到主管軟件的