所謂“重”方法，就是指形式化的、戒律森嚴的軟件工程方法學——不僅指這些方法所生成紙文檔重量，還意指管理資源投入、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 Berners-Lee在構建WWW的初始版本和瀏覽器的第一個草樣時又該如何考慮呢?讓他寫出詳細需求的意義何在呢?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
