01a _bestpractices
TRANSCRIPT
-
8/10/2019 01a _BestPractices
1/62
Best Practices of
Software Engineering
Petrus Mursanto
-
8/10/2019 01a _BestPractices
2/62
Objectives:
Explore the symptoms and root causes of softwaredevelopment problems
Explain Rationals six best practices for softwaredevelopment
Look at how Rationals best practices address theroot causes of software development problems
-
8/10/2019 01a _BestPractices
3/62
Software Development Situation Analysis
World economies
increasingly softwaredependent
Business demands
increased productivity &
quality in less time Not enough qualified people
Applications expanding in
size, complexity &distribution, importance
-
8/10/2019 01a _BestPractices
4/62
Software Development is a Job for Teams
Challenges
Larger teams
Specialization
Distribution
Rapid Technology change
Analyst
Tester
Developer
ReleaseEngineer
PerformanceEngineer
ProjectManager
-
8/10/2019 01a _BestPractices
5/62
IT Projects
32%
68%
Cancelled
Completed
Chaos Report by Standish Group 1997
-
8/10/2019 01a _BestPractices
6/62
IT Projects
32%
51%
17%
Cancelled
Over-budget
On-budget
Chaos Report by Standish Group 1997
-
8/10/2019 01a _BestPractices
7/62
How Are We Doing?
Analyst
Tester
Developer
ReleaseEngineer
PerformanceEngineer
ProjectManager
Many Successes Too Many Failures
-
8/10/2019 01a _BestPractices
8/62
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
-
8/10/2019 01a _BestPractices
9/62
Treating Symptoms Does Not Solve the Problem
Symptoms
end-user needs
changing requirements
modules dont fit
hard to maintain
late discovery
poor quality
poor performancecolliding developers
build-and-release
Root Causes
insufficient requirements
ambiguous communications
brittle architecturesoverwhelming complexity
undetected inconsistencies
poor testing
subjective assessment
waterfall developmentuncontrolled change
Insufficient automationDiagnose
-
8/10/2019 01a _BestPractices
10/62
Best Practices Address Root Causes
Best Practices
Develop iteratively
Manage requirements
Use component architecturesModel the software visually
Verity quality
Control changes
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architecturesOverwhelming complexity
Undetected inconsistencies
Poor testing
Subjective assessment
Waterfall developmentUncontrolled change
Insufficient automation
-
8/10/2019 01a _BestPractices
11/62
Addressing Root Causes Eliminates the Symptoms
Symptoms
end-user needs
changing requirements
modules dont fit
hard to maintainlate discovery
poor quality
poor performance
colliding developers
build-and-release
Root Causes
insufficient requirements
ambiguouscommunications
brittle architecturesoverwhelming complexity
undetected inconsistencies
poor testing
subjective assessment
waterfall development
uncontrolled change
Insufficient automation
Best Practices
develop iteratively
manage requirements
use component
architecturesmodel the software
visually
verity quality
control changes
-
8/10/2019 01a _BestPractices
12/62
Best Practices of Software Engineering
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
VerifyQuality
Control Changes
-
8/10/2019 01a _BestPractices
13/62
Best Practices Enable High-Performance Teams
Develop Iteratively
Manage
Requirements
Use
ComponentArchitectures
Model
Visually
Verify
Quality
Control Changes
Results
More Successful
projectsAnalyst
Tester
Developer
ReleaseEngineer
PerformanceEngineer
ProjectManager
-
8/10/2019 01a _BestPractices
14/62
Practice 1: Develop Software Iteratively
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
VerifyQuality
Control Changes
-
8/10/2019 01a _BestPractices
15/62
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 implementinga faulty design are not recoverable
-
8/10/2019 01a _BestPractices
16/62
Iterative Development
Accommodate changing requirements
Progressively integrate elements into end-product.
Mitigate risks earlier
Development process itself can be improved and refinedalong the way
Early feedback from end-users
Facilitates reuse
Results in a very robust architecture
-
8/10/2019 01a _BestPractices
17/62
Mitigate risks earlier
Design
ReqmAnalysis
Implemt
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Waterfall Model
Iterative Model
-
8/10/2019 01a _BestPractices
18/62
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 additionalincrement of the system
Each iteration includes integration and test
-
8/10/2019 01a _BestPractices
19/62
Traditional Waterfall Development
Iteration Iteration Iteration Iteration Iteration Iteration Iteration
-
8/10/2019 01a _BestPractices
20/62
-
8/10/2019 01a _BestPractices
21/62
Iterative Development Characteristics
Critical risks are resolved before making largeinvestments
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
-
8/10/2019 01a _BestPractices
22/62
Apply Best Practices Throughout the Life Cycle
-
8/10/2019 01a _BestPractices
23/62
Problem Addressed by Iterative Development
Solutions
Enables and encourages userfeedback
Serious misunderstandingsevident early in the life cycle
Development focuses on criticalissues
Objective assessment thru testing
Inconsistencies detected early
Testing starts earlierRisks identified and addressed
early
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architecturesOverwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall developmentUncontrolled change
Insufficient automation
-
8/10/2019 01a _BestPractices
24/62
Practice 2: Manage Requirements
Develop Iteratively
UseComponent
Architectures
ModelVisually
VerifyQuality
Control Changes
ManageRequirements
R i t M t
-
8/10/2019 01a _BestPractices
25/62
25
Requirements ManagementMeans
Making sure you solve the right problem build the right system
by taking a systematic approach to
eliciting organizing documentingmanagingestablishing and maintaining agreement on
the changing requirements of a software application.
-
8/10/2019 01a _BestPractices
26/62
Agreement on What the System Should Do
Use Case Model Requirements
Customer
User Community
Requirements
Verification
Surrogate
Goal
System tobe built
The Goal
Misunderstanding requirements
-
8/10/2019 01a _BestPractices
27/62
Misunderstanding requirements
Misunderstanding requirements
-
8/10/2019 01a _BestPractices
28/62
Misunderstanding requirements
-
8/10/2019 01a _BestPractices
29/62
Requirements Trace to Many Project Elements
-
8/10/2019 01a _BestPractices
30/62
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
-
8/10/2019 01a _BestPractices
31/62
Problems Addressed by Requirement Management
Solutions
A disciplined approach is built intorequirements management
Communications are based on defined
requirementsRequirements can be prioritized, filtered,
and traced
Objective assessment of functionalityand performance
Inconsistencies are more easily detected
RM tool provides a repository forrequirements, attributes and tracing,with automatic links to documents
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architecturesOverwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall developmentUncontrolled change
Insufficient automation
-
8/10/2019 01a _BestPractices
32/62
Practice 3: Use Component-Base Architectures
Develop Iteratively
ManageRequirements
ModelVisually
VerifyQuality
Control Changes
UseComponent
Architectures
-
8/10/2019 01a _BestPractices
33/62
Software Architecture Defined
Software architecture encompasses significant decisions about theorganization of a software system
Selection of the structural elements and their interfaces by which asystem is composed
Behavior as specified in collaborations among those elements
Composition of these structural and behavioral elements intoprogressively larger subsystems
Architectural style that guides this organization, these elements andtheir interfaces, their collaborations, and their composition
J2EE Browser
-
8/10/2019 01a _BestPractices
34/62
J2EEArchitecture
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
-
8/10/2019 01a _BestPractices
35/62
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
-
8/10/2019 01a _BestPractices
36/62
Resilient, Component-Based Architectures
Good architectures meet their requirements, are resilient, and arecomponent-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
-
8/10/2019 01a _BestPractices
37/62
Problems Addressed by Component Architectures
Solutions
Components facilitate resilientarchitectures
Reuse of commercially available
components and frameworks isfacilitated
Modularity enables separation ofconcerns
Components provide a naturalbasis for configurationmanagement
Visual modeling tools provideautomation for component-based design
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall developmentUncontrolled change
Insufficient automation
-
8/10/2019 01a _BestPractices
38/62
Practice 4: Visually Model Software
Develop Iteratively
ManageRequirements
UseComponentArchitectures
VerifyQuality
Control Changes
ModelVisually
-
8/10/2019 01a _BestPractices
39/62
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 abi l i ty to
manage software complexi ty
-
8/10/2019 01a _BestPractices
40/62
What is the UML?
The Unified Modeling Language (UML) is a language for :
Specifying
Visualizing
Constructing
Documentingthe artifacts of a software-intensive system
-
8/10/2019 01a _BestPractices
41/62
Representing Architecture: The 4+1 View Model
Logical
View
Use-Case
View
Implementation
View
Deployment View
Process
View
Analyst/DesignersStructure
ProgrammersSoftware Managmt
System IntegratorsPerformance
Scalability
System EngineersSystem topology
Delivery, Installation
communication
End-UserFunctionality
-
8/10/2019 01a _BestPractices
42/62
UML History
UML 1.1Sept 97
UML 1.0Jan 97
UML 0.9Jun 96
Oct 95 Unified Method 0.8
Use CaseDr.Ivar Jacobson
joins Rational
(Fall of 1995)
OMT BoochDr.James Rumbaugh
joins Rational
(Oct 1994)
Microsoft,Oracle, IBM,
HP & other
industry leaders
-
8/10/2019 01a _BestPractices
43/62
Inputs to UML
Booch
JacobsonRumbaugh
MeyerPre and post
conditionsHarel
State Charts
Gamma, et.al.Framework, patterns,
notesShlaer-Mellor
Object Lifecycles
OdellClassification
Wirfs-BrockResponsibilities
EmbleySingleton classes,
High-level view
FusionOperation descriptions,
Message numbering
-
8/10/2019 01a _BestPractices
44/62
The UML Provides Standardized Diagrams
ClassDiagrams
Use-caseDiagrams
ActivityDiagrams
SequenceDiagrams
CollaborationDiagrams
Object
Diagrams
StateDiagrams
DeploymentDiagrams
ComponentDiagrams
Model
-
8/10/2019 01a _BestPractices
45/62
Visual Modeling Using UML Diagrams
Class DiagramSet count = 0
[ count = 10 ]
Cancel Cancel
Cancel
State Diagram
:
Sequence Diagram
Deployment
Diagram
Customer
Check Balance
Withdraw Money
Use-Case Diagram
DomainExpert
User InterfaceDefinition
Collaboration
Diagram
Student
Name
IDAddress
Identify()
Enroll()Print()
Class
PackageDiagramUniversityPackage
Enrollment Package
AdministrationPackage
Enrollment Package
Component Diagramexecutable
system
Source Code edit,
compile, debug, link
Forward & Reverse
Engineering
-
8/10/2019 01a _BestPractices
46/62
Problems Addressed by Visual Modeling
Solutions
use-cases and scenariosunambiguously specify behavior
Models capture software designs
unambiguouslyNon-modular or inflexible
architectures are exposed
Unnecessary detail hidden whenappropriate
Unambiguous designs revealinconsistencies more rapidly
Application quality starts with gooddesign
Visual modeling tools provide supportfor UML modeling
Root Causes
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation
-
8/10/2019 01a _BestPractices
47/62
Practice 5: Verify Software Quality
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
Control Changes
VerifyQuality
-
8/10/2019 01a _BestPractices
48/62
Practice 5: Verify Software Quality
Software pro blems are 100 to 1000 t imes more
cos t ly to f ind and repair af ter development
Cost
DevelopmentDeployment
-
8/10/2019 01a _BestPractices
49/62
Relative Cost to Repair
Requirements
Design
Coding
Unit test
Acceptance test
Maintenance
Stage
.1 - .2
.5
1
2
5
20
-
8/10/2019 01a _BestPractices
50/62
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
ExecuteEvaluate
TIME
Plan
Design
Implement
ExecuteEvaluate
Plan
Design
Implement
ExecuteEvaluate
Test
Life
Cycle
-
8/10/2019 01a _BestPractices
51/62
Testing in an Iterative Environment
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Requirements
Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4
Automa
tedTests
-
8/10/2019 01a _BestPractices
52/62
Type Why? How?
Dimensions of Software Quality
Functionality
Reliability
Application
Performance
SystemPerformance
Does my app do whats
required?
Does my app leak memory?
Does my app respond
acceptably?
Does my system performunder production load?
Test cases for each scenario
implemented
Analysis tools and codeinstrumentation
Check performance for each
use-case/scenario
implemented
Test performance of all use-cases under authentic and
worst-case load
-
8/10/2019 01a _BestPractices
53/62
Problems Addressed by Verifying Quality
Solutions
Testing provides objective projectstatus assessment
Objective assessment exposes
inconsistencies earlyTesting and verification are
focused on high risk areas
Defects are found earlier and areless expensive to fix
Automated testing tools providetesting 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
-
8/10/2019 01a _BestPractices
54/62
Practice 6: Control Changes to Software
Control Changes
ManageRequirements
UseComponent
ArchitecturesModel
VisuallyVerify
Quality
Develop Iteratively
-
8/10/2019 01a _BestPractices
55/62
Multiple developers
Multiple teams
Multiple sites
Multiple iterations
Multiple releases
Multiple projects
Multiple platforms
Practice 6: Control Changes to Software
Without explici t control,parallel development degrades to chaos
-
8/10/2019 01a _BestPractices
56/62
Change Control Board
PRD
SRS
Code
Test
CR
NewFeature
New
Requirement
Bug
ChangeReqest (CR)
Customer andEnd-User Inputs
Marketing
Coders inputsTesters inputs
Help DeskEnd-User Inputs
-
8/10/2019 01a _BestPractices
57/62
Concepts of Configuration & Change Management
Decompose the architecture into subsystems and assignresponsibility 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
-
8/10/2019 01a _BestPractices
58/62
Change Control Supports All Other Best Practices
Progress is incremental only if changes toartifacts are controlled
To avoid scope creep, assess the impact of allproposed changes before approval
Components must be reliable, i.e., the correctversions of all constituent parts found
To assure convergence, incrementally controlmodels as designs stabilize
Tests are only meaningful if the versions of theitems under test are known and the itemsprotected from changes
Develop iteratively
Manage requirements
Use componentarchitectures
Model visually
Verify quality
-
8/10/2019 01a _BestPractices
59/62
Problems Addressed by Controlling Changes
Solutions
Requirements change workflow isdefined and repeatable
Change requests facilitate clearcommunication
Isolated workspaces reduceinterference from parallel work
Change rate statistics are goodmetrics for objectively assessingproject status
Workspaces contain all artifacts,
facilitating consistencyChange 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
-
8/10/2019 01a _BestPractices
60/62
Summary: Best Practices of Software Engineering
-
8/10/2019 01a _BestPractices
61/62
Analyst
Tester
Developer
ReleaseEngineer
PerformanceEngineer
ProjectManager
Summary: Best Practices of Software Engineering
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
VerifyQuality
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
-
8/10/2019 01a _BestPractices
62/62
on their software projects.
Team-BasedDevelopment
ModelingLanguage
UnifiedProcess