資料來源：https://www.cnblogs.com/wayne-ivan/articles/525818.html

1　概要

1.1　內(nèi)容

規(guī)范配置管理活動(dòng)，確保配置項(xiàng)正確地唯一標(biāo)識(shí)并易于存取，保證基準(zhǔn)配置項(xiàng)的更改受控，明確基線狀態(tài)，在貫穿整個(gè)軟件生命周期中建立和維護(hù)項(xiàng)目產(chǎn)品的完整性和可追溯性。

1.2　適用范圍

對(duì)于不同類別的軟件項(xiàng)目，配置管理的流程不同，可在本流程的基礎(chǔ)上進(jìn)行裁減。

1.3　術(shù)語和縮略語

1.3.1　軟件配置管理（Software Configuration Management，SCM）

軟件配置管理是對(duì)軟件修改進(jìn)行標(biāo)識(shí)、組織和控制的技術(shù)，用來協(xié)調(diào)和控制整個(gè)過程。是通過技術(shù)或行政手段對(duì)軟件產(chǎn)品及其開發(fā)過程和生命周期進(jìn)行控制、規(guī)范的一系列措施。配置管理的目標(biāo)是記錄軟件產(chǎn)品的演化過程，確保軟件開發(fā)者在軟件生命周期中各個(gè)階段都能得到精確的不同版本的產(chǎn)品配置。

1.3.2　配置（Configuration）

配置是在技術(shù)文檔中明確說明并最終組成軟件產(chǎn)品的功能或物理屬性。因此配置包括了即將受控的所有產(chǎn)品特性，其內(nèi)容及相關(guān)文檔、軟件版本、變更文檔、軟件運(yùn)行的支持?jǐn)?shù)據(jù)，以及其他一切保證軟件一致性的組成要素，相對(duì)與硬件類配置，軟件產(chǎn)品的配置包括更多的內(nèi)容并具有易變性。

1.3.3　配置項(xiàng)（Configuration Item，CI）

凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項(xiàng)（Configuration Item, CI），配置項(xiàng)邏輯上組成軟件系統(tǒng)的各組成部分，一般是可以單獨(dú)進(jìn)行設(shè)計(jì)、實(shí)施和測(cè)試的。一個(gè)純軟件的CIs通常也稱之為軟件配置項(xiàng)（Computer Software Configuration Items，CSCIs）。

配置項(xiàng)主要有兩大類：

1)屬于產(chǎn)品組成部分的工作成果，例如需求文檔、設(shè)計(jì)文檔、源代碼、測(cè)試用例等；

2)項(xiàng)目管理和機(jī)構(gòu)支撐過程產(chǎn)生的文檔。這些文檔雖然不是產(chǎn)品的組成部分，但是值得保存。

每個(gè)配置項(xiàng)的主要屬性有：名稱、標(biāo)識(shí)符、文件狀態(tài)、版本、作者、日期等。所有配置項(xiàng)都被保存在配置庫(kù)里，確保不會(huì)混淆、丟失。配置項(xiàng)及其歷史記錄反映了軟件的演化過程。

1.3.4　基線（Baseline）

在配置管理系統(tǒng)中，基線就是一個(gè)CI或一組CIs在其生命周期的不同時(shí)間點(diǎn)上通過正式評(píng)審而進(jìn)入正式受控的一種狀態(tài)，些配置項(xiàng)構(gòu)成了一個(gè)相對(duì)穩(wěn)定的邏輯實(shí)體，而這個(gè)過程被稱為“基線化”。每一個(gè)基線都是其下一步開發(fā)的出發(fā)點(diǎn)和參考點(diǎn)。基線確定了元素（配置項(xiàng)）的一個(gè)版本，且只確定一個(gè)版本。一般情況下，基線一般在指定的里程碑（Milestone）處創(chuàng)建，并與項(xiàng)目中的里程碑保持同步。每個(gè)基線都將接受配置管理的嚴(yán)格控制，基線中的配置項(xiàng)被“凍結(jié)”了，不能再被任何人隨意修改，對(duì)其的修改將嚴(yán)格按照變更控制要求的過程進(jìn)行，在一個(gè)軟件開發(fā)階段結(jié)束時(shí)，上一個(gè)基線加上增加和修改的基線內(nèi)容形成下一個(gè)基線。

基線的主要屬性有：名稱、標(biāo)識(shí)符、版本、日期等。通常將交付給客戶的基線稱為一個(gè)“Release”，為內(nèi)部開發(fā)用的基線則稱為一個(gè)“Build”。

建立基線的好處：

1)重現(xiàn)性：及時(shí)返回并重新生成軟件系統(tǒng)給定發(fā)布版的能力，或者是在項(xiàng)目中的早些時(shí)候重新生成開發(fā)環(huán)境的能力。當(dāng)認(rèn)為更新不穩(wěn)定或不可信時(shí)，基線為團(tuán)隊(duì)提供一種取消變更的方法。

2)可追蹤性：建立項(xiàng)目工件之間的前后繼承關(guān)系。目的是確保設(shè)計(jì)滿足要求、代碼實(shí)施設(shè)計(jì)以及用正確代碼編譯可執(zhí)行文件。

3)版本隔離：基線為開發(fā)工件提供了一個(gè)定點(diǎn)和快照，新項(xiàng)目可以從基線提供的定點(diǎn)之中建立。作為一個(gè)單獨(dú)分支，新項(xiàng)目將與隨后對(duì)原始項(xiàng)目（在主要分支上）所進(jìn)行的變更進(jìn)行隔離。

2　相關(guān)人權(quán)責(zé)

2.1　項(xiàng)目經(jīng)理（Project Manager，PM）

責(zé)任：

1)與CCB協(xié)商確定項(xiàng)目起始基線和開發(fā)里程碑；

2)接受配置管理計(jì)劃，并按相關(guān)規(guī)定貫徹執(zhí)行；

3)接受配置控制委員會(huì)的報(bào)告。

權(quán)利：

1) 提出配置管理計(jì)劃的修改要求；

2) 提出管理管理的建議和要求。

2.2　配置控制委員會(huì)（Configuration Control Board，CCB）

責(zé)任：

1) 制定和修改項(xiàng)目的配置管理策略；

權(quán)利：

1) 批準(zhǔn)、發(fā)布配置管理計(jì)劃；

2) 建立、更改基線的設(shè)置，審核變更申請(qǐng)；

3)根據(jù)配置管理員的報(bào)告決定相應(yīng)的對(duì)策。

2.3　配置管理員（Configuration Management Officer，CMO）

責(zé)任：

1)編制配置管理計(jì)劃；

2)執(zhí)行配置項(xiàng)管理方案；

3) 執(zhí)行版本控制和變更控制方案；

4)編制配置狀態(tài)報(bào)告；

權(quán)利：

向CCB匯報(bào)有關(guān)配置管理流程中的不符合情況。

2.4　程序庫(kù)管理員（Program Librarian，PL）

責(zé)任：

1)配置庫(kù)的建立和權(quán)限分配；

2)配置管理工具的日常管理與維護(hù)；

3) 配置庫(kù)的日常操作和維護(hù)；

權(quán)利：

1)各配置項(xiàng)的管理與維護(hù)；

2)對(duì)開發(fā)人員進(jìn)行相關(guān)的培訓(xùn)。

2.5　開發(fā)人員（Developer）

責(zé)任：

1）根據(jù)確定的配置管理計(jì)劃和相關(guān)規(guī)定，提交配置項(xiàng)和基線；

2）負(fù)責(zé)軟件集成和版本生成。

權(quán)利：

按照軟件配置管理工具的使用模型來完成開發(fā)任務(wù)。

2.6　測(cè)試人員（Tester）

責(zé)任：

根據(jù)配置管理計(jì)劃和相關(guān)規(guī)定，提交測(cè)試配置項(xiàng)和測(cè)試基線；

權(quán)利：

負(fù)責(zé)軟件變更的測(cè)試驗(yàn)證。

2.7　軟件質(zhì)量保證員（Software Quality Assurance，SQA）

責(zé)任：

負(fù)責(zé)配置審核并提交報(bào)告。

權(quán)利：

對(duì)配置審核中發(fā)現(xiàn)的不符合項(xiàng)，要求相關(guān)責(zé)任人進(jìn)行糾正。

3　實(shí)施細(xì)則

3.1　CCB的成立

3.1.1　項(xiàng)目在設(shè)計(jì)發(fā)注后，由項(xiàng)目經(jīng)理負(fù)責(zé)組織成立CCB。

3.1.2　CCB成員組成

CCB成員人數(shù)一般為奇數(shù)，人數(shù)在3～7人范圍內(nèi)。CCB成員一般包括：

1)項(xiàng)目經(jīng)理PM；

2) 配置管理員CMO；

3) SQA；

4) 測(cè)試人員Tester；

5)顧客代表；

6)主要開發(fā)人員等。

3.1.3　CCB的決策機(jī)制

尋求CCB成員的一致意見。若不能達(dá)成一致，可采取由顧客代表做出決策；或采取少數(shù)服從多數(shù)的原則，由CCB成員投票確定，投票超過半數(shù)即為通過。

3.2　確定配置策略

3.2.1　配置策略確定的時(shí)機(jī)

CCB成立后，由CCB組織會(huì)議根據(jù)項(xiàng)目的開發(fā)計(jì)劃確定各個(gè)里程碑和開發(fā)策略，CMO負(fù)責(zé)整理確定的項(xiàng)目基線和配置項(xiàng)列表，并在編制《配置管理計(jì)劃》時(shí)列明，按約定的時(shí)機(jī)收集配置項(xiàng)和建立初始基線。

3.2.2　配置項(xiàng)的范圍

1)技術(shù)文檔（Documents）：項(xiàng)目開發(fā)計(jì)劃、需求分析報(bào)告、軟件設(shè)計(jì)書、質(zhì)量保證計(jì)劃、概要設(shè)計(jì)書、詳細(xì)設(shè)計(jì)書、測(cè)試文檔、技術(shù)報(bào)告、用戶手冊(cè)、總結(jié)報(bào)告等；

2)程序（Program）：階段產(chǎn)品、計(jì)算機(jī)程序、源程序、釋放產(chǎn)品等；

3)工具（Tools）：自動(dòng)設(shè)計(jì)工具、開發(fā)工具、測(cè)試工具、維護(hù)工具等；

4)交互文檔（Communications）：與客戶或項(xiàng)目組內(nèi)交互產(chǎn)生文檔，如會(huì)談?dòng)涗?、E-mail、會(huì)議紀(jì)要、MSN記錄等。

3.3　制定配置管理計(jì)劃

3.3.1　《配置管理計(jì)劃》的編制

通常情況下，由CMO在設(shè)計(jì)發(fā)注后，開始編制《配置管理計(jì)劃》；如有特殊需要，根據(jù)合同或項(xiàng)目要求，由CMO在某一項(xiàng)目或項(xiàng)目的某一階段開始前制定《配置管理計(jì)劃》。

3.3.2　《配置管理計(jì)劃》的內(nèi)容

《配置管理計(jì)劃》應(yīng)包括以下方面的內(nèi)容：

1)該項(xiàng)目對(duì)配置管理的要求；

2) 實(shí)施配置管理的責(zé)任人、組織及其職責(zé)；

3)需要開展的配置管理活動(dòng)及其進(jìn)度安排；

4)采用的方法和工具等。

3.3.3　《配置管理計(jì)劃》的由CCB負(fù)責(zé)審批。

3.4　配置項(xiàng)標(biāo)識(shí)規(guī)則

3.4.1　配置項(xiàng)標(biāo)識(shí)要求

1)合同有明確標(biāo)識(shí)和追蹤要求時(shí)，由開發(fā)人員按合同要求進(jìn)行標(biāo)識(shí)，以保證滿足合同追蹤要求。

2)在開發(fā)過程中項(xiàng)目組人員提交的配置項(xiàng)，由項(xiàng)目組人員按照本節(jié)相關(guān)部分標(biāo)識(shí)規(guī)則進(jìn)行標(biāo)識(shí)。

3) 項(xiàng)目組人員將要標(biāo)識(shí)或已標(biāo)識(shí)的配置項(xiàng)提交給CMO納入配置庫(kù)統(tǒng)一管理，并填寫《配置狀態(tài)報(bào)告》。

3.4.2　配置項(xiàng)標(biāo)識(shí)方式

3.4.2.1　標(biāo)識(shí)項(xiàng)

配置項(xiàng)標(biāo)識(shí)屬性包括：名稱、編號(hào)、文件狀態(tài)、版本、作者、日期等。本文標(biāo)識(shí)規(guī)則對(duì)名稱、編號(hào)、文件狀態(tài)和版本進(jìn)行了描述和規(guī)定。

3.4.2.2　名稱

文件名稱的標(biāo)識(shí)按文檔模板中統(tǒng)一名稱為準(zhǔn)。

a)編號(hào)

文檔編號(hào)格式為CC_XXX_***_$$$_###，其中CC表示公司，XXX是項(xiàng)目的三位英文字母縮寫表示，***_$$$表示文檔類別，###表示文檔順序號(hào)。同時(shí)對(duì)應(yīng)每個(gè)內(nèi)容都有固定的一個(gè)索引文件CC_XXX_**_$$$_index，目的是為了為本類別下的文件建立一個(gè)概要說明列表，保證快速對(duì)文檔進(jìn)行識(shí)別和檢索。

3.4.2.3　文件狀態(tài)

文件狀態(tài)分為“草稿”、“正式發(fā)布”和“修改中”三種。

修改處于“草稿”狀態(tài)的配置項(xiàng)不算是“變更”，無需CCB的批準(zhǔn)，修改者按照版本控制規(guī)則執(zhí)行即可。

當(dāng)配置項(xiàng)的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)”后，此時(shí)任何人都不能隨意修改，必須依據(jù)配置變更控制的規(guī)則執(zhí)行。

3.4.2.4　文檔版本控制

對(duì)于計(jì)劃性文檔、技術(shù)文檔和用戶文檔，其版本按修改的先后順序確定。新生成的文檔第一次發(fā)行為第一版，修改后第二次發(fā)行為第二版，以此類推。

3.4.2.5　發(fā)行版本控制

最終完成的軟件版本用三位符號(hào)表示：“s.x.y”。各符號(hào)位的含義如下：

1)“y”為第二次版本號(hào)，表示糾正錯(cuò)誤時(shí)的版本升級(jí)，用一位數(shù)字表示：“1~9”，對(duì)上一次產(chǎn)品或項(xiàng)目中的缺陷做修正，第二次版本號(hào)增加；

2)“x”為第一次版本號(hào)，表示增加功能時(shí)的版本升級(jí)，用一位數(shù)字表示：“0~9”。與上一產(chǎn)品或項(xiàng)目相比，功能進(jìn)行了小量的增加或修正時(shí)，第一次版本號(hào)增加，第二次版本號(hào)為零，第二版本號(hào)為零時(shí)可以省略不寫；

3) “s”為主版本號(hào)。對(duì)產(chǎn)品作重大調(diào)整，或與已發(fā)行的上一產(chǎn)品相比，在功能與性能上有較大改善時(shí)主版本號(hào)增加；產(chǎn)品或項(xiàng)目概念全新，第一次完成，版本號(hào)為1.0。

3.4.2.6　基線版本標(biāo)識(shí)

內(nèi)部基線，如計(jì)劃基線、設(shè)計(jì)基線等，在版本號(hào)前加Build，如Build 1.0；

發(fā)行產(chǎn)品基線在版本號(hào)前加Release，如Release 2.0。

3.5　配置庫(kù)管理

3.5.1　配置庫(kù)（Repository）的分類

配置庫(kù)分為兩類：

1)文檔庫(kù)（Document Library）：由CMO負(fù)責(zé)管理，主要使用eSM系統(tǒng)管理除程序以外的文檔資料（包括圖片等）；

2)程序庫(kù)（Program Library）：由PL負(fù)責(zé)管理，主要使用CVS版本工具對(duì)程序代碼進(jìn)行管理。

3.5.2　配置庫(kù)的建立

3.5.2.1　CCB成立之后，PL即可著手組織建立配置庫(kù)。所有項(xiàng)目應(yīng)建立配置庫(kù)，以便管理各配置項(xiàng)。

3.5.2.2　文檔庫(kù)空間由eSM系統(tǒng)創(chuàng)建，PL僅創(chuàng)建基線文檔庫(kù)，僅PL可以對(duì)其操作。

3.5.2.3　程序庫(kù)主要通過設(shè)置版本的分支，來實(shí)現(xiàn)對(duì)配置項(xiàng)權(quán)限管理，基本上要為每個(gè)配置項(xiàng)從建立開始就劃分成3個(gè)不同的分支（如圖1）：

圖1　配置庫(kù)空間分配和版本遷移策略

1)私有分支（Private Branch）：私有分支對(duì)應(yīng)的是開發(fā)人員的私有開發(fā)空間。開發(fā)人員根據(jù)任務(wù)分工獲得對(duì)相應(yīng)配置項(xiàng)的操作許可之后，他即在自己的私有開發(fā)分支上工作，他的所有工作成果體現(xiàn)為在該配置項(xiàng)的私有分支上的版本的推進(jìn)，除該開發(fā)人員外，其他人員均無權(quán)操作該私有空間中的元素。

2)集成分支（Integration Branch）：集成分支對(duì)應(yīng)的是開發(fā)團(tuán)隊(duì)的公共空間。凡是要為同組人員共享的配置項(xiàng)都從該分支獲得。即各開發(fā)人員必須將私有工作空間中的開發(fā)成果歸并（Merge）到該分支后才能進(jìn)入下一個(gè)開發(fā)活動(dòng)。所有涉及多人協(xié)調(diào)的開發(fā)工作（如集成測(cè)試等）都必須工作在這一空間中。該開發(fā)團(tuán)隊(duì)擁有對(duì)該集成分支的讀寫權(quán)限，而其他成員只有只讀權(quán)限。該分支的管理工作由PL及相關(guān)指定人員負(fù)責(zé)。

3)公共分支（Common Branch）：公共分支對(duì)應(yīng)的是整個(gè)軟件開發(fā)組織的公共空間。各個(gè)開發(fā)小組在現(xiàn)階段的任務(wù)完成后，將可以發(fā)布的版本歸并到該分支上，將來需要查閱相關(guān)資料時(shí)，以該分支上的版本為準(zhǔn)。該分支對(duì)組織內(nèi)的全體軟件人員開放只讀權(quán)限。該分支的管理工作由PL負(fù)責(zé)。

3.5.2.4　上述定義的3類分支以及文檔庫(kù)由CMO統(tǒng)一管理，根據(jù)各開發(fā)階段的實(shí)際情況定制相應(yīng)的版本選取規(guī)則，來保證開發(fā)活動(dòng)的正常運(yùn)作。在變更發(fā)生時(shí)，應(yīng)及時(shí)做好基線的推進(jìn)。

3.5.3　分配權(quán)限

PL為每個(gè)項(xiàng)目成員分配配置庫(kù)操作權(quán)限。一般地，項(xiàng)目成員擁有Add、 Checkin/Checkout、Download等權(quán)限，但是不能擁有“刪除”權(quán)限。PL的權(quán)限最高。

3.5.4　配置庫(kù)的操作與管理

3.5.4.1　開發(fā)人員根據(jù)獲得的授權(quán)的資源進(jìn)行項(xiàng)目的研發(fā)工作，操作配置庫(kù)，例如Add、Checkin/Checkout、Download等。

3.5.4.2　PL根據(jù)配置管理計(jì)劃創(chuàng)建與維護(hù)基線，“凍結(jié)”配置項(xiàng)，控制變更。

3.5.4.3　配置庫(kù)的檢出

當(dāng)發(fā)生變更且變更評(píng)審?fù)ㄟ^后，或者發(fā)現(xiàn)Bug且Bug評(píng)審?fù)ㄟ^后，由PL將Common Branch中CIs檢出至開發(fā)人員的Private Branch上，供開發(fā)人員進(jìn)行變更。

3.5.4.4　配置庫(kù)的檢入

當(dāng)變更實(shí)施結(jié)束或Bug修正和測(cè)試結(jié)束，并通過配置審核后，由PL將變更后的CIs檢入到Common Branch。

3.5.4.5　PL定期清除配置庫(kù)里的垃圾文件。

3.5.4.6　PL定期備份配置庫(kù)。

3.6　配置項(xiàng)和基線管理

3.6.1　CMO根據(jù)配置管理計(jì)劃，對(duì)配置項(xiàng)和基線進(jìn)行分階段管理。

3.6.2　項(xiàng)目啟動(dòng)

配置項(xiàng)包括需求說明、訂單及其評(píng)審結(jié)果等；項(xiàng)目發(fā)注后應(yīng)封鎖該子項(xiàng)目，建立發(fā)注基線。

3.6.3　需求分析

系統(tǒng)調(diào)研后開發(fā)人員進(jìn)行系統(tǒng)分析，并整理需求分析報(bào)告。需求分析報(bào)告通過評(píng)審并需取得客戶的確定。在需求分析報(bào)告取得客戶的確認(rèn)后，封鎖該子項(xiàng)目，建立需求基線。如需升版則必須通過評(píng)審并得到客戶的確認(rèn)。

3.6.4　項(xiàng)目計(jì)劃

需求分析完成后即可制定項(xiàng)目的開發(fā)計(jì)劃，包括項(xiàng)目總體進(jìn)度說明、進(jìn)度跟蹤、計(jì)劃修改、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、測(cè)試計(jì)劃等。項(xiàng)目開發(fā)計(jì)劃評(píng)審?fù)ㄟ^后，封鎖該子項(xiàng)目，建立項(xiàng)目計(jì)劃基線。

3.6.5　系統(tǒng)設(shè)計(jì)

系統(tǒng)設(shè)計(jì)可分為概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)和數(shù)據(jù)庫(kù)設(shè)計(jì)等部分。針對(duì)需求分析報(bào)告進(jìn)行系統(tǒng)設(shè)計(jì)，配置時(shí)應(yīng)說明系統(tǒng)設(shè)計(jì)的版本與需求分析報(bào)告版本的對(duì)應(yīng)關(guān)系。設(shè)計(jì)書評(píng)審?fù)ㄟ^后，建立設(shè)計(jì)基線。

3.6.6　編碼

編碼按功能模塊分子項(xiàng)目，即每個(gè)模塊計(jì)作一個(gè)配置項(xiàng)。代碼基線分別在單元測(cè)試結(jié)束后建立Alpha版，Alpha測(cè)試后建立Beta版，在集成測(cè)試時(shí)建立Merge后版。

3.6.7　測(cè)試

各測(cè)試階段應(yīng)提供測(cè)試計(jì)劃、測(cè)試用例、測(cè)試結(jié)果和測(cè)試分析報(bào)告，項(xiàng)目啟動(dòng)后應(yīng)提供項(xiàng)目測(cè)試計(jì)劃書，項(xiàng)目驗(yàn)收結(jié)束后應(yīng)提交項(xiàng)目測(cè)試總結(jié)報(bào)告等。配置時(shí)應(yīng)說明測(cè)試的版本與編碼版本的對(duì)應(yīng)關(guān)系。各階段測(cè)試（如單元測(cè)試、集成測(cè)試）完成后建立測(cè)試基線。

3.6.8　交付與驗(yàn)收

在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項(xiàng)，包括交付施工文檔、工具等。

3.6.9　項(xiàng)目總結(jié)

項(xiàng)目總結(jié)應(yīng)經(jīng)過部門內(nèi)部評(píng)審，包括項(xiàng)目質(zhì)量報(bào)告、測(cè)試報(bào)告等。

3.6.10　相關(guān)資料與培訓(xùn)

相關(guān)資料與培訓(xùn)也應(yīng)作為配置項(xiàng)納入配置管理，此部分包括：

1)相關(guān)法律、法規(guī)；

2) 必須遵照或項(xiàng)目組約定的技術(shù)規(guī)范；

3)與客戶或項(xiàng)目組內(nèi)部重要的交互信息記錄，如Question Sheet、會(huì)議記錄、會(huì)談?dòng)涗?、e-mail和MSN記錄；

4)必要的業(yè)務(wù)或技術(shù)培訓(xùn)等。

3.7　配置變更控制

3.7.1　變更的分類

軟件及其相關(guān)文檔的變更按照變更的影響范圍進(jìn)行分類：

1)A級(jí)：變更會(huì)影響系統(tǒng)級(jí)需求、外部接口、產(chǎn)品價(jià)格或者交付期；這類變更必須經(jīng)過CCB審核并有客戶批準(zhǔn)和確認(rèn)。

2)B級(jí)：變更會(huì)影響配置項(xiàng)間的功能接口、組件級(jí)成本或者項(xiàng)目Schedule；這類變更必須由CCB或上級(jí)管理部門的批準(zhǔn)和認(rèn)可。

3) C級(jí)：變更會(huì)影響配置項(xiàng)內(nèi)部功能的設(shè)計(jì)和分配；這類變更可以由配置項(xiàng)的管理人員負(fù)責(zé)批準(zhǔn)。

圖2 變更控制流程

3.7.2　變更請(qǐng)求的提出

3.7.2.1　由發(fā)起者（客戶、最終用戶或開發(fā)部門）確定變更，填寫《變更請(qǐng)求/評(píng)審單》，描述變更原因和變更內(nèi)容，并提交給CMO。

3.7.2.2　CMO對(duì)填寫的申請(qǐng)表是否清晰、明確和完整性進(jìn)行審查，若CMO發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請(qǐng)表給發(fā)起者。CMO對(duì)通過審查的變更申請(qǐng)分配變更ID，以便跟蹤和記錄變更信息。

3.7.3　變更評(píng)估

3.7.3.1　CMO將《變更請(qǐng)求/評(píng)審單》發(fā)送給項(xiàng)目經(jīng)理（或者其他授權(quán)人員），由項(xiàng)目經(jīng)理負(fù)責(zé)對(duì)變更進(jìn)行評(píng)估。

3.7.3.2　變更控制的一個(gè)重要環(huán)節(jié)就是變更評(píng)估，變更評(píng)估要分析每個(gè)變更對(duì)系統(tǒng)功能、接口、成本、進(jìn)度以及約定需求的影響，同時(shí)還要分析對(duì)軟件安全性、可靠性、可維護(hù)性、可移植性和性能的影響。

3.7.3.3　變更評(píng)估產(chǎn)生的文檔應(yīng)描述若實(shí)施變更必須變更的配置項(xiàng)、文檔和資源；變更評(píng)估文檔在完成變更評(píng)估后發(fā)送給CMO。

3.7.3.4　CMO收到評(píng)估后的《變更請(qǐng)求/評(píng)審單》后，更新變更記錄，并安排CCB會(huì)議日程。

3.7.4　變更審核

3.7.4.1　CCB對(duì)提交的變更申請(qǐng)進(jìn)行審核，并根據(jù)變更評(píng)估確定變更的影響級(jí)別；CCB審核可能的結(jié)果有三種：接受變更；拒絕變更；延期變更。CCB也可能需要更多的變更分析的信息。

3.7.4.2　CCB批準(zhǔn)的變更，由CMO將變更項(xiàng)目發(fā)送到指定的開發(fā)人員（Assigner）進(jìn)行下一步的實(shí)施變更工作；對(duì)于拒絕的變更，由CMO將CCB拒絕變更的原因發(fā)送給發(fā)起者，并保存《變更請(qǐng)求/評(píng)審單》，更新變更記錄，關(guān)閉變更活動(dòng)；需要進(jìn)一步分析的，由CMO將變更項(xiàng)目隨同CCB的Question Sheet發(fā)送給評(píng)估分析人員；對(duì)于延期的變更，由CMO對(duì)變更的相關(guān)文檔進(jìn)行歸檔，以便在適當(dāng)時(shí)機(jī)提交CCB審核。

3.7.4.3　CMO負(fù)責(zé)整理CCB會(huì)議記錄，填寫《變更請(qǐng)求/評(píng)審單》中相應(yīng)審核項(xiàng)；更新變更記錄，如果是接受變更，還需將要變更的CIs狀態(tài)改為“修改中”；將變更文檔分發(fā)給相關(guān)人員。

3.7.5　變更實(shí)施

3.7.5.1　變更被批準(zhǔn)后，PL負(fù)責(zé)將要變更的CIs以及相關(guān)文檔遷移至變更負(fù)責(zé)人的Private Branch上，由變更負(fù)責(zé)人開始實(shí)施變更，并詳細(xì)記錄變更的內(nèi)容；項(xiàng)目管理部門要對(duì)變更的實(shí)施進(jìn)行跟蹤。

3.7.5.2　對(duì)于代碼變更，必須修改設(shè)計(jì)、代碼、測(cè)試以及變更正確性的驗(yàn)證。而且與變更相關(guān)的文檔必須修訂，以反映變更。當(dāng)變更以及測(cè)試完成后，進(jìn)行Merge。

3.7.5.3　對(duì)于開發(fā)計(jì)劃、配置管理計(jì)劃發(fā)生變更的，項(xiàng)目組人員要按照變更過的開發(fā)計(jì)劃、配置管理計(jì)劃提交配置項(xiàng)。

3.7.6　變更確認(rèn)

3.7.6.1　變更后的程序Merge后必需經(jīng)過測(cè)試組進(jìn)行回歸測(cè)試，以確保變更沒有引入新的Bug。不會(huì)引起程序變更的文檔（如計(jì)劃文檔）的變更不需經(jīng)過測(cè)試。

3.7.6.2　通過Merge后測(cè)試后，SQA需對(duì)變更進(jìn)行審核，審核的范圍一般涉及以下方面：

1)測(cè)試記錄；

2)變更請(qǐng)求；

3)配置項(xiàng)的檢入及檢出；

5) 文件的命名；

6) 版本的編號(hào)。

3.7.6.3　SQA審核后，開發(fā)人員才能生成新的版本，由PL更新到基線庫(kù)中。

3.7.6.4　PL應(yīng)重新標(biāo)識(shí)所有被影響的配置項(xiàng)及版本。

3.7.6.5　A級(jí)和B級(jí)的變更項(xiàng)也可能直到下次系統(tǒng)發(fā)行版本時(shí)才生成。

3.7.6.6　生成新版本后，CMO負(fù)責(zé)收集所有變更信息歸檔，修改變更CIs狀態(tài)為“正式發(fā)布”，關(guān)閉變更，并將變更報(bào)告發(fā)送給發(fā)起者。

3.8　配置狀態(tài)報(bào)告

3.8.1　配置狀態(tài)報(bào)告的目的

記錄和報(bào)告整個(gè)軟件生命周期演化狀態(tài)。

3.8.2　配置狀態(tài)報(bào)告記錄的內(nèi)容

配置狀態(tài)報(bào)告記錄的內(nèi)容包括：

2)軟件和文檔的標(biāo)識(shí)；

3) 目前狀態(tài)；

4) 基線演化狀態(tài)；

5)變更狀態(tài)；

6)版本交付信息等。

3.8.3　配置狀態(tài)報(bào)告的生成

配置管理報(bào)告自第一個(gè)基線創(chuàng)建時(shí)建立，由配置管理系統(tǒng)生成，及時(shí)反映當(dāng)前配置狀態(tài)。

3.9　配置審核

3.9.1　配置審核的類別

配置審核分為：

1)功能配置審核（Functional Configuration Audit，F(xiàn)CA）：審核軟件功能是否與需求一致，并符合基線文檔要求；通常要審查測(cè)試方法、流程、報(bào)告和設(shè)計(jì)文檔等。

2) 物理配置審核（Physical Configuration Audit，PCA）：審核要交付的組成項(xiàng)是否存在，是否包含所有必需的項(xiàng)目，如正確版本的源代碼、資源、文檔、安裝說明等等。

3.9.2　配置審核執(zhí)行的時(shí)機(jī)

通常選擇以下幾種情況由SQA負(fù)責(zé)實(shí)施配置審核：

1)軟件產(chǎn)品交付或是軟件產(chǎn)品正式發(fā)行前；

2)軟件開發(fā)的階段工作結(jié)束后；

3)在產(chǎn)品維護(hù)工作中，定期地進(jìn)行。

3.9.3　不符合項(xiàng)的處理

對(duì)配置審核中發(fā)現(xiàn)的不符合現(xiàn)象，SQA進(jìn)行記錄，并填寫《不符合項(xiàng)報(bào)告》，交由責(zé)任部門限期進(jìn)行糾正，SQA負(fù)責(zé)糾正措施的驗(yàn)證。所有的不符合項(xiàng)報(bào)告均關(guān)閉后，才能發(fā)布新版本。

3.10　發(fā)行管理

3.10.1　通過配置審核后，由項(xiàng)目經(jīng)理負(fù)責(zé)生產(chǎn)新版本，并由PL檢入產(chǎn)品庫(kù)中，并按照5.4節(jié)配置標(biāo)識(shí)規(guī)則進(jìn)行版本標(biāo)識(shí)。

3.10.2　交付管理

這里“交付”是指從配置庫(kù)中提取配置項(xiàng)，交付給客戶或項(xiàng)目外的人員。交付出去的配置項(xiàng)必須有據(jù)可查，避免發(fā)生混亂。流程如下：

1)“索取人”向CCB提出交付申請(qǐng)。

2) CCB審批該申請(qǐng)。如果該申請(qǐng)不合法（合理），則拒絕交付配置項(xiàng)。如果同意交付，CCB應(yīng)給出詳細(xì)的交付清單。

3) PL依據(jù)CCB的批示，從配置庫(kù)中提取配置項(xiàng)交付給“索取人”。

4)“索取人”驗(yàn)收后簽字。