隨著軟件工業(yè)不斷發(fā)展，各種各樣的模型不斷涌現(xiàn)或退出歷史舞臺(tái)。早期從不同角度提出的各種設(shè)計(jì)表示方法(常常以發(fā)明者的名字來(lái)命名)目前似乎已經(jīng)聚合成為UML這種被廣泛接受的標(biāo)準(zhǔn)，結(jié)構(gòu)化設(shè)計(jì)方法也正在讓位于面向?qū)ο笤O(shè)計(jì)等更受歡迎的方法學(xué)，這種變化在更高層次的全局性開發(fā)方法學(xué)方面同樣進(jìn)行著。
傳統(tǒng)意義上的軟件方法學(xué)描述通?！澳軌颉碧幚砣魏未笮〉?a href="http://opto-elec.com.cn/" target="_blank">項(xiàng)目，而實(shí)際上真正的困難就來(lái)自于如何對(duì)這些方法加以裁剪以適合較小的項(xiàng)目。針對(duì)這種理論與實(shí)際的脫節(jié)現(xiàn)象，國(guó)際上一些著名的軟件工程專家提出所謂“重(heavy)”方法和“輕(light)” 方法之分，試圖為快速發(fā)展的軟件工業(yè)探尋更切合實(shí)際的解決方法。
所謂“重”方法，就是指形式化的、戒律森嚴(yán)的軟件工程方法學(xué)——不僅指這些方法所生成紙文檔重量，還意指管理資源投入、QA評(píng)審的程度和開發(fā)人員被要求遵守的嚴(yán)格流程。相對(duì)的，諸如快速應(yīng)用開發(fā)(Rapid Application Development，簡(jiǎn)記為RAD)和原型方法等則可以被稱為“輕”方法——不僅是因?yàn)檫@些方法傾向于產(chǎn)生最小數(shù)量的紙文檔，還因?yàn)槠鋵⒐芾碣Y源投入最小化。不幸的是，1990年代的許多RAD項(xiàng)目在方法學(xué)上采取了過(guò)“輕”的處理以至于幾乎不存在什么方法，這些項(xiàng)目常常退化為雜湊式作坊開發(fā)，實(shí)質(zhì)上根本沒(méi)有任何文檔。 顯然，需要在兩種極端方法之間找到平衡點(diǎn)。
輕方法代表了一種有意識(shí)的風(fēng)險(xiǎn)防護(hù)方法，依據(jù)不同風(fēng)險(xiǎn)在與開發(fā)相關(guān)的各種活動(dòng)中投入相應(yīng)時(shí)間、資金和資源。例如，進(jìn)行多少需求分析工作才算是過(guò)多，擬或過(guò)少?針對(duì)一個(gè)幾百個(gè)需求的開發(fā)項(xiàng)目而言，一個(gè)需求分析“輕”方法(requirements-light approach)可能是由將每一個(gè)需求通過(guò)一個(gè)簡(jiǎn)潔的句子加以文檔化的行為所組成，一個(gè)需求分析“中”方法(requirements-medium approach)可能要求對(duì)每個(gè)需求通過(guò)一段描述性文本來(lái)文檔化，而一個(gè)需求分析“重”方法(requirements-heavy approach)則可能要求詳細(xì)的UML模型、數(shù)據(jù)元素定義和每個(gè)對(duì)象方法的形式化描述。
究竟選擇需求分析的“輕”方法還是“重”方法很大程度上受到公司產(chǎn)品上市時(shí)間或合同期限壓力的影響。同時(shí)，公司雇員的流動(dòng)率也是一種影響因素：作為形式化開發(fā)過(guò)程的理由之一認(rèn)為，如果有一份詳細(xì)的文檔來(lái)記錄需求、設(shè)計(jì)和編碼，那么一旦在項(xiàng)目進(jìn)行中關(guān)鍵開發(fā)成員離職所造成的混亂將會(huì)被盡量減小。
然而，盡管1970年代和1980年代的系統(tǒng)生命周期預(yù)期為十年或二十年，也許Interbet時(shí)代的網(wǎng)絡(luò)公司更愿意正式承諾其電子商務(wù)應(yīng)用僅持續(xù)一年，然后被廢棄或完全重寫。如果正是這種情況，并且如果下一代應(yīng)用預(yù)期與當(dāng)前應(yīng)用存在質(zhì)的差異，那么僅僅為了達(dá)到SCM-CMM三級(jí)就遵循需求分析“重”方法還真的有意義嗎?
同樣地，針對(duì)設(shè)計(jì)和測(cè)試工作采用什么樣的形式化和嚴(yán)格程度才是合適的呢?與項(xiàng)目管理有關(guān)的時(shí)間匯報(bào)、進(jìn)展匯報(bào)、狀態(tài)會(huì)議及其他常見活動(dòng)又如何呢——尤其針對(duì)那些僅持續(xù)一周或兩周的項(xiàng)目?這些問(wèn)題總是相互關(guān)聯(lián)的，但是一些傳統(tǒng)上被接受的答案卻需要至少每隔幾年重新審視一下，因?yàn)槌杀?收益參數(shù)正在隨著商業(yè)環(huán)境、技術(shù)和軟件開發(fā)人員的變化而不斷變化。
輕方法還重新審視了歷史上有關(guān)投入資源在需求分析的假定，以及投入資源在過(guò)程改進(jìn)的假定。1981年Barry Boehm在他的經(jīng)典著作“軟件工程經(jīng)濟(jì)學(xué)”(Software Engineering Economics)中指出了一項(xiàng)驚人發(fā)現(xiàn)，即如果我們?cè)陧?xiàng)目的系統(tǒng)分析階