Agile Modeling

Theory

2

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

Copyright Scott W. Ambler

3

The Core of AM

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

Copyright Scott W. Ambler

4 Copyright Scott W. Ambler

Agile Model Driven Development 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

5 Copyright Scott W. Ambler

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

6

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

Copyright Scott W. Ambler

7

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 Copyright Scott W. Ambler

8

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

Copyright 2004 Scott W. Ambler

Copyright Scott W. Ambler

9

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

Copyright Scott W. Ambler

Agile Modeling

Details

11

AM Values (1)

The values of AM includes: communication, simplicity, feedback, courage, and humility.

Communication: It is critical to have effective communication between development team as well as with and between all project stakeholders.

Simplicity: Models are critical for simplifying both software and the software process.

12

AM Values (2)

Feedback: “Optimism is an occupational hazard of programming, feedback is the treatment”. (Kent Back, Extreme Programming Explained )

Courage: Need to make important decisions and to change direction by either discarding or refactoring completed work when some decisions proved inadequate.

13

AM Values (3)

Humility: All people involved with the project have equal value and should be treated with respect.

14

AM Principles (1)

AM defines a collection of core and supplementary principles that when applied on a software development project set the stage for a collection of modeling practices.

Core Principles are as follows: Assume Simplicity: Simplest solution is the

best solution. Embrace Change: People’s understanding

and requirements evolve over time.

15

AM Principles (2)

Enabling The Next Effort Is Your Secondary Goal: “When you are playing the software development game your secondary goal is to setup to play the next game”. (Alistair Cockburn,2002)

Incremental Change: Develop a small model, or perhaps a high-level model, and evolve it over time in an incremental manner.

16

AM Principles (3)

Maximize Stakeholder Investment: Developed software must meet the requirements of the project stakeholder since he is investing time, money, resources, etc.

Model With A Purpose: Identify a valid

purpose for creating a model and audience for the model.

17

AM Principles (4)

Multiple Models: Need to use multiple models since each model describes a single aspect of your software.

Rapid Feedback: Work closely with customers to understand and analyze their requirements and to develop a user interface that meets their need and provide opportunities for rapid feedback.

18

AM Principles (5)

Quality Work: Nobody likes sloppy work.

Software is your primary goal: Produced software should meet the stakeholders need in effective manner.

Travel Light: Create just enough models and documentation to get by.

19

AM Principles (6)

Supplementary principles: Content is more important than

representation: Any given model can be represented by several ways.

Everyone can learn from everyone else: Have the humility to recognize that one can never master everything.

20

AM Principles (7)

Know your models: Need to know the strengths and weaknesses of the multiple models to be effective in their use.

Open and honest communication: This enables people to make better decisions.

Work with people’s instincts: Instincts become sharper with the experience of software development.

21

AM Principles (8)

Know your tools: Know the features of the modeling tools for its effective use.

Local Adaptation: Adapt a specific approach to a project level as well as the individual level.

22

AM Practices (1)

AM defines a collection of core and supplementary practices, based on the principles of AM

Core practices are as follows: Active Stakeholder Participation: Project

success requires a significant level of involvement by project stakeholder.

Apply the Right Artifact(s): “Use the right tool for the job”. (e.g. A UML activity diagram is useful for describing a business process).

23

AM Practices (2)

Collective Ownership: Everyone can work on any model or any artifact on the project, if they need to.

Consider Testability: Do not build software if no one can test it.

Depict Models Simply: Key features are sufficient to understand the model.

24

AM Practices (3)

Create Simple Content: Don’t add any additional aspects to the model unless they are justifiable.

Create Several Models in Parallel: People are more productive when they work on several models simultaneously

Model with others: Dangerous to do it alone.

25

AM Practices (4)

Display Models Publicly: This supports open and honest communication since the current model is quickly accessible.

Iterate to Another Artifact: Start another artifact when you got stuck doing one.

Model in Small Increments: model a little, code a little, test a little, then deliver a little.

26

AM Practices (5)

Prove it with Code: validate the model by writing a corresponding code.

Use the Simplest Tools: Vast majority of models can be depicted on papers or whiteboard.

27

AM Practices (6)

Supplementary practices:

Apply modeling standards: Developers should agree on a common set of modeling standards on a software project.

Apply Patterns Gently: “Developers should consider easing into the application of a pattern, to apply it gently” (Martin Fowler and Joshua Kerievsky, 2001).

28

AM Practices (7)

Discard Temporary Models: Models quickly become out of sync with the code and there’s nothing wrong in discarding them.

Formalize Contract Models: Models are formalized when both parties agree to them and are ready to mutually change them over time if required.

29

AM Practices (8)

Model to Communicate: Need to create a contract model or to communicate with people external to the developing team.

Model to Understand: Explore the problem space, to identify and analyze the system requirements for the best potential solution that meets the requirements.

30

AM Practices (9)

Reuse Existing Resources: Take advantage of wealth of information by reusing the information (models and documentations).

Update only When It Hurts: Is not having the model updated is more painful than the effort of updating it?

31

When is a Model Agile?

Agile models are good enough when they exhibit the following criteria: They fulfill their purpose and no more. They are understandable. They are sufficiently accurate. They are as simple as possible. They are sufficiently consistent. They provide positive value. They are sufficiently detailed.

32

Agile Documentation (1)

A document is agile when it meets the following criteria: Agile documents maximize stakeholder

investment. Agile documents are “lean and mean”. Agile documents fulfill a purpose. Agile documents describe information that is

less likely to change. Agile documents describe “good things to

know”.

33

Agile Documentation (2)

Agile documents have a specific customer and facilitate the work efforts of that customer.

Agile documents are sufficiently accurate, consistent, and detailed.

Agile documents are sufficiently indexed.