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

1　概要

1.1　內(nèi)容

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

1.2　適用范圍

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

1.3　術(shù)語和縮略語

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

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

1.3.2　配置（Configuration）

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

1.3.3　配置項（Configuration Item，CI）

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

配置項主要有兩大類：

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

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

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

1.3.4　基線（Baseline）

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

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

建立基線的好處：

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

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

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

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

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

責(zé)任：

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

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

3)接受配置控制委員會的報告。

權(quán)利：

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

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

2.2　配置控制委員會（Configuration Control Board，CCB）

責(zé)任：

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

權(quán)利：

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

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

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

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

責(zé)任：

1)編制配置管理計劃；

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

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

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

權(quán)利：

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

2.4　程序庫管理員（Program Librarian，PL）

責(zé)任：

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

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

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

權(quán)利：

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

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

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

責(zé)任：

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

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

權(quán)利：

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

2.6　測試人員（Tester）

責(zé)任：

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

權(quán)利：

負(fù)責(zé)軟件變更的測試驗證。

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

責(zé)任：

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

權(quán)利：

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

3　實施細(xì)則

3.1　CCB的成立

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

3.1.2　CCB成員組成

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

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

2) 配置管理員CMO；

3) SQA；

4) 測試人員Tester；

5)顧客代表；

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

3.1.3　CCB的決策機(jī)制

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

3.2　確定配置策略

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

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

3.2.2　配置項的范圍

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

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

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

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

3.3　制定配置管理計劃

3.3.1　《配置管理計劃》的編制

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

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

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

1)該項目對配置管理的要求；

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

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

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

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

3.4　配置項標(biāo)識規(guī)則

3.4.1　配置項標(biāo)識要求

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

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

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

3.4.2　配置項標(biāo)識方式

3.4.2.1　標(biāo)識項

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

3.4.2.2　名稱

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

a)編號

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

3.4.2.3　文件狀態(tài)

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

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

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

3.4.2.4　文檔版本控制

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

3.4.2.5　發(fā)行版本控制

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

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

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

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

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

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

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

3.5　配置庫管理

3.5.1　配置庫（Repository）的分類

配置庫分為兩類：

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

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

3.5.2　配置庫的建立

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

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

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

圖1　配置庫空間分配和版本遷移策略

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

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

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

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

3.5.3　分配權(quán)限

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

3.5.4　配置庫的操作與管理

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

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

3.5.4.3　配置庫的檢出

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

3.5.4.4　配置庫的檢入

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

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

3.5.4.6　PL定期備份配置庫。

3.6　配置項和基線管理

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

3.6.2　項目啟動

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

3.6.3　需求分析

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

3.6.4　項目計劃

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

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

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

3.6.6　編碼

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

3.6.7　測試

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

3.6.8　交付與驗收

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

3.6.9　項目總結(jié)

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

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

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

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

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

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

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

3.7　配置變更控制

3.7.1　變更的分類

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

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

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

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

圖2 變更控制流程

3.7.2　變更請求的提出

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

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

3.7.3　變更評估

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

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

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

3.7.3.4　CMO收到評估后的《變更請求/評審單》后，更新變更記錄，并安排CCB會議日程。

3.7.4　變更審核

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

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

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

3.7.5　變更實施

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

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

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

3.7.6　變更確認(rèn)

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

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

1)測試記錄；

2)變更請求；

3)配置項的檢入及檢出；

5) 文件的命名；

6) 版本的編號。

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

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

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

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

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

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

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

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

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

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

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

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

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

6)版本交付信息等。

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

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

3.9　配置審核

3.9.1　配置審核的類別

配置審核分為：

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

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

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

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

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

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

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

3.9.3　不符合項的處理

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

3.10　發(fā)行管理

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

3.10.2　交付管理

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

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

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

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

4)“索取人”驗收后簽字。