【正文】 進度安排是否考慮了關(guān)鍵路徑？ 是否可能出現(xiàn)某一項工作延誤導(dǎo)致其他一連串的工作也被延誤？ 任務(wù)分配是否合理？（即把任務(wù)分配給合適的項目成員，充分發(fā)揮其才能） 是否為了節(jié)省錢，不采用（購買）成熟的軟件模塊，一切從零做起？ … 項目團隊 項目成員團結(jié)嗎？是否存在矛盾？ 是否絕大部分的項目成員對工作認真負責？ 絕大部分的項目成員有工作熱情嗎？ 團隊之中有“害群之馬”嗎？ 技術(shù)開發(fā)隊伍中有臨時工嗎？ 本項目開發(fā)過程中是否會有 核心人員辭職、調(diào)動？ 是否能保證“人員流動基本不會影響工作的連續(xù)性”？ 項目經(jīng)理是否忙于行政事務(wù)而無暇顧及項目的開發(fā)工作？ 上級領(lǐng)導(dǎo) 行政部門 合作部門 本項目是否得到上級領(lǐng)導(dǎo)的重視？ 上級領(lǐng)導(dǎo)是否隨時會抽調(diào)本項目的資源用于其他“高優(yōu)先級”的項目？ 上級領(lǐng)導(dǎo)是否過多地介入本項目的事務(wù)并且瞎指揮？ 行政部門的辦事效率是否比較底，以至于拖項目的后腿？ 行政部門是否經(jīng)常干一些無益于生產(chǎn)力的事情，以至于騷擾本項目？ 機構(gòu)是否能全面、公正地考核員工的工作業(yè)績？ 機構(gòu)是否有較好的獎勵和 懲罰措施？ 本項目的合作部門的態(tài)度積極嗎？是否應(yīng)付了事？或者做事與承諾的不一致？ 技術(shù)風險 風險類型 檢查項 需求開發(fā)人員懂得如何獲取用戶需求嗎？效率高嗎？ 17 需求開發(fā) 需求管理 需求開發(fā)人員懂得項目所涉及的具體業(yè)務(wù)嗎？能否理解用戶的需求？ 需求文檔能夠正確地、完備地表達用戶需求嗎？ 需求開發(fā)人員能否與客戶對有爭議的需求達成共識？ 需求開發(fā)人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？ 綜合技術(shù) 開發(fā)能力 包括設(shè)計 編程、測試等 開發(fā)人員是否有開發(fā)相似產(chǎn)品的經(jīng) 驗？ 待開發(fā)的產(chǎn)品是否要與未曾證實的軟硬件相連接？ 對開發(fā)人員而言，本項目的技術(shù)難度高嗎？ 開發(fā)人員是否已經(jīng)掌握了本項目的關(guān)鍵技術(shù)？ 如果某項技術(shù)尚未實踐過，開發(fā)人員能否在預(yù)定時間內(nèi)掌握？ 開發(fā)小組是否采用比較有效的分析、設(shè)計、編程、測試工具？ 分析與設(shè)計工作是否過于簡單、草率，從而讓程序員邊做邊改？ 開發(fā)小組采用統(tǒng)一的編程規(guī)范嗎？ 開發(fā)人員對測試工作重視嗎？能保證測試的客觀性嗎？ 項目有獨立的測試人員嗎？懂得如何進行高效率地測試嗎？ 是否對所有重要的工作成果進行了 同行評審（正式評審或快速檢查）？ 開發(fā)人員懂得版本控制、變更控制嗎？能夠按照配置管理規(guī)范執(zhí)行嗎？ 開發(fā)人員重視質(zhì)量嗎？是否會在進度延誤時降低質(zhì)量要求？ 表 54 風險檢查表 風險名稱 風險識別人 風險編號 風險識別日期 風險描述 風險嚴重性 風險系數(shù) 風險可能性 風險處理人 風險減緩措施 跟蹤記錄 （ 1）記錄何人在何時做了什么事情 （ 2）記錄當前風險狀態(tài)（正在處理，已經(jīng)解決，不作處理） 18 表 55 風險管理報告 6 需求管理 需求管 理（ Requirement Management, RM）的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護需求 與其他 工作成果的一致性，并控制需求的變更。風險管理過程域產(chǎn)生的主要文檔是 《風險管理報告》 。直到項目的所有風險都被識別與解決為止。 ? 風險跟蹤：跟蹤風險減緩 過程，記錄風險的狀態(tài)。 ? 風險分析：估計風險嚴重性、風險可能性、風險系數(shù)。 表 53 風險系數(shù)等級 15 風險嚴重性的等級劃分如表 51 所示，風險可能性的等級劃分如表 52 所示，風險系數(shù)的等級劃分如表 3 所示。 很低 1 例如進度延誤低于 5%，或者費用超支低于 5%。 中等 3 例如進度延誤低于 20%，或者費用超支低于 20%。 參數(shù) 等級 值 描述 風險 嚴重性 很高 5 例如進度延誤大于 30%，或者費用超支大于 30%。 ? 風險可能性：指風險發(fā)生的幾率。風險管理屬于“防火模式”，目的就是“防止風險產(chǎn)生真正的危害”。一種是被動態(tài)度，可比作“救火模式”。被刻畫為風險的事件最終可能發(fā)生也可能不發(fā)生。 基本信息 項目名稱 報告日期 項目編號 報告批次 第 N 份 項目經(jīng)理 項目所處階段 項目進展狀況 計劃 實際情況 任務(wù)與進度 工作成果 費用 人力資源 軟 硬件資源 問題與對策 表 46 項目 進展 報告 14 5 風險管理 風險管理（ Risk Management, RiskM）的目的是在風險產(chǎn)生危害之前識別它們，從而有計劃地消除或削弱風險。 記錄日期 顯著偏差描述 原因分析 糾正措施 結(jié)果 表 45 項目偏差控制報告 13 項目進展匯報 周期性地匯報項目進展情況。工作成果跟蹤表的參考格式如表 44 所示。資源跟蹤表的參考格式如表 43 所示。費用跟蹤表的參考格式如表 42 所示。任務(wù)跟蹤表的參考格式如表 41 所示。 為持續(xù)過程改進提供有價值的數(shù)據(jù)。 圖 31 項目規(guī)劃流程圖 項目計劃模板 4 項目監(jiān)控 項目監(jiān)控（ Project Monitoring and Control, PMC）的目的是通過周期性地跟蹤項目計劃的各種參數(shù)如進度、工作量、費用、資源、工作成果等，不斷地了解項目的進展情況，以便當項目實際進展狀況顯著偏離計劃時能夠及時采取糾正措施。而下屬計劃書一般由項目成員制定，由項目經(jīng)理審批即可。 下屬計劃書是對《項目計劃》的補充，其內(nèi)容不可與《項目計劃》沖突。如果必要的資金和資源已經(jīng)到位，那么項目經(jīng)理和核心成員即可組成一個項目規(guī)劃小組，著手 制定《項目計劃》，并按計劃執(zhí)行研發(fā)和管理工作。 SEPG 對項目過程能力的評估成績將作為評定項目人員工作業(yè)績的重要因素，具體比重由機構(gòu)領(lǐng)導(dǎo)決定，建議占 30％以上的比重。這項工作應(yīng)當在“項目規(guī)劃過程域”中完成，并在《項目計劃》中體現(xiàn)出來。項目經(jīng)理應(yīng)當樹立榜樣，并且督促項目成員們按規(guī)范做事。對于 QAG 與項目之間出現(xiàn)的難以調(diào)和的爭議，由機構(gòu)領(lǐng)導(dǎo)處理。 機構(gòu)領(lǐng)導(dǎo)賦予 QAG 一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。這種獨立性有助于質(zhì)量保證員客觀地檢查和監(jiān)控“過程以及產(chǎn)品的質(zhì)量”。在機構(gòu)領(lǐng)導(dǎo)的許可下，該負責人組建 QAG（成員可以是全職的也可以是兼職的）。如果有條件的話， 建議 9 機構(gòu)成立專門的測試小組從事單元測試、集成測試和系統(tǒng)測試工作。系統(tǒng)測試階段必須有項目外的人員參與，以保證系統(tǒng)測試的客觀性。 一般地，產(chǎn)品開發(fā)過程中有四個測試階段：單元測試、集成測試、系統(tǒng)測試和驗收測試。 三、測試 測試是指通過運行測試用例（ test case）來找出軟件中的缺陷。 如果時間允許的話，應(yīng)當盡可能多地對產(chǎn)品的重要工作成果進行技術(shù)評審。 機構(gòu)的質(zhì)量保證員獨立于任何項目，并賦予他一定的權(quán)利，對質(zhì)量不合格的工作成果作出處理。 質(zhì)量管理有種基本措施：“質(zhì)量保證”、“技術(shù)評審”和“測試”。例如參加培訓(xùn)和考試 ，準照過程規(guī)范執(zhí)行立項管理和結(jié)項管理等。一般地， SEPG 成員和質(zhì)量保證員共占機構(gòu)總?cè)藬?shù)的 5%左右。建議讓 SEPG 和QAG 的大部分人員重疊，這些人既是 SEPG 成員又是質(zhì)量保證員，扮演兩種角色。 ? 機構(gòu)領(lǐng)導(dǎo)組建 SEPG 和 QAG，專門從事軟件過程改進工作。 表 13 精簡模型 的角色與職責簡表 8 公司 軟件過程的政策 目標 ? 持續(xù)改進機構(gòu)的軟件過程能力，不斷地提高產(chǎn)品質(zhì)量、提高生產(chǎn)率并且降低開發(fā)成本。該委員會由項目內(nèi)外的技術(shù)專家組成。結(jié)項委員會的人員組成與立項評審委員會的類似。 立項評審委員會 由機構(gòu)領(lǐng)導(dǎo)、各級經(jīng)理、市場人員、技術(shù)專家、財務(wù)人員等組成，委員會按少數(shù)服從多數(shù)原則投票決定是否同意立項。 臨時角色 職責說明 立項建議小組 （ 1）開展立項調(diào)查、產(chǎn)品構(gòu)思和可行性分析，撰寫相應(yīng)文檔。 產(chǎn)品維護人員 （ 1）糾錯性維護：及時解決用戶遇到的技術(shù)故障和消除產(chǎn)品中的缺陷。 培訓(xùn)管理員 制定機構(gòu)（或項目）的《培訓(xùn)計劃》，監(jiān)督該計劃的實施，撰寫《培訓(xùn)評估報告》。 （ 2）周期性的開展“過程與產(chǎn)品質(zhì)量檢查”。 （ 2）創(chuàng)建并維護配置庫，如分配權(quán)限、清除垃圾文件、備份配置庫等。 測試員 從事單元測試、集成測試和系統(tǒng) 測試，主要工作包括制定測試計劃、設(shè)計測試用例、執(zhí)行測試和撰寫測試報告。 程序員 （ 1）根據(jù)系統(tǒng)設(shè)計文檔，編寫軟件系統(tǒng)的代碼。 項目研發(fā) 過程 角色 需求分析員 調(diào)查、分析并定義需求，撰寫相應(yīng)的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。 （ 2）是項目規(guī)劃、項目監(jiān)控、風險管理和需求管理過程域的負責人。 （ 2）監(jiān)督項目經(jīng)理的工作，審批項目經(jīng)理的各種申請。 （ 2）分析并解決機構(gòu)內(nèi)存在的共性質(zhì)量問題，協(xié)組 SEPG 完善規(guī)范。 （ 2）在機構(gòu)范圍內(nèi)推廣該規(guī)范（如培訓(xùn)、考核），評估機構(gòu)過程能力等。 一個人可以被賦予多個角色， 視具體情況而定。 圖 12 精簡模型 文檔結(jié)構(gòu) 項目管理過程域 主要規(guī)程 文檔模板 立項管理 立項建議 立項評審 項目籌備 《立項建議書》 《立項調(diào)查報告書》 《立項可行性分析報告》 《立項評審報告》 結(jié)項管理 結(jié)項管理 《結(jié)項申請書》 《結(jié)項評審報告》 項目規(guī)劃 制定項目計劃 審批項目計劃 項目計劃變更控制 《項目計劃》 《項目計劃變更控制報告》 項目監(jiān)控 項目計劃跟蹤 偏差控制 項目進展總結(jié) 《項目監(jiān)控數(shù)據(jù)表》 《項目偏差控制報告》 《項目進展報告》 風險管理 風險管理 《 風險檢查表》 《風險管理報告》 需求管理 需求確認 需求跟蹤 需求變更控制 《需求跟蹤報告》 《需求變更控制報告》 項目研發(fā)過程域 主要規(guī)程 文檔模板 需求開發(fā) 需求調(diào)查 需求分析 需求定義 《用戶需求說明書》 《產(chǎn)品需求規(guī)格說明書》 技術(shù)預(yù)研 技術(shù)預(yù)研 《技術(shù)預(yù)研計劃》 《技術(shù)預(yù)研報告》 過程改進政策 過程域 規(guī)程 文檔模板 6 系統(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ù)評審報告》 《技術(shù)評審檢查表》 機構(gòu)支撐過程域 規(guī)程與關(guān)鍵活動 文檔模板 質(zhì)量保證 制定質(zhì)量保證計劃 過程與產(chǎn)品質(zhì)量檢查 問題跟蹤與質(zhì)量改進 《質(zhì)量保證計劃》 《質(zhì)量保證檢查表》 《質(zhì)量保證報告》 《質(zhì)量問題跟蹤表》 配置管理 制定配置管理計劃 配置庫管理 版本控制 變更控制 《配置管理計劃》 《配置庫管理報告》 《 配置項變更控制報告》 培訓(xùn)管理 機構(gòu)培訓(xùn)管理 項目培訓(xùn)管理 《培訓(xùn)計劃》 《培訓(xùn)評估報告》 服務(wù)與維護 客戶服務(wù) 《客戶服務(wù)計劃》 《客戶服務(wù)報告》 產(chǎn)品維護 《產(chǎn)品維護計劃》 《產(chǎn)品維護報告》 表 12 精簡模型 規(guī)范細分 精簡模型 角色與職責表 精簡模型 的主要角色及其職責如表 13 所示（詳見各個過程域?qū)巧c職責的描述）。 服務(wù)與維護 是指產(chǎn)品銷售之后的客戶服務(wù)和產(chǎn)品維護，其宗旨是提高客戶對產(chǎn)品以及對開發(fā)方的滿意度。 質(zhì)量保證 提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實現(xiàn)持續(xù)地改進質(zhì)量。 機構(gòu)支撐過程域 目的 配置管理 通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件來保證所有配置項的完整性和可跟蹤性。 客戶驗收 客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。在 精簡模型 中，實現(xiàn)與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。 系統(tǒng)設(shè)計 設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，從而在需求與代碼之間建立橋梁，指導(dǎo)開發(fā)人員去實現(xiàn)能滿足用戶需求的軟件產(chǎn) 品。 項目研發(fā)過程域 目的 需求開發(fā) 通過調(diào)查與分析，獲取用