Introduction to Agile Model Driven

Development (AMDD)

Scott W. Ambler
Senior Consultant, Ambysoft Inc.
www.ambysoft.com/scottAmbler.html

Copyright 2001-2005 Scott W. Ambler 1

About These Slides
 Some slides have notes
 You may use these slides, or a subset thereof, in presentations
or training materials
 You must indicate that the slide is Copyright Scott W. Ambler
2005
 You must not remove copyright notices from the diagrams
 You may not sell or license the material contained within this
file without the express permission of Scott W. Ambler
 Visit www.agilemodeling.com/essays/amddPresentation.htm for
updates

Copyright 2001-2005 Scott W. Ambler 2

 Agile Modeling (AM)
 AM is a chaordic, practices-based process for modeling
and documentation
 AM is a collection of practices based on several values
and proven software engineering principles
 AM is a light-weight approach for enhancing modeling
and documentation efforts for other software processes
such as XP and RUP
Principles and Practices of Other Techniques
Agile Modeling (AM) (e.g. Database refactoring)

A Base Software Process

(e.g. XP, RUP, DSDM, FDD, …)

Your Software Process

Copyright 2001-2005 Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler 3
 The Core of AM
You Need to Adopt at Least the Core
Core Principles Core Practices
 Assume Simplicity  Active Stakeholder Participation
 Embrace Change  Apply the Right Artifact(s)
 Enabling the Next Effort is Your  Collective Ownership
Secondary Goal  Create Several Models in Parallel
 Incremental Change
 Create Simple Content
 Model With a Purpose
 Depict Models Simply
 Multiple Models
 Display Models Publicly
 Maximize Stakeholder
 Iterate to Another Artifact
Investment
 Model in Small Increments
 Quality Work
 Model With Others
 Rapid Feedback
 Prove it With Code
 Software Is Your Primary Goal
 Single Source Information
 Travel Light
 Use the Simplest Tools

Copyright 2001-2005 Scott W. Ambler 4

Agile Model Driven Development (AMDD)
Project Level (www.agilemodeling.com/essays/amdd.htm)

Initial Requirements Initial Architectural

Modeling Modeling
(days) (days)

Cycle 0: Initial Modeling

Model Storming
(minutes)
Reviews
(optional)

All Cycles
(hours)

Implementation
(Ideally Test Driven)
(hours)

Cycle 1: Development
Cycle 2: Development
Copyright 2003-2005
Cycle n: Development Scott W. Ambler

Copyright 2001-2005 Scott W. Ambler 5

What Are Agile Models?
 Agile models:
 Fulfill their purpose Just Barely
Good Enough

 Are understandable Ideal Realistic

 Are sufficiently accurate

Value
 Are sufficiently consistent
 Are sufficiently detailed
 Provide positive value Effort

Are as simple as possible

Copyright 2005 Scott W. Ambler


 Agile models are just

barely enough!

Copyright 2001-2005 Scott W. Ambler 6

 Agile Models
www.agilemodeling.com/artifacts/
Usage Modeling
- Acceptance Tests
User Interface Development
- Essential Use Cases
- Features
- Essential User Interface Prototype
- System Use Cases
- User Interface Flow Diagram
- Usage scenario
- User Interface Prototype
- User Stories
- UML Use Case Diagram

Supplementary Requirements
Detailed Structural Modeling Modeling
- External Interface (EI) Specification - Business Rules
- Physical Data Model (PDM) - Conceptual Cases
- UML Class Diagram - Constraints
- UML Object Diagram - Glossary
- Technical Requirements

Dynamic Object Modeling

Conceptual Domain Modeling
- UML Communication Diagram
- Class Responsibility Collaborator (CRC) Cards
- UML Composite Structure Diagram
- Logical Data Model (LDM)
- UML Interaction Overview Diagram
- Object Role Model (ORM) Diagram
- UML Sequence Diagram
- Robustness Diagram
- UML State Machine Diagram
- UML Class Diagram
- UML Timing Diagram

Architectural Modeling
Process Modeling
- Change Cases
- Data Flow Diagram (DFD)
- Free Form Diagram
- Flow Chart
- Security Threat Modeling
- UML Activity Diagram
- UML Component Diagram
- Value Stream Map
- UML Deployment Diagram
- Workflow diagram Copyright 2003-2005
- UML Package Diagram
Scott W. Ambler

Copyright 2001-2005 Scott W. Ambler 7

Tests as Primary Artifacts
Reduce Documentation by Single Sourcing Information

 Acceptance tests are considered to be

primary requirements artifacts
 You can reduce your requirements documentation
dramatically by not recording the same
information twice
 Unit tests are considered to be detailed
design artifacts
 You can reduce your design documentation
dramatically and increase the chance that your
detailed design artifacts are kept up to date by
coders
 www.agilemodeling.com/essays/singleSourceInformation.htm

Copyright 2001-2005 Scott W. Ambler 8

 Agile Documentation
 Travel light – You need far less documentation than you think
 Agile documents:
 Maximize stakeholder investment
 Are concise
 Fulfill a purpose
 Describe information that is less likely to change
 Describe “good things to know”
 Have a specific customer and facilitate the work efforts of that customer
 Are sufficiently accurate, consistent, and detailed
 Are sufficiently indexed
 Valid reasons to document:
 Your project stakeholders require it
 To define a contract model
 To support communication with an external group
 To think something through
 www.agilemodeling.com/essays/agileDocumentation.htm

Copyright 2001-2005 Scott W. Ambler 9

Communication Modes
Always Strive to Use the Most Effective Approach

Face-to-face
at whiteboard
Face-to-face
conversation
Communication Effectiveness

Video
conversation
Modeling
Phone Options
conversation

Videotape
Email
conversation

Audiotape
Documentation
Options
Paper

Cold Hot
Richness of Communication Channel
Copyright 2002-2005 Scott W. Ambler
Original Diagram Copyright 2002 Alistair Cockburn

Copyright 2001-2005 Scott W. Ambler 10

 The Cost of Traditional BRUF
“Successful” Projects Still Have Significant Waste

Always
7%
Often
13%

Never
45%

Sometimes
16%

Rarely
19%

Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002

Copyright 2001-2005 Scott W. Ambler 11

Agile Software Requirements Management
Changing Requirements Are a Competitive Advantage if You Can Act
on Them: www.agilemodeling.com/essays/changeManagement.htm

High
{ Each iteration implement the highest-
Priority priority requirements

Each new requirement is

prioritized and added to
the stack

Requirements may be
reprioritized at any time

Requirements may be
removed at any time

Low
Priority
Requirements Copyright 2004 Scott W. Ambler

Copyright 2001-2005 Scott W. Ambler 12

Active Stakeholder Participation
The Stakeholders are the Experts, Shouldn’t They Model?

 Project stakeholders should:

 Provide information in a timely manner
 Make decisions in a timely manner
 Actively participate in business-oriented
modeling
 www.agilemodeling.com/essays/activeStakeholderParticipation.htm
 www.agilemodeling.com/essays/inclusiveModels.htm

Copyright 2001-2005 Scott W. Ambler 13

Model With Others
 The modeling equivalent of pair
programming
 You are fundamentally at risk whenever
someone works on something by
themselves
 Several heads are better than one

Copyright 2001-2005 Scott W. Ambler 14

 Active Stakeholder Participation
On-Site Customer

Joint Application Design (JAD)

Focus Groups
Observation
Face-To-Face Interviews

Effectiveness
of Electronic Interviews
Legacy Code Analysis
Requirements
Reading
Gathering
Collaborative Restricted
Techniques Interaction Interaction
Copyright 2005 Scott W. Ambler

Copyright 2001-2005 Scott W. Ambler 15

Relative Effectiveness of User
Representatives
Actual Stakeholder

Product Manager
Effectiveness

Business Analyst as User

Personas
Copyright 2005 Scott W. Ambler

Copyright 2001-2005 Scott W. Ambler 16

 References and
Recommended Reading
 Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP . New
York: John Wiley & Sons.
 Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons.
 Ambler, S.W. (2004). The Object Primer 3rd Edition: AMDD with UML 2. New York:
Cambridge University Press.
 Ambler, S.W. (2005). The Elements of UML 2.0 Style. New York: Cambridge
University Press.
 Beck, K. (2000). Extreme Programming Explained – Embrace Change . Reading,
MA: Addison Wesley Longman, Inc.
 Beck, K. & Fowler, M. (2001). Planning Extreme Programming. Reading, MA:
Addison Wesley Longman, Inc.
 Constantine, L.L. & Lockwood, L.A.D. (1999). Software For Use: A Practical Guide
to the Models and Methods of Usage-Centered Design . New York: ACM Press.
 Fowler, M. (1997). Analysis Patterns: Reusable Object Models. Menlo Park,
California: Addison Wesley Longman, Inc.
 Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide . Reading,
MA: Addison Wesley Longman, Inc.
 Palmer, S.R. & Felsing, J.M. (2002). A Practical Guide to Feature Driven
Development. Upper Saddle River, NJ: Prentice Hall PTR.

Copyright 2001-2005 Scott W. Ambler 17

Online Resources
www.agilemodeling.com

www.agilealliance.org

www.controlchaos.com

www.ambysoft.com

www.agiledata.org

www.enterpriseunifiedprocess.com

Copyright 2001-2005 Scott W. Ambler 18