introduction to agile development

Introduction to Agile Model Driven Development (AMDD)

Scott W. Ambler

Senior Consultant, Ambysoft Inc.

www.ambysoft.com/scottAmbler.html

Copyright 2001-2005 Scott W. Ambler

About These Slides
Some slides have notesYou may use these slides, or a subset thereof, in presentations or training materialsYou must indicate that the slide is Copyright Scott W. Ambler 2005You must not remove copyright notices from the diagramsYou may not sell or license the material contained within this file without the express permission of Scott W. AmblerVisit www.agilemodeling.com/essays/amddPresentation.htm for updates

Agile Modeling (AM)
AM is a chaordic, practices-based process for modeling and documentationAM is a collection of practices based on several values and proven software engineering principlesAM is a light-weight approach for enhancing modeling and documentation efforts for other software processes such as XP and RUP

AM is a partial method which is meant to be tailored into other processes such as RUP, FDD, and XP

The AM site has a wealth of material

A Base Software Process(e.g. XP, RUP, DSDM, FDD, )

Principles and Practices ofAgile Modeling (AM)

Your Software Process

Other Techniques(e.g. Database refactoring)


The Core of AM
You Need to Adopt at Least the Core

Core Principles
Assume SimplicityEmbrace ChangeEnabling the Next Effort is Your Secondary GoalIncremental ChangeModel With a PurposeMultiple ModelsMaximize Stakeholder InvestmentQuality WorkRapid FeedbackSoftware Is Your Primary GoalTravel Light
Core Practices
Active Stakeholder ParticipationApply the Right Artifact(s)Collective OwnershipCreate Several Models in ParallelCreate Simple ContentDepict Models SimplyDisplay Models PubliclyIterate to Another ArtifactModel in Small IncrementsModel With OthersProve it With CodeSingle Source InformationUse the Simplest Tools

www.agilemodeling.com/practices.htm

www.agilemodeling.com/principles.htm

The supplementary principles and practices are good ideas which you should also consider adopting

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


You should do some initial modeling up front to identify a plausible architecture and the scope of your effort

Do the detail just in time (JIT) via model storming

http://www.agilemodeling.com/essays/modelReviews.htm

Initial RequirementsModeling(days)

Initial ArchitecturalModeling(days)

Model Storming(minutes)

Implementation(Ideally Test Driven)(hours)

Cycle 1: Development

Reviews(optional)All Cycles(hours)

Cycle 0: Initial Modeling


Cycle n: Development

Copyright 2003-2005Scott W. Ambler

What Are Agile Models?
Agile models:Fulfill their purposeAre understandableAre sufficiently accurateAre sufficiently consistentAre sufficiently detailedProvide positive valueAre as simple as possibleAgile models are just barely enough!

http://www.agilemodeling.com/essays/barelyGoodEnough.html

Agile models are the most effective possible because you invest just enough effort to get the job done.

If the model isnt good enough yet then you can invest more effort into it and still get value.

If the model is good enough, for your current needs, or more than good enough, then any more work done on it would be a waste.

Good enough is in the eye of the beholder, so this can be tough. Active Stakeholder Participation and Model With Others to know what the audience for the model actually needs, dont guess.

Value

Effort

Ideal

Copyright 2005 Scott W. Ambler

Realistic

Just Barely Good Enough

Agile Models
www.agilemodeling.com/artifacts/


Software development is complex

Each type of model is good at one type of view, but you need many views

No starting point, no ending point

http://www.agilemodeling.com/essays/phasesExamined.htm

You need to know a range of techniques to be effective, but you dont need to know all of them

In each category there are often several similar techniques, use the one that works for you

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 Artifacts
Reduce Documentation by Single Sourcing Information
Acceptance tests are considered to be primary requirements artifactsYou can reduce your requirements documentation dramatically by not recording the same information twiceUnit tests are considered to be detailed design artifactsYou can reduce your design documentation dramatically and increase the chance that your detailed design artifacts are kept up to date by coderswww.agilemodeling.com/essays/singleSourceInformation.htm

You want to store information in the best place possible, and thats often in tests, not documents

Agile Documentation
Travel light You need far less documentation than you thinkAgile documents:Maximize stakeholder investment Are conciseFulfill a purpose Describe information that is less likely to change Describe good things to knowHave 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 itTo define a contract modelTo support communication with an external groupTo think something throughwww.agilemodeling.com/essays/agileDocumentation.htm

Communication Modes
Always Strive to Use the Most Effective Approach


Software development is a communication game

Documentation is the worst way to communicate

Whatever your situation, use the most effective means at your disposal to communicate

http://www.agilemodeling.com/essays/communication.htm

Communication Effectiveness

Richness of Communication Channel

Cold

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

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


Looked at hundreds of successful projects which took a traditional/serial approach with a big requirements up front (BRUF) strategy

All projects delivered software into production many projects in the Chaos study didnt deliver

49% of functionality delivered wasnt used by stakeholders, 19% rarely used

The main point to make is even when you succeed you still have close to 2/3 wastage

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


HighPriority

LowPriority

{

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


Active Stakeholder Participation
The Stakeholders are the Experts, Shouldnt They Model?
Project stakeholders should:Provide information in a timely mannerMake decisions in a timely mannerActively participate in business-oriented modelingwww.agilemodeling.com/essays/activeStakeholderParticipation.htm www.agilemodeling.com/essays/inclusiveModels.htm

Model With Others
The modeling equivalent of pair programmingYou are fundamentally at risk whenever someone works on something by themselvesSeveral heads are better than one

Software development is a lot like swimming, very dangerous to do it alone

http://www.agilemodeling.com/practices.htm#ModelWithOthers

Effectiveness of Requirements Gathering Techniques


www.agilemodeling.com/essays/agileRequirements.htm

Prefer collaborative techniques over restricted interaction techniques

Prefer techniques high up on the chart over lower ones (the arrow indicates effectiveness)

Focus Groups


Electronic Interviews

On-Site Customer

Reading

Joint Application Design (JAD)

Legacy Code Analysis

CollaborativeInteraction

Restricted Interaction

Face-To-Face Interviews

Observation


Relative Effectiveness of User Representatives


There are different ways to represent stakeholders, the best way it to get the actual stakeholders actively involved on your project

Effectiveness

Business Analyst as User

Personas

Actual Stakeholder

Product Manager


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 Managers 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


C

o

m

m

u

n

i

c

a

t

i

o

n

E

f

f

e

c

t

i

v

e

n

e

s

s

Richness of Communication Channel

ColdHot

Paper

Audiotape

Videotape

Email

conversation

Phone

conversation

Video

conversation

Face-to-face

conversation

Face-to-face

at whiteboard

Documentation

Options

Modeling

Options


Original Diagram Copyright 2002 Alistair Cockburn

Cycle n: 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

Never

45%

Rarely

19%

Sometimes

16%

Often

13%

Always

7%

{

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

High

Priority

Low

Priority


Value

Effort

IdealRealistic


Just Barely

Good Enough

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)


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-2005

Scott W. Ambler

Actual Stakeholder

Product Manager


Personas

E

f

f

e

c

t

i

v

e

n

e

s

s


On-Site Customer



Focus Groups


Reading

Collaborative

Interaction

Restricted

Interaction

One-On-One InterviewsObservation


On-Site Customer



Focus Groups


Reading

Collaborative

Interaction

Restricted

Interaction

Face-To-Face Interviews

Observation


Actual Stakeholder

Product Manager


Personas

E

f

f

e

c

t

i

v

e

n

e

s

s


introduction to agile development

Documents

copyright scott

express permission of

possibleagile models

software processes

copyright notices

model storminghttp

collection of practices

ambleragile modeling