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