You are on page 1of 18

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  Collective Ownership

Your 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
 Are understandable Good Enough
 Are sufficiently accurate
Ideal
 Are sufficiently consistent
 Are sufficiently detailed
 Provide positive value
Value
 Are as simple as possible
 Agile models are just
barely enough!

Effort
Copyright 2005 Scott W. Ambler

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%

Sometimes
16% Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002
Copyright 2001-2005 Scott W. Ambler 11
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

Effectivenes Electronic Interviews


s of Legacy Code Analysis

Requiremen Reading

ts Gathering Collaborative Restricted


Interaction Interaction
Techniques 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

You might also like