全套CMMi軟件質(zhì)量管理體系

[Step4]審批新的項目計劃機構(gòu)領(lǐng)導(dǎo)審批新的《項目計劃》，參見規(guī)程[SPP-PROC-PP-APPROVE]。5.6輸出《項目計劃變更控制報告》新的《項目計劃書》5.7結(jié)束準則變更申請以及新的《項目計劃》都得到了機構(gòu)領(lǐng)導(dǎo)的批準。5.8度量項目經(jīng)理統(tǒng)計工作量。6補充對項目規(guī)劃過程域產(chǎn)生的所有有價值的文檔進行配置管理?！俄椖坑媱潯繁粰C構(gòu)領(lǐng)導(dǎo)批準之后，有關(guān)人員即可撰寫下屬計劃如《配置管理計劃》、《質(zhì)量保證計劃》、一些開發(fā)計劃和測試計劃等。選用合適的軟件工具，盡量減少項目規(guī)劃過程域的工作量。對于客戶委托開發(fā)的項目，客戶在項目規(guī)劃過程域的介入程度視具體情況而定 四、項目監(jiān)控項目監(jiān)控（ProjectMonitoringandControl,PMC）的目的是通過周期性地跟蹤項目計劃的各種參數(shù)如進度、工作量、費用、資源、工作成果等，不斷地了解項目的進展情況，以便當(dāng)項目實際進展狀況顯著偏離計劃時能夠及時采取糾正措施。項目監(jiān)控過程域是SPP模型的重要組成部分。本規(guī)范闡述了項目監(jiān)控過程域的三個主要規(guī)程：項目計劃跟蹤[PASS-PROC-PMC-TRACKING]控制偏差[PASS-PROC-PMC-CONTROL]項目進展匯報[PASS-PROC-PP-REPORT]上述每個規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。本規(guī)范適用于國內(nèi)IT企業(yè)的軟件研發(fā)項目。建議用戶根據(jù)自身情況（如商業(yè)目標、研發(fā)實力等）適當(dāng)?shù)匦薷谋疽?guī)范，然后推廣使用。1介紹項目監(jiān)控至少有以下幾個好處：避免原本合理的計劃在實施時落空；避免“執(zhí)迷不悟”地按照不合理的計劃行事；將監(jiān)控過程產(chǎn)生的數(shù)據(jù)保存起來，為機構(gòu)持續(xù)的過程改進提供有價值的數(shù)據(jù)。項目監(jiān)控過程域有3個主要規(guī)程：“項目計劃跟蹤”、“偏差控制”、“項目進展匯報”，流程如圖4-1所示。項目計劃跟蹤項目經(jīng)理周期性地跟蹤項目計劃的各種參數(shù)如進度、工作量、費用、資源、工作成果等，從而及時了解項目的實際進展情況。從數(shù)據(jù)分析角度講，計劃是基于估計的，而跟蹤則是基于度量的。偏差控制項目經(jīng)理將跟蹤得到的數(shù)據(jù)和《項目計劃》中的數(shù)據(jù)進行對比，分析偏差，如果發(fā)現(xiàn)項目進展顯著偏離計劃，應(yīng)當(dāng)及時采取糾正措施。項目進展匯報項目經(jīng)理周期性地召開會議，討論項目進展情況，撰寫“項目進展報告”并通報給機構(gòu)領(lǐng)導(dǎo)和所有項目成員。項目監(jiān)控過程域產(chǎn)生的主要文檔有：《項目監(jiān)控數(shù)據(jù)表》，模板見[SPP-TEMP-PMC-DATA]?！俄椖科羁刂茍蟾妗?，模板見[SPP-TEMP-PMC-CONTROL]?！俄椖窟M展報告》，模板見[SPP-TEMP-PP-REPORT]。項目計劃跟蹤偏差控制項目進展總結(jié)周期性地開展圖4-1項目監(jiān)控流程2項目計劃跟蹤2.1目的周期性的跟蹤任務(wù)（含進度和工作量）、費用、資源、工作成果等，及時了解項目的實際進展情況。為持續(xù)過程改進提供有價值的數(shù)據(jù)。2.2角色與職責(zé)項目經(jīng)理跟蹤項目的實施。項目成員協(xié)助項目經(jīng)理采集有關(guān)數(shù)據(jù)。2.3啟動準則《項目計劃》已經(jīng)制定2.4輸入《項目計劃》2.5主要步驟[Step1]任務(wù)跟蹤項目經(jīng)理（或其指定的項目成員）周期性地（如每周一次）跟蹤每個重要的任務(wù)，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中。任務(wù)跟蹤表的參考格式如表4-1所示。任務(wù)名稱任務(wù)名稱實際起止時間跟蹤日期、當(dāng)前進度實際工作量實際工作成果表4-1任務(wù)跟蹤表[Step2]費用跟蹤項目經(jīng)理（或其指定的項目成員）周期性地跟蹤項目費用，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中。費用跟蹤表的參考格式如表4-2所示。費用類別費用類別主要開支項、用途金額時間表4-2費用跟蹤表[Step3]資源跟蹤項目經(jīng)理（或其指定的項目成員）周期性地跟蹤軟硬件資源，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中。資源跟蹤表的參考格式如表6-3所示。軟硬件資源名稱軟硬件資源名稱級別實際配置獲取方式與時間使用說明關(guān)鍵關(guān)鍵普通…普通表6-3資源跟蹤表[Step4]工作成果及其規(guī)模跟蹤項目經(jīng)理（或其指定的項目成員）周期性地跟蹤工作成果及其規(guī)模，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中。工作成果跟蹤表的參考格式如表6-4所示。工作成果名稱工作成果名稱新開發(fā)的成果規(guī)模（代碼行、類、文檔頁數(shù)）復(fù)用或自動生成的成果規(guī)模（代碼行、類、文檔頁數(shù)）工作成果1工作成果2…總和表6-4工作成果及其規(guī)模跟蹤表2.6輸出《項目監(jiān)控數(shù)據(jù)表》2.7結(jié)束準則任務(wù)跟蹤、費用跟蹤、資源跟蹤、工作成果跟蹤所產(chǎn)生的數(shù)據(jù)已經(jīng)保存在《項目監(jiān)控數(shù)據(jù)表》之中。2.8度量項目經(jīng)理記錄本規(guī)程產(chǎn)生的所有度量數(shù)據(jù)。3控制偏差3.1目的對比“項目實際進展”和“項目計劃”，分析偏差，如果發(fā)現(xiàn)項目實際進展顯著偏離計劃，則及時采取糾正措施。3.2角色與職責(zé)項目經(jīng)理分析偏差，采取糾正措施。3.3啟動準則周期性地跟蹤進度、工作量、費用、資源、工作成果等，及時了解項目的實際進展情況。3.4輸入《項目計劃》《項目監(jiān)控數(shù)據(jù)表》3.5主要步驟[Step1]找出顯著偏差項目經(jīng)理根據(jù)任務(wù)跟蹤、費用跟蹤、工作成果跟蹤所產(chǎn)生的數(shù)據(jù)，對比“項目實際進展”與“項目計劃”，找出顯著偏差項（例如進度或費用偏差大于20％）。[Step2]分析原因項目經(jīng)理分析產(chǎn)生顯著偏差的原因，以便采取正確的糾正措施。[Step3]給出糾正偏差的措施項目經(jīng)理給出糾正顯著偏差的措施：如果偏差主要是由于《項目計劃》不合理導(dǎo)致的，則要變更項目計劃，見規(guī)程[SPP-PROC-PP-CHANGE]。如果《項目計劃》本身是合理的，偏差主要是由于項目成員在執(zhí)行時產(chǎn)生的，那么要求項目成員彌補偏差，避免原本合理的計劃在實施時落空。[Step4]跟蹤糾正偏差的過程項目經(jīng)理跟蹤糾正偏差的過程，直到該偏差被消除為止。3.6輸出《項目偏差控制報告》3.7結(jié)束準則已發(fā)現(xiàn)的顯著偏差被消除。3.8度量項目經(jīng)理統(tǒng)計工作量。4項目進展匯報4.1目的周期性地匯報項目進展情況。4.2角色與職責(zé)項目經(jīng)理周期性地總結(jié)項目進展情況，撰寫《項目進展報告》并通報給機構(gòu)領(lǐng)導(dǎo)和所有項目成員。4.3啟動準則已經(jīng)開展“項目計劃跟蹤”和“偏差控制”。4.4輸入《項目計劃》《項目監(jiān)控數(shù)據(jù)表》《項目偏差控制報告》4.5主要步驟[Step1]舉行項目進展會議項目經(jīng)理周期性地（或者在里程碑處）召開項目進展會議，探討問題，總結(jié)工作，讓所有項目成員清楚地了解項目的實際進展情況。[Step2]撰寫項目進展報告項目經(jīng)理撰寫《項目進展報告》，并及時通報給所有項目成員和機構(gòu)領(lǐng)導(dǎo)。4.6輸出《項目進展報告》4.7結(jié)束準則已經(jīng)舉行項目進展會議，《項目進展報告》已經(jīng)通報給所有項目成員和機構(gòu)領(lǐng)導(dǎo)。4.8度量項目經(jīng)理統(tǒng)計工作量。5補充對項目規(guī)劃過程域產(chǎn)生的所有有價值的文檔進行配置管理。項目經(jīng)理根據(jù)本項目的特征，確定項目監(jiān)控的重點，適當(dāng)修改《項目監(jiān)控數(shù)據(jù)表》和《項目進展報告》的格式。項目經(jīng)理根據(jù)本項目的特征，確定“項目計劃跟蹤”、“項目進展總結(jié)”的頻度，例如每周一次或每月一次。選用合適的軟件工具，盡量減少項目監(jiān)控過程域的工作量。項目監(jiān)控過程域和風(fēng)險管理過程域均由項目經(jīng)理負責(zé)，兩者同步執(zhí)行。 五、風(fēng)險管理風(fēng)險管理（RiskManagement,RiskM）的目的是在風(fēng)險產(chǎn)生危害之前識別它們，從而有計劃地消除或削弱風(fēng)險。風(fēng)險管理過程域是SPP模型的重要組成部分。本規(guī)范闡述了風(fēng)險管理的規(guī)程，該規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。1介紹所有可能危害項目的因素都稱為風(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)險嚴重性：指風(fēng)險對項目造成的危害程度。風(fēng)險可能性：指風(fēng)險發(fā)生的幾率。風(fēng)險系數(shù)：是風(fēng)險嚴重性和風(fēng)險可能性的乘積。參數(shù)參數(shù)等級值描述風(fēng)險嚴重性很高5例如進度延誤大于30%，或者費用超支大于30%。比較高4例如進度延誤20%~30%，或者費用超支20%~30%。中等3例如進度延誤低于20%，或者費用超支低于20%。比較低2例如進度延誤低于10%，或者費用超支低于%10。很低1例如進度延誤低于5%，或者費用超支低于5%。表5-1風(fēng)險嚴重性等級參數(shù)參數(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.00.2表5-2風(fēng)險可能性等級風(fēng)險風(fēng)險系數(shù)風(fēng)險可能性很高5比較高4中等3比較低2很低1風(fēng)險嚴重性很高5252015105比較高420161284中等31512963比較低2108642很低154321本表灰色部分的風(fēng)險系數(shù)值為10~25，應(yīng)當(dāng)優(yōu)先處理。表5-3風(fēng)險系數(shù)等級風(fēng)險嚴重性的等級劃分如表7-1所示，風(fēng)險可能性的等級劃分如表7-2所示，風(fēng)險系數(shù)的等級劃分如表3所示。風(fēng)險管理有4個主要活動：風(fēng)險識別：根據(jù)風(fēng)險檢查表，識別出本項目的風(fēng)險。風(fēng)險分析：估計風(fēng)險嚴重性、風(fēng)險可能性、風(fēng)險系數(shù)。風(fēng)險減緩：對于風(fēng)險系數(shù)超過“容許值”的每一個風(fēng)險，都應(yīng)當(dāng)采取減緩措施。風(fēng)險跟蹤：跟蹤風(fēng)險減緩過程，記錄風(fēng)險的狀態(tài)。風(fēng)險識別風(fēng)險分析風(fēng)險減緩風(fēng)險跟蹤圖7-1風(fēng)險管理示意圖在項目的生命周期內(nèi)，上述4個活動將被循環(huán)執(zhí)行，如圖7-1所示。直到項目的所有風(fēng)險都被識別與解決為止。常用的風(fēng)險檢查表見[SPP-TEMP-RISKM-CHECKLIST]，使用者應(yīng)根據(jù)實際情況進行適當(dāng)?shù)膭h減或補充。風(fēng)險管理過程域產(chǎn)生的主要文檔是《風(fēng)險管理報告》，模板見[SPP-TEMP-RISKM-REPORT]。2風(fēng)險管理規(guī)程2.1目的在項目的生命周期內(nèi)，循環(huán)執(zhí)行風(fēng)險識別、風(fēng)險分析、風(fēng)險減緩和風(fēng)險跟蹤，直到項目的所有風(fēng)險都被識別與解決為止。2.2角色與職責(zé)項目經(jīng)理負責(zé)風(fēng)險管理。項目成員協(xié)助項目經(jīng)理處理風(fēng)險。2.3啟動準則《項目計劃》已經(jīng)制定，項目研發(fā)已經(jīng)開始。2.4輸入《項目計劃》項目監(jiān)控過程產(chǎn)生的文檔如《項目監(jiān)控數(shù)據(jù)表》、《項目偏差控制報告》和《項目進展報告》等2.5主要步驟[Step1]風(fēng)險識別項目經(jīng)理根據(jù)“風(fēng)險檢查表”[SPP-TEMP-RISKM-CHECKLIST，]定期（例如每周一次）識別本項目的風(fēng)險。[Step2]風(fēng)險分析項目經(jīng)理評估每個風(fēng)險的嚴重性、可能性和風(fēng)險系數(shù)，并按照風(fēng)險系數(shù)從高到低的順序排列風(fēng)險。[Step3]風(fēng)險減緩對于風(fēng)險系數(shù)超過“容許值”（建議為10）的每一個風(fēng)險，項目經(jīng)理應(yīng)當(dāng)給出風(fēng)險減緩措施，并指定責(zé)任人。風(fēng)險系數(shù)越高，越先處理。[Step4]風(fēng)險跟蹤項目經(jīng)理跟蹤風(fēng)險減緩過程，直到風(fēng)險已經(jīng)解決為止。如果風(fēng)險的性質(zhì)發(fā)生變化，應(yīng)當(dāng)及時更新風(fēng)險減緩措施2.6輸出《風(fēng)險管理報告》2.7結(jié)束準則所有風(fēng)險都已經(jīng)解決，相關(guān)信息已經(jīng)記錄到《風(fēng)險管理報告》之中。2.8度量項目經(jīng)理統(tǒng)計工作量。3補充對風(fēng)險管理過程域產(chǎn)生的所有有價值的文檔進行配置管理。項目經(jīng)理根據(jù)本項目的特征，確定風(fēng)險識別的頻度（通常為每周一次），適當(dāng)修改“風(fēng)險檢查表”[SPP-TEMP-RISKM-CHECKLIST]。選用合適的軟件工具，盡量減少風(fēng)險管理過程域的工作量。

六、需求管理需求管理（RequirementManagement,RM）的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更。SCRUM開發(fā)過程中常常會出現(xiàn)需求的變更，SCRUMMaster和SCRUMOwner需要在每次Sprint結(jié)束的時候重新評估需求的變更對項目/產(chǎn)品的計劃的影響，內(nèi)容包括：交付期限的影響資源配備的影響其他商務(wù)目標的影響在影響已經(jīng)超過可控范圍的時候需要啟動需求變更[RM-CHANGE]過程。本規(guī)范闡述了需求管理過程域的三個主要規(guī)程：需求確認[PASS-PROC-RM-VALIDATE]需求跟蹤[PASS-PROC-RM-TRACKING]需求變更控制[PASS-PROC-RM-CHANGE]上述每個規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。1介紹我們把所有與需求相關(guān)的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬于需求開發(fā)，另一類屬于需求管理。圖6-1為需求工程的結(jié)構(gòu)圖。需求工程需求開發(fā)需求變更控制需求管理需求確認需求跟蹤需求調(diào)查需求分析需求定義圖6-1需求工程結(jié)構(gòu)圖需求管理過程域主要有3個規(guī)程：需求確認、需求跟蹤與需求變更控制。需求確認需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。需求跟蹤需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。需求變更控制需求變更控制是指依據(jù)“變更申請－審批－更改－重新確認”的流程處理需求的變更，確保需求的變更不會失去控制而導(dǎo)致項目發(fā)生混亂。需求管理過程域產(chǎn)生的主要文檔有：《需求評審報告》，同技術(shù)評審報告的模板[SPP-TEMP-TR-REPORT]?！缎枨蟾檲蟾妗?，模板見[SPP-TEMP-RM-TRACKING]。《需求變更控制報告》，模板見[SPP-TEMP-RM-CHANGE]。2需求確認2.1目的開發(fā)方和客戶對需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》進行評審，并作書面承諾。補充說明：《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》可以分開也可以放在一起進行需求確認，視項目的具體情況而定。2.2角色與職責(zé)開發(fā)方和客戶共同組織人員對需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》進行評審。開發(fā)方負責(zé)人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。2.3啟動準則需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》已經(jīng)完成。2.4輸入需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》。2.5主要步驟[Step1]非正式需求評審項目經(jīng)理先在項目內(nèi)部組織人員進行非正式的需求評審，以消除明顯的錯誤和分歧。非正式的需求評審方式請參考技術(shù)評審過程域的對應(yīng)規(guī)程[SPP-PROC-TR-ITR。][Step2]正式需求評審項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。正式需求評審方式請參考技術(shù)評審過程域的對應(yīng)規(guī)程[SPP-PROC-TR-FTR。][Step3]獲取需求承諾當(dāng)需求文檔通過正式的評審之后，開發(fā)方負責(zé)人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。示例如下：本需求文檔建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進度等。甲方負責(zé)人簽字乙方負責(zé)人簽字2.6輸出《需求評審報告》書面的需求承諾2.7結(jié)束準則需求文檔通過了正式評審，并且獲得開發(fā)方和客戶的書面承諾。2.8度量項目經(jīng)理統(tǒng)計工作量和上述文檔的規(guī)模3需求跟蹤3.1目的將系統(tǒng)設(shè)計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文檔－設(shè)計文檔－代碼－測試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。3.2角色與職責(zé)項目經(jīng)理跟蹤需求。3.3啟動準則需求文檔已經(jīng)通過正式評審并獲得了承諾。系統(tǒng)設(shè)計、編程、測試等階段的工作成果如設(shè)計文檔、代碼、測試用例已經(jīng)產(chǎn)生。3.4輸入需求文檔設(shè)計文檔、代碼、測試用例等3.5主要步驟[Step1]建立與維護需求跟蹤矩陣正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點。逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單元之間的可能存在“一對一”、“一對多”或“多對多”的關(guān)系。由于對應(yīng)關(guān)系比較復(fù)雜，最好在表格中加必要的文字解釋。表8-1為簡單的需求跟蹤矩陣格式。當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。＃＃需求文檔（版本，日期）設(shè)計文檔（版本，日期）代碼（版本，日期）測試用例（版本，日期）1標題或標識符，說明標題或標識符，說明代碼名稱，說明測試用例名稱，說明2…………表8-1簡單的需求跟蹤矩陣格式[Step2]查找不一致使用需求跟蹤矩陣的優(yōu)點是很容易發(fā)現(xiàn)需求文檔與后續(xù)工作成果之間的不一致之處，例如：后續(xù)工作成果沒有實現(xiàn)需求文檔中的某些需求；后續(xù)工作成果實現(xiàn)了需求文檔中的不存在的需求；后續(xù)工作成果沒有正確實現(xiàn)需求文檔中的的需求；項目經(jīng)理將發(fā)現(xiàn)的“不一致性”記錄在《需求跟蹤報告》之中，并通報給相關(guān)責(zé)任人（工作成果的開發(fā)者）。[Step3]消除不一致相關(guān)責(zé)任人給出消除“不一致”的措施和計劃，項目經(jīng)理將該措施和計劃記錄到《需求跟蹤報告》之中。相關(guān)責(zé)任人消除“不一致性”之后，項目經(jīng)理更新“需求跟蹤矩陣”。3.6輸出《需求跟蹤報告》3.7結(jié)束準則每個開發(fā)階段的“需求跟蹤矩陣”都已經(jīng)建立。已經(jīng)消除了需求文檔與后續(xù)工作成果之間的不一致性。3.8度量項目經(jīng)理統(tǒng)計工作量和上述文檔的規(guī)模。4需求變更控制4.1目的修改“原需求文檔”中不正確的內(nèi)容，產(chǎn)生新的需求文檔?？刂菩枨笪臋n的變更，防止發(fā)生混亂。補充說明：本規(guī)程中的“原需求文檔”是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。4.2角色與職責(zé)開發(fā)方負責(zé)人（項目經(jīng)理）和客戶共同控制需求變更。4.3啟動準則某人（來自開發(fā)方或客戶方）提出變更“原需求文檔”的申請。4.4輸入“原需求文檔”4.5主要步驟[Step1]需求變更申請需求變更申請人撰寫“需求變更申請書”，遞交給項目經(jīng)理或客戶方負責(zé)人?！靶枨笞兏暾垥北仨氷U述：（1）變更原因；（2）變更的內(nèi)容；（3）此變更對項目造成的影響。[Step2]審批需求變更申請開發(fā)方負責(zé)人（項目經(jīng)理）和客戶共同審批“需求變更申請書”：如果任何一方不同意變更，則退回變更請求，項目按照“原需求文檔”執(zhí)行。如果雙方都同意變更，轉(zhuǎn)向[Step3]。[Step3]更改需求文檔需求分析員根據(jù)[Step1]和[Step2]更改“原需求文檔”，產(chǎn)生新的需求文檔。[Step4]重新進行需求確認重新進行需求評審，參見需求確認規(guī)程中的[Step2]。重新獲取書面的需求承諾，參見需求確認規(guī)程中的[Step3]。4.6輸出《需求變更控制報告》4.7結(jié)束準則新的需求文檔已經(jīng)被確認。4.8度量項目經(jīng)理統(tǒng)計工作量。5補充先對項目經(jīng)理和客戶進行培訓(xùn)，讓他們掌握必要的需求管理知識。對需求管理過程域產(chǎn)生的所有有價值的文檔進行配置管理。對于非合同項目，本規(guī)范中有關(guān)客戶的活動可以被裁減掉。第三篇技術(shù)實現(xiàn)過程一、技術(shù)預(yù)研技術(shù)預(yù)研（TechnicalPre-Research,TPR）是指在立項之后到開發(fā)工作完成之前的時間內(nèi)，對項目將采用的關(guān)鍵技術(shù)提前學(xué)習(xí)和研究，以便盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙。技術(shù)預(yù)研過程域是SPP模型的重要組成部分。本規(guī)范闡述了技術(shù)預(yù)研的規(guī)程，該規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。本規(guī)范適用于國內(nèi)IT企業(yè)的軟件研發(fā)項目。建議用戶根據(jù)自身情況（如商業(yè)目標、研發(fā)實力等）適當(dāng)?shù)匦薷谋疽?guī)范，然后推廣使用。1介紹在產(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ù)研的流程如圖所示。制定計劃撰寫預(yù)研報告工作成果介紹技術(shù)評審…開展技術(shù)預(yù)研圖7-1技術(shù)預(yù)研流程技術(shù)預(yù)研過程中產(chǎn)生的主要文檔有：《技術(shù)預(yù)研計劃》，模板見[SPP-TEMP-TPR-PLAN]?！都夹g(shù)預(yù)研報告》，模板見[SPP-TEMP-TPR-REPORT]。2技術(shù)預(yù)研規(guī)程2.1目的提前發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙。2.2角色與職責(zé)項目經(jīng)理或技術(shù)負責(zé)人識別項目中的技術(shù)難題，指定技術(shù)預(yù)研人員攻克該問題。2.3啟動準則項目中的技術(shù)難題已經(jīng)識別。技術(shù)預(yù)研人員已經(jīng)指定。2.4輸入一些用戶需求文檔和技術(shù)方案文檔2.5主要步驟[Step1]制定計劃技術(shù)預(yù)研人員制定《技術(shù)預(yù)研計劃》，主要內(nèi)容包括：確定技術(shù)預(yù)研的內(nèi)容和目標。確定應(yīng)遞交的工作成果。分配任務(wù)，制定進度表。項目經(jīng)理或技術(shù)負責(zé)人審批該計劃，如果該計劃被批準，則轉(zhuǎn)向[Step2]。[Step2]開展技術(shù)預(yù)研技術(shù)預(yù)研人員按照計劃開展技術(shù)預(yù)研工作。[Step3]撰寫技術(shù)預(yù)研報告在預(yù)研任務(wù)結(jié)束時，技術(shù)預(yù)研人員撰寫《技術(shù)預(yù)研報告》。[后續(xù)活動]技術(shù)預(yù)研人員向相關(guān)人員介紹工作成果。項目經(jīng)理或技術(shù)負責(zé)人視具體情況決定是否對該預(yù)研成果進行技術(shù)評審。2.6輸出《技術(shù)預(yù)研報告》2.7結(jié)束準則指定的預(yù)研任務(wù)已經(jīng)完成，《技術(shù)預(yù)研報告》已經(jīng)產(chǎn)生。2.8度量技術(shù)預(yù)研人員統(tǒng)計工作量和工作成果的規(guī)模，匯報給項目經(jīng)理。3補充技術(shù)預(yù)研不同于真正地開發(fā)產(chǎn)品，投入人員與時間相對比較少。一個項目可以有多次技術(shù)預(yù)研，由項目經(jīng)理或技術(shù)負責(zé)人視具體情況而定。對技術(shù)預(yù)研過程中產(chǎn)生的所有有價值的文檔進行配置管理。

二、SCRUM過程1介紹Scrum是一個敏捷開發(fā)框架，是一個增量迭代的開發(fā)過程.。在這個框架整個開發(fā)周期由若干個小的跌代周期，每個小的的跌代周期稱為一個Sprint，每個Sprint的長度2到4周。在每個Sprint中，Scrum的開發(fā)團隊拿到一個排列好優(yōu)先級的需求列表，我們稱它為用戶故事或者叫Sprintbacklog，所以我們先開發(fā)的是對客戶具有較高價值的需求。在每個迭代結(jié)束后，都會開發(fā)完成可交付的產(chǎn)品?？蚣苋鐖D所示：SCRUM實現(xiàn)包括以下三個規(guī)程體系結(jié)構(gòu)設(shè)計Sprint迭代項目按照計劃可劃分為幾個ScrumTeam。每個Sprint周期控制在3到5天之內(nèi)。鞏固和提交2體系結(jié)構(gòu)設(shè)計2.1目的將Backlogs按照優(yōu)先級制成列表，根據(jù)該表制定軟件交付基線。建立軟件體系結(jié)構(gòu)，將Backlog項按高內(nèi)聚，低耦合的原則劃分為一系列的問題包，成立數(shù)個ScrumTeam，為ScrumTeam分配問題包。建立開發(fā)環(huán)境。2.2角色與職責(zé)項目組由全職開發(fā)人員及與該交付產(chǎn)品有關(guān)的市場人員、銷售人員、用戶等組成。設(shè)以下小組：確定系統(tǒng)開發(fā)、測試、運行所需的軟硬件環(huán)境。[Step5]撰寫體系結(jié)構(gòu)設(shè)計文檔體系結(jié)構(gòu)設(shè)計人員根據(jù)指定的模板撰寫《體系結(jié)構(gòu)設(shè)計報告》，主要內(nèi)容包括：軟件系統(tǒng)概述影響設(shè)計的約束因素設(shè)計策略系統(tǒng)總體結(jié)構(gòu)子系統(tǒng)的結(jié)構(gòu)與模塊功能開發(fā)、測試、運行所需的軟硬件環(huán)境[Step6]體系結(jié)構(gòu)設(shè)計評審體系結(jié)構(gòu)評審的重點不是“對還是錯”，而是“好還是差”。主要評審要素包括：合適性?？疾煸擉w系結(jié)構(gòu)是否適合于產(chǎn)品需求，是否可在預(yù)定計劃內(nèi)實現(xiàn)。系統(tǒng)的綜合能力（Capability）。例如“時－空”效率（性能，容量等），可擴展性，可管理性（可維護性），可復(fù)用性，安全性等等，視產(chǎn)品特征而定。2.6輸出《體系結(jié)構(gòu)設(shè)計報告》Backlog列表2.7結(jié)束準則軟件體系結(jié)構(gòu)建立，2.8度量項目經(jīng)理根據(jù)人員統(tǒng)計工作量和工作成果的規(guī)模3Sprint過程規(guī)程3.1目的該過程由若干個迭代的沖刺(Sprint)活動組成，直至風(fēng)險評估認為產(chǎn)品可交付為止。一個Sprint是在限定時間段內(nèi)（Sprint周期，通常為1~6周，可在前一個Sprint結(jié)束時調(diào)整）的一系列開發(fā)活動（包括分析、設(shè)計、編碼、測試等），每個SCRUM小組并行開發(fā)且必須步調(diào)一致（在一個Sprint結(jié)束后，均須完成所分配的Backlog項并有可執(zhí)行的產(chǎn)出）。每個Sprint包含以下活動：開發(fā)。對分配的Backlog工作進行分析，將所需改動（changes）映射到各packets，打開packets,進行領(lǐng)域分析，然后設(shè)計、開發(fā)、實施、測試、文檔化這些改動。打包(Wrap)。封裝packets,產(chǎn)生一個滿足Backlog需求的可執(zhí)行版本。評審（Review）。所有的SCRUM小組一起開會，提交各自的工作并演示(Demo)，然后提出和解決問題(Issue及難點（) problem）,增加新的Backlog項；發(fā)布、審查或調(diào)整產(chǎn)品的標準規(guī)范；進行風(fēng)險評估并提出合適的對策；確定下一個Sprint的工作內(nèi)容和結(jié)束時間。調(diào)整（Adjust）。根據(jù)評審會匯集的信息，對受影響的Packets進行適當(dāng)調(diào)整和鞏固。3.2角色與職責(zé)項目管理組。由產(chǎn)品經(jīng)理領(lǐng)銜，包括總設(shè)計師，各SCRUM小組組長，市場、銷售的高級職員及典型用戶等。若干個SCRUM小組。各小組由組長（SCRUMMaster）領(lǐng)銜。每個小組都是跨專業(yè)的（通常包括開發(fā)人員，文檔人員，質(zhì)量控制人員或用戶代表等），通常為3~7人，以使小組內(nèi)有充分的交流。小組的劃分最好是功能導(dǎo)向的（按所分配的問題包或Backlog），也可是系統(tǒng)層次導(dǎo)向（按體系結(jié)構(gòu)中的分層）。3.3啟動準則《體系結(jié)構(gòu)設(shè)計報告》建立3.4輸入需求文檔如《產(chǎn)品需求規(guī)格說明書》等作為原始PBL3.5主要步驟[Step1]開發(fā)。對分配的Backlog工作進行分析，將所需改動（changes）映射到各packets，打開packets,進行領(lǐng)域分析，然后設(shè)計、開發(fā)、實施、測試、文檔化這些改動。[Step2]打包(Wrap)。封裝packets,產(chǎn)生一個滿足Backlog需求的可執(zhí)行版本。[Step3]評審（Review）。所有的SCRUM小組一起開會，提交各自的工作并演示(Demo)，然后提出和解決問題(Issue及難點（)problem）,增加新的Backlog項；發(fā)布、審查或調(diào)整產(chǎn)品的標準規(guī)范；進行風(fēng)險評估并提出合適的對策；確定下一個Sprint的工作內(nèi)容和結(jié)束時間。[Step4]調(diào)整（Adjust）。根據(jù)評審會匯集的信息，對受影響的Packets進行適當(dāng)調(diào)整和鞏固。3.6輸出軟件產(chǎn)品（Artifact）3.7結(jié)束準則產(chǎn)品可交付為止3.8度量Scrum主管根據(jù)人員統(tǒng)計工作量和工作成果的規(guī)模，匯報給項目經(jīng)理4交付和鞏固4.1目的一旦根據(jù)風(fēng)險評估結(jié)果認為可交付產(chǎn)品時，即進入該階段。該階段的活動包括：組裝，系統(tǒng)測試和回歸測試（Regression），準備培訓(xùn)材料，完成最終文檔。SCRUM過程認為一個產(chǎn)品的開發(fā)將一直持續(xù)下去，除非經(jīng)風(fēng)險評估后認為應(yīng)停止。產(chǎn)品交付后的鞏固活動類似于傳統(tǒng)方法中的維護和改善，目的在于整理Sprint期壓力下忽略的工作，為下一階段的開發(fā)做準備，以便輕裝上陣。4.2角色與職責(zé)4.3啟動準則根據(jù)風(fēng)險評估結(jié)果認為可交付產(chǎn)品時，即進入該階段。4.4輸入需求文檔如《產(chǎn)品需求規(guī)格說明書》等作為原始PBL4.5主要步驟[Step1]制定系統(tǒng)測試計劃系統(tǒng)測試小組各成員共同協(xié)商測試計劃。測試組長按照指定的模板起草《系統(tǒng)測試計劃》。該計劃主要包括：測試范圍（內(nèi)容）測試方法測試環(huán)境與輔助工具測試完成準則人員與任務(wù)表項目經(jīng)理審批《系統(tǒng)測試計劃》。該計劃被批準后，轉(zhuǎn)向[Step2]。[Step2]設(shè)計系統(tǒng)測試用例系統(tǒng)測試小組各成員依據(jù)《系統(tǒng)測試計劃》和指定的模板，設(shè)計（撰寫）《系統(tǒng)測試用例》。測試組長邀請開發(fā)人員和同行專家，對《系統(tǒng)測試用例》進行技術(shù)評審。該測試用例通過技術(shù)評審后，轉(zhuǎn)向[Step3]。[Step3]執(zhí)行系統(tǒng)測試系統(tǒng)測試小組各成員依據(jù)《系統(tǒng)測試計劃》和《系統(tǒng)測試用例》執(zhí)行系統(tǒng)測試。將測試結(jié)果記錄在《系統(tǒng)測試報告》中，用“缺陷管理工具”來管理所發(fā)現(xiàn)的缺陷，并及時通報給開發(fā)人員。[Step4]缺陷管理與改錯從[Step1]至[Step3]，任何人發(fā)現(xiàn)軟件系統(tǒng)中的缺陷時都必須使用指定的“缺陷管理工具”。該工具將記錄所有缺陷的狀態(tài)信息，并可以自動產(chǎn)生《缺陷管理報告》。開發(fā)人員及時消除已經(jīng)發(fā)現(xiàn)的缺陷。開發(fā)人員消除缺陷之后應(yīng)當(dāng)馬上進行回歸測試，以確保不會引入新的缺陷。[Step7]測試報告編制[Step6]操作文檔編制4.6輸出軟件產(chǎn)品（Artifact）《用戶操作文檔》《測試報告》4.7結(jié)束準則完成最終文檔 三、用戶驗收客戶驗收（CustomerAcceptance,CA）是指客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。本規(guī)范闡述了客戶驗收的規(guī)程，該規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。1介紹客戶對產(chǎn)品的驗收主要有兩種方式：成果審查。驗收人員審查開發(fā)方應(yīng)當(dāng)交付的成果，如代碼、文檔等等。確保這些成果是完整的并且是正確的。驗收測試。驗收人員對待交付的產(chǎn)品進行全面的測試，確保產(chǎn)品功能、質(zhì)量符合需求。驗收測試的內(nèi)容、方法與系統(tǒng)測試幾乎是相同的。兩者主要區(qū)別在于執(zhí)行人員不同。驗收測試人員來自于客戶方，而系統(tǒng)測試人員則來自于開發(fā)方?？蛻趄炇樟鞒倘鐖D15-1所示。驗收準備問題處理成果審查與驗收測試交付與簽字圖15-1客戶驗收流程客戶驗收過程域產(chǎn)生的主要文檔有：《客戶驗收計劃》，模板見[SPP-TEMP-CA-PLAN]。《驗收測試用例》，模板見[SPP-TEMP-TEST-CASE]。《客戶驗收報告》，模板見[SPP-TEMP-CA-REPORT]。補充說明：“客戶驗收”是針對合同項目而言的，對于非合同項目，請參見Beta測試[SPP-PROC-BETA]。2客戶驗收規(guī)程2.1目的客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。2.2角色與職責(zé)客戶方組建一個驗收小組，并指定驗收負責(zé)人。開發(fā)方的項目經(jīng)理和其他成員為客戶驗收工作提供協(xié)助。開發(fā)方應(yīng)當(dāng)及時解決客戶方發(fā)現(xiàn)的問題。2.3啟動準則系統(tǒng)測試已經(jīng)完成。開發(fā)方對客戶進行了必要的培訓(xùn)，參見培訓(xùn)管理規(guī)范[SPP-PROC-TM]。2.4輸入產(chǎn)品需求文檔需求變更記錄產(chǎn)品使用指南有關(guān)合同2.5主要步驟[Step1]驗收準備開發(fā)方和客戶方共同制定《客戶驗收計劃》，主要包括“成果審查計劃”和“驗收測試計劃”。雙方的負責(zé)人審批該計劃。開發(fā)方和客戶方共同設(shè)計“驗收測試用例”。開發(fā)方將待驗收的工作成果準備好，并將必要的材料提前交給驗收小組。[Step2]成果審查與驗收測試成果審查。驗收人員根據(jù)計劃審查開發(fā)方應(yīng)當(dāng)交付的成果，如代碼、文檔等等。確保這些成果是完整的并且是正確的。驗收人員將審查結(jié)果記錄在《客戶驗收報告》之中。驗收測試。驗收人員依據(jù)計劃和測試用例，對待交付的產(chǎn)品進行全面的測試，確保產(chǎn)品符合需求。驗收人員將測試結(jié)果記錄在《客戶驗收報告》之中。[Step3]問題處理如果驗收人員在審查與測試時發(fā)現(xiàn)工作成果存在問題，則開發(fā)方應(yīng)當(dāng)視問題的嚴重性與客戶協(xié)商，給出合適的處理措施。如果工作成果存在嚴重的缺陷，則退回給開發(fā)方。開發(fā)方應(yīng)當(dāng)給出糾正缺陷的措施，雙方協(xié)商第二次驗收的時間。如果給客戶方帶來損失，應(yīng)當(dāng)依據(jù)合同對開發(fā)方作出相應(yīng)的處罰。如果工作成果存在一些輕微的缺陷，則開發(fā)方應(yīng)當(dāng)給出糾正缺陷的措施，雙方協(xié)商是否需要第二次驗收。[Step4]交付與簽字當(dāng)待驗收的所有工作成果都通過了審查和測試后，開發(fā)方將其交付給客戶方。雙方的責(zé)任人簽字認可。2.6輸出《客戶驗收報告》2.7結(jié)束準則所有應(yīng)交付的工作成果都已經(jīng)通過了客戶方的審查與驗收?！犊蛻趄炇請蟾妗芬呀?jīng)產(chǎn)生，雙方的責(zé)任人已經(jīng)簽字認可。2.8度量項目經(jīng)理統(tǒng)計客戶驗收期間雙方投入的工作量。3實施建議在客戶驗收之前，開發(fā)方對驗收人員進行必要的產(chǎn)品培訓(xùn)。開發(fā)方可以將系統(tǒng)測試用例給驗收人員參考，以減少設(shè)計測試用例的時間。開發(fā)方人員應(yīng)當(dāng)熱情地協(xié)助驗收人員。對驗收人員發(fā)現(xiàn)的軟件缺陷馬上予以糾正；對于復(fù)雜的問題應(yīng)當(dāng)立即請示有關(guān)領(lǐng)導(dǎo)，不可拖延。在驗收期間不可與客戶爭吵，給客戶留下很好的印象。對驗收過程中產(chǎn)生的所有有價值的文檔進行配置管理 四、技術(shù)評審技術(shù)評審（TechnicalReview,TR）的目的是盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而有效地提高產(chǎn)品的質(zhì)量。本規(guī)范闡述了技術(shù)評審過程域的兩個主要規(guī)程：制定技術(shù)評審計劃[TR-PLANNING]技術(shù)評審[TR-FTR]上述每個規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。1介紹技術(shù)評審最初是由IBM公司為了提高軟件質(zhì)量和提高程序員生產(chǎn)率而倡導(dǎo)的。技術(shù)評審方法已經(jīng)被業(yè)界廣泛采用并收到了很好的效果，它被普遍認為是軟件開發(fā)的最佳實踐之一。技術(shù)評審能夠在任何開發(fā)階段執(zhí)行，它可以比測試更早地發(fā)現(xiàn)并消除工作成果中的缺陷。技術(shù)評審的主要好處有：通過消除工作成果的缺陷而提高產(chǎn)品的質(zhì)量。越早消除缺陷就越能降低開發(fā)成本。開發(fā)人員能夠及時地得到同行專家的幫助和指導(dǎo)，無疑會加深對工作成果的理解，更好地預(yù)防缺陷，一定程度上提高了開發(fā)生產(chǎn)率?？梢娂夹g(shù)評審有助于“提高質(zhì)量、提高生產(chǎn)率、降低成本”，符合軟件過程改進的根本目的。理論上講，為了確保產(chǎn)品的質(zhì)量，產(chǎn)品的所有工作成果都應(yīng)當(dāng)接受技術(shù)評審?，F(xiàn)實中，為了節(jié)約時間，允許人們有選擇地對工作成果進行技術(shù)評審。技術(shù)評審方式也視工作成果的重要性和復(fù)雜性而定。技術(shù)評審過程域有兩個主要規(guī)程：“制定技術(shù)評審計劃”、“技術(shù)評審”，如圖1所示。制定技術(shù)評審計劃正規(guī)技術(shù)評審圖1技術(shù)評審過程域示意圖技術(shù)評審的注意事項：評審人員的職責(zé)是發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員給出消除缺陷的辦法，而不是替開發(fā)人員消除缺陷。技術(shù)評審應(yīng)當(dāng)“就事論事”，不要打擊有失誤的開發(fā)人員的工作積極性，更不準搞人身攻擊（如挖苦、諷刺等）。在會議評審期間要限制過多的爭論，以免浪費他人的時間。技術(shù)評審過程域產(chǎn)生的主要文檔有：整個項目的《技術(shù)評審計劃》，模板見[SPP-TEMP-TR-PLAN]?！都夹g(shù)評審報告》，模板見[SPP-TEMP-TR-REPORT]。常用的《技術(shù)評審檢查表》見[SPP-TEMP-TR-CHECKLIST。]2制定技術(shù)評審計劃2.1目的確定需要評審的工作成果、評審方式，預(yù)定評審時間、地點以及相關(guān)人員。2.2角色與職責(zé)項目的技術(shù)負責(zé)人（或技術(shù)骨干）制定《技術(shù)評審計劃》。項目經(jīng)理審批《技術(shù)評審計劃》。2.3啟動準則《項目計劃》已經(jīng)制定。2.4輸入《項目計劃》2.5主要步驟[Step1]確定需要評審的工作成果如果項目的時間充足，為了確保產(chǎn)品的質(zhì)量，應(yīng)當(dāng)對產(chǎn)品的所有工作成果都進行技術(shù)評審。如果項目的時間不充足，為了節(jié)約時間，可以選擇一些重要的工作成果對其進行技術(shù)評審。[Step2]確定技術(shù)評審方式根據(jù)工作成果的重要性和復(fù)雜性確定技術(shù)評審方式。將重要性、復(fù)雜性各分“高、中、低”3個等級。重要性－復(fù)雜性組合與技術(shù)評審方式的對應(yīng)關(guān)系見下表。重要性－復(fù)雜性組重要性－復(fù)雜性組合技術(shù)評審方式（FTR,ITR）高高FTR高中FTR高低FTR或者ITR均可中中FTR或者ITR均可中低中低ITR低低ITR表2重要性－復(fù)雜性組合與技術(shù)評審方式的對應(yīng)關(guān)系[Step3]預(yù)定評審時間、地點以及相關(guān)人員根據(jù)《項目計劃》中的進度表，預(yù)定評審時間和地點。根據(jù)工作成果的特征預(yù)定評審主持人和其他評審員。[Step4]審批計劃項目經(jīng)理根據(jù)《項目計劃》以及現(xiàn)實情況（如可以支配的人力資源），審批《技術(shù)評審計劃》。項目的技術(shù)負責(zé)人（或技術(shù)骨干）應(yīng)根據(jù)項目經(jīng)理的批示修正《技術(shù)評審計劃》。2.6輸出《技術(shù)評審計劃》2.7結(jié)束準則《技術(shù)評審計劃》已經(jīng)制定并被項目經(jīng)理批準。2.8度量技術(shù)負責(zé)人（或技術(shù)骨干）統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經(jīng)理。3技術(shù)評審3.1目的對工作成果進行正式技術(shù)評審，盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷。3.2角色與職責(zé)作者：是指待評審的工作成果的開發(fā)者，可能是一個人也可能是個小組。在評審會議期間，作者答復(fù)評審小組的問題，并與評審小組共同查找缺陷、商討缺陷解決方案。評審會議結(jié)束后，作者應(yīng)當(dāng)及時消除工作成果中的缺陷。評審小組評審主持人是應(yīng)當(dāng)具備比較高的技術(shù)水平和比較豐富的評審經(jīng)驗，能夠控制評審會議的進程。評審主持人可以是項目內(nèi)的技術(shù)骨干也可以是項目外的技術(shù)專家。評審主持人本身是一名評審員，評審結(jié)論必須有評審主持人的簽字才能生效。評審員主要來源于項目內(nèi)和項目外的技術(shù)人員，必要時還應(yīng)當(dāng)邀請客戶和質(zhì)量保證人員擔(dān)任評審員。工作成果的作者不能擔(dān)任評審員。評審員的人選以及分工都由評審主持人來確定。評審員應(yīng)當(dāng)根據(jù)“檢查表”認真地查找工作成果中的缺陷，并和作者共同商討缺陷解決方案。評審小組的總?cè)藬?shù)一般在3～7人之間。記錄員：由評審主持人指定一位評審員來擔(dān)任記錄員。記錄員如實地將評審過程記錄在指定的文檔中。3.3啟動準則作者已經(jīng)按照指定的格式（如模板）完成了工作成果，對工作成果進行了內(nèi)部檢查，消除了拼寫、排版等初級錯誤。根據(jù)《技術(shù)評審計劃》，該工作成果進行正式技術(shù)評審的時間已到。3.4輸入待評審的工作成果。與該工作成果評審相關(guān)的一些材料，如檢查表。3.5主要步驟技術(shù)評審的流程如圖16-2所示。Step3.修正跟蹤審核Step2.舉行評審會議Step1.準備評審2.1主持人宣講2.2作者介紹工作成果2.3識別缺陷和答辯2.4討論缺陷解決方案2.5會議結(jié)束決議3.1修正與跟蹤3.2遞交審核3.3審核工作成果圖16-2技術(shù)評審的流程圖[Step1]準備評審評審主持人首先確定評審會議的時間、地點、設(shè)備和參加會議的人員名單（包括評審員、記錄員、作者、旁聽者等），然后起草《技術(shù)評審?fù)ㄖ罚⒏嬷邢嚓P(guān)人員。評審主持人把工作成果及相關(guān)材料、技術(shù)評審規(guī)程、檢查表等發(fā)給評審員。評審員閱讀（了解）工作成果及相關(guān)材料。[Step2]舉行評審會議[Step2.1]主持人宣講主持人宣講本次評審會議的議程、重點、原則、時間限制等。[Step2.2]作者介紹工作成果作者扼要地介紹工作成果。[Step2.3]識別缺陷和答辯評審員根據(jù)“檢查表”認真查找工作成果的缺陷。作者回答評審員的問題，雙方要對每個缺陷達成共識（避免誤解）。[Step2.4]討論缺陷解決方案作者和評審員共同討論缺陷的解決方案。對于當(dāng)場難以解決的問題，由主持人決定“是否有必要繼續(xù)討論”或者“另定時間再討論”。[Step2.5]會議結(jié)束決議評審小組給出評審結(jié)論和意見，主持人簽字后本次會議結(jié)束。評審結(jié)論有三種：工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。工作成果基本合格，需要作少量的修改，之后通過審核即可。工作成果不合格，需要作比較大的修改，之后必須重新對其評審。[Step3]修正、跟蹤與審核[Step3.1]修正與跟蹤作者修正工作成果，消除已發(fā)現(xiàn)的缺陷。評審主持人（或者指定審查員）跟蹤每個缺陷的狀態(tài)。[Step3.2]提交審核作者消除所有已發(fā)現(xiàn)的缺陷后，再將修正后的工作成果遞交給評審主持人（或者指定審查員）審核。[Step3.2]審核工作成果評審主持人（或者指定審查員）審核修正后的工作成果。審核結(jié)論有兩種：修正后的工作成果合格。修正后的工作成果仍然不合格，需重新修改，重復(fù)[Step3]。3.6輸出該工作成果的《技術(shù)評審報告》。根據(jù)評審報告修正后的工作成果。3.7結(jié)束準則工作成果中所有已識別的缺陷都已經(jīng)被消除。3.8度量評審主持人統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經(jīng)理。4實施建議對于重要性和復(fù)雜性都很高的工作成果，建議先在項目內(nèi)部進行“非正式技術(shù)評審”，然后再進行“正式技術(shù)評審”。技術(shù)評審應(yīng)當(dāng)與質(zhì)量保證有機地結(jié)合起來，請質(zhì)量保證人員參加并監(jiān)督正規(guī)技術(shù)評審是很好的方式。技術(shù)評審應(yīng)當(dāng)與配置管理有機地結(jié)合起來，規(guī)定沒有通過技術(shù)評審的工作成果不允許成為基準文件（Baselined）。建議機構(gòu)采用統(tǒng)一的缺陷跟蹤工具，使得技術(shù)評審所發(fā)現(xiàn)的缺陷能被及時地消除，不被遺漏。第四篇支撐過程一、配置管理配置管理（ConfigurationManagement,CM）的目的是通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件，來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。配置管理過程域是SPP模型的重要組成部分。本規(guī)范闡述了配置管理過程域的四個主要規(guī)程：制定配置管理計劃[PASS-PROC-CM-PLANNING]配置庫管理[PASS-PROC-CM-LIB]配置項版本控制[PASS-PROC-CM-VERSION]配置項變更控制[PASS-PROC-CM-CHANGE]上述每個規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。1介紹項目研發(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)品的組成部分，但是值得保存。每個配置項的主要屬性有：名稱、標識符、文件狀態(tài)、版本、作者、日期等。所有配置項都被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程?；€（Baseline）由一組配置項組成，這些配置項構(gòu)成了一個相對穩(wěn)定的邏輯實體?；€中的配置項被“凍結(jié)”了，不能再被任何人隨意修改（見變更控制規(guī)程）。基線通常對應(yīng)于開發(fā)過程中的里程碑（Milestone），一個產(chǎn)品可以有多個基線，也可以只有一個基線。基線的主要屬性有：名稱、標識符、版本、日期等。通常將交付給客戶的基線稱為一個“Release”，為內(nèi)部開發(fā)用的基線則稱為一個“Build”。所有的項目成員都要使用配置管理軟件來保護自己的工作成果。XX軟件采用Subversion作為配置管理工具。配置管理員為每個項目制定《配置管理計劃》，創(chuàng)建和維護配置庫。配置管理的流程如圖17-1所示。版本控制制定配置管理計劃配置庫管理變更控制配置審計圖17-1配置管理流程圖制定配置管理計劃配置管理員制定《配置管理計劃》，主要內(nèi)容包括配置管理軟硬件資源、配置項計劃、基線計劃、交付計劃、備份計劃等。CCB審批該計劃。配置庫管理配置管理員為項目創(chuàng)建配置庫，并給每個項目成員分配權(quán)限。各項目成員根據(jù)自己的權(quán)限操作配置庫。配置管理員定期維護配置庫，例如清楚垃圾文件、備份配置庫等。版本控制在項目開發(fā)過程中，絕大部分的配置項都要經(jīng)過多次的修改才能最終確定下來。對配置項的任何修改都將產(chǎn)生新的版本。由于我們不能保證新版本一定比老版本“好”，所以不能拋棄老版本。版本控制的目的是按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失或混淆等現(xiàn)象，并且可以快速準確地查找到配置項的任何版本。配置項的狀態(tài)有三種：“草稿”、“正式發(fā)布”和“正在修改”，本規(guī)程制定了配置項狀態(tài)變遷與版本號的規(guī)則。變更控制在項目開發(fā)過程中，配置項發(fā)生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導(dǎo)致混亂。修改處于“草稿”狀態(tài)的配置項不算是“變更”，無需CCB的批準，修改者按照版本控制規(guī)則執(zhí)行即可。當(dāng)配置項的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)”后，此時任何人都不能隨意修改，必須依據(jù)“申請－審批－執(zhí)行變更－再評審－結(jié)束”的規(guī)則執(zhí)行。配置審計為了保證所有人員（包括項目成員、配置管理員和CCB）都遵守配置管理規(guī)范，質(zhì)量保證人員要定期審計配置管理工作。配置審計是一種“過程質(zhì)量檢查”活動，是質(zhì)量保證人員的工作職責(zé)之一。請參考質(zhì)量保證規(guī)范SPP-PROC-QA，此處不再論述。配置管理過程域產(chǎn)生的主要文檔有：《配置管理計劃》，模板見[SPP-TEMP-CM-PLAN]?！杜渲脦旃芾韴蟾妗罚０逡奫SPP-TEMP-CM-LIB]。《配置項變更控制報告》，模板見[SPP-TEMP-CM-CHANGE]。2制定配置管理計劃2.1目的制定配置管理計劃，以便有計劃地開展配置管理工作。2.2角色與職責(zé)配置管理員制定《配置管理計劃》。CCB審批《配置管理計劃》。CCB的人數(shù)視項目的規(guī)模而定。通常CCB由項目經(jīng)理、資深項目成員等人組成，項目經(jīng)理為CCB負責(zé)人。CCB的決策采用“少數(shù)服從多數(shù)”原則。2.3啟動準則《項目計劃》已經(jīng)制定配置管理員和CCB已經(jīng)確定。2.4輸入《項目計劃》2.5主要步驟[Step1]確定配置管理的軟硬件資源[Step2]制定配置項計劃配置管理員識別項目的主要配置項。每個配置項都有唯一的標識符，標識符的參考格式為Project-Type…Type-Number。配置項計劃的參考格式如下：類型類型主要配置項標識符預(yù)計正式發(fā)布時間[Step3]制定基線計劃配置管理員確定每個基線的名稱（標識符）及其主要配置項，估計每個基線建立的時間?；€計劃的參考格式如下：基線名稱基線名稱/標識符基線所包含的主要配置項預(yù)計建立時間[Step4]制定配置庫備份計劃配置管理員制定配置庫備份計劃，指明“何人”在“何時”（頻度）將配置庫備份到“何處”。2.6輸出《配置管理計劃》2.7結(jié)束準則《配置管理計劃》已經(jīng)制定并被CCB的批準。2.8度量配置管理統(tǒng)計工作量以及文檔的規(guī)模，匯報給項目經(jīng)理。3配置庫管理3.1目的所有人員依照配置管理規(guī)范和《配置管理計劃》操作配置庫。3.2角色與職責(zé)配置管理創(chuàng)建并維護配置庫。項目成員在權(quán)限之內(nèi)操作配置庫。3.3啟動準則《配置管理計劃》已經(jīng)制定。配置管理的軟件硬件已經(jīng)存在。3.4輸入《配置管理計劃》3.5主要步驟[Step1]創(chuàng)建配置庫配置管理員創(chuàng)建配置庫，并且至少創(chuàng)建配置庫的所有第一級目錄。[Step2]分配權(quán)限配置管理員為每個項目成員分配操作權(quán)限。一般地，項目成員擁有Add,Checkin/Checkout,Download等權(quán)限，但是不能擁有“刪除”權(quán)限。配置管理員的權(quán)限最高。具體操作視所采用的配置管理軟件而定。[Step3]配置庫操作與管理項目成員根據(jù)自己的權(quán)限操作配置庫，例如Add,Checkin/Checkout,Download等。配置管理員根據(jù)“基線計劃”創(chuàng)建與維護基線，“凍結(jié)”配置項，控制變更。配置管理員定期清除配置庫里的垃圾文件。配置管理員定期備份配置庫。3.6輸出《配置庫管理報告》（由配置管理員撰寫）3.7結(jié)束準則對配置庫的操作與管理將持續(xù)到項目結(jié)束。3.8度量配置管理員統(tǒng)計工作量以及文檔規(guī)模。4版本控制4.1目的按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失或混淆等現(xiàn)象，并且可以快速準確地查找到配置項的任何版本。4.2角色與職責(zé)所有項目成員都必須遵照版本控制規(guī)程操作配置庫。5配置項狀態(tài)變遷規(guī)則配置項的狀態(tài)有三種：“草稿”（Draft）、“正式發(fā)布”（Released）和“正在修改”（Changing）。配置項狀態(tài)變遷如圖17-2所示。配置項剛建立時其狀態(tài)為“草稿”。配置項通過評審（或?qū)徟┖?，其狀態(tài)變?yōu)椤罢桨l(fā)布”。此后若更改配置項，必須依照“變更控制規(guī)程”執(zhí)行，其狀態(tài)變?yōu)椤罢谛薷摹?。?dāng)配置項修改完畢并重新通過評審（或?qū)徟r，其狀態(tài)又變?yōu)椤罢桨l(fā)布”，如此循環(huán)。變更控制正式發(fā)布正在修改自由修改草稿評審或?qū)徟駴Q通過圖17-2配置項狀態(tài)變遷圖6配置項版本號規(guī)則配置項的版本號與配置項的狀態(tài)緊密相關(guān)：處于“草稿”狀態(tài)的配置項的版本號格式為：0.YZYZ數(shù)字范圍為01-99。隨著草稿的不斷完善，“YZ”的取值應(yīng)遞增?！癥Z”的初值和增幅由用戶自己把握。處于“正式發(fā)布”狀態(tài)的配置項的版本號格式為：X.YX為主版本號，取值范圍為1-9。Y為次版本號，取值范圍為1-9。配置項第一次“正式發(fā)布”時，版本號為1.0。如果配置項的版本升級幅度比較小，一般只增大Y值，X值保持不變。只有當(dāng)配置項版本升級幅度比較大時，才允許增大X值。處于“正在修改”狀態(tài)的配置項的版本號格式為：X.YZ配置項正在修改時，一般只增大Z值，X.Y值保持不變。當(dāng)配置項修改完畢，狀態(tài)重新成為“正式發(fā)布”時，將Z值設(shè)置為0，增加X.Y值。參見規(guī)則（2）。7補充要求所有人員對其工作成果進行配置管理。對全員進行配置管理培訓(xùn)。由于配置庫里保存的是項目的所有工作成果，應(yīng)當(dāng)選擇“責(zé)任心強、可靠”的人員擔(dān)任配置管理員。 二、質(zhì)量保證質(zhì)量保證（QualityAssurance,QA）的目的是提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實現(xiàn)持續(xù)地改進質(zhì)量。質(zhì)量保證是一種有計劃的、貫穿于整個產(chǎn)品生命周期的質(zhì)量管理方法。本規(guī)范闡述了質(zhì)量保證過程域的三個主要規(guī)程：制定質(zhì)量保證計劃[PASS-PROC-QA-PLANNING]過程與產(chǎn)品質(zhì)量檢查[PASS-PROC-QA-PPQC]問題跟蹤與質(zhì)量改進[PASS-PROC-QA-TRACKING]上述每個規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。1介紹過程質(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ù)專家，他也能夠客觀地檢查和監(jiān)控產(chǎn)品的質(zhì)量。這是質(zhì)量保證方法富有成效的一面。但是“工作過程以及工作成果”符合既定的規(guī)范卻并不意味著產(chǎn)品的質(zhì)量一定合格，因為僅靠規(guī)范無法識別出產(chǎn)品中可能存在的大量缺陷。這是質(zhì)量保證方法的不足之處。所以單獨的“質(zhì)量保證”其實并不能“保證質(zhì)量”。技術(shù)評審與測試關(guān)注的是產(chǎn)品質(zhì)量而不是過程質(zhì)量，兩者的技術(shù)強度比質(zhì)量保證要高得多。技術(shù)評審和測試能彌補質(zhì)量保證的不足，三者是相輔相成的質(zhì)量管理方法。我們在實踐中不能將質(zhì)量保證、技術(shù)評審和測試混為一談，也不能把三者孤立起來執(zhí)行。讓質(zhì)量保證人員參加并監(jiān)督重要的技術(shù)評審和測試工作，這是很好的方法。把三者有機地結(jié)合起來，可提高工作效率，降低成本。質(zhì)量保證小組（QualityAssuranceGroup,QAG）有如下特點：質(zhì)量保證小組在行政上獨立于任何項目。這種獨立性有助于質(zhì)量保證小組客觀地檢查和監(jiān)控“過程以及產(chǎn)品的質(zhì)量”。質(zhì)量保證小組有一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。這種權(quán)利使得質(zhì)量保證小組的工作不會被輕視，并有助于加強全員的質(zhì)量意識。需要強調(diào)的是，提高產(chǎn)品質(zhì)量是全員的職責(zé)，并非只是質(zhì)量保證小組的職責(zé)。質(zhì)量保證過程域有3個主要規(guī)程：“制定質(zhì)量保證計劃”、“過程與產(chǎn)品質(zhì)量檢查”和“問題跟蹤與質(zhì)量改進”，如圖18-1所示。制定質(zhì)量保證計劃質(zhì)量保證小組為每個項目指定一名質(zhì)量保證員（即接口人）。質(zhì)量保證員撰寫《質(zhì)量保證計劃》，項目經(jīng)理和質(zhì)量經(jīng)理審批該計劃?！顿|(zhì)量保證計劃》的主要內(nèi)容是“過程與產(chǎn)品質(zhì)量檢查計劃”、“參與技術(shù)評審計劃”和“參與測試計劃”。過程與產(chǎn)品質(zhì)量檢查質(zhì)量保證員客觀地檢查項目成員的“工作過程”和“工作成果”是否符合既定的規(guī)范，并與項目成員協(xié)商改進措施。質(zhì)量保證員記錄本次檢查的結(jié)果和經(jīng)驗教訓(xùn)，并及時通報給所有相關(guān)人員。問題跟蹤與質(zhì)量改進質(zhì)量保證員設(shè)法先在項目內(nèi)部解決質(zhì)量問題，如果在項目內(nèi)部難以解決，則提交給上級領(lǐng)導(dǎo)處理。質(zhì)量保證小組分析機構(gòu)內(nèi)共性的質(zhì)量問題，給出質(zhì)量改進措施。制定質(zhì)量保證計劃過程與產(chǎn)品質(zhì)量檢查問題跟蹤與質(zhì)量改進周期性地開展技術(shù)評審測試表示質(zhì)量保證與技術(shù)評審、測試有機結(jié)合圖18-1質(zhì)量保證過程域示意圖質(zhì)量保證過程域產(chǎn)生的主要文檔有：《質(zhì)量保證計劃》，模板見[SPP-TEMP-QA-PLAN]?！顿|(zhì)量保證檢查表》，模板見[SPP-TEMP-QA-CHECKLIST]?！顿|(zhì)量保證報告》，模板見[SPP-TEMP-QA-REPORT]?！顿|(zhì)量問題跟蹤表》，模板見[SPP-TEMP-QA-TRACKING]。2制定質(zhì)量保證計劃2.1目的制定關(guān)于檢查和改進過程質(zhì)量、產(chǎn)品質(zhì)量的計劃。2.2角色與職責(zé)質(zhì)量保證小組為每個項目指定一名質(zhì)量保證員（即接口人）。項目的質(zhì)量保證員制定《質(zhì)量保證計劃》。項目經(jīng)理和質(zhì)量經(jīng)理（如果存在的話）審批《質(zhì)量保證計劃》。2.3啟動準則《項目計劃》已經(jīng)制定。該項目的質(zhì)量保證員已經(jīng)確定。2.4輸入《項目計劃》2.5主要步驟[Step1]制定過程與產(chǎn)品質(zhì)量檢查計劃質(zhì)量保證員根據(jù)本項目的特征，確定需要檢查的主要過程域和主要工作成果，并估計檢查時間和人員。注意，對某些過程域的檢查應(yīng)當(dāng)是周期性的而不是一次性的，例如配置管理、需求管理等。質(zhì)量保證員確定相應(yīng)的檢查表（模板見SPP-TEMP-QA-CHECKLIST）。[Step2]制定“參與技術(shù)評審”的計劃《技術(shù)評審計劃》一般由項目經(jīng)理或者項目的技術(shù)骨干制定。質(zhì)量保證員應(yīng)當(dāng)參與并監(jiān)督重要工作成果如需求、設(shè)計、代碼的技術(shù)評審。質(zhì)量保證員根據(jù)《技術(shù)評審計劃》，制定“參與技術(shù)評審”的計劃。[Step3]制定“參與測試”的計劃一般地，項目開發(fā)小組自己負責(zé)單元測試和集成測試，機構(gòu)獨立測試小組負責(zé)最終產(chǎn)品的測試（如系統(tǒng)測試和驗收測試）。由于測試的種類比較多，《測試計劃》也可能有多個。質(zhì)量保證員應(yīng)當(dāng)參與并監(jiān)督重要工作成果的測試。質(zhì)量保證員參考各種《測試計劃》，制定“參與測試”的計劃。[Step4]審批質(zhì)量保證計劃雖然質(zhì)量保證小組在行政上獨立于任何項目，但是質(zhì)量保證員的工作與項目緊密相關(guān)，所以《質(zhì)量保證計劃》應(yīng)當(dāng)經(jīng)過項目經(jīng)理的審批才能生效，以確?！顿|(zhì)量保證計劃》與《項目計劃》一致。如果機構(gòu)存在質(zhì)量經(jīng)理，那么質(zhì)量經(jīng)理也要審批《質(zhì)量保證計劃》，以確?！顿|(zhì)量保證計劃》符合機構(gòu)的要求（避免過于寬松而流于形式）。2.6輸出《質(zhì)量保證計劃》2.7結(jié)束準則《質(zhì)量保證計劃》已經(jīng)制定，項目經(jīng)理和質(zhì)量經(jīng)理（如果存在的話）批準該計劃。2.8度量質(zhì)量保證員統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經(jīng)理和質(zhì)量經(jīng)理。3過程與產(chǎn)品質(zhì)量檢查3.1目的客觀地檢查項目開發(fā)小組的“工作過程”和“工作成果”是否符合既定的規(guī)范。3.2角色與職責(zé)質(zhì)量保證員負責(zé)過程與產(chǎn)品質(zhì)量檢查。3.3啟動準則根據(jù)《質(zhì)量保證計劃》執(zhí)行質(zhì)量檢查。3.4輸入《質(zhì)量保證計劃》質(zhì)量保證檢查表3.5主要步驟[Step1]準備質(zhì)量保證員和項目經(jīng)理確定本次質(zhì)量檢查的時間、地點、參加人員等。[Step2]客觀地檢查過程質(zhì)量質(zhì)量保證員根據(jù)檢查表，和相關(guān)的項目成員交談，檢查項目的實際執(zhí)行過程（包括項目管理過程、項目研發(fā)過程、機構(gòu)支撐過程等）是否符合既定的規(guī)范。如果發(fā)現(xiàn)不一致，質(zhì)量保證員應(yīng)當(dāng)與相關(guān)人員分析原因并協(xié)商改進措施。[Step3]客觀地檢查工作成果的質(zhì)量質(zhì)量保證員根據(jù)檢查表，和相關(guān)的項目成員交談，檢查項目的工作成果是否符合既定的規(guī)范（一個產(chǎn)品包含很多工作成果）。如果發(fā)現(xiàn)不一致，質(zhì)量保證員應(yīng)當(dāng)與相關(guān)人員分析原因并協(xié)商改進措施。[Step4]記錄檢查結(jié)果質(zhì)量保證員如實記錄本次質(zhì)量檢查結(jié)果，并總結(jié)經(jīng)驗教訓(xùn)。該信息保存在《質(zhì)量保證工作報告》中。[Step5]通報結(jié)果質(zhì)量保證員及時將本次質(zhì)量檢查的結(jié)果、經(jīng)驗教訓(xùn)通報給所有項目成員、上級領(lǐng)導(dǎo)和其他相關(guān)的人員。3.6輸出《質(zhì)量保證報告》3.7結(jié)束準則質(zhì)量保證員已經(jīng)客觀地檢查了過程質(zhì)量和工作成果的質(zhì)量。質(zhì)量保證員把本次PPQC結(jié)果、經(jīng)驗教訓(xùn)通報給所有相關(guān)人員。3.8度量質(zhì)量保證員統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經(jīng)理。4問題跟蹤與質(zhì)量改進4.1目的識別質(zhì)量問題并跟蹤問題的解決過程；分析共性質(zhì)量問題，給出質(zhì)量改進措施。4.2角色與職責(zé)項目的質(zhì)量保證員識別質(zhì)量問題并跟蹤問題的解決過程。質(zhì)量保證小組分析機構(gòu)內(nèi)共性的質(zhì)量問題，給出質(zhì)量改進措施。4.3啟動準則有關(guān)人員已經(jīng)執(zhí)行質(zhì)量檢查、技術(shù)評審或者產(chǎn)品測試。4.4輸入質(zhì)量檢查、技術(shù)評審或者產(chǎn)品測試的報告4.5主要步驟[Step1]記錄質(zhì)量問題質(zhì)量保證員記錄在質(zhì)量檢查、技術(shù)評審和產(chǎn)品測試過程中發(fā)現(xiàn)的質(zhì)量問題。[Step2]確定解決措施質(zhì)量保證員首先設(shè)法在項目內(nèi)解決已經(jīng)發(fā)現(xiàn)的質(zhì)量問題，與項目成員們協(xié)商解決措施。質(zhì)量保證員識別出那些在項目內(nèi)難以解決的質(zhì)量問題，將這些問題遞交給上級領(lǐng)導(dǎo)，由上級領(lǐng)導(dǎo)給出解決措施。[Step3]跟蹤問題的解決過程質(zhì)量保證員跟蹤問題的解決過程，記錄問題的狀態(tài)，直到問題被解決為止。[Step4]分析共性問題，給出改進措施質(zhì)量保證小組分析機構(gòu)內(nèi)共性的質(zhì)量問題，給出質(zhì)量改進措施。4.6輸出《質(zhì)量問題跟蹤表》4.7結(jié)束準則所有已經(jīng)識別出來的質(zhì)量問題都得到妥善的解決。4.8度量質(zhì)量保證員統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經(jīng)理。5補充企業(yè)根據(jù)自身的實力、人力資源組建質(zhì)量保證小組，人員可以是全職的也可以是兼職的。一般地，質(zhì)量保證小組和SEPG之和占企業(yè)總?cè)藬?shù)的5％左右。質(zhì)量保證小組應(yīng)當(dāng)擁有直接向上級領(lǐng)導(dǎo)反映情況、提出建議的權(quán)利，如果質(zhì)量保證小組的地位無足輕重，他的工作很容易被項目成員輕視或抵制。先對質(zhì)量保證小組進行培訓(xùn)，讓他們掌握必要的工作技能。 三、培訓(xùn)管理培訓(xùn)管理（TrainingManagement,TM）是指根據(jù)機構(gòu)（或項目）的需求來制定培訓(xùn)計劃，并監(jiān)督該計劃的實施，確保培訓(xùn)取得預(yù)期效果。培訓(xùn)管理過程域是SPP模型的重要組成部分。本規(guī)范闡述了培訓(xùn)管理過程域的兩個主要規(guī)程：機構(gòu)培訓(xùn)管理[PASS-PROC-TM-ORG]項目培訓(xùn)管理[PASS-PROC-QA-PROJECT]上述每個規(guī)程的“目標”、“角色與職責(zé)”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。本規(guī)范適用于國內(nèi)IT企業(yè)的軟件研發(fā)項目。建議用戶根據(jù)自身情況（如商業(yè)目標、研發(fā)實力等）適當(dāng)?shù)匦薷谋疽?guī)范，然后推廣使用。1介紹按范圍劃分，培訓(xùn)管理可分為“機構(gòu)培訓(xùn)管理”和“項目培訓(xùn)管理”。流程如圖20-1所示。確定機構(gòu)培訓(xùn)需求執(zhí)行培訓(xùn)制定機構(gòu)培訓(xùn)計劃培訓(xùn)效果評估確定項目培訓(xùn)需求執(zhí)行培訓(xùn)制定