19 1

Continuing Best PracticesContinuing Best Practices

►Slide information taken in large part Slide information taken in large part from former Rational Corporation from former Rational Corporation slides and the RUP textbook - slides and the RUP textbook - considerably modified and considerably modified and supplemented for classroom use.supplemented for classroom use.

►Additional information taken from Additional information taken from other sources.other sources.

19 2

Practice 2: Manage Practice 2: Manage RequirementsRequirements

Control Changes

Develop Iteratively

Use Component

ArchitecturesManage Manage

RequirementsRequirements

Model Visually

VerifyQuality

A report by Standish Group cites forty percent of software projects fail. According to them, the mail causes of failure are: (note: there are others…) Poor Requirements Management; (eliciting, capturing, documenting,

modeling, verification; prototyping, throughout life cycle)(handling Change!! Addressing Risk)

Incorrect Definition of Requirements from the start of the project; and (feedback, verification…)

(Source: Chaos Report, http://www.standishgroup.com).

19 3

Requirements are dynamic -- Expect them to change during software development

Change cannot be stopped, but it can be managed!!

Practice 2: Manage Practice 2: Manage RequirementsRequirements

► Elicit, organize, and Elicit, organize, and documentdocument required functionality and constraintsrequired functionality and constraints

► Evaluate changes and determine impactsEvaluate changes and determine impacts► Track and document tradeoffs and decisionsTrack and document tradeoffs and decisions► Getting comprehensive system Getting comprehensive system requirements is a requirements is a continuous processcontinuous process► Obtaining a complete, exhaustive set of Obtaining a complete, exhaustive set of

requirements prior to development is requirements prior to development is impossible! (except for trivial impossible! (except for trivial

applications)applications)

19 4

Definitions: Requirements and Their Definitions: Requirements and Their ManagementManagement

► AA requirement requirement is a condition or capability to which the is a condition or capability to which the system must conform (functional / non-functional)system must conform (functional / non-functional)

► Requirements managementRequirements management is a systematic approach is a systematic approach toto Eliciting, organizing, and documenting the requirements of the Eliciting, organizing, and documenting the requirements of the

system, & system, & Establishing and maintaining agreement between the Establishing and maintaining agreement between the

customer/user and the project team on the changing customer/user and the project team on the changing requirements of the systemrequirements of the system

► Requirements specify ‘Requirements specify ‘whatwhat’ the system must do - not ’ the system must do - not howhow!!

► Requirements Management will be successful only if it Requirements Management will be successful only if it allows for allows for uncertaintyuncertainty early in development early in development

► Requirements Management must ensure Requirements Management must ensure requirementsrequirements coveragecoverage over time. (What does this mean to you?) over time. (What does this mean to you?)

19 5

How To Catch Requirements How To Catch Requirements Errors Errors EarlyEarly

► Effectively analyze the problem and Effectively analyze the problem and elicit user needselicit user needs

► Gain agreementGain agreement with customer/user on the requirements with customer/user on the requirements

► ModelModel interactioninteraction between the user and the system between the user and the system

► Establish a baseline and Establish a baseline and changechange controlcontrol processprocess

► Maintain forward and backward Maintain forward and backward traceabilitytraceability of requirements of requirements

► Use an Use an iterative development processiterative development process

► Create a ‘Create a ‘sharablesharable’ model with customers’ model with customers

► All requirements need not be known up frontAll requirements need not be known up front; however, ; however, before before startingstarting a a specificspecific iteration, those requirements iteration, those requirements must must be fully known.be fully known.

19 6

Problems Addressed by Requirements Problems Addressed by Requirements ManagementManagement

Root CausesRoot Causes SolutionsSolutionsA disciplined approach is built into requirements management

Communications are based on defined requirements

Requirements can be prioritized, filtered, and traced

Objective assessment of functionality and performance

Inconsistencies are more easily detected

RM tool provides a repository for requirements, attributes and tracing, with automatic links to documents

Insufficient Insufficient requirementsrequirements

Ambiguous Ambiguous communicationscommunications

Brittle architecturesBrittle architectures Overwhelming Overwhelming

complexitycomplexity Subjective Subjective

assessment assessment Undetected Undetected

inconsistenciesinconsistencies Poor testingPoor testing Waterfall developmentWaterfall development Uncontrolled changeUncontrolled change Insufficient Insufficient

automationautomation

19 7

Use Use Component Component

ArchitecturesArchitectures

Practice 3: Use Component-Based Practice 3: Use Component-Based ArchitecturesArchitectures

Control Changes

Develop Iteratively

Manage Requirements

Model Visually

VerifyQuality

Software architecture is a much misunderstood discipline by the industry

Some say that software architecture is the development product that yields the greatest ROI with respect to quality, schedule, and cost…

I wholeheartedly AGREE!

19 8

SoftwareSoftware ArchitectureArchitecture Defined Defined► Software architectureSoftware architecture addresses major addresses major

decisionsdecisions about the about the organizationorganization of a of a softwaresoftware systemsystem..

Deals with identification of the Deals with identification of the structuralstructural elementselements and and their their interfacesinterfaces by which a system is composed by which a system is composed (packages, subsystems, …)(packages, subsystems, …)

► For applications: maybe layered architectures or pipe-filter or client-For applications: maybe layered architectures or pipe-filter or client-serverserver

► For programs: w/OOP: UML diagrams; procedural: structure charts.For programs: w/OOP: UML diagrams; procedural: structure charts.

Architectural style guides Architectural style guides thisthis organization, these organization, these elements and their interfaces, their collaborations, and elements and their interfaces, their collaborations, and ompositionomposition

Architecture is the Architecture is the keykey part of design part of design – addresses – addresses questions on questions on HOWHOW the system will be built. the system will be built.

(Really, ‘first’ part of design…)(Really, ‘first’ part of design…)

19 11

Problems Addressed by Component Problems Addressed by Component ArchitecturesArchitectures

Components facilitate Components facilitate resilient architectures resilient architectures

Reuse of commercially Reuse of commercially available components and available components and frameworks is facilitatedframeworks is facilitated

Modularity enables separation Modularity enables separation of concernsof concerns

Components provide a natural Components provide a natural basis for configuration basis for configuration managementmanagement

Visual modeling tools provide Visual modeling tools provide automation for component-automation for component-based designbased design

Root CausesRoot Causes SolutionsSolutions Insufficient Insufficient

requirementsrequirements Ambiguous Ambiguous

communicationscommunications

Brittle architecturesBrittle architectures Overwhelming Overwhelming

complexitycomplexity Subjective assessment Subjective assessment Undetected Undetected

inconsistenciesinconsistencies Poor testingPoor testing Waterfall developmentWaterfall development

Uncontrolled changeUncontrolled change Insufficient Insufficient

automationautomation

19 12

Practice 4: Visually Model SoftwarePractice 4: Visually Model Software

Control Changes

Develop Iteratively

Use Component

Architectures

Manage Requirements

VerifyQualityModel Model

VisuallyVisually

A Model is a simplification of reality that produces a complete description of something from a specific perspective.

We build models when we cannot fully comprehend the complexity of some things.

Modeling helps the development team visualize, specify, construct, and document thestructure and behavior of a system’s architecture.

We will use a standard modeling language, UML (Unified Modeling Language).

19 13Visual modeling improves our abilityto manage software complexity

Practice 4: Visually Model SoftwarePractice 4: Visually Model Software

► Use to:Use to: Capture (model) both the Capture (model) both the structurestructure (static) and (static) and

behaviorbehavior (dynamic) of architectures and components (dynamic) of architectures and components Show how the Show how the elements of system fit togetherelements of system fit together and and

collaborate to provide functionality (dependencies, etc.)collaborate to provide functionality (dependencies, etc.) Hide / expose details as appropriate for the task – Hide / expose details as appropriate for the task –

► Implies a hierarchyImplies a hierarchy

Maintain consistency between a design and Maintain consistency between a design and implementationimplementation

Promote unambiguous communication via Promote unambiguous communication via standard standard modeling language, UMLmodeling language, UML

19 14

What Is the UML?What Is the UML?

►The Unified Modeling Language (UML) The Unified Modeling Language (UML) is a language foris a language for

►SpecifyingSpecifying►VisualizingVisualizing►ConstructingConstructing►DocumentingDocumenting

the the artifactsartifacts of a software-intensive of a software-intensive systemsystem

► UML is a ‘UML is a ‘notationnotation.’.’UML is an industry standard and is platform independent!It defines a graphical modeling language for presenting models and defines the semantics for each graphical element from different perspectives

19 15

Diagrams Are Views of a ModelDiagrams Are Views of a ModelA model is a completedescription of a systemfrom a particularperspective

DeploymentDiagrams

DeploymentDiagrams

Use-CaseDiagrams

Use-CaseDiagrams

ScenarioDiagrams

ScenarioDiagramsScenario

Diagrams

ScenarioDiagramsSequence

Diagrams

SequenceDiagrams

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsState

Diagrams

StateDiagrams

ComponentDiagrams

ComponentDiagramsComponent

Diagrams

ComponentDiagramsComponentDiagrams

ComponentDiagrams

Models

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsObject

Diagrams

ObjectDiagrams

ScenarioDiagrams

ScenarioDiagramsScenario

Diagrams

ScenarioDiagramsCollaboration

Diagrams

CollaborationDiagrams

ActivityDiagrams

ActivityDiagrams

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsClass

Diagrams

ClassDiagrams

Know these!!!!!

In the Unified Process, We use UML to provide nine different diagrams and five (4+1) major views: Use Case View, Logical View, Process View, Implementation View, and Deployment View

Explain:

Models are more inclusive than Views.

19 16

Visual Modeling Using UML Visual Modeling Using UML DiagramsDiagrams

Actor A

use-case 1

use-case 2

Actor B

user : »ç¿ëÀÚ

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

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

UI

MFC

RogueWave

global

DocumentApp

Persistence Window95

¹®¼ °ü¸® Ŭ¶óÀ̾ðÆ®.EXE

WindowsNT

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

WindowsNT

Windows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

AlphaUNIX

IBM Mainframe

µ¥ÀÌŸº£À̽º¼ ¹ö

Windows95

¹®¼ °ü¸® ¾ÖÇø´

ºÐ»ê È °̄æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ̧ 𵨠- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼ ¹ö

- À ´̄нº ̧ Ó½Å: ÀÀ¿ë ¼ ¹ö ¹× µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö

Document

FileManager

GraphicFile

File

Repository DocumentList

FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

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

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

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

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

Customernameaddr

withdraw()fetch()send()

receive()

<<entity>>

Forward Engineering (Code Generation)and

Reverse Engineering

Executable System

User InterfaceDefinition

Domain Expert

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close file

use-case 3

Source Code edit, compile, debug, link

Use-Case Diagram Class Diagram

Collaboration Diagram

Sequence Diagram

Component Diagram

State Diagram

Package Diagram

Deployment DiagramClass

• Single, common modeling language used throughout• Maps the artifacts between business engineering, requirements capture, and analysis, design, and testing.

19 17

Problems Addressed by Visual Problems Addressed by Visual ModelingModeling

use-cases and scenarios use-cases and scenarios unambiguously specify unambiguously specify behaviorbehavior

Models capture software Models capture software designs unambiguously designs unambiguously

Non-modular or inflexible Non-modular or inflexible architectures are exposedarchitectures are exposed

Unnecessary detail hidden Unnecessary detail hidden when appropriatewhen appropriate

Unambiguous designs Unambiguous designs reveal inconsistencies more reveal inconsistencies more readilyreadily

Application quality starts Application quality starts with with good designgood design

Visual modeling tools Visual modeling tools provide support for UML provide support for UML modelingmodeling

Root CausesRoot Causes SolutionsSolutions Insufficient Insufficient

requirementsrequirements Ambiguous Ambiguous

communicationscommunications Brittle architecturesBrittle architectures Overwhelming Overwhelming

complexitycomplexity Subjective assessmentSubjective assessment Undetected Undetected

inconsistenciesinconsistencies Poor testingPoor testing Waterfall developmentWaterfall development Uncontrolled changeUncontrolled change Insufficient Insufficient

automationautomation