隨著信息技術的迅猛發展，今天的IT從業人員正處于這樣一種進退兩難的境地：一方面，根據以往的痛苦開發經歷，他們知道如果采用雜湊的作坊模式來開發復雜的、高質量的信息系統具有太大的風險；另一方面，他們也同樣知道，形式化的、戒律森嚴的軟件工程方法（典型情況下是與ISO9000和SEI-CMM相關的）又常常是官僚主義和耗費時間的，不可能滿足目前高度競爭的“Inte.net時代”環境下對于進度方面不斷增長的挑戰性要求。顯然，如何使得企業在保證軟件質量的前提下，同時又能夠適應快速變化的市場需求，無疑是業內人士關注的焦點。為此，本文從市場驅動的IT開發特點分析入手，對目前國際上正日趨成熟的“輕”方法和滿意質量的內涵和操作加以討論，同時以快速應用開發為實例介紹了具體操作及注意事項，為讀者進一步深入理解現代軟件工程實踐工作提供幫助。
一、市場驅動的IT開發工作
當今的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三級就遵循需求分析“重”方法還真的有意義嗎？
文章來源于領測軟件測試網 http://www.kjueaiud.com/