某軟件有限公司文檔版本管理規(guī)范

1、研發(fā)本部版本管理規(guī)范V1.0浪潮集團山東通用軟件有限公司密級：內控目錄文檔類別使用對象 21引言 31.1 目的 31.2 范圍 31.3 術語定義 31.4 參考資料 41.5 版序控制記錄 41.6 版本更新記錄 42版本管理 521 版本標識方法 52 1 1 正式版本 521 2特殊版本 522目錄結構 523文檔的存放 71.3.1 當前版本和歷史版本的存放 71.3.2 開發(fā)文檔的存放 71.3.3 源代碼的存放 71.3.4 SQL 語句的存放 71.3.5 發(fā)行文檔的存放 82 4權限控制管理 83更新管理 83 1源程序的修改 84 2已發(fā)布版本的維護及修改 95 3外出人員

2、對產品的修改 93 4版本升級 123.1.1 版本升級原則 123.1.2 新版本的發(fā)布 123.1.3 安裝盤制作步驟 134備份管理 135用戶版本管理 14文檔類別使用對象文檔類別該文檔是為浪潮通軟公司研發(fā)本部各產品部、事業(yè)部提供一個版本管理規(guī)范性文件。使用對象該文檔使用對象為浪潮通軟公司研發(fā)本部各部門經理及版本管理人員，以及其他相 關人員。未經管理過程改善部書面許可，該文檔不得提供給上述規(guī)定對象以外的人員閱 讀或使用。1引言1.1 目的本文檔是為規(guī)范公司研發(fā)本部各產品部、事業(yè)部版本管理而制定的。1.2 范圍本文檔為各產品部、事業(yè)部版本管理員提供有關版本管理規(guī)范的相關內容，包括：版本標

3、識方法軟件系統(tǒng)數(shù)據(jù)的存放文檔的修改控制文檔的備份制度1. 3術語定義SCMSoftwere Configuration Management 縮寫SVMSoftware Version Management 縮寫文檔一種數(shù)據(jù)媒體和其上所記錄的數(shù)據(jù)。配置管理標識和確定系統(tǒng)中配置項的過程， 在系統(tǒng)整個生存周期內控制這些項的投放和更動，記錄并報告配置的狀態(tài)和更動要求，驗證配置項的完整性和正確性。軟件配置軟件的具體形態(tài)在某時刻的瞬時影像。配置項軟件配置管理的對象稱為配置項，如：系統(tǒng)規(guī)格說明書，項目開發(fā)計劃，用戶手冊，源碼?；€軟件生存周期中各開發(fā)階段末尾的標記，它的作用是把各階段工作的劃分更加明確化，

4、使本來連續(xù)的工作在這些點上斷開，使之便于檢驗和肯定階段成果1.4 參考資料1事業(yè)部門版本管理工作標準SEPG V1.0財務產品部V1.0V 1.0V 1.0V 1.02國強財務V6CK置管理3商業(yè)事業(yè)部版本管理規(guī)范4酒店事業(yè)部版本管理規(guī)范5財務產品部版本管理規(guī)范6PAC事業(yè)部版本管理規(guī)范V1.07MRPII部版本管理規(guī)范V1.08金融事業(yè)部版本管理規(guī)范V1.09ER唐B版本管理規(guī)范V1.01.5 版序控制記錄版序狀 態(tài)擬稿審核批準發(fā)布日期1.0管理過程改善部任甲林99/11/181.6 版本更新記錄*A -增加 M -修改 D -刪除版本/修訂版修改貞他修改記錄修改人日期1.0;初始版本99/

5、112.版本管理2. 1版本標識方法為了使工作規(guī)范化、統(tǒng)一化，研發(fā)本部各部門實行的版本標識管理方法分為：正式 版本和特殊版本。2. 1. 1正式版本公司在市場渠道上發(fā)行的正規(guī)版本。以"V'開頭，版本號放后。版本號分3節(jié)：主版本號，次版本號和內部版本號，每 節(jié)之間以小數(shù)點（.）間隔。如V2.0.01表示主版本號為2,次版本號為0,內部版本號 為01。3. 1. 2特殊版本特殊版本是在正式版本的基礎上，針對某客戶開發(fā)的版本。它與正式版本的不同之 處在于問題不具有通用性和適應性，只符合該用戶的實際使用情況。該版本標識分為常規(guī)部分和擴展部分，常規(guī)部分表示該特殊版本哪一個正式版本的 分

6、支，命名方法同正式版本的命名方法。對于擴展部分，以“S”開頭，后加一唯一序號。舉例如下：V2.33.S01表示由V2.33分支出的第一個特殊版本V2.33.S02表示由V2.33分支出的第二個特殊版本事業(yè)部不鼓勵產生特殊版本。只有在極特殊的情況下，才產生適當?shù)奶厥獍姹?。?在以后的版本演化中，盡量將其納入到正式版本中。4. 2目錄結構由于各部門的實際情況不同，目錄結構很難統(tǒng)一，但為了能更好地管理各事業(yè)部的 文檔，建議可將被管理的配置項分為三大類：文檔類、源碼類及安裝盤類，這樣存放比 較清晰，有利于版本管理。至于二級目錄是以模塊劃分還是以版本劃分，各產品部、事 業(yè)部可根據(jù)自己部門的情況，制定適合

7、本部門的目錄結構，并根據(jù)制定的目錄結構給出 文件級目錄清單（先給出源程序及文檔的文件級目錄清單，安裝盤的可以后再執(zhí)行）：?，F(xiàn)以財務產品部V& 0的目錄結構舉例如下：根目錄二級目錄三級目錄四級目錄對應配置項備注源碼（F：）模塊縮寫1Current存目錄前正在修改 的內容V6.0PBL源碼SQLSQL文件DOC詳細設計、數(shù)據(jù) 結構HTML幫助文件BMP圖像文件V6.0.01按版本號依次類推模塊縮寫2與模塊1相同o O Oo O O模塊縮寫n文檔（G:）Require用戶需求記錄版本號在文件名上 標識DesignV6.0總體設計文檔按版本號依次類推V6.0.1TestRecord測試記錄版本

8、號在文件名上 標識CaseV6.0測試用例V6.0.01UserV6.0用戶使用手冊 產品說明手冊V6.0.01PlanProject項目計劃Month月度計劃安裝盤（H：）V6.0ReleaseREL_SRC產品盤或發(fā)伸文檔SETUPV6.0.01.表示正式版本及特殊版本的目錄按以下原則定義：（1） 正始版本：以" V'開頭，版本號放后，主版本號和次主版本號之間的 去掉，明細版本號之前加“-"。舉例如下：版本號目錄名V6.0V60V6.1V61V6.0.01V60-1V6.1.02V61-22) 特殊版本： 目錄名分為常規(guī)名和擴展名兩部分， 常規(guī)部分表示該特殊版本

9、是由哪一個正始版本分支而來，命名方法同正始版本的命名方法。對于擴展名，以“S”開頭，后加一唯一序號。舉例如下：目錄名 意義V60.S01表示由V6.0 分支出的第一個特殊版本V60.S02表示由V6.0 分支出的第二個特殊版本V60-1.S01表示由V6.0.01分支出的第一個特殊版本3) 對于有些事業(yè)部是針對某個具體用戶開發(fā)的特殊版本， 在表示特殊版本的目錄時，常規(guī)部分表示該特殊版本是哪一個正始版本的分支，對于擴展部分，可以把項目名稱作為擴展名。舉例如下：V60. 中信表示由 V6.0 分支出的中信版本2 3 文檔的存放2.3.1 當前版本和歷史版本的存放對于源碼文件，特別增加了一個Curr

10、ent 目錄，存放當前正在開發(fā)與維護的源碼文件，當前未發(fā)布版本的所有數(shù)據(jù)都存放在下。一旦當前版本正式發(fā)行，則當前目錄被修改為相應的歷史目錄。歷史版本是指已經發(fā)行的版本，存放在相應的版本目錄之下，一般不允許改動。2.3.2 開發(fā)文檔的存放根據(jù)各部門自己的情況，將系統(tǒng)用戶需求記錄、總體設計文檔、詳細設計及數(shù)據(jù)結 構文件、測試記錄、用戶手冊等放入相應的目錄下，也可將不同模塊的開發(fā)文檔存放于 不同的模塊中。2.3.3 源代碼的存放源代碼包括如：PBL，PBR，BMP，ICO，CPP，HPP，MAK，PRJ，INI 等相關文件，是未經編譯處理的、不能直接交付使用的產品文件以及編譯產品所需的文件；聯(lián)機幫助

11、文件HLP在未生成HLP文件之前的DOC RTF等格式的文檔也視為源代碼。各子系統(tǒng)當前的程序源文件放入相應的目錄下。對于一個子系統(tǒng)又分多個分子系統(tǒng)的情況，應在該目錄下分別建立幾個相應的目錄。2.3.4 SQL 語句的存放各子系統(tǒng)SQL文件放入 . .SQL下，對于不同的數(shù)據(jù)庫，分別建立不同的子目錄，如 WAT SYB MSS ORC DB2等。公共SQL文件直接放入 SQL下即可，不同 數(shù)據(jù)庫的特殊SQL分別放入對應的子目錄下。2.3.5 發(fā)行文檔的存放發(fā)行文檔是指產品交付用戶使用所必須的文件。包括：產品可執(zhí)行文件，用戶使用說明書，聯(lián)機幫助（HLB;資源文件（BMP ICO等），環(huán)境配置文件等

12、。以上文檔作為制作發(fā)行盤的素材，放在 RELEASE REL_SR（g錄之下，制作好的發(fā) 行盤放在RELEASED SETUPS錄。2 4 權限控制管理為保障文檔的安全性，一致性，以及防止意外修改，必須對不同的文檔設置不同的訪問權限。文檔權限類別：只讀權限，讀寫權限。文檔類別：設計文檔，源碼，發(fā)行文檔。用戶類別：開發(fā)人員、測試人員、分析設計人員、部門經理、配置管理員、安裝盤制作人員、問題及需求管理人員、用戶文檔編寫人員等。為了控制不同的使用權限，根據(jù)要求在服務器上分別建立不同的用戶，針對不同的配置項所在目錄分配不同的權限。為了便于各產品部、事業(yè)部的管理，應以表格的形式列出人員與管理對象的訪問關

13、系（用戶權限清單） 。3更新管理3 1 源程序的修改當開發(fā)小組在開發(fā)同一產品時，應能保障：各成員間的修改不會互相覆蓋；程序員的修改能及時反映到產品的最新版本中。建議首先在相應子系統(tǒng)的下一級建一目錄，如 checkout ，存放正在修改的文檔及修改登記表。當某個程序員要修改某一文檔時，遵循以下程序：1、接收維護任務；2、查看需要修改的文件（如 PBL及SQL等）是否正在被其它人員修改（檢查 checkout 目錄下是否存在要修改的文件或后綴已改為該程序員姓名簡寫） ； 3、如果有人在修改該文件，等待或與相應的開發(fā)員聯(lián)系，重復2。否則繼續(xù)；4、將該文件復制到checkout 目錄下，在修改登記表中

14、登記；或將該文件的后綴改為本人姓名簡寫；5、將該文件考至自己的私有目錄；6、根據(jù)要求修改源文件；7、根據(jù)要求測試，并進行相關項的回歸測試；8、交測試人員測試，如未通過，重復 6。如通過則繼續(xù)；9、在checkout目錄中刪除該文件，并在修改登記表中標注修改完成；10、將修改完畢的文件通過電子郵件或其它手段送交版本管理員，版本管理員將文件復制到相應的路徑；如遇特殊情況(版本管理員出差)，程序員可將修改完畢的文件復制到相應的路徑下，或將后綴改回正式。11、回復下達者，報告維護任務完成。駐外開發(fā)時，也采用以上程序進行控制。3. 2已發(fā)布版本的維護及修改在正式版本發(fā)布后，由于軟件錯誤或其它問題(如用戶

15、提出增加小功能)需要對程序進行修改時，應及時作出修補盤(可以軟盤或其它的形式),0(1)在該發(fā)布版本目錄下建立一該版本的修補目錄，該目錄由版本管理員負責。(2)各系統(tǒng)如果修改了部分錯誤或增強了部分功能，應將修改或增加的編譯后程 序文件交由版本管理員，由管理員將該程序文件加入到該目錄下，并更及時 更新到安裝盤中去。(3)維護人員在更改產品的程序錯誤，如增加小的模塊，或做小的改進時，應將 程序文件及時通知版本管理員，由版本管理員負責更新源程序。維護人員應 詳細記錄修改內容。舉例如下：修改時間產品代號或名稱以及版本號修改原因修改的模塊；受影響的模塊是否修改了表結構，修改了哪些表結構對應的修改申請表單

16、號修改負責人該表存放在相應版本的根目錄下。(4)修改過的源程序要經過測試人員的測試。事業(yè)部如沒有專人測試，可由程序 員自己測試。(5)對于涉級數(shù)據(jù)結構的程序變動，原則上不作為修補的內容，它只對某些用戶 有用，將可能在下一版本中體現(xiàn)，具體情況要具體處理。3. 3外出人員對產品的修改外出人員對產品的修改，是指以下幾種情況:(1)外出維護時，需要對產品進行修改；(2)實施工程時，針對客戶要求，對產品進行用戶個性化修改(在這種情況下， 一般需要衍生出特殊版本)。執(zhí)行程序：(1)維護人員每當接到實施或維護任務時， 若需修改源代碼，應在啟程前認真填寫 源程序修改申請表，交部門負責人認定后，維護人員可攜帶源

17、程序到用戶現(xiàn)場。(2)在維護期間，確實由于維護需要而必須在用戶設備上拷入源程序時，應確保源程序的安全性，并及時予以刪除。(3)在維護期間若修改了源程序或用戶提出了新的問題， 維護人員必須認真填寫源 程序更新登記表。(4)回公司后，版本管理員應負責和監(jiān)督相關人員將所有文檔復制到規(guī)定目錄之 下，并完善相關的所有文檔，相關的文檔包括：源程序更新登記表、用戶程序 更改日志和修改申請表。將更新登記表及所更新的源程序數(shù)據(jù)交由部門版本管 理人員確認并審定。如果是已發(fā)布版本的源程序，必須由版本管理員負責更新； 非對外發(fā)布的版本如特殊版本可由程序員自己更新， 但版本管理員應及時進行 備份，保證源程序為最新。(5

18、)修改過的源程序要經過測試人員的測試。 事業(yè)部如沒有專人測試，可由其他程 序員或本人自己測試。(6)將更新登記表交由部門負責人簽字確認。(7)將更新登記表交由部門版本管理人員存檔。(8)部門配置管理員及時通知相關程序員。修改申請表樣例:申請時間用戶名稱版本號問題簡單描述申請人簽字負責人簽字源程序更新登記表樣例：源程序更新登記表編號：年 月日 填表人單位名稱地址版本情況問 題 描 述編P描述內容（包括：模塊問題現(xiàn)象問題原因）實際修改編R修改時間修改內容遺留問題*更.新編R是否更新更新時間版本管理 員簽字備注：部門經理 簽字注：更新欄由部門版本管理寫53. 4版本升級3.4.1版本升級原則版本升級

19、應嚴格納入版本管理的控制之下。應當謹慎地控制版本的升級，保障高版 本的向下兼容性，或提供嚴格定義的升級方法。在下面幾種情況下，進行版本演化和升級：1、當產品發(fā)生重大修改和改進時，主版本號加 1。重大修改和改進包括：1）平臺遷移；2）開發(fā)工具的遷移；3）體系結構的變遷。2、當產品發(fā)生較小的改進或修改時，次版本號可以加1。3、對于改動量比較少的，如修改產品的錯誤，可增加內部版本號。內部版本號對用戶來說是不可見的，只對事業(yè)部內部版本控制有用。4、記錄版本升級過程。每次版本升級，都要填寫版本升級記錄表，記錄表樣例如下:版本升級記錄表版本號發(fā)布日期修改文件問題簡要描述發(fā)布責任人批準人備注說明：版本號：

20、記錄當前發(fā)布的版本。發(fā)布日期：該版本批準發(fā)布的日期。修改文件：版本修改記錄文件，一般為版本修改日志3.4.2 新版本的發(fā)布新版本的發(fā)布包括主版本號和次版本號的升級，一般不包括內部版本號的升級。流程如下：1、接收新版本發(fā)布任務，接收本次發(fā)布的版本代號。2、在指定目錄中，根據(jù)本次發(fā)布的版本號建立相應的子目錄，將 current下的 所有內容拷貝至新建目錄下。3、可在新建目錄下建立readme.txt ,并加入相應的內容。4、下達安裝盤制作指令。readme.txt文件是記錄該版本與上一版本的不同，作過哪些改動。格式樣例如下:增加或修改功能涉及源文件改動原因3.4.3 安裝盤制作步驟1 .接收安裝盤制作指令。2 .編譯源程序。3 .制作升級SQL4 .測試升級程序。5 .根據(jù)版本號在安裝盤目錄下建立新版安裝盤目錄。6 .在新建目錄下制作安裝盤