配置管理流程

配置管理流程

1　概要

1.1　內容

規範配置管理活動，確保配置項正確地唯一標識並易於存取，保證基準配置項的更改受控，明確基線狀態，在貫穿整個軟件生命週期中建立和維護項目產品的完整性和可追溯性。

1.2　適用範圍

對於不同類別的軟件項目，配置管理的流程不同，可在本流程的基礎上進行裁減。

1.3　術語和縮略語

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

軟件配置管理是對軟件修改進行標識、組織和控制的技術，用來協調和控制整個過程。是通過技術或行政手段對軟件產品及其開發過程和生命週期進行控制、規範的一系列措施。配置管理的目標是記錄軟件產品的演化過程，確保軟件開發者在軟件生命週期中各個階段都能得到精確的不同版本的產品配置。

1.3.2　配置（Configuration）

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

1.3.3　配置項（Configuration Item，CI）

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

配置項主要有兩大類：

1) 屬於產品組成部分的工作成果，例如需求文檔、設計文檔、源代碼、測試用例等；
2) 項目管理和機構支撐過程產生的文檔。這些文檔雖然不是產品的組成部分，但是值得保存。

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

1.3.4　基線（Baseline）

在配置管理系統中，基線就是一個CI或一組CIs在其生命週期的不同時間點上通過正式評審而進入正式受控的一種狀態，這些配置項構成了一個相對穩定的邏輯實體，而這個過程被稱爲“基線化”。每一個基線都是其下一步開發的出發點和參考點。基線確定了元素（配置項）的一個版本，且只確定一個版本。一般情況下，基線一般在指定的里程碑（Milestone）處創建，並與項目中的里程碑保持同步。每個基線都將接受配置管理的嚴格控制，基線中的配置項被“凍結”了，不能再被任何人隨意修改，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線。

基線的主要屬性有：名稱、標識符、版本、日期等。通常將交付給客戶的基線稱爲一個“Release”，爲內部開發用的基線則稱爲一個“Build”。

建立基線的好處：

1) 重現性：及時返回並重新生成軟件系統給定發佈版的能力，或者是在項目中的早些時候重新生成開發環境的能力。當認爲更新不穩定或不可信時，基線爲團隊提供一種取消變更的方法。

2) 可追蹤性：建立項目工件之間的前後繼承關係。目的是確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執行文件。

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

2　相關人權責

2.1　項目經理（Project Manager，PM）

責任：

1) 與CCB協商確定項目起始基線和開發里程碑；
2) 接受配置管理計劃，並按相關規定貫徹執行；
3) 接受配置控制委員會的報告。

權利：

1) 提出配置管理計劃的修改要求；
2) 提出管理管理的建議和要求。

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

責任：

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

權利：

1) 批准、發佈配置管理計劃；
2) 建立、更改基線的設置，審覈變更申請；
3) 根據配置管理員的報告決定相應的對策。

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

責任：

1) 編制配置管理計劃；
2) 執行配置項管理方案；
3) 執行版本控制和變更控制方案；
4) 編制配置狀態報告；

權利：

向CCB彙報有關配置管理流程中的不符合情況。

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

責任：

1) 配置庫的建立和權限分配；
2) 配置管理工具的日常管理與維護；
3) 配置庫的日常操作和維護；

權利：

1) 各配置項的管理與維護；
2) 對開發人員進行相關的培訓。

2.5　開發人員（Developer）

責任：

1） 根據確定的配置管理計劃和相關規定，提交配置項和基線；
2） 負責軟件集成和版本生成。

權利：

按照軟件配置管理工具的使用模型來完成開發任務。

2.6　測試人員（Tester）

責任：

根據配置管理計劃和相關規定，提交測試配置項和測試基線；

權利：

負責軟件變更的測試驗證。

2.7　軟件質量保證員（Software Quality Assurance，SQA）

責任：

負責配置審覈並提交報告。

權利：

對配置審覈中發現的不符合項，要求相關責任人進行糾正。

3　實施細則

3.1　CCB的成立

3.1.1　項目在設計發注後，由項目經理負責組織成立CCB。

3.1.2　CCB成員組成

CCB成員人數一般爲奇數，人數在3～7人範圍內。CCB成員一般包括：

1) 項目經理PM；
2) 配置管理員CMO；
3) SQA；
4) 測試人員Tester；
5) 顧客代表；
6) 主要開發人員等。

3.1.3　CCB的決策機制

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

3.2　確定配置策略

3.2.1　配置策略確定的時機

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

3.2.2　配置項的範圍

1) 技術文檔（Documents）：項目開發計劃、需求分析報告、軟件設計書、質量保證計劃、概要設計書、詳細設計書、測試文檔、技術報告、用戶手冊、總結報告等；
2) 程序（Program）：階段產品、計算機程序、源程序、釋放產品等；
3) 工具（Tools）：自動設計工具、開發工具、測試工具、維護工具等；

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

3.3　制定配置管理計劃

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

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

3.3.2　《配置管理計劃》的內容

《配置管理計劃》應包括以下方面的內容：

1) 該項目對配置管理的要求；
2) 實施配置管理的責任人、組織及其職責；
3) 需要開展的配置管理活動及其進度安排；
4) 採用的方法和工具等。

3.3.3　《配置管理計劃》的由CCB負責審批。

3.4　配置項標識規則

3.4.1　配置項標識要求

1) 合同有明確標識和追蹤要求時，由開發人員按合同要求進行標識，以保證滿足合同追蹤要求。
2) 在開發過程中項目組人員提交的配置項，由項目組人員按照本節相關部分標識規則進行標識。
3) 項目組人員將要標識或已標識的配置項提交給CMO納入配置庫統一管理，並填寫《配置狀態報告》。

3.4.2　配置項標識方式

3.4.2.1　標識項

配置項標識屬性包括：名稱、編號、文件狀態、版本、作者、日期等。本文標識規則對名稱、編號、文件狀態和版本進行了描述和規定。

3.4.2.2　名稱

文件名稱的標識按文檔模板中統一名稱爲準。

a) 編號

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

3.4.2.3　文件狀態

文件狀態分爲“草稿”、“正式發佈”和“修改中”三種。

修改處於“草稿”狀態的配置項不算是“變更”，無需CCB的批准，修改者按照版本控制規則執行即可。

當配置項的狀態成爲“正式發佈”，或者被“凍結”後，此時任何人都不能隨意修改，必須依據配置變更控制的規則執行。

3.4.2.4　文檔版本控制

對於計劃性文檔、技術文檔和用戶文檔，其版本按修改的先後順序確定。新生成的文檔第一次發行爲第一版，修改後第二次發行爲第二版，以此類推。

3.4.2.5　發行版本控制

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

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

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

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

3.4.2.6　基線版本標識

內部基線，如計劃基線、設計基線等，在版本號前加Build，如Build 1.0；

發行產品基線在版本號前加Release，如Release 2.0。

3.5　配置庫管理

3.5.1　配置庫（Repository）的分類

配置庫分爲兩類：

1) 文檔庫（Document Library）：由CMO負責管理，主要使用eSM系統管理除程序以外的文檔資料（包括圖片等）；
2) 程序庫（Program Library）：由PL負責管理，主要使用CVS版本工具對程序代碼進行管理。

3.5.2　配置庫的建立

1) CCB成立之後，PL即可着手組織建立配置庫。所有項目應建立配置庫，以便管理各配置項。
2) 文檔庫空間由eSM系統創建，PL僅創建基線文檔庫，僅PL可以對其操作。
3) 程序庫主要通過設置版本的分支，來實現對配置項權限管理，基本上要爲每個配置項從建立開始就劃分成3個不同的分支（如圖1）：

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

1) 私有分支（Private Branch）：私有分支對應的是開發人員的私有開發空間。開發人員根據任務分工獲得對相應配置項的操作許可之後，他即在自己的私有開發分支上工作，他的所有工作成果體現爲在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素。

2) 集成分支（Integration Branch）：集成分支對應的是開發團隊的公共空間。凡是要爲同組人員共享的配置項都從該分支獲得。即各開發人員必須將私有工作空間中的開發成果歸併（Merge）到該分支後才能進入下一個開發活動。所有涉及多人協調的開發工作（如集成測試等）都必須工作在這一空間中。該開發團隊擁有對該集成分支的讀寫權限，而其他成員只有只讀權限。該分支的管理工作由PL及相關指定人員負責。

3) 公共分支（Common Branch）：公共分支對應的是整個軟件開發組織的公共空間。各個開發小組在現階段的任務完成後，將可以發佈的版本歸併到該分支上，將來需要查閱相關資料時，以該分支上的版本爲準。該分支對組織內的全體軟件人員開放只讀權限。該分支的管理工作由PL負責。

上述定義的3類分支以及文檔庫由CMO統一管理，根據各開發階段的實際情況定製相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。

3.5.3　分配權限

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

3.5.4　配置庫的操作與管理

1) 開發人員根據獲得的授權的資源進行項目的研發工作，操作配置庫，例如Add、Checkin/Checkout、Download等。
2) PL根據配置管理計劃創建與維護基線，“凍結”配置項，控制變更。
3) 配置庫的檢出

當發生變更且變更評審通過後，或者發現Bug且Bug評審通過後，由PL將Common Branch中CIs檢出至開發人員的Private Branch上，供開發人員進行變更。

4) 配置庫的檢入

當變更實施結束或Bug修正和測試結束，並通過配置審覈後，由PL將變更後的CIs檢入到Common Branch。

5) PL定期清除配置庫裏的垃圾文件。
6) PL定期備份配置庫。

3.6　配置項和基線管理

3.6.1　CMO根據配置管理計劃，對配置項和基線進行分階段管理。

3.6.2　項目啓動

配置項包括需求說明、訂單及其評審結果等；項目發注後應封鎖該子項目，建立發注基線。

3.6.3　需求分析

系統調研後開發人員進行系統分析，並整理需求分析報告。需求分析報告通過評審並需取得客戶的確定。在需求分析報告取得客戶的確認後，封鎖該子項目，建立需求基線。如需升版則必須通過評審並得到客戶的確認。

3.6.4　項目計劃

需求分析完成後即可制定項目的開發計劃，包括項目總體進度說明、進度跟蹤、計劃修改、配置管理計劃、質量保證計劃、測試計劃等。項目開發計劃評審通過後，封鎖該子項目，建立項目計劃基線。

3.6.5　系統設計

系統設計可分爲概要設計、詳細設計和數據庫設計等部分。針對需求分析報告進行系統設計，配置時應說明系統設計的版本與需求分析報告版本的對應關係。設計書評審通過後，建立設計基線。

3.6.6　編碼

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

3.6.7　測試

各測試階段應提供測試計劃、測試用例、測試結果和測試分析報告，項目啓動後應提供項目測試計劃書，項目驗收結束後應提交項目測試總結報告等。配置時應說明測試的版本與編碼版本的對應關係。各階段測試（如單元測試、集成測試）完成後建立測試基線。

3.6.8　交付與驗收

在交付前配置審覈完成後建立產品基線，產品基線包含程序以及有關文檔配置項，包括交付施工文檔、工具等。

3.6.9　項目總結

項目總結應經過部門內部評審，包括項目質量報告、測試報告等。

3.6.10　相關資料與培訓

相關資料與培訓也應作爲配置項納入配置管理，此部分包括：

1) 相關法律、法規；
2) 必須遵照或項目組約定的技術規範；
3) 與客戶或項目組內部重要的交互信息記錄，如Question Sheet、會議記錄、會談記錄、e-mail和MSN記錄；
4) 必要的業務或技術培訓等。

3.7　配置變更控制

3.7.1　變更的分類

軟件及其相關文檔的變更按照變更的影響範圍進行分類：

1) A級：變更會影響系統級需求、外部接口、產品價格或者交付期；這類變更必須經過CCB審覈並有客戶批准和確認。
2) B級：變更會影響配置項間的功能接口、組件級成本或者項目Schedule；這類變更必須由CCB或上級管理部門的批准和認可。
3) C級：變更會影響配置項內部功能的設計和分配；這類變更可以由配置項的管理人員負責批准。

圖2 變更控制流程

3.7.2　變更請求的提出

1) 由發起者（客戶、最終用戶或開發部門）確定變更，填寫《變更請求/評審單》，描述變更原因和變更內容，並提交給CMO。
2) CMO對填寫的申請表是否清晰、明確和完整性進行審查，若CMO發現變更不明確或不完整，應返回申請表給發起者。CMO對通過審查的變更申請分配變更ID，以便跟蹤和記錄變更信息。

3.7.3　變更評估

1) CMO將《變更請求/評審單》發送給項目經理（或者其他授權人員），由項目經理負責對變更進行評估。
2) 變更控制的一個重要環節就是變更評估，變更評估要分析每個變更對系統功能、接口、成本、進度以及約定需求的影響，同時還要分析對軟件安全性、可靠性、可維護性、可移植性和性能的影響。
3) 變更評估產生的文檔應描述若實施變更必須變更的配置項、文檔和資源；變更評估文檔在完成變更評估後發送給CMO。
4) CMO收到評估後的《變更請求/評審單》後，更新變更記錄，並安排CCB會議日程。

3.7.4　變更審覈

1) CCB對提交的變更申請進行審覈，並根據變更評估確定變更的影響級別；CCB審覈可能的結果有三種：接受變更；拒絕變更；延期變更。CCB也可能需要更多的變更分析的信息。
2) CCB批准的變更，由CMO將變更項目發送到指定的開發人員（Assigner）進行下一步的實施變更工作；對於拒絕的變更，由CMO將CCB拒絕變更的原因發送給發起者，並保存《變更請求/評審單》，更新變更記錄，關閉變更活動；需要進一步分析的，由CMO將變更項目隨同CCB的Question Sheet發送給評估分析人員；對於延期的變更，由CMO對變更的相關文檔進行歸檔，以便在適當時機提交CCB審覈。
3) CMO負責整理CCB會議記錄，填寫《變更請求/評審單》中相應審覈項；更新變更記錄，如果是接受變更，還需將要變更的CIs狀態改爲“修改中”；將變更文檔分發給相關人員。

3.7.5　變更實施

1) 變更被批准後，PL負責將要變更的CIs以及相關文檔遷移至變更負責人的Private Branch上，由變更負責人開始實施變更，並詳細記錄變更的內容；項目管理部門要對變更的實施進行跟蹤。
2) 對於代碼變更，必須修改設計、代碼、測試以及變更正確性的驗證。而且與變更相關的文檔必須修訂，以反映變更。當變更以及測試完成後，進行Merge。
3) 對於開發計劃、配置管理計劃發生變更的，項目組人員要按照變更過的開發計劃、配置管理計劃提交配置項。

3.7.6　變更確認

1) 變更後的程序Merge後必需經過測試組進行迴歸測試，以確保變更沒有引入新的Bug。不會引起程序變更的文檔（如計劃文檔）的變更不需經過測試。

2) 通過Merge後測試後，SQA需對變更進行審覈，審覈的範圍一般涉及以下方面：

• 1) 測試記錄；
• 2) 變更請求；
• 3) 配置項的檢入及檢出；
• 4) 文件的命名；
• 5) 版本的編號。

3) SQA審覈後，開發人員才能生成新的版本，由PL更新到基線庫中。
4) PL應重新標識所有被影響的配置項及版本。
5) A級和B級的變更項也可能直到下次系統發行版本時才生成。
6) 生成新版本後，CMO負責收集所有變更信息歸檔，修改變更CIs狀態爲“正式發佈”，關閉變更，並將變更報告發送給發起者。

3.8　配置狀態報告

3.8.1　配置狀態報告的目的

記錄和報告整個軟件生命週期演化狀態。

3.8.2　配置狀態報告記錄的內容

配置狀態報告記錄的內容包括：

• 軟件和文檔的標識；
• 目前狀態；
• 基線演化狀態；
• 變更狀態；
• 版本交付信息等。

3.8.3　配置狀態報告的生成

配置管理報告自第一個基線創建時建立，由配置管理系統生成，及時反映當前配置狀態。

3.9　配置審覈

3.9.1　配置審覈的類別

配置審覈分爲：

1) 功能配置審覈（Functional Configuration Audit，FCA）：審覈軟件功能是否與需求一致，並符合基線文檔要求；通常要審查測試方法、流程、報告和設計文檔等。
2) 物理配置審覈（Physical Configuration Audit，PCA）：審覈要交付的組成項是否存在，是否包含所有必需的項目，如正確版本的源代碼、資源、文檔、安裝說明等等。

3.9.2　配置審覈執行的時機

通常選擇以下幾種情況由SQA負責實施配置審覈：

1) 軟件產品交付或是軟件產品正式發行前；
2) 軟件開發的階段工作結束後；
3) 在產品維護工作中，定期地進行。

3.9.3　不符合項的處理

對配置審覈中發現的不符合現象，SQA進行記錄，並填寫《不符合項報告》，交由責任部門限期進行糾正，SQA負責糾正措施的驗證。所有的不符合項報告均關閉後，才能發佈新版本。

3.10　發行管理

3.10.1　通過配置審覈後，由項目經理負責生產新版本，並由PL檢入產品庫中，並按照5.4節配置標識規則進行版本標識。

3.10.2　交付管理

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

1) “索取人”向CCB提出交付申請。
2) CCB審批該申請。如果該申請不合法（合理），則拒絕交付配置項。如果同意交付，CCB應給出詳細的交付清單。
3) PL依據CCB的批示，從配置庫中提取配置項交付給“索取人”。
4) “索取人”驗收後簽字。