1. Agile Model Development with the IBM®
Rational® Software Architect
Daniel Leroux
Distinguished Engineer, IBM
dleroux@ca.ibm.com
Maneesh Goyal
Senior Software Engineer, IBM
mgoyal@ca.ibm.com
Select View/Master/Slide Master to add Session Number Here
MAC03
© 2009 IBM Corporation

2. IBM Rational Software Conference 2009
Agenda
Introduction
Maneesh’ team
Agile Modeling and principles
Demo
Questions
MAC03

3. IBM Rational Software Conference 2009
What is a Model?
A model is an abstraction of a physical system
Typically, you will create different models for a
physical system to visualize different points of view
Users
Developers
Graphic Artists
Database developers
Testers
Documenters
And on and on ……
MAC03

4. IBM Rational Software Conference 2009
Why do we model?
To manage complexity
To detect errors and omissions early in the lifecycle
To communicate with stakeholders
To understand requirements
To drive implementation
To understand the impact of change
To ensure that resources are deployed
efficiently
MAC03

5. IBM Rational Software Conference 2009
Why do we model?
To manage complexity
To detect errors and omissions early in the lifecycle
To communicate with stakeholders
To understand requirements
To drive implementation
To understand the impact of change
To ensure that resources are deployed
efficiently
MAC03

6. IBM Rational Software Conference 2009
The Unified Modeling Language
The UML is
the standard
language for
visualizing,
specifying,
constructing,
and
documenting
software and
systems
MAC03

7. IBM Rational Software Conference 2009
TQ’s Golden Rule
Only use what
you need
UML
Is HUGE
MAC03

8. IBM Rational Software Conference 2009
Agile Modeling
Agile Modeling is a collection of values,
principles and practices for modeling software
that can be applied on a software
development project in an effective and light-
weight manner
Copyright © 2001-2008 Scott W. Ambler
MAC03

9. IBM Rational Software Conference 2009
Primary Approach to Modeling
No Modeling
Ad-Hoc
Sketch to Think and
Communicate
Traditional Sketch and Capture
Key Diagrams
SBMT for Docs
Iterative
SBMT to Generate
Code
Agile SBMT for Full Trip
Engineering
0% 20% 40% 60% 80% 100%
MAC03

10. IBM Rational Software Conference 2009
Common Misconceptions About CASE Tools
Agile modelers don’t use CASE tools
Agile modelers use the simplest tool, and if the simplest tool for the job is a CASE tool,
then that is what will be used
UML requires CASE tools
Not true. UML drawings are often done by hand
You start modeling with CASE tools
Typically modeling is started with a simple tool (e.g. flip charts) and then you migrate to a
CASE tool if needed (e.g. to create persistent models)
The CASE tool is the master
Not true. Once code is either generated from the model or written by hand, the code is
the master. One tough decision that has to be made is should the model be updated to
reflect the code?
MAC03

11. IBM Rational Software Conference 2009
Maneesh’ Team
Maneesh: software development manager
responsible for managing the architecture of a
Rational Modeling product and leading a team
of engineers developing this product
Maneesh’ team
10 brilliant software engineers
Maneesh’ extended team
Product Manager Product delivery team
Release engineering team User Experience team
MAC03

12. IBM Rational Software Conference 2009
Team Process – Agile Modeling
Review requirements
New requirements arrive from the product manager
Ask clarifying questions to the product manager and provide feedback
Review the updated requirements
Manage SW architecture
Create new SW design models
Use case diagrams
Class diagrams, sequence diagrams, …
Review the SW designs created by the team members
Share and collaborate within the team and extended team
MAC03

13. IBM Rational Software Conference 2009
The Problem
Information overload
Email discussions
Meeting minutes, whiteboards
Collaboration and communication
Globally distributed teams
Knowledge transfer – The whys of architecture
MAC03

14. IBM Rational Software Conference 2009
Agile Modeling Principles
Requirements envisioning
Prioritized requirements
Architecture envisioning
Multiple models
Just barely good enough models
Model storming
Active stakeholder participation
Copyright © 2001-2008 Scott W. Ambler
MAC03

15. IBM Rational Software Conference 2009
Requirements envisioning
Create new requirements
Modify existing requirements
Use Rational Requirements Composer
Stakeholder participation
Product managers
User experience team
MAC03

16. IBM Rational Software Conference 2009
Prioritized requirements
Define criteria for prioritization
Review and prioritize requirements
Stakeholder participation
Internal stakeholders – software development engineers, user experience team
External stakeholders – product managers
MAC03

17. IBM Rational Software Conference 2009
Architecture envisioning
Create and modify architecture models
Associate the models with the requirements
Stakeholder participation
Software architects
Software development engineers
MAC03

18. IBM Rational Software Conference 2009
Multiple models &
Just barely good enough models
Similar to whiteboard models
Use case diagram
Class and Component diagram
Sequence diagram
Deployment diagram
Stakeholder participation
Software architect
Software development engineers
MAC03

19. IBM Rational Software Conference 2009
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!
MAC03

20. IBM Rational Software Conference 2009
Active stakeholder participation &
Model storming
Review the requirements and architecture with
all stakeholders
Remove the barriers to participation
The needs of the globally distributed team
Provide the right tools
MAC03

21. IBM Rational Software Conference 2009
MAC03 21

22. IBM Rational Software Conference 2009
Conclusion
You are engaged in Agile Modeling if:
Your customers/users are active participants
Changing requirements are welcomed and acted upon
You work on the highest priority requirements first
You take an iterative and incremental approach to modeling
Your primary focus is the development of software, not documentation or
models themselves
You model as a team where everyone’s input is welcome
You actively try to keep things as simple as possible
You discard models as development progresses
Customers/business owners make business decisions; developers make
technical decisions
The model’s content is recognized as being significantly more important than the
format/representation of that content
How you test what you describe with your model(s) is a critical issue continually
considered as you model
MAC03

23. IBM Rational Software Conference 2009
References and Recommended Reading
www.agilealliance.com, www.agilemodeling.com, www.agiledata.org,
www.ambysoft.com, www.databaserefactoring.com,
www.enterpriseunifiedprocess.com
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. and Sadalage, P.J. (2006). Refactoring Databases:
Evolutionary Database Design. Reading, MA: Addison Wesley Longman, Inc.
Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide.
Reading, MA: Addison Wesley
McGovern, J., Ambler, S.W., Stevens, M., Linn, J., Sharan, V., & Jo, E.
(2003). The Practical Guide to Enterprise Architecture. Prentice Hall PTR.
MAC03

24. IBM Rational Software Conference 2009
MAC03 24

25. IBM Rational Software Conference 2009
© Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature
availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines
Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
MAC03 25