針對軟體開發，無論是瀑布模型還是敏捷模型，還是任何開發模式，永遠都是軟體工程所說的步驟，即在開發計劃的指引下，按照需求、設計、開發、測試四個環節，完成應用系統的交付。只是各個環節所用的技術不同、框架不同、以及粒度不同。

1、需求獲取、需求分析和需求管理

需求獲取是問客戶想要什麼？需求的分析是知道客戶的需求是什麼，並且解決做什麼，最後形成需求規格說明書，需求的管理就是保證需求到被實現的過程的完整性，變更是規範的，保證專案範圍不偏離。

例如在傳統的軟體開發過程中，實際的軟體專案需求規格說明書的編寫過程中，是存在兩種需求規格說明書的，一種是使用者需求說明書，一種是軟體需求規格說明書，軟體需求規格說明書是基於使用者需求說明書編寫的，其格式取決於所採用的開發和管理方式，例如按流程開發的方式、面對物件的開發方式和敏捷專案所採用的需求規格說明書是不同的。在需求規格書說明書的編寫中，是和業務需求分析緊密結合在一起的，最簡單的包括需求的分類，滿足業務域或業務類別，還有一些業務改進和過程改進的內容，還有一些內容是行為分析的內容。雖然需求不是設計，但需求多多少少還有一些系統最終實現後的影子，為此有一些功能性需求的編寫過程中已經對功能結構進行了初步的組織。需求不一定一定要用用例圖來描述，採用靈活清晰的規格化的文件描述來編寫具體的需求，但避免過於複雜，例如出現很多分支。如果在需求規格說明書中放入系統原型，則是對系統介面的實現進行約束。

在敏捷的軟體開發過程中，需求就是經過分析後的使用者故事。無論哪一種方式，需求都是要經過評審、需要確認的。

2、設計

在開展軟體設計前，最重要的事情是是應用系統是基於什麼平臺進行設計和開發，或者利用什麼框架進行開發，甚至是利用過去的那一個專案框架進行開發，這直接影響後續的工作，選擇不同型別的開發框架，工作量，人員投入是完全不同的。在當前技術環境下，幾乎很少的軟體會從零開發，都是利用已有的框架進行的。

在傳統的軟體開發過程中，是根據需求規格說明書的要求，利用概要設計、詳細設計和資料庫設計三種設計來完成軟體應用的設計的，概要設計關注流程和功能，詳細設計關注於類的程式碼的實現，資料庫設計關注於資料庫和表。將設計任務分配下去，不同的人完成不同的模組的設計方案，方案由流程圖、類圖等組成。利用敏捷開發方法，則省去很多步驟，不再形成規模巨大的文件，而是圍繞著使用者故事進行設計、開發和測試的，目標是快速交付成果。無論什麼形式的設計，也都需要透過不停的最佳化和評審，最後形成正確有效的開發方案。

3、開發程式碼

開發程式碼是一個非常具體的工作，透過一個個鍵盤上的字母完成整個系統的交付，就和作家爬格子完成長篇小說一樣。每個人的開發效率不同，能力不同，根據自己的能力做好估算，否則不能完成任務。開發程式碼前，也是需要有一些設計的，因為具體的程式碼實現和設計還是存在差異的。存在無數開發技巧和方法，例如開發的時候注意使用已有的類庫進行程式碼重用，少用全域性變數等等，總之，程式碼要清晰，增加註釋。作為程式設計師，註釋就是一切文件。

開發程式碼時，要利用配置管理系統進行版本控制，此外，不懂就問、網際網路搜尋是加快開發速度的關鍵。此外，程式碼也是需要進行評審的，透過評審還能夠最佳化程式碼。

4、測試

測試的目的是發現軟體的缺陷，保證交付的應用系統滿足需求，測試是非常關鍵的，甚至測試的時間比開發的時間還要長，並且越是在開發末期發現的缺陷，修復缺陷所付出的成本是越多的。敏捷開發是測試驅動的，開發時就是包括測試工作的，這樣才能迅速交付能用的系統。相比之下，傳統模式就複雜得多，首先編寫測試用例，然後開始單元測試、功能測試、整合測試、驗收測試等，按部就班，發現測試問題再週期性去完善開發，週期比較長，某環節問題較多的情況下，容易讓專案延期。測試還包括介面測試、效能測試、壓力測試、介面測試、安全測試、安裝測試等，這些都是根據不同的專案型別進行選擇，如果合同中提到或者需求中提到，就需要去完成這個測試。

測試需要工具，自動化工具讓測試事半功倍，測試出的缺陷，需要跟紀錄、審查、跟蹤、修改、驗證、關閉、整理、分析、彙總等很多狀態管理，無論過程有多麼複雜，測試工作都需要去完成，畢竟，交付一個少缺陷的高質量的軟體是每一個IT人的夢想。