軟件研發(fā)管理制度_第1頁
軟件研發(fā)管理制度_第2頁
軟件研發(fā)管理制度_第3頁
軟件研發(fā)管理制度_第4頁
軟件研發(fā)管理制度_第5頁
已閱讀5頁,還剩38頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

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 精簡模型精簡模型 文檔結(jié)構(gòu)與規(guī)范細分文檔結(jié)構(gòu)與規(guī)范細分 .51.4 精簡模型精簡模型 角色與職責表角色與職責表 .61.5 公司軟件過程的政策公司軟件過程的政策 .81

2、.5.1 目標.81.5.2 機構(gòu)領(lǐng)導的支持.81.5.3 質(zhì)量管理的政策.81.5.4 質(zhì)量保證小組的政策.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 結(jié)項管理結(jié)項管理 .228 需求開發(fā)需求開發(fā) .239 技術(shù)預研技術(shù)預研 .2410 系統(tǒng)設(shè)計系統(tǒng)設(shè)計 .25310.1 體系結(jié)構(gòu)設(shè)計體系結(jié)構(gòu)設(shè)計 .2610.2 用戶界面設(shè)計用戶界面設(shè)計 .2610.3 數(shù)據(jù)庫設(shè)計數(shù)據(jù)庫設(shè)計 .2710.4 模塊設(shè)計模塊設(shè)計 .2811 實現(xiàn)與測試實現(xiàn)與測試 .2812 系統(tǒng)測試系統(tǒng)測試 .3013 客戶驗收客戶驗收 .3114 技術(shù)評審技術(shù)評審 .3215 配置管理配置管理 .3316 質(zhì)量保證質(zhì)量保證 .3517 培訓管理培訓管理 .3718 服務與維護服務與維護 .3841 軟件研發(fā)制度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29、系數(shù):是風險嚴重性和風險可能性的乘積。參數(shù)參數(shù)等級等級值值描述描述很高5例如進度延誤大于 30%,或者費用超支大于 30%。比較高4例如進度延誤 20%30%,或者費用超支 20%30%。中等3例如進度延誤低于 20%,或者費用超支低于 20%。比較低2例如進度延誤低于 10%,或者費用超支低于 10%。風險嚴重性很低1例如進度延誤低于 5%,或者費用超支低于 5%。表 5-1 風險嚴重性等級參數(shù)參數(shù)等級等級值值描述描述很高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 風險可能性等級風險可能性風險可能性風險風險系數(shù)系數(shù)很高 5比較高 4中等 3比較低 2很低 1很高 5252015105比較高 420161284中等 31512963比較低 2108642風險風險嚴重性嚴重性很低 154321本表灰色部分的風險系數(shù)值為本表灰色部分的風險系數(shù)值為 1025,應當優(yōu)先處理。,應當優(yōu)先處理。表 5-3 風險系數(shù)等級15風險嚴重性的等級劃分如表 5-1 所示,風險可能性的等級劃分如表 5-2 所示,風險系數(shù)的等級劃分如表 3 所示。風險管理有 4 個主要活動:風險識別:根據(jù)風險檢查表,識別出本項目的風險。風險分析:估計風險嚴重

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論