Introduction to Agile Model Driven Development (amdd)
Introduction to Agile Model Driven Development (AMDD)
- Scott W. Ambler
- Senior Consultant, Ambysoft Inc.
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
- 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)
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 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
- 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
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 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:
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.
The database is protected by copyright ©sckool.org 2016