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
Agile Modeling (AM)
Other Techniques
(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
Modeling
(days)
Initial Architectural
Modeling
(days)
Cycle 0: Initial Modeling
Model Storming
(minutes)
Reviews
(optional)
All Cycles
(hours)
Implementation
(Ideally Test Driven)
(hours)
Cycle 1: Development
Cycle 2: Development
Cycle n: Development
Copyright 2003-2005
Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler
5
What Are Agile Models?

Agile models:








Fulfill their purpose
Are understandable
Are sufficiently accurate
Are sufficiently consistent
Are sufficiently detailed
Provide positive value
Are as simple as possible
Just Barely
Good Enough
Ideal
Realistic
Value
Effort
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
- Essential Use Cases
- Features
- System Use Cases
- Usage scenario
- User Stories
- UML Use Case Diagram
User Interface Development
- Essential User Interface Prototype
- User Interface Flow Diagram
- User Interface Prototype
Supplementary Requirements
Modeling
Detailed Structural Modeling
- External Interface (EI) Specification
- Physical Data Model (PDM)
- UML Class Diagram
- UML Object Diagram
- Business Rules
- Conceptual Cases
- Constraints
- Glossary
- Technical Requirements
Dynamic Object Modeling
Conceptual Domain Modeling
- UML Communication Diagram
- UML Composite Structure Diagram
- UML Interaction Overview Diagram
- UML Sequence Diagram
- UML State Machine Diagram
- UML Timing Diagram
- Class Responsibility Collaborator (CRC) Cards
- Logical Data Model (LDM)
- Object Role Model (ORM) Diagram
- Robustness Diagram
- UML Class Diagram
Architectural Modeling
- Change Cases
- Free Form Diagram
- Security Threat Modeling
- UML Component Diagram
- UML Deployment Diagram
- UML Package Diagram
Process Modeling
- Data Flow Diagram (DFD)
- Flow Chart
- UML Activity Diagram
- Value Stream Map
- Workflow diagram
Copyright 2001-2005 Scott W. Ambler
Copyright 2003-2005
Scott W. Ambler
7
Tests as Primary Artifacts
Reduce Documentation by Single Sourcing Information

Acceptance tests are considered to be
primary requirements artifacts


Unit tests are considered to be detailed
design artifacts


You can reduce your requirements documentation
dramatically by not recording the same
information twice
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:









Valid reasons to document:





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
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
Communication Effectiveness
Face-to-face
conversation
Video
conversation
Phone
conversation
Modeling
Options
Videotape
Email
conversation
Audiotape
Paper
Cold
Documentation
Options
Richness of Communication Channel
Hot
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
Often
13%
Always
7%
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
Priority
Each iteration implement the highestpriority 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
Effectiveness
of
Requirements
Gathering
Techniques
Face-To-Face Interviews
Electronic Interviews
Legacy Code Analysis
Reading
Collaborative
Interaction
Restricted
Interaction
Copyright 2005 Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler
15
Relative Effectiveness of User
Representatives
Effectiveness
Actual Stakeholder
Product Manager
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