軟件配置管理

軟件配置管理第一頁，共三十八頁，編輯于2023年，星期一17.1軟件配置管理的任務隨著軟件工程過程的進展，軟件配置項(SCI，SoftwareConfigurationItems)的層次、數(shù)量迅速增加。考慮到因為市場原因、客戶原因、組織原因和預算與進度原因的影響，軟件工程過程隨時都可能發(fā)生變化。這就不可避免地會影響到配置項發(fā)生變化。SCM的任務就是在計算機軟件的整個生命周期內(nèi)管理變化。我們可以將SCM看作是應用于整個軟件過程的一類質(zhì)量保證活動。17.1.1基線變化是軟件開發(fā)過程中必然發(fā)生的事情。客戶要變更需求，開發(fā)者希望修改技術方法，管理者要調(diào)整預算等等第二頁，共三十八頁，編輯于2023年，星期一都屬于合理的變化要求。遺憾的是如果完全隨意地進行變化的話，軟件工程將變成一場災難。變化不可避免，變化必須得到管理，已經(jīng)成為業(yè)界的共識。引入基線的概念，正是為了實現(xiàn)對變化的管理。

基線(BaseLine)的原意是棒球場的邊線，在軟件工程中將其引申成為軟件配置管理中的一個專用名詞?；€用來在不對合理變化造成嚴重阻礙的前提下控制變化。IEEE組織對于基線的定義是：“已經(jīng)通過正式復審和批準的某規(guī)約或產(chǎn)品，它因此可以作為進一步開發(fā)的基礎，并且只能遵循正式的變化控制過程得到改變”。這里的規(guī)約(Specification)可以解釋為“詳細說明”或“規(guī)格說明”。第三頁，共三十八頁，編輯于2023年，星期一根據(jù)這個定義，可以認為基線是一組已經(jīng)經(jīng)過正式技術復審而被認可、發(fā)布并且可供使用，只能遵循一定規(guī)程進行變化的軟件工作產(chǎn)品。SCI被納入基線之前，生產(chǎn)者可以為了順應某種要求，對其進行迅速而非正式的變更，但是如果該項已經(jīng)納入基線，那么針對它的每一個變化，必須按照特定的、正式的規(guī)程進行評估、實施、驗證和發(fā)布。雖然基線可以在任意的細節(jié)層次上定義，但為了避免過于繁瑣，最常見的軟件基線如圖17.1所示。第四頁，共三十八頁，編輯于2023年，星期一圖17.1基線第五頁，共三十八頁，編輯于2023年，星期一

在軟件工程的范圍內(nèi)，基線是軟件開發(fā)過程中的里程碑，其標志是有一個或多個軟件配置項(SCI)的交付。而且這些配置項已經(jīng)經(jīng)過正式技術復審并獲得認可。例如：某設計規(guī)約的要素已經(jīng)形成文檔并通過復審，錯誤已被發(fā)現(xiàn)并且得到了糾正。一旦規(guī)約的所有部分均通過復審、糾正，然后認可，則該設計規(guī)約就變成了一個基線。此后任何對包含在此設計規(guī)約中的程序體系結(jié)構的變化都只能在被評估并得到批準之后方可進行。產(chǎn)生基線的事件進展如圖17.2所示。

第六頁，共三十八頁，編輯于2023年，星期一圖17.2作為基線的SCI和項目的配置數(shù)據(jù)庫第七頁，共三十八頁，編輯于2023年，星期一

軟件工程產(chǎn)生一個或多個SCI，在SCI被復審并得到認可后，它們被放進項目的配置管理數(shù)據(jù)庫中。當軟件工程項目組中的某個成員希望修改某個基線SCI時，該SCI被從項目的配置管理數(shù)據(jù)庫拷貝到工程師的私有工作區(qū)中，然而，這個提取出來的SCI只有在遵循SCM控制的情況下才可以被修改。圖17.2中的虛線說明了對某一個SCI進行修改的事件路徑。

第八頁，共三十八頁，編輯于2023年，星期一

軟件財富基線主要包括各類可復用的軟件構件。對這些構件進行標識、維護、管理，提供給所有需要重用它們的項目組，無疑將會極大地提高生產(chǎn)率，改進未來產(chǎn)品的質(zhì)量并提供更多可供選擇的解決方案和設計方案。項目中形成的可復用構件，應當及時納入財富基線，盡快發(fā)揮它們的作用，擴大財富的積累。17.1.2軟件配置項軟件配置項已經(jīng)定義為在部分軟件工程過程中創(chuàng)建的信息。一般地說，一個SCI可以是一個文檔、一套測試用例或者一個已經(jīng)命名的程序構件。下面的SCI成為配置管理技術的目標并形成一組基線。第九頁，共三十八頁，編輯于2023年，星期一1：系統(tǒng)規(guī)約2：軟件項目計劃3：軟件需求規(guī)約a:圖形分析模型b:處理規(guī)約c:原型d:數(shù)學規(guī)約4：初步的設計手冊5：設計規(guī)約a:數(shù)據(jù)設計描述b:體系結(jié)構設計描述c:模塊設計描述d:界面設計描述e:對象描述(如果采用了面向?qū)ο蠹夹g)第十頁，共三十八頁，編輯于2023年，星期一6：源代碼清單7：測試規(guī)約a:測試計劃和過程b:測試用例和結(jié)果記錄8：操作和安裝手冊9：可執(zhí)行程序a:模塊的可執(zhí)行代碼b:鏈接的模塊10：數(shù)據(jù)庫描述a:模式和文件結(jié)構b:初始內(nèi)容11：聯(lián)機用戶手冊12：維護文檔a:軟件問題報告b:維護請求c:工程變化命令13：軟件工程的標準和規(guī)程第十一頁，共三十八頁，編輯于2023年，星期一

除此之外，為了清晰地描述開發(fā)環(huán)境，許多軟件開發(fā)組織也將使用的工具和開發(fā)環(huán)境內(nèi)容納入配置管理庫中。工具，就像利用它們生產(chǎn)的產(chǎn)品一樣，可以被基線化，并作為綜合配置管理工作的一部分，一般稱之為“環(huán)境基線”。SCI被組織成配置對象、被命名并被歸類到項目的配置管理數(shù)據(jù)庫中。一個配置對象有名字、屬性，并通過“關系”和其他的對象連接。第十二頁，共三十八頁，編輯于2023年，星期一圖17.3配置對象在圖17.3中，配置對象“設計規(guī)約、“測試規(guī)約”、“數(shù)據(jù)模塊”、“模塊N”、“源代碼”分別被定義。但每個對象都和其他對象存在著一定的關聯(lián)。曲線表示的關系是組裝關系，說明數(shù)據(jù)模塊和模塊N都是設計規(guī)約的組成部分。直線雙箭頭連接指明關聯(lián)關系。如果一個對象(比如源代碼對象)發(fā)生變化，關聯(lián)關系使得軟件工程師能夠據(jù)此判定還有哪些對象會被影響。第十三頁，共三十八頁，編輯于2023年，星期一17.2SCM過程

軟件配置管理過程是軟件工程中的重要環(huán)節(jié)，它的直接目標是管理變更。在管理過程中，配置管理活動還要關注個體SCI的標識和軟件產(chǎn)品的版本控制，負責軟件配置庫的審核和配置變更情況并及時提出配置變更報告。概括地說，SCM過程的任務主要有下面五項。

(1)組織如何標識和管理程序及文檔的很多現(xiàn)存版本，以保證能夠高效率地進行必要的變更。(2)如何在軟件發(fā)布之前和之后控制變更。(3)明確由什么角色負責批準變更，并給變更確定優(yōu)先級別。(4)如何保證變更已經(jīng)被恰當?shù)貓?zhí)行。(5)采用什么機制去告訴相關人員目前已經(jīng)發(fā)生的變更。

第十四頁，共三十八頁，編輯于2023年，星期一簡單地說，SCM任務是標識配置項、控制產(chǎn)品版本、控制變化、配置審計和發(fā)布配置報告。在軟件能力成熟度模型中，將配置管理作為達到二級成熟度的一個關鍵活動域，提出了四項必須達到的目標。

目標1：軟件配置管理活動是有計劃的。目標2：所選定的軟件工作產(chǎn)品是已標識的、受控的和適用的。目標3：對已標識的軟件工作產(chǎn)品的更改是受控的。目標4：受影響的組和個人得到軟件基線的狀態(tài)和內(nèi)容的通知。

第十五頁，共三十八頁，編輯于2023年，星期一17.3軟件配置中對象的標識

為了控制和管理軟件配置項，每一個配置項必須被獨立命名，然后用面向?qū)ο蟮姆椒右越M織。對象命名是為了能夠根據(jù)名稱提取對象；而通過組織對象并描述其間的關系則是著眼于在對象變更時能夠清楚地了解變更的影響范圍。能夠被標識的對象分為基本對象和聚集對象兩大類?；緦ο笫擒浖こ處熢诠ぷ髦袆?chuàng)建的諸如需求規(guī)約的一個段落、一組測試用例、模塊的源代碼清單之類的“文本單元”(unitoftext)。而一個聚集對象是基本對象和其他聚集對象的集合，是一個遞歸的概念。例如圖17.3中的“設計規(guī)約”。在概念上，聚集對象可以被認為是已經(jīng)被標識命名的“指針表”。指針指向基本對象“模塊N”和“數(shù)據(jù)模塊”。第十六頁，共三十八頁，編輯于2023年，星期一

配置對象具有一組惟一標識它的特征數(shù)據(jù)：(對象名、描述、資源表、實體)。各項特征的含義如下：

(1)對象名：無二義的表示對象的一個字符串。(2)描述：一組數(shù)據(jù)項的列表，具體標識：該對象所表示的SCI類型；項目標識符、變更信息和(或)版本信息。(3)資源：由對象提供、處理、引用或需要的實體，如數(shù)據(jù)類型、特定的函數(shù)、變量名稱等等。(4)實體：是一個指針。對于基本對象，它指向特定的“文本單元”；對于聚合對象，它指向null。第十七頁，共三十八頁，編輯于2023年，星期一在標識配置對象時，應當能夠反映它們之間的關系。通過制定命名規(guī)則，一個對象可以被標識為某個聚集對象的局部(part-of...)。(part-of...)定義了一個對象層次，例如：E-Rdigram1.4(part-of)datamodeldatamodel(part-of)DesignSpecification使用這樣的對象標識方法，能夠創(chuàng)建SCI之間的層次結(jié)構。實際上，在層次結(jié)構中也存在有交叉關連(interrelated)關系：datamodel(interrelated)dataflowmodel(數(shù)據(jù)模塊和數(shù)據(jù)流程圖關聯(lián))datamodel(interrelated)testcaseclassm(數(shù)據(jù)模塊和測試用例類m之間關聯(lián))第十八頁，共三十八頁，編輯于2023年，星期一對于配置項的標識，除了上面的基本原則必須滿足之外，各個軟件開發(fā)組織也可制定自己的配置項標識規(guī)范。例如，某組織的配置項標識方法規(guī)定：配置項標識：要求對每一配置項進行惟一性標識。命名規(guī)范：1位基線庫編碼+“_”+2位配置對象編碼+“_”+最多五個漢字或10個英文/拼音的配置項標識(一般為功能/模塊名稱，但要求有易懂且惟一)+‘_’+5位版本號(最多5位——q.m.n)一個對象在被納入基線之前，它可能變化了許多次。在被納入基線之后，也允許繼續(xù)發(fā)生受控的變化。對象的標識必須能夠反映對象在整個軟件過程中的演化情況。對象演化圖能夠滿足這一要求，直觀地反映對象的演化過程和演化路徑。第十九頁，共三十八頁，編輯于2023年，星期一

圖17.4中，反映出對象1.0經(jīng)歷了四次一般變化，演化出對象1.1、1.2、1.3、1.4；演化對象1.1經(jīng)歷了兩次小的變化，演化出對象1.1.1和1.1.2；對象1.2經(jīng)歷了一次大的變化，形成了對象2.0；對象2.0發(fā)生一般變化后，形成對象2.1對象的變化有可能針對它當前存在的任意版本，但一般不會針對所有版本。經(jīng)過恰當?shù)臉俗R使得對象被選中進行變化時，可以借助于標識符的引導找到本對象及其相關聯(lián)的所有對象，實施聯(lián)帶變化，保證配置管理數(shù)據(jù)庫的完整性。目前許多用于SCM的自動工具已經(jīng)被開發(fā)出來，提高了配置管理的工作效率和準確程度。第二十頁，共三十八頁，編輯于2023年，星期一圖17.4配置對象演化圖第二十一頁，共三十八頁，編輯于2023年，星期一17.4版本控制

為適應不同的環(huán)境特點和用戶的個性化需求，同一個軟件可能會推出不同的版本。為方便用戶的使用，軟件的若干功能可以是“可選件”，即使同一版本的軟件，選件的不同也將導致它們成為同一版本的不同“變體”。如何利用配置項裝配成不同版本的產(chǎn)品進行產(chǎn)品發(fā)布，也是SCM工作必須完成的任務。如果圖17.4中的每個節(jié)點都是包括軟件所有組成部分的聚集對象，那么，每個對象節(jié)點也就代表了軟件的一個版本(一組SCI的集合，包括源代碼、文檔、數(shù)據(jù)、可執(zhí)行程序)。每個版本可以由許多不同的變體(Variant)組成。這第二十二頁，共三十八頁，編輯于2023年，星期一種情況在我們使用工具軟件時也經(jīng)常會遇到。比如在工具軟件的安裝過程中我們可以進行裁剪，得到同一版本軟件的不同變體。圖17.5軟件版本變化及其變體第二十三頁，共三十八頁，編輯于2023年，星期一圖17.5是實現(xiàn)變體的示意圖。對版本2.1來說，可以定義由構件(1、2、3、4)和構件(1、2、3、5)構成的相同版本的兩種變體。當軟件使用彩色顯示器實現(xiàn)時選擇使用構件4，構件5只在使用單色顯示器時才被選中。為了構造某程序的給定版本的適當變體，可以為每一個構件賦予一個“屬性元組”，即構件特征表。當要構造某軟件版本的特殊變體時，只要規(guī)定了應當使用具有什么特征屬性的構件，就能夠很方便地完成構件的選擇和組裝。目前已經(jīng)有許多不同的、能夠自動進行版本控制的方法與工具，并得到了廣泛的使用。使用這樣的SCM工具，第二十四頁，共三十八頁，編輯于2023年，星期一能夠進行增量式的版本生成與管理，能夠根據(jù)當前版本對早期版本進行追溯，同時具有基線管理能力，完全排除了對特定版本進行無控制修改、刪除的可能性。第二十五頁，共三十八頁，編輯于2023年，星期一17.5變更控制

軟件工程活動中，變更不可避免，重要的是對變更進行管理。無控制的變化將迅速地導致過程的混亂。合理的組織保證，人為的規(guī)程限制和自動化的工具相結(jié)合，能夠?qū)崿F(xiàn)良好的變更控制機制。變更控制過程流程如圖17.6所示，當修改(變更)請求被提出后，首先要從技術指標，潛在的副作用，對其他配置對象和系統(tǒng)功能的整體影響和變更成本幾方面評估變更的可行性。評估結(jié)果形成變更報告。該報告交由變更控制審核小組(CCA，ChangeControlAuthority)使用。第二十六頁，共三十八頁，編輯于2023年，星期一

CCA針對被批準的變更生成一個工程變更命令(ECO，EngineeringChangeOrder)。ECO描述將要進行的變更，必須注意的約束，復審和審核的標準。然后，接到ECO的技術人員將指定要被修改的對象從項目配置管理數(shù)據(jù)庫中提取出來(CheckOut)，進行修改，并進行必要的SQA活動和測試活動。接著，將改定的對象提交(CheckIn)回項目配置管理數(shù)據(jù)庫。最后使用合適的版本控制機制去建立軟件的下一個版本。第二十七頁，共三十八頁，編輯于2023年，星期一圖17.6變更控制的過程第二十八頁，共三十八頁，編輯于2023年，星期一

“提取”和“提交”過程實現(xiàn)了兩個主要的變更控制因素?！疤崛　睂崿F(xiàn)了對配置項的“訪問控制”，限制了只有被指定的工程師才有權獲得和修改特定的配置對象，在對象被提取后自動“加鎖”；“提交”提供了一種“同步控制”。特定的配置項一旦被授權人提取進行修改，在修改完畢提交回配置庫之前，由于已經(jīng)加鎖，其他人只能夠進行瀏覽性提取，無權進行修改。修改者執(zhí)行了提交操作后，配置庫中原被鎖定的修改對象將被更新并被“解鎖”。在變更管理流程中，CCA的作用十分重要。他們要從全局的觀點來評估變更對SCI之外的事物的影響，包括變更是第二十九頁，共三十八頁，編輯于2023年，星期一否會影響硬件，如何影響性能，如何影響軟件的質(zhì)量和可靠性等等。最終CCA將根據(jù)變更評估的結(jié)果就是否實行變更進行決策，并具體安排變更的實施。

第三十頁，共三十八頁，編輯于2023年，星期一17.6配置審核與狀態(tài)報告17.6.1配置審核

SCM通過配置項標識、版本控制和變更控制措施，保障了軟件工程過程中的工作秩序。對于變更工作，必須通過正式的技術復審和軟件配置審核工作來驗證被核準進行變更的對象是否進行了必要的、正確的變更，并得到了重新的配置。對變更結(jié)果進行的正式復審由技術工程師們進行。它關注的是被修改的配置對象在技術上的正確性。復審者們要評估SCI以確定它和其他SCI的一致性，關注是否有潛在的副作用等問題。第三十一頁，共三十八頁，編輯于2023年，星期一

作為對變更進行的正式復審的補充，SQA人員還要針對和變更管理相關的SCM工作進行審核。作為正式技術復審的補充環(huán)節(jié)，這種審核主要關注下列幾方面的問題：

(1)ECO中提出的變更是否已經(jīng)完成，有無進行未經(jīng)指定的其他附加變更。(2)針對變更工作的技術正確性，是否已經(jīng)進行了正式的技術復審。(3)變更工作是否遵循了軟件工程標準。(4)檢查是否針對被變更的SCI進行了強調(diào)說明。被變更的SCI的屬性是否反映了本次變更，是否記錄了變更日期和變更實施者等必要信息。(5)是否遵循了標注變更、記錄變更和報告變更的SCM工作規(guī)程。(6)所有相關的SCI是否都得到了恰當?shù)男薷?。第三十二頁，共三十八頁，編輯?023年，星期一17.6.2配置狀態(tài)報告建立并發(fā)布配置狀態(tài)報告(CSR，ConfigurationStatusReporting)是SCM的任務之一。CSR應當說明：配置庫發(fā)生了什么事情，該事是誰做的，是什么時候發(fā)生的，將會造成哪些影響。每當一個SCI被賦予新的或修改后的標識時，就有一個CSR的條目被創(chuàng)建；每當下達一個ECO時，也有一個CSR條目被創(chuàng)建。在每次進行配置審核時，審核的結(jié)果也作為CSR的一部分被報告。應當定期地生成配置狀態(tài)報告并向所有相關人員發(fā)布。保證大家始終能夠清楚地了解配置管理庫的現(xiàn)狀和配置管理工作的進展。在大型項目中，離開了配置狀態(tài)報告有可能導致狀態(tài)混亂。例如，兩個開發(fā)者可能試圖以不同的或者互相沖突第三十三頁，共三十八頁，編輯于2023年，星期一的意圖去修改一個配置對象；不了解未來的軟件運行環(huán)境已經(jīng)發(fā)生了變更的工程師們可能還在針對已經(jīng)不再存在的環(huán)境開發(fā)軟件。有了真實、及時的配置狀態(tài)報告，就能夠防患于未然。第三十四頁，共三十八頁，編輯于2023年，星期一17.7小結(jié)

SCM活動是應用于軟件工程全過程中的一種保護性活動。SCM標識、控制、審核和報告在軟件開發(fā)過程