軟件工程：是指導軟件開發和維護的一門工程學科 三要素方法/工具/開發過程 價值：促進項目成功
現代產品開發三原則：功用性、可行性、稱許性 軟件過程是軟件工程的核心組成部分。
迭代 ：反復求精? 增量：逐塊建造 ???需求調查手段:研究文檔、訪談、現場觀察、問卷、原型法
經典軟件過程：瀑布模型、RUP統一軟件過程、Scrum敏捷過程、擴展ICONIX過程
瀑布模型：需求分析、需求定義、概要設計、詳細設計、實現、系統測試、驗收測試、維護
UML承載面對象思想。靜態圖：對象圖/類圖/組件圖/部署圖；動態圖：用例圖/序列圖/活動圖/狀態圖/協作圖
需求是軟件成功的基礎，需求工程是解決需求噩夢手段：需求開發/調查/分析/定義/管理/確認/跟蹤/變更控制
需求開發（獲取用戶需求/定義產品需求，找到痛點提出辦法）需求調查需求分析（定義愿景、業務建模、用例分析）需求定義：規格說明書（（非）功能需求）需求管理（客戶與開發方需求共同理解，維護與其他成果一致，控制變更）
三類人需求：老板戰略/開源節流/定愿景；經理:簡化管理優化流程 業務建模；業務建模;員工：工作簡單用例分析
ICONIX過程：(開源節流用例驅動)愿景、業務建模(用例/現狀序列圖/改進)需求分析（系統/域）健壯性分析(健壯性圖更新域模型)關鍵設計最終設計（詳細設計）實現（域模型->更新->靜態類圖）
特點:早編碼，縮短設計周期。簡化RUP過程。基于敏捷思想。
與RUP比是輕量級過程。與敏捷比提供充足的需求設計文檔，但不過度分析設計。
?
獲取愿景：找項目老大（最有權力的干系人）得到期望（掏錢的目的）描述度量指標
業務建模步驟明確為誰服務（改進組織）什么現狀從外部看：組織是價值的集合；從內部看是系統的集合。改進
業務建模意義把視角轉向客戶，清晰準確診斷。明確為誰服務，不為自己做；組織現狀/痛處不足；如何改進/解決.
業務用例圖：幫助從高層次了解組織的業務構成。業務執行者：享受價值；業務組織：提供的價值。
業務序列圖（幫助從細節上了解組織的業務流程）用例對應一段流程優勢：以面向對象的思想來看業務流程
作用：識別業務對象：確定業務對象間職責、協作和交互順序；通過業務序列圖了解現狀，為業務的優化提供依據
組成：業務執行者；業務工人；業務實體；調用消息；返回消息 常用分支：循環loop、分支alt、可選opt
改進1新系統作為實體引入現有流程、查看可改進流程、評估改進結果
2了解目的，發現改進點：信息自動流轉、封裝復雜邏輯、職責轉移、操作業務對象（管理系統）
結果復核（所有參與者簽字確認或未達成共識需要返工）目的：完善建模成果，尋找遺漏錯誤的地方，修正，可以迭代回去繼續做業務建模。關鍵干系人在信息和意見上達成一致，簽字確認，下一階段啟動標志。
?
域建模步驟提取名詞短語、排除重復相似、排除系統本身及范圍外、第一版、整理第一版域模型 ?
意義術語表確保清晰一致術語交流。比普通術語：圖示化方式，清晰顯示術語關系3修正完善演化為最終靜態類圖
域模型數據模型關系
域模型：分析模型、認識實體間關系的工具；數據模型：系統設計實現的一部分，描述用戶需求在數據結構的實現
組成系統：主執行者：發起者,為其實現輔執行者：支持者；提供支持（后臺）3系統邊界、系統用例、用例關系
系統用例建模意義把視角轉向新系統，站在最終用戶角度看問題，是對新系統為系統執行者提供的價值的建模
繪制系統用例步驟：1確定系統邊界 2識別系統執行者3識別系統用例，執行動作，生成執行者可觀測價值結果
用例關系包含：封裝一組相似動作以便復用。泛化：繼承。擴展：一段相對獨立且可選的動作
用例≠功能/步驟（用例是執行者愿望，很多步驟）大量用例分包：按執行者、按主題、按開發團隊、按發布情況
系統用例描述干系人利益（客戶：簡單。銀行：安全。法律：保護）基本路徑（客戶最想看到 “名動名” 主語是執行者或系統）擴展路徑（意外分支）業務規則（限額）非功能性需求：做到的程度、功能性需求：做什么
軟件需求規格書：正確性、必要性、優先級、明確性、可測性、完整性、一致性、可修改性
需求評審：
1臨時評審（回顧與用戶日常溝通）2輪查（交叉產物互相提意見）3結對編程/走查/評審/審查4規劃：誰參加/評審什么5總體會議6準備7審查會議：暴露討論問題8返工：防形式主義9跟蹤：解決問題避免再次出現
?
健壯性分析三種元素：邊界類實體類控制器類
規則1執行者只和邊界通話2邊界和控制器3控制器和控制器4控制器和實體
健壯性步驟：創建圖、用例文本、基本路徑，執行者、邊界對象和實體對象、控制器，元素之間的連線、擴展路徑。
健壯性優點：1.用例的對象化圖示，用例和對象鏈接起來2.指出了對象互相如何交互3.確保用例文本正確，提供了健壯性檢查4.幫助確保用例考慮所有必要擴展路徑，提供完整正確檢查5.能夠發現對象6.縮小分析和設計鴻溝
價值：幫助完善用例分析結果。完善域模型，做為需求分析走向系統設計的過度技術
?
關鍵設計意義：尋找對象間交互關系，進行方法分配。包括用例圖、用例描述、健壯性分析圖。
非功能性需求：可靠性、可用性、性能、可支持性
高內聚：一個軟件模塊由相關性強的代碼組成，只負責一項任務，一個好內聚模塊恰好做一件事，單一責任原則
低耦合：度量模塊間直接依賴關系，模塊與模塊間接口應少而簡單，如關系較復雜，模塊劃分，有利于修改與組合
詳細設計（編碼測試部署維護升級）技術架構：開發語言、網絡拓撲安全、體系結構、硬件環境、軟件環境
?
敏捷宣言敏捷=理念+優秀實踐+具體應用（是敏捷起源基礎，揭示更好開發方式，重新思考開發中的價值和如何更好工作，是以人為核心/迭代/循序漸進的開發方法）
1)個體與交互>過程和工具2）可以工作的軟件>面面俱到的文檔3)客戶協作>合同談判4）響應變化>遵循計劃
（軟件：復雜性/一致性/可變性/不可見性）敏捷有改變:管理者的轉變\團隊成員的轉變
好功能列表有DEEP特征：詳略得當、涌現的、做過估算、排列優先級。
Scrum產品負責人、scrum教練、開發團隊
1)產品負責人和開發對產品業務目標形成共識2)產品負責人建立維護需求列表（不斷新增改變），優先級排序3)產品負責人每輪迭代前，篩選高優先級需求本輪開發4)開發團隊細化迭代需求，按照優先級依次迭代完成5)開發團隊每日立會/特性開發/持續集成，使開發進度真正透明（每日立會）6)產品負責人對每輪迭代交付的可工作軟件現場驗收反饋（迭代評審會議）7)團隊內部進行本輪回顧，發現可改進方面指導下一輪迭代（迭代回顧會議）
敏捷管理實踐迭代計劃會議（達成一致確定任務）、迭代執行、每日立會、迭代評審會議、迭代回顧會議（總結改進）
敏捷工程實踐結對編程、測試驅動開發、持續集成、Code Review、產品發布規則、用戶故事
用戶故事三要素：客戶價值、用戶 級別：史詩故事（1月）、特性故事（1周）、沖刺故事（1天）、任務（小時）
