Copyright 2001-2005 Scott W. Ambler 1 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
Introduction to Agile Model Driven Development (AMDD)
Scott W. AmblerSenior Consultant, Ambysoft Inc.www.ambysoft.com/scottAmbler.html
Copyright 2001-2005 Scott W. Ambler 2
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 3
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
Your Software Process
A Base Software Process(e.g. XP, RUP, DSDM, FDD, …)
Principles and Practices ofAgile Modeling (AM)
Other Techniques(e.g. Database refactoring)
Copyright 2001-2005 Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler 4
The Core of AMYou Need to Adopt at Least the Core
Core Principles Assume Simplicity Embrace Change Enabling the Next Effort is
Your Secondary Goal Incremental Change Model With a Purpose Multiple Models Maximize Stakeholder
Investment Quality Work Rapid Feedback Software Is Your Primary Goal Travel Light
Core Practices Active Stakeholder Participation Apply the Right Artifact(s) Collective Ownership Create Several Models in
Parallel Create Simple Content Depict Models Simply Display Models Publicly Iterate to Another Artifact Model in Small Increments Model With Others Prove it With Code Single Source Information Use the Simplest Tools
Copyright 2001-2005 Scott W. Ambler 5
Agile Model Driven Development (AMDD)
Project Level (www.agilemodeling.com/essays/amdd.htm)
Cycle n: Development
Cycle 2: Development
Cycle 1: Development
Cycle 0: Initial Modeling
Initial RequirementsModeling
(days)
Initial ArchitecturalModeling
(days)
Model Storming(minutes)
Implementation(Ideally Test Driven)
(hours)
Reviews(optional)
All Cycles(hours)
Copyright 2003-2005Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler 6
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
Agile models are just barely enough!
Value
Effort
Ideal Realistic
Copyright 2005 Scott W. Ambler
Just Barely Good Enough
Copyright 2001-2005 Scott W. Ambler 7
Agile Modelswww.agilemodeling.com/artifacts/
Conceptual Domain Modeling
- Class Responsibility Collaborator (CRC) Cards- Logical Data Model (LDM)- Object Role Model (ORM) Diagram- Robustness Diagram- UML Class Diagram
Usage Modeling- Acceptance Tests- Essential Use Cases- Features- System Use Cases- Usage scenario- User Stories- UML Use Case Diagram
Supplementary Requirements Modeling
- Business Rules- Conceptual Cases- Constraints- Glossary- Technical Requirements
User Interface Development
- Essential User Interface Prototype- User Interface Flow Diagram- User Interface Prototype
Architectural Modeling
- Change Cases- Free Form Diagram- Security Threat Modeling- UML Component Diagram- UML Deployment Diagram- UML Package Diagram
Dynamic Object Modeling
- UML Communication Diagram- UML Composite Structure Diagram- UML Interaction Overview Diagram- UML Sequence Diagram- UML State Machine Diagram- UML Timing Diagram
Process Modeling
- Data Flow Diagram (DFD)- Flow Chart- UML Activity Diagram- Value Stream Map- Workflow diagram
Detailed Structural Modeling
- External Interface (EI) Specification- Physical Data Model (PDM)- UML Class Diagram- UML Object Diagram
Copyright 2003-2005Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler 8
Tests as Primary ArtifactsReduce 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 9
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 10
Communication ModesAlways Strive to Use the Most Effective Approach
Com
mun
icat
ion
Effe
ctiv
enes
s
Richness of Communication ChannelCold Hot
Paper
Audiotape
Videotape
Email conversation
Phone conversation
Video conversation
Face-to-face conversation
Face-to-faceat whiteboard
DocumentationOptions
ModelingOptions
Copyright 2002-2005 Scott W. AmblerOriginal Diagram Copyright 2002 Alistair Cockburn
Copyright 2001-2005 Scott W. Ambler 11
The Cost of Traditional BRUF“Successful” Projects Still Have Significant Waste
Never45%
Rarely19%
Sometimes16%
Often13%
Always7%
Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002
Copyright 2001-2005 Scott W. Ambler 12
Agile Software Requirements ManagementChanging Requirements Are a Competitive Advantage if You Can Act on Them: www.agilemodeling.com/essays/changeManagement.htm
{Each iteration implement the highest-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
Requirements
HighPriority
LowPriority
Copyright 2004 Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler 13
Active Stakeholder ParticipationThe 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/activeStakeholderParticipatio
n.htm
www.agilemodeling.com/essays/inclusiveModels.htm
Copyright 2001-2005 Scott W. Ambler 14
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 15
Effectiveness of Requirements Gathering Techniques
Active Stakeholder Participation
On-Site Customer
Joint Application Design (JAD)
Legacy Code Analysis
Focus Groups
Electronic Interviews
Reading
CollaborativeInteraction
Restricted Interaction
Face-To-Face InterviewsObservation
Copyright 2005 Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler 16
Relative Effectiveness of User Representatives
Actual Stakeholder
Product Manager
Business Analyst as User
Personas
Effe
ctiv
enes
s
Copyright 2005 Scott W. Ambler
Copyright 2001-2005 Scott W. Ambler 17
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 18
Online Resourceswww.agilemodeling.com
www.agilealliance.org
www.controlchaos.com
www.ambysoft.com
www.agiledata.org
www.enterpriseunifiedprocess.com