ICS 121: The Unified Process
Overview
- What is the (Rational) Unified Process?
- RUP Key Practices
- RUP Concepts
- RUP Phases
- RUP Workflows
- RUP Workers
- Who does what and when?
- Why use RUP?
- Some things to notice about RUP
What is the (Rational) Unified Proces?
- It is a comprehensive, practical software process defined and
promoted by Rational Software Corporation (now part of IBM).
- Based on traditional software engineering methods. Based on
experience with large software projects, but made simpler and more
broadly applicable.
- Emphasis is on UML and design
RUP Key Practices
- Develop software iteratively
- The team is forced to work through many types of problems early
- User feedback on early releases can inform later work
- Releases provide fairly trustworthy measures of progress
- Mangage requirements
- Other decisions are traceable back to specific requirements
- Individual requirements can be prioritized for each release
- Use component-based architectures
- Thinking in terms of components facilitates reuse and
separation of concerns
- Emphasize architectural decisions because they affect
how well the system can satisfy its requirements
- Visually model software
- UML makes design decisions clear and exposes design problems
- Design quality strongly product quality
- Continuously verify software quality
- Allows QA team to work all the time, not just a rush at the end
- Test results are objective measures of progress
- It is cheaper to fix problems sooner
- Control changes to software
- Written change requests facilitate clear communications
- Developers can safely work in parallel in their own working copy
- Change control board (CCB) can manage the risk of changes made
in given release
- Metrics on changes indicate progress, effort, and certain risks
RUP Concepts
- Worker
- A role that a person plays. E.g., designer,
programmer, tester.
- Activity
- A unit of work that a worker does. An activity
usually takes hours or days of effort. E.g., writing a use case,
coding a function, reviewing a design, or testing a component. Each
activity is done at some cost to the organization.
- Artifact
- A document, source file, or other piece of information
that is produced or used by a worker during an activity. Each
artifact is an asset to the organization.
- Workflow
- a sequence/flowchart of activities that result in
the production of desired artifacts. E.g., requirements, design,
implementation, testing.
- Iteration
- All the work that goes into producing an internal
release. This includes all the workflows needed to produce that
release. Each iteration emphasizes a subset of workflows based on
the phase.
- Phase
- A set of one or more iterations that together, at least,
satisfy a milestone criteria. Phases are analogous to waterfall
phases, except that all activities are done to different degrees in
each phase.
- Development cycle
- All the effort that goes into producing one
release of a product to the market. This is the largest unit of
scheduling.
RUP Phases
- Each phase is disctinct in it's goal. Different workers can
work on any workflow in any iteration, e.g., your programmer can
implement a prototype in the inception phase, but it is not itself
the goal for that phase.
- Inception
- What does the customer really want?
- What is our plan for this entire release? Is it feasible?
- How long will it take? how much will it cost?
- E.g., 6 weeks for v1.0.0, and 2 weeks for minor versions
- Elaboration
- How will the system work?
- Prove to ourselves that the design is good enough.
- E.g., 10 weeks for v1.0.0, and 2 weeks for minor versions
- Constrution
- Build and test the system.
- Fix problems as they are found.
- Create all documentation, data, etc.
- E.g., 20 weeks for v1.0.0, and 9 weeks for minor versions
- Transition
- Finish up the system and package it.
- Prepare the customer accept it, and our company's departments
to support it.
- Actually ship it and support it.
- E.g., 5 weeks for v1.0.0, and 1 week for minor versions
Who Does What and When?
|
One development cycle |
|
Inception |
Elaboration |
Implementation |
Transition |
|
Iter-1 |
Iter-2 |
Iter-3 |
Iter-4 |
Iter-5 |
Iter-6 |
Iter-7 |
Iter-8 |
Iter-9 |
| Requirements |
X |
X |
|
|
| Analysis |
X |
X |
|
|
| Design |
|
X |
X |
|
| Implementation |
|
|
X |
X |
| Test |
|
|
X |
X |
- Dark cells = workflow is emphasized in that phase
Why Use RUP?
- RUP has good old-fashioned software engineering principles.
Managers like RUP.
- RUP is an actual process, not just a process model
- It contains specific advice on specific activities
- When to do each activity and how much.
- Integrated tool support for the more formal artifacts (e.g.,
Rational Rose for UML)
- Document templates for less formal artifacts
- Adoption:
- In any process, one big challenge is getting everyone to have
the same understanding of the process.
- In any process, another big challenge is having too many
people trying to define, refine, or change the process. Process
definition is often tied into office politics. More vocal or
eloquent people can have undue influence.
- A unique feature of RUP is that it can be purchased: books,
tools, training, templates, project websites, etc.
- As a result, adopting RUP can deflate some arguments over
process and make the whole team focus on actually carrying out the
process.
- RUP has enough adoption to make it a marketable job skill.
Some things to notice about RUP
- Similar to the synch-and-stablize model:
- iterative development
- parallel work by different workers with different skills
- process guidance emphasizes both risk management and
time-to-market
- Details of the process are built into the tools and document
templates.
- There is no maintenance phase. Further changes are always made
as part of a new development cycle.
example use case templatesample test plan templateProject plan template