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

Copyright Scott W. Ambler 5 Agile Models

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

8 Agile Software Requirements Management Changing Requirements Are a Competitive Advantage if You Can Act on Them: Copyright Scott W. Ambler

9 Active Stakeholder Participation The 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 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.