Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to DDD系統分析
Similar to DDD系統分析 (20)
More from 國昭 張
DDD系統分析
- 1. DDD系統分析
- 2. 大綱 • 開發生命週期 • 需求蒐集 & 系統分析 • 領域切割 • 限界上下文
- 3. 軟體開發生命週期(瀑布) 軟體概念 需求分析 架構設計 細節設計 程式撰寫 測試 設計模型 軟體需求原型 架構設計文件 使用者需求 程式碼 • 每個週期都是上一個的產出 • 所有成員的工作職責分明 • 需要有從頭到尾的執行者-PM
- 4. 軟體開發生命週期 • 首先承認沒辦法一次做到完美 • 反覆的執行整個瀑布式流程 (Iteration) • 在迭代結束後反思這次迭代 (Learn)
- 7. 敏捷式在系統分析方面 敏捷的系統分析,好處是不 是不用寫文件? • 敏捷的考量只有: • 這個行為的CP值是不是大家認可 • 若寫文件更有價值,就可以寫 • 敏捷的核心精神在於反思還有哪邊是 可以改進的地方
- 8. 瀑布式的弱點 瀑布式要寫好多文件,這樣 的壞處是不是分析人員會 很累? • 組織的效能是來自於溝通的效果 • 文件傳達知識的效果並不高 • 錯誤的知識傳達種下專案失敗的原因
- 9. 越晚修復錯誤,代價越高
- 10. 敏捷式? 為什麼有的人會說,敏捷式 不一定適合呢? • 組織的文化和成員的思維模式,會 直接影響執行的方式 • 某些人會依照自行喜好而改變 敏捷的作法方式,進而導致 失去敏捷精神
- 11. 需求方面導致專案失敗的原因 • GIGO(Garbage In Garbage Out) • 需求收集切忌-默契 • 知識傳達鏈越長,失真率就越高 • 需求分析錯誤的代價很昂貴 • 要不斷地反覆驗證&確認 • 緊密合作,不靠文件傳話
- 12. 重新思考專案/產品流程 真正的專案和產品開發流程 是什麼? 和軟體開發流程有 什麼不一樣? • 專案/產品開發流程與軟體開發流程 完全不同,兩者千萬不可以混為一談 • 彼此關係是協作關係;由專案管理為 主,軟體開發為輔
- 16. 串起來兩者 該怎麼把兩者給串起來? • 專案管理用來處理軟體開發進行中在 非開發相關的議題 • 開發的部份由軟體開發流程來控 制 • 專案管理的一開始就是進行專案的 價值評估
- 17. 探索的前置動作- 評估和探索價值
- 18. 探索的過程- 使用者故事地圖 • 以使用案例來探索系統 • 模擬/觀察使用者的行為,並進行分析 • 依照”最小可行產品(MVP)”的概念來 排定釋出的版本
- 19. 往開發階段進行 使用者故事地圖結束後,怎 麼往下進行到開發階段? • 從使用者故事地圖中探索可以加強的 部份;作為系統分析的參考 • 每張在使用者地圖上的使用者行為, 都可以轉化成為使用案例(Use Case)或是 使用者故事(User Story)
- 20. 開發- Scrum
- 21. Scrum的失敗 聽很多人說導入Scrum全部 都失敗了ㄟ? • Scrum的變革是整體公司文化上的變革, 相較於其它開發方式是較為激烈的! • Scrum代表著敏捷,而Kanban代表著是 精實! • 藉Kanban的淺移默化,慢慢讓Scrum導入, 同時也可用Kanban來改進Scrum流程
- 22. 變革管理- Kanban
- 23. Scrumban 創新(通才) 中斷、事件驅動、 多樣化的工作 重複(專才) 專注 Scrum Scrum+ Kanban Kanban Product Line Kanban Support Kanban 友善連結 • 專注-創新 • 需要創新或是創作思維 • 適合使用Scrum • 專注-重複 • 需要專注且工作是屬於重複性的 • 適合使用Product Line Kanban • 中斷-創新 • 應付需要創新,但是具有大量中斷和 事件驅動的工作 • 適合使用Scrum+Kanban • 中間點 • 任何狀況 • Kanban可以應用在各種狀況
- 24. 反饋 之後就是一直單純的開發? • 在開發的過程中,藉由使用者與客戶 的反饋,回到專案探索階段重新分析 • 將新探索的成果重新規劃MVP,再繼 續進入開發階段 • 開發的過程中當然也會需要做價值 評估,因為有些時候已錯過市場時機 就沒有開發的必要了
- 25. 流程 資料 規則 期望 需求蒐集
- 26. 如何蒐集流程 • 與領域專家會談 • 採用UML商業活動圖 • 每個腳色的行為都能清楚表達
- 27. 界定系統範圍 • 進行系統初步分析 • 採用UML的使用案例圖 • 界定系統提供哪些服務
- 28. 找出資料、規則 • 詳實摘錄出與領域專家會談內容 • 以特定格式撰寫使用案例 • 撰寫過程中,會發現有特定的資料 、規則
- 29. User Story & Use Case? 這兩個好難懂歐?兩者有關 係嗎? • User Story以一個簡短的方式描述 User case • User Story主要目標在於讓團隊成員 能夠快速回憶曾經討論過的需求
- 30. 影響力地圖- 管理所有人的期望
- 31. 為什麼要在意每個人的期望? 不是只要在意老闆的期望 就可以了嗎? • 專案團隊成員與老闆同樣重要 • 不在意團隊成員的期望,會導致專案 士氣低落,進而失敗 • 有的時候團隊成員的期望是小到你 無法想像
- 32. 需求蒐集完了之後,要做什麼? 接下來要做系統分析了!但 是該怎麼進行系統分析呢? • 系統分析之前需要先擬定戰略方針 • 領域驅動提供戰略方針的指引法則, 幫助系統分析更加有效率和效果
- 34. 系統開發中的角色 • 整理&管理需求 • 繪製領域概念模型 • 擔任開發團隊對內/外的窗口 系統分析師 • 將需求轉化成開發平台相依的概念 • 繪製領域實做模型 • 制定系統架構與開發技術 系統設計師
- 35. 領域驅動- 戰略思維 • 以領域為單位去分析和設計系統 • 找出最有價值領域,深度開發 • 以一套方法論來取得所有團隊成員 的共識
- 36. 領域思維? 感覺起來和功能模組化 有點像? • 系統與現實世界彼此相互映射 • 現實世界怎麼切割職責,系統就怎麼切割 • 在系統中,以子領域來切割職責
- 37. 領域切割 • 將系統要處理的部分看成是一個領域 • 切割領域為多個子領域 • 找出子領域中最有價值的那一個 (Core Domain) 最有價值的
- 38. Core/Support/Generic Domain? 這三個子領域的分類個別是 什麼意思? • Core Domain: 最有價值,值得採用DDD 戰術技術的部份 • Support Domain: 用來支持Core Domain; 本身重要性為第二級 • Generic Domain: Core/Support共用的功能
- 39. 子領域 & 限界上下文 可是你的示意圖 好像不是這樣ㄟ!? 現實與理想總是有 一段差距 一個限界上下文 對 映 一個領域最剛好
- 40. 限界上下文(Bounded Context) 什麼是限界上下文,他與領 域有什麼關係? • 分析出子領域是為了讓團隊有共識; 知道哪個部分是系統中最重要的 • 限界上下文是以子領域為範圍,進行 更細緻的分析 • 限界上下文就是實際的軟體系統,可能 是一個網站/第三方軟體
- 41. 限界上下文 • 彼此之間有關連性 • 可以直接添購第三方軟體作為 非Core Domain的限界上下文 系統 • 關聯性可以是上下游、共用核心 …等等 • Core Domain的限界上下文,建議 採用DDD戰術技術
- 42. 使用案例 使用案例 使用案例 為什麼要有限界上下文? 分析 使用案例 分析 分析 使用案例 使用案例 使用案例 • 當需求越來越複雜時,分析出來的模型 就會跟著變的複雜 • 一旦超出人類所能理解的複雜度,系統 開發就會發生問題 • 採用限界上下文,就能切割使用案例與 模型,去除了上述問題 模型 模型 模型
- 46. 限界上下文的關係- 公開服務 • 在防腐層應用上,如果發現有多個上下文 都在使用同一個上下文,這時候可以為這 個共用的上下文建立一組API,以共享模型 轉換邏輯 上下文 上下文 上下文 上下文 服務層
- 49. 限界上下文的合作關係- 遵從 上下文 上下文 • 如果上下游彼此無法協作,或是有極高 的溝通成本,那麼可以選擇遵從模式 • 實務上,會發生在介接外部廠商的API • 這種模式最不利於下游開發團隊 遵從
- 50. 通用語言 在分析和需求上,還有需要 注意的地方嗎? • 在與領域專家的會談過程中,最重要的 就是不斷地建立 - 通用語言 • 通用語言 通俗地說,就是資料字典;每個 術語或專有名詞都有其專有的解釋 • 通用語言一定要是整個團隊都認可的,不 單只是領域專家,還有開發人員
- 51. 通用語言帶來的幫助 • 讓團隊成員與領域專家的溝通更順暢 • 協助現實生活與系統的映射 • 更容易做到程式碼即文件
- 52. 通用語言可能的問題 如果…通用語言的定義發生 衝突怎麼辦? • 建議每一個子領域定義一套專屬的 通用語言,以避免過多的衝突 • 在不同子領域中,相同的通用語言可以 有不同的定義(以子領域做邊界)
- 53. 回顧 • 依照專案/團隊文化選用不同開發方式 • 需求蒐集: • 流程: 利用 商業活動圖 建構 • 資料、規則: 利用 使用案例圖/描述 建構 • 期望: 利用 影響力地圖 建構 • Use story是Use case的簡單描述 • 領域驅動戰略提供系統分析的初步規劃 • 現實生活中的知識直接映射到系統上 • 以子領域切割並分級系統中重要的部分 • 限界上下文即是可用的系統 • 通用語言幫助現實生活與系統的映射更加順利