amddintroduction

8/7/2019 AMDDIntroduction

1/18

Copyright 2001-2005 Scott W. Ambler 1

Introduction to Agile Model DrivenDevelopment (AMDD)

Scott W. AmblerSenior Consultant, Ambysoft Inc.

www.ambysoft.com/scottAmbler.html
http://www.ambysoft.com/scottAmbler.htmlhttp://www.ambysoft.com/scottAmbler.html


2/18


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 ScottW. Ambler

Visitwww.agilemodeling.com/essays/amddPresentation.htmfor updates
http://www.agilemodeling.com/essays/amddPresentation.htmhttp://www.agilemodeling.com/essays/amddPresentation.htm


3/18


Agile Modeling (AM) AM is a chaordic, practices-based process for

modeling and documentation AM is a collection ofpractices based on several values

and proven software engineeringprinciples AM is a light-weight approach for enhancing modeling

and documentation efforts for other softwareprocesses such as XP and RUP

Your Software Process

A Base Software Process

(e.g. XP, RUP, DSDM, FDD, )

Principles and Practices of

Agile Modeling (AM)

Other Techniques

(e.g. Database refactoring)

Copyright 2001-2005 Scott W. Ambler


4/18


T e Core o AMYou Need to Adopt at Least the

CoreCore 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


5/18


(AMDD)

Project Level (www.agilemodeling.com/essays/amdd.htm)

Cycle n: Development

Cycle 2: Development

Cycle 1: Development

Cycle 0: Initial Modeling

Initial Requirements

Modeling

(days)

Initial Architectural

Modeling

(days)

Model Storming(minutes)

Implementation(Ideally Test Driven)

(hours)

Reviews

(optional)

All Cycles

(hours)

Copyright 2003-2005

Scott W. Ambler
http://www.agilemodeling.com/essays/amdd.htmhttp://www.agilemodeling.com/essays/amdd.htm


6/18


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 justbarely enough!

Value

Effort

Ideal

Copyright 2005 Scott W. Ambler

Just Barely

Good Enough


7/18


Agile Modelswww.agilemodeling.com/artifacts/

Conceptual Domain Modeling

- Class Responsibility Collaborator (CRC) Cards

- Logical Data Model (LDM)

- Object Role Model (ORM) Diagram

- Robustness D iagram

- UML Class Diagram

Usage Modeling- Acceptance Tests

- Essential Use Cases

- Features

- System Use Cases

- Usage scenario

- User Stories

- UML Use Case Diagram

Supplementary RequirementsModeling

- 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
http://www.agilemodeling.com/artifacts/http://www.agilemodeling.com/artifacts/


8/18


Tests as Primary ArtifactsReduce Documentation by Single Sourcing Information

Acceptance tests are considered to beprimary requirements artifacts You can reduce your requirements

documentation dramatically by notrecording the same information twice

Unit tests are considered to be detaileddesign artifacts

You can reduce your design documentationdramatically and increase the chance thatyour detailed design artifacts are kept up todate by coders

www.agilemodeling.com/essays/singleSourceInformation.htm
http://www.agilemodeling.com/essays/singleSourceInformation.htmhttp://www.agilemodeling.com/essays/singleSourceInformation.htm


9/18


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
http://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agilemodeling.com/essays/agileDocumentation.htm


10/18


Communication ModesAlways Strive to Use the Most Effective Approach

CommunicationEffectiv

eness

Richness of Communication ChannelCold Hot

Paper

Audiotape

Videotape

Emailconversation

Phoneconversation

Video

conversation

Face-to-faceconversation

Face-to-face

at whiteboard

DocumentationOptions

ModelingOptions

Copyright 2002-2005 Scott W. Ambler

Original Diagram Copyright 2002 Alistair Cockburn


11/18


The Cost of TraditionalBRUFSuccessful Projects Still Have Significant Waste

Sometimes16%

Often

13%

Always7%

Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002


12/18


ManagementChanging Requirements Are a Competitive Advantage if YouCan Act on Them:www.agilemodeling.com/essays/changeManagement.htm

{ Each iteration implement the highest-priority requirements

Each new requirement isprioritized and added to

the stack

Requirements may be

reprioritized at any time

Requirements may beremoved at any time

Requirements

High

Priority

Low

Priority

http://www.agilemodeling.com/essays/changeManagement.htmhttp://www.agilemodeling.com/essays/changeManagement.htm


13/18


Active StakeholderParticipationThe Stakeholders are the Experts, Shouldnt 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
http://www.agilemodeling.com/essays/activeStakeholderParticipation.htmhttp://www.agilemodeling.com/essays/inclusiveModels.htmhttp://www.agilemodeling.com/essays/inclusiveModels.htmhttp://www.agilemodeling.com/essays/activeStakeholderParticipation.htm


14/18


Model With OthersThe modeling equivalent of pair

programming

You are fundamentally at riskwhenever someone works onsomething by themselves

Several heads are better than one


15/18


Effectiveness ofRequiremen

ts GatheringTechniques

Active Stakeholder Participation

On-Site Customer

Joint Application Design (JAD)

Legacy Code Analysis

Focus Groups

Electronic Interviews

Reading

Collaborative

Interaction

Restricted

Interaction

Face-To-Face Interviews

Observation



16/18


Relative Effectiveness of

User RepresentativesActual Stakeholder

Product Manager

Business Analyst as User

Personas

Effectiveness



17/18


18/18


Online Resources

www.agilemodeling.com

www.agilealliance.org

www.controlchaos.com

www.ambysoft.com

www.agiledata.org

www.enterpriseunifiedprocess.com
http://www.agilemodeling.com/http://www.agilealliance.org/http://www.controlchaos.com/http://www.ambysoft.com/http://www.agiledata.org/http://www.enterpriseunifiedprocess.com/http://www.enterpriseunifiedprocess.com/http://www.agiledata.org/http://www.ambysoft.com/http://www.controlchaos.com/http://www.agilealliance.org/http://www.agilemodeling.com/

amddintroduction

Documents