1)PM：項(xiàng)目經(jīng)理(ProjectManager)是負(fù)責(zé)項(xiàng)目管理的專業(yè)人員，項(xiàng)目經(jīng)理負(fù)責(zé)一個(gè)項(xiàng)目的計(jì)劃，執(zhí)行及結(jié)束關(guān)閉。目前，項(xiàng)目經(jīng)理管理角色在多種行業(yè)中得到應(yīng)用，尤其是在建筑、網(wǎng)絡(luò)技術(shù)、通信、軟件開發(fā)等行業(yè)發(fā)揮積極而重要的作用。項(xiàng)目經(jīng)理的主要對(duì)項(xiàng)目目標(biāo)的完成負(fù)責(zé)。項(xiàng)目目標(biāo)包括項(xiàng)目的項(xiàng)目范圍，成本，進(jìn)度，質(zhì)量，溝通等多維目標(biāo)，項(xiàng)目經(jīng)理通過專業(yè)努力，組織團(tuán)隊(duì)按項(xiàng)目要求，在一定的時(shí)間內(nèi)完成項(xiàng)目規(guī)定的任務(wù)。PMI(TheProjectManagementInstitute)討論和制定了一套有關(guān)項(xiàng)目管理的原則和方法論，形成一套專業(yè)的指導(dǎo)體系，強(qiáng)有力地支持了項(xiàng)目經(jīng)理的專業(yè)化發(fā)展。從從業(yè)角度，項(xiàng)目經(jīng)理有時(shí)會(huì)獲得企業(yè)法人代表或項(xiàng)目擁有者的授權(quán)，在工程項(xiàng)目中全面負(fù)責(zé)，成為企業(yè)法定代表或項(xiàng)目擁有者在工程項(xiàng)目上的代表人。CCB：CCB變更控制委員會(huì)(ChangeControlBoard)又名配置控制委員會(huì)(ConfigurationControlBoard)實(shí)施整體變更控制——變更控制委員會(huì)軟件開發(fā)活動(dòng)中公認(rèn)變更控制委員會(huì)為最好的策略之一CCB的組成CCB可以由一個(gè)小組擔(dān)任，也可以由多個(gè)不同的組擔(dān)任，負(fù)責(zé)做出決定究竟將哪些已建議需求變更或新產(chǎn)品特性付諸應(yīng)用。典型的變更控制委員會(huì)會(huì)同樣決定在哪一些版本中糾正哪些錯(cuò)誤。CCB的成員應(yīng)當(dāng)能代表變更涉及的團(tuán)體。其可能包括如下方面的代表：產(chǎn)品或計(jì)劃管理部門項(xiàng)目管理部門開發(fā)部門測(cè)試或質(zhì)量保證部門市場(chǎng)部或客戶代表制作用戶文檔的部門技術(shù)支持部門幫助桌面或用戶支持熱線部門配置管理部門當(dāng)組建包含軟硬件兩方面項(xiàng)目的CCB時(shí)，還應(yīng)當(dāng)包含來自硬件工程、系統(tǒng)工程、制造部門或者硬件質(zhì)量保證和配置管理的代表。CCB是系統(tǒng)集成項(xiàng)目的所有者權(quán)益代表，負(fù)載裁定接受那些變更。CCB由項(xiàng)目所涉及的多方成員共同組成，通常包括用戶和實(shí)施方的決策人員。CCB是決策機(jī)構(gòu)，不是作業(yè)機(jī)構(gòu)，通常CCB的工作是通過評(píng)審手段來決定項(xiàng)目是否能變更，單不提出變更方案。CCB的作用1、 批準(zhǔn)配置項(xiàng)的標(biāo)識(shí)，以及信息系統(tǒng)的基線建立2、 制定訪問控制策略3、 建立更改基線的設(shè)置，審核變更申請(qǐng)4、 根據(jù)配置管理員的報(bào)告決定相應(yīng)的對(duì)策3)CMO：ConfigurationManagementOfficer，配置管理員根據(jù)配置管理計(jì)劃執(zhí)行各項(xiàng)管理任務(wù)，定期向CCB提交報(bào)告，并列席CCB的例會(huì)。其具體職責(zé)為以下幾項(xiàng)：文件配置管理工具的日常管理與維護(hù)；各配置項(xiàng)的管理與維護(hù)；執(zhí)行版本控制和變更控制方案；完成配置審計(jì)并提交報(bào)告；對(duì)開發(fā)人員進(jìn)行相關(guān)的培訓(xùn)；識(shí)別軟件開發(fā)過程中存在的問題并擬就解決方案；4)SIO:SystemIntegrationOfficer，系統(tǒng)集成員系統(tǒng)及成員負(fù)責(zé)生產(chǎn)和管理項(xiàng)目的內(nèi)部和外部發(fā)布版本，其具體職責(zé)為以下幾項(xiàng)：集成修改；構(gòu)建系統(tǒng)；完成對(duì)版本的日常維護(hù)；建立外部發(fā)布版本。DEV：Developer,開發(fā)人員開發(fā)人員的職責(zé)就是根據(jù)組織內(nèi)確定的軟件配置管理計(jì)劃和相關(guān)規(guī)定，按照軟件配置管理工具的使用模型來完成開發(fā)任務(wù)?；€(Baseline)在配置管理系統(tǒng)中，基線就是一個(gè)CI或一組Cis在其生命周期的不同時(shí)間點(diǎn)上通過正式評(píng)審而進(jìn)入正式受控的一種狀態(tài)，些配置項(xiàng)構(gòu)成了一個(gè)相對(duì)穩(wěn)定的邏輯實(shí)體，而這個(gè)過程被稱為“基線化”。每一個(gè)基線都是其下一步開發(fā)的出發(fā)點(diǎn)和參考點(diǎn)。基線確定了元素(配置項(xiàng))的一個(gè)版本，且只確定一個(gè)版本。一般情況下，基線一般在指定的里程碑(Milestone)處創(chuàng)建，并與項(xiàng)目中的里程碑保持同步。每個(gè)基線都將接受配置管理的嚴(yán)格控制，基線中的配置項(xiàng)被“凍結(jié)”了，不能再被任何人隨意修改，對(duì)其的修改將嚴(yán)格按照變更控制要求的過程進(jìn)行，在一個(gè)軟件開發(fā)階段結(jié)束時(shí)，上一個(gè)基線加上增加和修改的基線內(nèi)容形成下一個(gè)基線?；€的主要屬性有：名稱、標(biāo)識(shí)符、版本、日期等。通常將交付給客戶的基線稱為一個(gè)"Release”，為內(nèi)部開發(fā)用的基線則稱為一個(gè)"Build”。建立基線的好處：重現(xiàn)性：及時(shí)返回并重新生成軟件系統(tǒng)給定發(fā)布版的能力，或者是在項(xiàng)目中的早些時(shí)候重新生成開發(fā)環(huán)境的能力。當(dāng)認(rèn)為更新不穩(wěn)定或不可信時(shí)，基線為團(tuán)隊(duì)提供一種取消變更的方法?？勺粉櫺裕航㈨?xiàng)目工件之間的前后繼承關(guān)系。目的是確保設(shè)計(jì)滿足要求、代碼實(shí)施設(shè)計(jì)以及用正確代碼編譯可執(zhí)行文件。版本隔離：基線為開發(fā)工件提供了一個(gè)定點(diǎn)和快照，新項(xiàng)目可以從基線提供的定點(diǎn)之中建立。作為一個(gè)單獨(dú)分支，新項(xiàng)目將與隨后對(duì)原始項(xiàng)目(在主要分支上)所進(jìn)行的變更進(jìn)行隔離。二．配置管理中可能涉及的文檔：項(xiàng)目管理過程文檔：項(xiàng)目任務(wù)書；項(xiàng)目計(jì)劃；項(xiàng)目周報(bào)；個(gè)人日?qǐng)?bào)和周報(bào)；項(xiàng)目會(huì)議記錄；培訓(xùn)記錄和培訓(xùn)文檔.QA過程文檔:QA不符合報(bào)告；QA周報(bào)評(píng)審記錄.工作產(chǎn)品：需求文檔：設(shè)計(jì)文檔：代碼：測(cè)試文檔：軟件說明書和手冊(cè).項(xiàng)目中使用的第三方產(chǎn)品：一個(gè)工程型的項(xiàng)目會(huì)大量使用第三方軟件，對(duì)這些產(chǎn)品的管理至少可以解決三個(gè)方面的問題：a)版本配合的問題：大部分的第三方軟件在升級(jí)之后，并不能實(shí)現(xiàn)二進(jìn)制層面上的兼容，需要對(duì)原有的代碼進(jìn)行重新編譯；甚至有的第三方軟件在升級(jí)之后，API層面上的兼容性都做不到；因此，在工程實(shí)施的過程中，版本的配合問題是一個(gè)需要關(guān)注的問題，。發(fā)布的完整性問題：一般來說，比較大型的第三方軟件在發(fā)布過程中都不會(huì)有遺漏，但對(duì)于一些小的第三方軟件來說，如果在開發(fā)過程中沒有意識(shí)到進(jìn)行管理的話，很容易發(fā)生遺漏。在某些特殊條件下由第三方軟件的變化引起的基線變更。版本命名規(guī)范，詳見“版本命名規(guī)范.docx”三．配置管理實(shí)施細(xì)則：CCB的成立項(xiàng)目在設(shè)計(jì)發(fā)布后，由項(xiàng)目經(jīng)理負(fù)責(zé)組織成立CCB。CCB成員組成CCB成員人數(shù)一般為奇數(shù)，人數(shù)在3?7人范圍內(nèi)。CCB成員一般包括：項(xiàng)目經(jīng)理PM；配置管理員CMO；SQA；測(cè)試人員Tester；顧客代表；主要開發(fā)人員等。CCB的決策機(jī)制尋求CCB成員的一致意見。若不能達(dá)成一致，可采取由顧客代表做出決策；或采取少數(shù)服從多數(shù)的原則，由CCB成員投票確定，投票超過半數(shù)即為通過。確定配置策略配置策略確定的時(shí)機(jī)CCB成立后，由CCB組織會(huì)議根據(jù)項(xiàng)目的開發(fā)計(jì)劃確定各個(gè)里程碑和開發(fā)策略，CMO負(fù)責(zé)整理確定的項(xiàng)目基線和配置項(xiàng)列表，并在編制《配置管理計(jì)劃》時(shí)列明，按約定的時(shí)機(jī)收集配置項(xiàng)和建立初始基線。配置項(xiàng)的范圍技術(shù)文檔(Documents):項(xiàng)目開發(fā)計(jì)劃、需求分析報(bào)告、軟件設(shè)計(jì)書、質(zhì)量保證計(jì)劃、概要設(shè)計(jì)書、詳細(xì)設(shè)計(jì)書、測(cè)試文檔、技術(shù)報(bào)告、用戶手冊(cè)、總結(jié)報(bào)告等；程序(Program):階段產(chǎn)品、計(jì)算機(jī)程序、源程序、釋放產(chǎn)品等；工具(Tools):自動(dòng)設(shè)計(jì)工具、開發(fā)工具、測(cè)試工具、維護(hù)工具等；交互文檔(Communications)：與客戶或項(xiàng)目組內(nèi)交互產(chǎn)生文檔，如會(huì)談?dòng)涗洝-mail、會(huì)議紀(jì)要、MSN記錄等。制定配置管理計(jì)劃《配置管理計(jì)劃》的編制通常情況下，由CMO在設(shè)計(jì)發(fā)布后，開始編制《配置管理計(jì)劃》；如有特殊需要，根據(jù)合同或項(xiàng)目要求，由CMO在某一項(xiàng)目或項(xiàng)目的某一階段開始前制定《配置管理計(jì)劃》?！杜渲霉芾碛?jì)劃》的內(nèi)容《配置管理計(jì)劃》應(yīng)包括以下方面的內(nèi)容:該項(xiàng)目對(duì)配置管理的要求；實(shí)施配置管理的責(zé)任人、組織及其職責(zé)；需要開展的配置管理活動(dòng)及其進(jìn)度安排；采用的方法和工具等。3.3.3《配置管理計(jì)劃》的由CCB負(fù)責(zé)審批。配置項(xiàng)標(biāo)識(shí)規(guī)則配置項(xiàng)標(biāo)識(shí)要求合同有明確標(biāo)識(shí)和追蹤要求時(shí)，由開發(fā)人員按合同要求進(jìn)行標(biāo)識(shí)，以保證滿足合同追蹤要求。在開發(fā)過程中項(xiàng)目組人員提交的配置項(xiàng)，由項(xiàng)目組人員按照本節(jié)相關(guān)部分標(biāo)識(shí)規(guī)則進(jìn)行標(biāo)識(shí)。項(xiàng)目組人員將要標(biāo)識(shí)或已標(biāo)識(shí)的配置項(xiàng)提交給CMO納入配置庫(kù)統(tǒng)一管理，并填寫《配置狀態(tài)報(bào)告》。配置項(xiàng)標(biāo)識(shí)方式標(biāo)識(shí)項(xiàng)配置項(xiàng)標(biāo)識(shí)屬性包括：名稱、編號(hào)、文件狀態(tài)、版本、作者、日期等。本文標(biāo)識(shí)規(guī)則對(duì)名稱、編號(hào)、文件狀態(tài)和版本進(jìn)行了描述和規(guī)定。名稱文件名稱的標(biāo)識(shí)按文檔模板中統(tǒng)一名稱為準(zhǔn)。a)編號(hào)文檔編號(hào)格式為CC_XXX_***_$$$_###，其中CC表示公司，XXX是項(xiàng)目的三位英文字母縮寫表示，***_$$$表示文檔類別，###表示文檔順序號(hào)。同時(shí)對(duì)應(yīng)每個(gè)內(nèi)容都有固定的一個(gè)索引文件CC_XXX_**_$$$_index,目的是為了為本類別下的文件建立一個(gè)概要說明列表，保證快速對(duì)文檔進(jìn)行識(shí)別和檢索。文件狀態(tài)文件狀態(tài)分為“草稿”、“正式發(fā)布”和“修改中”三種。修改處于“草稿”狀態(tài)的配置項(xiàng)不算是“變更”，無需CCB的批準(zhǔn)，修改者按照版本控制規(guī)則執(zhí)行即可。當(dāng)配置項(xiàng)的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)”后，此時(shí)任何人都不能隨意修改，必須依據(jù)配置變更控制的規(guī)則執(zhí)行。文檔版本控制對(duì)于計(jì)劃性文檔、技術(shù)文檔和用戶文檔，其版本按修改的先后順序確定。新生成的文檔第一次發(fā)行為第一版，修改后第二次發(fā)行為第二版，以此類推。發(fā)行版本控制最終完成的軟件版本用三位符號(hào)表示：“s.x.y”。各符號(hào)位的含義如下:“y”為第二次版本號(hào)，表示糾正錯(cuò)誤時(shí)的版本升級(jí)，用一位數(shù)字表示：“1~9”，對(duì)上一次產(chǎn)品或項(xiàng)目中的缺陷做修正，第二次版本號(hào)增加；“x”為第一次版本號(hào)，表示增加功能時(shí)的版本升級(jí)，用一位數(shù)字表示：“0~9”。與上一產(chǎn)品或項(xiàng)目相比，功能進(jìn)行了小量的增加或修正時(shí)，第一次版本號(hào)增加，第二次版本號(hào)為零，第二版本號(hào)為零時(shí)可以省略不寫；“s”為主版本號(hào)。對(duì)產(chǎn)品作重大調(diào)整，或與已發(fā)行的上一產(chǎn)品相比，在功能與性能上有較大改善時(shí)主版本號(hào)增加；產(chǎn)品或項(xiàng)目概念全新，第一次完成，版本號(hào)為1.0?；€版本標(biāo)識(shí)內(nèi)部基線，如計(jì)劃基線、設(shè)計(jì)基線等，在版本號(hào)前加Build，如Build1.0；發(fā)行產(chǎn)品基線在版本號(hào)前加Release，如Release2.0。3.5配置庫(kù)管理3.5.1配置庫(kù)(Repository)的分類配置庫(kù)分為兩類：文檔庫(kù)(DocumentLibrary):由CM0負(fù)責(zé)管理，主要使用eSM系統(tǒng)管理除程序以外的文檔資料(包括圖片等)；程序庫(kù)(ProgramLibrary):由PL負(fù)責(zé)管理，主要使用CVS版本工具對(duì)程序代碼進(jìn)行管理。配置庫(kù)的建立CCB成立之后，PL即可著手組織建立配置庫(kù)。所有項(xiàng)目應(yīng)建立配置庫(kù)，以便管理各配置項(xiàng)。3.5.2.2文檔庫(kù)空間由eSM系統(tǒng)創(chuàng)建，PL僅創(chuàng)建基線文檔庫(kù)，僅PL可以對(duì)其操作。程序庫(kù)主要通過設(shè)置版本的分支，來實(shí)現(xiàn)對(duì)配置項(xiàng)權(quán)限管理，基本上要為每個(gè)配置項(xiàng)從建立開始就劃分成3個(gè)不同的分支(如圖1)：圖1配置庫(kù)空間分配和版本遷移策略私有分支(PrivateBranch):私有分支對(duì)應(yīng)的是開發(fā)人員的私有開發(fā)空間。開發(fā)人員根據(jù)任務(wù)分工獲得對(duì)相應(yīng)配置項(xiàng)的操作許可之后，他即在自己的私有開發(fā)分支上工作，他的所有工作成果體現(xiàn)為在該配置項(xiàng)的私有分支上的版本的推進(jìn)，除該開發(fā)人員外，其他人員均無權(quán)操作該私有空間中的元素。集成分支(IntegrationBranch):集成分支對(duì)應(yīng)的是開發(fā)團(tuán)隊(duì)的公共空間。凡是要為同組人員共享的配置項(xiàng)都從該分支獲得。即各開發(fā)人員必須將私有工作空間中的開發(fā)成果歸并(Merge)到該分支后才能進(jìn)入下一個(gè)開發(fā)活動(dòng)。所有涉及多人協(xié)調(diào)的開發(fā)工作(如集成測(cè)試等)都必須工作在這一空間中。該開發(fā)團(tuán)隊(duì)擁有對(duì)該集成分支的讀寫權(quán)限，而其他成員只有只讀權(quán)限。該分支的管理工作由PL及相關(guān)指定人員負(fù)責(zé)。公共分支(CommonBranch):公共分支對(duì)應(yīng)的是整個(gè)軟件開發(fā)組織的公共空間。各個(gè)開發(fā)小組在現(xiàn)階段的任務(wù)完成后，將可以發(fā)布的版本歸并到該分支上，將來需要查閱相關(guān)資料時(shí)，以該分支上的版本為準(zhǔn)。該分支對(duì)組織內(nèi)的全體軟件人員開放只讀權(quán)限。該分支的管理工作由PL負(fù)責(zé)。上述定義的3類分支以及文檔庫(kù)由CMO統(tǒng)一管理，根據(jù)各開發(fā)階段的實(shí)際情況定制相應(yīng)的版本選取規(guī)則，來保證開發(fā)活動(dòng)的正常運(yùn)作。在變更發(fā)生時(shí)，應(yīng)及時(shí)做好基線的推進(jìn)。分配權(quán)限PL為每個(gè)項(xiàng)目成員分配配置庫(kù)操作權(quán)限。一般地，項(xiàng)目成員擁有Add、Checkin/Checkout、Download等權(quán)限，但是不能擁有“刪除”權(quán)限。PL的權(quán)限最高。配置庫(kù)的操作與管理3.5.4.1開發(fā)人員根據(jù)獲得的授權(quán)的資源進(jìn)行項(xiàng)目的研發(fā)工作，操作配置庫(kù)，例如Add、Checkin/Checkout、Download等。PL根據(jù)配置管理計(jì)劃創(chuàng)建與維護(hù)基線，“凍結(jié)”配置項(xiàng)，控制變更。配置庫(kù)的檢出當(dāng)發(fā)生變更且變更評(píng)審?fù)ㄟ^后，或者發(fā)現(xiàn)Bug且Bug評(píng)審?fù)ㄟ^后，由PL將CommonBranch中CIs檢出至開發(fā)人員的PrivateBranch上，供開發(fā)人員進(jìn)行變更。配置庫(kù)的檢入當(dāng)變更實(shí)施結(jié)束或Bug修正和測(cè)試結(jié)束，并通過配置審核后，由PL將變更后的CIs檢入到CommonBranch。PL定期清除配置庫(kù)里的垃圾文件。PL定期備份配置庫(kù)。配置項(xiàng)和基線管理CMO根據(jù)配置管理計(jì)劃，對(duì)配置項(xiàng)和基線進(jìn)行分階段管理。項(xiàng)目啟動(dòng)配置項(xiàng)包括需求說明、訂單及其評(píng)審結(jié)果等；項(xiàng)目發(fā)布后應(yīng)封鎖該子項(xiàng)目，建立發(fā)布基線。需求分析系統(tǒng)調(diào)研后開發(fā)人員進(jìn)行系統(tǒng)分析，并整理需求分析報(bào)告。需求分析報(bào)告通過評(píng)審并需取得客戶的確定。在需求分析報(bào)告取得客戶的確認(rèn)后，封鎖該子項(xiàng)目，建立需求基線。如需升版則必須通過評(píng)審并得到客戶的確認(rèn)。項(xiàng)目計(jì)劃需求分析完成后即可制定項(xiàng)目的開發(fā)計(jì)劃，包括項(xiàng)目總體進(jìn)度說明、進(jìn)度跟蹤、計(jì)劃修改、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、測(cè)試計(jì)劃等。項(xiàng)目開發(fā)計(jì)劃評(píng)審?fù)ㄟ^后，封鎖該子項(xiàng)目，建立項(xiàng)目計(jì)劃基線。系統(tǒng)設(shè)計(jì)系統(tǒng)設(shè)計(jì)可分為概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)和數(shù)據(jù)庫(kù)設(shè)計(jì)等部分。針對(duì)需求分析報(bào)告進(jìn)行系統(tǒng)設(shè)計(jì)，配置時(shí)應(yīng)說明系統(tǒng)設(shè)計(jì)的版本與需求分析報(bào)告版本的對(duì)應(yīng)關(guān)系。設(shè)計(jì)書評(píng)審?fù)ㄟ^后建立設(shè)計(jì)基線。編碼編碼按功能模塊分子項(xiàng)目，即每個(gè)模塊計(jì)作一個(gè)配置項(xiàng)。代碼基線分別在單元測(cè)試結(jié)束后建立Alpha版，Alpha測(cè)試后建立Beta版，在集成測(cè)試時(shí)建立Merge后版。測(cè)試各測(cè)試階段應(yīng)提供測(cè)試計(jì)劃、測(cè)試用例、測(cè)試結(jié)果和測(cè)試分析報(bào)告，項(xiàng)目啟動(dòng)后應(yīng)提供項(xiàng)目測(cè)試計(jì)劃書，項(xiàng)目驗(yàn)收結(jié)束后應(yīng)提交項(xiàng)目測(cè)試總結(jié)報(bào)告等。配置時(shí)應(yīng)說明測(cè)試的版本與編碼版本的對(duì)應(yīng)關(guān)系。各階段測(cè)試（如單元測(cè)試、集成測(cè)試）完成后建立測(cè)試基線。交付與驗(yàn)收在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項(xiàng)，包括交付施工文檔、工具等。項(xiàng)目總結(jié)項(xiàng)目總結(jié)應(yīng)經(jīng)過部門內(nèi)部評(píng)審，包括項(xiàng)目質(zhì)量報(bào)告、測(cè)試報(bào)告等。相關(guān)資料與培訓(xùn)相關(guān)資料與培訓(xùn)也應(yīng)作為配置項(xiàng)納入配置管理，此部分包括：1） 相關(guān)法律、法規(guī)；必須遵照或項(xiàng)目組約定的技術(shù)規(guī)范；與客戶或項(xiàng)目組內(nèi)部重要的交互信息記錄，如QuestionSheet、會(huì)議記錄、會(huì)談?dòng)涗洝-mail和MSN記錄；必要的業(yè)務(wù)或技術(shù)培訓(xùn)等。配置變更控制變更的分類軟件及其相關(guān)文檔的變更按照變更的影響范圍進(jìn)行分類：A級(jí)：變更會(huì)影響系統(tǒng)級(jí)需求、外部接口、產(chǎn)品價(jià)格或者交付期；這類變更必須經(jīng)過CCB審核并有客戶批準(zhǔn)和確認(rèn)。B級(jí)：變更會(huì)影響配置項(xiàng)間的功能接口、組件級(jí)成本或者項(xiàng)目Schedule；這類變更必須由CCB或上級(jí)管理部門的批準(zhǔn)和認(rèn)可。C級(jí)：變更會(huì)影響配置項(xiàng)內(nèi)部功能的設(shè)計(jì)和分配；這類變更可以由配置項(xiàng)的管理人員負(fù)責(zé)批準(zhǔn)。圖2變更控制流程變更請(qǐng)求的提出由發(fā)起者(客戶、最終用戶或開發(fā)部門)確定變更，填寫《變更請(qǐng)求/評(píng)審單》，描述變更原因和變更內(nèi)容，并提交給CMO。CMO對(duì)填寫的申請(qǐng)表是否清晰、明確和完整性進(jìn)行審查，若CMO發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請(qǐng)表給發(fā)起者。CMO對(duì)通過審查的變更申請(qǐng)分配變更ID,以便跟蹤和記錄變更信息。變更評(píng)估CMO將《變更請(qǐng)求/評(píng)審單》發(fā)送給項(xiàng)目經(jīng)理(或者其他授權(quán)人員)，由項(xiàng)目經(jīng)理負(fù)責(zé)對(duì)變更進(jìn)行評(píng)估。變更控制的一個(gè)重要環(huán)節(jié)就是變更評(píng)估，變更評(píng)估要分析每個(gè)變更對(duì)系統(tǒng)功能、接口、成本、進(jìn)度以及約定需求的影響，同時(shí)還要分析對(duì)軟件安全性、可靠性、可維護(hù)性、可移植性和性能的影響。變更評(píng)估產(chǎn)生的文檔應(yīng)描述若實(shí)施變更必須變更的配置項(xiàng)、文檔和資源；變更評(píng)估文檔在完成變更評(píng)估后發(fā)送給CMO。CMO收到評(píng)估后的《變更請(qǐng)求/評(píng)審單》后，更新變更記錄，并安排CCB會(huì)議日程。變更審核CCB對(duì)提交的變更申請(qǐng)進(jìn)行審核，并根據(jù)變更評(píng)估確定變更的影響級(jí)別；CCB審核可能的結(jié)果有三種：接受變更；拒絕變更；延期變更oCCB也可能需要更多的變更分析的信息。CCB批準(zhǔn)的變更，由CMO將變更項(xiàng)目發(fā)送到指定的開發(fā)人員(Assigner)進(jìn)行下一步的實(shí)施變更工作；對(duì)于拒絕的變更，由CMO將CCB拒絕變更的原因發(fā)送給發(fā)起者，并保存《變更請(qǐng)求/評(píng)審單》，更新變更記錄，關(guān)閉變更活動(dòng)；需要進(jìn)一步分析的，由CMO將變更項(xiàng)目隨同CCB的QuestionSheet發(fā)送給評(píng)估分析人員；對(duì)于延期的變更，由CMO對(duì)變更的相關(guān)文檔進(jìn)行歸檔，以便在適當(dāng)時(shí)機(jī)提交CCB審核。CMO負(fù)責(zé)整理CCB會(huì)議記錄，填寫《變更請(qǐng)求/評(píng)審單》中相應(yīng)審核項(xiàng)；更新變更記錄，如果是接受變更，還需將要變更的CIs狀態(tài)改為“修改中”；將變更文檔分發(fā)給相關(guān)人員。變更實(shí)施變更被批準(zhǔn)后，PL負(fù)責(zé)將要變更的CIs以及相關(guān)文檔遷移至變更負(fù)責(zé)人的PrivateBranch上，由變更負(fù)責(zé)人開始實(shí)施變更，并詳細(xì)記錄變更的內(nèi)容；項(xiàng)目管理部門要對(duì)變更的實(shí)施進(jìn)行跟蹤。對(duì)于代碼變更，必須修改設(shè)計(jì)、代碼、測(cè)試以及變更正確性的驗(yàn)證。而且與變更相關(guān)的文檔必須修訂，以反映變更。當(dāng)變更以及測(cè)試完成后，進(jìn)行Merge。對(duì)于開發(fā)計(jì)劃、配置管理計(jì)劃發(fā)生變更的，項(xiàng)目組人員要按照變更過的開發(fā)計(jì)劃、配置管理計(jì)劃提交配置項(xiàng)。變更確認(rèn)變更后的程序Merge后必需經(jīng)過測(cè)試組進(jìn)行回歸測(cè)試，以確保變更沒有引入新的Bugo不會(huì)引起程序變更的文檔(如計(jì)劃文檔)的變更不需經(jīng)過測(cè)試。通過Merge后測(cè)試后，SQA需對(duì)變更進(jìn)行審核，審核的范圍一般涉及以下方面：測(cè)試記錄；變更請(qǐng)求；配置項(xiàng)的檢入及檢出；文件的命名；版本的編號(hào)。SQA審核后，開發(fā)人員才能生成新的版本，由PL更新到基線庫(kù)中。PL應(yīng)重新標(biāo)識(shí)所有被影響的配置項(xiàng)及版本。A級(jí)和B級(jí)的變更項(xiàng)也可能直到下次系統(tǒng)發(fā)行版本時(shí)才生成。3.7.6.6生成新版本后，CMO負(fù)責(zé)收集所有變更信息歸檔，修改變更Cis狀態(tài)為“正式發(fā)布”，關(guān)閉變更，并將變更報(bào)告發(fā)送給發(fā)起者。配置狀態(tài)報(bào)告配置狀態(tài)報(bào)告的目的記錄和報(bào)告整個(gè)軟件生命周期演化狀態(tài)。配置狀態(tài)報(bào)告記錄的內(nèi)容配置狀態(tài)報(bào)告記錄的內(nèi)容包括：軟件和文檔的標(biāo)識(shí)；目前狀態(tài)；基線演化狀態(tài)；變更狀態(tài)；版本交付信息等。配置狀態(tài)報(bào)告的生成配置管理報(bào)告自第一個(gè)基線創(chuàng)建時(shí)建立，由配置管理系統(tǒng)生成，及時(shí)反映當(dāng)前配置狀態(tài)。配置審核配置審核的類別配置審核分為：功能配置審核(FunctionalConfigurationAudit,FCA):審核軟件功能是否與需求一致，并符合基線文檔要求；通常要審查測(cè)試方法、流程、報(bào)告和設(shè)計(jì)文檔等。物理配置審核(PhysicalConfigurationAudit,PCA