You are on page 1of 25

Rational Unified Process

An Iterative and Incremental Approach

Presented By G.Keerthi Satya M.Tech. (S.E.) Roll. No: 11031D2507
1

What is the Rational Unified Process?
 

A software engineering process Process framework

2

Dynamic Structure: Iterative Development

The sequential, or waterfall, process is fine for small projects. An iterative process breaks a development cycle into a succession of iterations. A development cycle is divided into a sequence of four phases that partition the sequence of iterations. The phases are inception, elaboration, construction, and transition.
3

iterative and incremental process

Incremental development partitions a system by functionality  Early release starts with small, functional subsystem, later releases add functionality  Top part of this figure shows how incremental development builds up to full functionality Iterative development improves overall system in each release  Delivers a full system in the first release, then changes the functionality of each subsystem with each new release Many organizations combine iterative and incremental approaches

Why Iterative and Incremental
 

 

To get a handle on critical and significant risks early. To set forth an architecture to guide development. To provide a framework that handles change. To build up the system incrementally over time (rather than at the end). To provide a development process for more effective work. continuous integration Always have a worki ng model.
5

From sequential to an iterative cycle

6

Benefits of an iteration approach

The iterative approach accommodates changes in requirements and in implementation strategy. It confronts and mitigates risks as early as possible. It allows the development organization to grow, to learn, and to improve. It focuses on real, tangible objectives.

7

Each iteration has:
  

Project plan Workflows in order A release of the working product (internal) The release can in some cases be shown to the customer to get feedback.

8

Develop in small steps
 

Specify, design, implement a little. Integrate, test, and run each increment a little.

9

An Iteration is Not Hacking

Each iteration should be well planned, organized according to a project plan and workflows, and documented. The outcome should be predictable and the process should be repeatable.
10

Getting a Robust Architecture

By concentrating on the architecture in the inception and elaboration phases we can make changes to the architecture early in the process before the mass of the work on details is done.
11

Handling Changing Requirements

Users can see a working product early in the process and tell what they like or don't like about it. Developers also have a better understanding of how their piece fits into the big picture after seeing a working model. You can then talk about functions to be added or changed.
12

Allowing for Tactical Changes

A series of builds allows for graceful small changes in each build letting the system evolve itself.

13

Stakeholders can see evidence that the project is progressing with each iteration since there is a working product with the new functionality. Milestones for each iteration help keep on schedule better than just one due date at the end of the project.
14

Achieving Continuous Integration

Definition of Risk :Risk Management

Risk is the possibility of suffering loss, injury, disadvantage, or destruction.

]

Slide #15

Risks
  

Technical risks Project risks Business risks Success does not require winning big, but avoiding failure

CS427

5-16

Common risks
 

Projects get killed for same old reasons Use database of problems to identify risk
   

Assess risks Avoid risks Monitor risks you can’t avoid Manage risks

CS427

5-17

Managing risk

Iterations alleviate risk
 

Feedback Chance to try out new technology

 

Architecture should address known risks Rank use cases by customer priority and risk Management is responsible for nontechnical risk
CS427 5-18

Risk Analysis: Activities

Grouping
  

Eliminate redundant risks; Combine related risks; Link dependent risks One possible grouping - Organizational, Process, Product Schedule/budget, new technology/obsolescence, etc.

Quantification
  

Establish Measurement scale Measure probability, consequence, time frame Risk Exposure = Likelihood x Consequence

Ranking

Order of likelihood, consequence, exposure, time frame

Identifying Triggers

Define scenarios or conditions that indicate occurrence of a risk is imminent

Slide #19

Generic Software Project Risk Factors
Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues

L

M

H

Project Team Team Member Availability Application Experience

in place, little turnover expected; few interrupts for fire fighting extensive experience in team with projects like this extensive experience with this process

available, some turnover expected; some fire fighting some experience with similar projects some experience with this process or extensive experience with another training for some areas not available or training planned for future

high turnover, not available; team spends most of time fighting fires little or no experience with similar projects little or no experience with a defined process

Experience with Process

Training of Team

training plan in place, training ongoing

no training plan or training not readily available

Slide #20

Risk Mitigation
•Prioritize risks by triggers, exposure and timeframe. Deal with the most critical first. •All non-negligible risks must have mitigation strategies. •Obtain more information as necessary to eliminate or reduce uncertainty •Document decisions and strategies

Slide #21

Risk Mitigation : Activities

Risk Reduction

Take action to reduce risk -hold training, add resources, reduce scope of project, etc. Have resources (money, staff, equipment, etc.) available to handle occurrence of risk Get someone else to accept the risk – not recommended – if done, keep tracking the risk Live with it – appropriate only for low consequence risks

Risk Contingency

Risk Transfer

Risk Acceptance

Slide #22

Risk Creeping user requirements

Mitigation Requirements elicitation - consult stakeholders early, plan for requirements growth (10% per month) Planning (7% of system cost), cost estimation, communications Planning (Quality Assurance Plan), independent QA organization, training, IV&V Cost estimation, planning Planning (Configuration Management Plan), Training, Automated CM tools

Excessive schedule pressure Low quality

Cost Overruns Inadequate Configuration Control

Slide #23

Iteration and Incrementation
Work Quantity In Each Increment
Increment A Requirements Workflow Analysis Workflow Design Workflow Implementation Workflow Test Workflow High Medium Low Low Low Increment B Medium High High Medium Low Increment C Low Low High High Medium Increment D None Low Low Low High

Iteration and incrementation are used in conjunction with one another  There is no single “requirements phase” or “design phase”  Instead, there are multiple instances of each phase
Chapter 2A 24

Thank you

25