Best Practices of

Software Engineering
santo@cs.ui.ac.id
Petrus Mursanto
Objectives:
Explore the symptoms and root causes of software
development problems
Explain Rationals six best practices for software
development
Look at how Rationals best practices address the
root causes of software development problems
Software Development Situation Analysis
World economies
increasingly software
dependent
Business demands
increased productivity &
quality in less time
Not enough qualified people
Applications expanding in
size, complexity &
distribution, importance
Software Development is a Job for Teams
Challenges
Larger teams
Specialization
Distribution
Rapid Technology change
Analyst
Tester
Developer
Release
Engineer
Performance
Engineer
Project
Manager
IT Projects
32%
68%
Cancelled
Completed
Chaos Report by Standish Group 1997
IT Projects
32%
51%
17%
Cancelled
Over-budget
On-budget
Chaos Report by Standish Group 1997
How Are We Doing?
Analyst
Tester
Developer
Release
Engineer
Performance
Engineer
Project
Manager
Many Successes
Too Many Failures
Symptoms of Software Development Problems
Inaccurate understanding of end-user needs
Inability to deal with changing requirements
Modules that dont fit together
Software thats hard to maintain or extend
Late discovery of serious project flaws
Poor software quality
Unacceptable software performance
Team members in each others way, unable to reconstruct, who
changed what, when, where, why
An untrustworthy build-and-release process
Treating Symptoms Does Not Solve the Problem
Symptoms
end-user needs
changing requirements
modules dont fit
hard to maintain
late discovery
poor quality
poor performance
colliding developers
build-and-release
Root Causes
insufficient requirements
ambiguous communications
brittle architectures
overwhelming complexity
undetected inconsistencies
poor testing
subjective assessment
waterfall development
uncontrolled change
Insufficient automation
Diagnose
Best Practices Address Root Causes
Best Practices
Develop iteratively
Manage requirements
Use component architectures
Model the software visually
Verity quality
Control changes
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Undetected inconsistencies
Poor testing
Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation

Addressing Root Causes Eliminates the Symptoms

Symptoms
end-user needs
changing requirements
modules dont fit
hard to maintain
late discovery
poor quality
poor performance
colliding developers
build-and-release
Root Causes
insufficient requirements
ambiguous
communications
brittle architectures
overwhelming complexity
undetected inconsistencies
poor testing
subjective assessment
waterfall development
uncontrolled change
Insufficient automation
Best Practices
develop iteratively
manage requirements
use component
architectures
model the software
visually
verity quality
control changes
Best Practices of Software Engineering
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Control Changes
Best Practices Enable High-Performance Teams
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Control Changes
Results
More Successful
projects
Analyst
Tester
Developer
Release
Engineer
Performance
Engineer
Project
Manager
Practice 1: Develop Software Iteratively
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Control Changes
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
Practice 1: Develop Software Iteratively
$$$
The time and money spent implementing
a faulty design are not recoverable
Iterative Development
Accommodate changing requirements
Progressively integrate elements into end-product.
Mitigate risks earlier
Development process itself can be improved and refined
along the way
Early feedback from end-users
Facilitates reuse
Results in a very robust architecture
Mitigate risks earlier
Design
Reqm
Analysis
Implemt
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Waterfall Model
Iterative Model
Apply the Waterfall Iteratively to System Increments
R
D
C
T
R
D
C
T
R
D
C
T
Iteration 1 Iteration 2 Iteration 3
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
Traditional Waterfall Development
Iteration Iteration Iteration Iteration Iteration Iteration Iteration
Iterative Development
Each iteration
results in an
executable release.
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
Problem Addressed by Iterative Development
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
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation

Practice 2: Manage Requirements

Develop Iteratively
Use
Component
Architectures
Model
Visually
Verify
Quality
Control Changes
Manage
Requirements
25
Requirements Management
Means
Making sure you
solve the right problem
build the right system
by taking a systematic approach to
eliciting
organizing
documenting
managing
establishing and maintaining agreement on
the changing requirements of a software application.
Agreement on What the System Should Do
Use Case Model Requirements
Customer
User Community
Requirements
Verification
Surrogate
Goal
System to
be built
The Goal
Misunderstanding requirements
Misunderstanding requirements
Requirements Trace to Many Project Elements
How to Catch Requirements Error Early
Effectively analyze the problem and elicit 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 Requirement Management
Solutions
A 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
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation

Practice 3: Use Component-Base Architectures

Develop Iteratively
Manage
Requirements
Model
Visually
Verify
Quality
Control Changes
Use
Component
Architectures
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
J2EE
Architecture
Browser
Application Server
servlet DB
request response
Enterprise Server
Browser
Application Server
jsp
DB
request response
JavaBean
Enterprise Server
request
Browser
Application Server
servlet
DB
response
JavaBean
Enterprise Server
Browser
Application Server
servlet
DB
request response
jsp
JavaBean
Architectural Decision
Application Server
servlet DB
request response
Browser
Http browser
Java
MS Access
TARGET ELABORASI:
Menguji arsitektur sistem yang disebut sebagai arsitektur basis
Risk List:
belum pernah implemen J2EE
architecture
konon produk Microsoft tdk
compatible dgn Sun
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
Problems Addressed by Component Architectures
Solutions
Components facilitate resilient
architectures
Reuse of commercially available
components and frameworks is
facilitated
Modularity enables separation of
concerns
Components provide a natural
basis for configuration
management
Visual modeling tools provide
automation for component-
based design
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation

Practice 4: Visually Model Software

Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Verify
Quality
Control Changes
Model
Visually
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
Representing Architecture: The 4+1 View Model
Logical
View
Use-Case
View
Implementation
View
Deployment View
Process
View
Analyst/Designers
Structure
Programmers
Software Managmt
System Integrators
Performance
Scalability
System Engineers
System topology
Delivery, Installation
communication
End-User
Functionality
UML History
UML 1.1
Sept 97
UML 1.0
Jan 97
UML 0.9
Jun 96
Oct 95
Unified Method 0.8
Use Case
Dr.Ivar Jacobson
joins Rational
(Fall of 1995)
OMT Booch
Dr.James Rumbaugh
joins Rational
(Oct 1994)
Microsoft,
Oracle, IBM,
HP & other
industry leaders
Inputs to UML
Booch
Jacobson
Rumbaugh
Meyer
Pre and post
conditions
Harel
State Charts
Gamma, et.al.
Framework, patterns,
notes
Shlaer-Mellor
Object Lifecycles
Odell
Classification
Wirfs-Brock
Responsibilities
Embley
Singleton classes,
High-level view
Fusion
Operation descriptions,
Message numbering
The UML Provides Standardized Diagrams
Class
Diagrams
Use-case
Diagrams
Activity
Diagrams
Sequence
Diagrams
Collaboration
Diagrams
Object
Diagrams
State
Diagrams
Deployment
Diagrams
Component
Diagrams
Model
Visual Modeling Using UML Diagrams
Class Diagram
Set count = 0
[ count = 10 ]
Cancel
Cancel
Cancel
State Diagram
:
Sequence Diagram
Deployment
Diagram
Customer
Check Balance
Withdraw Money
Use-Case Diagram
Domain
Expert
User Interface
Definition
Collaboration
Diagram
Student
Name
ID
Address
Identify()
Enroll()
Print()
Class
Package
Diagram
University Package
Enrollment Package
Administration Package
Enrollment Package
Component Diagram
executable
system
Source Code edit,
compile, debug, link
Forward & Reverse
Engineering
Problems Addressed by Visual Modeling
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 rapidly
Application quality starts with good
design
Visual modeling tools provide support
for UML modeling
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation

Practice 5: Verify Software Quality

Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Control Changes
Verify
Quality
Practice 5: Verify Software Quality
Software problems are 100 to 1000 times more
costly to find and repair after development
Cost
Development
Deployment
Relative Cost to Repair
Requirements
Design
Coding
Unit test
Acceptance test
Maintenance
Stage
.1 - .2
.5
1
2
5
20
Iterative Development Permits Continuous Testing
R
D
C
T
R
D
C
T
R
D
C
T
Iteration 1 Iteration 2 Iteration 3
Test Test Test
Plan
Design
Implement
Execute
Evaluate
TIME
Plan
Design
Implement
Execute
Evaluate
Plan
Design
Implement
Execute
Evaluate
Test
Life
Cycle
Testing in an Iterative Environment
Iteration 1 Iteration 2 Iteration 3 Iteration 4
R
e
q
u
i
r
e
m
e
n
t
s
Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4
A
u
t
o
m
a
t
e
d

T
e
s
t
s
Type Why? How?
Dimensions of Software Quality
Functionality
Reliability
Application
Performance
System
Performance
Does my app do whats
required?
Does my app leak memory?
Does my app respond
acceptably?
Does my system perform
under production load?
Test cases for each scenario
implemented
Analysis tools and code
instrumentation
Check performance for each
use-case/scenario
implemented
Test performance of all use-
cases under authentic and
worst-case load
Problems Addressed by Verifying Quality
Solutions
Testing provides objective 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
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation

Practice 6: Control Changes to Software

Control Changes
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Develop Iteratively
Multiple developers
Multiple teams
Multiple sites
Multiple iterations
Multiple releases
Multiple projects
Multiple platforms
Practice 6: Control Changes to Software
Without explicit control,
parallel development degrades to chaos
Change Control Board
PRD
SRS
Code
Test
CR
New
Feature
New
Requirement
Bug
Change
Reqest (CR)
Customer and
End-User Inputs
Marketing
Coders inputs
Testers inputs
Help Desk
End-User Inputs
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
Progress is incremental only if changes to
artifacts are controlled
To avoid scope creep, assess the impact of all
proposed changes before approval
Components must be reliable, i.e., the correct
versions of all constituent parts found
To assure convergence, incrementally control
models as designs stabilize
Tests are only meaningful if the versions of the
items under test are known and the items
protected from changes
Develop iteratively
Manage requirements
Use component
architectures
Model visually
Verify quality
Problems Addressed by Controlling Changes
Solutions
Requirements change workflow is
defined and repeatable
Change requests facilitate clear
communication
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
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation

Best Practices Reinforces Each Other

Use Component
Architectures
Manage
Requirements
Model Visually
Verify Quality
Control Changes
Develop Iteratively
Ensures users involved
as requirements evolve
Validates architectural
Addresses complexity of
Measures quality early and often
Evolves baselines incrementally
decisions early on
design/implementation incrementally
Analyst
Tester
Developer
Release
Engineer
Performance
Engineer
Project
Manager
Summary: Best Practices of Software Engineering
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Control Changes
The result is software that is
On Time
On Budget
Meets Users Needs
The six best practices are designed to enable
high-performance teams to be successful
on their software projects.
Team-Based
Development
Modeling
Language
Unified
Process