軟件開發(fā)流程有哪些？完整的軟件開發(fā)流程

說到軟件研發(fā)流程，企業(yè)開發(fā)軟件時會按照基線和定制兩塊并行方式執(zhí)行項目開發(fā)工作。無論什么公司，都需要遵從一套成熟的產(chǎn)品研發(fā)過程體系，才能做出質(zhì)量較好的產(chǎn)品。因此，如果出現(xiàn)項目較多的情況，應該合理地安排基線和定制之前的里程碑，讓基線產(chǎn)品能夠盡量多地收集用戶的通用型需求，為定制項目進度實現(xiàn)技術支撐，減少定制項目中大量更改代碼、需要新增模塊情況發(fā)生。此外，產(chǎn)品研發(fā)過程體系也需要按照業(yè)務實際時間要求變化，凡事都需要找到契合自己的方式。

我們這里以一個基線產(chǎn)品開發(fā)過程作為流程，在項目執(zhí)行前要明確各個階段的目標、指定計劃、及時溝通，并確保各個時期所有成員對項目理解一致。

1、用戶需求

軟件開始開發(fā)前需要確定代價和所獲得價值的對比，也就是 ROI（Return On investment），一旦確定需要創(chuàng)建，就需要安排一系列的資源來支撐這個軟件的生存。這是需求的最原始描述。

為什么既要有用戶需求，也要有產(chǎn)品需求？產(chǎn)品需求是根據(jù)用戶需求轉化而來的技術實現(xiàn)需求，需要針對用戶提出的產(chǎn)品目標進行細分，總結出具體的每一個功能點，再針對每一個功能點細分為各種不同的操作流程，對每一個操作流程進行技術化定義。

用戶需求和產(chǎn)品需求容易發(fā)生不一樣，這是因為雖然大家都在談需求，但是出發(fā)點可能不同，造成了雙方關注點和思維方式不同。用戶需求關注的是系統(tǒng)如何支持業(yè)務流程，背后的需求是“實現(xiàn)業(yè)務目標”。技術人員關注的是合理技術方案，背后的需求是“工作量”、“實現(xiàn)難度”和“系統(tǒng)性能”。

2、產(chǎn)品需求

我們需要弄清楚產(chǎn)品經(jīng)理或項目需求提出者為什么要做這個項目？這是最本質(zhì)的業(yè)務需求。需求分析確定的業(yè)務需求，都是從業(yè)務需求推導出來的，都必須為業(yè)務需求服務。

產(chǎn)品需求一般包括產(chǎn)品需求規(guī)格說明書和產(chǎn)品需求矩陣。產(chǎn)品需求矩陣一般按照子系統(tǒng)、功能集、執(zhí)行單元的結構列出所有的功能需求，每列則對應每項功能的工作步驟以及每個步驟的工作量。

產(chǎn)品需求寫完后，需要進行評審。在需求評審會上，產(chǎn)品、技術詳細評審需求是否完整，產(chǎn)品功能的正常場景是什么？是否形成閉環(huán)？異常場景是什么？是否考慮周全？

需求評審后，開發(fā)和測試負責人，分別編寫技術方案和測試用例。技術方案評審，開發(fā)負責人拉上涉及到其他系統(tǒng)的負責人一起討論，技術方案中必須要有業(yè)務流程圖和時序圖，業(yè)務流程圖是為了梳理開發(fā)對業(yè)務的理解，是否和需求一致。時序圖是了梳理本次需求涉及的系統(tǒng)交互。技術方案評審通過后，確認工作量和交付時間，反饋給產(chǎn)品。

3、總體設計

設計階段的目標主要是對待開發(fā)系統(tǒng)的構架進行分析和設計，并建立系統(tǒng)構架的基線，以便為之后的實施工作提供一個穩(wěn)定的基礎。

設計階段包括了系統(tǒng)架構的輸出，一個好的系統(tǒng)架構設計可以幫助人類梳理業(yè)務邏輯且抓住核心需求，設計穩(wěn)定可擴展的業(yè)務系統(tǒng)，評估業(yè)務開發(fā)周期和開發(fā)成本，有效的規(guī)避風險。例如蓋房子的時候得有建筑圖紙，有了圖紙，才能核算施工周期。

總體設計是整個系統(tǒng)的框架型設計，意義及其重大，一般情況下不能省略（只有維護項目可以省略總體設計，因為基準項目已經(jīng)設計完畢），所有的產(chǎn)品開發(fā)項目均需要首先進行總體設計，它是設計首要步驟，決不允許本末倒置，不能出現(xiàn)先編碼后設計的情況，這是軟件開發(fā)的第二大痛點（第一大是需求不明確、任意變更需求）。

總體設計分為三個階段：

第一階段：初始設計。在對給定的數(shù)據(jù)流圖進行復審和精化的基礎上，將其轉化為初始的模塊結構圖。

第二階段：精化設計。依據(jù)模塊“高內(nèi)聚低耦合”的原則，精化初始的模塊結構圖，并設計其中的全局數(shù)據(jù)結構和每一模塊的接口。

第三階段：設計復審階段，對前兩個階段得到的高層軟件結構進行復審，必要時還可能需要對軟件結構做一些精化工作。

4、概要設計

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

概要設計按照結構化設計方法進行設計。結構化設計方法的基本思路是：按照問題域，將軟件逐級細化，分解為不必再分解的的模塊，每個模塊完成一定的功能，為一個或多個父模塊服務（即接受調(diào)用），也接受一個或多個子模塊的服務（即調(diào)用子模塊）。模塊的概念，和編程語言中的子程序或函數(shù)是對應的。

概要設計階段把軟件按照一定的原則分解為模塊層次，賦予每個模塊一定的任務，并確定模塊間調(diào)用關系和接口。

在這個階段，設計者會大致考慮并照顧模塊的內(nèi)部實現(xiàn)，但不過多糾纏于此。主要集中于劃分模塊、分配任務、定義調(diào)用關系。模塊間的接口與傳參在這個階段要制定得十分細致明確，需要編寫嚴謹?shù)臄?shù)據(jù)字典，避免后續(xù)設計產(chǎn)生不解或誤解。概要設計一般不是一次就能做到位，而是反復地進行結構調(diào)整。典型的調(diào)整是合并功能重復的模塊，或者進一步分解出可以復用的模塊。在概要設計階段，應最大限度地提取可以重用的模塊，建立合理的結構體系，節(jié)省后續(xù)環(huán)節(jié)的工作量。

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

5、詳細設計

詳細設計階段就是依據(jù)概要設計階段的分解，設計每個模塊內(nèi)的算法、流程，為每個模塊完成的功能進行具體的描述，要把功能描述轉變?yōu)榫_的、結構化的過程描述。

詳細設計這個階段，各個模塊可以分給不同的人去并行設計。設計者的工作對象是一個模塊，根據(jù)概要設計賦予的局部任務和對外接口，設計并表達出模塊的算法、流程、狀態(tài)轉換等內(nèi)容。這里要注意，如果發(fā)現(xiàn)有結構調(diào)整（如分解出子模塊等）的必要，必須返回到概要設計階段，將調(diào)整反應到概要設計文檔中，而不 能就地解決，不打招呼。詳細設計文檔最重要的部分是模塊的流程圖、狀態(tài)圖、局部變量及相應的文字說明等。一個模塊對應一篇詳細設計文檔。

概要設計階段通常得到軟件結構圖，詳細設計階段常用的描述方式有：流程圖、N-S 圖、PAD 圖、偽代碼等。而詳細設計的目的是描述某一個模塊內(nèi)部的處理流程、開發(fā)方法和編碼技巧。一般來說，詳細設計由項目簡介、模塊說明（具體說明每一個模塊內(nèi)部的流程、功能、邏輯、消耗以及未解決問題）、接口設計（包括內(nèi)部接口和外部接口）、數(shù)據(jù)結構設計（包括物理結構和邏輯結構）、特殊處理等幾個部分構成。軟件的詳細設計，最終是將軟件系統(tǒng)的各個部分的具體設計方法、邏輯、功能采用文字方式進行表述。這樣在實現(xiàn)過程中，編碼人員原則上嚴格按此進行代碼實現(xiàn)即可。

6、編寫代碼

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

先做核心模塊的壓測：很多程序員，習慣把東西做完，然后等著快上線的時候才做性能測試，那么如果前面設計出了問題，這個就很頭大了。當然，后期快上線的時候也要做性能測試，但前期的我認為還是很重要的。當然，做好這一點，需要懂一些業(yè)務，你要知道業(yè)務壓力在哪里，業(yè)務請求的重心在哪里，很多時候，產(chǎn)品經(jīng)理不講，你也要問清楚。

確保過程可控：代碼執(zhí)行時一定要保持中間的輸出，比如說，每處理 10 萬條日志，寫一條狀態(tài)日志，記錄處理的日志條目數(shù)和當前的執(zhí)行時間。

多打日志：很多時候，代碼寫的自己也不是很滿意，比如某個處理效率不夠優(yōu)化，某個處理的方法不夠簡潔，或者擴展性比較差，代碼寫的很弱智，但可能短時間沒有辦法想清楚最合理的解決方案，考慮到上線初期這里并不是重心所在，所以也不會特意去優(yōu)化它，但這種情況下我往往會留下注釋，并說明下一步優(yōu)化的可能思路是什么，或者想到的可行方案是什么。

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

不要沉迷于框架：框架最大的問題是什么？是過于繁冗的嵌套。為什么我一直很煩框架？因為經(jīng)常遇到需要一秒鐘幾千次請求的處理場景，那么調(diào)優(yōu)的時候，要從數(shù)不清的框架中尋找數(shù)據(jù)處理的邏輯，尋找性能卡點，可能改動代碼只有兩行，但是找問題需要兩天。程序員記住，你的技術能力絕對不能被框架約束住。

使用熟悉、成熟的技術：很多人根本沒搞明白自己的障礙和問題在哪里，根本不知道相關技術產(chǎn)品的優(yōu)勢和劣勢在哪里，看一堆第三方的數(shù)據(jù)測評，腦子一熱，去學新技術，然后，掉進坑里出不來，如果是創(chuàng)業(yè)公司，可能項目就死在里面了。使用新技術前，建議全面了解該技術的特征，適用范圍，以及不適用的范圍。

7、代碼審核

眾所周知，在團隊中進行代碼審查（Code Review）可以提升代碼質(zhì)量，分享項目知識、明確責任，最終達到構建更好的軟件、更好的團隊。

代碼審核及其重要，一般來說每周都要做一次代碼審核。首先，代碼審核有利于你跟蹤項目進展情況，我們能真實地看到手下的人進展如何，并且更早發(fā)現(xiàn)他們是否誤入歧途。

8、單元測試

要認識單元測試，首先要明白什么是“單元（Unit）”。所謂“單元”指的是代碼調(diào)用的最小單位，實際上指的是一個功能塊（Function）或者方法（Method）。所以單元測試指的就是對這些代碼調(diào)用單元的測試。

單元測試是一種白盒測試，就是必須要對單元的代碼細節(jié)很清楚才能做的測試。所以，單元測試的編寫和執(zhí)行都是由軟件工程師來做的。相對于單元測試，還有集成測試。集成測試基本都是黑盒測試，主要是由測試人員根據(jù)軟件的功能手冊來進行測試，需要有專門的測試環(huán)境配合。集成測試又分功能測試、回歸測試等。

需要單元測試的代碼實際上是開發(fā)人員自己寫的邏輯，測試邏輯所依賴的環(huán)境是否正常不是單元測試的目的。在環(huán)境訪問代碼中引入邏輯，只會讓邏輯更難測試，導致邏輯代碼無法進行單元測試。因此，可單元測試的代碼，才能夠采用單元測試。判斷可測試的代碼還有一個方法，就是看這個方法能否用一個 main 函數(shù)直接運行，如果可以的話就是可單元測試的代碼?？蓽y試的代碼還有另一個特征，就是該方法單元的參數(shù)，開發(fā)人員可以自由模擬，不需要依賴外部環(huán)境。

9、集成測試

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

集成測試是在軟件系統(tǒng)集成過程中所進行的測試，其主要目的是檢查軟件單位之間的借口是否正確。它根據(jù)集成測試計劃 ，一邊將模塊或其他模塊組合成越來越大的系統(tǒng)，一邊運行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各個組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。也可以理解為在軟件設計單元、功能模塊組裝、集成為系統(tǒng)時，對應用系統(tǒng)的各個部件（軟件單元、功能模塊接口、鏈接等）進行的聯(lián)合測試，以決定他們能否在一起共同工作，部件可以是代碼塊、獨立的應用、網(wǎng)絡上的客戶端或服務器端程序。

10、系統(tǒng)測試

系統(tǒng)測試階段包括系統(tǒng)測試方案及用例編寫、功能性測試、性能測試、穩(wěn)定性測試。

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

功能性測試一般由獨立測試小組采用黑盒方式來測試，主要測試系統(tǒng)是否符合“需求規(guī)格說明書”。在經(jīng)過以上各階段測試確認之后，把系統(tǒng)完整地模擬客戶環(huán)境來進行的測試。系統(tǒng)測試是將已經(jīng)確認的軟件、計算機硬件、外設、網(wǎng)絡等其他元素結合在一起，進行信息系統(tǒng)的各種組裝測試和確認測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方，從而提出更加完善的方案。

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

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

穩(wěn)定性測試（亦可稱可靠性測試）通過給系統(tǒng)加載一定的業(yè)務壓力，讓系統(tǒng)持續(xù)運行一段時間（一般為 7x24 小時），檢測系統(tǒng)是否能夠穩(wěn)定運行。

11、產(chǎn)品發(fā)布

產(chǎn)品發(fā)布是系統(tǒng)測試結束后的最后一步，通常在軟件產(chǎn)品開發(fā)過程中不需要產(chǎn)品試制環(huán)節(jié)，可以直接上線，只需要系統(tǒng)測試員輸出系統(tǒng)測試報告并批準產(chǎn)品發(fā)布（上線）就可以了。

產(chǎn)品發(fā)布前需要通過產(chǎn)品發(fā)布說明會形式，對整個產(chǎn)品開發(fā)過程從立項開始回溯過程，指出整個過程中的不足點，總結經(jīng)驗，為下一個項目提供經(jīng)驗案例。這一會議可以通過正式會議形式召開，需要召集產(chǎn)品經(jīng)理、主要開發(fā)人員、測試人員、上級領導等參與，準備充分，盡最大可能說清楚這個產(chǎn)品發(fā)布之后的效果、效益，為上線后的價值評估做準備。這一環(huán)節(jié)不可缺少，即便在互聯(lián)網(wǎng)公司，迭代速度很快的情況下，這一環(huán)節(jié)也需要滿足。

12、開發(fā)過程復盤

其實開發(fā)過程體系里并沒有這一過程，但是我個人認為它非常重要。

所有的總結，只有帶著問題去思考才會有收獲，這就是復盤。不論我說多少，如果沒有過類似的經(jīng)驗，就很難有很強的共鳴。我覺得看清一個問題最好的方式，就是你曾經(jīng)處在一個問題的兩個不同的角色中。

總結項目經(jīng)驗教訓的目的，在于總結問題、分析原因，避免以后犯同樣的錯誤，而不是追究誰的責任。

假設一個需求理解的缺陷，如果在需求階段發(fā)現(xiàn)，修改一下可能只要一個小時，但是如果到了設計完成時發(fā)現(xiàn)這個缺陷，因為涉及的人員、文檔增多，估計要一天時間，而如果等到代碼都編寫完成時才發(fā)現(xiàn)這個缺陷，可能需要十天八天了。如果缺陷沒被發(fā)現(xiàn)，而是直接到了生產(chǎn)系統(tǒng)中呢？這就不是工作量的問題了，估計損失就難以估計了。在質(zhì)量管理的理論中，缺陷每延遲一個階段被發(fā)現(xiàn)，修復的代價就要乘上十倍。

敏捷開發(fā)、極限開發(fā)等等模型是為了解決需求不明確、時間緊迫情況下的快速迭代，而不是為了從根本上否定研發(fā)流程，該設計還是要設計，只是將生命周期進行切分，將過程橫向切分為若干個周期。軟件開發(fā)是一門工程性要求很嚴謹?shù)膶W科，讓我們堅持嚴謹?shù)膽B(tài)度、高效的工作方式，打造高可用、高質(zhì)量的軟件產(chǎn)品。

推薦閱讀：

軟件生命周期與軟件過程有什么區(qū)別？

軟件測試生命周期都有哪些階段？

軟件測試與軟件生命周期的關系

APP軟件開發(fā)生命周期可以分為幾個階段？

軟件開發(fā)生命周期6個階段

為什么要做軟件生命周期管理？四大理由