敏捷軟件開發中的配置管理探討

陳申平

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

0 引言

軟件配置管理是采用配置識別、配置控制、配置狀態記錄及配置設計等手段，建立與維護工作產品完整性的一門學科[1]。配置管理側重于嚴格地控制工作產品方面的管理和技術，包括產品的實現或服務。

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

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

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

1 配置管理介紹

1.1 配置管理定義

CMMI模型認為配置管理是一門學科，它應用技術的、管理的指導和監督以于[1]：

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

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

（3）記錄和報告變更的處理和執行狀態；

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

1.2 配置管理活動

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

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

（2）配置識別；

（3）配置變更控制；

（4）配置狀態紀實；

（5）配置審核；

（6）發布管理和交付。

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

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

2 敏捷軟件開發中的配置管理活動

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

2.1 配置識別

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

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

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

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

2.2 配置控制

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

可追溯性是軟件配置管理中一個非常重要的特性，是配置管理的目標之一。可追溯性有助于理解軟件構件間的關系（如需求、設計和源代碼模塊）。同時，有助于理解開發過程中設計決策背后的基本原理[10]。應該盡可能地追溯變更，使文件可以追溯到具體的變更請求。同樣，當實施變更請求時，應該可以跟蹤文件的變更。與變更請求相關的文件不僅僅是源代碼，還應該包括測試用例、文檔等受變更影響的所有文件。另一方面，可追溯性能夠確切地知道一個特定建立或發布的內容——配置項包含一個特定文件的某個特定版本。良好可追溯性的主要優勢是可以更好地進行影響分析，了解變更的結果和提高個人與團隊的協調性[9]。

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

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

2.3 配置狀態紀實

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

配置狀態紀實涉及如下信息的存儲和維護：

（1）產品的配置信息（如變更編號、安裝信息）；

（2）產品的運行和維護文檔信息；

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

一個好的狀態紀實系統應該能夠回答如下問題：

1）項目的狀態是什么？

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

3）實現變更請求的版本？

4）變更請求分配給誰？

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

6）新版本有什么不同？

2.4 配置審核

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

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

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

與軟件配置管理密切相關的敏捷活動有：并行工作、持續集成、規則建立、重構、測試驅動開發等。本節將介紹軟件配置管理技術如何支持和加強并行跟蹤和持續集成兩項敏捷活動[13]。

敏捷團隊并行工作在相同系統，需同步更新共享數據和保持數據的雙向一致性。并行工作需要解決的問題有“共享數據”、“同步更新”和“雙向維護”。

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

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

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

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

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

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

3 配置管理在Scrum模型中的應用

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

4 結束語

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

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

[1] 任甲林. 木以載道——軟件過程改進實踐指南[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] 解晶晶. 基于敏捷開發的軟件配置管理[J]. 電子信息對抗技術, 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.