發(fā)布日期 : 11/4/2004 | 更新日期 : 11/4/2004
Jack Greenfield
Microsoft Corporation
摘要：簡要介紹 Microsoft 開發(fā)軟件工廠這種方法的動機。所謂軟件工廠就是指為了支持某種特定應用程序的快速開發(fā)而配置的開發(fā)環(huán)境。軟件工廠從邏輯上講就是軟件開發(fā)方法和實踐的下一個發(fā)展階段。然而，通過引入產(chǎn)業(yè)化模式，軟件工廠勢必會改變軟件行業(yè)的現(xiàn)狀。
擴大軟件開發(fā)的規(guī)模
從目前的情況來看，軟件開發(fā)的速度緩慢、代價高昂而又極易出錯，常常會生產(chǎn)出存在大量缺陷的產(chǎn)品，在可用性、可靠性、性能、安全以及其他服務質(zhì)量方面造成嚴重的問題。
根據(jù) Standish Group [Sta94] 的統(tǒng)計，美國公司每年投資約 175,000 個軟件開發(fā)項目，投資額約為 2,500 億美元。這些項目中只有 16％ 能夠在預算內(nèi)按計劃完成。另有 31％ 的項目主要由于質(zhì)量問題而被取消，經(jīng)濟損失約為 810 億美元。另外 53％ 的項目平均超出預算 189％，經(jīng)濟損失約為 590 億美元。完成的項目平均只實現(xiàn)了原來規(guī)劃的功能的 42％。
這些數(shù)字客觀地印證了我們根據(jù)經(jīng)驗所做出的判斷，那就是軟件開發(fā)是一項勞動密集型的產(chǎn)業(yè)，它創(chuàng)造每一美元的價值所消耗的人力資本超過了我們對于一個現(xiàn)代化行業(yè)的期望值。
當然，除了這些缺點以外，軟件開發(fā)的成果顯然為消費者帶來了巨大的價值，正如需求增長的長期趨勢所表明的那樣。但這并不意味著消費者已經(jīng)非常滿意，不管是對我們提供的軟件，還是對我們提供軟件的方式。這只是說明他們確實看好軟件的前景，愿意承擔巨大的風險和損失，以此來獲得軟件所帶來的好處。然而，正如軟件開發(fā)的外包越來越受歡迎所表明的，這種情況顯然不是最好的，因為它似乎不能推動軟件行業(yè)在軟件開發(fā)方法和實踐方面作出重大的改變。
在過去十年中，生產(chǎn)率只獲得了有限的提高，最重要的原因可能是采用了字節(jié)編碼的語言、模式和靈活的方法。除了這些進步，我們開發(fā)軟件的方法與十年前沒有什么不同。我們的方法和實踐實際上沒有太大的改變，相應的成本和風險同樣也沒有太大的改變。
然而，這種情況就要被改變。據(jù)預測，全球?qū)浖目傮w需求將在下一個十年中以數(shù)量級的速度增長，這是由于受到全球經(jīng)濟中的新生力量（例如中國的崛起）的推動，以及由于新的應用類型（例如商業(yè)集成和醫(yī)學信息科學）和新的平臺技術（例如 Web 服務、移動設備和智能產(chǎn)品）而使軟件在社會基礎結構中的作用日益加大。
如果軟件開發(fā)能力沒有相應的增長，那么十年后勢必出現(xiàn)總體軟件開發(fā)能力大大低于總體需求的局面。當然，如果市場力量能夠自由運作，這種情況不會真正出現(xiàn)，因為受到啟發(fā)的軟件提供商將出于個人利益而提供足夠多的軟件來滿足這種需求。
再次面對新的挑戰(zhàn)
那么，怎樣才能提供足夠多的軟件開發(fā)能力呢？不用太多的分析就可以看出，必須對軟件開發(fā)的方法和實踐進行顯著的改變。
因為行業(yè)的生產(chǎn)能力取決于合格開發(fā)人員的數(shù)量以及開發(fā)人員的工作效率，因此提高行業(yè)生產(chǎn)能力的方法是，或者繼續(xù)采用現(xiàn)有的方法和實踐而投入更多的開發(fā)人員，或者保持相當數(shù)量的開發(fā)人員而采用不同的方法和實踐。
盡管過去十年間培育起來的學徒制似乎已經(jīng)成功地增加了合格開發(fā)人員的數(shù)量并提高了開發(fā)人員的平均水平，但至少有兩個理由可以說明學徒制不大可能使軟件行業(yè)的生產(chǎn)能力滿足預期的需求水平：
因此解決問題的出路應是改變我們的方法和實踐。我們必須通過各種途徑提高開發(fā)人員的工作效率。
創(chuàng)新曲線與模式轉變
作為一個行業(yè)，我們從一開始就需要共同面對這種情況。軟件開發(fā)的歷史是一個與復雜和變化作斗爭的過程，時而盈利時而虧損，隨著時代的進步而產(chǎn)生更多的需求。雖然僅僅半個世紀就取得了不少輝煌的成績，然而道路并不平坦。相反，軟件開發(fā)一直沿著著名的創(chuàng)新曲線模式在前進，如圖 1 所示 [Chr97]。
圖 1：創(chuàng)新曲線
典型的情況是，一個不連續(xù)的創(chuàng)新為一個新的技術時代奠定基礎。新基礎之上的發(fā)展一開始是快速的，但隨著基礎的穩(wěn)固和成熟，發(fā)展速度逐漸慢下來。最后，這個基礎失去了繼續(xù)創(chuàng)新的能力，達到發(fā)展的頂峰。同時，另一個不連續(xù)的創(chuàng)新為另一個新技術時代的到來奠定基礎，于是上述模式得以重復。Kuhn 稱上述基礎為模式，稱它們之間的轉變?yōu)槟Ｊ睫D變 [Kuh70]。模式轉變發(fā)生在需要改變現(xiàn)狀以繼續(xù)前進的交匯時刻。我們現(xiàn)在正處在這樣一個交匯時刻。
提高抽象水平
在歷史上，模式的轉變曾經(jīng)成功地提高了開發(fā)人員的抽象水平，為在平臺和語言中獲得知識并重復利用知識提供了強大的概念。例如，在平臺方面，我們從批處理開始，經(jīng)歷了終端/主機、客戶機/服務器、個人計算、多層系統(tǒng)和企業(yè)應用集成，再到異步、松散耦合的服務。在語言方面，我們從數(shù)字編碼語言開始，經(jīng)歷了匯編語言、結構化語言和面向?qū)ο蟮恼Z言，再到字節(jié)編碼的語言和模式，這可以看作是基于語言的抽象。Smith 和 Stotts 對此進步作了意味深長的總結 [SS02]：
編程的歷史是在體系結構抽象方面的一種鍛煉。在每個時代，語言設計人員通過總結上一代的經(jīng)驗教訓創(chuàng)造出結構，然后體系結構設計師使用這些結構創(chuàng)造出更復雜，更強大的抽象。
他們還指出，新的抽象一般先出現(xiàn)在平臺上，然后移植到語言中。我們現(xiàn)在的情況是，基于語言的抽象已遠遠落后基于平臺的抽象。換句話說，現(xiàn)在是工具遠遠落后于平臺。我們現(xiàn)在正在使用最新的平臺技術（例如，通過采用配樂法編寫服務，我們現(xiàn)在能夠使位于這個星球上任何位置的多個企業(yè)間的進程自動化），但我們?nèi)匀辉谑謩泳帉懨總€應用程序，好象這是首選的方法一樣。我們從小的具體概念（例如循環(huán)、字符串和整數(shù)）入手來創(chuàng)造大的抽象概念（例如保險索賠和證券交易）。我們勤勤懇懇一絲不茍地工作，將上百萬小的相關源代碼片段和資源組合在一起，形成巨大而復雜的結構。如果半導體行業(yè)也采用類似的做法，他們需要用手焊接晶體管來建立起支持這些應用程序的巨大而復雜的處理器。相反，他們通過組裝稱為特定用途集成電路 (ASIC) 的預定義組件，使用如圖 2 所示的工具來完成實現(xiàn)。
圖 2：基于 ASIC 的設計工具7
難道我們不能采用類似的方式來實現(xiàn)軟件開發(fā)的自動化嗎？當然能，而且實際上我們已經(jīng)在這樣做。例如，數(shù)據(jù)庫管理系統(tǒng)通過 SQL 實現(xiàn)數(shù)據(jù)訪問自動化，提供了諸如數(shù)據(jù)集成和獨立性等優(yōu)點，使數(shù)據(jù)驅(qū)動的應用程序更易于創(chuàng)建和維護。與此類似，Widget 框架和 WYSIWYG 編輯器使得創(chuàng)建和維護圖形用戶界面更容易，提供了諸如設備獨立性和可視化組裝等優(yōu)點。仔細分析這些做法，我們可以發(fā)現(xiàn)一個反復出現(xiàn)的模式。
-
在給定問題領域開發(fā)出大量系統(tǒng)之后，我們?yōu)樵擃I域確定一組可以重復利用的抽象，然后我們制訂一組模式，規(guī)定如何使用這些抽象。
-
然后我們開發(fā)一個運行時（例如框架或服務器），將這些抽象和模式代碼化。這樣，我們可以通過對運行時所定義的組件實例化、調(diào)整、配置和組裝，從而在該領域中創(chuàng)建系統(tǒng)。
-
然后我們定義一種語言并創(chuàng)建支持該語言的工具（例如編輯器、編譯器和調(diào)試器），使組裝過程自動化。這樣可以幫助我們對不斷變化的要求做出快速響應，因為部分實現(xiàn)已經(jīng)完成，而且可以輕松地加以修改。
這就是 Roberts 和 Johnson [RJ96] 所描述的著名的“語言框架”模式。一個框架可以按數(shù)量級降低開發(fā)一個應用程序的成本，但只使用一個框架則很困難。一個框架定義一種具有某種典型體系結構的產(chǎn)品（例如應用程序或子系統(tǒng)），這些產(chǎn)品可以通過各種方式進行完善和專門化的處理，以滿足不同的要求。將每種產(chǎn)品的要求映射到框架中絕不是一個小問題，通常需要借助于體系結構設計師或高級開發(fā)人員的專業(yè)技能。通過使用語言表達式捕獲各種要求，然后生成框架完成代碼，基于語言的工具可以自動完成此過程。
實現(xiàn)軟件開發(fā)的產(chǎn)業(yè)化
在其他行業(yè)，提高生產(chǎn)能力的途經(jīng)是從手工作業(yè)過渡到機械生產(chǎn)。在手工作業(yè)階段，所有產(chǎn)品都是由個人或小組從無到有制造出來的，而在機械生產(chǎn)階段，各種產(chǎn)品通過組裝多家供應商生產(chǎn)的可重復利用的組件迅速生產(chǎn)出來，在這個過程中，許多機械瑣碎的任務都是由機器自動完成的。這些行業(yè)對工藝、設計和包裝進行標準化，借助產(chǎn)品線實現(xiàn)系統(tǒng)性重復利用，并通過供應鏈分擔成本和風險。現(xiàn)在已有部分行業(yè)可以實現(xiàn)大規(guī)模定制，根據(jù)需求快速而經(jīng)濟地制造出各種產(chǎn)品，以滿足不同客戶的特定要求。
軟件能夠?qū)崿F(xiàn)產(chǎn)業(yè)化嗎？
人們對軟件與實物之間的類比進行過熱烈的討論。這些產(chǎn)業(yè)化模式能夠應用于軟件行業(yè)嗎？難道軟件行業(yè)沒有因其產(chǎn)品性質(zhì)的不同而比其他行業(yè)特殊嗎？Peter Wegner 對它們之間的異同總結如下 [Weg78]：
軟件產(chǎn)品在某些方面與傳統(tǒng)工程學科中的有形產(chǎn)品（如橋梁、建筑物和計算機）存在相似之處。但也存在某些重要的區(qū)別，使得軟件開發(fā)與眾不同。由于軟件是邏輯概念而非實物，因此其成本集中在開發(fā)過程中而不是生產(chǎn)過程中。又因為軟件不會磨損，因此其可靠性取決于邏輯質(zhì)量（如正確性和穩(wěn)健性）而非物理質(zhì)量（如硬度和韌性）。
有些討論將實物的生產(chǎn)與軟件的開發(fā)比作“蘋果與桔子”。理清這些困擾的關鍵是理解生產(chǎn)和開發(fā)之間的不同，以及規(guī)模經(jīng)濟與范圍經(jīng)濟的不同。
為了獲得投資回報，必須盡最大可能重復利用那些可重復利用的組件而不僅僅是收回開發(fā)成本，無論是直接通過降低成本，還是間接通過降低風險、縮短進入市場的時間或改進質(zhì)量來實現(xiàn)。從投資角度講，可重復利用的組件屬于金融資產(chǎn)。由于為使組件可重復利用而耗費的成本通常非常高，很難達到可獲利的重復利用程度，因此需要有一種系統(tǒng)的方法來實現(xiàn)重復利用。這通常包括確定一個要開發(fā)多個系統(tǒng)的領域，找出該領域中重現(xiàn)出現(xiàn)的問題，開發(fā)出一套解決該問題的集成生產(chǎn)資產(chǎn)，然后將這些資產(chǎn)應用到在該領域中開發(fā)系統(tǒng)的過程中。
規(guī)模經(jīng)濟與范圍經(jīng)濟
系統(tǒng)性重復利用可以同時產(chǎn)生規(guī)模經(jīng)濟和范圍經(jīng)濟的效應。這兩種效應在其他行業(yè)廣為人知。盡管二者都是通過集中而非單獨生產(chǎn)多個產(chǎn)品來減少時間和降低成本并提高產(chǎn)品質(zhì)量，但二者在產(chǎn)生這些優(yōu)點的方式上卻存在著不同。
當集中而非單獨生產(chǎn)一個設計的多個相同實例時，就產(chǎn)生了規(guī)模經(jīng)濟，如圖 3 所示。規(guī)模經(jīng)濟可能出現(xiàn)在生產(chǎn)機器螺釘?shù)犬a(chǎn)品時，在這種生產(chǎn)過程中，可以使用機床等生產(chǎn)資產(chǎn)生產(chǎn)出多個相同的產(chǎn)品實例。工程師通過一種資源密集的過程（稱為開發(fā)）完成設計與最初的實例（稱為原型）。然后通過另一個由機器和/或低成本勞動力完成的過程（稱為生產(chǎn)）創(chuàng)造出更多實例（稱為復制品），以滿足市場需要。
圖 3：規(guī)模經(jīng)濟
范圍經(jīng)濟通過集中而非單獨生產(chǎn)多個相似但不同的設計和原型而實現(xiàn)，如圖 4 所示。例如在汽車制造業(yè)，多個相似但不同的汽車設計通常是通過組合子部件（如底盤、車體、內(nèi)部裝飾及傳動裝置）的現(xiàn)有設計來開發(fā)的，而不同的款式或型號通常是通過改變現(xiàn)有設計中的某些功能（如發(fā)動機和裝飾水平）來產(chǎn)生的。換言之，可以使用相同的方法、工藝、工具和材料設計出多個相似但不相同的產(chǎn)品，并制作出相似但不相同的原型。商業(yè)建筑同樣如此，很少看到多座橋梁或多幢摩天大樓采用同一種設計。但商業(yè)建筑領域存在一個有趣的現(xiàn)象，即每個成功的設計通常只會產(chǎn)生一兩個實例，因而規(guī)模經(jīng)濟幾乎從未真正實現(xiàn)過。在汽車制造業(yè)，通常會從成功的設計產(chǎn)生出許多不同的實例，通過復制每個原型，范圍經(jīng)濟與規(guī)模經(jīng)濟形成互補，如圖 4 所示。
圖 4：范圍經(jīng)濟
當然，軟件無論與汽車制造還是與商業(yè)建筑之間都存在重要區(qū)別，但它們常常有著相似的地方。
-
在諸如用戶桌面產(chǎn)品之類的市場中，操作系統(tǒng)和工作效率應用程序等產(chǎn)品通過復制形成批量生產(chǎn)，軟件行業(yè)呈現(xiàn)出規(guī)模經(jīng)濟的特點，如同在汽車制造業(yè)中一樣。
-
而在諸如企業(yè)用戶產(chǎn)品之類的市場中，為獲得競爭優(yōu)勢而開發(fā)的商業(yè)應用程序很少能夠進行批量生產(chǎn)，軟件僅呈現(xiàn)出范圍經(jīng)濟的特點，如同在商業(yè)建筑領域中一樣。
現(xiàn)在我們可以清楚地看到蘋果與桔子之間的區(qū)別了。將實物行業(yè)的生產(chǎn)與軟件開發(fā)進行比較未免有些天真。不管是軟件還是實物，在任何類型的開發(fā)中尋求規(guī)模經(jīng)濟效果都是沒有意義的。但是，我們卻可以期待軟件開發(fā)的產(chǎn)業(yè)化能夠帶來范圍經(jīng)濟的效果。
產(chǎn)業(yè)化會帶來什么樣的結果？
假設可以在軟件行業(yè)實現(xiàn)產(chǎn)業(yè)化，那么結果將會是什么樣子呢？當然，在事情發(fā)生之前我們不可能確切地知道。但是，我們可以根據(jù)軟件行業(yè)的發(fā)展道路以及其他行業(yè)產(chǎn)業(yè)化后的情形作出合理的推測。顯然，軟件開發(fā)永遠不會簡單到懶人們所希望的那種純機械化的程度。相反，滿足全球需求的關鍵是不要再把杰出開發(fā)人員的時間浪費在機械瑣碎的任務上。我們必須盡一切努力更好地利用這些稀有資源，不要再讓他們把時間花費在手動構造因為下一個主要平臺版本的出現(xiàn)或者市場條件的變化而致使行業(yè)需求改變進而導致短短幾個月或幾年內(nèi)就需要維護甚至替換掉的最終產(chǎn)品上。
實現(xiàn)此目的的方法之一就是為開發(fā)人員提供各種途經(jīng)，使他們能夠?qū)⒆约旱闹R轉化成可供他人重復利用的資產(chǎn)。這個目標是否遙遙無期？有些模式已經(jīng)表現(xiàn)出重復利用知識的有效性，盡管利用程度不高。下一步是使用語言、框架和工具自動生成模式化的應用程序，從而實現(xiàn)從編程到自動化的飛越。
半導體開發(fā)為軟件開發(fā)實現(xiàn)產(chǎn)業(yè)化后的情形提供了預演。這并不是說軟件組件很快就能象 ASIC 那樣易于組裝，ASIC 是經(jīng)過封裝和接口技術領域二十年的創(chuàng)新和標準化而開發(fā)出來的產(chǎn)品。但另一方面，軟件開發(fā)可能用不了 20 年。軟件開發(fā)的優(yōu)勢在于只需要處理比特，而半導體行業(yè)還需要承擔組件實現(xiàn)所需的物理材料工程的額外負擔。與此同時，比特所固有的短壽特性也為諸如數(shù)字知識產(chǎn)權保護等帶來了難題，正如我們在電影和音樂行業(yè)所看到的那樣。
結論
本文描述了軟件行業(yè)在利用現(xiàn)有方法和實踐來面對預期需求上的無能為力。這里只對許多問題進行了簡要敘述，無疑會引發(fā)讀者尋求證據(jù)或更多詳細的討論。要獲得更詳細的討論，請參閱此書 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/，這里提供了各種文章，介紹了阻止從手工作業(yè)向機械生產(chǎn)轉換的長期問題、幫助行業(yè)克服這些問題的重大創(chuàng)新以及集成了重大創(chuàng)新的軟件工廠方法。
版權聲明
© 版權所有 2004 Jack Greenfield。© 部分版權所有 2003 Jack Greenfield 和 Keith Short，已從 Wiley Publishing Inc. 獲準再版。保留所有權利。
參考資料
-
[Boe81] B Boehm.Software Engineering Economics.Prentice Hall PTR, 1981
-
[Bro95] F Brooks.The Mythical Man-Month.Addison-Wesley, 1995
-
[Chr97] C Christensen.The Innovator's Dilemma, Harvard Business School Press, 1997
-
[Kuh70] T Kuhn.The Structure Of Scientific Revolutions.The University Of Chicago Press, 1970
-
[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
-
[SS02] J. Smith and D Stotts.Elemental Design Patterns – A Link Between Architecture and Object Semantics.Proceedings of OOPSLA 2002
-
本圖利用 Virtuoso® Chip Editor 和 Virtuoso® XL Layout Editor 生成，并得到了 Cadence Design Systems, Inc. 的許可。© 版權所有 2003 Cadence Design Systems, Inc.。保留所有權利。Cadence 和 Virtuoso 是 Cadence Design Systems, Inc. 的注冊商標。
-
[Sta94] The Standish Group.The Chaos Report.http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf
-
[Weg78] P Wegner.Research Directions In Software Technology.Proceedings Of The 3rd International Conference On Software Engineering. 1978
作者簡介
Jack Greenfield 是 Microsoft 公司負責開發(fā)企業(yè)框架和工具的體系結構設計師。他曾擔任 Rational Software Corporation 公司 Practitioner Desktop Group 小組的主要體系結構設計師，他還是 InLine Software Corporation 公司的創(chuàng)始人和首席技術官。他曾在 NeXT 開發(fā)了企業(yè)對象框架，現(xiàn)在稱為 Apple Web Object。他是著名的演講者和作家，同時他還對 UML、J2EE 及相關的 OMG 和 JSP 規(guī)范做出過很大貢獻。他擁有 George Mason University 物理學學士學位。可通過 jackgr@microsoft.com 與 Jack 獲得聯(lián)系。
轉自：
http://msdn.microsoft.com/zh-cn/library/aa480032.aspx