Modeling in the Agile Age and casual astah models
Report
Share
•2 likes•1,272 views
Modeling in the Agile Age and casual astah models
•2 likes•1,272 views
Report
Share
Download to read offline
アジャイル時代のモデリングと astah* のサクサク活用
More Related Content
What's hot
What's hot(20)
Similar to Modeling in the Agile Age and casual astah models
Similar to Modeling in the Agile Age and casual astah models(20)
More from Kenji Hiranabe
More from Kenji Hiranabe(20)
Modeling in the Agile Age and casual astah models
- 2. 平鍋健児 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO (株)Scrum Inc. Japan 取締役 福井で受託開発を続けながら、アジ ャイル開発を推進し、国内外で、モ チベーション中⼼チームづくり、ア ジャイル開発の普及に努める。ソフ トウェアづくりの現場をより⽣産的 に、協調的に、創造的に、そしてな により、楽しく変えたいと考えてい る。アジャイルジャパン初代実⾏委 員⻑。
- 5. “While code is the truth, it is not the whole truth.” -Grady Booch コードは真実である。しかし、真実のすべてではない。
- 7. Design Upfront ? 設計なし NDUF 重厚な設計 BDUF ⼗分な設計 ENUF! ENough Design Upfront Big Design UpfrontNo Design Upfront http://www.business2community.com/strategy/is-your-shipping-documentation-all-at-sea-0388206
- 8. アーキテクチャのスイートスポット 開発時間 アーキテクチャ設計とリスク解決の時間 修正時間（⽋陥の修正、書き直し、間違い） 全体のプロジェクト時間 備考: アーキテクチャ設計に使った時間は開 発を加速し修正作業の時間を減らす Barry Boehm: The ROI of Systems Engineering: Some Quantitative Results 2007 Michael Keeling: “Design It!” (Design It! プログラマのためのアーキテクティング⼊⾨)
- 9. sweet spot アーキテクチャ設計とリスク解決のための時間 全体に追加された時間 アーキテクチャと アジャイルのバランス Barry Boehm: The ROI of Systems Engineering: Some Quantitative Results 2007 Michael Keeling: “Design It!” (Design It! プログラマのためのアーキテクティング⼊⾨) アーキテクチャ設計 修正作業
- 10. Barry Boehm et. al : Architected Agile Solutions for Software-Reliant Systems
- 11. アジャイル適正 メンバ 要求変化 企業⽂化メンバ数 クリティカルさ 3 5 3 0 2 5 2 0 1 5 0 1 0 2 0 3 0 4 0 (1B%) (L2,3 %) (変更/⽉(%))1 5 1 0 3 0 5 0 9 0 7 0 5 0 3 0 1 0 3 1 0 3 0 10 0 30 0 (⽋陥による損害) 快適さ 限定額 巨額 ⼀⽣命 多数の⽣命 計画型 アジャイル メンバ 要求変化 企業⽂化メンバ数 クリティカルさ 3 5 3 0 2 5 2 0 1 5 0 1 0 2 0 3 0 4 0 (1B%) (L2,3 %) (変更/⽉(%))1 5 1 0 3 0 5 0 9 0 7 0 5 0 3 0 1 0 3 1 0 3 0 10 0 30 0 (⽋陥による損害) 快適さ 限定額 巨額 ⼀⽣命 多数の⽣命 計画型 アジャイル Project A Project B “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001)
- 12. Agile Modeling • By Scott Ambler
- 13. “Letʼs keep the modeling baby but throw out the bureaucracy bathwater” – Scott Ambler お湯を抜いても、⾚ちゃんまで流さないように。
- 14. なぜモデルを使うのか ? • ⼈間はイメージの⽅が概要をうまく 掴むことができる。 –A picture is worth 1,000 words. –右脳と左脳
- 20. “Keeps” • Architecture • As Class/Package Diagrams • Domain Model • As Class Diagram/ER Diagrams • Key Use Cases • 1. As Use Case Diagrams • 2. As Sequence/Communication Diagrams
- 21. “Temps” • Casual Modeling • Ex. As Class+Sequence Diagrams, and others • “Keeps”の上に乗せる (ツールを使ったり、印刷の上に書いたり) • ホワイトボード! Picture from: Craig Larman
- 22. “Keeps” (again) • Architecture • As Class/Package Diagrams • Domain Model • As Class Diagram/ER Diagrams • Key Use Cases • 1. As Use Case Diagrams • 2. As Sequence/Communication Diagrams
- 23. Architecture • システム全体の構造的な表現 • ⼤域的な層(Tier)が表現されることが多く、 クラス図やパッケージ図がよく使われる。 • よく知られたパターンが存在する。 – MVC, Blackboard, Pipes-Filters, Layers • 「フレームワーク」を使うのもアーキテク チャ選択の１つ。
- 24. Pattern-Oriented Software Architecture (Vol.1-5) • By Frank Buschmann et. al
- 25. ドメインモデル • 問題領域（ドメイン）の概念とそれらの繋がり • ⼈間のコミュニケーション・レベル – 全ステークホルダーが話す語彙。 – ユーザー、ドメインの専⾨家、ビジネス分析、開発者 • プログラミング・レベル – コードを構成する要素（クラス、データ、変数、操作、 ファイル、、、、）の「名前づけ」 – それらの多くが永続データ(entity)や値(value object)に マッピングされる。
- 26. Domain-Driven Design • By Eric Evans • Ubiquitous Language
- 27. 「寿司」のドメインモデル
- 31. Key UseCases 1. ユーザーから⾒たシステムの代表的な使い⽅ • 誰がユーザーで、何がうれしいか。 2. そのゴールを得るまでのアーキテクチャを貫 通するメカニズム • シーケンス図やコミュニケーション図によって 描かれる、制御の流れ。 • 開発者には教育的な例⽰となる。
- 32. ここまでで質問どうでしょう︖
- 33. astah* を例に
- 34. 35 (イアフォンを外す)
- 35. “Keeps” (again) • Architecture • As Class/Package Diagrams • Domain Model • As Class Diagram/ER Diagrams • Key Use Cases • 1. As Use Case Diagrams • 2. As Sequence/Communication Diagrams
- 42. “Rather than divide and conquer, an XP team conquers then divides” –Kent Beck XPチームは、「分割→統治」でなく「統治→分割」する。
- 45. “Model to have a conversation.” –Craig Larman and Bas Vodde 会話のために、モデリングしよう。
- 48. Others to Keep • 設計の理由 (WHYʼs) = ADR(Architecture Decision Record) – 意思決定の理由リスト – なぜこのフレームワークを選んだか。 – なぜこのテクノロジを選んだか。 – なぜこの設計、アーキテクチャなのか。 – 考慮した別の設計案とメリデメ。 • テスト戦略 – API as Acceptance Test Interface
- 49. Tips • プロジェクタ – ツールとホワイトボードを組み合わせて • ふりかえり – ⾃分たちのベスト “Keeps” セットをさがせ。 • リバースエンジニアリング – 現在のコードベースを可視化。 • マインドマップ
- 50. ⼤事なこと • 「ふりかえり」を使ってチームによって ベストな “KEEP” セットを探せ。 • いらないモデルはないか︖ • 何か有⽤な情報がもれていないか?
- 51. Mind Map モデリング
- 53. Impact Mapping
- 54. 55
- 55. サクサク astah*
- 57. まとめ • 設計はソフトウェア開発においてこれまでもっと も⼤事な部分であるし、アジャイル開発でも、 もっとも⼤事な部分であり続けている。 • もっともシンプルなモデルセットを選び、それら をメンテナンスする。そして他のものはコードと テストにしてしまう。 • ふりかえり、で⾃分たちに合った KEEPSを選ぶ。 • 会話のためにモデルを利⽤ • “Divide and Conquer” でなく “Conquer THEN Divide” • 形式化しにくいアイディアには、マインドマップ を利⽤。
- 59. 最後に
- 60. “A lot of design information lives in tribal memory.” –Grady Booch
- 63. astah system safety 安全論証 ⾮故障・性能限 界安全分析 UML の MBSE拡張対応 ⾃動運転テスト シナリオ 26262レビュー