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

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

2、 測試、結(jié)項的各 個階段，規(guī)定了各開發(fā)階段的文檔編制、代碼編寫和資料備份內(nèi)容與要求。3. 術(shù)語和縮寫研發(fā)項目干系人：公司內(nèi)部與研發(fā)項目有關(guān)聯(lián)的任何人。 項目計劃周期：從項目立項到計劃完成時間的實際工作日數(shù)。 項目實際周期：從項目立項到實際完成時間的實際工作日數(shù)。項目質(zhì)量目標(biāo)：項目允許出現(xiàn)的總的缺陷數(shù)的加權(quán)平均值。 項目實際質(zhì)量：項目實際出現(xiàn)的總的缺陷數(shù)的加權(quán)平均值。軟件缺陷：在測試過程中被發(fā)現(xiàn)的軟件bug,按照不同的嚴(yán)重程度分為四級； 一級，系統(tǒng)崩潰，無法自動恢復(fù)，加權(quán)系數(shù)為 100。 二級,系統(tǒng)功能無法實現(xiàn)或性能指標(biāo)無法達(dá)到, 但不影響其他功 能的使用,加權(quán)系數(shù)為 2。三級,系統(tǒng)功能實現(xiàn)不完

3、整,加權(quán)系數(shù)為 1。 四級,不影響系統(tǒng)功能和性能的小錯誤, 忽略此錯誤系統(tǒng)可正常 運行,加權(quán)系數(shù)為 0.5 。加權(quán)缺陷數(shù)量：測試中出現(xiàn)的各種缺陷的數(shù)量乘以其對應(yīng)的加權(quán)系數(shù), 求和。4. 職責(zé)和權(quán)限4.1 軟件研發(fā)部經(jīng)理負(fù)責(zé)本規(guī)范的編制、發(fā)布、維護(hù)與解釋。4.2 軟件研發(fā)部經(jīng)理負(fù)責(zé)推動和監(jiān)督本規(guī)范的實施。4.3 公司所有員工可對本規(guī)范提出修改意見。5. 內(nèi)容和要求5.1 研發(fā)立項5.1.1 立項申請,產(chǎn)品研發(fā)經(jīng)過申請后才能立項, 立項申請人可以是公司員 工,也可以是公司各職能部門。5.1.2 立項申請人或委托其部門負(fù)責(zé)人召集相關(guān)人員討論通過, 確定項目經(jīng)理并初步確定項目組成員。5.2 研發(fā)5.2

4、.1 研發(fā)立項確定后，項目經(jīng)理需編寫軟件開發(fā)任務(wù)與職責(zé)分配表 。5.2.1.1 軟件開發(fā)任務(wù)與職責(zé)分配表 初步制定項目開發(fā)的任務(wù)列表和模 塊劃分，以及項目組人員的模塊歸屬和工作時間安排。5.2.1.2 軟件開發(fā)任務(wù)與職責(zé)分配表由項目組成員簽字認(rèn)可。5.2.1.3 項目經(jīng)理可根據(jù)實際情況和設(shè)計的深入， 隨時變更軟件開發(fā)任務(wù) 與職責(zé)分配表。5.2.1.4 研發(fā)部經(jīng)理可抽查 軟件開發(fā)任務(wù)與職責(zé)分配表 的編制和實施情 況，并給出改進(jìn)建議。5.2.2 研發(fā)設(shè)計5.2.2.1 研發(fā)設(shè)計階段確定整個系統(tǒng)的物理結(jié)構(gòu)和部署要求， 并根據(jù)系統(tǒng)的 物理結(jié)構(gòu)進(jìn)行模塊劃分， 確定各個模塊的功能范圍和模塊間的接口方式。

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

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

7、質(zhì)或性能指標(biāo) 或縮短產(chǎn)品的研發(fā)周期。 概要設(shè)計說明書的變更需得到項目經(jīng)理的同意， 必要是 由項目經(jīng)理召集相關(guān)技術(shù)人員和項目組成員召開簡短的技術(shù)會議進(jìn)行論證。 項目 經(jīng)理將變更后的內(nèi)容寫入新版本的軟件項目概要設(shè)計說明書 ，主管軟件的研 發(fā)經(jīng)理最終簽字確認(rèn)。5.2.4 軟件詳細(xì)設(shè)計5.2.4.1 軟件詳細(xì)設(shè)計由項目經(jīng)理指派，項目組成員分擔(dān)完成。5.2.4.2 軟件項目詳細(xì)設(shè)計的內(nèi)容及格式要求，軟件項目的詳細(xì)設(shè)計根據(jù) 軟件項目概要設(shè)計說明書 劃分的各個邏輯模塊包含的程序文件， 確定每個程 序文件中所包含的函數(shù)的詳細(xì)描述， 要求有函數(shù)的功能描述、 輸入輸出說明、 使 用規(guī)則和限制， 如有必要， 還可以

8、描述函數(shù)的實現(xiàn)流程。 詳細(xì)描述軟件中所有全 局變量的格式、 初始值、 用途和使用規(guī)則。 詳細(xì)描述軟件中所有的數(shù)據(jù)結(jié)構(gòu)和類 結(jié)構(gòu)。詳細(xì)描述數(shù)據(jù)庫中的數(shù)據(jù)表， 確定數(shù)據(jù)表的的每個字段， 以及數(shù)據(jù)表之間 的關(guān)系，確定所有的視圖、 觸發(fā)器和存儲過程。 詳細(xì)設(shè)計文檔不做具體的格式要 求，為了提高研發(fā)效率， 可以把詳細(xì)設(shè)計作為代碼的一部分， 直接在程序中編寫。5.2.4.3 項目經(jīng)理負(fù)責(zé)組織對詳細(xì)設(shè)計進(jìn)行審核， 審核方式可采用項目經(jīng)理 主審和項目成員互審相結(jié)合的方式， 主要審核詳細(xì)設(shè)計和概要設(shè)計及需求分析的 符合性，及詳細(xì)設(shè)計的正確性。 軟件研發(fā)部經(jīng)理可組織相關(guān)技術(shù)人員對詳細(xì)設(shè)計 情況進(jìn)行抽查。5.2.4

9、.4 詳細(xì)設(shè)計的變更， 可在項目開發(fā)的任何時段進(jìn)行， 由項目成員在得 到項目經(jīng)理的口頭同意后進(jìn)行，要在變更處做好變更記錄。5.2.5 質(zhì)量控制5.2.5.1 項目組內(nèi)部互審， 在項目的開發(fā)過程中， 項目經(jīng)理可組織項目組成 員對編制的代碼進(jìn)行互相審核， 目的是審查代碼是否符合 研發(fā)中心軟件編碼標(biāo) 準(zhǔn)的要求，并在聯(lián)調(diào)前找到代碼中的缺陷，審核時要做好審核記錄，內(nèi)容為代 碼的編寫人、審核人、缺陷位置、缺陷描述和改進(jìn)建議，格式由項目經(jīng)理決定。 根據(jù)項目的具體情況，項目經(jīng)理有權(quán)決定不進(jìn)行代碼的互審。5.2.5.2 研發(fā)中心內(nèi)部抽查審核， 在項目的開發(fā)過程中， 軟件研發(fā)部經(jīng)理可 組織相關(guān)人員對項目組的開發(fā)質(zhì)

10、量進(jìn)行抽查審核， 被審核的代碼模塊由研發(fā)經(jīng)理 確認(rèn)，審核的主要目的是驗證的代碼書寫的規(guī)范性和與設(shè)計的符合性。 在評審中 發(fā)現(xiàn)問題， 軟件研發(fā)部經(jīng)理可口頭通知項目經(jīng)理進(jìn)行整改， 問題嚴(yán)重時， 可對項 目組下達(dá)軟件整改通知單 ，通知項目組進(jìn)行整改。具體使用何種方式由軟件 研發(fā)部經(jīng)理確定。5.2.5.3 項目組內(nèi)部集成驗證測試， 項目經(jīng)理可在代碼完成后組織內(nèi)部集成 測試，并同時指派項目組成員進(jìn)行軟件使用說明書的編制，在內(nèi)部集成測試 結(jié)束，軟件使用說明書 完成后， 項目經(jīng)理可申請?zhí)峤卉浖y試人員進(jìn)行測試。5.2.5.4 測試人員在測試結(jié)束后，測試人員出具測試記錄表 。項目組對 測試出的問題進(jìn)行修改，

11、然后再申請新一輪的測試， 新的一輪測試由項目經(jīng)理決 定是進(jìn)行驗證性測試還是完整測試， 如果是驗證性測試， 可由項目經(jīng)理確定測試 內(nèi)容范圍并和測試經(jīng)理協(xié)商測試周期， 循環(huán)上述過程直到項目經(jīng)理認(rèn)為可以結(jié)束 測試。為了保證測試質(zhì)量，要求最后一次測試必須是完整測試。測試結(jié)束后，測 試人員要編制測試分析報告 。5.3 研發(fā)結(jié)項5.3.1 測試結(jié)束后，項目經(jīng)理可決定對項目進(jìn)行結(jié)項提交。5.4 技術(shù)資料的管理與備份5.4.1 項目經(jīng)理負(fù)責(zé)技術(shù)資料的管理與備份， 備份內(nèi)容包括項目所涉及的文 檔、代碼和其他相關(guān)技術(shù)資料。5.4.2 項目立項后，項目組要在代碼管理服務(wù)器上建立專門的項目目錄。5.4.3 在研發(fā)過程中，項目組不定期的向代碼管理服務(wù)器進(jìn)行代碼備份，備 份時機由項目經(jīng)理決定。5.4.4 項目提交測試前要進(jìn)行一次完整備份。5.4.5 項目結(jié)項后，要進(jìn)行一次完整備份， 并將最終項目內(nèi)容刻錄光盤備檔。5.4.6 備檔后的光盤由軟件研發(fā)部經(jīng)理統(tǒng)一管理。5.4.7 在研發(fā)過程中，紙質(zhì)文檔由項目經(jīng)理負(fù)責(zé)管理，項目結(jié)項后提