welcome to the training program: rational unified

8/14/2019 Welcome to the Training Program: Rational Unified

1/44


2/44

Rational Unified Process (RUP)

Chapter: 1 - Best P ractices Of Software

Engineering

Trace Symptoms to Root Causes

Symptoms of Software Development Problems

The Symptoms of Software Development Problems are:

o User or business needs not met

o Requirements churn

o Modules dont integrate

o Hard to maintaino Late discovery of flaws

o Poor quality or end-user experience

o Poor performance under load

o No coordinated team effort

o Build-and-release issues

Trace Symptoms to Root Causes

Treat the root causes, amd you'll eliminate the symptoms:

Symptoms Root Causes Best Practices

Needs not met

Requirements Churn

Modules dont fit

Hard to Maintain

Late Discovery

Poor QualityPoor Performance

Colliding developers

Build-and-releaseissues

Insufficient requirements

Ambiguoscommunications

Brittle Architecture

OverwhelmingComplexity

Undetectedinconsistencies

Poor testing

Subjective assessment

Waterfall development

Uncontrolled change

Insufficient automation

Develop Iteratively

Manage Requirements

Use Component

Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Changes


3/44

Eliminate the symptoms and you will be in a much better

position to devleop quality software in a repeatable andpredictable fashion

Best Practices are a set of commercially proven approaches tosoftware development, which, when used in combination, strikeat the root causes of software developement, problems.

The best practices are harvested from thousands of customerson thousands of projects and from industry experts.

Best Practice 1 - Develop Iteratively

What is Iterative Development ?

Develop Iteratively is a technique that is used to deliver thefunctionality of a system in a successive series of releases of

increasing completeness. Each release is developed in aspecific, fixed time period called aniteration"

Each iteration is focused on defining, analyzing, designing,building and testing some set of requirements.

Waterfall Development Characteristics

Waterfall is conceptually straightforward because it produces a

single deliverable.

The fundamental problem of this approach is that it pushes riskforward in time, where it is costly to undo mistakes from earlier

phases

An initial design will likely be flawed with respect to its keyrequirements

The late discovery of design defects tends to result in costlyoverruns and/or project cancellation

To sum it up the problems with Water Development are:

o Delays confirmation of critical risk resolution


4/44

o Measures progress by assessing work-products that are

poor predictors of time-to-completion

o Delays integration and testing

o Precludes early deployment

o Frequently results in major unplanned iterations

Iterative Development Produces an Executable

In Iterative Approach:

o The earliest iterations address greatest risks. Each iterationproduces an executable release.

o Resolve major risks before making large investmentso Enable early user feedback

o Make testing and integration continuous

o Focus project short-term objective milestones

o Make possible deployment of partial implementations

Instead of developing the whole system in lock step, an increment (i.e. asubset of system functionality) is selected and developed, the another

increment, etc.


5/44

The selection of first increment to be developed is based on risk, the

highest priority risk first.

To address the selected risk(s) choose a subset of use cases and other

non-functional requirements

Develop the minimal set of use cases the will allow objective verification

of the risks that you have chosen

Risk Profiles

Iterative Development produces the architecture first, allowing integrationto occur "as verification activity" of the design phase

It allows design flaws to be detected and resolved earlier in the lifecycle.

Continous integration throughout the project replaces the "big bang"

integration at the end of a project.

Iterative Development provides much better insight into quality,

because system characteristics that are largely inherent in the architecture(for e.g. performance, fault tolerance, maintainability) are tangible earlier

in the process.

Issues are still correctable without jeopardizing target costs and schedules.


6/44

Best Practice 2 - Manage Requirements

Manage Requirements

A report from the Standish Group confirms that a distinct

minority of software projects is completed on-time and on-budget.

The success rate was only 16.2%, while challenged projects

operational, but late and over budget accounted for 52.7%.

Impaired projects accounted for 31.1%.

Reason: Poor definition of requirements, poor requirementsmanagement and poor change management of requirements.

What is Requirements Management ?

Making sure you

o Solve the right problem

o Build the right system

By taking a systematic approach to

o Eliciting

o Organizing

o Documenting and

o Managing the changing requirements of a software

application

Also managing traceability among requirements is important

activity in Requirements Management

Aspects of Requirements Management

Following are workflow details of Requirments Management

o Analyze the Problem

o Understand the Stakeholders requests


7/44

o Define the System

o Manage the scope of the System

o Refine the System Definition

o Build the Right System

Traceability

Managing requirements involves the translation of stakeholder requests into aset of key stakeholder needs and system features.

Traceability allows us to:

o Assess the project impact of a change in a requirement

o Assess the impact of failure of testo Manage the scope of the system

o Manage Change


8/44

Best Practice 3 - Use Component Architecture

Use Component Architecture

Software Architecture is the development product that gives

highest ROI with respect to quality, schedule, and cost,according to the authors of Software Architecture in Practice.

Software Architecture is often misunderstood. It is not an

artifact which is merely on paper

It must be validated and evaluated

The Architecture is nothing but High Level Design

Resilient Component-Based Architecture

Component Based Architecture is Resilient

o Meets current and future requirements

o Enables reuse

o Improves Extensibility

o Encapsulates system dependencies

The Architecture must be based on components. It helps

o Reuse or customize components

o Select from commercially-available components

o Evolve existing software incrementally

Architecture is about making decisions on how the system will

be built

The elements of Architecture are those that have pervasice andlong-lasting effect on the systems performance and ability to

evolve.

The most important property of an architecture is resilience -flexibility in the face of change. The component orientedness

helps implement this property


9/44


10/44

Best Practice 4 - Model Visually (UML)

Model Visually

A model is a simplification of reality that provides a complete description of a

system from a particular perspective.

We build models because we cannot comprehend any system in its entirety.

Why Model Visually ?

We do modeling to

o Capture structure & behavior

o Show how system elements fit together

o Keep design & implementation consistento Hide or ex ose details as a ro riate


11/44

language for all practitioners/ul>

o Visula Modeling also helps you tomaintian consitencyamong a system's artifacts - its requirements, designs,

and implementations.

o Visual modeling helps improve a team's ability to

manage software complexity

o A model is a simplified view of a system.

It shows the essentials of the system from a particularperspective and hides the non-essential details.

Visual Modeling with Unified Modeling Language (UML)

Model Contains

o Static Diagrams

Use Case Diagrams to illustrate user interactionswith the system

Class Diagrams to illustrate logical structure Object Diagrams to illustrate objects & links

Component Diagrams to illustrate the physical

structure of the system Deployment Diagrams to show the mapping of

software to hardware config.o Dynamic Diagrams

Sequence Diagrams to illustrate behavior Collaboration Diagrams to illustrate behavior

State Chart Diagrams to illustrate behavior Activity Diagrams to illustrate flow of events


12/44

Best Practice 5 - Continuously Verify Quality

Continuously Verify Quality

Quality as used within Unified Process, is defined as The

Characteristic of having demonstrated the achievement ofproducing a product which meets or exceeds agreed upon

requirements, as measured by agreed upon measures and

criteria, and is produced by an agreed upon process.

Continuosly Verify Your Softw are's Quality (Contd.)

What to test:o Test for key scenarios ensure that all requirements are properly

implemented

o Poor application performance hurts as much as poor reliability

o Verify software reliability memory leaks, bottlenecks

o Test every iteration automate test

Software problems are 100 to 1000 times more costly to find and repairafter deployment. Verifying and managing quality throughout the project

lifecycle is essential to achieving the right objectives at the right time.


13/44

Test all Dimensions

Test all Dimensions of Software Quality:

o Functionality Test: Use case scenarios execute as

intended

o Performance Test: reliable under load, benchmarktests, load tests and performance profile tests.

o Load Test: Application runs reliable under various loads(peak hrs)

o Reliability Test: crahes, hangs, memory leaks,integrity, structure, stress, contention and volume tests.

o Usability: human factors, aesthetics, wizards andagents, user documentation

Test Each Iteration

Test within the P roduct Development Life Cycle

The testing lifecycle is a part of the software lifecycle; they should startat the same time.

The design and development process for tests is as complex and arduousas the application being built. - If not started early enough, the tests will

either be deficient, or cause a long testing and bug-fixing schedule to beappended to the development schedule, which defeats the goals of

iterative development.

The test planning and design activities can expose faults or flaws in theapplication definition.

The earlier these are resolved, the lower the impact on the overall

schedule


14/44

Best Practice 6 - Manage Changes

Manage Changes

We cannot stop change from being introduced into our project.

However, we must control how and when changes are

introduced into project artifacts and who introduces thechanges.

We also must synchronize change across development teams &locations

What do you want to Control ?


15/44

Establishing secure workspaces for each developer provides isolation

from changes made in other workspaces and control of all softwareartifacts models, code, docs etc.

Three common problems that result are:1. Simultaneous update When two or more roles separately

modify the same artifact, the last one to make changes destroysthe work of the former.

2. Limited Notification When a problem is fixed in sharedartifacts, some of the users are not notified of the change.

3. Multiple versions With iterative development, it would not beunusual to have multiple versions of an artifact in different

stages of development at the same time. For e.g. one release isin customer use, one is in test, and one is still in development. If

a problem is identified in any one of the versions, the fix must be

propagated among all of them.

Aspects of Change Management

Aspects of Change Management Includes

1. Change Request Management (CRM)2. Configuration Status Reporting

3. Configuration Management (CM)

4. Change Tracking5. Version Selection


16/44

6. Software Manufacture

Change Requestion Management

o CRM addresses the organizational infrastructre requiredto assess the cost and schedule impacts of a requestedchange to the existing product

o CRM addresses the workings of a Change Review Teamor Change Control Board

Configuration Status Accounting (Measurement)

o This is used to describe the "state" of the product based

on the type, number, rate and severity of defects foundand fixed during the course of product development.

o Metrics derived under this aspect, either through auditsor raw data, are useful in determining the overall

completeness of the project

Configuration Management

o This describes the product structure and identifies itsconstituent configuration items that are treated as single

versionable entities in the configuration management

process

o CM deals with defining configurations, building and

labeling, and collecting versioned artifacts intoconstituent sets and maintaining traceability between

these versions

Change Tracking

o This describes what is done to components for what

reason and at what time.

o It serves as histroy of rationale and change

o It is quite different from assessing the impact ofproposed changes

Version Selection

o This is to ensure that the right versions of configurationitems are selected for change or implementation

o Version selection relies on a solid foundation of"configuration identification"


17/44

Software Manufacture

o This covers the need to automate the steps to compile,test, and package software distribution

Unified Change Management (UCM)

Unified Change Management (UCM) is Rational Software's

approach to managing change in software development, fromrequirments to release

UCM spans the development lifecycle, defining how to manage

change to requirments, design models, documentation,

components, test cases and source code.

One of the key aspects of the UCM is that it unifies the activities

used to plan and track project and the artifacts undergoingchange

Rational Unified Process Implements Best P ractices

Why have a P rocess ?

Provides guidelines for efficient development of quality software

Reduces risk and increases predictability

Promotes a common vision and culture

Captures and institutionalizes best practices


18/44

Achieving Best Practices

Iterative approach

Guidance for activities and artifacts

Process focus on architecture

Use cases which drive design and implementation

Models which abstract the system

A Team-Based Definition of Process

A process defines WHO is doing WHATWHEN and HOW toreach a certain goal.

Process Structure - Life Cycle

The 4 Phases of RUP are explained below

Inception

o Define the scope of the project - what is included andwhat is not

o This is done by identifying all the actors and use cases,and by drafting the most essential use cases (usually

20% of the complete model)

o A business lan business case document is develo ed


19/44

the project

Elaboration

o Focus on 2 things: a) getting good grasp of therequirements (80%), and b) establishing an architecturalbaseline

o Plan project in detail, features specied in detail

o A detailed cost/resource estimations at the end of

Elaboration is achieved

Construction

o Build the product in several iterations upto beta release

o Detailed Level Design of all Use Cases including

important, ancillary and other that were notarchitecurally significant

o Unit Test, Integration Test & System Tests all completed

here

Transition

o The product goes to end-user community

o Focus is on end user training, installation, and support

Phase Boundaries Mark Major Milestones

At each of the major milestones, we review the project and decide

whether to proceed with the project as planned, to abort the project, or torevise it.

The criteria used to make this decision vary by phase


20/44

Definitions

LCO: Scope agreed upon and risks understood and reasonable

LCA: High risks addressed and architecture stable

IOC: Product is complete and quality acceptable

The Evaluation Criteria

Inception - Evaluation Criteria

o Stakeholders concurrence on scope definition andcost/schedule estimates

o Requirements understanding as evidenced by the fidelityof the primary use cases

o Credibility of cost/schedule guestimates, priorities, risks,and development process

o Depth & breadth of any architectural prototype

Elaboration - Evaluation Criteria

o Stability of the product vision and architecture

o

Resolution of major risk elementso Adequate planning and reasonable estimates for project

completion

o Stakeholder acceptance of product vision and project

plan

o Acceptable expenditure level


21/44

Construction - Evaluation Criteria

o Stability and Maturity of product release (i.e. it is ready

to be deployed)

o Readiness of the stakeholders for the transitiono Acceptable expenditure

Transition - Evaluation Criteria

o Here we decide whether to release the product

o The decision is based on the level of user satisfactionachieved during transition phase

o Users have accepted the product

o Product can be made "Generaly Available"

Following illustrates the effort and time devoted for each phase

Inception Elaboration Construction Transition

Effort ~5 % 20 % 65 % 10%

Schedule 10 % 30 % 50 % 10%

Iterations & Phases

An iteration is a distinct sequence of activities based on established plan andevaluation criteria, resulting in a release (Internal or External)

Within each phase, there is a series of iterations

The number of iterations per phase will vary


22/44

Each iteration results in an executable release encompassing larger and larger

subsets of the final application

An internal release is kept within the development environment and

(optionally) demonstrated to the stakeholders

Usually External Releases are provided to the stakeholders

External Releases are usually in Transition phase - although not necessary

The end of an iteration marks a minor milestone. At this point, we

asses technical results and revise future plans as necessary

Discipline P roduct Models

Following are the disciplines in RUP that produces model

o Business Modeling

o Requirements

o Analysis & Design

o Implementation

o Test

o Deployment

Disciplines guide iterative development

Basic Concepts in RUP

Role: A role defines the behavior and responsibilities of an

individual, or a set of individuals working together as a team.

Activity: An activity is the smallest piece of work that is

relevant. Concepts, Guidelines, Tool Mentors

Artifacts: Artifacts are the modeling constructs and documents

that activities evolve, maintain, or use as input.

There are : Checkpoints, Template, Artifact Guideline, Report

for each artifacts explained in RUP


23/44

Chapter: 2 - RUP Structure & Content

A Development Process Should

A Development Process Should:

Define the steps that leas to deliverables and who is reponsible

for them

Help to control the project and reduce confusion

Help project management to resource, plan, and measureprogress

Help reduce risk

Make Software Development Effort predictable, repeatable, and

measureable

Not be just another process gathering dust

RUP - A Software Development Process

Provides guidelines for efficient development of quality software

Reduces risk and increases predictability

Captures and presents best practices

o Provides learning from other's experiences

o Acts as a mentor on your desktop

o Provides an extension of training material

Promotes common vision and culture

Mentors successful use of Rational Tools.


24/44

Role of UML in RUP

Rational Unified Process was developed hand-in-hand witgh theUML

Many artifacts in Rational Unified Process have a UMLrepresentation

Rational Unified Process also includes guidelines for UML

Concepts

Process as a Product

Delivered in source, as a Web site

Continuously improved; regular upgrades

Templates and Online Help provided for faster ramp-up

RUP consists of a set of HTML pases which can be viewed usingany browser which supports frames.

RUP Structure

Organization along time

o Lifecycle structure: phases, iterations

o Process enactment (performing): planning, executing

o Activity management, project control

The time structure refers to the lifecycle aspect of the processi.e. how the process rolls out within the duration of a

project

Organization based on content

o Disciplines, roles, artifactsm activities

o Process configuration, process enhancement


25/44

The content structure refers to the Disciplines, which group

activities logically by nature

Organization Along Time

Organization Along Time

Refer to RUP Overview figure and note that: The time aspect ofthe process as it is enacted is shown by phases, iterations, and

milestones.

Organization along time helps minimize risk of your resource

allocation since resources are allocated only on a firm basis

Major Milestones: Business Decision Points

The phases of RUP were chosen such that phase boundariescorrespond to significant decision points in the life of a project.

Milestones help us assess the progress of a project of a project

at key points.

Management can use these milestones to establish clear criteriafrom which to decide the course of a project.

They provide opportunity to change course

Unlike Waterfall approach, phases contain iterations which yield

executable results.

On the following pages we will see each one of the phases indetail


26/44

Inception Phase: Objectives

Establishing the project's software scope and boundaryconditions, including an operational vision, acceptance criteria

and what is intended to be in the product and what is not.

Discriminating the critical use cases of the system, the primaryscenarios of operation that will drive the major design tradeoffs.

Exhibiting, and maybe demonstrating, at least one candidatearchitecture against some of the primary scenarios

Estimating the overall cost and schedule for the entire project(and more detailed estimates for the elaboration phase that will

immediately follow)

Estimating potential risks (the sources of unpredictability)

Preparing the supporting environment for the project

Inception Phase: Evaluation Criteria

Stakeholder concurrence on scope definition and cost/schedule

estimates

Agreement that the right set of requirements have beencaptured and that there is a shared understanding of theserequirements.

Agreement that the cost/schedule estimates, priorities, risks,

and development process are appropriate.

All risks have been identified and a mitigation strategy exists foreach.

Essential Artifacts

o Vision Document

o Business Case

o Risk Listo Software Development Plan

o Iteration Plan

o Development Process

o Development Infrastructure

o Glossary

o Use Case Model (Actors, Use Cases)


27/44

Optional Artifacts

o Domain Model (a.k.a Business Analysis Model)

o Prototypes

Elaboration P hase: Objectives

To ensure that the architecture, requirements and plans are

stable enough, and the risks sufficiently mitigated to be able topredictably determine the cost and schedule for the completion

of the development. For most projects, passing this milestonealso corresponds to the transition from a light-and-fast, low-risk

operation to a high cost, high risk operation with substantial

organizational inertia (lethargy, sluggish).

To address all architecturally significant risks of the project

To establish a baselined architecture derived from addressingthe architecturally significant scenarios, which typically expose

the top technical risks of the project.

To produce an evolutionary prototype of production-qualitycomponents, as well as possibly one or more exploratory,

throw-away prototypes to mitigate specific risks such as:

o design/requirements trade-offso component reuse

o product feasibility or demonstrations to investors,customers, and end-users.

To demonstrate that the baselined architecture will support the

requirements of the system at a reasonable cost and in a

reasonable time.

To establish a supporting environment


28/44

Elaboration P hase: Evaluation Criteria

The product Vision and requirements are stable & Thearchitecture is stable.

The key approaches to be used in test and evaluation areproven & Test and evaluation of executable prototypes havedemonstrated that the major risk elements have been

addressed and have been credibly resolved.

The iteration plans for the construction phase are of sufficient

detail and fidelity to allow the work to proceed.

The iteration plans for the construction phase are supported by

credible estimates.

All stakeholders agree that the current vision can be met if the

current plan is executed to develop the complete system, in thecontext of the current architecture.

Actual resource expenditure versus planned expenditure is

acceptable.

Essential Artifacts ( In order of Importance)

o Prototypes: One or more executable architecturalprototypes to explore criticial functionality &

architecturally significant scenarios

o Risk List: Updated & Approved

o Development Process: Project-Specific guildelines andtemplates refined

o Development Infrastructure: Developmentenvironment for construction is in place

o Software Architecture Document: Created and

baselined

o Design Model: Defined and baselined. Use-case

realizations for architecturally significant scenarios havebeen defined and required behavior has been allocated

to appropriate design elements. Components have been

identified and the make/buy/reuse decisions sufficientlyunderstood to determine the construction phase cost and

schedule with confidence. The selected architecturalcomponents are integrated and assessed against the

primary scenarios. Lessons learned from these activitiesmay well result in a redesign of the architecture, taking

into consideration alternative designs or reconsiderationof the requirements.

o Data Model: Defined and baselined. Major data modelelements (e.g. important entities, relationships, tables)

defined and reviewed.


29/44

major components prototyped.

o Vision: Refined

o Software Development P lan: Updated and expanded

to cover Construction and Transition

o Iteration Plan: Iteration plan for the construction

phase completed and reviewed.o Use-Case Model (Actors, Use Cases) : A use-case

model (approximately 80% complete)all use caseshaving been identified in the use-case model survey, all

actors having been identified, and most use-case

descriptions (requirements capture) have beendeveloped.

o Supplementary Specifications : Supplementaryrequirements capturing the non functional requirements

are documented and reviewed.

o Test Suite: Tests implemented and executed to validate

the stability of the build for each executable releasescreated during the elaboration phase.

Construction Phase: Construction

Minimizing development costs by optimizing resources and

avoiding unnecessary scrap and rework.

Achieving adequate quality as rapidly as practical & Achievinguseful versions (alpha, beta, and other test releases) as rapidly

as practical

Completing the analysis, design, development and testing of allrequired functionality.

To iteratively and incrementally develop a complete product

that is ready to transition to its user community. This impliesdescribing the remaining use cases and other requirements,

fleshing out the design, completing the implementation, andtesting the software.

To decide if the software, the sites, and the users are all readyfor the application to be deployed.

To achieve some degree of parallelism in the work of development teams. Even on smaller

projects, there are typically components that can be developed independently of one another,allowing for natural parallelism between teams (resources permitting). This parallelism canaccelerate the development activities significantly; but it also increases the complexity ofresource management and workflow synchronization. A robust architecture is essential if anysignificant parallelism is to be achieved.


30/44

Construction Phase: Evaluation Criteria

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

Are all the stakeholders ready for the transition into the usercommunity?

Are actual resource expenditures versus planned still

acceptable?

Essential Artifacts (In order of importance) :

o The System: The executable system itself, ready tobegin "beta" testing.

o Deployment P lan: Initial version developed, reviewedand baselined. On smaller projects, this may be

embedded in the Software Development Plan.

o Implementation Model: Expanded from that createdduring the elaboration phase; all implementation

elements created by the end of the construction phase.

o Test Suite: Tests implemented and executed to validate

the stability of the build for each executable releasescreated during the construction phase.

o End-User Support Material: User Manuals and othertraining materials. Preliminary draft, based on use cases.

May be needed if the system has a strong user interface

aspect.

o Iteration Plan: Iteration plan for the transition phase

completed and reviewed.

o Design Model (and all constituent artifacts):

Updated with new design elements identified during thecompletion of all requirements.

o Data Model: Updated with all elements needed tosupport the persistence implementation (e.g. tables,

indexes, object-to-relational mappings, etc.)

Transition P hase: Objectives

Beta testing to validate the new system against user

expectations & Beta testing and parallel operation relative to alegacy system that it's replacing

Convertin o erational databases, trainin of users and


31/44

forces

Deployment-specific engineering such as cutover, commercialpackaging and production, sales roll-out, field personnel training

Tuning activities such as bug fixing, enhancement forperformance and usability assessment of the deployment

baselines against the complete vision and the acceptancecriteria for the product

Achieving user self-supportability, achieving stakeholder

concurrence that deployment baselines are complete, achievingstakeholder concurrence that deployment baselines are

consistent with the evaluation criteria of the vision

Transition P hase: Evaluation Criteria

Is the user satisfied?

Are actual resources expenditures versus planned expenditures

acceptable?

Essential Artifacts (In order of importance)

o The Product Build: Complete in accordance with the

product requirements. The final product should be

useable by the customer.o End-User Support Material: Materials that assist the

end-user in learning, using, operating and maintainingthe product should be complete in accordance with

requirements.

o Implementation Elements: The implementation is

complete and baselined, and the deployable elementshave been incorporated in the final product.


32/44

What I s an Iteration

What is an I teration ?

An iteration is one pass through all disciplines

An Iteration can be seen as mini project with a aplan,

deliverables and assessment, in which periodic corrections areapplied to the remainder of the project.

If you are using the four phases of RUP, you are already using

iterations, but more iterations can be added to each phase of

needed.

Phases & I terations

Phases & I terations

The focus of an iteration changes across the cycle.

Recall that each iteration is, in a sense a mini-waterfall.

The iteration plan contains the activities of requirmentselicitation and analysis, of design and implemenration, and of

integration and test

The emphasis on the various activities changes, however, from

one iteration to the next.

Iteration: Number and Duration

Duration of an Iteration is driven by:

o

+ size of organizationo + size of project

o - familiarity with the process, maturity

o - technical simplicity


33/44

Inception: 0 .. 1

Elaboration: 1 .. 3

Construction: 1 .. 3

Transition: 1 .. 2

If Inception consits only of planning and marketing, tghen theremay be no real iteration.

If you need a prototype or need to immediately address a

techinical risk you will need an interation

The number of iterations in Elaboration may depend on thecomplexity of the architecture, where you're starting from, and

the experience of the team

During Construction, you can use iterations to do a good job oftesting and integration

Transition would rfequire at least one iteration, and more.

Organization Based on Content

Organization Based on Content

Organization into disciplines shows the content of the process(Refer to Overview figure of RUP). - the activities, artifacts and

roles.

Key RUP Elements: Roles, Activities, Artifacts

If the process describes who is doing what and how, then theprimary elements of Rational Unified Process can be described

as:

Roles

This describes the who in the process


34/44

Activities

This describes the how in the process

Artifacts

This describes the what in the process

A Role performs certian Activities and is responsible forcertain Artifacts

Role Perform Activities and Produce Artifacts

An Artifact is a work product of the process.

Roles use artifacts to perform activities and product artifacts in the course ofperforming activities.

Artifacts are the responsibility of a sinle role. Even though one person may"own" the artifact, many other people may use it or update it if permission is

granted


35/44

Key RUP Element: Role

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.

Roles have a set of cohesive activities that they perform.

Activities of a particular role are closely related and functionallyrelated.

Roles Are Used for Resource Planning


36/44

The project typically has at its disposal a number of resources, individuals

which have specific competencies.

For example, Joe, Marie, Paul, Sylvia are individuals with different, althoughoverlapping competencies. Using the roles defined in the process, map

resources available to the project onto roles they can play.

An individual might act as several different roles in the same day: For

example, Sylvia might be a Reviewer in the morning, and a Use-CaseDesigner in the afternoon.

An individual might act as several roles simultaneously: For example, Janecould be both the Software Architect and the Designer of a certain class, andalso the Package Owner of the package that contains this class.

Several people can act as the same role to perform a certain activity

together, acting as a team: For example, Paul and Mary could be both Use-

Case Designers of the same use case.

Key RUP Element: Activity

Activity

An activity is a unit of work that an individual playing the

described role may be asked to perform.


37/44

The activity has a clear purpose, usually expressed in terms of

creating or updating some artifacts, such as a model, a class, ora plan.

Every activity is assigned to a specific role.

The granularity of an activity is generally a few hours to a few

days, it usually involves one role, and affects one or only asmall number of artifacts.

Examples of Activities: Develop Iteration Plan, Find Actors &

Use Cases, Review the Architecture, Use Case Design.

Key RUP Element: Artifact

Artifact

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

The responsibility of a Role

LIkely to be subject to configuration control

May contain other artifacts

Only one role is responsible for the artifact but others can use it

Key RUP Element Workflow

Workflow

A mere enumeration of all roles, activities and artifacts does not

constitute a process; we need a way to describe meaningful

sequences of activities that produce some valuable result, and toshow interactions between roles.

A workflow is a sequence of activities that produces a result of

observable value


38/44

Workflow Details

A grouping of activites that are performed in close collaboration

to accomplish some result (See figure on previous slide)

A unit of planning


39/44

output from one activity serving as the input to another activity

Used to group activities to provide a higher level of abstractionand to improve the comprehensibility of workflows

Workflow guides iterative development

Iteration Plan

A given iteration includes multiple disciplines

The form a discipline will take varies depending on its positionwithin the overall lifecycle and the nature of the project.

The Iteration Plan includes all relevant portions of the

disciplines for that particular iteration

Characteristics of Iteration Plan

o Instantiation of the disciplineo One for each iteration

o A fine-grained plan

o Expressed in terms of selected Workflow Details or

Activities from the disciplines

o Shows assigned resources


40/44

Artifact Set Evolution Over Development Phases

With the iterative approach, artifact sets mature over time

Economy of Artifacts

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


41/44

Additional P rocess Elements

Additional Process Elements

Additional process Elements

o Discipline Introduction

Concepts Workflow

Activity Overview

And associated Tool Mentors andGuidelines

Artifacts Overview And associated Templates and Guidelines

Guidelines Overview Roadmaps

Process Elements: Concepts

Attached to the relevant Discipline

Explanation of key ideas

Examples of Concepts Related to Requirementso Requirements management

o Types of Requirements

o Traceability

Example of Concepts Related to Analysis and Design

o Software Architecture

o Analysis mechanisms

o Web Architecture patterns


42/44

Process Elements: Guidelines

These are Rules, recommendations, heuristics that supportactivities and heir steps. They:

Describe specific techniques like transformations from oneartifact to another and Use of UML

Are attached to relevant discipline.

Are kept short and to the point.

Describe well-form artifacts and focus on qualities.

Are used also to assess the quality of artifacts.

Are tailored for the project.

Process Elements: Tool Mentors

Attached to relevant activity

Explain how to use specific tool to perform an activity or steps

in an activity

Linked by default to Rational tools:o RequisitePro: requirement management

o Rational Rose: visual modeling, using UML

o SoDA: documentation generation

o ClearQuest: change management, defect tracking

Process Element: Templates

Attached to relevant document type

Predefined artifacts, prototypes:

o Documents(Microsoft Word,Adobe Framemaker)

o MS Project

o HTML


43/44

o

o Can be tailored for the process

Process Element: Roadmap

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.

Chapter: 3 - Discipl ines - I

Discipline: Environment

Development Case

Discipline: Project Management

Planning for I terative Development

Concerns in Project Management

Discipline: Requirements

Major Concepts in the Use Case Model

What is in a Use-Case Model

Discipline: Business Modeling

Chapter: 4 - Disciplines II

Discipline: Analysis & Design


44/44

Discipline: Test

Discipline: Implementation

Discipline: Deployment

Discipline: Configuration & Change Management

Chapter: 5 - Implementing RUP

Implementing Process - The Steps

Environment Discipline

Environment: Workflow

Environment: Artifact Overview

Configuring a Process

The Development Case

Implementing a Process

Common Mistakes and Solutions

Best Practices for Process Implementation