【文章內(nèi)容簡介】 的方式、將采用的風險管理策略、對最嚴重的風險所計劃的降低 /規(guī)避或預防的策略、監(jiān)測風險狀態(tài)的方式、風險復審的時間表。 ] 風險管理的組織和職責 [列出與風險管理相關的個人或小組，并對其職責進行描述。 ] 工具與技術(shù) [列出與風險管理將采用的工具軟件或技術(shù)。 ] 納入管理的風險項 [列出主要的風險項，并描述其影響以及應急措施。具體可以參考后面的《風險條目跟蹤表模板》。 ] 收尾計劃 [列出在項目后期將要做的事，包括材料存檔、匯報總結(jié)等。 ] 5. 相關技術(shù) 開發(fā)案例 [給出本項目將采用的軟件生命周期模型、過程規(guī)范等，從而對開發(fā)過程給予明確的指導。該部分可以視需要將其單列 為一個專題文件。 ] 方法、工具和技術(shù) [列出本項目中將運用的方法、工具和技術(shù)，并給出適當?shù)墓ぷ髦改虾驼f明。 ] 產(chǎn)品驗收計劃 [列出本項目驗收工作的一些細節(jié)計劃，本部分內(nèi)容可以視需要將其單列為一個專題計劃。 ] 6．其它支持過程管理 配置管理計劃 [在此列出該項目所采用的配置管理過程，通常是單列為一個專題。 ] 評估計劃 [列出本項目評估時所使用的技術(shù)、標準、指標和過程。這里的評估包括走查、檢查和復審。 ] 文檔計劃 質(zhì)量保證計劃 分包商管理計劃 風險條目跟蹤表模板 編者說明： 對于中型以上的項目，風險控制的意義就猶為突出 。要控制風險，就應該找到風險，并將風險記錄下來，確定相關責任人，對于風險性高的、可能性大的還需要制訂相關的應對措施。而最 好的方法就是整理成為本模板中的表格，為每個潛在風險備個案。 序列號 順序號 確定日期 風險被識別出的日期 撤消日期 撤消風險確定日期 描述 以 條件 結(jié)果 的形式描述風險 可能性 風險轉(zhuǎn)變?yōu)閱栴}的可能性 注：可用 (極不可能 )~(肯定發(fā)生 )來表示 影響 如果風險變成了事實獎造成的損失 注：可用 1(無甚么影響 )~10(有很深、很大的影響 )來表示 危害值 可能性＊影響 降低風險計劃 一種或多種用來控制、避免、最小化及降低風險的方法 負責人 解決風險的責任承擔者 截止日期 完成降低風險措施的截止日期 進度計劃風險列 表 編者說明： 準確來說，本列表不是一個文檔模板，而是一個參考文章。由于風險識 別許多人都覺得無從入手，下面就是列出了與進度相關的風險條目，對于風險識別有很大的參考價值。 計劃風險 1） 功能無限蔓延； 2） 需求鍍金或開發(fā)人員鍍金； 3） 質(zhì)量不定 4） 計劃過于樂觀 5） 設計欠佳 6） 銀彈綜合癥 7） 研發(fā)導向開發(fā) 8） 人員薄弱 9） 簽約商失??； 10）研發(fā)人員與客戶的磨擦。 計劃編制風險 1） 計劃、資源和產(chǎn)品定義全憑客戶或上層領導口頭指令，并且不完全一致； 2） 計劃是優(yōu)化的，是“最佳狀態(tài)”； 3） 計劃忽略了必要的任務； 4） 計劃基于使用特定的小組成員，而那個小組成員其實指望不上。 5） 在限定的時間內(nèi)無法建成已定規(guī)模大小的產(chǎn)品； 6） 產(chǎn)品規(guī)模比估計的要大一些； 7） 工作量大于估算數(shù)； 8） 進度已經(jīng)拖延的項目在重新評 估時過于優(yōu)化或忽視項目歷史； 9） 過度的進度壓力造成生產(chǎn)率下降； 10）目標日期提前，但沒有相應地調(diào)整產(chǎn)品范圍或可用資源； 11）一個任務的延遲導致相關任務的連鎖反應； 12）涉足不熟悉的產(chǎn)品領域，花費在設計和實現(xiàn)上的時間比預期的要多。 組織和管理 1） 項目缺乏一個有凝聚力的最高領導人； 2） 由于前期乏力，項目長時間被擱置； 3） 解雇和削減開支導致項目小組能力下降； 4） 僅由管理層或市場人員進行技術(shù)決策，導致計劃進度延長； 5） 低效的項目組結(jié)構(gòu)降低生產(chǎn)率； 6） 管理層審查 /決策的周期比預期時間長； 7） 預算削減打亂項目計劃； 8） 管理 層做出了打擊項目組織積極性的決定； 9） 非技術(shù)的第三方的工作比預期延長（如審批，采購等）； 10）計劃性太差，無法適應期望的開發(fā)速度； 11）項目計劃由于壓力而放棄，導致開發(fā)混亂、低效； 12）管理層強調(diào)英雄主義，而忽視客觀確切的狀態(tài)報告，這會降低發(fā)現(xiàn)和改正問題的能力。 開發(fā)環(huán)境 1） 設施沒有及時到位； 2） 設施到位，但不配套； 3） 設施擁擠、雜亂或者破損； 4） 開發(fā)工具未能及時到位； 5） 開發(fā)工具不如期望那樣有效，開發(fā)人員需要時間創(chuàng)建工作環(huán)境或切換新的工具； 6） 開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計劃要求的性能； 7） 新開 發(fā)工具的學習期比預期的長，內(nèi)容繁多。 最終用戶 1） 最終用戶堅持新的需求； 2） 最終用戶對于最后交付的產(chǎn)品不滿意，要求重新設計和重做； 3） 最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持； 4） 最終用戶的意見未被采納，造成產(chǎn)品最終無法滿足用戶期望，而必須重做。 客戶 1） 客戶堅持新的需求； 2） 客戶對規(guī)劃、原型和規(guī)格的審核 /決策周期比預期長； 3） 客戶沒有或不能參與規(guī)劃、原型和規(guī)格階段的審核，導致需求不穩(wěn)定和耗時的重復； 4） 客戶答復的時間比預期長（如回答需求中需澄清的問題）； 5） 客戶堅持技術(shù)決策而導致進度計劃延長； 6） 客戶對開發(fā)進 度管理過細，導致實際進展變慢； 7） 客戶提供的組件無法與開發(fā)的產(chǎn)品匹配，導致額外的設計和集成工作； 8） 客戶提供的組件質(zhì)量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶關系管理工作； 9） 客戶要求的支持工具和環(huán)境不兼容、性能差或者功能不完善，導致生產(chǎn)率降低； 10）客戶不接受交付的軟件，盡管它滿足了所有的規(guī)格； 11）客戶期望的開發(fā)速度是開發(fā)人員無法達到的。 承包商 1） 承包商沒有按承諾交付組件； 2） 承包商遞交的組件質(zhì)量低下無法接收，必須花時間改進質(zhì)量； 3） 承包商沒有買進項目開發(fā)需要的工具，進而無法提供需要的性能 水平。 需求 1） 需求已經(jīng)成為項目基準，但變化還在繼續(xù)； 2） 需求定義欠佳，而進一步的定義會擴展項目范疇； 3） 添加額外的需求； 4） 產(chǎn)品定義含混的部分比預期需要更多的時間。 產(chǎn)品 1） 錯誤發(fā)生率高的模塊需要比預期更多的測試、設計和實現(xiàn)工作； 2） 校正質(zhì)量低下不可接受的產(chǎn)品，需要比預期更多的測試、設計和實現(xiàn)工作。 3） 在一個或多上新興領域推廣計算機技術(shù)使得計劃進度的延長不可預期； 4） 由于軟件功能的錯誤，需要重新設計和實現(xiàn)； 5） 開發(fā)額外不需要的功能（鍍金）延長了計劃進度； 6） 要滿足產(chǎn)品規(guī)格與速度要求，需比預期更多時間，包括重新 設計和實現(xiàn)的時間； 7） 嚴格要求與現(xiàn)有系統(tǒng)兼容，需要進行比預期更多的測試、設計和實現(xiàn)工作； 8） 要求與其他系統(tǒng)、復雜系統(tǒng)或不受本項目控制的系統(tǒng)相連，導致無法預料的設計、實現(xiàn)和測試工作。 9） 要求在不同操作系統(tǒng)下運行將花費比預期更長的時間； 10）在不熟悉或未經(jīng)檢驗的軟（硬）件環(huán)境中運行產(chǎn)生未預料的問題； 11）開發(fā)一種對組織全新的模塊將比預期花費更長的時間； 12）依賴正在開發(fā)中的技術(shù)將延長計劃進度。 外部環(huán)境 1） 產(chǎn)品依賴政府規(guī)章，而規(guī)章的改變將是不可預期的； 2） 產(chǎn)品依賴草擬中的技術(shù)標準，而最后的標準將是不可預期的 。 人員 1） 招聘人員所花時間比預期的長； 2） 作為先決條件的任務不能按時完成（如培訓、其它項目）； 3） 開發(fā)人員和管理層之間關系不佳導致決策緩慢，影響全局； 4） 項目組成員沒有全身心投入項目，進而無法達到需要的產(chǎn)品性能水平； 5） 缺乏激勵措施，士氣低下，降低了生產(chǎn)能力； 6） 缺乏必要的規(guī)范，增加了工作失誤與重復工作； 7） 某些人需要更多時間適應不熟悉的軟件工具和環(huán)境、硬件環(huán)境、編程語言； 8） 項目結(jié)束前，合同制人員離開團隊，或雇員辭職； 9） 項目后期加入新的開發(fā)人員，額外的培訓和溝通降低現(xiàn)有成員的效率； 10）項目組成員不能有效地 一起工作； 11）由于項目組成員間的沖突，導致溝通不暢、設計欠佳、接口錯誤和額外的重復工作； 12）有問題的成員沒有調(diào)離項目組，損害了項目組其他成員的積極性； 13）項目的最佳人選未加入項目組； 14）項目的最佳人選已加入項目組，但因其他原因未能合理使用； 15）沒有找到項目急需的具有特定技能的人； 16）關鍵人物只能兼職參與； 17）項目人員不足； 18）任務的分配與人員技能不匹配； 19）人員工作的進展比預期的慢； 20）項目管理人員怠工導致計劃和進度失效； 21）技術(shù)人員怠工導致工作遺漏或質(zhì)量低下，工 作需要重做。 設計與實現(xiàn) 1） 設計過于簡單，無法確定主要事件，并導致重新設計和實現(xiàn)； 2） 設計過于復雜，導致一些不必要的工作，影響實現(xiàn)效率； 3） 設計質(zhì)量低下，導致重復設計和實現(xiàn) 4） 使用不熟悉的方法，導致額外的培訓時間，并重犯前期使用這種方法時導致的錯誤； 5） 產(chǎn)品采用低級語言來實施，導致生產(chǎn)率比預期的低； 6） 一些必要的功能無法使用現(xiàn)有的代碼和庫實現(xiàn)，開發(fā)人員必須使用新庫或自選開發(fā)所要的功能； 7） 代碼和庫質(zhì)量低下，導致需要額外的測試、錯誤修正或重做； 8） 過高估計了增強型工具對計劃進度的節(jié)省量； 9） 分別開發(fā)的模塊無法有效集成 ，需要重新設計或重做。 過程 1） 大量的紙面工作導致進程比預期的慢； 2） 進程跟蹤不準確，導致無法預知項目是否已落后于計劃進度； 3） 前期的質(zhì)量保證行為不真實，導致后期的重復工作； 4） 質(zhì)量跟蹤不準確，導致無法得知影響進度的質(zhì)量問題； 5） 太不正規(guī)，導致溝通不足，質(zhì)量問題和工作重做； 6） 過于正規(guī)，導致過多耗時無用的工作； 7） 向管理層撰寫進度報告占用的開發(fā)人員的時間比預期的多； 8） 風險管理粗心，導致沒有發(fā)現(xiàn)重大的項目風險； 9） 軟件項目風險管理花費的時間比預期的多。 開發(fā)進度月報 (ISO 標準 ) 編者說明： 計劃需要跟蹤 進度來進行適當?shù)恼{(diào)整，因此在開發(fā)組織內(nèi)應該形成良好的進度匯報機制， ISO 標準模板也對這一塊提供了參考。這一文檔格式十分全面， 不過也略顯繁瑣，適合于中型以上項目。 l．標題 2．工程進度與狀態(tài) 進度 [列出本月內(nèi)進行的各項主要活動，并且說明本月內(nèi)遇到的重要事件，這里所說的重要事件是指一個開發(fā)階段（即軟件生存周期內(nèi)各個階段中的某一個，例如需求分析階段）的開始或結(jié)束，要說明階段名稱及開始（或結(jié)束）的日期。 ] 狀態(tài) [說明本月的實際工作進度與計劃相比，是提前了、按期完成了、或是推 遲了？如果與計劃不一致，說明原因及準備采取的措施。 ] 3．資額耗用與狀態(tài) 資額耗用 [主要說明本月份內(nèi)耗用的工時與機時。 ] 工時 [分為三類： ] [a. 管理用工時 包括在項目管理（制訂計劃、布置工作、收集數(shù)據(jù)、檢查匯報工作等）方面耗用的工時； ] [b. 服務用工時 包括為支持項目開發(fā)所必須的服務工作及非直接的開發(fā)工作所耗用的工時； ] [c. 開發(fā)用工時 要分各個開發(fā)階段填寫。 ] 機時 [說明本月內(nèi)耗用的機時，以小時為單位，說明計算 機系統(tǒng)的型號。 ] 狀態(tài) [說明本月內(nèi)實際耗用的資源與計劃相比，是超出了、相一致、還是不到計劃數(shù)？如果與計劃不一致，說明原因及準備采取的措施。 ] 4 經(jīng)費支出與狀態(tài) 經(jīng)費支出 支持性費用 [列出本月內(nèi)支出的支持性費用，一般可按如下七類列出，并給出本月支持費用的總和： ] [ a. 房租或房屋折舊費； ] [b. 員工工資、獎金、補貼； ] 開發(fā)中的軟件系統(tǒng)的名稱和標識符 分項目名稱和標識符 分項目負責人簽名 本期月報編寫人簽名 本期月報的編號及所報告的年月 [c. 培訓費包括給教師的酬金及教室租金； ] [d. 資料費包括復印及購買參考資料的費用； ] [e. 會議費召集有關業(yè)務會議的費用； ] [f. 旅差費； ] [g. 其他費用。 ] 設備購置費 [列出本月內(nèi)支出的設備購置費，一般可分如下三類： ] [[a. 購買軟件的名稱與金額； ] [b. 購買硬設備的名稱、型號、數(shù)量及金額； ] [c. 已有硬設備的折舊費。 ] 狀態(tài) [說明本月內(nèi)實際支出的經(jīng)費與計劃相比較，是超過了。相符合、還是不到