這是一個非常大的計算機軟體工程學課題，全面展開都可以寫好幾本書，這裡我就力求用最精煉的方式將其中的要點講清楚
一、歷史
1、軟體作坊時代（20世紀60年代）
這一時期軟體規模一般都很小，人們寫軟體就是直接寫程式碼（數千～數萬行程式碼），畢竟規模有限、幾乎都能記住
2、軟體工程危機（20世紀70年代）
硬體飛速發展，隨著軟體規模及複雜度的激增，程式規模一旦到了幾十萬行、上百萬行時候，人們就開始駕馭不住了——系統沒有一個可讓團隊成員清晰參考的整體架構，不同人之間很難溝通協作；就算是自己寫的程式碼，一年半載之後，你不認識它、它不認識你！
3、軟體過程時代（20世紀80年代）
軟體開發引入了成熟的生產製造管理方法，以過程控制為中心、分階段來控制軟體的開發（如：瀑布模型），“過程控制”一定程度上緩解了軟體危機。
4、重型過程時代（20世紀90年代）
軟體專案的失敗，促使人們不斷地向“過程控制”增加約束及限制，軟體的開發過程變得越來越厚重（如：CMMI模型），人們會為“過程控制”寫大量的文件及規範，軟體開發週期被不斷地加長，最終導致做出來的產品並不能迅速滿足市場客戶的需求（大量開發出來的功能甚至成為使用者不需要的功能）
5、敏捷開發時代（2000~2009）
隨著資訊時代的到來，市場需求變化越來越快，交付週期成為企業核心競爭力，更能適應快速變化的敏捷軟體開發方法（如：scrum、XP等）被普遍認可；輕量級、快速地進行版本迭代，是敏捷開發的核心，相應地也產生了多種多樣的敏捷實踐方法，如：產品backlog、迭代會議、測試驅動開發、結對程式設計等等；敏捷開發，也讓一些團隊一度陷入過理解誤區，如：認為搞敏捷開發就意味著不再寫文件、做計劃、不再做架構設計、甚至不用再做測試等等
二、當下（2010~現在）
1、系統分析
該階段主要是闡述清楚專案到底要“做什麼”，可以從各種使用者的角度進行使用場景（Story）分析；可以用UML需求文件圖、用例圖、活動圖等進行分析建模，最終以文件的方式進行儲存
2、架構設計
該階段主要是根據系統分析闡述清楚專案總體上到底要“怎麼做”，劃分成哪些子系統（如：IOS端、Android端、Web端、應用伺服器、資料庫伺服器等），每個子系統大致又會有哪些主要的模組；然後就是根據總體設計進行使用者體驗設計、資料庫設計、業務互動設計、通訊協議設計等；可以用原型設計工具（如：Axure）、資料庫概念模型圖、UML協作圖等進行設計建模，最終以文件的方式進行儲存
3、模組設計
該階段主要是根據架構設計闡述清楚各個子系統中的每個模組具體實現上“怎麼做”，這裡可以用多種設計模式對模組中的類（及其介面）進行設計；可以用UML類圖、時序圖、狀態圖等對類（及其介面）進行設計建模，最終以文件的方式進行儲存
4、開發實現
該階段主要就是根據模組設計進行具體的程式碼實現（有的模組設計工具可以直接生成類的框架程式碼）。該階段開發人員不僅要完成功能程式碼的實現、而且還要對自己的功能程式碼進行單元測試及模組整合測試，這裡主要借鑑敏捷開發模式——將測試前移到開發階段，不再設立獨立的單元測試、整合測試階段——因為只有開發人員才知道自己實現程式碼的每一個細節、其他人很難做到全覆蓋測試。當前的主流開發語言幾乎都提供了相應的測試工具包支援該階段的測試。
5、系統測試
該階段主要是測試人員根據系統分析及原型設計，對系統的UI、效能進行測試，確保與前期分析與設計一致、而且執行起來穩定可靠
6、版本釋出
每個迭代版本最好有釋出說明書，方便後繼人員進行維護及部署；如果是首次釋出，需要提前規劃好將在哪些應用市場釋出，並申請好相應賬戶，準備好相關的釋出材料（如：著作權、授權書等）；如果非首次釋出，做好各版本的管理即可
這是一個非常大的計算機軟體工程學課題，全面展開都可以寫好幾本書，這裡我就力求用最精煉的方式將其中的要點講清楚
一、歷史
1、軟體作坊時代（20世紀60年代）
這一時期軟體規模一般都很小，人們寫軟體就是直接寫程式碼（數千～數萬行程式碼），畢竟規模有限、幾乎都能記住
2、軟體工程危機（20世紀70年代）
硬體飛速發展，隨著軟體規模及複雜度的激增，程式規模一旦到了幾十萬行、上百萬行時候，人們就開始駕馭不住了——系統沒有一個可讓團隊成員清晰參考的整體架構，不同人之間很難溝通協作；就算是自己寫的程式碼，一年半載之後，你不認識它、它不認識你！
3、軟體過程時代（20世紀80年代）
軟體開發引入了成熟的生產製造管理方法，以過程控制為中心、分階段來控制軟體的開發（如：瀑布模型），“過程控制”一定程度上緩解了軟體危機。
4、重型過程時代（20世紀90年代）
軟體專案的失敗，促使人們不斷地向“過程控制”增加約束及限制，軟體的開發過程變得越來越厚重（如：CMMI模型），人們會為“過程控制”寫大量的文件及規範，軟體開發週期被不斷地加長，最終導致做出來的產品並不能迅速滿足市場客戶的需求（大量開發出來的功能甚至成為使用者不需要的功能）
5、敏捷開發時代（2000~2009）
隨著資訊時代的到來，市場需求變化越來越快，交付週期成為企業核心競爭力，更能適應快速變化的敏捷軟體開發方法（如：scrum、XP等）被普遍認可；輕量級、快速地進行版本迭代，是敏捷開發的核心，相應地也產生了多種多樣的敏捷實踐方法，如：產品backlog、迭代會議、測試驅動開發、結對程式設計等等；敏捷開發，也讓一些團隊一度陷入過理解誤區，如：認為搞敏捷開發就意味著不再寫文件、做計劃、不再做架構設計、甚至不用再做測試等等
二、當下（2010~現在）
1、系統分析
該階段主要是闡述清楚專案到底要“做什麼”，可以從各種使用者的角度進行使用場景（Story）分析；可以用UML需求文件圖、用例圖、活動圖等進行分析建模，最終以文件的方式進行儲存
2、架構設計
該階段主要是根據系統分析闡述清楚專案總體上到底要“怎麼做”，劃分成哪些子系統（如：IOS端、Android端、Web端、應用伺服器、資料庫伺服器等），每個子系統大致又會有哪些主要的模組；然後就是根據總體設計進行使用者體驗設計、資料庫設計、業務互動設計、通訊協議設計等；可以用原型設計工具（如：Axure）、資料庫概念模型圖、UML協作圖等進行設計建模，最終以文件的方式進行儲存
3、模組設計
該階段主要是根據架構設計闡述清楚各個子系統中的每個模組具體實現上“怎麼做”，這裡可以用多種設計模式對模組中的類（及其介面）進行設計；可以用UML類圖、時序圖、狀態圖等對類（及其介面）進行設計建模，最終以文件的方式進行儲存
4、開發實現
該階段主要就是根據模組設計進行具體的程式碼實現（有的模組設計工具可以直接生成類的框架程式碼）。該階段開發人員不僅要完成功能程式碼的實現、而且還要對自己的功能程式碼進行單元測試及模組整合測試，這裡主要借鑑敏捷開發模式——將測試前移到開發階段，不再設立獨立的單元測試、整合測試階段——因為只有開發人員才知道自己實現程式碼的每一個細節、其他人很難做到全覆蓋測試。當前的主流開發語言幾乎都提供了相應的測試工具包支援該階段的測試。
5、系統測試
該階段主要是測試人員根據系統分析及原型設計，對系統的UI、效能進行測試，確保與前期分析與設計一致、而且執行起來穩定可靠
6、版本釋出
每個迭代版本最好有釋出說明書，方便後繼人員進行維護及部署；如果是首次釋出，需要提前規劃好將在哪些應用市場釋出，並申請好相應賬戶，準備好相關的釋出材料（如：著作權、授權書等）；如果非首次釋出，做好各版本的管理即可