顯然，滿意質量決不等同于平庸，它強調的是理性的選擇，而不是強制性行為。如果按照GEQ框架分析后認為某個軟件已經達到滿意質量，那么進一步的改進將意味著資源投入得不到足夠的回報。如果我們發現自己正處于這樣一種境地時，就應當認真找尋一下其背后的強制性理由何在。對于GEQ方法的強大推動來自于市場驅動型軟件的爆炸性增長，軟件公司對于巨額股票市值的憧憬導致公司致力于尋找最短途徑以更快地推出更好、更便宜的軟件，他們愿意承擔風險，而且很難容忍傳統意義上的所謂良好實踐，許多傳統的軟件管理觀點在應用到市場驅動軟件項目時常常不適用或顯得過于呆板�？梢钥闯�，GEQ方法與“輕”方法殊途同歸，無論是高可靠性要求的軟件開發還是高娛樂性要求的軟件開發，都可以利用其指導開發工作。無論稱其為GEQ，或其他什么稱謂如經濟性、實用主義、功利主義等，基本思想都是一致的，即我們的行為應受理性指導，而不是強制。
隨著GEQ思想的持續發展，我們思考的質量，而不是遵循形式方法的質量，將成為問題所在，而形式方法及其背后的權威將被重新審視，這也正是許多權威將GEQ視為危險思想的原因。
四、快速應用開發
以上從基本原理入手對于新興的“輕”方法和滿意質量框架進行了討論，本節則以近年來被廣泛應用的快速應用開發（RAD）方法作為具體實例加以探討，為加深對于這些新思想的理解提供幫助。
RAD方法與原型方法有很多相似之處。原型開發可以使用戶看到系統的不同設計方案，尤其當用戶需求不確定時。一般情況下，原型僅用于提供演示。不過，一旦最終版本原型功能正確，文檔齊全，且被正確構造，則可以將其用作最終產品。當原型被用作產品時，所有的遺留問題都必須已經解決，軟件應符合需求說明書、設計文檔和測試文檔。與原型法不同的是，RAD每次交付的是用戶在實際業務中應用的系統，而不僅僅是一個演示模型。
在接受項目定單以后，通過在產品開發時間、費用和質量三者間達成折衷從而快速地移交產品。RAD方法采用遞增式產品交付，通過用戶在每一開發循環周期中的反饋信息來確定下次循環的方向。由于市場需求很難預計，因此RAD循環將無限持續下去直至系統被淘汰。一個典型的RAD開發循環周期是每月推出一個系統的新版本，有時會縮短到每星期甚至每天。不過開發周期越短則開發過程就會越不穩定，也越容易失控。RAD方法通常建立在以下基礎上：
所有目標 的明確定義（需要做什么）和解決方案的指 導說明（怎樣去做）。
將解決具體問題的任務（怎樣去做）交給個人。
項目領導者以教練方式代替細節管理， 從一開始就讓各員工擔負較大責任（僅當有跡象表明員工不 能按時交付時領導再出面解決）。
團隊中的各角色都應預先明確， 這樣每一項任務的完成交付都至少和一位員工的責任對應。但在項目開發的中途， 當實際工作量高于或低于預期的工作量時， 可以改變員工角色或任務。
領導者本身具備 編程能力但可以不 進行編碼工作。
顧客積極參與：顧客是否支持該項目的結果、設計等？你需要確定誰是顧客：誰影響和作出決定？
開發團隊積極參與：團隊各成員認可各項需求和時間期限嗎？
范圍控制：保證當前和以后各階段的估計值不 會過于脫離實際。
實際應用中，RAD方法一般以進度和費用作為獨立參數來調整策略，步驟如下：
1. 客戶確定他們所能承受的最長開發時間和費用。
2. 開發人員估計滿足所有功能所需的開發時間和費用。
3. 如果開發人員估計的開發時間和費用同4. 客戶所能承受的時間和費用相差無幾，5. 那么就可以進行項目開發了。否則：
6. 客戶劃分項目所需功能的優先級。
7. 如果開發時間超出或費用不8. 夠時，9. 項目開發者會在系統開發中摒棄那些低優先級的功能特性。
10. 項目開發者先建立起系統的核心功能，11. 然后按照優先級由高到低的順序實現新的功能，12. 直到開發超時或費用超支。
在使用RAD方法時，可利用以下技巧來提高開發效率和質量：
在每次開發之前，確定一個明確的開發計劃，包括初始需求的建立，總體目標，項目范圍，成功標準，采用的RAD工具和開發方法。
在每次開發之前，簡要描述出每個開發周期中所需實現的功能模塊。制定出在前一兩個開發周期中所需實現的功能特性是非常重要的，這包括確定實現具有高優先級的基礎功能或關鍵功能，預測實現目標和潛在風險。
在每次開發之前，回顧需要在此階段實現或修改的每個功能，判斷它們是否同項目所要實現的目標一致。區分哪些功能是在這個階段中必須要實現的，哪些僅僅是希望實現的。
使用那些經驗豐富的、受人敬重的測試人員。
保證設計者和開發者密切聯系，并使測試人員盡可能參與到開發過程中。
要求設計者和開發者完成各自的單元測試和適當的集成測試。
確定開發過程的安全警戒點，例如，當開發過程中未解決的問題超過了預計值時，應安排額外的時間進行 產品修正，直到錯誤數量大大減少。
盡可能利用和調整已有測試工具，如回歸測試平臺、已有測試用例等。
使用成熟的調試工具和自動化的測試工具以加速開發進程。
使客戶和最終用戶最大程度地參與容量測試，請用戶在日常工作中盡可能地并行使用該系統，并與上次開發周期交付的版本進行前后對比。
對需求和產品范圍的任何改變應慎重分析，測試人員應對所提出的改變可能產生的影響做出評價，并在證明是正當的情況下有權予以否決。
提醒用戶可能存在錯誤，培訓他們怎樣認識和報告錯誤，怎樣在這些錯誤下工作。
應用程序的每一次循環開發都應在版本控制下進行。
不允許未經過最小測試的新版本發布。根據用戶反映、操作風險、故障等級、與上一版本相比最新改動的地方等因素來確定最小測試需求。
必要時，如果為了滿足有時間期限的下一次升級，可以考慮在準備發布之前刪掉漏洞多的功能部分。
如果最新功能證明包含一個漏洞，則要提供給用戶一個返回原版本的機制。
應用軟件通過反復的修正，會變得更穩定�；蛘咧辽偬囟üδ芑蜃酉到y會比其他部分更早些趨向穩定，作為系統穩定的部分，可使用自動測試工具進行更完全的測試。
發布升級版本后不必對用戶所發現的小漏洞感到不安。這對于首次運行是很自然的問題，而且通常還將會有使用戶抱怨的地方。用戶應當理解軟件升級的原因完全是因為新生事物很少有完全正確的。應強調團隊合作。
通過探測或預測程序中可能發生錯誤的地方而避免關鍵點任務的失敗。
通過原型、標準、一致性檢查等減少走回頭路，利用風險預測技術來避免各種缺陷和風險。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
