1

Rational Unified Process

- an overview

Uppsala, 2009-02-10

2

Mikael Broomé

�Consultant

�M.Sc. LTH

�10 years in Software Development

�4 different RUP implementations

�Project Manager

�Mentor for Project Managers

�Applying more and more of agile

mindset and techniques

�E-Mail: Mikael.Broome@it-arkitekterna.se

2

3

Agenda

�Why a process for developing software?

�What is RUP?

�What is the “RUP-way” of developing software?

�How is RUP packaged?

�Advantages by using RUP?

�Challenges when using RUP?

�Relation to other processes?

4

A good project

�delivers the right solution:

�satisified Users

�satisfied Sponsor

�delivers in time

�delivers on budget

3

5

Challenges

Common challenges in software development

projects:

� Capture the “right” requirements.

� Requirement changes.

� Different parts of the system do not fit together.

� Small changes causes big problems.

� Low quality and poor performance.

� Major problems identified late in projects.

� Lack of communication.

� Difficult to estimate time and cost.

� Management of environment, platforms and tools.

6

It’s all about (lack of) communication

4

7

Agenda

�Why a process for developing software?

�What is RUP?

�What is the “RUP-way” of developing software?

�How is RUP packaged?

�Advantages by using RUP?

�Challenges when using RUP?

�Relation to other processes?

8

What is RUP and UML?

�RUP is a process for development of software that describes

�what should be performed (activities)

�who should do it (roles)

�what the result should be (artifacts).

�UML is a notation with defined symbols that

�is worked out by OMG (Object Management

Group)

�is used to make drawings (for example in software development).

5

9

Agenda

�Why a process for developing software?

�What is RUP?

�What is the “RUP-way” of developing software?

�How is RUP packaged?

�Advantages by using RUP?

�Challenges when using RUP?

�Relation to other processes?

10

RUP’s Six Best practices

1. Develop the systems in an iterative way. Driven by risk.

2. Manage the requirements with use cases.

3. Focus on the architecture. Build the system with well delimited components.

4. Model visually

5. Continuously review and test the system.

6. Manage changes in a controlled way

JW2

Bild 10

JW2 Presentation- The different best practices depend on each other and enforce each other. Iterative development for example, enables higher quality since the most important requirements can be developed and tested early when there is still time for changes.Note that the best practices limit themselves to the software engineeering ”department”. Thus they provide no substantial reduction of problems outside the ”engineering space”. There are for example no best practices for targeting the right market segment, or aligning the values of an organization. Some best practices, however, help addressing also problems outside the engineering space. Requirements management with use cases can for example be used to make sure that the targeted users will like the system.Managing requirements according to RUP means starting from a general 10-20 page vision of what the system should be, the use cases are then used to capture the detailed requirements with higher precision than a simple list of requirements of the style ”The system shall...”.One of the most elegant parts of the RUP and the UML is how it allows the three concepts to be integrated: use cases, architecture, and iterations. By integrating these elements, the process actuallyties together the perspectives of the Customer/User, with that of the Developers, and of the Project Manager/Steering Group. To be able to evolve these things in synch with each other in order to reduce risk is one of the key benefits of the process.

Övergång- Hur leda presentationen över till nästa bild.Johan Wallentin; 2007-07-12

6

11

Develop iteratively

12

Withdraw money

Transfer Between

AccountsATM customer

Deposit Money

Use Cases

7

13

Use case outline

1. ”Withdraw Money” starts when the Customer

inserts a card in the ATM.

2. The System checks the card and asks for a pin-

code.

3. The Customer enters a pin-code.

4. The System asks the Customer what to do next…

1. ”Withdraw Money” starts when the Customer

inserts a card in the ATM.

2. The System checks the card and asks for a pin-

code.

3. The Customer enters a pin-code.

4. The System asks the Customer what to do next…

14

Architecture

An architecture is

�an interrelationship of the parts

which forms a greater whole

�the most important drawings for the

system

�the bearing idea in the system solution

�something that really works/executes!

JW4

Bild 14

JW4 Presentation- The architecture of a system is not so tangible. It is almost a philosophical question. Compare it to the question of what an architecture of a house is. A pragmatic approach to software architecture is to talk of how we can describe the architecture.Of course we can say that even a malfunctioning system has an architecture. But then that is not veryinteresting, so we choose to talk of only the good system structures as architectures.

Övergång- Hur leda presentationen över till nästa bild.Johan Wallentin; 2007-07-12

8

15

Architecture (cont.)

An architecture is

�a definition of the shape in big

�a shape that makes functions possible

�a shape that makes properties possible like

�performance

�load balancing

�security

�availability

�adaptability

�extensibility.

16

Account

Customer panel

The power of visual modelling

Withdrawal interface

Deposit interface

Withdrawal handler

Transfer handlerBank customer

Deposit handler

Analysis model

FE14

Bild 16

FE14 Användningsfallet Withdraw money realiseras av gränsnittsklassen Customer panel, kontrollklassen Withdrawal handler och entitetsklassen Account.Användningsfallet Ta ut Pengar realiseras även av gränsnittsklassen Withdrawal interface.

Användningsfallet Transfer Between Accounts realiseras av gränsnittsklassen Customer panel, kontrollklassen Transfer handler och entitetsklassen Account.

Användningsfallet Deposit Money realiseras av gränsnittsklassen Customer panel, kontrollklassen Deposition handler och entitetsklassen Account.Användningsfallet Deposit Money realiseras även av gränsnittsklassen Deposition interface.

När bildspelet är klart ser man att gränsnittsklassen Customer panel och entitetsklassen Account används för att realisera flera användningsfall.Fredrik.Ekenstam; 2005-11-21

9

17

Models

ProcessModel

Use case

Actor

Class

Package

Use-case model

Node

Use case realization

Analysis/Design model Deployment model

Component

Implementation model

...with

FE15

18

Test continuously

Test levels in RUP:

�Unit test – done by developers

�Integration Test – done by developers

�System Test – done by testers, based on Use Cases

�Acceptance Test – done with user representatives, customer

Bild 17

FE15 Användningsfallsmodellen används för att fånga kraven på IT-systemet. Kunder, användare, utvecklare och testare använder sig av användningsfallmodellen i sitt arbete.

Design modellen är en ritning över IT-systemet. Designmodellen används av arkitekter och utvecklare.

Implementationsmodellen innehåller koden och mjukvaran som skall installeras såsom t. ex. .exe filer.

Driftsättningsmodellen innehåller hårdvarunoder och nätverkskopplingar.

Modellerna beskrivs med språket UML. I RUP finns det dokumenterat hur man skall gå tillväga för att utveckla modellerna. Fredrik.Ekenstam; 2005-11-21

10

19

Manage change in a controlled way

�Change Request of two

types:

�Requirement changes

�Defects = Bugs

�Deal with changes in a

controlled way involves:

�Considering

consequences before

saying Yes/No !

�Configuration Management:

�Version control

�Enables creation of builds

20

Agenda

�Why a process for developing software?

�What is RUP?

�What is the “RUP-way” of developing software?

�How is RUP packaged?

�Advantages by using RUP?

�Challenges when using RUP?

�Relation to other processes?

11

21

RUP Overview

22

Inception

Objective:� To agree on project scope

12

23

Elaboration

Objective:

�To make sure there is a technical solution

24

Construction

Objective:

�Finalize the software by iteratively coding and testing in every iteration

13

25

Transition

Objective:

�Deploy the software in the user’s environment

26

RUP on-line

14

27

Benefits of using RUP

�Well known model – good for experience exchange

�Clearer and more correct requirements

�Increased predictability

�More efficient use of resources

�Increased visibility into project status

28

Challenges when using RUP

�RUP is large – not easy to find the goodies

�May lead to over-documenting

15

29

Relations to others

�Variants:

�Agile Unified Process

�Essential Unified Process

�OpenUP

�……….

�What about RUP vs Agile?

30

Reference list

�Philippe Kruchten, The Rational Unified Process, An Introduction, Third Edition, Addison Wesley,

Boston, 2003, ISBN 0-321-19770-4.