AMDDIntroduction

Introduction to Agile Model Driven Development (AMDD) : 

Introduction to Agile Model Driven Development (AMDD) Scott W. Ambler Senior Consultant, Ambysoft Inc. www.ambysoft.com/scottAmbler.html

About These Slides: 

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): 

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 AMYou Need to Adopt at Least the Core: 

The Core of AM You 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

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

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

What Are Agile Models?: 

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!

Agile Modelswww.agilemodeling.com/artifacts/: 

Agile Models www.agilemodeling.com/artifacts/

Tests as Primary ArtifactsReduce Documentation by Single Sourcing Information: 

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

Agile Documentation: 

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

Communication ModesAlways Strive to Use the Most Effective Approach: 

Communication Modes Always Strive to Use the Most Effective Approach

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

The Cost of Traditional BRUF “Successful” Projects Still Have Significant Waste Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002

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

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

Active Stakeholder ParticipationThe Stakeholders are the Experts, Shouldn’t They Model?: 

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

Model With Others: 

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: 

Effectiveness of Requirements Gathering Techniques

Relative Effectiveness of User Representatives: 

Relative Effectiveness of User Representatives

References and Recommended Reading: 

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.

Online Resources: 

Online Resources www.agilemodeling.com www.agilealliance.org www.controlchaos.com www.ambysoft.com www.agiledata.org www.enterpriseunifiedprocess.com