Download The Unified Process

Ivar Jacobson, Grady Booch, and James Rumbaugh
The Unified Software Development Process
Addison Wesley, 1999
1990: James Rumbaugh's OOMD
1992: Ivar Jacobson's Objectory
1993: Grady Booch's OOAD and diagrams
1995: Rational Software unites all three (“the three amigos”)
• Definition of unified process
• Definition of UML (Unified Modeling Language)
• Rational Rose toolset
2003: IBM buys Rational
Use multiple views
of the system
Class
diagram
Rambaugh et al.
Prentice-Hall
1990
Statechart
The Unified Process

Not really a process
–



Does not specify precisely what to do at each step
More of a framework
Needs to be adjusted to each project according
to need
Many refinements and extensions
–
Agile unified process
–
Enterprise unified process
Principles

Iterative and incremental
–

Use-case driven
–

Development is based on usage scenarios
Architecture centric
–

Four phases divided into multiple iterations
Defining and refining the architecture is a major
activity, baseline architecture a major milestone
Risk focused
–
Activities in initial phases designed to reduce risk,
Later phases fill details
Phases and Workflows
Phases and Workflows
Similar to doing
a waterfall in
each iteration
But each step in the
waterfall continues
across all iterations
Req’s
analyze
design
Not only the
diagonal!
code
test
Phases
Inception Phase
• Define scope
• What will the system do for users / stakeholders
• Use cases
• Establish business case
• Cost vs. expected benefit
• Need ideas for architecture and construction plan to
assess costs
• May discover that project is not worth doing
• Draw initial contract
• But maintain possibility of cancellation later
Elaboration Phase
• Fill in details of requirements and more use cases
• Identify and mitigate risks
• Use cases for requirements risks
• Prototypes for technical risks
• Use UML to create skeletal models
• Include only the important details
• Not high-level abstract models with no details
• Create baseline architecture
• Can change later
• Draw contract for whole system
Construction Phase
• Create a workplan
• Estimate time for each use case
• Decide on iteration time
• Assign use cases to iterations based on risk, priority,
and work capacity
• Execute iterations
• Maintain rhythm – if schedule slips move a use case
to a later iteration
• Test and integrate
• Refactor
Transition Phase
• First running system installed (beta test)
• Fix bugs based on user feedback
• Perform optimizations
• Do user training
Phase Milestones

Inception: figure out what this is all about, and
that it is feasible
Outcome: green light for the project

Elaboration: figure out how to actually do it
Outcome: project architecture and contract

Construction: now do it
Outcome: initial running system installed,
feedback from users
Phase Milestones

Inception: figure out what this is all about, and
that it is feasible
Outcome: green light for the project

Similar
Elaboration: figure out how to actually
do it to

Construction: now do it
Royce and
Outcome: project architecture and contract
Boehm
Outcome: initial running system installed,
feedback from users
Workflows
Workflows are Continuous

Exist in all phases and iterations

e.g. testing is done from the beginning

–
Even when there is no code to test
–
So test validity, completeness, and consistency of
whatever artifact was produced
–
And plan relevant future code tests
Relative weight may differ in different phases
Requirements Workflow
• Users don’t know what they want
• Hopefully they’ll know it when they see it
• Even when they know, they can’t specify it
precisely and fully
• Shakespeare / Bedazzled
• Exercise specifications in
courses
• Using formal methods
Example
There are multiple lights in the room.
Every light is controlled by a switch.
This just says: L S : S(L)
Example
There are multiple lights in the room.
Every light is controlled by a switch.
This just says: L S : S(L)
Could have two very different implementations:
L S : S(L)  K≠L ¬S(K)
S : L S(L)
Requirements Workflow
• Users don’t know what they need
• Hopefully they’ll know it when they see it
• Even when they know, they can’t specify it
precisely and fully
• Exercise specifications in courses
• Developers come from a different background
• Don’t know what the users assume is self evident
The requirements workflow is supposed to solve
these problems
Requirements Workflow
• Understand the domain (create domain model)
• Two types of requirements:
• Functional requirements (use cases)
• Non-functional requirements (performance, …)
• Maintain list of ideas
• Things may change during the project
• Identify things that were missed
• New ideas
• New external requirements (change in tax law)
Use Cases
• Tool to foster discussion of requirements
• Focus on goals for using the system
(what you want to achieve, not how you will do it)
• Identify roles / actors (not necessarily human)
• Identify interactions with system
• Expressed and recorded in use case diagrams
• Include scenario description
• Often also multiple failure scenarios
• Foreshadow agile user stories
Analysis Workflow
• Translate requirements from the language of the
client to the language of the designer
• Add considerations of system internals
• Resource usage and conflicts
• Use more formal notation
• Organize the requirements for easier handling
• First cut at design that will realize required use
cases
Design Workflow
• Shape the system and find a form that lives up
to requirements
• Less abstract then analysis
• More detailed realization
• Define subsystems and interfaces between
them
• Take constraints into account
Requirements / Analysis / Design
• Requirements are in the customer’s language
• Informal, intuitive
• Fill in background information and assumptions
• Analysis translates to the designer’s language
• Formalize
• Introduce implementation considerations
• Design re-shapes for implementation
• Detailed realization
Implementation Workflow
• Implement the classes in the design
• Integrate with results of previous iterations
• Map to platform
Test Workflow
• Unit tests for new code
• Integration tests for each build
• Regression tests: all previously passed tests
• System test at end of iterations
• Record tests and act on results (e.g. open
defect reports)