1.瀑布模型
瀑布模型將軟件的生命周期劃分為：制定計劃、需求分析、軟件設計、程序編寫、軟件測試、運行維護六個基本活動，并規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
瀑布模型將軟件生命周期分為三個大階段：定義階段，開發階段，運行和維護階段。瀑布模型的階段間具有順序性和依賴性：前一階段完成后,才能開始后一階段；前一階段的輸出文本為后一階段的輸入文本。
在瀑布模型的每個階段都堅持：
（1）每個階段都必須完成每個階段規定的文檔。
（2）每個階段結束前都要對所完成的文檔進行評審軟件工程中常用的軟件開發模型，以便于盡早發現問題，改正錯誤。
2.軟件生命周期
軟件生命周期分為三個階段：軟件定義、軟件開發、運行維護。軟件定義時期，確定軟件開發工程中的總目標，確定工程的可行性。估計完成該工程的時間成本，并且制定工程進度表。開發階段，具體設計和設計前一個時期定義的軟件。運行維護，使軟件持久地滿足用戶的需求。
問題定義：通過對用戶的調查訪問，確立用戶的問題性質，工程目標等。
可行性研究：確立問題研究的范圍與可行性、哪些階段應該投入更多的人力物力。
需求分析：與客戶進行密切訪問充分交流信息，以得出用戶想要的系統邏輯模型（是以后設計和實現目標的基礎）。
總體設計：應該先設計出實現目標系統的幾種可能性方案，還有設計程序的體系結構，即確定程序由哪些模塊組成及模塊之間的關系。
詳細設計：解決了具體實現系統的任務，詳細地設計每個模塊，確定模塊功能所需要的算法及數據結構。
編碼和單元測試：寫出正確的容易理解、易于維護的程序模塊。
綜合測試：通過各種類型的測試達到預定的要求。最基本的測試是集成測試和驗收測試。
3.分析模型
機構化分析導出的分析模型包括數據模型、功能模型、行為模型。該模型以“數據字典”為核心，描述了軟件使用的所有數據對象，圍繞這個核心的是“實體關系圖”、“數據流圖”、“狀態轉換圖”。
實體關系圖：描述數據對象以及對象間的關系，用于數據建模。
數據流圖：描述了數據流在系統中流動的過程，以及指明對數據流進行變換的功能，是用于功能建模的基礎。
狀態轉換圖：描述了對外部事件的響應方式，表示了系統的各種行為模式（稱為狀態）以及在狀態間進行變遷的方式，用于行為建模。
4.軟件設計模型
分析模型中的每一個提供了建立設計模型所需的信息。軟件設計，根據用數據、功能和行為模型表示的軟件需求，采用某種設計方法進行數據設計、體系結構設計、接口設計和過程設計。
數據設計將實體關系圖中描述的對象和對象之間的關系，以及數據字典中描述的詳細數據內容轉為數據結構的定義。
體系結構設計定義軟件系統各主要成分的關系，主要需要分析數據之間怎樣從一個模塊流向另一個模塊以及在模塊內部的流向。
總體設計分為數據設計和體系結構設計。
接口設計根據數據流圖定義軟件內部各成分之間、軟件與其他協同系統之間及軟件與用戶之間的交互機制，主要分析數據從不同的模塊之間如何設計接口，需要用到數據流圖。
過程設計把結構成分轉化為軟件的過程性描述，牽扯到數據狀態的轉換，以及狀態變化的方式。
5.測試過程模型
測試時，首先進行單元測試，再進行組裝測試，最后進行確認測試。
模塊測試：即單元測試。每個模塊對應一個獨立的子功能，將每個模塊作為一個獨立的實體進行測試，確認每一個單元能夠正常運行，在該階段的錯誤通常是編碼和詳細設計的錯誤。由編碼人員自己完成（白盒法）。
系統集成測試：即接口測試、組裝測試。將經測試后的單元模塊按照一定的順序組裝成系統，同時進行測試。重點是模塊之間的相互通信與協調。當規模系統龐大時，進行集成測試一般分為子系統與系統測試（黑盒法）。應當驗證系統是否能夠實現需求分析的功能與性能，由專門的測試部門完成。
確認測試：合格測試或驗收測試。驗證系統是否達到系統規定的要求。
回歸測試：在集成測試與確認測試之間加入回歸測試。當某一個系統測試出現問題時，與該系統相關的系統進行局部測試，不用進行完全測試，節省時間應該返回就行回歸測試。
6.噴泉模型
噴泉模型體現了軟件工程開發過程中的迭代和無縫的特性。噴泉模型也稱迭代模型，認為軟件開發過程的各個階段是相互重疊和多次反復的，就像噴泉一樣，水噴上去又可以落下來，既可以落在中間，又可以落到底部。
不同階段的圓圈相互重疊，表明兩個活動之間存在交迭。
圖中在一個階段中的每一個向下的箭頭表示階段內的迭代。維護的圓圈較小，表示在采取了面向對象范型之后維護的時間縮短了。編碼階段與集成測試階段的重疊較大，說明兩個活動之間存在較大的重疊性軟件工程中常用的軟件開發模型，編碼階段的“單元測試”由編碼人員自己完成。
與瀑布模型相比，瀑布模型是面向問題的一種軟件模型，而噴泉模型是面向對象分析的一種模型，噴泉模型的各個活動之間存在交迭，且每一部分完成之后都要求精，以節省時間。
7.面向對象分析模型
面向對象分析，指的是在一個系統的開發過程中進行了系統業務調查以后，按照面向對象的思想來分析問題。
原型開發指向發現對象，對象也指向原型開發。因為原型開發綜合其他活動進行是為了找出所有對象。早期的原型用于證實客戶的需求，晚期原型用于修改交付用戶前使用的狀態。建立用況圖是用戶使用/需求情況圖。發現對象是必要操作，是建立分析模型的必要環節。詳細說明與發現對象、定義屬性與服務、建立結構與連接、劃分主題有雙向箭頭，詳細分析對模型中的成分進行規范的定義和文字說明，可集中可分散。建立交互圖、狀態圖、活動圖是輔助模型，可有可無。
8.面向對象設計模型
面向對象設計模型分為四大系統：問題域、人機交互、任務管理、數據管理。
右邊主要是面向對象分析模型，5個過程之間無嚴格層次，先抽取一部分對象，按照其屬性與服務相同的歸為一個類，當有很多類時存在結構劃分，當有更多的結構時劃分為主題。對象是在不斷發現的，所以在發現新的對象時，又重新開始進行類與對象的劃分。
9.建模過程框圖
在進行一個軟件模型建立時，應該具有先驗知識、演繹分析、歸納程序、目標協調，然后進行模型構建，再進行可信度分析得到最終模型。
在進行一個軟件模型建立時，應該具有一定的先驗知識。
演繹分析應在一個邏輯上正確、數學上嚴格含義進行。
歸納法建模的主要信息來源是實驗數據，其可信性分析是檢查歸納程序是否按數學上和邏輯上進行。
10.建模的整個過程
將概念模型實例化，再次轉化為計算機執行所需要的設計模型。概念模型中的邊界類可以轉化為操作界面或者系統接口。控制類可以轉化為計算機程序或控制程序。實體類可以轉化為數據庫、文檔或者其他持久化特征的類。
完成9種圖例–完成5種視圖–完成3種轉換。
9種圖例：用例圖、類圖、對象圖、狀態圖、順序圖、協作圖、活動圖、構件圖、部署圖。
5種視圖：用例、邏輯、構件、并發、部署。
3種轉換：現實–業務 業務–概念 概念–設計。
概念模型：向上映射了原始需求，向下為計算機提出了一種更高層次的抽象。
邊界類：界面,所有對計算機的操作都要通過界面進行。
實體類：業務實體的實例化結果 ，添加那些實際業務中使用不到但是轉型計算機邏輯時需要的控制信息。
控制類：原始需求中的動態信息，即業務或用例場景中的步驟和活動。