Rational Unified Process Fundamentals Module 1: Best Practices of Software Engineering Rational...

Rational Unified Process Fundamentals

Module 1: Best Practices of Software Engineering

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

Objectives

Identify activities for understanding and solving software engineering problems.

Explain the Six Best Practices. Present RUP within the context of the Six

Best Practices.


Module 1 Content Outline

Software development problems The Six Best Practices RUP within the context of the Six Best

Practices


Symptoms of Software Development Problems

User or business needs not metRequirements churnModules don’t integrateHard to maintainLate discovery of flawsPoor quality or end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issues


Trace Symptoms to Root Causes

Needs not metRequirements churnModules don’t fitHard to maintainLate discoveryPoor qualityPoor performanceColliding developers Build-and-release

Insufficient requirementsAmbiguous communicationsBrittle architectures Overwhelming complexityUndetected inconsistencies Poor testingSubjective assessmentWaterfall development Uncontrolled changeInsufficient automation

Symptoms Root Causes Best Practices

Ambiguous communications

Undetected inconsistencies

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change



Modules don’t fit



Software development problemsThe Six Best Practices RUP within the context of the Six Best

Practices


Best PracticesProcess Made Practical

Develop IterativelyManage Requirements


Model Visually (UML)Continuously Verify Quality

Manage Change

Practice 1: Develop Iteratively


Waterfall Development Characteristics

Delays confirmation of critical risk resolution

Measures progress by assessing work-products that are poor predictors of time-to-completion

Delays and aggregates integration and testing

Precludes early deployment

Frequently results in major unplanned iterations

Code and unit test

Design

Subsystem integration

System test

Waterfall Process Requirements

analysis


Iterative Development Produces an Executable

InitialPlanning

Planning

Requirements

Analysis & Design

Implementation

Deployment

Test

Evaluation

ManagementEnvironment

Each iteration results in an executable release


Risk ReductionRisk Reduction

Time

Risk

Waterfall Risk

Iterative Risk

Risk Profiles


Practice 2: Manage Requirements





Manage Change


Requirements Management

A requirement is a condition or capability a system must have.

Managing the requirements of a project offers a number of solutions to the root causes of SW development problems. A disciplined approach is built into requirements

management. Communications are based on defined requirements Requirements can be prioritized and traced. An objective assessment of functionality and

performance is possible. Inconsistencies are detected more easily.


Requirements Management

Making sure you solve the right problem build the right system

by taking a systematic approach to eliciting organizing documenting managing

the changing requirements of a software application.


Aspects of Requirements Management

Analyze the Problem Understand User Needs Define the System Manage Scope Refine the System Definition Manage Changing Requirements


Problem

Solution Space

Problem Space

Needs

Features

SoftwareRequirements

Test ScriptsDesign User

Docs

The The Product Product

to Be to Be BuiltBuilt

Traceability

Map of the Territory


Practice 3: Use Component Architectures



Use Component ArchitecturesModel Visually (UML)

Continuously Verify QualityManage Change


Resilient Component-Based Architectures

A system’s architecture is perhaps the most important deliverable for the purpose of managing the diverse viewpoints of the various stakeholders.

The architecture is helpful in controlling the incremental and iterative development of a system throughout its lifecycle.


Resilient Component-Based Architectures

Resilient Meets current and future requirements Improves extensibility Enables reuse Encapsulates system dependencies

Component-based Reuse or customize components Select from commercially available components

Evolve existing software incrementally


Purpose of a Component-Based Architecture

Basis for reuse Component reuse Architecture reuse

Basis for project management Planning Staffing Delivery

Intellectual control Manage complexity Maintain integrity System-System-

softwaresoftware

MiddlewareMiddleware

Business-Business-specificspecific

Application-Application-specificspecific

Component-based architecture with layers


Practice 4: Model Visually (UML)





Manage Change


Why Model Visually?

To: Capture structure and behavior Show how system elements fit together Keep design and implementation consistent Hide or expose details as appropriate Promote unambiguous communication

UML provides one language for all practitioners


Visual Modeling with Unified Modeling Language

ActivityDiagrams

Models

Dynamic Diagrams

Static Diagrams

Multiple views Precise syntax and

semantics

SequenceDiagrams

CollaborationDiagrams

StatechartDiagrams

DeploymentDiagrams

ComponentDiagrams

ObjectDiagrams

ClassDiagrams

Use-CaseDiagrams


Visual Modeling Using UML Diagrams

Actor A

Use Case 1

Use Case 2

Actor B

user : Clerk

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

9: sortByName ( )

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

Window95

¹®¼ °ü¸® Å¬¶óÀÌ¾ðÆ®.EXE

WindowsNT

¹®¼ °ü̧ ® ¿£Áø.EXE

WindowsNT

Windows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

AlphaUNIX

IBM Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼ ¹ö

Windows95

¹®¼ °ü¸® ¾ÖÇÃ¸´Document

FileManager

GraphicFile

File

Repository DocumentList

FileList

usermainWnd fileMgr :

FileMgrrepositorydocument :

DocumentgFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼ ¿¡ ́ ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼

°́ Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È ̧é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ́ ëÇØ ÀÌ̧ §º°·Î Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.

Forward and Reverse Engineering

TargetSystem

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close fileUse Case 3

Use-CaseDiagram Class Diagram

Collaboration Diagram

Sequence Diagram

Component Diagram

StatechartDiagram

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

Deployment Diagram


Practice 5: Continuously Verify Quality




Model Visually (UML)ContinuouslyVerify Quality

Manage Change


Continuously Verify Your Software’s Quality

Verifying SW quality offers a number of solutions to the root causes of SW development problems. Project status is objective, not subjective. Objective assessment exposes inconsistencies

in requirements, design and implementation. Testing can be focused on the highest areas of

risk. Defects are identified earlier thus reducing the

cost of fixing them.


Continuously Verify Your Software’s Quality

Cost

TransitionConstructionElaborationInception

Software problems are100 to 1000 times more costly

to find and repair after deployment

Cost to Repair Software Cost of Lost Opportunities Cost of Lost Customers


Testing Dimensions of Quality

Reliability Test the application

behaves consistently and predictably.

Performance Test online response

under average and peak loading

Functionality Test the accurate

workings of each usage scenario

Usability Test application from the

perspective of convenience to end-user.

Supportability Test the ability to maintain

and support application under production use


UML Model and

Implementation

Tests

Iteration 1Iteration 1

Test Suite 1Test Suite 1







Test Each Iteration


Test Within the Product Development Lifecycle


Practice 6: Manage Change





Manage Change


Why manage change?

A key challenge when you are managing SW-intensive systems is that you must cope with multiple developers organized into teams, possible at different sites, working together on multiple iterations, releases, products, and platforms.

Without some sort of disciplined control, the development process rapidly degenerates into chaos.


ALERTREPORT

WorkspaceManagement

Process Integration

Parallel Development

Build Management

CM is more than just check-in and check-out

What Do You Want to Control?

Secure workspaces for each developer Automated integration/build management Parallel development


Aspects of a CM System

Change Request Management (CRM) Configuration Status Reporting Configuration Management (CM) Change Tracking Version Selection Software Manufacture


Unified Change Management (UCM)UCM involves: Management across the lifecycle

System Project Management

Activity-Based Management Tasks Defects Enhancements

Progress Tracking Charts Reports


Best Practices Reinforce Each Other

Validates architectural decisions early on

Addresses complexity of design/implementation incrementally

Measures quality early and often

Evolves baselines incrementally

Ensures users involved as requirements evolve

Best PracticesDevelop Iteratively

Manage Requirements




Manage Change



Software development problems The Six Best Practices RUP within the context of the Six Best

Practices


Rational Unified Process Implements Best Practices



Use Component ArchitecturesModel Visually (UML)

Continuously Verify QualityManage Change


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 What, When, and How, in order to reach a certain goal.

New or changed

requirements

New or changed

system

Software EngineeringProcess


InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

Process Structure - Lifecycle Phases

Rational Unified Process has four phases: Inception - Define the scope of project Elaboration - Plan project, specify features, baseline

architecture Construction - Build the product Transition - Transition the product into end-user

community

time


Phase Boundaries Mark Major Milestones


Lifecycle Objective Milestone

(LCO)

Lifecycle Architecture

Milestone (LCA)

Initial Operational Capability Milestone

(IOC)

Product Release

time


Iterations and Phases

An iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release (internal or external).

PreliminaryPreliminaryIterationIteration

Architect.Architect.IterationIteration

Architect.Architect.IterationIteration

Devel. Devel. IterationIteration



TransitionTransitionIterationIteration

TransitionTransitionIterationIteration


Minor Milestones: Releases


Bringing It All Together: The Iterative Approach

Disciplines group activities logically

In an iteration, you walk through all disciplines


Disciplines Produce Models

Realized ByImplemented

By

ImplementationModel

Design Model

Use-Case Model

Models

Disciplines Implement-ation

Analysis &Design

Require-ments

Business Use-Case Model

Business Modeling

Business Object Model

BBBB

Realized By

AutomatedBy


Disciplines Guide Iterative Development Business Modeling: Workflow

Requirements: Workflow


Overview of Rational Unified Process Concepts


Review

Best Practices guide software engineering by addressing root causes.

Best Practices reinforce each other. Process guides a team on who does what,

when, and how. Rational Unified Process is a means of

achieving Best Practices.

Rational Unified Process Fundamentals Module 1: Best Practices of Software Engineering Rational...

Documents

Transcript of Rational Unified Process Fundamentals Module 1: Best Practices of Software Engineering Rational...