1、企業(yè)軟件配置治理實施策略毫無疑問,軟件配置治理是軟件開發(fā)的基石.一個缺少軟件配置治理的企業(yè),就等于“作坊式的開發(fā) 模式.雖然大多數(shù)企業(yè)在這一點的熟悉上已經(jīng)達成共識,然而,在實際的實施時仍存在不少誤區(qū).正確 地在企業(yè)實施軟件配置治理,有賴于全面正確地熟悉軟件配置治理,以及預防一些常見的誤區(qū),并選擇 正確的工具.由于配置治理涉及的領(lǐng)域既有廣度,又有深度,因此,本演講不打算面面俱到,而只是抽取其中的 一局部,希望能起到拋磚引玉的效果.正確熟悉軟件配置治理要預防在軟件配置治理實施時的誤區(qū),首先需要我們對軟件配置治理的含義有一個正確全面的認 識,在這一方面,根本上有兩個權(quán)威的解釋,一個是 SEI, 一個

2、CMM方面的.SEI的定義要點包括：? 配置治理CM是軟件過程的一個關(guān)鍵元素.它是一個規(guī)程,通過限制產(chǎn)品的進化過程,如持續(xù)的、變化的變更,為軟件系統(tǒng)產(chǎn)品提供了穩(wěn)定性.? 作為一個治理規(guī)程, CM通過標識產(chǎn)品的組成局部和變更；通過限制變更的開始、評估、 授權(quán)和限制；通過記錄和報告產(chǎn)品及其變更的歷史和狀態(tài),最終限制了產(chǎn)品的整個進化 過程.? 作為一項開發(fā)支持功能, CM用來維護產(chǎn)品的實際組成局部；記錄產(chǎn)品的組成局部乃至整個產(chǎn)品的變化歷史；為產(chǎn)品的變更提供了一個穩(wěn)定的工作平臺；支持從產(chǎn)品的組件“組裝 成整個產(chǎn)品；并自動協(xié)調(diào)并發(fā)的修改.CMM/CMMI的定義要點包括：? 軟件配置治理的目標是在軟件的整

3、個生命周期期間建立和維護軟件產(chǎn)品的一致性.軟件 配置治理包括：標識軟件工程的配置項；限制配置項的修改；記錄和報告配置項的狀態(tài) 和修改活動.? 配置治理的核心是意圖消除由于不同版本工件的存在而可能帶來的混亂和錯誤.工程中 工件的變化不可預防,原因可能包括糾正錯誤,功能增強以及產(chǎn)品的進化.配置治理就 是要使得這些不可預防的變更處于限制之下.大家可以看到,無論是 SEI的定義,還是 CMM/CMMI的定義,二者之間并沒有本質(zhì)上的區(qū)別.歸納 起來,從總體上來說,軟件配置治理主要包括五個主要方面,即配置項的標識、對配置項修改的 限制、向團隊成員 報告軟件配置治理的狀態(tài)、審計軟件配置治理活動、實現(xiàn)自動化的

4、構(gòu)建與發(fā)布,其中第五點更是與時下流行的敏捷趨勢伴隨而流行.全面熟悉軟件配置治理的含義,可以幫助我們認知在企業(yè)內(nèi)實施配置治理時的先后步驟,以循序漸 進的方式來實施.另外,也可以幫助我們?nèi)嬷卫砥髽I(yè)實施時所涉及的活動.在軟件配置治理的五個主要方面中,很明顯,標識是根底,即首要的第一步是要確定哪些對象需要納入到配置治理的限制之下,候選的對象包括：源代碼,設(shè)計文件,用戶手冊,數(shù)據(jù)庫腳本,構(gòu)建腳本,網(wǎng)站圖形元素等等；接下來需要確定如何限制對這些配置項的修改,包括環(huán)境的搭建,用戶授權(quán),開發(fā) 流程等等；隨后,要及時向團隊成員報告軟件配置治理的狀態(tài),履行告知的義務(wù),以及進行審計,確認 相關(guān)的軟件配置治理活動確

5、實根據(jù)預定的方案高質(zhì)量地完成了.熟悉到這五個方面的軟件配置治理活動的相互關(guān)系非常重要,它們之間互為前提.同時,熟悉到這 一點也告訴我們在進行軟件配置治理建設(shè)時不要好高鷲遠,而是要分階段一點一點的穩(wěn)步前進.這五個方面,軟件配置治理工具都要進行強有力的支持,使得日常事務(wù)減至最少,這是一個成熟的 軟件配置治理工具應(yīng)具備的根本特征,將在后面講述.如果您到此還對上面的定義感到太學術(shù)的話,我們不妨換一個角度來理解軟件配置治理.實際的軟件開發(fā)活動中,常常會有以下的“課題,請您想想該如何解決呢? 如何跟蹤供給商Open Source 的代碼？? 如何治理并行開發(fā)？? 如何進行分布式開發(fā)？? 如何實現(xiàn)自動化的發(fā)

6、布？? 如何實現(xiàn)變更治理的流程自動化？如果一下子答復不上來的話,也沒關(guān)系.這些問題都是軟件配置治理研究的范疇,掌握軟件治理方面的理論,選擇適宜的工具,以及采用適宜的實施策略,將會使這些問題一一得以解決.由此可見,軟件配置治理在軟件開發(fā)研發(fā)活動中具有根底性的地位,無論是Borland的ALM理念,還是RUP的開發(fā)流程,以及敏捷開發(fā),都對這一觀念進行了充分的認可.CMM/CMMI對軟件配置治理的活動進行了進一步的細分,如以下圖所示：從圖中可見,CMM/CMMI將軟件配置治理的活動分成了六個方面,每個方面又再進行了細分.除了上述的五個方面外,還加上了實施軟件配置治理所需要的組織架構(gòu)上的支持活動.全面

7、熟悉軟件配置治理的活動,可以預防在實施的范圍上有所偏差或遺漏.組織架構(gòu)與實施級別前面提到,為了有效實施配置治理,還需要組織架構(gòu)上的支持活動,這就需要具備一定的組織結(jié)構(gòu). 視企業(yè)的規(guī)模以及實際應(yīng)用開發(fā)時的情形,軟件配置治理常常在三個級別上實施：工程級,應(yīng)用級和組 織級,不同級別的軟件配置治理需要履行不同的責任內(nèi)容,因而也具有相應(yīng)的組織結(jié)構(gòu),如下表所示：工程級將配置治理任務(wù)納入到工程總體方案之中 對代碼打基線,作為新開發(fā)的穩(wěn)定根底 建立適當?shù)姆种Р呗耘c結(jié)構(gòu)編譯代碼創(chuàng)立帶交付物的發(fā)布包參加CCB會議工程中的兼職 或?qū)Ｂ毰渲霉?理員工程經(jīng)理及項 目組成員應(yīng)用級產(chǎn)品 級評估應(yīng)用產(chǎn)品級另的配置治理需求選擇

8、最適合該應(yīng)用的配置治理技術(shù)定義應(yīng)用級別的配置治理方案獨立地,如果在組織級別/、存在的話為應(yīng)用建立配置治理環(huán)境為應(yīng)用建立配置治理流程檢出、檢入、構(gòu)建、發(fā)布、變更限制、問題治理等等執(zhí)行配置治理培訓專職配置治理 員、配置治理 經(jīng)理產(chǎn)品經(jīng)理組織級確定配置治理知識域評估組織級別的配置治理風險 評估配置治理的支持和贊助者 定義SCM預算建立配置治理的針對性架構(gòu)定義組織級別的配置治理方案 定義通用配置治理術(shù)語配置治理組, 包括組長,發(fā) 布經(jīng)理等等組織治理層熟悉到這一點非常重要,無論是組織還是個人,在實施軟件配置治理時首先要清楚自己實施軟件配 置治理時的范圍是在工程級,還是應(yīng)用級,或是組織級.不同級別的活動重

9、心不一樣,熟悉到這一點可 以使得將有限的資源投入到關(guān)鍵的地方,從而保證成功.實施誤區(qū)及對策盡管國內(nèi)在軟件配置治理的應(yīng)用上已經(jīng)有著多年的歷史,然而,失敗的情況仍然比比皆是,原因很 多,這里僅列出其中的一些情形,希望能起到警示的作用.我們在此不談?wù)撚捎谌鄙佘浖渲弥卫矶鴰?來的現(xiàn)象,大多數(shù)企業(yè)已經(jīng)不再在是否實施軟件配置治理方面猶豫不決.盡管如此,有了主觀上的愿望 還遠遠不夠,企業(yè)在實施軟件配置治理時還需要注意相應(yīng)的策略以及防范可能會走入的誤區(qū).1 .沒有專職的SCM人員；沒有兼職的 SCM人員；沒有SCM人員這是一個很常見的現(xiàn)象,由于對配置治理的內(nèi)容熟悉不清,組織常常不重視配置治理,工程組除 了工

10、程經(jīng)理,常常是清一色的開發(fā)人員. 缺乏配置治理人員或“湊合的配置治理人員常常會造成工程的諸 多問題,如版本喪失,問題的重復出現(xiàn),并行開發(fā)力度不夠等等.2 . SCM人員地位不高；團隊整體 SCM意識不夠地位不高的SCM人員缺乏推行SCM制度的力度,團隊的 SCM意識不夠更是造成實施的難度加倍.3 .對SCM缺乏正確全面的熟悉1) .范圍對SCM實施的范圍缺乏全面的熟悉常常使得實施時一葉障目,將焦點集中在有限的幾個點上, 例如版本限制和Bug治理,而其他方面卻成為了盲點,例如軟件的構(gòu)建與發(fā)布.2)偏見在主觀上對配置治理存在一些偏見,認為它過分強調(diào)過程與文檔,過于繁瑣,并且也解決不了 工程中的最終

11、問題.其實,配置治理是一項治理活動,是治理活動就得付出一定的治理本錢,只要將配置治理的活 動和前面所描述的相應(yīng)級別相適應(yīng),其投資回報也將最大化,為此所付出的本錢是值得的.另一方面,工程的成功有賴于諸多方面的努力,配置治理只是其中一方面.4 .實施大多以失敗告終1 .缺少中高層支持2 .缺少必要的培訓與支持,團隊對實施的目標熟悉不清3 .不夠敏捷4 .沒有把握好流程、人員、工具三者之間的關(guān)系5 .沒有做好配置審計、報告環(huán)節(jié)成熟軟件配置治理工具的特征相對于其他 CASE工具,配置治理工具應(yīng)該是最必不可少的,它可以幫助你治理軟件開發(fā)時繁瑣的 工作.從早期的基于文件的版本限制工具,如CVS,到今天現(xiàn)代

12、的軟件配置治理工具,如CleaseCase、StarTeam等,軟件配置治理工具已經(jīng)有了長足的開展,并且依然在快速的開展著.軟件配置治理工具發(fā) 展過程中的關(guān)鍵特征如下表所示：第1代：基于文件,以版本限制、支持 Check out/Check in 模型和簡單分支為主要特征第2代：基于工程庫,支持并行開發(fā)團隊協(xié)作以及過程治理第3代：全面Z合CM治理等各個軟件開發(fā)環(huán)節(jié)的軟件配置治理整體解決方案企業(yè)要實施軟件配置治理常常面臨的第一步就是要選擇適宜的工具,在此將列出一個成熟的軟件配 置治理工具應(yīng)該具備的特征：? 配置項對象治理?版本限制?配置治理?并行開發(fā)支持?基線支持?構(gòu)建與發(fā)布治理?能利用流行的構(gòu)

13、建工具：ANT/MAKE?支持多平臺構(gòu)建?支持并行構(gòu)建?能自動處理構(gòu)建依賴關(guān)系?能收集和維護重新產(chǎn)生之前構(gòu)建所需要的信息?工作空間治理?能自動跟蹤工作空間中所有類型的變更?能應(yīng)用不同配置填充工作空間?工作空間既允許隔離又允許更新?流程治理?不同類型的對象都應(yīng)具備流程定制水平?流程的范圍可定制?支持測試與發(fā)布流程?分布式開發(fā)的支持?負載均衡?與其他工具的集成水平?變更請求工具?開發(fā)工具?其他CASE工具?命令彳T, SDK?易用性、易治理性?報告水平?架構(gòu)的彈性Borland StarTeam2006 演示作為新一代的軟件配置治理工具,盡管歷史不長,StarTeam卻有著眾多的好評.隨著 200

14、6版本的發(fā)布,StarTeam在易用性,功能的全面性上仍在進行著長足的開展.StarTeam 簡介StarTeam作為一個配置治理工具,能夠?qū)Ξa(chǎn)品和工程的整個開發(fā)生命周期進行有力的治理,主要包 括兩大方面一、提供快速而有效率的：1、版本限制StarTeam能對各種配置項類型進行自動化的版本治理,并且在版本分支上也能實現(xiàn)自動化.2、過程治理StarTeam對工程開發(fā)過程的支持堪稱完美,通過在工程級強制過程規(guī)那么的使用,可以實現(xiàn)基于需求的開發(fā)、基于變更請求的開發(fā)、以及基于任務(wù)的開發(fā)等開發(fā)模式,并且,通過定制工作流,可以 以技術(shù)手段強制過程的采納.3、構(gòu)建Build治理通過與ANT,CruiseCo

15、ntrol等開源構(gòu)建工具,或諸如 BuidForge等商業(yè)工具的集成,可以實現(xiàn)完 美的構(gòu)建治理水平.4、并行開發(fā)StarTeam的并行開發(fā)通過視圖機制來實現(xiàn).二、提供了一序列的支持功能1、工程Project V和視圖View治理視圖是StarTeam的核心內(nèi)容,StarTeam提供了多種類型的視圖,從而對并行開發(fā)、權(quán)限配置、 發(fā)布等提供了靈活的支持.2、變更跟蹤StarTeam集成了變更治理功能,這一點是它區(qū)別于其他很多商業(yè)配置治理工具的地方.ChangeRequest組件可以實現(xiàn)與 TestDirector組件的集成,由于 TestDirector主要的用戶為測試部門,通 過集成可以實現(xiàn)測試

16、部門與開發(fā)部門間跨部門的協(xié)作.3、主題討論4、任務(wù)治理5、倉庫Repository 定制,允許你添加新的屬性到文件、變更請求、主題和任務(wù)上6、對工作流進行定制以適應(yīng)組織的需要,強制環(huán)境標準基于完整而具有彈性的功能,StarTeam簡化了軟件開發(fā)過程的治理,從而幫助完成配置治理任務(wù),它所帶來的收益主要表達在如下方面：一、改善了開發(fā)流程1、增強了團隊成員間的溝通質(zhì)量2、提升了估計過程的準確度3、改善了在開發(fā)、測試、開發(fā)循環(huán)中工程治理信息流轉(zhuǎn)的質(zhì)量 二、加速了開發(fā)過程1、減少任務(wù)間的流逝時間2、減少了不必要的會議與備忘錄3、自動化軟件打包處理三、強制標準的執(zhí)行1、清楚、自然的版本限制過程2、輕松定制

17、工作流和窗體StarTeam核心功能? 文件治理?自動化版本限制? 需求發(fā)布? 艾更治理? 團隊討論? 任務(wù)分配&追蹤? 可定制的工作流?可定制的表單? 開放的可定制的平臺? 以Web為中央的構(gòu)架? ? 分布式配置庫?自動鏈接可追溯性StarTeam 架構(gòu)一以 Web為中央的架構(gòu)上圖展示了 StarTeam的根本架構(gòu),但并不代表StarTeam的全貌,例如 MPX在上圖中并沒有表達出 來,它將在隨后講述.圖中的StarTeam Server限制了所有對數(shù)據(jù)的訪問,以預防數(shù)據(jù)被病毒感染.它使用當前流行的數(shù) 據(jù)庫,如Oracle, SQL Server ,因而沒有為了掌握一個專有的數(shù)據(jù)庫產(chǎn)品而產(chǎn)生

18、的陡峭的學習曲線和昂貴 的治理本錢.StarTeam有多個不同類型的客戶端接口,用來支持不同的平臺和不同的用戶,你可以遠程使用任意客戶端接口,由于它們與效勞器之間的通信都是通過TCP/IP協(xié)議進行的.很多配置治理產(chǎn)品不具有這一水平,它們可能只允許你遠程使用Web瀏覽器的方式進行訪問,這意味著你將不能在你自己的IDE環(huán)境中使用該產(chǎn)品.StarTeam可以與VSS和PVCS庫進行集成,這對于遺留系統(tǒng)來說是非常有用處的,這些遺留系統(tǒng)仍 然可以與當前的 CM系統(tǒng)一起協(xié)同運行,這樣,你將仍然可以使用已有的構(gòu)建過程,而這些文件來自何 處到底是 StarTeam ,還是VSS或PVCS對用戶來說是透明的.這

19、樣,系統(tǒng)就可以被逐步地根據(jù)需要 被移植過來,從而使得由于使用新技術(shù)所帶來的影響最小化了.StarTeam可以與許多其他產(chǎn)品進行集成,一個新的集成可以很容易地使用SDK創(chuàng)立出來.客戶端與效勞器之間的通訊采用開放標準的TCP/IP協(xié)議,并且傳輸過程可以壓縮和加密.StarTeamMPX 組件將 StarTeam 帶入了支持分布式開發(fā)的領(lǐng)域.StarTeamMPX 是 EnterpriseAdvantage版的組成局部.它為 StarTeam效勞器提供了一個發(fā)布/訂閱方式的消息架構(gòu).通過對客戶機/效勞器框架進行擴展,StarTeamMPX加速了信息在客戶端和效勞器之間的傳輸速率.通過使用高級客戶 端緩存,事件被實時地發(fā)布到客戶端.通過自動將最新的信息傳遞給用戶,使用戶對數(shù)據(jù)的訪問更快速, 同時也由于本地緩存的使用,消除了大量的與效勞器之間的通信,由