Rational Unified Process - an Overview Uppsala, 2009-02-10

Rational Unified Process - an overview Uppsala, 2009-02-10

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: [email protected]

1 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?

A good project

delivers the right solution: satisified Users satisfied Sponsor

delivers in time

delivers on budget

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

It’s all about (lack of) communication

3 Agenda

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

4 Agenda

JW2

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

5 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 actually ties 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 Develop iteratively

Use Cases

Withdraw money

ATM customer Transfer Between Accounts

Deposit Money

6 Use case outline

1.1. ”Withdraw ”Withdraw Money” Money” starts starts when when the the Customer Customer insertsinserts a a card card in in the the ATM.ATM. 2.2. The The System System checks checks the the card card and and asks asks for for a a pin- pin- code.code. 3.3. The The Customer Customer enters enters a a pin-code. pin-code. 4.4. The The System System asks asks the the Customer Customer what what to to do do next… next…

JW4

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!

7 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 very interesting, 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 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.

FE14

The power of visual modelling

Withdrawal interface Withdrawal handler

Account

Bank customer Customer panel Transfer handler

Deposit handler Deposit interface

Analysis model

8 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 FE15

Models

Analysis/Design Use-case model model Implementation model Deployment model

Component Node Actor Package

Use case Class

Use case realization ...with

Process Model

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

9 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 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 19

Agenda

10 RUP Overview

Inception

Objective: To agree on project scope

11 Elaboration

Objective: To make sure there is a technical solution

Construction

Objective: Finalize the software by iteratively coding and testing in every iteration

12 Transition

Objective : Deploy the software in the user’s environment

RUP on-line

13 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

Challenges when using RUP

RUP is large – not easy to find the goodies May lead to over-documenting

14 Relations to others

Variants: Agile Unified Process Essential Unified Process OpenUP ……….

What about RUP vs Agile?

Reference list

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