一：軟體生命週期模型：
概括的說，軟體生命週期由軟體定義、軟體開發和執行維護3個時期組成，每個時期又進一步分成若干個階段。
1：問題定義：
問題定義階段必須回答的關鍵是：“要解決的問題是什麼？”如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只有白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。儘管確切的定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。
通過對客戶的訪問調查，系統分析員扼要地寫出關於問題性質，工程目標和工程規模的書面報告，經過討論何必要的修改之後這份報告應該得到客戶的確認。
2：可行性研究：
這個階段要回答的關鍵是:”對於上一個階段所確定的問題有行得通的解決辦法麼？”為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了得系統分析和設計過程，也就是在比較抽象的高層次上進行的分析和設計過程。可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究這個問題是否值得去解決，是否有可行的解決辦法。
可行性研究的結果是客戶做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程專案才值得繼續進行下去。可行性研究以後的那些階段將需要投入更多的人力物力。及時終止不值得投資的專案，可以避免更多的浪費。
3：需求分析：
這個階段的任務依然不是具體解決問題，而是準確的確定“為了解決這個問題，目標系統必須做什麼”，主要是確定目標系統必須要具備哪些功能。
使用者瞭解他們所面對的問題，知道必須要做什麼，但是通常不能完整準確的表達出他們的要求，更不知道怎麼利用計算機解決問題，軟體開發人員知道怎麼用軟體實現人們的要求，但是對待定的使用者的具體要求並不完全清楚。因此，系統分析員在需求分析階段必須和使用者密切配合，充分交流資訊，以得出經過使用者確認的系統邏輯模型。通常用數字流圖，資料字典和簡要的演算法表示系統的邏輯模型。
4：總體設計：
這個階段必須要回答的關鍵問題是：”概括的說，應該怎麼實現目標系統？”總體設計又稱為概要設計。
首先，應該設計出實現目標系統的幾種可能的方案。通常至少應該設計出低成本，中等成本和高成本3中方案。軟體工程師應該用適當的表達工具描述每種方案，分析每種方案的優缺點，並在充分權衡各種方案的利弊的基礎上，推薦一個最佳的方案。此外，還應該制定出實現最佳方案的詳細計劃，如果客戶接受所推薦的方案，則應該進一步完成下述的主要任務。
上述設計工作確定瞭解決問題的策略及目標系統中應包含的程式，但是，怎麼設計這些程式呢？軟體設計的一條基本原理就是，程式應該模組化，也就是說，一個程式應該由若干個規模按合理的層次結構組織而成。因此，總體設計的另一項主要任務就是設計程式的體系結構，也就是確定有哪些模組組成以及模組間的關係。
5：詳細設計：
總體設計階段以比較抽象概括的方式提出瞭解決問題的辦法，詳細設計階段的任務就是把解決具體化，也就是回答下面這個關鍵問題：“應該怎麼樣具體的實現這個系統呢？”
這個階段的任務還不是編寫程式，而是設計出程式的詳細規格說明，這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，他們應該包含必要的細節，程式設計師可以根據他們寫出實際的程式程式碼。
詳細設計也成為模組化設計，在這個階段將詳細的設計每個模組，確定實現模組功能所需要的演算法和資料結構。
6：編碼和單元測試：
這個階段的關鍵任務是寫出正確的容易理解，容易維護的程式模組。
程式設計師應該根據目標系統的性質和實際環境，選取一種適當的高階程式設計師設計語言，把詳細設計的結果翻譯成用選定的語言書寫的程式，並且仔細測試編出的每一個模組。
7：綜合測試：
這個階段的關鍵任務是通過各種型別的測試使軟體達到預定的要求。
最基本的測試是整合測試和驗收測試，所謂整合測試是根據設計的軟體結構，把經過單元測試檢驗的模組按某種選定的策略裝配起來，在裝配過程中對程式進行必要的測試，所謂驗收測試則是按照規格說明書的規定有使用者對目標系統進行驗收。
通過對軟體測試結果的分析可以預測軟體的可靠性，反之，根據對軟體可靠性的要求，也可以決定測試和除錯過程什麼時候可以結束。
應該用正式的文件資料把測試計劃，詳細測試方案以及實際測試結果儲存下來，作為軟體配置的一個組成部分。
8：軟體維護：
維護階段的關建任務是，通過各種必要的維護活動使系統持久的滿足使用者的需要。
通常有4類維護活動：改正性維護也就是診斷和改正在使用過程中發現的軟體錯誤，適應性維護，及修改軟體以適應環境的變化，完善性維護，即根據使用者的要求改進或擴充軟體使他更完善，預防性維護及修改軟體為將來的維護活動預先做準備。
瀑布模型：
可強迫開發人員採用規範的方法；嚴格的規定了每一個階段必須要提交的文件要求每一個階段交出所有的產品都必須經過質量保證小組的仔細驗證。“瀑布模型是由文件驅動的”這個事實也是他的一個主要缺點，在可執行的軟體產品交付給使用者之前，使用者只能通過文件來了解產品是什麼樣的，但是，僅僅通過寫在紙上的靜態的規格說明，很難全面正確的認識動態的軟體產品，而且事實證明，一旦一個使用者開始使用一個軟體，在他的頭腦中關於該軟體應該做什麼的想法就會或多或少的發生變化，這就是使得最初的需求變得不完全試用了，事實上，要求使用者不經過實踐就提出完整準確的需求，在許多情況下都是不切實際的，總之，由於瀑布模型幾乎完全依賴於書面的規格說明，很可能導致最終開發的軟體產品不能真正滿足使用者的需求。
快速原型模型：
軟體產品的開發基本上是線性順序進行的，能基本上做到線性順序開發。開發人員通過建立原型系統已經學到了許多東西，因此，再設計和編碼階段發生錯誤的可能性比較小，這自然減少了在後續階段需要改正前面階段所犯錯誤的可能性。
增量模型：
目標都是一次就把一個滿足所有需求的產品提交給使用者。增量模型則與之相反，他分批的逐步提交產品，整個軟體產品被分解成許多個增量構建，開發人員一個構建借一個構件的向用戶提交產品，從第一個構建交付之日起，使用者就能做一些有用的工作，顯然，能在較短時間內向使用者提交可完成部分工作的產品，是增量模型的一個優點。
螺旋模型：
對可選方案和約束條件的強調有利於已有軟體的重用，也有助於把軟體質量作為軟體開發的一個重要目標，減少了過多測試或測試不足所帶來的風險，更重要的是，在螺旋模型中維護只是模型的另一個週期，在維護和開發之間並沒有本質區別。螺旋模型的主要優勢在於，他是風險驅動的，但是，這也可能是他的一個弱點，除非軟體開發人員具有豐富的風險評估經驗和這方面的專門知識，否則將出現真正的風險，當專案實際上正在走向災難時，開發人員可能還認為一切正常。