Agile UP Intro-Larman

Agile UP 9/27/2002
An
Agile UP:
Introduction
Craig Larman
www.craiglarman.com
www.valtech.com
Copyright © 2002 Craig Larman. All rights reserved.
speaker background
? www.craiglarman.com
? Roles at IntellAgile & Valtech. . .
Underway:
Agile and
Iterative
Development:
A Manager’s
Guide
2 Copyright © Craig Larman. www.craiglarman.com
Copyright (c) 2002 Craig Larman. All rights reserved. www.craigl arman.com 1
Agile UP 9/27/2002
UP
Overview
www.craiglarman.com
www.valtech.com
Defining our Terms: UP and RUP
? The RUP process framework is a detailed,

updated refinement of the more general
UP process framework.
? RUP lead architect: Philippe Kruchten.
? Some use the term “UP” for “UP family” —

those related to (and consistent with) the
UP process framework, especially the
RUP.
Agile UP 9/27/2002
UP Practice #1:
Develop Iteratively
iteration
2-6 weeks phase
inc. elaboration construction transition
Work in early iterations emphasize:

• Risk
• Criticality (high business value)
• Coverage (many components are touched)
UP Practice #1:
Develop Iteratively
Reqs Design Implement
inc. elaboration construction transition
Throwaway
Prototype
Agile UP 9/27/2002
UP Practice #2:
Continuously Verify Quality
UP Practice #3:
Build a Cohesive Architecture
Agile UP 9/27/2002
UP Practice #4 and #5:

Manage Requirements and Manage Change
UP Practice #6:
Model Visually
Agile UP 9/27/2002
Other Key UP Ideas

UP Disciplines
Requirements
Design
Implementation
Test
Iterations
Deployment
Discipline
Optional
Artifacts
Other Key UP Ideas
Agile UP 9/27/2002
Domain
Business Model
Modeling
Use-Case
Model
Requirements
Data
Design Model Model
Design
Useful, Common UP Artifacts
Use Cases Supplementary

Vision
Specification
Requirements
Software
Architecture Doc.
Design
Risk List
Project
Management
Agile UP 9/27/2002
When Work Products are Needed

use the UP Vocabulary
? Vision
? Use Case Model
? Supplementary Specification
? Software Architecture Document
Producers Domain Model

Consumers
Sale Register ProductCatalog ...

Captured-on
timeStamp 1 1 ... ... ...
Developer Subject
Developer
or Analyst Matter
Expert
domain concepts
Use-Case Model
: System
Process Sale : Cashier
make Process
1. Customer NewSale() Sale
system
Developer Subject arrives ... Cashier
events enterItem Developer
or Analyst Matter 2. Cashier
(id, quantity)
Expert makes new ...
sale.
3. ...
Use Cases System Sequence Diagrams Use Case Diagrams
use-case Design Model

realization with
interaction : Register : ProductCatalog
diagrams
Developer makeNewSale()
Developer
create()
: Sale
enterItem(id, quantity)
spec := getSpecification( id )
addLineItem( spec, quantity ) Data

... Architect
the design
Register classes
ProductCatalog ...
discovered
... 1 1 while designing
...
UCRs can be
makeNewSale() summarized in
getSpecification(...) : ProductSpecification
enterItem(...) class diagrams
...
...
Agile UP 9/27/2002
Use--Case Model
Use
Handle Returns
1. Customer
arrives ...
2. . . .
3. . . .
: System
Process Sale : Cashier
make Process
NewSale() Sale
1. Customer
system
arrives ... Cashier
events enterItem
2. Cashier
makes new (id, quantity)
...
sale.
3. ...
Use Cases System Sequence Diagrams Use Case Diagram
Records-sale-of
Domain Model
Described-by
1
Product
Product Specification
Catalog Contains
1 description
1..*
price
itemID
1
0..1 Used-by
* Describes
Sales * *
LineItem Store
Item
Stocks
quantity 1 address 1
name * 1..*
1..*
Logs- 1
Contained-in Houses
completed
1 ? 1.. *
Sale * Register
Manager
date Started-by
1 1
Captured-on
time 1 1
1
1 1
Paid-by Initiated-by ? Records-sales-on
1 1 1
Payment Customer Cashier
amount
Agile UP 9/27/2002
: Register
Design Model
: ProductCatalog
makeNewSale()
create()
: Sale
enterItem(id, quantity)
spec := getSpecification( id )
addLineItem( spec, quantity )

...
Register
ProductCatalog
... 1 1 ...
makeNewSale()
getSpecification(...) : ProductSpecification
enterItem(...)
...
...
Domain
Sales
Register Sale Pricing
ServiceAccess Payments
«interface»
Services
CreditPayment ICreditAuthorization
Factory
ServiceAdapter
Inventory POSRuleEngine Taxes
«interface» «interface»
POSRuleEngineFacade
IInventoryAdapter ITaxCalculatorAdapter
Technical Services
Persistence
Log4J Jess SOAP

DBFacade
Data Model
«Table»
«Table»
ProductSpecification
Manufacturer
1 * «PK» OID : char(16)
«PK» OID : char(16)
Description : varchar(100)
Name : varchar(100)
...
City : varchar(50) PK - primary key
«FK» Manu_OID : char(16)
FK - foreign key
Applies a UML Profile
Agile UP 9/27/2002
Deployment Model
: TaxServer
: Client «process»
: TaxCalulator
«process»
: JVM-
POS-client
: InventoryServer
: Client
SQL
«process»
: JVM- «process» «database»
POS-client : Inventory : Oracle9i
Notation vs. Method Models
UP Domain Model
Sale
Payment 1
1 Pays-for
date Raw UML class diagram
amount notation used in an
time
essential model
visualizing real-world
concepts.
UP Design Model
Sale
Payment Raw UML class diagram
1 1 date: Date notation used in a
amount: Money Pays-for startTime: Time specification model
visualizing software
getBalance(): Money getTotal(): Money components.
... ...
Agile UP 9/27/2002
Three Modeling Perspectives (Cook & Daniels)
Sale
Conceptual
date
time
Sale
date: Date
Specification
startTime: Time
getLineItems : List of LineItem

...
Sale
dateTime: java.util.Date Implementation
getLineItems : java.util.List
...
Modeling Perspectives in a Sequence Dgm
: Sales : Shipping
placeOrder()
UP
requestShipment() Business
Model
(conceptual)
: Register : Sale
makePayment
(cashTendered) UP
Design
makePayment(cashTendered) Model
(spec/impl)
Agile UP 9/27/2002
UP Adaptation
? In at least 4 areas:
1. Requirements
2. Design
3. Plan
4. Process
Great moments in evolution

Adaptive Planning in the UP
A, B E, F N, O
... I, J K, M ...
C, D G, H P
Project is at this point (in the middle of an iteration)
...
A, B
C, D
E, F,
?
? ? ? ...
?
MILESTONE: A date (perhaps 2 months in
future) and set of objectives is established.
Agile UP 9/27/2002
Mitigate High “ Risks

Risks”” Early
Mitigate High “ Risks

Risks”” Early
Iter 1 Iter 2 Iter 3 Iter n-1 Iter n
Risk Product
Agile UP 9/27/2002
Early Realistic Verification
Early evaluation —>
early feedback —>
•adaptation and
better fit
•provable reliability
•early defect removal
Follow the UP Phases
•Vision & biz case

•Scope •Baseline proved
•Lo-fi plan & est. architecture is built •Operational
•“10%” reqs •Hi-fi plan & est. •Deployed
system
•Candidate arch. •“80%” reqs in detail system
•Docs
Incep- Transi-
Elaboration Construction
tion tion
•Req •Design & build •Design & build the rest •Beta tests
workshop 1 high-risk elements •Minor req changes •Conversion
•Macro- • Req workshop 2, 3 •Prep for deploy •Training
estimation •Micro-estimation •Pilot tests •Deployment
Iter1 Iter2 Iter3 Iter1 Iter20 Iter1 Iter2

2 wk ... ...
4 wk 4 wk 4 wk 2 wk 2 wk 4 wk 4 wk
Agile UP 9/27/2002
? The key distinctive idea is the elaboration

phase.
? Early iterations to discover and refine the core

architecture and requirements while also
implementing the production core of the system.
? Believable macro-level plan and estimates at

the end of elaboration, not during inception.
Inception ? Requirements Phase
Elaboration ? Design Phase
Construction ? Implementation Phase
Transition ? Integration/QA Phase
Agile UP 9/27/2002
Elaboration vs. Construction?

Elaboration-ish Construction-ish
The distinction
between
elaboration and
construction
iterations is fuzzy,
and often
unimportant on a
project.
Time
Iteration
risk
On some projects, a milestone decision to requirements
stop or to submit the bidding for out-sourced instability
development.
Elaboration vs. Construction?
? Therefore, ask yourself: “Is there some real practical

reason I need to distinguish between elaboration and
construction?”
? Often, the answer is no. Fine.
? Then we have:
1. Inception—a few days or weeks to vaguely
comprehend the project goals and scope.
2. “Development”—a series of iterations, driven by risk,
that continue until transition.
3. Transition—beta test and deploy.
Agile UP 9/27/2002
Where Possible, Incremental Delivery

? Partial system in production, early.
? Difficult with embedded or device systems; easy with web sites.
6 month “development cycle”
#1 Incep-
Transi-
tion tion
iteration
Incep- Transi-
#2 tion
tion
#3 Incep-
Transi-
tion tion
Why the
UP?
www.craiglarman.com
www.valtech.com
Agile UP 9/27/2002
History and Rationale
? The UP has rapidly emerged as a world-

wide de facto industry standard for
modern process.
? Groups within many leading companies

are adopting it.
? IBM, Chase-Manhattan, Telia, Valtech,
Alcatel, MCI, British Aerospace, Sprint,
Volvo, Intel, Merrill, E&Y, Deloitte,
Ericsson, . . .
Why acceptance?
? It is good—combines most popular modern
best practices (e.g., iterative development)
? Perceived as coming from modern process

experts.
? It is cohesive and well documented

? HTML based RUP product
? Books
Agile UP 9/27/2002
Why acceptance?
? Flexible.
? Many organizations have “process fatigue” and

just want to adopt a good “turn key” solution.
How to
Fail with
the UP
www.craiglarman.com
www.valtech.com
Agile UP 9/27/2002
Warning: Superimposing Waterfall Thinking
? There are books that give the impression of

being a source of UP advice.
? They are based on this (incorrect)

viewpoint:
? Inception—do the requirements
? Elaboration—do the design or models
? Construction—translate design to code
? Warning! People superimpose waterfall

ideas/values on the UP.
Kruchten on Waterfall versus Iterative
“In a waterfall approach, there is a lot of emphasis on “the specs”

and getting them right, complete, polished and signed-off. In the
iterative process, the software we develop comes first. It is the
software product that is the main focus of attention throughout,
with both specs and software evolving in parallel. This has impact
on the teams: testers, for example, may be used to receiving
complete, stable specs, with plenty of advanced notice to start
testing; whereas in an iterative development, they have to begin
working at once, with specs and requirements that are still
evolving.”
From Waterfall to Iterative Lifecycle – A tough transition for project
managers
by Philippe Kruchten
Agile UP 9/27/2002
Adopt/Build a Process like a System—

System —
Iteratively and Incrementally
1 week 6 months
Share results;
Define basic Apply in pilot
Development Refine
project Development
Case
Case
Development
Case
Project Member Process Mentor

Project Member Process Mentor
Apply in other
Becomes projects
UP mentor
How to Fail with the UP
? No one has experience with short timeboxed

iterations.
? There is not a critical mass of very

knowledgeable object-oriented developers.
? Management doesn’t really understand the

profound implications of moving from waterfall
to iterative lifecycle and adaptive attitudes.
Agile UP 9/27/2002
? Big bang process adoption
? Leaders implementing iterative development

and the UP don’t have direct experience
working as developers in iterative development
and object technology projects.
? Defining changes or “enhancements” to the UP,

when have not yet practiced and mastered the
basics.
? First iteration too big or ambitious.
? Not intensively testing and integrating in each

iteration.
? Not doing true iterative development—still

applying waterfall ideas.
?Front-loading ...
Agile UP 9/27/2002
? Creating too many artifacts.
? Focusing on learning or doing UP minutiae

rather than the grasping the big ideas.
You know you didn’

didn’t
understand the UP when…
when…
? Inception = requirements,
?elaboration = design, . . .
? One tries to define most of the requirements

before starting design or implementation.
? One tries to define most of the design before

starting implementation.
Agile UP 9/27/2002
You know you didn’

didn’t
understand the UP when…
when…
? “Iterations” in months instead of weeks.
? One tries to speculatively predict all iterations,

and what will happen in each one.
? An organization wants believable plans and

estimates for projects before they have entered
the elaboration phase.

Agile UP Intro-Larman

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agile UP Intro-Larman

Transféré par

Droits d'auteur :

Formats disponibles

Agile UP 9/27/2002

2 Copyright © Craig Larman. www.craiglarman.com

Defining our Terms: UP and RUP

? The RUP process framework is a detailed,

? RUP lead architect: Philippe Kruchten.

? Some use the term “UP” for “UP family” —

4 Copyright © Craig Larman. www.craiglarman.com

inc. elaboration construction transition

Work in early iterations emphasize:

Reqs Design Implement

inc. elaboration construction transition

6 Copyright © Craig Larman. www.craiglarman.com

7 Copyright © Craig Larman. www.craiglarman.com

8 Copyright © Craig Larman. www.craiglarman.com

UP Practice #4 and #5:

9 Copyright © Craig Larman. www.craiglarman.com

10 Copyright © Craig Larman. www.craiglarman.com

Other Key UP Ideas

Other Key UP Ideas

12 Copyright © Craig Larman. www.craiglarman.com

13 Copyright © Craig Larman. www.craiglarman.com

Useful, Common UP Artifacts

Use Cases Supplementary

14 Copyright © Craig Larman. www.craiglarman.com

When Work Products are Needed

? Use Case Model

? Software Architecture Document

15 Copyright © Craig Larman. www.craiglarman.com

Producers Domain Model

Sale Register ProductCatalog ...

Use Cases System Sequence Diagrams Use Case Diagrams

use-case Design Model

addLineItem( spec, quantity ) Data

Use Cases System Sequence Diagrams Use Case Diagram

17 Copyright © Craig Larman. www.craiglarman.com

Payment Customer Cashier

addLineItem( spec, quantity )

Register Sale Pricing

Inventory POSRuleEngine Taxes

Log4J Jess SOAP

19 Copyright © Craig Larman. www.craiglarman.com

Applies a UML Profile

20 Copyright © Craig Larman. www.craiglarman.com

21 Copyright © Craig Larman. www.craiglarman.com

Notation vs. Method Models

22 Copyright © Craig Larman. www.craiglarman.com

Three Modeling Perspectives (Cook & Daniels)

getLineItems : List of LineItem

dateTime: java.util.Date Implementation

Modeling Perspectives in a Sequence Dgm

24 Copyright © Craig Larman. www.craiglarman.com

Great moments in evolution

Adaptive Planning in the UP

Project is at this point (in the middle of an iteration)

Mitigate High “ Risks

27 Copyright © Craig Larman. www.craiglarman.com

Mitigate High “ Risks

Iter 1 Iter 2 Iter 3 Iter n-1 Iter n

28 Copyright © Craig Larman. www.craiglarman.com

Early Realistic Verification

Early evaluation —>

early feedback —>