工程型軟件項(xiàng)目的配置管理實(shí)例

工程型軟件項(xiàng)目的配置管理實(shí)例

配置管理雙槍將VSS+SOS

“UserKeys”頁面用來生成客戶端訪問操縱的Key文件：

使用“AddKey..."按鈕能夠彈出“AddUserKey”的對話框。該對話框的第一個輸入框要求輸

入要增加的用戶在VSS中對應(yīng)的用戶名；第二個輸入框要求輸入SOS服務(wù)器的IP地址，

比如“8”，在局域網(wǎng)中能夠設(shè)置為“192或68.1.1"；（注意,假如配置管理服務(wù)器同

時具有局域網(wǎng)與廣域網(wǎng)的IP地址，同時用戶需要從局域網(wǎng)與廣域網(wǎng)都能夠訪問SOS,則對

同一個用戶需要兩個不一致的Key文件。在我們的實(shí)際工作中，我們只使用SOS進(jìn)行Iniernet

上的訪問，在局域網(wǎng)內(nèi)還是使用VSS,因此沒有這個問題）。下面的Expiration要求輸入用

戶的過期有效時間期限，選擇“KeyNeverExpired”同意用戶水只是期。

輸入完相應(yīng)信息后，點(diǎn)擊“0K”確認(rèn)生成用戶Key文件，生成的用戶Key文件儲存在SOS

安裝目錄下，文件名為［用戶名］.汰y,注意保留此文件，SOS客戶端在啟動時需要首先導(dǎo)入

一個key文件。

“WebProject”頁面用于設(shè)置WebProject的公布路徑：

在第一個編輯框中填入該工程在VSS中的路徑，比如“$/WcbProjcctl/test”，在下面的編輯

框中輸入公布的路徑，比如"d:\tcmp”。公布路徑也能夠是在其他機(jī)器上的網(wǎng)絡(luò)路徑。

“Debug”頁面是兩個調(diào)試級別的選項(xiàng)：

這兩個選項(xiàng)的具體含義在SOS的Manual中也沒有明確提到，我們在實(shí)際運(yùn)用中也沒有發(fā)

現(xiàn)該選項(xiàng)的具體作用，建議不選取。

“ExcludedFileTypes”頁面設(shè)置不同意添加到VSS庫中的文件類型：

添加的條目是文件后綴，具有在列表中的后綴的文件都不能被添加到VSS庫中。

“PinSupporl”頁面用于設(shè)置是否同意PIN操作:

假如同意“PIN”操作，還需要指定ss.exe文件所在的目錄。

設(shè)置完成后，需要重新啟動SOS服務(wù)端，具體方法是在“服務(wù)''中啟動相應(yīng)服務(wù)：啟動服

務(wù)完成后，服務(wù)端的安裝設(shè)置就已經(jīng)完成了，接卜.來我們介紹SOS客戶端的安裝與使用。

SOS客戶端的安裝與使用

SOS的客戶端分為Windows版本、Solaris版本與Linux版本。Windows版本的安裝非常簡

單，直接執(zhí)行安裝程序就能夠順利安裝。Solaris版本的SOS客戶端以前形式公布，首先在

Solaris上安裝GTK與GLIB,然后展開安裝程序到任意目錄即可。對Linux版本的SOS客

戶端,也需要首先安裝GTK與GLIB,然后展開相應(yīng)tar包到任意目錄即可。

Solaris>Linux與Windows版本的SOS客戶端運(yùn)行界面都非常類似，下面以Windows版本

為例說明其使用。

第一次運(yùn)行SOS客戶端時，系統(tǒng)會彈出一個對話框要求輸入服務(wù)器與端口號。這時用

“Cancel”按鈕取消，選擇菜單項(xiàng)的“Tools”------“ImportEncryptionKey…”，導(dǎo)入服務(wù)端生成的

Key文件:

導(dǎo)入完成后,選擇菜單項(xiàng)的“File"——"ConnecttoServer...輸入服務(wù)器IP地址與端口,

假如連接成功，系統(tǒng)會給出能夠連接的數(shù)據(jù)庫列表，能夠從列表中選擇合適的數(shù)據(jù)庫進(jìn)行連

接訪問。

連接成功后，顯示的主界面與VSS的基本一致，SOS的操作方式與VSS的也一樣，具體

能夠參見VSS的文檔。

下圖是SOS的主界面：

當(dāng)然，SOS在操作上也有一些與vss不一致的地方，下面列出這些不一致點(diǎn)：

1、缺省設(shè)置卜，SOS中每次登錄不可能主動刷新工程樹與文件列表，需要用工具條上的

刷新按鈕進(jìn)行刷新；

2、SOS的“Search”功能較VSS弱，只能查找CheckOut的文件；

3、SOS的Oplion設(shè)置項(xiàng)目很多，大部分都是SOS增加的為習(xí)慣遠(yuǎn)程連接的設(shè)置項(xiàng)：

Options

ExternalProcruts|Fil?Typ?s]Comn?ndDial。/

Gmtral|View|Files]HTTPProxy

rSendKeep7Aliyesi-er：|l

Dopuble-clickon?|Ask

rustconprcssionford&t<trw

rActonproject，recurs

MakeSourctOffSiteyourdeftuliSCCProvic

需定|取消|

【小結(jié)】本章介紹了VSS、SOS的使用，重點(diǎn)是SOS的安裝與使用方法。SOS在使用上

事實(shí)上還有很多小技巧，在此不能一一列舉，在sourcegear的網(wǎng)站上都能找到有關(guān)的資料。

在下一章中，我們將結(jié)合配置管理工具介紹配置管理規(guī)范的內(nèi)容。

配置管理規(guī)范

配置管理規(guī)范

關(guān)于-一個通常的項(xiàng)目來說，配置管理規(guī)范的內(nèi)容至少需要包含下列的內(nèi)容:

1、配置項(xiàng)及其命名規(guī)則；

2、配置庫文件目錄結(jié)構(gòu)；

3、角色與權(quán)限定義；

4、配置項(xiàng)變更流程；

5、配置項(xiàng)公布；

6、基線定義與基線變更。

配置項(xiàng)及其命名規(guī)則

對我們的項(xiàng)FI來說，配置項(xiàng)需要包含下列的內(nèi)容：

1、項(xiàng)目管理過程文檔；

a）項(xiàng)目任務(wù)書；

b）項(xiàng)目計劃；

c）項(xiàng)目周報；

d）個人日報與周報；

e）項(xiàng)目會議紀(jì)要；

f）培訓(xùn)記錄與培訓(xùn)文檔；

2、QA過程文檔；

a）QA不符合報告：

b）QA周報；

c）評審記錄；

3、工作產(chǎn)品

a）需求文檔；

b）設(shè)計文檔；

c）代碼；

d）測試文檔;

e）軟件說明書與手冊；

4、項(xiàng)目中使用的第三方產(chǎn)品

上文中用紅色部分標(biāo)識的是容易遺漏的配置項(xiàng)，特別是第4個（項(xiàng)目中使用的第三方產(chǎn)

品），實(shí)際上，一個工程型的項(xiàng)目會大量使用第三方的軟件（比如，我們的產(chǎn)品中就使用了

IBM的MQSeries、Oracle、一些第三方的開發(fā)控件），對這些產(chǎn)品的管理至少能夠解決三個

方面的問題：

1、版本配合的問題：大部分的第三方軟件在升級之后，并不能實(shí)現(xiàn)二進(jìn)制層面上的兼

容，需要對原有的代碼重新編譯；甚至有的第三方軟件在升級之后，API層面上的兼容性都

做不到；因此，在工程實(shí)施的過程中，版本的配合問題是一個需要關(guān)注的問題；

2、公布的完整性問題：通常來說，比較大型的第三方軟件在公布過程中都不可能有遺

漏，但對一些小的第三方軟件來說，比如我們使用的許多perl的CPan模塊，假如在開發(fā)過

程中沒有有意識的進(jìn)行管理的話，很容易就會發(fā)生遺漏；

3、在某些特殊條件下由于第三方軟件的變化引起的基線變更：這種情況極少會發(fā)生，

但在我們往常的項(xiàng)H中，確實(shí)還遇見過。通常是由于原先選型時使用的第三方軟件不能滿足

要求，只能通過更換新的第三方軟件，這就補(bǔ)課避免地需要變更基線（比如需求文檔、設(shè)計

文檔等）；將第三方軟件納入配置管理的范疇能夠更方便地管理基線的變更。

關(guān)于第三方軟件產(chǎn)品釀置項(xiàng)的管理還有一點(diǎn)需要說明：白于第三方軟件有可能會比較大，而

且相對我們的項(xiàng)目來說，是很少會發(fā)生變更的（通常在一個項(xiàng)目過程中，不可能使用不一致

的配置項(xiàng)的命名能夠便于杳找有關(guān)配置項(xiàng)。配置項(xiàng)的命名包含兩個方面的內(nèi)容：

1、配置項(xiàng)標(biāo)識：在我們的項(xiàng)目中，通常使用“項(xiàng)占名_配置類別一配置項(xiàng)特殊標(biāo)識”來

命名。下表列出了我們在項(xiàng)目中使用的配置類別命名：

配置類別命名配置類別令名

項(xiàng)目任務(wù)書PT項(xiàng)目計劃PP

項(xiàng)目周報PR個人口報與周報PER

項(xiàng)目會議紀(jì)要PM培訓(xùn)記錄與培訓(xùn)文檔TR

QA不符合報告QAFQA周報QAR

評審記錄KR需求文檔REQ

設(shè)計文檔DD代碼CODE

測試文檔Tl)軟件說明書與手冊

項(xiàng)目中使用的第三方產(chǎn)品PART3

配置項(xiàng)命名中的“配置項(xiàng)特殊標(biāo)識”根據(jù)配置類別的不一致而不一致。比如，對“設(shè)計

文檔”，假如細(xì)分的話，能夠分為“概要設(shè)計”與“全面設(shè)計”；對“代碼”，能夠按照模

塊來命名配置項(xiàng)。

2、配置項(xiàng)版本命名：配置項(xiàng)版本命名是針對配置項(xiàng)的版本進(jìn)行命名，在我們的項(xiàng)目中，

配置項(xiàng)版本通過對Project的Label操作來實(shí)現(xiàn)，配置項(xiàng)版本的命名需要能清晰標(biāo)識配置項(xiàng)

的狀態(tài)。通常說來，配置庫至少包含個人工作區(qū)、受控摩、公布區(qū)三個部分，在我們的項(xiàng)目

中，所有的配置項(xiàng)都儲存在一個VSS庫中，對這三個部分的劃分是通過邏輯劃分方式進(jìn)行的，

具體來說，就是通過配置項(xiàng)版本命名來劃分的。因此，我們配置項(xiàng)的版本命名規(guī)定如下：

a）基線版本：按照基線的狀態(tài)，我們這個項(xiàng)目中的基線有兩個方面：一是作為里程碑

的基線；另一個是模塊的階段性成果基線（對工作產(chǎn)品而言），由模塊的負(fù)責(zé)人確定。

里程碑基線一一對我們的項(xiàng)目來說，使用的是迭代的開發(fā)過程，以一個迭代過程為

例，分為需求、概要設(shè)計、全面設(shè)計、代碼實(shí)現(xiàn)、單元測試、集成測試、系統(tǒng)測試七個階段,

每個階段都需要產(chǎn)生里程碑。對每個里程碑都有明確的標(biāo)識標(biāo)明當(dāng)前狀態(tài)。

階段性成果基線一一階段性成果要緊表達(dá)在代碼過程中，比如代碼進(jìn)行到一個階

段，開發(fā)組長認(rèn)為代碼的這個狀態(tài)能夠保留，就能夠確定為一個代碼基線。這種基線通常不

需要通過評審等正式手段來確定，但也務(wù)必有相應(yīng)的驗(yàn)證手段：比如在我們的項(xiàng)目中，在代

碼階段，確定代碼基線的責(zé)任人是開發(fā)組長,但開發(fā)組長務(wù)必保證代碼基線符合一定的條件。

b）其他版本：除基線版本外，有的時候候還需要在開發(fā)與保護(hù)過程中確定其他版本。

比如，產(chǎn)品在測試過程中不斷的問題修復(fù)過程中，可能會有多種反復(fù)，如今需要將每次修改

的內(nèi)容作為一個版本。

關(guān)于版本，還有另一個需要注意的問題。通常來說，按照模塊來劃分，每個模塊有自己

的版本演進(jìn)比較合理。首先，一個模塊通常是由一個或者兩個開發(fā)人員完成的；其次，一個

模塊的功能會比較單一且獨(dú)立，在版本的演化過程中便亍操縱，也不可能與其他模塊產(chǎn)生過

于復(fù)雜的關(guān)系。而產(chǎn)品的版本則需要由各個模塊的不一致版本構(gòu)成，這個縱橫的關(guān)系需要很

好地管理，我們的做法是在VSS庫上用Label來標(biāo)識，同時保護(hù)?張描述產(chǎn)品版本與模塊版

本關(guān)系的矩陣圖便于追蹤，

配置庫目錄結(jié)構(gòu)

在確定了配置項(xiàng)之后，就能夠確定配置庫的目錄結(jié)構(gòu)了。配置庫的FI錄結(jié)構(gòu)百.接關(guān)系到

配置管理的工作量與使用的方便性，因此需要根據(jù)自己的需要確定一個合理的結(jié)構(gòu)。

在確定配置管理庫目錄結(jié)構(gòu)的時候，我們曾經(jīng)考慮過兩種產(chǎn)品目錄結(jié)構(gòu)的方式：一種是

按照模塊劃分，在模塊下再劃分諸如設(shè)計文檔、代碼等目錄；另一種方式是按照產(chǎn)品類型劃

分，比如首先是文檔、代瑪，然后在其下按照模塊劃分。這兩種方式都有自己的優(yōu)點(diǎn)，最終

我們還是選擇了前一種劃分方式，一方面是考慮便于進(jìn)行權(quán)限的分配，另一方面是考慮到便

于將同一模塊的所有內(nèi)容組織起來進(jìn)行版本的管理。

下表是我們在實(shí)際中使用的配置庫結(jié)構(gòu)（部分）：

第一級第二級第三級第四級說明

\\管理類文檔

PM項(xiàng)目管理

0—Init初始階段

)C

)TR

PN

1—Plan計劃階段

??????????????????

QA

O-PPQAP質(zhì)量保證計劃

??????

P項(xiàng)目產(chǎn)品

0—Req需求階段

O-CRS客戶需求

1-SRS需求分析文檔

2-RTM需求跟蹤矩陣

1—Des設(shè)計階段

O-HLD概要設(shè)計

1-DBD數(shù)據(jù)庫設(shè)計

2—Imp實(shí)現(xiàn)/‘編碼階段

0—Modulel模塊1

O-COD代碼

1-DDS全面設(shè)計

2-HLD概要設(shè)計

3-UNT單元測試

??????

3—Test

0—Int集成測試

1-Syt系統(tǒng)測試

..............

4—Man手冊

.......

5—Others其他

從這里的配置庫結(jié)構(gòu)中能夠看到，我們在最上層將配置項(xiàng)分為管理類與產(chǎn)品類：管理類

中的項(xiàng)目管理部分基本是按照初始一計劃一執(zhí)行一收尾四個階段來劃分。在項(xiàng)目產(chǎn)品類別

中，我們按照需求一設(shè)計一實(shí)現(xiàn)一測試四個階段劃分目錄，在實(shí)現(xiàn)階段，為每個模塊劃分了

代碼、全面設(shè)計、概要設(shè)計與單元測試四個目錄，需要說明的是，在第三層中有一個HLD

的目錄，在模塊下同樣有一個HLD的目錄，在我們的實(shí)際工作中，第三層的HLD目錄用來存

放系統(tǒng)級別的概要設(shè)計文檔，而模塊下的HLD目錄用來存放模塊級別的概要設(shè)計文檔。

當(dāng)然，這里的配置庫結(jié)構(gòu)僅僅起到了示范作用，在實(shí)際使用中，能夠根據(jù)自己的需要修改。

比如，在Module的級別上能夠增加一個Subsystem的層，便于在產(chǎn)品集成時更加方便。

角色定義及權(quán)限分配

角色是配置管理流程的執(zhí)行者與參與者，定義明確的角色有利于實(shí)現(xiàn)明確的授權(quán)與明晰

的流程，盡管在實(shí)際中可能多個角色由一個人擔(dān)任，但還是應(yīng)該保留角色的定義。

下面是該項(xiàng)目中我們的角色定義：

配置管理員

整個配置管理庫由配置管理員管理。配置管理員負(fù)責(zé)分配與修改其他成員的權(quán)限，要保

護(hù)所有目錄與配置項(xiàng)。

開發(fā)經(jīng)理

開發(fā)經(jīng)理在本項(xiàng)目中負(fù)責(zé)主導(dǎo)完成需求分析與系統(tǒng)總體設(shè)計，對項(xiàng)目的總體進(jìn)度負(fù)責(zé)。

開發(fā)經(jīng)理擁有對管理類文檔的讀取權(quán)限，能夠?qū)?xiàng)目類文檔進(jìn)行讀寫操作；

開發(fā)組長

開發(fā)組長對本小組的工作負(fù)有組織與管理任務(wù)，同時開發(fā)組長也需要承擔(dān)一定的開發(fā)任

務(wù)。開發(fā)組長對管理類文檔有讀取權(quán)限，對本組負(fù)責(zé)的模塊有讀取權(quán)限，對自己負(fù)責(zé)佗模塊

有讀寫的權(quán)限；

開發(fā)工程師

開發(fā)工程師完成具體的開發(fā)任務(wù)，對自己負(fù)責(zé)的模塊目錄有讀寫權(quán)限，對管理類文檔有

讀取權(quán)限；

測試組長

測試組長負(fù)責(zé)組織測試，給出測試計劃與測試方案，并核定測試報告。測試組長對所有

目錄都有讀取權(quán)限，對測試目錄有讀寫權(quán)限；

測試工程師

測試工程師負(fù)責(zé)完成測試工作，包含測試用例開發(fā)與測試執(zhí)行，測試報告編寫。測試工程師

對自己負(fù)責(zé)的模塊有讀取權(quán)限，對測試用例目錄有讀寫權(quán)限。

QA工程師

QA工程師擁有對所有目錄的讀取權(quán)限，擁有對QA類文檔目錄的讀寫權(quán)限。

1說明）除配置管理員外，其他所有成員都沒有Destroy目錄與文件的權(quán)限，這是為了防止

誤刪除操作帶來不可挽回的缺失。假如需要對目錄進(jìn)行Destroy操作，務(wù)必由配置管理員進(jìn)

行。

【小結(jié)】在本章中，我們介紹了配置管理規(guī)范的配置項(xiàng)及其命名、配置庫的目錄結(jié)構(gòu)與配置

管理的角色權(quán)限分配。在下?章中，我們將介紹完配置管理規(guī)范的其他內(nèi)容并給出配置管理

實(shí)施過程中的一些心得體會。

配置項(xiàng)的變更與公布

配置項(xiàng)變更流程

我們所說的配置項(xiàng)變更流程要緊是針對配置項(xiàng)發(fā)生變化的操縱,在我們的項(xiàng)目中分為兩

個部分，首先是對配置項(xiàng)新建、檢入（Checkin）與檢出（Checkout）的規(guī)定；其次是對入

庫的文件類型與大小的規(guī)定：

新建、檢入、檢出及破壞

1、新建：即Add,除特殊情況外，通常不規(guī)定由誰來新建（只要有權(quán)限即可），但盡

量指定每個project只有一人負(fù)責(zé)新建。

2、檢入：即checkin,檢入頻率規(guī)定如下：

i.在代碼編寫前，至少每周一次

ii.代碼編寫階段，至少每天一次

iii.測試階段以后，根據(jù)代碼、文檔的變動，只要當(dāng)天有變動就要檢入一次。

iv.為配合檢查、備份工作,需在檢杳備份周期前全部chockin（不保持checkout）

并退出登錄。詳見“檢杳及備份”部分

3、檢出：即checkout。原則上只對要修改的文檔方可檢出。

4、破壞（Destroy）：通常情況不能夠破壞文件、目錄。

5、假如是誤操作，則可在一天內(nèi)提交管理員處

6、假如超過天，則需要由項(xiàng)IR經(jīng)理同意，且管理員破壞前要備份。

7、各階段環(huán)境職責(zé)

環(huán)境階段負(fù)責(zé)人職責(zé)

每周及需要評審前cheekin工作產(chǎn)品（包含版本公布說

開發(fā)人員

明）到VSS上

編碼前

開發(fā)組長每周

SCM人員每周統(tǒng)計

開發(fā)人員每天checkin工作產(chǎn)品（包含版本公布說明）到vss上

開發(fā)組長每周檢查

編碼

經(jīng)理及組長抽查及走讀

SCM人員每周統(tǒng)計，檢查代碼風(fēng)格

每天工作產(chǎn)品到上（如當(dāng)天沒有修改能夠

公司內(nèi)部checkinvss

不進(jìn)行checkin）

開發(fā)人員

測試以LABEL形式提交一個新版本給測試，附帶版本公布說

明

測試人員對測試完成后的程序打LABEL

將新版本checkin到vss,打測試LABEL,向測試人員提

開發(fā)人員

交申請

公布后測試人員對測試完成后的程序打LABEL

SCM人員對變更做好操縱與記錄，并公布

現(xiàn)場開發(fā)負(fù)責(zé)人將公布后的產(chǎn)版本更新至現(xiàn)場，或者指定人員進(jìn)行

在無法通過sos連到公司vss的情況下，需要在現(xiàn)場建

公司外部編碼現(xiàn)場開發(fā)負(fù)責(zé)人立配置庫（文件方式或者VSS等），做到基本的版本操

縱與備份。每周至少通過SOS提交一次至公司的VS5庫

中。

每天checkin工作產(chǎn)品到現(xiàn)場配置庫（包含版本公布說

現(xiàn)場開發(fā)人員

明）。

做好督促與監(jiān)督工作，每周將現(xiàn)場開發(fā)負(fù)責(zé)人提交的現(xiàn)

SCM人員

場版本更新到公司配置庫（vss）。

每天checkin工作產(chǎn)品到現(xiàn)場配置庫（如當(dāng)天沒有修改

能夠不進(jìn)行checkin）o

如已經(jīng)回公司則每天checkin工作產(chǎn)品到公司配置庫

現(xiàn)場開發(fā)人員VSS（如當(dāng)天沒有修改能夠不進(jìn)行checkin）?,

測試

每周通過SOS提交一個新版本給測試，打測試LABEL,附

帶版本公布說明（如沒有更新可不提交）

對測試完成后的程序打LABEL

SCM人員做好督促與監(jiān)督工作

在無法通過sos連到公司VSS的情況卜\需要在現(xiàn)場建

立配置庫（文件方式或者VSS等），做到基本的版本操

現(xiàn)場開發(fā)負(fù)貢人

縱與備份。每冏至少通過SOS提交一次至公司的VSS庫

中。通過LABEL提交測試版本

公布后

現(xiàn)場調(diào)對修改后的版本通過SOScheckin新版本到vss,打測

試現(xiàn)場現(xiàn)場開發(fā)人員試LABEL,向測試人員提交申請（由修改至提交測試人員

保護(hù)不應(yīng)超過三天）

測試人員對測試完成后的程序打LABEL

對變更做好操縱與記錄，并公布

SCM人員

做好督促與監(jiān)督現(xiàn)場提交更新版本到VSSo

關(guān)于VSS庫內(nèi)存放文件類型及大小的規(guī)定

1、文件名及目錄規(guī)定：以英文名字命名

2、文件大小規(guī)定：最大不超過20M

3、同意類型：

4、表2.1中提至的文檔類

5、代碼及腳本類及為配合編譯需要的類庫等

6、下列類型不同意存放在VSS庫中：

7、備份數(shù)據(jù)

8、安裝程序、打包程序（zip'rar）

9、超過20M以上的非代碼類及開發(fā)文檔類文件

10、關(guān)于特殊情況或者不確定情況，需向配置管理人員咨詢后再加入

11、關(guān)于不同意存放類型的配置類文件，可與配置管理員聯(lián)絡(luò)，隨件附《說明清單》，

以文件型式儲存于服務(wù)器。

配置項(xiàng)公布

配置項(xiàng)公布是指配置項(xiàng)進(jìn)行到一定的階段（比如，旦程碑階段），需要對外公布時的規(guī)

則。在我們的項(xiàng)目中，配置項(xiàng)公布是通過標(biāo)簽，即LABEL,來實(shí)現(xiàn)的。

階段觸發(fā)事件操作人標(biāo)簽類型打標(biāo)簽的級別

單元測試單元測試完成，能夠提交集成測試開發(fā)人員FOR_TEST模塊級

集成測試完成，不通過（如通過進(jìn)入系統(tǒng)

測試人員TESTED模塊級

測試階段）

集成測試

BUG修改完成，能夠提交測試開發(fā)人員FOR.TEST模塊級

集成測試通過，能夠提交系統(tǒng)測試測試負(fù)責(zé)人TESTED模塊級

系統(tǒng)測試完成后，不通過，（如通過進(jìn)入

測試負(fù)責(zé)人TESTED項(xiàng)目級

系統(tǒng)測試階段）

系統(tǒng)測試

BUG修改完成，能夠提交惻試開發(fā)人員I'OK.TEST項(xiàng)目級

系統(tǒng)測試通過測試負(fù)責(zé)人TESTED項(xiàng)目級

驗(yàn)收前的版本，可公布到現(xiàn)場安裝配置管理員LOAD項(xiàng)目級

驗(yàn)收測試

驗(yàn)收后的版本，可公布的正式版本配置管理員LOAD項(xiàng)目級

模塊級/項(xiàng)目級/

修改BUG后提交測試保護(hù)工程師FORTEST

文件級

現(xiàn)場保護(hù)

模塊級/項(xiàng)目級/

測試通過與否測試人員TESTED

文件級

基線確立與變更

基線的確定在上一部分中已經(jīng)說到過，我們的項(xiàng)目基線分為兩類，一類是作為里程碑與

其他工作依靠的基線（比如需求文檔、設(shè)計文檔等），另一類是開發(fā)過程中有必要保留的一

種狀態(tài)（比如代碼過程中某個模塊的一個有保留價值的snapshot）o對這兩種不一致的基

線，其影響的范圍不一致，確立與變更方式也不一樣。

我們項(xiàng)目的基線變更操縱委員會由客戶代表、產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理與技術(shù)經(jīng)理構(gòu)成，對

公布的里程碑類基線的變更務(wù)必由變更操縱委員會確認(rèn)并由QA進(jìn)行變更記錄，所有被變更

影響的配置項(xiàng)都需要重新同步后再次公布；而關(guān)于僅僅作為工件