軟件配置教學提綱

軟件配置管理配置（Configuration）一詞在其它領(lǐng)域中已有廣泛的應(yīng)用，只不過稱呼有所不同，但都有其確切的含義。如原子結(jié)構(gòu)的形態(tài)和組態(tài)，控制系統(tǒng)的配置以及計算機系統(tǒng)的配置等等。許多領(lǐng)域也把配置稱為技術(shù)狀態(tài)。1，什么是配置管理ConfigurationManagement(1)幾種說法——ISO9000-3的4.8中給出：配置管理是一個管理學

科，它對配置項（包括軟件項）的開發(fā)和支持生

存期給予技術(shù)上和管理上的指導(dǎo)。配置管理的應(yīng)

用取決于項目的規(guī)模、復(fù)雜程度的風險大小。——W.Babich認為，軟件配置管理能協(xié)調(diào)軟件開發(fā)，使

得混亂減少到最小。軟件配置管理是一種標識、組

織和控制修改的技術(shù)，目的是最有效地提高生產(chǎn)率?！狦B/T11457:1995(軟件工程術(shù)語）對配置管理的解釋：A.標識和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存

周期內(nèi)控制這些項的投放和更動，記錄并報告配置

的狀態(tài)和更動要求，驗證配置項的完整性和正確性。B.對下列工作進行技術(shù)和行政指導(dǎo)與監(jiān)督的一套規(guī)范：

——對一配置項的功能和物理特性進行標識和文件編

制工作；

——控制這些特性的更動情況；

——記錄并報告對這些更動進行的處理和實現(xiàn)的狀態(tài)。(2)什么是軟件配置項(SoftwareConfigurationItem)——含義：配置管理的對象，軟件工程過程產(chǎn)生的所有

信息項?！ǎ河嬎銠C可執(zhí)行的源代碼、目標碼、數(shù)據(jù)庫

計算機不可執(zhí)行的文檔、源程序清單、測試用例?！芾淼漠a(chǎn)品(ISO9000-3的4.8)與合同、過程、計劃和產(chǎn)品有關(guān)的文檔和數(shù)據(jù)；源代碼、目標代碼和可執(zhí)行代碼；相關(guān)產(chǎn)品，包括：軟件工具、包括庫在內(nèi)的可復(fù)

用軟件、外購軟件和用戶提供的軟件。——軟件配置：所有以上產(chǎn)品在不同時期，出于不同要

求的組合，該組合隨著開發(fā)工作的進展而不斷演化。

可以說，軟件配置是指一個軟件產(chǎn)品在軟件生存期

各階段的不同形式（機器可讀或人工可讀）和不同

版本的文檔、程序及其數(shù)據(jù)的集合。該集合中的每

一個元素稱為該軟件產(chǎn)品軟件配置中的一個配置項。

如它可以是針對不同的硬件環(huán)境及軟件環(huán)境的組合。

例如，圖1表示某一軟件產(chǎn)品的初始系統(tǒng)展開出各種

版本?！渲脴俗R（ConfigurationIdentification)

配置標識包含了確定產(chǎn)品結(jié)構(gòu)，選擇配置項，將配

置項的物理特性和功能特性以及接口和隨后的變更

形式文件，為配置項及相應(yīng)文件分配標識符或編碼

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

和有關(guān)接口的控制?！_展的配置管理活動，涉及到：

配置標識配置控制，即變更控制配置狀態(tài)的記錄和報告配置審核和評審——配置管理所采用的工具、技術(shù)和方法。上述國家標準還附有軟件配置管理計劃的示例和配置管理報表及其格式。表1國際標準ISO/IEC12207(1995)

信息技術(shù)——軟件生存周期過程中規(guī)定的軟件配置管理過程活動任務(wù)解釋1.過程實施開發(fā)配置管理計劃計劃描述：配置活動、這些活動的規(guī)程、進度、配置管理組織及與其它組織的管理計劃應(yīng)形成文件2.配置標識規(guī)定標識規(guī)則以控制軟件項及其版本標識內(nèi)容包括：基線文檔、版本基準號、其它。3。配置控制標識并記錄變更申請分析與評價變更批準（或不批準）申請實現(xiàn)、驗證和發(fā)行已變更

的軟件項審核跟蹤變更控制并審核受控制軟件項跟蹤變更原因、變更授權(quán)以保證重要功能的安全或保密4.配置狀態(tài)報告編制管理記錄和狀態(tài)報告表明受控項(包括基線)的狀態(tài)和歷史狀態(tài)報告應(yīng)包括變更號、最新版本、發(fā)行標識、版本號及各版本比較5.配置評價確定和保證軟件項的功能完整性、物理完整性6.發(fā)行管理和交付有效控制軟件產(chǎn)品和文檔的發(fā)行和交付在產(chǎn)品的生存期內(nèi)保存代碼、文檔的主拷貝包含重要的安全或保密功能的代碼和文檔應(yīng)按組織的方針處理、儲存、包裝和交付3，軟件配置標識(1)確定配置項大型軟件項目在其開發(fā)過程中可能產(chǎn)生數(shù)十各，上百個，甚至上千個文檔，其中有技術(shù)性的，也會有不少管理性的。技術(shù)性文檔是在不斷地變更著，依它們又是下個階段工作的依據(jù)。管理性的如計劃書、建議書、會議錄、備忘錄等等，也是需要認真保管好的，但需要加以區(qū)分，例如項目計劃、需求規(guī)格說明、設(shè)計規(guī)格說明、源程序、測試數(shù)據(jù)等更為重要，被稱為正式文檔。確定配置項就是要從中做出選擇，決定哪些是受控的，稱之為配置項。圖2給出了一個軟件配置的層次圖，表2則列出了R.S.Pressman推薦的軟件配置項清單。(2)制定命名規(guī)則配置標識的一項重要工作就是為配置項命名。合理的命名將有利于管理，使之不致造成混亂。

命名的要求是唯一性（不允許多個配置項命名）和可追溯性（即命名能夠反映各配置項之間的相互關(guān)系，可追溯到相關(guān)的配置項）。(2)樹狀（層次式）命名規(guī)則例：圖3表明一個樹狀命名

為了表明樹結(jié)構(gòu)中的葉結(jié)點CODE，需以根結(jié)點起，逐層連貫，直至該葉結(jié)點：PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE顯然，這一命名方法是唯一，可追溯的，但在層次較多時，顯得不夠簡潔。表2軟件配置項清單1，系統(tǒng)規(guī)格說明2，軟件項目計劃3，軟件需求規(guī)格說明a.圖形分析模型

b.處理規(guī)格說明

c.原型

d.數(shù)學規(guī)格說明4，初步用戶手冊5，設(shè)計規(guī)格說明a.數(shù)據(jù)設(shè)計描述

b.體系結(jié)構(gòu)設(shè)計描述

c.模塊設(shè)計描述

d.接口設(shè)計描述

e.對象描述（采用面向?qū)ο蠹夹g(shù)時）6，源代碼清單7，測試規(guī)格說明a.測試計劃和步驟

b.測試用例和記錄的結(jié)果8，操作和安裝手冊9，可執(zhí)行程序a.模塊可執(zhí)行代碼

b.鏈接的模塊10，數(shù)據(jù)庫描述

a.模式和文件結(jié)構(gòu)

b.初始內(nèi)容11，聯(lián)機用戶手冊——————————

From:RogerS.Pressman

SoftwareEngineering–A

Practitioner’sApproach

FourthEdition,McGraw-Hill

——————————————12，維護文檔a.軟件問題報告

b.維護請求

c.工程變更指令13，軟件工程標準和規(guī)程4，變更管理(1)配置數(shù)據(jù)庫——作用：a.用于記錄與配置相關(guān)的所有信息b.評價系統(tǒng)變更的后果c.提供配置管理過程的管理信息——三類庫

開發(fā)庫(DevelopmentLibrary)專供開發(fā)人員使用，其中的信息會頻繁修改，對其控制相當寬松。受控庫(ControlledLibrary)在生存期某一階段的工作結(jié)束時，存放階段產(chǎn)品而釋放的、與軟件開發(fā)工作有關(guān)的計算機可讀信息和人工可讀信息。軟件配置管理就是對受控庫中的各個軟件項進行管理，也稱軟件配置管理庫。產(chǎn)品庫(ProductLibrary)在被開發(fā)的軟件產(chǎn)品完成系統(tǒng)測試后，作為最終產(chǎn)品存放，等待交付用戶運行或現(xiàn)場安裝。——典型的數(shù)據(jù)庫查詢問題

哪些客戶已提取了某個特定的系統(tǒng)版本？運行一個給定的系統(tǒng)版本需要什么硬件和操作系統(tǒng)？一個系統(tǒng)已生成了多少個版本，何時生成的？若某個特定的組件變更了，會影響到系統(tǒng)的哪些版本？一個特定的版本有哪幾個變更請求是最為重要的？一個特定的版本有多少已報告的錯誤？(2)基線與變更控制——開發(fā)過程中的變更不可能完全避免變更的來源：變更如果來自用戶，即開發(fā)過程中用戶提出變更要求，這應(yīng)該由CMM的2級KPA：需求管理加以解決。變更如果來自開發(fā)一方，如開發(fā)人員要修改以前已確定的技術(shù)方案或設(shè)計細部；或者是管理人員要修改以前已確定的項目方案，就應(yīng)由變更控制加以解決。

變更的原因：隨著開發(fā)工作的進展，人們掌握了更多的信息，或是對問題和方案有了更為深刻的認識，通常提出的變更有其理由，如經(jīng)由控制的采納，可能會使項目的開發(fā)趨于合理。c)變更管理的任務(wù):分析變更:研究變更的重要性以及經(jīng)濟可行性(成本-效益)和技術(shù)可行性.記錄及追蹤變更保證變更在受控狀態(tài)下進行——基線(baseline)基線是軟件生存期各開發(fā)階段末尾的特定點,也稱為里程碑(milestone)。在這些特定點上階段工作已經(jīng)結(jié)束，并已經(jīng)取得的正式的階段產(chǎn)品。

建立基線的概念是為了把各開發(fā)階段的工作劃分的更加明確，使連續(xù)的開發(fā)工作在這些點上斷開，使之利于檢驗和肯定階段成果。對于變更控制來說，原則上規(guī)定，不允許跨越里程碑運河修改另一階段的成果，認為該成果已告“凍結(jié)”。圖4給出了軟件開發(fā)各階段的配置基線，箭頭指向各階段得到的工作產(chǎn)品。計劃需求分析設(shè)計編碼測試計劃

基線需求

基線設(shè)計

基線編碼

基線測試

基線項目開發(fā)計劃需求規(guī)格說明用戶手冊設(shè)計規(guī)格說明程序清單測試報告圖4軟件配置基線為實施配置管理通常使用以下三種基線：功能基線——最初通過的功能配置：

功能基線是指在系統(tǒng)分析和軟件定義階段結(jié)束時，經(jīng)過正式評審和批準的系統(tǒng)設(shè)計規(guī)格說明中對被開發(fā)軟件系統(tǒng)的規(guī)格說明；或者是指經(jīng)過項目委托單位和項目承辦雙方簽字同意的協(xié)議書或合同中所規(guī)定的對被開發(fā)軟件系統(tǒng)的規(guī)格說明；或是指由下級申請及上級同意或直接由上級下達的項目任務(wù)書中所規(guī)定的對待開發(fā)軟件系統(tǒng)的規(guī)格說明。分配基線

分配基線是指在軟件需求分析階段結(jié)束時，經(jīng)正式評審和批準的軟件需求規(guī)格說明。產(chǎn)品基線

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

QA是質(zhì)量保證組(QualityAssurance)

CM是配置管理組(ConfigurationManagement)——變更管理過程按表4進行——記錄變更a)將CRF作為配置項在數(shù)據(jù)庫中登錄

b)在變更了的模塊代碼上作變更記錄，以反應(yīng)變更的

實際情況，如表5所示。表4變更控制過程提交變更請求表CRF分析變更請求如果變更能成立則估計變更如何實現(xiàn)估算變更成本將CRF送交CCB

如果變更獲準則

重復(fù)實施變更記錄變更將變更的軟件提交QA審查

直到軟件質(zhì)量達到要求由CM人員生成系統(tǒng)的新版本

否則拒絕變更請求

否則拒絕變更請求表5變更記錄示例//PROTEUSProject(ESPRIT)//PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE//Object:PCL_TOOL_DESC//作者：陳**//開發(fā)日期：1997.06.20//版權(quán)歸屬：清華同方軟件與系統(tǒng)集成公司//變更記錄//變更變更負責人日期變更概要變更理由//1.0王**98.1******//1.1李**98.8******5，版本管理和發(fā)行管理(1)版本管理是對系統(tǒng)不同版本進行標識和跟蹤的過程?！姹緲俗R的目的是便于對版本進行檢索和跟蹤，顯

示各版本的關(guān)系?！粋€版本是軟件系統(tǒng)的一個實例，在功能和性能上

與其他版本有所差別，或是修正了前一版本的不足?！行┌姹驹诠δ苌系葍r，但分別適用于不同的硬件

配置?！绻麅蓚€版本只有少量的差異，則互相稱為變體

(Variant)例：某軟件的一個版本由5個組件構(gòu)成，其中：

組件4適用于彩色顯示器

組件5適用于單色顯示器

則它的兩個版本，或稱兩個變體是

Version1:組件1，2，3，4

Version2:組件1，2，3，512345圖5變體示例——版本管理可用軟件工具支持，例如：

RCS，SCCS，PVCSVersionManager(2)系統(tǒng)發(fā)行是分配給客戶的一個版本，每次系統(tǒng)發(fā)行

都應(yīng)有新的功能或是針對不同的硬件平臺?！ǔ＼浖到y(tǒng)的版本數(shù)要比發(fā)行次數(shù)多，因為有的

版本并未發(fā)行，例如，有的版本僅供公司內(nèi)部使用

或?qū)９y試等?！淮伟l(fā)行不僅是一個可執(zhí)行程序，它還應(yīng)包括：*配置文件：規(guī)定發(fā)行應(yīng)作的特定安裝

*數(shù)據(jù)文件：系統(tǒng)運行所需的數(shù)據(jù)

*安裝程序：系統(tǒng)如何安裝到目標機上

*電子文檔或書面文檔：對系統(tǒng)的描述(3)版本標識——版本的命名規(guī)則——號碼版本標識a)線型1.01.11.0圖6號碼版本標識b)系統(tǒng)發(fā)行一般提供的是基礎(chǔ)版，即1.0,2.03.0等問題：

不易區(qū)分新版本和新發(fā)行

若前一版本聲出了多個新版本，怎么編號

實際情況并非線型的，如圖7所示V1.0V1.1V1.1aV1.1bV1.2V1.1.V2.0V2.1V2.2圖7非線型版本順序——符號命名版本標識*不用V1.1.2形式，而用V1/VMS/DBServer表示一個

在VMS操作系統(tǒng)上運行的數(shù)據(jù)庫服務(wù)器版本

*優(yōu)點示能夠反映出版本的特性，比線型命名好，但

仍不能完全反映導(dǎo)出的真實情況——屬性版本標識版本標識中反映的屬性有：

客戶、開發(fā)語言、開發(fā)狀態(tài)、硬件平臺、生成日期

*每個版本都由唯一的一組屬性標識，即一組唯一的

屬性值

*好處：容易加入新版本

版本間關(guān)系容易保持

易于檢索，如問：“最近生成的版本”、“在兩

個指定日期間生成的版本”。(4)發(fā)行管理——新版本與新發(fā)行

新版本：修改報告出的軟件缺陷，開發(fā)新的代碼，

構(gòu)成新系統(tǒng)。

新發(fā)行：除開發(fā)新代碼，構(gòu)成新系統(tǒng)外，還要為客

戶準備數(shù)據(jù)、配置文件、寫新文檔、作包

裝。比新版本開銷大?！N維護工作后，配置管理人員都要分析變更影響

的組件，確定何時生成新系統(tǒng)，何時作系統(tǒng)發(fā)行?！ǔＯ到y(tǒng)改動越多，可能引入的錯誤越多，這就必

須在下次發(fā)行時解決。為把出現(xiàn)問題的機會分散開，

往往把修補性變更后的發(fā)行與系統(tǒng)變更功能的發(fā)行

交叉起來，如圖8所示增強性發(fā)行增強性發(fā)行增強性發(fā)行增強性發(fā)行增強性發(fā)行圖8交叉的發(fā)行示例6，配置審核(ConfigurationAudit)(1)什么是配置審核盡管已對軟件配置項作了標識，實施了變更控制和版本控制，就不會發(fā)生混亂了嗎？軟件開發(fā)的實踐表明，仍然會出問題。為解決這些問題，通常采用兩個方法，即——正式技術(shù)評審：對所用的變更逐一檢查一致性、遺

漏、副作用。

——軟件配置審核：作為評審的補充。(2)配置審核提出的問題——已確定的變更完成了嗎？有沒有做任意附加的修改？

——是否進行了正式的技術(shù)評審，以便評估技術(shù)的正確

性？

——是否遵循了軟件工程標準？

——所作的變更是否遵循了軟件配置管理規(guī)程？

——任一變更可能涉及到其他軟件配置項，是否也相應(yīng)

作了變更？

這些問題也可能在評審時提到，但若將配置管理作為一項正式活動，配置審核應(yīng)由質(zhì)量保證組(QA)單獨進行。7，配置狀態(tài)報告（ConfigurationStatusReporting)(1)什么是配置狀態(tài)報告——配置狀態(tài)報告（也稱StatusAccounting）的目的時及

時、準確地給出軟件配置項的當前狀態(tài)，供相關(guān)人

員了解，以加強配置管理工作。相當于照片?！渲脿顟B(tài)報告可能提供的信息包括：＊當前作了哪些變更？

＊誰參與了這些變更？

＊何時作的變更？

＊可能影響的范圍是哪些？——報告可以定期提供，也可放如聯(lián)機數(shù)據(jù)庫中