軟體開發的生命周期

既然我們以後從事的工作時軟體開發，那麼我們就要對軟體開發的流程先做瞭解，畢竟要從娃娃抓起。早點瞭解軟體開發流程，也就有了軟體開發的思想與動力。

問題定義

問題定義 是軟體定義時期的第一個階段。作為軟體的開發者，在這個階段必須弄清用戶“需要電腦解決什麼問題”。如果在問題尚未明確的情況下就試圖解決這個問題，那麼就會白白浪費時間和精力，結果也毫無意義。所以總結起來問題的定義也是起到了十分重要的位置！

可行性分析

軟體可行性分析 是通過對項目的市場需求、資源供應、建設規模、工藝路線、設備選型、環境影響、資金籌措、盈利能力等方面的研究，從技術、經濟、工程等角度對項目進行調查研究和分析比較，並對項目建成以後可能取得的財務、經濟效益及社會環境影響進行科學預測，為項目決策提供公正、可靠、科學的軟體咨詢意見。

1. 技術角度： 通俗易懂點根據公司的技術來判定項目是否可行，比如：給定時間是否可以完成項目、軟體的質量、軟體的生產率。
2. 經濟角度： 根據公司資金周轉來判斷項目是否可以完成，這裡不只是資金問題，還需要考慮成本、收益、長期盈利與短期盈利。短期利益容易把握，風險較低；長遠利益難以把握，風險較大。
3. 社會因素： 根據項目的社會因素來評判項目是否可以做，比如：社會因素的可行性、法律可行性、社會推廣可行性、使用可行性。想必大家都明白，現在的有些軟體開發會出現抄襲、侵權的現象吧，所以在可行性分析中應當具有相關法律聲明。例如：該系統的開發將不會侵犯任何個人、集體、國家的利益，也不會違反國家的政策與法律。
4. 文檔： 《可行性分析文檔》

需求分析

需求分析 也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細緻的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。

1. 功能需求： 功能性需求即軟體必須完成哪些事，必須實現哪些功能，以及為了向其用戶提供有用的功能所需執行的動作。開發者需要與用戶溝通交流，並核實用戶需求，從幫助用戶完成事務的角度上充分描述外部行為，形成說明書。
2. 非功能用戶需求： 非功能性需求主要包含軟體使用時對性能方面的要求、所依賴的運行環境。軟體設計必須遵循的相關標準、規範、用戶界面設計的具體細節、未來可能的擴充方案等。
3. 設計約束： 設計限制條件，通常是對一些設計或實現方案的約束說明。
4. 文檔： 《軟體需求規格說明書》

需求分析階段的工作，可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。

1. 問題識別： 就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟體運行是所需的記憶體、CPU等)、軟體成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
2. 分析與綜合： 逐步細化所有的軟體功能，找出系統各元素間的聯繫，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。
3. 制訂規格說明書： 即編製文檔，描述需求的文檔稱為軟體需求規格說明書。請註意，需求分析階段的成果是需求規格說明書，向下一階段提交。
4. 評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。

概要設計

概要設計 的主要任務是把需求分析得到的系統擴展用例圖轉換為軟體結構和數據結構。設計軟體結構的具體任務是：將一個複雜系統按功能進行模塊劃分、建立模塊的層次結構及調用關係、確定模塊間的介面及人機界面等。數據結構設計包括數據特征的描述、確定數據的結構特性、以及資料庫的設計。

1. 技術選型： 通過需求分析結果來判斷使用什麼技術來完成項目，構建技術架構，例如：使用SSM+JSP技術等
2. 平臺搭建： 選擇項目搭建所需平臺技術，例如：JDK1.8、tomact8.5、MySQL5.X等
3. 資料庫設計： 實體、數據項、三範式、E-R圖等
4. 功能流程設計： 以模塊為單位進行流程圖的設計
5. UI設計： UI設計，簡稱界面設計。是指對軟體的人機交互、操作邏輯、界面美觀的整體設計。 UI設計師完成
6. 文檔： 《資料庫設計說明書》 、《概要設計說明書》

詳細設計

詳細設計 ，是軟體工程中軟體開發的一個步驟，就是對概要設計的一個細化，就是詳細設計每個模塊實現演算法，所需的局部結構。在詳細設計階段，主要是通過需求分析的結果，設計出滿足用戶需求的軟體系統產品。傳統軟體開發方法的詳細設計主要是用結構化程式設計法。

1. 創建資料庫、表、表關係等
2. 設計每個功能的實現步驟：例如：功能編號、功能名稱、功能描述、輸入項（用戶輸入數據的說明）、數據處理（程式對用戶輸入的數據的處理流程）、輸出項（展示給用戶的視圖界面及數據）等
3. 文檔： 《詳細設計說明書》

編寫編碼

編碼通俗易懂來說，就是需要寫代碼了！對產品根據功能和技術架構來實現功能開發、單元測試、功能測試等

產品測試

軟體測試 ，描述一種用來促進鑒定軟體的正確性、完整性、安全性和質量的過程。軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程。

1. 靜態測試： 對軟體代碼的靜態分析測驗，過程應用數據較少，可以通過人工或機器輔助測試

2. 動態測試： 檢測軟體運行中出現的問題，較靜態測試方式相比，其被稱為動態的原因即為其測試方式主要依賴程式的運用，主要為檢測軟體中動態行為是否缺失、軟體運行效果是否良好。

3. 功能測試（黑盒測試）： 通過數據輸入觀察數據輸出，檢查軟體內部功能是否正常，數據是否一致等等。

4. 性能測試（白盒測試）： 原理為根據軟體內部應用、源代碼等對產品內部工作過程進行調試。測試過程中常將其與軟體內部結構協同展開分析，最大優點即為其能夠有效解決軟體內部應用程式出現的問題，測試過程中常將其與黑盒測試方式結合

5. 系統集成測試： 在單元測試的基礎上，將所有模塊按照設計要求（如根據結構圖）組裝成為子系統或系統，進行集成測試。一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常的工作。一些局部反映不出來的問題，在全局上很可能暴露出來。

6. 壓力測試： 軟體壓力測試是一種基本的質量保證行為。壓力測試是給軟體不斷加壓，強制其在極限的情況下運行，觀察它可以運行到何種程度，從而發現性能缺陷，是通過搭建與實際環境相似的測試環境，通過測試程式在同一時間內或某一段時間內，向系統發送預期數量的交易請求、測試系統在不同壓力情況下的效率狀況，以及系統可以承受的壓力情況。然後做針對性的測試與分析，找到影響系統性能的瓶頸，評估系統在實際使用環境下的效率情況，評價系統性能以及判斷是否需要對應用系統進行優化處理或結構調整。並對系統資源進行優化。

壓力測試可以分為負載測試、併發性能測試、疲勞強度測試

負載測試： 通過增加系統負載來測試系統性能的變化趨勢。並最終確定系統的最大負載不能超過某個值，以確保為用戶提供最大的服務還保證了系統性能。

併發性能測試： 通過逐漸增加用戶量和用戶的併發訪問量，直到系統遇到瓶頸或者不能正常運轉，綜合分析交易執行指標與資源監控指標。

疲勞強度測試： 構建系統穩定運行情況下能夠支持的最大併發度與日常運轉。

軟體的性能可以通過響應時間、併發用戶數、吞吐量、資源利用率等性能指標來衡量。

響應時間： 是指用戶從客戶端發出請求到接收完伺服器返回結果的整個過程所需花費的時間，包含網路傳輸時間以及伺服器處理時間。從用戶角度來看，響應時間應該從客戶端電腦處理用戶操作併發出請求到客戶端程式收到伺服器端返回結果並顯示出來的時間。

併發用戶數： 是指在一定時間內，某一時刻同時與伺服器進行會話操作的用戶數，併發用戶數的類型包括：系統用戶數、同時線上用戶數，業務併發用戶數。

吞吐量： 是指單位時間內，系統處理用戶的請求數或頁面數量，可以直接反映出軟體的承載能力。一般來說，利用每秒鐘的請求數或頁面數量衡量吞吐量；從業務的角度來看，也可以用每天的訪問人數或每小時處理的業務數來衡量。

資源利用率： 是指系統資源（CPU、記憶體）的利用率，通常用資源的實際使用量與總的資源可用量比值來衡量，包括網路、操作系統、資料庫等方面。

產品交付

項目部署、用戶培訓、交付協議款、後期保證協議內期限的產品維護等

總結

軟體開發流程可以分為這幾大步驟：

• 問題定義
• 可行性分析
• 需求分析
• 概要設計
• 詳細設計
• 編寫代碼
• 產品測試
• 產品交付