[PDF] - Rational Unified Process - an overview Uppsala, 2009-02-10 Mikael PDF Document

SLIDE 1

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

SLIDE 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

SLIDE 3

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

SLIDE 4

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).

SLIDE 5

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

SLIDE 6

!

"!## ## $% &! '!$ !$ (')*++! ! # # ,'))(-!! ./ 01)!23 (1&4 ! $$ 56 789

:++;+;*

SLIDE 7

6

11

Develop iteratively

12 Withdraw money Transfer Between Accounts ATM customer Deposit Money

Use Cases

SLIDE 8

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!

<

SLIDE 9

!=!

$!! ,! / !$ 56 789

:++;+;*

SLIDE 10

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 handler Bank customer Deposit handler

Analysis model

>?*<

SLIDE 11

=9! 9$0$$

!$= =999$! =9/!=9$0 $$$= =92( 9$0$$ 2$= =92( 99$2 "99$9$0$= 989

>$?$:++@***

SLIDE 12

9

17

Models

Process Model Use case Actor Class Package Use-case model Node Use case realization Analysis/Design model Deployment model Component Implementation model ...with

>?*@

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

SLIDE 13

=9986$6 A9

$99 298 29$$ $ 6$3$$6 29669$$ ($6$)(-')$$698 $

>$?$:++@***

SLIDE 14

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?

SLIDE 15

11

21

RUP Overview

22

Inception

Objective:

To agree on project scope

SLIDE 16

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

SLIDE 17

13

25

Transition

Objective:

Deploy the software in the user’s environment

26

RUP on-line

SLIDE 18

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

SLIDE 19

15

29

Relations to others

Variants: Agile Unified Process Essential Unified Process OpenUP ………. What about RUP vs Agile?

30