没有银弹

《沒有銀彈：軟體工程的本質性與附屬性工作》（）是IBM大型電腦之父佛瑞德·布魯克斯所發表一篇關於軟體工程的論文，原先是在1986年都柏林IFIP研討會的一篇受邀論文Brooks, F. P.，“No silver bullet—essence and accidents of software engineering,”in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1069-1076.，隔年電機電子工程師學會《Computer》也轉載了這篇文章，他們用了幾張《》之類的電影劇照來當作說明Brooks, F. P. "No silver bullet—essence and accidents of software engineering", Computer 20, 4 (April, 1987), pp. 10-19.，還加上了一段〈終結狼人〉的附註，用來引出非銀彈則不能成功的（現代）傳說。該論述中強調由於軟體的複雜性本質，而使真正的銀彈並不存在；所謂的没有銀彈是指沒有任何一項技術或方法可使軟體工程的生產力在十年內提高十倍。

 摘要 
所有軟體創作都包括了本質性工作（essential task）和附屬性工作（accidental task）。前者是去創造出一種由抽象的軟體實體所組成的複雜概念結構，後者則是用程式語言來表現這些抽象的實體，並在某些空間和速度的限制之下，將程式對應至機器語言。

現在，若跟本質性的工作相比，軟體工程人員所做的事，還有多少算是花在附屬性的工作上呢？除非附屬性工作要耗費的心力超過全部工作的9/10，否則就算是將所有的附屬性工作降至零，也無法將整個開發工作的輕鬆程度提升一個數量級。以往，軟體生產力的重要進展絕大部分是來自於人為障礙的排除，像是嚴苛的硬體限制、難用的程式語言、上機時間（machine time）的不足等等，這些都是造成附屬性工作益發困難的原因。

 問題之所在－銀彈與軟體專案 
佛瑞德·布魯克斯在《沒有銀彈》F. P. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering", Computer, Vol. 20, pp. 10-19, 1987.中提到：

《沒有銀彈》主張並斷言在未來的十年之內（從1986年文章發表後開始計算），不會有任何單一的軟體工程上的突破，能夠讓程式設計的生產力得到一個數量級的提升。不過，作者認為這個假設現在已不再成立。

假設軟體開發的總工作量為10，其中，本質性工作佔掉1，附屬性工作佔掉9，那麼改善附屬性工作，將之消除，就可以把軟體工作量減輕到1（因為附屬性工作變成0），此時我們可以說，軟體工作開發的輕鬆程度提升了一個數量級（因為由10進步到1，差10倍）。

 軟體開發的困難 
布魯克斯將軟體開發的困難分為兩類，這篇經典論文的核心論述通常被解釋為複雜的軟體工程問題無法靠簡單的答案來解決。布魯克斯相信軟體開發真正的困難，是在於這種概念構造的規格制定、設計和測試，而並非在孜孜矻矻於它的呈現方式，以及測試該呈現方式的精確程度。
 本質性（essence）：軟體本身在概念（conceptual）建構上存先天的困難；亦即如何從抽象性問題，發展出具體概念上的解決方案。
 附屬性（accident）：將概念上的構思施行於電腦上，所遭遇到的困難。

布魯克斯提到，有某些地方已經被附屬性（accident）和附屬的（accidental）這些字眼給混淆了，這個字眼是出自於亞里斯多德的古老用法。就的這個字眼而言，他所指的並不是偶然發生的意思，也不是意外不幸的意思，而是比較接近伴隨的或次要的意思。

 造成本質性困難的原因 
布魯克斯認為，附加性的困難會隨著工具的改善而逐漸淡化，反而是本質性的困難最難以解決，因為大部分的活動是發生在人們的腦海裡，缺乏有效的輔助工具。依照布魯克斯的說法有下列幾項：
 複雜性（complexity）：軟體要解決的問題，通常牽扯到計算步驟，這是一種人為、抽象化的智能活動，多半是複雜的。
 隱匿性（invisibility）：尚未完成的軟體是看不見的，即使利用圖示說明，也常無法充分呈現其結構，使得人們在溝通上面臨極大的困難。Parnas, D. L.，“Designing software for ease of extension and contraction.”IEEE Trans. on SE,5,2 (March, 1979), pp. 128-138.
 配合性（conformity）：在大型軟體環境中，各子系統的介面必須協同一致。由於時間和環境的演變，要維持這樣的一致性通常十分困難。
 易變性（changeability）：軟體所應用的環境常是由人群、法規、硬體設備、應用領域等，各因素所匯集而成，而這些因素皆會快速變化。

 過去的突破解決了附屬性的困難 
 高階語言 

高階語言達成了什麼樣的使命呢？它使程式不再陷入許多原來附屬在程式裏的複雜性。一支抽象的程式所包含的是一些概念的構造：函式、資料型別、先後順序的關係，以及訊息傳遞的方式，然而實際上，與機器碼攸關的其實是位元、暫存器、條件、分支、通道、磁碟等等。高階語言可以將抽象程式裏所必要的構造予以具體化，並且避免掉所有更低階的東西，在這種情形下，它把跟程式內涵一點關係都沒有的那一整層複雜性給去除了。

 分時技術 

分時（time-sharing）技術所挑戰的是另一個截然不同的難題，因為分時，確保了即時性，使我們得以持續保住腦子裏對複雜的概觀。分時技術所能貢獻的底限也可以直接推算出來，由於其主要的效用就是縮短系統的反應時間，當這項時間趨近於零，並在某一點上跨越了人類所能夠察覺到有系統反應時間存在的臨界點，大約是十分之一秒，低於這個值，就不會再有任何效益了。

 統一的開發環境 

Unix和Interlisp是第一個得到廣泛使用的整合軟體開發環境，並且也被公認已將生產力提升了好幾倍。這方面所挑戰的附屬性難題，就是藉由完整的程式庫、統一的檔案格式、管道（pipe）和（filter），以促成軟體的共用，於是，任何概念的構造在理論上都可以呼叫、傳遞和運用在另一個對象，而實務上，這點也很容易就可以辦得到。這方面的突破隨後也帶動了整個工具軟體的發展，因為每一個新工具只要用的是標準規格，就可以適用於任何程式。

 尋找銀彈 
 Ada和其他高階語言的進展
程式語言Ada是1980年代的一個通用型高階語言。事實上，Ada不只是反映了在語言概念上的演進，同時也具體實現了一些助長現代設計與模組化概念的特徵；也許，Ada的理念才是比Ada語言本身更先進的地方，這理念就是：模組化（modularity）、抽象資料型別（abstract data type）、階層式結構（hierarchical structure）。

 物件導向程式設計
相對於當今流行的各種技術，物件導向程式設計（object-oriented programming）已被許多軟體工程的學生寄予了更多的希望Booch, G.
Object-oriented design,”in Software Engineering with Ada.Menlo Park, Calif.: Benjamin/Cummings, 1983.，达特茅斯学院的Mark Sherman指出，有兩個不同的概念我們必須小心地加以分辨，從名稱上就可以看出這兩個概念的不同：抽象資料型別和階層式型別。後者也被稱為類別（class）。所謂抽象資料型別，其概念就是一個物件的型別應該由一個名稱、一組適當的值和一組適當的操作方式來定義，而不是以它儲存的結構來定義，這部分應該是要被隱藏起來的，例如Ada的包裹（package，使用私有型別）或Modula的模組（module）。
人工智慧
專家系統
自動化程式設計
視覺化或圖形化程式設計
軟體的驗證
環境與工具
工作站

 評價迴響 
雖然《人月神話》引發了許多論述，但爭議很少，倒是《沒有銀彈》引發了不少持相反意見的文章，包括寄給期刊主編的一些信件，以及到今天都還在持續出現的一些書函和短評，這其中有大部分是對『不會有任何特效藥的主張』提出反駁。

1990年，Brad Cox發表一篇《銀彈存在》（"There Is a Silver Bullet"）Cox, B. J., "There is a silver bullet", Byte (Oct., 1990), pp. 209-218.，指出採取可再利用（reusable）、可替換組件的方式來對付屬於概念本質性部分的問題。Glass、Vessey和Conger在他們1992年的一篇論文中就指出，有充分的證據顯示，對銀彈這種沒有意義的研究仍尚未停止Glass, R. L., and S. A. Conger，“Research Software tasks: Intellectual or clerical?”Information and Management, 23, 4 (1992), pp. 183-192.。

 Harel的分析 
David Harel在1992年的一篇文獻《緊咬銀彈》（"Biting the Silver Bullet"
）中，對已經發表的《沒有銀彈》進行非常仔細的分析Harel, D., "Biting the silver bullet: Toward a brighter future for system development", Computer (Jan., 1992) , pp. 8-20.。Harel認為《沒有銀彈》和1984年Parnas《戰略防禦系統軟體面面觀》Parnas, D. L., "Software aspects of strategic defense systems", Communications of the ACM, 28 (12) (Dec., 1985), pp. 1326-1335.這兩篇都寫得太過於絕望了，於是他針對這一點來闡述較為光明的一面，他的文章還用了個副標題是「讓系統開發走向一個光明的未來」。

就Harel的認知，他認為造成《沒有銀彈》悲觀的原因有三點：
 本質性和附屬性的二分法。
 對每一個可能的銀彈採取個別單獨評論的方式。
 只預測10年，這對「預期任何重大的突破」而言，並沒有足夠長的時間。

Harel更提出了一項假想實驗，他假定《沒有銀彈》的主張不變，只是發表的時間換做是在1952年，而非1986年。他這時用的是歸謬法（reducto ad absurdum），用來反駁自附屬性中切分出本質性的作法。

 Jones的觀點 
Caper Jones曾提出一個敏銳的見解，這個見解最初是寫在一連串非正式的紀錄中，後來出現在書上，幾個與布魯克斯通信的朋友也提到過。《沒有銀彈》就如同大部分的論文一般，都把焦點集中在生產力，也就是軟體每單位的輸入成本能得到多少輸出效果。Jones則表示：「把重點放在品質上，生產力將隨之而來」Jones, C., Assessment and Control of Software Risks. Englewood Cliffs, N. J.: Prentice-Hall, 1994. p. 619.。他認為，只要是成本過高和時程落後的專案，都耗費了非常多的額外時間和工作在尋找並修正規格、設計、實作中的錯誤。Jones並提出資料佐證，缺乏有系統的品質控制與發生時程落後的災難，這兩者之間有強烈的相關性。

Caper Jones相信，兩份同等的Cobol程式分別花10年編寫，但其中一份使用結構化的方法，另一份則否，那麼所得到的效果將相差3倍。

 注释 

 參考文獻 

 引用 

 来源 

 期刊文章


 书籍


 外部連結 

 No Silver Bullet: Essence and Accidents of Software Engineering, by Frederick P. Brooks, Jr.
 No hay balas de plata: Lo esencial y lo accidental en la Ingeniería del Software, by Frederick P. Brooks, Jr.
 论银弹的存在 

 參見 

 佛瑞德·布魯克斯
 《人月神話》
 軟體危機
 银色子弹 → 狼人

Category:1986年作品
Category:学术期刊文章
Category:软件工程
Category:軟體專案管理