項目經(jīng)理總結(jié)報告范文

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

第1篇

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

二、范圍

中心機房，共計3個機房區(qū)域。

三、定義

3.1一級故障：

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

3.2二級故障：

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

3.3三級故障：

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

四、故障報告原則

先搶修，同報告；先核心，后邊緣；先始端，后末端，分故障等級進行處理。

五、故障（事故）類型

5.1一級故障

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

5.2二級故障

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

5.3三級故障

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

六、故障報告流程

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

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

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

七、故障處置方法

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

第2篇

 

 

一、 測試組組成測試組由測試組長和測試工程師組成。

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

（一）  測試組長工作職責： 

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

 

2、 對各個項目的測試工作進行統(tǒng)籌安排，并對各個項目的 測試工作進行計劃、分工和管理；

3、 定期或不定期與各個項目負責人溝通項目進度，隨時了 解項目進展情況；

4、 對測試組成員的日常工作進行評審考核；

 

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

 

6、 參與日常的軟件測試工作。

 

（二）  測試工程師工作職責： 

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

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

 

3、按照測試計劃編寫測試用例，保證測試用例合理有效；

 

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

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

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

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

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

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

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

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

3、 召開測試啟動會議，會議內(nèi)容包括：開發(fā)團隊與測試組 交接測試內(nèi)容，對測試目標達成一致，商討測試計劃，

 

統(tǒng)一項目組的目標和測試的工作重點；

 

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

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

 

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

l測試方案：整體測試的測試方法和每個測試需求的測 試方法；

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

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

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

l文檔報告：確定在項目測試過程中需要提交的測試計 劃，測試報告等；

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

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

 

足全部的測試需求。

 

（二）  測試實施階段 

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

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

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

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

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

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

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

3、 測試文檔歸檔：測試驗收結(jié)束后，對測試過程中涉及到 的各種標準文檔進行歸類、存檔。相關(guān)文檔包括：測試 任務(wù)書、測試計劃書、測試用例、測試報告書、測試總 結(jié)報告、測試驗收報告等。

 

 

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

第3篇

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

【中圖分類號】C29【文獻標識碼】A【文章編號】1672-5158（2013）07-0492-02

一、 引言

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

二、 配置管理流程

2.1制定配置管理計劃

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

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

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

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

2.2 項目配置庫的建立

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

2.3 配置識別

配置識別的目的是識別配置項和基線。

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

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

配置識別活動包括以下幾個內(nèi)容：

* 配置項識別

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

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

* 配置項標識

配置項的標識，版本等規(guī)則，參見企業(yè)標識規(guī)范。

* 基線建立

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

> 基線建立

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

> 基線變更

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

2.4 版本控制

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

* 標簽

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

* 分支

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

2.5變更控制

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

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

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

1） 變更請求

2） 變更審核

3） 配置項出庫

4） 變更實施

5） 變更驗證

6） 配置項入庫

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

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

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

2） 迭代模型中管理變更

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

2.6配置審計

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

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

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

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

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

> 審核配置項一致性，具體檢查點如下：

* 參照配置管理計劃檢查配置項是否按時提交；

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

配置項信息是否正確；

配置項評審記錄、變更記錄是否完備等。

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

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

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

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

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

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

> 周報告

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

> 總結(jié)報告

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

2.8 配置中止

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

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

三、 結(jié)束語

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

參考文獻