1

Rational Unified Process - an overview

Uppsala, 2009-02-16

2

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

6

11

Why Iterations?

100%

Risk exposure

Stable Architecture

Time span til stable Architecture increases due to: •  Lack of experience: Software Development & Process knowledge •  New technology •  Magnitude of technical risks

Accuracy of estimates

Iterations

12

Riskprofile

Waterfall

Iteration Iteration Iteration Iteration Iteration Iteration Iteration

R I S K

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

Iterative

Time

R I S K

Iteration

Crew size RUP

M A N P O W E R

Iterations

7

13

Withdraw money

Transfer Between Accounts

ATM customer

Deposit Money

Use Cases

Use Cases

14

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…

Use Cases

8

15

Always question the requirements

Never

Mostly

Sometimes

How large portion of functionality is used?

Source: Butler Group

Use Cases

16

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!

Architecture

9

17

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.

What do they have in common?

Architecture

18

Models

Process Model

Use case

Actor

Class

Package

Use-case model

Node

Use case realization

Analysis/Design model Deployment model

Component

Implementation model

...with

Models

10

19

Modells for visualization

Actor Use Cases

Use Case

1: 2: 3: 4:

Objekt 1: Objekt 2: Objekt 3: Objekt 4:

1: 2: 3:

4: Objekt 1:

Objekt 2:

Objekt 3:

Objekt 4:

Scenario

UC realization

Klass 1

Klass 2

Klass 3

Klass 4

Klass 5 Klass 6

Klass 7

Class diagram

Classes are grouped in packages

Classes in the Use Case

Component diagram

IDE

Source code

Build

Components

Visual modeling

Models

20

Use visualization

Models

11

21

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

 Question: When should test work begin?  What is the purpose of test?

Tests

22

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

Changes

12

23

Keep control of changes

Needs Benefits Req’s

Evaluate

Decide Plan Implement by plan

Changes

24

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?

13

25

RUP Overview

26

Inception

Objective:   To agree on project scope

14

27

Elaboration Objective:

 To make sure there is a technical solution

28

Construction Objective:

 Finalize the software by iteratively coding and testing in every iteration

15

29

Transition

Objective:  Deploy the software in the user’s environment

30

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

16

31

Challenges when using RUP  RUP is large – not easy to find the goodies  May lead to over-documenting  Risk of over doing!

32

Relations to others  Variants:

 Agile Unified Process  Essential Unified Process  OpenUP  ……….

 What about RUP vs Agile?

17

33

Reference list

 Philippe Kruchten, The Rational Unified Process, An Introduction, Third Edition, Addison Wesley, Boston, 2003, ISBN 0-321-19770-4.