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

1、0軟件研發(fā)管理制度軟件研發(fā)管理制度文件標(biāo)識：Lolaage-Software-PM當(dāng)前版本：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 精簡模型精簡模型 文檔結(jié)構(gòu)與規(guī)范細(xì)分文檔結(jié)構(gòu)與規(guī)范細(xì)分 .51.4 精簡模型精簡模型 角色與職責(zé)表角色與職責(zé)表 .61.5 公司軟件過程的政策公司軟件過程的政策 .81

2、.5.1 目標(biāo).81.5.2 機(jī)構(gòu)領(lǐng)導(dǎo)的支持.81.5.3 質(zhì)量管理的政策.81.5.4 質(zhì)量保證小組的政策.91.5.5 項(xiàng)目團(tuán)隊(duì)的政策.92 立項(xiàng)管理立項(xiàng)管理 .93 項(xiàng)目規(guī)劃項(xiàng)目規(guī)劃 .94 項(xiàng)目監(jiān)控項(xiàng)目監(jiān)控 .104.1 項(xiàng)目計(jì)劃跟蹤項(xiàng)目計(jì)劃跟蹤 .114.1.1 任務(wù)跟蹤任務(wù)跟蹤 .114.1.2 費(fèi)用跟蹤費(fèi)用跟蹤 .114.1.3 資源跟蹤資源跟蹤 .114.1.4 工作成果及其規(guī)模跟蹤工作成果及其規(guī)模跟蹤 .124.2 控制偏差控制偏差 .124.3 項(xiàng)目進(jìn)展匯報(bào)項(xiàng)目進(jìn)展匯報(bào) .135 風(fēng)險(xiǎn)管理風(fēng)險(xiǎn)管理 .146 需求管理需求管理 .186.1 需求確認(rèn)需求確認(rèn) .186.2 需

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

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

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

6、的過程域都合理地安排在產(chǎn)品生命周期中的某些階段。用戶可以根據(jù)自己產(chǎn)品的特征，適當(dāng)?shù)夭眉艋驍U(kuò)充精簡的過程域，很容易制定出最適合于本產(chǎn)品的過程模型。0圖 1-1 精簡模型產(chǎn)品概念產(chǎn)品定義產(chǎn)品開發(fā)產(chǎn)品測試客戶驗(yàn)收產(chǎn)品維護(hù)立項(xiàng)管理項(xiàng)目規(guī)劃項(xiàng)目監(jiān)控 風(fēng)險(xiǎn)管理 需求管理結(jié)項(xiàng)管理需求開發(fā)配置管理 質(zhì)量保證 培訓(xùn)管理項(xiàng)目管理過程項(xiàng)目研發(fā)過程機(jī)構(gòu)支撐過程服務(wù)與維護(hù)技術(shù)評審技術(shù)評審技術(shù)預(yù)研并行、迭代根據(jù)產(chǎn)品特征確定最合適的開發(fā)模型，以線性順序?yàn)橹鳎圆⑿?、迭代為輔。系統(tǒng)設(shè)計(jì)實(shí)現(xiàn)與測試系統(tǒng)測試客戶驗(yàn)收其它： 人力資源管理 財(cái)務(wù)管理 行政管理 市場營銷 41.2 精簡過程域的目的精簡過程域的目的精簡模型 所有 17

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

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

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

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

11、項(xiàng)目計(jì)劃審批項(xiàng)目計(jì)劃項(xiàng)目計(jì)劃變更控制項(xiàng)目計(jì)劃項(xiàng)目計(jì)劃變更控制報(bào)告項(xiàng)目監(jiān)控項(xiàng)目計(jì)劃跟蹤偏差控制項(xiàng)目進(jìn)展總結(jié)項(xiàng)目監(jiān)控?cái)?shù)據(jù)表項(xiàng)目偏差控制報(bào)告項(xiàng)目進(jìn)展報(bào)告風(fēng)險(xiǎn)管理風(fēng)險(xiǎn)管理風(fēng)險(xiǎn)檢查表風(fēng)險(xiǎn)管理報(bào)告需求管理需求確認(rèn)需求跟蹤需求變更控制需求跟蹤報(bào)告需求變更控制報(bào)告項(xiàng)目研發(fā)過程域項(xiàng)目研發(fā)過程域主要規(guī)程主要規(guī)程文檔模板文檔模板需求開發(fā)需求調(diào)查需求分析需求定義用戶需求說明書產(chǎn)品需求規(guī)格說明書技術(shù)預(yù)研技術(shù)預(yù)研技術(shù)預(yù)研計(jì)劃技術(shù)預(yù)研報(bào)告過程改進(jìn)政策過程域規(guī)程文檔模板6系統(tǒng)設(shè)計(jì)體系結(jié)構(gòu)設(shè)計(jì)用戶界面設(shè)計(jì)數(shù)據(jù)庫設(shè)計(jì)模塊設(shè)計(jì)體系結(jié)構(gòu)設(shè)計(jì)報(bào)告用戶界面設(shè)計(jì)報(bào)告數(shù)據(jù)庫設(shè)計(jì)報(bào)告模塊設(shè)計(jì)報(bào)告實(shí)現(xiàn)與測試實(shí)現(xiàn)與測試實(shí)現(xiàn)與測試計(jì)劃編程文檔系統(tǒng)測

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

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

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

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

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

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

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

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

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

21、賦予 QAG 一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。這種權(quán)利使得 QAG 的工作不會被輕視，并有助于加強(qiáng)全員的質(zhì)量意識。對于 QAG 與項(xiàng)目之間出現(xiàn)的難以調(diào)和的爭議，由機(jī)構(gòu)領(lǐng)導(dǎo)處理。1.5.5 項(xiàng)目團(tuán)隊(duì)的政策項(xiàng)目團(tuán)隊(duì)的政策項(xiàng)目中的任何管理人員、開發(fā)人員、測試人員等，必須學(xué)習(xí)與本職工作相關(guān)的過程規(guī)范，每個(gè)人都必須明白自己“應(yīng)當(dāng)在什么時(shí)候依據(jù)什么規(guī)范做什么事情應(yīng)當(dāng)在什么時(shí)候依據(jù)什么規(guī)范做什么事情” 。項(xiàng)目經(jīng)理應(yīng)當(dāng)樹立榜樣，并且督促項(xiàng)目成員們按規(guī)范做事。允許項(xiàng)目經(jīng)理根據(jù)本項(xiàng)目的特征，在 SEPG 和 QAG 的指導(dǎo)下，適當(dāng)?shù)夭眉艋驍U(kuò)充機(jī)構(gòu)的過程規(guī)范，從而快速建立本項(xiàng)目的過程規(guī)范。這項(xiàng)工作應(yīng)

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

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

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

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

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

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

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

29、系數(shù)：是風(fēng)險(xiǎn)嚴(yán)重性和風(fēng)險(xiǎn)可能性的乘積。參數(shù)參數(shù)等級等級值值描述描述很高5例如進(jìn)度延誤大于 30%，或者費(fèi)用超支大于 30%。比較高4例如進(jìn)度延誤 20%30%，或者費(fèi)用超支 20%30%。中等3例如進(jìn)度延誤低于 20%，或者費(fèi)用超支低于 20%。比較低2例如進(jìn)度延誤低于 10%，或者費(fèi)用超支低于 10%。風(fēng)險(xiǎn)嚴(yán)重性很低1例如進(jìn)度延誤低于 5%，或者費(fèi)用超支低于 5%。表 5-1 風(fēng)險(xiǎn)嚴(yán)重性等級參數(shù)參數(shù)等級等級值值描述描述很高5風(fēng)險(xiǎn)發(fā)生的幾率為 1.0 0.8比較高4風(fēng)險(xiǎn)發(fā)生的幾率為 0.8 0.6中等3風(fēng)險(xiǎn)發(fā)生的幾率為 0.6 0.4比較低2風(fēng)險(xiǎn)發(fā)生的幾率為 0.4 0.2風(fēng)險(xiǎn)可能性很低1風(fēng)險(xiǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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