Introduction to Agile Model Driven Development (AMDD)
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
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
The Core of AM You Need to Adopt at Least the Core
Enabling the Next Effort is Your Secondary Goal
Model With a Purpose
Maximize Stakeholder Investment
Software Is Your Primary Goal
Active Stakeholder Participation
Apply the Right Artifact(s)
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
Agile Model Driven Development (AMDD) Project Level (www.agilemodeling.com/essays/amdd.htm)
What Are Agile Models?
Fulfill their purpose
Are sufficiently accurate
Are sufficiently consistent
Are sufficiently detailed
Provide positive value
Are as simple as possible
Agile models are just barely enough!
Agile Models www.agilemodeling.com/artifacts/
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
Travel light -You need far less documentation than you think
Maximize stakeholder investment
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
Communication Modes Always Strive to Use the Most Effective Approach
The Cost of Traditional BRUF Successful Projects Still Have Significant Waste
Agile Software Requirements Management Changing Requirements Are a Competitive Advantage if You Can Act on Them: www.agilemodeling.com/essays/changeManagement.htm
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
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
Effectiveness of Requirements Gathering Techniques
Relative Effectiveness of User Representatives
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.