.軟件過程改進之確認與驗證過程指導書V1..修訂記錄編號章節(jié)修訂容簡述修訂日期版本號修訂人1全部初稿2004-07-05買志玉21增加了同級互查的描述2005-9-19海穎33增加了個體檢查表的更新的描述。2005-11-7吳焱4附錄B評審計劃中考慮并行項目的評審2005-12-9海穎5附錄B評審分類除了代碼采用同級互查,其他為專家評審2006-2-24熊烈6全部增加除評審以外其他的確認與驗證活動。2007-10-23卓三1中將采用審查進行評審時發(fā)現(xiàn)的缺陷改為問題,記錄在相應(yīng)評審會議紀要的問題列表中。1.2中評審的角色在評審方式下統(tǒng)一介紹。附錄A附錄B按照修改后的評審方式,修改《評審計劃》2007-10-24三增加對代碼的評審發(fā)現(xiàn)的問題的處理方法。2007-11-7目錄TOC\o"1-6"\h\z\u一、概述6二、確認61需求確認61.1概述61.2開始基準61.3實施過程61.4輸出工作產(chǎn)品71.5結(jié)束基準72驗收測試和Beta測試72.1概述72.2開始基準82.3實施過程8實施測試8缺陷的記錄、分析、解決和跟蹤82.4輸出工作產(chǎn)品82.5結(jié)束基準9三、驗證91評審91.1評審分類9專家評審9同級互查91.2角色101.3評審方式11審查11概述11開始基準11實施過程12評審準備12召開評審會議121.3.1.3.3評審結(jié)果13消除問題13問題跟蹤14評審結(jié)束14輸出工作產(chǎn)品14結(jié)束基準14小組評審15概述15開始基準15實施過程15輸出工作產(chǎn)品15結(jié)束基準16個體檢查16概述16開始基準16實施過程161.3.3.4輸出工作產(chǎn)品17結(jié)束基準17評審檢查表17對代碼的評審172測試172.1概述172.2開始基準182.3實施過程18實施測試18缺陷的記錄、分析、解決和跟蹤182.4輸出工作產(chǎn)品182.5結(jié)束基準19四、附錄A瀑布模型生命周期中的評審計劃19五、附錄B其它生命周期中的評審計劃22概述軟件"確認"與"驗證"是貫穿于軟件開發(fā)過程中十分細致的軟件檢驗活動。"確認"是從用戶的角度,檢驗當前的開發(fā)成果符合用戶的真正需求,即"做了正確的事"。"驗證"是在軟件開發(fā)的各個階段,從軟件技術(shù)人員的角度,測試當前的開發(fā)成果〔文檔,代碼等符合設(shè)計的規(guī),保證按照設(shè)計流程和要求進行開發(fā),即"正確地做了事"。確認需求確認概述從根本上說,需求來源于用戶的"需要"和"要求",這些"需要"和"要求"被分析、整理、確認后形成完整的文檔,該文檔詳細地說明了產(chǎn)品"應(yīng)當"實現(xiàn)的功能。需求確認是指項目經(jīng)理和客戶經(jīng)過充分的溝通和交流,對項目的開發(fā)要求達成共識并做出承諾。開始基準1、對需求的必要性和可行性進行分析,確定需求文檔。2、已識別了被確認的工作的產(chǎn)品和產(chǎn)品組件。實施過程1、將客戶的"需要"和"要求"記錄在《要求記錄表》中,容主要包括：功能性要求、非功能性要求、關(guān)于組件的重用和開發(fā)的要求以及業(yè)務(wù)流程圖?？蛻粜枰凇兑笥涗洷怼飞虾炞?。2、項目經(jīng)理與客戶代表雙方經(jīng)過充分的溝通和交流,對項目的開發(fā)需求已經(jīng)達成共識,將已確認的需求記錄在《要求記錄表》中,作為進行項目開發(fā)的依據(jù)?？蛻粜枰凇缎枨笥涗洷怼飞虾炞?。3、如果要對《要求記錄表》或《需求記錄表》中的容進行變更,必須由雙方協(xié)商確認。4、在項目過程中,客戶無法簽字的情況,可采用Q&A的方式確認。當對業(yè)務(wù)的理解有疑問,需要就需求文檔,設(shè)計文檔等工作產(chǎn)品與客戶進行確認時,可使用《Q&A》和客戶進行溝通,在《Q&A》中項目經(jīng)理向客戶提供主要的確認點<可從技術(shù)評審檢查表中提出主要的檢查項>,請客戶確認；對技術(shù)有疑問而部不能達成一致的或得到解決時,通過《Q&A》和客戶溝通,在《Q&A》中記錄疑問,請客戶回答。輸出工作產(chǎn)品1、《要求記錄表》。2、《需求記錄表》。3、《Q&A》或客戶返回的確認。結(jié)束基準1、客戶在《要求記錄表》和《需求記錄表》上簽字。2、客戶針對《Q&A》確認點或疑問,進行了確認或回答。3、項目經(jīng)理記錄了《Q&A》的問題數(shù)和確認工作的工作量。驗收測試和Beta測試概述驗收測試和Beta測試是檢驗軟件的功能和性能及其它特性是否與用戶的要求一致。對軟件的品質(zhì)從功能、性能、可靠性、易用性等方面作全面的質(zhì)量檢測,幫助項目組找出產(chǎn)品存在的問題。驗收測試主要針對項目來實施,Beta測試主要針對產(chǎn)品實施,可以把Beta測試看作是對產(chǎn)品的驗收測試。開始基準1、制定了《驗收測試計劃》和《Beta測試計劃》。2、準備了相關(guān)的《測試式樣書》、測試腳本、測試工具和測試所用數(shù)據(jù)。3、搭建好了測試環(huán)境。實施過程實施測試1、需要測試的所有測試項均已準備就緒,測試經(jīng)理會按照《項目開發(fā)進度表》中的測試進度來安排測試人員進行測試。2、測試人員將裝載所有軟件和測試數(shù)據(jù)文件,并利用《測試式樣書》中的測試用例、測試腳本和預(yù)期測試結(jié)果來進行測試。缺陷的記錄、分析、解決和跟蹤1、在測試過程中,記錄測試結(jié)果,對于預(yù)期結(jié)果和實際結(jié)果不符的,需要將預(yù)期結(jié)果與實際結(jié)果之間的差異一起記錄下來。可以記錄在《缺陷列表》或Bugzilla或客戶的不具合一覽表中。所有的缺陷都要進行記錄。2、項目經(jīng)理對缺陷進行分析,確定是客戶原因的缺陷還是己方原因的缺陷,對于己方原因的缺陷,需要分析缺陷產(chǎn)生的原因。缺陷原因分類：設(shè)計錯誤,代碼錯誤,功能遺漏,式樣理解錯誤,共通錯誤,其他等。3、確定了缺陷改正的措施,并解決了缺陷。4、解決了的缺陷得到了驗證,并通過了測試。輸出工作產(chǎn)品1、《缺陷列表》或客戶的不具合一覽表。結(jié)束基準1、《缺陷列表》或客戶的不具合一覽表中己方原因的缺陷均得到了解決、驗證并通過了測試。2、項目經(jīng)理記錄了缺陷數(shù)和解決缺陷的工作量。驗證評審評審分為：專家評審、同級互查兩種類型,每種類型都可以采用三種評審方式〔審查,小組評審,個體檢查之一進行評審,評審目的有兩個：工作產(chǎn)品評審和階段評審。一般來講,階段評審在每個階段結(jié)束前進行,工作產(chǎn)品評審一般安排在階段評審之前或同時進行。在制定計劃的時候,項目經(jīng)理識別出哪些工作產(chǎn)品將要進行同級互查,哪些工作產(chǎn)品將要進行專家評審,計劃采用哪種評審方式,評審的目的是什么等。并將評審的進度安排在項目進度表中并明確評審者。評審分類專家評審專家的定義：與另一個人或其他人在等級、階級上不一定具有同等地位,但在某些領(lǐng)域具有足夠的經(jīng)驗和技能,能夠在此領(lǐng)域?qū)δ承﹩栴}提出有見地的意見和建議。專家評審的目的：在項目組成員或外對工作產(chǎn)品進行專家級的檢查,盡可能在生命周期的早期發(fā)現(xiàn)并除去問題。同級互查同級的定義：與其他人處于相同等級、階級地位的人。同級互查的概念：由作者的同級按照預(yù)定的規(guī)程對軟件工作產(chǎn)品進行的評審,不得由作者本人對自己的工作產(chǎn)品進行評審。同級互查的目的：在項目組成員對工作產(chǎn)品進行相互檢查,盡可能在生命周期的早期發(fā)現(xiàn)并除去問題。角色下表列出了在評審過程中所有可能涉及的角色及其責任。每個參與者可以擔任多個角色。所有參與者除了自身擔任的特定角色外,也都是評審參與人員。一次評審需要至少三個參與者,包括作者。作者一般不作講解員或記錄員。角色責任作者·被評審的工作產(chǎn)品的創(chuàng)建者或維護者,與項目經(jīng)理一起發(fā)起評審過程?！な鲈u審目標·提交工作產(chǎn)品及相關(guān)文檔給項目經(jīng)理?！づc項目經(jīng)理一起選擇評審參與人員,并分配角色。·對應(yīng)階段/工作產(chǎn)品評審會議紀要的問題列表中的問題。·向項目經(jīng)理報告問題數(shù)和消除問題所用的時間。項目經(jīng)理·計劃,安排,組織評審活動?！づc作者一起選擇評審參與人員,并分配角色?！ぬ崆霸u審會議至少三天,將待評審的工作產(chǎn)品及相關(guān)文檔發(fā)送給評審參與人員?！ご_定會議準備是否充分。如果不充分,重新安排會議時間?！けＷC評審會議進行。糾正任何不適當?shù)男袨?。隨著講解員展現(xiàn)工作產(chǎn)品的各部分,引導評審參與人員提出問題?！ゎI(lǐng)導評審小組確定工作產(chǎn)品的評審結(jié)果。記錄員·記錄并分類評審會議中提出的問題。講解員·講解工作產(chǎn)品,幫助評審參與人員理解工作產(chǎn)品,發(fā)現(xiàn)問題。評審參與人員·在評審會議之前瀏覽工作產(chǎn)品,發(fā)現(xiàn)缺陷,為參加評審會議做準備?！⒓釉u審,識別問題,給出改進建議。評審方式下面主要描述了三種評審方式的實施過程。審查概述審查是正式評審方式,一般有3-5人參與評審,以評審會議或email的形式進行。以email方式進行審查時,評審參與人員需使用檢查表,對待評審的工作產(chǎn)品及相關(guān)資料進行審閱,將發(fā)現(xiàn)的問題記錄在階段/工作產(chǎn)品評審會議紀要的問題列表中,以email方式告知項目經(jīng)理。如果沒有問題,也需回復(fù)email說明。在進行立項、計劃、需求、設(shè)計的階段評審時間建議采用審查方式。另外,評審下列工作產(chǎn)品時一般也采用審查方式。關(guān)鍵的工作產(chǎn)品。復(fù)雜或關(guān)鍵的代碼。問題較多的工作產(chǎn)品。關(guān)鍵工作產(chǎn)品的最終評審。開始基準項目經(jīng)理為待評審的工作產(chǎn)品選擇了審查的評審方式。作者準備好待評審的工作產(chǎn)品及相關(guān)文檔。作者述了評審目標。配置經(jīng)理為待評審的文檔分配了版本號。所有頁面都標明了頁碼。文檔經(jīng)過了拼寫錯誤檢查。配置經(jīng)理為待評審的源代碼分配了版本號。代碼清單標明了行號和頁碼。代碼通過了基本檢查。對于二次評審,前一次評審中發(fā)現(xiàn)的所有問題都已經(jīng)解決。實施過程評審準備作者將待評審的工作產(chǎn)品和相關(guān)資料提交給項目經(jīng)理。項目經(jīng)理確定工作產(chǎn)品是否滿足評審入口準則。項目經(jīng)理根據(jù)工作產(chǎn)品的規(guī)模和復(fù)雜度確定需要多少次評審會議〔評審工作產(chǎn)品的工作量最長不超過2-3小時,若工作量過大,要分成多次評審會議。項目經(jīng)理和作者共同選擇評審參與人員,為其分配角色。在評審會議前,項目經(jīng)理至少提前三個工作日向評審參與人員發(fā)布評審會議通知,待評審的工作產(chǎn)品、相關(guān)資料和檢查表。作者向評審參與人員述評審目標,描述工作產(chǎn)品的重要特征?！部烧匍_評審說明會議,或通過說明。項目經(jīng)理要求評審參與人員以特定的角度準備評審。例如,檢查交叉引用的一致性,檢查接口錯誤,檢查對以往的規(guī)的可追溯性和一致性,檢查對標準的符合性。評審參與人員預(yù)評審工作產(chǎn)品,將發(fā)現(xiàn)的問題在階段/工作產(chǎn)品評審會議紀要的問題列表中,在評審會議之前交給項目經(jīng)理,由項目經(jīng)理轉(zhuǎn)交給作者。項目經(jīng)理確認準備情況：了解每個評審參與人員的準備時間,如果準備不充分,重新安排會議時間。召開評審會議召開會議：項目經(jīng)理介紹評審會議參加者〔可選,說明其角色〔可選,述評審目標。指導評審參與人員將精力集中于發(fā)現(xiàn)問題,而不是解決方法。提醒參與人員要針對正在評審的工作產(chǎn)品,而不是作者。展示工作產(chǎn)品：講解員向評審參與人員描述工作產(chǎn)品的各個部分。提出問題：每展示完工作產(chǎn)品的一部分,評審參與人員提出關(guān)心的問題,潛在的缺陷,疑問或改進建議。解答問題：作者簡短回答提出的問題,使評審參與人員進一步了解工作產(chǎn)品,從而幫助確認是否真的是問題。記錄問題：對確認存在的問題,記錄員記錄到階段/工作產(chǎn)品評審會議紀要的問題列表中。大聲讀出記錄,以確認問題被正確地記錄。評審結(jié)果確定產(chǎn)品評審結(jié)果：所有評審會議結(jié)束以后,評審小組確定工作產(chǎn)品的評審結(jié)果。如果意見不一致,由項目經(jīng)理協(xié)調(diào),評審結(jié)果應(yīng)確定為所有評審參與人員給出的評審結(jié)果中最保守的一個。評審結(jié)果如下表所示：評審結(jié)果含義完全接受可能需要做某些修改,但修改不需要審核。有條件的接受必須修改缺陷,所做的修改必須由指定的人審核。需進行二次評審工作產(chǎn)品的很大部分都需要修改或需要做很多變更。作者完成修改工作后需要二次評審。項目停止由于項目存在重大缺陷或其它的原因,項目停止。評審未完成評審容的重要部分沒有評審或評審因某些原因中斷。簽署評審結(jié)果：所有評審參與者都要在階段/工作產(chǎn)品評審會議紀要上簽字,說明他們同意評審結(jié)果。消除問題作者改正問題和小錯誤,解決提出的問題,并相應(yīng)地修改工作產(chǎn)品。在階段/工作產(chǎn)品評審會議紀要的問題列表中標注已經(jīng)處理過的問題。作者基于工作產(chǎn)品評審發(fā)現(xiàn)的問題,修改其他相關(guān)文檔。作者向項目經(jīng)理報告消除的問題數(shù)量,以及工作量。問題跟蹤由項目經(jīng)理或指定的人員來確認作者已經(jīng)對應(yīng)了相應(yīng)階段/工作產(chǎn)品評審會議紀要中的問題。確定作者是否正確的判斷了哪些問題不必改正,那些改進建議不必實現(xiàn)。項目經(jīng)理檢查修改后的工作產(chǎn)品,對問題的修正工作進行確認,將結(jié)果告之作者。項目經(jīng)理統(tǒng)計問題數(shù)及相關(guān)工作量。項目經(jīng)理檢查是否滿足評審的結(jié)束基準。如果滿足,則評審結(jié)束。配置經(jīng)理將工作產(chǎn)品基線化到項目配置管理系統(tǒng)中。評審結(jié)束項目經(jīng)理簡單總結(jié)此次評審活動,將問題記錄在相應(yīng)階段/工作產(chǎn)品評審會議紀要的問題列表中,提出建議和解決的方法。評審活動結(jié)束。輸出工作產(chǎn)品基線化的工作產(chǎn)品。完成的階段/工作產(chǎn)品評審會議紀要〔包括階段/工作產(chǎn)品評審會議紀要的問題列表。結(jié)束基準所有評審目標都已達成。評審中提出的確定必須消除的問題被跟蹤直至關(guān)閉。修改的工作產(chǎn)品已基線化到項目配置管理系統(tǒng)中。如果修改了以前的工作產(chǎn)品,則已經(jīng)正確地修改了這些工作產(chǎn)品,保存到了項目配置管理系統(tǒng)中。項目經(jīng)理記錄了問題數(shù)和消除問題的工作量。小組評審概述小組評審是非正式評審的方式,通常采用會議形式,有3-5人參與評審。在進行實現(xiàn)、測試的階段評審建議采用小組評審方式。另外在下列情況下也使用小組評審的方式：工作產(chǎn)品的初期評審。非關(guān)鍵工作產(chǎn)品的最終評審。當非關(guān)鍵工作產(chǎn)品發(fā)生大變更時。開始基準項目經(jīng)理為需要評審的工作產(chǎn)品選擇了小組評審的評審方式。作者述了評審目標。實施過程作者在會議之前分發(fā)工作產(chǎn)品給評審參與人員。在會議期間,作者以適當?shù)姆绞较蛟u審參與人員描述工作產(chǎn)品。針對評審參與人員關(guān)心的議題組織討論。評審參與人員提出可能的問題和改進建議,記錄在階段/工作產(chǎn)品評審會議紀要及階段/工作產(chǎn)品評審會議紀要的問題列表中。作者根據(jù)評審參與人員的評論,對工作產(chǎn)品執(zhí)行必要的修改。輸出工作產(chǎn)品修改的工作產(chǎn)品。完成的階段/工作產(chǎn)品評審會議紀要〔包括階段/工作產(chǎn)品評審會議紀要的問題列表。結(jié)束基準作者已經(jīng)對工作產(chǎn)品做了恰當?shù)男薷?。個體檢查概述個體檢查是非正式評審的形式,有2-n人參與評審。通常由作者將工作產(chǎn)品及相關(guān)資料分發(fā)給評審參與人員,作者和評審參與人員之間進行討論交流。在下列情況下使用個體檢查評審方式：工作產(chǎn)品最初的設(shè)計和開發(fā)時。非關(guān)鍵工作產(chǎn)品的最終評審。當非關(guān)鍵工作產(chǎn)品發(fā)生小變更時。開始基準項目經(jīng)理選擇了個體檢查的評審方式。作者對文檔進行了拼寫錯誤檢查。作者對代碼進行了基本的檢查。實施過程作者將工作產(chǎn)品及相關(guān)文檔發(fā)送或共享給每個評審參與人員。作者通知評審參與人員工作產(chǎn)品已經(jīng)準備好,指定評審的結(jié)束日期。評審參與人員將發(fā)現(xiàn)的問題記入階段/工作產(chǎn)品評審會議紀要的問題列表中,交給作者。作者在評審結(jié)束后,從共享目錄中移走工作產(chǎn)品。作者根據(jù)評審參與人員填寫的階段/工作產(chǎn)品評審會議紀要的問題列表,對工作產(chǎn)品進行必要的修改。輸出工作產(chǎn)品修改后的工作產(chǎn)品。完成的階段/工作產(chǎn)品評審會議紀要〔包括階段/工作產(chǎn)品評審會議紀要的問題列表。結(jié)束基準作者已經(jīng)對應(yīng)了階段/工作產(chǎn)品評審會議紀要的問題列表中的所有問題。評審檢查表評審檢查表分為工作產(chǎn)品評審檢查表〔包含在《工作產(chǎn)品評審會議紀要》中和階段評審檢查表〔包含在《階段評審會議紀要》中。開始時,檢查表可以基于行業(yè)標準,但是不可以與組織的標準有沖突。在個體檢查中,評審人員在執(zhí)行評審時,可以根據(jù)實際情況,對當前項目所使用的檢查表進行更新,對本項目的檢查對象不適用的項目可以刪除,而未被計入的可以作為新項目添加到當前項目所使用的檢查表模板中,但在對檢查表進行修改時必須得到項目經(jīng)理的認可。組織將定期對檢查表進行更新,確保其支持組織最新的開發(fā)模式,有些從來沒有發(fā)現(xiàn)過問題的檢查項也可以逐漸從檢查表中被刪除。對代碼的評審仔細的分析代碼發(fā)現(xiàn)的問題對于減少后期測試的工作量有很大的幫助,便于項目經(jīng)理掌控整個項目的缺陷信息,我們將代碼評審時發(fā)現(xiàn)的問題,當作缺陷處理,記錄在《缺陷列表》中。其處理流程參見缺陷的記錄、分析、解決和跟蹤。測試概述軟件測試是一個在可控的環(huán)境中執(zhí)行軟件的過程,其目的是為了驗證軟件是否按照預(yù)期運行。這里所說的測試包括單體測試、結(jié)合測試和系統(tǒng)測試。開始基準1、制定了《測試計劃》,并在其中說明了測試策略。2、準備了相關(guān)的《測試式樣書》、測試腳本、測試工具和測試所用數(shù)據(jù)。3、搭建好了測試環(huán)境。實施過程實施測試1、需要測試的所有測試項均已準備就緒,測試經(jīng)理會按照《項目開發(fā)進度表》中的測試進度來安排測試人員進行測試。單體測試一般由開發(fā)人員進行。2、測試人員將裝載所有軟件和測試數(shù)據(jù)文件,并利用《測試式樣書》中的測試用例、測試腳本和預(yù)期測試結(jié)果來進行測試。缺陷的記錄、分析、解決和跟蹤1、在測試過程中,記錄測試結(jié)果,對于預(yù)期結(jié)果和實際結(jié)果不符的,需要將預(yù)期結(jié)果與實際結(jié)果之間的差異一起記錄下來?？梢杂涗浽凇度毕萘斜怼坊駼ugzilla中。2、項目經(jīng)理對缺陷進行原因分析,缺陷原因等信息詳見《缺陷列表》。3、確定了缺陷改正的措施,并解決了缺陷。4、解決了的缺陷得到了驗證,并通過了測試。5、測試結(jié)束后,要對前一階段的測試進行分析,將分析結(jié)果記錄在《測試分析報告》中。輸出工作產(chǎn)品1、《缺陷列表》。2、《測試分析報告》。結(jié)束基準1、《缺陷列表》中的缺陷均得到了解決、驗證并通過了測試。2、項目經(jīng)理記錄了缺陷數(shù)和解決缺陷的工作量。附錄A瀑布模型生命周期中的評審計劃時機評審分類評審方式評審目的評審工作產(chǎn)品評審后的產(chǎn)物評審檢查表參加評審人員立項階段專家評審審查工作產(chǎn)品評審《項目啟動協(xié)議書》已簽字的《項目啟動協(xié)議書》《項目立項協(xié)議書檢查表》PMO、項目經(jīng)理、項目支持人員、項目啟動支持人員、QA計劃階段專家評審審查階段評審《執(zhí)行計劃書》《項目開發(fā)計劃》《裁減過程記錄》《項目估計表》《項目風險列表》《項目進度表》《測試計劃》《項目度量數(shù)據(jù)》《計劃評審會議紀要》〔含簽字《項目開發(fā)計劃評審檢查表》PMO、項目經(jīng)理、QA需求開發(fā)階段專家評審小組評審/個體走查工作產(chǎn)品評審《要求列表》《需求列表》〔需求規(guī)格式樣書《需求評審會議紀要》《需求文檔評審檢查表》領(lǐng)域?qū)＜?、客戶代表、項目?jīng)理、QA專家評審審查階段評審《項目風險列表》《問題列表》《項目度量數(shù)據(jù)》《項目進度表》《需求評審會議紀要》《需求階段評審會議紀要》《階段評審檢查表》PMO、項目經(jīng)理、QA設(shè)計階段專家評審小組評審/個體走查工作產(chǎn)品評審《概要設(shè)計式樣書》《詳細設(shè)計式樣書》Mockup《軟件設(shè)計對應(yīng)表》《畫面設(shè)計書》《畫面遷移圖》《表定義書》《消息定義書》《系統(tǒng)架構(gòu)設(shè)計書》《采購需求定義書》《軟件架構(gòu)設(shè)計書》《帳票設(shè)計書》《文件設(shè)計書》《外部接口說明書》《設(shè)計評審會議紀要》《設(shè)計文檔評審檢查表》架構(gòu)師、設(shè)計師、項目經(jīng)理、專家評審審查階段評審《項目風險列表》《問題列表》《項目度量數(shù)據(jù)》《項目進度表》《設(shè)計評審會議紀要》《設(shè)計階段評審會議紀要》《階段評審檢查表》PMO、項目經(jīng)理、QA實現(xiàn)同級互查個體檢查工作產(chǎn)品評審代碼《代碼走查檢查表》程序員專家評審個體檢查工作產(chǎn)品評審《單體測試式樣書》《單體測試式樣書評審紀要》《單體測試式樣書評審檢查表》程序員專家評審小組評審階段評審《單體測試報告》《缺陷列表》《