Lecture 4 - RUP

8/11/2019 Lecture 4 - RUP

1/38

Rational Unified Process ,

Introduction to UML


2/38

What is RUP?

The Rational Unified Model is a softwareengineering process

Both process and product Provides a common project knowledge base that

may be accessed by team members

Ensures consistency of communication

Commonality of project vision Enhances productivity

Focuses on the development and maintenance ofmodels

Reflect the best practices of software development


3/38

Software Development: Best

Practices1. Develop software iteratively

2. Manage requirements3. Use component-based architectures

4. Visually model software

5. Continuously verify software quality6. Control changes to software


4/38

RUP


5/38

The X-axis: Time / Iterations1. Inception

3. Construction

4. Transition2. Elaboration

LifecycleObjectives

Lifecycle

Architecture

Initial Operational

Capability

Product

Release

milestones


6/38

Phase 1: Inception

Develop business case

Success criteria

Risk assessment

Estimate of resources needed

Phase plan (with dates)

Deliverables

Vision document

Preliminary Use-case model

Initial project glossary

Business case

Possibly, some prototypes


7/38

Inception Milestone: Lifecycle

Objectives Stakeholder agreement on project scope and

cost/schedule estimates.

Requirements understanding (based on quality ofprimary use cases).

Credibility of the cost/schedule estimates,priorities, risks, and development process.

Depth and breadth of any architectural prototypethat was developed.

Actual expenditures versus planned expenditures.


8/38

Phase 2: Elaboration Goals

Develop a big picture view of the project

Most of the analysis is done in this stage

Develop an architectural foundation for the system A working, exploratory working prototype

Possibly the most important of the phases

Deliverables (partial list)

More comprehensive use-case model Supplementary requirements (not covered in use-case)

Revised risk assessment and business case

Working prototype

Development plan (with dates and number of iterations)


9/38

Elaboration Milestone: Lifecycle

Architecture Is the vision of the product stable?

Is the architecture stable?

Does the executable demonstration show that the majorrisk elements have been addressed and credibly resolved?

Is the plan for the construction phase sufficiently detailed

and accurate?

Do all stakeholders agree that the current vision can beachieved ?

Is the actual resource expenditure versus planned

expenditure acceptable?


10/38

Phase 3: Construction

The manufacturing phase

Goals

Develop and integrate all remaining components intoproduct

Thorough testing of all features

Deliverables

Actual product on the appropriate platform (betarelease)

User manuals

Description of current release


11/38

Construction Milestone: Initial

Operational Capability Is this product release stable and mature

enough to be deployed in the user

community?

Are all stakeholders ready for the transition

into the user community?

Are the actual resource expenditures versusplanned expenditures still acceptable?


12/38

Phase 4: Transition

Involves beta testing

Parallel conversion

Convert operational databases

Train users and support personnel

Rollout the product to other functional areas

(marketing, distribution, etc.) Typically involves several iterations (for purposes

of fine tuning user manuals and the product)


13/38

Transition Milestone: Product

Release Focuses on whether objectives were met

New development cycle needed?

The questions -

Is the user satisfied?

Are the actual resources expenditures versus

planned expenditures still acceptable?


14/38

Software Development: Best

Practices1. Develop software iteratively

2. Manage requirements3. Use component-based architectures

4. Visually model software

5. Continuously verify software quality6. Control changes to software


15/38

RUP


16/38

The X-axis: Time / Iterations1. Inception

3. Construction

4. Transition2. Elaboration

LifecycleObjectives

Lifecycle

Architecture

Initial Operational

Capability

ProductRelease

milestones


17/38

RUP


18/38

Representing the RUP

Processes involve

Who is doing

What,

How its being done

And when it was done

RUP main model elements

Workersthe who Activitiesthe what

Artifactsthe how

Workflowsthe when

worker

activity


19/38

RUP Element: Workers

A workerdefines the behavior and

responsibilities of an individual, or a group of

individuals working together as a team. Not really referring to a person or team

Refers to role individual plays in doing work

Worker responsibilities include

Activities

Artifact ownership


20/38

Example of Workers


21/38

RUP Element: Activity

An activityof a specific worker is a unit ofwork that an individual in that role may be

asked to perform Activities

Have clear purpose

Assigned to specific worker

Limited time span (hours or days)

Affects limited number of artifacts


22/38

Examples of Activities

Who might be the assigned

worker for this activity?

-Analyst

--Project Manager

-Tester

-Designer

Plan an iterationFind use cases and actors

Review the design

Execute performance test



-Analyst

--Project Manager

-Tester

-Designer



-Analyst

--Project Manager

-Tester

-Designer



-Analyst

--Project Manager

-Tester

-Designer

Answer: AnalystAnswer: TesterAnswer: DesignerAnswer: Project Manager


23/38

RUP Element: Artifacts

An artifactis a piece of information that isproduced, modified, or used by a process

Artifacts Tangible results of activities in the project Outputs of activities

May be used as inputs for other activities

Examples Models or model elements

Documents

Code

Executable prototypes


24/38

RUP Element: Workflows

A workflowis a sequence of activities that

produces a result of observable value.

Describes a meaningful sequence that produces a usefulresult

Shows interaction between workers

UML represents workflows through

Sequence diagram

Collaboration diagram

Activity diagram


25/38

Example of Workflows


26/38

Core Workflows


27/38

Core Workflows

Nine core workflows

Divided into two groups

Process workflows

Supporting workflows

Based on workers and activities

The activities in the workflow are revisited with

each iteration Emphasis on the activity changes with each

iteration


28/38

Core Workflows


29/38

Six Process Workflows

Business Modeling

Communication problems arise between

analysts and businessDocument business processes

Business use-cases

Artifact is a business object modelEnsures all stakeholders on same page

Not always done


30/38

Six Process Workflows contd.

Requirements

Describe the desired system functionality

Involves eliciting, organizing, and documentingrequired functionality and constraints

Artifacts include

Vision document

Use-cases

The use-cases are the common thread for allworkflows


31/38


Analysis and Design

show how the system will be created in the

implementationArtifact is a Design Model

Acts as blueprint for coding

Presents organized classes, subsystems, and

interfaces

Based on architecture of system


32/38


Implementation

To define the organization of the code

To implement classes and objects in terms ofcomponents

To test the developed components as units.

To integrate the results produced by individualimplementers (or teams), into an executable

system (a prototype)


33/38


Testing

Objectives

To verify the interaction between objects.

To verify the proper integration of all components of thesoftware.

To verify that all requirements have been correctlyimplemented.

To identify and ensure defects are addressed prior to the

deployment of the software. Based on reliability, functionality, application

performance and system performance.

Continuous process throughout the developmentprocess


34/38


Deployment

Aims to successfully produce product releases,

and deliver the software to its end usersIncludes

Producing external releases of the software

Packaging the software

Distributing the software Installing the software

Providing help and assistance to users


35/38

Core Workflows


36/38

Three Support Workflows

Configuration and Change Management

control the numerous artifacts produced during project

Typical problems with managing large number ofartifacts

Simultaneous Update

Limited notification

Multiple versions

how to report defects, manage them through their

lifecycle


37/38

Three Support Workflows contd.

Project Management

Involves

Balancing competing objectives

Overcoming constraints

deliver a product which meets the needs of both customers (thepayers of bills) and the users

RUPprovides

A framework for managing software-intensive projects

Practical guidelines for planning, staffing, executing, andmonitoring projects

A framework for managing risk


38/38

Three Support Workflows contd.

Environment

provide software development environment--

both processes and tools--that are needed tosupport the development team.

focuses on the activities to configure the

process in the context of a project

focus on activities to develop the guidelines

needed to support a project.