j. scott hawker 2003-01-21p. 1some material © rational corp. rational unified process overview see...

J. Scott Hawker 2003-01-21 p. 1 Some material © Rational Corp.

Rational Unified Process Overview

See and use the RUP Browser on lab machines


Software Engineering Process


Features of RUP Use-Case Driven

Requirements drive and focus development The “function” of “function + form”

Architecture-Centric The over-arching structure; the foundation of the design The “form” of “function + form”

Iterative and Incremental Step-wise, controlled growth through “mini-projects” Each step reacts to current needs and risks


Rational Unified Process

time


Phases

Four phases Inception

Establish business case, system viability Deliver life-cycle objectives

Elaboration Establish feasibility and constraints: financial,

schedule, technical, etc. Deliver life-cycle architecture

Construction Build the system Deliver initial operational capability

Transition Roll out the fully functional system to

customers Deliver product release


Each Discipline Contributes a Particular Set of Models


Artifacts


Time and the Unified Process

In the Unified Process, time flows through phases, increments and iterations, not through the traditional workflows of requirementsdesignimplementation test

Phase Time between two major milestones – points at which

management decides whether to proceed with development and to commit scope, budget and schedule to the next phase

Iteration A “mini-project” that typically crosses all five workflows

(disciplines) Results in a release (internal or external) May contain multiple increments -- builds

Increment A small, manageable part of the system – a build Usually the difference (“delta”) of functionality added to the

results of a previous increment


Deliverables

Increments (and phases) deliver artifacts Align deliverables with the phases and iterations,

not the disciplines Each discipline will contribute to part of the

deliverables A given deliverable contains content from multiple

disciplines Example: Vision document has contributions from

requirements and analysis (scope), design (architecture), and project management (schedule and risk)


Iterative and Incremental Small steps!

Iteratively go through each discipline Plan a little Specify, design and implement a little Integrate, test and run each iteration a little Assess and repeat (iterate), as necessary

Transform a delta (chunk) of users’ requirements into a delta (chunk) of software product Mini-project: one step at a time Each one includes planning, disciplines, environment support, etc. Early increments build knowledge (reduce risk) of required functionality

and technical viability. Later increments build product functionality Risk-Driven

Each iteration adds an increment and demonstrates the reduction of the risks with which it was concerned


Phases

Iterations help management plan, organize, monitor, and control (react to change in) the project

Iterations are organized into phases, each with staffing, funding, and scheduling requirements and entry and exit criteria


Inception Phase

Inception Launches the Project Make the business case to justify launching the

project Define scope Define candidate architecture Identify risks and develop risk management plan Estimate cost, schedule, return on investment Define development process and support


Inception Phase Deliverables

Feature list First version of business or domain model First version of use case model, analysis model and

(maybe) design model First draft candidate architecture description with use

case, analysis and design views (Maybe) Proof-of-concept prototype Initial risk list Initial use case priority list Initial project plan (for all phases) First draft of business case Stakeholder agreement to proceed or cancel


Inception Phase Deliverables

For this course Feature list First version of business or domain model First version of use case model, analysis model and

(maybe) design model First draft candidate architecture description with use

case, analysis and design views (Maybe) Proof-of-concept prototype Initial risk list Initial use case priority list Initial project plan (for all phases) First draft of business case Stakeholder agreement to proceed or cancel

with priority

sketch technical approach

schedule

state “why this project”


ArtifactsFor this course


Note that the requirements and design are addressed simultaneously Define and evolve requirements – problem space Define and evolve solution

Design, implement, test


A Layered Architecture

Middleware

Application

Platform Platform

Functional Architecture

Technical Architecture

• Operating Systems• Networking• etc.

• Distributed communications• Databases• Security• User interface framework• etc.

• Domain objects• Business logic• Workflow• etc.

FunctionalRequirements

Non-functional (quality) Requirements


Simultaneously Address Function and Form

• Define requirements• Design solution• Implement solution• Test solution

ApplicationModel

Elements

TechnicalModel

Elements

• Define requirements• Design solution• Implement solution• Test solution

Support• Project Mgmt.• Environment Tools & Methods• Configuration/Change Mgmt.

• Scope 50%• Prototype• Prototype

• Scope 50%• Feasible

approach• Prototype

• Business case• Schedule estim.• Cost estimate• Risks known

• 100%• 90%• 90%• 100% of built

• Go/No Go• Schedule• Cost• Risks managed

• Go/No Go• Manage

•cost•schedule•risk

• 100%• 100%• 100%• 100%

• Go/No Go• Customer

support• Manage

•scope•change•delivery

• Fix and maintain

• Fix and maintain

InceptionPhase

ElaborationPhase

ConstructionPhase

TransitionPhase

• Defined 80%• Funct. arch. 80% other 20%• Impl. 20%• Test 20%

• 100%• 100%• 100%• 100%

Define the function early Build the form early

= “completeness”

j. scott hawker 2003-01-21p. 1some material © rational corp. rational unified process overview see...

Documents