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

1、0軟件研發(fā)管理制度軟件研發(fā)管理制度文件標識：Lolaage-Software-PM當前版本：0.1.2作 者：宋孝光文件狀態(tài)： 草稿 正式發(fā)布 正在修改完成日期：2012/3/271版本/狀態(tài)作者參與者修改日期備注0.1.1宋孝光2012/3/26第一版草稿0.1.2宋孝光2012/3/27整理目錄2目錄1 軟件研發(fā)制度綜述軟件研發(fā)制度綜述 .31.1 精簡模型精簡模型 .31.2 精簡過程域的目的精簡過程域的目的 .41.3 精簡模型精簡模型 文檔結構與規(guī)范細分文檔結構與規(guī)范細分 .51.4 精簡模型精簡模型 角色與職責表角色與職責表 .61.5 公司軟件過程的政策公司軟件過程的政策 .81

2、.5.1 目標.81.5.2 機構領導的支持.81.5.3 質量管理的政策.81.5.4 質量保證小組的政策.91.5.5 項目團隊的政策.92 立項管理立項管理 .93 項目規(guī)劃項目規(guī)劃 .94 項目監(jiān)控項目監(jiān)控 .104.1 項目計劃跟蹤項目計劃跟蹤 .114.1.1 任務跟蹤任務跟蹤 .114.1.2 費用跟蹤費用跟蹤 .114.1.3 資源跟蹤資源跟蹤 .114.1.4 工作成果及其規(guī)模跟蹤工作成果及其規(guī)模跟蹤 .124.2 控制偏差控制偏差 .124.3 項目進展匯報項目進展匯報 .135 風險管理風險管理 .146 需求管理需求管理 .186.1 需求確認需求確認 .186.2 需

3、求跟蹤需求跟蹤 .206.3 需求變更控制需求變更控制 .207 結項管理結項管理 .228 需求開發(fā)需求開發(fā) .239 技術預研技術預研 .2410 系統(tǒng)設計系統(tǒng)設計 .25310.1 體系結構設計體系結構設計 .2610.2 用戶界面設計用戶界面設計 .2610.3 數據庫設計數據庫設計 .2710.4 模塊設計模塊設計 .2811 實現與測試實現與測試 .2812 系統(tǒng)測試系統(tǒng)測試 .3013 客戶驗收客戶驗收 .3114 技術評審技術評審 .3215 配置管理配置管理 .3316 質量保證質量保證 .3517 培訓管理培訓管理 .3718 服務與維護服務與維護 .3841 軟件研發(fā)制度

4、綜述軟件研發(fā)制度綜述1.1 精簡模型精簡模型“精簡模型”是基于 CMMI 以及軟件工程和項目管理知識而創(chuàng)作的一種“軟件過程改進方法和規(guī)范” ，它由眾多的過程規(guī)范和文檔模板組成。精簡模型把產品生命周期劃分為 6 個階段，分別為：產品概念階段產品定義階段產品開發(fā)階段產品測試階段用戶驗收階段產品維護階段在精簡模型中，軟件項目的過程有三大類：項目管理過程、項目研發(fā)過程和機構支持過程。上述三類過程可以細分為 17 個主要過程域，分布在產品生命周期的各個階段。項目管理過程包含 6 個過程域，分別為：立項管理結項管理項目規(guī)劃項目監(jiān)控風險管理需求管理項目研發(fā)過程包含 7 個過程域，分別為：需求開發(fā)技術預研系統(tǒng)

5、設計實現與測試系統(tǒng)測試客戶驗收技術評審機構支撐過程包含 4 個過程域，分別為：配置管理質量保證培訓管理服務與維護精簡模型如圖 1-1 所示。精簡模型的主要特征和優(yōu)點有：5一、直觀的過程模型一、直觀的過程模型精簡模型將項目管理、項目研發(fā)、機構支撐所包含的工作劃分為相對獨立的三類過程，各個過程域之間的關系直觀明了。這樣，機構領導、項目經理、開發(fā)人員、測試人員、質量保證人員等人根據精簡模型，很容易知道自己“應該在什么時候、按照什么規(guī)范做什么事情”。所以精簡模型有助于使機構內的各個職能單位有條不紊地開展工作。二、容易裁剪與擴充二、容易裁剪與擴充精簡模型的三類過程貫穿了產品的整個生命周期，17 個最常見

6、的過程域都合理地安排在產品生命周期中的某些階段。用戶可以根據自己產品的特征，適當地裁剪或擴充精簡的過程域，很容易制定出最適合于本產品的過程模型。0圖 1-1 精簡模型產品概念產品定義產品開發(fā)產品測試客戶驗收產品維護立項管理項目規(guī)劃項目監(jiān)控 風險管理 需求管理結項管理需求開發(fā)配置管理 質量保證 培訓管理項目管理過程項目研發(fā)過程機構支撐過程服務與維護技術評審技術評審技術預研并行、迭代根據產品特征確定最合適的開發(fā)模型，以線性順序為主，以并行、迭代為輔。系統(tǒng)設計實現與測試系統(tǒng)測試客戶驗收其它： 人力資源管理 財務管理 行政管理 市場營銷 41.2 精簡過程域的目的精簡過程域的目的精簡模型 所有 17

7、個過程域的目的如表 1-1 所示。項目管理過程域項目管理過程域目的目的立項管理采納符合機構最大利益的立項建議，通過立項管理使該建議成為正式的項目。杜絕不符合機構最大利益的立項建議被采納，避免浪費機構的資源、資金、時間等。結項管理在項目開發(fā)工作結束后，對項目的有形資產和無形資產進行清算、對項目進行綜合評估以及總結經驗教訓等。項目規(guī)劃為項目的研發(fā)和管理工作制定合理的行動綱領（即項目計劃） ，以便所有相關人員按照該計劃有條不紊地開展工作。項目監(jiān)控周期性地跟蹤項目計劃的各種參數如進度、工作量、費用、資源等，不斷地了解項目的進展情況，以便當項目實際進展顯著偏離計劃時能夠及時采取糾正措施。風險管理在風險產

8、生危害之前識別它們，從而有計劃地消除或削弱風險。需求管理在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。項目研發(fā)過程域項目研發(fā)過程域目的目的需求開發(fā)通過調查與分析，獲取用戶需求并定義產品需求。技術預研在立項之后到開發(fā)工作完成之前的時間內，對項目將采用的關鍵技術提前學習和研究，盡可能早地發(fā)現并解決開發(fā)過程中將會遇到的技術障礙。系統(tǒng)設計設計軟件系統(tǒng)的體系結構、用戶界面、數據庫、模塊等，從而在需求與代碼之間建立橋梁，指導開發(fā)人員去實現能滿足用戶需求的軟件產品。實現與測試依據系統(tǒng)設計文檔，編寫并測試整個系統(tǒng)的代碼。在精簡模型中，實現與測試是“編程、代碼審查、單

9、元測試、集成測試、缺陷管理與改錯”的綜合表述。系統(tǒng)測試對最終系統(tǒng)進行全面的測試，確保最終系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計?？蛻趄炇湛蛻粢罁贤瑢Ξa品進行審查和測試，確保產品滿足客戶需求。技術評審盡早地發(fā)現工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而有效地提高產品的質量。機構支撐過程域機構支撐過程域目的目的配置管理通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。質量保證提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質量”與“產品質量” ，從而實現持續(xù)地改進質量。培訓管理根據機構（或項目）的需求來

10、制定培訓計劃，并監(jiān)督該計劃的實施，確保培訓取得預期效果。服務與維護是指產品銷售之后的客戶服務和產品維護，其宗旨是提高客戶對產品以及對開發(fā)方的滿意度。表 1-1 精簡過程域的目的Comment j1: 使用現有的規(guī)范51.3 精簡模型精簡模型 文檔結構與規(guī)范細分文檔結構與規(guī)范細分精簡模型的文檔結構如圖 1-2 所示，SPP 包含 17 個過程域，規(guī)范細分如表 1-2 所示。圖 1-2 精簡模型 文檔結構項目管理過程域項目管理過程域主要規(guī)程主要規(guī)程文檔模板文檔模板立項管理立項建議立項評審項目籌備立項建議書立項調查報告書立項可行性分析報告立項評審報告結項管理結項管理結項申請書結項評審報告項目規(guī)劃制定

11、項目計劃審批項目計劃項目計劃變更控制項目計劃項目計劃變更控制報告項目監(jiān)控項目計劃跟蹤偏差控制項目進展總結項目監(jiān)控數據表項目偏差控制報告項目進展報告風險管理風險管理風險檢查表風險管理報告需求管理需求確認需求跟蹤需求變更控制需求跟蹤報告需求變更控制報告項目研發(fā)過程域項目研發(fā)過程域主要規(guī)程主要規(guī)程文檔模板文檔模板需求開發(fā)需求調查需求分析需求定義用戶需求說明書產品需求規(guī)格說明書技術預研技術預研技術預研計劃技術預研報告過程改進政策過程域規(guī)程文檔模板6系統(tǒng)設計體系結構設計用戶界面設計數據庫設計模塊設計體系結構設計報告用戶界面設計報告數據庫設計報告模塊設計報告實現與測試實現與測試實現與測試計劃編程文檔系統(tǒng)測

12、試系統(tǒng)測試系統(tǒng)測試計劃測試用例測試報告客戶驗收客戶驗收客戶驗收計劃客戶驗收報告技術評審正式技術評審非正式技術評審技術評審計劃技術評審報告技術評審檢查表機構支撐過程域機構支撐過程域規(guī)程與關鍵活動規(guī)程與關鍵活動文檔模板文檔模板質量保證制定質量保證計劃過程與產品質量檢查問題跟蹤與質量改進質量保證計劃質量保證檢查表質量保證報告質量問題跟蹤表配置管理制定配置管理計劃配置庫管理版本控制變更控制配置管理計劃配置庫管理報告配置項變更控制報告培訓管理機構培訓管理項目培訓管理培訓計劃培訓評估報告客戶服務客戶服務計劃客戶服務報告服務與維護產品維護產品維護計劃產品維護報告表 1-2 精簡模型 規(guī)范細分1.4 精簡模型

13、精簡模型 角色與職責表角色與職責表精簡模型的主要角色及其職責如表 1-3 所示（詳見各個過程域對角色與職責的描述） 。公司在應用精簡模型時，可以將精簡模型的各個角色映射到公司原有的崗位上，也可以依據精簡模型角色建立新的崗位。一個人可以被賦予多個角色，一個人可以被賦予多個角色，視具體情況而定。常設角色常設角色職責簡述職責簡述7軟件工程過程組（SEPG）（1）制定適合于本機構的過程規(guī)范。（2）在機構范圍內推廣該規(guī)范（如培訓、考核） ，評估機構過程能力等。機構過程改進角色質量保證小組（QAG）（1）監(jiān)督規(guī)范的實施，確保所有項目以及相關部門準照規(guī)范開展工作。（2）分析并解決機構內存在的共性質量問題，協(xié)

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

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

16、維護：及時解決用戶遇到的技術故障和消除產品中的缺陷。（2）完善性維護：在資源允許的情況下，不斷改善產品功能與質量。臨時角色臨時角色職責說明職責說明立項建議小組（1）開展立項調查、產品構思和可行性分析，撰寫相應文檔。（2）申請立項，并在立項評審會議上答辯。立項評審委員會由機構領導、各級經理、市場人員、技術專家、財務人員等組成，委員會按少數服從多數原則投票決定是否同意立項。結項評審委員會對項目的有形資產和無形資產進行清算，對項目進行綜合評估，總結經驗教訓等。結項委員會的人員組成與立項評審委員會的類似。技術評審委員會對工作成果進行正式技術評審，盡早地發(fā)現工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷。

17、該委員會由項目內外的技術專家組成。配置控制委員會對配置管理各項活動擁有決策權（例如審批計劃，審批變更請求等） 。表 1-3 精簡模型的角色與職責簡表81.5 公司軟件過程的政策公司軟件過程的政策1.5.1 目標目標持續(xù)改進機構的軟件過程能力，不斷地提高產品質量、提高生產率并且降低開發(fā)成本。1.5.2 機構領導的支持機構領導的支持機構領導批準用于軟件過程改進的必要經費，例如支付咨詢費，購買相關軟件工具等。機構領導組建 SEPG 和 QAG，專門從事軟件過程改進工作。SEPG 的主要職責是建立適合于機構的過程規(guī)范，QAG 的主要職責是監(jiān)督該規(guī)范的實施。建議讓 SEPG 和 QAG 的大部分人員重疊

18、，這些人既是 SEPG 成員又是質量保證員，扮演兩種角色。這樣不僅節(jié)約人力資源，并且提高了工作效果（由制定規(guī)范的人去監(jiān)督規(guī)范的實施最合適不過） 。一般地，SEPG 成員和質量保證員共占機構總人數的 5%左右。機構領導不僅要口頭支持，還要親自參與軟件過程改進的實踐。例如參加培訓和考試，準照過程規(guī)范執(zhí)行立項管理和結項管理等。1.5.3 質量管理的政策質量管理的政策質量管理口號：“在開發(fā)過程之中內建質量而非修補質量” 。質量管理有種基本措施：“質量保證” 、 “技術評審”和“測試” 。一、一、質量保證質量保證機構的質量保證員周期性地檢查項目成員的“工作過程以及工作成果”是否符合既定的規(guī)范，來監(jiān)控和改

19、進“過程質量以及產品質量” 。機構的質量保證員獨立于任何項目，并賦予他一定的權利，對質量不合格的工作成果作出處理。二、技術評審二、技術評審在工作成果剛產生之際，對其進行技術評審（分正式或非正式兩種） ，目的是盡早地發(fā)現工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而提高產品的質量。如果時間允許的話，應當盡可能多地對產品的重要工作成果進行技術評審。技術評審活動由項目開發(fā)團隊組織。三、測試三、測試測試是指通過運行測試用例（test case）來找出軟件中的缺陷。測試與技術評審的主要區(qū)別是前者要運行軟件而后者不必運行軟件。一般地，產品開發(fā)過程中有四個測試階段：單元測試、集成測試、系統(tǒng)測試和驗收測試

20、。其中單元測試和集成測試可以由項目開發(fā)團隊組織。系統(tǒng)測試階段必須有項目外的人員參與，以保證系統(tǒng)測試的客觀性。驗收測試由客戶組織。如果有條件的話，建議機構成立專門的測試小組從事單元測試、集成測試和系統(tǒng)測試工作。91.5.4 質量保證小組的政策質量保證小組的政策機構領導任命一位熟悉過程規(guī)范并且有豐富的質量管理經驗的人擔任 QAG 的負責人（或稱為質量經理） 。在機構領導的許可下，該負責人組建 QAG（成員可以是全職的也可以是兼職的） 。QAG 在行政上獨立于任何項目。這種獨立性有助于質量保證員客觀地檢查和監(jiān)控“過程以及產品的質量” 。QAG 準照 SEPG 制定的“質量保證規(guī)范”開展工作。機構領導

21、賦予 QAG 一定的權利，可以對質量不合格的工作成果做出處理。這種權利使得 QAG 的工作不會被輕視，并有助于加強全員的質量意識。對于 QAG 與項目之間出現的難以調和的爭議，由機構領導處理。1.5.5 項目團隊的政策項目團隊的政策項目中的任何管理人員、開發(fā)人員、測試人員等，必須學習與本職工作相關的過程規(guī)范，每個人都必須明白自己“應當在什么時候依據什么規(guī)范做什么事情應當在什么時候依據什么規(guī)范做什么事情” 。項目經理應當樹立榜樣，并且督促項目成員們按規(guī)范做事。允許項目經理根據本項目的特征，在 SEPG 和 QAG 的指導下，適當地裁剪或擴充機構的過程規(guī)范，從而快速建立本項目的過程規(guī)范。這項工作應

22、當在“項目規(guī)劃過程域”中完成，并在項目計劃中體現出來。如果項目對機構過程規(guī)范的裁剪幅度比較大，遭到 QAG 的反對，如果雙方不能達成共識，則由機構領導處理該爭議。SEPG 對項目過程能力的評估成績將作為評定項目人員工作業(yè)績的重要因素，具體比重由機構領導決定，建議占 30以上的比重。2 立項管理立項管理參見項目管理制度試行 V2.1 版本3 項目規(guī)劃項目規(guī)劃在立項管理過程域的項目籌備階段，機構領導首先任命一位項目經理，之后機構領導協(xié)助項目經理籌備項目經費、人力資源、軟件硬件資源等。如果必要的資金和資源已經到位，那么項目經理和核心成員即可組成一個項目規(guī)劃小組，著手制定項目計劃 ，并按計劃執(zhí)行研發(fā)和

23、管理工作。項目的計劃書可分兩類：一是全局的計劃書（Overall Plan） ，這里稱為項目計劃 ；二是一些下屬計劃書（Subordinate Plan） ，例如配置管理計劃 、 質量保證計劃 、一些開發(fā)計劃和測試計劃等。10下屬計劃書是對項目計劃的補充，其內容不可與項目計劃沖突。通常項目計劃由項目經理負責制定，由機構領導審批。而下屬計劃書一般由項目成員制定，由項目經理審批即可。項目計劃過程域有 3 個主要規(guī)程：“制定項目計劃” 、 “審批項目計劃”和“項目計劃變更控制” ，流程如圖 3-1 所示。 圖 3-1 項目規(guī)劃流程圖項目計劃模板4 項目監(jiān)控項目監(jiān)控項目監(jiān)控（Project Monit

24、oring and Control, PMC）的目的是通過周期性地跟蹤項目計劃的各種參數如進度、工作量、費用、資源、工作成果等，不斷地了解項目的進展情況，以便當項目實際進展狀況顯著偏離計劃時能夠及時采取糾正措施。本規(guī)范闡述了項目監(jiān)控過程域的三個主要規(guī)程：項目計劃跟蹤控制偏差 項目進展匯報 圖 4-1 項目監(jiān)控流程制定項目計劃審批項目計劃項目計劃變更控制按計劃執(zhí)行研發(fā)與管理工作項目計劃跟蹤偏差控制項目進展總結周期性地開展114.1 項目計劃跟蹤項目計劃跟蹤周期性的跟蹤任務（含進度和工作量） 、費用、資源、工作成果等，及時了解項目的實際進展情況。為持續(xù)過程改進提供有價值的數據。4.1.1 任務跟蹤

25、任務跟蹤項目經理（或其指定的項目成員）周期性地（如每周一次）跟蹤每個重要的任務，將采集的數據保存在項目監(jiān)控數據表之中。任務跟蹤表的參考格式如表 4-1 所示。任務名稱任務名稱實際起止時間實際起止時間跟蹤日期、當前進度跟蹤日期、當前進度實際工作量實際工作量實際工作成果實際工作成果表 4-1 任務跟蹤表4.1.2 費用跟蹤費用跟蹤項目經理（或其指定的項目成員）周期性地跟蹤項目費用，將采集的數據保存在項目監(jiān)控數據表之中。費用跟蹤表的參考格式如表 4-2 所示。費用類別費用類別主要開支項、用途主要開支項、用途金額金額時間時間表 4-2 費用跟蹤表4.1.3 資源跟蹤資源跟蹤項目經理（或其指定的項目成員

26、）周期性地跟蹤軟硬件資源，將采集的數據保存在項目監(jiān)控數據表之中。資源跟蹤表的參考格式如表 4-3 所示。軟硬件資源名稱軟硬件資源名稱級別級別實際配置實際配置獲取方式與時間獲取方式與時間使用說明使用說明關鍵12關鍵普通普通表 4-3 資源跟蹤表4.1.4 工作成果及其規(guī)模跟蹤工作成果及其規(guī)模跟蹤項目經理（或其指定的項目成員）周期性地跟蹤工作成果及其規(guī)模，將采集的數據保存在項目監(jiān)控數據表之中。工作成果跟蹤表的參考格式如表 4-4 所示。工作成果名稱工作成果名稱新開發(fā)的成果規(guī)模新開發(fā)的成果規(guī)模（代碼行、類、文檔頁數）（代碼行、類、文檔頁數）復用或自動生成的成果規(guī)模復用或自動生成的成果規(guī)模（代碼行、類

27、、文檔頁數）（代碼行、類、文檔頁數）工作成果 1工作成果 2總和總和表 4-4 工作成果及其規(guī)模跟蹤表4.2 控制偏差控制偏差對比“項目實際進展”和“項目計劃” ，分析偏差，如果發(fā)現項目實際進展顯著偏離計劃，則及時采取糾正措施。記錄日期記錄日期顯著偏差描述顯著偏差描述原因分析原因分析糾正措施糾正措施結果結果表 4-5 項目偏差控制報告134.3 項目進展匯報項目進展匯報周期性地匯報項目進展情況。項目經理周期性地總結項目進展情況，撰寫項目進展報告并通報給機構領導和所有項目成員。基本信息基本信息項目名稱報告日期項目編號報告批次第 N 份項目經理項目所處階段項目進展狀況項目進展狀況計劃計劃實際情況實

28、際情況任務與進度工作成果費用人力資源軟硬件資源問題與對策問題與對策表 4-6 項目進展報告145 風險管理風險管理風險管理（Risk Management, RiskM）的目的是在風險產生危害之前識別它們，從而有計劃地消除或削弱風險。所有可能危害項目的因素都稱為風險。被刻畫為風險的事件最終可能發(fā)生也可能不發(fā)生。人們對待風險有兩種態(tài)度。一種是被動態(tài)度，可比作“救火模式” 。另一種是主動態(tài)度，可比作“防火模式” 。風險管理屬于“防火模式” ，目的就是“防止風險產生真正的危害” 。為了便于量化管理，我們給風險定義 3 個參數：風險嚴重性：指風險對項目造成的危害程度。風險可能性：指風險發(fā)生的幾率。風險

29、系數：是風險嚴重性和風險可能性的乘積。參數參數等級等級值值描述描述很高5例如進度延誤大于 30%，或者費用超支大于 30%。比較高4例如進度延誤 20%30%，或者費用超支 20%30%。中等3例如進度延誤低于 20%，或者費用超支低于 20%。比較低2例如進度延誤低于 10%，或者費用超支低于 10%。風險嚴重性很低1例如進度延誤低于 5%，或者費用超支低于 5%。表 5-1 風險嚴重性等級參數參數等級等級值值描述描述很高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風險

30、發(fā)生的幾率為 0.2 0.0表 5-2 風險可能性等級風險可能性風險可能性風險風險系數系數很高 5比較高 4中等 3比較低 2很低 1很高 5252015105比較高 420161284中等 31512963比較低 2108642風險風險嚴重性嚴重性很低 154321本表灰色部分的風險系數值為本表灰色部分的風險系數值為 1025，應當優(yōu)先處理。，應當優(yōu)先處理。表 5-3 風險系數等級15風險嚴重性的等級劃分如表 5-1 所示，風險可能性的等級劃分如表 5-2 所示，風險系數的等級劃分如表 3 所示。風險管理有 4 個主要活動：風險識別：根據風險檢查表，識別出本項目的風險。風險分析：估計風險嚴重

31、性、風險可能性、風險系數。風險減緩：對于風險系數超過“容許值”的每一個風險，都應當采取減緩措施。風險跟蹤：跟蹤風險減緩過程，記錄風險的狀態(tài)。圖 5-1 風險管理示意圖在項目的生命周期內，上述 4 個活動將被循環(huán)執(zhí)行，如圖 5-1 所示。直到項目的所有風險都被識別與解決為止。常用的風險檢查表 ，使用者應根據實際情況進行適當的刪減或補充。風險管理過程域產生的主要文檔是風險管理報告 。商業(yè)風險商業(yè)風險風險類型檢查項政府或者其他機構對本項目的開發(fā)有限制嗎？有不可預測的市場動蕩嗎？有不利于我方的官司要打嗎？本產品銷售后在使用過程中可能導致發(fā)生重大的損失或傷亡事故嗎？競爭對手有不正當的競爭行為嗎？本產品銷

32、售后在使用過程中可能導致發(fā)生重大的損失或傷亡事故嗎？是否在開發(fā)很少有人真正需要卻自以為很好的產品？政治法律市場是否在開發(fā)可能虧本的產品？客戶的需求是否含糊不清？客戶是否反反復復地改動需求？客戶指定的需求和交付期限在客觀上可行嗎？客戶對產品的健壯性、可靠性、性能等質量因素有非常過分的要求嗎？客戶的合作態(tài)度友善嗎？與客戶簽的合同公正嗎？雙方互利嗎？客戶客戶的信譽好嗎？例如按客戶的需求開發(fā)了產品，但是客戶可能不購買。風險識別風險分析風險減緩風險跟蹤16與子承包商、供應商簽訂的合同公正嗎？雙方互利嗎？子承包商、供應商的信譽好嗎？子承包商、供應商有可能倒閉嗎？子承包商、供應商能及時交付質量合格的產品（或

33、部件）嗎？子承包商供應商子承包商、供應商有能力做好售后服務嗎？管理風險管理風險風險類型檢查項對項目的規(guī)模、難度估計是否比較正確？人力資源（開發(fā)人員、管理人員）夠用嗎？合格嗎？項目所需的軟件、硬件能按時到位嗎？項目的經費夠用嗎？進度安排是否過于緊張？有合理的緩沖時間嗎？進度表中是否遺忘了一些重要的（必要的）任務？進度安排是否考慮了關鍵路徑？ 是否可能出現某一項工作延誤導致其他一連串的工作也被延誤？任務分配是否合理？（即把任務分配給合適的項目成員，充分發(fā)揮其才能）是否為了節(jié)省錢，不采用（購買）成熟的軟件模塊，一切從零做起？項目計劃項目成員團結嗎？是否存在矛盾？是否絕大部分的項目成員對工作認真負責？

34、絕大部分的項目成員有工作熱情嗎？團隊之中有“害群之馬”嗎？技術開發(fā)隊伍中有臨時工嗎？本項目開發(fā)過程中是否會有核心人員辭職、調動？是否能保證“人員流動基本不會影響工作的連續(xù)性”？項目團隊項目經理是否忙于行政事務而無暇顧及項目的開發(fā)工作？本項目是否得到上級領導的重視？上級領導是否隨時會抽調本項目的資源用于其他“高優(yōu)先級”的項目？上級領導是否過多地介入本項目的事務并且瞎指揮？行政部門的辦事效率是否比較底，以至于拖項目的后腿？行政部門是否經常干一些無益于生產力的事情，以至于騷擾本項目？機構是否能全面、公正地考核員工的工作業(yè)績？機構是否有較好的獎勵和懲罰措施？上級領導行政部門合作部門本項目的合作部門的態(tài)

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

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

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

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

39、本合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。評審意見評審小組成員輸入評審小組成員表 6-1 需求評審報告需求承諾需求承諾需求文檔輸入名稱，標識符，版本，作者，完成日期客戶承諾承諾簽字，日期項目經理承諾承諾簽字，日期表 6-2 需求承諾6.2 需求跟蹤需求跟蹤將系統(tǒng)設計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文檔設計文檔代碼測試用例”之間的一致性，確保產品依據需求文檔進行開發(fā)。20項目經理跟蹤需求。建立與維護需求跟蹤矩陣：正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應點。逆向跟蹤。檢查設計文檔

40、、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。正向跟蹤和逆向跟蹤合稱為“雙向跟蹤” 。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格） 。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應關系。矩陣單元之間的可能存在“一對一” 、 “一對多”或“多對多”的關系。由于對應關系比較復雜，最好在表格中加必要的文字解釋。表 6-3 為簡單的需求跟蹤矩陣格式。當需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。需求文檔（版本，日期）設計文檔（版本，日期）代碼（版本，日期）測試用例（版本，日期）1標題或標識符，說明標題或標識符，說明代碼名稱，說明測試用例名稱，說明2表 6-3 簡單的需

41、求跟蹤矩陣格式6.3 需求變更控制需求變更控制修改“原需求文檔”中不正確的內容，產生新的需求文檔?？刂菩枨笪臋n的變更，防止發(fā)生混亂。補充說明：本規(guī)程中的“原需求文檔”是指已經通過了評審并獲得書面承諾的需求文檔。開發(fā)方負責人（項目經理）和客戶共同控制需求變更。需求變更申請需求變更申請申請變更的需求文檔輸入名稱，版本，日期等信息變更的內容及其理由21評估需求變更將對項目造成的影響申請人簽字變更申請的審批意見變更申請的審批意見項目經理簽字審批意見：簽字，日期客戶簽字（合同項目）審批意見：簽字，日期更改需求文檔更改需求文檔變更后的需求文檔輸入名稱，版本，完成日期等信息更改人簽字重新評審需求文檔重新評審

42、需求文檔需求評審小組簽字評審意見：簽字，日期變更結束變更結束項目經理簽字簽字日期：22表 6-4 需求變更控制報告7 結項管理結項管理結項管理（Project Closing Management, PCM）是指在項目開發(fā)工作結束后，對項目的有形資產和無形資產進行清算；對項目進行綜合評估；總結經驗教訓等。立項管理與結項管理是前后呼應的兩個過程域，使得項目管理過程“有始有終” 。項目結束有兩種狀況：一是正常結束，二是異常結束。前者是指項目按預定計劃結束。后者原因有多種，歸根結底都是由于該項目不再符合機構的最大利益。例如有些項目因不適應市場而被中途淘汰，有些項目在執(zhí)行過程中大大因偏離計劃（如進度延

43、誤、費用超支）而被取消。不論項目屬于正常結束還是異常結束，都要按照結項管理規(guī)范處理。不論項目屬于正常結束還是異常結束，都要按照結項管理規(guī)范處理。國內很多項目普遍存在“虎頭蛇尾”的現象，結項管理畸變成了“走過場，吃頓飯” ，這是非常有害的。有價值的結項管理至少包括三項內容：對項目的有形資產和無形資產進行清算，既要防止資產流失，又要及時地利用這些資產。對項目進行綜合評估。例如評估項目完成情況、項目質量、投入產出分析、項目的市場價值、項目對企業(yè)的貢獻等等。該評估報告可以作為考核項目人員業(yè)績的重要依據?？偨Y經驗教訓，使整個機構受益。圖 7-1 結項管理流程圖結項管理的流程如圖 7-1 所示，產生的主要

44、文檔有：結項申請書結項評審報告機構領導指示結項申請機構領導審批結項評審資產檢查綜合評估經驗總結238 需求開發(fā)需求開發(fā)需求開發(fā)（Requirement Development, RD）的目的是通過調查與分析，獲取用戶需求并定義產品需求。本規(guī)范闡述了需求開發(fā)過程域的兩個主要規(guī)程：需求調查需求定義需求開發(fā)與需求管理是相輔相成的兩類活動，它們共同構成完整的需求工程。需求工程結構圖如圖 6-1 所示，需求開發(fā)和需求管理的流程如圖 8-1 所示。圖 8-1 需求開發(fā)與需求管理流程圖需求開發(fā)可分為兩個階段：“用戶需求調查階段”和“產品需求定義階段” 。而“需求分析”則貫穿于上述兩個階段。需求調查階段和需求

45、定義階段在邏輯上存在先后關系，實際工作中二者通常是迭代進行的。我們把從事需求開發(fā)工作的人員稱為需求分析員（也叫系統(tǒng)分析員） ，避免與其它開發(fā)人員混淆。一、需求調查一、需求調查需求調查的目的是通過各種途徑獲取用戶的需求信息（原始材料） ，產生用戶需求說明書 。二、需求分析二、需求分析需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。常用的需求分析方法有“問答分析法” 、 “結構化分析法”和“面向對象分析法” 。三、需求定義三、需求定義需求分析用戶需求說明書產品需求規(guī)格說明書用戶需求調查輸出輸出產品需求定義需求變更控制需求確認需求跟蹤需求開發(fā)過程域需求管理過程域24需求定義的目的是根據

46、需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生產品需求規(guī)格說明書 。系統(tǒng)設計人員將依據產品需求規(guī)格說明書開展系統(tǒng)設計工作。需求開發(fā)過程域產生的主要文檔有： 用戶需求說明書產品需求規(guī)格說明書9 技術預研技術預研技術預研（Technical Pre-Research, TPR）是指在立項之后到開發(fā)工作完成之前的時間內，對項目將采用的關鍵技術提前學習和研究，以便盡可能早地發(fā)現并解決開發(fā)過程中將會遇到的技術障礙。在產品開發(fā)過程中，技術問題可能會層出不窮。如果一點技術障礙都沒有遇到，要么是開發(fā)人員的技術水平實在太高了，要么是項目的技術含量實在太低了，這類情況比較少見。一般說來，在設計或實現

47、階段遇到了技術障礙，才去攻克問題，其代價通常比較高。因為其他人的工作可能會被阻塞，已經投入的不少資源將被閑置。最糟糕的是，如果此技術障礙無法攻克，不得已要改變技術方案、重新設計系統(tǒng)，那么不僅浪費了人力、財力、時間，處理不好還會使開發(fā)隊伍陷入混亂狀態(tài)。所以開展技術預研工作至少有兩大好處：幫助開發(fā)人員更好地進行需求開發(fā)、系統(tǒng)設計和程序設計。防止開發(fā)進程被技術障礙打斷，導致大量的相關工作被阻塞。技術預研的流程如圖 9-1 所示。圖 9-1 技術預研流程技術預研過程中產生的主要文檔有： 技術預研計劃技術預研報告制定計劃撰寫預研報告工作成果介紹技術評審開展技術預研2510 系統(tǒng)設計系統(tǒng)設計系統(tǒng)設計（Sy

48、stem Design, SD）是指設計軟件系統(tǒng)的體系結構、用戶界面、數據庫、模塊等，從而在需求與代碼之間建立橋梁，指導開發(fā)人員去實現能滿足用戶需求的軟件產品。本規(guī)范闡述了系統(tǒng)設計過程域的四個主要規(guī)程：體系結構設計 用戶界面設計 數據庫設計 模塊設計 系統(tǒng)設計過程域分為兩個階段：高層設計階段和詳細設計階段。高層設計階段的重點是軟件系統(tǒng)的體系結構設計。詳細設計階段的重點是用戶界面設計、數據庫設計和模塊設計，如圖 10-1 所示。圖 10-1 系統(tǒng)設計過程域示意圖系統(tǒng)設計過程域產生的主要文檔有：體系結構設計報告用戶界面設計報告數據庫設計報告模塊設計報告10.1 體系結構設計體系結構設計分析與設計軟

49、件的體系結構。通過系統(tǒng)分解，確定子系統(tǒng)的功能和子系統(tǒng)之間的關系，以及模塊的功能和模塊之間的關系，產生體系結構設計報告 。項目經理指定若干名開發(fā)人員從事體系結構設計（以下稱為體系結構設計人員） 。詳細設計階段高層設計階段體系結構設計模塊設計數據庫設計用戶界面設計需求開發(fā)實現與測試26體系結構設計流程如圖 10-2 所示。圖 10-2 體系結構設計流程體系結構設計報告10.2 用戶界面設計用戶界面設計設計軟件的用戶界面，產生用戶界面設計報告 。制作用戶界面的資源如圖像、圖標或者界面專用組件等項目經理指定若干名開發(fā)人員從事用戶界面設計（以下稱為界面設計人員） 。如果可能的話，邀請用戶或美工人員協(xié)助設

50、計用戶界面。用戶界面設計流程如圖 10-3 所示。圖 10-3 體系結構設計流程用戶界面設計Step1. 設計準備Step5. 撰寫文檔Step6. 設計評審Step2. 確定約束因素Step3. 確定設計策略Step4. 系統(tǒng)分解設計Step2. 界面設計Step1. 設計準備2.1 原型創(chuàng)作2.2 原型評估2.3 細化Step3. 撰寫文檔Step4. 設計評審迭代2710.3 數據庫設計數據庫設計設計軟件的數據庫，產生數據庫設計報告 。項目經理指定若干名開發(fā)人員從事數據庫設計（以下稱為數據庫設計人員） 。數據庫設計流程如圖 10-4 所示。圖 10-4 數據庫設計流程數據庫設計報告10.

51、4 模塊設計模塊設計設計軟件所有模塊的主要接口與屬性、數據結構和算法，產生模塊設計報告 。項目經理指定若干名開發(fā)人員從事模塊的設計（以下稱為模塊設計人員） ，模塊設計人員將在實現階段編寫這些模塊的代碼。模塊設計流程如圖 10-5 所示。Step2. 數據庫設計Step1. 設計準備2.1 邏輯設計2.2 物理設計2.3 安全性設計2.4 優(yōu)化Step3. 撰寫文檔Step4. 設計評審迭代Step2. 模塊設計Step1. 設計準備2.1 接口與屬性設計2.2 數據結構與算法設計Step3. 撰寫文檔Step4. 設計評審迭代28圖 10-5 模塊設計流程模塊設計報告11 實現與測試實現與測試

52、實現與測試（Implementation and Test, IT）的目的是依據系統(tǒng)設計文檔，編寫并測試整個系統(tǒng)的代碼。在本規(guī)范中，實現與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。實現與測試的流程如圖 11-1 所示。一般地，編程、代碼審查、單元測試、集成測試大致存在先后順序關系，也可以并行、迭代地開展。上述任何活動中發(fā)現的缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應當及時消除缺陷（改錯） 。圖 11-1 實現與測試流程圖由于實現與測試是工作量最大、時間最長、產生工作成果（代碼與文檔）最多的一個項目研發(fā)過程域，所以需要作充分的準備工作。實現與測試工作基本上在開發(fā)

53、小組內部開展。一個項目可能有一個或者多個開發(fā)小組。對于小型項目，項目經理可以兼任開發(fā)組長。特別要注意的是，開發(fā)人員應當對自己的代碼進行審查和測試（這是份內的工作） ，但是不能作為該代碼已經通過審查和測試的依據。所以開發(fā)人員還要互相審查和測試同伴的代碼。實現與測試過程域產生的主要文檔有：實現與測試計劃編程文檔代碼審查報告編程代碼審查單元測試集成測試模塊軟件系統(tǒng)準備缺陷管理與改錯29測試用例測試報告缺陷管理報告 （由缺陷管理工具自動生成）一個項目可能有多個開發(fā)小組，視項目規(guī)模而定。開發(fā)組長由項目經理指定。開發(fā)組長管理編程、代碼審查、單元測試、集成測試、缺陷管理與改錯等活動。 編程文檔實現與測試計劃

54、12 系統(tǒng)測試系統(tǒng)測試系統(tǒng)測試（System Test, ST）的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計。系統(tǒng)測試流程如圖 12-1 所示。由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計，所以當產品需求和系統(tǒng)設計文檔完成之后，系統(tǒng)測試小組就可以提前開始制定測試計劃和設計測試用例，而不必等到“實現與測試”階段結束。這樣可以提高系統(tǒng)測試的效率。系統(tǒng)測試過程中發(fā)現的所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應當及時消除缺陷（改錯） 。圖 12-1 系統(tǒng)測試流程圖項目經理設法組建富有成效的系統(tǒng)測試小組。系統(tǒng)測試小組的成員主要來源于：機構

55、獨立的測試小組（如果存在的話） 。邀請其它項目的開發(fā)人員參與系統(tǒng)測試。本項目的部分開發(fā)人員。機構的質量保證人員。制定測試計劃設計測試用例執(zhí)行系統(tǒng)測試缺陷管理與改錯審批審批迭代30系統(tǒng)測試小組應當根據項目的特征確定測試內容。一般地，系統(tǒng)測試的主要內容包括：功能測試。即測試軟件系統(tǒng)的功能是否正確，其依據是需求文檔，如產品需求規(guī)格說明書 。由于正確性是軟件最重要的質量因素，所以功能測試必不可少。健壯性測試。即測試軟件系統(tǒng)在異常情況下能否正常運行的能力。健壯性有兩層含義：一是容錯能力，二是恢復能力。性能測試。即測試軟件系統(tǒng)處理事務的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數據供人們參考

56、（例如用于宣傳） 。用戶界面測試。重點是測試軟件系統(tǒng)的易用性和視覺效果等。安全性（security）測試。是指測試軟件系統(tǒng)防止非法入侵的能力。 “安全”是相對而言的，一般地，如果黑客為非法入侵花費的代價（考慮時間、費用、危險等因素）高于得到的好處，那么這樣的系統(tǒng)可以認為是安全的。安裝與反安裝測試。系統(tǒng)測試過程域產生的主要文檔有：系統(tǒng)測試計劃系統(tǒng)測試用例系統(tǒng)測試報告缺陷管理報告對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計。項目經理組建系統(tǒng)測試小組，并指定一名成員任測試組長。系統(tǒng)測試小組各成員共同制定測試計劃、設計測試用例、執(zhí)行測試，并撰寫相應的文檔。測試組長管理上述

57、事務。開發(fā)人員及時消除測試人員發(fā)現的缺陷。 系統(tǒng)測試計劃測試用例測試報告13 客戶驗收客戶驗收客戶驗收（Customer Acceptance, CA）是指客戶依據合同對產品進行審查和測試，確保產品滿足客戶需求?？蛻魧Ξa品的驗收主要有兩種方式：成果審查。驗收人員審查開發(fā)方應當交付的成果，如代碼、文檔等等。確保這些成果是完整的并且是正確的。驗收測試。驗收人員對待交付的產品進行全面的測試，確保產品功能、質量符合需31求。驗收測試的內容、方法與系統(tǒng)測試幾乎是相同的。兩者主要區(qū)別在于執(zhí)行人員不同。驗收測試人員來自于客戶方，而系統(tǒng)測試人員則來自于開發(fā)方。客戶驗收流程如圖 13-1 所示。圖 13-1 客

58、戶驗收流程客戶驗收過程域產生的主要文檔有：客戶驗收計劃驗收測試用例 客戶驗收報告補充說明：補充說明：“客戶驗收”是針對合同項目而言的。 客戶驗收計劃客戶驗收報告14 技術評審技術評審技術評審（Technical Review, TR）的目的是盡早地發(fā)現工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而有效地提高產品的質量。本規(guī)范闡述了技術評審過程域的三個主要規(guī)程：制定技術評審計劃 正式技術評審 非正式技術評審技術評審能夠在任何開發(fā)階段執(zhí)行，它可以比測試更早地發(fā)現并消除工作成果中的缺陷。技術評審的主要好處有：通過消除工作成果的缺陷而提高產品的質量。越早消除缺陷就越能降低開發(fā)成本。開發(fā)人員能夠及時

59、地得到同行專家的幫助和指導，無疑會加深對工作成果的理解，更好地預防缺陷，一定程度上提高了開發(fā)生產率?？梢娂夹g評審有助于“提高質量、提高生產率、降低成本” ，符合軟件過程改進的根本目的。驗收準備問題處理成果審查與驗收測試交付與簽字32技術評審有兩種基本類型：正規(guī)技術評審（FTR） 。FTR 比較嚴格，需要舉行評審會議，參加評審會議的人員比較多。非正規(guī)技術評審（ITR） 。ITR 的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，評審人員比較少。理論上講，為了確保產品的質量，產品的所有工作成果都應當接受技術評審?，F實中，為了節(jié)約時間，允許人們有選擇地對工作成果進行技術評審。技術評審方式也視工作

60、成果的重要性和復雜性而定。技術評審過程域有三個主要規(guī)程：“制定技術評審計劃” 、 “正規(guī)技術評審”和“非正規(guī)技術評審” ，如圖 14-1 所示。圖 14-1 技術評審過程域示意圖技術評審的注意事項：評審人員的職責是發(fā)現工作成果中的缺陷，并幫助開發(fā)人員給出消除缺陷的辦法，而不是替開發(fā)人員消除缺陷。技術評審應當“就是論事” ，不要打擊有失誤的開發(fā)人員的工作積極性，更不準搞人身攻擊（如挖苦、諷刺等） 。在會議評審期間要限制過多的爭論，以免浪費他人的時間。技術評審過程域產生的主要文檔有：技術評審計劃技術評審通知技術評審報告技術評審檢查表 技術評審計劃技術評審通知技術評審報告 技術評審檢查表15 配置管