配置管理流程.doc

SCM Flow Author: JessicaSoftware Configuration Management FlowSCM FlowDepartment(部門):Author(作者):Complete Date(完成日期):Syndic(評(píng)審人員):Syndic Date(評(píng)審日期):Copyright 2003 by XXXXXXXX Co.,Ltd.All Rights Reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of XXXXXXXXX Co.,Ltd.Table of contents一概要41.1 內(nèi)容規(guī)范41.2 適用范圍41.3 Nomenclature(術(shù)語(yǔ))41.3.1 SCM（軟件配置管理）41.3.2 Configuration（配置）41.3.3 SCI（配置項(xiàng)）41.3.4 Base line（基線）5二Role and Duty（角色和責(zé)任）52.1 PM（項(xiàng)目經(jīng)理）52.2 CCB（配置控制委員會(huì)）52.3 CMO（配置管理員）62.4 Developer（開發(fā)人員）62.5 Tester（測(cè)試人員）62.6 SQA（軟件質(zhì)量保證員）7三Actualize Rule（實(shí)施細(xì)則）73.1 CCB的成立73.2 SC Tactic（確定配置策略）73.2.1 配置策略73.2.2 配置項(xiàng)的范圍73.3 SC Plan（制定配置管理計(jì)劃）73.3.1 部門73.3.2 內(nèi)容73.3.3 審批83.4 SCI Label Rule（配置項(xiàng)標(biāo)識(shí)規(guī)則）83.4.1 配置項(xiàng)標(biāo)識(shí)要求83.4.2 配置項(xiàng)標(biāo)識(shí)方式83.4.2.1 標(biāo)識(shí)83.4.2.2 名稱83.4.2.3 文件狀態(tài)83.4.2.4 文檔版本控制93.4.2.5 發(fā)行版本控制93.4.2.6 基線版本標(biāo)識(shí)93.5 Repository（配置庫(kù)管理）93.5.1 配置庫(kù)分類93.5.2 配置庫(kù)建立93.5.3 分配權(quán)限103.5.4 配置庫(kù)的操作與管理103.6 配置項(xiàng)和基線管理103.7 配置變更控制113.7.1 變更級(jí)別分類113.7.2 變更請(qǐng)求的提出113.7.3 變更評(píng)估113.7.4 變更審核113.7.5 變更實(shí)施123.7.6 變更確認(rèn)123.8 配置狀態(tài)報(bào)告123.9 配置審核133.9.1 配置審核的類別133.9.2 配置審核執(zhí)行的時(shí)機(jī)133.9.3 不合格項(xiàng)的處理133.10 發(fā)行管理13四相關(guān)文件14配置管理流程一概要 1.1 內(nèi)容規(guī)范配置管理活動(dòng)，確保配置項(xiàng)正確地唯一標(biāo)識(shí)并易于存取，保證基線配置項(xiàng)的更改受控，明確基線狀態(tài)，在整個(gè)軟件生命周期中保證項(xiàng)目產(chǎn)品的完整性和可追溯性。 1.2 適用范圍本配置管理流程作為datalabchina公司暫行配置管理流程，適合于公司內(nèi)所有項(xiàng)目，作為試用版，在執(zhí)行一段時(shí)間后，可以根據(jù)實(shí)際工作情況中累積的經(jīng)驗(yàn)和實(shí)踐進(jìn)行修改、增刪。1.3 Nomenclature(術(shù)語(yǔ))1.3.1 SCM（軟件配置管理）軟件配置管理是對(duì)軟件修改進(jìn)行標(biāo)識(shí)、組織和控制的技術(shù)，用來(lái)協(xié)調(diào)和控制整個(gè)過程。是通過技術(shù)或行政手段對(duì)軟件產(chǎn)品及其開發(fā)過期進(jìn)行控制、規(guī)范的一系列措施。配置管理的目標(biāo)是記錄軟件產(chǎn)品的演化過程，確保軟件開發(fā)者在軟件生命周期中各個(gè)階段都能得到精版本的產(chǎn)品配置。1.3.2 Configuration（配置）配置是在技術(shù)文檔中明確說明并最終組成軟件產(chǎn)品的功能或物理屬性。因此配置包括了即將受控的所有產(chǎn)品特性，其內(nèi)容及相關(guān)本、變更文檔、軟件運(yùn)行的支持?jǐn)?shù)據(jù)，以及其他一切保證軟件一致性的組成要素，相對(duì)與硬件類配置，軟件產(chǎn)品的配置包括更多的變性。 1.3.3 SCI（配置項(xiàng)）凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項(xiàng)，配置項(xiàng)邏輯上組成軟件系統(tǒng)的各組成部分，一般是可以設(shè)計(jì)、實(shí)施和測(cè)試的。配置項(xiàng)主要有兩大類：l 屬于產(chǎn)品組成部分的工作成果，例如需求文檔、設(shè)計(jì)文檔、源代碼、測(cè)試用例等； l 項(xiàng)目管理和機(jī)構(gòu)支撐過程產(chǎn)生的文檔。這些文檔雖然不是產(chǎn)品的組成部分，但是值得保存。每個(gè)配置項(xiàng)的主要屬性有：名稱、標(biāo)識(shí)符、文件狀態(tài)、版本、作者、日期等。所有配置項(xiàng)都被保存在配置庫(kù)里，確保不會(huì)混淆、其歷史記錄反映了軟件的演化過程。 1.3.4 Base line（基線）在配置管理系統(tǒng)中，基線就是一個(gè)SCI 或一組SCI在其生命周期的不同時(shí)間點(diǎn)上通過正式評(píng)審而進(jìn)入正式受控的一種狀態(tài)，這些配置項(xiàng)是穩(wěn)定的邏輯實(shí)體，而這個(gè)過程被稱為“基線化”。每一個(gè)基線都是其下一步開發(fā)的出發(fā)點(diǎn)和參考點(diǎn)。基線確定了元素（配置項(xiàng)只確定一個(gè)版本。一般情況下，基線一般在指定的里程碑處創(chuàng)建，并與項(xiàng)目中的里程碑保持同步。每個(gè)基線都將得到嚴(yán)格控制，基線中的配置項(xiàng)被“凍結(jié)”了，不能再被任何人隨意修改，對(duì)其的修改將嚴(yán)格按照變更控制要求的過程進(jìn)行，在結(jié)束時(shí)，上一個(gè)基線加上增加和修改的基線內(nèi)容形成下一個(gè)基線。基線的主要屬性有：名稱、標(biāo)識(shí)符、版本、日期等。通常將交付給客戶的基線稱為一個(gè)“Release”，為內(nèi)部開發(fā)用的基線則稱為“d”。建立基線的好處： l 重現(xiàn)性：及時(shí)返回并重新生成軟件系統(tǒng)給定發(fā)布版的能力，或者是在項(xiàng)目中的早些時(shí)候重新生成開發(fā)環(huán)境的能力。當(dāng)認(rèn)為可信時(shí)，基線為團(tuán)隊(duì)提供一種取消變更的方法。 l 可追蹤性：建立項(xiàng)目工件之間的前后繼承關(guān)系。目的是確保設(shè)計(jì)滿足要求、代碼實(shí)施設(shè)計(jì)以及用正確代碼編譯可執(zhí)行文件 l 版本隔離：基線為開發(fā)工件提供了一個(gè)定點(diǎn)和快照，新項(xiàng)目可以從基線提供的定點(diǎn)之中建立。作為一個(gè)單獨(dú)分支，新項(xiàng)目項(xiàng)目（在主要分支上）所進(jìn)行的變更進(jìn)行隔離。二Role and Duty（角色和責(zé)任）2.1 PM（項(xiàng)目經(jīng)理）責(zé)任： l 確定項(xiàng)目起始基線和開發(fā)里程碑；l 接受配置管理計(jì)劃，并按相關(guān)規(guī)定貫徹執(zhí)行； l 接受配置控制委員會(huì)的報(bào)告。權(quán)利： l 提出配置管理計(jì)劃的修改要求； l 提出管理管理的建議和要求。 2.2 CCB（配置控制委員會(huì)）責(zé)任： l 制定和修改項(xiàng)目的配置管理策略。權(quán)利： l 批準(zhǔn)、發(fā)布配置管理計(jì)劃； l 建立、更改基線的設(shè)置，審核變更申請(qǐng)； l 根據(jù)配置管理員的報(bào)告決定相應(yīng)的對(duì)策。 2.3 CMO（配置管理員）責(zé)任： l 編制配置管理計(jì)劃； l 執(zhí)行配置項(xiàng)管理方案； l 執(zhí)行版本控制和變更控制方案； l 編制配置狀態(tài)報(bào)告；l 配置庫(kù)的建立和權(quán)限分配；l 配置管理工具的日常管理與維護(hù)；l 配置庫(kù)的日常操作和維護(hù)。權(quán)利：l 向 CCB 匯報(bào)有關(guān)配置管理流程中的不符合情況；l 各配置項(xiàng)的管理與維護(hù)；l 對(duì)開發(fā)人員進(jìn)行相關(guān)的培訓(xùn)。2.4 Developer（開發(fā)人員）責(zé)任： l 根據(jù)確定的配置管理計(jì)劃和相關(guān)規(guī)定，提交配置項(xiàng)和基線； l 新建或修改配置項(xiàng)時(shí)，在配置項(xiàng)中必須加入相應(yīng)的注釋，新建時(shí)的內(nèi)容包括：新建人、新建時(shí)間、新建原因、版本。修改時(shí)的內(nèi)容包括：修改人、修改時(shí)間、修改原因、修改內(nèi)容、修改版本。該注釋一般加注在配置項(xiàng)的head。l 負(fù)責(zé)軟件集成和版本生成。權(quán)利：l 按照軟件配置管理工具的使用模型來(lái)完成開發(fā)任務(wù)。 2.5 Tester（測(cè)試人員）責(zé)任：l 根據(jù)配置管理計(jì)劃和相關(guān)規(guī)定，提交測(cè)試配置項(xiàng)和測(cè)試基線；l 版本的發(fā)布。權(quán)利：l 負(fù)責(zé)軟件變更的測(cè)試驗(yàn)證。 2.6 SQA（軟件質(zhì)量保證員）責(zé)任：l 負(fù)責(zé)配置審核并提交報(bào)告。權(quán)利：l 對(duì)配置審核中發(fā)現(xiàn)的不符合項(xiàng)，要求相關(guān)責(zé)任人進(jìn)行糾正。 三Actualize Rule（實(shí)施細(xì)則） 3.1 CCB的成立公司首先應(yīng)該成立一個(gè)CCB，然后由CCB來(lái)制定和修改項(xiàng)目的配置管理策略。3.2 SC Tactic（確定配置策略）3.2.1 配置策略CCB 成立后，由 CCB 組織會(huì)議根據(jù)項(xiàng)目的開發(fā)計(jì)劃確定各個(gè)里程碑和開發(fā)策略， CMO 負(fù)責(zé)整理并且確定項(xiàng)目的基線和配置項(xiàng)列表，并在編制配置計(jì)劃時(shí)列出清單，按約定的時(shí)間收集配置項(xiàng)和建立初始基線。3.2.2 配置項(xiàng)的范圍 l 文檔：項(xiàng)目開發(fā)計(jì)劃、需求分析文檔、軟件設(shè)計(jì)文檔、質(zhì)量保證計(jì)劃、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、測(cè)試文檔、用戶手冊(cè)、聯(lián)機(jī)幫助、總結(jié)、報(bào)告、客戶反饋及交互文檔等。l 程序：階段產(chǎn)品、代碼程序、發(fā)布的安裝包、升級(jí)包等。3.3 SC Plan（制定配置管理計(jì)劃）3.3.1 部門配置管理計(jì)劃一般由CMO在項(xiàng)目開始設(shè)計(jì)前編制，根據(jù)公司的具體情況，所有項(xiàng)目的配置計(jì)劃大同小異，可以由CMO在適當(dāng)情況下編制，也可以沿用公司現(xiàn)有的配置計(jì)劃文檔。3.3.2 內(nèi)容配置管理計(jì)劃的內(nèi)容一般包括要求、職責(zé)、活動(dòng)、安排等，具體如下： l 該項(xiàng)目對(duì)配置管理的要求； l 實(shí)施配置管理的責(zé)任人、組織及其職責(zé)； l 需要開展的配置管理活動(dòng)及其進(jìn)度安排； l 采用的方法和工具等。3.3.3 審批配置管理計(jì)劃由 CCB 負(fù)責(zé)審批后交付CMO實(shí)施。 3.4 SCI Label Rule（配置項(xiàng)標(biāo)識(shí)規(guī)則）3.4.1 配置項(xiàng)標(biāo)識(shí)要求 l 提供需求時(shí)，如果需求中有明確標(biāo)識(shí)要求時(shí)，由開發(fā)人員按要求進(jìn)行標(biāo)識(shí)，以保證滿足需求中的要求。 l 在開發(fā)過程中項(xiàng)目組人員提交的配置項(xiàng)，由項(xiàng)目組人員按照本節(jié)相關(guān)部分標(biāo)識(shí)規(guī)則進(jìn)行標(biāo)識(shí)。 l 項(xiàng)目組人員將要標(biāo)識(shí)或已標(biāo)識(shí)的配置項(xiàng)提交給CMO納入配置庫(kù)統(tǒng)一管理，并填寫配置狀態(tài)報(bào)告。l 標(biāo)識(shí)規(guī)則由PM、CMO、CCB共同討論確定。3.4.2 配置項(xiàng)標(biāo)識(shí)方式 3.4.2.1 標(biāo)識(shí)配置項(xiàng)標(biāo)識(shí)屬性包括：名稱、編號(hào)、文件狀態(tài)、版本、作者、日期等。3.4.2.2 名稱l 文件名稱的標(biāo)識(shí)按文檔模板中統(tǒng)一名稱為準(zhǔn)。l 編號(hào)文檔編號(hào)格式為 DataLabChina_XXX_*_$_# ，其中 CC 表示公司， XXX 是項(xiàng)目的三位英文字母縮寫表示， *_$ 表示文檔類別，如技術(shù)類DOC_TEC，使用說明類DOC_GUI， # 表示文件的一個(gè)序列號(hào)，即序號(hào)，如001號(hào)。如PP Entry的用戶使用說明文件的編號(hào)為：DataLabChina_PPE_DOC_GUI_005。3.4.2.3 文件狀態(tài)文件狀態(tài)分為“草稿”、“正式發(fā)布”或“正本”和“修改中”三種。修改處于“草稿”狀態(tài)的配置項(xiàng)不算是“變更”，無(wú)需審核批準(zhǔn)，修改者按照版本控制規(guī)則執(zhí)行即可。當(dāng)配置項(xiàng)的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)”后，不能隨意修改，必須依據(jù)配置變更控制的規(guī)則執(zhí)行。當(dāng)配置項(xiàng)的狀態(tài)成為“修改中”，則是依照配置變更控制的規(guī)則獲得批準(zhǔn)后進(jìn)行的修改，即狀態(tài)是由正式發(fā)布或正本狀態(tài)更改到“修改中”，如果是草稿狀態(tài)，則不需要標(biāo)識(shí)狀態(tài)為修改中。3.4.2.4 文檔版本控制對(duì)于計(jì)劃性文檔、技術(shù)文檔和用戶文檔，其版本按修改的先后順序確定。新生成的文檔第一次發(fā)行為第一版，修改后第二次發(fā)行為第二版，依次類推。3.4.2.5 發(fā)行版本控制最終完成的軟件版本用三位符號(hào)表示：“ S.X.Y ”。各符號(hào)位的含義如下： l S為主版本號(hào)。對(duì)產(chǎn)品作重大調(diào)整，或與已發(fā)行的上一產(chǎn)品相比，在功能與性能上有較大改善時(shí)主版本號(hào)增加；產(chǎn)品第一次完成，版本號(hào)為 1.0；l X為第一次版本號(hào)，表示增加功能時(shí)的版本升級(jí)，用一位數(shù)字表示：“ 09 ”。與上一產(chǎn)品或項(xiàng)目相比，功能進(jìn)行了小量的修改，第一次版本號(hào)增加時(shí)，第二次版本號(hào)為零，第二版本號(hào)為零時(shí)可以省略不寫； l Y為第二次版本號(hào)，表示糾正錯(cuò)誤時(shí)的版本升級(jí)，用一位數(shù)字表示：“ 19 ”，對(duì)上一次產(chǎn)品或項(xiàng)目中的缺陷做修正。3.4.2.6 基線版本標(biāo)識(shí)l 內(nèi)部基線：如計(jì)劃基線、設(shè)計(jì)基線等，在版本號(hào)前加Build，如Build1.0；l 發(fā)行產(chǎn)品基線：在版本號(hào)前加Release，如Release 2.0。指發(fā)布產(chǎn)品或向客戶提供項(xiàng)目版本。3.5 Repository（配置庫(kù)管理）3.5.1 配置庫(kù)分類根據(jù)公司的實(shí)際情況，項(xiàng)目配置庫(kù)不進(jìn)行分類，一個(gè)項(xiàng)目直接由一個(gè)配置庫(kù)包含文檔管理、代碼管理、版本管理。3.5.2 配置庫(kù)建立CCB 成立之后，CMO即可著手組織建立配置庫(kù)。每個(gè)項(xiàng)目都有唯一對(duì)應(yīng)的配置庫(kù)來(lái)管理其配置項(xiàng)。每個(gè)配置庫(kù)都應(yīng)該建立至少三個(gè)分支：私有公支、集成分支和公共分支。l Private Branch（私有分支）：私有分支對(duì)應(yīng)的是開發(fā)人員的私有開發(fā)空間。開發(fā)人員根據(jù)任務(wù)分工獲得對(duì)相應(yīng)配置項(xiàng)的操作，即在自己的私有開發(fā)分支上工作，他的所有工作成果體現(xiàn)為在該配置項(xiàng)的私有分支上的版本的推進(jìn)，除該開發(fā)人員外無(wú)權(quán)操作該私有空間中的元素。l Integration Branch（集成分支）：集成分支對(duì)應(yīng)的是開發(fā)團(tuán)隊(duì)的公共空間。凡是要為同組人員共享的配置項(xiàng)都將私有工作空間中的開發(fā)成果歸并（ Merge ）到該分支后才能進(jìn)入下一個(gè)開發(fā)活動(dòng)。所有涉及多人協(xié)調(diào)的開發(fā)都必須工作在這一空間中。該開發(fā)團(tuán)隊(duì)擁有對(duì)該集成分支的讀寫權(quán)限，而其他成員只有只讀權(quán)限。該分支的管理工作指定人員負(fù)責(zé)。l Common Branch（公共分支）：公共分支對(duì)應(yīng)的是整個(gè)軟件開發(fā)組織的公共空間。各個(gè)開發(fā)小組在現(xiàn)階段的任務(wù)完成后，將歸并到該分支上，將來(lái)需要查閱相關(guān)資料時(shí)，以該分支上的版本為準(zhǔn)。該分支對(duì)組織內(nèi)的全體軟件人員開放只讀權(quán)限，由CMO管理該分支的日常維護(hù)。相當(dāng)天基線。3.5.3 分配權(quán)限 CMO為每個(gè)項(xiàng)目成員分配配置庫(kù)操作權(quán)限。一般地，項(xiàng)目成員擁有 Add、Checkin/Checkout 、 Download等權(quán)限，但是不能擁有刪除的權(quán)限。3.5.4 配置庫(kù)的操作與管理 l 開發(fā)人員根據(jù)獲得的授權(quán)的資源進(jìn)行項(xiàng)目的研發(fā)工作，操作配置庫(kù)，例如 Add、Checkin/Checkout、 Download等。 l CMO根據(jù)配置管理計(jì)劃創(chuàng)建與維護(hù)基線，“凍結(jié)”配置項(xiàng)，控制變更。l 當(dāng)發(fā)生變更且變更評(píng)審?fù)ㄟ^后，或者發(fā)現(xiàn) Bug 且 Bug 評(píng)審?fù)ㄟ^后，由CMO將Common Branch 中SCI簽出至開發(fā)人員的 Private Branch上行變更。 l 當(dāng)變更實(shí)施結(jié)束或Bug修正和測(cè)試結(jié)束，并通過配置審核后，由CMO將變更后的SCI簽入到Common Branch。l CMO定期清除配置庫(kù)里的垃圾文件，并且定期備份配置庫(kù)。 3.6 配置項(xiàng)和基線管理 CMO 根據(jù)配置管理計(jì)劃，對(duì)配置項(xiàng)和基線進(jìn)行分階段管理。l 需求分析系統(tǒng)通過評(píng)審并需取得客戶的確定后，鎖定該需求配置項(xiàng)，建立需求基線。如果需要修改或增加新的需求，必須通過評(píng)審并得到客戶的確認(rèn)。l 制定項(xiàng)目開發(fā)計(jì)劃，包括項(xiàng)目總體進(jìn)度說明、進(jìn)度跟蹤、計(jì)劃修改、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、測(cè)試計(jì)劃，計(jì)劃評(píng)審?fù)ㄟ^后，鎖定項(xiàng)目開發(fā)計(jì)劃，建立項(xiàng)目計(jì)劃基線。l 系統(tǒng)設(shè)計(jì)可分為概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)和數(shù)據(jù)庫(kù)設(shè)計(jì)等部分。設(shè)計(jì)評(píng)審?fù)ㄟ^后，建立設(shè)計(jì)基線。 l 編碼按功能模塊分子項(xiàng)目，即每個(gè)模塊計(jì)作一個(gè)配置項(xiàng)。代碼基線分別在單元測(cè)試結(jié)束后。l 測(cè)試階段應(yīng)提供測(cè)試計(jì)劃、測(cè)試用例、測(cè)試結(jié)果和測(cè)試分析報(bào)告，配置時(shí)應(yīng)說明測(cè)試的版本與編碼版本的對(duì)應(yīng)關(guān)系。各階段測(cè)試完成后建立測(cè)試基線。l 交付與驗(yàn)收：在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項(xiàng)，包括交付施工文檔、工具等。 l 項(xiàng)目總結(jié)：項(xiàng)目總結(jié)應(yīng)經(jīng)過部門內(nèi)部評(píng)審，包括項(xiàng)目質(zhì)量報(bào)告、測(cè)試報(bào)告等。 l 與客戶或項(xiàng)目組內(nèi)部重要的交互信息記錄，如Question Sheet、會(huì)議記錄、會(huì)談?dòng)涗洝-mail 和 MSN 記錄；應(yīng)該建立對(duì)應(yīng)的配置項(xiàng)。3.7 配置變更控制 3.7.1 變更級(jí)別分類l A 級(jí)：變更會(huì)影響系統(tǒng)級(jí)需求、外部接口或者交付期；這類變更必須經(jīng)過CCB審核并有經(jīng)過相關(guān)人員批準(zhǔn)和確認(rèn)。 l B 級(jí)：變更會(huì)影響配置項(xiàng)間的功能接口或者項(xiàng)目進(jìn)度表Schedule；這類變更必須由 CCB 或上級(jí)管理部門的批準(zhǔn)和認(rèn)可 l C 級(jí)：變更會(huì)影響配置項(xiàng)內(nèi)部功能的設(shè)計(jì)和分配；這類變更可以由配置項(xiàng)的管理人員負(fù)責(zé)批準(zhǔn)。3.7.2 變更請(qǐng)求的提出 由相關(guān)部門或相關(guān)人員確定變更，填寫變更請(qǐng)求/評(píng)審單，描述變更原因和變更內(nèi)容，并提交給CMO對(duì)填寫的申請(qǐng)表進(jìn)行審查（是否清晰、明確和完整性），若CMO發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請(qǐng)表給發(fā)起者重新填寫變單。CMO申請(qǐng)分配變更ID，以便跟蹤和記錄變更信息。3.7.3 變更評(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)度以及約定需求的影響和對(duì)軟件安全性、可靠性、可維護(hù)性、可移植性和性能的影響。變更評(píng)估產(chǎn)生的文檔應(yīng)描述若實(shí)施變更必須變更的配置項(xiàng)、文檔和資源；變更評(píng)估文檔在完成變更評(píng)估后發(fā)送給CMO。CMO 收到評(píng)估后的變更請(qǐng)求/評(píng)審單后，更新變更記錄。 3.7.4 變更審核 CCB 對(duì)提交的變更申請(qǐng)進(jìn)行審核，并根據(jù)變更評(píng)估確定變更的影響級(jí)別；CCB 審核可能的結(jié)果有三種：接受變更、拒絕變更、需要進(jìn)一步分析變更信息。CCB批準(zhǔn)的變更，由CMO將變更項(xiàng)目發(fā)送到項(xiàng)目經(jīng)理PM，由PM指定開發(fā)人員進(jìn)行下一步的實(shí)施變更工作；對(duì)于拒絕的變更，將拒絕變更的原因發(fā)送給發(fā)起者，并保存變更請(qǐng)求/評(píng)審單，更新變更記錄，關(guān)閉變更活動(dòng)；需要進(jìn)一步分析變更信息，由CMO將變更項(xiàng)發(fā)送給評(píng)估分析人員。 CMO負(fù)責(zé)整理CCB會(huì)議記錄，填寫變更請(qǐng)求/評(píng)審單中相應(yīng)審核項(xiàng)；更新變更記錄，如果是接受變更，還需將要變更的配置項(xiàng)狀態(tài)改為“修改中”；將變更文檔分發(fā)給相關(guān)人員。3.7.5 變更實(shí)施 變更被批準(zhǔn)后，PM負(fù)責(zé)將要變更的SCI以及相關(guān)文檔遷移至變更負(fù)責(zé)人的 Private Branch上，由變更負(fù)責(zé)人開始實(shí)施變更的內(nèi)容；項(xiàng)目管理部門要對(duì)變更的實(shí)施進(jìn)行跟蹤。對(duì)于代碼變更，必須修改設(shè)計(jì)、代碼、測(cè)試以及變更正確性的驗(yàn)證。而且與變更相關(guān)的文檔必須修訂，以反映變更。當(dāng)完成后，進(jìn)行Merge。對(duì)于開發(fā)計(jì)劃、配置管理計(jì)劃發(fā)生變更的，項(xiàng)目組人員要按照變更過的開發(fā)計(jì)劃、配置管理計(jì)劃提交配置項(xiàng)。3.7.6 變更確認(rèn) 變更后的程序歸并Merge后必組經(jīng)過測(cè)試組進(jìn)行回歸測(cè)試，以確保變更沒有引入新Bug，不會(huì)引起程序變更的文檔（如計(jì)劃性文檔則不需經(jīng)過測(cè)試）。通過 Merge 后的測(cè)試，SQA 需對(duì)變更進(jìn)行審核，審核的范圍一般涉及以下方面： l 測(cè)試記錄； l 變更請(qǐng)求；l 配置項(xiàng)的檢入及檢出； l 文件的命名； l 版本的編號(hào)