Modeling in the Agile Age and casual astah models
•
2 recomendaciones•1,287 vistas
アジャイル時代のモデリングと astah* のサクサク活用
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Modeling in the Agile Age and casual astah models
Similar a Modeling in the Agile Age and casual astah models (20)
Más de Kenji Hiranabe
Más de 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レビュー