問題定義
問題定義階段必須回答的關鍵問題：“要解決的問題是什麼？”如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出 的結果很可能是毫無意義的。儘管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。
問題定義階段是軟件生存週期中最簡短的階段，一般只需要一天甚至更少的時間。
文檔：項目定義
操作人：項目經理
可行性分析
這個階段要回答的關鍵問題：“對於上一個階段所確定的問題有行得通的解決辦法嗎？”爲了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的範圍，探索這個問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更準確、 更具體地確定工程規模和目標。然後分析員更準確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。
可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入更多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。
文檔：可行性分析
操作人：項目經理
需求分析
這個階段的任務仍然不是具體地解決問題，而是準確地確定“爲了解決這個問題，目標系統必須做什麼”，主要是確定目標系統必須具備哪些功能。用戶瞭解他們所面對的問題，知道必須做什麼，但是通常不能完整準確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟件開發人員知道怎樣使用軟件實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法描述表示系統的邏輯模型。
在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須準確完整地體現用戶的要求。系統分析員通常都是計算機軟件專家，技術專家一般都喜歡很快着手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法爲每個階段都規定了特定的結束標準，需求分析階段必須提供完整準確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於着手進行具體設計的傾向。
文檔：產品需求文檔
操作人：項目經理
概要設計
概要設計的主要任務是把需求分析得到的數據流圖轉換爲軟件結構和數據結構。設計軟件結構的具體任務是：將一個複雜系統按功能進行模塊劃分、建立模塊的層次結構及調用關係、確定模塊間的接口及人機界面等。數據結構設計包括數據特徵的描述、確定數據的結構特性、以及數據庫的設計。顯然，概要設計建立的是目標系統的邏輯模型，與計算機無關。文檔：概要設計文檔
操作人：項目架構師
總體設計
這個階段必須回答的關鍵問題是：“概括地說，應該如何解決這個問題？”首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是數據庫……。通常至少應該考慮下述幾類可能的方案：
低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。
中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。
高成本的“十全十美”的系統。這樣的系統具有用戶可能希望有的所有功能和特點。
系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以着手完成本階段的另一項主要工作。
上面的 工作確定瞭解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多 規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟件的結構，也就是確定程序由哪些模塊組成以及模塊間的關係。通常用層次 圖或結構圖描繪軟件的結構。
即對有關係統全局問題的設計，也就是設計系統總的處理方案，又稱系統概要設計。它包括：計算機配置設計、系統模塊結構設計、數據庫和文件設計、代碼設計以及系統可靠性與內部控制設計等內容。
總體設計簡述
完成大型工程體系的總體方案和總體技術途徑的設計過程。在一般工程設計中總體設計則指按計劃任務書的內容進行概略計算，附以必要的文字說明和圖紙設計，又稱初步設計。對於工程系統工程總體設計是指前一種含義。總體設計是工程項目開發過程中的一個重要階段（見圖）。
研製大型工程體系的基本問題是，怎樣把比較籠統的初始研製要求逐步地變爲成千上萬個研製參加者的具體工作，以及怎樣把這些工作最終綜合成一個技術上先進、經濟上合算、研製週期短、能協調運轉的實際系統，並使這個系統成爲它所從屬的更大系統的有效組成部分。1954年美國最早出現爲導彈研製計劃提供這種服務的系統工程公司──拉莫·沃爾德里奇公司。50年代末中國開始研製人造衛星和運載火箭時，也建立了這樣的機構，並稱之爲總體設計部。總體設計部設計的是系統的總體，系統的總體方案和實現它的技術途徑，並通過可行性研究和技術經濟論證，確保項目在規劃、設計、製造和運行各個階段，總體性能最優。這樣可以避免因規劃、研製和運用的缺陷造成人力、物力和財力的浪費。
文檔：總體設計文檔
操作人：項目架構師
詳細設計
總體設計階段以比較抽象概括的方式提出瞭解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：“應該怎樣具體地實現這個系統呢？”這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。
通常用ＨＩＰＯ圖（層次圖加輸入／處理／輸出圖）或ＰＤＬ語言（過程設計語言）描述詳細設計的結果。
文檔：詳細設計文檔
操作人：項目架構師
編碼和單元測試
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用彙編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。
文檔：單元測試文檔
操作人：測試工程師
集成測試
這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟件達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必 要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。
必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。
爲了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。
通過對軟件測試結果的分析可以預測軟件的可靠性；反之，根據對軟件可靠性的要求也可以決定測試和調試過程什麼時候可以結束。
應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做爲軟件配置的一個組成成分。
文檔：集成測試文檔
操作人：測試工程師
軟件維護
維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟件錯誤；適應性維護，即修改軟件以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟件使它更完善；預防性維護，即修改軟件爲將來的維護活動預先做準備。
雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方 案，審批維護方案，確定維護計劃，修改軟件設計，修改程序，測試程序，複查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟件定義和開發的全過 程。
都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟件設計，修改程序，測試程序，複查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟件定義和開發的全過程。
工具推薦
1.軟件開發必備翻牆代理，低延遲(50ms)，月費10元，詳詢（寶哥兒QQ1066690060）請自覺遵守國家法律法規
