1、軟件配置管理 SCM-Software Configuration Management -概念、方法與任務 主講：鄭人杰2001年8月,1,目 錄,什么是配置管理 軟件配置管理計劃 軟件配置標識 變更管理 版本管理和發(fā)行管理 配置審核 配置狀態(tài)報告 軟件配置管理工具 結論,參考：國家標準GB/T 12505-90計算機軟件配置管理計劃規(guī)范,2,配置（Configuration）一詞在其它領域中已有廣泛的應用，只不過稱呼有所不同，但都有其確切的含義。如原子結構的形態(tài)和組態(tài)，控制系統(tǒng)的配置以及計算機系統(tǒng)的配置等等。許多領域也把配置稱為技術狀態(tài)。,1，什么是配置管理Configuration Ma

2、nagement,(1)幾種說法,ISO9000-3的4.8中給出：配置管理是一個管理學 科，它對配置項（包括軟件項）的開發(fā)和支持生 存期給予技術上和管理上的指導。配置管理的應 用取決于項目的規(guī)模、復雜程度的風險大小。,3,W.Babich認為，軟件配置管理能協(xié)調軟件開發(fā)，使 得混亂減少到最小。軟件配置管理是一種標識、組 織和控制修改的技術，目的是最有效地提高生產(chǎn)率。,GB/T 11457:1995(軟件工程術語）對配置管理的解釋： A.標識和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存 周期內(nèi)控制這些項的投放和更動，記錄并報告配置 的狀態(tài)和更動要求，驗證配置項的完整性和正確性。 B.對下列工作進行

3、技術和行政指導與監(jiān)督的一套規(guī)范： 對一配置項的功能和物理特性進行標識和文件編 制工作； 控制這些特性的更動情況； 記錄并報告對這些更動進行的處理和實現(xiàn)的狀態(tài)。,4,(2)什么是軟件配置項 (Software Configuration Item),含義：配置管理的對象，軟件工程過程產(chǎn)生的所有 信息項。 包括：計算機可執(zhí)行的源代碼、目標碼、數(shù)據(jù)庫 計算機不可執(zhí)行的文檔、源程序清單、測試用例。 管理的產(chǎn)品(ISO9000-3的4.8),與合同、過程、計劃和產(chǎn)品有關的文檔和數(shù)據(jù)； 源代碼、目標代碼和可執(zhí)行代碼； 相關產(chǎn)品，包括：軟件工具、包括庫在內(nèi)的可復 用軟件、外購軟件和用戶提供的軟件。,5,軟件

4、配置：所有以上產(chǎn)品在不同時期，出于不同要 求的組合，該組合隨著開發(fā)工作的進展而不斷演化。 可以說，軟件配置是指一個軟件產(chǎn)品在軟件生存期 各階段的不同形式（機器可讀或人工可讀）和不同 版本的文檔、程序及其數(shù)據(jù)的集合。該集合中的每 一個元素稱為該軟件產(chǎn)品軟件配置中的一個配置項。 如它可以是針對不同的硬件環(huán)境及軟件環(huán)境的組合。 例如，圖1表示某一軟件產(chǎn)品的初始系統(tǒng)展開出各種 版本。,配置標識（Configuration Identification) 配置標識包含了確定產(chǎn)品結構，選擇配置項，將配 置項的物理特性和功能特性以及接口和隨后的變更 形式文件，為配置項及相應文件分配標識符或編碼 的活動。,6

5、,(3)軟件配置管理的任務,制定配置管理計劃 確定標識規(guī)則 實施變更控制 配置狀態(tài)報告 配置審核 發(fā)行管理和版本管理,總之，軟件配置管理是軟件質量管理的一部分。它是對軟件生存期過程中的各種階級產(chǎn)品和最終產(chǎn)品演化或變更的管理。因此有人概括地說，軟件配置管理是要解決軟件地標識變更、控制變更和發(fā)布變更的問題。 表1給出了國際標準ISO/IEC軟件生存期過程中規(guī)定的軟件配置管理過程的活動和任務。,7,2，軟件配置管理計劃,原則上，軟件配置管理計劃是軟件開發(fā)計劃的一個組成部分。按國家標準GB/T 12505-90計算機軟件配置管理計劃規(guī)范的規(guī)定，軟件配置管理計劃應包括以下重要內(nèi)容：,明確規(guī)定負責軟件配置

6、管理的機構及其任務、職責 和有關接口的控制。 要開展的配置管理活動，涉及到：,配置標識 配置控制，即變更控制 配置狀態(tài)的記錄和報告 配置審核和評審,8,配置管理所采用的工具、技術和方法。 上述國家標準還附有軟件配置管理計劃的示例和配置管理報表及其格式。,9,表1 國際標準ISO/IEC 12207 (1995)信息技術軟件生存周期過程中規(guī)定的軟件配置管理過程,10,11,3，軟件配置標識,(1)確定配置項,大型軟件項目在其開發(fā)過程中可能產(chǎn)生數(shù)十各，上百個，甚至上千個文檔，其中有技術性的，也會有不少管理性的。技術性文檔是在不斷地變更著，依它們又是下個階段工作的依據(jù)。管理性的如計劃書、建議書、會議

7、錄、備忘錄等等，也是需要認真保管好的，但需要加以區(qū)分，例如項目計劃、需求規(guī)格說明、設計規(guī)格說明、源程序、測試數(shù)據(jù)等更為重要，被稱為正式文檔。確定配置項就是要從中做出選擇，決定哪些是受控的，稱之為配置項。圖2給出了一個軟件配置的層次圖，表2則列出了R.S.Pressman 推薦的軟件配置項清單。,12,(2)制定命名規(guī)則,配置標識的一項重要工作就是為配置項命名。合理的命名將有利于管理，使之不致造成混亂。命名的要求是唯一性（不允許多個配置項命名）和可追溯性（即命名能夠反映各配置項之間的相互關系，可追溯到相關的配置項）。,(2)樹狀（層次式）命名規(guī)則,例：圖3表明一個樹狀命名為了表明樹結構中的葉結點

8、CODE，需以根結點起，逐層連貫，直至該葉結點：PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE 顯然，這一命名方法是唯一，可追溯的，但在層次較多時，顯得不夠簡潔。,13,表2 軟件配置項清單,14,From:Roger S.PressmanSoftware Engineering APractitioners ApproachFourth Edition, McGraw-Hill,15,16,4，變更管理,(1)配置數(shù)據(jù)庫,作用： a. 用于記錄與配置相關的所有信息 b. 評價系統(tǒng)變更的后果 c. 提供配置管理過程的管理信息,17,三類庫 開發(fā)庫

9、(Development Library),專供開發(fā)人員使用，其中的信息會頻繁修改，對其控制相當寬松。,受控庫(Controlled Library),在生存期某一階段的工作結束時，存放階段產(chǎn)品而釋放的、與軟件開發(fā)工作有關的計算機可讀信息和人工可讀信息。 軟件配置管理就是對受控庫中的各個軟件項進行管理，也稱軟件配置管理庫。,產(chǎn)品庫(Product Library),在被開發(fā)的軟件產(chǎn)品完成系統(tǒng)測試后，作為最終產(chǎn)品存放，等待交付用戶運行或現(xiàn)場安裝。,18,典型的數(shù)據(jù)庫查詢問題,哪些客戶已提取了某個特定的系統(tǒng)版本？ 運行一個給定的系統(tǒng)版本需要什么硬件和操作系統(tǒng)？ 一個系統(tǒng)已生成了多少個版本，何時生成

10、的？ 若某個特定的組件變更了，會影響到系統(tǒng)的哪些版本？ 一個特定的版本有哪幾個變更請求是最為重要的？ 一個特定的版本有多少已報告的錯誤？,19,(2)基線與變更控制,開發(fā)過程中的變更不可能完全避免,變更的來源：變更如果來自用戶，即開發(fā)過程中用戶提出變更要求，這應該由CMM的2級KPA：需求管理加以解決。變更如果來自開發(fā)一方，如開發(fā)人員要修改以前已確定的技術方案或設計細部；或者是管理人員要修改以前已確定的項目方案，就應由變更控制加以解決。 變更的原因：隨著開發(fā)工作的進展，人們掌握了更多的信息，或是對問題和方案有了更為深刻的認識，通常提出的變更有其理由，如經(jīng)由控制的采納，可能會使項目的開發(fā)趨于合理

11、。,20,c) 變更管理的任務:,分析變更: 研究變更的重要性以及經(jīng)濟可行性(成本-效益)和技術可行性. 記錄及追蹤變更 保證變更在受控狀態(tài)下進行,21,基線(baseline),基線是軟件生存期各開發(fā)階段末尾的特定點,也稱為里程碑(milestone)。在這些特定點上階段工作已經(jīng)結束，并已經(jīng)取得的正式的階段產(chǎn)品。建立基線的概念是為了把各開發(fā)階段的工作劃分的更加明確，使連續(xù)的開發(fā)工作在這些點上斷開，使之利于檢驗和肯定階段成果。對于變更控制來說，原則上規(guī)定，不允許跨越里程碑運河修改另一階段的成果，認為該成果已告“凍結”。,圖4給出了軟件開發(fā)各階段的配置基線，箭頭指向各階段得到的工作產(chǎn)品。,22,

12、計劃,需求分析,設計,編碼,測試,計劃基線,需求基線,設計基線,編碼基線,測試基線,項目開發(fā)計劃,需求規(guī)格 說明 用戶手冊,設計規(guī)格說明,程序清單,測試報告,圖4 軟件配置基線,23,為實施配置管理通常使用以下三種基線： 功能基線最初通過的功能配置：功能基線是指在系統(tǒng)分析和軟件定義階段結束時，經(jīng)過正式評審和批準的系統(tǒng)設計規(guī)格說明中對被開發(fā)軟件系統(tǒng)的規(guī)格說明；或者是指經(jīng)過項目委托單位和項目承辦雙方簽字同意的協(xié)議書或合同中所規(guī)定的對被開發(fā)軟件系統(tǒng)的規(guī)格說明；或是指由下級申請及上級同意或直接由上級下達的項目任務書中所規(guī)定的對待開發(fā)軟件系統(tǒng)的規(guī)格說明。 分配基線分配基線是指在軟件需求分析階段結束時，經(jīng)

13、正式評審和批準的軟件需求規(guī)格說明。,24,產(chǎn)品基線產(chǎn)品基線是指在軟件組裝與系統(tǒng)測試階段結束時，經(jīng)正式評審和批準的有關所開發(fā)的軟件產(chǎn)品的全部配置項的規(guī)格說明。,(3) 變更控制,變更請求：提出變更請求表(Change Request Form),25,表3 變更控制表,項目名- 變更請求人- 日期- 編號- 要求的變更描述- 變更分析員- 分析日期- 受影響模塊- 變更評估- 變更優(yōu)先性- 變更實現(xiàn)- 估計工作量- CCB收到日期- CCB決定日期- CCB決定- 變更實施負責人- 變更日期- 遞交QA日期- QA決定- 遞交CM日期-,表中：CCB是變更控制委員會(Change Control

14、 Board) QA是質量保證組(Quality Assurance) CM是配置管理組(Configuration Management),26,變更管理過程按表4進行,記錄變更 a)將CRF作為配置項在數(shù)據(jù)庫中登錄 b)在變更了的模塊代碼上作變更記錄，以反應變更的 實際情況，如表5所示。,27,表4 變更控制過程,提交變更請求表CRF 分析變更請求 如果 變更能成立 則 估計變更如何實現(xiàn) 估算變更成本 將CRF送交CCB 如果 變更獲準 則 重復 實施變更 記錄變更 將變更的軟件提交QA審查 直到 軟件質量達到要求 由CM人員生成系統(tǒng)的新版本 否則 拒絕變更請求 否則 拒絕變更請求,28,

15、表5 變更記錄示例,/PROTEUS Project (ESPRIT) /PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE /Object: PCL_TOOL_DESC /作者：陳* /開發(fā)日期：1997.06.20 /版權歸屬：清華同方軟件與系統(tǒng)集成公司 /變更記錄 / 變更 變更負責人 日期 變更概要 變更理由 / 1.0 王* 98.1 * * / 1.1 李* 98.8 * *,29,5，版本管理和發(fā)行管理,(1) 版本管理是對系統(tǒng)不同版本進行標識和跟蹤的過程。,版本標識的目的是便于對版本進行檢索和跟蹤，顯 示各版本的關系。 一個版本是軟件系統(tǒng)的一個

16、實例，在功能和性能上 與其他版本有所差別，或是修正了前一版本的不足。 有些版本在功能上等價，但分別適用于不同的硬件 配置。,30,如果兩個版本只有少量的差異，則互相稱為變體 (Variant),例：某軟件的一個版本由5個組件構成，其中：組件4適用于彩色顯示器組件5適用于單色顯示器則它的兩個版本，或稱兩個變體是Version 1: 組件1，2，3，4Version 2: 組件1，2，3，5,1,2,3,4,5,圖5 變體示例,版本管理可用軟件工具支持，例如： RCS，SCCS，PVCS Version Manager,31,(2) 系統(tǒng)發(fā)行是分配給客戶的一個版本，每次系統(tǒng)發(fā)行 都應有新的功能或是

17、針對不同的硬件平臺。,通常軟件系統(tǒng)的版本數(shù)要比發(fā)行次數(shù)多，因為有的 版本并未發(fā)行，例如，有的版本僅供公司內(nèi)部使用 或專供測試等。 一次發(fā)行不僅是一個可執(zhí)行程序，它還應包括：,* 配置文件：規(guī)定發(fā)行應作的特定安裝* 數(shù)據(jù)文件：系統(tǒng)運行所需的數(shù)據(jù)* 安裝程序：系統(tǒng)如何安裝到目標機上* 電子文檔或書面文檔：對系統(tǒng)的描述,32,(3) 版本標識版本的命名規(guī)則,號碼版本標識 a) 線型,1.0,1.1,1.0,圖6 號碼版本標識,b) 系統(tǒng)發(fā)行一般提供的是基礎版，即1.0, 2.0 3.0等,33,問題： 不易區(qū)分新版本和新發(fā)行 若前一版本聲出了多個新版本，怎么編號 實際情況并非線型的，如圖7所示,V1

18、.0,V1.1,V1.1a,V1.1b,V1.2,V1.1.,V2.0,V2.1,V2.2,圖7 非線型版本順序,34,符號命名版本標識,* 不用V1.1.2形式，而用V1/VMS/DB Server表示一個 在VMS操作系統(tǒng)上運行的數(shù)據(jù)庫服務器版本* 優(yōu)點示能夠反映出版本的特性，比線型命名好，但 仍不能完全反映導出的真實情況,屬性版本標識,版本標識中反映的屬性有： 客戶、開發(fā)語言、開發(fā)狀態(tài)、硬件平臺、生成日期* 每個版本都由唯一的一組屬性標識，即一組唯一的 屬性值* 好處：容易加入新版本 版本間關系容易保持 易于檢索，如問：“最近生成的版本”、“在兩 個指定日期間生成的版本”。,35,(4)

19、 發(fā)行管理,新版本與新發(fā)行 新版本：修改報告出的軟件缺陷，開發(fā)新的代碼， 構成新系統(tǒng)。 新發(fā)行：除開發(fā)新代碼，構成新系統(tǒng)外，還要為客 戶準備數(shù)據(jù)、配置文件、寫新文檔、作包 裝。比新版本開銷大。,三種維護工作后，配置管理人員都要分析變更影響 的組件，確定何時生成新系統(tǒng)，何時作系統(tǒng)發(fā)行。,36,通常系統(tǒng)改動越多，可能引入的錯誤越多，這就必 須在下次發(fā)行時解決。為把出現(xiàn)問題的機會分散開， 往往把修補性變更后的發(fā)行與系統(tǒng)變更功能的發(fā)行 交叉起來，如圖8所示,增強性發(fā)行,增強性發(fā)行,增強性發(fā)行,增強性發(fā)行,增強性發(fā)行,圖8 交叉的發(fā)行示例,37,6，配置審核(Configuration Audit),(

20、1) 什么是配置審核,盡管已對軟件配置項作了標識，實施了變更控制和版本控制，就不會發(fā)生混亂了嗎？軟件開發(fā)的實踐表明，仍然會出問題。為解決這些問題，通常采用兩個方法，即 正式技術評審：對所用的變更逐一檢查一致性、遺 漏、副作用。軟件配置審核：作為評審的補充。,38,(2) 配置審核提出的問題,已確定的變更完成了嗎？有沒有做任意附加的修改？是否進行了正式的技術評審，以便評估技術的正確 性？是否遵循了軟件工程標準？所作的變更是否遵循了軟件配置管理規(guī)程？任一變更可能涉及到其他軟件配置項，是否也相應 作了變更？ 這些問題也可能在評審時提到，但若將配置管理作為一項正式活動，配置審核應由質量保證組(QA)單獨進行。,39,7，配置狀態(tài)報告（Configuration Status Reporting),(1) 什么是配置狀態(tài)報告,配置狀態(tài)報告（也稱Status Accounting）的目的時及時、準確地給出軟件配置項的當前