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

軟件研發(fā)管理制度文件狀態(tài)：［V］草稿文件標(biāo)識：Lolaage-Software—PM當(dāng)前版本：0.1.2:］正式發(fā)布［］正在修改作 者：宋孝光完成日期：2012/3/27版本/狀態(tài)作者參與者修改日期備注0.1.1宋孝光2012/3/26第一版草稿0.1.2宋孝光2012/3/27整理目錄目錄1軟件研發(fā)制度綜述11。1精簡模型11。2精簡過程域的目的41。3精簡模型文檔結(jié)構(gòu)與規(guī)范細分51.4精簡模型角色與職責(zé)表61。5公司軟件過稈的政策81.5。 1冃標(biāo)81。5。2機構(gòu)領(lǐng)導(dǎo)的支持8153質(zhì)量管理的政策81。5.4質(zhì)量保證小組的政策91.5。 5項目團隊的政策92立項管理93項目規(guī)劃94項目監(jiān)控104.1項目計劃跟蹤104。1.1任務(wù)跟蹤104.1。2費用跟蹤114.1.3資源跟蹤114。1。4工作成果及其規(guī)模跟蹤114.2控制偏差125風(fēng)險管理126需求管理166?1需求確認176.2需求跟蹤186。3需求變更控制187結(jié)項管理198需求開發(fā)209技術(shù)預(yù)研2110系統(tǒng)設(shè)計2210?1體系結(jié)構(gòu)設(shè)計2310。2用戶界面設(shè)計2310。3數(shù)據(jù)庫設(shè)計2410?4模塊設(shè)計2411實現(xiàn)與測試2512系統(tǒng)測試2613客戶驗收2714技術(shù)評審2815配置管理2916質(zhì)量保證3117培訓(xùn)管理3318服務(wù)與維護33軟件研發(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ēng)險管理?需求管理項目研發(fā)過程包含7個過程域，分別為:需求開發(fā)技術(shù)預(yù)研?系統(tǒng)設(shè)計實現(xiàn)與測試系統(tǒng)測試客戶驗收?技術(shù)評審機構(gòu)支撐過程包含4個過程域，分別為：?配置管理?質(zhì)量保證?培訓(xùn)管理?服務(wù)與維護精簡模型如圖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)內(nèi)的各個職能單位有條不紊地開展工作.二、容易裁剪與擴充精簡模型的三類過程貫穿了產(chǎn)品的整個生命周期，17個最常見的過程域都合理地安排在產(chǎn)品生命周期中的某些階段.用戶可以根據(jù)自己產(chǎn)品的特征，適當(dāng)?shù)夭眉艋驍U充精簡的過程域，很容易制定出最適合于本產(chǎn)品的過程模型。圖1-1精簡模型1。2精簡過程域的目的精簡模型所有17個過程域的目的如表1-1所示。項目管理過程域目的立項管理采納符合機構(gòu)最大利益的立項建議，通過立項管理使該建議成為正式的項目。杜絕不符合機構(gòu)最大利益的立項建議被采納，避免浪費機構(gòu)的資源、資金、時間等。結(jié)項管理在項目開發(fā)工作結(jié)束后，對項目的有形資產(chǎn)和無形資產(chǎn)進行清算、對項目進行綜合評估以及總結(jié)經(jīng)驗教訓(xùn)等。項目規(guī)劃為項目的研發(fā)和管理工作制定合理的行動綱領(lǐng)（即項目計劃） ，以便所有相關(guān)人員按照該計劃有條不紊地開展工作。項目監(jiān)控周期性地跟蹤項目計劃的各種參數(shù)如進度、工作量、費用、資源等 ，不斷地了解項目的進展情況，以便當(dāng)項目實際進展顯著偏離計劃時能夠及時采取糾正措施 ?風(fēng)險管理在風(fēng)險產(chǎn)生危害之前識別它們，從而有計劃地消除或削弱風(fēng)險。需求管理在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。項目研發(fā)過程域目的需求開發(fā)通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。技術(shù)預(yù)研在立項之后到開發(fā)工作完成之前的時間內(nèi)，對項目將采用的關(guān)鍵技術(shù)提前學(xué)習(xí)和研究，盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙 ?系統(tǒng)設(shè)計設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，從而在需求與代碼之間建立橋梁，指導(dǎo)開發(fā)人員去實現(xiàn)能滿足用戶需求的軟件產(chǎn)品。實現(xiàn)與測試依據(jù)系統(tǒng)設(shè)計文檔，編寫并測試整個系統(tǒng)的代碼。在 精簡模型中，實現(xiàn)與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。系統(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)支撐過程域目的配置管理通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件來保證所有配置項的完整性和可跟蹤性?配置管理是對工作成果的一種有效保護?質(zhì)量保證提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實現(xiàn)持續(xù)地改進質(zhì)量。培訓(xùn)管理根據(jù)機構(gòu)（或項目）的需求來制定培訓(xùn)計劃，并監(jiān)督該計劃的實施，確保培訓(xùn)取得預(yù)期效果。服務(wù)與維護是指產(chǎn)品銷售之后的客戶服務(wù)和產(chǎn)品維護，其宗旨是提高客戶對產(chǎn)品以及對開發(fā)方的滿意度。表1-1精簡過程域的目的

1.3精簡模型文檔結(jié)構(gòu)與規(guī)范細分精簡模型的文檔結(jié)構(gòu)如圖1—2所示，SPP包含17個過程域，規(guī)范細分如表1-2所示。圖1-2精簡模型文檔結(jié)構(gòu)項目管理過程域主要規(guī)程文檔模板立項管理立項建議立項評審項目籌備《立項建議書》《立項調(diào)查報告書》《立項可行性分析報告》《立項評審報告》結(jié)項管理結(jié)項管理《結(jié)項申請書》《結(jié)項評審報告》項目規(guī)劃制定項目計劃審批項目計劃項目計劃變更控制《項目計劃》《項目計劃變更控制報告》項目監(jiān)控項目計劃跟蹤偏差控制項目進展總結(jié)《項目監(jiān)控數(shù)據(jù)表》《項目偏差控制報告》《項目進展報告》風(fēng)險管理風(fēng)險管理《風(fēng)險檢查表》《風(fēng)險管理報告》需求管理需求確認需求跟蹤需求變更控制《需求跟蹤報告》《需求變更控制報告》項目研發(fā)過程域主要規(guī)程文檔模板需求開發(fā)需求調(diào)查需求分析需求定義《用戶需求說明書》《產(chǎn)品需求規(guī)格說明書》技術(shù)預(yù)研技術(shù)預(yù)研《技術(shù)預(yù)研計劃》《技術(shù)預(yù)研報告》

系統(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)測試系統(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)評估報告》服務(wù)與維護客戶服務(wù)《客戶服務(wù)計劃》《客戶服務(wù)報告》產(chǎn)品維護《產(chǎn)品維護計劃》《產(chǎn)品維護報告》表1—2精簡模型規(guī)范細分1。4精簡模型角色與職責(zé)表精簡模型的主要角色及其職責(zé)如表1-3所示（詳見各個過程域?qū)巧c職責(zé)的描述）.公司在應(yīng)用精簡模型時，可以將精簡模型的各個角色映射到公司原有的崗位上，也可以依據(jù)精簡模型角色建立新的崗位。一個人可以被賦予多個角色，視具體情況而定。職責(zé)簡述常設(shè)角色

職責(zé)簡述機構(gòu)過程改進角色軟件工程過程組（SEPG）（1）制定適合于本機構(gòu)的過程規(guī)范。（2）在機構(gòu)范圍內(nèi)推廣該規(guī)范（如培訓(xùn)、考核），評估機構(gòu)過程能力等。質(zhì)量保證小組（QAG）（1）監(jiān)督規(guī)范的實施，確保所有項目以及相關(guān)部門準(zhǔn)照規(guī)范開展工作。（2）分析并解決機構(gòu)內(nèi)存在的共性質(zhì)量問題,協(xié)組SEPG完善規(guī)范。項目管理過程角色機構(gòu)領(lǐng)導(dǎo)（1） 是機構(gòu)內(nèi)所有項目的主管，對立項管理和結(jié)項管理有最終決策權(quán) ?（2） 監(jiān)督項目經(jīng)理的工作，審批項目經(jīng)理的各種申請。項目經(jīng)理（1）向機構(gòu)領(lǐng)導(dǎo)匯報工作。（2）是項目規(guī)劃、項目監(jiān)控、風(fēng)險管理和需求管理過程域的負責(zé)人。（3）監(jiān)督項目成員的工作，審批項目成員的各種申請?項目研發(fā)過程角色需求分析員調(diào)查、分析并定義需求，撰寫相應(yīng)的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。系統(tǒng)設(shè)計師根據(jù)需求文檔設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等 ，并撰寫相應(yīng)的設(shè)計文檔?程序員（1）根據(jù)系統(tǒng)設(shè)計文檔，編寫軟件系統(tǒng)的代碼。（2）隨時測試和檢查自己的代碼，及時消除代碼中的缺陷。測試員從事單元測試、集成測試和系統(tǒng)測試，主要工作包括制定測試計劃、設(shè)計測試用例、執(zhí)行測試和撰寫測試報告。機構(gòu)支撐過程角色配置管理員（1）為項目制定《配置管理計劃》。（2）創(chuàng)建并維護配置庫，如分配權(quán)限、清除垃圾文件、備份配置庫等。質(zhì)量保證員（即QAG成員）（1）為項目制定《質(zhì)量保證計劃》。（2）周期性的開展“過程與產(chǎn)品質(zhì)量檢查” ?（3）跟蹤質(zhì)量問題，給出質(zhì)量改進措施。培訓(xùn)管理員制定機構(gòu)（或項目）的《培訓(xùn)計劃》，監(jiān)督該計劃的實施，撰寫《培訓(xùn)評估報告》.客戶服務(wù)人員為客戶提供與產(chǎn)品相關(guān)的服務(wù)（如技術(shù)咨詢） ，快速響應(yīng)客戶的要求，給客戶一個滿意的解答?產(chǎn)品維護人員（1）糾錯性維護：及時解決用戶遇到的技術(shù)故障和消除產(chǎn)品中的缺陷。（2）完善性維護：在資源允許的情況下，不斷改善產(chǎn)品功能與質(zhì)量。臨時角色職責(zé)說明立項建議小組（1）開展立項調(diào)查、產(chǎn)品構(gòu)思和可行性分析，撰寫相應(yīng)文檔。（2）申請立項，并在立項評審會議上答辯。立項評審委員會由機構(gòu)領(lǐng)導(dǎo)、各級經(jīng)理、市場人員、技術(shù)專家、財務(wù)人員等組成，委員會按少數(shù)服從多數(shù)原則投票決定是否同意立項。結(jié)項評審委員會對項目的有形資產(chǎn)和無形資產(chǎn)進行清算，對項目進行綜合評估，總結(jié)經(jīng)驗教訓(xùn)等。結(jié)項委員會的人員組成與立項評審委員會的類似。技術(shù)評審委員會對工作成果進行正式技術(shù)評審，盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷?該委員會由項目內(nèi)外的技術(shù)專家組成。配置控制委員會對配置管理各項活動擁有決策權(quán)（例如審批計劃，審批變更請求等） 。表1—3精簡模型的角色與職責(zé)簡表1。5公司軟件過程的政策1。5。1目標(biāo)持續(xù)改進機構(gòu)的軟件過程能力，不斷地提高產(chǎn)品質(zhì)量、提高生產(chǎn)率并且降低開發(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ì)量管理的政策質(zhì)量管理口號：“在開發(fā)過程之中內(nèi)建質(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)生之際，對其進行技術(shù)評審（分正式或非正式兩種），目的是盡早地發(fā)現(xiàn)工作成果中的缺陷,并幫助開發(fā)人員及時消除缺陷,從而提高產(chǎn)品的質(zhì)量.如果時間允許的話，應(yīng)當(dāng)盡可能多地對產(chǎn)品的重要工作成果進行技術(shù)評審。技術(shù)評審活動由項目開發(fā)團隊組織。三、測試測試是指通過運行測試用例（testcase）來找出軟件中的缺陷。測試與技術(shù)評審的主要區(qū)別是前者要運行軟件而后者不必運行軟件.一般地，產(chǎn)品開發(fā)過程中有四個測試階段:單元測試、集成測試、系統(tǒng)測試和驗收測試。其中單元測試和集成測試可以由項目開發(fā)團隊組織。系統(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的負責(zé)人(或稱為質(zhì)量經(jīng)理)。在機構(gòu)領(lǐng)導(dǎo)的許可下，該負責(zé)人組建QAG(成員可以是全職的也可以是兼職的)。QAG在行政上獨立于任何項目。這種獨立性有助于質(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項目團隊的政策項目中的任何管理人員、開發(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ī)范，從而快速建立本項目的過程規(guī)范。這項工作應(yīng)當(dāng)在“項目規(guī)劃過程域”中完成，并在《項目計劃》中體現(xiàn)出來。如果項目對機構(gòu)過程規(guī)范的裁剪幅度比較大，遭到QAG的反對，如果雙方不能達成共識，則由機構(gòu)領(lǐng)導(dǎo)處理該爭議。SEPG對項目過程能力的評估成績將作為評定項目人員工作業(yè)績的重要因素，具體比重由機構(gòu)領(lǐng)導(dǎo)決定，建議占30％以上的比重。立項管理參見《項目管理制度試行V2.1版本》項目規(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ā)和管理工作。項目的計劃書可分兩類：一是全局的計劃書(OverallPlan),這里稱為《項目計劃》二是一些下屬計劃書(SubordinatePlan)，例如《配置管理計劃》、《質(zhì)量保證計劃》、一些開發(fā)計劃和測試計劃等。下屬計劃書是對《項目計劃》的補充,其內(nèi)容不可與《項目計劃》沖突。通?！俄椖坑媱潯酚身椖拷?jīng)理負責(zé)制定，由機構(gòu)領(lǐng)導(dǎo)審批.而下屬計劃書一般由項目成員制定，由項目經(jīng)理審批即可。

項目計劃過程域有3個主要規(guī)程:“制定項目計劃”、“審批項目計劃”和“項目計劃變更控制”，流程如圖3-1所示。圖3—1項目規(guī)劃流程圖項目監(jiān)控項目監(jiān)控（ProjectMonitoringandControl，PMC）的目的是通過周期性地跟蹤項目計劃的各種參數(shù)如進度、工作量、費用、資源、工作成果等，不斷地了解項目的進展情況,以便當(dāng)項目實際進展?fàn)顩r顯著偏離計劃時能夠及時采取糾正措施.本規(guī)范闡述了項目監(jiān)控過程域的三個主要規(guī)程:?項目計劃跟蹤?控制偏差?項目進展匯報圖4-1項目監(jiān)控流程4.1項目計劃跟蹤周期性的跟蹤任務(wù)（含進度和工作量）、費用、資源、工作成果等，及時了解項目的實際進展情況。為持續(xù)過程改進提供有價值的數(shù)據(jù)。4.1.1任務(wù)跟蹤項目經(jīng)理（或其指定的項目成員）周期性地（如每周一次）跟蹤每個重要的任務(wù)，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中.任務(wù)跟蹤表的參考格式如表4—1所示。任務(wù)名稱實際起止時間跟蹤日期、當(dāng)前進度實際工作量實際工作成果

表4—1任務(wù)跟蹤表4.1。2費用跟蹤項目經(jīng)理（或其指定的項目成員）周期性地跟蹤項目費用，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中.費用跟蹤表的參考格式如表4—2所示。4.1。3資源跟蹤項目經(jīng)理（或其指定的項目成員）周期性地跟蹤軟硬件資源，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中.資源跟蹤表的參考格式如表4-3所示.軟硬件資源名稱級別實際配置獲取方式與時間使用說明關(guān)鍵關(guān)鍵普通普通表4—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控制偏差對比“項目實際進展”和“項目計劃”,分析偏差,如果發(fā)現(xiàn)項目實際進展顯著偏離計劃，則及時采取糾正措施。4。3項目進展匯報周期性地匯報項目進展情況。項目經(jīng)理周期性地總結(jié)項目進展情況，撰寫《項目進展報告》并通報給機構(gòu)領(lǐng)導(dǎo)和所有項目成員。基本信息項目名稱報告日期項目編號報告批次第N份項目經(jīng)理項目所處階段項目進展?fàn)顩r計劃實際情況任務(wù)與進度工作成果費用人力資源軟硬件資源問題與對策表4—6項目進展報告風(fēng)險管理風(fēng)險管理(RiskManagement,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)險對項目造成的危害程度。?風(fēng)險可能性：指風(fēng)險發(fā)生的幾率。?風(fēng)險系數(shù):是風(fēng)險嚴(yán)重性和風(fēng)險可能性的乘積。參數(shù)等級值描述風(fēng)險嚴(yán)重性很高5例如進度延誤大于30%，或者費用超支大于30%。比較高4例如進度延誤20%~30%，或者費用超支20%?30%。中等3例如進度延誤低于20%，或者費用超支低于20%.比較低2例如進度延誤低于10%，或者費用超支低于10%。很低1例如進度延誤低于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ā)生的幾率為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ù)值為10~25，應(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)險跟蹤:跟蹤風(fēng)險減緩過程，記錄風(fēng)險的狀態(tài).

在項目的生命周期內(nèi),上述4個活動將被循環(huán)執(zhí)行，如圖5-1所示。直到項目的所有風(fēng)險都被識別與解決為止。常用的《風(fēng)險檢查表》，使用者應(yīng)根據(jù)實際情況進行適當(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ā)生重大的損失或傷亡事故嗎 ？是否在開發(fā)很少有人真正需要卻自以為很好的產(chǎn)品？是否在開發(fā)可能虧本的產(chǎn)品？客戶客戶的需求是否含糊不清？客戶是否反反復(fù)復(fù)地改動需求？客戶指定的需求和交付期限在客觀上可行嗎？客戶對產(chǎn)品的健壯性、可靠性、性能等質(zhì)量因素有非常過分的要求嗎？客戶的合作態(tài)度友善嗎？與客戶簽的合同公正嗎？雙方互利嗎？客戶的信譽好嗎？例如按客戶的需求開發(fā)了產(chǎn)品，但是客戶可能不購買。子承包商供應(yīng)商與子承包商、供應(yīng)商簽訂的合同公正嗎？雙方互利嗎？子承包商、供應(yīng)商的信譽好嗎？子承包商、供應(yīng)商有可能倒閉嗎？子承包商、供應(yīng)商能及時交付質(zhì)量合格的產(chǎn)品（或部件）嗎？子承包商、供應(yīng)商有能力做好售后服務(wù)嗎？管理風(fēng)險風(fēng)險類型檢查項項目計劃對項目的規(guī)模、難度估計是否比較正確？

人力資源（開發(fā)人員、管理人員）夠用嗎？合格嗎？項目所需的軟件、硬件能按時到位嗎？項目的經(jīng)費夠用嗎？進度安排是否過于緊張？有合理的緩沖時間嗎？進度表中是否遺忘了一些重要的（必要的）任務(wù)？進度安排是否考慮了關(guān)鍵路徑？是否可能出現(xiàn)某一項工作延誤導(dǎo)致其他一連串的工作也被延誤？任務(wù)分配是否合理？（即把任務(wù)分配給合適的項目成員，充分發(fā)揮其才能）是否為了節(jié)省錢，不采用（購買）成熟的軟件模塊，一切從零做起？???項目團隊項目成員團結(jié)嗎？是否存在矛盾？是否絕大部分的項目成員對工作認真負責(zé)？絕大部分的項目成員有工作熱情嗎？團隊之中有“害群之馬”嗎？技術(shù)開發(fā)隊伍中有臨時工嗎？本項目開發(fā)過程中是否會有核心人員辭職、調(diào)動？是否能保證“人員流動基本不會影響工作的連續(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ā)人員懂得項目所涉及的具體業(yè)務(wù)嗎？能否理解用戶的需求？需求文檔能夠正確地、完備地表達用戶需求嗎？需求開發(fā)人員能否與客戶對有爭議的需求達成共識？需求開發(fā)人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？綜合技術(shù)開發(fā)能力包括設(shè)計編程、測試等開發(fā)人員是否有開發(fā)相似產(chǎn)品的經(jīng)驗？待開發(fā)的產(chǎn)品是否要與未曾證實的軟硬件相連接？對開發(fā)人員而言，本項目的技術(shù)難度高嗎？開發(fā)人員是否已經(jīng)掌握了本項目的關(guān)鍵技術(shù)？如果某項技術(shù)尚未實踐過，開發(fā)人員能否在預(yù)定時間內(nèi)掌握？

開發(fā)小組是否采用比較有效的分析、設(shè)計、編程、測試工具 ？分析與設(shè)計工作是否過于簡單、草率，從而讓程序員邊做邊改 ？開發(fā)小組采用統(tǒng)一的編程規(guī)范嗎？開發(fā)人員對測試工作重視嗎？能保證測試的客觀性嗎 ？項目有獨立的測試人員嗎？懂得如何進行高效率地測試嗎？是否對所有重要的工作成果進行了同行評審（正式評審或快速檢查）？開發(fā)人員懂得版本控制、變更控制嗎？能夠按照配置管理規(guī)范執(zhí)行嗎？開發(fā)人員重視質(zhì)量嗎？是否會在進度延誤時降低質(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)險管理報告需求管理需求管理（RequirementManagement,RM）的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更。需求管理過程域的三個主要規(guī)程:需求確認需求跟蹤需求變更控制圖6-1需求工程結(jié)構(gòu)圖6.1需求確認項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。當(dāng)需求文檔通過正式的評審之后，開發(fā)方負責(zé)人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。示例如下：本需求文檔建立在雙方對需求的共同理解基礎(chǔ)之上,我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展.如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進度等.甲方負責(zé)人簽字乙方負責(zé)人簽字評審結(jié)束輸出《需求評審報告》,書面的需求承諾需求評審報告摘要需求文檔輸入名稱，標(biāo)識符，版本，作者，完成日期，…需求評審報告輸入名稱,標(biāo)識符，評審日期,...評審結(jié)論:］工作成果合格，“無需修改”或者“需要輕微修改但不必再審核” ?［丿］工作成果基本合格，需要作少量的修改，之后通過審核即可。:］工作成果不合格，需要作比較大的修改，之后必須重新對其評審。評審意見評審小組成員輸入評審小組成員表6—1需求評審報告需求承諾需求文檔輸入名稱,標(biāo)識符，版本，作者，完成日期客戶承諾承諾…簽字，日期項目經(jīng)理承諾承諾…簽字，日期表6-2需求承諾6。2需求跟蹤將系統(tǒng)設(shè)計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文檔－設(shè)計文檔－代碼－測試用例"之間的一致性，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。項目經(jīng)理跟蹤需求.建立與維護需求跟蹤矩陣：正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點。逆向跟蹤?檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處.正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）?需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單元之間的可能存在“一對一"、“一對多”或“多對多"的關(guān)系。由于對應(yīng)關(guān)系比較復(fù)雜，最好在表格中加必要的文字解釋。表6—3為簡單的需求跟蹤矩陣格式。?當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。#需求文檔（版本，日期）設(shè)計文檔（版本，日期）代碼（版本，日期）測試用例（版本，日期）1標(biāo)題或標(biāo)識符，說明標(biāo)題或標(biāo)識符，說明代碼名稱，說明測試用例名稱，說明2表6-3簡單的需求跟蹤矩陣格式6.3需求變更控制修改“原需求文檔”中不正確的內(nèi)容,產(chǎn)生新的需求文檔?？刂菩枨笪臋n的變更，防止發(fā)生混亂。補充說明：本規(guī)程中的“原需求文檔"是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。開發(fā)方負責(zé)人（項目經(jīng)理）和客戶共同控制需求變更。需求變更申請申請變更的需求文檔輸入名稱，版本，日期等信息變更的內(nèi)容及其理由

評估需求變更將對項目造成的影響申請人簽字變更申請的審批意見項目經(jīng)理簽字審批意見：簽字，日期客戶簽字（合同項目）審批意見：簽字，日期更改需求文檔變更后的需求文檔輸入名稱,版本，完成日期等信息更改人簽字重新評審需求文檔需求評審小組簽字評審意見：簽字，日期變更結(jié)束項目經(jīng)理簽字簽字日期：表6-4需求變更控制報告結(jié)項管理結(jié)項管理（ProjectClosingManagement，PCM）是指在項目開發(fā)工作結(jié)束后,對項目的有形資產(chǎn)和無形資產(chǎn)進行清算;對項目進行綜合評估;總結(jié)經(jīng)驗教訓(xùn)等。立項管理與結(jié)項管理是前后呼應(yīng)的兩個過程域，使得項目管理過程“有始有終 "。項目結(jié)束有兩種狀況:一是正常結(jié)束，二是異常結(jié)束。前者是指項目按預(yù)定計劃結(jié)束。后者原因有多種，歸根結(jié)底都是由于該項目不再符合機構(gòu)的最大利益。例如有些項目因不適應(yīng)市場而被中途淘汰，有些項目在執(zhí)行過程中大大因偏離計劃（如進度延誤、費用超支）而被取消。不論項目屬于正常結(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)驗教訓(xùn)，使整個機構(gòu)受益。結(jié)項管理的流程如圖7—1所示，產(chǎn)生的主要文檔有：需求開發(fā)需求開發(fā)(RequirementDevelopment,RD)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。本規(guī)范闡述了需求開發(fā)過程域的兩個主要規(guī)程：需求調(diào)查需求定義需求開發(fā)與需求管理是相輔相成的兩類活動，它們共同構(gòu)成完整的需求工程。需求工程結(jié)構(gòu)圖如圖6—1所示，需求開發(fā)和需求管理的流程如圖8-1所示。求分析”則貫穿于上述兩個階段。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進行的。我們把從事需求開發(fā)工作的人員稱為需求分析員（也叫系統(tǒng)分析員）,避免與其它開發(fā)人員混淆。一、需求調(diào)查需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說明書》.二、需求分析需求分析的目的是對各種需求信息進行分析,消除錯誤,刻畫細節(jié)等.常用的需求分析方法有“問答分析法”、“結(jié)構(gòu)化分析法"和“面向?qū)ο蠓治龇ā?。三、需求定義需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。系統(tǒng)設(shè)計人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作.需求開發(fā)過程域產(chǎn)生的主要文檔有:技術(shù)預(yù)研技術(shù)預(yù)研（TechnicalPre-Research，TPR）是指在立項之后到開發(fā)工作完成之前的時間內(nèi)對項目將采用的關(guān)鍵技術(shù)提前學(xué)習(xí)和研究,以便盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙。在產(chǎn)品開發(fā)過程中,技術(shù)問題可能會層出不窮。如果一點技術(shù)障礙都沒有遇到，要么是開發(fā)人員的技術(shù)水平實在太高了，要么是項目的技術(shù)含量實在太低了，這類情況比較少見一般說來，在設(shè)計或?qū)崿F(xiàn)階段遇到了技術(shù)障礙，才去攻克問題，其代價通常比較高。因為其他人的工作可能會被阻塞，已經(jīng)投入的不少資源將被閑置?最糟糕的是，如果此技術(shù)障礙無法攻克，不得已要改變技術(shù)方案、重新設(shè)計系統(tǒng)，那么不僅浪費了人力、財力、時間，處理不好還會使開發(fā)隊伍陷入混亂狀態(tài)。所以開展技術(shù)預(yù)研工作至少有兩大好處：?幫助開發(fā)人員更好地進行需求開發(fā)、系統(tǒng)設(shè)計和程序設(shè)計。?防止開發(fā)進程被技術(shù)障礙打斷，導(dǎo)致大量的相關(guān)工作被阻塞。技術(shù)預(yù)研的流程如圖9—1所示。圖9-1技術(shù)預(yù)研流程技術(shù)預(yù)研過程中產(chǎn)生的主要文檔有：10系統(tǒng)設(shè)計系統(tǒng)設(shè)計(SystemDesign,SD)是指設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，從而在需求與代碼之間建立橋梁，指導(dǎo)開發(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è)計分析與設(shè)計軟件的體系結(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è)計人員）體系結(jié)構(gòu)設(shè)計流程如圖10-2所示.圖10—2體系結(jié)構(gòu)設(shè)計流程10。2用戶界面設(shè)計設(shè)計軟件的用戶界面，產(chǎn)生《用戶界面設(shè)計報告》。制作用戶界面的資源如圖像、圖標(biāo)或者界面專用組件等項目經(jīng)理指定若干名開發(fā)人員從事用戶界面設(shè)計（以下稱為界面設(shè)計人員）如果可能的話，邀請用戶或美工人員協(xié)助設(shè)計用戶界面。用戶界面設(shè)計流程如圖10—3所示。Stepl。設(shè)計準(zhǔn)備Step2。 界面設(shè)計2.1原型創(chuàng)作2.2原型評估Stepl。設(shè)計準(zhǔn)備Step2。 界面設(shè)計2.1原型創(chuàng)作2.2原型評估2。3細化迭代Step3。Step4.撰寫 ?設(shè)計文檔評審圖10—3體系結(jié)構(gòu)設(shè)計流程10.3數(shù)據(jù)庫設(shè)計設(shè)計軟件的數(shù)據(jù)庫，產(chǎn)生《數(shù)據(jù)庫設(shè)計報告》。項目經(jīng)理指定若干名開發(fā)人員從事數(shù)據(jù)庫設(shè)計（以下稱為數(shù)據(jù)庫設(shè)計人員）10。4模塊設(shè)計設(shè)計軟件所有模塊的主要接口與屬性、數(shù)據(jù)結(jié)構(gòu)和算法，產(chǎn)生《模塊設(shè)計報告》。項目經(jīng)理指定若干名開發(fā)人員從事模塊的設(shè)計（以下稱為模塊設(shè)計人員），模塊設(shè)計人員將在實現(xiàn)階段編寫這些模塊的代碼。模塊設(shè)計流程如圖10-5所示.

圖10—5模塊設(shè)計流程11實現(xiàn)與測試實現(xiàn)與測試（ImplementationandTest，IT）的目的是依據(jù)系統(tǒng)設(shè)計文檔,編寫并測試整個系統(tǒng)的代碼。在本規(guī)范中，實現(xiàn)與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。實現(xiàn)與測試的流程如圖11—1所示。一般地,編程、代碼審查、單元測試、集成測試大致存在先后順序關(guān)系，也可以并行、迭代地開展。上述任何活動中發(fā)現(xiàn)的缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷（改錯）。圖11-1實現(xiàn)與測試流程圖由于實現(xiàn)與測試是工作量最大、時間最長、產(chǎn)生工作成果（代碼與文檔）最多的一個項目研發(fā)過程域，所以需要作充分的準(zhǔn)備工作。實現(xiàn)與測試工作基本上在開發(fā)小組內(nèi)部開展.一個項目可能有一個或者多個開發(fā)小組。對于小型項目，項目經(jīng)理可以兼任開發(fā)組長。特別要注意的是，開發(fā)人員應(yīng)當(dāng)對自己的代碼進行審查和測試 （這是份內(nèi)的工作），但是不能作為該代碼已經(jīng)通過審查和測試的依據(jù)。所以開發(fā)人員還要互相審查和測試同伴的代碼。實現(xiàn)與測試過程域產(chǎn)生的主要文檔有：《實現(xiàn)與測試計劃》《編程文檔》《代碼審查報告》《測試用例》《測試報告》《缺陷管理報告》（由缺陷管理工具自動生成）一個項目可能有多個開發(fā)小組，視項目規(guī)模而定.開發(fā)組長由項目經(jīng)理指定開發(fā)組長管理編程、代碼審查、單元測試、集成測試、缺陷管理與改錯等活動12系統(tǒng)測試系統(tǒng)測試（SystemTest,ST）的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。系統(tǒng)測試流程如圖12-1所示。由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計，所以當(dāng)產(chǎn)品需求和系統(tǒng)設(shè)計文檔完成之后，系統(tǒng)測試小組就可以提前開始制定測試計劃和設(shè)計測試用例，而不必等到“實現(xiàn)與測試"階段結(jié)束。這樣可以提高系統(tǒng)測試的效率.系統(tǒng)測試過程中發(fā)現(xiàn)的所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷（改錯）。審批 審批 迭代 圖12—1系統(tǒng)測試流程圖項目經(jīng)理設(shè)法組建富有成效的系統(tǒng)測試小組。系統(tǒng)測試小組的成員主要來源于:機構(gòu)獨立的測試小組（如果存在的話）.邀請其它項目的開發(fā)人員參與系統(tǒng)測試。本項目的部分開發(fā)人員.機構(gòu)的質(zhì)量保證人員.系統(tǒng)測試小組應(yīng)當(dāng)根據(jù)項目的特征確定測試內(nèi)容。一般地，系統(tǒng)測試的主要內(nèi)容包括：功能測試.即測試軟件系統(tǒng)的功能是否正確，其依據(jù)是需求文檔，如《產(chǎn)品需求規(guī)格說明書》。由于正確性是軟件最重要的質(zhì)量因素，所以功能測試必不可少。健壯性測試。即測試軟件系統(tǒng)在異常情況下能否正常運行的能力。健壯性有兩層含義:一是容錯能力，二是恢復(fù)能力。性能測試。即測試軟件系統(tǒng)處理事務(wù)的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考(例如用于宣傳)。用戶界面測試。重點是測試軟件系統(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í)行測試，并撰寫相應(yīng)的文檔.測試組長管理上述事務(wù)。開發(fā)人員及時消除測試人員發(fā)現(xiàn)的缺陷。13客戶驗收客戶驗收(CustomerAcceptance，CA)是指客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。客戶對產(chǎn)品的驗收主要有兩種方式：成果審查。驗收人員審查開發(fā)方應(yīng)當(dāng)交付的成果,如代碼、文檔等等。確保這些成果是完整的并且是正確的.驗收測試。驗收人員對待交付的產(chǎn)品進行全面的測試，確保產(chǎn)品功能、質(zhì)量符合需求。驗收測試的內(nèi)容、方法與系統(tǒng)測試幾乎是相同的。兩者主要區(qū)別在于執(zhí)行人員不同.驗收測試人員來自于客戶方，而系統(tǒng)測試人員則來自于開發(fā)方?？蛻趄炇樟鞒倘鐖D13-1所示.驗收準(zhǔn)備―?成果審查與驗收測試—問題處理——>交付與簽字圖13-1客戶驗收流程客戶驗收過程域產(chǎn)生的主要文檔有：?《客戶驗收計劃》《驗收測試用例》《客戶驗收報告》補充說明：“客戶驗收"是針對合同項目而言的14技術(shù)評審技術(shù)評審（TechnicalReview，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ā)人員能夠及時地得到同行專家的幫助和指導(dǎo) ,無疑會加深對工作成果的理解，更好地預(yù)防缺陷，一定程度上提高了開發(fā)生產(chǎn)率?？梢娂夹g(shù)評審有助于“提高質(zhì)量、提高生產(chǎn)率、降低成本”,符合軟件過程改進的根本目的.技術(shù)評審有兩種基本類型:正規(guī)技術(shù)評審（FTR）。FTR比較嚴(yán)格，需要舉行評審會議，參加評審會議的人員比較多。非正規(guī)技術(shù)評審（ITR）。ITR的形式比較靈活，通常在同伴之間開展，不必舉行評審會議,評審人員比較少。理論上講，為了確保產(chǎn)品的質(zhì)量,產(chǎn)品的所有工作成果都應(yīng)當(dāng)接受技術(shù)評審.現(xiàn)實中為了節(jié)約時間，允許人們有選擇地對工作成果進行技術(shù)評審。技術(shù)評審方式也視工作成果的重要性和復(fù)雜性而定。技術(shù)評審過程域有三個主要規(guī)程:“制定技術(shù)評審計劃”、“正規(guī)技術(shù)評審”和“非正規(guī)技術(shù)評審"，如圖14—1所示。圖14-1技術(shù)評審過程域示意圖技術(shù)評審的注意事項：?評審人員的職責(zé)是發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員給出消除缺陷的辦法,而不是替開發(fā)人員消除缺陷。技術(shù)評審應(yīng)當(dāng)“就是論事”不要打擊有失誤的開發(fā)人員的工作積極性，更不準(zhǔn)搞人身攻擊(如挖苦、諷刺等)。在會議評審期間要限制過多的爭論，以免浪費他人的時間。技術(shù)評審過程域產(chǎn)生的主要文檔有:《技術(shù)評審計劃》《技術(shù)評審?fù)ㄖ贰都夹g(shù)評審報告》《技術(shù)評審檢查表》15配置管理配置管理(ConfigurationManagement,CM)的目的是通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件，來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。本規(guī)范闡述了配置管理過程域的四個主要規(guī)程:制定配置管理計劃?配置庫管理?配置項版本控制?配置項變更控制項目研發(fā)和管理過程中會產(chǎn)生許許多多的工作成果，例如文檔、程序和數(shù)據(jù)等，它們都應(yīng)當(dāng)被保存起來，以便查閱和修改。如果把所有文件一股腦地塞進計算機里，那么使用起來肯定很麻煩。毫無疑問，人們應(yīng)當(dāng)將文件分門別類、有條理地保存起來。凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項(ConfigurationItem，CI)，配置項主要有兩大類:(1)屬于產(chǎn)品組成部分的工作成果，例如需求文檔、設(shè)計文檔、源代碼、測試用例 等(2)項目管理和機構(gòu)支撐過程域產(chǎn)生的文檔。這些文檔雖然不是產(chǎn)品的組成部分，但是值得保存。每個配置項的主要屬性有:名稱、標(biāo)識符、文件狀態(tài)、版本、作者、日期等.所有配置項都被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程?；€(Baseline)由一組配置項組成，這些配置項構(gòu)成了一個相對穩(wěn)定的邏輯實體?；€中的配置項被“凍結(jié)”了,不能再被任何人隨意修改(見變更控制規(guī)程)?；€通常對應(yīng)于開發(fā)過程中的里程碑(Milestone)，一個產(chǎn)品可以有多個基線，也可以只有一個基線.基線的主要屬性有：名稱、標(biāo)識符、版本、日期等。通常將交付給客戶的基線稱為一個“Release”,為內(nèi)部開發(fā)用的基線則稱為一個“Build”。所有的項目成員都要使用配置管理軟件來保護自己的工作成果。機構(gòu)應(yīng)當(dāng)采用統(tǒng)一的配置管理軟件，常見的配置管理軟件有Microsoft的VisualSourceSafe和Rational的ClearCase等.為了提高配置管理的效率和安全性，機構(gòu)應(yīng)當(dāng)有專門的配置管理員（角色）.配置管理員為每個項目制定《配置管理計劃》，創(chuàng)建和維護配置庫。鑒于配置管理的重要性和復(fù)雜性，機構(gòu)還應(yīng)當(dāng)設(shè)立配置控制委員會（ConfigurationControlBoard,CCB）.CCB是個虛擬小組,對配置管理各項活動擁有決策權(quán)（例如審批計劃，審批變更請求等）。對于配置管理而言，CCB是決策者，而配置管理員是執(zhí)行者。如果機構(gòu)的各個項目緊密相關(guān)（例如一個產(chǎn)品線下的多個項目）,建議機構(gòu)設(shè)立公共的CCB，這個公共的CCB對所有項目的配置管理擁有決策權(quán).如果機構(gòu)的各個項目相對獨立，那么每個項目可以設(shè)立各自的CCB。CCB的決策采用“少數(shù)服從多數(shù)”原則。配置管理的流程如圖15—1所示。一、制定配置管理計劃配置管理員制定《配置管理計劃》，主要內(nèi)容包括配置管理軟硬件資源、配置項計劃、基線計劃、交付計劃、備份計劃等。CCB審批該計劃。二、配置庫管理配置管理員為項目創(chuàng)建配置庫，并給每個項目成員分配權(quán)限。各項目成員根據(jù)自己的權(quán)限操作配置庫。配置管理員定期維護配置庫，例如清楚垃圾文件、備份配置庫等。三、版本控制在項目開發(fā)過程中,絕大部分的配置項都要經(jīng)過多次的修改才能最終確定下來。對配置項的任何修改都將產(chǎn)生新的版本.由于我們不能保證新版本一定比老版本“好",所以不能拋棄老版本。版本控制的目的是按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失或混淆等現(xiàn)象,并且可以快速準(zhǔn)確地查找到配置項的任何版本。配置項的狀態(tài)有三種：“草稿”、“正式發(fā)布"和“正在修改”,本規(guī)程制定了配置項狀態(tài)變遷與版本號的規(guī)則。四、變更控制 在項目開發(fā)過程中，配置項發(fā)生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導(dǎo)致混亂。修改處于“草稿”狀態(tài)的配置項不算是“變更”，無需CCB的批準(zhǔn)，修改者按照版本控制規(guī)則執(zhí)行即可.當(dāng)配置項的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)"后，此時任何人都不能隨意修改，必須依據(jù)“申請－審批－執(zhí)行變更－再評審－結(jié)束”的規(guī)則執(zhí)行。五、配置審計為了保證所有人員（包括項目成員、配置管理員和CCB）都遵守配置管理規(guī)范,質(zhì)量保證人員要定期審計配置管理工作。配置審計是一種“過程質(zhì)量檢查”活動，是質(zhì)量保證人員的工作職責(zé)之一。配置管理過程域產(chǎn)生的主要文檔有：《配置管理計劃》《配置庫管理報告》《配置項變更控制報告》16質(zhì)量保證質(zhì)量保證（QualityAssurance，QA）的目的是提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量 ",從而實現(xiàn)持續(xù)地改進質(zhì)量。質(zhì)量保證是一種有計劃的、貫穿于整個產(chǎn)品生命周期的質(zhì)量管理方法。本規(guī)范闡述了質(zhì)量保證過程域的三個主要規(guī)程：制定質(zhì)量保證計劃過程與產(chǎn)品質(zhì)量檢查?問題跟蹤與質(zhì)量改進過程質(zhì)量與產(chǎn)品質(zhì)量存在某種程度的因果關(guān)系，通?！昂玫倪^程”產(chǎn)生“好的產(chǎn)品"而“差的過程”將產(chǎn)生“差的產(chǎn)品”。人們銷售的是產(chǎn)品而不是過程，用戶關(guān)心的是最終產(chǎn)品的質(zhì)量，而開發(fā)者（團隊）既要關(guān)心過程質(zhì)量又要關(guān)心產(chǎn)品質(zhì)量.提高產(chǎn)品質(zhì)量有三種基本方法：質(zhì)量保證。質(zhì)量保證人員通過有計劃地檢查“工作過程以及工作成果"是否符合既定的規(guī)范，來監(jiān)控和改進“過程質(zhì)量”與“產(chǎn)品質(zhì)量"。技術(shù)評審。請同行專家、技術(shù)人員對工作成果進行評審，盡早發(fā)現(xiàn)工作成果中的缺陷。?測試。通過運行測試用例來找出軟件中的缺陷。例如單元測試、集成測試、系統(tǒng)測試、驗收測試等。質(zhì)量保證既關(guān)心過程質(zhì)量又關(guān)心產(chǎn)品質(zhì)量。如果“工作過程以及工作成果”不符合既定的規(guī)范，那么產(chǎn)品的質(zhì)量肯定有問題?；谶@樣的推理，質(zhì)量保證人員即使不是技術(shù)專家，他也能夠客觀地檢