配置管理計(jì)劃示例

1、卷號(hào)卷內(nèi)編號(hào)密級(jí)酒店管理系統(tǒng)配置管理計(jì)劃Version1.0項(xiàng)目承擔(dān)部門(mén)：配置管理部門(mén)撰寫(xiě)人（簽名）：完成日期：2010/7/18本文檔使用部門(mén)：口主管領(lǐng)導(dǎo)項(xiàng)目組口客戶（市場(chǎng)）口維護(hù)人員口用戶評(píng)審負(fù)責(zé)人（簽名）：評(píng)審日期：分類：專題計(jì)劃使用者：項(xiàng)目經(jīng)理、配置變更控制經(jīng)理、集成員、項(xiàng)目組成員文檔信息標(biāo)題：配置管理計(jì)劃作者:創(chuàng)建日期：2010/7/18上次更新日期：2010/7/18版本:Version1.0部門(mén)名稱：swjtu-Java-02修訂文檔歷史記錄日期版本說(shuō)明作者2010/7/18Version1.0創(chuàng)建文檔2010/7/22Version1.1修改文檔目錄1. 簡(jiǎn)介41.1 目的41

2、.2 范圍41.3 定義、首字母縮寫(xiě)詞和縮略語(yǔ)41.4 參考資料442. 軟件配置管理42.1 組織、職責(zé)和接口42.2 工具、環(huán)境和基礎(chǔ)設(shè)施43. 配置管理活動(dòng)63.1 配置標(biāo)識(shí)63.1.1 標(biāo)識(shí)方法63.1.2 項(xiàng)目基線63.2 配置和變更控制83.2.1 變更請(qǐng)求的處理和審批83.2.2 變更控制委員會(huì)(CCB)103.3 配置狀態(tài)統(tǒng)計(jì)113.3.1 項(xiàng)目介質(zhì)存儲(chǔ)和發(fā)布進(jìn)程113.3.2 報(bào)告和審計(jì)114. 里程碑115. 培訓(xùn)和資源126. 分包商和廠商軟件控制錯(cuò)誤！未定義書(shū)簽。配置管理計(jì)劃3 簡(jiǎn)介項(xiàng)目CM計(jì)劃說(shuō)明在產(chǎn)品生命周期中將執(zhí)行的所有與CMt目關(guān)的活動(dòng)。它詳細(xì)說(shuō)明了活動(dòng)時(shí)間表、

3、分配的職責(zé)以及必需的資源（包括人員、工具和計(jì)算機(jī)設(shè)備）。3.3 目的CM計(jì)劃的目的在于，定義或參考那些描述要在軟件產(chǎn)品開(kāi)發(fā)中執(zhí)行配置和變更控制管理（CM）方式的步驟和活動(dòng)。3.4 范圍本規(guī)范規(guī)定了在制訂軟件配置管理計(jì)劃時(shí)應(yīng)該遵循的統(tǒng)一的基本要求。本規(guī)范適用于軟件特別是重要軟件的配置管理計(jì)劃的制訂工作。對(duì)于非重要軟件或已開(kāi)發(fā)好的軟件，可以采用本規(guī)范規(guī)定的要求的子集。3.5 定義、首字母縮寫(xiě)詞和縮略語(yǔ)CCB-configurationcontrolboard變更（或配置）控制委員會(huì)CI-configurationitem配置項(xiàng)CM-configurationmanagement配置管理Baseli

4、ne:基線。PCA物理審計(jì)，在配置管理系統(tǒng)中建立基線的工件是否為正確”版本。FCA功能審計(jì)，是核實(shí)軟件配置項(xiàng)的實(shí)際性能是否符合它的需求。CMP-configurationmanagementplan配置管理計(jì)戈UCR-changerequest變更請(qǐng)求SCM-softwareconfigurationmanagement軟件配置管理任意角色-項(xiàng)目中所有角色3.6 參考資料«RationalUnifiedProcess2000»SDPPlan»«DevelopCase»4 軟件配置管理4.3 組織、職責(zé)和接口CCB該委員會(huì)監(jiān)督變更流程，由開(kāi)發(fā)人員

5、和用戶的代表組成。與任意角色：任意角色提出變更請(qǐng)求，需提交給CCB對(duì)變更請(qǐng)求進(jìn)行處理后，將結(jié)果通知給提出者。配置經(jīng)理配置經(jīng)理負(fù)責(zé)為產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)提供全面的配置管理(CM)基礎(chǔ)設(shè)施和環(huán)境。CM的作用是支持產(chǎn)品開(kāi)發(fā)行為，使開(kāi)發(fā)人員和集成員有適當(dāng)工作區(qū)來(lái)構(gòu)建和測(cè)試其工件，并且使所有工件均可根據(jù)需要包含在部署單元中。配置經(jīng)理還必須確保CM環(huán)境有利于進(jìn)行產(chǎn)品復(fù)審、更改和缺陷跟蹤等活動(dòng)。配置經(jīng)理還負(fù)責(zé)撰寫(xiě)CM計(jì)劃并匯報(bào)基于變更請(qǐng)求”的進(jìn)度統(tǒng)計(jì)信息。發(fā)布基線與項(xiàng)目經(jīng)理：CM計(jì)劃需要參照SDP計(jì)劃，而且SDP又參照CM計(jì)劃。SCM經(jīng)理每周/每階段都要提供系統(tǒng)的配置狀態(tài)報(bào)告給項(xiàng)目經(jīng)理。與集成員：CM經(jīng)理創(chuàng)建配置管

6、理庫(kù)，而集成員創(chuàng)建集成工作區(qū)。集成員創(chuàng)建基線和提升基線，由SCM經(jīng)理管理基線。與部署經(jīng)理：SCMg理創(chuàng)建部署單元，需要部署計(jì)劃。與架構(gòu)設(shè)計(jì)師：SCMg理創(chuàng)建CM環(huán)境，需要實(shí)施模型。與任意角色：任意角色創(chuàng)建開(kāi)發(fā)工作區(qū)，需要配置庫(kù)。與系統(tǒng)管理員：創(chuàng)建CM環(huán)境時(shí)，需要系統(tǒng)管理員提供硬件和網(wǎng)絡(luò)基礎(chǔ)設(shè)施。與組織SCM管理員：在每一階段基線完成后提交基線工件。與評(píng)審協(xié)調(diào)員：接收評(píng)審協(xié)調(diào)員提交的評(píng)審結(jié)果工件和評(píng)審表。與SQA人員：配合SQA人員活動(dòng)。任意角色項(xiàng)目組所有成員任何角色均可以檢入”和檢出"任何與產(chǎn)品相關(guān)的工件，以便在配置控制系統(tǒng)中進(jìn)行維護(hù)。此外，任意角色都可以提交變更請(qǐng)求，并且對(duì)它們所擁

7、有的變更請(qǐng)求進(jìn)行4.4 工具、環(huán)境和基礎(chǔ)設(shè)施.工具配置管理產(chǎn)品開(kāi)發(fā)全程PSvn|Svn簡(jiǎn)單，功能強(qiáng)大。2.CM環(huán)境和基礎(chǔ)設(shè)施1)產(chǎn)品數(shù)據(jù)量的預(yù)期大?。何覀兤谕卷?xiàng)目至少有150個(gè)文件，50M的磁盤(pán)空間。2)產(chǎn)品團(tuán)隊(duì)的分配:角色成員名單角色說(shuō)明PM項(xiàng)目經(jīng)理SA需求分析師SE設(shè)計(jì)分析師TE測(cè)試工程師CM配置管理員PPQA產(chǎn)品和質(zhì)量保證服務(wù)器和客戶機(jī)的實(shí)際位置：1臺(tái)。2G內(nèi)存、160G硬盤(pán)。Win7。服務(wù)器位置在C2-6,客戶端在C2-.05 配置管理活動(dòng)5.3 配置標(biāo)識(shí)5.3.1 標(biāo)識(shí)方法最終的工件的命名方式是大寫(xiě)字母+縮寫(xiě)+編號(hào)+名稱例：HMS-CM-101-配置管理

8、計(jì)劃相應(yīng)的工件的中間版本命名方式是以對(duì)應(yīng)的階段大寫(xiě)字母縮寫(xiě)加類別大寫(xiě)縮寫(xiě)加版本編號(hào)命名發(fā)布標(biāo)志為產(chǎn)品縮寫(xiě)加版本號(hào)，階段發(fā)布為階段號(hào)加版本號(hào)5.3.2 工件存儲(chǔ)目錄及分類項(xiàng)目開(kāi)發(fā)過(guò)程產(chǎn)生的工件由相應(yīng)的負(fù)責(zé)人及時(shí)上傳至SVN服務(wù)器，由配置管理員統(tǒng)一管理。SVN服務(wù)器文件存放目錄分類如下圖5.3.3 文件上傳管理所有模塊負(fù)責(zé)人必須與每日工作結(jié)束之前上傳當(dāng)日工作內(nèi)容上傳至SVN服務(wù)器。所有上傳工件必須符合標(biāo)識(shí)方法中的命名方式。3.1.3項(xiàng)目基線基線名稱基線標(biāo)識(shí)產(chǎn)出時(shí)機(jī)計(jì)劃基線JH-01計(jì)劃階段結(jié)束需求基線XQ-01需求分析階段結(jié)束設(shè)計(jì)基線SJ-02設(shè)計(jì)階段結(jié)束產(chǎn)品基線CP-03實(shí)現(xiàn)部署階段結(jié)束基線創(chuàng)建

9、非代碼類基線：由配置經(jīng)理根據(jù)開(kāi)發(fā)案例創(chuàng)建代碼類基線：由集成員根據(jù)產(chǎn)品架構(gòu)文檔創(chuàng)建5.4 配置和變更控制5.4.1 變更請(qǐng)求的處理和審批軟件配置的變更管理適用于本項(xiàng)目的所有文檔和代碼，其中包括本項(xiàng)目的各個(gè)運(yùn)行軟件，也包括為本項(xiàng)目專門(mén)開(kāi)發(fā)的支持軟件。變更請(qǐng)求表單是一個(gè)正式提交的工件，用于在整個(gè)項(xiàng)目的生命周期內(nèi)跟蹤所有的請(qǐng)求（包括新特性、擴(kuò)展請(qǐng)求、缺陷、變更的需求等）與相關(guān)的狀態(tài)信息。所有變更歷史記錄，包括所有狀態(tài)變更及變更的日期和原因，都將隨CR一起保存。進(jìn)行多次復(fù)審和結(jié)束項(xiàng)目時(shí)都可使用此信息。變更過(guò)程中的活動(dòng)提交變更請(qǐng)求提交者項(xiàng)目的任何涉眾均可提交變更請(qǐng)求（CR）o通過(guò)將變更請(qǐng)求狀態(tài)設(shè)置為已提交

10、，變更請(qǐng)求被記錄到變更請(qǐng)求追蹤系統(tǒng)中（例如ClearQuest）并放置到CCB復(fù)審隊(duì)列中。復(fù)審變更請(qǐng)求CCB此活動(dòng)的作用是復(fù)審已提交的變更請(qǐng)求。在CCB復(fù)審會(huì)議中對(duì)變更請(qǐng)求的內(nèi)容進(jìn)行初始復(fù)審，以確定它是否為有效請(qǐng)求。如果是，則基于小組所確定的優(yōu)先級(jí)、時(shí)間表、資源、努力程度、風(fēng)險(xiǎn)、嚴(yán)重性以及其他任何相關(guān)的標(biāo)準(zhǔn)，判定該變更是在當(dāng)前發(fā)布版的范圍之內(nèi)還是范圍之外。確認(rèn)重復(fù)或拒絕CCB代表如果懷疑某個(gè)變更請(qǐng)求為重復(fù)的請(qǐng)求或已拒絕的無(wú)效請(qǐng)求（例如，由于操作符錯(cuò)誤、無(wú)法重現(xiàn)、工作方式等），將指定一個(gè)CCB代表來(lái)確認(rèn)重復(fù)或已拒絕的變更請(qǐng)求。如果需要的話，該代表還從提交者處收集更多信息。更新變更請(qǐng)求提交者如果評(píng)

11、估變更請(qǐng)求時(shí)需要更多的信息（詳細(xì)信息），或者如果變更請(qǐng)求在流程中的某個(gè)時(shí)刻遭到拒絕（例如，被確認(rèn)為是重復(fù)、已拒絕等），那么將通知提交者，并用新信息更新變更請(qǐng)求。然后將已更新的變更請(qǐng)求重新提交給CCB復(fù)審隊(duì)列，以考慮新的數(shù)據(jù)。分配工作與安排工作時(shí)間項(xiàng)目經(jīng)理一旦變更請(qǐng)求被置為已打開(kāi)，項(xiàng)目經(jīng)理就將根據(jù)請(qǐng)求的類型（例如，擴(kuò)展請(qǐng)求、缺陷、文檔變更、測(cè)試缺陷等）把工作分配給合適的角色，并對(duì)項(xiàng)目時(shí)間表做必要的更新。進(jìn)行變更指定的角色指定的角色執(zhí)行在流程的有關(guān)部分中指定的活動(dòng)集（例如，需求、分析設(shè)計(jì)、實(shí)施、制作用戶支持材料、設(shè)計(jì)測(cè)試等），以進(jìn)行所請(qǐng)求的變更。這些活動(dòng)將包括常規(guī)開(kāi)發(fā)流程中所述的所有常規(guī)復(fù)審活動(dòng)和

12、單元測(cè)試活動(dòng)。然后，變更請(qǐng)求將標(biāo)記為已解決。核實(shí)測(cè)試工作版本中的變更測(cè)試員指定的角色（分析員、開(kāi)發(fā)人員、測(cè)試員、技術(shù)文檔編寫(xiě)員等）解決變更后，變更將放置在要分配給測(cè)試員的測(cè)試隊(duì)列中，并在產(chǎn)品工作版本中加以核實(shí)。核實(shí)發(fā)布工作版本中的變更系統(tǒng)集成員已確定的變更一旦在產(chǎn)品的測(cè)試工作版本中得到了核實(shí)，就將變更請(qǐng)求放置在發(fā)布隊(duì)列中，以便在產(chǎn)品的發(fā)布工作版本予以核實(shí)、生成發(fā)布版本說(shuō)明等，然后關(guān)閉該變更請(qǐng)求。 變更過(guò)程中的變更請(qǐng)求狀態(tài)已提交出現(xiàn)此狀態(tài)的原因?yàn)椋?）提交新的變更請(qǐng)求；2）更新現(xiàn)有的變更請(qǐng)求；或3）考慮在新的發(fā)布周期中使用已推遲的變更請(qǐng)求。變更請(qǐng)求放置在CCB復(fù)審隊(duì)列中。本操作的結(jié)

13、果不會(huì)指定擁有者。已推遲變更請(qǐng)確定為有效，但對(duì)于當(dāng)前發(fā)布版來(lái)說(shuō)屬于超出范圍工處于已推遲狀態(tài)的變更請(qǐng)求將得以保留，并在以后的發(fā)布版中被重新考慮并加以使用?？梢灾付ㄒ粋€(gè)目標(biāo)發(fā)布版，以表明可以提交變更請(qǐng)求（以重新進(jìn)入CCB復(fù)審隊(duì)列）的時(shí)間范圍。重復(fù)處于此狀態(tài)的變更請(qǐng)求被視作對(duì)已提交的另一個(gè)變更請(qǐng)求的重復(fù)。變更請(qǐng)求可由CCB復(fù)審管理員或被指定解決它的角色置于該狀態(tài)中。將變更請(qǐng)求置于重復(fù)狀態(tài)中時(shí)，將（在ClearQuest的附件”選項(xiàng)卡上）記錄它所重復(fù)的那個(gè)變更請(qǐng)求的編號(hào)。在提交變更請(qǐng)求之前，提交者應(yīng)苜先查詢變更請(qǐng)求數(shù)據(jù)庫(kù)，看是否已有與之相重復(fù)的變更請(qǐng)求。這將省去復(fù)審流程中的若干步驟，從而節(jié)省大量的時(shí)間

14、。應(yīng)將重復(fù)變更請(qǐng)求的提交者添加到原始變更請(qǐng)求的通知列表中，以便以后將有關(guān)解決事宜通知他們。已拒絕CCB復(fù)審會(huì)議或指定的角色確定此狀態(tài)中的變更請(qǐng)求為無(wú)效請(qǐng)求，或者需要提交者提供更為詳細(xì)的信息。如果已經(jīng)指定（提出）變更請(qǐng)求，則它將從解決隊(duì)列中刪除并重新復(fù)審。這將由CCB所指定的權(quán)威來(lái)予以確認(rèn)。除非有必要，否則提交者無(wú)需進(jìn)行任何操作。在此情況下變更請(qǐng)求狀態(tài)將變?yōu)樵敿?xì)信息?？紤]到可能會(huì)有新的信息，在CCB復(fù)審會(huì)議中將重新復(fù)審該變更請(qǐng)求。如果變更請(qǐng)求確認(rèn)為無(wú)效，將被CCB關(guān)閉并且通知提交者。詳細(xì)信息數(shù)據(jù)不足以確認(rèn)已拒絕或重復(fù)的變更請(qǐng)求是否有效。擁有者自動(dòng)變成提交者，將通知提交者提供更多數(shù)據(jù)。已打開(kāi)對(duì)于當(dāng)

15、前發(fā)布版來(lái)說(shuō)，處于此狀態(tài)的變更請(qǐng)求已被確定為屬于范圍之內(nèi)”，并且亟待解決。它已定于在即將來(lái)臨的目標(biāo)里程碑之前得以解決。它被確定在指定隊(duì)列”中。與會(huì)者是提出變更請(qǐng)求并將其放入解決隊(duì)列中的唯一權(quán)威。如果發(fā)現(xiàn)優(yōu)先級(jí)為第二或更高的變更請(qǐng)求，應(yīng)立即通知QE經(jīng)理或開(kāi)發(fā)經(jīng)理。此時(shí)，他們可以決定召開(kāi)緊急CCB復(fù)審會(huì)議，或立即打開(kāi)變更請(qǐng)求以將其放入解決隊(duì)列中。已指定然后由項(xiàng)目經(jīng)理負(fù)責(zé)已打開(kāi)的變更請(qǐng)求，他應(yīng)根據(jù)變更請(qǐng)求的類型分配工作；如果需要，還應(yīng)更新時(shí)間表。已解決表不該變更請(qǐng)求已解決完畢，現(xiàn)在可以進(jìn)行核實(shí)了。如果提交者是QE部門(mén)的成員，則擁有者將自動(dòng)變成執(zhí)行提交的QE成員。否則，擁有者將變成QE經(jīng)理，以重新進(jìn)行

16、人工分配。測(cè)試已失敗在測(cè)試工作版本或發(fā)布工作版本中進(jìn)行測(cè)試時(shí)失敗的變更請(qǐng)求將置于此狀態(tài)中。擁有者自動(dòng)變成解決變更請(qǐng)求的角色。已核實(shí)處于此狀態(tài)的變更請(qǐng)求已經(jīng)在測(cè)試工作版本中得到了核實(shí)，并且可以進(jìn)行發(fā)布了。已關(guān)閉變更請(qǐng)求不再引人注意。這是可以指定給變更請(qǐng)求的最后-個(gè)狀態(tài)。只有CCB復(fù)審管理員有權(quán)關(guān)閉變更請(qǐng)求。變更請(qǐng)求被關(guān)閉后，提交者將收到一份有關(guān)對(duì)變更請(qǐng)求的最終處理結(jié)果的電子郵件通知。在下列情況中可能關(guān)閉變更請(qǐng)求：1）其已核實(shí)的解決結(jié)果在發(fā)布工作版本中得到確認(rèn)之后；2）其拒絕狀態(tài)得到確認(rèn)時(shí)；或3）被確認(rèn)為對(duì)現(xiàn)有變更請(qǐng)求的重復(fù)。在斤-種情況中，會(huì)將重復(fù)變更請(qǐng)求通知給提交者，并將提交者添加到該變更請(qǐng)求

17、中，以便以后通知他們（詳情請(qǐng)參見(jiàn)狀態(tài)拒絕"禾口重復(fù)”的定義）。如果提交者希望對(duì)關(guān)閉變更請(qǐng)求有異議，則必須更新變更請(qǐng)求并且重新將其提交供CCB復(fù)審。變更過(guò)程的變更請(qǐng)求狀態(tài)（狀態(tài)圖）： 保存變更歷史記錄如果工件為Word文檔，則在文檔的修訂文檔歷史記錄。如果工件為其他工件，必須在相應(yīng)的記錄中保存變更歷史紀(jì)錄。 變更請(qǐng)求中受影響配置項(xiàng)的變更在變更請(qǐng)求中受影響配置項(xiàng)需要變更時(shí)，首先由CCB協(xié)調(diào)員通知受影響配置項(xiàng)的變更人員，其次被通知人員按照標(biāo)準(zhǔn)變更流程進(jìn)行變更。5.4.2 變更控制委員會(huì)（CCB）.職責(zé)：CCB的基本任務(wù)是明確產(chǎn)品的基線、復(fù)審對(duì)基線的變更、最后批準(zhǔn)

18、、否決變更或延期執(zhí)行。.選擇成員標(biāo)準(zhǔn)：從用戶、開(kāi)發(fā)人員、測(cè)試小組、項(xiàng)目管理中選擇。.項(xiàng)目的CCB成員為：.CCB主席：.處理變更請(qǐng)求和確認(rèn)的過(guò)程：CCB以事觸發(fā)為主要工作方式，必須定期（每個(gè)階段結(jié)束時(shí)）按需召開(kāi)會(huì)議。確保變更提議及時(shí)得到了復(fù)審和處理。擬定變更復(fù)審?fù)ㄖ獏f(xié)議。確保變更請(qǐng)求提交后，各有關(guān)人員都得到了通知，決定由誰(shuí)復(fù)審各種工件。傳達(dá)給同事和團(tuán)隊(duì)負(fù)責(zé)人，以及變更提議的接受者，并讓他們有機(jī)會(huì)復(fù)審并參與意見(jiàn)。施皓CCB主席協(xié)調(diào)組織復(fù)審員需求復(fù)審復(fù)審員需求復(fù)審、架構(gòu)復(fù)審復(fù)審員架構(gòu)復(fù)審、代碼復(fù)審復(fù)審員代碼復(fù)審復(fù)審員測(cè)試復(fù)審協(xié)調(diào)員負(fù)責(zé)通知由誰(shuí)進(jìn)行復(fù)審3.3配置狀態(tài)統(tǒng)計(jì)項(xiàng)目介質(zhì)存儲(chǔ)和發(fā)布進(jìn)程項(xiàng)目介質(zhì)

19、保留策略、備份計(jì)劃、事故處理計(jì)劃、恢復(fù)計(jì)劃.備份機(jī)制及保留策略：1）每天實(shí)驗(yàn)結(jié)束時(shí)將主服務(wù)器的數(shù)據(jù)備份到ftp服務(wù)器中。2）即服務(wù)器只保留最近一周的備份。.事故處理和恢復(fù)機(jī)制：如果出現(xiàn)事故（如：主服務(wù)器當(dāng)機(jī)、遭病毒、硬件損壞等），采用ftp服務(wù)器上的數(shù)據(jù)進(jìn)行恢復(fù)。.防病毒/殺毒機(jī)制：殺毒/防病毒軟件：Antivir2）頻率：每日殺毒。3）負(fù)責(zé)人：系統(tǒng)管理員（施皓）。介質(zhì)保留方式：介質(zhì)保留方式：聯(lián)機(jī)。類型：移動(dòng)硬盤(pán)。格式：Windows的文件。報(bào)告和審計(jì)目的：讓項(xiàng)目經(jīng)理確定需要報(bào)告哪些產(chǎn)品的相關(guān)變更數(shù)據(jù)，以及報(bào)告人和報(bào)告頻率。頻率：每日/每個(gè)階段結(jié)束時(shí)進(jìn)行報(bào)告。報(bào)告人：配置管理經(jīng)理。1.基于變更請(qǐng)求的報(bào)告。發(fā)現(xiàn)Bug個(gè)數(shù)修復(fù)Bug個(gè)數(shù)Bug發(fā)現(xiàn)頻率（天）Bug修復(fù)頻率（天）就打開(kāi)的缺陷和關(guān)閉的缺陷而言，它們之間的質(zhì)量差距”有多大？解決缺陷所用的平均