《軟件項目管理計劃書》模板x

1、軟件項目管理計劃書項目名稱：時間：年月日目錄1. 簡介 331.1. 項目概述 331.2. 項目主要功能及性能 331.3. 項目交付產品 331.4. 參考資料 332. 項目組織 332.1. 過程模型 332.2. 團隊的分工與合作 443. 管理過程 443.1. 管理目標及優(yōu)先級 443.2. 風險管理 553.3. 監(jiān)督及控制機制 553.4. 人員計劃 553.5. 培訓計劃 663.6. 風險管理計劃 663.7. 項目配置計劃 773.8. 計劃更新策略 773.9. 項目溝通計劃 883.9.1. 項目組會議 883.9.2. 項目報告機制 883.10. 項目的重用計劃

2、 993.11. 質量保證活動 993.11.1. 內部審核 993.11.2. 階段審核 10104. 技術過程 10104.1. 開發(fā)工具、方法和技術 10104.2. 軟件需交付的文檔 10105. 開發(fā)進度安排及預算 11115.1. 進度表格描述 11115.2. 開發(fā)過程中的資源需求 11115.3. 軟件管理過程中預算及資源分配 12125.4. 項目進度及關鍵工期設置 12121. 簡介關鍵時間任務要求1.1. 項目概述12項目主要功能及性能13項目交付產品(1)提交文檔：項目管理計劃、需求規(guī)格說明，設計報告、測試報告、 用戶使用手冊和項目個人總結。其中項目總結為每人一份，每個

3、小組所有成 員的總結裝訂在一起；其余文檔每組提交一份。每個團隊可將各小組的文檔 綜合到一起，各小組也可自行分開提交，具體方式由團隊內部協(xié)商確定。所 有文檔需要提交電子版和打印稿。(2)源程序檢查：一共14參考資料2. 項目組織2.1. 過程模型22團隊的分工與合作主程序員負責制。本團隊組織關系圖如下成員角色職責3. 管理過程3.1. 管理目標及優(yōu)先級3.2. 風險管理3.3. 監(jiān)督及控制機制報告機制：1. 要求各組員以周為單位記錄工作進展，形成開發(fā)日志，并以電子文 檔的形式提交給秘書進行整理，最后由文檔維護員進行維護。2. 每周例會上各位組員積極對當前的開發(fā)工作進行積極的評審和建言，由組長做最

4、后的作口頭總結，由秘書主持會議并記錄和整理會議的內容。文 檔維護員修改和維護相應的文檔。并交由小組進行會議評審并給出意見。3. 組成員都要密切監(jiān)控風險狀態(tài)，發(fā)現(xiàn)風險后提交風險報告。由秘書 定期提交風險報告。必要時將突發(fā)風險通知所有組員，并由組長做出臨時處 理決定。然后在該周的例會上由組成員共同討論對風險的處理意見。并形成 風險處理的日志做為以后的經驗。報告格式：報告主題，時間段，發(fā)現(xiàn)人，報告內容，審核意見評審機制：每周例會上小組討論形成一致意見后即為通過， 相關負責人針對改進意 見開展下一周工作，嚴格執(zhí)行例會上鎖制定的決策。小組會議持續(xù)評估其成 效。每一項目階段結束之前（里程碑前后），組織一次

5、階段評審會，評估整 個階段的工作效率和成果質量。盡量與項目例會合并，并邀請組長和其他組 成員參加評議。亦可詢問領導的意見。對于重大的風險處理意見，應該由組 長及其他組組長組成評審團對處理意見進行審議和評估。并以評審團的決議 （亦可根據(jù)老師的建議）作為重要參考來制定決策。3.4. 人員計劃java 程序員： 要求：熟悉 java 編程和 jsp 開發(fā)平臺 界面設計員： 要求：熟悉 CSS、Photoshop 數(shù)據(jù)庫設計員：要求：熟悉SQL語句，熟練使用SQL Sever 2005 文檔維護員：要求：熟悉使用Word及Powerpoint溝通交流員： 要求：較強的溝通能力，能及時調解組內以及組與組

6、之間的矛盾 軟件測試人員：要求：熟練使用開發(fā)工具的debug工具，有耐性。3.5.培訓計劃在本節(jié)中，明確說明相應人員現(xiàn)有的水平、需要的技能、培訓方式和培訓效果評估方式信息。舉例如下：培訓計劃No培訓領域需要的技能 水平項目組成 員已具備的 技能水平培訓方式培訓效果評估 方式1233.6.風險管理計劃（可根據(jù)項目選擇來寫，沒有也可不寫）在此詳細說明項目的風險項、風險描述、風險級別、規(guī)避措施、應急計劃、 觸發(fā)條件。存在哪些技術、市場和財務風險？已確認的風險和假設是否已解決？有無遺留問題？有無新的風險和假設？提供簡潔的風險管理計劃。為了減少風險，在各階段必需做些什么？如果在 計劃的時間范圍內，這些風

7、險不能解決，有沒有準備其它的計劃？如果沒有這些風險，對項目會有哪些影響？與產品包相關的各方面的風險包括：市場/ 客戶風險；技術風險；財務風險；制造風險；采購風險；技術支持風險；項目風險3.7. 項目配置計劃（可根據(jù)項目選擇來寫，沒有也可不寫）3.8. 計劃更新策略在本節(jié)中， 應描述項目計劃的更新策略， 明確說明項目計劃更新的發(fā)布方法。 還要說明對項 目計劃進行變更控制和管理的機制以及其載體。以下文字僅供參考：在發(fā)生如下事件時，修訂項目計劃和參考文檔： 到達某里程碑，在每個階段結束后如果必要的話修訂項目計劃。 項目的范圍發(fā)生變化當風險成為現(xiàn)實時采取了相應的行動 當進度、工作量超出控制的范圍并需要

8、采取糾正行動時。當與上階段規(guī)模變化超過 +/-15%。 內部或外部審核導致的糾正活動 對修訂后的項目計劃按照項目管理規(guī)程來批準和簽發(fā)。項目計劃的更新， 存在階段驅動性更新和事件驅動性更新兩種類型。 階段驅動性更新是指在每一階段結束時，如果計劃或者工作量估計的變動超過 10，就需要對項目計劃進行更新；word 文檔可編輯 事件驅動性更新是指在計劃執(zhí)行過程中遇到項目突然變動或者其他影響項目正常運行的事 件發(fā)生，需要對項目的計劃進行更新。項目計劃更新需要對計劃文檔更新和項目里程碑計劃的更新。不論是階段驅動性更新還是時間驅動性更新都需要對項目的更新計劃進行評審，評審需要 PD經理、PQ以及功能領域代表

9、參加。39項目溝通計劃3.9.1.項目組會議列舉項目跟蹤、監(jiān)控的會議類型、頻率以及參加人員，可以采用列表形式參考下例：項目組會議No會議頻度參加人跟蹤機制1.階段結束會議2.項目總結會議3.3.9.2. 項目報告機制列舉項目跟蹤、監(jiān)控過程中需要出示的報告類型、頻率、報告人、匯報人信息 參考下例：項目報告機制No.報告準備人頻度向誰匯報1.項目狀態(tài)報告2.項目階段結束報告3.項目總結報告4.3.10.項目的重用計劃需要對公司其他產品在本產品中實現(xiàn)重用進行分析以及本產品可以共享給公司的其他 產品以供重用，可以直接鏈接相應的文檔或者在此加以說明?，F(xiàn)有重用構件1SI.No構件/文檔名采用階段(If a

10、pplicable)重用構件的資產ID12新增重用構件2序 號構件/文檔名需求/文檔id說明123.11.質量保證活動羅列應該執(zhí)行的質量保證活動舉例如下：3.11.1.內部審核每個項目在開發(fā)生命周期中至少進行一次內部審核。3.11.2.階段審核規(guī)劃在哪些階段點需要進行基線審核技術評審 1之后技術評審 2之后技術評審 3之后技術評審 4之后技術評審 5之后技術評審 6之后4. 技術過程4.1. 開發(fā)工具、方法和技術4.2. 軟件需交付的文檔1軟件項目管理計劃 該文檔由組長完成，介紹項目的整個管理過程。該文檔在軟件設計需求分析初級階段完成，后續(xù)階段由文檔維護員進行相應的更新。2. 需求規(guī)格說明初稿

11、 在需求分析階段，由全體小組成員采集分析用戶的需求，并在例會上作 出決策，有文檔維護員撰寫整理需求規(guī)格說明初稿，并在后續(xù)各個階段進行 需求變更的更新。3. 設計報告初稿 在總體設計階段，小組根據(jù)需求規(guī)格說明文檔，完成軟件體系結構的設 計，由組長編寫軟件體系結構設計文檔初稿， 并在后續(xù)開發(fā)階段補充和更新。 該文檔由文檔維護員負責維護更新。4. 測試文檔在軟件開發(fā)階段， 測試人員需要編寫測試規(guī)格說明文檔， 并在后續(xù)測試階 段更新。開發(fā)人員將根據(jù)測試規(guī)格說明文檔建立測試環(huán)境、準備測試數(shù)據(jù)。 5用戶手冊在更新用需求分析階段，測試人員需要開始著手編寫用戶手冊，并在需 求分析結束后需要形成初稿；在后續(xù)階段不斷由文檔維護員戶文檔；并在系統(tǒng)交付階段隨著系統(tǒng)一起被交付6.個人項目總結由組內成員各自獨立完成，對開發(fā)過程中獲得的工作經驗進行總結。在 提交系統(tǒng)時一并提交。7. 其他文檔軟件開發(fā)過程中的其他文檔，如開發(fā)日志（按組員意見選擇公開與否） 風險報告及其處理意見等，由秘書進行整理與匯聚。作為以后軟件開發(fā)以及 交流的經驗。5.開發(fā)進度安排及預算5.1.進度表格描述工作集子工作完成時間負責人最終交付物描述52開發(fā)過程中的資源需求人員：小組軟件項目開發(fā)成員支持