前言：我們精心挑選了數(shù)篇優(yōu)質(zhì)項(xiàng)目經(jīng)理總結(jié)報(bào)告文章，供您閱讀參考。期待這些文章能為您帶來(lái)啟發(fā)，助您在寫作的道路上更上一層樓。

第1篇

加強(qiáng)和規(guī)范化中心機(jī)房基礎(chǔ)設(shè)施故障（事故）的報(bào)告和處置流程，提高運(yùn)維保障效率，保證故障（事故）的快速反應(yīng)并及時(shí)修復(fù)、恢復(fù)，使損失降低到最低。

二、范圍

中心機(jī)房，共計(jì)3個(gè)機(jī)房區(qū)域。

三、定義

3.1一級(jí)故障：

故障影響范圍小，不會(huì)對(duì)業(yè)務(wù)系統(tǒng)造成中斷影響，并且不會(huì)對(duì)其它系統(tǒng)使用造成影響。

3.2二級(jí)故障：

關(guān)鍵系統(tǒng)單個(gè)設(shè)備或獨(dú)立系統(tǒng)故障，造成單個(gè)或局部業(yè)務(wù)系統(tǒng)中斷，不會(huì)造成重大業(yè)務(wù)系統(tǒng)運(yùn)行中斷，不會(huì)造成關(guān)鍵系統(tǒng)運(yùn)行中斷。

3.3三級(jí)故障：

外部出現(xiàn)供水、供電、網(wǎng)絡(luò)系統(tǒng)等中斷，關(guān)鍵性系統(tǒng)造成大面積中斷。涉及到外協(xié)單位修復(fù)，并且無(wú)法在短時(shí)間（2小時(shí)）內(nèi)恢復(fù)，可能造成重大損失。

四、故障報(bào)告原則

先搶修，同報(bào)告；先核心，后邊緣；先始端，后末端，分故障等級(jí)進(jìn)行處理。

五、故障（事故）類型

5.1一級(jí)故障

單臺(tái)的機(jī)柜PDU斷電、單臺(tái)UPS及空調(diào)關(guān)鍵設(shè)備報(bào)警、機(jī)房溫度上升到30℃以上、空調(diào)漏水影響到其他區(qū)域等。

5.2二級(jí)故障

單臺(tái)UPS電源故障停機(jī)、單臺(tái)空調(diào)機(jī)組故障停機(jī)、環(huán)控系統(tǒng)無(wú)法檢測(cè)數(shù)據(jù)、機(jī)房溫度超過(guò)35℃等。

5.3三級(jí)故障

UPS前端供電中斷、空調(diào)配電柜前端供電中斷、空調(diào)冷凍水供水中斷（失壓）、機(jī)房溫度超過(guò)40℃、網(wǎng)絡(luò)中斷等。

六、故障報(bào)告流程

6.1當(dāng)發(fā)現(xiàn)一級(jí)故障的情況下，當(dāng)班運(yùn)維人員首先進(jìn)行故障確認(rèn)，確認(rèn)故障后進(jìn)行一般性修復(fù)，無(wú)法修復(fù)的設(shè)備及時(shí)通報(bào)運(yùn)維管理負(fù)責(zé)人以及數(shù)據(jù)中心當(dāng)日的值班民警，運(yùn)維負(fù)責(zé)人通知相應(yīng)的技術(shù)工程師到場(chǎng)維修。事故恢復(fù)后形成事故總結(jié)報(bào)告。

6.2當(dāng)發(fā)現(xiàn)二級(jí)故障的情況下，當(dāng)班運(yùn)維人員首先通知運(yùn)維負(fù)責(zé)人以及數(shù)據(jù)中心當(dāng)日值班民警，值班民警及運(yùn)維負(fù)責(zé)人及時(shí)趕到現(xiàn)場(chǎng)，同時(shí)判斷故障產(chǎn)生的原因。值班民警、運(yùn)維負(fù)責(zé)人和相應(yīng)專業(yè)技術(shù)工程師協(xié)調(diào)溝通相關(guān)部門，相關(guān)單位派維修工程師進(jìn)駐現(xiàn)場(chǎng)解決，短時(shí)間（1小時(shí)）無(wú)法解決的通知項(xiàng)目經(jīng)理，值班民警及時(shí)通知數(shù)據(jù)中心主管領(lǐng)導(dǎo)。事故恢復(fù)后形成事故總結(jié)報(bào)告。

6.3當(dāng)發(fā)現(xiàn)三級(jí)故障情況下，當(dāng)班運(yùn)維人員首先通知運(yùn)維負(fù)責(zé)人、項(xiàng)目經(jīng)理以及值班民警并告知物業(yè)管理部門相關(guān)人員。值班民警、項(xiàng)目經(jīng)理及運(yùn)維負(fù)責(zé)人及時(shí)趕到現(xiàn)場(chǎng)，判斷故障產(chǎn)生原因上報(bào)公司上級(jí)領(lǐng)導(dǎo)，值班民警上報(bào)主管領(lǐng)導(dǎo)和數(shù)據(jù)中心主要領(lǐng)導(dǎo)。由相應(yīng)的數(shù)據(jù)中心領(lǐng)導(dǎo)、項(xiàng)目經(jīng)理及物業(yè)部領(lǐng)導(dǎo)聯(lián)系外協(xié)單位進(jìn)行解決。事故恢復(fù)后形成事故總結(jié)報(bào)告。

七、故障處置方法

7.1一級(jí)故障的情況下，現(xiàn)場(chǎng)運(yùn)維人員主動(dòng)解決故障，運(yùn)維負(fù)責(zé)人及時(shí)聯(lián)系專業(yè)工程師到場(chǎng)解決故障。值班民警現(xiàn)場(chǎng)關(guān)注解決故障進(jìn)程，并且配合解決外部單位協(xié)調(diào)工作。

第2篇

 

 

一、 測(cè)試組組成測(cè)試組由測(cè)試組長(zhǎng)和測(cè)試工程師組成。

二、 測(cè)試組工作職責(zé)負(fù)責(zé)理解軟件產(chǎn)品的功能要求，搭建配套的測(cè)試環(huán)境，然后 對(duì)其進(jìn)行系統(tǒng)測(cè)試，檢查軟件有沒(méi)有錯(cuò)誤 (Bug)，決定軟件是否 具有穩(wěn)定性 (Robustness)，并寫出相應(yīng)的測(cè)試用例、各階段測(cè)試 報(bào)告。

（一）  測(cè)試組長(zhǎng)工作職責(zé)： 

1、 協(xié)調(diào)測(cè)試組與各個(gè)項(xiàng)目組之間的流程及工作關(guān)系；

 

2、 對(duì)各個(gè)項(xiàng)目的測(cè)試工作進(jìn)行統(tǒng)籌安排，并對(duì)各個(gè)項(xiàng)目的 測(cè)試工作進(jìn)行計(jì)劃、分工和管理；

3、 定期或不定期與各個(gè)項(xiàng)目負(fù)責(zé)人溝通項(xiàng)目進(jìn)度，隨時(shí)了 解項(xiàng)目進(jìn)展情況；

4、 對(duì)測(cè)試組成員的日常工作進(jìn)行評(píng)審考核；

 

5、 定期或不定期向部門總監(jiān)匯報(bào)工作情況；

 

6、 參與日常的軟件測(cè)試工作。

 

（二）  測(cè)試工程師工作職責(zé)： 

1、 仔細(xì)閱讀項(xiàng)目規(guī)格說(shuō)明、設(shè)計(jì)文檔、使用說(shuō)明書等，充 分掌握軟件的性能、特點(diǎn)、使用方法、業(yè)務(wù)流程等，協(xié) 助測(cè)試組長(zhǎng)制定項(xiàng)目的測(cè)試計(jì)劃；

2、 依據(jù)項(xiàng)目要求，搭建相應(yīng)的測(cè)試環(huán)境，維護(hù)測(cè)試設(shè)備；

 

3、按照測(cè)試計(jì)劃編寫測(cè)試用例，保證測(cè)試用例合理有效；

 

4、 根據(jù)測(cè)試計(jì)劃及測(cè)試案例，執(zhí)行測(cè)試，并根據(jù)產(chǎn)品特點(diǎn) 及測(cè)試要求，實(shí)施集成測(cè)試、系統(tǒng)測(cè)試等，及時(shí)發(fā)現(xiàn)軟 件缺陷，評(píng)估軟件的特性與缺陷；

5、 詳細(xì)記錄測(cè)試過(guò)程，編寫測(cè)試報(bào)告和對(duì)測(cè)試結(jié)果進(jìn)行分 析，通過(guò)測(cè)試，掌握軟件具有的能力、缺陷、局限等， 對(duì)軟件質(zhì)量給出評(píng)價(jià)性的結(jié)論與意見，整理測(cè)試文檔， 填寫軟件測(cè)試報(bào)告,編寫測(cè)試總結(jié)，為軟件開發(fā)成果提供 總結(jié)性意見；

6、 配合研發(fā)部門各項(xiàng)軟件產(chǎn)品，并詳細(xì)編寫產(chǎn)品 通知單；

7、 完成上級(jí)及部門其他領(lǐng)導(dǎo)交辦的臨時(shí)任務(wù)。

三、 測(cè)試組工作流程測(cè)試組的工作與項(xiàng)目開發(fā)進(jìn)度緊密相關(guān)，所以測(cè)試的工作流 程依據(jù)開發(fā)進(jìn)度分階段進(jìn)行大致分為以下幾個(gè)階段：

（一）  計(jì)劃和設(shè)計(jì)階段 

1、 項(xiàng)目組成立時(shí)，確定項(xiàng)目需求及項(xiàng)目設(shè)計(jì)方案，了解軟 件產(chǎn)品的主體功能及實(shí)現(xiàn)目的；

2、 項(xiàng)目經(jīng)理下發(fā)測(cè)試預(yù)通知，通知內(nèi)容包括：正式交接測(cè) 試時(shí)間、測(cè)試規(guī)模預(yù)計(jì)估算等信息；

3、 召開測(cè)試啟動(dòng)會(huì)議，會(huì)議內(nèi)容包括：開發(fā)團(tuán)隊(duì)與測(cè)試組 交接測(cè)試內(nèi)容，對(duì)測(cè)試目標(biāo)達(dá)成一致，商討測(cè)試計(jì)劃，

 

統(tǒng)一項(xiàng)目組的目標(biāo)和測(cè)試的工作重點(diǎn)；

 

4、 編寫測(cè)試計(jì)劃及相關(guān)文檔，依據(jù)測(cè)試啟動(dòng)會(huì)議中確定的 目標(biāo)和重點(diǎn)，結(jié)合項(xiàng)目經(jīng)理下發(fā)的《測(cè)試任務(wù)書》，編寫

《測(cè)試計(jì)劃書》（見附件一）。計(jì)劃書的內(nèi)容應(yīng)該包括：

 

l測(cè)試需求：需要測(cè)試組測(cè)試的范圍，估算出測(cè)試所花 費(fèi)的人力資源和各個(gè)測(cè)試需求的測(cè)試優(yōu)先級(jí)；

l測(cè)試方案：整體測(cè)試的測(cè)試方法和每個(gè)測(cè)試需求的測(cè) 試方法；

l測(cè)試資源：本次測(cè)試所需要的人力、軟件、硬件及技 術(shù)資源；

l   測(cè)試組角色：明確測(cè)試組人員的工作內(nèi)容及相關(guān)職責(zé)；

l里程碑：明確項(xiàng)目進(jìn)行過(guò)程中的測(cè)試組應(yīng)該關(guān)注的里 程碑；

l文檔報(bào)告：確定在項(xiàng)目測(cè)試過(guò)程中需要提交的測(cè)試計(jì) 劃，測(cè)試報(bào)告等；

l測(cè)試計(jì)劃編寫完畢后，需提交給全體項(xiàng)目組成員，由 項(xiàng)目成員綜合評(píng)審后，確定最終《測(cè)試計(jì)劃書》（見 附件二）。項(xiàng)目經(jīng)理要以此為依據(jù)，跟蹤監(jiān)控項(xiàng)目測(cè) 試進(jìn)度，評(píng)估測(cè)試計(jì)劃的可行性，完整性，并且在項(xiàng) 目結(jié)束后評(píng)估測(cè)試質(zhì)量。

5、 設(shè)計(jì)測(cè)試用例，依據(jù)《測(cè)試計(jì)劃書》相關(guān)內(nèi)容，根據(jù)每 一步測(cè)試計(jì)劃編寫全部的測(cè)試用例，測(cè)試用例必須能滿

 

足全部的測(cè)試需求。

 

（二）  測(cè)試實(shí)施階段 

1、 實(shí)施測(cè)試用例，測(cè)試工程師依據(jù)《測(cè)試計(jì)劃書》中分配 的測(cè)試任務(wù)和測(cè)試用例，實(shí)施相應(yīng)的測(cè)試工作，并詳細(xì) 記錄測(cè)試過(guò)程及結(jié)果。

2、 提交測(cè)試報(bào)告，在實(shí)施測(cè)試用例的過(guò)程中，依據(jù)記錄的 測(cè)試過(guò)程和結(jié)果，填寫《測(cè)試報(bào)告書》，并由測(cè)試組長(zhǎng)審 批后，上報(bào)項(xiàng)目經(jīng)理。項(xiàng)目經(jīng)理安排開發(fā)組修改相應(yīng)的 軟件產(chǎn)品。測(cè)試報(bào)告內(nèi)容包括：測(cè)試產(chǎn)品版本、測(cè)試人 員、測(cè)試時(shí)間、測(cè)試過(guò)程、產(chǎn)品運(yùn)行BUG、產(chǎn)品缺陷狀態(tài)、 急待解決的問(wèn)題。

3、 回歸測(cè)試，接到開發(fā)組的回歸測(cè)試通知后，測(cè)試組重新 拷貝修改后的最新版本，進(jìn)行回歸測(cè)試。回歸測(cè)試的用 例屬于測(cè)試用例的一部分或者全部測(cè)試用例，但不能超 出測(cè)試用例的范圍。

（三）  測(cè)試總結(jié)階段 

1、 編寫測(cè)試總結(jié)報(bào)告：回歸測(cè)試全部通過(guò)完成后，由測(cè)試 組長(zhǎng)整理填寫《測(cè)試總結(jié)報(bào)告》，報(bào)告主要內(nèi)容包括： 測(cè)試資源描述——參與測(cè)試人數(shù)，耗用測(cè)試時(shí)間； 測(cè)試結(jié)果摘要——描述各個(gè)測(cè)試需求的測(cè)試結(jié)果和功能 實(shí)現(xiàn)情況； 缺陷分析——按照缺陷的屬性分類進(jìn)行分析；

測(cè)試需求覆蓋率——如果在測(cè)試過(guò)程中未覆蓋到的測(cè)試 需求，在此應(yīng)詳細(xì)說(shuō)明原因； 測(cè)試評(píng)估——對(duì)此次項(xiàng)目質(zhì)量進(jìn)行評(píng)估； 測(cè)試組建議——從測(cè)試組角度為項(xiàng)目組提出工作建議。

2、 測(cè)試驗(yàn)收：項(xiàng)目經(jīng)理收到測(cè)試組長(zhǎng)提交的測(cè)試總結(jié)報(bào)告 后，對(duì)此次測(cè)試工作進(jìn)行驗(yàn)收。驗(yàn)收內(nèi)容包括：測(cè)試效 果驗(yàn)收、測(cè)試文檔驗(yàn)收、測(cè)試工作評(píng)估、測(cè)試工作建議， 簽字驗(yàn)收后，宣布此次測(cè)試結(jié)束。

3、 測(cè)試文檔歸檔：測(cè)試驗(yàn)收結(jié)束后，對(duì)測(cè)試過(guò)程中涉及到 的各種標(biāo)準(zhǔn)文檔進(jìn)行歸類、存檔。相關(guān)文檔包括：測(cè)試 任務(wù)書、測(cè)試計(jì)劃書、測(cè)試用例、測(cè)試報(bào)告書、測(cè)試總 結(jié)報(bào)告、測(cè)試驗(yàn)收?qǐng)?bào)告等。

 

 

（四）  產(chǎn)品階段 

第3篇

【關(guān)鍵詞】中小企業(yè)、配置管理流程

【中圖分類號(hào)】C29【文獻(xiàn)標(biāo)識(shí)碼】A【文章編號(hào)】1672-5158（2013）07-0492-02

一、 引言

軟件配置管理的發(fā)展在國(guó)內(nèi)雖然是21世紀(jì)的事，但是發(fā)展比較迅速，得到了軟件公司的普遍認(rèn)可。但是對(duì)于中小公司，由于重視不夠或缺少相關(guān)知識(shí)，在實(shí)際使用中存在一些問(wèn)題。中小公司照搬大公司流程存在也不切合實(shí)際。

二、 配置管理流程

2.1制定配置管理計(jì)劃

在《項(xiàng)目開發(fā)計(jì)劃》完成后，配置管理員（SCME）參考項(xiàng)目經(jīng)理制定的《項(xiàng)目開發(fā)計(jì)劃》完成《配置管理計(jì)劃》，《配置管理計(jì)劃》中需要明確項(xiàng)目的基線配置項(xiàng)計(jì)劃，以及基線計(jì)劃等信息。

不同的項(xiàng)目，配置管理計(jì)劃的內(nèi)容可以不同。主要受以下方面影響：

項(xiàng)目的大小和復(fù)雜性會(huì)影響到配置管理計(jì)劃。特別簡(jiǎn)單的項(xiàng)目可能只需要一個(gè)配置管理工具，簡(jiǎn)單管理一下源代碼；但是大項(xiàng)目、復(fù)雜的項(xiàng)目則需要詳細(xì)的配置計(jì)劃。

特殊的項(xiàng)目需要更詳細(xì)的計(jì)劃。舉例來(lái)說(shuō)，如果企業(yè)中絕大多數(shù)產(chǎn)品都是完整獨(dú)立開發(fā)，而某產(chǎn)品使用了開源代碼。那么在該項(xiàng)目的配置計(jì)劃中，此點(diǎn)就要考慮。

2.2 項(xiàng)目配置庫(kù)的建立

項(xiàng)目立項(xiàng)后，項(xiàng)目經(jīng)理通知配置管理員建立項(xiàng)目的配置庫(kù)，同時(shí)為項(xiàng)目組人員開放配置庫(kù)權(quán)限。

2.3 配置識(shí)別

配置識(shí)別的目的是識(shí)別配置項(xiàng)和基線。

配置項(xiàng)是指處于配置管理之下的軟件或/和硬件的集合體。這個(gè)集合體在配置管理過(guò)程中作為一個(gè)實(shí)體出現(xiàn)。

基線是已經(jīng)通過(guò)正式復(fù)審和批準(zhǔn)的某規(guī)約或產(chǎn)品，它因此可以作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只能通過(guò)正式的變更控制過(guò)程來(lái)改變。

配置識(shí)別活動(dòng)包括以下幾個(gè)內(nèi)容：

* 配置項(xiàng)識(shí)別

配置項(xiàng)可以分為基線配置項(xiàng)和非基線配置項(xiàng)。基線配置項(xiàng)包括所有的技術(shù)類文檔和源程序等；非基線配置項(xiàng)包括項(xiàng)目的各類計(jì)劃和報(bào)告等。

配置管理工作的關(guān)注重點(diǎn)是基線配置項(xiàng)。配置項(xiàng)識(shí)別由SCME參照項(xiàng)目開發(fā)計(jì)劃中的交付物，同項(xiàng)目經(jīng)理共同識(shí)別基線配置項(xiàng)，以及配置項(xiàng)間的依賴關(guān)系。配置管理員需要完成《配置管理計(jì)劃》中的配置項(xiàng)計(jì)劃。

* 配置項(xiàng)標(biāo)識(shí)

配置項(xiàng)的標(biāo)識(shí)，版本等規(guī)則，參見企業(yè)標(biāo)識(shí)規(guī)范。

* 基線建立

一般在項(xiàng)目的不同階段有對(duì)應(yīng)的基線。

> 基線建立

當(dāng)基線包含的配置項(xiàng)穩(wěn)定后，由項(xiàng)目經(jīng)理通知SCME建立基線。基線建立后一般不允許隨意更改。SCME需要對(duì)基線庫(kù)的權(quán)限進(jìn)行設(shè)置。

> 基線變更

當(dāng)基線建立后，如果基線配置項(xiàng)經(jīng)過(guò)若干次變更，在配置項(xiàng)穩(wěn)定后，項(xiàng)目經(jīng)理認(rèn)為有必要進(jìn)行變更（再等），或者基線不穩(wěn)定，需要回朔到上一基線，由項(xiàng)目經(jīng)理通知SCME對(duì)基線進(jìn)行變更。

2.4 版本控制

版本控制能夠簡(jiǎn)單、明確地重現(xiàn)軟件系統(tǒng)的歷史版本。一般的配置工具都能自動(dòng)保存配置項(xiàng)的版本歷史，但是大多時(shí)候，針對(duì)項(xiàng)目不同階段需要整體化的標(biāo)識(shí)。以下是整體化版本控制的方法：

* 標(biāo)簽

如果項(xiàng)目只有一個(gè)主干，只需要通過(guò)打標(biāo)簽的方式，來(lái)辨明當(dāng)前的整體版本。這樣將來(lái)搜索所有的以這個(gè)整體版本命名的標(biāo)簽，就能找到這個(gè)整體版本對(duì)應(yīng)的所有文件的正確版本，包括源代碼。

* 分支

不同的客戶，基本需求一定，但是有不同的差別，此時(shí)就需要用到分支。使用分支，能夠有效地實(shí)現(xiàn)隔離，也實(shí)現(xiàn)共享。但是分支是有管理成本的。如果標(biāo)準(zhǔn)版的比較頻繁，而客戶又要求變體的跟上標(biāo)準(zhǔn)版的話，那么需要頻繁創(chuàng)建分支。另一方面，如果變體所在的分支上，包含了一些應(yīng)該共享的改動(dòng)，那么應(yīng)該合并到主干。這樣，相應(yīng)管理成本也會(huì)提高。

2.5變更控制

在項(xiàng)目開發(fā)過(guò)程中，配置項(xiàng)發(fā)生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項(xiàng)被隨意修改而導(dǎo)致混亂。

在瀑布模型的管理中：修改處于“草稿”狀態(tài)的配置項(xiàng)不算是“變更”。當(dāng)配置項(xiàng)的狀態(tài)成為“正式”，或者被“凍結(jié)”后，此時(shí)任何人都不能隨意修改，必須依據(jù)變更的規(guī)則執(zhí)行。

以下為變更規(guī)則：

1） 變更請(qǐng)求

2） 變更審核

3） 配置項(xiàng)出庫(kù)

4） 變更實(shí)施

5） 變更驗(yàn)證

6） 配置項(xiàng)入庫(kù)

SCME負(fù)責(zé)實(shí)施配置項(xiàng)入庫(kù)，確保配置項(xiàng)處于“正式”狀態(tài)，并且版本正確。并通知項(xiàng)目經(jīng)理，項(xiàng)目組人員，質(zhì)量保證人員等變更已經(jīng)完成。

但是還有兩種情況，可能不需要嚴(yán)格的變更流程：

1） 功能小變動(dòng)：把程序已有的功能，稍微增強(qiáng)或改變一下。特點(diǎn)是：數(shù)量多容易丟，改動(dòng)量不太大。對(duì)這類請(qǐng)求的管理，建議像對(duì)缺陷的管理，進(jìn)行分別跟蹤、處理，直至解決。

2） 迭代模型中管理變更

迭代開發(fā)把一個(gè)大項(xiàng)目在時(shí)間軸上分解成很多小項(xiàng)目，每個(gè)小項(xiàng)目被稱作一個(gè)迭代。幾乎每次迭代，都會(huì)包含需求分析，系統(tǒng)設(shè)計(jì)、代碼實(shí)現(xiàn)，以及集成和測(cè)試。這樣就不必刻意走變更流程，只要通過(guò)基線或標(biāo)簽的方式就可以對(duì)配置項(xiàng)進(jìn)行識(shí)別。但是在每一個(gè)迭代中，出現(xiàn)的對(duì)正式的配置項(xiàng)進(jìn)行修改，還需要走變更流程。

2.6配置審計(jì)

配置審計(jì)是對(duì)交付的軟件基線進(jìn)行檢驗(yàn)，以驗(yàn)證其中包含了所有必需的內(nèi)容，并且這些內(nèi)容本身都是經(jīng)過(guò)驗(yàn)證而滿足了需求。配置審計(jì)分為功能審計(jì)和物理審計(jì)兩種：

1） 功能審計(jì)是一種驗(yàn)證審核，它驗(yàn)證配置項(xiàng)的開發(fā)是否完全滿足特定的性能和功能特性，并且所有的操作和支持文檔是齊備的。功能審計(jì)主要方法有評(píng)審、測(cè)試等。一般由研發(fā)人員和測(cè)試人員來(lái)做。

2） 物理審計(jì)的目的是為了驗(yàn)證配置項(xiàng)是按照技術(shù)文檔中的規(guī)定構(gòu)建的。

物理審計(jì)工作主要由配置管理人員定期（每月）執(zhí)行。也可因事件驅(qū)動(dòng)進(jìn)行，比如配置項(xiàng)，新版本等。

主要進(jìn)行以下內(nèi)容：

> 審核配置項(xiàng)一致性，具體檢查點(diǎn)如下：

* 參照配置管理計(jì)劃?rùn)z查配置項(xiàng)是否按時(shí)提交；

配置項(xiàng)是否滿足配置管理相關(guān)規(guī)定，如配置項(xiàng)標(biāo)識(shí)，版本，狀態(tài)，版式等；

配置項(xiàng)信息是否正確；

配置項(xiàng)評(píng)審記錄、變更記錄是否完備等。

審核配置項(xiàng)版本一致性：檢查配置管理工作表中配置項(xiàng)版本信息與配置庫(kù)中配置項(xiàng)版本信息是否一致，以免工作疏漏造成不一致情況。

審核基線一致性：檢查配置管理工作表中基線內(nèi)容與配置庫(kù)中基線信息是否一致。

審核結(jié)構(gòu)權(quán)限一致性：檢查配置庫(kù)結(jié)構(gòu)權(quán)限是否合理，是否滿足安全適用需要。

2.7配置狀態(tài)報(bào)告

配置狀態(tài)報(bào)告工作主要由SCME定期執(zhí)行。也可因事件驅(qū)動(dòng)進(jìn)行，比如階段總結(jié)，階段評(píng)審等。

常用的配置狀態(tài)報(bào)告分為：

> 周報(bào)告

周報(bào)告每周進(jìn)行，主要內(nèi)容為本周開展的關(guān)于SCM的活動(dòng)總結(jié)，以及對(duì)SCM工作發(fā)現(xiàn)的問(wèn)題的跟蹤。周報(bào)告的審閱人為項(xiàng)目經(jīng)理、質(zhì)量部經(jīng)理。

> 總結(jié)報(bào)告

總結(jié)報(bào)告主要用于項(xiàng)目結(jié)束時(shí)，或者因事件驅(qū)動(dòng)而對(duì)SCM工作的當(dāng)前狀態(tài)進(jìn)行概括總結(jié)。總結(jié)報(bào)告的審閱人為項(xiàng)目經(jīng)理、質(zhì)量部經(jīng)理。

2.8 配置中止

當(dāng)項(xiàng)目結(jié)束時(shí)，由項(xiàng)目經(jīng)理確認(rèn)此項(xiàng)目已不會(huì)再有配置管理方面的變更，由項(xiàng)目經(jīng)理通知配置管理員項(xiàng)目關(guān)閉。

配置管理員關(guān)閉該項(xiàng)目的所有讀寫權(quán)限，并將項(xiàng)目基準(zhǔn)庫(kù)內(nèi)容移入產(chǎn)品庫(kù)中。該項(xiàng)目配置管理活動(dòng)中止。

三、 結(jié)束語(yǔ)

本文對(duì)配置管理各環(huán)節(jié)都根據(jù)實(shí)際進(jìn)行了簡(jiǎn)化變通，或提供了方法，對(duì)中小企業(yè)的配置工作有一定的借鑒意義。

參考文獻(xiàn)