配置管理流程(整理)

1、一 流程圖制定配置管理計劃DEVSIOCMOCCBPM批準并發(fā)布配置管理計劃制定項目計劃發(fā)布版本審核劃定（變更）基線審核配置管理計劃制定訪問控制和開發(fā)策略配置（維護）工作空間創(chuàng)建（維護）附加元素創(chuàng)建配置管理庫建立發(fā)布版本申請基線變更構建系統建立基線歸并集成更新工作空間提交工作成果修改文件建立私有工作空間1） PM：項目經理（Project Manager)是負責項目管理的專業(yè)人員，項目經理負責一個項目的計劃，執(zhí)行及結束關閉。目前，項目經理管理角色在多種行業(yè)中得到應用，尤其是在建筑、網絡技術、通信、軟件開發(fā)等行業(yè)發(fā)揮積極而重要的作用。項目經理的主要對項目目標的完成負責。項目目標包括項目的項目范圍

2、，成本，進度，質量，溝通等多維目標，項目經理通過專業(yè)努力，組織團隊按項目要求，在一定的時間內完成項目規(guī)定的任務。PMI（The Project Management Institute）討論和制定了一套有關項目管理的原則和方法論，形成一套專業(yè)的指導體系，強有力地支持了項目經理的專業(yè)化發(fā)展。從從業(yè)角度，項目經理有時會獲得企業(yè)法人代表或項目擁有者的授權，在工程項目中全面負責，成為企業(yè)法定代表或項目擁有者在工程項目上的代表人。2） CCB：CCB變更控制委員會(Change Control Board)又名配置控制委員會(Configuration Control Board)實施整體變更控制變更控

3、制委員會軟件開發(fā)活動中公認變更控制委員會為最好的策略之一CCB的組成CCB可以由一個小組擔任，也可以由多個不同的組擔任，負責做出決定究竟將哪些已建議需求變更或新產品特性付諸應用。典型的變更控制委員會會同樣決定在哪一些版本中糾正哪些錯誤。CCB的成員應當能代表變更涉及的團體。其可能包括如下方面的代表：1.產品或計劃管理部門2.項目管理部門3.開發(fā)部門4.測試或質量保證部門5.市場部或客戶代表6.制作用戶文檔的部門7.技術支持部門8.幫助桌面或用戶支持熱線部門9.配置管理部門當組建包含軟硬件兩方面項目的CCB時，還應當包含來自硬件工程、系統工程、制造部門或者硬件質量保證和配置管理的代表。CCB是系

4、統集成項目的所有者權益代表，負載裁定接受那些變更。CCB由項目所涉及的多方成員共同組成，通常包括用戶和實施方的決策人員。CCB是決策機構，不是作業(yè)機構，通常CCB的工作是通過評審手段來決定項目是否能變更，單不提出變更方案。CCB的作用1、批準配置項的標識，以及信息系統的基線建立2、制定訪問控制策略 3、建立更改基線的設置，審核變更申請4、 根據配置管理員的報告決定相應的對策3） CMO：Configuration Management Officer，配置管理員根據配置管理計劃執(zhí)行各項管理任務，定期向CCB提交報告，并列席CCB的例會。其具體職責為以下幾項：文件配置管理工具的日常管理與維護；各

5、配置項的管理與維護；執(zhí)行版本控制和變更控制方案；完成配置審計并提交報告；對開發(fā)人員進行相關的培訓；識別軟件開發(fā)過程中存在的問題并擬就解決方案；4） SIO：System Integration Officer，系統集成員系統及成員負責生產和管理項目的內部和外部發(fā)布版本，其具體職責為以下幾項：集成修改；構建系統；完成對版本的日常維護；建立外部發(fā)布版本。5） DEV：Developer，開發(fā)人員開發(fā)人員的職責就是根據組織內確定的軟件配置管理計劃和相關規(guī)定，按照軟件配置管理工具的使用模型來完成開發(fā)任務。6） 基線（Baseline）在配置管理系統中，基線就是一個CI或一組CIs在其生命周期的不同時間

6、點上通過正式評審而進入正式受控的一種狀態(tài)，些配置項構成了一個相對穩(wěn)定的邏輯實 體，而這個過程被稱為“基線化”。每一個基線都是其下一步開發(fā)的出發(fā)點和參考點。基線確定了元素（配置項）的一個版本，且只確定一個版本。一般情況下，基 線一般在指定的里程碑（Milestone）處創(chuàng)建，并與項目中的里程碑保持同步。每個基線都將接受配置管理的嚴格控制，基線中的配置項被“凍結”了，不 能再被任何人隨意修改，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發(fā)階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線?；€的主要屬性有：名稱、標識符、版本、日期等。通常將交付給客戶的基線稱為一個“Relea

7、se”，為內部開發(fā)用的基線則稱為一個“Build”。建立基線的好處：1) 重現性：及時返回并重新生成軟件系統給定發(fā)布版的能力，或者是在項目中的早些時候重新生成開發(fā)環(huán)境的能力。當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。2) 可追蹤性：建立項目工件之間的前后繼承關系。目的是確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執(zhí)行文件。3) 版本隔離：基線為開發(fā)工件提供了一個定點和快照，新項目可以從基線提供的定點之中建立。作為一個單獨分支，新項目將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。二 配置管理中可能涉及的文檔：1） 項目管理過程文檔：a） 項目任務書；b） 項目

8、計劃；c） 項目周報；d） 個人日報和周報；e） 項目會議記錄；f） 培訓記錄和培訓文檔.2） QA過程文檔:a） QA不符合報告；b） QA周報c） 評審記錄.3） 工作產品：a） 需求文檔：b） 設計文檔：c） 代碼：d） 測試文檔：e） 軟件說明書和手冊.4） 項目中使用的第三方產品：一個工程型的項目會大量使用第三方軟件，對這些產品的管理至少可以解決三個方面的問題：a） 版本配合的問題：大部分的第三方軟件在升級之后，并不能實現二進制層面上的兼容，需要對原有的代碼進行重新編譯；甚至有的第三方軟件在升級之后，API層面上的兼容性都做不到；因此，在工程實施的過程中，版本的配合問題是一個需要關注

9、的問題，。b） 發(fā)布的完整性問題：一般來說，比較大型的第三方軟件在發(fā)布過程中都不會有遺漏，但對于一些小的第三方軟件來說，如果在開發(fā)過程中沒有意識到進行管理的話，很容易發(fā)生遺漏。c） 在某些特殊條件下由第三方軟件的變化引起的基線變更。5） 版本命名規(guī)范，詳見“版本命名規(guī)范.docx”。三 配置管理實施細則： 3.1CCB的成立3.1.1項目在設計發(fā)布后，由項目經理負責組織成立CCB。3.1.2CCB成員組成CCB成員人數一般為奇數，人數在37人范圍內。CCB成員一般包括：1) 項目經理PM；2) 配置管理員CMO；3) SQA；4) 測試人員Tester；5) 顧客代表；6) 主要開發(fā)人員等。3

10、.1.3CCB的決策機制尋求CCB成員的一致意見。若不能達成一致，可采取由顧客代表做出決策；或采取少數服從多數的原則，由CCB成員投票確定，投票超過半數即為通過。3.2確定配置策略3.2.1配置策略確定的時機CCB成立后，由CCB組織會議根據項目的開發(fā)計劃確定各個里程碑和開發(fā)策略，CMO負責整理確定的項目基線和配置項列表，并在編制配置管理計劃時列明，按約定的時機收集配置項和建立初始基線。3.2.2配置項的范圍1) 技術文檔（Documents）：項目開發(fā)計劃、需求分析報告、軟件設計書、質量保證計劃、概要設計書、詳細設計書、測試文檔、技術報告、用戶手冊、總結報告等；2) 程序（Program）：

11、階段產品、計算機程序、源程序、釋放產品等；3) 工具（Tools）：自動設計工具、開發(fā)工具、測試工具、維護工具等；4) 交互文檔（Communications）：與客戶或項目組內交互產生文檔，如會談記錄、E-mail、會議紀要、MSN記錄等。3.3制定配置管理計劃3.3.1配置管理計劃的編制通常情況下，由CMO在設計發(fā)布后，開始編制配置管理計劃；如有特殊需要，根據合同或項目要求，由CMO在某一項目或項目的某一階段開始前制定配置管理計劃。3.3.2配置管理計劃的內容配置管理計劃應包括以下方面的內容：1) 該項目對配置管理的要求；2) 實施配置管理的責任人、組織及其職責；3) 需要開展的配置管理活

12、動及其進度安排；4) 采用的方法和工具等。3.3.3配置管理計劃的由CCB負責審批。3.4配置項標識規(guī)則3.4.1配置項標識要求1) 合同有明確標識和追蹤要求時，由開發(fā)人員按合同要求進行標識，以保證滿足合同追蹤要求。2) 在開發(fā)過程中項目組人員提交的配置項，由項目組人員按照本節(jié)相關部分標識規(guī)則進行標識。3) 項目組人員將要標識或已標識的配置項提交給CMO納入配置庫統一管理，并填寫配置狀態(tài)報告。3.4.2配置項標識方式3.4.2.1標識項配置項標識屬性包括：名稱、編號、文件狀態(tài)、版本、作者、日期等。本文標識規(guī)則對名稱、編號、文件狀態(tài)和版本進行了描述和規(guī)定。3.4.2.2名稱文件名稱的標識按文檔模

13、板中統一名稱為準。a) 編號文檔編號格式為CC_XXX_*_$_#，其中CC表示公司，XXX是項目的三位英文字母縮寫表示，*_$表示文檔類 別，#表示文檔順序號。同時對應每個內容都有固定的一個索引文件CC_XXX_*_$_index，目的是為了為本類別下的文件建立一個概要說 明列表，保證快速對文檔進行識別和檢索。3.4.2.3文件狀態(tài)文件狀態(tài)分為“草稿”、“正式發(fā)布”和“修改中”三種。修改處于“草稿”狀態(tài)的配置項不算是“變更”，無需CCB的批準，修改者按照版本控制規(guī)則執(zhí)行即可。當配置項的狀態(tài)成為“正式發(fā)布”，或者被“凍結”后，此時任何人都不能隨意修改，必須依據配置變更控制的規(guī)則執(zhí)行。3.4.2

14、.4文檔版本控制對于計劃性文檔、技術文檔和用戶文檔，其版本按修改的先后順序確定。新生成的文檔第一次發(fā)行為第一版，修改后第二次發(fā)行為第二版，以此類推。3.4.2.5發(fā)行版本控制最終完成的軟件版本用三位符號表示：“s.x.y”。各符號位的含義如下：1) “y”為第二次版本號，表示糾正錯誤時的版本升級，用一位數字表示：“19”，對上一次產品或項目中的缺陷做修正，第二次版本號增加；2) “x”為第一次版本號，表示增加功能時的版本升級，用一位數字表示：“09”。與上一產品或項目相比，功能進行了小量的增加或修正時，第一次版本號增加，第二次版本號為零，第二版本號為零時可以省略不寫；3) “s”為主版本號。對

15、產品作重大調整，或與已發(fā)行的上一產品相比，在功能與性能上有較大改善時主版本號增加；產品或項目概念全新，第一次完成，版本號為1.0。3.4.2.6基線版本標識內部基線，如計劃基線、設計基線等，在版本號前加Build，如Build 1.0；發(fā)行產品基線在版本號前加Release，如Release 2.0。3.5配置庫管理3.5.1配置庫（Repository）的分類配置庫分為兩類：1) 文檔庫（Document Library）：由CMO負責管理，主要使用eSM系統管理除程序以外的文檔資料（包括圖片等）；2) 程序庫（Program Library）：由PL負責管理，主要使用CVS版本工具對程序代

16、碼進行管理。3.5.2配置庫的建立3.5.2.1CCB成立之后，PL即可著手組織建立配置庫。所有項目應建立配置庫，以便管理各配置項。3.5.2.2文檔庫空間由eSM系統創(chuàng)建，PL僅創(chuàng)建基線文檔庫，僅PL可以對其操作。3.5.2.3程序庫主要通過設置版本的分支，來實現對配置項權限管理，基本上要為每個配置項從建立開始就劃分成3個不同的分支（如圖1）：圖1配置庫空間分配和版本遷移策略1) 私有分支（Private Branch）：私有分支對應的是開發(fā)人員的私有開發(fā)空間。開發(fā)人員根據任務分工獲得對相應配置項的操作許可之后，他即在自己的私有開發(fā)分支上工作，他的 所有工作成果體現為在該配置項的私有分支上的

17、版本的推進，除該開發(fā)人員外，其他人員均無權操作該私有空間中的元素。2) 集成分支（Integration Branch）：集成分支對應的是開發(fā)團隊的公共空間。凡是要為同組人員共享的配置項都從該分支獲得。即各開發(fā)人員必須將私有工作空間中的開發(fā)成果歸并 （Merge）到該分支后才能進入下一個開發(fā)活動。所有涉及多人協調的開發(fā)工作（如集成測試等）都必須工作在這一空間中。該開發(fā)團隊擁有對該集成分支的讀 寫權限，而其他成員只有只讀權限。該分支的管理工作由PL及相關指定人員負責。3) 公共分支（Common Branch）：公共分支對應的是整個軟件開發(fā)組織的公共空間。各個開發(fā)小組在現階段的任務完成后，將可以

18、發(fā)布的版本歸并到該分支上，將來需要查閱相關資 料時，以該分支上的版本為準。該分支對組織內的全體軟件人員開放只讀權限。該分支的管理工作由PL負責。3.5.2.4上述定義的3類分支以及文檔庫由CMO統一管理，根據各開發(fā)階段的實際情況定制相應的版本選取規(guī)則，來保證開發(fā)活動的正常運作。在變更發(fā)生時，應及時做好基線的推進。3.5.3分配權限PL為每個項目成員分配配置庫操作權限。一般地，項目成員擁有Add、 Checkin/Checkout、Download等權限，但是不能擁有“刪除”權限。PL的權限最高。3.5.4配置庫的操作與管理3.5.4.1開發(fā)人員根據獲得的授權的資源進行項目的研發(fā)工作，操作配置庫

19、，例如Add、Checkin/Checkout、Download等。3.5.4.2PL根據配置管理計劃創(chuàng)建與維護基線，“凍結”配置項，控制變更。3.5.4.3配置庫的檢出當發(fā)生變更且變更評審通過后，或者發(fā)現Bug且Bug評審通過后，由PL將Common Branch中CIs檢出至開發(fā)人員的Private Branch上，供開發(fā)人員進行變更。3.5.4.4配置庫的檢入當變更實施結束或Bug修正和測試結束，并通過配置審核后，由PL將變更后的CIs檢入到Common Branch。3.5.4.5PL定期清除配置庫里的垃圾文件。3.5.4.6PL定期備份配置庫。3.6配置項和基線管理3.6.1CMO根

20、據配置管理計劃，對配置項和基線進行分階段管理。3.6.2項目啟動配置項包括需求說明、訂單及其評審結果等；項目發(fā)布后應封鎖該子項目，建立發(fā)布基線。3.6.3需求分析系統調研后開發(fā)人員進行系統分析，并整理需求分析報告。需求分析報告通過評審并需取得客戶的確定。在需求分析報告取得客戶的確認后，封鎖該子項目，建立需求基線。如需升版則必須通過評審并得到客戶的確認。3.6.4項目計劃需求分析完成后即可制定項目的開發(fā)計劃，包括項目總體進度說明、進度跟蹤、計劃修改、配置管理計劃、質量保證計劃、測試計劃等。項目開發(fā)計劃評審通過后，封鎖該子項目，建立項目計劃基線。3.6.5系統設計系統設計可分為概要設計、詳細設計和

21、數據庫設計等部分。針對需求分析報告進行系統設計，配置時應說明系統設計的版本與需求分析報告版本的對應關系。設計書評審通過后，建立設計基線。3.6.6編碼編碼按功能模塊分子項目，即每個模塊計作一個配置項。代碼基線分別在單元測試結束后建立Alpha版，Alpha測試后建立Beta版，在集成測試時建立Merge后版。3.6.7測試各測試階段應提供測試計劃、測試用例、測試結果和測試分析報告，項目啟動后應提供項目測試計劃書，項目驗收結束后應提交項目測試總結報告等。配置時應說明測試的版本與編碼版本的對應關系。各階段測試（如單元測試、集成測試）完成后建立測試基線。3.6.8交付與驗收在交付前配置審核完成后建立

22、產品基線，產品基線包含程序以及有關文檔配置項，包括交付施工文檔、工具等。3.6.9項目總結項目總結應經過部門內部評審，包括項目質量報告、測試報告等。3.6.10相關資料與培訓相關資料與培訓也應作為配置項納入配置管理，此部分包括：1) 相關法律、法規(guī)；2) 必須遵照或項目組約定的技術規(guī)范；3) 與客戶或項目組內部重要的交互信息記錄，如Question Sheet、會議記錄、會談記錄、e-mail和MSN記錄；4) 必要的業(yè)務或技術培訓等。3.7配置變更控制3.7.1變更的分類軟件及其相關文檔的變更按照變更的影響范圍進行分類：1) A級：變更會影響系統級需求、外部接口、產品價格或者交付期；這類變更

23、必須經過CCB審核并有客戶批準和確認。2) B級：變更會影響配置項間的功能接口、組件級成本或者項目Schedule；這類變更必須由CCB或上級管理部門的批準和認可。3) C級：變更會影響配置項內部功能的設計和分配；這類變更可以由配置項的管理人員負責批準。圖2 變更控制流程3.7.2變更請求的提出3.7.2.1由發(fā)起者（客戶、最終用戶或開發(fā)部門）確定變更，填寫變更請求/評審單，描述變更原因和變更內容，并提交給CMO。3.7.2.2CMO對填寫的申請表是否清晰、明確和完整性進行審查，若CMO發(fā)現變更不明確或不完整，應返回申請表給發(fā)起者。CMO對通過審查的變更申請分配變更ID，以便跟蹤和記錄變更信息

24、。3.7.3變更評估3.7.3.1CMO將變更請求/評審單發(fā)送給項目經理（或者其他授權人員），由項目經理負責對變更進行評估。3.7.3.2變更控制的一個重要環(huán)節(jié)就是變更評估，變更評估要分析每個變更對系統功能、接口、成本、進度以及約定需求的影響，同時還要分析對軟件安全性、可靠性、可維護性、可移植性和性能的影響。3.7.3.3變更評估產生的文檔應描述若實施變更必須變更的配置項、文檔和資源；變更評估文檔在完成變更評估后發(fā)送給CMO。3.7.3.4CMO收到評估后的變更請求/評審單后，更新變更記錄，并安排CCB會議日程。3.7.4變更審核3.7.4.1CCB對提交的變更申請進行審核，并根據變更評估確定

25、變更的影響級別；CCB審核可能的結果有三種：接受變更；拒絕變更；延期變更。CCB也可能需要更多的變更分析的信息。3.7.4.2CCB批準的變更，由CMO將變更項目發(fā)送到指定的開發(fā)人員（Assigner）進行下一步的實施變更工作；對于拒絕的變更， 由CMO將CCB拒絕變更的原因發(fā)送給發(fā)起者，并保存變更請求/評審單，更新變更記錄，關閉變更活動；需要進一步分析的，由CMO將變更項目隨同 CCB的Question Sheet發(fā)送給評估分析人員；對于延期的變更，由CMO對變更的相關文檔進行歸檔，以便在適當時機提交CCB審核。3.7.4.3CMO負責整理CCB會議記錄，填寫變更請求/評審單中相應審核項；更

26、新變更記錄，如果是接受變更，還需將要變更的CIs狀態(tài)改為“修改中”；將變更文檔分發(fā)給相關人員。3.7.5變更實施3.7.5.1變更被批準后，PL負責將要變更的CIs以及相關文檔遷移至變更負責人的Private Branch上，由變更負責人開始實施變更，并詳細記錄變更的內容；項目管理部門要對變更的實施進行跟蹤。3.7.5.2對于代碼變更，必須修改設計、代碼、測試以及變更正確性的驗證。而且與變更相關的文檔必須修訂，以反映變更。當變更以及測試完成后，進行Merge。3.7.5.3對于開發(fā)計劃、配置管理計劃發(fā)生變更的，項目組人員要按照變更過的開發(fā)計劃、配置管理計劃提交配置項。3.7.6變更確認3.7.

27、6.1變更后的程序Merge后必需經過測試組進行回歸測試，以確保變更沒有引入新的Bug。不會引起程序變更的文檔（如計劃文檔）的變更不需經過測試。3.7.6.2通過Merge后測試后，SQA需對變更進行審核，審核的范圍一般涉及以下方面：1) 測試記錄；2) 變更請求；3) 配置項的檢入及檢出；5) 文件的命名；6) 版本的編號。3.7.6.3SQA審核后，開發(fā)人員才能生成新的版本，由PL更新到基線庫中。3.7.6.4PL應重新標識所有被影響的配置項及版本。3.7.6.5A級和B級的變更項也可能直到下次系統發(fā)行版本時才生成。3.7.6.6生成新版本后，CMO負責收集所有變更信息歸檔，修改變更CIs

28、狀態(tài)為“正式發(fā)布”，關閉變更，并將變更報告發(fā)送給發(fā)起者。3.8配置狀態(tài)報告3.8.1配置狀態(tài)報告的目的記錄和報告整個軟件生命周期演化狀態(tài)。3.8.2配置狀態(tài)報告記錄的內容配置狀態(tài)報告記錄的內容包括：2) 軟件和文檔的標識；3) 目前狀態(tài)；4) 基線演化狀態(tài)；5) 變更狀態(tài)；6) 版本交付信息等。3.8.3配置狀態(tài)報告的生成配置管理報告自第一個基線創(chuàng)建時建立，由配置管理系統生成，及時反映當前配置狀態(tài)。3.9配置審核3.9.1配置審核的類別配置審核分為：1) 功能配置審核（Functional Configuration Audit，FCA）：審核軟件功能是否與需求一致，并符合基線文檔要求；通常要審查測試方法、流程、報告和設計文檔等。2) 物理配置審核（Physical Configu