Best Practices of

Software Engineering

Petrus Mursanto
[email protected]

Obj i
Objectives:
 Explore the symptoms and root causes of software
development problems

 Explain Rational’s
Rational s six best practices for software
development

 Look at how Rational’s best practices address the

root causes of software development
p p
problems
 Software Development Situation Analysis

World economies Applications expanding in

i
increasingly
i l software
ft size,
i complexity
l it &
dependent distribution, importance

Business demands
increased productivity &
quality in less time Not enough qualified people

Software Development is a Job for Teams

Challenges

Performance
 Larger teams Engineer

Analyst
 Specialization
Project
Manager
 Distribution
Developer
Tester
 Rapid Technology change

Release
Engineer
IT Projects Chaos Report by Standish Group 1997

32%

Cancelled
Completed

68%

IT Projects Chaos Report by Standish Group 1997

17%
32%
Cancelled
Over-budget
On-budget

51%
How Are We Doing?

Performance
Engineer

• Many Successes Analyst

• Too
T Many
M Failures
F il 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
what, when
when, where
where, why
 An untrustworthy build-and-release process
Treating Symptoms Does Not Solve the Problem
Symptoms Root Causes

end-user needs insufficient requirements

changing requirements ambiguous communications
b ittl architectures
brittle hit t
modules don’t fit
overwhelming complexity
hard to maintain
undetected inconsistencies
late discovery
poor testing
poor quality subjective assessment
poor performance waterfall
f ll development
d l
colliding developers uncontrolled change
build-and-release
build and release Diagnose Insufficient automation

Best Practices Address Root Causes

Root Causes Best Practices

 Insufficient requirements  Develop iteratively

 Ambiguous communications  Manage requirements
 B ittl architectures
Brittle hit t  U componentt architectures
Use hit t
 Overwhelming complexity  Model the software visually
 Undetected inconsistencies  Verity
yqquality
y
 Poor testing  Control changes
 Subjective assessment
 W
Waterfall
f ll development
d l
 Uncontrolled change
 Insufficient automation
Addressing Root Causes Eliminates the Symptoms
Symptoms Root Causes Best Practices

end-user
d needs
d insufficient requirements develop iteratively
changing requirements ambiguous manage requirements
modules don’t fit communications use component
hard to maintain brittle architectures architectures
late discovery overwhelming complexity model the software
poor quality undetected inconsistencies visually
poor p
p performance poor testing verity quality
colliding developers control changes
subjective assessment
build-and-release
waterfall development
uncontrolled change
Insufficient automation

Best Practices of Software Engineering

Develop Iteratively

Use
U
Manage Model Verify
Component
Requirements Visually Quality
Architectures

Control Changes
 Best Practices Enable High-Performance Teams

Results Performance
Engineer
• More Successful
projects Analyst

Project
Manager
Develop Iteratively
Developer
Use
Tester
Manage Model Verify
Component
Requirements Visually Quality
Architectures

Control Changes
g Release
Engineer

Practice 1: Develop Software Iteratively

Develop Iteratively

Use
U
Manage Model Verify
Component
Requirements Visually Quality
Architectures

Control Changes
Practice 1: Develop Software Iteratively

 An initial design will likely be flawed with respect to its key requirements
 Late-phase
p discovery y of design
g defects results in costlyy over-runs and/or
project cancellation

$$$

The time and money spent implementing

a faulty design are not recoverable

Iterative Development

 Accommodate changing requirements

 Progressively integrate elements into end
end-product.
product
 Mitigate risks earlier
 Development process itself can be improved and refined
along the way
 Early feedback from endend-users
users
 Facilitates reuse
 R
Results
lt iin a very robust
b t architecture
hit t
Mitigate risks earlier
Waterfall Model
Reqm
Analysis Design
g
I l t
Implemt

Iterative Model

Iteration 1 Iteration 2 Iteration 3 Iteration 4

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

TIME

• Earliest iterations address greatest risks

• Each iteration produces an executable release,
release an additional
increment of the system
g
• 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
Root Causes Solutions

 Insufficient requirements Enables and encourages user

feedback
 Ambiguous communications
Brittle
B ittl architectures
hit t Serious misunderstandings
evident early in the life cycle
 Overwhelming complexity
Development focuses on critical
 j
Subjective assessment issues
 Undetected inconsistencies Objective assessment thru testing
 Poor testing Inconsistencies detected early y
 W
Waterfall
f ll development
d l Testing starts earlier
Uncontrolled change Risks identified and addressed
Insufficient automation early

Practice 2: Manage Requirements

Develop Iteratively

Use
Model Verify
Manage Component
Visually Quality
Requirements Architectures

Control Changes
Requirements Management
Means…
Making sure you
 solve the right problem
 build the right system
by taking a systematic approach to
 eliciting
 organizing
 documenting
 managing
 establishingg and maintaining
g agreement
g on
the changing requirements of a software application.

25

Agreement on What the System Should Do

The Goal

System to
be built
Customer
User Community

q
Requirements Surrogate
g
Verification Goal

Use Case Model Requirements

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
Root Causes Solutions

 Insufficient requirements A disciplined approach is built into

requirements management
 Ambiguous communications Communications are based on defined
Brittle
B ittl architectures
hit t requirements
 Overwhelming complexity Requirements can be prioritized, filtered,
 j
Subjective assessment and traced
Objective assessment of functionality
 Undetected inconsistencies
and performance
 Poor testing Inconsistencies are more easily detected
W
Waterfall
f ll development
d l RM tool provides a repository for
Uncontrolled change requirements, attributes and tracing,
with automatic links to documents
 Insufficient automation

Practice 3: Use Component-Base Architectures

Develop Iteratively

Manage Use Model Verify

Requirements Component Visually 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
 A hit t l style
Architectural t l th
thatt guides
id thi
this organization,
i ti th
these elements
l t and
d
their interfaces, their collaborations, and their composition

J2EE Browser

A hit t
Architecture request response

jsp JavaBean Browser

Browser request response

Application Server
request response
servlet jsp

servlet JavaBean DB
JavaBean
Enterprise Server
Application Server
Application Server

Browser
DB
DB
request response
Enterprise Server
Enterprise Server

servlet DB

Application Server
Architectural Decision
Http browser
Browser
request response MS Access

Risk List:
servlet DB • belum pernah implemen J2EE
architecture
Application Server • konon produk Microsoft tdk
compatible
p dgn
g Sun
Java

TARGET ELABORASI:
• Menguji arsitektur sistem yang disebut sebagai arsitektur basis

Resilient, Component-Based Architectures

 Good architectures meet their requirements, are resilient, and are
component-based
 A resilient architecture enables
 Improved maintainability and extensibility
 E
Economically-significant
i ll i ifi t reuse
 Clean division of work among teams of developers
 Encapsulation
capsu a o o of hardware
ad aea andd sys
system
e depe
dependencies
de c es
 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
Root Causes Solutions

Insufficient requirements Components facilitate resilient

Ambiguous communications architectures
 B ittl architectures
Brittle hit t Reuse of commercially available
components and frameworks is
 Overwhelming complexity facilitated
j
Subjective assessment Modularity enables separation of
Undetected inconsistencies concerns
Poor testing Components provide a natural
W
Waterfall
f ll development
d l b i for
basis f configuration
fi ti
management
 Uncontrolled change
 Insufficient automation Visual modeling tools provide
automation for component-
based design

Practice 4: Visually Model Software

Develop Iteratively

Use
U
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
y fit together
g
 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

Implementation
Logical
View
View
A l t/D i
Analyst/Designers P
Programmers
Structure Software Managmt
End-User
Functionality
y
Use-Case
View
Process
View
Vi Deployment
D l View
Vi System
S Engineers
i
System Integrators System topology
Performance Delivery, Installation
Scalability communication

UML History
Sept ‘97 UML 1.1

Jan ‘97 UML 1.0

Jun ‘96 UML 0.9 Microsoft,

Mi f
Oracle, IBM,
O t ‘95
Oct Unified Method 0
0.8
8 HP & other
industry leaders
Dr.Ivar Jacobson
joins Rational Use Case
(Fall of 1995)

Dr.James Rumbaugh
j i Rational
joins R ti l
OMT Booch
(Oct 1994)
Inputs to UML
Booch
Rumbaugh Jacobson
Fusion
Meyer Operation descriptions,
Pre and post g numbering
Message g
conditions
Embley
Harel
Singleton classes,
State Charts
High-level view
Gamma, et.al.
Framework,, patterns,
p , Wirfs-Brock
notes Responsibilities
Shlaer-Mellor Odell
j
Object Lifecycles
y Classification

The UML Provides Standardized Diagrams

Use-case Class
Diagrams Diagrams

Activity
Diagrams
Object
Diagrams

Sequence
Diagrams
Model
State
Diagrams
g

Collaboration
Diagrams
Deployment Component
Diagrams Diagrams
 Visual Modeling Using UML Diagrams
State Diagram
Use-Case Diagram Set count = 0
Class Diagram
Cancel Cancel
[ count = 10 ]

Domain
D i Check Balance Cancel

Expert
Customer

Withdraw Money Student

Name
ID
Address Deployment
Package Identify()
Enroll() Diagram
University Package

Diagram Print()

User Interface Collaboration Class

Definition Diagram
Enrollment Package

Enrollment Package
Forward & Reverse
Engineering
Administration Package

S
Source Code
C d edit,
dit
: compile, debug, link
Component Diagram
executable
e ecutab e
system
Sequence Diagram

Problems Addressed by Visual Modeling

Root Causes Solutions

 Insufficient requirements use-cases and scenarios

unambiguously specify behavior
 Ambiguous communications
Models capture
p software designsg
 B ittl architectures
Brittle hit t unambiguously
 Overwhelming complexity Non-modular or inflexible
j
Subjective assessment architectures are exposed
Unnecessary detail hidden when
 Undetected inconsistencies
appropriate
 Poor testing Unambiguous designs reveal
W
Waterfall
f ll development
d l inconsistencies more rapidly
Uncontrolled change Application quality starts with good
design
 Insufficient automation
Visual modeling tools provide support
for UML modeling
 Practice 5: Verify Software Quality

Develop Iteratively

Use
U
Manage Model
Component Verify
Requirements Visually
Architectures Quality

Control Changes

Practice 5: Verify Software Quality

Software problems are 100 to 1000 times more
costly to find and repair after development

Cost

D
Development
l t
Deployment
 R l i C
Relative Cost to R
Repair
i
Stage
1 - .2
.1 2 Requirements

.5 Design

1 Coding
2 Unit test

5 Acceptance test
20 Maintenance

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
TIME

Plan Plan Plan

Test Design Design Design
Life
Lif Implement Implement Implement
Execute Execute Execute
Cycle
Evaluate Evaluate Evaluate
 Testing in an Iterative Environment
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Reqquiremeents
Auutomateed Testss

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

Dimensions of Software Quality

Type Why? How?

Functionality Does my app do what’s Test cases for each scenario
required? implemented
Reliability Does my app leak memory? Analysis tools and code
instrumentation
Application Does my app respond Check performance for each
Performance acceptably? use-case/scenario
p
implemented
System Does my system perform Test performance of all use-
Performance under production load? cases under authentic and
worst-case load
l d
Problems Addressed by Verifying Quality
Root Causes Solutions

Insufficient requirements Testing provides objective project

Ambiguous communications status assessment
B ittl architectures
Brittle hit t Objective assessment exposes
inconsistencies early
Overwhelming complexity
Testing and verification are
 j
Subjective assessment focused on high risk areas
 Undetected inconsistencies Defects are found earlier and are
 Poor testing less expensive to fix
W
Waterfall
f ll development
d l
Uncontrolled change Automated testing tools provide
 Insufficient automation g for reliability,
testing y,
functionality and performance

Practice 6: Control Changes to Software

Develop Iteratively

Use
U
Manage Model Verify
Component
Requirements Visually Quality
Architectures

Control Changes
Practice 6: Control Changes to Software

 Multiple developers
 Multiple
p teams
 Multiple sites
 Multiple iterations
 Multiple releases
 Multiple projects
 Multiple platforms

Without explicit control,

parallel development
p p degrades
g to chaos

Change Control Board

Customer
C t andd
End-User Inputs
New
Feature PRD Marketing
New
Requirement SRS
Coders inputs
Testers inputs
Bug Code

Change Test
Reqest (CR)
Help Desk
CR 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
 C t l allll software
Control ft artifacts
tif t - models,
d l code,
d d docs, etc.
t
 Establish an integration workspace
 Establish an enforceable change control mechanism
 Know which changes appear in which releases
 Release a tested baseline at the completion
p of each iteration

Change Control Supports All Other Best Practices

 Develop iteratively Progress is incremental only if changes to
artifacts are controlled

 Manage requirements To avoid scope creep, assess the impact of all

proposed changes before approval

 Use component Components must be reliable, i.e., the correct

architectures versions of all constituent parts found

To assure convergence, incrementally control

 Model visually models as designs stabilize

Tests are only meaningful if the versions of the

 Verify quality items under test are known and the items
protected from changes
Problems Addressed by Controlling Changes
Root Causes Solutions

 Insufficient requirements Requirements change workflow is

defined and repeatable
 Ambiguous communications Change requests facilitate clear
Brittle
B ittl architectures
hit t communication
i ti
 Overwhelming complexity Isolated workspaces reduce
interference from parallel work
 j
Subjective assessment
Change rate statistics are good
 Undetected inconsistencies metrics for objectively assessing
Poor testing project status
W
Waterfall
f ll development
d l W k
Workspaces contain
t i all
ll artifacts,
tif t
facilitating consistency
 Uncontrolled change
Change propagation is controlled
 Insufficient automation
Ch
Changes maintained
i t i d in
i a robust,
b t
customizable system

Best Practices Reinforces Each Other

Ensures users involved Manage

as requirements evolve Requirements
R i t

Validates architectural Use Component

decisions early on A hit t
Architectures

Addresses complexity of
Develop Iteratively Model Visually
design/implementation incrementally
Measures quality early and often
Verify Quality

Evolves baselines incrementally

Control Changes
S
Summary: Best
B t Practices
P ti off Software
S ft Engineering
E i i

The result is software that is Performance

• On Time Engineer

• On Budget Analyst
• Meets Users Needs
Project
Manager
Develop Iteratively
Developer
Use
Tester
Manage Model Verify
Component
Requirements Visually Quality
Architectures

Control Changes
g Release
Engineer

The six best practices are designed to enable

high-performance teams to be successful
on their software projects.

Team-Based
Development

Modeling Unified
Language Process