軟件研發流程

軟件研發是需要遵從一套成熟的產品研發過程體系，才能做出質量較好的產品。

當然，產品研發過程體系也需要按照業務的實際時間要求而變化，不要拘泥于一定按照瀑布開發方式、或是敏捷開方式進行管理，凡事都需要找到契合自己的方式。鞋合不合腳，只有腳知道。軟件研發流程在以下所描述的各個階段、在項目執行前都要明確各個階段的目標、既定計劃、及時溝通，并確保各個時期所有成員對項目理解一致

一、項目啟動會

項目啟動會是要明確該產品研發項目的目標。目標不是孤立存在的，目標與計劃相輔相成，目標指導計劃，計劃的有效性影響著目標的達成。所以在執行目標的時候，考慮清楚自己的行動計劃，怎么做才能更有效地完成目標，是每個人都要想清楚的問題，否則，目標越是不清晰或是過高，都會影響項目的實際結果。

項目啟動會需要說明***項目目標、階段劃分、組織結構、管理流程***等關鍵事項，將這些內容寫成文檔并達成一致。

二、用戶需求

軟件研發前需要確定研發代價和所獲得價值的對比，確定需要研發，再安排一系列的資源來支撐這個軟件的生存。用戶需求由用戶提出，對技術一般不描述，只描述項目目標。用戶需求關注的是系統如何支持業務流程，背后的需求是“實現業務目標”。

三、產品需求

產品需求是根據用戶需求轉化而來的技術實現需求，需要針對用戶提出的產品目標進行細分，總結出具體的功能點，再對功能點細分為各種不同的操作流程。產品需求關注的是合理技術方案，背后的需求是“工作量”、“實現難度”和“系統性能”。產品需求一般包括產品需求規格說明書和產品需求矩陣。產品需求矩陣一般按照子系統、功能集、執行單元的結構列出所有的功能需求，每列則對應每項功能的工作步驟以及每個步驟的工作量。產品需求完成后，需要進行評審。在需求評審會上，產品、技術詳細評審需求是否完整，產品功能的正常場景是什么？是否形成閉環？異常場景是什么？是否考慮周全？需求評審后，開發和測試負責人，分別編寫技術方案和測試用例。技術方案評審，開發負責人拉上涉及到其他系統的負責人一起討論，技術方案中必須要有業務流程圖和時序圖，業務流程圖是為了梳理開發對業務的理解，是否和需求一致。時序圖是為了梳理本次需求涉及的系統交互。技術方案評審通過后，確認工作量和交付時間，反饋給產品。

四、總體設計

設計階段的目標是對待開發的系統構架進行分析和設計，為之后的實施工作提供一個穩定的基礎。

設計階段包括了系統架構的輸出，好的系統架構設計可以幫助梳理業務邏輯且抓住核心需求，設計穩定可擴展的業務系統，評估業務開發周期和開發成本，有效的規避風險。總體設計是整個系統的框架型設計，一般情況下不能省略（只有維護項目可以省略總體設計，因為項目前期已經設計完畢）。所有研發項目均需要首先進行總體設計，它是設計首要步驟，決不允許本末倒置，不能出現先編碼后設計的情況，這是軟件研發的第二大痛點（第一大是需求不明確、任意變更需求）。

總體設計分為三個階段：

1.初始設計。在對給定的數據流圖進行復審和精化的基礎上，將其轉化為初始的模塊結構圖。

2.精化設計。依據模塊“高內聚低耦合”的原則，精化初始的模塊結構圖，并設計其中的全局數據結構和每一模塊的接口。

3.設計復審階段，對前兩個階段進行復審，必要時還可能需要對軟件結構做一些精化工作。

五、概要設計

概要設計的目的是描述系統的每個模塊的內部設計，對總體設計和詳細設計承擔承上啟下的作用。

概要設計按照結構化設計方法進行。在概要設計階段，應最大限度地提取可以重用的模塊，建立合理的結構體系，節省后續環節的工作量。

概要設計文檔最重要的部分是分層數據流圖、結構圖、數據字典以及相應的文字說明等。以概要設計文檔為依據，各個模塊的詳細設計就可以并行展開了。

六、詳細設計

詳細設計階段就是依據概要設計階段的分解，設計每個模塊內的算法、流程，為每個模塊完成的功能進行具體的描述，要把功能描述轉變為精確的、結構化的過程描述。

詳細設計文檔最重要的部分是模塊的流程圖、狀態圖、局部變量及相應的文字說明等。一個模塊對應一篇詳細設計文檔。

詳細設計最終是將軟件系統的各個部分的具體設計方法、邏輯、功能采用文字方式進行表述。這樣在實現過程中，編碼人員原則上嚴格按此進行代碼實現即可。

七、代碼編寫

編寫代碼可以遵循以下幾點原則：

1.做好核心模塊壓測：做好這一點需要懂一些業務，要知道業務壓力在哪里，業務請求的重心在哪里。

2.確保過程可控：代碼執行時要保持中間的輸出，比如說，每處理 10 萬條日志，寫一條狀態日志，記錄處理的日志條目數和當前的執行時間。

3.多寫注釋：多寫注釋，說明代碼實現業務情況及優化思路等。

4.簡單易懂的邏輯：千萬不要把自己繞進去了，時間一長，誰都看不明白你的邏輯。如果邏輯真的很難在一個函數內完成，嘗試切分。

5.使用熟悉、成熟的技術：使用新技術前，建議全面了解該技術的特征、適用范圍、不適用的范圍。

八、代碼審核

團隊代碼審查可以提升代碼質量，分享項目知識、明確責任，最終達到構建更好的軟件、更好的團隊。

代碼審核及其重要，一般來說每周都要做一次代碼審核。

代碼審核有利于你跟蹤項目進展情況，首先，我們能真實地看到研發人員進展如何，并且更早發現他們是否誤入歧途。

九、單元測試

所謂“單元”指的是代碼調用的最小單位，實際上指的是一個功能塊（Function）或者方法（Method）。所以單元測試指的就是對這些代碼調用單元的測試。

單元測試是白盒測試，就是必須要對單元的代碼細節很清楚才能做的測試。所以，單元測試的編寫和執行都是由軟件工程師來做的。

十、集成測試

集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。一些局部反映不出來的問題，在全局上很可能暴露出來。

集成測試是黑盒測試，主要是由測試人員根據軟件的功能手冊來進行測試，需要有專門的測試環境配合。集成測試又分功能測試、回歸測試等。

十一、系統測試

系統測試階段包括系統測試方案及用例編寫、功能性測試、性能測試、穩定性測試。

為了驗證需求確定的功能是否齊全并被正確實現，同時還要對安裝、部署、適應性、安全性、界面等非功能性需求進行測試。系統測試也由測試人員負責，應該在需求分析完成后進行設計，在集成測試完成后進行實施。

功能性測試一般由獨立測試小組采用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。

在經過以上各階段測試確認之后，把系統完整地模擬客戶環境來進行的測試。系統測試是將已經確認的軟件、計算機硬件、外設、網絡等其他元素結合在一起，進行信息系統的各種組裝測試和確認測試，其目的是通過與系統的需求相比較，發現所開發的系統與用戶需求不符或矛盾的地方，從而提出更加完善的方案。

性能測試驗證系統的穩定性和效率，檢查系統是否滿足規定的性能要求。性能測試通常選擇一些典型的功能，檢驗這些功能在大量用戶同時使用系統時系統是否穩定。性能測試由測試人員負責，可以在系統測試完成后進行，也可以對重要模塊先進行性能測試，可以貫穿整個測試周期，目的是盡早發現系統的性能瓶頸并提早解決。

穩定性測試和性能測試都必須等到系統基本沒問題、趨于穩定時再進行才有效果，否則很難順利測下去，出現異常也不能定位究竟是系統架構的問題，還是功能上的缺陷。

穩定性測試（亦可稱可靠性測試）通過給系統加載一定的業務壓力，讓系統持續運行一段時間（一般為 7x24 小時），檢測系統是否能夠穩定運行。

十二、產品發布

產品發布是系統測試結束后的最后一步，產品發布前需要通過產品發布說明會形式，對整個產品開發過程從立項開始回溯過程，指出整個過程中的不足點，總結經驗，為下一個項目提供經驗案例。

這一會議可以通過正式會議形式召開，需要召集產品經理、主要開發人員、測試人員、上級領導等參與，準備充分，盡最大可能說清楚這個產品發布之后的效果、效益，為上線后的價值評估做準備。

十三、開發過程復盤

只有帶著問題去思考才會有收獲，這就是復盤。

總結項目經驗教訓的目的，在于及時總結問題、解決問題并分析原因，避免以后犯同樣的錯誤，而不是追究誰的責任。

總結

以上是生活随笔為你收集整理的软件研发流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。