Semat計(jì)劃于2009年12月由軟件工程三位大師（合稱(chēng)“Troika”）Ivar Jacobson（UML、RUP、組件和組件架構(gòu)、用例等技術(shù)之父），Bertrand Meyer（Eiffel和按約定設(shè)計(jì)之父）和Richard Soley（OMG主席）正式發(fā)起，倡導(dǎo)以堅(jiān)實(shí)的理論、已經(jīng)證明的原理和最佳實(shí)踐為基礎(chǔ)，重新發(fā)現(xiàn)軟件工程的本質(zhì)。Jacobson等撰寫(xiě)了三篇文章詳細(xì)闡述Semat思想，本刊將陸續(xù)刊載，本文是其中第一篇。佛羅里達(dá)大西洋大學(xué)黃詩(shī)虹教授另撰有《Semat: 軟件開(kāi)發(fā)的又一次革命》一文，刊載于雜志官網(wǎng)，推薦閱讀。

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

　　在本文中，我們將論述軟件開(kāi)發(fā)方法學(xué)必須經(jīng)歷深刻的變革。應(yīng)該放棄當(dāng)前依賴(lài)于新詞和政治式宣傳的狀況，轉(zhuǎn)向基于理論和實(shí)驗(yàn)驗(yàn)證的嚴(yán)肅的科學(xué)工作。

　　時(shí)裝業(yè)，政治還是工程學(xué)科？

　　軟件方法學(xué)是一個(gè)特殊的領(lǐng)域。按原理它應(yīng)該是基于科學(xué)的工程學(xué)科，但目前的實(shí)踐中它卻時(shí)而像時(shí)裝業(yè)，時(shí)而又像搞政治。

　　時(shí)裝業(yè)每年都要有一種新潮流，在匆忙跟風(fēng)中，人們將好的和壞的一起拋棄。人們不是從自己的經(jīng)驗(yàn)中學(xué)習(xí)，而是跟著自認(rèn)為更好的走，因?yàn)槠渌硕颊f(shuō)這樣更好。創(chuàng)新者們常常抱怨，大公司擁抱變化非常緩慢，但事實(shí)上并非如此，許多大公司非常渴望嘗試新事物。真正的問(wèn)題在于，他們也會(huì)更快地放棄，還沒(méi)等認(rèn)真用起來(lái)呢，在過(guò)程和工具上的不菲投入就打水漂了。

　　在政治（或者說(shuō)得更準(zhǔn)確些是壞的政治）中，重點(diǎn)不是放在難題的切實(shí)解決，而是口號(hào)、宣傳和煽情。理念不是通過(guò)對(duì)利弊仔細(xì)的討論來(lái)提出，而是像品牌那樣進(jìn)行營(yíng)銷(xiāo)，借助一些大師的一些金口玉言來(lái)傳播。每一種方法都試圖忽略自己的同類(lèi)，如果不得不承認(rèn)它們的存在，通常也會(huì)惡意貶低，這弄得一線人員無(wú)所適從。

　　最終，很少有新思想能運(yùn)用在大規(guī)模的項(xiàng)目里，因此對(duì)大系統(tǒng)開(kāi)發(fā)中的質(zhì)量、生產(chǎn)力和上市時(shí)間等等都沒(méi)有產(chǎn)生什么影響。過(guò)去四十年中軟件開(kāi)發(fā)方法中出現(xiàn)的所有新概念里，只有少數(shù)大的創(chuàng)新——結(jié)構(gòu)化編程、對(duì)象技術(shù)、設(shè)計(jì)模式和UML等對(duì)行業(yè)產(chǎn)生了真正的影響。

　　這些都是不成熟的表現(xiàn)。我們的學(xué)科該長(zhǎng)大了。

　　敏捷

　　席卷業(yè)界的最新一波浪潮是“敏捷”。敏捷方法的確做出了許多貢獻(xiàn)，并使我們?cè)俅巫⒁獾饺嗽谲浖こ讨械闹行牡匚弧Ｒ恍┟艚莸慕?jīng)驗(yàn)很可能仍然會(huì)在未來(lái)的方法中繼續(xù)存在。與此同時(shí)，敏捷領(lǐng)域也為上面談到的現(xiàn)象提供了活例子。作為一個(gè)重視人甚于過(guò)程和工具的運(yùn)動(dòng)，敏捷卻提出了許多被宣傳為“新的”過(guò)程和工具，而且沒(méi)有說(shuō)清楚其中哪些是真正新的，哪些只是已有概念的重述。很多一線人員很自然地就被弄暈了。先不說(shuō)這些“新”概念的價(jià)值如何，對(duì)它們的推廣方式就頗為引人注目：先是為這個(gè)方法精心編寫(xiě)了一份基礎(chǔ)性文獻(xiàn)的——一個(gè)宣言（http://agilemanifesto.org/），更多的是第一人稱(chēng)復(fù)數(shù)的情感訴求（我們必須……），而缺少事實(shí)依據(jù)。這種風(fēng)格對(duì)于吸引眼球可能有效，但隨著概念日益成熟，還是應(yīng)該采用更傳統(tǒng)（也更枯燥的）闡釋形式。

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

　　目前的方法：多種實(shí)踐的大雜燴

　　我們目前軟件開(kāi)發(fā)的方法，無(wú)論是商業(yè)還是公司內(nèi)部，新還是舊，需求已知還是不清，實(shí)際上都只是來(lái)自方法文獻(xiàn)中各種元素的組合，加上一些特定于領(lǐng)域或者業(yè)務(wù)的擴(kuò)展。基本的成分是一個(gè)個(gè)實(shí)踐。

　　如果我們將這些基本成分從大雜燴中分離出來(lái)，大家就可以建立自己所需的方法。這種方法是以模塊的方式設(shè)計(jì)的，能夠在不斷總結(jié)經(jīng)驗(yàn)的基礎(chǔ)上快速演進(jìn)，響應(yīng)我們快速變化的行業(yè)的需求。

　　構(gòu)建理論

　　經(jīng)濟(jì)壓力是當(dāng)前的時(shí)代特征，與時(shí)裝業(yè)的跟風(fēng)和政治宣傳一樣都不會(huì)完全消失。但是，所有關(guān)注軟件工程價(jià)值的方法學(xué)者都理應(yīng)為學(xué)科找到存在的理由。

　　我們所缺乏的是作為一門(mén)科學(xué)和工程學(xué)的基礎(chǔ)：理論及其驗(yàn)證。我們應(yīng)該采取以下步驟，將軟件方法學(xué)轉(zhuǎn)變?yōu)橐环N嚴(yán)謹(jǐn)?shù)墓ぷ鳌?strong>

　　對(duì)方法的本質(zhì)進(jìn)行建模

　　軟件開(kāi)發(fā)是一種人的活動(dòng)，但它也是由若干明確定義的步驟組成的，而且我們對(duì)這些步驟之間關(guān)系已經(jīng)有了充分認(rèn)識(shí)。至少，在有經(jīng)驗(yàn)的從業(yè)人員腦中，對(duì)這些概念的定義和理解都是不言自明的。但這還不夠，我們需要堅(jiān)實(shí)的軟件開(kāi)發(fā)理論。形式化方法為我們提供了進(jìn)行建模的正確工具，含有約定構(gòu)造（contract）的面向?qū)ο笳Z(yǔ)言也可以實(shí)現(xiàn)同一目的。如果軟件開(kāi)發(fā)的任務(wù)和限制沒(méi)有精確的、無(wú)歧義的模型，我們就無(wú)法顯著地進(jìn)行改善。模型應(yīng)該獨(dú)立于具體方法（只描述問(wèn)題，而非解決方案）；模型應(yīng)該不僅包含定義和公理，而且還應(yīng)該包括描述所有系統(tǒng)和可行方法的定理——這恰恰是形式化模型經(jīng)常缺失的部分。

　　尋找內(nèi)核——所有方法之母

　　所有方法在被過(guò)度宣傳的差異之外，都有許多共同的屬性。而以理論作為基礎(chǔ)，我們將描述出任何有效的開(kāi)發(fā)高質(zhì)量軟件的方法都應(yīng)該滿(mǎn)足的屬性。畢竟，它們都是用來(lái)開(kāi)發(fā)軟件的，而且都承認(rèn)軟件開(kāi)發(fā)中有一些東西總是需要。我們總是要寫(xiě)代碼，用某種方式進(jìn)行測(cè)試，總是要考慮需求（無(wú)論要不要文檔），總是有backlog（無(wú)論顯式還是隱式），總是需要計(jì)劃（無(wú)論是寫(xiě)在紙上，還是留在腦子里）。

　　我們需要找到軟件開(kāi)發(fā)本質(zhì)的不能再簡(jiǎn)化的內(nèi)核（Kernel）。例如，通過(guò)研究大約50種方法包括XP和Scrum，我們已經(jīng)找到了一個(gè)包含超過(guò)15個(gè)元素的內(nèi)核，其中的元素是我們總要做的事情或者總要生成的東西。

　　使用內(nèi)核描述各種有價(jià)值的方法

　　有了內(nèi)核之后，所有方法都可以進(jìn)行描述和比較。我們可以從所有廣泛使用和經(jīng)過(guò)驗(yàn)證的方法或者過(guò)程中采集隱含的實(shí)踐，比如架構(gòu)、組件、迭代等等。有些實(shí)踐是重疊的，比如用例驅(qū)動(dòng)開(kāi)發(fā)和特性驅(qū)動(dòng)開(kāi)發(fā)。有些是互相補(bǔ)充的，比如用例驅(qū)動(dòng)開(kāi)發(fā)和按約定設(shè)計(jì)。

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

　　因?yàn)閮?nèi)核對(duì)于任何具體的實(shí)踐都是中立的，我們可以簡(jiǎn)單地分辨出不同實(shí)踐之間的實(shí)際區(qū)別，不是表面上的，而是深層次的。這將減少各種方法中包含的“宗教”成分。

　　行動(dòng)起來(lái)！

　　本文是一篇行動(dòng)呼吁書(shū)，我們希望它能夠被所有同意軟件業(yè)應(yīng)該進(jìn)入成熟階段的同仁所接納（當(dāng)然，還需要進(jìn)行適當(dāng)?shù)男抻啠?/p>

　　最重要的一步，可能是認(rèn)識(shí)到不同學(xué)派應(yīng)該求同存異。具體而言，要認(rèn)識(shí)到以下兩點(diǎn)。

　　敏捷與過(guò)程：這兩者之間的差異被夸大了。它們的目標(biāo)其實(shí)是一樣的：流暢地開(kāi)發(fā)出優(yōu)秀的軟件。所有過(guò)程都需要敏捷，因?yàn)榕c其他領(lǐng)域相比，軟件中變化是規(guī)則，穩(wěn)定則是例外。與此同時(shí)，所有敏捷方法如果要應(yīng)用于關(guān)鍵的企業(yè)項(xiàng)目，還是需要過(guò)程，包括規(guī)格說(shuō)明和設(shè)計(jì)。

　　形式化與非形式化：軟件開(kāi)發(fā)人員必須認(rèn)識(shí)到，任何進(jìn)展都會(huì)多多少少包含一些形式化方法，沒(méi)有必要畏之如虎。所有工程都要依賴(lài)數(shù)學(xué)：我們能夠想象電氣或者機(jī)械工程師不愿意學(xué)習(xí)和運(yùn)用數(shù)學(xué)工具嗎？形式化方法當(dāng)然有其局限——沒(méi)人說(shuō)它們能解決任何問(wèn)題，但是形式化方法絕不是純理論，它們的價(jià)值早已經(jīng)被不斷證明了。無(wú)論我們是否能認(rèn)識(shí)到這一點(diǎn)，它們都已經(jīng)在一些領(lǐng)域（現(xiàn)代編程語(yǔ)言中的類(lèi)型檢查就是一種證明形式，而硬件設(shè)計(jì)也越來(lái)越依靠數(shù)學(xué)工具）廣泛應(yīng)用了。隨著IT業(yè)向更專(zhuān)業(yè)的運(yùn)營(yíng)方式發(fā)展，有選擇的數(shù)學(xué)工具的運(yùn)用將與日俱增。

　　僅僅通過(guò)忽略表面上的差異，并充分利用已有的概念，我們將能夠?yàn)闃I(yè)界提供曾經(jīng)只能從專(zhuān)家們那里得到的東西：科學(xué)上堅(jiān)實(shí)、而且實(shí)用的方法和工具。

　　這就是我們的看法。我們是否像堂吉訶德那樣在挑戰(zhàn)風(fēng)車(chē)呢？還是有可能就此對(duì)現(xiàn)在開(kāi)發(fā)方法中混亂的局面正本清源，開(kāi)發(fā)出業(yè)界所需要的堅(jiān)實(shí)基礎(chǔ)？有一點(diǎn)是肯定的：進(jìn)步只能來(lái)自許多人的通力合作。已經(jīng)有許多論壇在討論這些問(wèn)題，請(qǐng)從我們的博客（http://ivarblog.com/， http://bertrandmeyer.com）開(kāi)始。歡迎將你的想法告訴我們，幫助軟件工程學(xué)科進(jìn)入成熟階段。

it知識(shí)庫(kù)：軟件開(kāi)發(fā)方法需要理論，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。