Agile Modeling

1
Agile Modeling

• Prepared by Pankaj Patel

2
What is Agile Modeling (AM)?

• A practice-based methodology for effective
  modeling and documentation of software-based
  systems.
• A collection of values, principles and practices
  for modeling software that can be applied on a
  software development project in an effective and
  light-weight manner.

3
The Goals of AM

• To put into practice, a collection of values,
  principles and practices pertaining to effective
  and light-weight modeling.
• To show how to apply modeling techniques on
  software projects taking an agile approach.
• To show how to model effectively on a Unified
  Process (UP) project, common instantiations of
  which include the Rational Unified Process (RUP)
  and the Enterprise Unified Process (EUP). 

4
The Scope of AM
Figure AM enhances other software processes.
5
AM Values

• The values of AM includes communication,
  simplicity, feedback, courage, and humility.
• Communication It is critical to have effective
  communication between development team as well as
  with and between all project stakeholders.
• Simplicity Models are critical for simplifying
  both software and the software process.

6
AM Values (Cont)

• Feedback Optimism is an occupational hazard of
  programming, feedback is the treatment. (Kent
  Back, Extreme Programming Explained )
• Courage Need to make important decisions and to
  change direction by either discarding or
  refactoring completed work when some decisions
  proved inadequate.

7
AM Values (Cont)

• Humility All people involved with the project
  have equal value and should be treated with
  respect.

8
AM Principles

• AM defines a collection of core and supplementary
  principles that when applied on a software
  development project set the stage for a
  collection of modeling practices.
• Core Principles are as follows
• Assume Simplicity Simplest solution is the best
  solution.
• Embrace Change Peoples understanding and
  requirements evolve over time.

9
AM Principles (Cont)

• Enabling The Next Effort Is Your Secondary Goal
  When you are playing the software development
  game your secondary goal is to setup to play the
  next game. (Alistair Cockburn,2002)
• Incremental Change Develop a small model, or
  perhaps a high-level model, and evolve it over
  time in an incremental manner.

10
AM Principles (Cont)

• Maximize Stakeholder Investment Developed
  software must meet the requirements of the
  project stakeholder since he is investing time,
  money, resources, etc.
• Model With A Purpose Identify a valid purpose
  for creating a model and audience for the model.

11
AM Principles (Cont)

• Multiple Models Need to use multiple models
  since each model describes a single aspect of
  your software.
• Rapid Feedback Work closely with customers to
  understand and analyze their requirements and to
  develop a user interface that meets their need
  and provide opportunities for rapid feedback.

12
AM Principles (Cont)

• Quality Work Nobody likes sloppy work.
• Software is your primary goal Produced software
  should meet the stakeholders need in effective
  manner.
• Travel Light Create just enough models and
  documentation to get by.

13
AM Principles (Cont)

• Supplementary principles are as follows
• Content is more important than representation
  Any given model can be represented by several
  ways.
• Everyone can learn from everyone else Have the
  humility to recognize that one can never master
  something.

14
AM Principles (Cont)

• Know your models Need to know the strengths and
  weaknesses of the multiple models to be effective
  in their use.
• Open and honest communication This enables
  people to make better decisions.
• Work with peoples instincts Instincts become
  sharper with the experience of software
  development.

15
AM Principles (Cont)

• Know your tools Know the features of the
  modeling tools for its effective use.
• Local Adaptation Adapt a specific approach to a
  project level as well as the individual level.

16
AM Practices

• AM defines a collection of core and supplementary
  practices, based on the principles of AM
• Core practices are as follows
• Active Stakeholder Participation Project success
  requires a significant level of involvement by
  project stakeholder.
• Apply the Right Artifact(s) Use the right tool
  for the job. (e.g. A UML activity diagram is
  useful for describing a business process).

17
AM Practices (Cont)

• Collective Ownership Everyone can work on any
  model or any artifact on the project, if they
  need to.
• Consider Testability Do not build software if no
  one can test it.
• Depict Models Simply Key features are sufficient
  to understand the model.

18
AM Practices (Cont)

• Create Simple Content Dont add any additional
  aspects to the model unless they are justifiable.
• Create Several Models in Parallel People are
  more productive when they work on several models
  simultaneously
• Model with others Dangerous to do it alone.

19
AM Practices (Cont)

• Display Models Publicly This supports open and
  honest communication since the current model is
  quickly accessible.
• Iterate to Another Artifact Start another
  artifact when got stuck doing one.
• Model in Small Increments model a little, code a
  little, test a little, then deliver a little.

20
AM Practices (Cont)

• Prove it with Code validate the model by writing
  a corresponding code.
• Use the Simplest Tools Vast majority of models
  can be depicted on papers or whiteboard.

21
AM Practices (Cont)

• Supplementary practices are as follows
• Apply modeling standards Developers should agree
  on a common set of modeling standards on a
  software project.
• Apply Patterns Gently Developers should
  consider easing into the application of a
  pattern, to apply it gently (Martin Fowler and
  Joshua Kerievsky, 2001).

22
AM Practices (Cont)

• Discard Temporary Models Models quickly become
  out of sync with the code and nothing wrong in
  discarding them.
• Formalize Contract Models Models are formalized
  when both parties agree to them and are ready to
  mutually change them over time if required.

23
AM Practices (Cont)

• Model to Communicate Need to create a contract
  model or to communicate with people external to
  the developing team.
• Model to Understand Explore the problem space,
  to identify and analyze the system requirements
  for the best potential solution that meets the
  requirements.

24
AM Practices (Cont)

• Reuse Existing Resources Take advantage of
  wealth of information be reusing the information
  (models and documentations).
• Update only When It Hurts Not having the model
  updated is more painful than the effort of
  updating it.

25
When is a Model Agile?

• If there is a such thing as agile modeling, then
  there are also agile models.
• Agile models are good enough when they exhibit
  the following criteria
• They fulfill their purpose and no more.
• They are understandable.
• They are sufficient accurate.

26
When is a Model Agile? (Cont)

• They are as simple as possible.
• They are sufficient consistent.
• They provide positive value.
• They are sufficiently detailed.

27
Agile Documentation

• A document is agile when it meets the following
  criteria
• Agile documents maximize stakeholder investment.
• Agile documents are lean and mean.
• Agile documents fulfill a purpose.
• Agile documents describe information that is less
  likely to change.
• Agile documents describe good things to know.

28
Agile Documentation (Cont)

• Agile documents have a specific customer and
  facilitate the work efforts of that customer.
• Agile documents are sufficiently accurate,
  consistent, and detailed.
• Agile documents are sufficiently indexed.

29
References

• Ambler, S. (2002). Agile Modeling, John Wiley
  Sons, Inc., New York.
• http//www.agilemodeling.com
• http//www.agiledata.org