Semat計劃于2009年12月由軟件工程三位大師（合稱“Troika”）Ivar Jacobson（UML、RUP、組件和組件架構、用例等技術之父），Bertrand Meyer（Eiffel和按約定設計之父）和Richard Soley（OMG主席）正式發起，倡導以堅實的理論、已經證明的原理和最佳實踐為基礎，重新發現軟件工程的本質。Jacobson等撰寫了三篇文章詳細闡述Semat思想，本刊將陸續刊載，本文是其中第一篇。佛羅里達大西洋大學黃詩虹教授另撰有《Semat: 軟件開發的又一次革命》一文，刊載于雜志官網，推薦閱讀。

　　對于正在尋找軟件開發方法的人來說，問題不在于是否能找到答案，而是確定答案是否滿足要求。是的，我們已經有了很多方法——每年都會出來一茬新的，但是這讓可憐的一線開發人員感到奇怪，為什么去年的招兒又不夠好了，為什么他們必須接受今年的新法子。為了尋找嚴格的概念性論據，必須看透炒作之詞，找到其中少
量行之有效的真知灼見。

　　在本文中，我們將論述軟件開發方法學必須經歷深刻的變革。應該放棄當前依賴于新詞和政治式宣傳的狀況，轉向基于理論和實驗驗證的嚴肅的科學工作。

　　時裝業，政治還是工程學科？

　　軟件方法學是一個特殊的領域。按原理它應該是基于科學的工程學科，但目前的實踐中它卻時而像時裝業，時而又像搞政治。

　　時裝業每年都要有一種新潮流，在匆忙跟風中，人們將好的和壞的一起拋棄。人們不是從自己的經驗中學習，而是跟著自認為更好的走，因為其他人都說這樣更好。創新者們常常抱怨，大公司擁抱變化非常緩慢，但事實上并非如此，許多大公司非常渴望嘗試新事物。真正的問題在于，他們也會更快地放棄，還沒等認真用起來呢，在過程和工具上的不菲投入就打水漂了。

　　在政治（或者說得更準確些是壞的政治）中，重點不是放在難題的切實解決，而是口號、宣傳和煽情。理念不是通過對利弊仔細的討論來提出，而是像品牌那樣進行營銷，借助一些大師的一些金口玉言來傳播。每一種方法都試圖忽略自己的同類，如果不得不承認它們的存在，通常也會惡意貶低，這弄得一線人員無所適從。

　　最終，很少有新思想能運用在大規模的項目里，因此對大系統開發中的質量、生產力和上市時間等等都沒有產生什么影響。過去四十年中軟件開發方法中出現的所有新概念里，只有少數大的創新——結構化編程、對象技術、設計模式和UML等對行業產生了真正的影響。

　　這些都是不成熟的表現。我們的學科該長大了。

　　敏捷

　　席卷業界的最新一波浪潮是“敏捷”。敏捷方法的確做出了許多貢獻，并使我們再次注意到人在軟件工程中的中心地位。一些敏捷的經驗很可能仍然會在未來的方法中繼續存在。與此同時，敏捷領域也為上面談到的現象提供了活例子。作為一個重視人甚于過程和工具的運動，敏捷卻提出了許多被宣傳為“新的”過程和工具，而且沒有說清楚其中哪些是真正新的，哪些只是已有概念的重述。很多一線人員很自然地就被弄暈了。先不說這些“新”概念的價值如何，對它們的推廣方式就頗為引人注目：先是為這個方法精心編寫了一份基礎性文獻的——一個宣言（http://agilemanifesto.org/），更多的是第一人稱復數的情感訴求（我們必須……），而缺少事實依據。這種風格對于吸引眼球可能有效，但隨著概念日益成熟，還是應該采用更傳統（也更枯燥的）闡釋形式。

　　在工程和科學中，一種新技術的提出者與任何人一樣都急于推廣自己的發明，但是也會很小心地確定應用這項新技術在什么地方存在不足或者未經證實。然而，很少有軟件方法學者會提供這樣的警示信息。太多人夸大了自己的方法與前人的差異。每一次變革（比如對象技術）中，有多少突破其實是已知概念的調整？逐漸改進當然沒有錯，科學和工程中大量進展都是如此實現的。但是，將每一次改進都包裝成革命，就沒意思了。

　　目前的方法：多種實踐的大雜燴

　　我們目前軟件開發的方法，無論是商業還是公司內部，新還是舊，需求已知還是不清，實際上都只是來自方法文獻中各種元素的組合，加上一些特定于領域或者業務的擴展。基本的成分是一個個實踐。

　　如果我們將這些基本成分從大雜燴中分離出來，大家就可以建立自己所需的方法。這種方法是以模塊的方式設計的，能夠在不斷總結經驗的基礎上快速演進，響應我們快速變化的行業的需求。

　　構建理論

　　經濟壓力是當前的時代特征，與時裝業的跟風和政治宣傳一樣都不會完全消失。但是，所有關注軟件工程價值的方法學者都理應為學科找到存在的理由。

　　我們所缺乏的是作為一門科學和工程學的基礎：理論及其驗證。我們應該采取以下步驟，將軟件方法學轉變為一種嚴謹的工作。

　　對方法的本質進行建模

　　軟件開發是一種人的活動，但它也是由若干明確定義的步驟組成的，而且我們對這些步驟之間關系已經有了充分認識。至少，在有經驗的從業人員腦中，對這些概念的定義和理解都是不言自明的。但這還不夠，我們需要堅實的軟件開發理論。形式化方法為我們提供了進行建模的正確工具，含有約定構造（contract）的面向對象語言也可以實現同一目的。如果軟件開發的任務和限制沒有精確的、無歧義的模型，我們就無法顯著地進行改善。模型應該獨立于具體方法（只描述問題，而非解決方案）；模型應該不僅包含定義和公理，而且還應該包括描述所有系統和可行方法的定理——這恰恰是形式化模型經常缺失的部分。

　　尋找內核——所有方法之母

　　所有方法在被過度宣傳的差異之外，都有許多共同的屬性。而以理論作為基礎，我們將描述出任何有效的開發高質量軟件的方法都應該滿足的屬性。畢竟，它們都是用來開發軟件的，而且都承認軟件開發中有一些東西總是需要。我們總是要寫代碼，用某種方式進行測試，總是要考慮需求（無論要不要文檔），總是有backlog（無論顯式還是隱式），總是需要計劃（無論是寫在紙上，還是留在腦子里）。

　　我們需要找到軟件開發本質的不能再簡化的內核（Kernel）。例如，通過研究大約50種方法包括XP和Scrum，我們已經找到了一個包含超過15個元素的內核，其中的元素是我們總要做的事情或者總要生成的東西。

　　使用內核描述各種有價值的方法

　　有了內核之后，所有方法都可以進行描述和比較。我們可以從所有廣泛使用和經過驗證的方法或者過程中采集隱含的實踐，比如架構、組件、迭代等等。有些實踐是重疊的，比如用例驅動開發和特性驅動開發。有些是互相補充的，比如用例驅動開發和按約定設計。

　　內核清除了方法之間表面存在的差異，比如不同方法中只是稱呼不同的相同事物。比如，RUP所說的迭代在Scrum中稱為sprint，但是它們基本上說的是一回事。通過這種清理，可以明顯地看出不同方法之間真正的差異。

　　因為內核對于任何具體的實踐都是中立的，我們可以簡單地分辨出不同實踐之間的實際區別，不是表面上的，而是深層次的。這將減少各種方法中包含的“宗教”成分。

　　行動起來！

　　本文是一篇行動呼吁書，我們希望它能夠被所有同意軟件業應該進入成熟階段的同仁所接納（當然，還需要進行適當的修訂）。

　　最重要的一步，可能是認識到不同學派應該求同存異。具體而言，要認識到以下兩點。

　　敏捷與過程：這兩者之間的差異被夸大了。它們的目標其實是一樣的：流暢地開發出優秀的軟件。所有過程都需要敏捷，因為與其他領域相比，軟件中變化是規則，穩定則是例外。與此同時，所有敏捷方法如果要應用于關鍵的企業項目，還是需要過程，包括規格說明和設計。

　　形式化與非形式化：軟件開發人員必須認識到，任何進展都會多多少少包含一些形式化方法，沒有必要畏之如虎。所有工程都要依賴數學：我們能夠想象電氣或者機械工程師不愿意學習和運用數學工具嗎？形式化方法當然有其局限——沒人說它們能解決任何問題，但是形式化方法絕不是純理論，它們的價值早已經被不斷證明了。無論我們是否能認識到這一點，它們都已經在一些領域（現代編程語言中的類型檢查就是一種證明形式，而硬件設計也越來越依靠數學工具）廣泛應用了。隨著IT業向更專業的運營方式發展，有選擇的數學工具的運用將與日俱增。

　　僅僅通過忽略表面上的差異，并充分利用已有的概念，我們將能夠為業界提供曾經只能從專家們那里得到的東西：科學上堅實、而且實用的方法和工具。

　　這就是我們的看法。我們是否像堂吉訶德那樣在挑戰風車呢？還是有可能就此對現在開發方法中混亂的局面正本清源，開發出業界所需要的堅實基礎？有一點是肯定的：進步只能來自許多人的通力合作。已經有許多論壇在討論這些問題，請從我們的博客（http://ivarblog.com/， http://bertrandmeyer.com）開始。歡迎將你的想法告訴我們，幫助軟件工程學科進入成熟階段。

it知識庫：軟件開發方法需要理論，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。