發表者

討論內容

冷日
(冷日)

發表時間：2008/3/14 9:14

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[轉貼]一個愚蠢農夫和奶牛的故事: 一個愚蠢農夫和奶牛的故事－轉載

Ivar Jacobson博士
他被認為是影響或改變了整個軟件工業開發模式的幾位世界級大師之一，是軟件方法論的一面」旗幟」。他是組件和組件架構、用例、現代業務工程、Rational統一過程等業界主流方法或技術的創始人。
Ivar Jacobson博士認為，如果採用不良的軟件過程，通過CMM/CMMI的成熟度級別越高，只會使軟件企業生產不合格軟件的過程更加有效率，而不是使企業開發出更好的軟件。
軟件外包是時下的一個熱門話題，被我國不少軟件企業視為一座金礦，而CMM被人們認為是進入這個市場的敲門磚，為了拿到那張代表資格的CMM認證證書，不少企業甚至不惜投入數百萬之巨。事實上，拿到CMM認證在國外並不代表企業就能提供一個合格的軟件，著名的軟件專家、擁有組件技術、用例技術等多項發明、與Grady Booch、James Rumbaugh一起被稱為UML之父的Ivar Jacobson博士在近期訪華期間一再提醒中國的軟件企業，謹防掉入CMM陷阱。

CMM/CMMI的缺點
CMM/CMMI最早起源於美國國防部。為了改變在採購過程中頻繁地採購到大量不合格軟件的局面，美國國防部需要一種評估軟件質量的方法，這就是要求軟件企業進行CMM/CMMI認證。然而，CMM/CMMI真正解決這個問題了嗎？
CMM/CMMI被認為是一種最成熟、最有效地提高軟件工程化水平的方法和標準，用來評估和改進過程，它是一個描述在軟件開發過程中有待改進的關鍵因素的框架，描述了一個能用漸進方式進行改進的途徑。它為軟件過程改進提供一個基礎，將軟件開發從一個相對來說隨意、不成熟的過程變成非常成熟的、有規律的、可管理的過程。
然而，CMM/CMMI也有一些與身俱來的缺點不容忽視。比如，CMM/CMMI的評估耗資不菲，一個CMM2級評估就可能達到數百萬之巨，而且耗時很長，過程十分複雜，常常導致效果不太理想。不少企業的認證流於形式，評估完成後就只留下一大堆文檔，而真正的軟件開發過程卻依然故我。而且，CMM/CMMI只告訴我們應該怎麼做，而沒有具體地告訴如何做。比如說，它要求必須改進需求管理，那麼到底該如何做需求管理？CMM/CMMI沒有提供答案。
還有最重要的一點是，不少軟件企業陷入了一個誤區，以為單單通過CMM/CMMI評估就可以解決軟件質量不高的問題，而忽略了軟件過程這一真正改善軟件質量的環節。事實上，完全有可能出現這樣的情況: 軟件成熟度為CMM 1級或2級的企業開發出的軟件是真正好用的，而有的企業即使通過了CMM 5級認證，也無法保證它交付好的軟件。最糟糕的情形是，如果採用不好的軟件過程，通過CMM/CMMI的成熟度級別越高，只會使軟件企業生產差勁軟件的過程變得更加有效率，而不是使企業開發出更好的軟件。
Ivar Jacobson認為,好的軟件過程首先一定是基於組件的,在此基礎之上,還要符合迭代開發、用例驅動開發和以架構為中心的這三個最佳實踐。

合理的軟件過程是軟件質量的基礎
為什麼會是這樣呢，Ivar Jacobson舉了一個非常形象的例子。這是一個農夫和他的奶牛的故事。在奶牛喝水的途中（稱為」牛路」）有一片莊稼地，牛會吃掉很多莊稼。農夫看到這種情況後，意識到必須對奶牛喝水的過程進行改進，所以他就在這條道路上鋪上了瀝青。結果，農夫得到了一個好的」牛路」，牛走得更快了，但是並沒有真正解決牛吃莊稼的問題。它應該有更好的方式，就是為牛喝水尋找一條全新的道路。
軟件企業利用CMM框架進行軟件質量控制的過程，就像是這個農夫為牛路鋪瀝青。對於軟件企業來說，如果從一個錯誤的軟件過程開始，即使你在這個上面再改進，得到的永遠只是」牛路」。這裡更應該考慮的是要選擇一條更好的路，也就是從一開始時，就採用能夠開發出好的軟件的過程。然後在這個軟件過程的基礎上，對這個軟件進行度量，改進這個軟件的過程,也就是進行CMM/CMMI要求的改進。
Ivar Jacobson博士認為，從一個不良的軟件過程出發，在此基礎上進行改進，實際上會把軟件開發變得更糟糕，因為你把軟件開發過程固化了，使日後再想對它進行改造，變得更加困難。正確的方法是，先要有一個好的軟件過程，這是不容易的，但是值得做的事情。
Ivar Jacobson 說，」把一個好的軟件過程變得可度量非常容易，但是把一個可度量的軟件過程變成一個好的軟件過程卻很難」。也就是說，只有把一個好的軟件過程，即能夠開發出好的軟件的過程變得可度量才是有益的。而把一個已經經過CMMI改進的、可度量的過程變成一個真正的能夠開發出好軟件的過程，這是幾乎不可能的事情。

那麼什麼是一個好的軟件過程？Ivar Jacobson建議從以下幾個方面進行辨別:
1 壞的過程關注文檔上，而好的過程關注在可執行的程序或者系統上;
2 壞的過程延誤了揭露風險的時間，而好的過程一開始就把自己暴露在風險之下，並及時解決它;
3 壞的過程在項目的最後才能夠驗證這個項目的質量，而好的過程其質量是每時每刻都能夠得到驗證的;
4 壞的過程有一個非常複雜的跟蹤關係矩陣，從需求到代碼需要一個非常複雜的矩陣，而好的過程，卻是一個無縫鏈接;
5 在面對變更時，壞的軟件很脆弱，好的軟件會很健壯。
Ivar Jacobson提醒軟件開發人員要做聰明的農夫，首先得到一個正確的軟件過程; 然後，再考慮去度量它、定義它。因為軟件項目管理的本質不是能否描述並度量軟件過程以及過程到底怎麼樣，而是首先關注軟件，你是否能很好地開發出合格軟件。重點是得到結果，通過軟件過程得到這個結果，也就是交付的軟件產品。

觀點碰撞
敏捷開發企圖終結軟件危機
如今在軟件開發領域佔絕對主流地位的傳統軟件工程學思想是大約在20世紀60年代伴隨著」軟件危機」言論的出現而誕生的。所謂軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題，它包含兩方面內容：一是如何開發軟件，以滿足不斷增長、日趨複雜的需求；二是如何維護數量不斷膨脹的軟件產品。的確，傳統軟件工程學思想的誕生，把軟件開發活動按照工程化的原則和方法進行組織，並一度被認為是擺脫軟件危機的一個主要出路。
但是，數十年後的今天，人們對於軟件危機的」恐懼」仍沒有絲毫減弱，相反隨著軟件系統的急速膨脹而越發不可收拾了：對軟件開發成本和進度的估計常常不準確，開發成本超出預算，實際進度比預定計劃一再拖延的現象並不罕見；用戶對」已完成」系統不滿意的現象也經常發生；軟件產品的質量往往靠不住，Bug一大堆，補丁一個接一個；等等。於是，無論是產業界還是理論界，都開始對傳統軟件工程學思想產生懷疑，甚至背叛。因此，關於軟件到底是」工程」還是」藝術」的討論一度風靡全球。而以迭代式循序漸進開發方式為主，以」人」為核心的敏捷開發方法就是在這樣的背景下產生的，它背叛了傳統軟件工程學中以」過程」為核心，把設計和開發盡可能分開，盡量弱化」人」在整個工程中地位的思想。
近日，當世界軟件開發領域最具影響力的五位大師之一、敏捷軟件開發方法的早期開拓者馬丁·福勒先生來華與國內軟件高手論道之際，北京大學軟件學院院長陣鍾老師再次將軟件是」工程」還是」藝術」這一問題擺到了桌面上。而這位軟件教父似乎對這一問題早有深入思考，他認為，這一爭論的核心應該在於軟件設計是否要與軟件開發分開，這也正是傳統工程化軟件開發方法與敏捷軟件開發方法的重要區別。
作為敏捷軟件開發方法的推動者，馬丁先生認為，軟件設計應該和軟件開發緊密結合在一起，採用迭代式開發。軟件開發不能被認為是一個既定的過程，因為軟件開發中有太多的變化出現，既定的過程設置不可能達到合適的預想結果。由於需求變化、技術更新、人員流動等問題的存在，許多軟件設計工作應該在軟件開發到一定程度的時候才能進行，兩者不應該在順序上嚴格分開。他說:」至於從哲學的角度講，到底軟件開發活動是藝術還是工程呢？我很難清晰地界定，也許都是或者都不是。也許我們應該把軟件開發活動當做一個獨立的東西來對待。」
由此看來，馬丁先生既不認為軟件開發活動應該是一個先進行設計，然後根據「設計圖紙」進行構建的工程化過程，也不認為軟件開發應該是完全依賴於開發者頭腦中隨時蹦出的靈感的藝術活動，因為這兩種傾向在人類數十年的軟件開發實踐中已經被證明都不甚完美。而他企圖在兩者之間找到一個均衡點，這個均衡點也許正是真正解決」軟件危機」的突破口。
據瞭解，敏捷開發實際上包括了許多優秀的軟件開發習慣。首先，這種方法改變了軟件測試的流程，在編寫代碼前進行測試，減少了開發風險；其次，可以對軟件進行持續集成，即每個小時都在集成，任何部件間的衝突都可以隨時解決；此外，這種方法的」動態規劃」和」重構」做法，意味著開發者可以對軟件架構進行持續改進，可以根據用戶的需求隨時進行改進，而利用傳統的軟件開發方法則很難對軟件的架構進行調整，同時也會造成成本的大幅增加。

回覆

主題一覽的下方

討論串

前一個主題 | 下一個主題 | 頁首 |

| |

發表新主題

軟工藝術 : [轉貼]一個愚蠢農夫和奶牛的故事