軟件研發(fā)版本管理制度

1、泰豪軟件研發(fā)版本管理規(guī)范v1.0（草案）研發(fā)部2009-2-4目錄文檔類別使用對象 21引言 21.1 目的 21.2 范圍 21.3 術語定義 21.4 版序控制記錄 31.5 版本更新記錄 32版本管理 32 1 版本標識方法 32 11 正式版本 32 2 目錄結構 42 3 文檔的存放 52.3.1 當前版本和歷史版本的存放 52.3.2 開發(fā)文檔的存放 52.3.3 源代碼的存放 52.3.4 SQL 語句的存放 52.3.5 發(fā)行文檔的存放 52 4 權限控制管理 53更新管理（版本升級） 63.1 版本升級原則 63.2 新版本的發(fā)布 64備份管理 75用戶版本管理 76研發(fā)部統(tǒng)

2、一管理階段性版本 86.1 階段性版本的提交到研發(fā)部 86.2 階段性版本的發(fā)布到公司網站上 86.3 各項目組新版本內部及時備份。 87版本工具的使用 87.1研發(fā)部采用SVN配置管理工具88各項目組提交文檔及源碼以及規(guī)則 98.1 各項目組需要提交的文檔 98.2 目前所管理的產品列表 99周報管理制度 1010風險管理制度10文檔類別使用對象文檔類別該文檔是為泰豪公司提供一個版本管理規(guī)范性文件。 使用對象該文檔使用對象為泰豪軟件公司研發(fā)本部各部門項目經理及版本管理人員，以及其他相 關人員。未經許可，該文檔不得提供給上述規(guī)定對象以外的人員閱讀或使用。1 引言1.1 目的本文檔是為規(guī)范泰豪軟

3、件公司研發(fā)版本管理而制定的。1.2 范圍本文檔為各產品部、事業(yè)部版本管理員提供有關版本管理規(guī)范的相關內容，包括：版本標識方法 軟件系統(tǒng)數(shù)據(jù)的存放 文檔的修改控制 文檔的備份制度1.3 術語定義SVNSvn是一個開源的版本控制系統(tǒng)Subversion的簡稱文檔一種數(shù)據(jù)媒體和其上所記錄的數(shù)據(jù)。配置管理標識和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存周期內控制這些項的投放和更動，記錄并報告配置的狀態(tài)和更動要求，驗證配置項的完整性和正確性。軟件配置軟件的具體形態(tài)在某時刻的瞬時影像。配置項軟件配置管理的對象稱為配置項，如： 系統(tǒng)規(guī)格說明書，項目開發(fā)計劃，用戶手冊，源碼?；€軟件生存周期中各開發(fā)階段末尾的標記

4、， 它的作用是把各階段工作的劃分更加明確化， 使 本來連續(xù)的工作在這些點上斷開，使之便于檢驗和肯定階段成果。1.4 版序控制記錄版序狀 態(tài)擬稿審核批準發(fā)布日期1.0研發(fā)部張洪興09/11/181.5 版本更新記錄*A -增加 M -修改 D -刪除版本/修訂版修改貞他修改記錄修改人日期1.0初始版本2009/022. 版本管理3. 1版本標識方法為了使工作規(guī)范化、統(tǒng)一化，各項目組實行的版本標識管理方法分為：正式版本和特殊 版本。4. 1. 1正式版本公司在市場上發(fā)行的正規(guī)版本。以“V”開頭，版本號放后。V前面增加項目名稱，版本號分 3節(jié)：主版本號，次版本 號和內部版本號，每節(jié)之間以小數(shù)點（.）

5、間隔。如V2.0.1表示主版本號為2,次版本號為0, 內部版本號為1。研發(fā)部控制主版本號和次版本號，各項目組控制內部版本號。例如：一體 化平臺-平陰版V1.1.1 , 一體化平臺為產品名稱，平陰版為版本名稱（平陰為具體項目名 稱），V1.1.1為主版本號+次版本號+內部版本號。2. 2目錄結構由于各項目組的實際情況不同，目錄結構很難統(tǒng)一，但為了能更好地管理各項目組的文 檔，建議可將被管理的配置項分為三大類： 文檔類、源碼類及安裝盤類，這樣存放比較清晰, 有利于版本管理。至于二級目錄是以版本劃分，并根據(jù)制定的目錄結構給出文件級目錄清單(先給出源程序及文檔的文件級目錄清單，安裝盤的可以后再執(zhí)行)：

6、?，F(xiàn)以農電平臺1.0的目錄結構舉例如下:根目錄一級目錄二級目錄三級目錄對應配置項備注產品名稱 一體化平 臺版本號源碼(F：)核心 源碼 包jarClass 文件源碼存目錄前正在修改 的內容擴展源碼包源碼sqlSQL文件版本變動說明文檔(G:)需求文檔用戶需求記 錄版本號在文件名上 標識概要設計文檔 r數(shù)據(jù)庫設計詳細設計文檔總體設計文 檔按版本號依次類推測試用例測試記錄版本號在文件名上 標識用戶加產品說明書用戶使用手 冊項目計劃項目計劃實施加實施手冊月叱劃月度計劃安,（H：）麥盤REL_SRC SETUP r發(fā)布義檔產品盤或發(fā)體文檔表示正式版本及特殊版本的目錄按以下原則定義:(1) 正始版本：以

7、“ V”開頭，版本號放后，主版本號和次主版本號之間的“.”去掉，明細版本號之前加“-。舉例如下： 版本號目錄名V 1.0V1.0V 1.1V1.1V 1.0.1V1.0.1V 1.1.2V1.1.22 3 文檔的存放2.3.1 當前版本和歷史版本的存放對于源碼文件，特別增加了一個Current 目錄，存放當前正在開發(fā)與維護的源碼文件，當前未發(fā)布版本的所有數(shù)據(jù)都存放在下。一旦當前版本正式發(fā)行，則當前目錄被修改為相應的歷史目錄。歷史版本是指已經發(fā)行的版本，存放在相應的版本目錄之下，一般不允許改動。2.3.2 開發(fā)文檔的存放根據(jù)各項目部自己的情況，將系統(tǒng)用戶需求記錄、總體設計文檔、詳細設計及數(shù)據(jù)結構

8、文件、測試記錄、用戶手冊等放入相應的目錄下。2.3.3 源代碼的存放源代碼包括如：java， jsp， BMP， ICO 等相關文件，是未經編譯處理的、不能直接交付使用的產品文件以及編譯產品所需的文件；聯(lián)機幫助文件HLP 在未生成HLP 文件之前的DOC， RTF 等格式的文檔也視為源代碼。各子系統(tǒng)當前的程序源文件放入相應的目錄下。對于一個子系統(tǒng)又分多個分子系統(tǒng)的情況，應在該目錄下分別建立幾個相應的目錄。2.3.4 SQL 語句的存放各子系統(tǒng)SQL文件放入.SQL下，對于不同的數(shù)據(jù)庫，分別建立不同的子目錄， 如oracle、sysbase db2等。公共SQL文件直接放入SQL下即可，不同數(shù)據(jù)

9、庫的特殊 SQL 分別放入對應的子目錄下。2.3.5 發(fā)行文檔的存放發(fā)行文檔是指產品交付用戶使用所必須的文件。包括：產品可執(zhí)行文件，用戶使用說明書，聯(lián)機幫助（HLP） ；資源文件（BMP， ICO 等） ，環(huán)境配置文件等。以上文檔作為制作發(fā)行盤的素材，放在RELEASE 的 REL_SRC 目錄之下，制作好的發(fā)行盤放在RELEASE 的 SETUP 目錄。2 4 權限控制管理為保障文檔的安全性，一致性，以及防止意外修改，必須對不同的文檔設置不同的訪問權限。文檔權限類別：只讀權限，讀寫權限。文檔類別：設計文檔，源碼，發(fā)行文檔。用戶類別：開發(fā)人員、測試人員、分析設計人員、項目經理、配置管理員、安裝

10、盤制作 人員、問題及需求管理人員、用戶文檔編寫人員等。為了控制不同的使用權限，根據(jù)要求在服務器上分別建立不同的用戶，針對不同的配置 項所在目錄分配不同的權限。為了便于管理，應以表格的形式列出人員與管理對象的訪問關系（用戶權限清單）3 .更新管理（版本升級）3.1 版本升級原則版本升級應嚴格納入版本管理的控制之下。應當謹慎地控制版本的升級，保障高版本的 向下兼容性，或提供嚴格定義的升級方法。在下面幾種情況下，進行版本演化和升級：1、當產品發(fā)生重大修改和改進時，主版本號加 1。重大修改和改進包括：1）平臺遷移；2）開發(fā)工具的遷移；3）體系結構的變遷。2、當產品發(fā)生較小的改進或修改時，次版本號可以加

11、1。3、對于改動量比較少的，如修改產品的錯誤，可增加內部版本號。內部版本號對用戶 來說是不可見的，只對項目部內部版本控制有用。4、記錄版本升級過程。每次版本升級，都要填寫版本升級記錄表，記錄表樣例如下：版本升級記錄表版本號發(fā)布日期修改文件問題簡要描述發(fā)布責任人批準人備注說明：版本號：記錄當前發(fā)布的版本。發(fā)布日期：該版本批準發(fā)布的日期。修改文件：版本修改記錄文件，一般為版本修改日志。3.2 新版本的發(fā)布新版本的發(fā)布包括主版本號和次版本號的升級，一般不包括內部版本號的升級。流程如下：1、根據(jù)項目進展情況，或者根據(jù)用戶需要進行發(fā)布準備。2、在指定目錄中，根據(jù)本次發(fā)布的版本號建立相應的子目錄，將 cu

12、rrent下的所有內容拷貝至新建目錄下3、可在新建目錄下建立readme.txt,并加入相應的內容。readme.txt文件是記錄該版本與上一版本的不同，作過哪些改動。格式樣例如下:增加或修改功能涉及源文件改動原因4 .備份管理為了保證文檔的最大可恢復性，要隨時及定期地進行備份工作。1、隨時備份：(1)開發(fā)人員每天都要將自已當日修改的源文件在本地機器上進行備份。(2)開發(fā)負責人每天要將所有源文件在本地機備份。(3)建議備份采用循環(huán)備份。2、定期備份(1)備份形式為硬盤備份和光盤備份。硬盤備份時，要備份在獨立的硬盤上；光 盤備份時，要將光盤存放在可靠的地方。(2)備份周期視各產品部、事業(yè)部的具體

13、情況而定。如果處于開發(fā)階段，每周應 對所有的源程序項進行備份，一般為每周周五；如果處于其它階段，根據(jù)具 體情況而定，但周期不能超過兩周。(3)備份要由版本管理員負責，備份原則應是保證文檔的最大可恢復性。(4)對于歷史版本或某用戶的特殊版本，如果無特殊原因不再進行修改的話，建 議用光盤進行備份，而且應有備份盤說明文件 BACKUP.TXT。該文件應該記 錄以下內容：本次備份時間，備份內容，執(zhí)行人。5 .用戶版本管理目前主要以做項目為主，是根據(jù)客戶要求開發(fā)的程序。為了更好地管理源程序，應為每 一用戶建立一個用戶版本文件，該文件應包含以下內容：用戶編號：用戶名稱：軟件版本號：開始使用時間：聯(lián)系人：聯(lián)

14、系電話：用戶程序更改日志樣例如下：更改 時間版本號修改模 塊名稱變更原因變更概述軟件位置變更 人員備注說明：1）用戶購買軟件時要為該用戶建立一個包含上述內容的一個用戶版本文件，并填寫有 關數(shù)據(jù)。2）用戶進行版本更新時要求填寫該文件的版本變更記錄，用以反映用戶版本的變更情 況。6 .研發(fā)部統(tǒng)一管理階段性版本6.1 階段性版本的提交到研發(fā)部當各項目組更新了新版本以后，如果次版本號發(fā)生改變，各項目組配置管理員經項目經 理批準后要把次版本修改的內容（提交的內容分為修改的源碼、新的文檔和安裝盤）提交給 研發(fā)部版本管理人員。6.2 階段性版本的發(fā)布到公司網站上產品新版本發(fā)布以后，及時在軟件演示環(huán)境中進行更

15、新。 并且新版本的特色和特點要在 公司網站上進行發(fā)布，描述新版本特色的文檔要由各項目組進行提供給項目部，經項目部保存后，文檔提交給公司網站管理人員進行發(fā)布，以便供其他項目組和公司營銷人員進行了解。6.3 各項目組新版本內部及時備份。研發(fā)部負責進行所有產品版本的管理，但各個項目組也要自己進行備份。7 .版本工具的使用7.1 研發(fā)部采用svn配置管理工具研發(fā)部采用專門的配置管理服務器， 此服務器只是專門用于版本的管理， 一般不用于其 他的應用，配置管理軟件采用 svn1.5進行配置管理。8 .各項目組提交文檔及源碼以及規(guī)則8.1 各項目組需要提交的文檔名稱成果描述立項申請書寫名此項目的價值、所需人

16、力資源及費用、可行性分析、成 本-效益分析、風險分析立項評審報告評審結論、評審建議軟件需求說明書目標客戶、業(yè)務流程、系統(tǒng)中的角色、子功能模塊介紹、質 量要求、界囿要求系統(tǒng)設計說明書系統(tǒng)約束、開發(fā)環(huán)境、數(shù)據(jù)流程圖、用例圖、模塊之間的關 系圖、類函數(shù)文件變量等命名規(guī)則、系統(tǒng)安全設計說明、性 能分析數(shù)據(jù)庫設計說明書所有表名、表設計、表 ER圖、生成庫的sql語句、存儲過 程等。表及字段命名規(guī)則。用戶界面設計說明書系統(tǒng)界面設計說明、原型圖模塊設計說明書編程的接口、主要的數(shù)據(jù)結構、主要算法測試用例用例名稱、用例描述、輸入值、希望輸出值缺陷報告Bug名稱、bug狀態(tài)、bug緊急情況、bug處理人等測試報告

17、界面測試報告、性能測試報告部署說明書部署環(huán)境說明、初始化的數(shù)據(jù)、注意事項、數(shù)據(jù)的遷移等安裝和使用手冊安裝過程描述、各模塊使用手冊、FAQ手冊軟件源代碼源代碼、開發(fā)工具、 API詳細說明、代碼注釋、編譯后程序系統(tǒng)維護記錄問題描述、問題解決情況技術評審報告評審內容、評審結果、評審人系統(tǒng)安裝程序打包程序、打包工具、打包完以后的安裝程序8.2 目前所管理的產品列表序列號產品名稱應用范圍所屬項目組產品介紹1一體化平臺Sg186農電農電2安全性評價系統(tǒng)電網安全性 評價調度3電網調度專業(yè)技術 安全知識在線調考 系統(tǒng)（網省版）電網調度4電網現(xiàn)場標準化作 業(yè)系統(tǒng)電網調度5國調E語言編輯瀏 覽器電網調度6江四省電力公司生 產安全管理系統(tǒng)電網調度7江四省電力公司電網輸電GIS電網調度8青海一體化OMS項 目建設電網調度9生產管理系統(tǒng)短信 平臺電網調度10泰豪EOMP業(yè)務基 礎平臺電網調度11泰豪圖形化智能操 作票系統(tǒng)電網調度9 .周報管理制度各項目組每周向研發(fā)部提交周報。周報具體的格式如下:項