軟體危機與軟體工程
在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）所舉辦研討會的名稱，也在此時對外宣布這個概念。軟體工程旨在研究和應用如何以系統性的、規範化的、可定量的程序化方法去開發和維護軟體，以及如何把合適的管理技術與軟體開發執行技術結合起來的一門學問。（Wikipedia，2015）
在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）
由此可見軟體工程的領域已經非常龐大，需要夠大的開發團隊，才能夠掌握所有面相。其中「軟體開發流程」是影響一個軟體開發速度與品質管理的重要項目。採用正確的發流程，小型團隊也能夠掌握複雜的開發工作，降低失敗的機率及避免系統開發者陷入「焦油坑」（Brooks，1975）。以下將簡介幾個目前常見或常被討論的軟體開發流程與方法，皆被視為實踐軟體工程的方式之一。
瀑布流模型
瀑布流模型（Waterfall Model）是軟體開發流程與步驟的一種理論模式，其概念在名詞被提出前已廣泛流傳在不同的開發者之間，之後Winston W. Royce在1970年作了一次完整的描述。在瀑布流模型中，軟體開發被分為為需求分析，設計，實作，測試，整合與維護這樣的步驟依序進行，並強調系統開發應該要有完整的週期，每一次的調整、修改，都必須從頭依序經歷這些階段，如圖所示：
由於每一個週期都要自上而下依序進行，因此被稱為瀑布流（Waterfall），或稱「系統發展生命週期」（System Development Life Cycle，SDLC）。瀑布流的支持者認為，在軟體規劃時期的成本遠低於開發時期，因此應該要在規劃時清楚的分析需求，才能進入開發階段。一旦有任何錯誤在開發階段或開發完成後才被察覺，其補救成本可能是預先排除問題的50到200倍。另外，瀑布流也非常重視文件的撰寫。支持者認為大型軟體的開發沒有人可以獨力了解所有面相，隨著人員的去留，只有完整的文件才能確保軟體結構穩定且健壯，新進人員可以藉由閱讀文件快速進入狀況，參與開發。 由於瀑布流強調必須嚴格遵循整個開發與規劃流程的循環，因此導致的是其執行效率低落，即便在Royce的文章中，也認為這個模型不見得可以正常的運作。Parnas等人（2011）則認為客戶常常看見實際開發的系統後，才察覺到需要調整的地方，因此會造成軟體設計被持續更改、重建，造成不必要的成本支出，意味軟體的需求規格總是無法在規劃期就完美的確認。但整體而言，多數人還是認為瀑布流適用於大型企業的軟體開發工作，且嚴格遵循瀑布流的軟體在結構穩定性與品質上是非常優良的。
敏捷軟體開發
敏捷軟體開發（Agile software development）（以下簡稱「敏捷開發」）是1990年代開始逐漸引起關注的新興軟體開發方式，此名詞在在2001年，由一群已經在使用此開發方式的實踐者，聚集在美國猶他州雪鳥滑雪勝地共同宣布，此次會議又稱「雪鳥會議」。 此開發方式的特色是能夠應付快速需求變化，讓開發團隊更緊密的溝通協調，也更適合中小型開發團隊使用。其開發過程採用迭代的方式，每個階段重功能後再進行下一階段。與其他「非敏捷」開發方式相比，敏捷開發的重點在強調四個原則：
- 重視人與人之間的互動，而非工具與規範。
- 直接開發出可用的軟體，並以程式本身做為文件與討論依據，而非依賴大量文書文件。
- 與客戶密切合作、討論，尋求解決方案，而非依賴合約。
- 隨時快速的回應變化做調整，而非永遠遵循預定計畫。
由此可見，敏捷軟體開發並不意味著開發速度的「快」，而是對變動的即時反應與彈性，並把程式碼本身當成溝通用文件，省去程式以外不必要的大量繁瑣細節，因為每一次的需求變動，會讓那些辛苦寫完的文件失去價值。對比於瀑布模型嚴格遵循計畫流程來說，敏捷開發較能適應高度變化的市場與不確定最終需求的專案。
適用於敏捷開發的團隊與組織會與瀑布模型有所不同，由於敏捷軟體開發重視人與人之間的溝通、交流，也重視與客戶溝通的層面，因此一個能夠成功實踐敏捷開發的組織需要有以下特色：
- 組織文化必須支持談判
- 人員彼此信任
- 人少但是精幹
- 開發人員所作決定得到認可
- 環境設施滿足成員間快速溝通之需要（Wikipedia，2015）
但除了「敏捷」一詞以外，其實有大量強調快速的開發模式與敏捷軟體開發非常相似，但使用不同的名詞，這些開發方式也被認為是敏捷開發的一部分。因此「敏捷開發」一詞並非一個完全固定的開發模型，而是泛指任何一個相較於傳統「非敏捷」開發模式來說，較能即刻回應需求變動的方式，皆可被稱為「敏捷（Agile）方法」。目前被認為屬於敏捷方法的開發模式有：極限編程（Extreme programming，XP）、Scrum、AUP（Agile Unified Process）與Crystal等等。而使用在敏捷開發的技術，則有TDD（測試驅動）與BDD（行為驅動）等。
敏捷開發主要的缺點在於過短的迭代開發時間可能會導致軟體功能無法如期完成，一旦時程脫勾越來越嚴重，反而會造成軟體發佈的延遲。另外敏捷開發強調人與人的溝通，在網路時代逐漸流行遠端或分散工作的情況下，需要更合適的溝通工具，來彌補人員無法見面討論的不足。
快速應用程式開發
快速應用程式開發（Rapid Application Development）（以下簡稱 RAD），比起敏捷軟體開發更早被提出來，是為了面對早期「非敏捷」開發模式而設計的一種加速開發的方法。由電腦顧問專家 James Martin在1991年提出，是一種快速生成系統並不會犧牲品質的方法。RAD與原型開發方法（Prototyping）有一定程度相似，目標都是對用戶需求做出快速反。RAD的目標是在30天到90天內產出符合需求的軟體，根據80/20法則，最重要的80%功能常常只佔有20%的開發時間，因此若開發者與客戶能夠適度妥協，將能夠讓軟體開發速度大幅提昇。當第一階段軟體交付後，還有需要調整或擴充的地方，再藉由多次迭代開發來滿足。（MBA智庫百科，2015）雖然RAD並不列為敏捷開發的一種，但在迭代開發以滿足需求變動的部份本質上是非常相似的。
RAD在開發技術上有額外的特色，採用RAD模式的軟體開發需要合適的工具來支援，軟體工具的成熟發展有機會蓬勃發展。例如所謂的「第四代程式語言」（4GL），便是實現RAD開發的一個重要輔助工具。第四代程式語言主要描述不需要紮實的專業技能就能使用的開發技術，例如SQL查詢語言、圖形語言、報表產生工具、應用程式產生器（例如Visual Basic）等等，是一般程式語言再做了更高階抽象化後的樣貌。運用第四代語言，可以快速替軟體進行原型開發，建立基本功能，上線測試之後再持續迭代修改，這也就是 RAD與原型開發模式的開發流程。
目前常見的RAD開發工具，以大型IDE所提供的程式片段產生器、GUI元件拖拉編輯器等為主，例如微軟的 Visual Basic、寶蘭的Delphi皆自稱為RAD開發工具，蘋果的Xcode也屬於RAD的工具之一。但雖然在主流上稱這些具備GUI編輯功能的環境為RAD工具，但其實廣泛的定義下，任何語言的函式庫，或者提供簡潔的指令用來產生介面元件的純開發框架，都被認為是一種第四代語言或RAD工具。
王要武（2008）制定了幾個適合採用RAD開發模式的情境：
- 開發的軟體相對獨立，不與其他軟體交互
- 軟體可利用許多現有的函式庫
- 系統效能並非關鍵的考慮因素時
- 應用的開發可以使用高端的軟體開發工具（如4GL）
- 系統使用範圍較窄（內部使用或面向垂直市場）
- 專案的執行範圍與時程受到高度限制
- 系統可靠性並非關鍵的考慮因素
- 系統可分解成多個獨立的模組
- 所採用的技術相對成熟（已使用超過一年）
至於RAD的缺點則與敏捷開發差不多，由於兩者皆是採迭代開發，有很高的機率在短期迭代內無法產出令人滿意的成果，長期下來將會拖垮專案進度。但同樣也可以藉由合適的工具與成熟的管理技術來避免。
來源 https://scholars.lib.ntu.edu.tw/handle/123456789/24759
