【正文】 人員參加友誼活動(dòng)，例如運(yùn)動(dòng)、聚餐、娛樂(lè)等等。二、 處理不合理的變更項(xiàng)目經(jīng)理（和銷(xiāo)售人員）要設(shè)法“拒絕客戶(hù)提出的不合理變更” 。所謂“不合理的變更”是指：客戶(hù)提出的變更不是由于開(kāi)發(fā)方的過(guò)錯(cuò)引起的，此變更造成開(kāi)發(fā)方承擔(dān)了額外的成本，但是客戶(hù)不愿意支付相應(yīng)的費(fèi)用?？蛻?hù)會(huì)想當(dāng)然地以為變更是他的權(quán)利，通常情況下開(kāi)發(fā)方是不敢得罪客戶(hù)的，但是無(wú)原則地退讓將使開(kāi)發(fā)團(tuán)隊(duì)陷入困境。這里建議了三種應(yīng)對(duì)方法：方法 1：依據(jù)合同處理變更如果客戶(hù)是很有信譽(yù)、嚴(yán)格按照合同辦事的企業(yè)，那么雙方應(yīng)當(dāng)依據(jù)合同中的條款處理變更糾紛。這就要求雙方在簽訂合同的時(shí)候，要在合同中寫(xiě)明“變更處理協(xié)議” 。例如：當(dāng)《需求規(guī)格說(shuō)明書(shū)》被雙方確認(rèn)之后，如果再發(fā)生需求變更的話(huà)，那么按照“變更申請(qǐng)－審批－執(zhí)行”的變更管理流程執(zhí)行。如果客戶(hù)（或者開(kāi)發(fā)方）提出的變更對(duì)項(xiàng)目進(jìn)度、成本的影響超過(guò) 10%，那么雙方要重新協(xié)商成本、資源和進(jìn)度，否則開(kāi)發(fā)方（或者客戶(hù)）可以拒絕變更請(qǐng)求。方法 2：設(shè)法拖延到下個(gè)版本如果雙方簽訂的合同中沒(méi)有“變更協(xié)議” ，或者有變更協(xié)議但是客戶(hù)找出很多理由來(lái)搪塞，只要雙方還沒(méi)有完全鬧僵的話(huà)，項(xiàng)目經(jīng)理（和銷(xiāo)售人員）需要一些社交技巧來(lái)減緩矛盾：首先承認(rèn)客戶(hù)提出的需求變更請(qǐng)求是合理的（讓客戶(hù)面子上過(guò)得去） ；再闡述己方的難處和變更對(duì)客戶(hù)造成的不利影響，例如質(zhì)量問(wèn)題等等，讓客戶(hù)明白隨意變更對(duì)他自己也沒(méi)有好處；最后建議在開(kāi)發(fā)新版本的時(shí)候?qū)崿F(xiàn)客戶(hù)提出的變更。這種方式比直接拒絕有效得多，既不得罪客戶(hù)，又為自己爭(zhēng)取了余地。拖延到下個(gè)版本實(shí)現(xiàn)客戶(hù)的變更，有可能讓客戶(hù)支付升級(jí)費(fèi)用。即使升級(jí)是免費(fèi)的，也不會(huì)延誤當(dāng)26 / 52前項(xiàng)目的進(jìn)度和客戶(hù)驗(yàn)收，讓開(kāi)發(fā)方及時(shí)拿到合同經(jīng)費(fèi)。方法 3：讓客戶(hù)欠下人情如果客戶(hù)提出重大的變更請(qǐng)求，既不愿意支付變更的費(fèi)用，也不愿意延緩到下個(gè)版本中實(shí)現(xiàn)，而且客戶(hù)也知道自己理虧，但是現(xiàn)實(shí)環(huán)境迫使客戶(hù)必須那樣做。開(kāi)發(fā)方?jīng)]有辦法拒絕，因?yàn)樘热艟芙^的話(huà)，就得不到合同余款，怎么辦？在這種情況下，開(kāi)發(fā)方只能接受讓自己吃虧的變更，但是還有辦法減少損失，這個(gè)辦法就是“讓客戶(hù)欠下人情” 。銷(xiāo)售人員（和項(xiàng)目經(jīng)理）應(yīng)當(dāng)真誠(chéng)地和客戶(hù)溝通，讓客戶(hù)明白“開(kāi)發(fā)方為了客戶(hù)的利益付出了額外的代價(jià)” 。只要客戶(hù)是個(gè)講道理的正常人，那么客戶(hù)會(huì)感激開(kāi)發(fā)方的幫助，覺(jué)得自己欠下了“人情” ，可以約定在后面恰當(dāng)?shù)臋C(jī)會(huì)回報(bào)開(kāi)發(fā)方。例如，在客戶(hù)驗(yàn)收的時(shí)候，適當(dāng)?shù)胤潘梢?，及時(shí)地向開(kāi)發(fā)方支付合同費(fèi)用等，這些回報(bào)對(duì)開(kāi)發(fā)方而言都是隱形的收益。三、發(fā)掘新的商機(jī)項(xiàng)目經(jīng)理（和銷(xiāo)售人員）和客戶(hù)交往的過(guò)程中，不僅要關(guān)注已經(jīng)簽訂合同的項(xiàng)目進(jìn)展情況，還要不斷發(fā)掘新的商機(jī)，例如：? 發(fā)掘客戶(hù)更深層次的需求，吸引客戶(hù)繼續(xù)采購(gòu)（例如不斷升級(jí)） 。? 將合同項(xiàng)目的成果轉(zhuǎn)化成為通用的產(chǎn)品或構(gòu)件，賣(mài)給其它客戶(hù)。? 請(qǐng)老客戶(hù)推薦其新客戶(hù)。 問(wèn)題跟蹤問(wèn)題跟蹤的范圍包括：開(kāi)發(fā)過(guò)程中的各種問(wèn)題、風(fēng)險(xiǎn)和建議，以及結(jié)項(xiàng)后遺留的問(wèn)題。問(wèn)題跟蹤的一般步驟如圖 26 所示，問(wèn)題跟蹤表見(jiàn)表 212。第 1 步。報(bào)告者創(chuàng)建問(wèn)題，指定接收者，此時(shí)狀態(tài)為“新的” 。第 2 步。接受者處理問(wèn)題，狀態(tài)為“正在處理” 。第 3 步。如果已經(jīng)解決了問(wèn)題，則把狀態(tài)置為“解決待關(guān)閉” 。第 4 步。報(bào)告者審核這個(gè)問(wèn)題，如果確定該問(wèn)題已經(jīng)解決，則把狀態(tài)設(shè)置為“關(guān)閉” 。如果發(fā)現(xiàn)問(wèn)題沒(méi)有解決，則可以“重新打開(kāi)”問(wèn)題，回到第 2 步。報(bào)告問(wèn)題♀報(bào)告者 ♀接受者 ♀報(bào)告者處理問(wèn)題 解決待關(guān)閉 審核關(guān)閉♀接受者重新打開(kāi)27 / 52圖 26 問(wèn)題跟蹤示意圖問(wèn)題跟蹤表問(wèn)題編號(hào) 問(wèn)題類(lèi)型重要性 緊急程度問(wèn)題描述報(bào)告者 報(bào)告時(shí)間接受者 期望完成日期問(wèn)題處理方案當(dāng)前狀態(tài) 實(shí)際完全日期審核關(guān)閉意見(jiàn)表 212 問(wèn)題跟蹤表28 / 52第 3 章 項(xiàng)目研發(fā)過(guò)程 需求開(kāi)發(fā) 與管理需求開(kāi)發(fā)與管理是指通過(guò)“調(diào)研、分析、定義、評(píng)審、跟蹤”等活動(dòng)，使開(kāi)發(fā)方和委托方（客戶(hù)或本公司領(lǐng)導(dǎo)）對(duì)需求有共同、清晰的理解，并依據(jù)雙方確認(rèn)的需求開(kāi)展后續(xù)開(kāi)發(fā)工作（如設(shè)計(jì)、編程、測(cè)試等） 。項(xiàng)目經(jīng)理根據(jù)本項(xiàng)目的人力資源來(lái)確定需求分析員（可以多人） 。需求分析員負(fù)責(zé)開(kāi)展調(diào)研、分析、定義、評(píng)審、跟蹤等活動(dòng)。 需求調(diào)研需求分析員起草需求問(wèn)題表，將調(diào)查重點(diǎn)鎖定在該問(wèn)題表內(nèi)，否則調(diào)研工作將變得漫無(wú)邊際。需求分析員確定需求調(diào)研的方式，例如：? 與用戶(hù)交談，向用戶(hù)提問(wèn)題。? 參觀(guān)用戶(hù)的工作流程，觀(guān)察用戶(hù)的操作。? 向用戶(hù)群體發(fā)調(diào)查問(wèn)卷。? 與同行、專(zhuān)家交談，聽(tīng)取他們的意見(jiàn)。? 分析已經(jīng)存在的同類(lèi)軟件產(chǎn)品，提取需求。? 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。? 從 Inter 上搜查相關(guān)資料。需求分析員在調(diào)研過(guò)程中隨時(shí)填寫(xiě)“客戶(hù)需求記錄” ，參考格式如表 31 所示。項(xiàng)目名稱(chēng) 需求分析員調(diào)研方式 被調(diào)研者時(shí)間、地點(diǎn)需求標(biāo)題 客戶(hù)需求記錄表 31 客戶(hù)需求記錄需求分析員整理所有客戶(hù)需求記錄，歸納與總結(jié)共性的需求，為撰寫(xiě)詳細(xì)的《需求規(guī)格說(shuō)明書(shū)》作準(zhǔn)備。調(diào)研過(guò)程中獲取的需求信息可以作為《需求規(guī)格說(shuō)明書(shū)》的附件。29 / 52 需求分析需求分析是對(duì)各種來(lái)源的需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫(huà)細(xì)節(jié)等。常見(jiàn)的需求分析方法有“問(wèn)答分析法”和“建模分析法”兩類(lèi)。問(wèn)答分析最重要的問(wèn)題是：“是什么”和“為什么” 。每個(gè)需求都應(yīng)當(dāng)用陳述句說(shuō)明“是什么” ，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補(bǔ)充說(shuō)明“不是什么” 。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么” ，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對(duì)于某些類(lèi)型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來(lái)描述需求是很自然的方法。需求建模就是指用圖形符號(hào)來(lái)表示、刻畫(huà)需求?，F(xiàn)代建模工具如 Rose 有非常豐富的圖形符號(hào)和文字標(biāo)注，能很好地表達(dá)模型的細(xì)節(jié)。要注意的是：在建模時(shí)使用花樣過(guò)多的圖形符號(hào)或文字意味著模型表示的復(fù)雜化，將使開(kāi)發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個(gè)包羅萬(wàn)象的圖用以完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。 需求定義需求分析員根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無(wú)誤的需求，撰寫(xiě)《需求規(guī)格說(shuō)明書(shū)》 ，模板見(jiàn)表 32。 提示：若有其它類(lèi)型的需求規(guī)格說(shuō)明書(shū)，請(qǐng)另定義模板。軟件需求規(guī)格說(shuō)明書(shū)1. 背景介紹2. 軟件系統(tǒng)的用戶(hù)介紹 用戶(hù)類(lèi)型和角色職責(zé) 用戶(hù)組織結(jié)構(gòu)圖（可選） 用戶(hù)的信息化情況3. 用戶(hù)業(yè)務(wù)流程介紹4. 軟件系統(tǒng)的約束5. 軟件系統(tǒng)當(dāng)前版本的范圍6. 軟件系統(tǒng)的功能清單7. 模塊需求說(shuō)明（可以寫(xiě)在單獨(dú)的模塊文檔中）8. 其它需求9. 簽字確認(rèn)表 32 軟件需求規(guī)格說(shuō)明書(shū)30 / 52 需求評(píng)審需求分析員邀請(qǐng)項(xiàng)目成員（包括項(xiàng)目經(jīng)理）和客戶(hù)代表共同評(píng)審《需求規(guī)格說(shuō)明書(shū)》 ，大家盡最大努力使《需求規(guī)格說(shuō)明書(shū)》能夠正確無(wú)誤地反映用戶(hù)的真實(shí)意愿。需求評(píng)審的流程見(jiàn)“項(xiàng)目評(píng)審流程” 。一般地，需求分析員為申請(qǐng)人，項(xiàng)目經(jīng)理為評(píng)審負(fù)責(zé)人，項(xiàng)目成員和客戶(hù)代表可以擔(dān)任評(píng)審員。所有評(píng)審人員認(rèn)真檢查需求文檔，力求使需求文檔達(dá)到正確、清楚、無(wú)二義性、一致、必要、完備、可實(shí)現(xiàn)、可驗(yàn)證。 需求跟蹤第 1 步。需求分析員創(chuàng)建需求的目錄結(jié)構(gòu)，便于人們閱讀。第 2 步。需求分析員輸入每條需求的詳細(xì)內(nèi)容，可以多次細(xì)化修改，每次修改后應(yīng)通知相關(guān)項(xiàng)目成員。第 3 步。需求分析員跟蹤每條需求的進(jìn)展?fàn)顩r，填寫(xiě)需求跟蹤記錄（當(dāng)前狀態(tài)和情況說(shuō)明），需求跟蹤表的格式見(jiàn)表 33。需求跟蹤表需求目錄/名稱(chēng) 優(yōu)先級(jí) 狀態(tài) 責(zé)任人 關(guān)聯(lián)信息（文檔，任務(wù)，缺陷等）表 33 需求跟蹤表 系統(tǒng)設(shè)計(jì) 軟件系統(tǒng)設(shè)計(jì)軟件系統(tǒng)設(shè)計(jì)的主要內(nèi)容有體系結(jié)構(gòu)設(shè)計(jì)、用戶(hù)界面設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)等，在需求與代碼之間建立橋梁，指導(dǎo)工作人員開(kāi)發(fā)能夠滿(mǎn)足用戶(hù)需求的軟件系統(tǒng)。項(xiàng)目經(jīng)理根據(jù)本項(xiàng)目的人力資源來(lái)確定軟件設(shè)計(jì)師（可以多人） 。軟件設(shè)計(jì)師撰寫(xiě)《軟件系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)》 ，并構(gòu)造可運(yùn)行的軟件系統(tǒng)框架，所有的模塊都是在該系統(tǒng)框架上開(kāi)發(fā)和運(yùn)行。 《軟件系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)》的模板參見(jiàn)表 34。31 / 52軟件系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)1. 軟件系統(tǒng)概述2. 設(shè)計(jì)約束3. 開(kāi)發(fā)、測(cè)試與運(yùn)行環(huán)境4. 軟件體系結(jié)構(gòu)圖5. 功能模塊設(shè)計(jì)概述 模塊匯總 模塊之間的關(guān)系6. 數(shù)據(jù)庫(kù)設(shè)計(jì)概述 數(shù)據(jù)庫(kù)環(huán)境說(shuō)明 數(shù)據(jù)庫(kù)命名規(guī)則 安全性設(shè)計(jì)說(shuō)明 表匯總和表設(shè)計(jì)7. 用戶(hù)界面設(shè)計(jì)概述8. 綜合考慮（可選） 穩(wěn)定性和可擴(kuò)展性 性能分析 復(fù)用和移植 防錯(cuò)與出錯(cuò)處理 其它表 34 軟件系統(tǒng)設(shè)計(jì)說(shuō)明書(shū) 設(shè)計(jì)評(píng)審設(shè)計(jì)評(píng)審的目的是在同行專(zhuān)家的幫助下，盡早地發(fā)現(xiàn)本系統(tǒng)中存在的設(shè)計(jì)缺陷，及時(shí)消除設(shè)計(jì)缺陷。當(dāng)軟件設(shè)計(jì)師撰寫(xiě)完成《軟件系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)》，并構(gòu)建可運(yùn)行的系統(tǒng)框架之后，邀請(qǐng)項(xiàng)目成員（包括項(xiàng)目經(jīng)理）和本公司技術(shù)專(zhuān)家開(kāi)展設(shè)計(jì)評(píng)審。設(shè)計(jì)評(píng)審的流程見(jiàn)“項(xiàng)目評(píng)審流程” 。 模塊開(kāi)發(fā)與集成項(xiàng)目經(jīng)理分配合適的模塊開(kāi)發(fā)任務(wù)給開(kāi)發(fā)人員，開(kāi)發(fā)人員對(duì)自己承擔(dān)模塊的質(zhì)量和開(kāi)發(fā)進(jìn)度負(fù)責(zé)。開(kāi)發(fā)人員閱讀《需求規(guī)格說(shuō)明書(shū)》和《系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)》 ，分析并細(xì)化自己承擔(dān)的模塊需求，并且進(jìn)行模塊細(xì)節(jié)設(shè)計(jì)，撰寫(xiě)《模板需求和設(shè)計(jì)文檔》 ，見(jiàn)表 35。32 / 52所有開(kāi)發(fā)人員按照既定的規(guī)范（如編程規(guī)范）來(lái)實(shí)現(xiàn)自己承擔(dān)的模塊，并在系統(tǒng)框架中和其它模塊集成一起。開(kāi)發(fā)人員完成模塊開(kāi)發(fā)后，必須先進(jìn)行自我測(cè)試，必須走通模塊的所有功能，消除自己已經(jīng)發(fā)現(xiàn)的缺陷，然后交付給下個(gè)環(huán)節(jié)。模塊文檔（需求和設(shè)計(jì)）項(xiàng)目名稱(chēng) 模塊名稱(chēng)撰寫(xiě)人 完成日期1. 模塊功能和流程介紹說(shuō)明模塊用途、主要功能，最好繪制功能結(jié)構(gòu)圖和工作流程。2. 模塊的設(shè)計(jì)思路3. 模塊的主要數(shù)據(jù)結(jié)構(gòu)4. 本模塊的主要調(diào)用（1）本模塊主要調(diào)用了其它模塊的哪些接口；（2）本模塊為其它模塊提供了什么接口。5. 其它說(shuō)明表 35 模塊需求和設(shè)計(jì)文檔 測(cè)試與缺陷跟蹤測(cè)試與缺陷跟蹤的流程見(jiàn)下圖31。圖 31 測(cè)試與缺陷跟蹤的流程測(cè)試準(zhǔn)備消除缺陷執(zhí)行測(cè)試♀測(cè)試人員缺陷跟蹤審核關(guān)閉♀開(kāi)發(fā)人員提交測(cè)試♀開(kāi)發(fā)負(fù)責(zé)人 ♀測(cè)試負(fù)責(zé)人33 / 52 提交測(cè)試開(kāi)發(fā)負(fù)責(zé)人把待測(cè)試物品（如軟件包）交付給測(cè)試組之前，必須完成以下工作（否則測(cè)試人員可以拒絕接受）：（1）在配置庫(kù)中打標(biāo)記（Label ） ，這個(gè) Label 就是待測(cè)試物品（如軟件包）的版本號(hào)（建議包含年月日時(shí)分的信息） 。（2）說(shuō)明該版本要測(cè)試什么，注意事項(xiàng)等。（3）開(kāi)發(fā)人員必須測(cè)試自己開(kāi)發(fā)的功能，通過(guò)后才可以交付給測(cè)試人員。 測(cè)試準(zhǔn)備測(cè)試準(zhǔn)備主要有三件事情：分配測(cè)試任務(wù)，設(shè)計(jì)測(cè)試用例，構(gòu)建測(cè)試環(huán)境。一、分配測(cè)試任務(wù)測(cè)試負(fù)責(zé)人和測(cè)試人員商議測(cè)試計(jì)劃，安排合適的測(cè)試人員執(zhí)行測(cè)試任務(wù)。二、設(shè)計(jì)測(cè)試用例測(cè)試用例是用于檢驗(yàn)?zāi)繕?biāo)系統(tǒng)是否符合需求的一種“示例” ，基本要素有：前提條件、輸入數(shù)據(jù)或動(dòng)作、期望的響應(yīng)。 《測(cè)試用例》就是描述各種測(cè)試用例的文檔，相當(dāng)于一本“測(cè)試操作手冊(cè)” 。關(guān)于測(cè)試用例的一些常識(shí)如下：（1）設(shè)計(jì)測(cè)試用例的目的是找出需求、設(shè)計(jì)、代碼中的毛病，因此最好盡可能早地設(shè)計(jì)測(cè)試用例。（2）不同的測(cè)試用例其用途應(yīng)當(dāng)不一樣，不要累贅。（3）顯而易見(jiàn)的測(cè)試用例不必完整地用文字描述，因?yàn)榇藭r(shí)文字描述的價(jià)值不大、反而消耗時(shí)間。測(cè)試人員根據(jù)模塊的需求和設(shè)計(jì)說(shuō)明書(shū)，撰寫(xiě)《測(cè)試用例》 ，格式見(jiàn)表 36。最好由開(kāi)發(fā)人員審閱《測(cè)試用例》 ，提出改進(jìn)建議，雙方達(dá)成共識(shí)。測(cè)試用例用例名稱(chēng) 項(xiàng)目名稱(chēng)對(duì)應(yīng)模塊 撰寫(xiě)人前提條件輸入 / 動(dòng)作 期望的輸出示例：典型值…示例：邊界值…示例：異常值…34 / 52審閱人 / 意見(jiàn)表 36 測(cè)試用例三、構(gòu)建測(cè)試環(huán)境測(cè)試人員（和開(kāi)發(fā)工程師）構(gòu)建測(cè)試環(huán)境，注意測(cè)試環(huán)境要盡可能接近用戶(hù)的實(shí)際運(yùn)行環(huán)境。 執(zhí)行測(cè)試測(cè)試人員執(zhí)行測(cè)試，填寫(xiě)測(cè)試報(bào)告，見(jiàn)表 37。測(cè)試報(bào)告目錄/用例名稱(chēng) 測(cè)試人員 測(cè)試記錄/結(jié)論 測(cè)試時(shí)間表 37 測(cè)試報(bào)告 缺陷跟蹤缺陷跟蹤如圖 32 所示，缺陷跟蹤表見(jiàn)表 38。一般步驟如下：第 1 步。測(cè)試人員（報(bào)告者）如果發(fā)現(xiàn)缺陷，則記錄缺陷的詳細(xì)信息，報(bào)告給開(kāi)發(fā)人員（接受者） 。此時(shí)缺陷的狀態(tài)是“新的” 。第2步。開(kāi)發(fā)人員處理缺陷，此時(shí)缺陷的狀態(tài)是“正在處理” 。提示：如果開(kāi)發(fā)人員把缺陷狀態(tài)設(shè)置為“不做處理或延后處理”，則項(xiàng)目經(jīng)理召集相關(guān)人員評(píng)審那些“不做處理或延后處理”的缺陷，給出“處理”還是“不處理”決定。第 3 步。如果開(kāi)發(fā)人員消除了缺陷，則把缺陷的狀態(tài)設(shè)置為“解決待關(guān)閉” 。第 4 步。測(cè)試人員重新測(cè)試該缺陷對(duì)應(yīng)的功能，如果確定缺陷已經(jīng)消除，則把狀態(tài)設(shè)置為“關(guān)閉” 。如果發(fā)現(xiàn)該缺陷沒(méi)有解決，則可以“重新打開(kāi)”缺陷，回到第 2 步。報(bào)告缺陷♀報(bào)告者 ♀接受者 ♀報(bào)告者處理缺陷 解決待關(guān)閉 審核關(guān)閉♀接受者重新打開(kāi)35 / 52圖 32 缺陷跟蹤的流程缺陷跟蹤表缺陷編號(hào) 缺陷類(lèi)型嚴(yán)重性 緊急程度缺陷描述報(bào)告者 報(bào)告時(shí)間接受者 期望完成日期缺陷解決方案當(dāng)前狀態(tài) 實(shí)際完全日期審核關(guān)閉意見(jiàn)表 38 缺陷跟蹤表 消除缺陷消除缺陷的