rational unified process - an overview uppsala, 2009-02-16uppsala, 2009-02-16 2 2 3 agenda why a...
TRANSCRIPT
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.