RUP for Software Development Projects

(1)

1 1

RUP RUP

for Software Development Projects for Software Development Projects

George Merguerian Business Management Consultants

www.BMC-Online.com

Business Management Consultants Specialists in Global Project Management™

Brussels Frankfurt Houston Istanbul Milan Ottawa Shanghai Singapore Warsaw Washington DC

Official

(2)

33

© BMC 2007 Business Management Consultants

Project Managed Project Managed

4 4

Agenda Agenda

z z IT Project Management Developments IT Project Management Developments

z z Agile Approaches and characteristics Agile Approaches and characteristics

z z RUP RUP

z z Where do RUP and PMBOK Where do RUP and PMBOK

^®^®

meet? meet?

z

z Challenges Challenges

(3)

55

IT Project

IT Project Developments Developments

z z 1 out of 3 IT projects fail – 1 out of 3 IT projects fail – Standish Group, PM Network Standish Group, PM Network .. ..

z z BMC BMC ’s experience indicates a higher failure ratio ’ s experience indicates a higher failure ratio (Europe)

(Europe)

z

z Most failures occur because … Most failures occur because …. .

zz

Poor coupling of Projects to the Business Process/Strategy Poor coupling of Projects to the Business Process/Strategy

z

Inadequate funding and resourcing Inadequate funding and resourcing of the project of the project

z

Inadequate IT technical competence of team members Inadequate IT technical competence of team members

zz

Poor planning and control processes Poor planning and control processes

Key Reasons for Project Failure Key Reasons for Project Failure

1. Inadequately trained and/or inexperienced project managersÎPoor effort estimation

2. Failure to set and manage expectations ÎPoor communications

3. Poor leadership at any and all levelsÎMisalignment between the project team and the business or other organization it serves

4. Failure to adequately identify, document and track requirementsÎ Inadequate or misused methods

5. Poor plans and planning processesÎPoor planning, control, change management

6. Poor or no Methodology

(4)

77

PM Approaches PM Approaches

1950s Classical PM – SSDM/CMM/ISO etc

Incremental/Iterative Approaches

Rational Objectory Process ÎRUP (1998) 1997

1980s

1990s Agile Methods

Objectory Process

Rational Approach 1996

8 8

“Agile “ Agile” ” Methodologies Methodologies

z z ASD, Adaptive Software Development ASD, Adaptive Software Development

z

z Crystal Clear Crystal Clear

z z DSDM, Dynamic Software Development Method DSDM, Dynamic Software Development Method

z

z FDD, Feature Driven FDD, Feature Driven

z z RAD, Rapid Application Development RAD, Rapid Application Development

z z RUP, Rational Unified Process RUP, Rational Unified Process

z

z Scrum Scrum

z z XP, Xtreme XP, Xtreme Programming Programming

z

z …. … .

(5)

99

Comparing Classical and Agile Project Comparing Classical and Agile Project

Management Approaches Management Approaches

Common Principles of Agile Approaches Common Principles of Agile Approaches

zz

Iterative approach to software development Iterative approach to software development

z

Time- Time -boxed iteration periods boxed iteration periods

zz

Agile processes can handle requirements change during the Agile processes can handle requirements change during the project

project’ ’s development cycle s development cycle

z

Risk management is a key process Risk management is a key process

z

Emphasize communications and interaction Emphasize communications and interaction

zz

Emphasize resource competency and involvement Emphasize resource competency and involvement

(6)

1111

Classical Project Management (waterfall)

Quality

(Planned Results)

Resource

(Budget)

Schedule

(Time)

Well Defined Needs of the Customer

Agile/Dynamic Project Management

Quality

(Planned Results)

Resource

(Budget)

Schedule

(Time)

Customer Requirements not fully defined

12 12

(7)

1313

Iterative Approach

Iterative Approach – – What is it? What is it?

zz

The project produces a certain % of the ultimate product during The project produces a certain % of the ultimate product during each iteration (cycle) of the workflows below

each iteration (cycle) of the workflows below

z

Number of iterations depends on the complexity of the project Number of iterations depends on the complexity of the project

Each Iteration results into executable software

Iterative development Versus

Iterative development Versus “ “Waterfall Waterfall” ”

zz

Each iteration builds on the previous one Each iteration builds on the previous one

zz

Each step comes closer to the final product Each step comes closer to the final product

zz

Emphasis changes with each iteration Emphasis changes with each iteration

(8)

1515

Waterfall Cycle Waterfall Cycle

The project Moves from The project Moves from Analysts send requirements

Analysts send requirements Î Î Designers Î Designers Î Programmers send components Programmers send components Î Î Integrators I ntegratorsÎ Î Testers T esters

Î Î ‘poor ‘ poor’ ’ responsibility for the final product. responsibility for the final product.

16

Waterfall Cycle

1.Now is the time for men in the ranks to stay in the ranks.

10. Now is the time for men in the ranks to stay in the ranks.

11. Now is the time for men in the ranks to stay in the ranks.

Capture requirements

Analyse

Design

Code 2 months

1 month

4 months

12 months

2 months What if changes from requirements

are identified at this stage?

Integration and Testing

(9)

1717

Waterfall approach Waterfall approach

Iterative approach Iterative approach

Iterative approach advantages Iterative approach advantages

z z Easier to meet changing requirements (main cause Easier to meet changing requirements (main cause of trouble for IT/IS projects)

of trouble for IT/IS projects)

z

z Integration becomes easier (not the big thing at the Integration becomes easier (not the big thing at the end) end)

z z Risks are discovered earlier Risks are discovered earlier

z

z Management can make changes to the product Management can make changes to the product

z z Team members gain expertise as they assume Team members gain expertise as they assume several roles during each development

several roles during each development cycle/iteration.

cycle/iteration.

(10)

1919

Comparing Classical and Iterative PM Comparing Classical and Iterative PM

Waterfall

Iterative

Low Ceremony High Ceremony

CMM

Lean DSDM XP Crystal Lite Orange

RUP

Classical- SSDM

Little Documentation Light Process

Plan-Driven, Well-Documented,

Traceability, Change Control Board Hybrids

Manzo – AgileTek Code Agile Plus Boehm-Turner Risk Based

20 20

Source: www.controlchaos.com

Example of an Iterative Approach - SCRUM

(11)

2121

Introducing

Introducing RUP RUP

Why RUP?

z

Addresses the requirements understanding challenge in IS Addresses the requirements understanding challenge in IS

z

Allows for requirements refining during the project lifecycle Allows for requirements refining during the project lifecycle

z

Risk Driven Risk Driven

zz

The user gets involved throughout the project’ The user gets involved throughout the project ’s lifecycle and do s lifecycle and do not get

not get … ….. ..

(12)

2323

24 24

RUP and the Spiral Model RUP and the Spiral Model

The Spiral Model proposed by Barry W. Boehm

(13)

2525

Develop Iteratively Develop Iteratively

Risk Driven Risk Driven

Manage Requirements Manage Requirements

Fix Architecture early Fix Architecture early

Use Components Use Components

Model Visually Model Visually

Manage Change Manage Change

Key RUP Concepts Key RUP Concepts

1. Key RUP Concept

1. Key RUP Concept – – Develop Iteratively Develop Iteratively

(14)

2727

A RUP Project Lifecycle A RUP Project Lifecycle

28

2. Key RUP Concept – Address risks early

Risks

Time Waterfall

Iterative

Risk Reduction

(15)

29

3. Key RUP Concept: Manage Requirements

Business Requirements

User Requirements

Business Rules

System Requirements

Functional Requirements

Quality Attributes

External Interfaces

Constraints

Software Requirements Specification Use Case Document

Vision & Scope Document

Source: Karl E. Wiegers

Requirements Development

(16)

3131

4. Key RUP Concept

4. Key RUP Concept – – Establish the Architecture Baseline Establish the Architecture Baseline Early

Early

z

A project’ A project ’s technical risks can be mitigated by implementing and s technical risks can be mitigated by implementing and testing the architecture early.

testing the architecture early.

zz

A stable architecture facilitates communications and makes it A stable architecture facilitates communications and makes it easier to see the impact of changing requirements on the easier to see the impact of changing requirements on the system.

system.

zz

Establishing the architecture early facilitates the estimation of a Establishing the architecture early facilitates the estimation o f a project

project’ ’s effort. s effort.

32 32

5. Key RUP Concept

5. Key RUP Concept - - Build a components Build a components based system

based system

Applications built with components are more resilient to change Applications built with components are more resilient to change and and have reduced system maintenance costs. Components facilitate have reduced system maintenance costs. Components facilitate reuse, allowing you to build higher quality applications faster reuse, allowing you to build higher quality applications faster than than using functional decomposition.

using functional decomposition.

Functional decomposition Component based architecture

(17)

3333

6. Key RUP Concept

6. Key RUP Concept – – Model Visually Model Visually

RUP is a Model

RUP is a Model- - Based Development Process. Models are Based Development Process. Models are

abstractions of reality and help to make communications between abstractions of reality and help to make communications between stakeholders more effective

stakeholders more effective

7. Key RUP Concept

7. Key RUP Concept – – Accommodate change early Accommodate change early

z Changes that come late into the project mean rework, increase in costs, reduce quality, and cause schedule delays.

z The graphic below shows the impact of change on a

project’s costs during its lifecycle.

(18)

3535

Managing Change Requests and Configuration Management

36 36

How The Development Lifecycle is Managed in RUP How The Development Lifecycle is Managed in RUP Process?

Process?

z

Dynamic Elements: Dynamic Elements: The horizontal (Time) dimension of the The horizontal (Time) dimension of the project expressed in phases, iterations and Milestones.

project expressed in phases, iterations and Milestones.

z

Static Elements : Static Elements : The vertical dimension describes how The vertical dimension describes how process elements

process elements — — activities, workflows, artifacts activities, workflows, artifacts, and roles , and roles — — are logically grouped into core process disciplines.

are logically grouped into core process disciplines.

(19)

3737

Dynamic

Dynamic Elments Elments – – 4 phases: 4 phases:

1.1.

Inception Phase: Inception Phase :

zzUnderstand the scope of the project, Functional and non-Understand the scope of the project, Functional and non-Functional requirements, build Functional requirements, build the business case and get stakeholders

the business case and get stakeholders’’buy-buy-in.in.

2.2.

Elaboration Phase: Elaboration Phase :

z

zMitigate key technical risks and develop an architecture baseline.Mitigate key technical risks and develop an architecture baseline.

3.3.

Construction Phase: Construction Phase :

zzBuild the operational version of the product Build the operational version of the product 4.4.

Transition Phase: Transition Phase :

zzBuild the final version of the product and deliver it to the customer Build the final version of the product and deliver it to the customer

Dynamic Aspect of RUP Dynamic Aspect of RUP

z

A phase is a period of time between two major milestones of the project

¾

Each phase has exit criteria to ensure that objectives are met, artifacts are finalized. Upon satisfaction of the key stakeholders a decision is made whether to proceed to the next phase.

z

An iteration is like a mini project with defined sequence of activities

¾

Each iteration has a plan and criteria for success.

Changes in requirements

(20)

39

RUP Lifecycle in terms of Schedule and Effort

10%

50 % 30 %

10 % Schedule

10%

65 % 20 %

~5 % Effort

Transition Construction

Elaboration Inception

40 40

Static Elements: 9 Core Process Disciplines Static Elements: 9 Core Process Disciplines

zz

Logical grouping of the process elements- Logical grouping of the process elements - activities, activities, workflows,

workflows, artifacts artifacts and roles encapsulated into nine core and roles encapsulated into nine core process disciplines:

process disciplines:

1.1.

Business modelling Business modelling

2.2.

Requirements Requirements

3.

Analysis and Design Analysis and Design

4.

Implementation Implementation

5.5.

Test Test

6.

Deployment Deployment

7.

Configuration and change management Configuration and change management

8.

Project management Project management

9.9.

Environment Environment

(21)

4141

A Core Process Discipline:

z

Groups 4 process elements together Groups 4 process elements together – – activities, workflows, activities, workflows, artifacts

artifacts and roles and roles

Designer Use Case

Analysis

Use Case Design

Activities Roles

Artifacts – Use case realisation

The Concept of Role, Activity and

The Concept of Role, Activity and Artifact Artifact are central are central for RUP

for RUP

(22)

4343

Roadmap of RUP Workflows, Roles and Artefacts Roadmap of RUP Workflows, Roles and Artefacts

(Snapshot taken from IBM RUP Builder)

44 44

An Example of a Key Artefact

An Example of a Key Artefact – – The vision The vision Document

Document

zz

Who needs the project Who needs the project

zz Who will use itWho will use it

z

z The benefits of the project , what problem it will solve..The benefits of the project , what problem it will solve..

zz Key deliverables, Key features (use cases) Key deliverables, Key features (use cases)

z

z Non-Non-functional requirementsfunctional requirements

zz

The benefits that the application will produce – The benefits that the application will produce – business- business -wise, the wise, the problems it will solve, risks

problems it will solve, risks

zz

Who are the key stakeholders Who are the key stakeholders

zz

What will the product do – What will the product do – key use cases key use cases

zz

Non functional requirements – Non functional requirements – database support, OS related database support, OS related issues,

issues, scaleability scaleability etc. etc.

The Vision document is updated regularly

The Vision document is updated regularly – – it is like a contract it is like a contract

document between the clients of the project and the project team

document between the clients of the project and the project team. .

(23)

45

I The Problem The current reporting system and structure at the Unit are inadequate. There are too many activities (critical and non- critical) which are being reported on. The situation is of an over-reporting one.

The Head of the Unit requires a new reporting system which captures key information visually and yet allows more in depth probing if necessary. ….

II The benefits of a new system

A reporting system of the above nature will save the head of the Unit 6 hours per week allowing him to focus on areas of priority. The system will also enable for reports to enter information on a centralized basis which is then automatically consolidated for viewing by the Directors.

….

III Key deliverables of the project

• A Secure report entry tool

• A database

• Report output based on a Dashboard system – visual with links to the projects being reported on.

• ..

III Non-Functional requirements

• The system should be flexible enough to allow future changes in the reporting structure. Easy addition of new Reports

• Potential links to other reporting systems that may be developed

• Capability for web based report generation.

IV Current Environment See Figure 1 (slide) V Proposed Solution See Figures 2 and 3 (slide)

VI Stakeholders ^• The Directorate: Receiving the reports of the Unit. A visual Dashboard system will be easier to follow and save time.

• The Director of the unit: the initiator of this project.

• The Reports: will welcome an automated reporting system. However may loose influence towards the leaders as data will be consolidated. Also some of the activities will loose their current visibility/importance of the work done.

• The DG: The DG may wish to consolidate such initiatives that may be undertaken in other directorates.

• The IRM of the DG. Will need to find time and space for the project.

• DIGIT: May have a similar tool in place.

VII Risks & Constraints • Business changes Î Transfer

• Missing Input Î Mitigate – interact with users

• Users do not like to use application Î mitigate/transfer

• Access rights/Data Protection – Do not care VIII Resources Initial Estimates:

• 200 Person Days involving:

o System Analyst o Architect o Programmer o Dbase specialist

Example of vision

Features (needs)

•Filtering of activities

•Planned work/Actual/Issues/Risks (input)

•Security (Role Based Access)

•Historical Trend (nice to have?) Assumptions/Risks

•Report types can evolve

•No other points of extensibility

•Weekly based process

•Data input is reliable

Resources

•1 Analyst Designer

•1 PM

•1 DB Expert

•2 Developers (GUI)

•1 Tester

Iterations

Inception - 5% of effort – 1 iteration Elaboration - - 25 % 1 or 2 iterations

Iteration 1 – Technical Architecture; Initial SW; Mitigate Key Technical risks: output function, input function.

Construction – 60% - 2 iterations

Vision Document Figure 2:

System Perspective

(24)

47

Use Case Example – Input Data

“Happy Scenario”

1. User Logs in

2. Select User’s Projects 3. Display projects 4. Select project for

editing 5. Edit

6. Save information 7. Back to list

User Dbase

Controller (checks ECAS)

Login rejected

No Project Details Found Display

Display Login

Catalogue

Request Project

Select Project for Edit Display Project Details

Edit Project Update Dbase Enter History Display Updated

Project Details

48 48

Key RUP Artefacts Key RUP Artefacts

z z Principal Principal

z

Vision Document Vision Document

zz

Glossary Glossary

z

Architecture Architecture

z

Software Software

zz

Configuration Management Plan Configuration Management Plan

z

Test Plans, Scripts, Results Test Plans, Scripts, Results

z

User Support Manuals User Support Manuals

z z Support Support

z

Software Development Plan Software Development Plan

zz

Software Architecture Document Software Architecture Document

z

Iteration Plan Iteration Plan

z

Risk Plan Risk Plan

(25)

4949

The RUP Process Framework The RUP Process Framework – – Dynamic & Static Elements Dynamic & Static Elements

RUP Templates and Support Tools

(26)

5151

Software is Available to Support The RUP Process Software is Available to Support The RUP Process

52 52

Where do RUP and Project Management (PMBOK

Where do RUP and Project Management (PMBOK® ®) Meet? ) Meet?

zz

Starting a project, a phase or an iteration and reviews – Starting a project, a phase or an iteration and reviews – Project Project Management

Management

zz

Configuration management, production releases and change Configuration management, production releases and change management

management

z

Measuring Progress Measuring Progress

PMBOK^®is Project Management Institute’s standard for managing projects – Project Management Body of Knowledge

(27)

5353

The PMBOK Process Groups The PMBOK Process Groups

Key Outputs (

Key Outputs (Artifacts Artifacts) of the PMBOK ) of the PMBOK ^® ^® Process Groups

Process Groups

Admin/Contractual Closure Admin/Contractual Closure Closing

Closing

Progress reports, Scope Progress reports, Scope Verification, Time, $, Risk Verification, Time, $, Risk and Q control

and Q control Execution and Control

Execution and Control

The Project Execution Plan The Project Execution Plan Planning

Planning

Project Charter Project Charter Initiation

Initiation

(28)

5555

The Project Management Core Discipline in RUP The Project Management Core Discipline in RUP

56 56

Project Management

(29)

5757

Elaboration Phase

Elaboration Phase – – Revised Planning Revised Planning

10 W10 W 10 W 10 W 6 W6 W 1 W1 W Revised Revised (Weeks) (Weeks)

24 D24 D 24 D 24 D 15 D15 D 4 D4 D Revised Revised (Days) (Days)

2 D 2 D 4 D4 D Actual Actual (Days) (Days) Inception

Inception

Functional Prototype Functional Prototype Database

Database 10 D10 D

4 W4 W 1 Iteration

1 Iteration Elaboration Elaboration

Manual & Training Manual & Training 10 D10 D

2 W2 W 1 Iteration

1 Iteration Transition Transition

Dashboard V Final Dashboard V Final Drill Down Drill Down 30 D30 D

12 W12 W Iteration 2

Iteration 2

Dashboard V 1.0 Dashboard V 1.0 30 D

30 D 12 W

12 W Iteration 1

Iteration 1 Constructio Constructio n

n

Final & all Use Cases Final & all Use Cases Architecture & SAD (LCA) Architecture & SAD (LCA) 6 D

6 D 2 W

2 W 1 Iteration

1 Iteration

4 Use Cases 4 Use Cases 2 D

2 D 1 W

1 W 1 Iteration

1 Iteration

Vision (LCO) Vision (LCO) 3 D3 D

1 W1 W 1 Iteration

1 Iteration

Artefacts Artefacts Effort

Effort (Days) (Days) Time

Time (weeks) (weeks)

Difficult to compare.. PMBOK

^®^®

Outputs and RUP Outputs and RUP Artifacts

Artifacts

Config

Config. Management . Management

………

……….. ..

Config

Config. Management . Management

………

……….. ..

Software, Progress reports, software, Software, Progress reports, software, test results

test results… … Software, Progress reports, software,

Software, Progress reports, software, test results

test results… …

Vision Document and Software Vision Document and Software Development Plan

Development Plan The Project Execution Plan

The Project Execution Plan

Vision Document Vision Document Project Charter

Project Charter’ ’s Problem definition s Problem definition and Business Case

and Business Case

(30)

5959

RUP RUP

z z Project Management is one of the core disciplines Project Management is one of the core disciplines

z z Each iteration is like a project Each iteration is like a project

z z Risk management occurs throughout the lifecycle Risk management occurs throughout the lifecycle of the project

of the project

z

z Team roles change according to phase Team roles change according to phase

z z RUP is a comprehensive methodology packaged RUP is a comprehensive methodology packaged into a product by IBM (though UP is open to public) into a product by IBM (though UP is open to public)

z

z RUP does not cover how you can use PM tools RUP does not cover how you can use PM tools

60 60

RUP Challenges RUP Challenges

z z Applying RUP in tendering situations – Applying RUP in tendering situations – involving involving contractors

contractors

z

z Documentation- Documentation - notion that projects are over- notion that projects are over - planned

planned

z z Organisational readiness to work with X- Organisational readiness to work with X - disciplinary teams

disciplinary teams

z z Involving end users Involving end users

z z Relatively lower maturity across non- Relatively lower maturity across non -IT/IS IT/IS

companies in using RUP (Budget flexibility, teams, companies in using RUP (Budget flexibility, teams, etc.)

etc.)

(31)

6161

Reflections on Contractors Reflections on Contractors

z z Most customers prefer fixed price contractsÎ Most customers prefer fixed price contracts Î stable stable requirements

requirements

z z Fixed Price Contracts and requirements change do not fit Fixed Price Contracts and requirements change do not fit in RUP

in RUP Î Î Customer needs to accept scope flexibility if T Customer needs to accept scope flexibility if T and $ are fixed

and $ are fixed

z z In IT visualisation of the end product difficult – In IT visualisation of the end product difficult – RUP RUP involves the customer in each iteration

involves the customer in each iteration Î Î no surprise at no surprise at the end

the end

When to sign a contract?

?

(32)

6363

The 7

The 7 Sins Sins of RUP of RUP

1. 1. Planning to death Planning to death

2. 2. Detailing too much Detailing too much

3. 3. Skipping Problem Analysis Skipping Problem Analysis

4. 4. Letting end dates of iterations slip Letting end dates of iterations slip

5. 5. Starting the construction phase before fulfilling the exit Starting the construction phase before fulfilling the exit criteria of the elaboration phase

criteria of the elaboration phase

6. 6. Testing only at the end of the project Testing only at the end of the project

7. 7. Failing to move the product to maintenance Failing to move the product to maintenance

Adopting the Rational Unified Process

Adopting the Rational Unified Process ––Stefan Stefan BergstrBergströömmand Lottaand LottaRabergRaberg

64 64

RUP Concluding remarks RUP Concluding remarks

z z Results into high quality software Results into high quality software

z z Less customer surprises than traditional Less customer surprises than traditional

z

z Well supported product Well supported product

z z Large community of users - Large community of users - RUP and UP user RUP and UP user groups

groups

z z Needs organisational support for success Needs organisational support for success

z z Select methodology according to your own needs Select methodology according to your own needs

(33)

6565