Introduction to Agile Model Driven Development (amdd)



Download 8,17 Kb.
Date conversion15.02.2017
Size8,17 Kb.

Introduction to Agile Model Driven Development (AMDD)

  • Scott W. Ambler
  • Senior Consultant, Ambysoft Inc.
  • www.ambysoft.com/scottAmbler.html

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
  • www.agilemodeling.com/essays/singleSourceInformation.htm

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 Modes Always Strive to Use the Most Effective Approach

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:
  • www.agilemodeling.com/essays/activeStakeholderParticipation.htm
  • www.agilemodeling.com/essays/inclusiveModels.htm

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.

Online Resources

  • www.agilemodeling.com
  • www.agilealliance.org
  • www.controlchaos.com
  • www.ambysoft.com
  • www.agiledata.org
  • www.enterpriseunifiedprocess.com


The database is protected by copyright ©sckool.org 2016
send message

    Main page