1、目錄第1項合同21技術服務合同2項目名稱：網上圖書商城系統2合同內容2第2項項目實施6項目生存期6第3項項目實施9系統功能模塊概述和分析9系統功能模塊設計10第4項項目任務11序言11任務分解11第5項項目估算13系統功能模塊概述和分析13第6項項目進度19項目進度時間表19甘特圖20第7項項目進度23組織機構23職責23高層管理23項目的質量保證人員24項目經理24.質量目標24.質量策略25.軟件質量保證26第8項項目風險管理27、項目風險管理的目的27、項目風險管理的組成27、風險的種類27資源風險28業務風險29技術風險29進度風險30、定義風險參數31、風險管理策略31、風險管理角色

2、及職責31、網上書店中風險的識別32、風險的控制32風險監控33、網上圖書商城項目的風險管理3311v1.0可編輯可修改第1項合同1技術服務合同項目名稱：網上圖書商城系統委托方（甲方）:劉某人承攬方（乙方）:劉某人地點：簽訂日期：2016年06月01日有效期限：2016年衛匚月衛匚日至2016年_06_月24_日合同內容、合同標題甲方同意委托乙方開發網上圖書商城系統項目。乙方愿意承接甲方上述開發項目,并保證按時、按質地完成開發任務。、雙方責任1、甲方負責提出信息發布系統用戶需求，并在系統開發完成后，及時組織驗收和付款。2、乙方負責詳細需求調查、設計、開發、調試、培訓、技術服務等，保證按照甲方提

3、出的用戶需求按時、按質地完成開發任務。在項目開發完成后，程序源代碼使用權以及相關的技術文件完整地交給甲方。3、為使項目開發后能更好地滿足用戶的需要并方便今后的維護等，甲方將同時參加系統的開發。甲方人員參與系統開發和編程，也可對開發工作提出建議，必要時與乙方共同對方案設計和要求進行修改。#v1.0可編輯可修改4、甲方為乙方現場調查、設計、測試、安裝提供必要的條件，以滿足項目的實施需。5、甲方在合同有效期內發生需求變更較大，引起合同中乙方設計開發內容調整時,雙方對變更內容進行協商，協同解決，并形成備忘錄。6、此項目作為甲方和乙方共同開發項目，利益共享，其中任何一方如未經另一方同意，得利用此次項目開

4、發設計程序申請其他專題立項，或給與第三方使用。三、開發費用及付款方式（一）本項目的總開發費用為（人民幣大寫）壹萬貳仟叁佰肆拾伍元整（人民幣元）（二）甲方向乙方支付執行本合同所需款項：1、分期付款方式：在本合同簽訂后的15日內，甲方支付乙方項目預付款三十五萬元人民幣；在項目驗收合格后的15日內，甲方支付乙方項目開發款伍佰三十五萬元人民幣；四、驗收由甲乙雙方派出技術人員對軟件進行驗收。五、售后服務支持1、在系統驗收合格后，乙方對所開發的應用系統提供一年免費的售后服務。2、在售后服務期的前兩周，乙方將派工作人員協同甲方使用改軟件。3、售后服務內容包括軟件缺陷、故障及軟件功能的部分修改和完善等，用戶因

5、工作需要要求對部分功能作小范圍改動時，乙方應免費給予完成。4、在售后服務期內，乙方保證在出現應用系統故障時應及時、積極響應，遇有特殊情況雙方協商。六、保密責任甲、乙雙方保證應用系統的所有技術信息和資料，不透露給第三方。七、履行的期限、地點和方式。本合同自2016年06月01日至2016年06月24日在北京履行。本合同的履行方式：甲方責任甲方全力協助乙方完成合同內容。合同期內甲方為乙方提供專業性接口技術支持。乙方責任：33v1.0可編輯可修改乙方按甲方要求完成合同內容。乙方愿提供在實現功能的前提下，進一步予以完善。乙方在合同商定的時間內保證系統正常運行。乙方在項目驗收后提供一年免費維護。未經甲方

6、同意，乙方不得向第三方提供本系統中涉及專業的技術內容和所有的系統數據。八、技術情報和資料的保密本合同中的相關專業技術內容和所有的系統數據，歸甲方所有，未經甲方同意乙方不得提供給第三方。九、不可抗力1、如合同雙方中任何一方由于不可抗力，如：地震、水災、臺風、戰爭和其他雙方都認為的不可抗力原因而無法按期履行合同，則合同執行的時間由于上述時間的發生做相應延期。2、受影響方應盡快將所發生的不可抗力事故的情況以電話或傳真通知另一方，并在不可抗力發生14天內盡快用傳真和掛號信將有關權威機構出具的證明文件提交另一方確認。3、當不可抗力事故終止或事故消除后，受阻方應盡快用傳真或電傳通知對方關于不可抗力形勢的解

7、除并以掛號信加以確認，并繼續履行合同。4、如果不可抗力阻礙合同的履行超過180天，雙方就合同的進一步履行問題進行討論并達成一致意見。十、爭議的解決辦法在本合同履行過程中發生爭議或出現未能預料到的問題，雙方本著互相諒解、協作的原則，協商解決。十、培訓用戶培訓：乙方在系統試運行期間在甲方辦公地點，為用戶的操作培訓。十二、專利成果分配甲方在本項目中所有使用的專利保留專利權，乙方只擁有專利的使用權，未經甲方允許乙方不得私自出售，泄露甲方專利。十三、其他1、雙方簽字、蓋章的日期即為本合同的生效日期。2、本項目的知識產權屬于甲乙雙方共有。3、本合同一式兩份，甲乙雙方各執一份。甲方簽字:乙方簽字:#v1.0

8、可編輯可修改甲方蓋章:乙方蓋章:55v1.0可編輯可修改第2項項目實施項目生存期該項目的特點此項目需求比較模糊，在開發過程中極有可能發生需求的變更，即使在開發結束后，也常常需要功能上的擴充，面向的用戶群體相當廣泛，不同的用戶都有可能提出該系統針對某一類群體的改進意見和要求。項目組內部對此系統的認識也不夠統一，對大量輔助功能及新增功能有不同的看法，需要在基本的核心功能完成之后，隨著項目的進行，由項目經理進一步收集用戶及成員的想法意見進行決策。用戶及成員都需要在短時間內得到一個系統最初的版本，對其進行評價并在后續的開發上對其定位，并得出更多明確的需求。在項目本身的開發上，為了使系統錦上添花，會用到

9、許多開發人員也并不熟悉的技術，這可能需要開發人員進一步的學習后，再對系統進行改進。針對該項目的這些特點，權衡各個生存期的適用條件，該項目組選用了增量式模型來開發此系統。增量式模型的特點如下：可以避免一次性投資太多帶來的風險，將主要的功能或者風險大的功能首先實現，然后逐步完善，保證投入的有效性。可以更快地開發出可以操作的系統。可以減少開發過程中用戶需求的變更。一些增量可能需要重新開發（如果早期開發的需求不穩定或者不完整）。可見，增量式模型充分迎合了該項目的特點，并且提供了多種途徑解決項目中的一些難題。#v1.0可編輯可修改項目規劃需求分析設計產品提交V集成MS根據該項目的特點并結合公司已有的軟件

10、生存期模型定義，本項目生存期采用增量模型如圖2-1。圖4-1增量模型生存期中的各階段描述如下:項目規劃階段階段目標：根據合冋和初步的需求分析確定項目的規模、時間計劃和資源需求。輸入：合冋文本、sow過程：項目規劃，計劃確認輸出：項目計劃需求分析階段階段目標：確定客戶的需求輸入：項目計劃，sow過程：需求獲取，需求分析，需求控制輸出：原型系統，需求規格設計階段階段目標：總體系統結構設計輸入：原型系統，需求規格過程：總體設計輸出：系統設計說明書，數據庫結構定義增量1實現階段目標：實現系統的通用功能輸入：系統設計說明書數據庫結構定義過程：詳細設計，編碼，代碼走查，代碼評審，單兀測試輸出：詳細設計說明

11、書，源代碼，可運行版本-177v1.0可編輯可修改增量2實現階段目標：實現系統的圖書管理功能輸入：系統設計說明書過程：數據庫結構定義詳細設計，編碼，代碼走查，代碼評審，單元測試輸出：詳細設計說明書，源代碼，可運行版本-2增量3實現階段目標：實現系統的圖書顯示功能輸入：系統設計說明書過程：數據庫結構定義詳細設計，編碼，代碼走查，代碼評審，單元測試輸出：詳細設計說明書，源代碼，可運行版本-3增量4實現階段目標：實現系統的圖書訂單管理功能輸入：系統設計說明書過程：數據庫結構定義詳細設計，編碼，代碼走查，代碼評審，單元測試輸出：詳細設計說明書，源代碼，可運行版本-4集成測試階段目標：通過集成環境下的軟

12、件測試輸入：測試計劃測試案例過程：集成測試，系統測試輸出：系統軟件包，測試報告，產品說明書產品提交階段目標：產品可投入使用輸入：系統軟件包過程：產品提交輸出：驗收報告#v1.0可編輯可修改第3項項目實施系統功能模塊概述和分析網上圖書商城是典型的網上購物實踐中最為普遍的電子商務企業對客戶（B2C）模式，主要包括會員注冊、訂單管理、購物車、搜索、支付等基本功能。此外，本系統也將實現在線圖書銷售系統的后端管理，包括圖書的添加、訂單的處理等功能。本系統完全基于JSP技術，在系統的設計與開發過程中嚴格遵守軟件工程的規范，運用軟件設計模式，從而減少系統模塊間的偶合，力求做到系統的穩定性、可重用性和可擴充性

13、。網上圖書商城主要功能如下：（1）前臺（客戶購買）部分： 用戶管理：注冊會員、登錄、激活、退出、修改密碼； 分類顯示：顯示所有1級和2級分類； 圖書顯示：按分類查詢圖書、通過關鍵字搜索圖書、高級搜索圖書、查看某本圖書的詳細等； 購物車管理：向購物車中添加圖書、修改購物車中圖書數量、刪除購物車中圖書、我的購物車； 訂單管理：通過購物車中圖書生成訂單、查看我的訂單、查看某個訂單的詳細、訂單支付、確認收貨、取消未付款訂單。（2）后臺（管理員管理）部分： 管理員：管理員登錄； 分類管理：查看所有分類、添加1級分類、添加2級分類、修改1級分類、修改2級分類、刪除1級分類、刪除2級分類； 圖書管理：按分類

14、搜索圖書、高級搜索圖書、添加新圖書、查看圖書詳細信息、編輯圖書、刪除圖書； 訂單管理：按狀態搜索訂單、查看訂單詳細信息、取消訂單、發貨；99v1.0可編輯可修改1011系統功能模塊設計根據系統功能分析，可以畫出系統的功能模塊圖。前臺：用戶購書功能圖用尸竄7注冊4P!顯|JdJ*1L1H-fr國書連廠誨加囪書&臺菅理員模ir單占厘的購翎牟分S不*s書查詢訂單管理按分塗查看a查詢E書編nmif除新ffiES書書書所訂有單訂岌里貨,査看訂單詳細取消訂里v1.0可編輯可修改第4項項目任務序言本計劃以項目初期估算為藍本，盡量實現所有成員在整個項目過程中都能得到相關技能的鍛煉，根據現有成員的特點，制定了任

15、務分配。若在計劃執行過程中遇到不可控困難，可向項目經理提出申請延期。項目開始前可根據個人意愿進行小幅度任務調整，申請人需填寫任務申請表。計劃開始后除極特別因素外，不予重新調整。任務分解項目任務分解編碼表編碼任務名稱備注R000000需求討論初步確定需求P000000軟件規劃制定項目計劃P100000項目規劃P200000計劃評審M000000需求開發細化需求M100000用戶界面設計M200000用戶需求評審M300000修改需求、界面M400000編寫需求說明M500000需求驗證D000000設計完成項目設計工作D100000概要設計D200000數據庫ER圖編制、建庫vv1.0可編輯可修

16、改D300000設計評審C000000實施實際開發C100000用戶管理C100100用戶注冊C100200用戶注銷C100300賬號登陸C100400個人信息管理C200000圖書管理C200100添加新書C200200刪除圖書C200300編輯圖書C200400查看圖書C300000界面實現C400000整合T000000測試對項目進行測試T100000功能模塊測試T200000系統集成測試T300000環境測設V000000部署發布并交付#v1.0可編輯可修改第5項項目估算系統功能模塊概述和分析聲明項目規模估算使用Delphi法進行估算，具體步驟如下：協調人向小組成員提供項目規格和估計表

17、格；協調人召集小組討論與規模相關的因素；小組成員匿名填寫迭代表格；協調人整理出一個估計總結，以迭代表的形式返回各成員；協調人召集小組會，討論較大的估計差異；成員復查估計總結并在迭代表上提交另一個匿名估計；重復4-6，直到達到一個最低和最高估計的一致。1313v1.0可編輯可修改附Delphi法規模估計迭代表。Delphi法規模估計迭代表項目名稱：估計日期：估計者：估計輪次：結果：代碼行（LOC周期（月）工作量（人月）費用（元）#v1.0可編輯可修改理由：項目規模估算經過小組內部討論得出項目規模估算如下:項目名稱：個人微薄系統規模預測：代碼行：15,000LOC周期：1月工作量：6人月費用：Y5

18、530元項目進度估算任務完成時間負責人資源備注需求討論劉權2開發人員參與1515v1.0可編輯可修改項目規劃張三全體人員參與需求確定張三全體人員參與設計張三3開發人員參與項目實施張三全體人員參與有待細化測試張三3開發人員參與部署張三2開發人員參與交付張三項目執行期間可根據實際完成情況申請延期。附延期申請表。項目名稱：項目代號：項目所處階段：第階段（）申請時間：年月曰原計劃時間：年月曰申請延期至：年月曰申請延期的理由（逐條列出）：#v1.0可編輯可修改申請人簽字：項目經理意見不同意延遲，理由:同意延遲至：年月曰簽字：項目成本估算聲明由于涉及到的小組成員沒有實際開發的經驗，在薪酬結算方面沒有可供參

19、照的標準，因此在這里采用統一的Y人天。1717v1.0可編輯可修改成本估算任務名稱工時成本估算個人微薄系統111人天設備損耗31工作日需求討論2*2人天軟件規劃6*2人天需求開發6*4人天設計4*4人天實施6*13人天測試3*5人天部署2*1人天1818v1.0可編輯可修改第6項項目進度項目進度時間表任務代碼工期開始時間結束時間資源網上圖書商城31工作日2016-6-152016-7-15R0000002工作日2016-6-152016-6-16劉權P0000002工作日2016-6-172016-6-18全體開發人員P1000001工作日2016-6-172016-6-17劉權P200000

20、1工作日2016-6-182016-6-18全體開發人員M0000004工作日2016-6-192016-6-22全體開發人員M1000001工作日2016-6-192016-6-19劉權M2000001工作日2016-6-192016-6-19劉權M3000001工作日2016-6-202016-6-20劉權M4000001工作日2016-6-212016-6-21劉權M5000001工作日2016-6-222016-6-22全體開發人員D0000004工作日2016-6-232016-6-26全體開發人員D1000002工作日2016-6-232016-6-24全體開發人員D2000001

21、工作日2016-6-252016-6-25全體開發人員D3000001工作日2016-6-262016-6-26全體開發人員C00000013工作日2016-6-272016-7-9全體開發人員C1000006工作日2016-6-272016-7-2全體開發人員C1001004工作日2016-6-272016-6-30全體開發人員C1002002工作日2016-7-12016-7-2全體開發人員C1003004工作日2016-6-272016-6-30全體開發人員C1004002工作日2016-7-12016-7-2全體開發人員C20000011工作日2016-6-272016-7-7全體開發

22、人員C2001005工作日2016-7-12016-7-5全體開發人員C2002005工作日2016-7-12016-7-5全體開發人員C2003003工作日2016-7-62016-7-8全體開發人員C2004003工作日2016-6-272016-6-29全體開發人員C3000008工作日2016-7-12016-7-8全體開發人員C3001005工作日2016-7-12016-7-5全體開發人員C3002005工作日2016-7-12016-7-5全體開發人員C3003003工作日2016-7-62016-7-8全體開發人員C3003103工作日2016-7-62016-7-8全體開發人

23、員C3003203工作日2016-7-62016-7-8全體開發人員C40000012工作日2016-6-272016-7-8全體開發人員C5000001工作日2016-7-92016-7-9全體開發人員T0000005工作日2016-7-102016-7-14全體開發人員T1000003工作日2016-7-102016-7-12全體開發人員T2000001工作日2016-7-132016-7-13全體開發人員T3000001工作日2016-7-142016-7-14全體開發人員V0000001工作日2016-7-152016-7-15全體開發人員甘特圖在此僅列出項目實施階段甘特圖，其他部分省

24、略。2020v1.0可編輯可修改2121v1.0可編輯可修改附任務申請表任務申請表申請人：申請時間：計劃任務代碼：申請任務代碼：理由：（逐條列出）經理意見批準拒絕理由：日期：年月日經理簽字：2222v1.0可編輯可修改2424第7項項目進度組織機構在項目實施期間成立項目質量保證組織，該組織由質量保證人員和項目經理組成，項目經理負責質量監督工作及項目進展過程中各環節的質量把關，開發經理負責質量控制的工作，質量保證人員負責質量保證的工作。組織結構圖1如下:高層管理f1Coordinator項目管理1*市場部*用戶質量保證軟件開發配置管理圖1：項目的組織結構職責在本項目中，質量保證組織的職責如下:高

25、層管理高層管理是公司負責質量的高級管理，其質量職責如下:受理項目內不能解決的不符合問題，必要時與項目經理協調；負責聽取質量保證組的工作報告，評審質量保證活動和結果；參加有關質量保證過程改進的評審。項目的質量保證人員質量保證人員的質量職責如下：負責項目實施過程中對項目實施情況進行監督，包括對項目實施過程和工作產品進行監督檢查；實施項目組成員的質量保證培訓；制定質量保證計劃；按計劃實施審計活動，依照質量保證計劃執行評審/審計，并記錄執行中發現的不符合項；對不符合問題提交不符合項報告，跟蹤并驗證糾正措施的執行情況；對項目內不能解決的不符合項問題向高層管理提交報告；向項目經理報告項目質量工作狀況和質量

26、度量結果；定期向項目組報告質量活動的結果；制訂質量保證的過程改進計劃，記錄過程數據。項目經理項目經理的質量職責如下：評審質量計劃；與質量保證人員一起協商不符合項問題的糾正措施，并安排資源實施糾正措施；定期或事件驅動的評審質量保證活動和結果。,制定項目的總體質量目標:根據企業的質量方針和質量目標，結合本項目特點1) 基于需求的測試覆蓋率為100%2) 軟件功能測試用例通過率不低于95%;v1.0可編輯可修改3）每個階段評審中發現的問題都已經解決或得到適當處理。4）產品發布時不存在嚴重及其以上的缺陷。注：嚴重問題指導致系統或模塊不能正常工作的問題。結合以往的項目經驗和企業的質量相應標準，制定質量標

27、準如下表質量計劃標準項目具體描述計戈U實際缺陷排除率（缺陷數/頁）需求檢查4系統總體設計檢查2缺陷排除率（缺陷數/KLOC）詳細設計復核30詳細設計檢查10代碼復核65代碼檢查20編譯20單元測試15系統集成5系統測試5為了保證提交用戶的產品是高質量，實施過程中采取的質量保證措施包括：1）將質量貫徹到日常的項目進展過程中；2）應該特別注意項目工作產品質量的早期評審工作，無論是質量保證還是質量控制采取的策略都是早期預防和早期排除缺陷。2525v1.0可編輯可修改2626.軟件質量保證SQA活動圖v1.0可編輯可修改第8項項目風險管理、項目風險管理的目的風險是指在項目進行過程中可能發生的事件，這些

28、事件將會對項目按預期時間，資源和預算完成產生重大影響。風險管理的目標是在潛在問題發作以前就標志它們，這樣就可以在生命周期中可以適時地計劃和啟用風險處理活動。、項目風險管理的組成風險控制風險管理風險監控風險優先級風險分析風險識別風險評估風險化解、風險的種類分清風險的種類有利于更好的對項目進行風險管理。2727v1.0可編輯可修改2929資源風險組織QA和其他外部的相關各方）對該項目是否有足夠的支持（包括管理人員、測試員、這是否是該組織嘗試過的最大項目。軟件工程是否有明確定義的流程需求記錄和管理。資金完成項目所需的資金是否到位。是否為培訓和指導分配了資金。是否有預算限制使得系統必須以固定的成本交付

29、，否則將被取消。成本估算是否準確人員是否可以獲得足夠的項目工作人員。他們是否具備合適的技能和經驗。他們以前是否在一起工作過。他們是否相信項目會成功。是否可以找到用戶代表來擔任復審員。是否可以找到領域專家。時間時間表制定得是否現實。是否可以為了滿足時間表而對功能進行規模管理。對交付日期的要求有多嚴格。是否有時間“把工作做好”。業務風險如果競爭對手搶先將產品推向市場怎么辦。如何確保有足夠的資金。系統的預計價值是否大于預計成本（考慮貨幣的時間價值和資金的成本）如果無法同關鍵的供應商簽定合同怎么辦。技術風險規模風險成功是否能夠被評測。是否有關于如何評測成功的協議。需求是否相當穩定并得到了充分的了解。項

30、目規模是固定不變還是在不斷擴展。項目開發的時間范圍是否太短、不夠靈活。技術風險技術是否已經過證明。重復使用目標是否合理。工件必須要使用一次后才能被重復使用。構件可能要在若干次發布后才能變得穩定，以致無需重大變更即可復用。v1.0可編輯可修改需求中的事務量是否合理。事務比率的估計值是否可靠這些估計是否過于樂觀。數據量是否合理當前可用的框架是否能夠保存這些數據，或者，如果需求使您相信工作站或部門系統將成為設計的一部分，那么是否能夠在這些地方合理地保存數據。是否有特殊或苛刻的技術需求。成功是否依賴于新的或未經試驗的產品、服務或技術是否依賴于新的或未被證明的硬件、件或技術。對于與其他系統（包括企業以外

31、的系統）的接口是否存在外部依賴性是否存在必需的接口或必須創建它們。是否存在極不靈活的可用性和安全性需求（例如“系統必須永遠不出現故障”）。系統的用戶是否對正在開發的系統類型沒有經驗。應用程序的大小或復雜性，或者技術的新穎性是否導致了風險的增加。是否存在對國家語言支持的需求。是否可能設計、實施和運行該系統某些系統只由于太大或太復雜而無法正常工作。外部依賴性風險該項目是否依賴于其他（平行的）開發項目。成功是否依賴于市售產品或外部開發的構件。成功是否依賴于開發工具（設計工具、編譯器等）和實施技術（操作系統、數據庫、進程間通信機制等）的成功集成。您是否有替代計劃，可以在沒有這些技術的情況下交付項目。進

32、度風險功能是否無限追加。計劃是否過于樂觀。3030v1.0可編輯可修改是否缺乏計劃。在壓力下是否放棄計劃。是否追趕計劃。、定義風險參數風險參數可用于評估、分類和劃分風險的優先級；該項目將發生的可能性的等級劃分為:非常可能發生，可能發生，幾乎不可能發生3個級別。將對項目的影響程度劃分為：非常嚴重影響，嚴重影響，中等影響，微弱影響4個級別。相應的表格如下：發生的可能性對項目的影響程度名稱等級名稱等級非常可能發生3非常嚴重影響4可能發生2嚴重影響3幾乎不可能發生2中等影響2微弱影響1、風險管理策略有三種主要的策略：*風險規避：使其不再受到該風險的影響。*風險轉移：讓其他方（客戶、廠商、銀行、其他主體

33、等）承擔該風險。*風險接受：決定將該風險當作意外事件來接受。監測風險征兆，并制定應急計劃，以確定在風險發生時將采取何種行動。、風險管理角色及職責（1）項目經理項目經理對風險管理工作負全部責任。3131v1.0可編輯可修改(2)項目組開發人員項目組開發人員將被要求作為項目風險分析組的成員，對項目工作中存在的風險進行分析，并整理成書面材料。(3)SQASQA經理將定期對風險管理工作開展情況進行評審，確保所開展的風險管理工作符合組織的要求。、網上書店中風險的識別根據風險識別的分類標準可以識別出網上書店中存在的風險，如下：資源風險完成該項目所需的資金受到一定的限制，人員的培訓指導資金不到位，存在一定資金風險；參與項目的部分人員沒有一起工作過，也存在著一定的人員風險；此外，交付日期的嚴格要求導致項目存在時間風險。業務風險由于軟件行業的飛速發展，競爭對手可能搶先將產品推向市場，故存在著業務風險。技術風險客戶可能隨時提出需求和對項目的改進，需求的不穩定性和項目規模的不斷擴展，可能導致項目存在規模風險。進度風險功能的無限追加，在強大的壓力下放棄計劃都造成了項目的進度風險。、風險的控制1控制方法(1)風險管理計劃重點是制定一個計劃，以處理在排位靠前的高風險項。風險管理計劃每階段/迭代重新評估一次。風險監控時選取風險管理計劃中沒有關閉的前10大風險進行監控即可。每階段/迭代啟動時