線性順序模型

軟件工程的線性順序模型，有時也稱“傳統生命週期”或“瀑布模型”，線性順序模型提出了軟件開發的系統化的、順序的方法（雖然由Winston Royce[ROY70]提出的最早的瀑布模型支持帶有反饋的循環，但大多數使用該過程模型的組織均把它視為是嚴格線性的），從系統級開始，隨後是分析、設計、編碼、測試和維護。 ^[1] 

瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟件生命週期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。 ^[2] 

瀑布模型是最早出現的軟件開發模型，在軟件工程中佔有重要的地位，它提供了軟件開發的基本框架。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。對於經常變化的項目而言，瀑布模型毫無價值。 ^[2] 

因為軟件總是一個大系統（或商業）的組成部分，所以一開始應該建立所有系統成分的需求，然後再將其中某個子集分配給軟件。整個系統基礎是，以軟件作為其他成分如硬件、人及數據庫的接口。系統工程和分析包括了系統級收集的需求，以及一小部分頂層分析和設計。信息工程包括了在戰略商業級和商業領域級收集的需求。 ^[3] 

需求收集過程特別集中於軟件上。要理解待建造程序的本質，軟件工程師（“分析員”）必須瞭解軟件的信息領域以及需求的功能、行為、性能和接口。系統需求和軟件需求均要文檔化，並與用户一起復審。

設計：軟件設計實際上是一個多步驟的過程，集中於程序的四個完全不同的屬性上：數據結構、軟件體系結構、界面表示及過程（算法）細節。設計過程將需求轉換成軟件表示，在編碼之前可以評估其質量。象需求一樣，設計也要文檔化，並且是軟件配置的一部分。

代碼生成：設計必須轉換成機器可讀的形式。代碼生成這一步就是完成這個任務的。如果設計已經表示得很詳細，代碼生成可以自動完成。

測試：一旦生成了代碼，就可以開始程序測試。測試過程集中於軟件的內部邏輯——保證所有語句都測試到，以及外部功能——即引導測試去發現錯誤，並保證定義好的輸入能夠產生與預期結果相同的輸出。

維護：軟件在交付給用户之後不可避免地要發生修改（一個可能的例外是嵌入式軟件）。在如下情況下會發生修改：當遇到錯誤時；當軟件必須適應外部環境的變化時（例如，因為使用新的操作系統或外設）；或者當用户希望增強功能或性能時。軟件維護重複以前各個階段，不同之處在於它是針對已有的程序，而非新程序。 ^[3] 

1）階段間的順序性和依賴性，項目從開始到結束按照一定的順序執行；瀑布模型是文檔驅動的，各個階段不連續也不交叉。

2）嚴格階段評估，必須先進行一個階段嚴格評估才能進入下一個階段。

3）開發初期需要清楚全部需求。

4）開發週期長，風險大。 ^[3] 

1）實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。

2）很多情況下客户難以表達真正的需求，而這種模型卻要求如此，這種模型是不“歡迎”具有二義性問題存在的。

3）客户要等到開發週期的末期才能看到程序運行的測試版本，而在這時發現大的錯誤時，可能引起客户的驚慌，而造成的後果也可能是災難性的。

4）經常會在過程的開始和結束時碰到等待其他成員完成其所依賴的任務才能進行下去的情況，有可能花在等待的時間比開發的時間要長，稱為“堵塞狀態”。 ^[3] 

1）它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該模板下有一個共同的指導。

2）儘管有不少缺陷，但比在軟件開發中呈現隨意的狀態要好得多。 ^[3]