01a _bestpractices

8/10/2019 01a _BestPractices

1/62

Best Practices of

Software Engineering

[email protected]

Petrus Mursanto


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


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


4/62

Software Development is a Job for Teams

Challenges

Larger teams

Specialization

Distribution

Rapid Technology change

Analyst

Tester

Developer

ReleaseEngineer

PerformanceEngineer

ProjectManager


5/62

IT Projects

32%

68%

Cancelled

Completed

Chaos Report by Standish Group 1997


6/62

IT Projects

32%

51%

17%

Cancelled

Over-budget

On-budget

Chaos Report by Standish Group 1997


7/62

How Are We Doing?

Analyst

Tester

Developer

ReleaseEngineer

PerformanceEngineer

ProjectManager

Many Successes Too Many Failures


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


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


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


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


Best Practices

develop iteratively

manage requirements

use component

architecturesmodel the software

visually

verity quality

control changes


12/62

Best Practices of Software Engineering

Develop Iteratively

ManageRequirements

UseComponent

Architectures

ModelVisually

VerifyQuality

Control Changes


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


14/62

Practice 1: Develop Software Iteratively

Develop Iteratively

ManageRequirements

UseComponent

Architectures

ModelVisually

VerifyQuality

Control Changes


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


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


17/62

Mitigate risks earlier

Design

ReqmAnalysis

Implemt

Iteration 1 Iteration 2 Iteration 3 Iteration 4

Waterfall Model

Iterative Model


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


19/62

Traditional Waterfall Development

Iteration Iteration Iteration Iteration Iteration Iteration Iteration


20/62


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


22/62

Apply Best Practices Throughout the Life Cycle


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






Poor testing




24/62

Practice 2: Manage Requirements

Develop Iteratively

UseComponent

Architectures

ModelVisually

VerifyQuality

Control Changes

ManageRequirements

R i t M t


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.


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


27/62




28/62



29/62

Requirements Trace to Many Project Elements


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


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






Poor testing




32/62

Practice 3: Use Component-Base Architectures

Develop Iteratively

ManageRequirements

ModelVisually

VerifyQuality

Control Changes

UseComponent

Architectures


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


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


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


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


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



Brittle architectures

Overwhelming complexity



Poor testing




38/62

Practice 4: Visually Model Software

Develop Iteratively

ManageRequirements

UseComponentArchitectures

VerifyQuality

Control Changes

ModelVisually


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


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


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


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


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


44/62

The UML Provides Standardized Diagrams

ClassDiagrams

Use-caseDiagrams

ActivityDiagrams

SequenceDiagrams

CollaborationDiagrams

Object

Diagrams

StateDiagrams

DeploymentDiagrams

ComponentDiagrams

Model


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


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







Poor testing

Waterfall development

Uncontrolled change



47/62

Practice 5: Verify Software Quality

Develop Iteratively

ManageRequirements

UseComponent

Architectures

ModelVisually

Control Changes

VerifyQuality


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


49/62

Relative Cost to Repair

Requirements

Design

Coding

Unit test

Acceptance test

Maintenance

Stage

.1 - .2

.5

1

2

5

20


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


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


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


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







Poor testing


Uncontrolled change



54/62

Practice 6: Control Changes to Software

Control Changes

ManageRequirements

UseComponent

ArchitecturesModel

VisuallyVerify

Quality

Develop Iteratively


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


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


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


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


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







Poor testing


Uncontrolled change



60/62

Summary: Best Practices of Software Engineering


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


62/62

on their software projects.

Team-BasedDevelopment

ModelingLanguage

UnifiedProcess

01a _bestpractices

Documents