線性順序模型

簡介

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

模型核心思想

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

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

系統/信息工程和建模

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

軟體需求分析

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

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

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

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

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