“輕”方法與滿意質量——市場驅動的軟體工程實踐 (轉)

“輕”方法與滿意質量——市場驅動的軟體工程實踐 (轉)[@more@]

“輕”方法與滿意質量——市場的工程實踐

共創軟體聯盟

（本文轉載自軟體工程專家網）

?page=/bbs/index.asp?Type=H" target=_blank> 　　隨著資訊科技的迅猛發展，今天的IT從業人員正處於這樣一種進退兩難的境地：一方面，根據以往的痛苦開發經歷，他們知道如果採用雜湊的作坊來開發複雜的、高質量的資訊具有太大的風險；另一方面，他們也同樣知道，形式化的、戒律森嚴的軟體工程方法（典型情況下是與ISO9000和SEI-CMM相關的）又常常是官僚主義和耗費時間的，不可能滿足目前高度競爭的“Inte時代”環境下對於進度方面不斷增長的挑戰性要求。顯然，如何使得企業在保證軟體質量的前提下，同時又能夠適應變化的市場需求，無疑是業內人士關注的焦點。為此，本文從市場驅動的IT開發特點分析入手，對目前國際上正日趨成熟的“輕”方法和滿意質量的內涵和操作加以討論，同時以快速應用開發為例項介紹了具體操作及注意事項，為讀者進一步深入理解現代軟體工程實踐工作提供幫助。

一、市場驅動的IT開發工作

　　當今的IT企業正處於一種前所未有的競爭環境之中，無論是作為獨立軟體供應商還是增殖服務商，也無論是開發直接面向市場的軟體產品如遊戲、工具、多等等，還是為定製軟體如電子商務應用、MIS等等，市場競爭都無處不在，IT開發工作被迫在市場驅動的狀態進行，具有以下典型特徵：
　　快速演變升級的基礎技術，必須及時跟蹤基礎技術的革新並調整策略。
　　持續的競爭，必須不斷推陳出新來滿足使用者需求。
　　時間就是金錢——需要在時間、質量、費用之間達成折衷。
　　從業人員聰明且教育程度高，能夠在一定範圍內進行自我管理。
　　以往流行於IT行業的設計—評審—構造模型已過時。IT業最新的技術和工具改變了以前專案執行所必須遵循的邏輯順序。比如：現在一些工具允許“即時”建立螢幕，使得冗長的設計—評審—構造模型不再適用，而要求一種更難於計劃的原型—稽核—構造—再稽核—再構造的過程。
　　角色重疊：現代技術和工具使原來專門的設計、分析、編碼人員之間嚴格的區分界限變的模糊。
　　以往的IT開發人員相對於當前市場驅動下的開發人員而言，至少擁有以下優勢：控制他們的應用開發技術。在傳統的企業應用開發中，機器和其他系統元素在實現階段就被指定。現在，這種優勢不復存在，很少有哪個系統被實現為在專用機器上的孤立應用。相反，他們經常是企業使用者機器上的另一種應用，必須與其他商業應用聯合使用，這使得IT開發人員不得不為保持與、Internet、或標準的變化相一致而疲於奔命。同時，持續的競爭、緊迫的進度和嚴格的預算讓IT開發經理不得不經常根據銷售人員或客戶的要求而調整開發工作。
　　顯然，市場驅動的新環境給IT開發帶來新的挑戰，如果照搬套用以往的成功和開發模式並非明智之舉，必須適應新形勢的要求，重新思考和定位。

二、“輕”方法浮出水面

　　隨著軟體工業不斷髮展，各種各樣的模型不斷湧現或退出歷史舞臺。早期從不同角度提出的各種設計表示方法（常常以發明者的名字來命名）目前似乎已經聚合成為UML這種被廣泛接受的標準，結構化設計方法也正在讓位於面向設計等更受歡迎的方法學，這種變化在更高層次的全域性性開發方法學方面同樣進行著。
　　傳統意義上的軟體方法學描述通常“能夠”處理任何大小的專案，而實際上真正的困難就來自於如何對這些方法加以裁剪以適合較小的專案。針對這種理論與實際的脫節現象，國際上一些著名的軟體工程專家提出所謂“重（heavy）”方法和“輕（light）” 方法之分，試圖為快速發展的軟體工業探尋更切合實際的解決方法。
　　所謂“重”方法，就是指形式化的、戒律森嚴的軟體工程方法學——不僅指這些方法所生成紙文件重量，還意指管理資源投入、QA評審的程度和開發人員被要求遵守的嚴格流程。相對的，諸如快速應用開發（Rd 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的需求時，可能他會說“就象 Navigator那樣，但要更好”，可能Netscape的Marc Andreesen也會這樣想：“我希望使Navigator就象Mosaic一樣，但要更好。”但是當Tim 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工具和開發方法。
　　在每次開發之前，簡要描述出每個開發週期中所需實現的功能模組。制定出在前一兩個開發週期中所需實現的功能特性是非常重要的，這包括確定實現具有高優先順序的基礎功能或關鍵功能，預測實現目標和潛在風險。
　　在每次開發之前，回顧需要在此階段實現或修改的每個功能，判斷它們是否同專案所要實現的目標一致。區分哪些功能是在這個階段中必須要實現的，哪些僅僅是希望實現的。
　　使用那些經驗豐富的、受人敬重的測試人員。
　　保證設計者和開發者密切聯絡，並使測試人員儘可能參與到開發過程中。
　　要求設計者和開發者完成各自的單元測試和適當的整合測試。
　　確定開發過程的安全警戒點，例如，當開發過程中未解決的問題超過了預計值時，應安排額外的時間進行產品修正，直到錯誤數量大大減少。
　　儘可能利用和調整已有測試工具，如迴歸測試平臺、已有測試用例等。
　　使用成熟的工具和自動化的測試工具以加速開發程式。
　　使客戶和終端使用者最大程度地參與容量測試，請使用者在日常工作中儘可能地並行使用該系統，並與上次開發週期交付的版本進行前後對比。
　　對需求和產品範圍的任何改變應慎重分析，測試人員應對所提出的改變可能產生的影響做出評價，並在證明是正當的情況下有權予以否決。
　　提醒使用者可能存在錯誤，培訓他們怎樣認識和報告錯誤，怎樣在這些錯誤下工作。
　　應用程式的每一次迴圈開發都應在版本控制下進行。
　　不允許未經過最小測試的新版本釋出。根據使用者反映、操作風險、故障等級、與上一版本相比最新改動的地方等因素來確定最小測試需求。
　　必要時，如果為了滿足有時間期限的下一次升級，可以考慮在準備釋出之前刪掉多的功能部分。
　　如果最新功能證明包含一個漏洞，則要提供給使用者一個返回原版本的機制。
　　應用軟體透過反覆的修正，會變得更穩定。或者至少特定功能或子系統會比其他部分更早些趨向穩定，作為系統穩定的部分，可使用自動測試工具進行更完全的測試。
　　釋出升級版本後不必對使用者所發現的小漏洞感到不安。這對於首次執行是很自然的問題，而且通常還將會有使使用者抱怨的地方。使用者應當理解軟體升級的原因完全是因為新生事物很少有完全正確的。應強調團隊合作。
　　透過探測或預測程式中可能發生錯誤的地方而避免關鍵點任務的失敗。
　　透過原型、標準、一致性檢查等減少走回頭路，利用風險預測技術來避免各種缺陷和風險。