軟體工廠簡介—自MSDN

軟體工廠簡介

Microsoft Corporation

擴大軟體開發的規模

從目前的情況來看，軟體開發的速度緩慢、代價高昂而又極易出錯，常常會生產出存在大量缺陷的產品，在可用性、可靠性、效能、安全以及其他服務品質方面造成嚴重的問題。

根 據 Standish Group [Sta94] 的統計，美國公司每年投資約 175,000 個軟體開發項目，投資額約為 2,500
億美元。這些項目中只有 16％ 能夠在預算內按計劃完成。另有 31％ 的項目主要由於品質問題而被取消，經濟損失約為 810 億美元。另外
53％ 的項目平均超出預算 189％，經濟損失約為 590 億美元。完成的項目平均只實現了原來規劃的功能的 42％。

這些數字客觀地印證了我們根據經驗所做出的判斷，那就是軟體開發是一項勞動密集型的產業，它創造每一美元的價值所消耗的人力資本超過了我們對於一個現代化行業的期望值。

當
然，除了這些缺點以外，軟體開發的成果顯然為消費者帶來了巨大的價值，正如需求增長的長期趨勢所表明的那樣。但這並不意味著消費者已經非常滿意，不管是對
我們提供的軟體，還是對我們提供軟體的方式。這隻是說明他們確實看好軟體的前景，願意承擔巨大的風險和損失，以此來獲得軟體所帶來的好處。然而，正如軟體
開發的外包越來越受歡迎所表明的，這種情況顯然不是最好的，因為它似乎不能推動軟體行業在軟體開發方法和實踐方面作出重大的改變。

在過去十年中，生產率只獲得了有限的提高，最重要的原因可能是採用了位元組編碼的語言、模式和靈活的方法。除了這些進步，我們開發軟體的方法與十年前沒有什麼不同。我們的方法和實踐實際上沒有太大的改變，相應的成本和風險同樣也沒有太大的改變。

然
而，這種情況就要被改變。據預測，全球對軟體的總體需求將在下一個十年中以數量級的速度增長，這是由於受到全球經濟中的新生力量（例如中國的崛起）的推
動，以及由於新的應用類型（例如商業整合和醫學資訊科學）和新的平台技術（例如 Web
服務、行動裝置和智能產品）而使軟體在社會基礎結構中的作用日益加大。

如果軟體開發能力沒有相應的增長，那麼十年後勢必出現總體軟體開發能力大大低於總體需求的局面。當然，如果市場力量能夠自由運作，這種情況不會真正出現，因為受到啟發的軟體供應商將出於個人利益而提供足夠多的軟體來滿足這種需求。

返回頁首

再次面對新的挑戰

那麼，怎樣才能提供足夠多的軟體開發能力呢？不用太多的分析就可以看出，必須對軟體開發的方法和實踐進行顯著的改變。

因為行業的生產能力取決於合格開發人員的數量以及開發人員的工作效率，因此提高行業生產能力的方法是，或者繼續採用現有的方法和實踐而投入更多的開發人員，或者保持相當數量的開發人員而採用不同的方法和實踐。

儘管過去十年間培育起來的學徒制似乎已經成功地增加了合格開發人員的數量並提高了開發人員的平均水平，但至少有兩個理由可以說明學徒制不大可能使軟體行業的生產能力滿足預期的需求水平：

•	經驗告訴我們，沒有什麼比擁有一些傑出的程式員更重要。傑出開發人員比蹩腳開發人員的工作效率高一千倍，但蹩腳開發人員的數量也幾乎是傑出開發人員的一千倍 [Boe81]。
•	Brooks [Bro95] 指出，增加項目人數最終會導致邊際收入減少。通過招募和培訓新開發人員而獲得的生產能力將逐漸下降。

因此解決問題的出路應是改變我們的方法和實踐。我們必須通過各種途徑提高開發人員的工作效率。

返回頁首

創新曲線與模式轉變

作
為一個行業，我們從一開始就需要共同面對這種情況。軟體開發的曆史是一個與複雜和變化作鬥爭的過程，時而盈利時而虧損，隨著時代的進步而產生更多的需求。
雖然僅僅半個世紀就取得了不少輝煌的成績，然而道路並不平坦。相反，軟體開發一直沿著著名的創新曲線模式在前進， 1 所示 [Chr97]。

圖 1：創新曲線

典
型的情況是，一個不連續的創新為一個新的技術時代奠定基礎。新基礎之上的發展一開始是快速的，但隨著基礎的穩固和成熟，發展速度逐漸慢下來。最後，這個基
礎失去了繼續創新的能力，達到發展的頂峰。同時，另一個不連續的創新為另一個新技術時代的到來奠定基礎，於是上述模式得以重複。Kuhn
稱上述基礎為模式，稱它們之間的轉變為模式轉變 [Kuh70]。模式轉變發生在需要改變現狀以繼續前進的交匯時刻。我們現在正處在這樣一個交匯時刻。

返回頁首

提高抽象水平

在
曆史上，模式的轉變曾經成功地提高了開發人員的抽象水平，為在平台和語言中獲得知識並重複利用知識提供了強大的概念。例如，在平台方面，我們從批處理開
始，經曆了終端/主機、客戶機/伺服器、個人計算、多層系統和公司專屬應用程式整合，再到非同步、鬆散耦合的服務。在語言方面，我們從數字編碼語言開始，經曆了彙編
語言、結構化語言和物件導向的語言，再到位元組編碼的語言和模式，這可以看作是基於語言的抽象。Smith 和 Stotts
對此進步作了意味深長的總結 [SS02]：

編程的曆史是在體繫結構抽象方面的一種鍛煉。在每個時代，語言設計人員通過總結上一代的經驗教訓創造出結構，然後體繫結構設計師使用這些結構創造出更複雜，更強大的抽象。

他
們還指出，新的抽象一般先出現在平台上，然後移植到語言中。我們現在的情況是，基於語言的抽象已遠遠落後基於平台的抽象。換句話說，現在是工具遠遠落後於
平台。我們現在正在使用最新的平台技術（例如，通過採用配樂法編寫服務，我們現在能夠使位於這個星球上任何位置的多個企業間的進程自動化），但我們仍然在
手動編寫每個應用程式，好象這是首選的方法一樣。我們從小的具體概念（例如迴圈、字串和整數）入手來創造大的抽象概念（例如保險索賠和證券交易）。我們
勤勤懇懇一絲不苟地工作，將上百萬小的相關原始碼片段和資源群組合在一起，形成巨大而複雜的結構。如果半導體行業也採用類似的做法，他們需要用手焊接晶體管
來建立起支援這些應用程式的巨大而複雜的處理器。相反，他們通過組裝稱為特定用途整合電路 (ASIC) 的預定義組件，使用 2
所示的工具來完成實現。

圖 2：基於 ASIC 的設計工具7

難 道我們不能採用類似的方式來實現軟體開發的自動化嗎？當然能，而且實際上我們已經在這樣做。例如，資料庫管理系統通過 SQL
實現資料訪問自動化，提供了諸如Data Integration和獨立性等優點，使資料驅動的應用程式更易於建立和維護。與此類似，Widget 架構和 WYSIWYG
編輯器使得建立和維護圖形化使用者介面更容易，提供了諸如裝置獨立性和可視化組裝等優點。仔細分析這些做法，我們可以發現一個反覆出現的模式。

•	在給定問題領域開發出大量系統之後，我們為該領域確定一組可以重複利用的抽象，然後我們制訂一組模式，規定如何使用這些抽象。
•	然後我們開發一個運行時（例如架構或伺服器），將這些抽象和模式代碼化。這樣，我們可以通過對運行時所定義的組件執行個體化、調整、配置和組裝，從而在該領域中建立系統。
•	然後我們定義一種語言並建立支援該語言的工具（例如編輯器、編譯器和調試器），使組裝過程自動化。這樣可以協助我們對不斷變化的要求做出快速響應，因為部分實現已經完成，而且可以輕鬆地加以修改。

這 就是 Roberts 和 Johnson [RJ96]
所描述的著名的“語言架構”模式。一個架構可以按數量級降低開發一個應用程式的成本，但只使用一個架構則很困難。一個架構定義一種具有某種典型體繫結構的
產品（例如應用程式或子系統），這些產品可以通過各種方式進行完善和專門化的處理，以滿足不同的要求。將每種產品的要求映射到架構中絕不是一個小問題，通
常需要藉助於體繫結構設計師或進階開發人員的專業技能。通過使用語言運算式捕獲各種要求，然後產生架構完成代碼，基於語言的工具可以自動完成此過程。

返回頁首

實現軟體開發的產業化

在
其他行業，提高生產能力的途經是從手工作業過渡到機械生產。在手工作業階段，所有產品都是由個人或小組從無到有製造出來的，而在機械生產階段，各種產品通
過組裝多家供應商生產的可重複利用的組件迅速生產出來，在這個過程中，許多機械瑣碎的任務都是由機器自動完成的。這些行業對工藝、設計和封裝進行標準化，
藉助產品線實現系統性重複利用，並通過供應鏈分擔成本和風險。現在已有部分行業可以實現大規模定製，根據需求快速而經濟地製造出各種產品，以滿足不同客戶
的特定要求。

返回頁首

軟體能夠實現產業化嗎？

人們對軟體與實物之間的類比進行過熱烈的討論。這些產業化模式能夠應用於軟體行業嗎？難道軟體行業沒有因其產品性質的不同而比其他行業特殊嗎？Peter Wegner 對它們之間的異同總結如下 [Weg78]：

軟
件產品在某些方面與傳統工程學科中的有形產品（如橋樑、建築物和電腦）存在相似之處。但也存在某些重要的區別，使得軟體開發與眾不同。由於軟體是邏輯概
念而非實物，因此其成本集中在開發過程中而不是生產過程中。又因為軟體不會磨損，因此其可靠性取決於邏輯品質（如正確性和穩健性）而非物理品質（如硬度和
韌性）。

有些討論將實物的生產與軟體的開發比作“蘋果與桔子”。理清這些困擾的關鍵是理解生產和開發之間的不同，以及規模經濟與範圍經濟的不同。

為
了獲得投資回報，必須盡最大可能重複利用那些可重複利用的組件而不僅僅是收回開發成本，無論是直接通過降低成本，還是間接通過降低風險、縮短進入市場的時
間或改進品質來實現。從投資角度講，可重複利用的組件屬於金融資產。由於為使組件可重複利用而耗費的成本通常非常高，很難達到可獲利的重複利用程度，因此
需要有一種系統的方法來實現重複利用。這通常包括確定一個要開發多個系統的領域，找出該領域中重現出現的問題，開發出一套解決該問題的整合生產資產，然後
將這些資產應用到在該領域中開發系統的過程中。

返回頁首

規模經濟與範圍經濟

系統性重複利用可以同時產生規模經濟和範圍經濟的效應。這兩種效應在其他行業廣為人知。儘管二者都是通過集中而非單獨生產多個產品來減少時間和降低成本並提高產品品質，但二者在產生這些優點的方式上卻存在著不同。

當 集中而非單獨生產一個設計的多個相同執行個體時，就產生了規模經濟， 3
所示。規模經濟可能出現在生產機器螺釘等產品時，在這種生產過程中，可以使用機床等生產資產生產出多個相同的產品執行個體。工程師通過一種資源密集的過程（稱
為開發）完成設計與最初的執行個體（稱為原型）。然後通過另一個由機器和/或低成本勞動力完成的過程（稱為生產）創造出更多執行個體（稱為複製品），以滿足市場需
要。

圖 3：規模經濟

範 圍經濟通過集中而非單獨生產多個相似但不同的設計和原型而實現， 4
所示。例如在汽車製造業，多個相似但不同的汽車設計通常是通過組合子組件（如底盤、車體、內部裝飾及傳動裝置）的現有設計來開發的，而不同的款式或型號通
常是通過改變現有設計中的某些功能（如發動機和裝飾水平）來產生的。換言之，可以使用相同的方法、工藝、工具和材料設計出多個相似但不相同的產品，並製作
出相似但不相同的原型。商業建築同樣如此，很少看到多座橋樑或多幢摩天大廣告採用同一種設計。但商業建築領域存在一個有趣的現象，即每個成功的設計通常只會
產生一兩個執行個體，因而規模經濟幾乎從未真正實現過。在汽車製造業，通常會從成功的設計產生出許多不同的執行個體，通過複製每個原型，範圍經濟與規模經濟形成互
補， 4 所示。

圖 4：範圍經濟

當然，軟體無論與汽車製造還是與商業建築之間都存在重要區別，但它們常常有著相似的地方。

•	在諸如使用者案頭產品之類的市場中，作業系統和工作效率應用程式等產品通過複製形成批量生產，軟體行業呈現出規模經濟的特點，如同在汽車製造業中一樣。
•	而在諸如企業使用者產品之類的市場中，為獲得競爭優勢而開發的商務應用程式很少能夠進行批量生產，軟體僅呈現出範圍經濟的特點，如同在商業建築領域中一樣。

現在我們可以清楚地看到蘋果與桔子之間的區別了。將實物行業的生產與軟體開發進行比較未免有些天真。不管是軟體還是實物，在任何類型的開發中尋求規模經濟效果都是沒有意義的。但是，我們卻可以期待軟體開發的產業化能夠帶來範圍經濟的效果。

返回頁首

產業化會帶來什麼樣的結果？

假
設可以在軟體行業實現產業化，那麼結果將會是什麼樣子呢？當然，在事情發生之前我們不可能確切地知道。但是，我們可以根據軟體行業的發展道路以及其他行業
產業化後的情形作出合理的推測。顯然，軟體開發永遠不會簡單到懶人們所希望的那種純機械化的程度。相反，滿足全球需求的關鍵是不要再把傑出開發人員的時間
浪費在機械瑣碎的任務上。我們必須盡一切努力更好地利用這些稀有資源，不要再讓他們把時間花費在手動構造因為下一個主要平台版本的出現或者市場條件的變化
而致使行業需求改變進而導致短短几個月或幾年內就需要維護甚至替換掉的最終產品上。

實現此目的的方法之一就是為開發人員提供各種途經，使他
們能夠將自己的知識轉化成可供他人重複利用的資產。這個目標是否遙遙無期？有些模式已經表現出重複利用知識的有效性，儘管利用程度不高。下一步是使用語
言、架構和工具自動產生模式化的應用程式，從而實現從編程到自動化的飛越。

半導體開發為軟體開發實現產業化後的情形提供了預演。這並不是說 軟體組件很快就能象 ASIC 那樣易於組裝，ASIC
是經過封裝和介面技術領域二十年的創新和標準化而開發出來的產品。但另一方面，軟體開發可能用不了 20
年。軟體開發的優勢在於只需要處理位元，而半導體行業還需要承擔組件實現所需的物理材料工程的額外負擔。與此同時，位元所固有的短壽特性也為諸如數字知識
產權保護等帶來了難題，正如我們在電影和音樂行業所看到的那樣。

返回頁首

結論

本
文描述了軟體行業在利用現有方法和實踐來面對預期需求上的無能為力。這裡只對許多問題進行了簡要敘述，無疑會引發讀者尋求證據或更多詳細的討論。要獲得更
詳細的討論，請參閱此書 Software Factories: Assembling Applications with Patterns,
Models, Frameworks and Tools，此書的作者為 Jack Greenfield 和 Keith Short，由
John Wiley and Sons 出版社出版。有關詳細資料，也可以訪問 http://msdn.microsoft.com/architecture/overview/softwarefactories 和 http://www.softwarefactories.com/，這裡提供了各種文章，介紹了阻止從手工作業向機械生產轉換的長期問題、協助行業克服這些問題的重大創新以及整合了重大創新的軟體工廠方法。

著作權聲明

著作權 2004 Jack Greenfield。 部分著作權 2003 Jack Greenfield 和 Keith Short，已從 Wiley Publishing Inc. 獲准再版。著作權所有，並保留一切權利。

參考資料

1.	[Boe81] B Boehm.Software Engineering Economics.Prentice Hall PTR, 1981
2.	[Bro95] F Brooks.The Mythical Man-Month.Addison-Wesley, 1995
3.	[Chr97] C Christensen.The Innovator's Dilemma, Harvard Business School Press, 1997
4.	[Kuh70] T Kuhn.The Structure Of Scientific Revolutions.The University Of Chicago Press, 1970
5.	[RJ96] D Roberts and R. Johnson. Evolving Frameworks:A Pattern Language for Developing Object-Oriented Frameworks.Proceedings of Pattern Languages of Programs, Allerton Park, Illinois, September 1996
6.	[SS02] J. Smith and D Stotts.Elemental Design Patterns – A Link Between Architecture and Object Semantics.Proceedings of OOPSLA 2002
7.	本 圖利用 Virtuoso Chip Editor 和 Virtuoso XL Layout Editor 產生，並得到了 Cadence Design Systems, Inc. 的許可。 著作權 2003 Cadence Design Systems, Inc.。著作權所有，並保留一切權利。Cadence 和 Virtuoso 是 Cadence Design Systems, Inc. 的註冊商標。
8.	[Sta94] The Standish Group.The Chaos Report.http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf
9.	[Weg78] P Wegner.Research Directions In Software Technology.Proceedings Of The 3rd International Conference On Software Engineering. 1978

作者簡介

Jack Greenfield 是 Microsoft 公司負責開發企業架構和工具的體繫結構設計師。他曾擔任 Rational
Software Corporation 公司 Practitioner Desktop Group 小組的主要體繫結構設計師，他還是
InLine Software Corporation 公司的創始人和首席技術官。他曾在 NeXT 開發了企業對象架構，現在稱為 Apple
Web Object。他是著名的演講者和作家，同時他還對 UML、J2EE 及相關的 OMG 和 JSP 規範做出過很大貢獻。他擁有
George Mason University 物理學學士學位。可通過 jackgr@microsoft.com 與 Jack 獲得聯絡。