01. bestpractices of software engineering

Best Practices of Software Engineering

[email protected]

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


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


CustomerService

Stock

Production

Technician

Billing

Secretary

orderproceed

ask_consumablesrepair

ask_consumables

buy

total_cost

notify

OOA/D Analogy


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


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


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


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


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

01. bestpractices of software engineering

Documents