軟體開發重點應該放在哪個階段

1. 軟體開發的流程都有哪些步驟呢

軟體開發是指一個軟體項目的開發，如市場調查，需求分析，可行性分析，初步設計，詳細設計，形成文檔，建立初步模型，編寫詳細代碼，測試修改，發布等。

軟體是怎麼樣開發出來的

第一個步驟是市場調研，技術和市場要結合才能體現最大價值。

第二個步驟是需求分析，這個階段需要出三樣東西，用戶視圖，數據詞典和用戶操作手 冊。

用戶視圖 是該軟體用戶（包括終端用戶和管理用戶）所能看到的頁面樣式，這裡麵包含了 很多操作方面的流程和條件。

數據詞典 是指明數據邏輯關系並加以整理的東東，完成了數據詞典，資料庫的設計就完成了一半多。

用戶操作手冊是指明了操作流程的說明書。

請注意，用戶操作流程和用戶視圖是由需求決定的，因此應該在軟體設計之前完成，完成這些，就為程序研發提供了約束和准繩，很遺憾太多公司都不是這樣做的，因果顛倒，順序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。

需求分析，除了以上工作，筆者以為作為項目設計者應當完整的做出項目的性能需求說明 書，因為往往性能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或公司市場部門）能夠有真正的溝通和了解。

第三個步驟是概要設計，將系統功能模塊初步劃分，並給出合理的研發流程和資源要求。
作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常採用這種方法是因為涉及的研發任務屬於新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是 並不是說詳細設計說明書不重要，事實上快速原型法在完成原型代碼後，根據評測結果和 經驗教訓的總結，還要重新進行詳細設計的步驟。

第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把 具體的模塊以最』干凈』的方式(黑箱結構）提供給編碼者，使得系統整體模塊化達到最 大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低，實際上，嚴格的講詳細 設計說明書應當把每個函數的每個參數的定義都精精細細的提供出來，從需求分析到概要 設計到完成詳細設計說明書，一個軟體項目就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行代碼工作。

那些把作軟體的程序員簡單理解為寫代碼的，就從根子上犯了錯誤了。

第五個步驟是編碼，在規范化的研發流程中，編碼工作在整個項目流程里最多不會超過1/ 2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提 高，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在很多研發過程中都 出現過。
編碼時的相互溝通和應急的解決手段都是相當重要的，對於程序員而言，bug永 遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候 嗎？從來沒有！

第六個步驟是測試

測試有很多種：

按照測試執行方，可以分為內部測試和外部測試

按照測試范圍，可以分為模塊測試和整體聯調

按照測試條件，可以分為正常操作情況測試和異常情況測試

按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試

以上都很好理解，不再解釋。

總之，測試同樣是項目研發中一個相當重要的步驟，對於一個大型軟體，3個月到1年的外部測試都是正常的，因為永遠都會又不可預料的問題存在。

完成測試後，完成驗收並完成最後的一些幫助文檔，整體項目才算告一段落，當然日後少不了升級，修補等等工作，只要不是想通過一錘子買賣騙錢，就要不停的跟蹤軟體的運營 狀況並持續修補升級，直到這個軟體被徹底淘汰為止。

什麼是軟體開發的核心問題

按照軟體工程鼻祖，《人月神話》作者 Brooks 在「沒有銀彈——軟體工程中的根本和次要問題」一章中闡述的思想，軟體開發的核心問題就是如何從概念上對一個復雜的業務系統進行建模。這個建模是含義廣泛的，不僅僅包括對象建模，還包括數據建模、演算法建模等等一系列的內容。總而言之是要先找到解決復雜問題的突破口（先要搞明白需要做什麼，然後再考慮如何做）。至於採用什麼表示方法（簡單文本、UML 圖、E-R 圖）、採用什麼高級語言、是否一定要用面向對象、使用什麼開發工具都是次要的問題。

軟體開發方法

軟體開發方法(Software Development Method)是指軟體開發過程所遵循的辦法和步驟。
軟體開發活動的目的是有效地得到一些工作產物，也就是一個運行的系統及其支持文檔，並且滿足有關的質量要求。軟體開發是一種非常復雜的腦力勞動，所以經常更多討論的是軟體開發方法學，指的是規則、方法和工具的集成，既支持開發，也支持以後的演變過程(交付運行後，系統還會變化，或是為了改錯，或是為了功能的增減)。

關於組成軟體開發和系統演化的活動有著各種模型(參見軟體生存周期，軟體開發模型，軟體過程)，但是典型地都包含了以下的過程或活動：分析、設計、實現、確認(測試驗收)、演化(維護)。

有些軟體開發方法是專門針對某一開發階段的，屬於局部性的軟體開發方法。
特別是軟體開發的實踐表明，在開發的早期階段多做努力，在後來的測試和維護階段就會使費用較大地得以縮減。因此，針對分析和設計階段的軟體開發方法特別受到重視。其它階段的方法，從程序設計發展的初期起就是研究的重點，
已經發展得比較成熟(參見程序設計，維護過程)。除了分階段的局部性軟體開發方法之外，還有覆蓋開發全過程的全局性方法，尤為軟體開發方法學注意的重點。

對軟體開發方法的一般要求：當提出一種軟體開發方法時，應該考慮許多因素，包括：

①覆蓋開發全過程，並且便於在各階段間的過渡；

②便於在開發各階段中有關人員之間的通信；

③支持有效的解決問題的

④支持系統設計和開發的各種不同途徑；

⑤在開發過程中支持軟體正確性的校驗和驗證；

⑥便於在系統需求中列入設計、實際和性能的約束；

⑦支持設計師和其他技術人員的智力勞動；

⑧在系統的整個生存周期都支持它的演化；

⑨受自動化工具的支持。此外，在開發的所有階段，有關的軟體產物都應該是可見和可控的；軟體開發方法應該可教學、可轉移，還應該是開放的，即可以容納新的技術、管理方法和新工具，並且與已有的標准相適應。

參考：http://www.blog.e.cn/user5/280156/archives/2008/2090192.shtml

2. 互聯網軟體開發過程包括哪幾個階段

1問題定義

問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。

通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。

問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。

2可行性研究

這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。

可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。

在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。

可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。

3需求分析

這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。

用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。

在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。

4總體設計

這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」

首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：

低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。

中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。

高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。

系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。

上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。

5詳細設計

總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」

這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。

通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設計語言）描述詳細設計的結果。

6編碼和單元測試

這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。

程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。

7綜合測試

這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。

最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。

必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。

為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。

通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。

應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。

8軟體維護

維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。

通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。

雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程

3. 軟體開發有哪幾個階段,每個階段的任務是什麼

軟體開發一般分為五個階段：
1.問題的定義及規劃
此階段是軟體開發與需求放共同討論，主要確定軟體的開發目標及其可行性。
2.需求分析
在確定軟體開發可行性的情況下，對軟體需要實現的各個功能進行詳細需求分析。需求分析階段是一個很重要的階段，這一階段做的好，將為整個軟體項目的開發打下良好的基礎。「唯一不變的是變化本身」，同樣軟體需求也是在軟體愛你開發過程中不斷變化和深入的，因此，我們必須定製需求變更計劃來應付這種變化，以保護整個項目的正常進行。
3.軟體設計
此階段中偶要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計、資料庫設計等。軟體設計一般分為總體設計和詳細設計。還的軟體設計將為軟體程序編寫打下良好的基礎。
4.程序編碼
此階段是將軟體設計的結果轉化為計算機可運行的程序代碼。在程序編碼中必定要制定統一、符合標準的編寫規范。以保證程序的可讀性、易維護性。提高程序的運行效率。
5.軟體測試
在軟體設計完成之後要進行嚴密的測試，一發現軟體在整個軟體設計過程中存在的問題並加以糾正。整個測試階段分為單元測試、組裝測試、系統測試三個階段進行。測試方法主要有白盒測試和黑盒測試。

以上就是軟體開發過程的五個階段，但是有的時候在軟體愛你開發過程中並不是必須按照這個過程進行的。

4. 軟體開發步驟包括哪些過程

軟體開發一般分為五個階段：

1.問題的定義及規劃

此階段是軟體開發與需求放共同討論，主要確定軟體的開發目標及其可行性。

2.需求分析

在確定軟體開發可行性的情況下，對軟體需要實現的各個功能進行詳細需求分析。需求分析階段是一個很重要的階段，這一階段做的好，將為整個軟體項目的開發打下良好的基礎。「唯一不變的是變化本身」，同樣軟體需求也是在軟體愛你開發過程中不斷變化和深入的，因此，我們必須定製需求變更計劃來應付這種變化，以保護整個項目的正常進行。

3.軟體設計

此階段中偶要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計、資料庫設計等。軟體設計一般分為總體設計和詳細設計。還的軟體設計將為軟體程序編寫打下良好的基礎。

4.程序編碼

此階段是將軟體設計的結果轉化為計算機可運行的程序代碼。在程序編碼中必定要制定統一、符合標準的編寫規范。以保證程序的可讀性、易維護性。提高程序的運行效率。

5.軟體測試在軟體設計完成之後要進行嚴密的測試，一發現軟體在整個軟體設計過程中存在的問題並加以糾正。整個測試階段分為單元測試、組裝測試、系統測試三個階段進行。測試方法主要有白盒測試和黑盒測試。

5. 軟體開發哪個部分是重點

沒有重點，所有環節都是必不可少的。但這么多環節還是有緩急差別。

需求 > 測試 > 編碼 > BUG維護 > 新業務

我是個小程序員，需求直接影響到設計的好壞，一個正確的需求調研是所有工作的開始，也直接影響到正確的編碼方向和實現方式。如果需求出現了較大偏差，極大的可能會導致後期代碼的重復修改、返工。

測試之所以是第二位，我認為一個工程要上線，必然要經受得住用戶的考驗。在無法得知用戶所有可能使用出現問題的情況下，測試工作尤其重要。如果此時有較大隱患的BUG沒有測試出來，則可能在用戶真實使用中造成用戶實際損失。金融系統尤為可怕。

編碼工作不是不重要，但是沒有測試把關，代碼就是不牢靠的。如果沒有需求和設計，編碼工作是無法開展的。又如果需求工作出現偏差，要反復修改代碼可能會導致原本嚴謹的代碼出現意想不到的漏洞或不完善的地方（拆東牆補西牆的做法）。

如果在現有需求都沒有完成的情況下，因把新增加的需求延後處理。項目開發是有工期限制的，每個程序員工作一天項目組都要為此付出成本。如果用戶增加新需求則看情況而定。但絕對不能影響現有需求開發（一般進入編碼階段，需求確認後會有少量實際改動，都因與用戶有書面協議，如要求添加則另訂）。

以上為我在工作中的看法，請你參考下。

6. 什麼是軟體開發工作的五個階段

F1第一階段軟體工程，免費下載

鏈接:https://pan..com/s/1NMX-eXOtRYFpfcsaYpv3Vw

計劃階段----開發階段----維護階段

計劃階段：問題定義，可行性研究，需求分析

開發階段：概要設計，詳細設計，編碼，測試

維護階段：運行與維護

7. 軟體開發主要分為哪幾個階段

軟體開發一般分為五個階段：
1.問題的定義及規劃
此階段是軟體開發與需求放共同討論，主要確定軟體的開發目標及其可行性。
2.需求分析
在確定軟體開發可行性的情況下，對軟體需要實現的各個功能進行詳細需求分析。需求分析階段是一個很重要的階段，這一階段做的好，將為整個軟體項目的開發打下良好的基礎。「唯一不變的是變化本身」，同樣軟體需求也是在軟體愛你開發過程中不斷變化和深入的，因此，我們必須定製需求變更計劃來應付這種變化，以保護整個項目的正常進行。
3.軟體設計
此階段中偶要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計、資料庫設計等。軟體設計一般分為總體設計和詳細設計。還的軟體設計將為軟體程序編寫打下良好的基礎。
4.程序編碼
此階段是將軟體設計的結果轉化為計算機可運行的程序代碼。在程序編碼中必定要制定統一、符合標準的編寫規范。以保證程序的可讀性、易維護性。提高程序的運行效率。
5.軟體測試
在軟體設計完成之後要進行嚴密的測試，一發現軟體在整個軟體設計過程中存在的問題並加以糾正。整個測試階段分為單元測試、組裝測試、系統測試三個階段進行。測試方法主要有白盒測試和黑盒測試。

8. 軟體開發過程一般有幾個階段每個階段有什麼作用

1、首先制定項目計劃，最初計劃是里程碑性質的。可以先按瀑布模型設置，里程碑點主要為需求評審、設計評審、經過代碼開發和單元測試後進行集成測試、部署上線是一個很重要的里程碑，一般用戶會期望系統何時能使用，進入試運行期。

2、需求開發階段：怎麼樣寫好需求很關鍵，這個需要實踐經驗鍛煉自己。如果有項目成員，可以一起做需求，這個階段對於業務理解、分析、如何開展調研以及文字表述、業務流程圖描述還有文檔編輯能力都有不少要求。一般分為《用戶需求說明書》和《需求規格說明書》，小項目可以寫一個《需求分析報告》，《用戶需求說明書》是用用戶的語言進行描述，讓用戶和開發團隊對於需求的達成一致的理解，《需求規格說明書》，則是對用戶需求的分析，形成系統要具有的功能，這個是真正提供用戶可交互操作的文檔，也就是後期設計和代碼開發的重要基線。
另外，作為了解需求，拿出用戶UI和用戶交流也是一項比較重要的需求獲取手段，雖然這個屬於設計的范疇

3、系統設計階段：
系統總體架構，結合用戶對系統環境、開發語言以及運行的網路硬體等要求，確定開發工具等，對應用系統關系進行架構性設計，通過需求階段對用戶的分析歸類，用圖的方式描述出用戶和各子系統或模塊的全局視圖，以及和其他系統的關系。也就是搞清楚系統的邊界問題。
概要設計中除了高層架構設計，還需要設計網路拓撲圖，以及系統部署圖。概要設計比較重要的還有就是子系統、模塊進行合理的劃分。模塊的名稱很大程度上會成為用戶的主要菜單，如何用用戶的角度去取比較清楚的子系統和模塊是很重要的。

4、代碼開發和單元測試階段：這個階段一般來說需要改進瀑布模型，類似跌代開發，把模塊進行合理劃分，把項目總體計劃的代碼開發測試階段劃分為多個時間段，每個時間段都包括代碼開發、單元測試和集成測試，這個階段還需要對需求變更進行跟蹤控制，如果需求有變更，那麼要把需求文檔、設計文檔都重新跟上。跌代開發的好處就是不讓代碼開發階段拉的過程，沒有進行及時的自我檢查，不小心到了提交時間，卻不是用戶想要的，還有可能都不是自己想要的。
項目經理重要的責任是控制好進度，能及早發現風險，並能拿出好的預防和解決辦法的措施。合理安排好開發團隊的任務，合時的任務安排和銜接，你會覺得非常有藝術感，這個要自己體會了。另外，關注項目團隊各人員的狀況，保持高的戰鬥力，及時發現並能鼓勵團隊共同朝一個目標前進。

5、測試工作，測試是項目的很重要的環節，怎麼測試，怎麼准確測試，怎麼有效測試，怎麼覆蓋測試，時間、人手、經驗扽個方面都會有制約。高級測試人員能夠分析系統各測試要點，在需求、設計階段都要參與，提早了解如何去測試，能寫出測試用例。

6、文檔工作，文檔在項目開發中也佔有重要位置，除非你覺得代碼是項目唯一的成果，那麼你把文檔拋掉吧，什麼都在你的腦子里，團隊中人員一走，項目的一部分也就帶走了。代碼開發其實也需要文檔，代碼是成果，代碼注釋是成果，模塊開發卷宗也是重要的成果，因為程序員在開發時候的邏輯是怎麼樣的，對於今後查問題很有作用。除非你的系統設計程度到了方法、類，把代碼邏輯也都設計好了，那麼程序員就CODEING去吧。

7、QA是對項目過程的質量保障，有些公司吧QA和測試工作合成一個崗位叫做QA&測試人員，或者就叫QA人員。QA是對項目全過程的監管，獨立於項目之外。監督項目經理在各項目里程碑提交相關成果，入庫形成基線。

9. 軟體生命周期，常說是三個時期八個階段，請問這三個時期的八個階段分別是什麼

軟體計劃與可行性研究階段、需求分析階段、軟體設計階段、軟體編碼階段、軟體測試階段和軟體運行與維護階段。

1、軟體計劃與可行性研究階段：此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。

2、需求分析階段：在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，也是在整個軟體開發過程中不斷變化和深入的階段，能夠為整個軟體開發項目的成功打下良好的基礎。

軟體常見周期模型：

1、瀑布模型

瀑布模型首先由Royce提出。該模型由於酷似瀑布聞名。在該模型中，首先確定需求，並接受客戶和SQA小組的驗證。

然後擬定規格說明，同樣通過驗證後，進入計劃階段…可以看出，瀑布模型中至關重要的一點是只有當一個階段的文檔已經編制好並獲得SQA小組的認可才可以進入下一個階段。

2、迭代式模型

迭代式模型是RUP推薦的周期模型，也是我們在這個系列文章討論的基礎。在RUP中，迭代被定義為：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。

10. 軟體開發過程一般有幾個階段

F1第一階段軟體工程，免費下載

鏈接:https://pan..com/s/1NMX-eXOtRYFpfcsaYpv3Vw

計劃階段----開發階段----維護階段

計劃階段：問題定義，可行性研究，需求分析

開發階段：概要設計，詳細設計，編碼，測試

維護階段：運行與維護