軟件研發(fā)管理制度

1、軟件研發(fā)管理制度軟件研發(fā)管理制度 文件標識：lolaage-software-pm 當前版本：0.1.2 作 者：宋孝光 文件狀態(tài)： 草稿 正式發(fā)布 正在修改 完成日期：2012/3/27 版本/狀態(tài)作者參與者修改日期備注 0.1.1宋孝光2012/3/26第一版草稿 0.1.2宋孝光2012/3/27整理目錄 目錄 1 軟件研發(fā)制度綜述軟件研發(fā)制度綜述 .3 1.1 精簡模型精簡模型 .3 1.2 精簡過程域的目的精簡過程域的目的 .4 1.3 精簡模型精簡模型 文檔結(jié)構(gòu)與規(guī)范細分文檔結(jié)構(gòu)與規(guī)范細分 .5 1.4 精簡模型精簡模型 角色與職責表角色與職責表 .6 1.5 公司軟件過程的政策公

2、司軟件過程的政策 .8 1.5.1 目標.8 1.5.2 機構(gòu)領(lǐng)導的支持.8 1.5.3 質(zhì)量管理的政策.8 1.5.4 質(zhì)量保證小組的政策.9 1.5.5 項目團隊的政策.9 2 立項管理立項管理 .9 3 項目規(guī)劃項目規(guī)劃 .9 4 項目監(jiān)控項目監(jiān)控 .10 4.1 項目計劃跟蹤項目計劃跟蹤 .11 4.1.1 任務(wù)跟蹤任務(wù)跟蹤 .11 4.1.2 費用跟蹤費用跟蹤 .11 4.1.3 資源跟蹤資源跟蹤 .11 4.1.4 工作成果及其規(guī)模跟蹤工作成果及其規(guī)模跟蹤 .12 4.2 控制偏差控制偏差 .12 4.3 項目進展匯報項目進展匯報 .13 5 風險管理風險管理 .14 6 需求管理

3、需求管理 .18 6.1 需求確認需求確認 .18 6.2 需求跟蹤需求跟蹤 .20 6.3 需求變更控制需求變更控制 .20 7 結(jié)項管理結(jié)項管理 .22 8 需求開發(fā)需求開發(fā) .23 9 技術(shù)預研技術(shù)預研 .24 10 系統(tǒng)設(shè)計系統(tǒng)設(shè)計 .25 10.1 體系結(jié)構(gòu)設(shè)計體系結(jié)構(gòu)設(shè)計 .26 10.2 用戶界面設(shè)計用戶界面設(shè)計 .26 10.3 數(shù)據(jù)庫設(shè)計數(shù)據(jù)庫設(shè)計 .27 10.4 模塊設(shè)計模塊設(shè)計 .28 11 實現(xiàn)與測試實現(xiàn)與測試 .28 12 系統(tǒng)測試系統(tǒng)測試 .30 13 客戶驗收客戶驗收 .31 14 技術(shù)評審技術(shù)評審 .32 15 配置管理配置管理 .33 16 質(zhì)量保證質(zhì)量保證

4、 .35 17 培訓管理培訓管理 .37 18 服務(wù)與維護服務(wù)與維護 .38 1 軟件研發(fā)制度綜述軟件研發(fā)制度綜述 1.1 精簡模型精簡模型 “精簡模型”是基于 cmmi 以及軟件工程和項目管理知識而創(chuàng)作的一種“軟件過程改進 方法和規(guī)范” ，它由眾多的過程規(guī)范和文檔模板組成。 精簡模型把產(chǎn)品生命周期劃分為 6 個階段，分別為： 產(chǎn)品概念階段 產(chǎn)品定義階段 產(chǎn)品開發(fā)階段 產(chǎn)品測試階段 用戶驗收階段 產(chǎn)品維護階段 在精簡模型中，軟件項目的過程有三大類：項目管理過程、項目研發(fā)過程和機構(gòu)支持過 程。上述三類過程可以細分為 17 個主要過程域，分布在產(chǎn)品生命周期的各個階段。 項目管理過程包含 6 個過程

5、域，分別為： 立項管理 結(jié)項管理 項目規(guī)劃 項目監(jiān)控 風險管理 需求管理 項目研發(fā)過程包含 7 個過程域，分別為： 需求開發(fā) 技術(shù)預研 系統(tǒng)設(shè)計 實現(xiàn)與測試 系統(tǒng)測試 客戶驗收 技術(shù)評審 機構(gòu)支撐過程包含 4 個過程域，分別為： 配置管理 質(zhì)量保證 培訓管理 服務(wù)與維護 精簡模型如圖 1-1 所示。精簡模型的主要特征和優(yōu)點有： 一、直觀的過程模型一、直觀的過程模型 精簡模型將項目管理、項目研發(fā)、機構(gòu)支撐所包含的工作劃分為相對獨立的三類過程， 各個過程域之間的關(guān)系直觀明了。這樣，機構(gòu)領(lǐng)導、項目經(jīng)理、開發(fā)人員、測試人員、質(zhì)量 保證人員等人根據(jù)精簡模型，很容易知道自己“應(yīng)該在什么時候、按照什么規(guī)范做

6、什么事情” 。所以精簡模型有助于使機構(gòu)內(nèi)的各個職能單位有條不紊地開展工作。 二、容易裁剪與擴充二、容易裁剪與擴充 精簡模型的三類過程貫穿了產(chǎn)品的整個生命周期，17 個最常見的過程域都合理地安排在 產(chǎn)品生命周期中的某些階段。用戶可以根據(jù)自己產(chǎn)品的特征，適當?shù)夭眉艋驍U充精簡的過程 域，很容易制定出最適合于本產(chǎn)品的過程模型。 圖 1-1 精簡模型 產(chǎn)品概念產(chǎn)品定義產(chǎn)品開發(fā)產(chǎn)品測試客戶驗收產(chǎn)品維護 立項管理項目規(guī)劃項目監(jiān)控 風險管理 需求管理結(jié)項管理 需求開發(fā) 配置管理 質(zhì)量保證 培訓管理 項目 管理 過程 項目 研發(fā) 過程 機構(gòu) 支撐 過程 服務(wù)與維護 技術(shù)評審技術(shù)評審 技術(shù)預研 并行、迭代 根據(jù)產(chǎn)

7、品特征確定最合適的開發(fā)模型， 以線性順序為主，以并行、迭代為輔。 系統(tǒng)設(shè)計 實現(xiàn)與測試 系統(tǒng)測試 客戶驗收 其它： 人力資源管理 財務(wù)管理 行政管理 市場營銷 1.2 精簡過程域的目的精簡過程域的目的 精簡模型 所有 17 個過程域的目的如表 1-1 所示。 項目管理過程域項目管理過程域目的目的 立項管理 采納符合機構(gòu)最大利益的立項建議，通過立項管理使該建議成為正式的項目。杜絕不 符合機構(gòu)最大利益的立項建議被采納，避免浪費機構(gòu)的資源、資金、時間等。 結(jié)項管理 在項目開發(fā)工作結(jié)束后，對項目的有形資產(chǎn)和無形資產(chǎn)進行清算、對項目進行綜合評 估以及總結(jié)經(jīng)驗教訓等。 項目規(guī)劃 為項目的研發(fā)和管理工作制定

8、合理的行動綱領(lǐng)（即項目計劃） ，以便所有相關(guān)人員按照 該計劃有條不紊地開展工作。 項目監(jiān)控 周期性地跟蹤項目計劃的各種參數(shù)如進度、工作量、費用、資源等，不斷地了解項目 的進展情況，以便當項目實際進展顯著偏離計劃時能夠及時采取糾正措施。 風險管理在風險產(chǎn)生危害之前識別它們，從而有計劃地消除或削弱風險。 需求管理 在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并 控制需求的變更。 項目研發(fā)過程域項目研發(fā)過程域目的目的 需求開發(fā)通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。 技術(shù)預研 在立項之后到開發(fā)工作完成之前的時間內(nèi)，對項目將采用的關(guān)鍵技術(shù)提前學習和研究， 盡可能早地發(fā)現(xiàn)

9、并解決開發(fā)過程中將會遇到的技術(shù)障礙。 系統(tǒng)設(shè)計 設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，從而在需求與代碼之間建立 橋梁，指導開發(fā)人員去實現(xiàn)能滿足用戶需求的軟件產(chǎn)品。 實現(xiàn)與測試 依據(jù)系統(tǒng)設(shè)計文檔，編寫并測試整個系統(tǒng)的代碼。在精簡模型中，實現(xiàn)與測試是“編 程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。 系統(tǒng)測試對最終系統(tǒng)進行全面的測試，確保最終系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。 客戶驗收客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。 技術(shù)評審 盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而有效地提高產(chǎn)品 的質(zhì)量。 機構(gòu)支撐過程域機構(gòu)支撐過程域目的

10、目的 配置管理 通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件來保證所有配置項的完 整性和可跟蹤性。配置管理是對工作成果的一種有效保護。 質(zhì)量保證 提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與 “產(chǎn)品質(zhì)量” ，從而實現(xiàn)持續(xù)地改進質(zhì)量。 培訓管理 根據(jù)機構(gòu)（或項目）的需求來制定培訓計劃，并監(jiān)督該計劃的實施，確保培訓取得預 期效果。 服務(wù)與維護 是指產(chǎn)品銷售之后的客戶服務(wù)和產(chǎn)品維護，其宗旨是提高客戶對產(chǎn)品以及對開發(fā)方的 滿意度。 表 1-1 精簡過程域的目的 comment j1: 使用現(xiàn)有的規(guī)范 1.3 精簡模型精簡模型 文檔結(jié)構(gòu)與規(guī)范細分文檔結(jié)構(gòu)與規(guī)范細分

11、精簡模型的文檔結(jié)構(gòu)如圖 1-2 所示，spp 包含 17 個過程域，規(guī)范細分如表 1-2 所示。 圖 1-2 精簡模型 文檔結(jié)構(gòu) 項目管理過程域項目管理過程域主要規(guī)程主要規(guī)程文檔模板文檔模板 立項管理 立項建議 立項評審 項目籌備 立項建議書 立項調(diào)查報告書 立項可行性分析報告 立項評審報告 結(jié)項管理結(jié)項管理 結(jié)項申請書 結(jié)項評審報告 項目規(guī)劃 制定項目計劃 審批項目計劃 項目計劃變更控制 項目計劃 項目計劃變更控制報告 項目監(jiān)控 項目計劃跟蹤 偏差控制 項目進展總結(jié) 項目監(jiān)控數(shù)據(jù)表 項目偏差控制報告 項目進展報告 風險管理風險管理 風險檢查表 風險管理報告 需求管理 需求確認 需求跟蹤 需求

12、變更控制 需求跟蹤報告 需求變更控制報告 項目研發(fā)過程域項目研發(fā)過程域主要規(guī)程主要規(guī)程文檔模板文檔模板 需求開發(fā) 需求調(diào)查 需求分析 需求定義 用戶需求說明書 產(chǎn)品需求規(guī)格說明書 技術(shù)預研技術(shù)預研 技術(shù)預研計劃 技術(shù)預研報告 過程改進政策 過程域 規(guī)程 文檔模板 系統(tǒng)設(shè)計 體系結(jié)構(gòu)設(shè)計 用戶界面設(shè)計 數(shù)據(jù)庫設(shè)計 模塊設(shè)計 體系結(jié)構(gòu)設(shè)計報告 用戶界面設(shè)計報告 數(shù)據(jù)庫設(shè)計報告 模塊設(shè)計報告 實現(xiàn)與測試 實現(xiàn)與測試實現(xiàn)與測試計劃 編程文檔 系統(tǒng)測試系統(tǒng)測試 系統(tǒng)測試計劃 測試用例 測試報告 客戶驗收客戶驗收 客戶驗收計劃 客戶驗收報告 技術(shù)評審 正式技術(shù)評審 非正式技術(shù)評審 技術(shù)評審計劃 技術(shù)評審報

13、告 技術(shù)評審檢查表 機構(gòu)支撐過程域機構(gòu)支撐過程域規(guī)程與關(guān)鍵活動規(guī)程與關(guān)鍵活動文檔模板文檔模板 質(zhì)量保證 制定質(zhì)量保證計劃 過程與產(chǎn)品質(zhì)量檢查 問題跟蹤與質(zhì)量改進 質(zhì)量保證計劃 質(zhì)量保證檢查表 質(zhì)量保證報告 質(zhì)量問題跟蹤表 配置管理 制定配置管理計劃 配置庫管理 版本控制 變更控制 配置管理計劃 配置庫管理報告 配置項變更控制報告 培訓管理 機構(gòu)培訓管理 項目培訓管理 培訓計劃 培訓評估報告 客戶服務(wù) 客戶服務(wù)計劃 客戶服務(wù)報告 服務(wù)與維護 產(chǎn)品維護 產(chǎn)品維護計劃 產(chǎn)品維護報告 表 1-2 精簡模型 規(guī)范細分 1.4 精簡模型精簡模型 角色與職責表角色與職責表 精簡模型的主要角色及其職責如表 1

14、-3 所示（詳見各個過程域?qū)巧c職責的描述） 。公 司在應(yīng)用精簡模型時，可以將精簡模型的各個角色映射到公司原有的崗位上，也可以依據(jù)精 簡模型角色建立新的崗位。一個人可以被賦予多個角色，一個人可以被賦予多個角色，視具體情況而定。 常設(shè)角色常設(shè)角色職責簡述職責簡述 軟件工程過程組 （sepg） （1）制定適合于本機構(gòu)的過程規(guī)范。 （2）在機構(gòu)范圍內(nèi)推廣該規(guī)范（如培訓、考核） ，評估機構(gòu)過程能力等。 機構(gòu)過 程改進 角色 質(zhì)量保證小組 （qag） （1）監(jiān)督規(guī)范的實施，確保所有項目以及相關(guān)部門準照規(guī)范開展工作。 （2）分析并解決機構(gòu)內(nèi)存在的共性質(zhì)量問題，協(xié)組 sepg 完善規(guī)范。 機構(gòu)領(lǐng)導 （1）

15、是機構(gòu)內(nèi)所有項目的主管，對立項管理和結(jié)項管理有最終決策權(quán)。 （2）監(jiān)督項目經(jīng)理的工作，審批項目經(jīng)理的各種申請。 項目 管理 過程角 色 項目經(jīng)理 （1）向機構(gòu)領(lǐng)導匯報工作。 （2）是項目規(guī)劃、項目監(jiān)控、風險管理和需求管理過程域的負責人。 （3）監(jiān)督項目成員的工作，審批項目成員的各種申請。 需求分析員 調(diào)查、分析并定義需求，撰寫相應(yīng)的需求文檔，盡最大努力使需求文檔能 夠正確無誤地反映用戶的真實意愿。 系統(tǒng)設(shè)計師 根據(jù)需求文檔設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，并 撰寫相應(yīng)的設(shè)計文檔。 程序員 （1）根據(jù)系統(tǒng)設(shè)計文檔，編寫軟件系統(tǒng)的代碼。 （2）隨時測試和檢查自己的代碼，及時消除代碼

16、中的缺陷。 項目研 發(fā) 過程 角色 測試員 從事單元測試、集成測試和系統(tǒng)測試，主要工作包括制定測試計劃、設(shè)計 測試用例、執(zhí)行測試和撰寫測試報告。 配置管理員 （1）為項目制定配置管理計劃 。 （2）創(chuàng)建并維護配置庫，如分配權(quán)限、清除垃圾文件、備份配置庫等。 質(zhì)量保證員 （即 qag 成員） （1）為項目制定質(zhì)量保證計劃 。 （2）周期性的開展“過程與產(chǎn)品質(zhì)量檢查” 。 （3）跟蹤質(zhì)量問題，給出質(zhì)量改進措施。 培訓管理員 制定機構(gòu)（或項目）的培訓計劃 ，監(jiān)督該計劃的實施，撰寫培訓評估 報告 。 客戶服務(wù)人員 為客戶提供與產(chǎn)品相關(guān)的服務(wù)（如技術(shù)咨詢） ，快速響應(yīng)客戶的要求，給客 戶一個滿意的解答。

17、 機構(gòu) 支撐 過程 角色 產(chǎn)品維護人員 （1）糾錯性維護：及時解決用戶遇到的技術(shù)故障和消除產(chǎn)品中的缺陷。 （2）完善性維護：在資源允許的情況下，不斷改善產(chǎn)品功能與質(zhì)量。 臨時角色臨時角色職責說明職責說明 立項建議小組 （1）開展立項調(diào)查、產(chǎn)品構(gòu)思和可行性分析，撰寫相應(yīng)文檔。 （2）申請立項，并在立項評審會議上答辯。 立項評審委員會 由機構(gòu)領(lǐng)導、各級經(jīng)理、市場人員、技術(shù)專家、財務(wù)人員等組成，委員會 按少數(shù)服從多數(shù)原則投票決定是否同意立項。 結(jié)項評審委員會 對項目的有形資產(chǎn)和無形資產(chǎn)進行清算，對項目進行綜合評估，總結(jié)經(jīng)驗 教訓等。結(jié)項委員會的人員組成與立項評審委員會的類似。 技術(shù)評審委員會 對工作

18、成果進行正式技術(shù)評審，盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開 發(fā)人員及時消除缺陷。該委員會由項目內(nèi)外的技術(shù)專家組成。 配置控制委員會對配置管理各項活動擁有決策權(quán)（例如審批計劃，審批變更請求等） 。 表 1-3 精簡模型的角色與職責簡表 1.5 公司軟件過程的政策公司軟件過程的政策 1.5.1 目標目標 持續(xù)改進機構(gòu)的軟件過程能力，不斷地提高產(chǎn)品質(zhì)量、提高生產(chǎn)率并且降低開發(fā)成本。 1.5.2 機構(gòu)領(lǐng)導的支持機構(gòu)領(lǐng)導的支持 機構(gòu)領(lǐng)導批準用于軟件過程改進的必要經(jīng)費，例如支付咨詢費，購買相關(guān)軟件工具等。 機構(gòu)領(lǐng)導組建 sepg 和 qag，專門從事軟件過程改進工作。sepg 的主要職責是建立適 合于機構(gòu)

19、的過程規(guī)范，qag 的主要職責是監(jiān)督該規(guī)范的實施。建議讓 sepg 和 qag 的 大部分人員重疊，這些人既是 sepg 成員又是質(zhì)量保證員，扮演兩種角色。這樣不僅節(jié) 約人力資源，并且提高了工作效果（由制定規(guī)范的人去監(jiān)督規(guī)范的實施最合適不過） 。一 般地，sepg 成員和質(zhì)量保證員共占機構(gòu)總?cè)藬?shù)的 5%左右。 機構(gòu)領(lǐng)導不僅要口頭支持，還要親自參與軟件過程改進的實踐。例如參加培訓和考試， 準照過程規(guī)范執(zhí)行立項管理和結(jié)項管理等。 1.5.3 質(zhì)量管理的政策質(zhì)量管理的政策 質(zhì)量管理口號：“在開發(fā)過程之中內(nèi)建質(zhì)量而非修補質(zhì)量” 。 質(zhì)量管理有種基本措施：“質(zhì)量保證” 、 “技術(shù)評審”和“測試” 。 一

20、、一、質(zhì)量保證質(zhì)量保證 機構(gòu)的質(zhì)量保證員周期性地檢查項目成員的“工作過程以及工作成果”是否符合既定的 規(guī)范，來監(jiān)控和改進“過程質(zhì)量以及產(chǎn)品質(zhì)量” 。 機構(gòu)的質(zhì)量保證員獨立于任何項目，并賦予他一定的權(quán)利，對質(zhì)量不合格的工作成果作 出處理。 二、技術(shù)評審二、技術(shù)評審 在工作成果剛產(chǎn)生之際，對其進行技術(shù)評審（分正式或非正式兩種） ，目的是盡早地發(fā) 現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而提高產(chǎn)品的質(zhì)量。 如果時間允許的話，應(yīng)當盡可能多地對產(chǎn)品的重要工作成果進行技術(shù)評審。技術(shù)評審活 動由項目開發(fā)團隊組織。 三、測試三、測試 測試是指通過運行測試用例（test case）來找出軟件中的缺陷。

21、測試與技術(shù)評審的主要區(qū) 別是前者要運行軟件而后者不必運行軟件。 一般地，產(chǎn)品開發(fā)過程中有四個測試階段：單元測試、集成測試、系統(tǒng)測試和驗收測試。 其中單元測試和集成測試可以由項目開發(fā)團隊組織。系統(tǒng)測試階段必須有項目外的人員參與， 以保證系統(tǒng)測試的客觀性。驗收測試由客戶組織。如果有條件的話，建議機構(gòu)成立專門的測 試小組從事單元測試、集成測試和系統(tǒng)測試工作。 1.5.4 質(zhì)量保證小組的政策質(zhì)量保證小組的政策 機構(gòu)領(lǐng)導任命一位熟悉過程規(guī)范并且有豐富的質(zhì)量管理經(jīng)驗的人擔任 qag 的負責人 （或稱為質(zhì)量經(jīng)理） 。在機構(gòu)領(lǐng)導的許可下，該負責人組建 qag（成員可以是全職的也可以 是兼職的） 。 qag 在

22、行政上獨立于任何項目。這種獨立性有助于質(zhì)量保證員客觀地檢查和監(jiān)控“過程 以及產(chǎn)品的質(zhì)量” 。qag 準照 sepg 制定的“質(zhì)量保證規(guī)范”開展工作。 機構(gòu)領(lǐng)導賦予 qag 一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。這種權(quán)利使 得 qag 的工作不會被輕視，并有助于加強全員的質(zhì)量意識。對于 qag 與項目之間出現(xiàn)的難 以調(diào)和的爭議，由機構(gòu)領(lǐng)導處理。 1.5.5 項目團隊的政策項目團隊的政策 項目中的任何管理人員、開發(fā)人員、測試人員等，必須學習與本職工作相關(guān)的過程規(guī)范， 每個人都必須明白自己“應(yīng)當在什么時候依據(jù)什么規(guī)范做什么事情應(yīng)當在什么時候依據(jù)什么規(guī)范做什么事情” 。項目經(jīng)理應(yīng)當樹立榜 樣

23、，并且督促項目成員們按規(guī)范做事。 允許項目經(jīng)理根據(jù)本項目的特征，在 sepg 和 qag 的指導下，適當?shù)夭眉艋驍U充機構(gòu) 的過程規(guī)范，從而快速建立本項目的過程規(guī)范。這項工作應(yīng)當在“項目規(guī)劃過程域”中完成， 并在項目計劃中體現(xiàn)出來。 如果項目對機構(gòu)過程規(guī)范的裁剪幅度比較大，遭到 qag 的反對，如果雙方不能達成共 識，則由機構(gòu)領(lǐng)導處理該爭議。 sepg 對項目過程能力的評估成績將作為評定項目人員工作業(yè)績的重要因素，具體比重 由機構(gòu)領(lǐng)導決定，建議占 30以上的比重。 2 立項管理立項管理 參見項目管理制度試行 v2.1 版本 3 項目規(guī)劃項目規(guī)劃 在立項管理過程域的項目籌備階段，機構(gòu)領(lǐng)導首先任命一

24、位項目經(jīng)理，之后機構(gòu)領(lǐng) 導協(xié)助項目經(jīng)理籌備項目經(jīng)費、人力資源、軟件硬件資源等。如果必要的資金和資源已經(jīng)到 位，那么項目經(jīng)理和核心成員即可組成一個項目規(guī)劃小組，著手制定項目計劃 ，并按計 劃執(zhí)行研發(fā)和管理工作。 項目的計劃書可分兩類：一是全局的計劃書（overall plan） ，這里稱為項目計劃 ；二 是一些下屬計劃書（subordinate plan） ，例如配置管理計劃 、 質(zhì)量保證計劃 、一些開發(fā) 計劃和測試計劃等。 下屬計劃書是對項目計劃的補充，其內(nèi)容不可與項目計劃沖突。通常項目計 劃由項目經(jīng)理負責制定，由機構(gòu)領(lǐng)導審批。而下屬計劃書一般由項目成員制定，由項目經(jīng) 理審批即可。 項目計劃過

25、程域有 3 個主要規(guī)程：“制定項目計劃” 、 “審批項目計劃”和“項目計劃變更控 制” ，流程如圖 3-1 所示。 圖 3-1 項目規(guī)劃流程圖 項目計劃模板 4 項目監(jiān)控項目監(jiān)控 項目監(jiān)控（project monitoring and control, pmc）的目的是通過周期性地跟蹤項目計劃的 各種參數(shù)如進度、工作量、費用、資源、工作成果等，不斷地了解項目的進展情況，以便當 項目實際進展狀況顯著偏離計劃時能夠及時采取糾正措施。 本規(guī)范闡述了項目監(jiān)控過程域的三個主要規(guī)程： 項目計劃跟蹤 控制偏差 項目進展匯報 圖 4-1 項目監(jiān)控流程 制定 項目 計劃 審批 項目 計劃 項目計劃變更控制 按計

26、劃執(zhí)行 研發(fā)與管理工作 項目計劃跟蹤偏差控制項目進展總結(jié) 周期性地開展 4.1 項目計劃跟蹤項目計劃跟蹤 周期性的跟蹤任務(wù)（含進度和工作量） 、費用、資源、工作成果等，及時了解項目的實 際進展情況。 為持續(xù)過程改進提供有價值的數(shù)據(jù)。 4.1.1 任務(wù)跟蹤任務(wù)跟蹤 項目經(jīng)理（或其指定的項目成員）周期性地（如每周一次）跟蹤每個重要的任務(wù)，將采 集的數(shù)據(jù)保存在項目監(jiān)控數(shù)據(jù)表之中。任務(wù)跟蹤表的參考格式如表 4-1 所示。 任務(wù)名稱任務(wù)名稱實際起止時間實際起止時間跟蹤日期、當前進度跟蹤日期、當前進度實際工作量實際工作量實際工作成果實際工作成果 表 4-1 任務(wù)跟蹤表 4.1.2 費用跟蹤費用跟蹤 項目經(jīng)

27、理（或其指定的項目成員）周期性地跟蹤項目費用，將采集的數(shù)據(jù)保存在項目 監(jiān)控數(shù)據(jù)表之中。費用跟蹤表的參考格式如表 4-2 所示。 費用類別費用類別主要開支項、用途主要開支項、用途金額金額時間時間 表 4-2 費用跟蹤表 4.1.3 資源跟蹤資源跟蹤 項目經(jīng)理（或其指定的項目成員）周期性地跟蹤軟硬件資源，將采集的數(shù)據(jù)保存在項 目監(jiān)控數(shù)據(jù)表之中。資源跟蹤表的參考格式如表 4-3 所示。 軟硬件資源名稱軟硬件資源名稱級別級別實際配置實際配置獲取方式與時間獲取方式與時間使用說明使用說明 關(guān)鍵 關(guān)鍵 普通 普通 表 4-3 資源跟蹤表 4.1.4 工作成果及其規(guī)模跟蹤工作成果及其規(guī)模跟蹤 項目經(jīng)理（或其指

28、定的項目成員）周期性地跟蹤工作成果及其規(guī)模，將采集的數(shù)據(jù)保存 在項目監(jiān)控數(shù)據(jù)表之中。工作成果跟蹤表的參考格式如表 4-4 所示。 工作成果名稱工作成果名稱新開發(fā)的成果規(guī)模新開發(fā)的成果規(guī)模 （代碼行、類、文檔頁數(shù)）（代碼行、類、文檔頁數(shù)） 復用或自動生成的成果規(guī)模復用或自動生成的成果規(guī)模 （代碼行、類、文檔頁數(shù)）（代碼行、類、文檔頁數(shù)） 工作成果 1 工作成果 2 總和總和 表 4-4 工作成果及其規(guī)模跟蹤表 4.2 控制偏差控制偏差 對比“項目實際進展”和“項目計劃” ，分析偏差，如果發(fā)現(xiàn)項目實際進展顯著偏離計 劃，則及時采取糾正措施。 記錄日期記錄日期顯著偏差描述顯著偏差描述原因分析原因分析

29、糾正措施糾正措施結(jié)果結(jié)果 表 4-5 項目偏差控制報告 4.3 項目進展匯報項目進展匯報 周期性地匯報項目進展情況。 項目經(jīng)理周期性地總結(jié)項目進展情況，撰寫項目進展報告并通報給機構(gòu)領(lǐng)導和所有 項目成員。 基本信息基本信息 項目名稱報告日期 項目編號報告批次第 n 份 項目經(jīng)理項目所處階段 項目進展狀況項目進展狀況計劃計劃實際情況實際情況 任務(wù)與進度 工作成果 費用 人力資源 軟硬件資源 問題與對策問題與對策 表 4-6 項目進展報告 5 風險管理風險管理 風險管理（risk management, riskm）的目的是在風險產(chǎn)生危害之前識別它們，從而有 計劃地消除或削弱風險。 所有可能危害項目

30、的因素都稱為風險。被刻畫為風險的事件最終可能發(fā)生也可能不發(fā)生。 人們對待風險有兩種態(tài)度。一種是被動態(tài)度，可比作“救火模式” 。另一種是主動態(tài)度，可 比作“防火模式” 。風險管理屬于“防火模式” ，目的就是“防止風險產(chǎn)生真正的危害” 。 為了便于量化管理，我們給風險定義 3 個參數(shù)： 風險嚴重性：指風險對項目造成的危害程度。 風險可能性：指風險發(fā)生的幾率。 風險系數(shù)：是風險嚴重性和風險可能性的乘積。 參數(shù)參數(shù)等級等級值值描述描述 很高5例如進度延誤大于 30%，或者費用超支大于 30%。 比較高4例如進度延誤 20%30%，或者費用超支 20%30%。 中等3例如進度延誤低于 20%，或者費用超

31、支低于 20%。 比較低2例如進度延誤低于 10%，或者費用超支低于 10%。 風險 嚴重性 很低1例如進度延誤低于 5%，或者費用超支低于 5%。 表 5-1 風險嚴重性等級 參數(shù)參數(shù)等級等級值值描述描述 很高5風險發(fā)生的幾率為 1.0 0.8 比較高4風險發(fā)生的幾率為 0.8 0.6 中等3風險發(fā)生的幾率為 0.6 0.4 比較低2風險發(fā)生的幾率為 0.4 0.2 風險 可能性 很低1風險發(fā)生的幾率為 0.2 0.0 表 5-2 風險可能性等級 風險可能性風險可能性風險風險 系數(shù)系數(shù)很高 5比較高 4中等 3比較低 2很低 1 很高 5252015105 比較高 420161284 中等

32、31512963 比較低 2108642 風險風險 嚴重性嚴重性 很低 154321 本表灰色部分的風險系數(shù)值為本表灰色部分的風險系數(shù)值為 1025，應(yīng)當優(yōu)先處理。，應(yīng)當優(yōu)先處理。 表 5-3 風險系數(shù)等級 風險嚴重性的等級劃分如表 5-1 所示，風險可能性的等級劃分如表 5-2 所示，風險系數(shù) 的等級劃分如表 3 所示。 風險管理有 4 個主要活動： 風險識別：根據(jù)風險檢查表，識別出本項目的風險。 風險分析：估計風險嚴重性、風險可能性、風險系數(shù)。 風險減緩：對于風險系數(shù)超過“容許值”的每一個風險，都應(yīng)當采取減緩措施。 風險跟蹤：跟蹤風險減緩過程，記錄風險的狀態(tài)。 圖 5-1 風險管理示意圖

33、在項目的生命周期內(nèi)，上述 4 個活動將被循環(huán)執(zhí)行，如圖 5-1 所示。直到項目的所有風 險都被識別與解決為止。 常用的風險檢查表 ，使用者應(yīng)根據(jù)實際情況進行適當?shù)膭h減或補充。風險管理過程 域產(chǎn)生的主要文檔是風險管理報告 。 商業(yè)風險商業(yè)風險 風險類型檢查項 政府或者其他機構(gòu)對本項目的開發(fā)有限制嗎？ 有不可預測的市場動蕩嗎？ 有不利于我方的官司要打嗎？ 本產(chǎn)品銷售后在使用過程中可能導致發(fā)生重大的損失或傷亡事故嗎？ 競爭對手有不正當?shù)母偁幮袨閱幔?本產(chǎn)品銷售后在使用過程中可能導致發(fā)生重大的損失或傷亡事故嗎？ 是否在開發(fā)很少有人真正需要卻自以為很好的產(chǎn)品？ 政治 法律 市場 是否在開發(fā)可能虧本的產(chǎn)品

34、？ 客戶的需求是否含糊不清？ 客戶是否反反復復地改動需求？ 客戶指定的需求和交付期限在客觀上可行嗎？ 客戶對產(chǎn)品的健壯性、可靠性、性能等質(zhì)量因素有非常過分的要求嗎？ 客戶的合作態(tài)度友善嗎？ 與客戶簽的合同公正嗎？雙方互利嗎？ 客戶 客戶的信譽好嗎？例如按客戶的需求開發(fā)了產(chǎn)品，但是客戶可能不購買。 風險識別 風險分析 風險減緩 風險跟蹤 與子承包商、供應(yīng)商簽訂的合同公正嗎？雙方互利嗎？ 子承包商、供應(yīng)商的信譽好嗎？ 子承包商、供應(yīng)商有可能倒閉嗎？ 子承包商、供應(yīng)商能及時交付質(zhì)量合格的產(chǎn)品（或部件）嗎？ 子承包商 供應(yīng)商 子承包商、供應(yīng)商有能力做好售后服務(wù)嗎？ 管理風險管理風險 風險類型檢查項 對

35、項目的規(guī)模、難度估計是否比較正確？ 人力資源（開發(fā)人員、管理人員）夠用嗎？合格嗎？ 項目所需的軟件、硬件能按時到位嗎？ 項目的經(jīng)費夠用嗎？ 進度安排是否過于緊張？有合理的緩沖時間嗎？ 進度表中是否遺忘了一些重要的（必要的）任務(wù)？ 進度安排是否考慮了關(guān)鍵路徑？ 是否可能出現(xiàn)某一項工作延誤導致其他一連串的工作也被延誤？ 任務(wù)分配是否合理？（即把任務(wù)分配給合適的項目成員，充分發(fā)揮其才能） 是否為了節(jié)省錢，不采用（購買）成熟的軟件模塊，一切從零做起？ 項目計劃 項目成員團結(jié)嗎？是否存在矛盾？ 是否絕大部分的項目成員對工作認真負責？ 絕大部分的項目成員有工作熱情嗎？ 團隊之中有“害群之馬”嗎？ 技術(shù)開發(fā)

36、隊伍中有臨時工嗎？ 本項目開發(fā)過程中是否會有核心人員辭職、調(diào)動？ 是否能保證“人員流動基本不會影響工作的連續(xù)性”？ 項目團隊 項目經(jīng)理是否忙于行政事務(wù)而無暇顧及項目的開發(fā)工作？ 本項目是否得到上級領(lǐng)導的重視？ 上級領(lǐng)導是否隨時會抽調(diào)本項目的資源用于其他“高優(yōu)先級”的項目？ 上級領(lǐng)導是否過多地介入本項目的事務(wù)并且瞎指揮？ 行政部門的辦事效率是否比較底，以至于拖項目的后腿？ 行政部門是否經(jīng)常干一些無益于生產(chǎn)力的事情，以至于騷擾本項目？ 機構(gòu)是否能全面、公正地考核員工的工作業(yè)績？ 機構(gòu)是否有較好的獎勵和懲罰措施？ 上級領(lǐng)導 行政部門 合作部門 本項目的合作部門的態(tài)度積極嗎？是否應(yīng)付了事？或者做事與承

37、諾的不一致？ 技術(shù)風險技術(shù)風險 風險類型檢查項 需求開發(fā)人員懂得如何獲取用戶需求嗎？效率高嗎？ 需求開發(fā)需求開發(fā)人員懂得項目所涉及的具體業(yè)務(wù)嗎？能否理解用戶的需求？ 需求文檔能夠正確地、完備地表達用戶需求嗎？ 需求開發(fā)人員能否與客戶對有爭議的需求達成共識？需求管理 需求開發(fā)人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？ 開發(fā)人員是否有開發(fā)相似產(chǎn)品的經(jīng)驗？ 待開發(fā)的產(chǎn)品是否要與未曾證實的軟硬件相連接？ 對開發(fā)人員而言，本項目的技術(shù)難度高嗎？ 開發(fā)人員是否已經(jīng)掌握了本項目的關(guān)鍵技術(shù)？ 如果某項技術(shù)尚未實踐過，開發(fā)人員能否在預定時間內(nèi)掌握？ 開發(fā)小組是否采用比較有效的分析、設(shè)計、編程、

38、測試工具？ 分析與設(shè)計工作是否過于簡單、草率，從而讓程序員邊做邊改？ 開發(fā)小組采用統(tǒng)一的編程規(guī)范嗎？ 開發(fā)人員對測試工作重視嗎？能保證測試的客觀性嗎？ 項目有獨立的測試人員嗎？懂得如何進行高效率地測試嗎？ 是否對所有重要的工作成果進行了同行評審（正式評審或快速檢查）？ 開發(fā)人員懂得版本控制、變更控制嗎？能夠按照配置管理規(guī)范執(zhí)行嗎？ 綜合技術(shù) 開發(fā)能力 包括設(shè)計 編程、測試等 開發(fā)人員重視質(zhì)量嗎？是否會在進度延誤時降低質(zhì)量要求？ 表 5-4 風險檢查表 風險名稱風險識別人 風險編號風險識別日期 風險描述 風險嚴重性風險系數(shù) 風險可能性風險處理人 風險減緩措施 跟蹤記錄 （1）記錄何人在何時做了什

39、么事情 （2）記錄當前風險狀態(tài)（正在處理，已經(jīng)解決，不作處理） 表 5-5 風險管理報告 6 需求管理需求管理 需求管理（requirement management, rm）的目的在客戶與開發(fā)方之間建立對需求的共 同理解，維護需求與其他工作成果的一致性，并控制需求的變更。 需求管理過程域的三個主要規(guī)程： 需求確認 需求跟蹤 需求變更控制 圖 6-1 需求工程結(jié)構(gòu)圖 6.1 需求確認需求確認 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔，盡最大努力盡最大努力 使需求文檔能夠正確無誤地反映用戶的真實意愿。使需求文檔能夠正確無誤地反映用戶的真實意愿。 當需求文檔通過正式的評審之

40、后，開發(fā)方負責人（項目經(jīng)理）和客戶對需求文檔作書面 承諾，使之具有商業(yè)合同效果。示例如下： 本需求文檔建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該需求 文檔開展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白需求的變更 將導致雙方重新協(xié)商成本、資源和進度等。 甲方負責人簽字 乙方負責人簽字 評審結(jié)束 輸出 需求評審報告 ，書面的需求承諾 需求工程 需求開發(fā) 需求變更控制 需求管理 需求確認 需求跟蹤 需求調(diào)查 需求分析 需求定義 需求評審報告摘要需求評審報告摘要 需求文檔輸入名稱，標識符，版本，作者，完成日期， 需求評審報告輸入名稱，標識符，評審日期， 評審結(jié)論

41、 工作成果合格， “無需修改”或者“需要輕微修改但不必再審核” 。 工作成果基本合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。 評審意見 評審小組成員輸入評審小組成員 表 6-1 需求評審報告 需求承諾需求承諾 需求文檔輸入名稱，標識符，版本，作者，完成日期 客戶承諾 承諾 簽字，日期 項目經(jīng)理承諾 承諾 簽字，日期 表 6-2 需求承諾 6.2 需求跟蹤需求跟蹤 將系統(tǒng)設(shè)計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文 檔設(shè)計文檔代碼測試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 項目經(jīng)理跟蹤需求。 建立與維

42、護需求跟蹤矩陣： 正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點。 逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤” 。不論采用何種跟蹤方式，都要建立與維護需 求跟蹤矩陣（即表格） 。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單 元之間的可能存在“一對一” 、 “一對多”或“多對多”的關(guān)系。由于對應(yīng)關(guān)系比較復雜， 最好在表格中加必要的文字解釋。表 6-3 為簡單的需求跟蹤矩陣格式。 當需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。 需求文檔 （版本，日期） 設(shè)計文檔 （版本，日期） 代碼 （版本，日期） 測試用例 （版本，日期） 1標題或標識符，說明標題或標識符，說明代碼名稱，說明測試用例名稱，說明 2 表 6-3 簡單的需求跟蹤矩陣格式 6.3 需求變更控制需求變更控制 修改“原需求文檔”中不正確的內(nèi)容，產(chǎn)生新的需求文檔。 控制需求文檔的變更，防止發(fā)生混亂。 補充說明：本規(guī)程中的“原需求文檔”是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。 開發(fā)方負責人（項目