| Bottom | Home | Article | Bookshelf | Keyword | Author | Oxymoron |

agilemodel

Agile Modeling
Category: IT
Published: 2002
#1005b

Scott W. Ambler

13903u/18121r

Title

Agile Modeling

アジャイルモデリング
Index
  1. Introduction:
  2. Agile Modeling values:
  3. Core principles:
  4. Supplementary principles:
  5. Core practices:
  6. Supplementary practices:
  7. Order from chaos:
  8. Communication:
  9. Nurturing an agile culture:
  10. Using the simpleset tools possilbe:
  11. Agile work areas :
  12. Agile Modeling teams:
  13. Agile Modeling sessions:
  14. Agile documentation:
  15. Adoping AM or overcoming adversity:
  16. Glossary of definitions and abbreviations:
  1. アジャイルモデリング (AM) への招待:
  2. AMの価値:
  3. 基本原則:
  4. 追加原則:
  5. 基本実践:
  6. 追加実践:
  7. カオスからの秩序:
  8. コミュニケーション:
  9. アジャイル文化の育成:
  10. 最も単純な道具を使う:
  11. アジャイルな作業場所:
  12. AMのチーム:
  13. AMのセッション:
  14. アジャイルなドキュメント:
  15. AMの採用あるいは逆境の克服:
  16. 用語集、その定義と略語:
Why?
  • >"Agile" = having a quick resourceful and adptable character (Merriam-Webster)"
  • It is worth to read this agile book slowly and carefully. Because there are many suggestions not only about software evelopment but also human behaivior in various activities.
  • Corporate organizations tend to require perfect planning and process without paying atttention to time and cost or effectivess to reach the final goal.
  • "Agile"の意味：迅速な処理能力と適応性の特徴を有する
  • このアジャイルの本はゆっくり熟読する価値がある。ソフトウェア開発のみならずさまざまな人間の活動での振る舞いに多くの示唆を与えてくれるからである。
  • 企業組織はややもすれば完全な計画とプロセスを時間コストや最終目標まで到達までの効率を無視して要求する傾向がある。
Key phrase
キーフレーズ

>Top 1. Introduction:

  • To change your fate, you must first change your attitude.
  • Software development:
    • The current software development situation is lee than ideal. Systems are regularly delivered late or over budget. Systems often don't meet the needs of our customers and we must develop them again and again. Customers put unrealistic demands on us.
    • embarking on a death march.
  • Developer side:
    • They describe themselves as PERL programmers, Linux experts, EJB developers, or .NET developers. To them the technology is the important thing. After several rounds of technologies, they realize that the fundamentals don't change.
    • By the time that developers begin to truly learn their craft they're in the process of transitioning out of their roles as developers.
  • Customer side:
    • Customers don't understand how software is developed. They generally aren't really interested in participating in complex processes.They receive key documents through the project, receiving glowing status reports throughout, just before delivery, and finally receiving the system, often late and over budget.
    • it is possible for our project stakeholders to be actively involved.

1. AMへの招待:

  • 運命を変えるには、まず態度を変えなければならない。
  • ソフトウェア開発:
    • 現在のソフトウェア開発は、理想とはほど遠い状態納期遅れ、予算超過は当たり前顧客ニーズの合致せず、何回も開発し直し顧客側も非現実的な要求。
    • デスマーチを歩む。
  • 開発者側：
    • 自分達をPerlプログラマー、Linuxエキスパート、EJB開発者、.NET3若者には技術だけが大事で、若い開発者は技術を表面的に学ぶ傾向がある。自分達をPerlプログラマー、Linuxエキスパート、EJB開発者、.NET開発者などと呼ぶ。彼らには技術こそが大事なのだ。
    • 開発者は、開発者の役割を終える頃になって初めて、本当の技能を学び始める。
  • 顧客側:
    • 顧客はソフトウェアがどのように開発されるのかを理解していない。自分達がよく理解していない複雑なプロセスに参加しない。開発の進捗と共に良いことづくめの報告を受け取り、納品直前の受入テストに立ち会う。予算も期間も超過してやっとシステムを受け取るはめになる。
    • プロジェクトのステイクホルダはもっと積極的にプロジェクトに関わることは可能
  • >Top The manifesto (Agile Alliance 2001a) : defined four simple value statements:
    1. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation.
    2. Responding to change over following a plan.
  • The principles for agile software development:
    1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, form a couple of weeks to a couple of months, with a preference to the shorter time scale.
    2. Business people and developers must work together daily throughout the project. Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    3. The most efficient and effective method of conveying information to and within a development team is fact-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    4. Continuous attention to technical excellence and good design enhances ability. Simplicity - the art of maximizing the amount of work not done - is essential. The best architectures, requirements, and designs emerge from self-organizing teams.
    5. At regular intervals, the team reflects on how to become more effective, and then tunes and adjusts its behavior accordingly.
  • Agile Alliance宣言(2001): ４つの価値を定義:
    1. 個人や相互作業をプロセスやツールより重視。目的は、ソフトウェアを作ることであり、文書を作ることではない。顧客との協調を契約交渉よりも重視
    2. 計画に従うことより変化に対応することを重視
  • アジャイルなソフトウェア開発の原則：
    1. 早期、継続的な納入によって、顧客満足を満たす。開発終盤であろうとも、要求内容の変更を歓迎する。数週間〜数ヶ月サイクルでソフトウェアを納入する。
    2. ビジネス側人材と開発側人材とがプロジェクトを通じて、日常的な協力する。意欲的な開発者を中心にプロジェクト編成を行う。必要な環境や支援を与えて、彼らの任務遂行を信頼する。
    3. チーム内外での効率的、効果的な情報伝達手段は、対面での会議である。動くソフトウェアが、主たる進捗の確認手段である。アジャイルなソフト開発は、持続的な開発を促す。スポンサー、開発者、ユーザは一定のペースを守ことができる。
    4. 技術力と良い設計に注目することで、アジャイル度は向上する。簡潔さは本質である。即ち、不要なことは最大限しないこと。最善のアーキテクチャ、要求、設計は自己組織化されたチームから生まれる。
    5. チームは、定期的にどうしたらもっと効果的になるか、また行動もそれに合わせられるかを熟慮すること。
  • >Top Agile Modeling (AM) is a chaordic, practice-based methodology for effective modeling and documentation of software-based systems.
    • AM is chaordic (Hock 1999), in that it blends the chaos of simple modeling practices and blends it with the order inherent in software modeling artifacts. Extreme Programming (XP) (Beck 2000)SCRUM (Beedle and Schwaber 2001) Dynamic System Development Method (DSDM) (Stapleton 1997) Class Responsibility Collaborator (CRC) models This forces you to think through how you will build your software before you actually build it. There are two primary reasons why you model;
      • to understand what it is you are building
      • to aid your communication efforts within your team or with your project stakeholders.
    • AM is not a complete software process. AM's focus is on effective modeling and documentation.
      • You start with a base process such as XP or UP, and then tailor it with AM as well as other techniques as appropriate to form your own process.
  • What are Agile Models?
    • Agile models fulfill their purpose.
    • Agile models are understandable.
    • Agile models are sufficiently accurate.
    • Agile models are sufficiently consistent.
    • Agile models are sufficiently detailed.
    • Agile models provide positive value.
    • Agile models are as simple as possible.
  • What isn't Agile Modeling?
    • AM is an attitude, not a prescriptive process.
    • AM is a supplement to existing methods; it is not a complete methodology.
    • AM is complementary to other modeling processes.
    • AM is a way to work together effectively to meet the needs of project.
    • AM is effective and is about being effective.
    • AM is something that works in practice; it isn't an academic theory.
    • AM is not a silver bullet.
    • AM is for the average developer, but is not a replacement for competent people.
    • AM is not an attack on documentation.
    • AM is not an attack on CASE tools.
  • アジャイルモデリング (AM):は、カオス秩序的(chaordic; Hock, 1999) な実践に基づく方法論
    • AMは、単純なモデリングの実践のカオスに、ソフトウェアのモデリングの秩序を配合XP (eXtreme Programming): Beck, 2000 SCRUM (like Rugby scrum): Beedle/Schwaber, 2001 DSDM (Dynamic System Development Mehtod0: Satapleton, 1997 CRC (Class REsponsibility Collaborator) モデル ソフトウェアを作るまでにソフトウェアをどのように作るかを考える。モデリングの目的:
      • 開発する内容の理解
      • 関係者との意思疎通
    • AMは完結したソフトウェア開発プロセスではない。AMは効果的なモデリングとドキュメントに焦点を当てている。
      • XPやUPなど土台となるプロセスから始めて、それをAMや他の適切な技法でカスタマイズし、ニーズに合わせた独自プロセスを構築する。
  • AMは何であるか:
    • AMによって目的を達成する。
    • AMは理解可能である。
    • AMはかなりの程度正確である。
    • AMはかなりの程度一貫性がある
    • AMはかなりの程度詳細である。
    • AMはプラスの価値をもたらす
    • AMはできる限り簡潔である
  • AMは何でないか:
    • AMは心構えであり、規範的なプロセスではない。
    • AMは他の手法の補完であり、単独の完全な方法論ではない。
    • AMは実践で役立つものであり、学術上の理論ではない。
    • AMは銀の弾丸(特効薬) ではない。
    • AMは平均的な開発者向けであって、有能な人々の代替えにはならない。
    • AMはドキュメント化を否定するものではない。
    • AMはケースツールを否定するものではない。

>Top 2. Agile Modeling (AM) value:

  • Modeling is similar to planning - most of the value is in the act of modeling, not the model itself. The values of AM are:
    • communication: simpleness, feedback, courage
    • humility: Project stakeholders, not developers, are the source of requirements.
  • Communication:
    • Communication is a two-way street. You both provide and gain information as the result of communication.
    • Modeling helps you to communicate your ideas, to understand the ideas of others, to mutually explore those ideas to eventually reach a common understanding
  • Simplicity:
    • The KISS rule (Keep It Simple Stupid!) The IT industry has preached simplicity for years, but for some reason the choir hasn't been listening.
    • Common complications include:
      • Applying complex patterns too soon. Overachieving your system to support potential future requirements.
      • To develop a complex infrastructure.
  • >Top Feedback:
    • Develop the model as a team. Review the model with your target audience. Implement the model.
    • Acceptance testing.
  • Courage:
    • Courageous people walk through the door; they don't stand there and wonder what's on the other side. Methods such as XP and AM ask you to do the simplest thing that you can, to trust that you can solve tomorrow's problems tomorrow.
    • During development you also need courage to change direction when some of you decisions prove inadequate, by either discarding or refactoring your work.
  • Humility:
    • Agile modelers understand that their fellow developers and their project stakeholders have their own areas of expertise and have value to add to project.
    • Agile modelers have the humility to admit that they need help to do their jobs successfully, to work together with others.
    • Arrogance leads to communication problems that in turn lead your project into trouble.

2. AMの価値:

  • モデリングは計画と似ている：殆どの価値はモデリングを行う行為の中にあって、モデルそのものではない。AMの価値:
    • コミュニケーション簡潔さフィードバック勇気
    • 謙虚さ：要求事項の源泉はステイクホルダであって、開発者ではない。
  • コミュニケーション:
    • コミュニケーションは双方向。情報を提供すると共に情報を得る。
    • モデリングする理由の１つは自分のアイデアを伝え、相手のアイデアを理解し、双方のアイデアを深めて相互理解に至るためである。
  • 簡潔さ:
    • KISS原則 (Keep It Simple, Stupid!)シンプルで低機能(愚鈍) に。IT業界は、何年も簡潔さを布教してきたが、なぜかまだ見解が一致していない。
    • ソフトウェアの複雑さの原因は：
      • 複雑なパターンを性急に適用することによる潜在的な将来の要求事項に備えるために、システムに過剰なアーキテクチャを適用することによる
      • 過剰なアーキテクチャを開発することによる
  • フィードバック:
    • チームでモデルを開発する。自分のモデルの利用者とモデルをレビューするモデルを実装する
    • 受入テスト
  • 勇気:
    • 勇気ある人たちは、ドアを黙って通り抜ける。ドアの前で立ち止まったり、向こう側に何があるか考えもしない。XPやAMのような方法論では、できる限り作業を簡潔に行い、明日の問題は明日に解決できると信じること。
    • 自分の間違いに気づいた時は、作業結果を廃棄したり、書き直したりして方向転換する勇気を持たなければならない。
  • 謙虚さ:
    • 同僚やステイクホルダが各々の得意分野を持ち、プロジェクトに貢献できることを理解する他人と力を合わせる謙虚さを備えている。
    • 傲慢さが高じると、他人が協力しなくない、コミュニケーションが阻害され、プロジェクトがトラブルに陥る。

>Top 3. Core principles:

  • Principles only mean something when you stick to them when the going gets tough. Software is your primary goal.
    • The primary goal of software development is to produce high-quality software that meets the needs of your project stakeholders in an effective manner.
    • We're not documentation developers, or even model developers; we're software developers.
  • Enabling the next effort is your secondary goal.
    • Your secondary goal is to set up to play the next game. Your next effort may be to develop the next major release of your system or it may simply be to operate and support the current version that you are building.
  • Travel light.
    • Traveling light means that you create just enough models and documentation to get by.
    • A good rule of thumb is to not maintain a model until it is very clear that you need it.
  • Assume simplicity:
    • The advantage is that you aren't investing extra time implementing difficult solutions, approaches that take more time and effort to put in place. Don't over-model your system today; model based on today's existing requirements and then refactor your system in the future when you requirements evolve.
  • This principle is the Occam's Razor of modeling - when in doubt take the simplest approach possible.
    • Re: Occam's Razor: Entities must not be multiplied beyond necessity.
    • Given two predictive theories, choose the simplest.

3. 基本原則:

  • 原則とは、窮地に陥った場合、守るべき何かを表しているに過ぎない。ソフトウェアが第１のゴール:
    • ステイクホルダのニーズを効果的に満たす高品質のソフトウェアを開発する。
    • 我々はドキュメント開発者でも、モデル開発者でもない。我々はソフトウェア開発者である。
  • 次への備えが第２のゴール:
    • 次のゲームに対して備える。次に来るのは、次のメジャーリリースや現バージョンの運用・サポートの場合もある。
  • 身軽な旅:
    • 開発で必要な最低限のモデルとドキュメントを作成する。
    • 本当に必要だと明らかになるまでは、モデルを保守しない。
  • 簡潔さを心掛ける:
    • 最も簡単な解で役立たない場合でも、資源浪費はなく、より複雑なソリューションを実装するだけの時間が残されている。システムのモデルを作り込み過ぎない。要求が変化した時点でモデルを改良(refactor)する。
  • これはモデリングにおけるオッカムの剃刀 (Ockham's razor) の原則である。
    • ある事柄を説明するためには、必要以上の多くの実体を仮定するべきではない。
    • 現象を同程度にうまく説明する仮説があるなら、より単純な方を選ぶべきである。
  • >Top Embrace change:
    • Accept the fact that change happens. Revel in it. Requirements evolve over time.Your business and technological environments change as your project evolves; things occur that are often beyond the scope of your control.
    • The Agile Alliance advises that you welcome changing requirements even late in the project lifecycle.
  • Incremental change:
    • You can make a big change as a series of small, incremental changes.
    • Make it run, make it right, then make it fast.
  • Model with a purpose:
    • You aren't modeling solely for the personal satisfaction of modeling; instead you are modeling to fulfill the needs of your project stakeholders.
    • Your first step is to identify a valid purpose for creating a model and the audience for that model.
  • 変化を受け入れる:
    • 変化は起きるものであり、それを大いに楽しむべし。要求事項は時間と共に変化する。プロジェクトの途中でビジネスや技術的環境が変化する。コントロールできる範囲外でさまざまなことが起こる。
    • アジャイル・アライアンスは、プロジェクトの終盤でも要求事項の変化を歓迎することを推奨している。
  • 少しずつ変更する:
    • 大きな変更は、小さくインクリメンタルな変更の積み重ねによる。
    • まず動くようにして、次に正しく動くように、それから速く動くようにする。
  • 目的をもったモデリング:
    • 自己満足のためにではなく、ステイクホルダのニーズを満たすためのモデリングをする。
    • まず、モデルを作成する目的およびモデルの利用者を明確にする。
  • >Top Multiple models:
    • You can describe the complexities of what you are building using several simple models instead of one or two very complex ones. Note that although you have a wide range of models available to you don't need to develop all of them for any given system.
    • You need an intellectual toolbox of techniques, just as a carpenter has a toolbox of tools.
  • Quality work:
    • Agile developers should invest the effort to make permanent artifacts, such as source code, user documentation, and technical system documentation.
    • Similarly, agile developers don't invest much effort in artifacts that they intend to discard, particularly sketches or low-fidelity artifacts such as essential user interface prototypes.
  • Rapid feedback:
    • we make most of our mistakes in the early aspects of development and the cost of fixing defects increases exponentially the later they are found.
  • Maximize stakeholder investment:
    • System documentation is a business decision, not a technical one.
  • Why core principals?:
    • By failing to adopt one to the core principles or practices of AM, you reduce the method' s effectiveness. You can benefit by only adopting a portion of AM.
    • Feel free to adopt whatever aspects of AM that you see fit.
  • 複数のモデル:
    • 少数の簡潔なモデルで複雑な開発内容を表現することができる。広範なモデルを使える場合でも、それら全てを使う必要はないことに留意すべきである。
    • 複数のテクニックの入った「考えるための道具箱」が必要。あたかも大工道具の箱のように。
  • 質の高い仕事をする:
    • 後まで残る成果物は十分な品質になるようにする。ソースコード、ユーザドキュメント、技術システムドキュメントなど。
    • 最終的には捨てる成果物には多くの労力を投じない。手書きの図、UIプロトタイプなど
  • 素早いフィードバック:
    • 我々の間違いの多くは開発の初期に生まれる。
    • 問題の発見が遅くなるにつれて問題の解決コストが指数関数的に増える。
  • ステイクホルダの投資を最大限活かす
    • システムの文書化はビジネス上の判断であり、技術上の判断ではない。
  • なぜ基本原則なのか？:
    • AMの一部を取り入れるだけでも効果はあるが、相乗効果があるので飛躍的な改善は生じない。
    • 自分が良いと思うAMのどの側面でも、気軽に取り入れてもよい。

>Top 4. Supplementary principles:

  • It is easier to fight for one's principles than to live up to them.
  • Although these principles support AM's core principles, their adoption is not required for you to be truly agile modeling. These principles are all very good ideas and you should adopt them if they fit well into your organizational culture.
    • Content is more important than representation:
      • At first it is better to work with simple, flexible tools.
    • Everyone can learn from everyone else:
      • There is always an opportunity to learn more and to extend your knowledge. Existing technologies such as Java evolve at a blinding pace, and new technologies such as C# and .NET are introduced regularly.
      • The point is that we work in an industry where change is the norm, were you must take every opportunity to learn new ways of doing things through training, education, mentoring, reading, and working with each other.
    • Know your models:
      • Because you have multiple models that you can apply as an agile modeler, you need to know their strengths and weaknesses to be effective in their use.
    • Local adaptation:
      • You will need to modify AM to reflect your environment, including the nature of your organization, your co-workers, your project stakeholders, and your project itself.
      • It may not be realistic to try to adopt AM in full, at least not right away, so you may find that you can tailor a portion of AM's principles and practices into your existing software process.
    • Open and honest communication:
      • This requires commitment on everyone's part and an understanding that effective communication is a critical success factor for software development projects.
      • I t requires humility on everyone's part to be willing to abandon their pet ideas upon hearing that they may not be as good as they originally thought.
    • Work with people's instincts:
      • As you gain experience at developing software, your instincts become sharper, and what your instincts are telling you subconsciously can often be an important input into your modeling efforts.

4. 追加原則:

  • 原則を受け入れて生きるより、原則の為に戦う方がたやすい。
  • 以下の追加原則は必須ではない。組織文化とうまく整合する場合のみ、これらの原則を受け入れるべき。
    • 見栄えより中身:
      • 時には手書きの図も
    • 誰しも他人から学べる:
      • 自分が何かを学び尽くすことはないことを理解する
      • Javaのような技術は、
      • 変化が当たり前の業界で仕事をしている。そのため、研修、教育、指導、読書、他人との一緒のモデリングなどを通じた学ぶ機会を活用すべき。
    • モデルを知る:
      • AMとして適用できる複数のモデルがあるが、それらを効果的に使うためには、その長所、欠点を理解する必要がある。
    • 現場の実情に合わせる:
      • 組織、チーム、ステイクホルダなど自分の環境を反映するためにAMを変える必要がある。
      • AMを全面的にすぐ取り入れるのが現実的でない場合、AMの原則や実践を調整することで、既存のソフトウェアプロセスにその一部分を取り入れることが可能となる。
    • オープンで正直なコミュニケーション:
      • これは各々の分担を確約させると共に、効果的なコミュニケーションがソフトウェア開発にとって重要な成功要因であることを理解させることになる。
      • 自分の最初の考えが良くなければ、進んで自分の考えを捨てる謙虚さを備えることが必要
    • 直感に従って開発する:
      • ソフトウェア開発の経験を積むに従い、本能が鋭くなり、無意識的にモデリングを行う上で、重要な情報源となる。
      • 自分の感覚が間違っている場合には、その状況を修正する勇気を持つ。

>Top 5. Core practices:

  • Perfect practice makes perfect.The hart of Agile Modeling is its practices.
  • It is better to adopt all of them if they fit well into your organization's culture. AM's core practices are organized into four categories:

  • 1. Iterative and incremental modeling:
    • Apply the right artifacts:
      • UML state chart essential use case source code data flow diagram (DFD)
      • If a picture is worth 1000 words, then a model is often worth 1024 lines of code.
    • Create several models in parallel:
      • When you are designing Java, you need to develop a UML class diagram to formulate its structure, a UML state chart diagram to explore the inner workings of a complex class, a UML sequence diagram to determine how to implement the logic of a flow within a business flow, and a physical data model to understand the structure of your relational database.
      • Agile modelers are far more productive working on several models simultaneously than if they are focusing on only one at any given time.
    • Iterate to another artifact:
      • Whenever you find you have difficulties working on one artifact, you should iterate to another artifact; by iterating to another artifact, you immediately become unstuck because you are making progress working on that other artifact.
      • The hardest thing is to identify a likely candidate to iterate to.
    • Model in small increments:
      • Release over time, ideally in increments of several weeks or a month or two.This increase your agility by enabling you to deliver software into the hands of your users faster.No more big design up front (BDUF) , where you invest weeks or even months creating models and documents.
      • Have the courage to solve today's problem today, and trust that you can solve tomorrow's problem tomorrow.

5. 基本実践:

  • 完全な実践が完全さを作る。
  • AMの核心はその実践にある。AMを実践するためには、基本プラクティスをすべて取り入れる必要がある。基本プラクティスとは、以下４分野に分類される:

  • 1. 反復的でインクリメンタルなモデリング:
    • 適切な成果物を使う (それぞれ長所と短所)
      • UMLのステートチャート基本ユースケースソースコードデータフロー図 (DFD)
      • １つの図が1000の単語、１つのモデルが1024行位のコードに匹敵
    • 複数のモデルを併行して作る
      • Javaでの設計には、UMLのクラス図、UMLのステートチャート図、UMLのシーケンス図、物理データモデルを使う必要がある。
      • アジャイルモデラーは、一時期に１モデルに集中するより、複数のモデルを併行して作業する方が効率的である。
    • 他の成果物に移る
      • ビジネスロジックを書くのに行き詰まったら、他の成果物で作業を進めることで、視点が変わり、問題の解決策が見つかる場合も多い。
      • 最も難しいのは、行き詰まった際に移る先の成果物の候補を見出すこと
    • 少しずつモデリングする
      • 数週間から1〜2ヶ月毎にリリースを重ねるユーザにソフトウェアを早く納品できる。 何週間や何ヶ月もモデルや文書作成して、先行して大量に設計するBDUF (Big Design Up Front)こととはおさらばする。
      • 今日の問題は今日解決し、明日の問題は明日解決できるという勇気を持つ。
  • >Top 2. Practices for effective teamwork:
    • Model with others
      • One you are finished drawing, talk about your ideas with someone to see if you're going in the right direction. Two or more heads are better than one.
    • Active stakeholder participation
      • On-Site Customer:
        Have on-site access to people, typically users or their representatives, who have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements and prioritization thereof.
    • Collective ownership
    • Display models publicly
  • 2. チームワーク:
    • 他人と一緒にモデリングする
      • 考えがまとめたあら、他人に説明し、正しい方向を確認する方がよい。一人より2-3人で考える方が良い考えが生まれる。
    • ステイクホルダの積極敵な参加
      • オンサイト・カスタマ:
        開発対象のシステムに重要な情報を提供したり、要求事項や優先度について適切な判断を下す、ユーザやその代表が開発チームの近くに必要である。
    • 共同所有
    • モデルの公開
  • >Top 3. Simplicity:
    • Create simple content
      • The model fulfills its purpose.The model must contain no duplicate information.
      • The model should have the fewest possible elements.
      Depict models simply
      • Avoid crossing lines
      • Avoid unnecessary detail
    • Use the simplest tools
  • 4. Validation:
    • Consider testability
      • If you can't test the software that you build, you shouldn't build it.
    • Prove it with code
      • Do some modeling, do some coding, and do some testing.
      • Because you are usually your model's customer and therefore are the one directly affected by any problems with it. Do quality work to begin with.
  • 3. 簡潔さ:
    • 中身はシンプルに作る
      • モデルの目的を達成している重複した情報がない
      • なるべく少ない要素
      モデルはシンプルに描く
      • 線の交差は避ける
      • 不必要に詳しくしない
    • 最も簡単な道具を使う
  • 4. 検証:
    • テストできるか考える
      • 自分の作るソフトウェアがテストできないなら、そのようなものを作るべきではない。
    • コードで確かめる
      • ある程度モデリングしたら、コーディングし、テストをする。
      • モデルの利用者は自分自身なので、そのモデルによって発生する問題の影響を自身が直接受ける。 そもそも最初から質の高い仕事を行う。

>Top 6. Supplementary practices:

  • The practices are not the knowing. They are a path to the knowing.
  • 1. Productivity:
    • Apply modeling standards
      • UML (Unified Modeling Language) provides a good start for standard modeling notation but it isn't sufficient. UML does not include model for user interface design nor data/persistence model.
    • Apply patterns gently
      • If you suspect that a pattern is applicable, you should model it in such a way as to implement the minimal functionality that you need today but that makes it easy to refactor/rework later if required.
    • Reuse existing resources
      • NIT syndrome is often blamed for low levels of reuse, but agile developers will readily reuse something if it addresses a problem relevant to the project they are working on and is of sufficient quality.

6. 追加実践:

  • プラクティスは智恵にあらず。それは智恵に至る道である。
  • 1. 生産性:
    • モデリング標準を適用する
      • UMLは、標準モデリング技法の良い出発点を提供しているが、十分ではない。UMLにはユーザインターフェイスのデザインのためのモデルがなく、またデータ・永続性のモデルもない。
    • パターンは控えめに使用する
      • パターンが使える場合でも、今必要最小限の機能のみを実現し、後日必要な場合改良や再作業を行いやすくする。
    • 既存の資源を再利用する
      • NIH症候群としてよく指摘されるが、アジャイルな開発者は、自分達のプロジェクトにとって重要な問題に役立ち、そこそこの品質があれば、何でも積極的に再利用すべきである。
  • >Top 2. Documentation:
    • Discard temporary models
      • If a model is temporary, then discard it the instant you are finished.
      • This has several benefits: First, it reduces the clutter within your workspace. Second, it reduce the change that someone will make a decision based on the out-of-date information. Third, it reduces the temptation to invest time updating the model.
      Formalize contract models
      • Examples of contract models include the detailed documentation of API, a file layout description, an XML DTD, or a physical data model describing a shred database.
      • Your goal is to minimize the number of contract models for your system.
    • Update only when it hurts
      • The most difficult part of it is to become comfortable with artifacts getting out of sync with one another, to wait until it really does start to become inconvenient for you.
      • This practice is enhanced by the principle of traveling light - the less permanent models and documentation that you choose to maintain, the less painful it is to update them.
  • 2. ドキュメント:
    • 一時的なモデルは破棄する
      • モデルが一時的であれば、目的達成後すぐにそれを破棄する。
      • これには利点がある。第一に、作業場所を雑然とさせない。第二に、古い情報に基づく判断の機会を減らす。第三に、モデル更新に時間を使おうという誘惑もなくなる。
      契約モデルはきちんと定義する
      • 契約モデルの例としては、APIに関する詳細ドキュメント、ファイルレイアウトの説明、XMLのDVD、共用データベースを説明する物理データモデルなど。
      • 開発に必要な契約モデルを最小限にする。
    • 困った時のみ更新する
      • 最も難しいのは、成果物の整合性が失われても平然と構えることであり、実際に不都合が生じるまで不整合のままで置いておく。
      • このプラクティスは身軽な旅という原則に基づいており、ずっと維持し続けるモデルやドキュメントが少ないほど、変更が発生した際にそれらを更新する苦労は少なくなる。
  • >Top 3. Motivation:
    • Model to understand
      • You often develop small, simple diagrams that focus on one aspect of you software, such as the life cycle of a class or the flow between screens, diagrams that you often throw away once you are finished with them.
    • Model to communicate
      • remember the principle model with a purpose and first identify why you are creating this model and for whom. (Principle: Content is more important than representation.)
      • It also helps to build a common vocabulary within your team and with your project stakeholders.
  • 3. 動機:
    • 理解するためのモデリング
      • １つのクラスのライフサイクルやスクリーン間の遷移のように、ソフトウェアの特定の側面に焦点を当てた小さくて簡潔な図を多く作成し、作業後にはそれらを廃棄する。
    • コミュニケートするためのモデリング
      • も的をもってモデリングする。まずモデルを作成する目的や利用者を明確にする。 (見栄えより中身)
      • またモデルを作成することによって開発チーム内やステイクホルダとの間の共通の用語ができる。
  • >Top 4. Really good ideas:
    • Know your tools
      • We should give developers adequate training in a tool and the opportunity to learn how to use their tools effectively on the job.
      Refactoring
      • You make small changes called refactorings, to your code to support new requirements or to keep your design as simple as possible.
      • It preserves the semantics of your code: you make a change and your code still works.
      Test-first design:
      • Write your testing code before you write your business code.
      • Agile developers quickly discover whether or not heir ideas actually work providing rapid feedback regarding the ideas captured within the models.
  • 4. 良いアイデア:
    • 道具を知る
      • 開発者には、ツールに関する適切なトレーニングを提供し、ツールを効果的に使う方法を修得させるべきである。
      リファクタリング
      • 新たな要求事項に応え、設計をできるだけ簡潔にするためにリファクタリングと呼ばれる若干の変更を加える。
      • リファクタリングの前後でコードに意味は変わらないようにすべきで、変更後でもコードは元通り動作することが重要である。
      テースファーストデザイン
      • コードを書く前にテスト用のコードを書くべきである。
      • アジャイルな開発者は、自分の考えが役立つかどうかを迅速に見極めることができ、モデルに盛り込んだ考えに対して素早いフィードバックを提供できる。

>Top 7. Order from Chaos:

  • So much of what we call management consists in making it difficult for people to work. AM_practicesThe practices of AM are synergistic in the fact that they support and often enable one another.
    • They are chaordic in that they define behavior that harmoniously blends order and chaos.The first four categories - Validation, Iterative & Incremental, Teamwork, and Simplicity - consolidate AM's core practices.
    • The supplementary practices are consolidated by Documentation, Motivation, and Productivity categories.
  • Chaos and Order: Chaordic
      1. the behavior of any self-governing organism, organization, or system that harmoniously blends characteristics of order and chaos patterned in a way dominated by neither chaos nor order.
      2. characteristic of the fundamental organizing principles of evolution and nature

7. カオスからの秩序:

  • マネジメントを呼ぶものの大半が仕事を困難にすることにある。AMのプラクティスは、相互に助け合うことで、相乗効果的に作用している。
    • それは秩序的であると同時に調和的な振る舞いを定義する。 (カオス秩序的)基本プラクティスは、検証、反復的でインクリメンタル、チームワーク、簡潔さの４分野から成る。
    • 追加プラクティスは、ドキュメント、動機、生産性の３分野から成る。
  • カオスと秩序：カオス秩序的 (Chaordic)
    1. カオスと秩序をうまく調和するようにブレンドした自律的な生物・組織・システムの振る舞い。カオスにも秩序にも支配されないパターンを持つ状態
    2. 進化と自然の基本的な原則を系統立てる特徴
  • >Top Why is the concept of chaordic important?
    • Because it provides a conceptual framework for a practice-based framework such as AM. A practice-based methodology such as AM can appear chaotic at times, particularly to people unfamiliar with it or who are not actively involved with the project. But chaordic isn't the right word because, when followed properly, AM produces significant results.
    • AM supports a good form of chaos, one that is steered, rather than directed, by people working together guided by common values and principles. Thus AM supports order within your project. Chaos and order; Chaordic.
  • カオス秩序的という概念はなぜ重要か？
    • それはAMなど実践ベースのフレームワークに対する概念的な枠組みを与えるからである。
    • AMなど実践ベースの方法論は、時にカオス的に見える。特にその方法論に慣れていない人や、プロジェクトに積極敵に参加していない人にとっては顕著である。しかし、カオスという言葉は適切な表現ではない。AMを正しく使うと素晴らしい結果が生まれるからである。
    • AMはカオスの優れた形、即ち、指図ではなく、指導という形を支援する。それは人々が共通価値や原則に基づき協同することを意味する。こうしてAMはプロジェクト内の秩序を後押しする。つまりカオスと秩序のカオス秩序的という訳である。

>Top 8. Communication:

  • modesof_commMode of Communication Channel:
    1. One way: Document-based communication
    2. Two way: Modeling-based communication
    The most effective communication is face-to-face, enhanced by a shared modeling medium such as a whiteboard, flip chart, paper, or index cards.As you move away from this situation, by removing the shared medium or by no longer being face-to-face, you experience a drop in communication effectiveness.
  • The ability to answer questions in real time is important because questions provide insight into how well the information is understood by the listener.

8. コミュニケーション:

  • コミュニケーションチャネル・モード: <左図>
    1. 一方向のコミュニケーション：ドキュメントを介するコミュニケーション
    2. 双方向コミュニケーション：目処リングを介するコミュニケーション
    最も効果的なのは、対面でのコミュニケーションであり、補ワイドボードなどの共有できるモデリング手段を使う場合は、更に効果的となる。共有手段を取り除いたり、対面での話し合いが亡くなることで、コミュニケーションの効果は急激に低下する。
  • すぐに質問に答えられる点は、聞き手の理解度を知る上で重要である。

>Top 9. Nurturing an agile culture:

  • You can be agile or you can be fragile. What can you do to nurture an AM-positive culture within your organization?
    • Overcome the misconceptions that surround modeling.
    • Think small.
    • Loosen up a bit.
    • Rigidly support project stakeholder rights and responsibilities
    • Rethink presentations to stakeholders
  • Misconception #1:
    Model = Documentation.
    • The concept of 'model' and 'document' are orthogonal - you can have models that aren't documents and documents that aren't models. Modeling is a lot like planning : Just as the value is in the planning efforts and not the actual plan itself, most of the value is in the modeling and not the model itself.
    • There are few models that you actually need to keep: Discard temporary models.
  • >Top Misconception #2:
    You can think everything through from the start.
    • There is often a motivation to 'freeze' requirements before coding starts, and 'analysis paralysis' often sets in - the fear of moving forward until your models are perfect. (BDUF)
    • Specification is destined to quickly become out of synch with your code. The fundamental reality is that only your code is ever truly in sync with your code.
    • An iterative approach to software development (little modeling, some coding, some testing, and deploy a small working system) is the norm for software development.
  • Misconception #3:
    Modeling implies a heavy-weight (HW) software process
    • You can model in an agile manner by developing simple models using simple tools.
  • Misconception #4:
    You must freeze requirements:
    • Take an iterative and incremental approach to software development where you can act appropriately when you requirements evolve. (Model in small increments)

9. アジャイル文化の育成:

  • 機敏にも脆弱にもなり得る。組織内にAMに前向きな文化を助長するには
    • モデリングを取り巻く誤解の克服。
    • 小さく考える。
    • 少し余裕を持つ。
    • ステイクホルダの権利と責任を厳格に支援する。
    • ステイクホルダへのプレゼンを再考する。
  • 誤解その1:
    モデル＝ドキュメントである。
    • モデルと文書とは完全に別物である。文書でないモデルや、モデルでない文書を作ることができる。
    • モデリングは計画に似ている。計画自体ではなく、計画するという作業自体に価値があるのと同様に、モデル自体ではなく、モデリングという作業に価値の大半がある。
    • 真に残しておく必要のあるモデルはほとんどない。一時的なモデルは破棄する。
  • 誤解その2:
    最初からすべてを見通せる。
    • コーディングを始める前に要求を凍結しようとし、モデルが完璧に仕上がらない内は進むのを恐れるという分析麻痺症が生じる。(BDUF)
    • 仕様はモードやモデルとすぐに同期が取れなくなるのが宿命である。コードと真に同期が取れているのはコードだけだという現実がある。
    • 少しモデリングし、少しコーディングし、少しテストして、システムの動く部分まで配置するというのが反復的アプローチである。
  • 誤解その3:
    モデリングというとてつもないソフト開発プロセス
    • 単純な道具を使って簡単なモデルを作成することでアジャイルモデリングができる。
  • 誤解その4:
    要求を凍結しなければならない。
    • 反復的で増分的なソフト開発手法を取り入れることで、要求が変化した時に、適切に対応できる。 (少しずつのモデリング)
  • >Top Misconception #5:
    Your design is carved in stone.
    • Changes to your requirements will force changes to you design. Remember that your design isn't finished for a given release until you've shipped the code.
  • Misconception #6:
    You must use a CASE tool.
    • You can create effective yet simple models that only show critical information and not irrelevant details.
  • Misconception #7:
    Modeling is a waste of time.
    • You are very often more productive sketching a diagram, developing a low-fidelity prototype, or creating a few index cards to think something through before you code it. (Model to Understand)
  • Misconception #8:
    The world revolves around data modeling.
    • You have a wide variety of model - use cases, business rules, activity diagrams, class diagrams, component diagrams, user interface flow diagrams, and class responsibility collaborator (CRC) models.
    • Each model has its strengths and weaknesses. (Apply the right artifacts)
  • Misconception #9:
    All developers know how to model.
    • Programmers, as highly intelligent people, often believe they can do anything - they're programmers after all.
    • Everyone should have the humility to understand that they don't know everything and that they can always learn something important from everyone else.
  • 誤解その5:
    設計は石に刻印されたように不変である。
    • 要求が変われば、設計も変わる。あるリリースの設計はコードを出荷するまでは終わらない。
  • 誤解その6:
    CASEツールは使わなければならない。
    • 重要な情報だけを示して、不適切な詳細を省いた効果的かつ簡潔なモデルを作成することはできる。
  • 誤解その7:
    モデリングは時間の無駄である。
    • 図、大雑把なプロトタイプ、数枚のインデックスカードを書いたりして、コーディングを羽島得る前に熟慮することで生産性が向上する。 (理解のためのモデリング)
  • 誤解その8:
    データモデリング中心に世界は回る。
    • 様々なモデルを使うことができる。ユースケース、ビジネスルール、アクティビティ図、クラス図、コンポーネント図、UIフロー図、CRCモデル
    • 各々のモデルにも長所欠点がある。
  • 誤解その9:
    すべての開発者がモデリング手法を知っている。
    • プログラマは、非常に聡明なので、自分は何でもできると考える傾向がある。
    • 誰もが、自分が全てを知っている訳ではなく、他人から重要なことを学ぶことができるということを理解する謙虚さが必要である。
  • >Top Think small:
    • Short (small) modeling sessions
    • Small teams: Smaller teams require less management overhead, such as status reports and meetings, than do larger teams.
    • Small models
    • Small documents
  • Loosen up a bit:
    • You don't need to slavishly follow a process that tells you that to achieve goal X you need to produce artifact Y.
    • First, question whether you need to achieve goal X and, then ak yourself what the best artifact is. (Apply the Right Artifacts)
  • >Top Rethink presentations to project stakeholders:
    • Minimize the number of presentations
    • Try to find an alternative
    • Turn the presentation into a working session
    • Make project stakeholders aware of the costs
    • Project stakeholders decide whether they wish to have a presentation
    • Keep it simple:
      Are your stakeholders interested in the system or MS Power Point skills?
    • Minimize the number of people involved in preparation:
      Do not distract the entire team with the creation of a presentation.
    • Minimize the number of people that attend the presentation:
      The best approach is to identify the minimum number of people who need to attend the presentation, ideally only the person giving it, and have them report back to the rest of the team.
  • 小さく考える:
    • 短時間モデリング期間
    • 小さいチーム：進捗報告や会議など管理のためのオーバーヘッドが少なくなる。
    • 小さいモデル
    • 小さい文書
  • 少しゆとりを持つ:
    • 目的Xを達成するには、成果物Yを作成する必要がある、という場合でも、やみくもに従う必要はない。
    • 目的X を達成する必要があるかどうかを疑い、達成する必要があるなら、そのための最善の成果は何かを考える。
  • ステイクホルダに対するプレゼンを見直す:
    • プレゼンの回数を最小にする
    • 代替手段を探す
    • プレゼンの代わりに作業セッションを行う
    • ステイクホルダにコスト意識を持たせる
    • プレゼンが必要かどうかステイクホルダに決めさせる
    • 簡潔にする：
      システムに興味あるのか、PowerPointのスキルに興味があるのか
    • 準備に関わる人数を最少にする
      プレゼン作成をチーム全体で分担しない。
    • プレゼンに出席する人数を最少にする。
      プレゼンへの参加は理想的にはプレゼンを行う人だけとし、残りのメンバには後で結果を知らせる。

>Top 10. Using the simples tools possible:

  • Stick with simple tools, like pencil, paper, and whiteboard. Communication is more important than whiz-bang.
    • Use the simplest tool possible that meet your need. Sometimes that tool is a whiteboard and some markers, and sometimes that tool is leading-edge CASE tool.
  • Agile modeling with simple tools?:
    • Advantages of simple tools
  • The evolution of a model:
  • Agile modeling with CASE tools: (below)
    Potential advantage and disadvantage of CASE tools:
  • Use the media:
    • Color
    • Size
    • Flexible drawing tools
    • 3D mock-ups
  • The effects of tools on models:
    • You are likely to get a different model when using simple tools than when using more complex ones.
    • Simple tools are far more flexible and don't suffer from the modeling limitations.
  • Using the simplest tools in practice:
    • Let the principles 'know your tools and maximize stakeholder investment' guide your tool selection efforts.

10. 最も簡単な道具を使う:

  • 紙や鉛筆やホワイトボードといった単純な道具を使うべきである。かっこよさよりもコミュニケーションの方が重要である。
    • ニーズを満たすことができる最も簡単な道具を使うべきであって、それは補ワードボードとマーカーの場合もあれば、最先端のCASEツールの場合もある。
  • 簡単な道具を使ったAM:
  • モデルの発展:
  • CASEツールを使ったAM: (下表)
  • 様々なメディアの利用
    • 色
    • サイズ
    • 柔軟なドローイング・ツール
    • 3D模型
  • モデルに対するツールの影響
    • 単純なツールを使う場合は、複雑なツールの場合とは異なるモデルができあがる。
    • 単純なツールはずっと柔軟でモデリング上の制限に悩むことはない。
  • 最も簡単な道具を実践で使う
    • ツールを理解し、ステイクホルダの投資を最大化するという原則に基づき、ツールの選択をする。
Advantages
Disadvantages
Forward engineering (code generation) Initial training and education
Reverse engineering of existing code Maintenance of the model over time
Support for changing levels of abstraction (from requirements to analysis to design to code) Upgrade and maintenance fees
Testing of the consistency and validity of your models Time lost over-using the tool (making diagrams look pretty, extraneous information)
Synchronization of models with delivered code. Increased effort to synchronize models with other artifacts (source code)
Support or different views and/or potential solutions to a problem CASE tools often promote syntax over communication between developers
Generation of documentation Generated code often too simplistic or cluttered with extraneous information
  Poor user interfaces often hamper the modeling effort
  Inadequate integration with other tools reduces productivity

>Top 11. Agile work places:

  • Agile Modeling room:
    • Dedicated space
    • significant whiteboard space
    • Digital camera
    • Modeling supplies
    • A bookshelf or storage cabinet
    • Large table
    • Computer
    • Chairs
    • Wall space to attach paper
    • Reference books
    • Food
    • Toys
  • Effective work areas
  • Making this work in the real world.
    • Communicate the importance of having an effective workspace to senior management
    • Communicate the importance of having an effective workspace in the team
    • Get rid of the headphones
    • Allow people to keep their former office.
    • Provide private areas.

11. アジャイルな作業場所:.

  • アジャイルモデリングルーム
    • 専用のスペース
    • ホワイトボー用のかなり広いスペース
    • デジタルカメラ
    • モデリング用の道具
    • 本箱または保管棚
    • 大きなテーブル
    • コンピュータ
    • 椅子
    • 紙を貼る壁面
    • プロジェクター
    • 参考書
    • 食べ物
    • 玩具
  • 効果的な作業場所
  • 現実世界で役立てる
    • 効果的な作業場所の重要性を幹部と話し合う。
    • チーム員と効果的な作業場所の重要性を話し合う。
    • ヘッドホンを外す。
    • 以前のオフィスを維持することを許容する。
    • プライベートな場所を残す。

>Top 12. Agile Modeling team:

  • There is no 'I' in 'agile.' To build an effective development team:
    • Recruit a few good developers.
      • Team player, Communicative, Practical, Inquisitive, Skeptical, Realistic, Courageous, Experimental
      • Disciplined
  • Generalists or specialists?
    • Neither extreme works well. One approach is to build a team with some generalist and some specialists; the generalists provide the glue within the team and focus on the bigger picture whereas the specialists focus on the detailed complexities of your project.
  • Recognize that here is no 'I' in agile.
    • AM's values of humility and feedback are critical factors promoting effective teamwork and communication. There is no 'I' in team, and my experience is that there is no 'I' in agile either.
  • Require that everyone actively participates modeling in teams.
    • Why is it important to build an effective team? Because modeling is best done by groups of people, not individuals.
    • Development pair
      Pair development results in greater consistency, efficiency, quality and job satisfaction among developers.
    • Small impromptu/ad-hoc team
      An impromptu/ad-hoc modeling team is one that is put together quickly, often in a matter of seconds, to address a specific issue. Once the team has addressed the issue, it just as quickly disbands.
    • Designated team

12. AMのチーム:

  • 効果的な開発チームを作るには
    • 少数の優秀な開発者を集める。
      • チームプレイ会話上手実務的好奇心旺盛懐疑的現実的勇敢実験好き
      • 規律性
    ゼネラリストかスペシャリストか？
    • 極端はうまく行かない。一案としては、何人かのゼネラリストと何人かのスペシャリストを組み合わせる。ゼネラリストはチーム内の接着剤となり全体像を注視し、スペシャリストはプロジェクトの詳細で複雑な部分に注力する。
  • アジャイルには立場の違いはない。
    • AMの謙虚さやフィードバックの価値は、効果的なチームワークやコミュニケーションを実施する上で不可欠である。
  • 全員が積極的に参加しなければならないチームでモデリングする
    • なぜ効果的チームが必要か？それはモデリングは個人ではなく、グループとして行うことが最適だからである。
    • 開発ペア
      ペア開発によって一貫性と効率と品質が向上し、仕事に対する開発者の満足感も大きくなる。
    • 小さな即興・臨時チーム
      即興・臨時モデリングチームは特定問題に対応するために素早く招集されるチームである。その問題への対応が終了すると、チームはすぐに解散する。
    • 指名チーム

>Top 13. Agile Modeling sessions:

  • A modeling session is an activity where several people focus on the development of one or more models. Modeling sessions are important to collaborate together in order to communicate their needs, to come to a better understanding, and ideally to work toward a solution.
  • Modeling session duration:
    • Majority of the sessions last between 10 -30 minutes. Prefer stand-up modeling sessions around a whiteboard or table because most people are only willing to stand up for short period.When the session go longer people will star to feel uneasy about it.Keep the modeling session focused on a singe topic.
    • Stop modeling once you've fulfilled your goal (Model with a purpose)
  • 　Type of modeling sessions:
    • Never have single artifact modeling sessions, even if your intention is to work on several artifact at once.
    • The best approach is simply to hold agile modeling sessions. Agile software development is highly iterative, particularly in a day-to-day basis, where it is quite common to identify a requirement, analyses it, and propose a potential design strategy within minutes.
  • Participants in modeling sessions:
    • Facilitator:
      Facilitators have good meeting skills, understand the modeling process, and ask valid, intelligent questions to elicit information from the active participants. Scribe:
      Scribe need good listening skills, good oral communication skills, and they have an ear for business logic and technical details.
    • Observer:
      A more agile approach is to put observes to work, as active participants if they have domain knowledge or modeling skills or worst case as scribes.
    • There are diminishing rates of return once you've reached groups of 7 or 8 people - there is less of a chance that a new person will bring new information to the group.
  • The formality of modeling sessions
    • Modeling session style: Informal (ad hoc)
      • smaller, co-located groups. People are readily available, willing, and able to participate. Shorter modeling sessions (less than 1 hour)
      • Time-to-market a critical factor for your project.

13. AMのセッション:

  • AMのセッションとは、１つ以上のモデルを対象に複数人で集中的に作業を行うこと。自分達のニースを話し合ったり、よく理解したり、理想的には解決に向かって互いに協力する機会を提供する。
  • モデリングセッションの長さ:
    • 大半のセッションは10-30分ホワイトボードや机の周りでの立ちモデリング長時間のモデリングセッションは居心地悪い１つの話題に限定してモデリングセッションを開催する。
    • 目的を達したらモデリングを終了 (目的をもったモデリング)
  • モデリングセッションの種類:
    • 単一成果物モデリングセッションは避けるべき。たとえ複数の成果物の作業を行うつもりであったとしても。
    • 最善のアプローチは、複数のAMセッションを開催すること。アジャイルなソフト開発は反復的であり、日々作業を行き来するので、数分間で要求事項を特定し、分析し＿・、設計戦略を提案することもしばしばである。
  • モデリングセッションへの参加者:
    • 司会者:
      会議を運営するスキル、モデリングプロセスの理解、参加者からの情報引き出すための巧みな質問能力書記:
      話を聴くスキル、コミュニケーション能力、ビジネスロジックや技術の詳細を聞く
    • オブザーバ:
      アジャイルなアプローチでは、オブザーバーにもドメインナレッジがあれば積極的な参加者として、あるいはモデリングスキルや最悪書記として機能させる。
    • 7- 8名を超えると追加の参加者は新たな情報をもたらさない。
  • モデリングセッションの形式:
    • モデリングセッション（非公式)
      • 小グループ、同じ場所勤務参加意思あり、参加可能より短時間セッション (1時間以内)
      • 早期納品が重要
  • Critical points regarding agile documentation:

>Top 14. Agile documentation:

  • From AM's point of view, a document is any artifact external to source code whose purpose is to convey information in a persistent manner.
    • A model is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem.
    • Some models will become documents, or be included as a part of them.
    • Some models will be used to drive the development of source code, although some models may simply be used to drive the development of other models.
    • Source code is a sequence of instruction, including the comments describing those instructions.
    • Although source code is clearly an abstraction, within the scope of AM it will not be considered a model.
    • The term documentation includes both documents and comments in source code.
  • Why do people document?
    1. Your project stakeholders require
    2. To define a contract model
    3. To support communication with an external group
    4. To think something through
    5. The requester wants to be seen to be in control
    6. The requester wants to justify their existence
    7. The requester doesn't know any better
    8. Your process says to create the document
    9. Someone wants reassurance that everything is okay
    10. You're specifying work for another group
    11. Your development contracts are routinely subject to re-competition.

14. アジャイルなドキュメント:

  • AMの観点からは、ドキュメントは、保存に耐える方法で情報を伝えるための成果物である。但しソースコードは含まれない。
    • モデルは一つ以上の問題点、または問題の解決策を抽象的に記述したものである。
    • あるモデルはドキュメントになるか、またはその一部として含まれる。
    • あるモデルはソースコードを開発するために利用される。一部のモデルは単に他のモデルを開発するためだけに使われるが。
    • ソースコードは一連の命令であり、それらの命令を記述したコメントを含む。
    • ソースコードは明らかに抽象的に記述されるが、AMの観点では、ソースコードはモデルとはみなさない。
    • ドキュメンテーションの用語にはドキュメントとソースコード中のコメントを含む。
  • なぜドキュメントを作成するのか:
    1. ステイクホルダの要求
    2. 契約モデルを定義するため
    3. 外部グループとのコミュニケーションのため
    4. 何かを熟慮するため
    5. 文書管理者が、管理していること示すため
    6. 文書管理者が自分の存在を正当化するため
    7. 文書管理者は他によい方法を知らない
    8. プロセスが文書作成を要求している
    9. すべて順調という確信を望んでいる
    10. 別のグループのために作業を記述する
    11. 開発契約は常に再び競争の対象となる

>Top When does a model become permanent?

  • A UML state chart that depicts the lifecycle of an agile model:
  • model_UML
    • Models are not always documents; Many models are temporary in nature. Furthermore, documents aren't always models.
    • The concepts of model and document are orthogonal because you can clearly have one without the other. Acceptance of this idea is an important step toward becoming more agile.
    • The benefit provided by the model is far less than the burden of maintaining it.
  • Temporary models can be long lived:
    • Just because a model is temporary　 doesn't mean that you discard it immediately. Temporary models should be discarded once they are no longer needed.
  • What are the trade-offs associated with documentation?:
    • Software development vs. documentation development:
    • Software developers have the knowledge; technical writers have the skill:
    • What is required during development is often different than what is required after development:
    • Willingness to write documentation vs. willingness to read it:
      • RTFM (Read the fucking manual)
    • Do you document as you work or when you are finished?:
      • An effective middle ground is to take notes of important decisions that you make, often something you can do in your source code, and to retain copies of the critical diagrams and models that you create during development.
    • Internal vs. external documentation:
    • Project-level vs. enterprise-level documentation:
    • Quantity vs. quality:
      • What would you rather have 2000-page detailed system document or 20 page high-level overview?
      • You'd be more likely to trust this document because it's shorter, worst case you could easily update or simply rewrite it if you found it to be grossly inaccurate.
  • What does it mean to travel light?
    • You create just enough models and just enough documentation to get by.
    • A good rule of thumb is that you shouldn't create a model or document until you actually need it.
    • Imagine crossing a desert with insufficient water; you're traveling too light.
    • You fail again because you7re traveling so heavy that you cannot respond quickly to change in the marketplace.
  • When is a document agile?
    • Agile documents maximize stakeholder investment.
    • Agile documents are 'lean and mean.'
    • Agile documents describe information that is less likely to change.
    • Agile documents describe 'good thins to know.'
    • Agile documents describe 'good things to know.'
    • Agile documents are sufficiently accurate, consistent, and detailed.
    • Agile documents are sufficiently indexed.

いつモデルは保管用になるか:

  • アジャイル・モデルのライフサイクルを占めるUMLステートチャート：<左図>
    • モデルは文書とは限らない。多くのモデルは一時的なものである。また文書はモデルではない。
    • モデルと文書の概念は対極的であって、一方だけで存在できる。このアイデアを取り入れることはアジャイルになる重要な一歩となる。
    • モデルによる便益は、それを残す負担よりもずっと小さい。
  • 一時的なモデルも長期間利用することもある。
    • 一時的なモデルといってもすぐ破棄されるものでもない。一時的なモデルは必要なくなってから廃棄すべし。
  • ドキュメントに関するトレードオフとは:
    • ソフト開発とドキュメント作成
    • 知識のあるソフト開発者とスキルのあるテクニカルライター
    • 開発中に必要なものと開発後に必要となるものとは異なる。
    • ドキュメントを書きたがるか読みたがるか
      • RTFM: マニュアル位は読め！
    • 作業中に書くか、終了後書くか:
      • 効果的な方法は、重要な決定事項についてメモを取り（大抵はソースコードにコメントを書いておく）開発中に作成した重要な図やモデルのコピーを保存しておく。
    • コード内ドキュメントとコード外ドキュメント
    • プロジェクトレベルドキュメントと全社レベルドキュメント
    • 量と質
      • 2000頁の詳細システムドキュメントと20頁の高レベルの概要書とどちらかよいか
      • 短いドキュメントの方が、おそらく信頼できる。最悪の場合でも、不正確であれば更新したり全面書き直しができる。
  • 身軽な旅とは:
    • 何とかやっていくために、必要なだけのモデルとドキュメントを作成する。
    • 経験則で言えば、実際に必要になるまでモデルやドキュメントを作らない。
    • 水を十分持たずに砂漠を横切るのでは、身軽すぎる。
    • 旅の荷物が重すぎても、市場の変化にすぐに反応できなくて失敗する。
  • ドキュメントがアジャイルな時は？
    • ステイクホルダの投資を最大化している。
    • 引き締まった節約型
    • 変化の可能性の低い情報を書く
    • 知っておくべき事項を書く
    • そこそこ正確で一貫性があり詳細である
    • 十分な索引がついている
  • >Top Potential documents created by your development team:
document Audience Description Advice 文書
Contract models Other teams technical interface to a system or portion of a system may already be in place for existing systems 契約モデル
Design decisions Developers,
Maintenance-developer, Project manager 		critical designs pertaining to design and architecture focus on decision that are not obvious; the goal is to avoid needless refactoring in the future 設計決定書
Executive overview

Senior management,
User management,
Project manager

vision for the system, current cost estimates, predicted benefits, risks, staffing estimates, and scheduled milestone used to gain funding and support ;have the courage to make this publicly available 経営向け概要説明書
Operations documentation Operations staff interaction with other systems, databases, and files; backup procedures; contact points for your system; availability/reliability requirements; expected load profile of your system; troubleshooting guidelines operations department often has a standard format or good examples from other systems 運用文書
Project overview Developers, Managers, Maintenance-developer, Operations staff vision for the system, primary users contracts, technologies and tools, critical operation processes; source code (project name in the source code control system is often sufficient), permanent models pertaining to the system, where other documents are typically crate and maintain this during development; keep it short and to the point; starting point for anyone new to the team プロジェクト概要
Requirements document Developer,
Maintenance-developer, Users,
User-managers 		what the system will do, summarizing requirements artifacts such as business rule definitions, user cases, user stories, or essential user interface prototypes XP projects typically favor low-tech requirements; RUP projects tend toward more formal requirements. 要求文書
Support documentation Support staff training materials specific to support staff; user reference when solving problems, trouble-shooting guide, escalation procedures for handling difficult problems, contact points within the maintenance team support department often has a standard escalation procedure in place. サポート文書
System documentation Maintenance-developer, Developers overviews of the system; technical architecture, business architecture, high-level requirements for the system system documentation helps to reduce perceived risk on the project by providing truck insurance. システム文書
User documentation Users,
User-managers 		reference manual, usage guide, support guide, training materials; quick lookups should be considered part of the user interface for your system and should undergo usability testing ユーザ文書
  • >Top Critical points regarding agile documentation:

1

 The fundamental issue is effective communication, not documentation. ドキュメントよりコミュニケーション
2 Documentation should be 'lean and mean.' スリムなドキュメント心掛けよ
3 Travel as light as you possibly can. 身軽な旅にしかず
4 Documentation should be just good enough. 必要十分なドキュメントたるべし
5 Models are not necessarily documents, and documents are not necessarily models. モデルとドキュメントは別物
6 Documentation is as much a part of the system as the source code. ドキュメントはシステムの一部
7 Your team's primary goal is to develop software, its secondary goal is to enable your next effort. システム開発第一、次の作業への備え第二
8 The benefit of having documentation must be greater than the cost of creating and maintaining it. ドキュメントは手間暇以上の価値あってこそ
9 Never trust the documentation ドキュメントは疑ってかかれ
10 Each system has its own unique documentation needs; one size does not fit all. システム毎にドキュメントニーズは異なる
11 Ask whether you need the documentation, and why you believe you need the documentation, not whether you want it. ドキュメントはなぜ必要か問うべき
12 The investment is system documentation is a business decision, not a technical one. ドキュメントへの投資はビジネス判断
13 Create documentation only when you need it - Don't create documentation for the sake of documentation. ドキュメントのためにドキュメント作るな
14 Update documentation only when it hurts. 困った時のみ更新せよ
15 The customer, not the developer, determines whether documentation is sufficient. ドキュメントが十分かどうかは顧客が決める
Documentation should be 'lean and mean.' スリムなドキュメント心掛けよ Travel as light as you possibly can. 身軽な旅にしかず Documentation should be just good enough. 必要十分なドキュメントたるべし Models are not necessarily documents, and documents are not necessarily models. モデルとドキュメントは別物 Documentation is as much a part of the system as the source code. ドキュメントはシステムの一部 Your team's primary goal is to develop software, its secondary goal is to enable your next effort. システム開発第一、次の作業への備え第二 The benefit of having documentation must be greater than the cost of creating and maintaining it. ドキュメントは手間暇以上の価値あってこそ Never trust the documentation ドキュメントは疑ってかかれ Each system has its own unique documentation needs; one size does not fit all. システム毎にドキュメントニーズは異なる Ask whether you need the documentation, and why you believe you need the documentation, not whether you want it. ドキュメントはなぜ必要か問うべき The investment is system documentation is a business decision, not a technical one. ドキュメントへの投資はビジネス判断 Create documentation only when you need it - Don't create documentation for the sake of documentation. ドキュメントのためにドキュメント作るな Update documentation only when it hurts. 困った時のみ更新せよ The customer, not the developer, determines whether documentation is sufficient. ドキュメントが十分かどうかは顧客が決める

1

 The fundamental issue is effective communication, not documentation. ドキュメントよりコミュニケーション
2
3
4
5
6
7
8
9
10
11
12
13
14
15

>Top 15. Adopting AM or overcoming adversity:

  • Overcome organizational and cultural challenges:
    There are very common organizational and cultural challenges that you may run into:
  • Skeptical developers:
    • A little bit skepticism is health. However, too much skepticism will often hinder you ability as a software professional.
    1. I've seen this before:
      What is new about AM is the packaging of these principles and practices into a chaordic, synergistic methodology.
    2. It's just another fad.
      AM works well in practice with leading methodologies, particularly XP and UP, and is fact enhances them.
    3. It's not software engineering.
      The real issue isn't whether AM is software engineering or not, it's whether AM offers the potential to improve your productivity as a software developer.
    4. It's no proven.
      This skepticism, like the software engineering issue, is a red herring. This is simply a convenient excuse to not try something new.
  • Overzealous process police:
    • ISO 990x and CMM process are often prescriptive and very well documented.
    • inspections to ensure following the process (=process police) : Instead of considering new ways of doing things, they instead declare that you many not follow AM practices.
  • Paper pushers with power:
    • The paper pushers that simply required documents or that scheduled review meetings ware of little value and often a great hindrance.
  • Cookbook philosophy:
    • This idea is that if your organization had a well-defined software process in place that prescribed in excruciating detail the steps for each development activity, then all you IT problems would be solved.
  • >Top Inability to accept blame:
    • The common process-related mistakes:
      • Right process, wrong situation
      • Right name, wrong process
      • Right process, wrong instantiation
  • Excessive documentation due to fear of losing everyone:
    • This becomes a self-fulfilling prophecy. You force your developers to write excessive amounts of documentation because you fear they'll leave, and then they decide to leave because of your organizational bureaucracy, lack of trust in them, and lack of focus on software development.
  • Fixed-price contracts:
    • Project managers will often refer to the 'iron triangle' of planning - cost, scope, and quality. You can only fix two of these three aspects of your project.
    • Through Quality Work principle, the implication is that that you need to be flexible on scope, the amount of functionality that you can deliver for that fixed amount of money. Towards a less-dysfunctional situation:
      • a ranged estimate; plus or minus
      • a series of smaller phases or iterations
      • basic plus bonus for meeting performance

15. AMの採用あるいは逆境の克服:

  • 組織的・文化的問題の克服:
    以下のような組織的、文化的な問題がある。
  • 懐疑的な開発者:
    • 若干の懐疑心は健全だが、度を過ぎた懐疑心は、ソフトの専門家としての能力が損なわれる。
    1. 以前にも見たことがある
      AMの新規性は、これらの幻想と実践をカオス秩序的に、相乗効果の方法論にまとめたことである。
    2. これもただの流行である
      実際にAMは、XPやUPといった主な方法論と融合し、その効果を高めている。
    3. ソフトウェア工学ではない
      問題は、AMを使うことでソフト開発の生産性が向上する可能性があるかどうかである。
    4. 実証されていない
      このような懐疑論は、ソフトウェア工学問題と同様に、注意をそらすものでしかなく、新しいことを試みないための便利な方便
  • 熱心過ぎるプロセス警察
    • ISO 900xやCMMは、きっちり定義され、非常に明確に文書化している。
    • これを確認するための検査の仕事(＝プロセス警察) は、物事を行う新たな方法を考慮する代わりに、AMのプラクティスに従ってはならないと宣言する。
  • 権力をもった文書化推進者:
    • 単に文書を要求したり、レビュー会議の予定を立てるだけの文書化推進者は、殆ど無価値で大きな障害となる。
  • ガイドブック哲学:
    • これは、組織において全ての開発作業ステップがきっちり定められたソフトウェアプロセスを定義しておけは、ITのあらゆる問題が解決されるはずだというもの。
  • 非難を受け入れられない:
    • よくある間違い
      • プロセスは正しいが、状況に合わない
      • 名目は正しいが、プロセスが間違っている
      • プロセスは正しいが、実施方法が間違っている
  • 全員失うことを恐れての過剰な文書化:
    • これはやぶへび効果。開発に過剰の文書化を強要するのは、開発者に去られてことを恐れてのことだが、その結果、開発者は、組織の官僚主義と信頼性のなさ、そしてソフト開発への注力欠如を理由に去ってしまう。
  • 固定価格契約:
    • プロジェクトでは、費用・範囲・品質を鉄の三角形をいう。この３つの側面の内、２つしか固定することはできない。
    • 固定契約では、品質が固定されれば、範囲、つまり固定金額で納品できる機能の量に柔軟性を持たせる必要がでてくる。少しでも機能不全とならないための案は
      • 変動幅見積
      • フェーズ分け見積
      • 基本料プラスボーナス条項

>Top 16. Glossary of definitions and abbreviations:

  1. AM: Agile Modeling
    A chaordic, practice-based methodology for effectively modeling software-based system.
  2. Agile modeling session:
    A modeling session where you follow the principles, and apply the practice of AM.
  3. Analysis modeling session:
    A modeling session where your focus is on fleshing out the requirements for your system.
  4. Analysis paralysis:
    The fear of moving forward until your models are perfect.
  5. Architecture modeling session:
    A modeling session where your focus is on identifying a high-level strategy for how your system will be built.
  6. Architecture spike:
    An XP concept that refers to just enough code to show that a candidate architecture will work.
  7. Artifact: A deliverable or work product
  8. BDUF: Big Design Up Front
  9. Cardinality:
    Represents the concept 'how many?' in associations.
  10. >Top C&CM: Configuration and Change Management
  11. Change case:
    An artifact used to describe a potential requirement for a system or a potential modification to existing requirement.
  12. Chaordic:
    The behavior of a self-governing organism, organization, or system that harmoniously blends chaos and order.
  13. Class diagram:
    A UML diagram that depicts classes, their static inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of those classes.
  14. CRC (Class Responsibility Collaborator) card:
    A standard index card that has been divided into three sections, one indicating the name of the class that the card represents, one listing the responsibilities of the class, and the third listing the names of the other classes that this one collaborates with to fulfill its responsibilities.
  15. Connascence:
    Between two software elements, A and B, the property by which a change in A would require a change to B to preserve overall correctness within your system.
  16. Contract model:
    A model that defines an agreement between two or more parties. A contract model is something that the parties should mutually agree to and mutually change over time if required. Contract models are often required when an external group controls an information resource that your system requires, such as a database, legacy application, or information service.
  17. CORBA: Common Object Request Broker Architecture
  18. CIT: Core Infrastructure Team
    Any team with an enterprise-wide scope whose mission is to support development teams.
  19. Context diagram
    A diagram that shows how your system fits into its overall environment. It is common to develop high-level data flow diagrams or deployment diagrams for this.
  20. >Top COTS: Commercial off-the-shelf
  21. DDL: Data Definition Language
    Commands supported by a database that enable the creation, removal, or modification of structures (such as relational tables or classes) within it.
  22. DFD: Data-Flow Diagram
    A diagram that shows the movement of data between processes, entities, and data stores within a system
  23. Death march:
    A doomed software project, without any apparent hope of success, where the developers carry on anyway.
  24. DML: Data manipulation language
    Commands supported by a database that enable the access of data within it, including the creation, retrieval, update, and deletion of that data.
  25. Documentation:
    Persistent information written for people that describes a system including both documents and comments in source code.
  26. DSDM: Dynamic Systems Development Method
  27. Evil wizard:
    A code generator that produces code that you do not understand.
  28. Facilitator:
    Someone responsible for planning, running, and managing modeling sessions.
  29. FDD: Feature -Driven Development
  30. Gold owner: The person or organization that funds your project
  31. Hardware node:
    A computer, switch, printer, or other hardware device.
  32. Information radiator:
    A display of information posted on the wall where passers by can see it.
  33. Iron Triangle:
    A planning concept that you can only fix two of three aspects - cost, scope, and quality - on your project.
  34. IRUF: Initial Requirements up front
  35. Iterate:
    To move on to the next step/task, often in a repetitions manner, taking small steps each time.
  36. Ivory tower architecture:
    An architecture developed in isolation from the developers, or teams of developers, responsible for following it.
  37. MDA: Model Document Architecture
    Part of the OMG's vision to support interoperability with specification, defining the relationships among OMG standards and how they can be used together in a coordinated manner.
  38. OOA&D: Object-oriented analysis and design
  39. Osmotic communication:
    Indirect information transfer through overhearing conversations or simply noticing things that happen around you.
  40. >Top PIM: Platform Independent Model:
    A type of MDA model that specifies a system in a manner that abstracts away technical details.
  41. PIG: Process Improvement Group (the pun is intended)
  42. Project Stakeholder:
    A direct user, indirect user, manager, senior manger, operations staff member, support staff member, testers, developers working on other systems that integrate or interact with this one, or maintenance professionals potentially affected by the development and/or deployment of a software project.
  43. PSM: Platform Specific Model:
    A type of MDA model that realizes a portion, one, or several PIM to take into account technical considerations.
  44. Requirements modeling session:
    A modeling session where your focus is on defining what your project stakeholders want your system to do.
  45. Reverse engineering:
    The generation of a model based on the information contained in source code.
  46. Scaffolding:
    Additional code, including both operations and attributes, required to make your design work.
  47. Scribe:
    A person responsible for recording information during a modeling session.
  48. Simple tools:
    Manual item that you use to model systems, including flipchart paper, sticky notes, paper napkins, sheet paper, string, thumb tacks, whiteboards, and index cards.
  49. SPI: Software Process Improvement
  50. >Top SRS: Software Requirements Specification
  51. Trigger:
    An operation that is automatically invoked as the result of data manipulation language (DML) activity within a database.
  52. Truck insurance:
    The assurance that if the development team leaves, or gets hit by a truck, that critical information about the project is left behind in the form of documentation.
  53. Truck number:
    An estimate of the minimum number of people you would need to lose from your team before you find yourself in trouble (for example, the number of people that would need to be hit by a truck).
  54. UML: Unified Modeling Language
  55. Usage scenario:
    A description of a single path of logic through one or more use cases or user stories.
  56. Use case:
    A sequence of actions that provide a measurable value to an actor.
  57. Zero-Feature Release (ZFR)

16. 用語集：その定義と略語:

  1. アジャイル・モデリング:
    ソフトベースのシステムを効果的に設計するためのカオス秩序的かつ実践的な方法論
  2. アジャイル・モデリング・セッション:
    AMを、原則に基づき実践する設計作業
  3. 分析設計セッション:
    システム要求を肉付けするためのモデリング作業
  4. 分析症:
    モデリングが完璧になるまで前へ進めない恐怖症
  5. アーキテクチャ・モデリング・セッション:
    システムとどう構築するかハイレベルのskrを決定するためのモデリング作業
  6. アーキテクチャ・スパイク:
    XPの概念で、対象のアーキテクチャが機能することを示すに最低十分であることを示す
  7. 成果物: 納入される作品
  8. BDUF: 先行して沢山の設計をすること
  9. 濃度:
    どの位の概念を示す
  10. 構成・変更管理:
  11. チェンジ・ケース:
    システムに対する要求可能性または既存の要求に対する変更可能性を記述した成果物
  12. カオス秩序的:
    カオスと秩序とを調和的にブレンドした自律組織や組織体やシステムの振る舞い
  13. クラス・ダイアグラム:
    クラスを記述したUMLのダイアグラムで、静的な内部関係 (継承、集団、関連)、およびそれらのクラスの作用や性質を記述する。
  14. インデックスカードを３つに区切り: １つ目はクラス名、２つ目はそのクラスの責務、3つめはコラボレーションする他のクラスの一覧表を記述する。
  15. コネッセンス: ２つのソフトウェア要素AとBについては、Aを変更することによってシステムを正常に維持するには、Bの変更が必要となる特徴のこと
  16. 契約モデル:
    2人以上の当事者間の契約を定義するモデル。契約モデルは、時間経過に伴い、必要に応じて、当事者間で相互に合意し、変更するようなもの。契約モデルは、システムが要求する情報源 (データベース、レガシー・アプリケーション、情報サービス）を管理する外部グループによってしばしば変更される。
  17. CORBA: OMGが定めた分散オブジェクト技術の仕様
  18. CIT: 開発チームを全社的観点でもって支えるチーム
  19. コンテクスト・ダイヤグラム:
    システムが全般的な環境にどれほど適合しているかしめる図。ハイレベルのデータフロー図やこのための配置図を開発するのが通常
  20. 市販の製品 (COTS)
  21. データ定義言語 (DDL):
    データベース内の構造の創成、移動、修正 (リレーショナルテーブルやクラス)を行う命令
  22. データフローダイアグラム (DFD):
    システム内のプロセス、エンティティ、データストア間のデータの動きを示す
  23. 死の行軍:
    開発が続けても成功の望みがないと運命づけられたソフトウェアプロジェクト
  24. データ操作言語 (DML):
    データの創成、検索、変更、削除などデータアクセスを可能にするデータベース用の命令
  25. ドキュメンテーション:
    文書とソースコード内のコメントを含むシステムを人間のために記述した永続的な情報
  26. DSDM: 動的システム開発メソッド
  27. 悪魔のウイザード:理解不能なコードを生成するコードジェネレータ
  28. ファシリテータ:
  29. 特徴ドリブン開発 (FDD)
  30. ゴールドオーナー:
    プロジェクトに資金提供する個人や組織
  31. ハードウェアノード:
    コンピュータ、スイッチ、プリンター、あるいは他のハードデバイス
  32. 情報ラジエータ:
    誰にでも見られるように壁に張り出した情報表示
  33. 鉄の三角形:
    ３つの内２つしか固定することができない計画概念、即ちプロセスのコスト、範囲、品質の３つである。
  34. 先行的な初期要求事項
  35. 繰り返す:
    毎回少しづつ繰り返しの方法で次ぎのステップやタスクを続けること
  36. 象牙の塔アーキテクチャ:
    開発者やそれを続ける責任チームから孤立して開発するアーキテクチャ
  37. モデルドキュメントアーキテクチャ (MDA):
    仕様に基づく相互運用性をサポートするOMG構想の一部。OMG標準の間の関係と、どのように協調させるべきかを定義
  38. オブジェクト指向分析と設計 (OO&D)
  39. 浸透圧的コミュニケーション:
    会話を漏れ聞いたり、周囲の雰囲気に注目することによる間接的な情報伝達
  40. プラットフォーム非依存のモデル (PIM):
    技術的な詳細を抽象化をすることでシステムを記述したMDAモデルの一つで、OMG標準間の関係やそれらを協調させる方法を定義したもの
  41. プロセス改良グループ (PIG): ダジャレ表現
  42. プロジェクト・ステイクホルダ:
    直接・間接のユーザ、マネジャ、シニアマネジャ、オペレーション担当メンバ、サポート担当メンバ、テスト担当、他システムの関連でこのシステムとの連携に関与する人、保守専門員でソフトウェアプロジェクト開発に影響受ける人
  43. プラットフォーム固有モデル (PSM):
    MDAモデルの一つで、技術的な事柄を考慮して一つあるいは数個のPIMを実現する。
  44. 要求モデリングセッション:
    モデリングのセッションで、ステイクホルダがシステムに何を要求しているのかを定義することに焦点を合わせた会議
  45. リバース・エンジニアリング:
    ソースコードの情報を元にモデルを生成すること。
  46. 足場:
    追加のコードで、設計を動かすために必要なオペレーションや属性を含む。
  47. 書記:
    モデリング・セッションの間、情報を記録する責任者
  48. シンプルな道具:
    モデルシステムに仕様される手作業の道具。フリップチャート、付箋、紙ナプキン、定型紙、ひも、画鋲、ホワイトボード、カードなど。
  49. ソフトウェア・プロセス改善 (SPI)
  50. ソフトウェア要求仕様 (SRS)
  51. トリガー:
    データベース内のDMLの働きの結果、自動的に引き起こされるオペレーション
  52. トラック保険:
    開発チームが解散したり、トラックにはねられたりした場合、プロジェクトの重要情報がドキュメントの形で残存している保証
  53. トラック数:
    トラブルとなる以前に、チームが失ってもよい最少人員の予測数 (トラックにはねられてもよい人数)
  54. ユニファイド・モデリング言語 (UML)
  55. ユーセッジ・シナリオ:
    一つ以上のユースケースやユーザのストー李を通じての論理の一本道の記述
  56. ユースケース:
    動作主体に対して測定可能名価値を提供するアクションの連続
  57. ゼロ機能リリース (ZFR)
Comment
  • >Top Agile Modeling seems applicable to almost all human activities.
  • Particularly, Japan must learn lots of suggestions, not only for technical fields, from this Agile Modeling.
  • We are limited in cost, scope, and quality: we are limited in money, life length, and time and energy. Therefore we must cope with chaordic environment.
  • アジャイル・モデリングはほとんどすべての人の活動に応用できるように思える。
  • 特に、日本にとっては、技術に限らず、このアジャイルモデリングから学ぶものは多い。
  • 我々はコスト、範囲、品質に限りがある。我々は資金も寿命も時間もエネルギーも限界がある。それ故、カオス秩序的な環境に向かっていかなければならない。

| Top | Home | Article | Bookshelf | Keyword | Author | Oxymoron |