軟體工程是研究和應用如何以系統性的、規範化的
、可定量的過程化方法去開發和維護軟體,以及如
何把經過時間考驗而證明正確的管理技術和當前能
夠得到的最好的技術方法結合起來。
瀑布原型
增量迭代
1、問題分析定義
對實際問題進行分析定義、以便更高效的解決該問題。
2、可行性研究
確定這個問題是否值得去解決，避免造成專案資源浪費。
3、需求分析
確定使用者的需求，並分析如何用計算機來實現這些需求，確定的系統邏輯模型必須準確完整地體現使用者的要求。
4、軟體設計
提出解決問題的方法，有結構設計和邏輯設計。
5、編碼實現
用特定的計算機語言實現前面的方法
6、測試
單元測試，整合測試
7、執行維護
通過各種必要的維護活動使系統持久地滿足使用者的需要。
下面給出詳細的步驟說明
１問題定義
問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試**決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出 的結果很可能是毫無意義的。儘管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的乙個步驟。
通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際使用者和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的 理解，並在使用者和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不清的地方，改正理解不正確的地方，最後得出乙份雙方都滿意的文件。
問題定義階段是軟體生存週期中最簡短的階段，一般只需要一天甚至更少的時間。
２可行性研究
這個階段要回答的關鍵問題：「對於上乙個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。
可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的範圍，探索這個問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該匯出系統的高層邏輯模型（通常用資料流圖表示），並且在此基礎上更準確、 更具體地確定工程規模和目標。然後分析員更準確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。
可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程專案才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程專案，可以避免更大的浪費。
３需求分析
這個階段的任務仍然不是具體地解決問題，而是準確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。
使用者了解他們所面對的問題，知道必須做什麼，但是通常不能完整準確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使 用軟體實現人們的要求，但是對特定使用者的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和使用者密切配合，充分交流資訊，以得出經過使用者確認的系 統邏輯模型。通常用資料流圖、資料字典和簡要的演算法描述表示系統的邏輯模型。
４總體設計
這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」
首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機互動方式；資訊儲存使用傳統的檔案系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：
低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。
中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有使用者沒有具體指定的某些功能和特點。雖然使用者沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。
高成本的「十全十美」的系統。這樣的系統具有使用者可能希望有的所有功能和特點。
系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦乙個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計畫。如果使用者接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。
上面的 工作確定了解決問題的策略以及目標系統需要哪些程式，但是，怎樣設計這些程式呢？結構設計的一條基本原理就是程式應該模組化，也就是乙個大程式應該由許多 規模適中的模組按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程式由哪些模組組成以及模組間的關係。通常用層次 圖或結構圖描繪軟體的結構。
５詳細設計
總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」
這個階段的任務還不是編寫程式，而是設計出程式的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程式設計師可以根據它們寫出實際的程式**。
通常用ｈｉｐｏ圖（層次圖加輸入／處理／輸出圖）或ｐｄｌ語言（過程設計語言）描述詳細設計的結果。
６編碼和單元測試
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程式模組。
程式設計師應該根據目標系統的性質和實際環境，選取一種適當的高階程式語言（必要時用組合語言），把說細設計的結果翻譯成用選定的語言書寫的程式，並且仔細測試編寫出的每乙個模組。
７綜合測試
這個階段的關鍵任務是通過各種型別的測試（及相應的除錯）使軟體達到預定的要求。
最基本的測試是整合測試和驗收測試。所謂整合測試是根據設計的軟體結構，把經過單元測試檢驗的模組按某種選定的策略裝配起來，在裝配過程中對程式進行必 要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由使用者（或在使用者積極參加下）對目標系統進行驗收。
必要時還可以再通過現場測試或平行執行等方法對目標系統進一步測試檢驗。
為了使使用者能夠積極參加驗收測試，並且在系統投入生產性執行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對使用者進行培訓。
通過對軟體測試結果的分析可以**軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和除錯過程什麼時候可以結束。
應該用正式的文件資料把測試計畫、詳細測試方案以及實際測試結果儲存下來，做為軟體配置的乙個組成成分。
８軟體維護
維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足使用者的需要。
通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據使用者的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做準備。
雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方 案，審批維護方案，確定維護計畫，修改軟體設計，修改程式，測試程式，複查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過 程。
都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計畫，修改軟體設計，修改程式，測試程式，複查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
軟體開發過程
1.程式設計師寫出自認為沒有bug的 2.軟體測試，發現了20個bug。3.程式設計師修改了10個bug，並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作，同時又發現了15個新bug。5.重複3次步驟3和步驟4。6.鑑於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，...
軟體開發過程
1.程式設計師寫出自認為沒有bug的 2.軟體測試，發現了20個bug。3.程式設計師修改了10個bug，並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作，同時又發現了15個新bug。5.重複3次步驟3和步驟4。6.鑑於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，...
軟體開發過程
軟體生命週期 1 問題定義 使用者需要解決什麼問題?2 可行性分析 使用者需要解決的問題是否可行 技術可行性 市場可行性 3 需求分析 將使用者提出的問題進行細化 4 系統設計 確定細化問題的實現方法 5 編碼 依據需求和設計穩定進行開發，解決問題 6 測試 驗證是否已經解決使用者提出的問題 單元測...