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

Rational Unified Process Fundamentals

Module 1: Best Practices of Software Engineering

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

Evaluation

ManagementEnvironment

Each iteration results in an executable release

Risk ReductionRisk Reduction

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

Features

SoftwareRequirements

Test ScriptsDesign User

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

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( )

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( )

FileList

add( )delete( )

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

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

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

Phase Boundaries Mark Major Milestones

Lifecycle Objective Milestone

Lifecycle Architecture

Milestone (LCA)

Initial Operational Capability Milestone

Product Release

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

Devel. Devel. IterationIteration

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

ImplementationModel

Design Model

Use-Case Model

Models

Disciplines Implement-ation

Analysis &Design

Require-ments

Business Use-Case Model

Business Modeling

Business Object Model

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...

Rational Unified rup

Cap7_The Rational Unified Proces

HighTecRUP - Rational Unified Process1 RUP – Rational Unified Process Acadêmicos: Ítalo Afonso Maurício Gomes Maurício Martins Solano Júnior.

Unified Software Project Management with Rational ... · Unified Software Project Management with Rational ProjectConsole by Paul R. Wyrick Product Manager for Rational Project Console

Using a Single Business Pattern with the Rational Unified ... · 2 Using a Single Business Pattern with the Rational Unified Process (RUP) Figure 1 Rational Unified Process RUP is

Rational Unified Process Fundamentals Module 4: Disciplines II

Rational Expressions Fundamentals of College Algebra.

Software Project Management Rational Unified Framework

Rational unified processing

Heavy vs Light Methodologies: Bulimic or Anorexic?...Rational Unified Process (RUP) Some history … 1995 Rational Approach Objectory Process 3.8 IBM - Rational Unified Process v2003

Agile Methodology vs Rational Unified Process1

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

Introduction to Rational Unified Process. Objectives: Rational Unified Process l Describe the Unified Modeling Language (UML) l Define what a software.

Rational Unified Process Fundamentals Module 3: Disciplines I.

The Rational Unified Process (RUP) Unified Modeling ...scripts.cac.psu.edu/users/t/s/tsb4/IST210_SP2004/ist210/UML.pdf · The Rational Unified Process (RUP) and Unified Modeling Language

Rational Unified Process (RUP)

Rational Unified Process Methodology used by Rational Rose.

Rational Unified Process(Rup)

Rational Unified Process Fundamentals Module 4: Disciplines II.

Rational Unified Process Important