淨室基礎 (轉)

淨室基礎 (轉)[@more@]

淨室基礎

未經允許，嚴禁轉載本欄目內容

 

本文經許可轉載自工程專家網，

未經CSDN許可，請勿隨便轉載，謝謝合作

?page=/bbs/index.asp?Type=D"> 

　　淨室理論基礎來自於數學。Harlan Mills敏銳地看出可以一個數學，從而為確立了合適的科學基礎。在他的早期論文“結構化的數學基礎”、“計算機程式設計的新數學”和“如何正確編寫和認識程式”中，解釋了軟體開發基於數學的函式理論。Mills在軟體測試的統計特性方面同樣敏銳地確立了相應的科學基礎，也就是說，軟體測試只是從無限的可能使用中抽取的樣本。他的早期論文，如關於計算機程式的統計驗證“將統計學應用於軟體。Mills提出的軟體的科學基礎使得淨室軟體工程成為一個真正的工程學科。對Mills的基本思想感興趣的讀者，可從1988年相關出版物以及Mills的早期論文<>(由Dorset House公司出版)中獲得第一手資料。

函式理論

　　淨室開發方法基於數學中的函式理論。一個函式定義了一個從定義域到值域的映謝，定義域中的每個元素都可在值域中找到惟一的元素與之對應。一個特定的程式好似定義了一個從定義域（程式所有可能輸入序列的集合）到值域（所有對應於輸入的輸出集合）的對映。這樣一個程式的規範就是一個函式的規範，描述了一個程式的定義域（或輸入序列）到值域（或輸出空間）的對映。

　　一個定義明確(well-defined)的函式有如下特性：完備性、一致性和正確性。因為一個程式規範描述了一個函式，所以它必須是完備的、一致的和正確的。

　　（1）數學完備性要求對定義域中的每個元素，值域中至少有一個元素與之對應。也就是說，每種可能的輸入都必須定義，並有一個輸出與之對應。

　　（2）數學一致性要求在值域中最多有一個元素與定義域中的同一元素對應，也就是說，每個輸入只能對應一個輸出。

　　（3）相對於需求的規範正確性由定義域專家判斷。然而對於一個給定的正確的規範，某項設計及其規範的正確性是可以透過基於函式理論的推理來驗證的。

　　Linger、Mills和Hevner（1986）提出的用於淨室軟體開發的盒子結構的方法取代了由Linger、Mills和Witt（1997）提出的將數學函式理論應用於軟體開發的方法。被明確提出的有三種功能形式的盒子：黑盒、狀態盒和明盒。

統計理論

　　淨室測試方法基於統計學。過去的幾十年中統計學在工程中獲得了廣泛的成功和應用。當從經濟上或技術上無法測試樣本全體時，可以使用統計抽樣的方法。如果統計結果沒有達到質量目標，生產過程需做必要調整。這種以統計學為堅實基礎的從產品度量到生產過程之間的反饋迴圈，得到了廣泛的認可和應用。怎樣把這種方法應用於軟體呢？在製造業，統計數字在於所生產產品的有形變化；在一些處理過程（如包裹投遞）中，統計數學牌預期處理的偏差中，那麼在軟體中統計數學中如何產生呢？

　　在軟體中，用於取樣的全體(population)是所有可能使用情況的集合其中集合中的每個元素代表的一種可能執行情況。統計的目的是度量系統正確執行一個樣本的能力。因為總體是無限的，完全的測試是不可能的，所以必須利用統計學方法來對系統發生做一個有效的推理。測試過程不論如何擴充套件，在所有可能的輸入序列中都只能算一個很小的集合所有的測試活動只能是無限總體中的抽樣。
　　在淨室軟體工程中，統計測試既可用於產品檢測（單開發過程迴圈的結果），也可用於過程檢測（多開發過程迴圈的結果）。淨室採用增量開發的迭代過程，這樣可測量和提高執行的一致性。

淨室小組的工作

　　淨室開發小組完成三項主要工作：制定系統規範、開發和認證。開發小組通常很小，由3~8人組成，這樣可減少協調和簡化通訊。小組中有一名組長。根據整個組的責任和進度優先順序，任務在小組內部分配和協調。對於小組規模專案，一個小組足夠了。這種情況下，小組在開發的不同階段分別完成規範制定、開發和認證工作。對於中等規模的專案，可能需要組際(team-of-teams)方法。一個最初的組通常由一些最有的人組成。他們規範和定義系統的結構，開發並認證一兩個增量，併為子系統制定規範。然後由這個初始小組的成員擔任開發和認證各個子系統的小組組長。為了適應需求變化或系統層次策略的改變，初始小組在一段時間（1天或一個月或更長時間）後可能重組。對於大規模的系統，組際方法是必要的，可能會指定規範組、開發組和認證組。因此，應該組成三個初始組，一個組制定系統規範，一個組開發初始增量，還有一個組認證這些增量。之後這些組的成員在子系統層次上領導特定小組。無論是什麼組織，所有小組成員都要接受淨室技術培訓。這種培訓可在有經驗的小組領導的指導下作為在職訓練進行。

　　評審是淨室小組的一項重要工作。每個產品從最初的概念到最後形成都要經歷多次評審。有兩種評審。一種稱為開發評審，開發評審的焦點集中於技術策略、好的想法以及小組培訓和交流。舉例來說，一個小組成員可以召集人們來評論一個只有一兩頁程式的設計方案討論的焦點是關於控制和最初資料結構的策略、演算法折中方案等待。接著最好的思路產生了，這可能導致下一次開發評審時評論的是5頁紙的方案。最初的開發評論可能很短，經常只有約半小時，但隨著產品的進化，評論的時間將不斷增加。一個產品可能要經歷許多次開發評審。在成功的評審會上，透過積累的知識交流可提高並節省時間。這樣隨著評審的進行，小組成員對產品更熟悉。最後的產品將是小組所有成員智慧的結晶。

　　所有工作產品的簡化是小組評審的顯著目標之一。最初的思路幾乎從來就不是最好的，所以評審的一個關鍵目標是在規範、設計和驗證方面找到更好的思路。例如，一個較好的思路可使1000行的設計取代原來5000行的設計。驗證（或維護）1000行程式碼要比5000行容易得多。為了簡化或更好的思路而重新設計幾乎總是一種有效的策略。分類結構的標識和重用常常導致簡化，這種結構驗證一次，可以永遠重用。

　　第二種評審稱為驗證評審。這種評審透過形式化方法來驗證工作產品的正確性和完備性，這些驗證通常這樣進行，設計者以口頭方式逐一列舉其滿足基於函式的正確性條件的理由。小組按順序檢查每個條件，不允許有存在異議的情況。任何修改必須經過後續評審的重新驗證。一個工作產品經過驗證評審後而不再有更改的必要時就被認為是正確的和完整的。從這一點看，整個組對工作產品擁有主權，其中任何後續錯誤都應該由該組承擔責任。在先前的開發評審中，每個參與者都已熟悉了被驗證產品的結構和內容，所以在檢查評審中效率得到了保證。另外，經常採用的是可重用的規範和設計模型，所以驗證部分大體上也是可重用的。