The document provides an introduction to the Rational Unified Process (RUP). It discusses what a software engineering process is, limitations of the waterfall model, and an overview of RUP. RUP is an iterative software development process framework that is use case driven and architecture-centric. It consists of four main phases - inception, elaboration, construction, and transition - with milestones used to transition between phases. The goal is to deliver working software incrementally throughout the project lifetime.

1. Unified Process
Introduction to Rational Unified process
Martin Terreni

2. Agenda
• What is a software engineering process?
• Waterfall model
• What is RUP?
• Why RUP?
• RUP workflows and phases
• RUP BKP
• Summary
• Bibliography

3. What is a software engineering
process?
• First –what is not?
– It is not UML! (it is not any modeling or coding
language at all!)
– It is not planning MPOR Items and there
schedule (though it is related…).
– It is not writing lot of IPS, EPS and other over
head docs (and if it is all you are doing
something wrong).

4. What is a software engineering
process?
• Then what IS IT?
– Who is doing what, when and how (and
WHY!!)

5. Waterfall model
Completely understand requirements, finish
design, code, test
and only then implement.

6. Waterfall Process Assumptions
• Requirements are known up front before
design
• Requirements rarely change
• Users know what they want, and rarely need
visualization
• Design can be conducted in a purely abstract
space, or trial rarely leads to error
• The technology will all fit nicely into place when
the time comes (the apocalypse)
• The system is not so complex. (Drawings are
for wimps)

7. What is RUP?
“a web-enabled software engineering
process that enhances team productivity
and delivers software best practices to all
team members”
The Rational Unified Process, 2nd Edition

8. What is RUP?
• RUP is a method of managing OO Software
Development
• It can be viewed as a Software Development
Framework which is extensible .

9. What is RUP?
The Spirit of RUP:
• Attack major risks early and continuously…or
they will attack you.
• Ensure that you deliver value to your
customer.
• Stay focused on executable software.
• Accommodate change early in the project.
• Baseline an executable architecture early on.
• Build your system with components.
• Work together as one team.
• Make quality a way of life, not an
afterthought.

10. Why RUP?
1. It accommodates changing requirements
2. Integration is not one "big bang" at the end of a
project
3. Risks are usually discovered or addressed
during early integrations
4. Reuse is facilitated
5. Defects can be found and corrected over
several iterations
6. The development process itself is improved
and refined along the way

11. Workflows and phases
Management
Environment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Workflows
Iterations
Supporting Workflows
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
time
conten
t

12. Workflows and phases
Major Milestones

13. Workflows and phases
Phases and iterations

14. Workflows and phases
Three Types of Projects
• Project Ganymede, a green-field development of a small
application. The initial development cycle of a brand-new
application where everything, including the requirements,
have to be designed from scratch.
• Project Mars, a green-field development of a larger
system so that we can articulate the major difference with
the first example.
• Project Jupiter, an evolution cycle of an existing large
application (the "version 2.0"); this is more representative of
a large number of RUP projects, which only evolve existing
systems and do not create them from scratch.

15. Our project
Lets take an existing project that needs a
new improved version.
We have a simulation system for logic
circuits and a test plan DB.
The customer wants them to communicate
and work atumaticaly.

16. The Inception Phase
• In this phase a business case which includes: Business
context, Success factors such as (expected revenue,
market recognition, etc), and Financial forecast are
established. Besides a business case a basic use case
model, project plan, initial risk assessment and a
document that generally describes the project (the core
project requirements, constraints and key features) are
realized.

17. The Inception Phase
Objectives of the Inception Phase:
1. Understand what to build. Determine the vision, the scope of the
system, and its boundaries, that is, what is inside the system and
what is outside. Identify who wants this system and what it is worth
to them.
2. Identify key system functionality. Decide which use cases (which
ways of using the system) are most critical.
3. Determine at least one possible solution. Identify at least one
candidate architecture.
4. Understand the costs, schedule, and risks associated with the
project.
5. Decide what process to follow and what tools to use.

18. The Inception Phase
Lifecycle Objective Milestone
• Stakeholder concurrence on scope definition and an
initial cost/schedule estimate (which will be refined in
later phases)
• Agreement that the right set of requirements has been
captured and that there is a shared understanding of
these requirements
• Agreement that the cost/schedule estimate, priorities,
risks, and development process are appropriate
• Agreement that initial risks have been identified and a
mitigation strategy exists for each

19. The Elaboration Phase
• Elaboration is the second of the four phases in the RUP
approach. The goal of the Elaboration phase is to define and
baseline the architecture of the system in order to provide a
stable basis for the bulk of the design and implementation
effort in the Construction phase. The architecture evolves out
of a consideration of the most significant requirements (those
that have a great impact on the architecture of the system) and
an assessment of risks.

20. The Elaboration Phase
Objectives of the Elaboration Phase:
1. Get a more detailed understanding of the
requirements.
2. Design, implement, validate, and baseline
the architecture.
3. Mitigate essential risks, and produce more
accurate schedule and cost estimates.
4. Refine the development case and put the
development environment in place.

21. The Elaboration Phase
Lifecycle Architecture Milestone
• Are the product Vision and requirements stable?
• Is the architecture stable?
• Are the key approaches to be used in testing and evaluation
proven?
• Have testing and evaluation of executable prototypes demonstrated
that the major risk elements have been addressed and resolved?
• Are the iteration plans for Construction of sufficient detail and
fidelity to allow the work to proceed?
• Are the iteration plans for the Construction phase supported by
credible estimates?
• Do all stakeholders agree that the current Vision, as defined in the
Vision Document, can be met if the current plan is executed to
develop the complete system in the context of the current
architecture?
• Are actual resource expenditures versus planned expenditures
acceptable?

22. The Construction Phase
In this phase the main focus goes to the development of
components and other features of the system that is
being developed. This is the phase when coding takes
place.
At the end of this phase the first release of the software
product is expected and this is a major criterion of its
milestone.

23. The Construction Phase
Objectives of the Construction Phase
1. Minimize development costs and achieve
some degree of parallelism.
2. Iteratively develop a complete product that
is ready to transition to its user community.

24. The Construction Phase
Initial Operational Capability Milestone:
1. Is this product release stable and mature
enough to be deployed in the user
community?
2. Are all the stakeholders ready for the
transition into the user community?
3. Are actual resource expenditures versus
planned expenditures still acceptable?

25. The Transition Phase
The focus of the Transition phase is to ensure
that the software fully addresses the needs of its
users. The Transition phase normally spans one
or two iterations that include testing the product
in preparation for release and making minor
adjustments based on user feedback.

26. The Transition Phase
Objectives of the Transition Phase
1. Beta test to validate that user expectations are met.
2. Train users and maintainers to achieve user self-
reliability.
3. Prepare deployment site and convert operational
databases.
4. Achieve stakeholder concurrence that deployment
baselines are complete and consistent with the
evaluation criteria of the vision.
5. Improve future project performance through lessons
learned.

27. The Transition Phase
Product Release Milestone
• Are the users satisfied?
• Are actual resource expenditures versus
planned expenditures acceptable, and, if
not, what actions can be taken in future
projects to address this issue?

28. RUP BKP
1. Develop software iteratively
2. Manage requirements
3. Use component based architecture
4. Visually model software
5. Verify software quality
6. Control changes to software

29. Summary
The RUP is a software development approach
that is iterative, architecture-centric, and use-
case-driven.
It is actually a framework to be tailored to create
a suitable process for a specific project.
The transition between phases is done by mile
stones reached during iterations.
It has 6 main BKPs to follow.

30. Summary

31. Questions?

32. Bibliography
The Rational Unified Process Made
Easy: A Practitioner's Guide to the
RUP.
By Per Kroll, Philippe Kruchten