Rational Unified Process

Agenda
Part I: Introduction

Part II: Disciplines & Workflows

Part III: Phases & Iterations

Part IV: Configuring RUP

Introduction

Whats Rational?

Three important contributors Grady Booch (Booch Method) James Rumbaugh (OMT Method) Ivar Jacobson (OOSE Method)

Introduction

Why Unified?

Unification of Development Approaches using UML

Unification of the Work Of many Methodologists

Introduction

Whats Process?
Defines Who is What, When to do it, and How to reach a certain goal.

A Software Development Process is the set of activities needed to transform a users requirements into a software system[Jacobson]

Introduction

History Of RUP

Rational Unified Process 1998

Rational Objectory Process 1996-1997 UML

Objectory Process 1987-1995

The Ericsson Approach

6

Features

Process Product

Process must be built on Technologies Tools are integral to process People: limit the skill set needed to operate Organization Pattern "Software processes are software, too"

Balance

Features

Process Product

continue

Like a software product is based on UML

Is delivered online using Web technology, not in books or binders

Released by Rational Software approximately twice a year

Features

Process Framework

Rational Unified Process

Is specialized to

My Development Process Is enacted as

My Project

Features

The Architecture of RUP

time and the lifecycle

process disciplines or workflows

10

3+1 Keywords

The 3+1 Keywords

Architecture Centric
Use Case Driven

Iterative and Incremental

Risk Confronting

From USDP

11

3+1 Keywords

RUP is

Use Case Driven

Use-Case Model

Specified by Realized by Implemented by

Analysis Model
Design Model

Distributed by Verified by

Implementation Model

Deployment Model Test Model

12

3+1 Keywords

RUP is

Iterative & Incremental

Iteration 2
Requirements analysis Design Code and unit test

Iteration 1
Requirements analysis Design Code and unit test

Subsystem integration

Subsystem integration

System test

System test

13

3+1 Keywords

RUP is

Architecture Centric

Logical View
Analysts/ Designers Structure End-user Functionality

Implementation View
Programmers Software management

Use-Case View

Process View
System Integrators Performance Scalability Throughput

Deployment View
System Engineering System topology Delivery, installation communication
14

3+1 Keywords

RUP is
Inception

Risk Confronting
Focus on the 20% that really matter: The primary use cases The architectural components The driving scenarios

Architectural prototype Draft specifications & models

Elaboration
Initial executable system Refined specifications & models

R i s k Construction Iteration 3... Intermediate system

Transition
Final system

15

Part II

Process Disciplines & Workflows

16

Definition
Workflow The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business Core workflow A core workflow shows all activities you may go through to produce a particular set of artifacts. Workflow detail A grouping of activities which are performed in close collaboration to accomplish some result. The activities are typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Workflow details are used to group activities to provide a higher level of abstraction and to improve the comprehensibility of 17 workflows.

Workflows

Workflows in RUP

Core Process Workflows

Support Process

Workflows

18

Business Modeling
To understand the structure and the dynamics of the target organization). To understand current problems in the target organization and identify improvement potentials. To ensure that customers, end users, and developers have a common understanding of the target organization. To derive the system requirements needed to support the target organization

19

Workflows

Requirements

To agreement with stakeholders To provide system developers better understanding of the system requirements. define the boundaries of the system. To provide a basis for planning the technical contents of iterations. To provide a basis for estimating cost and time to develop the system. To define a user-interface for the system, focusing on the needs and goals of the users.

glossary

vision
20

Workflows

Analysis and Design

To transform the requirements into a design of the system to-be.
To evolve a robust architecture for the system. To adapt the design to match the implementation environment, designing it for performance.

21

Workflows

Implementation
To define the organization of the code, in terms of implementation subsystems organized in layers To implement classes and objects in terms of components (source files, binaries, executables, and others) To test the developed components as units To integrate the results produced by individual implementers (or teams), into an executable system.

22

Workflows

Test
To verify the interaction between objects.

To verify the proper integration of all components of the software.

To verify that all requirements have been correctly implemented. To identify and ensure defects are addressed prior to the deployment of the software.

Test Model

Test Case
23

Workflows

Deployment

The Deployment Workflow describes the activities associated with ensuring that the software product is available for its end users

24

Workflows

Environment

The environment workflow focuses on the activities necessary to configure the process for a project. The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team

25

Workflows

Configuration and Change Management

supports development methods maintains product integrity ensures completeness and correctness of the configured product provides a stable environment within which to develop the product restricts changes to artifacts based on project policies provides an audit trail on why, when and by whom any artifact was changed.

26

Workflows

Project Management
To provide a framework for managing softwareintensive projects. To provide practical guidelines for planning, staffing, executing, and monitoring projects. To provide a framework for managing risk.
NOT Managing people: hiring, training, coaching Managing budget: defining, allocating, etc. Managing contracts, with suppliers and customers
27

Workflows

Key Concepts

28

Workflows

Implementation Workflow
Structure the Implementation Model

Plan the Integration

Implement Components

Implement Components

[more components to implement in this iteration] [more subsystem integration for this iteration]
[more system builds for this iteration]

Implement Components

29

Workflow Details

Structure the Implementation Model

Design Model

Artifact Activity

Worker
Use-Case Specifier Structure the Implementation Model Software Architecture Document

Implementation Model
30

Activity: Structure the Implementation Model

Purpose To establish the structure in which the implementation will reside. To assign responsibilities for Implementation Subsystems and their contents.

Steps Create the initial implementation model structure Adjust implementation subsystems Define imports for each implementation subsystems Decide how to treat executables (and other derived objects) Decide how to treat test assets Update the implementation view Evaluate the implementation model Input Artifacts: Software Architecture Document Supplementary Specifications Design Guidelines Design Model Resulting Artifacts: Implementation View section of the Software Architecture Document Implementation Subsystems Implementation Model

Worker: Architect Guidelines: Guidelines: Implementation Subsystems Tool Mentor: Structuring the Implementation Model Using Rational Rose Setting Up the Implementation Model Using Rational ClearCase

31

Artifact: Software Architecture Document

Software Architecture Document Worker: Template: Microsoft Word Template HTML Template Examples: Course Registration System Collegiate Sports Paging System (e-Business) The Software Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. Architect

More Information: Checkpoints: Software Architecture Document Guidelines: Software Architecture Document

Purpose Brief Outline Timing Responsibility Tailoring Annotated Outline (hyperlinks into HTML template in a new window)

32

Checkpoints: Design Model

Topics General Layers General Layers The design appears to be understandable and maintainable There are no more than seven (plus or minus two) layers. The model appears to be able to accommodate reasonably expected future The design appears to be implementable change. The design is appropriate to the task at hand (neither too complex nor too advanced)

The rationale for layer definition is clearly presented and consistently applied.

33

Use-Case SpecificationHTML Template

<Project Name> Use Case Specification: <Use-Case Name> Version <1.0>

Use Case Specification: <Use-Case Name> 1. Use Case Name [The following template is provided for a Use-Case Specification, which contains the textual properties of the use case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use case properties] [The diagrams of the use case can be developed in a visual modeling tool, such as Rational Rose. A use-case report (with all properties) may be generated with Rational SoDA. For more information, see the tool mentors in the Rational Unified Process.] 1.1 Brief Description [The description should briefly convey the role and purpose of the use case. A single paragraph should suffice for this description.] 2. 2.1 Flow of Events Basic Flow

[This use case starts when the actor does something. An actor always initiates use Cases. The use case should describe what the actor does and what the system does in response. It should be phrased in the form of a dialog between the actor and the system. The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters customer information. It is better to say the Actor enters the customers name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageableyou may want to define things like customer information there to keep the use case from drowning in details. 34

Part III

Phases and Iterations

35

Phases

Lifecycle Phases
Inception Elaboration Construction Transition

time

Inception

Understand what to build

Define the Scope of Project and Develop Business Case and Critical Use-Case

Elaboration

Understand how to build it

Plan Project, Specify Features, and Baseline the Architecture

Construction Transition

Build the Product

Produce a beta product

Transition the Product to its Users

Produce final product
36

Milestones

Inception

Elaboration

Construction

Transition

time
Lifecycle Architecture Milestone Initial Operational Capability

Lifecycle Objectives Milestone

Product Release

37

Phases

Phases and Iterations

An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external) Within each phase are a number of iterations

Inception
Preliminary Iteration

Elaboration
Architect. Iteration Architect. Iteration Devel. Iteration

Construction
Devel. Iteration Devel. Iteration

Transition
Transition Transition Iteration Iteration

Minor Milestones: Releases

38

Phases

Iteration as Waterfall

In an iteration, you walk through all workflows

39

Phases

The Iteration Life Cycle: A MiniWaterfall

Selected scenarios Results of previous iterations Up-to-date risk assessment Controlled libraries of models, code, and tests

Iteration Planning

Requirements Capture Analysis & Design Implementation Test Prepare Release Release description Updated risk assessment Controlled libraries
40

Phases

Iteration
Requirements Capture Planning Implementation Initial Planning Management Environment Analysis & Design

Deployment

Evaluation Test

41

Phases

What the Iterative Lifecycle Is

It is planned and managed It is predictable It accommodates changes to requirements with less disruption It is based on evolving executable prototypes, not documentation It involves the user/customer throughout the process It is risk driven

42

Phases

Phases and Iterations: A Sample

Short e-Business Project 5 Project Member

No of Iterations Project Inception Elaboration Construction Transition Length 3-4 1 Time: 10% 1 3 1 month Iteration Length 2-3

weeks

30%

50%

10%

43

Phases

Risk Profile of an Iterative Development

Inception

Waterfall
Elaboration

Risk

Construction Transition

Preliminary Iteration

Architect. Iteration

Architect. Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

Transition Iteration

Transition Iteration

Postdeployment

Time
Copyright 1997 by Rational Software Corporation

44

Part IV

Configuring RUP

45

Configure RUP

Why Do You Need To Configure RUP

Each have different Objectives

Each have different Equipment

Each have different Risk

RUP is a Framework not a single Process No one process fits all projects Essentials Each have different Safety and Security

All thing will be changed

Technologies Organization

46

Configure RUP

Which Do I Need for My Project

47

Configure RUP

Who Configures The RUP?

Process Engineer

Assess Current Organization

Develop Develop Development Project Specific Templates Case

Launch Development Case

Development Organization Assessment

Development Case

Project Specific Templates 48

Configure RUP

How To Configure The RUP?

Development Case: The development-case description describes the development process that you have chosen to follow in your project Roadmap: Roadmaps provide a way of describing how to use the general-purpose process described in the Rational Unified Process to solve specific types of problems

49

Tools: Rational Suite

Jacobson: a process without integral tools is just an academic idea!

Content Studio Project Console

Purify Quantify PureCoverage

Rose

Rational Unified
Process

TeamTest

RequisitePro ClearQuest SoDA ClearCase

50

References
Unified Software Development Process, Ivar Jacobson, Grady Booch, Jim Rumbaugh Ten Essential Of RUP, Leslee Probasco Trends in Software Engineering a personal view, Ivar Jacobson Object Oriented Methodology, William F. Nazzaro What is RUP, Philippe Kruchten Introduction to Rational Unified Process, Philippe Kruchten Rational Unified Process, www.rational.com/rup www.therationaledge.com

51

Rational Unified Process

This presentation can be download from:

http://www.BaridSoft.ca

52