Best Practices of

Software Engineering
 Objectives: Best Practices of SE

• Explore the symptoms and root causes of

software development problems
• Explain Rational’s six best practices for
software development
• Look at how Rational’s best practices
address the root causes of software
development problems
Software Development Situation Analysis

World economies Applications expanding

increasingly software in size, complexity, &
dependent distribution

Business demands Not enough qualified

increased productivity & people
quality in less time
Software Development is a Job for Teams

Challenges
• Larger teams Performance
Engineer
• Specialization
Analyst
• Distribution
• Rapid technology change Project
Manager
Developer

Tester

Release
Engineer
How Are We Doing?
Performance
Engineer
Analyst

Project
Manager
Developer

Tester

Release
Engineer
 Symptoms of Software Development
Problems
• Inaccurate understanding of end-user needs
• Inability to deal with changing requirements
• Modules that don’t fit together
• Software that’s hard to maintain or extend
• Late discovery of serious project flaws
• Poor software quality
• Unacceptable software performance
• Team members in each other’s way, unable to
reconstruct who changed what, when, where, why
• An untrustworthy build-and-release process
 Treating Symptoms Does Not Solve the
Problem
Root Causes
Symptoms insufficient requirements
end-user needs
ambiguous
changing communications
requirements
brittle architectures
modules don’t fit
overwhelming
hard to maintain complexity
late discovery undetected
poor quality inconsistencies

poor poor testing

performance subjective
colliding assessment
developers waterfall
development
build-and-release Diagnose uncontrolled change
insufficient automation
 Root Causes of Software Development
Problems

• Insufficient requirements management

• Ambiguous and imprecise communications
• Brittle architectures
• Overwhelming complexity
• Undetected inconsistencies among requirements,
designs, and implementations
• Insufficient testing
• Subjective project status assessment
• Delayed risk reduction due to waterfall development
• Uncontrolled change propagation
• Insufficient automation
 Best Practices Address Root Causes
Root Causes Best Practices
 Insufficient requirements  Develop iteratively
 Ambiguous  Manage requirements
communications  Use component
 Brittle architectures architectures
 Overwhelming complexity  Model the software visually
 Subjective assessment  Verify quality
 Undetected  Control changes
inconsistencies
 Poor testing
 Waterfall development
 Uncontrolled change
 Insufficient automation
 Addressing Root Causes Eliminates the Symptoms

Symptom Root Causes Best

s insufficient Practices
end-user requirements develop
needs ambiguous iteratively
changing communications manage
requirements brittle requirements
modules don’t architectures use component
fit overwhelming architectures
hard to complexity model the
maintain undetected software
inconsistencies visually
late discovery
poor testing verify quality
poor quality
subjective control changes
poor
performance assessment

colliding waterfall
developers development

build-and- uncontrolled
release change
insufficient
Best Practices of Software Engineering

Develop Iteratively

Use
Manage Model Verify
Component Visually
Requirements Architectures Quality

Control Changes
 Best Practices Enable High-Performance Teams
Results
Performance
• More Successful Engineer
projects Analyst

Project
Manager
Developer
Develop Iteratively

Tester
Use Model
Manage Component Visually Verify
Requirements Architectures Quality
Release
Engineer
Control
Changes
Practice 1: Develop Software
Iteratively
Develop Iteratively

Use
Manage Model Verify
Component Visually
Requirements Quality
Architectures

Control Changes
 Practice 1: Develop Software Iteratively

• An initial design will likely be flawed with respect

to its key requirements
• Late-phase discovery of design defects results in
costly over-runs and/or project cancellation

The time and money spent

implementing a
faulty design are not recoverable
 Waterfall Development
Requirements
Analysis

Design

Code & Unit

Testing

Subsystem
Testing

System Testing

T I M E
Waterfall Development Delays
Reduction of Risk

Requirements
R Analysis
I
Design
S
K Code & Unit
Testing

Subsystem
Testing

System Testing

T I M E
 Apply the Waterfall Iteratively to System
Increments
Iteration 1 Iteration 2 Iteration 3
R R R
D D D
C C C
T T T

T I M E

• Earliest iterations address greatest risks

• Each iteration produces an executable release, an
additional increment of the system
• Each iteration includes integration and test
Iterative Development Accelerates
Risk Reduction

K Iterative Waterfall

Iteration Iteration Iteration Iteration Iteration Iteration Iteration

T I M E
 Iterative Development Characteristics

• Critical risks are resolved before making large

investments
• Initial iterations enable early user feedback
• Testing and integration are continuous
• Objective milestones provide short-term focus
• Progress is measured by assessing
implementations
• Partial implementations can be deployed
 Apply Best Practices Throughout the Life
Cycle Phases
Process Workflows Inception Elaboration Construction Transition

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
 Problems Addressed by Iterative Development
Root Causes
 Insufficient requirements
 Ambiguous
communications
 Brittle architectures
 Overwhelming complexity
 Subjective assessment
 Undetected
inconsistencies
 Poor testing
 Waterfall development
 Uncontrolled change
 Insufficient automation
Solutions
Enables and encourages user
feedback
Serious misunderstandings evident
early in the life cycle
Development focuses on critical
issues
Objective assessment thru testing
Inconsistencies detected early
Testing starts earlier
Risks identified and addressed
early
 Practice 2: Manage
Requirements
Develop Iteratively

Use
Model Verify
Manage Component Visually Quality
Requirements Architectures

Control Changes
 Practice 2: Manage Requirements

• Elicit, organize, and

document required
functionality and constraints
• Evaluate changes and
determine their impact
• Track and document tradeoffs
and decisions
Requirements are dynamic --
Expect them to change during software
development
 Definitions: Requirements and Their
Management
• A requirement is a condition or capability to
which the system must conform
• Requirements management is a systematic
approach to
– Eliciting, organizing, and documenting the
requirements of the system, and
– Establishing and maintaining agreement
between the customer/user and the project
team on the changing requirements of the
system
 Agreement on What the System Should
Do
The Goal

Customer System
User Community To Be Built

Requirements Surrogate
Verification Goal

Adapted from Al Davis

Requirements
Requirements Trace To Many Project
Elements
 How To Catch Requirements Errors Early

• Effective problem analysis and elicitation of user needs

• Gain agreement with the customer/user on the
requirements
• Model interaction between the user and the system
• Establish a baseline and change control process
• Maintain forward and backward traceability of
requirements
• Use an iterative process
 Problems Addressed by Requirements Man
Root Causes Solutions
 Insufficient A disciplined approach is built
requirements into requirements
 Ambiguous management
communications Communications are based on
 Brittle architectures defined requirements
 Overwhelming Requirements can be
complexity prioritized, filtered, and traced
 Subjective
assessment Objective assessment of
functionality and performance
 Undetected
inconsistencies Inconsistencies are more
 Poor testing easily detected
 Waterfall development RM tool provides a repository
 Uncontrolled change for requirements, attributes
 Insufficient and tracing, with automatic
automation links to documents
Practice 3: Use Component-
Based Architectures
Develop Iteratively

Manage Use Model Verify

Verify
Requirements Component Visually Quality
Quality
Architectures

Control Changes
 Software Architecture Defined
• Software architecture encompasses significant
decisions about the organization of a software system
– Selection of the structural elements and their
interfaces by which a system is composed
– Behavior as specified in collaborations among those
elements
– Composition of these structural and behavioral
elements into progressively larger subsystems
– Architectural style that guides this organization, these
elements and their interfaces, their collaborations,
and their composition
 Architectural Concerns
• Software architecture is concerned with structure and
behavior and context:
– Usage
– Functionality
– Performance
– Resilience
– Reuse
– Comprehensibility
– Economic and technological constraints and tradeoffs
– Aesthetics
 Resilient, Component-Based Architectures
• Good architectures meet their requirements, are
resilient, and are component-based
• A resilient architecture enables
– Improved maintainability and extensibility
– Economically-significant reuse
– Clean division of work among teams of developers
– Encapsulation of hardware and system dependencies
• A component-based architecture permits
– Reuse or customization of existing components
– Choice of thousands of commercially-available
components
– Incremental evolution of existing software
 Example: Component-Based
Architecture
Lead Tracking
User Interface
Licensing
User Interface

User Interface
Mechanisms

Customer Product License

Key:
- Purchased Oracle Vantive
- Built
- New
 Problems Addressed by Component
Architectures
Root Solutions
Components facilitate resilient
Causes architectures
 Insufficient requirements Reuse of commercially available
 Ambiguous components and frameworks is
communications facilitated
 Brittle architectures Modularity enables separation of
 Overwhelming complexity concerns
 Subjective assessment Components provide a natural basis
 Undetected inconsistencies for configuration management
 Poor testing Visual modeling tools provide
automation for component-based
 Waterfall development
design
 Uncontrolled change
 Insufficient automation
 Practice 4: Visually Model
Software
Develop Iteratively

Use
Manage Verify
Component Model
Requirements Quality
Architectures Visually

Control Changes
 Practice 4: Visually Model Software

• Capture the structure and behavior of architectures and

components
• Show how the elements of the system fit together
• Hide or expose details as appropriate for the task
• Maintain consistency between a design and its
implementation
• Promote unambiguous communication

Visual modeling improves our ability

to manage software complexity
 What Is the UML?
• The Unified Modeling Language (UML) is
a language for
• Specifying
• Visualizing
• Constructing
• Documenting
the artifacts of a software-intensive system
 Diagrams Are Views of a Model
A model is a complete
description of a system
from a particular
State
perspective State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Activity Diagrams
Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Sequence
Diagrams State
Diagrams
Diagrams Model Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Component
Collaboration
Diagrams Deployment Diagrams
Diagrams Diagram Diagrams
 Visual Modeling Using UML Diagrams
Use-Case Diagram Class Diagram State Diagram add file

DocumentList
FileMgr Document

add( )
name : int
fetchDoc( ) delete( ) docid : int
sortByName( ) numField : int
Writing
add file [ numberOffile==MAX ] /
get( ) flag OFF
open( ) read() fill the
close( ) code..
FileList read( )
sortFileList( ) Openning

Use Case 1 add( )

fList create( )
fillDocument( )
delete( )
1 close file

Actor A Actor B
close file
Closing
Reading

rep
Use Case 2 File

<<entity>>
Repository

Customer
(from Persistence) GrpFile
read( )

name
name : char * = 0
read( )
readDoc( )

addr
readFile( ) open( )
create( )
fillFile( )

receive()
Use Case 3 withdraw()
Domain fetch()
Expert UI
send()
Deployment
MFC Class Diagram
DocumentApp

ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼-¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö

DocumentList
RogueWave

Persistence
Repository Window95 Windows95

9: sortByName ( ) Windows95

global

¹®¼-°ü¸®

FileManager Ŭ¶óÀ̾ðÆ®.EXE
¹®¼-°ü¸® ¾ÖÇø´

User Interface mainWnd : MainWnd Windows

Package
NT

1: Doc view request ( ) L

Definition Document Solaris

2: fetchDoc( )
¹®¼-°ü¸® ¿£Áø.EXE

4: create ( ) gFile : GrpFile

Diagram
Alpha
UNIX
8: fillFile ( ) ÀÀ¿ë¼-¹ö.EXE

Windows
NT

user : »ç¿ëÀÚ GraphicFile IBM

fileMgr : FileMgr Mainframe

3: create ( )
File FileList
6: fillDocument ( )
µ¥ÀÌŸº£À̽º¼-¹ö

7: readFile ( )

5: readDoc ( )
document : Document
repository : Repository

Component Forward Engineering (Code Generation)

Collaboration Diagram Diagram and
Reverse Engineering
mainWnd fileMgr : document : gFile repository
user FileMgr Document

Source Code edit, compile, debug, link

ƯÁ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( )
»ç¿ëÀÚ°¡¿äûÇÑ´Ù.

2: fetchDoc()

3: create ( )

4: create ( )

5: readDoc ( )

È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument ( )

¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼-
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ́Ù.

7: readFile ( )

8: fillFile ( )

È-¸é °´Ã¼´Â ÀоîµéÀÎ 9: sort ByName ( )

°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡
º¸¿©ÁØ´Ù.

Sequence Diagram

Executable System
 Problems Addressed by Visual Modeling
Root Causes
 Insufficient requirements
 Ambiguous
communications
 Brittle architectures
 Overwhelming complexity
 Subjective assessment
 Undetected
inconsistencies
 Poor testing
 Waterfall development
 Uncontrolled change
 Insufficient automation
Solutions
Use cases and scenarios
unambiguously specify behavior
Models capture software designs
unambiguously
Non-modular or inflexible
architectures are exposed
Unnecessary detail hidden when
appropriate
Unambiguous designs reveal
inconsistencies more readily
Application quality starts with
good design
Visual modeling tools provide
support for UML modeling
Practice 5: Verify Software Quality

Develop Iteratively

Use
Manage Model
Component Visually Verify
Requirements Architectures Quality

Control Changes
 Practice 5: Verify Software Quality

Software problems are 100 to 1000

times more
costly to find and repair after
deployment

Cost

Development Deployment
 Iterative Development Permits
Continuous Testing
Iteration 1 Iteration 2 Iteration 3
R R R
D D D
C C C
T T T

Test Test Test

T I M E
 Testing in an Iterative Environment
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Requirements
Automated Tests

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

 Automation Reduces Testing Time and Effort
One Manual Test Cycle
13,000 Tests 2 Weeks 6 People

Test
Automation
13,000 Tests
6 hours Run More Tests More Often
1 Person
 Dimensions of Software Quality
Type Why? How?
Reliability Does my app leak memory? Analysis tools and code
instrumentation

Functionality Does my app do what’s Test cases for each

required? scenario implemented

Application Does my app respond Check performance for

Performance acceptably? each use case/scenario
implemented

System Does my system perform Test performance of all use

Performance under production load? cases under authentic and
worst-case load
 Problems Addressed by Verifying Quality
Root Causes
 Insufficient requirements
 Ambiguous communications
 Brittle architectures
 Overwhelming complexity
 Subjective assessment
 Undetected
inconsistencies
 Poor testing
 Waterfall development
 Uncontrolled change
 Insufficient automation
Solutio
Testing provides objective
ns
project status assessment
Objective assessment exposes
inconsistencies early
Testing and verification are
focused on high risk areas
Defects are found earlier and are
less expensive to fix
Automated testing tools provide
testing for reliability,
functionality, and performance
Practice 6: Control Changes to
Software
Develop Iteratively

Use
Manage Model Verify
Component Visually
Requirements Quality
Architectures

Control Changes
Practice 6: Control Changes to Software
• Multiple developers
• Multiple teams
• Multiple sites
• Multiple iterations
• Multiple releases
• Multiple projects
• Multiple platforms

Without explicit control,

parallel development degrades to
chaos
Three Major Aspects of a CM
System
 Concepts of Configuration & Change
Management
• Decompose the architecture into subsystems and assign
responsibility for each subsystem to a team
• Establish secure workspaces for each developer
– Provide isolation from changes made in other
workspaces
– Control all software artifacts - models, code, docs,
etc.
• Establish an integration workspace
• Establish an enforceable change control mechanism
• Know which changes appear in which releases
• Release a tested baseline at the completion of each
iteration
 Change Control Supports All Other Best
Practices
• Develop iteratively  Progress is incremental only if changes to
artifacts are controlled
 To avoid scope creep, identify, assess and
• Manage
approve all changes
requirements
 Components must be reliable, i.e., the
• Use component correct versions of all constituent parts
architectures found
 To assure convergence, incrementally
• Model visually
control models as designs stabilize
• Verify quality  Tests are only meaningful if the versions of
the items under test are known and the
items protected from changes
 Problems Addressed by Controlling Changes
Root
Causes
 Insufficient requirements
 Ambiguous
communications
 Brittle architectures
 Overwhelming complexity
 Subjective assessment
 Undetected
inconsistencies
 Poor testing
 Waterfall development
 Uncontrolled change
 Insufficient automation
Soluti
ons
Requirements change workflow
is defined and repeatable
Change requests facilitate clear
communications
Isolated workspaces reduce
interference from parallel work
Change rate statistics are good
metrics for objectively assessing
project status
Workspaces contain all artifacts,
facilitating consistency
Change propagation is
controlled
Changes maintained in a robust,
customizable system
 Best Practices Reinforce Each Other
Ensures users involved Manage
as requirements evolve Requirements

Validates architectural Use

Component
decisions early on
Architectures

Develop Addresses complexity of Model

Iteratively Visually
design/implementation incrementally

Measures quality early and often Verify

Quality

Evolves baselines incrementally Control

Changes
 Summary: Best Practices of Software
Engineering
• The result is software that is
– On Time Performance
Engineer
– On Budget
– Meets Users Needs Analyst

Project
Manager
Develop Iteratively
Developer

Use Model
Manage Component Visually Verify
Quality
Tester
Requirements Architectures

Control Release
Changes
Engineer