軟件項目管理第12章 軟件配置管理

1、第12章 軟件配置管理 12.1 什么是軟件配置管理 12.2 軟件配置管理的相關(guān)概念 12.3 軟件配置管理的活動 12.4 軟件配置管理組織 12.5 配置管理工具 12.6 小結(jié) 12.1 什么是軟件配置管理變更是軟件過程中的一項基本活動，需求變更驅(qū)動設(shè)計變更，設(shè)計變更驅(qū)動代碼變更，測試活動也將導(dǎo)致變更，有時甚至是原始需求的變更。對于軟件過程中經(jīng)常遇到的變更問題，如果沒有有效的機(jī)制進(jìn)行控制，將會引起巨大的混亂，導(dǎo)致項目失敗。軟件配置管理(Software Configuration Management, SCM)就是在項目開發(fā)中，標(biāo)識、控制和管理軟件變更的一種管理活動，是通過技術(shù)或行政

2、手段對軟件產(chǎn)品及其開發(fā)過程和生命周期進(jìn)行控制、規(guī)范的一系列措施，用于記錄軟件產(chǎn)品的演化過程，最大限度地減少錯誤和混亂，保證軟件項目工作產(chǎn)品在整個生命周期內(nèi)的完整性。IEEE關(guān)于軟件配置管理的定義為：軟件配置管理是一門應(yīng)用技術(shù)、管理和監(jiān)督相結(jié)合的學(xué)科，通過標(biāo)識和文檔來記錄配置項的功能和物理特性，控制這些特性的變更，記錄和報告變更的過程和狀態(tài)，并驗證它們與需求是否一致。隨著軟件開發(fā)規(guī)模的不斷擴(kuò)大，一個項目的中間軟件產(chǎn)品的數(shù)目越來越多，中間軟件產(chǎn)品之間的關(guān)系越來越復(fù)雜，對中間軟件產(chǎn)品的管理也越來越困難，有效的軟件配置管理有助于解決這些問題。軟件配置管理貫穿于軟件生存期的全過程，目的是用于建立和維護(hù)軟

3、件產(chǎn)品的完整性和可追朔性。12.1.1 配置管理需求分析現(xiàn)在的軟件開發(fā)通常由許多人共同合作完成。在團(tuán)隊開發(fā)模式中，軟件項目開發(fā)管理就顯得更加重要，直接影響到軟件產(chǎn)品的質(zhì)量。如果缺乏對軟件開發(fā)過程的統(tǒng)一管理，就會產(chǎn)生如圖12.1所示的問題。 圖12.1 缺乏統(tǒng)一管理出現(xiàn)的問題(在實際開發(fā)中表現(xiàn)為項目組成員溝通困難、軟件重用率低下、開發(fā)人員各自為政、代碼冗余度高、文檔不健全等)缺乏統(tǒng)一管理出現(xiàn)的問題具體描述為：(1) 由于開發(fā)經(jīng)費及開發(fā)時間的限制，不可能一次開發(fā)就解決所有問題，許多問題有待維護(hù)階段解決，由此帶來軟件產(chǎn)品的不斷升級，但是維護(hù)和升級必需的文檔往往非?；靵y。(2) 開發(fā)過程缺乏規(guī)范化管理

4、，即使有源程序以及相應(yīng)的文檔，也由于說明不詳細(xì)而不能對產(chǎn)品進(jìn)行功能擴(kuò)充，用戶不得不再次投入大量的經(jīng)費去開發(fā)新產(chǎn)品，浪費大量的人力、物力和時間。(3) 在開發(fā)團(tuán)隊中，人員流動在所難免。如果管理不善，有些人員流動將對開發(fā)工作產(chǎn)生致命影響。特別是軟件開發(fā)管理人員或核心成員的流失，可能會導(dǎo)致無法確定軟件產(chǎn)品中各模塊所處的狀態(tài)及階段，使軟件產(chǎn)品版本出現(xiàn)混亂，甚至可能泄露公司的核心機(jī)密。(4) 管理不善可能導(dǎo)致未經(jīng)測試的軟件成分加入到產(chǎn)品中，不但會影響產(chǎn)品質(zhì)量，有時還會導(dǎo)致致命錯誤，以至造成不可挽回的損失。(5) 用戶利益無法保證，用戶與開發(fā)商缺乏有效的溝通手段。用戶投入了開發(fā)費用后，得到的只是可執(zhí)行文件

5、和一堆雜亂無章的文檔。即使是較好的文檔，對不熟悉開發(fā)過程的非專業(yè)人員來說也無從下手，更談不上日后的維護(hù)和升級。(6) 軟件生產(chǎn)達(dá)不到規(guī)?；?，無法形成軟件企業(yè)的內(nèi)部標(biāo)準(zhǔn)構(gòu)件倉庫。軟件產(chǎn)品總處于一種低水平、重復(fù)開發(fā)的狀態(tài)，不但時間得不到保證，而且成本也無法降低，產(chǎn)品也就缺乏市場競爭力。這些問題在實際開發(fā)中表現(xiàn)為項目組成員溝通困難、軟件重用率低下、開發(fā)人員各自為政、代碼冗余度高、文檔不健全等。由此造成的后果是數(shù)據(jù)丟失、開發(fā)周期漫長、產(chǎn)品可靠性差、軟件維護(hù)困難、用戶抱怨使用不方便、項目風(fēng)險增加等。怎樣進(jìn)行軟件開發(fā)管理才能生產(chǎn)出高質(zhì)量的軟件產(chǎn)品呢？ISO 9000質(zhì)量管理和質(zhì)量保證體系制定了相關(guān)標(biāo)準(zhǔn)軟件

6、開發(fā)、供應(yīng)和維護(hù)使用指南。標(biāo)準(zhǔn)除對軟件生命周期的各個階段做出了嚴(yán)格規(guī)定外，還在質(zhì)量體系中規(guī)定了與階段無關(guān)的支持活動，其中軟件配置管理被放在了首位。作為管理軟件開發(fā)過程的有效方法，SCM的有效性早已被發(fā)達(dá)國家軟件產(chǎn)業(yè)的發(fā)展實踐所證明。SCM可以系統(tǒng)地管理軟件系統(tǒng)中的多重版本，全面記載系統(tǒng)開發(fā)的歷史過程，包括為什么修改、誰做了修改、修改了什么，同時管理和追蹤開發(fā)過程中危害軟件質(zhì)量、影響開發(fā)周期的缺陷和變化。SCM對開發(fā)過程進(jìn)行有效的管理和控制，完整、明確地記載開發(fā)過程中的歷史變更，形成規(guī)范化的文檔。SCM是通往ISO 9000和SEI CMM標(biāo)準(zhǔn)的基石。在軟件開發(fā)團(tuán)隊中，正確地引入、實施軟件配置管

7、理系統(tǒng)，可以提高生產(chǎn)力、增強(qiáng)對項目的控制能力、改善軟件產(chǎn)品質(zhì)量，使企業(yè)從容地面對快速上市和產(chǎn)品質(zhì)量的雙重壓力。12.1.2 配置管理的作用隨著軟件系統(tǒng)的日益復(fù)雜化和用戶需求的多樣化、軟件升級的頻繁化，軟件配置管理逐漸成為軟件生存周期中的重要控制過程，在軟件開發(fā)過程中扮演著越來越重要的角色。好的配置管理過程能覆蓋軟件開發(fā)和維護(hù)的各個方面，同時對軟件開發(fā)過程的宏觀管理(即項目管理)也有重要的支持作用。良好的配置管理能使軟件開發(fā)過程有更好的可預(yù)測性，使軟件系統(tǒng)具有可重復(fù)性，使用戶和主管部門對軟件質(zhì)量和開發(fā)小組有更強(qiáng)的信心。軟件配置管理通過對軟件的修改和每個修改生成的軟件組成部件進(jìn)行控制、記錄、追蹤來

8、實現(xiàn)對軟件產(chǎn)品的管理功能。由于軟件產(chǎn)品是在用戶需求不斷變化的驅(qū)動下不斷變化的，為了保證對產(chǎn)品有效地進(jìn)行控制和追蹤，配置管理過程不能僅對靜態(tài)的、成型的產(chǎn)品進(jìn)行管理，還必須對動態(tài)的、成長的產(chǎn)品進(jìn)行管理。由此可見，配置管理同軟件開發(fā)過程緊密相關(guān)。配置管理必須緊扣軟件開發(fā)過程的各個環(huán)節(jié)：管理用戶所提出的需求，監(jiān)控其實施，確保用戶需求最終落實到產(chǎn)品的各個版本中去，并在產(chǎn)品發(fā)行和用戶支持等方面提供幫助，響應(yīng)用戶新的需求，推動新的開發(fā)周期。通過配置管理過程控制，用戶對軟件產(chǎn)品的需求如同普通產(chǎn)品的訂單一樣，遵循嚴(yán)格的流程，經(jīng)過受控的生產(chǎn)流水線，最后形成產(chǎn)品，發(fā)售給相應(yīng)用戶。從另一個角度看，在產(chǎn)品開發(fā)的不同階段

9、通常有不同的任務(wù)，由不同的角色擔(dān)當(dāng)，各個角色職責(zé)明確、涇渭分明，同時又前后銜接、相互協(xié)調(diào)。好的配置管理過程有助于規(guī)范各個角色的行為，同時又為角色之間的任務(wù)傳遞提供無縫銜接，使整個開發(fā)團(tuán)隊像一個交響樂隊一樣和諧地進(jìn)行。正因為配置管理過程直接連接產(chǎn)品開發(fā)過程、開發(fā)人員和最終產(chǎn)品，這些都是項目主管人員關(guān)注的重點，因此，配置管理在軟件項目管理中也起著越來越重要的作用。配置管理過程演化出的控制、報告功能可以幫助項目經(jīng)理更好地了解項目進(jìn)度、開發(fā)人員負(fù)荷、工作效率、產(chǎn)品質(zhì)量狀況和交付日期等信息。同時，配置管理過程所規(guī)范的工作流程和明確分工有利于管理者應(yīng)付開發(fā)人員流動的困境，使新老成員可以快速實現(xiàn)任務(wù)交接，盡

10、量減少因人員流動造成的損失。配置管理對軟件開發(fā)項目的具體作用，表現(xiàn)在以下幾個方面：(1) 縮短開發(fā)周期。通過配置管理工具對程序資源進(jìn)行版本管理和跟蹤，建立公司的代碼知識庫，保存開發(fā)過程中每個過程的版本，可以提高代碼重用率，便于同時維護(hù)多個版本和進(jìn)行新版本開發(fā)，防止系統(tǒng)崩潰，最大限度地共享代碼。同時，項目管理人員通過查看項目開發(fā)日志對開發(fā)過程進(jìn)行管理，測試人員可以根據(jù)開發(fā)日志的不同版本對軟件進(jìn)行測試，工程人員可以得到不同的運行版本。有些配置管理工具還提供Web版本，供外地實施人員存取最新版本，無須開發(fā)人員親臨現(xiàn)場。(2) 減少施工費用。利用配置管理工具，建立開發(fā)管理規(guī)范，把版本管理檔案鏈接到公司

11、內(nèi)部的Web服務(wù)器上，內(nèi)部人員可直接通過瀏覽器訪問，工程人員通過遠(yuǎn)程進(jìn)入內(nèi)部網(wǎng)，進(jìn)而獲取所需的最新版本。開發(fā)人員無須親自到現(xiàn)場，現(xiàn)場工程人員通過對方系統(tǒng)管理員收集反饋意見，書面提交到公司內(nèi)部開發(fā)組的項目經(jīng)理，開發(fā)組內(nèi)部討論決定是否修改，并做出書面答復(fù)。這樣可以同時響應(yīng)多個項目，防止開發(fā)人員被分配到各個項目引起力量分散、人員緊缺等問題，避免開發(fā)人員將大量的時間和精力浪費在旅途中，同時節(jié)約大量的差旅費用。(3) 代碼對象庫的建立。軟件代碼是軟件開發(fā)人員腦力勞動的結(jié)晶，也是軟件公司的寶貴財富，長期開發(fā)過程中形成的各種代碼對象就如同一個個已生產(chǎn)好的標(biāo)準(zhǔn)件一樣，是快速生成系統(tǒng)的組成部分。一個長期的事實是

12、：一旦某個開發(fā)人員離開工作崗位，其原來所做的代碼便基本成為垃圾，無人過問。究其原因，就是沒有專門對各個開發(fā)人員的有用代碼對象進(jìn)行管理，沒有把使用范圍擴(kuò)大到公司一級，沒有進(jìn)行規(guī)范化，沒有加以說明和普及。配置管理對軟件對象管理提供了一個平臺和倉庫，有利于建立公司級的代碼對象庫。(4) 建立業(yè)務(wù)及經(jīng)驗庫。通過配置管理，可以形成完整的開發(fā)日志及問題集合，以文檔方式伴隨開發(fā)的全過程，不以某個人的轉(zhuǎn)移而消失，有利于公司積累業(yè)務(wù)經(jīng)驗，無論對版本修改還是版本升級，都具有重要的指導(dǎo)作用。(5) 量化工作量考核。傳統(tǒng)的開發(fā)管理中，工作量一直是難以估量的指標(biāo)，靠開發(fā)人員自己把握，隨意性很大；靠管理人員把握，主觀性卻

13、又太強(qiáng)。采用配置管理工具，開發(fā)人員每天下班前將修改的文件上傳，記述當(dāng)天修改的細(xì)節(jié)，這些描述可以作為工作量的衡量指標(biāo)。(6) 規(guī)范測試。采用配置管理，測試工作有了實實在在的內(nèi)容，測試人員根據(jù)每天的修改細(xì)節(jié)描述，對每天的工作做具體測試，對測試人員也具有可考核性，這樣環(huán)環(huán)相扣，減少了工作的隨意性。(7) 加強(qiáng)協(xié)調(diào)與溝通。采用配置管理，通過文檔共享及其特定鎖定機(jī)制，為項目組成員之間搭建交流的平臺，加強(qiáng)項目組成員之間的溝通，做到有問題及時發(fā)現(xiàn)、及時修改、及時通知，但又不額外增加太多的工作量。從這些具體作用可以看出，配置管理確實能夠解決困擾軟件項目經(jīng)理的很多問題。12.2 軟件配置管理的相關(guān)概念12.2.

14、1 軟件配置項軟件配置管理的對象就是軟件配置項(Software Configuration Item, SCI)。軟件配置是指一個軟件產(chǎn)品在軟件生命周期各個階段產(chǎn)生的各種形式和各種版本的文檔、程序及其數(shù)據(jù)的集合，軟件配置項就是該集合中的一個元素。例如，需求規(guī)格說明書、設(shè)計規(guī)格說明書、源代碼、可執(zhí)行程序、安裝包、測試計劃、測試用例、測試數(shù)據(jù)、用戶手冊和項目計劃等。另外，構(gòu)造軟件的工具和軟件賴以運行的環(huán)境也應(yīng)作為軟件配置項來管理，例如操作系統(tǒng)、開發(fā)工具、數(shù)據(jù)庫管理系統(tǒng)和編輯器等，這些工具和環(huán)境要與特定版本的軟件產(chǎn)品相匹配，從而在任何時候都能夠構(gòu)造和運行軟件的任一版本。1. 軟件配置項的狀態(tài)在軟件

15、生命周期中，一般包括制定計劃、需求、分析、設(shè)計、實現(xiàn)、測試和運行維護(hù)等狀態(tài)。與此相似，軟件配置項可劃分為設(shè)計態(tài)、測試態(tài)、受控態(tài)和運行態(tài)4種狀態(tài)，狀態(tài)聯(lián)系如圖12.2所示。圖12.2 軟件配置項的4種狀態(tài)(這4種狀態(tài)之間沿箭頭方向進(jìn)行轉(zhuǎn)換，進(jìn)入受控態(tài)就表示配置項已經(jīng)過測試，可以進(jìn)入配置庫，受控態(tài)需要交付就進(jìn)入運行態(tài)，進(jìn)入產(chǎn)品庫)這4種狀態(tài)相互之間的聯(lián)系具有方向性，沿圖中實線箭頭所指方向的狀態(tài)變化是允許的，虛線表示為了驗證或檢測某些功能或性能而重新執(zhí)行相應(yīng)的測試，一般不沿虛線變化。2. 軟件配置項的版本軟件配置項也有不同的版本，配置項和配置項的版本類似于面向?qū)ο蟮念惡蛯嵗?。配置項可以看成是類，版?/p>

16、看成是類的實例。例如，圖l2.3表示了數(shù)據(jù)庫設(shè)計說明的配置項。數(shù)據(jù)庫設(shè)計說明的不同版本對應(yīng)于數(shù)據(jù)庫設(shè)計說明的實例。配置項的不同版本是從最原始的配置項(相當(dāng)于配置項類)逐漸演變而來的，盡管每個都不相同，但是具有相關(guān)性。圖12.3 軟件配置項類及實例(配置項和配置項的不同版本類似于面向?qū)ο蟮念惡蛯嵗?3. 軟件配置項的分類在軟件開發(fā)過程中，最早的軟件配置項是系統(tǒng)需求規(guī)格說明書。隨著軟件開發(fā)過程的不斷深入，需要納入管理的各種工作產(chǎn)品越來越多，軟件配置項的數(shù)量也隨之上升，而軟件配置管理的目的是在軟件項目的整個生存周期內(nèi)建立和標(biāo)識軟件配置項，并對其進(jìn)行控制管理和跟蹤維護(hù)，保證其完整性和一致性。這樣軟件配

17、置管理的作用將清晰可見。通過對軟件配置項進(jìn)行分類，可以加強(qiáng)對軟件配置項的管理。軟件配置項的分類如表l2-1所示。表12-1 軟件配置項的分類12.2.2 基線1. 基線的定義基線是一個或多個配置項的集合，它們的內(nèi)容和狀態(tài)已經(jīng)通過技術(shù)復(fù)審，并在生存期的某個階段被接受了。一旦配置項經(jīng)過復(fù)審并正式成為一個初始基線，那么該基線就可以作為項目生存期開發(fā)活動的起始點。IEEE對基線的定義是這樣的：“已經(jīng)正式通過復(fù)審和批準(zhǔn)的某規(guī)約或產(chǎn)品，可作為進(jìn)一步開發(fā)的基礎(chǔ)，只能通過正式的變更控制過程才能改變?！彼?，根據(jù)這個定義，在軟件的開發(fā)流程中把所有需加以控制的配置項分為基線配置項和非基線配置項兩類。例如，基線配置

18、項可能包括所有的設(shè)計文檔和源程序等，非基線配置項可能包括項目的各類計劃和報告等?；€代表了軟件開發(fā)過程的各個里程碑，標(biāo)志了一個開發(fā)過程階段的結(jié)束。對于已成為基線的配置項，雖然可以修改，但是必須按照一個特殊的、正式的過程進(jìn)行評估，確認(rèn)每一處修改，只有批準(zhǔn)的修改才能安排資源來實施修改。相反，對于未成為基線的配置項，可以進(jìn)行非正式修改。在開發(fā)過程中，在不同階段要建立各種基線，因此基線是具有里程碑意義的一個配置。雖然基線可在任何級別上定義，但是一般最常用的軟件基線如圖12.4所示。基線提供了軟件生存期中各開發(fā)階段的特點，其作用是把開發(fā)階段工作的劃分更加明確化，使本來連續(xù)的工作在這些點上斷開，以便于檢查

19、與肯定階段成果。在交付項中確定一個一致的子集，作為軟件配置基線，這些版本一般不是同一時間產(chǎn)生的，但是具有在開發(fā)的某一特定步驟上相互一致的性質(zhì)，例如系統(tǒng)的一致、狀態(tài)的一致等。基線可以作為一個檢查點，正式發(fā)行的系統(tǒng)必須是經(jīng)過控制的基線產(chǎn)品。圖12.4 軟件基線示意圖(基線可以作為一個檢查點，以便檢查與肯定階段成果)2. 建立基線的原因建立基線的三大原因是重現(xiàn)性、可追蹤性和報告。(1) 重現(xiàn)性：指及時返回并重新生成軟件系統(tǒng)給定發(fā)布版本的能力，或者是在項目早期重新生成開發(fā)環(huán)境的能力。(2) 可追蹤性：指建立項目部件之間的前承后繼關(guān)系，目的在于確保設(shè)計滿足要求、代碼實施設(shè)計以及用正確代碼編譯可執(zhí)行文件。

20、(3) 報告：來源于一個基線內(nèi)容同另一個基線內(nèi)容的比較，基線比較有助于調(diào)試并生成發(fā)布說明。3. 基線的分類一般來說，對于大多數(shù)生存周期模型而言，存在四種基線。每種基線都表示一個參照點，可以作為項目進(jìn)一步開發(fā)的起點。在某些情況下，客戶依據(jù)這些基線進(jìn)行評審和支付費用。這四種基線是：功能基線、分配基線、開發(fā)基線和產(chǎn)品基線。(1) 功能基線。功能基線描述系統(tǒng)應(yīng)該能夠執(zhí)行的功能，是在系統(tǒng)需求評審和系統(tǒng)設(shè)計評審之后所建立的配置。通常，功能基線是軟件開發(fā)項目的初始基線。功能基線中的文檔規(guī)范了軟件配置項的所有必要的功能特性，包括為表示這些特性的實現(xiàn)所要求的系統(tǒng)層的測試、必要的接口特性、性能需求、質(zhì)量屬性及設(shè)計

21、約束等，但并不區(qū)分哪些是由軟件執(zhí)行的，哪些是由硬件和操作系統(tǒng)完成的。(2) 分配基線。分配基線有時候稱為軟件需求基線。它描述了被開發(fā)的軟件所能執(zhí)行的功能，是在軟件需求評審之后建立起來的配置，是系統(tǒng)分配給軟件的需求配置，一般是軟件項目組在完成對系統(tǒng)的功能性需求和非功能性需求分析后，經(jīng)過客戶參與評審確定后的軟件需求規(guī)格說明。(3) 開發(fā)基線。開發(fā)基線是一個不斷演化和積累的基線，出現(xiàn)于分配基線和產(chǎn)品基線之間。軟件開發(fā)項目組可以根據(jù)項目的需要設(shè)置開發(fā)基線，也就是說在詳細(xì)設(shè)計完成之后設(shè)立一個基線，包括詳細(xì)設(shè)計報告、概要設(shè)計報告和數(shù)據(jù)庫設(shè)計等設(shè)計文檔。(4) 產(chǎn)品基線。產(chǎn)品基線是在經(jīng)過系統(tǒng)層驗證和確認(rèn)后，

22、確信可交付的產(chǎn)品滿足需求基線中的所有需求項所建立起來的配置。因此，產(chǎn)品基線完整地記錄了軟件的最終版本。對外發(fā)布的產(chǎn)品都來源于這一產(chǎn)品基線，并支持產(chǎn)品的發(fā)布版本。該基線也是任一后續(xù)版本開發(fā)的起點。這四種基線的劃分在項目開發(fā)周期中對應(yīng)的位置如圖12.5所示。圖12.5 基線規(guī)劃圖(分配基線、開發(fā)基線和產(chǎn)品基線主要是針對軟件項目的配置基線)4. 建立基線的優(yōu)點(1) 基線為開發(fā)部件提供了一個定點和快照。(2) 新項目可以從基線提供的定點處建立。作為一個單獨的分支，新項目將與隨后對原始項目所進(jìn)行的變更進(jìn)行隔離。(3) 各開發(fā)人員可以將建有基線的構(gòu)件作為在隔離的私有工作區(qū)中進(jìn)行更新的基礎(chǔ)。(4) 當(dāng)認(rèn)為

23、更新不穩(wěn)定或不可信時，基線為團(tuán)隊提供了一種取消變更的方法。(5) 可以利用基線重新建立基于某個特定發(fā)布版本的配置，這樣也可以重現(xiàn)已報告的錯誤。(6) 定期建立基線，以確保各開發(fā)人員的工作保持同步。12.2.3 版本版本是某一配置項已標(biāo)識了的實例。版本用來定義一個具體實例應(yīng)該具有什么樣的內(nèi)容和屬性。隨著軟件的開發(fā)進(jìn)展，版本也在不斷地演變，這些不同配置項的不同版本構(gòu)成了一個復(fù)雜的版本空間。一個系統(tǒng)版本就是一個系統(tǒng)實例，在某種程度上有別于其他系統(tǒng)實例。系統(tǒng)新版本可能有不同的功能和性能，可能修改了系統(tǒng)錯誤。有些版本可能在功能上沒有什么不同，只是為不同的硬件或軟件配置而設(shè)計的。如果版本之間只有細(xì)微區(qū)別，

24、有時就把其中的一個版本稱作另一個版本的變體。一個系統(tǒng)的發(fā)布版本指的是要分發(fā)給客戶的版本。每個系統(tǒng)發(fā)布版本都應(yīng)該包含新的功能或是針對不同的硬件平臺。一個系統(tǒng)的版本要比發(fā)布版本多得多，因為機(jī)構(gòu)的內(nèi)部版本是為內(nèi)部開發(fā)或測試而創(chuàng)建的，有些根本不會發(fā)布到客戶手中。版本的演變一般有串行演變和并行演變兩種方式。串行演變所形成的每個新版本都是由當(dāng)前最新版本演變而來的。這樣，各個不同版本按演變過程就形成了一個簡單鏈，稱為版本鏈。在這種方式下，版本的演變是按照一對一的映射關(guān)系前進(jìn)的，通常是為了彌補(bǔ)缺陷、提高性能和適應(yīng)環(huán)境。并行演變采用一對多的方式進(jìn)行。在實際應(yīng)用中，這兩種版本演變形式通常結(jié)合在一起，形成更為普通的

25、帶分支的版本圖，也稱為版本樹。版本樹反映了項目開發(fā)演變的歷史，版本樹示例如圖12.6所示。圖12.6 版本樹示例(版本樹直觀地反映了版本的演變過程)在圖12.6中，共有3條版本鏈，分別是“1.01.11.2 1.31.41.5”、“1.01.11.1.11.1.2”和“1.01.11.2 2.02.12.23.03.0.1”。其中，“1.01.11.21.3 1.41.5”是串行演變；從1.1開始，“1.11.2”和“1.11.1.1”是并行演變。為了建立特定的系統(tǒng)版本，必須確定系統(tǒng)組件的版本。在大型軟件系統(tǒng)內(nèi)，有數(shù)以百計的軟件組件，其中每種組件都可能有諸多不同的版本。版本管理規(guī)程應(yīng)該規(guī)定明確

26、標(biāo)識每個組件版本演變的方法，這樣在需要進(jìn)一步變更時，可以查找到組件的具體版本。組件版本的變化過程如圖12.7所示。圖12.7 組件版本的變化過程(版本管理可以方便地標(biāo)識每個組件版本演變的過程)12.2.4 配置數(shù)據(jù)庫配置數(shù)據(jù)庫(Configuration Management Database, CMDB)用于記錄與配置有關(guān)的所有信息，幫助評估因系統(tǒng)變更帶來的影響，并提供有關(guān)配置管理過程的管理信息，也稱為軟件受控庫。除了定義配置數(shù)據(jù)庫的模式以外，還要定義記錄和檢索項目信息的規(guī)程，這是配置管理規(guī)劃過程的一部分。配置數(shù)據(jù)庫不僅包含有關(guān)配置項的信息，可能也包含組件用戶、系統(tǒng)用戶、可執(zhí)行平臺及計劃變更

27、等信息。配置數(shù)據(jù)庫必須能夠?qū)Ω鞣N系統(tǒng)配置查詢做出應(yīng)答。理想情況下，配置數(shù)據(jù)庫與版本管理系統(tǒng)集成到一起，版本管理系統(tǒng)負(fù)責(zé)存儲和管理正式項目文檔。這種方法(某些集成CASE工具支持該方法)使得變更與受變更影響的文檔和組件間的直接鏈接成為可能。例如，設(shè)計文檔和程序代碼之間的鏈接能得到維護(hù)，這樣在提出一個變更時，可以較容易地找出所有必須修改的地方。由于配置管理的集成CASE工具非常昂貴，許多公司在進(jìn)行配置管理時并不考慮使用，而是把配置數(shù)據(jù)庫作為一個獨立的系統(tǒng)加以維護(hù)，配置項存儲于文件或版本管理系統(tǒng)中，例如CVS、Subversion就是版本管理系統(tǒng)。配置數(shù)據(jù)庫存儲配置項的有關(guān)信息并在版本管理系統(tǒng)或文件

28、存儲中索引它們的名字。雖然這種做法費用低廉、使用靈活，但是配置項的變更可能不經(jīng)過配置數(shù)據(jù)庫，因此不能確定配置數(shù)據(jù)庫是否反映了系統(tǒng)的最新狀態(tài)。建立構(gòu)建腳本是軟件項目的有效實踐，配置數(shù)據(jù)庫不僅要存儲各種文檔和源代碼，還要存儲環(huán)境配置，甚至是構(gòu)建腳步。 12.3 軟件配置管理的活動實施軟件配置管理就是要在軟件的整個生命周期中建立和維護(hù)軟件的完整性。軟件配置管理是組織和管理各種軟件產(chǎn)品及文檔，控制其變化的一系列活動，這些活動將貫穿軟件產(chǎn)品的整個生命周期。在項目管理過程中，需要解決的問題有很多，例如采用何種方式標(biāo)識和管理已存在程序的各種版本、在軟件交付用戶前后如何控制變更、利用什么辦法來估計變更引起的各

29、種問題等，這些問題歸結(jié)到軟件配置管理中的活動方面。通常的軟件項目配置管理包括以下12項活動：擬定配置管理計劃；配置標(biāo)識；確定配置管理范圍；確認(rèn)和記錄配置項屬性；為配置項定義標(biāo)識符；確定配置基線；確定配置結(jié)構(gòu)；確定配置項命名規(guī)則；配置項控制；配置狀態(tài)報告；配置審計；配置管理數(shù)據(jù)庫的備份、存檔和保管。通過上述活動，可以實現(xiàn)軟件配置管理，其主要流程如圖12.8所示。圖12.8 軟件配置管理的主要流程(項目組制定SCM計劃，進(jìn)入配置數(shù)據(jù)庫，供開發(fā)人員和管理人員使用。其中PTO(Project Tracing and Oversight)即項目跟蹤與監(jiān)督)根據(jù)圖12.8，對配置管理流程中各項活動進(jìn)行分析

30、，可將軟件配置管理流程中具體實施的活動歸納為以下5個主要活動：配置標(biāo)識：在系統(tǒng)演化過程中標(biāo)識中間的軟件產(chǎn)品；版本控制：記錄每個配置項的發(fā)展歷史，并控制基線的生成；變更控制：在整個生命周期中控制中間軟件產(chǎn)品的變化；狀態(tài)報告：記錄和報告軟件的變化過程；配置審計：用于保證軟件產(chǎn)品是依照需求、標(biāo)準(zhǔn)和合同開發(fā)出來的。12.3.1 配置標(biāo)識在軟件開發(fā)過程中，隨著軟件生命周期的推進(jìn)，產(chǎn)生的配置項越來越多，為了控制和管理方便，所有的軟件配置項都應(yīng)該按照一定的方式來命名和組織，這是進(jìn)行軟件配置管理的基礎(chǔ)。配置標(biāo)識能唯一地標(biāo)識軟件配置項，并在技術(shù)文檔中記錄其功能特征和物理特征，使它們可以通過某種方式訪問。配置標(biāo)識

31、的目標(biāo)是在整個系統(tǒng)生命周期中標(biāo)識系統(tǒng)的構(gòu)件，提供軟件和軟件相關(guān)產(chǎn)品之間的跟蹤能力。軟件配置標(biāo)識是軟件配置管理的基礎(chǔ)性工作，是管理配置的前提。每個軟件配置項都包括名字、描述、資源列表和實際存在體4個部分。此外，在對配置項進(jìn)行標(biāo)識時，還要考慮配置項之間的關(guān)系。配置標(biāo)識管理是一個配置項的選擇、命名和描述的過程。首先，把一個軟件系統(tǒng)分成便于進(jìn)行配置管理的配置項；接著，按照一定的方法對這些配置項命名、編號，便于管理人員和開發(fā)人員明確該系統(tǒng)各配置項之間的相互關(guān)系，包括各個文檔之間以及文檔與代碼之間的聯(lián)系；最后，對每個組成部件的功能、性能和物理特性進(jìn)行必要的描述。1配置標(biāo)識的對象配置標(biāo)識的對象包括：(1)

32、各種功能規(guī)格說明和技術(shù)規(guī)格說明，以及軟件項目的特殊功能和開發(fā)過程中使用的方法；(2) 所有受到功能和技術(shù)規(guī)格影響的開發(fā)工具，這些工具不僅包括用于創(chuàng)建應(yīng)用程序的開發(fā)工具，而且還包括對比、調(diào)試和圖形化工具；(3) 所有與其他軟件項目和硬件的接口；(4) 所有與軟件項目相關(guān)的文檔和計算機(jī)文件，例如文本文件、源程序、文檔和圖形，以及任意的二進(jìn)制文件。標(biāo)識軟件項不僅需要處理程序項和需求之間的聯(lián)系，一般來講，還需要使用多種方式來標(biāo)識軟件項，以及軟件項同軟件產(chǎn)品之間的關(guān)聯(lián)。2. 配置標(biāo)識的活動配置標(biāo)識的主要活動包括選擇配置項、制定標(biāo)識方案和存取方案。(1) 選擇配置項。配置項是配置管理的最小單元，一般由一個

33、或多個文件組成。軟件組織可以根據(jù)不同的原則選擇配置項。(2) 制定配置項標(biāo)識方案。選擇好配置項后就要為其選擇適當(dāng)?shù)臉?biāo)識方案。配置項的標(biāo)識使配置項被唯一識別，因此，標(biāo)識方案應(yīng)該顯示軟件演化的層次結(jié)構(gòu)和可追溯性。常用的方案是數(shù)字方案，即配置項由名稱和數(shù)字版本號標(biāo)識。一般情況下，配置項的標(biāo)識以記錄該配置項的計算機(jī)文件為單位，標(biāo)識形式由文件名、作者、文件修改日期以及使用配置管理工具檢入的時間等標(biāo)識。與軟件有關(guān)的文檔也應(yīng)使用配置管理工具進(jìn)行管理。(3) 制定存取方案。軟件組織需要建立軟件配置庫，存放軟件配置。軟件項目組的所有成員都可根據(jù)權(quán)限存取配置庫中的配置項，同時必須協(xié)調(diào)各成員之間的關(guān)系，使每個成員所

34、能執(zhí)行的權(quán)限不超過權(quán)限的范圍。例如，如果某個程序員只負(fù)責(zé)一個模塊的開發(fā)，那么就不能有對其他模塊源碼的修改權(quán)。有效的配置標(biāo)識是其他配置管理活動的前提。如果閑置項和相關(guān)的配置文檔沒有被很好地標(biāo)識，想要控制這些配置的變更、建立準(zhǔn)確的記錄和報告、審核配置的有效性是不可能的。不準(zhǔn)確或不完全的配置項標(biāo)識和配置文檔可能會導(dǎo)致產(chǎn)品延期交付，或花費很高的維護(hù)費用。3. 配置標(biāo)識框架配置標(biāo)識是軟件生存周期中產(chǎn)生的所有文檔的總稱，例如一個函數(shù)、一個模塊說明、一個等價類的測試數(shù)據(jù)、一份軟件結(jié)構(gòu)圖等。配置標(biāo)識定義配置項的名稱、與其他配置項的聯(lián)系和版本信息等。由于文檔之間存在著復(fù)雜的關(guān)聯(lián)，一旦要求對配置項進(jìn)行更改，尤其是

35、當(dāng)軟件需求發(fā)生變化時，就不只是更改一個配置項，而且還要修改其他文檔。因此，在標(biāo)識配置項時，應(yīng)考慮其名稱、描述、資源、變化、版本方面的內(nèi)容。下面介紹一個典型的配置標(biāo)識框架模型。上面的配置標(biāo)識框架中，供應(yīng)資源是由本配置產(chǎn)生并能為其他配置項所利用、參考的數(shù)據(jù)/變量/功能等實體，需求資源則是僅供本配置項所使用、參考的其他配置項供應(yīng)的資源。一個配置標(biāo)識包含該配置項的所有版本。實際上，新版本是在某一舊版本的基礎(chǔ)上作一些變化而形成的，這就構(gòu)成了一條樹狀的版本鏈。在一條版本鏈中各版本存在很多共性，也有一些差異，反映在資源、接口和文檔內(nèi)容等方面。因此，在實際存儲時，僅存儲配置項的最初版本內(nèi)容和版本變化信息。4.

36、 要注意的問題配置標(biāo)識功能論述了與基線中包含的軟件配置項的標(biāo)識以及基線本身的標(biāo)識有關(guān)的問題?！皹?biāo)識”用來確定如何識別產(chǎn)品的所有部件和由部件建造的產(chǎn)品基線。在標(biāo)識過程中，要考慮下面幾個關(guān)鍵點：必須識別出每個軟件配置項并賦予它唯一的標(biāo)記。識別和標(biāo)記計劃必須反映產(chǎn)品的結(jié)構(gòu)。必須建立識別和標(biāo)記軟件配置項的標(biāo)準(zhǔn)。必須建立識別和標(biāo)記所有形式的測試和測試數(shù)據(jù)的標(biāo)準(zhǔn)。必須建立識別建造基線需要的支持工具的標(biāo)準(zhǔn)。工具中需要包括編譯程序、連接程序、匯編程序、make文件以及其他用來翻譯軟件和建造基線的工具，這一點很重要。它確保在基線被變更、替換或更新很長一段時間后，開發(fā)人員總能夠重新獲得由這些工具產(chǎn)生的信息。要特別

37、關(guān)注集成到軟件產(chǎn)品中的第三方軟件，特別是那些存在版權(quán)或版稅問題的軟件。必須建立第三方軟件如何集成到軟件產(chǎn)品的標(biāo)準(zhǔn)，從而能夠容易地刪除、替代或升級這些軟件。要特別關(guān)注來自其他產(chǎn)品中正被重新使用的軟件或打算重用的軟件。要特別關(guān)注打算替換掉的原型軟件?？傊?，配置標(biāo)識是配置管理的基礎(chǔ)，唯一地標(biāo)識軟件配置項和各種文檔，使它們可以通過某種方式訪問。配置標(biāo)識的目標(biāo)是在整個系統(tǒng)生命周期中標(biāo)識系統(tǒng)的組件，提供軟件和軟件相關(guān)產(chǎn)品之間的追蹤能力。12.3.2 版本控制這是典型的由于版本管理混亂帶來的麻煩，很大程度上受工作環(huán)境的影響，通過版本管理工具就可以有效地解決這類問題，這也是目前流行的軟件工程和項目管理實踐。軟

38、件配置管理的一個必備功能就是在軟件產(chǎn)品開發(fā)時及交付后，可靠地建立和重新創(chuàng)建版本。在開發(fā)時會建立產(chǎn)品的中間版本，并進(jìn)行常規(guī)測試。因為經(jīng)常需要回到以前的版本，所以就需要能準(zhǔn)確地重建以前的版本。開發(fā)完成后，還需要管理交付給用戶的軟件版本，因而必須對所有必要的信息進(jìn)行維護(hù)，例如編譯程序、連接程序以及使用的其他工具，以確保每個已交付的軟件產(chǎn)品版本能夠重建。常見的版本控制流程如圖12.9所示。圖12.9 版本控制流程圖(這是版本控制的過程，開發(fā)人員先訪問當(dāng)時的最新版本并下載到本地，修改調(diào)試后提交新版本，在此基礎(chǔ)上生成最新版本，并讓其進(jìn)入源代碼庫)版本控制是所有軟件配置管理系統(tǒng)的核心功能，負(fù)責(zé)為配置庫中的所

39、有元素自動分配版本標(biāo)識，并保證版本命名的唯一性。版本控制的目的是便于對版本變化加以區(qū)分、檢索和跟蹤，以表明各個版本之間的關(guān)系。一個版本是軟件系統(tǒng)的一個實例，在功能和性能方面與其他版本有所不同，或是修正、補(bǔ)充了前一個版本的某些不足。1. 版本控制的內(nèi)容版本控制包括了對配置項版本的一系列操作控制。一般來說，版本控制包括檢入檢出控制、分支和合并、歷史記錄。1) 檢入檢出控制軟件開發(fā)人員對源文件的修改不能在軟件配置管理庫中進(jìn)行，對源文件的修改依賴于基本的文件系統(tǒng)并在各自的工作空間中進(jìn)行。為了方便軟件開發(fā)，需要不同的軟件開發(fā)人員組織各自的工作空間。一般來說，不同的工作空間由不同的目錄表示，對工作空間的訪

40、問，由文件系統(tǒng)提供的文件訪問權(quán)限來加以控制。訪問控制需要管理各個人員存取或修改一個特定軟件配置對象的權(quán)限，例如，軟件開發(fā)經(jīng)理一般比軟件開發(fā)人員具有更高的權(quán)限。開發(fā)人員能夠從庫中取出對應(yīng)項目的配置項，也可以修改，并檢入軟件配置庫中，對配置庫中的版本進(jìn)行“升級”；軟件開發(fā)經(jīng)理除了具有開發(fā)人員的所有執(zhí)行權(quán)限外，還可以確定多余配置項，而且可以刪除多余配置項。同步控制的實質(zhì)是版本的檢入檢出控制。檢入就是把軟件配置項從用戶的工作環(huán)境存入軟件配置庫的過程，檢出就是把軟件配置項從軟件配置庫中取出的過程。檢入是檢出的逆過程。同步控制可用來確保由不同人員并發(fā)執(zhí)行的修改不會產(chǎn)生混亂。2) 分支和合并進(jìn)行版本分支(以

41、一個已有分支的特定版本為起點，但是獨立發(fā)展的版本序列)的人工方法就是從主版本(又稱主干)上復(fù)制一份，并做上標(biāo)記。在實行了版本控制后，版本分支也是一份副本，這時的復(fù)制過程和標(biāo)記動作由版本控制系統(tǒng)完成。進(jìn)行版本合并(來自不同分支的兩個版本合并為其中一個分支的新版本)有兩種途徑，一種是將版本A的內(nèi)容附加到版本B中；另一種是合并版本A和版本B的內(nèi)容，形成新的版本C。對文件來說，分支與合并的結(jié)果就是形成具有圖結(jié)構(gòu)的版本歷史，即版本圖，如圖12.10所示。圖12.10 版本的分支與合并(從版本圖中可以直觀地了解版本的歷史)進(jìn)行版本分支有以下幾個目的：代表獨立的開發(fā)路徑，例如開發(fā)過程和維護(hù)過程；代表組件的不

42、同變體；代表實驗性的開發(fā)，該分支在以后可能會丟棄，或合并到主分支中；適應(yīng)兩個開發(fā)人員并發(fā)地修改同一組件的情況，此時分支僅暫時存在，一旦兩個開發(fā)人員修改完畢，將被合并。合并就是將獨立發(fā)生在兩個版本分支上文件的修改合成到其中一個分支上，從而形成該分支上的一個新版本。合并包含兩方面的內(nèi)容：第一是兩個文件版本內(nèi)容的實際合并；第二是在版本圖上作為版本歷史的一部分進(jìn)行反映。3) 歷史記錄版本的歷史記錄有助于對軟件配置項進(jìn)行審計，有助于追蹤問題的來源。歷史記錄包括版本號、版本修改時間、版本修改者和版本修改描述等最基本的內(nèi)容，還可以有其他一些輔助性內(nèi)容，例如版本的文件大小和讀寫屬性等。2. 版本編號的方法版本

43、號是配置項的某個版本的唯一標(biāo)識。源代碼文件、文檔文件、軟件產(chǎn)品整體(源代碼整體或安裝包)都有版本號，這里主要關(guān)注的是軟件產(chǎn)品整體的版本編號方法。合理的版本編號策略可以使軟件配置管理更為簡便和有序。目前，業(yè)界尚無統(tǒng)一的軟件版本編號方法，但是常用的方法有兩種：數(shù)字順序型編號和屬性編號。1) 數(shù)字順序型編號數(shù)字順序型編號通常會分為幾段，不同段上的數(shù)字的變化，標(biāo)志著產(chǎn)品不同類型的變化。例如，一種典型的版本編號策略是：版本號分為3段，形如X.Y.Z，其中X為主版本號，Y為特征版本號，Z為缺陷修復(fù)版本號。主版本號的增加表示提供給客戶的主要產(chǎn)品功能的增強(qiáng)，特征版本號的增加表示產(chǎn)品新增了一些特征或做了一些重要

44、修改，缺陷修復(fù)版本號的增加表示在軟件產(chǎn)品上做了一些缺陷修復(fù)工作。當(dāng)某一級版本號增加時，其下級版本號要清零。例如，軟件的一個版本是1.3.2，如果該版本新增了一些特性，使特征版本號增加為4，那么缺陷修復(fù)版本號要復(fù)位為0，所以整個版本號就變?yōu)?.4.0。同樣，如果軟件做了重大改進(jìn)，提升了主版本號，那么特征版本號和缺陷修復(fù)版本號就都要復(fù)位為0，這樣就得到了版本2.0.0。如果要標(biāo)記軟件的測試版和測試版，可在上述3段數(shù)字版本編號后面增加一個大寫字符A或B來分別表示版本或版本。例如，1.2.4A或1.2.4B。如果存在多次的發(fā)布和發(fā)布，可在A或B后面添加一個數(shù)字來說明發(fā)布的次數(shù)，例如，1.2.5A1，1

45、.3.0B2等。以上版本編號策略是面向用戶的，在開發(fā)團(tuán)隊內(nèi)部，對版本號也有要求。例如，測試團(tuán)隊需要區(qū)分測試對象的版本，軟件的每次對外發(fā)布，可能也對應(yīng)著不止一次內(nèi)部測試。簡單的解決方法是，版本號中再增加一段，說明是新版本軟件發(fā)布前的第幾次送測，或稱第幾次內(nèi)部發(fā)布。例如，1.0.3.0是發(fā)布版本1.0.3在發(fā)布前的第1次送測，而1.0.3.1是第2次送測。當(dāng)然，新增加的這一段數(shù)字不必讓外部用戶看到。2) 屬性編號數(shù)字順序型版本編號的特點是簡單易用，但是包含的信息有限，而且如果段數(shù)太多的話，就難以讓人識別和理解。因此在有些情況下，開發(fā)團(tuán)隊會使用屬性版本編號，就是把版本的一些重要屬性反映在版本標(biāo)識中。

46、屬性版本編號可以包括的屬性有：客戶名、開發(fā)語言、開發(fā)狀態(tài)、硬件平臺、生成日期、技術(shù)特征和質(zhì)量狀態(tài)等。例如，下面的這個版本號就包含了軟件的生成日期和時間，以及技術(shù)特征(native threads, jit)。J2SDK.v.1.2.2: 11/31/2013-18:00, native threads, jit-122當(dāng)然，像這樣復(fù)雜的屬性版本號一般只應(yīng)用于開發(fā)團(tuán)隊內(nèi)部，不顯示給用戶。現(xiàn)在的版本控制通常由CASE工具來支持。工具用于管理對每個系統(tǒng)版本的存儲，并控制對系統(tǒng)組件的訪問。這些組件必須能夠從系統(tǒng)中抽取出來進(jìn)行編輯，當(dāng)將其重新放入系統(tǒng)的時候，就構(gòu)成了一個新的系統(tǒng)版本，由版本管理系統(tǒng)給它一

47、個新的名字。版本控制是全面實行軟件配置管理的基礎(chǔ)，可以保證軟件技術(shù)狀態(tài)的一致性。版本控制是配置管理的基本要求，可以保證在任何時刻恢復(fù)任何一個配置項的任何一個版本。版本控制記錄了每個配置項的發(fā)展歷史，這樣就保證了版本之間的可追蹤性，也為查找錯誤提供了幫助。版本控制也是支持并行開發(fā)的基礎(chǔ)。12.3.3 變更控制變更是軟件開發(fā)的固有屬性。變更會造成很大的麻煩，例如客戶不斷提出需求變更，導(dǎo)致重新設(shè)計和實現(xiàn)系統(tǒng)，造成大量返工。事實上，軟件開發(fā)中不可避免地會存在編碼錯誤等問題，這就需要修正錯誤。在開發(fā)過程中，隨著用戶和開發(fā)人員逐步掌握更多的信息，他們也會對已經(jīng)確定了的設(shè)計方案或設(shè)計細(xì)節(jié)進(jìn)行改進(jìn)。修改錯誤或

48、進(jìn)行改進(jìn)都是變更。軟件開發(fā)過程中的變更以及相應(yīng)的返工，會對產(chǎn)品的質(zhì)量造成很大的影響。軟件變更的不可避免性并不意味著軟件可以任意修改。變更控制是軟件配置控制的關(guān)鍵活動，指在整個軟件生命周期中控制軟件的變化，建立一套對軟件配置項的修改進(jìn)行有意識的控制機(jī)制，防止在軟件開發(fā)過程中因盲目修改造成混亂，主要是進(jìn)行基線管理以及對基線更改控制過程的處理。配置管理最初就是為了控制變更而提出的，能否解決好變更控制問題是衡量軟件組織成熟度的一個標(biāo)志。1. 變更的涉及面變更是不可避免的，也是必不可少的，變更和變更控制是矛盾的統(tǒng)一體。由于變更的內(nèi)容和變更的幅度都會直接影響到整個項目，所以時刻需要考慮到變更的波及面。在瀑

49、布模型的生命周期中，變更的波及面如圖12.11所示。圖12.11 變更的波及面(越早形成的基線發(fā)生變更，變更的影響就越大，波及面就越寬。反之，越晚形成的基線發(fā)生變更，變更的影響就越小，波及面就越窄)在圖12.11中，如果在系統(tǒng)工程階段的工作需要發(fā)生變化，那么軟件生命周期中的各個階段都有可能受到影響，這些階段所有相關(guān)的軟件配置項也都會或多或少地受到影響；如果代碼編寫階段的工作需要變化，則軟件測試和系統(tǒng)測試階段的工作都要受到影響；如果在代碼編寫階段發(fā)現(xiàn)錯誤，該錯誤是由需求階段的工作造成的，則需要需求及以下階段都要進(jìn)行相應(yīng)的修改。變更控制需要記錄每次變化的相關(guān)信息，查看這些相關(guān)信息，有助于追蹤出現(xiàn)的

50、各種問題。記錄正在執(zhí)行的變化信息有助于做出正確的管理決策。軟件配置管理對基線管理的任務(wù)之一是追蹤更改的變化過程，以保證對軟件開發(fā)過程的可見性和可追蹤性。對基線更改變化過程的追蹤有兩部分內(nèi)容：一是對基線更改版本的跟蹤，另一個是對其更改原因以及更改結(jié)果的追蹤。2. 變更的分類一般來說，軟件的變更通常有功能變更和錯誤修補(bǔ)變更兩種類型。(1) 功能變更。功能變更是為了增加或刪除某些功能或者為了改變完成某個功能的方法而進(jìn)行的變更。這類變更如果代價比較小，對軟件系統(tǒng)其他部分沒有影響或影響很小，就應(yīng)該批準(zhǔn)這類變更。反之，如果變更的代價比較高，或者對軟件系統(tǒng)其他部分影響比較大，就必須權(quán)衡利弊，以決定是否進(jìn)行這

51、類變更。(2) 錯誤修補(bǔ)變更。錯誤修補(bǔ)變更是為了修復(fù)漏洞而進(jìn)行的變更，是必須進(jìn)行的，通常不需要從管理角度對這類變更進(jìn)行審查和批準(zhǔn)。但是如果在造成錯誤階段的后面發(fā)現(xiàn)錯誤，例如在實現(xiàn)階段發(fā)現(xiàn)了設(shè)計錯誤，就必須遵照標(biāo)準(zhǔn)的變更控制過程，把變更正式記入文檔，把所有受變更影響的文檔都做相應(yīng)的修改。3. 變更控制的內(nèi)容變更控制作為配置管理的主要內(nèi)容之一，在操作過程中有嚴(yán)格的控制流程，以保證配置項的一致性和有效性。一般變更控制的內(nèi)容如下：確定變更批準(zhǔn)人的責(zé)任范圍和權(quán)限；建立變更控制流程，實施變更控制；對配置項變更進(jìn)行管理；對基線變更進(jìn)行管理；設(shè)立兩個變更授權(quán)機(jī)構(gòu)，變更控制委員會(Change Control

52、Board，CCB)和項目經(jīng)理；CCB成員為項目級的，可因項目的不同而有所不同，由高級經(jīng)理在項目任務(wù)書中定義。4. 變更控制的類型變更控制一般分為兩類：一類是基線的變更控制，另一類是軟件版本的變更控制。1) 基線的變更控制基線的變更是指在一個軟件版本的開發(fā)周期內(nèi)對基線配置項的變更，主要包括基線的應(yīng)用和更新等活動。基線變更所涉及的操作主要包括基線標(biāo)簽的定義和標(biāo)簽的使用?；€標(biāo)簽屬于嚴(yán)格受控的配置項，命名必須嚴(yán)格按照相關(guān)的規(guī)范來進(jìn)行?；€在建立時，按照角色職責(zé)的分工，須經(jīng)CCB同意并正式地將該基線的標(biāo)識和作用范圍通知系統(tǒng)集成人員，由后者負(fù)責(zé)執(zhí)行；基線一旦劃定，由該基線控制的各配置項的歷史版本均處于

53、鎖定或嚴(yán)格受控狀態(tài)，任何對基線位置的變更請求都必須按變更控制流程提交CCB批準(zhǔn)，然后由系統(tǒng)集成人員執(zhí)行。2) 軟件版本的變更控制軟件版本的命名規(guī)范應(yīng)事先制定，并按照開發(fā)計劃予以發(fā)布使用。在軟件版本的演化過程中既需要從以前的版本中繼承，又需要相對的獨立性，所以對于子版本(例如某特定用戶的定制版本)而言，就需要對一系列配置項從統(tǒng)一的開發(fā)起始基線所確定的版本上建立新的分支，然后在此分支上開發(fā)新的版本。因此在這樣的變更控制流程中，受控的對象還應(yīng)該包括特定的分支類型，以及工作視圖的選取規(guī)則，同時配置管理員將在這一過程中擔(dān)負(fù)更多的操作職責(zé)。5. 變更控制的流程典型的變更管理規(guī)程涉及如何提交變更請求、如何對

54、變更請求進(jìn)行復(fù)審以便決定是否實施、由誰實施、如何實施和如何確定變更請求準(zhǔn)確實施完成等方面。通常規(guī)范的變更管理過程都應(yīng)包含以下步驟(如圖12.12所示)。圖12.12 變更控制流程(泳道圖很好地反映了各種不同的人員執(zhí)行的活動和責(zé)任)(1) 變更請求。變更請求是實施變更控制的第一步，也是必不可少的一步。變更請求可以由任何人提出，包括用戶和開發(fā)人員。典型的變更請求有清除缺陷和適應(yīng)運行平臺的變更，軟件擴(kuò)展提出的要求(例如增加功能、提高性能等)，以及對已有功能的優(yōu)化和改進(jìn)等。變更請求有多種形式，而且來自不同的地方，例如來自內(nèi)部及外部的錯誤報告，來自市場及工程部門的功能增強(qiáng)請求，需求、設(shè)計及文檔變更請求等

55、。(2) 變更請求評審。變更請求評審是根據(jù)變更管理規(guī)程、項目目標(biāo)、變更的必要性、變更實現(xiàn)所需的時間、成本利潤分析、變更對系統(tǒng)其他部分的影響以及技術(shù)可行性(能否實現(xiàn))等分析評估變更請求的。一般由變更控制委員會(CCB)召開相應(yīng)的評估會議，并根據(jù)變更的影響范圍，邀請相關(guān)人員參加。如果有必要，可以設(shè)立不同級別的CCB，對不同層次的變更申請進(jìn)行控制，在這種情況下，項目組可以在配置管理計劃中以樹狀結(jié)構(gòu)說明其從屬結(jié)構(gòu)，并在計劃中明確說明CCB的授權(quán)范圍，在變更管理規(guī)程中規(guī)定由誰來評估變更。一般在大型項目中，對已基線化的配置項的變更，由變更控制委員會評審；在較小型項目中，由項目經(jīng)理評估。(3) 批準(zhǔn)變更。根

56、據(jù)評估決定接受變更或拒絕變更，對接受的變更也會有不同的處理方式，例如立即實現(xiàn)變更，或在下一個版本的產(chǎn)品中或下一期項目中再實現(xiàn)變更。不同的企業(yè)會根據(jù)項目情況將變更分類，對不同類型的變更采取不同的措施?？梢詫⒆兏殖上铝袔追N類型：增強(qiáng)型：變更要求對已批準(zhǔn)的項目功能進(jìn)行增強(qiáng)。改進(jìn)型：變更不會造成功能更改，將使配置項的維護(hù)更加有效率。糾錯型：變更對錯誤進(jìn)行修正。通常，對糾錯型的變更會根據(jù)系統(tǒng)的質(zhì)量標(biāo)準(zhǔn)決定是否批準(zhǔn)變更，對增強(qiáng)型和改進(jìn)型的變更要根據(jù)評估結(jié)果決定是否批準(zhǔn)變更。(4) 實現(xiàn)變更。如果接受了變更請求，就開始區(qū)分變更的優(yōu)先級，根據(jù)優(yōu)先級計劃變更實現(xiàn)方案，包括技術(shù)方案、人員安排和任務(wù)分配等。不同企

57、業(yè)會根據(jù)項目情況區(qū)分變更優(yōu)先級，并對不同優(yōu)先級的變更采取不同的實現(xiàn)方案。變更可分配下述幾種優(yōu)先級：高：嚴(yán)重地影響一些用戶或許多用戶。在變更請求提交的5個工作日內(nèi)要對所做改動的版本進(jìn)行全面測試。中：對用戶造成不方便或存在主要問題但可以采取相應(yīng)的變通方法處理。在變更請求提交的20個工作日內(nèi)要對所做改動的版本進(jìn)行全面測試。低：小問題。在變更請求提交的3個月內(nèi)，在下一個發(fā)布版本中進(jìn)行改動。(5) 確認(rèn)變更。實現(xiàn)的變更要經(jīng)過審計，審計由質(zhì)量控制小組或負(fù)責(zé)管理產(chǎn)品的發(fā)布人完成。(6) 發(fā)布變更。配置管理人員要記錄和追蹤變更，采取措施保證變更在受控狀態(tài)下進(jìn)行，并發(fā)布變更請求的狀態(tài)。變更請求可具有下列狀態(tài)：提

58、交：變更請求提交給配置管理人員。拒絕：變更評審小組或個人拒絕變更請求。接受：變更評審小組或個人接受變更請求。掛起：變更請求被掛起，以后再做決定。已驗證：變更請求要求的更改已執(zhí)行和驗證。關(guān)閉：驗證并歸檔配置項，并將更新的配置項提交給用戶(例如通過版本發(fā)布)。12.3.4 狀態(tài)報告1. 狀態(tài)報告為了清楚、及時地記載軟件配置的變化，不至于到后期造成貽誤，需要在開發(fā)的過程中對每個軟件配置項做出系統(tǒng)的記錄，以反映開發(fā)活動的歷史情況。配置狀態(tài)報告就是根據(jù)配置項操作數(shù)據(jù)庫中的記錄來向管理者報告軟件開發(fā)活動的進(jìn)展情況的。記錄主要包括軟件配置項的出入庫情況、軟件變更控制委員會的會議記錄和變更情況記錄，根據(jù)這些情

59、況和記錄產(chǎn)生配置狀態(tài)報告。這些報告應(yīng)及時發(fā)放給有關(guān)人員，以避免可能產(chǎn)生的矛盾和沖突。而且，這樣的報告應(yīng)該是定期進(jìn)行的，并盡量通過CASE工具自動生成，用數(shù)據(jù)庫中的客觀數(shù)據(jù)來真實地反映各種配置項的情況。配置狀態(tài)報告的對象，包括配置項的狀態(tài)、更改申請和對已批準(zhǔn)的更改的實現(xiàn)情況3個方面。配置狀態(tài)報告的任務(wù)是記錄、報告整個生命周期中軟件的狀態(tài)，用以跟蹤對已建立基線的需求、源代碼、數(shù)據(jù)及相關(guān)文檔的更改和文件的形式等，表明每一軟件版本的內(nèi)容，以及形成該版本的所有更改，供相關(guān)人員了解，以加強(qiáng)配置管理工作。配置狀態(tài)報告應(yīng)該著重反映當(dāng)前基線配置項的狀態(tài)，以作為對開發(fā)進(jìn)度報告的參考，同時，也能根據(jù)開發(fā)人員對配置項

60、的操作記錄來分析開發(fā)團(tuán)隊成員之間的工作關(guān)系。2. 狀態(tài)統(tǒng)計配置狀態(tài)統(tǒng)計是配置狀態(tài)報告的組成部分之一，在產(chǎn)品開發(fā)過程中，基于已發(fā)現(xiàn)并修復(fù)了的缺陷類型、數(shù)量、頻率和嚴(yán)重性等方面，可以說明產(chǎn)品的狀態(tài)。狀態(tài)報告持續(xù)地記錄了配置狀態(tài)以及保持基線產(chǎn)品和基線變更的歷史，并使相關(guān)人員了解配置和基線的狀態(tài)。配置狀態(tài)統(tǒng)計包括在軟件生命周期中對基線所有變更的可跟蹤性報告中。項目和配置項的關(guān)鍵信息可通過配置狀態(tài)統(tǒng)計傳遞給項目組成員。軟件工程師可以看到做了哪些修改，或每個文件包含在哪個基線中；項目經(jīng)理可以跟蹤項目的問題報告和各種其他維護(hù)活動。配置狀態(tài)統(tǒng)計包括對以下問題的答復(fù)：配置項的狀態(tài)是什么？變更要求是否被CCB批準(zhǔn)