陳申平

（中國電子科技集團(tuán)公司第七研究所，廣東 廣州 510310）

0 引言

軟件配置管理是采用配置識別、配置控制、配置狀態(tài)記錄及配置設(shè)計等手段，建立與維護(hù)工作產(chǎn)品完整性的一門學(xué)科[1]。配置管理側(cè)重于嚴(yán)格地控制工作產(chǎn)品方面的管理和技術(shù)，包括產(chǎn)品的實現(xiàn)或服務(wù)。

2010年 11月，SEI正式發(fā)布了《CMMI for Development》1.3版，主要的變化就是增加了對敏捷方法的支持，并在項目策劃、風(fēng)險管理、質(zhì)量保證等相關(guān)過程域中增加了敏捷方法的使用說明。全球使用敏捷方法的軟件企業(yè)日益增多。2002年前后，敏捷方法開始被國內(nèi)的軟件人員所了解。作為敏捷方法在國內(nèi)的先行者，中興、華為、騰訊等民營企業(yè)已開始應(yīng)用敏捷方法。近年來，越來越多的國企也開始采用敏捷方法，如銀行、證券公司、通信研究所等。

敏捷軟件開發(fā)中，為支持快速變更、快速建立、多重基線，個人、團(tuán)隊、甚至線程等多重配置管理工作空間，配置管理是非常重要的。軟件配置管理不僅僅是控制和停止變更，它實際上提供了一個能服務(wù)和支持敏捷開發(fā)團(tuán)隊的完整技術(shù)范圍和過程[2]。為實現(xiàn)配置管理活動更好地服務(wù)于敏捷軟件開發(fā)，國內(nèi)外許多學(xué)者對敏捷軟件開發(fā)中的配置管理活動進(jìn)行了研究[3-6]。

本文結(jié)合敏捷的特點，探討了敏捷軟件開發(fā)中如何使用配置管理來控制軟件開發(fā)過程，以及軟件配置管理技術(shù)如何支持和加強并行工作與持續(xù)集成兩項敏捷活動，并描述配置管理在Scrum敏捷模型中的應(yīng)用，為其他敏捷方法提供了參考依據(jù)。

1 配置管理介紹

1.1 配置管理定義

CMMI模型認(rèn)為配置管理是一門學(xué)科，它應(yīng)用技術(shù)的、管理的指導(dǎo)和監(jiān)督以于[1]：

（1）識別和記錄配置項功能特征和物理特征；

（2）控制這些特征的變更；

（3）記錄和報告變更的處理和執(zhí)行狀態(tài)；

（4）驗證其是否符合特定的需求。

1.2 配置管理活動

配置管理的目的是通過采用配置識別、配置控制、配置狀態(tài)紀(jì)實和配置審核來建立和維護(hù)工作產(chǎn)品的完整性[2]。軟件配置管理包含的活動如下[7]：

（1）制定配置管理計劃；

（2）配置識別；

（3）配置變更控制；

（4）配置狀態(tài)紀(jì)實；

（5）配置審核；

（6）發(fā)布管理和交付。

配置管理活動如圖1所示：

圖1 配置管理活動圖[7]Fig.1 Configur ation management activity diagram[7]

2 敏捷軟件開發(fā)中的配置管理活動

敏捷軟件開發(fā)方法是一種以人為本、迭代、應(yīng)對需求快速變化的一種“輕量型”軟件開發(fā)方法。其主要特點是：迭代式開發(fā)、增量交付、持續(xù)集成、開發(fā)團(tuán)隊自我管理、開發(fā)團(tuán)隊與用戶反饋推動產(chǎn)品開發(fā)[8]。本節(jié)描述了可添加到敏捷方法中的四項典型活動，以向團(tuán)隊提供更多幫助。同時介紹軟件配置管理技術(shù)如何支持和加強并行工作與持續(xù)集成兩項敏捷活動。

2.1 配置識別

對敏捷方法而言，配置識別最重要的部分是配置項識別和組成。對一個項目，一些產(chǎn)品是非常重要的，這些產(chǎn)品應(yīng)識別為配置項，其它含有更多個人隱私的產(chǎn)品（如草圖、經(jīng)驗、筆記等）不需要識別為配置項。盡管部分私人工作產(chǎn)品不是配置項，仍然需要保存和版本化。因此，在配置管理工具中，劃分產(chǎn)品、配置項和非配置項的結(jié)構(gòu)是非常重要的[9]。

敏捷軟件開發(fā)中，每次迭代過程中需制定迭代計劃、進(jìn)行持續(xù)開發(fā)和測試。因此，敏捷配置管理較傳統(tǒng)配置管理方法新增的配置項有測試代碼、測試工具和測試腳本、持續(xù)集成相關(guān)工具、構(gòu)建腳本、迭代計劃、迭代任務(wù)列表、用戶故事或用戶卡[2]。

敏捷軟件開發(fā)中，完整的工作產(chǎn)品需要多次迭代才能完成，因此，配置項與基線的建立時機與傳統(tǒng)方法不同。每次迭代階段應(yīng)編寫文檔片段并測試實現(xiàn)的代碼，當(dāng)完整的文檔通過評審或所有代碼通過測試后，將文檔或代碼入軟件受控庫，并建立相應(yīng)的基線。迭代過程中，可以在軟件開發(fā)庫建立迭代基線。敏捷軟件開發(fā)中至少需要建立軟件功能基線、軟件分配基線、軟件產(chǎn)品基線三條基線，基線及配置項如表1所示：

表1 敏捷軟件開發(fā)中的基線及配置項表Tab.1 Baseline and configuration table for agile software development

2.2 配置控制

配置控制包括版本控制和變更控制，這里只介紹變更控制。配置管理變更請求的跟蹤貫穿整個生命周期。在任何時間點，了解變更請求的當(dāng)前狀態(tài)和誰負(fù)責(zé)變更是非常重要的，這有利于處理變更請求和協(xié)調(diào)不同人員的工作[9]。

可追溯性是軟件配置管理中一個非常重要的特性，是配置管理的目標(biāo)之一?？勺匪菪杂兄诶斫廛浖?gòu)件間的關(guān)系（如需求、設(shè)計和源代碼模塊）。同時，有助于理解開發(fā)過程中設(shè)計決策背后的基本原理[10]。應(yīng)該盡可能地追溯變更，使文件可以追溯到具體的變更請求。同樣，當(dāng)實施變更請求時，應(yīng)該可以跟蹤文件的變更。與變更請求相關(guān)的文件不僅僅是源代碼，還應(yīng)該包括測試用例、文檔等受變更影響的所有文件。另一方面，可追溯性能夠確切地知道一個特定建立或發(fā)布的內(nèi)容——配置項包含一個特定文件的某個特定版本。良好可追溯性的主要優(yōu)勢是可以更好地進(jìn)行影響分析，了解變更的結(jié)果和提高個人與團(tuán)隊的協(xié)調(diào)性[9]。

變更請求涵蓋：預(yù)算變更、需求變更、需求刪除、工具更新、硬件配置項和實現(xiàn)變更[7]。敏捷軟件開發(fā)中，需對變更配置項進(jìn)行影響分析，考慮需求、用戶故事、測試是否需要變更。提出變更申請后，項目軟件配置控制委員會（SCCB）進(jìn)行變更影響分析。影響分析通常應(yīng)考慮對系統(tǒng)、硬件配置項、相關(guān)產(chǎn)品、工作量、進(jìn)度、質(zhì)量等帶來的影響，同時還應(yīng)識別并分析可能存在的技術(shù)、管理及人力等方面的風(fēng)險。在某次迭代階段中，開始設(shè)計、編碼的需求在該次迭代期間通常不能變更。如經(jīng)影響分析表明必須馬上進(jìn)行變更，則應(yīng)終止該次迭代，重新策劃并啟動新的迭代。本次迭代過程中未對上次迭代工作產(chǎn)品進(jìn)行變更，則不需走變更流程，直接建立迭代產(chǎn)品。變更流程如圖2所示[7]。

圖2 軟件變更流程圖[7]Fig.2 Software change flow chart[7]

2.3 配置狀態(tài)紀(jì)實

配置狀態(tài)紀(jì)實的目的是為了保持經(jīng)理、用戶、開發(fā)人員和其他項目利益相關(guān)方了解各配置階段的演變。配置狀態(tài)紀(jì)實與配置識別不同，不是一個預(yù)先開展的活動，而是事件觸發(fā)隨時添加的活動。需要根據(jù)項目的進(jìn)展情況，記錄配置項的出入庫、變更狀態(tài)。配置狀態(tài)紀(jì)實包含三個基本任務(wù)：數(shù)據(jù)采集、數(shù)據(jù)記錄和報告生成[11]。配置狀態(tài)紀(jì)實通過記錄并報告各配置項變更的申請、批準(zhǔn)和實施來跟蹤變更現(xiàn)狀，提供配置項及影響配置項活動的所有信息，包括配置項的變更日志、進(jìn)度報告和事務(wù)日志[12]。

配置狀態(tài)紀(jì)實涉及如下信息的存儲和維護(hù)：

（1）產(chǎn)品的配置信息（如變更編號、安裝信息）；

（2）產(chǎn)品的運行和維護(hù)文檔信息；

（3）軟件配置管理過程信息（如變更請求狀態(tài)）。

一個好的狀態(tài)紀(jì)實系統(tǒng)應(yīng)該能夠回答如下問題：

1）項目的狀態(tài)是什么？

2）影響變更請求的事項是什么？

3）實現(xiàn)變更請求的版本？

4）變更請求分配給誰？

5）目前有多少高優(yōu)先級的變更請求未實施？

6）新版本有什么不同？

2.4 配置審核

配置審核用來驗證配置庫中的配置項是否符合特定的標(biāo)準(zhǔn)或需求的一種審核手段[7]。配置審核分為功能審核、物理審核、配置管理審核三種類型，最常用的審核類型為功能審核和物理審核。功能審核用于檢查軟件配置項的正確性和完備性，主要內(nèi)容為核查軟件實現(xiàn)的功能、性能等是否符合用戶要求，以及軟件的支持文檔是否齊套。敏捷軟件開發(fā)中，功能配置審核可以通過單元測試和驗收測試來實現(xiàn)。物理審核則從“準(zhǔn)入條件”的角度檢查進(jìn)入配置庫的配置項是否已通過了相應(yīng)的評審或測試及其齊全性，同理，在配置項出庫時，同樣需檢查出庫配置項的齊全性與版本的正確性。物理審核是一種對覆蓋存儲配置項的所有物理載體的檢測，當(dāng)被審核的對象是可安裝程序時，還需確認(rèn)其可以被正確的安裝。配置管理審核檢查配置管理記錄和配置項是否完備、一致和準(zhǔn)確。

在敏捷軟件開發(fā)中，配置項相關(guān)記錄存在于多重數(shù)據(jù)庫或配置管理系統(tǒng)。在這種情況下，為了確保正確性、一致性、非正式配置項的完整性，配置審核應(yīng)該涉及這些數(shù)據(jù)庫。配置審核可以看作一個驗證活動，實際工作可以被視為質(zhì)量保證活動，并覆蓋于軟件開發(fā)的其他過程和活動之中。實際工作中，配置審核可以通過驗證活動開展。

2.5 配置管理對敏捷活動的支持

與軟件配置管理密切相關(guān)的敏捷活動有：并行工作、持續(xù)集成、規(guī)則建立、重構(gòu)、測試驅(qū)動開發(fā)等。本節(jié)將介紹軟件配置管理技術(shù)如何支持和加強并行跟蹤和持續(xù)集成兩項敏捷活動[13]。

敏捷團(tuán)隊并行工作在相同系統(tǒng)，需同步更新共享數(shù)據(jù)和保持?jǐn)?shù)據(jù)的雙向一致性。并行工作需要解決的問題有“共享數(shù)據(jù)”、“同步更新”和“雙向維護(hù)”。

“共享數(shù)據(jù)”問題很容易解決。創(chuàng)建一個包含所有代碼的物理或虛擬工作空間，用于隔離其他人的變更。了解團(tuán)隊其他成員的變更并將變更內(nèi)容添加到工作空間。

“同步更新”問題只發(fā)生在同一時間多人同時修改相同的代碼。解決方案也是相當(dāng)簡單的。需要能夠檢測到配置庫中的最新版本，而不是用于變更的歷史版本。這時，需要集成并行變更并將合并后的變更結(jié)果添加到配置庫。

“雙向維護(hù)”問題是由保護(hù)共享數(shù)據(jù)問題引起的。在多個工作空間中，每一個文件的多個副本很快不再是相同的。當(dāng)對一個工作空間的文件進(jìn)行了變更，為保持所有副本相同，需對其他工作空間的所有副本進(jìn)行相同的變更。這聽起來復(fù)雜，但其實非常簡單。只需要將每次變更后的工作產(chǎn)品放到配置庫，其他成員進(jìn)行變更時從配置庫提取，并將變更并行集成。

持續(xù)集成意味著團(tuán)隊成員需頻繁地整合變更，需盡可能快地響應(yīng)變更，并能夠在真實環(huán)境盡早開展變更測試。持續(xù)集成要求每一個團(tuán)隊成員整合其他成員的變更，并盡早發(fā)現(xiàn)不正確的變更。由于頻繁的集成可以盡早發(fā)現(xiàn)不正確的變更，降低了整體開銷，進(jìn)而減少了復(fù)雜集成問題[14]。

與傳統(tǒng)軟件開發(fā)相比，持續(xù)集成導(dǎo)致變更的速度增加，因此保持變更的雙向一致變得尤為重要。將變更合并到配置庫需要兩個步驟。第一步：實施所有變更前，需從配置庫中“下載”最新集成結(jié)果；第二步：變更完成后，將個人工作空間內(nèi)容合并后再“上傳”到配置庫。如圖3所示，一個盒子代表配置項的一個新版本，如果配置庫沒有任何變更，可以安全地將變更后的配置項作為最新版本“上傳”到配置庫。如果在變更前配置庫有新版本的文件，可以簡單的更新個人工作空間。如果變更開始后，配置庫有新版本的文件有可能引起變更沖突，必須先合并配置庫的所有變更，再更新個人工作空間?？梢酝ㄟ^各類測試（如單元測試、驗收測試等）來檢驗集成結(jié)果的質(zhì)量。檢驗正常后，將個人工作空間的最新版本上傳配置庫。

圖3 下載和上傳集成圖[9]Fig.3 Download and upload integration figure[9]

3 配置管理在Scrum模型中的應(yīng)用

Scrum模型是最常用的敏捷模型，本節(jié)將介紹Scrum模型中的配置管理活動，如圖4所示。在進(jìn)行總體策劃前，需已建立功能基線?？傮w策劃時，先標(biāo)識配置項和基線；制定并評審配置管理計劃；根據(jù)識別的配置項和基線，在配置庫中建立項目目錄。每次迭代中，需對迭代工作產(chǎn)品進(jìn)行管理，集成上一次迭代的工作產(chǎn)品并進(jìn)行測試。最后一次迭代，評審并測試完整工作產(chǎn)品，將工作產(chǎn)品入庫并發(fā)布，建立相應(yīng)基線。在模型的整個生命周期內(nèi)，為保證工作產(chǎn)品的正確性和完整性，需對產(chǎn)生的工作產(chǎn)品進(jìn)行配置控制、配置狀態(tài)紀(jì)實、配置審核。

4 結(jié)束語

相比傳統(tǒng)的軟件開發(fā)方法，敏捷方法更強調(diào)快速靈活響應(yīng)、積極適應(yīng)變化，主張客戶與開發(fā)團(tuán)隊更緊密地協(xié)作。基于敏捷的這些特點，在敏捷軟件開發(fā)中配置管理是非常重要的。在敏捷開發(fā)中使用軟件配置管理能更好地支持可追溯性和跟蹤變更，為需求、缺陷和實現(xiàn)之間的雙向可追溯性提供一些額外的作用。本文通過介紹配置管理的定義和活動，引出敏捷軟件開發(fā)中的配置識別、配置控制、配置狀態(tài)紀(jì)實、配置審核四項典型配置管理活動，可以看到敏捷軟件開發(fā)中的配置管理活動與傳統(tǒng)方法的具體實施有所不同。文中還介紹了Scrum模型中配置管理活動的具體實施方法。

圖4 S crum模型中的配置管理活動圖Fig.4 Configuration management activity diagram in Scrum model

[1] 任甲林. 木以載道——軟件過程改進(jìn)實踐指南[M]. 人民郵電出版社, 2014, 4: 347.

[2] Mary Beth Chrissis, Mike Konrad, Sandy Shrum. CMMI for Development[S], Version1.3. NewYork: Software Engineering Institute, 2011: 137-148.

[3] Angelina Espinoza, Juan Garbajosa. A study to support agile methods more effectively through traceability[J]. Innovations Syst Softw Eng (2011) 7: 53-69.

[4] Fletcher J, Cleland-Huang J (2006) Softgoal traceability patterns. In: Proceedings of the international symposium on software reliability engineering (ISSRE). IEEE Computer Society, Washington, pp 363–374. ISBN:0-7695-2684-5. [5]Leon, A. (2005). Software configuration management handbook. Artech House.

[5] 解晶晶. 基于敏捷開發(fā)的軟件配置管理[J]. 電子信息對抗技術(shù), 2016, 31(1): 74.

[6] Lara Drvodelic Cvitak, Zeljka Car. Impact of agile developmentation on configuration and change management in telecom domain[J]. PIPRO, 2010.

[7] Mikael Lindvall, Vic Basili, Barry Boehm, et al. Empirical Findings in Agile Methods[J]. Springer Berlin Heidelberg,2002, 2418: 197-207.

[8] Ioannis G.Stamelos,Panagiotis Sfetsos. Agile Software Development Quality Assurance[M]. London: INFORMATION SCIENCE REFERENCE, 2007: 142-145.

[9] Kannan Mohan, Peng Xu, Lan cao. Improving change management in software development:Integrating traceability and software configuration management[J]. Decision Support Systems, 2008: 922-936.

[10] Andreas Beergstrom. Software Configuration Management in Scrum Projects[D]. Department of Computer Science Lund Institute of Technology Sweden, 2007: 9-10.

[11] Juha Koskela. Software configuration management in agile methods[P]. VTT Electronics, 2003: 14.

[12] B Loppin,P Couble. Software Configuration Management in Agile Development[J]. Clinical Oral Implants Research,2010, 21(1): 55-64.

[13] Abu Wahid Md,Masud Parvez. A Managed Approach to Interact between Agile Scrum and Software Configuration Management System[J]. Advances in Information Technology and Management(AITM), 2012: 111-114.