版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領
文檔簡介
第6章軟件項目配置管理
內(nèi)容提要
6.1概述
6.1.1起源與發(fā)展
6.1.2解決哪些問題
6.2軟件配置管理的任務和活動
6.2.1軟件和配置項
6.2.2標識
6.2.3變更控制
6.2.4狀態(tài)報告
6.2.5配置審計
6.3軟件配置管理的核心要素
6.3.1版本和版本樹
6.3.2軟件配置庫
6.3.3工作空間
6.3.4變更請求與變更集
6.3.5軟件配置管理工具
內(nèi)容提要
6.4軟件配置管理的主要過程
6.4.1配置項標識與存儲過程
6.4.2版本管理過程
6.4.3變更控制過程
6.4.4基線管理過程
6.5軟件配置管理中的角色
6.5.1配置管理專職人員
6.5.2機構運營管理人員
6.5.3項目開發(fā)人員
6.6常用軟件配置管理工具
6.6.1軟件配置管理工具的發(fā)展歷程
6.6.2版本控制工具及功能
6.6.4面向開發(fā)流程的配置管理工具及功能
6.7案例研究
6.8小結
軟件配置管理
軟件配置管理(SoftwareConfigurationManagement,SCM)是軟件工程領域的重要課題,也
是軟件產(chǎn)品開發(fā)過程中的核心控制過程。
與傳統(tǒng)產(chǎn)品開發(fā)生產(chǎn)相比,軟件產(chǎn)品的開發(fā)生產(chǎn)具有較強的復雜性和不確定性。
主要體現(xiàn)在開發(fā)講度難以捽制、開發(fā)結果難以預計C
所幸的是,軟件配置管理通過一整套可視化可跟蹤和可控制管理方法為軟件開發(fā)項目提供了保
護傘。
軟件配置管理
軟件配置管理
軟件配置管理在開發(fā)過程中各階段,管理計算機程序演變的學科,作為軟件工程的關鍵元素,
已經(jīng)成為軟件開發(fā)和維護的重要組成部分。
軟件配置管理提供了結構化的、有序化的、產(chǎn)品化的管理軟件工程的方法,涵蓋了軟件生命周
期的所有領域并影響所有數(shù)據(jù)和過程。
配置管理是對產(chǎn)品進行標識、存儲和控制,以維護其完整性、可追溯性以及正確性的學科。
軟件配置管理
計算機軟件產(chǎn)品的總體發(fā)展趨勢,就是系統(tǒng)自身的復雜化與系統(tǒng)使用的簡單化。
如何控制日益復雜化的系統(tǒng),管理系統(tǒng)開發(fā)和維護過程,始終是軟件從業(yè)者頭痛的難題。
軟件配置管理正是在軟件產(chǎn)品與軟件開發(fā)產(chǎn)業(yè)進化過程中不斷演練出來的解決這一難題的主要
方法。
遺憾的是,由于軟件配置管理本身也是在軟件產(chǎn)業(yè)發(fā)展過程中逐步形成和完善的,即使是資深
軟件從業(yè)人員,也經(jīng)常混淆其概念和方法。
6.1軟件配置管理概覽
6.1.1什么是軟件配置管理
1.軟件配置管理
軟件配置管理(SoftwareConfigurationManagement,SCM)就是在軟件開發(fā)過程中管理軟件
的配置。
這里的配置,是指構成軟件產(chǎn)品的各種原始部件,包括源程序、數(shù)據(jù)文件、設計文檔、用戶文
檔,及其組織關系(如目錄結構)。
相應的管理包括管理這些部件的產(chǎn)生、修改、提取與發(fā)布,以保證整個產(chǎn)品的正確性、完整性,
產(chǎn)品部件的一致性。
軟件配置管理的正式定義,在不同的標準規(guī)范中有不同的表述。
軟件配置管理的內(nèi)容
配置(Configuration)一詞來源于拉丁語的"Com-"("與"或者"一起")和"figure"("形
成”),意為多個部件集合在一起形成一個整體。
由此,配置管理可以理解為使事物的各個部件或元素組合成整體的管理過程。
軟件部件分解圖
軟件配置管理(SoftwareConfigurationManagement,SCM)就是在軟件開發(fā)過程中管理軟件
的配置。
軟件配置管理標準的目標
在不同的標準規(guī)范中有不同的表述
(1)<ISO/IEC12207(1995)信息技術一軟件生存周期過程標準》
配置管理過程是在整個軟件生命周期中實施管理和技術規(guī)程的過程,它標識、定義系統(tǒng)中軟件
項素,并定制基線(Baseline)o
控制軟件項素的修改和發(fā)行,記錄和報告軟件項素的狀態(tài)和修改請求,保證軟件項素的完整性、
協(xié)調(diào)性和正確性,以及控制軟件項素的存儲、裝載和交付,
(2)《GB/T11457(1995)軟件工程術語》
軟件配置管理是標識和確定系統(tǒng)中配置項的過程,在系統(tǒng)整個生命周期內(nèi)控制這些項的投放和
變動,記錄并報告配置的狀況和變動要求,驗證配置項的完整性和正確性。
(3)集成化成熟度模型(CMMI)
配置管理是通過配置標識、配置控制、配置狀況統(tǒng)計與配置審計來建立與維持工作產(chǎn)品的完整
性的管理過程。
CMMI中的定義概括了軟件配置管理的主要任務和方法。
軟件工程中的軟件配置管理
6.1.1起源與發(fā)展
配置管理的概念,最早來源于制造工業(yè),尤其是在國防工業(yè)中。
這些工業(yè)產(chǎn)品往往相當復雜,包含數(shù)萬種部件,經(jīng)歷幾代人多年的開發(fā),每種部件都在不斷地
改進、演化。
這就需要有一套機制去管理產(chǎn)品部件的變更、版次,保存完整的產(chǎn)品開發(fā)信息,以保持不同階
段產(chǎn)品開發(fā)的連續(xù)性。
1962年,美國空軍在進行噴氣式飛機設計時,制訂了一個標準規(guī)范配置管理,這被視為第一個
配置管理標準,該標準被美國國防部和軍方其他標準廣泛引用。
6.1.1起源與發(fā)展
單一產(chǎn)品需要的開發(fā)人員不斷增多,開發(fā)人員之間的信息溝通、進度協(xié)調(diào)和交付管理等方面的
矛盾日益突出。
現(xiàn)在,軟件配置管理已經(jīng)作為一種重要的軟件開發(fā)管理環(huán)節(jié),被大多數(shù)軟件標準化組織所采納,
作為衡量軟件開發(fā)組織成熟程度的基本標準。
用于軟件配置管理的工具也在不斷地豐富和完善。
這些工具有力地幫助軟件開發(fā)機構實現(xiàn)軟件配置管理自動化。
6.1.2軟件配置管理的起源與發(fā)展
配置管理的概念,最早來源于制造工業(yè),尤其是在國防工業(yè)中。
1962年,美國空軍在進行噴氣式飛機設計時,制訂了一個標準規(guī)范配置管理,這被視為第一個
配置管理標準,該標準被美國國防部和軍方其他標準廣泛引用。
從20世紀80年代起,美國國防部、美國電氣和電子工程師協(xié)會、美國國家標準協(xié)會和國際標
準化組織都開始關注軟件開發(fā)過程中的配置管理并陸續(xù)制訂了各自的標準
6.1.2解決哪些問題
沒有配置管理的“手工作坊”式的軟件開發(fā)項目,經(jīng)常會遇到許多問題。
例如,一個嚴重的錯誤被修正了,卻在一段時間后又重現(xiàn)了;
一個己經(jīng)開發(fā)并經(jīng)過測試的功能在手工集成后完全消失了;
系統(tǒng)崩潰了,卻很難查出是什么修改造成的;用于測試的執(zhí)行程序與源代碼嚴重不一致;
新的開發(fā)人員對現(xiàn)有代碼難以理解,不知其前因后果無法判斷單個功能的實現(xiàn)進度和整個項目
的完成程度;
無法確知整個產(chǎn)品的代碼修改頻度和每個版本的代碼修改量。
配置管理的原則
完善的軟件配置管理系統(tǒng)有助于規(guī)范開發(fā)人員的工作流程,明確角色分工,清楚記錄代碼的任
何修改,同時又能加強代碼修改時的溝通協(xié)作;
完善的配置關聯(lián)系統(tǒng)也有助于項目經(jīng)理更好地了解項目的進度、開發(fā)人員的負荷、工作效率與
產(chǎn)品質(zhì)量狀況、交付日期等關鍵信息;
配置管理系統(tǒng)中的完整配置信息和修改歷史使新的成員可以快速實現(xiàn)任務交接,盡量減少因人
員流動而造成的損失。
6.1.2解決哪些問題
完善的軟件配置管理系統(tǒng)有助于規(guī)范開發(fā)人員的工作流程,明確角色分工,清楚記錄代碼的任
何修改,同時又能加強代碼修改時的溝通協(xié)作
完善的配置關聯(lián)系統(tǒng)也有助于項目經(jīng)理更好地了解項目的進度、開發(fā)人員的負荷、工作效率與
產(chǎn)品質(zhì)量狀況、交付日期等關鍵信息:
軟件配置管理的功能
軟件配置管理通過對軟件產(chǎn)品各個部件的管理控制,協(xié)調(diào)軟件開發(fā)項目中不同角色的活動,能
夠有效地幫助軟件開發(fā)團隊避免上述問題。
6.2軟件配置管理的任務和活動
6.2.1軟件和配置項
軟件的脆弱性和易變性的根源在于軟件的復雜性,大型軟件通常由數(shù)以千萬個文件組成,這些
文件包括以下內(nèi)容:
定義產(chǎn)品功能、描述設計實現(xiàn)細節(jié)的設計文檔。
規(guī)定產(chǎn)品開發(fā)過程、進度計劃和交付合同等項目管理文檔。
各種語言的源程序文件,這是數(shù)量最多、最關鍵的文件。
各種格式的數(shù)據(jù)文件,包括數(shù)字、文字、圖片、視頻等。
構造生成的中間文件、可執(zhí)行文件和可安裝文件。
實現(xiàn)源程序文件到可執(zhí)行文件和可安裝文件轉(zhuǎn)換的構造、包裝腳本。
該軟件所依賴的其他文件:包括開發(fā)運行工具、硬件環(huán)境說明或相關軟件說明。
軟件配置項(CI)樹
軟件配置是指一個軟件產(chǎn)品在軟件生命周期各階段產(chǎn)生的各種形式(機器可讀或人工可讀)和
各種版本的文檔、程序及數(shù)據(jù)的集合。
該集合中的每個元素稱為該軟件產(chǎn)品軟件配置中的一個配置項
軟件配置管理作為支撐平臺
軟件配置管理,是軟件項目運作的一個支撐平臺,將項目干系人的工作協(xié)同起來,實現(xiàn)高效的
團隊溝通,使工作成果及時共享。
這種支撐,貫穿在項目的整個生命周期中。
6.2.2標識
標識,指從物理上確定軟件系統(tǒng)中的每個組件。配置項標識的主要任務,是唯一地標識出需要
控制的軟件配置項,并確定它和外界,以及其他配置項的關系。
配置項標識是所有配置管理活動的基礎。在項目初始,將原始產(chǎn)品置于配置管理系統(tǒng)控制時就
要進行配置項標識活動。
配置項標識的結果是形成各個配置項的元數(shù)據(jù)記錄,包括配置項的名字、描述、編號、類型、
創(chuàng)建者、創(chuàng)建時間、存儲方式和位置等信息。
標識任務的主要活動
(1)定義配置項選取原則
根據(jù)項目實際情況規(guī)定產(chǎn)品開發(fā)中哪些類型的文件必須置于配置管理系統(tǒng)之中,并約定唯一標
識的形式與格式。
一般應將各種源程序文件和系統(tǒng)依賴的重要數(shù)據(jù)文件包含在選取原則中。
(2)選擇配置項
按照既定原則從項目文件中選出需要進行配置管理的文件,并給每個配置項予以編號登記,規(guī)
定其授權和訪問約束。
在常用的自動化配置管理系統(tǒng)中,系統(tǒng)會自動填充編號和相關配置創(chuàng)建信息,并提供訪問控制
機制。
(3)確定存取方案
標識好了的配置項必須存放到軟件配置庫中。選擇哪種工具存儲管理配置項是一件復雜的工作。
一般要考慮項目的規(guī)模、尸發(fā)環(huán)境、項目成員的使用習慣,應兼顧存取的方便性和數(shù)據(jù)的安全
性。
軟件配置管理-重要性、活動
軟件架構和軟件配置管理
6.2.3變更控制
變更控制的目的,是控制對產(chǎn)品中己標識的所有配置項的任何修改,從而實現(xiàn)全面控制產(chǎn)品的
更改.
事件記錄,是變更控制活旬的輸入,變更控制的輸出結果,是歸檔化的事件與變更請求以及對
相應軟件配置項的修改。
變更控制的主要活動
創(chuàng)建事件記錄:
以文字形式描述事件,并通過適當?shù)那捞峤弧?/p>
分析事件記錄:
確定可能的需要對哪些配置項進行變更,并估計這些變更的波及面。
拒絕或者接受事件記錄:
若事件記錄被接受,就為每個受影響的配置項創(chuàng)建一個變更請求,分配給相關的開發(fā)人員。
實施變更:
依據(jù)變更請求的描述,實施配置項的修改,確保修改結果在配置管理庫中得到體現(xiàn)。
關閉變更請求?
當變更完成并被驗證后,就可以關閉變更請求了。
關閉事件記錄:
當同一事件所派生出的所有變更請求都關閉后,就可以關閉該事件記錄。
6.2.4狀態(tài)報告
狀態(tài)報告的任務是提取、報告整個軟件生存期中軟件各個部件的相關信息,以一種可讀的形式
呈現(xiàn)給相關人員。
報告的內(nèi)容主要是針對軟件配置項的狀態(tài)、事件記錄與變更請求,以及變更請求的執(zhí)行結果(即
實現(xiàn)的變更)三方面的數(shù)據(jù)
狀態(tài)報告——一個實用的模型和例子
軟件配置狀態(tài)報告
軟件配置狀態(tài)報告,通常用來回答如下問題:
配置項當前有何屬性,處于什么狀態(tài)?
配置項的每一版本是如何生成的?
配置項的新舊版本有何區(qū)別?
變更請求何時被誰批準,如何實現(xiàn)?
近期有哪些配置項發(fā)生了改變?
近期批準了多少變更請求,完成了多少?
哪些開發(fā)人員最近對配置項進行了修改?
完成狀態(tài)報告任務的主要活動
(1)確定報告范圍
不同組織、同一組織在不同階段關注的側重點不同,對狀態(tài)報告內(nèi)容的需求也不同,應根據(jù)實
際需要選定報告的內(nèi)容范圍,有選擇性地回答上述幾個問題。
(2)定義報告模板
格式化的報告通常便于閱讀者迅速、準確地抓住關鍵信息C
(3)提取配置數(shù)據(jù)
根據(jù)確定的報告范圍定期(每天、每周、每月)從配置庫中把相關配置數(shù)據(jù)提取出來,按模板
整理成便于閱讀的文檔。
(4)發(fā)布狀態(tài)報告
配置狀態(tài)報告應該發(fā)布給項目的所有開發(fā)與管理人員,同時必須歸檔以備日后查考。
(5)定制特定信息查找途徑
為滿足不同用戶的專門需求,必須在周期性的報告之外定制靈活的配置數(shù)據(jù)查找方式,并提供
便捷、友好的界面。
6.2.5配置審計
軟件配置審計的任務,是確認整個軟件在生命周期中各個部件在技術上和管理上的正確性與完
整性C
審計過程通過審查軟件配置項的狀況和修改歷史尋求以下兩個問題的答案,軟件的演化過程是
否符合既定的流程,軟件實現(xiàn)的功能是否與需求保持一致,
配置審計的主要活動是評審與測試-
前者,確保軟件配置變更和軟件開發(fā)流程的正確執(zhí)行,后者,確保軟件產(chǎn)品功能的正確性。
測試任務主要由軟件質(zhì)量保證人員完成,具體過程將在后續(xù)章節(jié)中詳細闡述。
配置評審活動,主要包括如下環(huán)節(jié)
(1)項目經(jīng)理和配置經(jīng)理確定審計的人員。
(2)配置審計人員準備配置審核檢查單,并制訂審計計劃。
(3)配置審計人員按照計劃安排時間對配置數(shù)據(jù)進行審計,與相關人員面談。
(4)配置審計人員將在審計中發(fā)現(xiàn)的不符合現(xiàn)象做記錄,并發(fā)送給項目經(jīng)理。
(5)項目經(jīng)理和配置經(jīng)理對上報的問題進行解決跟蹤。
6.3軟件配置管理的核心要素
軟件配置管理的主要任務是管理軟件產(chǎn)品的演變,確保產(chǎn)品在演變過程中仍保持正確性、完整
性與一致性。
顯然,這是一個不容易完成的任務,必須借助于一些特別的機制,專門的過程才能實現(xiàn)。
下面,看看有哪些核心要素支撐配置管理活動,以實現(xiàn)配置管理任務。
6.3.1版本和版本樹
版本,是軟件配置項在演化過程中的每一個實例。
軟件產(chǎn)品由許多文件(即配置項)組成,其中的每一個文件在軟件的開發(fā)、演化過程中都會不
斷地被修改,每次修改都形成不同的文件內(nèi)容。
如果檢取出同一文件任何一次修改后形成的內(nèi)容,都可看做作該文件的一個實例,即該文件的
一個版本。
對同一文件的每次修改總是有先后順序的。因此文件的每一個版本也是有先后順序的。后一版
本總是在前一版本的基礎上形成的0
此外,同一個版本還能根據(jù)不同的需要同時衍生出多個后續(xù)版本。
如果我們把一個文件的所有版本按衍生順序描繪出來,通常會出現(xiàn)為一種樹形圖,稱為該文件
的版本樹。
什么是版本控制,它是如何工作的?
某一文件的版本樹
版本樹中分叉處的版本大多是重要修改的開始,如新功能的開發(fā)、產(chǎn)品新發(fā)布的開始,或是新
開發(fā)小組的介入。
文件版本管理是軟件配置管理的基礎。
只有對每個文件的每個版本實現(xiàn)了嚴格有序的管理,保證每個文件的版本樹能自由而又穩(wěn)健地
成長。
能隨時方便地提取版本樹中任意一個版本,這才能構建更為復雜的軟件配置管理功能
Windows家譜
Java編程語言的完整歷史
安卓各個版本
6.3.2軟件配置庫
軟件配置庫,又稱軟件受控庫,是指用來存放軟件配置項的存儲池,保存軟件產(chǎn)品配置項的所
有版本與每個版本相關的控制信息。
最原始的軟件配置庫,是以筆書形式登記的軟件項目中所有文件及其版本的手工清單。
軟件配置管理自動化以后,軟件配置庫的存儲一般采用數(shù)據(jù)庫的形式,可以是通用的商業(yè)數(shù)據(jù)
庫,也有些是軟件配置管理系統(tǒng)私有數(shù)據(jù)庫。
6.3.2軟件配置庫
早期的軟件配置庫通常只在軟件生命周期的某一階段結束時存放軟件產(chǎn)品和與軟件產(chǎn)品開發(fā)工
作有關的計算機或人工可讀信息,僅用做作軟件產(chǎn)品資產(chǎn)庫,不要求實時在線存取,只要求安
全性、完整性與可維護性。
現(xiàn)代軟件配置庫是軟件開發(fā)項目的核心基礎設施,是項目開發(fā)人員隨時需要訪問的軟件代碼庫。
最新、常用的軟件開發(fā)工具通常都具有與軟件配置庫直接連接訪問的功能。
因此,現(xiàn)代化的軟件配置庫應該具有較高的實時性和容錯性,同時有較強的可擴展性、可分布
性和可復制性,以滿足不斷增長的開發(fā)團隊對配置項的巨大訪問量。
6.3.3工作空間
工作空間,是每個開發(fā)人員訪問軟件配置庫、存取文件版本并進行產(chǎn)品開發(fā)的主要渠道。
它為開發(fā)人員提供了一個具有穩(wěn)定性與一致性的工作環(huán)境。
工作空間首先是一個相對穩(wěn)定的私有文件區(qū),在該區(qū)域里開發(fā)人員可以相對獨立地編碼、修改
和測試,不受其他開發(fā)人員的代碼的影響。
其次,工作空間內(nèi)的代碼本身必須是一致的,即所選取的各個文件(配置項)的版本必須是相
互兼容的,在進行任何修改之前工作空間內(nèi)的文件應該是可編譯、可運行的。
由此,工作空間一般初始化為產(chǎn)品的某一穩(wěn)定基線(Baseline)所標識的配置項集合,以保證不
同開發(fā)人員可以獲得相同的工作空間。
6.3.3工作空間
同時,每個開發(fā)人員的工作空間必須及時更新到最新的產(chǎn)品基線才能保證工作空間的實效性,
避免在舊版本上做無用的開發(fā)。
“刻舟求劍”的寓言在軟件開發(fā)過程中時有上演。
工作空間通常提供相應的機制為開發(fā)人員方便進行修改的合并和基線的刷新。
總之,軟件配置管理中的工作空間為開發(fā)人員提供了一個相對穩(wěn)定一致的開發(fā)環(huán)境.使得開發(fā)
人員既可以獨自分離地進行開發(fā),又可以方便、快捷地合并開發(fā)結果。
軟件開發(fā)中的“分”與“合”的基本邏輯在工作空間中得以實現(xiàn)。
6.3.4變更請求與變更集
如前所述,軟件產(chǎn)品總是處在不斷變化、演進過程中的,軟件配置管理的核心任務、就是管理
軟件產(chǎn)品的變化,使其在變化過程中保持正確性、完整性和一致性。
實現(xiàn)這一任務的關鍵,是對軟件的變更進行管理,確保產(chǎn)品的任何變化都有憑有據(jù)。
變更請求就是開發(fā)人員對軟件產(chǎn)品進行修改的憑據(jù),對產(chǎn)品的每一點改動都應該通過變更請求
詳細登記,并取得相關人員的批準。
6.3.4變更請求與變更集
變更請求通常被分為兩大類,增強請求和缺陷。增強請求,是指系統(tǒng)的新增特征或?qū)ο到y(tǒng)現(xiàn)有
功能的有計劃的修改。
缺陷,是指存在于一個已交付產(chǎn)品中的與所設計功能不一致的異?,F(xiàn)象,這里的交付對象可以
是最終客戶。
也可以是同產(chǎn)品的開發(fā)或測試人員。
例如,每個里程碑或基線的交付。
變更集,是記錄一個變更請求實施后生成的配置項新版本的集合,是該變更請求完成后的結果。
6.3.5軟件配置管理工具
軟件配置管理工具是一些軟件工具,其自動化軟件配置管理最佳實踐并提供方便的操作接口以
便于開發(fā)人員日常使用。
同編輯器、編譯器和調(diào)試一樣,軟件配置管理工具是今天的軟件工程師工具箱中必要的組成部
分。
沒有工具很難實現(xiàn)有效的軟件配置管理。
在早期軟件開發(fā)項目中,配置管理由配置庫管理員手工完成,記錄每個開發(fā)人員取出和生成的
每個配置項版本,煩瑣、緩慢而又容易出錯。
現(xiàn)代化的軟件配置管理工具能精確、有效地管理軟件配置管理中的各種要素,盡可能地自動化
軟件開發(fā)過程中用于配置管理相關的過程,同時保持對軟件產(chǎn)品的有力控制。
6.4軟件配置管理的主要過程
6.4.1配置項標識與存儲過程
標識過程的關鍵,是如何紿每個配置項賦予一個唯一而又有意義的標識。
在普通的文件系統(tǒng)中,文件名及其目錄路徑可以作為一個文件的唯一標識,但在配置管理系統(tǒng)
中同一個文件(配置項)有許多版本,必須把每個版本也標識出來。
給版本賦予標識首先要確定版本的命名規(guī)則,版本命名規(guī)則經(jīng)確定就在整個配置管理系統(tǒng)或過
程中保持不變(在自動化配置管理系統(tǒng)中,版本命名規(guī)則一般是固化在配置管理工具中的)。
同一配置項的前后版本之間存在傳遞關系,相鄰版本之間存在分支關系。
兩種常用的版本標識方式
版本命名規(guī)則,應該體現(xiàn)這些關系。常用配置管理工具,通常采用兩級制版本命名規(guī)則,前一
級標識版本分支、后一級標識同一分支中的特定版本,多個前后級標識串聯(lián)起來可以表示任何
復雜的版本。
不同配置管理工具可能用不同的符號連接每級標識(常用的連接符號有和7’),而且也
可能采用字符或數(shù)字來標識分支,但其本質(zhì)構成是相同的。
6.4.2版本管理過程
版本管理過程,是實現(xiàn)完整的配置管理功能的基礎。
版本管理的主要內(nèi)容,是管理產(chǎn)品配置項的每一個版本的生成和使用
主要方法包括版本訪問與修改控制、版本分支和合并、版本歷史記錄,以及歷史版本檢取。
軟件開發(fā)人員不能直接訪問配置庫對源文件(配置項)進行修改,所有修改必須在開發(fā)人員各
自的工作空間中進行。
6.4.2版本管理過程
一般說來,工作空間是開發(fā)人員本地文件系統(tǒng)中的一個文件夾,具有文件系統(tǒng)提供的訪問控制
機制。
開發(fā)人員可以按特定方法選取所需要的并且授予訪問權的文件版本,從配置庫中加載到工作空
間內(nèi)。
由于產(chǎn)品源代碼是產(chǎn)品開發(fā)中最重要的信息,項目管理人員通常會在配置庫中設置額外的訪問
權限控制,以確保只有授權的人員才可以訪問相應產(chǎn)品或模塊的代碼版本。
6.4.2版本管理過程
盡管軟件配置項經(jīng)過不斷的修改、分支合并形成復雜的版本關系,版本管理系統(tǒng)總是能清晰、
完整地記錄各個配置項的版本歷史的“
版本歷史記錄中,通常包括每個版本的版本標識、修改時間、修改人員、修改說明等基本信息。
這些信息可以被項目開發(fā)人員查找瀏覽,用于問題追溯、影響分析、版本重構或項目審計等活
動。
版本管理的另一重要功能,是歷史版本檢取。
配置管理工具大多可以根據(jù)配置項版本標識或基線名稱檢取出一個或多個配置項的指定歷史版
本。
也可通過調(diào)整工作空間的版本選取條件,加載整個產(chǎn)品的某一歷史版本。
6.4.3變更控制過程
軟件產(chǎn)品在開發(fā)過程中進行變更是不可避免的,但不對變更加以控制是萬萬不可的。
變更和變更控制,是矛盾的統(tǒng)一體。
變更控制過程就是通過一系列方法、手段對變更進行引導約束,使變更的結果有利于改進產(chǎn)品、
滿足客戶需要,同時使變更的實施對項目影響較小。
變更控制過程主要包括提出變更請求、分析變更請求、變更決策、實施變更和驗證變更等步驟。
這些步驟需要有不同的軟件開發(fā)人員參與,每個步驟主要由不同角色負責。
基本的變更控制流程
通過自動、手工的分配方式,提交的每一個變更請求將被分配給相關的開發(fā)人員進行初步的分
析。
6.4.3變更控制過程
變更都是有原因的,任何人提出變更請求都是受相關事件的觸發(fā)造成的。
這些事件可以是用戶使用產(chǎn)品過程中遇到的產(chǎn)品故障或需要產(chǎn)品新功能的愿望,也可以是開發(fā)
人員在開發(fā)環(huán)節(jié)發(fā)現(xiàn)的各種錯誤,如測試時發(fā)現(xiàn)的功能錯誤、審查文檔時發(fā)現(xiàn)的描述與實際操
作不符、瀏覽代碼時發(fā)現(xiàn)某行代碼邏輯有誤等。
發(fā)生這些事件后,相關人員可自行提出變更請求或通過各種渠道委托項目開發(fā)人員提出變更請
求。
6.4.3變更控制過程
變更分析,主要從客觀的角度驗證變更請求的正確性和合理性,提出初步的修改可行性判斷、
修改方案和工時,并預測可能對項目和產(chǎn)品帶來的影響。
變更分析一般由開發(fā)小組負責人或有經(jīng)驗的開發(fā)人員完成。
變更分析的結果,必須附加到該變更請求在配置管理庫的記錄中。
經(jīng)過初步分析的變更請求將被變更控制組(ChangeControlBoard,CCB)統(tǒng)一評審決策,以確
定是否實施變更
CCB根或變更請求的相關信息和變更分析的結果,結合項目當前狀況決定每個變更請求實施與
否。
決:實施的變更將被分配給相應開發(fā)人員去實施;決定實施的變更將被終止,并告知變更提交
者。CCB通常也為待實施的變更分配優(yōu)先級或重新指定其他開發(fā)人員去實施。
6.4.3變更控制過程
開發(fā)人員實施變更并提交修改后必須經(jīng)過質(zhì)量保證人員進行變更驗證,確保所做的修改不多不
少地實現(xiàn)了相應的變更請求。
驗證通過的變更將反映在產(chǎn)品的下個版本中,并告知相應的變更請求提出者。驗證未通過的變
更將被要求返工或回滾。
從理論上說,配置項的所有修改都必須經(jīng)過上述的變更控制過程。
這對許多開發(fā)人員來說或許是難以忍受的繁文維節(jié)和官僚主義。
優(yōu)秀的配置管理工具能根據(jù)項目的需要對變更控制流程加以定制,如小項目可通過合并或自動
化某些步驟使得變更控制過程更為靈活高效。
相反,大型項目可通過擴充變更控制步驟,以實現(xiàn)更嚴格的控制過程。
6.4.4基線管理過程
基線(BaseLine),是由軟件產(chǎn)品所有配置項的特定版本構成的一個固定的產(chǎn)品版本,它是一定
階段變更請求實施后的累加效果。
基線標志產(chǎn)品開發(fā)前一個階段的結果,又作為下一階段開發(fā)的基礎。
基線管理和產(chǎn)品開發(fā)模式、開發(fā)階段劃分,以及產(chǎn)品發(fā)布過程緊密相關。
基線管理過程
基線管理過程,主要解決基線的創(chuàng)建、發(fā)布、使用、維護等方面的問題
6.4.4基線管理過程
基線一旦創(chuàng)建,就成為整個產(chǎn)品的一個正式標準,隨后的開發(fā)都基于此標準進行,直到下一個
基線被創(chuàng)建。
因此,每一個新創(chuàng)建的基線都需要以正式的方式發(fā)布給項目中所有人員,發(fā)布內(nèi)容包括基線的
名稱、包含的版本、可執(zhí)行代碼,以及初步驗證結果。
基線發(fā)布后,代碼開發(fā)人員可以將基線內(nèi)的配置項版本更新到他的工作空間中,使個人的工作
環(huán)境與項目中的整體變更保持同步。
項目測試人員可以取得基線對應的可執(zhí)行代碼,進行進一步的測試驗證,根據(jù)發(fā)現(xiàn)的問題提出
新的變更請求,推動下一個基線的生成。
在項目的進展過程中,也可以利用舊的基線重新建立基于某個特定發(fā)布版本的配置,用來重現(xiàn)
已報告的錯誤或定位重復發(fā)生的問題。
6.4.4基線管理過程
此外,基線也可作為新項目的起點,由此生成一個單獨的分支進行新項目的開發(fā),新項目將與
隨后對原始項目(在主要分支上)所進行的變更相互隔離,必要時再進行臺并。
基線反映的是配置項已經(jīng)發(fā)生的變更.是固化的版本,因比基線的內(nèi)容本身不需要什么維護工
作。基線的維護,主要是保存基線記錄,并結合產(chǎn)品開發(fā)過程標識基線狀態(tài)。
產(chǎn)品配置項的不同基線
6.5軟件配置管理中的角色
軟件配置管理涉及了軟件開發(fā)過程中幾乎所有的環(huán)節(jié),需要項目所有人員的參與。
確實,對軟件產(chǎn)品的開發(fā)和維護人員來說,配置管理是不可避免的日常工作。
不管擔任的是什么樣的開發(fā)過程中的角色,都會涉及軟件配置管理活動。
區(qū)別在于同一種角色在軟件開發(fā)過程中和在配置管理過程中的角色主次不同。
從另一方面看,配置管理中有些任務是需要專門的配置管理人員來完成的。
如配置管理規(guī)劃、配置庫和配置管理工具的維護、配置審計。
6.5.1配置管理專職人員
1.配置管理負責人
配置管理負責人的職責,是在開發(fā)機構管理層提供的框架內(nèi)實施、維護并改進軟件配置管理流
程與設施。
有些機構的配置管理負責人需要全面負責整個機構的配置管理,有些機構按項目或組織單元設
置配置管理負責人。
配置管理負責人的工作,包括以下內(nèi)容。
(1)為組織機構規(guī)劃配置管理方案,將機構或組織對配置管理的需求轉(zhuǎn)換為實際的生產(chǎn)過程、
工具和操作規(guī)范。
(2)部署和更新配置管理工具'
(3)跟蹤機構或組織的配置管理執(zhí)行情況,確保所定的流程被嚴格地執(zhí)行。
(4)為管理層提供配置管理狀態(tài)報告、數(shù)據(jù)分析結果和相關改進建議。
2.配置庫管理員
配置庫管理員負責建立產(chǎn)品配置庫,并維護每個配置庫的內(nèi)部完整性與存儲空間的安全性。
配置庫管理員的工作范圍,主要有以下幾方面:
(1)建立配置庫。
(2)創(chuàng)建并維護組成配置庫的元數(shù)據(jù)(非配置項數(shù)據(jù))。
(3)對配置庫的使用者進行日常支持。
(4)從配置庫中提取配置項狀態(tài)信息與其他過程度量信息,以供配置報告和審計。
3.配置控制委員會
配置控制委員會全面負責配置項的變更控制,因此又稱為變更控制委員會。
配置控制委員會有一位專職的主席,負責協(xié)調(diào)和決策.委員會的成員則由項目經(jīng)理、產(chǎn)品經(jīng)理、
客戶代表、以及質(zhì)量保證負責人等項目中的重要人員擔當,
配置控制委員會的主要工作,有以下幾點:
(1)評估變更請求,批準或否決所請求的變更。
(2)協(xié)調(diào)變更請求的執(zhí)行過程,安排合理的優(yōu)先級。
(3)跟蹤變更請求的執(zhí)行狀況,并向變更請求的提出者及相關人員提供反饋。
(4)決定產(chǎn)品基線的創(chuàng)建和使用策略,確定對外發(fā)布的基線。
6.5.2機構運營管理人員
配置管理專職人員,是一個機構或項目中配置管理過程的構造者和推廣者,但他們只有獲得了
機構或項目管理層的支持與認可后才能有效地完成其職責任務。
因此,機構運營和管理人員是配置管理的有力支持者。在比,我們把一個機構的組織管理人員
和負責日常運營工作人員都劃歸為配置管理的重要支持力量。
這些人員主要包括機構管理層、資產(chǎn)負責人、工程管理負責人、環(huán)境與工具負責人,這些角色
對配置管理有不同的支持作用。
機構管理層對配置管理的支持主要體現(xiàn)在兩個方面:
為配置管理的實施和改進提供資本和對實施相關人員授予所需的特權
為配置管理專職的人員明晰崗位職責,并提供職業(yè)晉升途稅。
6.5.2機構運營管理人員
過程管理負責人制訂組織或機構的各種過程,保證這些過程滿足生產(chǎn)和發(fā)展的需求,能夠正確
地得到實施。
配置管理過程是其中的一和過程。
因此,過程管理負責人會參與配置管理策略和過程的編制,使其與其他過程相互銜接兼容。同
時確保同一機構中不同項目的配置管理過程基本一致。
環(huán)境與工具負責人,為開發(fā)機構提供環(huán)境和工具的支持,例如網(wǎng)絡、數(shù)據(jù)存儲、開發(fā)工具等方
面的支持。
配置管理活動同樣離不開這些環(huán)境和工具。
環(huán)境與工具負責人為配置管理活動提供所依環(huán)境和工具的安裝和培訓支持,同時協(xié)助配置管理
負責人定制配置管理工具,以實現(xiàn)與其他開發(fā)工具的集成。
6.5.3項目開發(fā)人員
項目開發(fā)人員,是配置管理活動中的重要參與者和執(zhí)行者,
從前面關于配置管理過程的描述中可以看出,配置管理過程和項目開發(fā)過程緊密相關,其中的
許多步驟和開發(fā)環(huán)節(jié)緊密關聯(lián),需要相應環(huán)節(jié)的開發(fā)人員去實施相應的配置管理操作,下面我
們來看看項目中主要開發(fā)角色在配置管理中的職責。
項目經(jīng)理對項目以及項目生成的產(chǎn)品承擔總體責任。
在配置管理方面,項目經(jīng)理應該根據(jù)項目需求來計劃配置管理,并在項目預算中包括配置管理
相關的花費,在項目進行過程中提供有預算的資源。
此外,項目經(jīng)理參與變更控制決策、審批配置管理報告和配置審計報告等配置管理活動。
6.5.3項目開發(fā)人員
設計人員生成產(chǎn)品整體結構以及詳細設計,并在產(chǎn)品整個生命周期內(nèi)維護這些設計結果。
設計人員與分析人員參與類似的配置管理活動。
程序員完成所有的編程活動,生成并維護源代碼和相關文件。
程序員從事的配置管理操作包括:
標識代碼和數(shù)據(jù)文件為配置項,并存儲到配置庫中;
依據(jù)變更請求修改代碼,生成正確的代碼版本檢入到配置庫中:
跟蹤產(chǎn)品基線的發(fā)布,更新自己的工作空間。
資深程序員還可作為配置控制委員會成員,參與變更決策C
6.5.3項目開發(fā)人員6.53項目開發(fā)人員
集成人員將源代碼或派生文件集合成一個完整、一致的系統(tǒng),并生成系統(tǒng)的可執(zhí)行文件。
集成人員從事的配置管理活動有:
創(chuàng)建并發(fā)布基線、維護基線狀態(tài)審查基線中配置項一致性、參與配置審計等。
測試人員根據(jù)測試計劃來測試驗證產(chǎn)品的各個版本,包括內(nèi)部發(fā)行的中間版本。
測試人員需要將測試方案和相關的用例、腳本標識為配置項,并存儲在配置庫中。
測試人員還主要負責變更結果驗證和基線狀態(tài)標定等配置管理任務,
6.6常用軟件配置管理工具
軟件配置管理是軟件開發(fā)過程中的一項十分繁瑣而又重要的工作,同時又和軟件的開發(fā)項目的
整個過程緊密地聯(lián)系在一起,所以必須要有合適的工具來協(xié)助配置管理過程。
軟件配置管理工具在軟件的整個生命周期中起著重要的支持和控制作用。
選擇合適的軟件配置管理工具,能給配置管理的實施和整個開發(fā)過程提供強有力的保障。
將按照配置管理工具的發(fā)展日程和功能特點對常用的配置管理工具進行簡單的介紹。
6.6.1軟件配置管理工具的發(fā)展歷程
軟件配置管理工具,幾乎是伴隨著計算機軟件的出現(xiàn)而產(chǎn)生的。
當計算機還在以打孔紙帶輸入程序時,配置管理工具就形成了。
最原始的配置管理工具是以手工方式在記錄本或公示板上記錄每個紙帶的檢出狀態(tài)和使用者的
簡單數(shù)據(jù)記錄。
之后,在19世紀50年代末,主機系統(tǒng)(Mainframe)中的系統(tǒng)更新程序(UpdateSysten)就
可以通過記錄打孔帶的修改位置來生成新的程序版本了,這就是自動化的配置管理(版本管理)
工具的雛形。
6.6.1軟件配置管理工具的發(fā)展歷程
早期的軟件配置管理工具,只是在程序文件一級進行版本控制的,因此,可稱之為面向文件的
配置管理工具。
從功能上看,M類系統(tǒng)基本上具備了現(xiàn)有配置管理系統(tǒng)中的版本管理功能。能夠標志和記錄每
個文件的各個修改版本;
提供檢出和檢入機制以避免版本覆蓋,
具有簡單的工作空間管理機制,用于開發(fā)人員和配置庫交互;
通過版本分支與合并機制支持并行開發(fā)(盡管操作可能很復雜);
能夠方便提取歷史版本的內(nèi)容與控制信息;
提供文件版本比較功能;
記錄重要版本信息和數(shù)據(jù)存取日志以供配置審計。
6.6.1軟件配置管理工具的發(fā)展歷程
這類系統(tǒng)一般提供簡潔的命令行操作方式,以方便其他系統(tǒng)封裝,調(diào)用相應命令。這類配置管
理工具的主要特點如下。
(1)大多以單個文件為處理對象,對每個文件的改變以犯立的版本文件存儲在配置庫中。
(2)配置庫只是普通的文件系統(tǒng),在每個程序文件中嵌入版本控制信息,沒有復雜的配置管理
元數(shù)據(jù)(MetaData)o
(3)開發(fā)人員必須對每個要修改的文件分別進行檢出和檢入。
(4)系統(tǒng)沒有開發(fā)任務的概念,只能由開發(fā)人員通過其他方式記錄、查找每個任務所修改的文
件。
元數(shù)據(jù)
通信元數(shù)據(jù)
6.6.2版本控制工具及功能
1.版本控制系統(tǒng)
版本控制系統(tǒng)(VersionControlSystem,VCS),是一種記錄一個或若干文件內(nèi)容變化,以便將
來查閱特定版本修訂情況的系統(tǒng)。
版本控制系統(tǒng)不僅可以應用于軟件源代碼的文本文件,而且可以對任何類型的文件進行版本控
制。
版本控制是一種在開發(fā)的過程中用于管理我們對文件、目錄、工程的修改歷史,方便查看更改
歷史記錄,備份以便恢復以前的版本的軟件工程技術。
1.版本控制系統(tǒng)
版本控制的目的包括:
①實現(xiàn)跨區(qū)域多人協(xié)同開發(fā);
②追蹤、記載一個或者多個文件的歷史記錄;
③組織、保護源代碼和文檔;
④統(tǒng)計工作量;
⑤并行開發(fā)、提高開發(fā)效率;
⑥跟蹤記錄整個軟件的開發(fā)過程;
⑦減輕開發(fā)人員的負擔,節(jié)省時間,同時降低人為錯誤,簡單說,就是用于管理多人協(xié)同開發(fā)
項目的技術。
沒有進行版本控制或者版本控制本身缺乏正確的流程管理軟件開發(fā)過程中,會引入很多問題,
如軟件代碼的一致性、軟件內(nèi)容的冗余、軟件過程的事物性、軟件開發(fā)過程中的并發(fā)性、軟件
源代碼的安全性,以及軟件的整合等問題。
本地版本控制
版本控制分類包括:本地版本控制、集中版本控制、分布式版本控制
1)本地版本控制
記錄文件每次的更新,可以對每個版本做一個快照,或是記錄補丁文件,適合個人用,如RCS
(GNURevisionControlSystem)0
集中版本控制
版本控制分類包括:本地版本控制、集中版本控制、分布式版本控制
3)分布式版本控制
分布式版本控制系統(tǒng)中,客戶端不僅僅是只提取最新版本的文件快照,而是把代碼倉庫完整的
鏡像下來。
所以,每一次提取的操作,都是對代碼倉庫的完整備份,也就不必擔心協(xié)同工作用的服務器發(fā)
生故障。
所有版本信息倉庫,全部同步到本地的每個用戶,這樣,就可以在本地查看所有版本歷史,可
以離線在本地提交,只需在連聯(lián)網(wǎng)時push到相應的服務器或其它他用戶。
由于每個用戶那里保存的,都是所有的版本數(shù)據(jù),只要有一個用戶的設備沒有問題,就可以恢
復所有的數(shù)據(jù),但這增加了本地存儲空間的占用。
IBM筆記PNG支持-軟件配置管理
數(shù)據(jù)和元數(shù)據(jù)
2.CVS
CVS(ConcurrentVersionSystem)版本控制系統(tǒng)是一種GNU軟件包,主要用于在多人開發(fā)環(huán)
境下的源碼的維護。
實際上,CVS可以維護任意文檔的開發(fā)和使用,例如,共享文件的編輯修改,而不僅僅局限于
程序設計。
CVS維護的文件類型,可以是文本類型也可以是二進制類型。
CVS用Copy-Modify-Merge(拷貝、修改、合并)變化表支持對文件的同時訪問、修改,明確
地將源文件的存儲和用戶的工作空間獨立開來,并使其并行操作。
CVS基于客戶端/服務器的行為使其可容納多個用戶,構成網(wǎng)絡也很方便。
這一特性,使得CVS成為位于不同地點的人同時處理數(shù)據(jù)文件(程序源代碼)時的首選。
2.CVS
2.CVS
CVS的基本工作思路,是在一臺服務器上建立一個源代碼庫,庫里可以存放許多不同項目的源
程序。
由源代碼庫管理員統(tǒng)一管理這些源程序。
每個用戶在使用源代碼庫之前,首先要把源代碼庫里的項目文件下載到本地,然后,用戶可以
在本地任意修改,最后,用CVS命令進行提交,由CVS源代碼庫統(tǒng)一管理修改。
這樣,就好像只有一個人在修改文件一樣,既避免了沖突,又可以做到跟蹤文件變化等。
3.VSS
VSS(VisualSourceSafe)是微軟VisualStudio的成員,主要任務是負責項目文件的管理,幾乎
可以適用任何軟件項目。
管理軟件開發(fā)中各個不同版本的源代碼和文檔,占用空間小,并且方便各個版本代碼和文檔的
獲取,對開發(fā)小組中對源代碼的訪問進行有效的協(xié)調(diào)。
3.VSS
VSS是一款歷史悠久的版本管理工具,在早期扛起了版本管理系統(tǒng)方面的大氣,能幫助解決一
部分版本控制方面的問題,在一定程度上幫助解決代碼共享方面的難題。
但是依舊存在一些不足,比如:
(1)文件大多會以獨占的形勢進行鎖定。如果一個人在修改的時候,其他人沒有辦法進行修改。
(2)VSS只支持Windows版本,且只兼容微軟的開發(fā)工具。
(3)文件存儲,服務器必須共享文件夾,對文件的安全性沒有足夠保障。
微軟VisualSourceSafeClient-CodeProject
4.SVN
SVN(SubVersion)作為CVS的重寫和改進產(chǎn)品,其目標就是成為一個更好的版本控制軟件,
以更新傳統(tǒng)的CVS系統(tǒng)。
SVN是開源的配置管理系統(tǒng)中的新的杰作,主要開發(fā)人員都是業(yè)界知名的CVS專家,它支持絕
大部分的CVS功能和命令,其命令風格與界面也與CVS非常接近。
SVN在繼承了CVS的功能基礎上增加了許多新的特性。
SVN
SVN是一個開放源代碼的版本控制系統(tǒng),相較于RCS、CVS.SVN采用了分支管理系統(tǒng),設計
目標就是取代CVSo
互聯(lián)網(wǎng)上很多版本控制服務,已從CVS遷移至ijSubversion。
SVN就是用于多個人共同開發(fā)同一個項目,共用資源的目的。
微軟VisualSourceSafeClient-CodeProject
VSS為建立一個項目的多個版本提供了良好的模式:他有共享(Share),分支(Branch).標簽
(Label).合并(Merge),鏈接(Links).路徑(Paths)等版本管理機制和相關操作的命令。
SVN
SVN作為集中式的版本管理系統(tǒng),優(yōu)點在于:
①管理方便,邏輯明確,操作簡單,上手快;
②易于管理,集中式服務器更能保證安全性;
③代碼一致性非常高;
④有良好的目錄級權限控制系統(tǒng)。
劣勢在于:
①對服務器性能要求高,數(shù)據(jù)庫容量經(jīng)常暴增,體量大;
②必須聯(lián)網(wǎng),如果不能連接到服務器上,基本上不可以工作,如果服務器不能連接上,就不能
提交,還原,對比;
③不適合開源開發(fā);
④分支的管控方式不靈活。
SVN
SVN是一個開放源代碼的版本控制系統(tǒng),相較于RCS、CVS.SVN采用了分支管理系統(tǒng),它的
設計目標就是取代CVSo
互聯(lián)網(wǎng)上很多版本控制服務已從CVS遷移至ISubversion0
SVN就是用于多個人共同開發(fā)同一個項目,共用資源的目的。
Git
Git是一款免費、開源的分布式版本控制系統(tǒng),用于敏捷高效地處理任何或小或大的項目。
作為一個開源的分布式版本控制系統(tǒng),可以有效、高速的處理從很小到非常大的項目版本管理。
Git
Git的優(yōu)缺點為:
①適合分布式開發(fā),每個個體都可以作為服務器,每一次Clone就是從服務器上pull到了所有
的內(nèi)容,包括版本信息;
②公共服務器壓力和數(shù)據(jù)量都不會太大;
③速度快、靈活,分支之間可以任意切換;
④任意兩個開發(fā)者之間,可以很容易的解決沖突,并且單機上就可以進行分支合并;
⑤離線工作,不影響本地代碼編寫,等有網(wǎng)絡連接以后可以再上傳代碼,并且在本地可以根據(jù)
不同的需要,本地新建自己的分支。
6.ClearCaseUCM
ClearCase是IBM公司Rational產(chǎn)品部門生產(chǎn)的一款業(yè)界領先的重量級軟件配置管理工具。
ClearCase的主要功能特點
1)版本管理
ClearCase能夠管理文件和目錄項的每個修改版本,并通過分支和歸并功能支持并行開發(fā)。
ClearCase支持不同文件類型的差異化版本管理,能自動識別二進制文件和特殊的文本文件(如
XML文件),對不同類型的文件采用不同的方式進行版本七較和合并操作。
版本信息保存在私有的關系數(shù)據(jù)庫中,保證數(shù)據(jù)的安全性和訪問效率。
2)工作空間管理
ClearCase給每位開發(fā)者提供了獨立的工作空間(視圖),開發(fā)人員在各自的工作空間中可以方
便地訪問或修改文件版本。
ClearCase使工作空間與本池文件系統(tǒng)無縫集成。開發(fā)人員能夠透明地以本地文件目錄的形式訪
問配置項的任何版本。
ClearCase的主要功能特點
3)構建管理
ClearCase能方便地生成軟件構造文件清單,而且可以完全、可靠地重建任何構造版本。
ClearCase也可以通過共享二進制文件和并發(fā)執(zhí)行多個構建腳本的方式支持有效的軟件構「牛,既
可以使用定制腳本,也可使用自身的Clearmake程序。
4)變更控制
ClearCase可以通過配置策咯的設置和使用鉤子程序(Hoo<)來加強變更控制,規(guī)定只有符合特
定條件的變更才能用來修改程序文件。
ClearCaseUCM是在大量軟件工程實踐和ClearCase用于反饋建議的基礎之上,提煉出來的最
佳配置管理方案——統(tǒng)一變更管理。
6.6.4面向開發(fā)流程的配置管理工具及功能
第二代面向變更集的配置管理工具,具有配置項和任務的關聯(lián)能力,但它自身的任務管理功能
很有限,只起到了基于任務的版本收集的功效。
在面向變更集的配置管理的基礎上,產(chǎn)生了更新一代的面向開發(fā)流程的配置管理工具。
這類工具中的任務有更豐富的數(shù)據(jù),具備較強的任務管理功能,并能通過任務管理對項目的開
發(fā)流程進行規(guī)范。
這類工具中,有些自帶流程支持功能,有些需要與配套的工具集成來支持開發(fā)流程;
這些只支持相對固定的開發(fā)流程,有些可方便地進行流程設定,甚至任意定制流程。
1.集成的ClearCase和CearQuest
ClearQuest是一個強大的企業(yè)級流程自動化工具。
通過定制可以適用于任何領域的流程控制。
不過通常的用法是作為缺陷管理或變更管理系統(tǒng),用于軟件開發(fā)或類似的具有復雜流程的生產(chǎn)
項目中
盡管ClearQuest提供了多種預定義的流程方案供客戶選擇,其主要的功能特性,還是支持自定
義流程。
多數(shù)ClearQuest用戶都會基于某種預定義的流程定制出適合本組織實際情況的開發(fā)流程。
集成的ClearCase和ClearQuest系統(tǒng)有如下功能特點
1)有效地記錄、管理和追蹤變更請求
ClearQuest通過多種易于使用的客戶端(Windows、UNIX、Web、E-mail),使用戶在任何地點、
以任何方式都可以提交、獲取在整個開發(fā)生命周期中出現(xiàn)的各種類型的變更請求,包括測試階
段出現(xiàn)的缺陷、需求分析階段的需求擴展請求等。
所有的變更請求在ClearQuest中被集中存儲在統(tǒng)一的數(shù)據(jù)庫之中,以便進行各種形式的查詢,
同時也便于集中管理。
2)有效地加強變更請求和版本修改的聯(lián)系
集成的方案中ClearCaseUCM的活動將會與ClearQuest中的變更請求相對應,可以通過
ClearCase策略規(guī)定只有處于某種狀態(tài)(如CCB批準后)的變更請求才能用來修改代碼并且修
改后的代碼版本將和該變更請求緊密綁定,便于代碼審查和追蹤。
3)能促進團隊的溝通和協(xié)作
ClearQuest提供一套完備的電子流管理系統(tǒng)。它可以利用企業(yè)現(xiàn)有的郵件服務系統(tǒng)實現(xiàn)自動電
子郵件通知功能。
當系統(tǒng)內(nèi)提交了新的變更請求或已有變更請求的狀態(tài)發(fā)生變化時,ClearQuest會自動通過電子
郵件通知相關的人員,從而大大提高了團隊的協(xié)作效率。
集成的ClearCase和ClearQuest系統(tǒng)有如下功能特點
4)隨時隨地了解項目狀況
ClearQuest支持通過Web的方式對系統(tǒng)進行訪問,在瀏覽器中可以查詢變更請求的狀態(tài)、瀏覽
變更請求的信息、生成多和統(tǒng)計分析圖表和項目狀態(tài)報告。
所以,項目經(jīng)理可以及時、準確地了解項目的狀況。
5)具有很強的可定制性
在ClearQuest系統(tǒng)中所涉及的表單信息域、狀態(tài)變遷過程、分析圖表和狀態(tài)報告等都是可以根
據(jù)用戶的實際需要進行定制的,并且可以隨項目的發(fā)展不斷進行調(diào)整。
因此,ClearQuest可以適用于任何類型,以及任何規(guī)模的項目。
2.其他面向開發(fā)流程的工具
1)CCC/Harvest
CCC/Harvest起源于20世紀70年代初
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 衛(wèi)生局防疫消殺制度
- 游泳池公共衛(wèi)生管理制度
- 衛(wèi)生類應急管理制度
- 衛(wèi)生院廉政建設制度
- 環(huán)境衛(wèi)生分片區(qū)管理制度
- 酒店客房衛(wèi)生間管理制度
- 美容美發(fā)館衛(wèi)生管理制度
- 影劇院公共衛(wèi)生管理制度
- 衛(wèi)生院藥品調(diào)劑管理制度
- 泡椒加工廠衛(wèi)生管理制度
- DB32/T 3392-2018灌溉水系數(shù)應用技術規(guī)范
- 2025年福建省水利投資開發(fā)集團連城水務有限公司招聘筆試參考題庫含答案解析
- 股東清算解散協(xié)議書
- 產(chǎn)后腰背疼康復治療
- 2025年商業(yè)物業(yè)抵押貸款合同范本
- 2024用電信息采集系統(tǒng)技術規(guī)范第1部分:專變采集終端
- 浙江省杭州市2024年中考語文試卷(含答案)
- 四川省綿陽市2020年中考數(shù)學試題(含解析)
- 期末達標測試卷(試題)-2024-2025學年人教PEP版英語四年級上冊
- DLT 1563-2016 中壓配電網(wǎng)可靠性評估導則
- HJ 377-2019 化學需氧量(CODCr)水質(zhì)在線自動監(jiān)測儀技術要求及檢測方法
評論
0/150
提交評論