Rational Unified Process Fundamentals Module 2: RUP Structure and Content.

Rational Unified Process Fundamentals

Module 2: RUP Structure and Content

Rational Unified Process Fundamentals

Module 2: RUP Structure and Content

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 2

Objectives: Rational Unified Process Structure

Explain the role of process in software development.

Explore the phase organization of Rational Unified Process and its relationship to iterative development.

Explore the discipline organization of Rational Unified Process and its relationship to iterative development


A Development Process Should:

Define the steps that lead to deliverables and who is responsible for them.

Help to control the project and reduce confusion.

Help project management to resource, plan, and measure progress.

Reduce risk. Make software development predictable,

repeatable, and measurable. Not be another process gathering dust.


Rational Unified Process

Provides guidelines for efficient development of quality software

Reduces risk and increases predictability Captures and presents best practices

Provides learning from others’ experiences Acts as a mentor on your desktop Provides an extension of training material

Promotes common vision and culture Mentors successful use of our tools


Role of UML in RUP

Rational Unified Process was developed hand-in-hand with the UML.

Many artifacts in Rational Unified Process have a UML representation.

Rational Unified Process also includes guidelines for UML concepts.


RUP Structure

Organization along time Lifecycle structure: phases, iterations Process enactment: planning, executing Activity management, project control

Organization based on content Disciplines, roles, artifacts, activities Process configuration, process enhancement


Organization Along TimeTime

Organization by phases helps minimize the risks of resource allocation.


Major Milestones: Business Decision Points

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

Commit resources for the elaboration phase

Lifecycle Objective Milestone

Commit resources for construction

Lifecycle Architecture

Milestone

Product sufficiently mature for customers

Initial Operational Capability Milestone

Customer acceptanceor end of life

Product Release

time


Inception Phase

The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.


Inception Phase: Objectives

Prepare supporting environment for project Establish project scope and boundary

conditions Determine the use cases and primary

scenarios that will drive the major design trade-offs

Demonstrate a candidate architecture against some of the primary scenarios

Estimate the overall cost and schedule Identify potential risks (the sources of

unpredictability)


Inception Phase: Artifacts

The outcome of the inception phase is the creation of these artifacts• A vision document outlining the core

requirements, key features and main constraints

• A high-level use-case model• Initial project glossary (project terms and

definitions)• An initial business case containing ROI, etc. • An initial risk assessment• A project plan showing phases and iterations.


Inception Phase: Evaluation Criteria

Stakeholder concurrence on scope definition and cost/schedule estimates

Agreement that the right set of requirements have been captured and that there is a shared understanding of these requirements

Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate

All risks have been identified and a mitigation strategy exists for each

Milestone: Lifecycle Objectives (LCO)


Elaboration Phase

The overriding goal of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the project’s high-risk elements.


Elaboration Phase: Objectives

Refine support environment Define, validate and baseline the

architecture as rapidly as is practical Baseline the vision Baseline a detailed plan for the construction

phase Demonstrate that the baseline architecture

will support the vision at a reasonable cost in a reasonable period of time


Elaboration Phase: Evaluation Criteria

Product Vision and requirements are stable. • Use-case model is at least 80% complete.• Supplementary requirements largely completed.

Architecture is stable. • Executable architectural prototype developed

Key test and evaluation approaches are proven; major risk elements have been addressed and resolved. • Revised risk list

Iteration plans for construction phase are of sufficient detail and fidelity to allow work to proceed, and are supported by credible estimates.

Milestone: Lifecycle Architecture (LCA)


Elaboration Phase: Evaluation Criteria

Iteration plans for construction phase are of sufficient detail and fidelity to allow work to proceed, and are supported by credible estimates.

All stakeholders agree that current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture.

Actual resource expenditure versus planned expenditure are acceptable.

Preliminary users manual developed.

Milestone: Lifecycle Architecture (LCA)


Construction Phase

The overriding goal of the construction phase is to develop all remaining components and features and integrate them into the product.


Construction Phase: Objectives

Completing the software product for transition to production

Minimizing development costs by optimizing resources and avoiding unnecessary scrap and rework

Achieving adequate quality as rapidly as is practical

Achieving useful versions (alpha, beta, and other test releases) as rapidly as possible


Construction Phase: Evaluation Criteria

The evaluation criteria for the construction phase involve the answers to these questions:

Is this product release stable and mature enough to be deployed in the user community?

Are all the stakeholders ready for the product’s transition into the user community?

Are actual resource expenditures versus planned still acceptable?

Milestone: Initial Operational Capability (IOC) “beta”


Transition Phase

The overriding goal of the transition phase is to move the product to the user community.


Transition Phase: Objectives

Achieving user self-supportability Achieving stakeholder concurrence that

deployment baselines are complete and consistent with the evaluation criteria of the vision

Achieving final product baseline as rapidly and cost-effectively as possible


Transition Phase: Evaluation Criteria

The primary evaluation criteria for the transition phase involve the answers to these questions:

Is the user satisfied? Are actual resources expenditures versus planned

expenditures acceptable?

Milestone: Product release (“GA”)


What Is an Iteration?


Phases and Iterations

Commit resources for the Commit resources for the elaboration phase elaboration phase

Commit resources Commit resources for constructionfor construction

Product sufficiently mature for Product sufficiently mature for customers to usecustomers to use

(Understand the problem)(Understand the problem) (Understand the solution)(Understand the solution) (Have a solution)(Have a solution)

AcceptanceAcceptanceor end of lifeor end of life

Planned (Business) Decision PointsPlanned (Business) Decision Points

PreliminaryPreliminaryIterationIteration

Architect.Architect.IterationIteration

Architect.Architect.IterationIteration

Devel. Devel. IterationIteration



TransitionTransitionIterationIteration

TransitionTransitionIterationIteration

Planned (Technical) Visibility PointsPlanned (Technical) Visibility Points

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition


Iteration: Number and Duration

Duration driven by + size of organization+ size of project- familiarity with the process, maturity- technical simplicity

6, plus or minus 3Inception: 0 .. 1Elaboration: 1 .. 3Construction: 1 .. 3Transition: 1 .. 2


One Iteration

In an iteration, you walk through all disciplines.


Organization Based on ContentC

onte

nt


Key RUP Elements: Roles, Activities, Artifacts

DesignerUse-CaseAnalysis

Use-Case Realizations

Role Activity

Artifact

responsible for

performs


Roles Perform Activities and Produce Artifacts

Example:Requirements->

Workflow Detail->

Define the System C apture a C om m on

Vocabulary

SystemAnalyst

F ind Actors and Use Cases

Use-Case Model(re fined)

Use-CaseModeling

Guidelines

SupplementarySpecifications

Glossary(refined)

Glossary

StakeholderRequests

Use-Case Model

M anage D ependencies

RequirementsManagement

Plan

Vision

Business Use-Case Model

Business Object Model

RequirementsAttributes

RequirementsAttributes

(refined)

D evelopVision

BusinessRules

Vision(refined)

Use Case(outlined)


Key RUP Element: Role

A Role defines the behavior and responsibilities of an individual, or a set of individuals working together as a team.

Team members can “wear different hats,” that is, each member can play more than one Role.


Resource

Paul

Mary

Joe

Sylvia

Stefan

Roles Are Used for Resource Planning

Each individual in the project is assigned to one or several roles

Role

Designer

Requirements Specifier

System Analyst

Implementer

Architect

Activities

Define Operations

Detail a Use Case

Find Actors and Use Cases

Perform Unit Tests

Identify Design Mechanisms


Key RUP Element: Activity

A piece of work a Role is responsible for, that the Role may be asked to perform

Granularity: a few hours to a few days Repeated, as necessary, in each iteration


A document or model produced, evolved, or used by a process

The responsibility of a Role Likely to be subject to

configuration control May contain other artifacts

Key RUP Element: Artifact


Key RUP Elements: Roles, Activities, Artifacts

DesignerUse-CaseAnalysis

Use-Case Realizations

Role Activity

Artifact

responsible for

performs

Disciplines also contain Workflows and Workflow Details, as you will see.


Nine Disciplines


Elements of a Discipline

If you expand any Discipline in the RUP tree browser, you will see the following:


The conditional flow of high-level activities (Workflow Details) that produces a result of observable value.

Key RUP Element: Workflow


Workflow Details

Example:Workflow Detail: Prepare Environment for Project

Example:Environment: Workflow


Workflow Path Is Adapted to:

Position in Lifecycle Phase

Artifacts being produced

Technology Iteration goals

Example:Analysis & Design


Workflows Guide Iterative Development Business Modeling:

Workflow Details

Requirements:

Workflow Details


Includes relevant portions of Disciplinefor a particular iteration

Iteration Plan


Iteration Plan (cont.)

Instantiation of the discipline

One for each iteration A fine-grained plan Expressed in terms of

selected Workflow Details or Activities from the disciplines

Shows assigned resources


Sample Iteration PlanExample:Table of Steps for anInception Iteration


Artifact Set Evolution Over the Development Phases

With the iterative approach, artifact sets mature over time.


Summary of Major Artifacts


Economy of Artifacts

RUP’s use of Artifacts allows you to: Produce only the artifacts that get used Keep the artifact in the most appropriate

tool, in electronic form (Rose, Excel, RequisitePro, etc.)

Use reports to extract snapshots of information out of models in tools, for review (SoDA, scripts, etc.)

Put effort into artifacts that are part of the product (e.g. models)


Additional Process Elements

Discipline Introduction

Concepts

Workflow

Activity Overview• And associated Tool Mentors and Guidelines

Artifact Overview• And associated Templates and Guidelines

Guidelines Overview

Roadmaps


Process Element: Concepts

Attached to the relevant Discipline Explanation of key ideas Examples of Concepts

Requirements• Requirements Management • Types of Requirements

• Traceability Analysis and Design

• Software Architecture • Analysis Mechanisms

• Web Architecture Patterns


Process Element: Guidelines

These are Rules, recommendations, heuristics that support activities and their steps. They:

Describe specific techniques. Transformations from one artifact to another Use of UML

Are attached to relevant discipline. Are kept short and to the point. Describe well-formed artifacts and focus on

qualities. Are used also to assess the quality of artifacts. Are tailored for the project.


Process Element: Tool Mentors

Attached to relevant activity Explain how to use a specific tool to

perform an activity or steps in an activity Linked by default to Rational tools:

RequisitePro: requirements management Rational Rose: visual modeling, using UML SoDA: documentation generation ClearQuest: change management, defect

tracking …and more


Process Element: Templates

Attached to relevant document type Predefined artifacts, prototypes:

Documents (Microsoft® Word™, Adobe® Framemaker™)

MS Project HTML

Tailored for the process


Process Element: Roadmap

Roadmaps are used to: Apply the general-purpose process to solve

specific types of problems. Describe process variants using phases. Provide a mechanism for extending and

adapting the process. Highlight certain process features to

achieve a particular goal.

Rational Unified Process Fundamentals Module 2: RUP Structure and Content.

Documents

Transcript of Rational Unified Process Fundamentals Module 2: RUP Structure and Content.