在現代軟體研發過程中，快速適應變化是重要關鍵，但你知道嗎？這是經過了數十年的發展才形成的觀念，甚至在這個觀念普及前，失控的軟體規模還造成民眾傷亡。
傳統的開發方式，往往需要嚴格的規劃和長時間的執行，這讓許多團隊在面對不斷變化的需求時顯得力不從心。為了應對這一挑戰，工程師們開始尋找更靈活的開發方法，強調反覆迭代、快速回應市場和用戶的需求。本篇文章將帶你回顧軟體工程的歷史，並探討這些方法是如何演變和影響當代軟體開發的。
- 軟體危機與軟體工程
- 人月神話
- 瀑布流模型
- 敏捷軟體開發
- 快速應用程式開發（RAD）
本文章目次
軟體危機與軟體工程
早期的計算機只能處理單一工作
在1920到1940年代電腦被發明出來，人們意識到單純依賴機器的操作將會越來越複雜且不靈活。例如一個專門用來計算數據的計算機（電腦），若要改處理文字文件，必須更改線路、結構，甚至重新設計機器。
對那個年代來講，更改電腦程式意味著重新進行紙上作業，規劃機器架構，然後製作出新的機器。
馮紐曼架構
為了應付越來越大型的電腦開發，馮紐曼於1945年為EDVAC電腦計畫提出的《First Draft of a Report on the EDVAC》報告中，設計了「馮紐曼架構」（Von Neumann architecture），又稱「儲存型（Stored）程式架構」或「普林斯頓架構」。
此架構設計了一組指令集，將程式的運算轉成一連串指令執行細節。藉由將指令也當成一種資料來儲存，一台馮紐曼架構的電腦可以輕易改變其程式邏輯，以計算不同的內容。
從這個時候開始，電腦的發展逐漸將抽象化軟體與硬體區隔開來，到了1950年代，現代化程式語言如Fortran、ALGOL與COBOL也陸續誕生。
失控的軟體規模（軟體危機）
軟體的發展非常迅速，專案也越來越龐大，開發人力越來越多。到了1980年代，許多軟體的規模開始失控，不只品質大幅下降，時程也嚴重延遲，導致成本劇烈上升，這段期間被稱為「軟體危機」。
軟體品質的下降甚至造成人員傷亡，例如1985到1987年間，輻射治療的機器Therac-25的劑量計算錯誤導致許多治療中患者遭到嚴重輻射灼傷。由於這個意外，使得軟體的開發方法逐漸被重視，因而喚起軟體開發工程化管理方法論的思維。
軟體工程
「軟體工程」（Software Engineering）由Margaret Hamilton在1968年提出，這個名詞被作為北約科技委員會（NATO）所舉辦研討會的名稱，也在此時對外宣布這個概念。軟體工程旨在研究和應用如何以系統性的、規範化的、可定量的程序化方法去開發和維護軟體，以及如何把合適的管理技術與軟體開發執行技術結合起來的一門學問。
在ACM與IEEE Computer Society（2014）聯合修定的《Software Engineering Body of Knowledge》提到，軟體工程領域中的核心知識包括：
軟體需求（Software requirements）
軟體設計（Software design）
軟體建構（Software construction）
軟體測試（Software test）
軟體維護與更新（Software maintenance）
軟體構型管理（Software Configuration Management, SCM）
軟體工程管理（Software Engineering Management）
軟體開發流程（Software Development Process）
軟體工程工具與方法（Software Engineering Tools and methods）
軟體品質（Software Quality）
由此可見軟體工程的領域已經非常龐大，需要夠大的開發團隊，才能夠掌握所有面相。其中「軟體開發流程」是影響一個軟體開發速度與品質管理的重要項目。採用正確的發流程，小型團隊也能夠掌握複雜的開發工作，降低失敗的機率及避免系統開發者陷入「焦油坑」。
這也是軟體工程經典書籍「人月神話」裡面提到的概念。
人月神話
《人月神話：軟體專案管理之道》（The Mythical Man-Month: Essays on Software Engineering）是由美國軟體工程師暨IBM System/360 系統之父佛瑞德·布魯克斯（Fred Brooks）所著書籍，被譽為軟體領域的聖經，內容源於作者布魯克斯在IBM公司 System/360 家族和 OS/360 中的專案管理經驗。
許多有名的詞彙如「焦油坑」、「銀子彈」、「外科手術團隊」、「第二系統效應」等等，都是來自這本書。
焦油坑
人月神話裡面提到一個基本概念：
若要令一個軟體成為「產品」，在文件、測試、維護管理方面的消耗是開發過程的「三倍」
若要令一個軟體成為可重複使用與擴充的元件，消耗也是開發過程的「三倍」。
也就是說，軟體開發真正的成本是在規劃、測試、以及讓某些功能可以重複使用或適應多種情境，通常這些「試圖讓軟體變好用」的努力，消耗是基本功能開發的「三倍」。
很多軟體團隊，可能一開始能夠快速開發出基礎可用的原型產品，但是在後續為了讓產品能重複使用、對應多種情境、適應未來變更等等的改良上，陷入萬劫不復的泥坑中無法自拔。這也是現代軟體研發常講，「避免過早最佳化」與「Done is better then perfect」的由來。
史前史中，沒有別的場景比巨獸們中焦油坑中垂死掙扎的場面更令人震撼。上帝見證者恐龍、猛獁象、劍齒虎在焦油坑中掙扎。它們掙扎得越猛烈，焦油糾纏得就越緊，沒有哪種猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛，它們最後都沉到了坑底。
過去十年間，大型系統的軟體開發工作就像是掉進了焦油坑裏......
-- 佛瑞德·布魯克斯
沒有銀子彈
人月神話進一步提到：沒有任何方法可以在十年內，讓軟體開發的速度提升一個量級。也就是說，由於錯綜複雜的相依引用，軟體開發的總時程沒有辦法藉由技術與管理輕易提升。書中舉了一個有趣的例子：十個孕婦也無法在一個月生出小孩。
近年來對這件事的延伸解釋：沒有任何技術、軟體、架構，可以一勞永逸的解決現實生活面對的軟體運作困境，一切都是 trade off 與選擇的問題。
由於這很像早期狼人小說中的銀子彈的概念：一種可以一勞永逸擊殺狼人的子彈。
所以人們把這個概念稱為「軟體研發沒有銀子彈」。這意味著現實世界的軟體研發，永遠沒有這麼好用的銀子彈，可以像工業革命一樣，在未來幾十年中讓軟體研發變得簡單快速且十倍速成長。
人們嘗試著尋找能夠奇蹟似地將狼人一槍斃命的銀彈。
軟體專案平常看似單純而率直，但很可能一轉眼就變成一隻時程延誤、預算 超支、產品充滿瑕疵的怪獸，所以我們渴望有一種銀彈，能夠有效降低軟體開發的成本。
但是從現在開始的十年之內，將不會看到任何銀彈，無論是在技術上或管理 上，都不會有任何單一的重大突破,能夠保證在生產力、可靠度或簡潔性上獲得改善，甚至，連一個數量級的改善都不會有。
--佛瑞德·布魯克斯
由於前面幾十年面對了如此龐雜的研發困境，人們開始尋找合適的方法論，能夠有效的控管軟體的產出，也就是接下來要介紹的各類研發模型。
瀑布流模型
瀑布流模型（Waterfall Model）是軟體開發流程與步驟的一種理論模式，其概念在名詞被提出前已廣泛流傳在不同的開發者之間，之後Winston W. Royce在1970年作了一次完整的描述。
在瀑布流模型中，軟體開發被分為為需求分析，設計，實作，測試，整合與維護這樣的步驟依序進行，並強調系統開發應該要有完整的週期，每一次的調整、修改，都必須從頭依序經歷這些階段，如圖所示：
由於每一個週期都要自上而下依序進行，因此被稱為瀑布流（Waterfall），或稱「系統發展生命週期」（System Development Life Cycle，SDLC）。
論點：規劃期的成本最低
瀑布流的支持者認為，在軟體規劃時期的成本遠低於開發時期，因此應該要在規劃時清楚的分析需求，才能進入開發階段。
一旦有任何錯誤在開發階段或開發完成後才被察覺，其補救成本可能是預先排除問題的50到200倍。
瀑布模型重視文件的撰寫
另外，瀑布流也非常重視文件的撰寫。支持者認為大型軟體的開發沒有人可以獨力了解所有面相，隨著人員的去留，只有完整的文件才能確保軟體結構穩定且健壯，新進人員可以藉由閱讀文件快速進入狀況，參與開發。
人們對瀑布模型的觀點
由於瀑布流強調必須嚴格遵循整個開發與規劃流程的循環，因此導致的是其執行效率低落，即便在Royce的文章中，也認為這個模型不見得可以正常的運作。Parnas 等人則認為客戶常常看見實際開發的系統後，才察覺到需要調整的地方，因此會造成軟體設計被持續更改、重建，造成不必要的成本支出，意味軟體的需求規格總是無法在規劃期就完美的確認。
但整體而言，多數人還是認為瀑布流適用於大型企業的軟體開發工作，且嚴格遵循瀑布流的軟體在結構穩定性與品質上是非常優良的。
敏捷軟體開發
敏捷的興起與雪鳥會議
敏捷軟體開發（Agile software development）（以下簡稱「敏捷開發」）是1990年代開始逐漸引起關注的新興軟體開發方式。早在眾人為之熟悉「敏捷」一詞之前，敏捷的模式已經被許多工程師在日常工作中實踐。
而「敏捷」這個詞，是在2001年，由一群已經在使用此開發方式的實踐者，聚集在美國猶他州雪鳥滑雪勝地共同宣布，此次會議又稱「雪鳥會議」。
敏捷特色與四大原則
此開發方式的特色是能夠應付快速需求變化，讓開發團隊更緊密的溝通協調，也更適合中小型開發團隊使用。其開發過程採用迭代的方式，每個階段重功能後再進行下一階段。與其他「非敏捷」開發方式相比，敏捷開發的重點在強調四個原則：
重視人與人之間的互動，而非工具與規範。
直接開發出可用的軟體，並以程式本身做為文件與討論依據，而非依賴大量文書文件。
與客戶密切合作、討論，尋求解決方案，而非依賴合約。
隨時快速的回應變化做調整，而非永遠遵循預定計畫。
由此可見，敏捷軟體開發並不意味著開發速度的「快」，而是對變動的即時反應與彈性，並把程式碼本身當成溝通用文件，省去程式以外不必要的大量繁瑣細節。因為每一次的需求變動，會讓那些辛苦寫完的文件失去價值。
對比於瀑布模型嚴格遵循計畫流程來說，敏捷開發較能適應高度變化的市場與不確定最終需求的專案。
敏捷更重視人與人的交流
適用於敏捷開發的團隊與組織會與瀑布模型有所不同，由於敏捷軟體開發重視人與人之間的溝通、交流，也重視與客戶溝通的層面，因此一個能夠成功實踐敏捷開發的組織需要有以下特色：
組織文化必須支持談判
人員彼此信任
人少但是精幹
開發人員所作決定得到認可
環境設施滿足成員間快速溝通之需要（Wikipedia，2015）
但除了「敏捷」一詞以外，其實有大量強調快速的開發模式與敏捷軟體開發非常相似，但使用不同的名詞，這些開發方式也被認為是敏捷開發的一部分。
正確稱呼：敏捷方法
因此「敏捷開發」一詞並非一個完全固定的開發模型，而是泛指任何一個相較於傳統「非敏捷」開發模式來說，較能即刻回應需求變動的方式，皆可被稱為「敏捷（Agile）方法」。
目前被認為屬於敏捷方法的開發模式有：
而使用在敏捷開發的技術，則有TDD（測試驅動）與BDD（行為驅動）等。
敏捷的優缺點
敏捷開發主要的缺點在於過短的迭代開發時間可能會導致軟體功能無法如期完成，一旦時程脫勾越來越嚴重，反而會造成軟體發佈的延遲。
另外敏捷開發強調人與人的溝通，在網路時代逐漸流行遠端或分散工作的情況下，需要更合適的溝通工具，來彌補人員無法見面討論的不足。
快速應用程式開發（RAD）
快速應用程式開發（Rapid Application Development）（以下簡稱 RAD），比起敏捷軟體開發更早被提出來，是為了面對早期「非敏捷」開發模式而設計的一種加速開發的方法。由電腦顧問專家 James Martin在1991年提出，是一種快速生成系統並不會犧牲品質的方法。
快速反應需求，持續迭代
RAD與原型開發方法（Prototyping）有一定程度相似，目標都是對用戶需求做出快速反。RAD的目標是在30天到90天內產出符合需求的軟體，根據80/20法則，最重要的80%功能常常只佔有20%的開發時間，因此若開發者與客戶能夠適度妥協，將能夠讓軟體開發速度大幅提昇。
換句話說，先讓軟體能動，再來討論下一步怎麼進行。
當第一階段軟體交付後，還有需要調整或擴充的地方，再藉由多次迭代開發來滿足。雖然RAD 的歷史比敏捷要早，但在迭代開發以滿足需求變動的部份本質上是非常相似的。
通常會搭配開發工具
RAD在開發技術上有額外的特色，採用RAD模式的軟體開發需要合適的工具來支援，軟體工具的成熟發展有機會蓬勃發展。
例如所謂的「第四代程式語言」（4GL），便是實現RAD開發的一個重要輔助工具。第四代程式語言主要描述不需要紮實的專業技能就能使用的開發技術，例如SQL查詢語言、圖形語言、報表產生工具、應用程式產生器（例如Visual Basic）等等，是一般程式語言再做了更高階抽象化後的樣貌。
運用第四代語言，可以快速替軟體進行原型開發，建立基本功能，上線測試之後再持續迭代修改，這也就是 RAD與原型開發模式的開發流程。
目前常見的RAD開發工具，以大型IDE所提供的程式片段產生器、GUI元件拖拉編輯器等為主，例如微軟的 Visual Basic、寶蘭的Delphi皆自稱為RAD開發工具，蘋果的Xcode與 Google Android Studio 也屬於RAD的工具之一。
但雖然在主流上稱這些具備GUI編輯功能的環境為RAD工具，但其實廣泛的定義下，任何語言的函式庫，或者提供簡潔的指令用來產生介面元件的純開發框架，都被認為是一種第四代語言或RAD工具。所以現在流行的 RoR / Laravel / Symfony / Angular 等等開發框架，皆提供了一系列程式碼鷹架產生器，都可以算是廣義的 RAD 工具之一。
適合的情境與優缺點
王要武在 2008 年制定了幾個適合採用RAD開發模式的情境：
開發的軟體相對獨立，不與其他軟體交互
軟體可利用許多現有的函式庫
系統效能並非關鍵的考慮因素時
應用的開發可以使用高端的軟體開發工具（如4GL）
系統使用範圍較窄（內部使用或面向垂直市場）
專案的執行範圍與時程受到高度限制
系統可靠性並非關鍵的考慮因素
系統可分解成多個獨立的模組
所採用的技術相對成熟（已使用超過一年）
至於RAD的缺點則與敏捷開發差不多，由於兩者皆是採迭代開發，有很高的機率在短期迭代內無法產出令人滿意的成果，長期下來將會拖垮專案進度。但同樣也可以藉由合適的工具與成熟的管理技術來避免。
RAD 的延伸閱讀：
