針對軟件開發，無論是瀑布模型還是敏捷模型，還是任何開發模式，永遠都是軟件工程所說的步驟，即在開發計劃的指引下，按照需求、設計、開發、測試四個環節，完成應用系統的交付。只是各個環節所用的技術不同、框架不同、以及粒度不同。
1、需求獲取、需求分析和需求管理
需求獲取是問客戶想要什么？需求的分析是知道客戶的需求是什么，并且解決做什么，最后形成需求規格說明書，需求的管理就是保證需求到被實現的過程的完整性，變更是規范的，保證項目范圍不偏離。
例如在傳統的軟件開發過程中，實際的軟件項目需求規格說明書的編寫過程中，是存在兩種需求規格說明書的，一種是用戶需求說明書，一種是軟件需求規格說明書，軟件需求規格說明書是基于用戶需求說明書編寫的，其格式取決于所采用的開發和管理方式，例如按流程開發的方式、面對對象的開發方式和敏捷項目所采用的需求規格說明書是不同的。在需求規格書說明書的編寫中，是和業務需求分析緊密結合在一起的，最簡單的包括需求的分類，滿足業務域或業務類別，還有一些業務改進和過程改進的內容，還有一些內容是行為分析的內容。雖然需求不是設計，但需求多多少少還有一些系統最終實現后的影子，為此有一些功能性需求的編寫過程中已經對功能結構進行了初步的組織。需求不一定一定要用用例圖來描述，采用靈活清晰的規格化的文檔描述來編寫具體的需求，但避免過于復雜，例如出現很多分支。如果在需求規格說明書中放入系統原型，則是對系統界面的實現進行約束。
在敏捷的軟件開發過程中，需求就是經過分析后的用戶故事。無論哪一種方式，需求都是要經過評審、需要確認的。
2、設計
在開展軟件設計前，最重要的事情是是應用系統是基于什么平臺進行設計和開發，或者利用什么框架進行開發，甚至是利用過去的那一個項目框架進行開發，這直接影響后續的工作，選擇不同類型的開發框架，工作量，人員投入是完全不同的。在當前技術環境下，幾乎很少的軟件會從零開發，都是利用已有的框架進行的。
在傳統的軟件開發過程中，是根據需求規格說明書的要求，利用概要設計、詳細設計和數據庫設計三種設計來完成軟件應用的設計的，概要設計關注流程和功能，詳細設計關注于類的代碼的實現，數據庫設計關注于數據庫和表。將設計任務分配下去，不同的人完成不同的模塊的設計方案，方案由流程圖、類圖等組成。利用敏捷開發方法，則省去很多步驟，不再形成規模巨大的文檔，而是圍繞著用戶故事進行設計、開發和測試的，目標是快速交付成果。無論什么形式的設計，也都需要通過不停的優化和評審，最后形成正確有效的開發方案。
3、開發代碼
開發代碼是一個非常具體的工作，通過一個個鍵盤上的字母完成整個系統的交付，就和作家爬格子完成長篇小說一樣。每個人的開發效率不同，能力不同，根據自己的能力做好估算，否則不能完成任務。開發代碼前，也是需要有一些設計的，因為具體的代碼實現和設計還是存在差異的。存在無數開發技巧和方法，例如開發的時候注意使用已有的類庫進行代碼重用，少用全局變量等等，總之，代碼要清晰，增加注釋。作為程序員，注釋就是一切文檔。
開發代碼時，要利用配置管理系統進行版本控制，此外，不懂就問、互聯網搜索是加快開發速度的關鍵。此外，代碼也是需要進行評審的，通過評審還能夠優化代碼。
4、測試
測試的目的是發現軟件的缺陷，保證交付的應用系統滿足需求，測試是非常關鍵的，甚至測試的時間比開發的時間還要長，并且越是在開發末期發現的缺陷，修復缺陷所付出的成本是越多的。敏捷開發是測試驅動的，開發時就是包括測試工作的，這樣才能迅速交付能用的系統。相比之下，傳統模式就復雜得多，首先編寫測試用例，然后開始單元測試、功能測試、集成測試、驗收測試等，按部就班，發現測試問題再周期性去完善開發，周期比較長，某環節問題較多的情況下，容易讓項目延期。測試還包括接口測試、性能測試、壓力測試、界面測試、安全測試、安裝測試等，這些都是根據不同的項目類型進行選擇，如果合同中提到或者需求中提到，就需要去完成這個測試。
測試需要工具，自動化工具讓測試事半功倍，測試出的缺陷，需要跟紀錄、審查、跟蹤、修改、驗證、關閉、整理、分析、匯總等很多狀態管理，無論過程有多么復雜，測試工作都需要去完成，畢竟，交付一個少缺陷的高質量的軟件是每一個IT人的夢想。
