當今的IT企業正處于一種前所未有的競爭環境之中，無論是作為獨立軟件供應商還是增殖服務商，也無論是開發直接面向市場的軟件產品如游戲、工具、多媒體等等，還是為用戶定制軟件如電子商務應用、MIS等等，市場競爭都無處不在，IT開發工作被迫在市場驅動的狀態進行，具有以下典型特征：
快速演變升級的基礎技術，必須及時跟蹤基礎技術的革新并調整策略。
持續的競爭，必須不斷推陳出新來滿足用戶需求。
時間就是金錢——需要在時間、質量、費用之間達成折衷。
從業人員聰明且教育程度高，能夠在一定范圍內進行自我管理。
以往流行于IT行業的設計—評審—構造模型已過時。IT業最新的技術和工具改變了以前項目運行所必須遵循的邏輯順序。比如：現在一些工具允許“即時”創建屏幕，使得冗長的設計—評審—構造模型不再適用，而要求一種更難于計劃的原型—審核—構造—再審核—再構造的過程。
角色重疊：現代技術和工具使原來專門的設計、分析、編碼人員之間嚴格的區分界限變的模糊。
以往的IT開發人員相對于當前市場驅動下的開發人員而言，至少擁有以下優勢：控制他們的應用開發技術。在傳統的企業應用開發中，機器配置和其他系統元素在實現階段就被指定�，F在，這種優勢不復存在，很少有哪個系統被實現為在專用機器上的孤立應用。相反，他們經常是企業用戶機器上的另一種應用，必須與其他商業應用程序聯合使用，這使得IT開發人員不得不為保持與CORBA、Internet、或數據庫標準的變化相一致而疲于奔命。同時，持續的競爭、緊迫的進度和嚴格的預算讓IT開發經理不得不經常根據銷售人員或客戶的要求而調整開發工作。
顯然，市場驅動的新環境給IT開發帶來新的挑戰，如果照搬套用以往的成功經驗和開發模式并非明智之舉，必須適應新形勢的要求，重新思考和定位。
二、“輕”方法浮出水面
隨著軟件工業不斷發展，各種各樣的模型不斷涌現或退出歷史舞臺。早期從不同角度提出的各種設計表示方法（常常以發明者的名字來命名）目前似乎已經聚合成為UML這種被廣泛接受的標準，結構化設計方法也正在讓位于面向對象設計等更受歡迎的方法學，這種變化在更高層次的全局性開發方法學方面同樣進行著。
傳統意義上的軟件方法學描述通�！澳軌颉碧幚砣魏未笮〉捻椖�，而實際上真正的困難就來自于如何對這些方法加以裁剪以適合較小的項目。針對這種理論與實際的脫節現象，國際上一些著名的軟件工程專家提出所謂“重（heavy）”方法和“輕（light）” 方法之分，試圖為快速發展的軟件工業探尋更切合實際的解決方法。
所謂“重”方法，就是指形式化的、戒律森嚴的軟件工程方法學——不僅指這些方法所生成紙文檔重量，還意指管理資源投入、QA評審的程度和開發人員被要求遵守的嚴格流程。相對的，諸如快速應用開發（Rapid Application Development，簡記為RAD)和原型方法等則可以被稱為“輕”方法——不僅是因為這些方法傾向于產生最小數量的紙文檔，還因為其將管理資源投入最小化。不幸的是，1990年代的許多RAD項目在方法學上采取了過“輕”的處理以至于幾乎不存在什么方法，這些項目常常退化為雜湊式作坊開發，實質上根本沒有任何文檔。 顯然，需要在兩種極端方法之間找到平衡點。
輕方法代表了一種有意識的風險防護方法，依據不同風險在與開發相關的各種活動中投入相應時間、資金和資源。例如，進行多少需求分析工作才算是過多，擬或過少？針對一個幾百個需求的開發項目而言，一個需求分析“輕”方法（requirements-light approach）可能是由將每一個需求通過一個簡潔的句子加以文檔化的行為所組成，一個需求分析“中”方法（requirements-medium approach）可能要求對每個需求通過一段描述性文本來文檔化，而一個需求分析“重”方法（requirements-heavy approach）則可能要求詳細的UML模型、數據元素定義和每個對象方法的形式化描述。
究竟選擇需求分析的“輕”方法還是“重”方法很大程度上受到公司產品上市時間或合同期限壓力的影響。同時，公司雇員的流動率也是一種影響因素：作為形式化開發過程的理由之一認為，如果有一份詳細的文檔來記錄需求、設計和編碼，那么一旦在項目進行中關鍵開發成員離職所造成的混亂將會被盡量減小。然而，盡管1970年代和1980年代的系統生命周期預期為十年或二十年，也許Interbet時代的網絡公司更愿意正式承諾其電子商務應用僅持續一年，然后被廢棄或完全重寫。如果正是這種情況，并且如果下一代應用預期與當前應用存在質的差異，那么僅僅為了達到SCM-CMM三級就遵循需求分析“重”方法還真的有意義嗎？
同樣地，針對設計和測試工作采用什么樣的形式化和嚴格程度才是合適的呢？與項目管理有關的時間匯報、進展匯報、狀態會議及其他常見活動又如何呢——尤其針對那些僅持續一周或兩周的項目？這些問題總是相互關聯的，但是一些傳統上被接受的答案卻需要至少每隔幾年重新審視一下，因為成本-收益參數正在隨著商業環境、技術和軟件開發人員的變化而不斷變化。
輕方法還重新審視了歷史上有關投入資源在需求分析的假定，以及投入資源在過程改進的假定。1981年Barry Boehm在他的經典著作“軟件工程經濟學”（Software Engineering Economics）中指出了一項驚人發現，即如果我們在項目的系統分析階段引入一個缺陷的話，那么在項目的分析階段發現這個缺陷會比允許這個錯誤直至進入設計階段才被發現節省約10倍資源。但是Boehm在此做了一個在新千年的頭十年中未必依然正確的基本假定：僅當該缺陷在生命周期某階段發生時可通過某種方式加以鑒別，那么這種數量級增長關系圖才是相關的。在今天的環境中，這個前提假定在許多商業條件下都是不成立的。比如，當Bill Gates闡明對于瀏覽器IE的需求時，可能他會說“就象Netscape Navigator那樣，但要更好”，可能Netscape的Marc Andreesen也會這樣想：“我希望使Navigator就象Mosaic一樣，但要更好�！钡钱擳im BernersLee在構建WWW的初始版本和瀏覽器的第一個草樣時又該如何考慮呢？讓他寫出詳細需求的意義何在呢？
與此同時，重方法的倡導者爭辯說，如果一個缺陷在開發階段就被發現，那么就不應當責備引入該缺陷的個人，而應重新檢查允許該缺陷發生的過程本身。但此處又有一個基本假設，也就是說，我們值得投入資源在鑒別一個過程中潛在缺陷的唯一理由是我們希望再次使用同樣的過程——因為我們的下一個項目將會與上一個項目足夠相似，很自然就應使用同樣的過程。但是現在事物變化是如此之快，以至于完全不能保證第N+1個項目會與第N個項目有任何相似之處。因此，昨天的過程可能不得不為了明天的需求而發生實質性變化，換言之，也許只有投資于過程中的重要缺陷才是值得的，因為一些細節僅針對某個特定項目才有意義。
當然，仍然有一些環境需要我們繼續依賴于舊的、基本的軟件工程原理，在這些環境中重方法被證實依然正確。但是我們應當捫心自問，隱藏在這些原理背后的前提假定是否依然合理。對于許多今天的項目而言，一些根本性的前提假定需要加以改變，而輕方法將是具有最優性能價格比的方法。
可以看出，輕方法的基本思路是試圖在項目范圍、成本、時間和質量之間達成一種平衡，其關鍵是在足夠的管理可見度、足夠的靈活性和足夠快的開發速度以完成工作之間找到這種平衡，必須嚴格審查你想要對項目加入或刪除的控制手段的價值何在。盡管我們可以將某個公布于眾的開發方法作為基礎進行裁剪，但必須深入理解你要執行的每個步驟的理由，尤其在項目的初始規劃階段，就應明確定義開發方法，確保項目團隊成員的參與和認可，并以滿足項目的商業需求為目標。
三、滿意質量框架
滿意質量（Good Enough Quality，簡記為GEQ）是與“輕”方法相呼應的新思路，同時也是一個存在很大爭議和誤解較深的概念，近年來受到越來越多的關注，其理論基礎正在不斷走向成熟，本節對其進行深入探討。
滿意質量的提法最初主要源自軟件項目的直接參與人員，而不是那些制定軟件過程或提供咨詢的人士，在軟件工程學術界則更是缺乏相關研究。這種情況導致了相關概念的濫用，滿意質量常被用來為軟件中明顯存在的缺陷做辯解，甚至有人認為軟件供應商在軟件產品中保留錯蟲是一種蓄意行為甚至是聰明的策略，這無疑造成了很大誤解。
為此，著名的軟件工程專家James Bach根據自己多年的實踐經驗和理論基礎對滿意質量的原則進行了系統化定義，提出了滿意質量框架，澄清了許多模糊認識。滿意質量框架基于以下假定：
1) 軟件開發被迫面對一個充滿復2) 雜性、未知、限制、錯誤和不3) 完美的世界；
4) 截止目前人員是軟件項目中最易變和最重要的元素；
5) 任何事情都帶來成本，6) 而7) 我們所想要的總是超過我們能夠支付的；
8) 質量在本質上是有條件的和主觀的；
9) 為了在軟件方面達到完美，10) 我們不11) 得不12) 解決許多困難問題、達成許多折衷和解決相互沖突的價值，13) 完美不14) 會很容易或機械性地實現；
15) 軟件工程方法僅在其設計范圍和假定前提下有用。
基于上述假定，滿意質量定義如下：（1）可帶來足夠的利益；（2）不存在致命性問題；（3）所帶來的利益超過問題所造成的損失；（4）在當前條件下綜合考慮所有因素后，進一步的改進所帶來的損害大于其帶來的幫助。同時，提供了一個用于評估GEQ的框架，該框架包括四個GEQ元素和六個GEQ視角，它們構成了一個提示問題集，可用來幫助相互溝通，或者幫助進行產品開發、產品改進、實現更好的實踐活動等。例如，當某人說“滿意未必是滿意”時，就可以利用受益人和關鍵目的兩個視角來理解該悖論的真實含義并予以討論，可以應對“對你而言的滿意對我卻未必”，或者“相對生存目的而言的滿意在以成功為目標時卻未必”，這樣問題就轉換成誰的價值起作用或哪個目標是真正要實現的，進而探討可行解決方法。以下是GEQ框架的概要描述：
GEQ元素（factor）
這里給出的四個元素是以GEQ定義為基礎擴展而得到，并非嚴格的公式。這些元素被設計用來提醒那些忙碌的、超負荷工作的軟件人士在評估軟件產品質量時應思考的問題。
1. 評估產品的利益
鑒別——對于產品的受益人而 言具有什么已知利益或潛在利益？
可能性——假設產品正如所設計的那樣工作， 受益人有多大可能性會認識到每個利益？
影響——對受益人而 言， 每個利益的期望程度如何？
個體重要程度——從個體考慮， 哪些利益是完全不 可替代的？
整體利益——作為一個整體且假設沒有問題， 是否具有足夠的利益以滿足受益人？
2. 評估產品的問題
鑒別——對于產品的受益人而 言具有什么已知問題或潛在問題？
可能性——受益人有多大可能性會發現每個問題？
影響——對受益人而 言， 每個問題的破壞程度如何？是否可以繼續工作？
個體重要程度——從個體考慮， 哪些問題是完全不 可接受的？
整體問題——所有問題疊加在一起會怎樣？是否有太多的非關鍵問題？
3. 評估產品質量
整體質量——根據GEQ視角， 利益是否看來超值于問題？
安全/完美邊際值——如果需要或想要使利益超值于問題， 那么至少需要投入多少？
4. 評估改進產品的后勤問題
策略——有哪些策略可用于改進產品？
能力——具備 實現這些策略的能力嗎？知道如何做嗎？
成本——改進工作需要多少成本或存在什么麻煩？是否充分利用了資源？
進度——能否立即開始或稍 后再改進？能否在可接受的時間范圍內實現改進工作？
利益——改進效果明確嗎？有附加利益嗎（如更好的士氣）？
問題——改進工作會有多大可能帶來負面影響（例如， 引入錯蟲、損傷士氣、占用其他項目資源）？
GEQ視角（perspective）
上述GEQ元素是必要條件而不是充分條件。為了執行可靠的評估，還必須同時從六個關鍵視角來檢查每個元素：
1. 受益人——哪些人關于質量的意見起作用？（例如，2. 項目團隊、客戶、商會、法院等）
3. 關鍵目的——什么是必須達到的？（例如，4. 即時生存、利潤、市場份額、客戶滿意度等）
5. 時間尺度——質量改進成果的時間敏感性如何？（例如，6. 立即、近期、長期、某個關鍵事件之后等）
7. 替代物——本產品與替代物相比如何？（例如，8. 競爭對手的產品、服9. 務或解決方案）
10. 失敗結果——如果質量比GEQ稍11. 差一些會怎樣？是否需要對突發事件進行規劃？
12. 評估質量——評估本身的可信度如何？是否令人滿意？
顯然，滿意質量決不等同于平庸，它強調的是理性的選擇，而不是強制性行為。如果按照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/
