Object-Oriented Analysis and Design

Lecture 1: Best Practices of

Software Engineering
Objectives
 Identify activities for understanding and
solving software engineering problems.
 Explain the Six Best Practices.
 Present the Rational Unified Process (RUP)
within the context of the Six Best Practices.

Object Oriented Analysis and Design 2

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

Object Oriented Analysis and Design 3

Symptoms of Software Development Problems
User or business needs not met
Requirements not addressed
Modules not integrating
Difficulties with maintenance
Late discovery of flaws
Poor quality of end-user experience
Poor performance under load
No coordinated team effort
Build-and-release issues

Object Oriented Analysis and Design 4

Trace Symptoms to Root Causes
Symptoms
Needs not met
Requirements churn
Modules do notfitfit
don’t
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Object Oriented Analysis and Design
Root Causes Best Practices
Insufficient requirements Develop Iteratively
Ambiguous communications
Brittle architectures Manage Requirements
Overwhelming complexity
Use Component Architectures
Undetected inconsistencies
Poor testing
Model Visually
Model Visually (UML)
(UML)
Subjective assessment
Waterfall development Continuously Verify
Verify Quality
Quality
Continuously
Uncontrolled change
Insufficient automation Manage Change
5
Content Outline
 Software development problems
 The Six Best Practices
 RUP within the context of the Six Best
Practices

Object Oriented Analysis and Design 6

Practice 1: Develop Iteratively

Best Practices
Process Made Practical

Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change

Object Oriented Analysis and Design 7

Waterfall Development Characteristics
 Delays confirmation of
critical risk resolution
Waterfall Process  Measures progress by
assessing work
Requirements products that are poor
analysis
predictors of time-to-
Design completion
Code and unit test
 Delays and aggregates
Subsystem integration integration and testing
System test  Precludes early
deployment
 Frequently results in
major unplanned
iterations

Object Oriented Analysis and Design 8

Iterative Development Produces an Executable
Requirements
Analysis & Design
Planning
Implementation
Initial
Planning Management
Environment
Test

Evaluation

Deployment
Each iteration
results in an
executable release

Object Oriented Analysis and Design 9

Risk Profiles

Waterfall Risk
Risk

Risk Reduction

Iterative Risk

Time

Object Oriented Analysis and Design 10

Practice 2: Manage Requirements

Best Practices
Process Made Practical

Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change

Object Oriented Analysis and Design 11

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.

Object Oriented Analysis and Design 12

Aspects of Requirements Management
 Analyze the Problem
 Understand User Needs
 Define the System
 Manage Scope
 Refine the System Definition
 Manage Changing Requirements

Object Oriented Analysis and Design 13

Map of the Territory

Problem Problem
Space
Needs

Solution
Features Space

The
Product
Software to Be
Requirements Built

Test Scripts Design User

Docs

Object Oriented Analysis and Design 14

Practice 3: Use Component Architectures

Best Practices
Process Made Practical

Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change

Object Oriented Analysis and Design 15

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

Object Oriented Analysis and Design 16

Purpose of a Component-Based Architecture
 Basis for reuse
 Component reuse
 Architecture reuse Component-based
 Basis for project management architecture with
layers
 Planning
 Staffing Application-
specific
 Delivery Business-
specific
 Intellectual control
 Manage complexity Middleware

 Maintain integrity System-

software

Object Oriented Analysis and Design 17

Practice 4: Model Visually (UML)

Best Practices
Process Made Practical

Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change

Object Oriented Analysis and Design 18

Why Model Visually?
 Captures structure and behavior
 Shows how system elements fit together
 Keeps design and implementation
consistent
 Hides or exposes details as appropriate
 Promotes unambiguous communication
 The UML provides one language for all
practitioners

Object Oriented Analysis and Design 19

Visual Modeling With the Unified Modeling Language
 Multiple views
 Precise syntax and Static
semantics Diagrams
Class
Use-Case Diagrams
Sequence Diagrams Object
Diagrams Diagrams

Collaboration Component
Diagrams Models Diagrams

Dynamic Statechart Deployment

Diagrams Diagrams Diagrams
Activity
Diagrams

Object Oriented Analysis and Design 20

Visual Modeling Using UML Diagrams
Use-Case
Diagram Statechart
Class Diagram Diagram add file

DocumentList

Use Case 1 FileMgr Document

add( )
name : int
Actor A Actor B fetchDoc( ) delete( )
docid : int
sortByName( ) numField : int Writing
add file [ numberOffile==MAX ] /
flag OFF
get( )
open( ) read() fill the
Use Case 2 close( ) code..
Openning
FileList read( )
sortFileList( )
fList create( )
fillDocument( ) close file
add( )
delete( )
1

Use Case 3 Reading

close file
Closing

rep

File
Repository

(from Persistence)

name : char * = 0

readDoc( )
readFile( )
read( )
GrpFile

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

Collaboration 9: sortByName ( )
Repository DocumentList
Diagram
Diagram 1: Doc view request ( )
mainWnd : MainWnd
L

2: fetchDoc( )
FileManager
Window95

¹®¼-° ü¸®
Windows95

Windows95

Ŭ¶óÀ̾ðÆ®.EXE

4: create ( ) gFile : GrpFile Document ¹®¼-° ü¸® ¾ÖÇø´

Windows
8: fillFile ( ) NT

user : Clerk Solaris

fileMgr : FileMgr ¹®¼-°ü¸® ¿£Áø.EXE

3: create ( ) GraphicFile Alpha

UNIX
ÀÀ¿ë¼-¹ö.EXE
6: fillDocument ( )
File FileList Windows
NT

IBM

7: readFile ( ) Mainframe

5: readDoc ( )
document : Document
repository : Repository
µ¥ÀÌŸº£À̽º¼-¹ö

user
mainWnd fileMgr :
FileMgr
document :
Document
gFile repository
Component
ƯÁ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ° ¡ ¿äûÇÑ´Ù.
1: Doc view request ( )

Diagram
2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )
Target
È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â
¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼-
° ´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )

8: fillFile ( )
7: readFile ( ) System
Forward and
È-¸é ° ´Ã¼´Â ÀоîµéÀÎ 9: sortByName ( )
° ´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡
º¸¿©ÁØ´Ù.

Sequence Reverse
Diagram Engineering
Object Oriented Analysis and Design 21
Practice 5: Continuously Verify Quality

Best Practices
Process Made Practical

Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously
Verify Quality
Manage Change

Object Oriented Analysis and Design 22

Continuously Verify Your Software’s Quality
Software problems are
100 to 1000 times more costly
to find and repair after deployment

 Cost to Repair Software

 Cost of Lost Opportunities
Cost  Cost of Lost Customers

Inception Elaboration Construction Transition

Object Oriented Analysis and Design 23

Testing Dimensions of Quality
Usability
 Test application
from the perspective
of convenience to
end user.

Functionality Reliability
 Test the accurate  Test that the application
workings of each behaves consistently
usage scenario. and predictably.

Supportability
 Test the ability to
maintain and support
application under
production use.
Performance
 Test the online response
under average and
peak loading.

Object Oriented Analysis and Design 24

Test Each Iteration
Iteration 1 Iteration 2 Iteration 3 Iteration 4

UML Model
and
Implementation

Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4

Tests

Object Oriented Analysis and Design 25

 Test Within the Product Development Lifecycle
Iteration Iteration Iteration
X X+1 X+2

Requirements Capture

Analysis and Design

Project
Planning Implementation
Build

Define Validate Test and Achieve Improve

Mission Build Evaluate Mission Assets

Verify Approach

Time

Object Oriented Analysis and Design 26

Practice 6: Manage Change

Best Practices
Process Made Practical

Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change

Object Oriented Analysis and Design 27

What Do You Want to Control?
 Secure workspaces for each developer
 Automated integration/build management
 Parallel development
Workspace Parallel
Management Development

Configuration
Management is
more than just
check-in and REPORT ALERT
check-out Process Build
Integration Management

Object Oriented Analysis and Design 28

Aspects of a CM System
 Change Request Management (CRM)
 Configuration Status Reporting
 Configuration Management (CM)
 Change Tracking
 Version Selection
 Software Manufacture

Object Oriented Analysis and Design 29

Unified Change Management (UCM)
UCM involves:
 Management across the lifecycle
 System
 Project Management
 Activity-Based Management
 Tasks
 Defects
 Enhancements
 Progress Tracking
 Charts
 Reports

Object Oriented Analysis and Design 30

Best Practices Reinforce Each Other
Best Practices
Develop Iteratively

Ensures users are involved

Manage Requirements as requirements evolve

Validates architectural
Use Component Architectures
decisions early on

Addresses complexity of
Model Visually (UML) design/implementation incrementally

Continuously Verify Quality Measures quality early and often

Manage Change Evolves baselines incrementally

Object Oriented Analysis and Design 31

Module 1 Content Outline
 Software development problems
 The Six Best Practices
 RUP within the context of the Six Best
Practices

Object Oriented Analysis and Design 32

Rational Unified Process Implements Best Practices

Best Practices
Process Made Practical

Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change

Object Oriented Analysis and Design 33

Achieving Best Practices

 Iterative approach
 Guidance for activities
and artifacts
 Process focus on
architecture
 Use cases that drive
design and
implementation
 Models that abstract
the system

Object Oriented Analysis and Design 34

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 Software Engineering New or changed

requirements Process system

Object Oriented Analysis and Design 35

Process Structure - Lifecycle Phases

Inception Elaboration Construction Transition

time

Rational Unified Process has four phases:

 Inception - Define the scope of project
 Elaboration - Plan project, specify features and
baseline architecture
 Construction - Build the product
 Transition - Transition the product into end-user
community

Object Oriented Analysis and Design 36

Phase Boundaries Mark Major Milestones

Inception Elaboration Construction Transition

time

Lifecycle Lifecycle Initial Operational Product

Objective Architecture Capability Release
Milestone Milestone Milestone
(LCO) (LCA) (IOC)

Object Oriented Analysis and Design 37

Iterations and Phases

Inception Elaboration Construction Transition

Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

Minor Milestones: Releases

An iteration is a distinct sequence of activities based on

an established plan and evaluation criteria, resulting in an
executable release (internal or external).

Object Oriented Analysis and Design 38

Bringing It All Together: The Iterative Approach
In an
iteration,
you walk
through all
disciplines.

Disciplines
group
activities
logically.

Object Oriented Analysis and Design 39

Disciplines Produce Models

Business Require- Analysis & Implement-

Disciplines Modeling Design ation
ments

Models

Implemented
Realized By By
Realized Business Use- Use-Case
By Case Model Model

B
B B B
Automated
Business By Design Model Implementation
Object Model Model

Object Oriented Analysis and Design 40

Disciplines Guide Iterative Development
Business
Modeling:
Workflow

Requirements:
Workflow
Object Oriented Analysis and Design 41
Overview of Rational Unified Process Concepts
Divided into Considers Described by

Workflow
Phase Iteration Discipline Detail
Participates in References

Role Activity
Responsible for Modifies

Model
Document Model
Element
Artifact

Object Oriented Analysis and Design 42

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.
 The Rational Unified Process is a means of
achieving Best Practices.

Object Oriented Analysis and Design 43