Agile Model Developement- Daniel Leroux

© 2009 IBM Corporation

Select View/Master/Slide Master to add Session Number Here

Agile Model Development with the IBM®Rational® Software Architect

Daniel LerouxDistinguished Engineer, IBM

[email protected]

Maneesh GoyalSenior Software Engineer, IBM

[email protected] MAC03

© 2009 IBM Corporation

IBM Rational Software Conference 2009

MAC03

Agenda

Introduction

Maneesh’ team

Agile Modeling and principles

Demo

Questions


MAC03

What is a Model?

A model is an abstraction of a physical systemTypically, you will create different models for a physical system to visualize different points of view

UsersDevelopersGraphic ArtistsDatabase developersTestersDocumentersAnd on and on ……


MAC03

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

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

The Unified Modeling Language

The UML is the standard language for visualizing, specifying, constructing, and documenting software and systems


MAC03

TQ’s Golden Rule

UML Is HUGE

Only use what you need


MAC03

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

Primary Approach to Modeling

0% 20% 40% 60% 80% 100%

Agile

Iterative

Traditional

Ad-HocNo Modeling

Sketch to Think andCommunicateSketch and CaptureKey DiagramsSBMT for Docs

SBMT to GenerateCodeSBMT for Full TripEngineering


MAC03

Common Misconceptions About CASE Tools

Agile modelers don’t use CASE toolsAgile 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 toolsNot true. UML drawings are often done by hand

You start modeling with CASE toolsTypically 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 masterNot 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

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’ team10 brilliant software engineers

Maneesh’ extended teamProduct ManagerRelease engineering team

Product delivery teamUser Experience team


MAC03

Team Process – Agile Modeling

Review requirementsNew requirements arrive from the product managerAsk clarifying questions to the product manager and provide feedbackReview the updated requirements

Manage SW architectureCreate new SW design models

Use case diagramsClass diagrams, sequence diagrams, …

Review the SW designs created by the team membersShare and collaborate within the team and extended team


MAC03

The Problem

Information overloadEmail discussionsMeeting minutes, whiteboards

Collaboration and communicationGlobally distributed teamsKnowledge transfer – The whys of architecture


MAC03

Agile Modeling Principles

Requirements envisioning

Prioritized requirements

Architecture envisioning

Multiple models

Just barely good enough models

Model storming

Active stakeholder participationCopyright © 2001-2008 Scott W. Ambler


MAC03

Requirements envisioning

Create new requirements

Modify existing requirements

Use Rational Requirements Composer

Stakeholder participationProduct managersUser experience team


MAC03

Prioritized requirements

Define criteria for prioritization

Review and prioritize requirements

Stakeholder participationInternal stakeholders – software development engineers, user experience teamExternal stakeholders – product managers


MAC03

Architecture envisioning

Create and modify architecture models

Associate the models with the requirements

Stakeholder participationSoftware architectsSoftware development engineers


MAC03

Multiple models &Just barely good enough models

Similar to whiteboard modelsUse case diagramClass and Component diagramSequence diagramDeployment diagram

Stakeholder participationSoftware architectSoftware development engineers


MAC03

What Are Agile Models?

Agile models:Fulfill their purposeAre understandableAre sufficiently accurateAre sufficiently consistentAre sufficiently detailedProvide positive valueAre as simple as possible

Agile models are just barely enough!


MAC03

Active stakeholder participation &Model storming

Review the requirements and architecture with all stakeholders

Remove the barriers to participationThe needs of the globally distributed teamProvide the right tools


MAC03 21


MAC03

Conclusion

You are engaged in Agile Modeling if:Your customers/users are active participantsChanging requirements are welcomed and acted upon

You work on the highest priority requirements firstYou take an iterative and incremental approach to modelingYour primary focus is the development of software, not documentation or models themselvesYou model as a team where everyone’s input is welcomeYou actively try to keep things as simple as possibleYou discard models as development progressesCustomers/business owners make business decisions; developers make technical decisionsThe model’s content is recognized as being significantly more important than the format/representation of that contentHow you test what you describe with your model(s) is a critical issue continually considered as you model


MAC03

References and Recommended Reading

www.agilealliance.com, www.agilemodeling.com, www.agiledata.org, www.ambysoft.com, www.databaserefactoring.com, www.enterpriseunifiedprocess.comAmbler, 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


MAC03

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

25

Technology

Agile Model Developement- Daniel Leroux