前言
大學老師說：軟件工程是個很重要的課
以程序員的我，表示並沒有什麼卵用。直到有一天，我明白了原來軟件工程講的是讓我怎麼開展一件事情。
軟件工程
| 軟件工程 | 事件 | 產物 |
|---|---|---|
| 問題的定義 | 對系統的實際用戶和使用部門負責人的訪問調查 | 提出關於問題性質、工程目標和規模的書面報告 |
| 可行性分析 | 從技術，經濟，操作，法律方面分析上述問題 | 可行性分析報告 |
| 需求分析 | 確定目標系統必須具備哪些功能 | 產品原型圖PRD |
| 總體設計 | 根據功能分解模塊，層級 | 系統架構（模塊）圖 |
| 詳情設計 | 確定模塊，層級功能的算法和數據結構 | 用例圖，E-R圖，順序圖 & 測試用例 |
| 編碼 | 針對詳情設計內碼編寫代碼 | 代碼及單元測試 |
| 測試 | 根據測試要求提供測試 | 測試&交付報告 |
| 維護 | 通過各種必要的維護活動使系統持久地滿足用戶的需要 | 系統正常運行 |
問題定義
- 主處理人：產品經理
- 問題的來源：
- 老闆要求的市場調研
- 客戶反饋的市場需求
- 競爭產品上的功能的市場調研
- 對應會議： 無
可行性分析
- 主處理人：產品經理
- 分析過程：
- 技術諮詢併成本估算
- 法律諮詢
- 其它諮詢
- 對應會議： 立項會
- 會議目的：
- 大致說明產品功能及價值
- 解決大家相關疑問，確立項目
需求分析
- 主處理人：產品經理
- 分析過程：
- 根據各功能點，完成PRD
- 對應會議： 需求評審會
- 會議目的：詳細說明PRD中產品功能，價值以及產品的性能要求，並解決大家的疑問。
總體設計 & 詳情設計
- 主處理人：技術經理（架構師），開發人員
- 設計過程：
- 根據功能劃分模塊。系統架構（模塊）圖
- 確定各模塊內的數據結構與算法。用例圖，ER圖，順序圖
- 對應會議： 架構評審會
- 會議目的：介紹自己的設計，通過此設計是否可滿足產品需求
編碼
- 主處理人：開發人員
- 編碼過程：根據設計編寫代碼，及單元測試，代碼review
- 主處理人：測試人員
- 設計過程：
- 根據PRD,編寫測試用例
- 根據架構及詳情設計，確立產品性能測試方案
- 對應會議： 測試用例評審會
- 會議目的：介紹自己的測試範圍及測試方法，通過些方法是否可滿足用戶使用需求
測試
- 主處理人：測試人員
- 測試過程：根據測試用例及性能測試方案進行測試
- 主處理人：開發人員，測試人員
- 設計過程：
- 根據設計方案，制定發佈計劃。
- 確定回滾方案
- 對應會議： 發佈計劃會
- 會議目的：針對發佈計劃，回滾方案進行評審，接納各方意見，保證發佈順利進行。
維護
- 主處理人：開發人員，測試人員，產品經理
- 維護過程：
- 開發人員查看報警日誌
- 產品經理跟蹤用戶反饋
- 測試人員復現線上問題
- 對應會議： 無
開發模式
針對軟件工程的生命週期，不同公司針對自身情況做了不同的調整
瀑布模型
瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行。
它的嚴格分級導致的自由度降低，需求調整代價高昂。需求不明並且在項目進行過程中可能變化的情況下基本是不可行的
迭代式開發
每次只設計和實現這個產品的一部分, 逐步逐步完成的方法叫迭代開發。
- 整個開發工作被組織爲一系列的短小的、固定長度（如3周）的小項目，被稱爲一系列的迭代。
- 每一次迭代都包括了需求分析、設計、實現與測試。
採用這種方法，開發工作可以在需求被完整地確定之前啓動， 並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。 再通過客戶的反饋來細化需求，並開始新一輪的迭代
螺旋開發
（略）
敏捷開發
（略）
總結
明確自己所在的位置，明確自己所做的事情後。也就不迷茫了。不要再怪會議多了。