Copyright 2001-2005 Scott W. Ambler1 Introduction to Agile Model Driven Development (AMDD) Scott W....

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


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

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


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


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


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


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


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


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

Co

mm

un

icat

ion

Eff

ecti

ven

ess

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


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


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



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


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

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



Relative Effectiveness of User Representatives

Actual Stakeholder

Product Manager

Business Analyst as User

Personas

Effe

ctiv

enes

s



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

Copyright 2001-2005 Scott W. Ambler1 Introduction to Agile Model Driven Development (AMDD) Scott W....

Documents

Transcript of Copyright 2001-2005 Scott W. Ambler1 Introduction to Agile Model Driven Development (AMDD) Scott W....