配置管理流程

配置管理流程

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) 「索取人」驗收後簽字。