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.

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…)incorrect definition of requirements

from the start of the project; and (feedback, verification…)poor requirements management throughout the development lifecycle. (handling Change!!! Addressing Risk)(Source: Chaos Report, http://www.standishgroup.com).

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 document Elicit, organize, and document required functionality and constraintsrequired functionality and constraints

► Evaluate changes and determine impactsEvaluate changes and determine impacts► Track and document tradeoffs and Track and document tradeoffs and decisions 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 applications)impossible! (except for trivial applications)

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 conformsystem must conform

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

system, & system, & Establishing and maintaining agreement between the customer/user Establishing and maintaining agreement between the customer/user

and the project team on the changing requirements of the systemand the project team on the changing requirements of the system

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

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

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

How To Catch Requirements How To Catch Requirements Errors Errors EarlyEarly

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

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

► ModelModel interaction interaction between the user and the system between the user and the system

► Establish a baseline and change control processEstablish a baseline and change control process

► 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

► For a given iteration, For a given iteration, all requirements need not be known up all requirements need not be known up frontfront; however, before ; however, before developingdeveloping that iteration, all that iteration, all requirements should be known.requirements should be known.

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 assessment Subjective assessment Undetected Undetected

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

automationautomation

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!

Software Architecture DefinedSoftware Architecture Defined► Software architectureSoftware architecture addresses major addresses major

decisionsdecisions about the about the organizationorganization of a of a software system.software system.

Selection of the Selection of the structural elementsstructural elements and their and their interfacesinterfaces by which a system is composed by which a system is composed (packages, subsystems, …)(packages, subsystems, …)

► Addresses how the application will be built….Addresses how the application will be built….► Behavior as specified in collaborations among those elementsBehavior as specified in collaborations among those elements► Composition of these structural and behavioral elements into Composition of these structural and behavioral elements into

progressively larger subsystemsprogressively larger subsystems

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

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

Resilient, Component-Based Resilient, Component-Based

ArchitecturesArchitectures ► Good architectures meet their requirements, are Good architectures meet their requirements, are

resilient,resilient, and are and are component-basedcomponent-based ► A A resilientresilient architecture enables architecture enables

Improved maintainability and extensibilityImproved maintainability and extensibility Economically-significant reuseEconomically-significant reuse Clean division of work among teams of developersClean division of work among teams of developers Encapsulation of hardware and system dependenciesEncapsulation of hardware and system dependencies

► A A component-basedcomponent-based architecture permits architecture permits Reuse or customization of existing components Reuse or customization of existing components Choice of thousands of commercially-available componentsChoice of thousands of commercially-available components Incremental evolution of existing softwareIncremental evolution of existing software

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 requirementsInsufficient requirements 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 automationInsufficient automation

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

Visual modeling improves our abilityto manage software complexity

Practice 4: Visually Model SoftwarePractice 4: Visually Model Software

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

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

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

a hierarchy (helps greatly when dealing with a hierarchy (helps greatly when dealing with complexity…)complexity…)

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

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

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

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

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:

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 throughoutMaps the artifacts between business engineering, requirements capture, and analysis, design, and testing .

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 reveal Unambiguous designs reveal inconsistencies more readilyinconsistencies more readily

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 automationInsufficient automation