01. bestpractices of software engineering
DESCRIPTION
Software enginering best practicesTRANSCRIPT
Best Practices of Software Engineering
Petrus Mursanto
Objectives:
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 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
TesterDeveloper
ReleaseEngineer
PerformanceEngineer
ProjectManager
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
TesterDeveloper
ReleaseEngineer
PerformanceEngineer
ProjectManager
• Many Successes• Too Many Failures
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
Symptoms
end-user needs
changing requirements
modules don’t fit
hard to maintain
late discovery
poor quality
poor performance
colliding developers
build-and-release
Root Causes
insufficient requirementsambiguous communications
brittle architecturesoverwhelming complexity
undetected inconsistenciespoor testing
subjective assessmentwaterfall development
uncontrolled changeInsufficient automationDiagnose
Best Practices Address Root Causes
Best Practices
Develop iterativelyManage requirementsUse component architecturesModel the software visuallyVerity qualityControl changes
Root Causes
Insufficient requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexityUndetected inconsistenciesPoor testingSubjective assessmentWaterfall developmentUncontrolled changeInsufficient automation
Addressing Root Causes Eliminates the Symptoms
Symptoms
end-user needschanging requirementsmodules don’t fithard to maintainlate discoverypoor qualitypoor performancecolliding developersbuild-and-release
Root Causes
insufficient requirementsambiguous
communicationsbrittle architecturesoverwhelming complexityundetected inconsistenciespoor testingsubjective assessmentwaterfall developmentuncontrolled changeInsufficient automation
Best Practices
develop iterativelymanage requirementsuse component
architecturesmodel the software
visuallyverity qualitycontrol changes
Best Practices of Software Engineering
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
VerifyQuality
Control Changes
Best Practices Enable High-Performance Teams
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
VerifyQuality
Control Changes
Results
• More Successful projects Analyst
TesterDeveloper
ReleaseEngineer
PerformanceEngineer
ProjectManager
Practice 1: Develop Software Iteratively
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
VerifyQuality
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
DesignReqm
AnalysisImplemt
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 testingInconsistencies detected earlyTesting starts earlierRisks identified and addressed
early
Root Causes
Insufficient requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexitySubjective assessmentUndetected inconsistenciesPoor testingWaterfall developmentUncontrolled changeInsufficient automation
Practice 2: Manage Requirements
Develop Iteratively
UseComponent
Architectures
ModelVisually
VerifyQuality
Control Changes
ManageRequirements
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
CustomerUser Community
RequirementsVerification
SurrogateGoal
System tobe 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 detectedRM tool provides a repository for
requirements, attributes and tracing, with automatic links to documents
Root Causes
Insufficient requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexitySubjective assessmentUndetected inconsistenciesPoor testingWaterfall developmentUncontrolled changeInsufficient automation
Practice 3: Use Component-Base Architectures
Develop Iteratively
ManageRequirements
ModelVisually
VerifyQuality
Control Changes
UseComponent
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
Document Service Company
What kind of services we will provide?
• Photocopy (color, b/w, zoom in/out)
• Printing (color, b/w, poster size)
• Binding
• etc.
OOA/D Analogy
Document Service Company
CustomerService
Stock
Production
Technician
Billing
Secretary
orderproceed
ask_consumablesrepair
ask_consumables
buy
total_cost
notify
OOA/D Analogy
Document Service Company
Customer Serviceorder( )notify( )
Stockask_consumables( )buy( )
Productionproceed( )
Technicianrepair( )
Billingtotal_cost( )
Secretary
OOA/D Analogy
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 requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexitySubjective assessmentUndetected inconsistenciesPoor testingWaterfall developmentUncontrolled changeInsufficient automation
Practice 4: Visually Model Software
Develop Iteratively
ManageRequirements
UseComponent
Architectures
VerifyQuality
Control Changes
ModelVisually
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 ViewProcess View
Analyst/DesignersStructure
ProgrammersSoftware Managmt
System IntegratorsPerformanceScalability
System EngineersSystem topology
Delivery, Installation communication
End-UserFunctionality
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 Rumbaughjoins Rational
(Oct 1994)
Microsoft, Oracle, IBM,HP & other
industry leaders
Inputs to UML
BoochJacobsonRumbaugh
MeyerPre and post
conditions
HarelState Charts
Gamma, et.al.Framework, patterns,
notesShlaer-Mellor
Object LifecyclesOdell
Classification
Wirfs-BrockResponsibilities
EmbleySingleton classes,
High-level view
FusionOperation descriptions,
Message numbering
The UML Provides Standardized Diagrams
ClassDiagrams
Use-caseDiagrams
ActivityDiagrams
SequenceDiagrams
CollaborationDiagrams
ObjectDiagrams
StateDiagrams
DeploymentDiagrams
ComponentDiagrams
Model
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
NameIDAddress
Identify()Enroll()Print()
Class
Package DiagramUniversity Package
Enrollment Package
Administration Package
Enrollment Package
Component Diagramexecutable
system
Source Code edit,compile, debug, link
Forward & ReverseEngineering
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 requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexitySubjective assessmentUndetected inconsistenciesPoor testingWaterfall developmentUncontrolled changeInsufficient automation
Practice 5: Verify Software Quality
Develop Iteratively
ManageRequirements
UseComponent
Architectures
ModelVisually
Control Changes
Verify Quality
Practice 5: Verify Software Quality
Software problems are 100 to 1000 times morecostly 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
RD
CT
RD
CT
RD
CT
Iteration 1 Iteration 2 Iteration 3
Test Test Test
PlanDesign
ImplementExecute
Evaluate
TIME
PlanDesign
ImplementExecute
Evaluate
PlanDesign
ImplementExecute
Evaluate
TestLife
Cycle
Testing in an Iterative EnvironmentIteration 1 Iteration 2 Iteration 3 Iteration 4
Req
uire
men
ts
Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4
Aut
omat
ed T
ests
Type Why? How?
Dimensions of Software Quality
Functionality
Reliability
Application Performance
System Performance
Does my app do what’s 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 requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexitySubjective assessmentUndetected inconsistenciesPoor testingWaterfall developmentUncontrolled changeInsufficient automation
Practice 6: Control Changes to Software
Control Changes
ManageRequirements
UseComponent
Architectures
ModelVisually
VerifyQuality
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
NewFeature
NewRequirement
Bug
ChangeReqest (CR)
Customer andEnd-User Inputs
Marketing
Coders inputsTesters inputs
Help DeskEnd-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 controlledChanges maintained in a robust,
customizable system
Root Causes
Insufficient requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexitySubjective assessmentUndetected inconsistenciesPoor testingWaterfall developmentUncontrolled changeInsufficient automation
Best Practices Reinforces Each Other
Use ComponentArchitectures
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
TesterDeveloper
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 on their software projects.
Team-BasedDevelopment
ModelingLanguage
UnifiedProcess