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

1、. z.軟件研發(fā)管理制度文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標(biāo)識：Lolaage-Software-PM當(dāng)前版本：作 者：宋孝光完成日期：2012/3/27版本/狀態(tài)作者參與者修改日期備注宋孝光2012/3/26第一版草稿宋孝光2012/3/27整理目錄目錄TOC o 1-3 h z uHYPERLINK l _Toc3206503521 軟件研發(fā)制度綜述 PAGEREF _Toc320650352 h 3HYPERLINK l _Toc3206503531.1 精簡模型 PAGEREF _Toc320650353 h 3HYPERLINK l _Toc3206503541.2 精簡過程域

2、的目的 PAGEREF _Toc320650354 h 4HYPERLINK l _Toc3206503551.3 精簡模型文檔構(gòu)造與規(guī)細(xì)分 PAGEREF _Toc320650355 h 5HYPERLINK l _Toc3206503561.4 精簡模型角色與職責(zé)表 PAGEREF _Toc320650356 h 6HYPERLINK l _Toc3206503571.5 公司軟件過程的政策 PAGEREF _Toc320650357 h 8HYPERLINK l _Toc3206503581.5.1 目標(biāo) PAGEREF _Toc320650358 h 8HYPERLINK l _Toc

3、3206503591.5.2 機構(gòu)領(lǐng)導(dǎo)的支持 PAGEREF _Toc320650359 h 8HYPERLINK l _Toc3206503601.5.3 質(zhì)量管理的政策 PAGEREF _Toc320650360 h 8HYPERLINK l _Toc3206503611.5.4 質(zhì)量保證小組的政策 PAGEREF _Toc320650361 h 9HYPERLINK l _Toc3206503621.5.5 工程團(tuán)隊的政策 PAGEREF _Toc320650362 h 9HYPERLINK l _Toc3206503632 立項管理 PAGEREF _Toc320650363 h 9H

4、YPERLINK l _Toc3206503643 工程規(guī)劃 PAGEREF _Toc320650364 h 9HYPERLINK l _Toc3206503654 工程監(jiān)控 PAGEREF _Toc320650365 h 10HYPERLINK l _Toc3206503664.1工程方案跟蹤 PAGEREF _Toc320650366 h 11HYPERLINK l _Toc3206503674.1.1 任務(wù)跟蹤 PAGEREF _Toc320650367 h 11HYPERLINK l _Toc320650368費用跟蹤 PAGEREF _Toc320650368 h 11HYPERLI

5、NK l _Toc320650369資源跟蹤 PAGEREF _Toc320650369 h 11HYPERLINK l _Toc320650370工作成果及其規(guī)模跟蹤 PAGEREF _Toc320650370 h 12HYPERLINK l _Toc3206503714.2 控制偏差 PAGEREF _Toc320650371 h 12HYPERLINK l _Toc3206503724.3 工程進(jìn)展匯報 PAGEREF _Toc320650372 h 13HYPERLINK l _Toc3206503735 風(fēng)險管理 PAGEREF _Toc320650373 h 14HYPERLINK

6、 l _Toc3206503746需求管理 PAGEREF _Toc320650374 h 18HYPERLINK l _Toc3206503756.1 需求確認(rèn) PAGEREF _Toc320650375 h 18HYPERLINK l _Toc3206503766.2 需求跟蹤 PAGEREF _Toc320650376 h 20HYPERLINK l _Toc3206503776.3 需求變更控制 PAGEREF _Toc320650377 h 20HYPERLINK l _Toc3206503787 結(jié)項管理 PAGEREF _Toc320650378 h 22HYPERLINK l

7、_Toc3206503798需求開發(fā) PAGEREF _Toc320650379 h 23HYPERLINK l _Toc3206503809 技術(shù)預(yù)研 PAGEREF _Toc320650380 h 24HYPERLINK l _Toc32065038110 系統(tǒng)設(shè)計 PAGEREF _Toc320650381 h 25HYPERLINK l _Toc32065038210.1體系構(gòu)造設(shè)計 PAGEREF _Toc320650382 h 26HYPERLINK l _Toc32065038310.2用戶界面設(shè)計 PAGEREF _Toc320650383 h 26HYPERLINK l _T

8、oc32065038410.3數(shù)據(jù)庫設(shè)計 PAGEREF _Toc320650384 h 27HYPERLINK l _Toc32065038510.4 模塊設(shè)計 PAGEREF _Toc320650385 h 28HYPERLINK l _Toc32065038611 實現(xiàn)與測試 PAGEREF _Toc320650386 h 28HYPERLINK l _Toc32065038712 系統(tǒng)測試 PAGEREF _Toc320650387 h 30HYPERLINK l _Toc32065038813 客戶驗收 PAGEREF _Toc320650388 h 31HYPERLINK l _T

9、oc32065038914 技術(shù)評審 PAGEREF _Toc320650389 h 32HYPERLINK l _Toc32065039015 配置管理 PAGEREF _Toc320650390 h 33HYPERLINK l _Toc32065039116 質(zhì)量保證 PAGEREF _Toc320650391 h 35HYPERLINK l _Toc32065039217 培訓(xùn)管理 PAGEREF _Toc320650392 h 37HYPERLINK l _Toc32065039318 效勞與維護(hù) PAGEREF _Toc320650393 h 381 軟件研發(fā)制度綜述1.1精簡模型精

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

11、理質(zhì)量保證培訓(xùn)管理效勞與維護(hù)精簡模型如圖1-1所示。精簡模型的主要特征和優(yōu)點有：一、直觀的過程模型精簡模型將工程管理、工程研發(fā)、機構(gòu)支撐所包含的工作劃分為相對獨立的三類過程，各個過程域之間的關(guān)系直觀明了。這樣，機構(gòu)領(lǐng)導(dǎo)、工程經(jīng)理、開發(fā)人員、測試人員、質(zhì)量保證人員等人根據(jù)精簡模型，很容易知道自己應(yīng)該在什么時候、按照什么規(guī)做什么事情。所以精簡模型有助于使機構(gòu)的各個職能單位有條不紊地開展工作。二、容易裁剪與擴大精簡模型的三類過程貫穿了產(chǎn)品的整個生命周期，17個最常見的過程域都合理地安排在產(chǎn)品生命周期中的*些階段。用戶可以根據(jù)自己產(chǎn)品的特征，適當(dāng)?shù)夭眉艋驍U大精簡的過程域，很容易制定出最適合于本產(chǎn)品的過

12、程模型。. z.客戶驗收根據(jù)產(chǎn)品特征確定最適宜的開發(fā)模型，以線性順序為主，以并行、迭代為輔。并行、迭代配置管理 質(zhì)量保證 培訓(xùn)管理其它： 人力資源管理 財務(wù)管理 行政管理 市場營銷 技術(shù)預(yù)研效勞與維護(hù)系統(tǒng)測試技術(shù)評審實現(xiàn)與測試需求開發(fā)系統(tǒng)設(shè)計結(jié)項管理工程監(jiān)控 風(fēng)險管理 需求管理產(chǎn)品維護(hù)客戶驗收產(chǎn)品測試產(chǎn)品開發(fā)工程規(guī)劃立項管理產(chǎn)品定義產(chǎn)品概念機構(gòu)支撐過程工程研發(fā)過程工程管理過程客戶驗收根據(jù)產(chǎn)品特征確定最適宜的開發(fā)模型，以線性順序為主，以并行、迭代為輔。并行、迭代配置管理 質(zhì)量保證 培訓(xùn)管理其它： 人力資源管理 財務(wù)管理 行政管理 市場營銷 技術(shù)預(yù)研效勞與維護(hù)系統(tǒng)測試技術(shù)評審實現(xiàn)與測試需求開發(fā)系統(tǒng)

13、設(shè)計結(jié)項管理工程監(jiān)控 風(fēng)險管理 需求管理產(chǎn)品維護(hù)客戶驗收產(chǎn)品測試產(chǎn)品開發(fā)工程規(guī)劃立項管理產(chǎn)品定義產(chǎn)品概念機構(gòu)支撐過程工程研發(fā)過程工程管理過程圖1-1 精簡模型-. z.1.2 精簡過程域的目的精簡模型 所有17個過程域的目的如表1-1所示。工程管理過程域目的立項管理采納符合機構(gòu)最大利益的立項建議，通過立項管理使該建議成為正式的工程。杜絕不符合機構(gòu)最大利益的立項建議被采納，防止浪費機構(gòu)的資源、資金、時間等。結(jié)項管理在工程開發(fā)工作完畢后，對工程的有形資產(chǎn)和無形資產(chǎn)進(jìn)展清算、對工程進(jìn)展綜合評估以及總結(jié)經(jīng)歷教訓(xùn)等。工程規(guī)劃為工程的研發(fā)和管理工作制定合理的行動綱領(lǐng)即工程方案，以便所有相關(guān)人員按照該方案有

14、條不紊地開展工作。工程監(jiān)控周期性地跟蹤工程方案的各種參數(shù)如進(jìn)度、工作量、費用、資源等，不斷地了解工程的進(jìn)展情況，以便當(dāng)工程實際進(jìn)展顯著偏離方案時能夠及時采取糾正措施。風(fēng)險管理在風(fēng)險產(chǎn)生危害之前識別它們，從而有方案地消除或削弱風(fēng)險。需求管理在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。工程研發(fā)過程域目的需求開發(fā)通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。技術(shù)預(yù)研在立項之后到開發(fā)工作完成之前的時間，對工程將采用的關(guān)鍵技術(shù)提前學(xué)習(xí)和研究，盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙。系統(tǒng)設(shè)計設(shè)計軟件系統(tǒng)的體系構(gòu)造、用戶界面、數(shù)據(jù)庫、模塊等，從而在需求與

15、代碼之間建立橋梁，指導(dǎo)開發(fā)人員去實現(xiàn)能滿足用戶需求的軟件產(chǎn)品。實現(xiàn)與測試依據(jù)系統(tǒng)設(shè)計文檔，編寫并測試整個系統(tǒng)的代碼。在精簡模型中，實現(xiàn)與測試是編程、代碼審查、單元測試、集成測試、缺陷管理與改錯的綜合表述。系統(tǒng)測試對最終系統(tǒng)進(jìn)展全面的測試，確保最終系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計?？蛻趄炇湛蛻粢罁?jù)合同對產(chǎn)品進(jìn)展審查和測試，確保產(chǎn)品滿足客戶需求。技術(shù)評審盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而有效地提高產(chǎn)品的質(zhì)量。機構(gòu)支撐過程域目的配置管理通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護(hù)。質(zhì)量保證提供一

16、種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控過程質(zhì)量與產(chǎn)品質(zhì)量，從而實現(xiàn)持續(xù)地改良質(zhì)量。培訓(xùn)管理根據(jù)機構(gòu)或工程的需求來制定培訓(xùn)方案，并監(jiān)視該方案的實施，確保培訓(xùn)取得預(yù)期效果。效勞與維護(hù)是指產(chǎn)品銷售之后的客戶效勞和產(chǎn)品維護(hù)，其宗旨是提高客戶對產(chǎn)品以及對開發(fā)方的滿意度。表1-1 精簡過程域的目的1.3精簡模型 文檔構(gòu)造與規(guī)細(xì)分精簡模型的文檔構(gòu)造如圖1-2所示，SPP包含17個過程域，規(guī)細(xì)分如表1-2所示。過程域過程改良政策文檔模板規(guī)程過程域過程改良政策文檔模板規(guī)程圖 1-2 精簡模型 文檔構(gòu)造工程管理過程域主要規(guī)程文檔模板立項管理立項建議立項評審工程籌備立項建議書立項調(diào)查報告書立項可行性分

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

18、與測試實現(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)評估報告效勞與維護(hù)客戶效勞客戶效勞方案客戶效勞報告產(chǎn)品維護(hù)產(chǎn)品維護(hù)方案產(chǎn)品維護(hù)報告表1-2精簡模型 規(guī)細(xì)分1.4 精簡模型 角色與

19、職責(zé)表精簡模型的主要角色及其職責(zé)如表1-3所示詳見各個過程域?qū)巧c職責(zé)的描述。公司在應(yīng)用精簡模型時，可以將精簡模型的各個角色映射到公司原有的崗位上，也可以依據(jù)精簡模型角色建立新的崗位。一個人可以被賦予多個角色，視具體情況而定。常設(shè)角色職責(zé)簡述機構(gòu)過程改良角色軟件工程過程組SEPG1制定適合于本機構(gòu)的過程規(guī)。2在機構(gòu)圍推廣該規(guī)如培訓(xùn)、考核，評估機構(gòu)過程能力等。質(zhì)量保證小組QAG1監(jiān)視規(guī)的實施，確保所有工程以及相關(guān)部門準(zhǔn)照規(guī)開展工作。2分析并解決機構(gòu)存在的共性質(zhì)量問題，協(xié)組SEPG完善規(guī)。工程管理過程角色機構(gòu)領(lǐng)導(dǎo)1是機構(gòu)所有工程的主管，對立項管理和結(jié)項管理有最終決策權(quán)。2監(jiān)視工程經(jīng)理的工作，審批

20、工程經(jīng)理的各種申請。工程經(jīng)理1向機構(gòu)領(lǐng)導(dǎo)匯報工作。2是工程規(guī)劃、工程監(jiān)控、風(fēng)險管理和需求管理過程域的負(fù)責(zé)人。3監(jiān)視工程成員的工作，審批工程成員的各種申請。工程研發(fā)過程角色需求分析員調(diào)查、分析并定義需求，撰寫相應(yīng)的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。系統(tǒng)設(shè)計師根據(jù)需求文檔設(shè)計軟件系統(tǒng)的體系構(gòu)造、用戶界面、數(shù)據(jù)庫、模塊等，并撰寫相應(yīng)的設(shè)計文檔。程序員1根據(jù)系統(tǒng)設(shè)計文檔，編寫軟件系統(tǒng)的代碼。2隨時測試和檢查自己的代碼，及時消除代碼中的缺陷。測試員從事單元測試、集成測試和系統(tǒng)測試，主要工作包括制定測試方案、設(shè)計測試用例、執(zhí)行測試和撰寫測試報告。機構(gòu)支撐過程角色配置管理員1為

21、工程制定配置管理方案。2創(chuàng)立并維護(hù)配置庫，如分配權(quán)限、去除垃圾文件、備份配置庫等。質(zhì)量保證員即QAG成員1為工程制定質(zhì)量保證方案。2周期性的開展過程與產(chǎn)品質(zhì)量檢查。3跟蹤質(zhì)量問題，給出質(zhì)量改良措施。培訓(xùn)管理員制定機構(gòu)或工程的培訓(xùn)方案，監(jiān)視該方案的實施，撰寫培訓(xùn)評估報告?？蛻粜谌藛T為客戶提供與產(chǎn)品相關(guān)的效勞如技術(shù)咨詢，快速響應(yīng)客戶的要求，給客戶一個滿意的解答。產(chǎn)品維護(hù)人員1糾錯性維護(hù)：及時解決用戶遇到的技術(shù)故障和消除產(chǎn)品中的缺陷。2完善性維護(hù)：在資源允許的情況下，不斷改善產(chǎn)品功能與質(zhì)量。臨時角色職責(zé)說明立項建議小組1開展立項調(diào)查、產(chǎn)品構(gòu)思和可行性分析，撰寫相應(yīng)文檔。2申請立項，并在立項評審會議

22、上辯論。立項評審委員會由機構(gòu)領(lǐng)導(dǎo)、各級經(jīng)理、市場人員、技術(shù)專家、財務(wù)人員等組成，委員會按少數(shù)服從多數(shù)原則投票決定是否同意立項。結(jié)項評審委員會對工程的有形資產(chǎn)和無形資產(chǎn)進(jìn)展清算，對工程進(jìn)展綜合評估，總結(jié)經(jīng)歷教訓(xùn)等。結(jié)項委員會的人員組成與立項評審委員會的類似。技術(shù)評審委員會對工作成果進(jìn)展正式技術(shù)評審，盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷。該委員會由工程外的技術(shù)專家組成。配置控制委員會對配置管理各項活動擁有決策權(quán)例如審批方案，審批變更請求等。表1-3精簡模型的角色與職責(zé)簡表1.5 公司軟件過程的政策1.5.1 目標(biāo)持續(xù)改良機構(gòu)的軟件過程能力，不斷地提高產(chǎn)品質(zhì)量、提高生產(chǎn)率并且降低開

23、發(fā)本錢。1.5.2 機構(gòu)領(lǐng)導(dǎo)的支持機構(gòu)領(lǐng)導(dǎo)批準(zhǔn)用于軟件過程改良的必要經(jīng)費，例如支付咨詢費，購置相關(guān)軟件工具等。機構(gòu)領(lǐng)導(dǎo)組建SEPG和QAG，專門從事軟件過程改良工作。SEPG的主要職責(zé)是建立適合于機構(gòu)的過程規(guī)，QAG的主要職責(zé)是監(jiān)視該規(guī)的實施。建議讓SEPG和QAG的大局部人員重疊，這些人既是SEPG成員又是質(zhì)量保證員，扮演兩種角色。這樣不僅節(jié)約人力資源，并且提高了工作效果由制定規(guī)的人去監(jiān)視規(guī)的實施最適宜不過。一般地，SEPG成員和質(zhì)量保證員共占機構(gòu)總?cè)藬?shù)的5%左右。機構(gòu)領(lǐng)導(dǎo)不僅要口頭支持，還要親自參與軟件過程改良的實踐。例如參加培訓(xùn)和考試，準(zhǔn)照過程規(guī)執(zhí)行立項管理和結(jié)項管理等。1.5.3 質(zhì)量

24、管理的政策質(zhì)量管理口號：在開發(fā)過程之中建質(zhì)量而非修補質(zhì)量。質(zhì)量管理有種根本措施：質(zhì)量保證、技術(shù)評審和測試。質(zhì)量保證機構(gòu)的質(zhì)量保證員周期性地檢查工程成員的工作過程以及工作成果是否符合既定的規(guī)，來監(jiān)控和改良過程質(zhì)量以及產(chǎn)品質(zhì)量。機構(gòu)的質(zhì)量保證員獨立于任何工程，并賦予他一定的權(quán)利，對質(zhì)量不合格的工作成果作出處理。二、技術(shù)評審在工作成果剛產(chǎn)生之際，對其進(jìn)展技術(shù)評審分正式或非正式兩種，目的是盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而提高產(chǎn)品的質(zhì)量。如果時間允許的話，應(yīng)當(dāng)盡可能多地對產(chǎn)品的重要工作成果進(jìn)展技術(shù)評審。技術(shù)評審活動由工程開發(fā)團(tuán)隊組織。三、測試測試是指通過運行測試用例test

25、case來找出軟件中的缺陷。測試與技術(shù)評審的主要區(qū)別是前者要運行軟件而后者不必運行軟件。一般地，產(chǎn)品開發(fā)過程中有四個測試階段：單元測試、集成測試、系統(tǒng)測試和驗收測試。其中單元測試和集成測試可以由工程開發(fā)團(tuán)隊組織。系統(tǒng)測試階段必須有工程外的人員參與，以保證系統(tǒng)測試的客觀性。驗收測試由客戶組織。如果有條件的話，建議機構(gòu)成立專門的測試小組從事單元測試、集成測試和系統(tǒng)測試工作。1.5.4 質(zhì)量保證小組的政策機構(gòu)領(lǐng)導(dǎo)任命一位熟悉過程規(guī)并且有豐富的質(zhì)量管理經(jīng)歷的人擔(dān)任QAG的負(fù)責(zé)人或稱為質(zhì)量經(jīng)理。在機構(gòu)領(lǐng)導(dǎo)的許可下，該負(fù)責(zé)人組建QAG成員可以是全職的也可以是兼職的。QAG在行政上獨立于任何工程。這種獨立性

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

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

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

29、控Project Monitoring and Control, PMC的目的是通過周期性地跟蹤工程方案的各種參數(shù)如進(jìn)度、工作量、費用、資源、工作成果等，不斷地了解工程的進(jìn)展情況，以便當(dāng)工程實際進(jìn)展?fàn)顩r顯著偏離方案時能夠及時采取糾正措施。本規(guī)闡述了工程監(jiān)控過程域的三個主要規(guī)程：工程方案跟蹤控制偏差 工程進(jìn)展匯報 周期性地開展工程方案跟蹤工程進(jìn)展總結(jié)偏差控制周期性地開展工程方案跟蹤工程進(jìn)展總結(jié)偏差控制圖4-1 工程監(jiān)控流程4.1工程方案跟蹤周期性的跟蹤任務(wù)含進(jìn)度和工作量、費用、資源、工作成果等，及時了解工程的實際進(jìn)展情況。為持續(xù)過程改良提供有價值的數(shù)據(jù)。4.1.1 任務(wù)跟蹤工程經(jīng)理或其指定的工程

30、成員周期性地如每周一次跟蹤每個重要的任務(wù)，將采集的數(shù)據(jù)保存在工程監(jiān)控數(shù)據(jù)表之中。任務(wù)跟蹤表的參考格式如表4-1所示。任務(wù)名稱實際起止時間跟蹤日期、當(dāng)前進(jìn)度實際工作量實際工作成果表4-1 任務(wù)跟蹤表4.1.2費用跟蹤工程經(jīng)理或其指定的工程成員周期性地跟蹤工程費用，將采集的數(shù)據(jù)保存在工程監(jiān)控數(shù)據(jù)表之中。費用跟蹤表的參考格式如表4-2所示。費用類別主要開支項、用途金額時間表4-2 費用跟蹤表4.1.3資源跟蹤工程經(jīng)理或其指定的工程成員周期性地跟蹤軟硬件資源，將采集的數(shù)據(jù)保存在工程監(jiān)控數(shù)據(jù)表之中。資源跟蹤表的參考格式如表4-3所示。軟硬件資源名稱級別實際配置獲取方式與時間使用說明關(guān)鍵關(guān)鍵普通普通表4-

31、3 資源跟蹤表4.1.4工作成果及其規(guī)模跟蹤工程經(jīng)理或其指定的工程成員周期性地跟蹤工作成果及其規(guī)模，將采集的數(shù)據(jù)保存在工程監(jiān)控數(shù)據(jù)表之中。工作成果跟蹤表的參考格式如表4-4所示。工作成果名稱新開發(fā)的成果規(guī)模代碼行、類、文檔頁數(shù)復(fù)用或自動生成的成果規(guī)模代碼行、類、文檔頁數(shù)工作成果1工作成果2總和表4-4 工作成果及其規(guī)模跟蹤表4.2 控制偏差比照工程實際進(jìn)展和工程方案，分析偏差，如果發(fā)現(xiàn)工程實際進(jìn)展顯著偏離方案，則及時采取糾正措施。記錄日期顯著偏差描述原因分析糾正措施結(jié)果表4-5工程偏差控制報告4.3 工程進(jìn)展匯報周期性地匯報工程進(jìn)展情況。工程經(jīng)理周期性地總結(jié)工程進(jìn)展情況，撰寫工程進(jìn)展報告并通報

32、給機構(gòu)領(lǐng)導(dǎo)和所有工程成員。根本信息工程名稱報告日期工程編號報告批次第N份工程經(jīng)理工程所處階段工程進(jìn)展?fàn)顩r方案實際情況任務(wù)與進(jìn)度工作成果費用人力資源軟硬件資源問題與對策表4-6工程進(jìn)展報告5 風(fēng)險管理風(fēng)險管理Risk Management, RiskM的目的是在風(fēng)險產(chǎn)生危害之前識別它們，從而有方案地消除或削弱風(fēng)險。所有可能危害工程的因素都稱為風(fēng)險。被刻畫為風(fēng)險的事件最終可能發(fā)生也可能不發(fā)生。人們對待風(fēng)險有兩種態(tài)度。一種是被動態(tài)度，可比作救火模式。另一種是主動態(tài)度，可比作防火模式。風(fēng)險管理屬于防火模式，目的就是防止風(fēng)險產(chǎn)生真正的危害。為了便于量化管理，我們給風(fēng)險定義3個參數(shù)：風(fēng)險嚴(yán)重性：指風(fēng)險對工

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

34、幾率為0.2 0.0表5-2 風(fēng)險可能性等級風(fēng)險系數(shù)風(fēng)險可能性很高 5比擬高 4中等 3比擬低 2很低 1風(fēng)險嚴(yán)重性很高 5252015105比擬高 420161284中等 31512963比擬低 2108642很低 154321本表灰色局部的風(fēng)險系數(shù)值為1025，應(yīng)當(dāng)優(yōu)先處理。表5-3 風(fēng)險系數(shù)等級風(fēng)險嚴(yán)重性的等級劃分如表5-1所示，風(fēng)險可能性的等級劃分如表5-2所示，風(fēng)險系數(shù)的等級劃分如表3所示。風(fēng)險管理有4個主要活動：風(fēng)險識別：根據(jù)風(fēng)險檢查表，識別出本工程的風(fēng)險。風(fēng)險分析：估計風(fēng)險嚴(yán)重性、風(fēng)險可能性、風(fēng)險系數(shù)。風(fēng)險減緩：對于風(fēng)險系數(shù)超過容許值的每一個風(fēng)險，都應(yīng)當(dāng)采取減緩措施。風(fēng)險跟蹤：跟

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

36、否在開發(fā)很少有人真正需要卻自以為很好的產(chǎn)品？是否在開發(fā)可能賠本的產(chǎn)品？客戶客戶的需否模糊不清？客戶是否反反復(fù)復(fù)地改動需求？客戶指定的需求和交付期限在客觀上可行嗎？客戶對產(chǎn)品的強健性、可靠性、性能等質(zhì)量因素有非常過分的要求嗎？客戶的合作態(tài)度友善嗎？與客戶簽的合同公正嗎？雙方互利嗎？客戶的信譽好嗎？例如按客戶的需求開發(fā)了產(chǎn)品，但是客戶可能不購置。子承包商供給商與子承包商、供給商簽訂的合同公正嗎？雙方互利嗎？子承包商、供給商的信譽好嗎？子承包商、供給商有可能倒閉嗎？子承包商、供給商能及時交付質(zhì)量合格的產(chǎn)品或部件嗎？子承包商、供給商有能力做好售后效勞嗎？管理風(fēng)險風(fēng)險類型檢查項工程方案對工程的規(guī)模、難度

37、估計是否比擬正確？人力資源開發(fā)人員、管理人員夠用嗎？合格嗎？工程所需的軟件、硬件能按時到位嗎？工程的經(jīng)費夠用嗎？進(jìn)度安排是否過于緊？有合理的緩沖時間嗎？進(jìn)度表中是否遺忘了一些重要的必要的任務(wù)？進(jìn)度安排是否考慮了關(guān)鍵路徑？ 是否可能出現(xiàn)*一項工作延誤導(dǎo)致其他一連串的工作也被延誤？任務(wù)分配是否合理？即把任務(wù)分配給適宜的工程成員，充分發(fā)揮其才能是否為了節(jié)省錢，不采用購置成熟的軟件模塊，一切從零做起？工程團(tuán)隊工程成員團(tuán)結(jié)嗎？是否存在矛盾？是否絕大局部的工程成員對工作認(rèn)真負(fù)責(zé)？絕大局部的工程成員有工作熱情嗎？團(tuán)隊之中有害群之馬嗎？技術(shù)開發(fā)隊伍中有臨時工嗎？本工程開發(fā)過程中是否會有核心人員辭職、調(diào)動？是否

38、能保證人員流動根本不會影響工作的連續(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ēng)險風(fēng)險類型檢查項需求開發(fā)需求管理需求開發(fā)人員懂得如何獲取用戶需求嗎？效率高嗎？需求開發(fā)人員懂得

39、工程所涉及的具體業(yè)務(wù)嗎？能否理解用戶的需求？需求文檔能夠正確地、完備地表達(dá)用戶需求嗎？需求開發(fā)人員能否與客戶對有爭議的需求達(dá)成共識？需求開發(fā)人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？綜合技術(shù)開發(fā)能力包括設(shè)計編程、測試等開發(fā)人員是否有開發(fā)相似產(chǎn)品的經(jīng)歷？待開發(fā)的產(chǎn)品是否要與未曾證實的軟硬件相連接？對開發(fā)人員而言，本工程的技術(shù)難度高嗎？開發(fā)人員是否已經(jīng)掌握了本工程的關(guān)鍵技術(shù)？如果*項技術(shù)尚未實踐過，開發(fā)人員能否在預(yù)定時間掌握？開發(fā)小組是否采用比擬有效的分析、設(shè)計、編程、測試工具？分析與設(shè)計工作是否過于簡單、草率，從而讓程序員邊做邊改？開發(fā)小組采用統(tǒng)一的編程規(guī)嗎？開發(fā)人員對測試工作

40、重視嗎？能保證測試的客觀性嗎？工程有獨立的測試人員嗎？懂得如何進(jìn)展高效率地測試嗎？是否對所有重要的工作成果進(jìn)展了同行評審正式評審或快速檢查？開發(fā)人員懂得版本控制、變更控制嗎？能夠按照配置管理規(guī)執(zhí)行嗎？開發(fā)人員重視質(zhì)量嗎？是否會在進(jìn)度延誤時降低質(zhì)量要求？表5-4 風(fēng)險檢查表風(fēng)險名稱風(fēng)險識別人風(fēng)險編號風(fēng)險識別日期風(fēng)險描述風(fēng)險嚴(yán)重性風(fēng)險系數(shù)風(fēng)險可能性風(fēng)險處理人風(fēng)險減緩措施跟蹤記錄1記錄何人在何時做了什么事情2記錄當(dāng)前風(fēng)險狀態(tài)正在處理，已經(jīng)解決，不作處理表5-5 風(fēng)險管理報告6需求管理需求管理Requirement Management, RM的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其

41、他工作成果的一致性，并控制需求的變更。需求管理過程域的三個主要規(guī)程：需求確認(rèn) 需求跟蹤 需求變更控制 需求確認(rèn)需求管理需求分析需求定義需求調(diào)查需求開發(fā)需求工程需求變更控制需求跟蹤需求確認(rèn)需求管理需求分析需求定義需求調(diào)查需求開發(fā)需求工程需求變更控制需求跟蹤圖6-1 需求工程構(gòu)造圖6.1 需求確認(rèn)工程經(jīng)理邀請同行專家和用戶包括客戶和最終用戶一起評審需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。當(dāng)需求文檔通過正式的評審之后，開發(fā)方負(fù)責(zé)人工程經(jīng)理和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。例如如下：本需求文檔建立在雙方對需求的共同理解根底之上，我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔

42、開展。如果需求發(fā)生變化，我們將按照需求變更控制規(guī)程執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商本錢、資源和進(jìn)度等。甲方負(fù)責(zé)人簽字乙方負(fù)責(zé)人簽字評審?fù)戤?輸出 需求評審報告，書面的需求承諾需求評審報告摘要需求文檔輸入名稱，標(biāo)識符，版本，作者，完成日期，需求評審報告輸入名稱，標(biāo)識符，評審日期，評審結(jié)論 工作成果合格，無需修改或者需要輕微修改但不必再審核。 工作成果根本合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比擬大的修改，之后必須重新對其評審。評審意見評審小組成員輸入評審小組成員表6-1 需求評審報告需求承諾需求文檔輸入名稱，標(biāo)識符，版本，作者，完成日期客戶承諾承諾簽字，日期工

43、程經(jīng)理承諾承諾簽字，日期表6-2 需求承諾6.2 需求跟蹤將系統(tǒng)設(shè)計、編程、測試等階段的工作成果與需求文檔進(jìn)展比擬，建立與維護(hù)需求文檔設(shè)計文檔代碼測試用例之間的一致性，確保產(chǎn)品依據(jù)需求文檔進(jìn)展開發(fā)。工程經(jīng)理跟蹤需求。建立與維護(hù)需求跟蹤矩陣：正向跟蹤。檢查需求文檔中的每個需否都能在后續(xù)工作成果中找到對應(yīng)點。逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。正向跟蹤和逆向跟蹤合稱為雙向跟蹤。不管采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣即表格。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單元之間的可能存在一對一、一對多或多對多的關(guān)系。由于對應(yīng)關(guān)系比擬復(fù)雜，最好

44、在表格中加必要的文字解釋。表6-3為簡單的需求跟蹤矩陣格式。當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。需求文檔版本，日期設(shè)計文檔版本，日期代碼版本，日期測試用例版本，日期1標(biāo)題或標(biāo)識符，說明標(biāo)題或標(biāo)識符，說明代碼名稱，說明測試用例名稱，說明2表6-3 簡單的需求跟蹤矩陣格式6.3 需求變更控制修改原需求文檔中不正確的容，產(chǎn)生新的需求文檔?？刂菩枨笪臋n的變更，防止發(fā)生混亂。補充說明：本規(guī)程中的原需求文檔是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。開發(fā)方負(fù)責(zé)人工程經(jīng)理和客戶共同控制需求變更。需求變更申請申請變更的需求文檔輸入名稱，版本，日期等信息變更的容及其理由評估需求變更將對工

45、程造成的影響申請人簽字變更申請的審批意見工程經(jīng)理簽字審批意見：簽字，日期客戶簽字合同工程審批意見：簽字，日期更改需求文檔變更后的需求文檔輸入名稱，版本，完成日期等信息更改人簽字重新評審需求文檔需求評審小組簽字評審意見：簽字，日期變更完畢工程經(jīng)理簽字簽字日期：表6-4 需求變更控制報告7 結(jié)項管理結(jié)項管理Project Closing Management, PCM是指在工程開發(fā)工作完畢后，對工程的有形資產(chǎn)和無形資產(chǎn)進(jìn)展清算；對工程進(jìn)展綜合評估；總結(jié)經(jīng)歷教訓(xùn)等。立項管理與結(jié)項管理是前后照應(yīng)的兩個過程域，使得工程管理過程有始有終。工程完畢有兩種狀況：一是正常完畢，二是異常完畢。前者是指工程按預(yù)定方

46、案完畢。后者原因有多種，歸根結(jié)底都是由于該工程不再符合機構(gòu)的最大利益。例如有些工程因不適應(yīng)市場而被中途淘汰，有些工程在執(zhí)行過程大因偏離方案如進(jìn)度延誤、費用超支而被取消。不管工程屬于正常完畢還是異常完畢，都要按照結(jié)項管理規(guī)處理。國很多工程普遍存在虎頭蛇尾的現(xiàn)象，結(jié)項管理畸變成了走過場，吃頓飯，這是非常有害的。有價值的結(jié)項管理至少包括三項容：對工程的有形資產(chǎn)和無形資產(chǎn)進(jìn)展清算，既要防止資產(chǎn)流失，又要及時地利用這些資產(chǎn)。對工程進(jìn)展綜合評估。例如評估工程完成情況、工程質(zhì)量、投入產(chǎn)出分析、工程的市場價值、工程對企業(yè)的奉獻(xiàn)等等。該評估報告可以作為考核工程人員業(yè)績的重要依據(jù)?？偨Y(jié)經(jīng)歷教訓(xùn)，使整個機構(gòu)受益。經(jīng)

47、歷總結(jié)綜合評估結(jié)項評審結(jié)項申請機構(gòu)領(lǐng)導(dǎo)審批機構(gòu)領(lǐng)導(dǎo)指示資產(chǎn)檢查經(jīng)歷總結(jié)綜合評估結(jié)項評審結(jié)項申請機構(gòu)領(lǐng)導(dǎo)審批機構(gòu)領(lǐng)導(dǎo)指示資產(chǎn)檢查圖7-1結(jié)項管理流程圖結(jié)項管理的流程如圖7-1所示，產(chǎn)生的主要文檔有：8需求開發(fā)需求開發(fā)Requirement Development, RD的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。本規(guī)闡述了需求開發(fā)過程域的兩個主要規(guī)程：需求調(diào)查需求定義需求開發(fā)與需求管理是相輔相成的兩類活動，它們共同構(gòu)成完整的需求工程。需求工程構(gòu)造圖如圖6-1所示，需求開發(fā)和需求管理的流程如圖8-1所示。需求分析需求變更控制需求跟蹤需求確認(rèn)需求管理過程域輸出輸出用戶需求說明書產(chǎn)品需求定義用

48、戶需求調(diào)查產(chǎn)品需求規(guī)格說明書需求開發(fā)過程域需求分析需求變更控制需求跟蹤需求確認(rèn)需求管理過程域輸出輸出用戶需求說明書產(chǎn)品需求定義用戶需求調(diào)查產(chǎn)品需求規(guī)格說明書需求開發(fā)過程域圖8-1 需求開發(fā)與需求管理流程圖需求開發(fā)可分為兩個階段：用戶需求調(diào)查階段和產(chǎn)品需求定義階段。而需求分析則貫穿于上述兩個階段。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進(jìn)展的。我們把從事需求開發(fā)工作的人員稱為需求分析員也叫系統(tǒng)分析員，防止與其它開發(fā)人員混淆。一、需求調(diào)查需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息原始材料，產(chǎn)生用戶需求說明書。二、需求分析需求分析的目的是對各種需求信息進(jìn)展分析，消

49、除錯誤，刻畫細(xì)節(jié)等。常用的需求分析方法有問答分析法、構(gòu)造化分析法和面向?qū)ο蠓治龇?。三、需求定義需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生產(chǎn)品需求規(guī)格說明書。系統(tǒng)設(shè)計人員將依據(jù)產(chǎn)品需求規(guī)格說明書開展系統(tǒng)設(shè)計工作。需求開發(fā)過程域產(chǎn)生的主要文檔有：9 技術(shù)預(yù)研技術(shù)預(yù)研Technical Pre-Research, TPR是指在立項之后到開發(fā)工作完成之前的時間，對工程將采用的關(guān)鍵技術(shù)提前學(xué)習(xí)和研究，以便盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙。在產(chǎn)品開發(fā)過程中，技術(shù)問題可能會層出不窮。如果一點技術(shù)障礙都沒有遇到，要么是開發(fā)人員的技術(shù)水平實在太高了，要么是工

50、程的技術(shù)含量實在太低了，這類情況比擬少見。一般說來，在設(shè)計或?qū)崿F(xiàn)階段遇到了技術(shù)障礙，才去攻克問題，其代價通常比擬高。因為其他人的工作可能會被阻塞，已經(jīng)投入的不少資源將被閑置。最糟糕的是，如果此技術(shù)障礙無法攻克，不得已要改變技術(shù)方案、重新設(shè)計系統(tǒng)，則不僅浪費了人力、財力、時間，處理不好還會使開發(fā)隊伍陷入混亂狀態(tài)。所以開展技術(shù)預(yù)研工作至少有兩大好處：幫助開發(fā)人員更好地進(jìn)展需求開發(fā)、系統(tǒng)設(shè)計和程序設(shè)計。防止開發(fā)進(jìn)程被技術(shù)障礙打斷，導(dǎo)致大量的相關(guān)工作被阻塞。技術(shù)預(yù)研的流程如圖9-1所示。開展技術(shù)預(yù)研制定方案撰寫預(yù)研報告工作成果介紹技術(shù)評審開展技術(shù)預(yù)研制定方案撰寫預(yù)研報告工作成果介紹技術(shù)評審圖9-1 技

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

52、設(shè)計數(shù)據(jù)庫設(shè)計用戶界面設(shè)計模塊設(shè)計實現(xiàn)與測試詳細(xì)設(shè)計階段圖10-1 系統(tǒng)設(shè)計過程域示意圖系統(tǒng)設(shè)計過程域產(chǎn)生的主要文檔有：體系構(gòu)造設(shè)計報告用戶界面設(shè)計報告數(shù)據(jù)庫設(shè)計報告模塊設(shè)計報告10.1體系構(gòu)造設(shè)計分析與設(shè)計軟件的體系構(gòu)造。通過系統(tǒng)分解，確定子系統(tǒng)的功能和子系統(tǒng)之間的關(guān)系，以及模塊的功能和模塊之間的關(guān)系，產(chǎn)生體系構(gòu)造設(shè)計報告。工程經(jīng)理指定假設(shè)干名開發(fā)人員從事體系構(gòu)造設(shè)計以下稱為體系構(gòu)造設(shè)計人員。體系構(gòu)造設(shè)計流程如圖10-2所示。Step3. 確定設(shè)計策略Step2. 確定約束因素Step1. 設(shè)計準(zhǔn)備Step3. 確定設(shè)計策略Step2. 確定約束因素Step1. 設(shè)計準(zhǔn)備Step4. 系統(tǒng)分

53、解設(shè)計Step6. 設(shè)計評審Step5. 撰寫文檔圖10-2 體系構(gòu)造設(shè)計流程10.2用戶界面設(shè)計設(shè)計軟件的用戶界面，產(chǎn)生用戶界面設(shè)計報告。制作用戶界面的資源如圖像、圖標(biāo)或者界面專用組件等工程經(jīng)理指定假設(shè)干名開發(fā)人員從事用戶界面設(shè)計以下稱為界面設(shè)計人員。如果可能的話，邀請用戶或美工人員協(xié)助設(shè)計用戶界面。用戶界面設(shè)計流程如圖10-3所示。迭代Step2. 界面設(shè)計Step4. 設(shè)計評審Step3. 撰寫文檔Step1. 設(shè)計準(zhǔn)備2.3細(xì)化2.2原型評估2.1原型創(chuàng)作迭代Step2. 界面設(shè)計Step4. 設(shè)計評審Step3. 撰寫文檔Step1. 設(shè)計準(zhǔn)備2.3細(xì)化2.2原型評估2.1原型創(chuàng)作圖

54、10-3 體系構(gòu)造設(shè)計流程10.3數(shù)據(jù)庫設(shè)計設(shè)計軟件的數(shù)據(jù)庫，產(chǎn)生數(shù)據(jù)庫設(shè)計報告。工程經(jīng)理指定假設(shè)干名開發(fā)人員從事數(shù)據(jù)庫設(shè)計以下稱為數(shù)據(jù)庫設(shè)計人員。數(shù)據(jù)庫設(shè)計流程如圖10-4所示。迭代Step2. 數(shù)據(jù)庫設(shè)計Step3. 撰寫文檔2.4優(yōu)化2.3平安性設(shè)計2.2物理設(shè)計2.1邏輯設(shè)計Step1. 設(shè)計準(zhǔn)備Step4. 設(shè)計評審迭代Step2. 數(shù)據(jù)庫設(shè)計Step3. 撰寫文檔2.4優(yōu)化2.3平安性設(shè)計2.2物理設(shè)計2.1邏輯設(shè)計Step1. 設(shè)計準(zhǔn)備Step4. 設(shè)計評審圖10-4 數(shù)據(jù)庫設(shè)計流程10.4 模塊設(shè)計設(shè)計軟件所有模塊的主要接口與屬性、數(shù)據(jù)構(gòu)造和算法，產(chǎn)生模塊設(shè)計報告。工程經(jīng)理指定

55、假設(shè)干名開發(fā)人員從事模塊的設(shè)計以下稱為模塊設(shè)計人員，模塊設(shè)計人員將在實現(xiàn)階段編寫這些模塊的代碼。模塊設(shè)計流程如圖10-5所示。Step2. 模塊設(shè)計2.1接口與屬性設(shè)計Step4. 設(shè)計評審Step3. 撰寫文檔Step1. 設(shè)計準(zhǔn)備迭代2.2數(shù)據(jù)構(gòu)造Step2. 模塊設(shè)計2.1接口與屬性設(shè)計Step4. 設(shè)計評審Step3. 撰寫文檔Step1. 設(shè)計準(zhǔn)備迭代2.2數(shù)據(jù)構(gòu)造與算法設(shè)計圖10-5 模塊設(shè)計流程11 實現(xiàn)與測試實現(xiàn)與測試Implementation and Test, IT的目的是依據(jù)系統(tǒng)設(shè)計文檔，編寫并測試整個系統(tǒng)的代碼。在本規(guī)中，實現(xiàn)與測試是編程、代碼審查、單元測試、集成測試

56、、缺陷管理與改錯的綜合表述。實現(xiàn)與測試的流程如圖11-1所示。一般地，編程、代碼審查、單元測試、集成測試大致存在先后順序關(guān)系，也可以并行、迭代地開展。上述任何活動中發(fā)現(xiàn)的缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷改錯。缺陷管理與改錯單元測試集成測試代碼審查編程模塊軟件系統(tǒng)準(zhǔn)備缺陷管理與改錯單元測試集成測試代碼審查編程模塊軟件系統(tǒng)準(zhǔn)備圖11-1 實現(xiàn)與測試流程圖由于實現(xiàn)與測試是工作量最大、時間最長、產(chǎn)生工作成果代碼與文檔最多的一個工程研發(fā)過程域，所以需要作充分的準(zhǔn)備工作。實現(xiàn)與測試工作根本上在開發(fā)小組部開展。一個工程可能有一個或者多個開發(fā)小組。對于小型工程，工程經(jīng)理可以兼任開發(fā)

57、組長。特別要注意的是，開發(fā)人員應(yīng)當(dāng)對自己的代碼進(jìn)展審查和測試這是份的工作，但是不能作為該代碼已經(jīng)通過審查和測試的依據(jù)。所以開發(fā)人員還要互相審查和測試同伴的代碼。實現(xiàn)與測試過程域產(chǎn)生的主要文檔有：實現(xiàn)與測試方案編程文檔代碼審查報告測試用例測試報告缺陷管理報告由缺陷管理工具自動生成一個工程可能有多個開發(fā)小組，視工程規(guī)模而定。開發(fā)組長由工程經(jīng)理指定。開發(fā)組長管理編程、代碼審查、單元測試、集成測試、缺陷管理與改錯等活動。12 系統(tǒng)測試系統(tǒng)測試System Test, ST的目的是對最終軟件系統(tǒng)進(jìn)展全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。系統(tǒng)測試流程如圖12-1所示。由于系統(tǒng)測試的目的

58、是驗證最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計，所以當(dāng)產(chǎn)品需求和系統(tǒng)設(shè)計文檔完成之后，系統(tǒng)測試小組就可以提前開場制定測試方案和設(shè)計測試用例，而不必等到實現(xiàn)與測試階段完畢。這樣可以提高系統(tǒng)測試的效率。系統(tǒng)測試過程中發(fā)現(xiàn)的所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷改錯。審批設(shè)計測試用例缺陷管理與改錯制定測試方案執(zhí)行系統(tǒng)測試審批迭代審批設(shè)計測試用例缺陷管理與改錯制定測試方案執(zhí)行系統(tǒng)測試審批迭代圖12-1 系統(tǒng)測試流程圖工程經(jīng)理設(shè)法組建富有成效的系統(tǒng)測試小組。系統(tǒng)測試小組的成員主要來源于：機構(gòu)獨立的測試小組如果存在的話。邀請其它工程的開發(fā)人員參與系統(tǒng)測試。本工程的局部開發(fā)人員。機

59、構(gòu)的質(zhì)量保證人員。系統(tǒng)測試小組應(yīng)當(dāng)根據(jù)工程的特征確定測試容。一般地，系統(tǒng)測試的主要容包括：功能測試。即測試軟件系統(tǒng)的功能是否正確，其依據(jù)是需求文檔，如產(chǎn)品需求規(guī)格說明書。由于正確性是軟件最重要的質(zhì)量因素，所以功能測試必不可少。強健性測試。即測試軟件系統(tǒng)在異常情況下能否正常運行的能力。強健性有兩層含義：一是容錯能力，二是恢復(fù)能力。性能測試。即測試軟件系統(tǒng)處理事務(wù)的速度，一是為了檢驗性能是否符合需求，二是為了得到*些性能數(shù)據(jù)供人們參考例如用于宣傳。用戶界面測試。重點是測試軟件系統(tǒng)的易用性和視覺效果等。平安性security測試。是指測試軟件系統(tǒng)防止非法入侵的能力。平安是相對而言的，一般地，如果黑客

60、為非法入侵花費的代價考慮時間、費用、危險等因素高于得到的好處，則這樣的系統(tǒng)可以認(rèn)為是平安的。安裝與反安裝測試。系統(tǒng)測試過程域產(chǎn)生的主要文檔有：系統(tǒng)測試方案系統(tǒng)測試用例系統(tǒng)測試報告缺陷管理報告對最終軟件系統(tǒng)進(jìn)展全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。工程經(jīng)理組建系統(tǒng)測試小組，并指定一名成員任測試組長。系統(tǒng)測試小組各成員共同制定測試方案、設(shè)計測試用例、執(zhí)行測試，并撰寫相應(yīng)的文檔。測試組長管理上述事務(wù)。開發(fā)人員及時消除測試人員發(fā)現(xiàn)的缺陷。13 客戶驗收客戶驗收Customer Acceptance, CA是指客戶依據(jù)合同對產(chǎn)品進(jìn)展審查和測試，確保產(chǎn)品滿足客戶需求?？蛻魧Ξa(chǎn)品的驗收主