【文章內(nèi)容簡介】 和工作量，開發(fā)組織必須投入資金。 ? 但是上述例子的結(jié)果證明，我們面臨的是一種“現(xiàn)在付出、否則以后付出更多”的情況。 ? （設(shè)計和其他技術(shù)活動中的）正式技術(shù)復(fù)審提供了顯而易見的成本效益。 ? 因此 ， 應(yīng)該進行復(fù)審活動。 正式技術(shù)復(fù)審 Formal technical Reviews 正式技術(shù)復(fù)審（ FTR）是一種由軟件工程師進行的 軟件質(zhì)量保證活動 。 FTR的 目標(biāo) 是 （ 1）在軟件的任何一種表示形式中發(fā)現(xiàn)功能、邏輯或?qū)崿F(xiàn)的錯誤； （ 2）證實經(jīng)過復(fù)審的軟件的確滿足需求； （ 3）保證軟件的表示符合預(yù)定義的標(biāo)準(zhǔn)； （ 4）得到以一種一致的方式開發(fā)的軟件； （ 5）使項目更易于管理 。由于 FTR的進行使大量人員對軟件系統(tǒng)中原本并不熟悉的部分更為了解，因此， FTR還起到了提高項目連續(xù)性和培訓(xùn)后備人員的作用。 ? FTR(正式技術(shù)復(fù)審 )實際上是一類復(fù)審方式，包括“走查”（ Walkthrough）、“審查”（ Inspection）、“輪查”（ Roundrobin Review）以及其他軟件小組的技術(shù)評估。 ? 每次 FTR都以會議形式進行，只有經(jīng)過適當(dāng)?shù)挠媱?、控制和參與， FTR才能獲得成功。 復(fù)審會議 The Review Meeting ? 不論選擇何種 FTR(正式技術(shù)復(fù)審 )形式，每個復(fù)審會議都應(yīng)該遵守下面的約束： * 復(fù)審會議（通常）應(yīng)該在 3到 5個人之間進行 * 應(yīng)該進行提前準(zhǔn)備，但是每人占用工作時間應(yīng)該少于 2小時 * 復(fù)審會議時間應(yīng)該不超過 2小時 ? 在上述約束之下，顯然 FTR應(yīng)該關(guān)注的是整個軟件中的某個特定（且較?。┎糠帧? 例如 ，不要試圖復(fù)審整個設(shè)計，而是對每個模塊或者一小組模塊進行走查。當(dāng)FTR的關(guān)注范圍較小時，發(fā)現(xiàn)錯誤的可能性更大。 在復(fù)審結(jié)束時，所有 FTR的與會者必須作出以下決定中的一個： （ 1）工作產(chǎn)品可以不經(jīng)修改而被接受； （ 2）由于嚴(yán)重錯誤而否決工作產(chǎn)品（錯誤改正后必須再次進行復(fù)審）；或 （ 3）暫時接受工作產(chǎn)品（發(fā)現(xiàn)必須改正的微小錯誤，但是不再需要進一步復(fù)審）。作出決定之后，所有 FTR與會者需要“簽名”，以表示他們參加了此次 FTR,并且同意復(fù)審小組所作的決定。 復(fù)審報告和記錄保存 Review Reporting and Record Keeping ? 在 FTR期間，一名復(fù)審者（記錄員）主動記錄所有提出的問題。在復(fù)審會議結(jié)束時，對這些問題進行總結(jié)，并生成一份 “ 復(fù)審問題列表 ” 。此外，還要完成一份簡單的 “ 復(fù)審總結(jié)報告 ” 。復(fù)審總結(jié)報告將回答以下問題： 1. 復(fù)審什么？ 2. 由誰復(fù)審？ 3. 發(fā)現(xiàn)和結(jié)論是什么？ ? 復(fù)審總結(jié)報告通常是一頁紙大?。赡苓€有附件）。它是項目歷史記錄的一部分，有可能被分發(fā)給項目管理者和其他感興趣的參與方。 ? 復(fù)審問題列表有兩個作用 ： (1) 標(biāo)識產(chǎn)品中存在問題的區(qū)域； (2) 用作“行動條目”檢查表以指導(dǎo)生產(chǎn)者進行改正。 建立一個跟蹤規(guī)程以保證問題列表中的每一項條目都得到適當(dāng)?shù)母恼?。只有做到這一點，才能保證提出的問題真正得到控制。 復(fù)審指南 Review Guidelines 進行正式技術(shù)復(fù)審之前必須建立復(fù)審指南，分發(fā)給所有復(fù)審者，并得到大家的認可，然后才能依照它進行復(fù)審。 ADVICE：不要嚴(yán)厲地指出錯誤。一種溫和地方式是問一個問題，以使得生產(chǎn)者能夠發(fā)現(xiàn)他自己的錯誤。 1. 復(fù)審產(chǎn)品，而不是復(fù)審生產(chǎn)者 。 FTR涉及到別人和自我。如果進行得適當(dāng)， FTR可以使所有參與者體會到溫暖的成就感。如果進行得不適當(dāng)，則可能陷入一種審問的氣氛之中。 復(fù)審主席應(yīng)該引導(dǎo)復(fù)審會議以保證會議始終處于適當(dāng)?shù)臍夥蘸蛻B(tài)度之中，在討論失去控制時應(yīng)立即休會。 2. 制定日程并且遵守日程 。各種類型的會議都具有一個主要缺點：放任自流。 FTR必須保證不要離題和按照計劃進行。復(fù)審主席被賦予維持會議程序的責(zé)任，在有人轉(zhuǎn)移話題時應(yīng)該提醒他。 3. 限制爭論和辯駁 。在復(fù)審者提出問題時，未必所有人都認同該問題的嚴(yán)重性。不要花時間爭論這一問題，這樣的問題應(yīng)該被記錄在案，留到會后進一步討論。 4. 對各個問題都發(fā)表見解，但是不要試圖解決所有記錄的問題 。復(fù)審不是一個問題解決會議。問題的解決通常由生產(chǎn)者自己，或者在其他人的幫助下來完成。問題解決應(yīng)該放到復(fù)審會議之后進行。 5. 作書面筆記 。 6. 限制參與者人數(shù)并堅持事先作準(zhǔn)備 。 7. 為每個可能要復(fù)審的工作產(chǎn)品建立一個檢查表 。檢查表能夠幫助復(fù)審主席組織 FTR會議，并幫助每個復(fù)審者將注意力集中在重要問題上。應(yīng)該為分析、設(shè)計、編碼、甚至測試文檔都建立檢查表。 8. 為 FTR分配資源和時間 。為了讓復(fù)審有效，應(yīng)該將復(fù)審作為軟件工程過程中的任務(wù)加以調(diào)度。而且要為由復(fù)審結(jié)果而導(dǎo)致的修改活動分配時間。 9. 對所有復(fù)審者進行有意義的培訓(xùn) 。為了提高效率，所有復(fù)審參與者都應(yīng)該接受某種正式培訓(xùn)。 10. 復(fù)審以前所作的復(fù)審 。聽取匯報對發(fā)現(xiàn)復(fù)審過程本身的問題十分有益。最早被復(fù)審的工作產(chǎn)品應(yīng)該是復(fù)審指南本身。 由于成功的復(fù)審涉及到許多變數(shù)（ 如，參與者數(shù)量、工作產(chǎn)品類型、時間和長度、特定的復(fù)審方法等） ，軟件組織應(yīng)該在實驗中決定何種方法最為適用。 SQA的形式化方法 Formal Approaches to SQA ? 在過去的 20年中，在軟件界中有一群雖然很少但是很堅決的人們，提出軟件質(zhì)量保證應(yīng)該采用一種更為 形式化的方法 。一個計算機程序可以看作一個數(shù)學(xué)對象。 ? 對于每一種程序設(shè)計語言都能夠定義一套嚴(yán)格的語法和語義，且對于軟件需求規(guī)格說明也出現(xiàn)了一種類似的嚴(yán)格方法。 ? 一旦需求模型（規(guī)約）和程序設(shè)計語言以一種嚴(yán)格的方式被表達出來，就可以采用程序正確性的數(shù)學(xué)證明來說明程序是否嚴(yán)格符合它的規(guī)約。 ? 程序正確性證明 不是一個新的思路。 Dijkstra和 Linger、 Mills及 Witt，以及其他很多人都支持程序正確性的數(shù)學(xué)證明，并將它與結(jié)構(gòu)化程序設(shè)計概念聯(lián)系在一起。 Statistical Quality Assurance ? 統(tǒng)計質(zhì)量保證反映了一種在產(chǎn)業(yè)界不斷增長的趨勢：質(zhì)量的量化。對于軟件而言， 統(tǒng)計質(zhì)量保證包括以下步驟： 1. 收集和分類軟件缺陷信息。 2. 嘗試對每個缺陷的形成原因（例如，不符合規(guī)約、設(shè)計錯誤、違背標(biāo)準(zhǔn)、與客戶通信不力等）進行追溯。 3. 使用 Pareto原則（ 80％的缺陷可以追溯到所有可能原因中的 20％），將這 20％（重要的少數(shù)）分離出來。 4. 一旦標(biāo)識出重要的少數(shù)原因，就可以開始糾正引起缺陷的問題 。 所有錯誤都可以追溯到下述原因中的一個 (或幾個 ): * 規(guī)約不完整或規(guī)約錯誤 （ inplete or erroneous specifications， IES） * 與客戶通信中所產(chǎn)生的誤解 （ misinterpretation of customer munication， MCC） * 故意與規(guī)約偏離 （ intentional deviation from specification， I