1問題定義
問題定義階段必須回答的關(guān)鍵問題：“要解決的問題是什么？”如果不知道問題是什么就試圖解決這個(gè)問題，顯然是盲目的，只會(huì)白白浪費(fèi)時(shí)間和金錢，最終得出的結(jié)果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實(shí)踐中它卻可能是最容易被忽視的一個(gè)步驟。
通過問題定義階段的工作，系統(tǒng)分析員應(yīng)該提出關(guān)于問題性質(zhì)、工程目標(biāo)和規(guī)模的書面報(bào)告。通過對系統(tǒng)的實(shí)際用戶和使用部門負(fù)責(zé)人的訪問調(diào)查，分析員扼要地寫出他對問題的理解，并在用戶和使用部門負(fù)責(zé)人的會(huì)議上認(rèn)真討論這份書面報(bào)告，澄清含糊不精的地方，改正理解不正確的地方，最后得出一份雙方都滿意的文檔。
問題定義階段是軟件生存周期中最簡短的階段，一般只需要一天甚至更少的時(shí)間。
2可行性研究
這個(gè)階段要回答的關(guān)鍵問題：“對于上一個(gè)階段所確定的問題有行得通的解決辦法嗎？”為了回答這個(gè)問題，系統(tǒng)分析員需要進(jìn)行一次大大壓縮和簡化了的系統(tǒng)分析和設(shè)計(jì)的過程，也就是在較抽象的高層次上進(jìn)行的分析和設(shè)計(jì)的過程。
可行性研究應(yīng)該比較簡短，這個(gè)階段的任務(wù)不是具體解決問題，而是研究問題的范圍，探索這個(gè)問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標(biāo)和規(guī)模的報(bào)告通常比較含糊。可行性研究階段應(yīng)該導(dǎo)出系統(tǒng)的高層邏輯模型（通常用數(shù)據(jù)流圖表示），并且在此基礎(chǔ)上更準(zhǔn)確、更具體地確定工程規(guī)模和目標(biāo)。然后分析員更準(zhǔn)確地估計(jì)系統(tǒng)的成本和效益，對建議的系統(tǒng)進(jìn)行仔細(xì)的成本／效益分析是這個(gè)階段的主要任務(wù)之一。
可行性研究的結(jié)果是使用部門負(fù)責(zé)人做出是否繼續(xù)進(jìn)行這項(xiàng)工程的決定的重要依據(jù)，一般說來，只有投資可能取得較大效益的那些工程項(xiàng)目才值得繼續(xù)進(jìn)行下去?？尚行匝芯恳院蟮哪切╇A段將需要投入要多的人力物力。及時(shí)中止不值得投資的工程項(xiàng)目，可以避免更大的浪費(fèi)。
3需求分析
這個(gè)階段的任務(wù)仍然不是具體地解決問題，而是準(zhǔn)確地確定“為了解決這個(gè)問題，目標(biāo)系統(tǒng)必須做什么”，主要是確定目標(biāo)系統(tǒng)必須具備哪些功能。
用戶了解他們所面對的問題，知道必須做什么，但是通常不能完整準(zhǔn)確地表達(dá)出他們的要求，更不知道怎樣利用計(jì)算機(jī)解決他們的問題；軟件開發(fā)人員知道怎樣使用軟件實(shí)現(xiàn)人們的要求，但是對特定用戶的具體要求并不完全清楚。因此系統(tǒng)分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經(jīng)過用戶確認(rèn)的系統(tǒng)邏輯模型。通常用數(shù)據(jù)流圖、數(shù)據(jù)字典和簡要的算法描述表示系統(tǒng)的邏輯模型。
在需求分析階段確定的系統(tǒng)邏輯模型是以后設(shè)計(jì)和實(shí)現(xiàn)目標(biāo)系統(tǒng)的基礎(chǔ)，因此必須準(zhǔn)確完整地體現(xiàn)用戶的要求。系統(tǒng)分析員通常都是計(jì)算機(jī)軟件專家，技術(shù)專家一般都喜歡很快著手進(jìn)行具體設(shè)計(jì)，然而，一旦分析員開始談?wù)摮绦蛟O(shè)計(jì)的細(xì)節(jié)，就會(huì)脫離用戶，使他們不能繼續(xù)提出他們的要求和建議。較件工程使用的結(jié)構(gòu)分析設(shè)計(jì)的方法為每個(gè)階段都規(guī)定了特定的結(jié)束標(biāo)準(zhǔn)，需求分析階段必須提供完整準(zhǔn)確的系統(tǒng)邏輯模型，經(jīng)過用戶確認(rèn)之后才能進(jìn)入下一個(gè)階段，這就可以有效地防止和克服急于著手進(jìn)行具體設(shè)計(jì)的傾向。
4總體設(shè)計(jì)
這個(gè)階段必須回答的關(guān)鍵問題是：“概括地說，應(yīng)該如何解決這個(gè)問題？”
首先，應(yīng)該考慮幾種可能的解決方案。列如，目標(biāo)系統(tǒng)的一些主要功能是用計(jì)算機(jī)自動(dòng)完成還是用人工完成；如果使用計(jì)算機(jī)，那么是使用批處理方式還是人機(jī)交互方式；信息存儲(chǔ)使用傳統(tǒng)的文件系統(tǒng)還是數(shù)據(jù)庫……。通常至少應(yīng)該考慮下述幾類可能的方案：
低成本的解決方案。系統(tǒng)只能完成最必要的工作，不能多做一點(diǎn)額處的工作。
中等成本的解決方案。這樣的系統(tǒng)不僅能夠很好地完成預(yù)定的任務(wù)，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點(diǎn)。雖然用戶沒有提出這些具體要求，但是系統(tǒng)分析員根據(jù)自己的知識和經(jīng)驗(yàn)斷定，這些附加的能力在實(shí)踐中將證明是很有價(jià)值的。
高成本的“十全十美”的系統(tǒng)。這樣的系統(tǒng)具有用戶可能希望有的所有功能和特點(diǎn)。
系統(tǒng)分析員應(yīng)該使用系統(tǒng)流程圖或其他工具描述每種可能的系統(tǒng)，估計(jì)每種方案的成本和效益，還應(yīng)該在充分權(quán)衡各種方案的利弊的基礎(chǔ)上,推薦一個(gè)較好的系統(tǒng) (最佳方案),并且制定實(shí)現(xiàn)所推薦的系統(tǒng)的詳細(xì)計(jì)劃。如果用戶接受分析員推薦的系統(tǒng)，則可以著手完成本階段的另一項(xiàng)主要工作。
上面的工作確定了解決問題的策略以及目標(biāo)系統(tǒng)需要哪些程序，但是，怎樣設(shè)計(jì)這些程序呢？結(jié)構(gòu)設(shè)計(jì)的一條基本原理就是程序應(yīng)該模塊化，也就是一個(gè)大程序應(yīng)該由許多規(guī)模適中的模塊按合理的層次結(jié)構(gòu)組織而成。總體設(shè)計(jì)階段的第二項(xiàng)主要任務(wù)就是設(shè)計(jì)軟件的結(jié)構(gòu)，也就是確定程序由哪些模塊組成以及模塊間的關(guān)系。通常用層次圖或結(jié)構(gòu)圖描繪軟件的結(jié)構(gòu)。
5詳細(xì)設(shè)計(jì)
總體設(shè)計(jì)階段以比較抽象概括的方式提出了解決問題的辦法。詳細(xì)設(shè)計(jì)階段的任務(wù)就是把解法具體化，也就是回答下面這個(gè)關(guān)鍵問題：“應(yīng)該怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)呢？”
這個(gè)階段的任務(wù)還不是編寫程序，而是設(shè)計(jì)出程序的詳細(xì)規(guī)格說明。這種規(guī)格說明的作用很類似于其他工程領(lǐng)域中工程師經(jīng)常使用的工程藍(lán)圖，它們應(yīng)該包含必要的細(xì)節(jié)，程序員可以根據(jù)它們寫出實(shí)際的程序代碼。
通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設(shè)計(jì)語言）描述詳細(xì)設(shè)計(jì)的結(jié)果。
6編碼和單元測試
這個(gè)階段的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護(hù)的程序模塊。
程序員應(yīng)該根據(jù)目標(biāo)系統(tǒng)的性質(zhì)和實(shí)際環(huán)境，選取一種適當(dāng)?shù)母呒壋绦蛟O(shè)計(jì)語言（必要時(shí)用匯編語言），把說細(xì)設(shè)計(jì)的結(jié)果翻譯成用選定的語言書寫的程序，并且仔細(xì)測試編寫出的每一個(gè)模塊。
7綜合測試
這個(gè)階段的關(guān)鍵任務(wù)是通過各種類型的測試（及相應(yīng)的調(diào)試）使軟件達(dá)到預(yù)定的要求。
最基本的測試是集成測試和驗(yàn)收測試。所謂集成測試是根據(jù)設(shè)計(jì)的軟件結(jié)構(gòu)，把經(jīng)過單元測試檢驗(yàn)的模塊按某種選定的策略裝配起來，在裝配過程中對程序進(jìn)行必要的測試。所謂驗(yàn)收測試則是按照規(guī)格說明書的規(guī)定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標(biāo)系統(tǒng)進(jìn)行驗(yàn)收。
必要時(shí)還可以再通過現(xiàn)場測試或平行運(yùn)行等方法對目標(biāo)系統(tǒng)進(jìn)一步測試檢驗(yàn)。
為了使用戶能夠積極參加驗(yàn)收測試，并且在系統(tǒng)投入生產(chǎn)性運(yùn)行以后能夠正確有效地使用這個(gè)系統(tǒng)，通常需要以正式的或非正式的方式對用戶進(jìn)行培訓(xùn)。
通過對軟件測試結(jié)果的分析可以預(yù)測軟件的可靠性；反之，根據(jù)對軟件可靠性的要求也可以決定測試和調(diào)試過程什么時(shí)候可以結(jié)束。
應(yīng)該用正式的文檔資料把測試計(jì)劃、詳細(xì)測試方案以及實(shí)際測試結(jié)果保存下來，做為軟件配置的一個(gè)組成成分。
8軟件維護(hù)
維護(hù)階段的關(guān)鍵任務(wù)是，通過各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要。
通常有四類維護(hù)活動(dòng)：改正性維護(hù)，也就是診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯(cuò)誤；適應(yīng)性維護(hù)，即修改軟件以適應(yīng)環(huán)境的變化；完善性維護(hù)，即根據(jù)用戶的要求改進(jìn)或擴(kuò)充軟件使它更完善；預(yù)防性維護(hù)，即修改軟件為將來的維護(hù)活動(dòng)預(yù)先做準(zhǔn)備。
雖然沒有把維護(hù)階段進(jìn)一步劃分成更小的階段，但是實(shí)際上每一項(xiàng)維護(hù)活動(dòng)都應(yīng)該經(jīng)過提出維護(hù)要求（或報(bào)告問題），分析維護(hù)要求，提出維護(hù)要求，提出維護(hù)方案，審批維護(hù)方案，確定維護(hù)計(jì)劃，修改軟件設(shè)計(jì)，修改程序，測試程序，復(fù)查驗(yàn)收等一系列步驟，因此實(shí)質(zhì)上是經(jīng)歷了一次壓縮和簡化了的軟件定義和開發(fā)的全過程。
都應(yīng)該經(jīng)過提出維護(hù)要求（或報(bào)告問題），分析維護(hù)要求，提出維護(hù)要求，提出維護(hù)方案，審批維護(hù)方案，確定維護(hù)計(jì)劃，修改軟件設(shè)計(jì)，修改程序，測試程序，復(fù)查驗(yàn)收等一系列步驟，因此實(shí)質(zhì)上是經(jīng)歷了一次壓縮和簡化了的軟件定義和開發(fā)的全過程。
而對開發(fā)人員來說軟件開發(fā)的每個(gè)階段及相關(guān)內(nèi)容：
1.構(gòu)思
這個(gè)階段主要是提供概念模型，對外提供所要開發(fā)系統(tǒng)的軟件功能設(shè)計(jì)，具體表現(xiàn)在軟件功能說明書。
2.設(shè)計(jì)
這個(gè)階段是對內(nèi)而言的，把概念模型轉(zhuǎn)換為邏輯模型，要列舉出系統(tǒng)軟件對象，如：業(yè)務(wù)對象，導(dǎo)航對象，服務(wù)對象和數(shù)據(jù)存儲(chǔ)對象，這些內(nèi)容具體表現(xiàn)在界面導(dǎo)航說明書，應(yīng)用服務(wù)說明書和數(shù)據(jù)存儲(chǔ)說明書。
3.實(shí)現(xiàn)
這一階段主要是開發(fā)人員編寫代碼，以實(shí)現(xiàn)整個(gè)系統(tǒng)的正常運(yùn)行，把邏輯模型轉(zhuǎn)化為物理模型，并且要提供程序框架說明書(對已有框架可有可無)，程序?qū)ο笳f明書，源碼文檔，API說明。
4.部署
這一階段主要是讓系統(tǒng)發(fā)布、上線，提供發(fā)布包和產(chǎn)品使用說明書。
