Pertemuan 4 - Bestpractices

Best Practices of Software Engineering

Petrus Mursanto [email protected]

Objectives: z

Explore the symptoms and root causes of software development problems

z

Explain Rational’s six best practices for software development

z

Look at how Rational’s best practices address the root causes of software development problems

1

Software Development Situation Analysis

World economies increasingly software dependent

Business demands increased productivity & quality in less time

Applications expanding in size, complexity & distribution, importance

Not enough qualified people

Software Development is a Job for Teams Challenges z

Larger teams

z

Specialization

z

Distribution

Performance Engineer Analyst Project Manager Developer Tester

z

Rapid Technology change Release Engineer

2

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%

3

How Are We Doing?

Performance Engineer

• Many Successes • Too Many Failures Analyst

Project Manager

Developer

Tester

Release Engineer

Symptoms of Software Development Problems z z z z z z z z z

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

4

Treating Symptoms Does Not Solve the Problem Root Causes

Symptoms end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release

Diagnose

insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change Insufficient automation

Best Practices Address Root Causes Root Causes

3 3 3 3 3 3 3 3 3 3

Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation

Best Practices

3 3 3 3 3 3

Develop iteratively Manage requirements Use component architectures Model the software visually Verity quality Control changes

5

Addressing Root Causes Eliminates the Symptoms Symptoms

Root Causes

Best Practices

end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release

insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change Insufficient automation

develop iteratively manage requirements use component architectures model the software visually verity quality control changes

Best Practices of Software Engineering Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

6

Best Practices Enable High-Performance Teams

Results

Performance Engineer

• More Successful projects

Analyst Project Manager

Develop Iteratively

Manage Requirements

Use Component Architectures

Developer Tester

Model Visually

Verify Quality

Release Engineer

Control Changes

Practice 1: Develop Software Iteratively Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

7

Practice 1: Develop Software Iteratively z z

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

$$$ The time and money spent implementing a faulty design are not recoverable

Iterative Development z z z z z z z

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

8

Mitigate risks earlier Waterfall Model Reqm

Analysis

Design

Implemt

Iterative Model

Iteration 1

Iteration 2

Iteration 3

Iteration 4

Apply the Waterfall Iteratively to System Increments

Iteration 1

Iteration 2

R

Iteration 3

R D

R D

C

D C

T

C T

T

TIME

• Earliest iterations address greatest risks • Each iteration produces an executable release, an additional increment of the system • Each iteration includes integration and test

9

Traditional Waterfall Development

Iteration

Iteration

Iteration

Iteration

Iteration

Iteration

Iteration

Iterative Development

Each iteration results in an executable release.

10

Iterative Development Characteristics z z z z z z

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

11

Problem Addressed by Iterative Development Root Causes

Solutions

3 Insufficient requirements 3 Ambiguous communications 3 3 3 3 3

Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation

Enables and encourages user feedback Serious misunderstandings evident early in the life cycle Development focuses on critical issues Objective assessment thru testing Inconsistencies detected early Testing starts earlier Risks identified and addressed early

Practice 2: Manage Requirements Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

12

Practice 2: Manage Requirements • Elicit, organize, and document required functionality and constraints • Evaluate changes and determine their impact • Track and document tradeoffs and decisions

Requirements are dynamic – Expect them to change during software development

Definitions: Requirements and Their Management z z

A requirement is a condition or capability to which the system must conform Requirement management is a systematic approach to z

z

Eliciting, organizing, and documenting the requirements of the system, and Establishing and maintaining agreement between the customer/user and the project team on the changing requirements of the system

13

Requirements Management Means… Making sure you z solve the right problem z build the right system by taking a systematic approach to z eliciting z organizing z documenting z managing the changing requirements of a software application.

27

Agreement on What the System Should Do

The Goal

System to be built

Customer User Community Requirements Verification

Surrogate Goal

Use Case Model Requirements

14

Misunderstanding requirements

Misunderstanding requirements

15

Requirements Trace to Many Project Elements

How to Catch Requirements Error Early z

Effectively analyze the problem and elicit user needs

z

Gain agreement with the customer/user on the requirements

z

Model interaction between the user and the system

z

Establish a baseline and change control process

z

Maintain forward and backward traceability of requirements

z

Use an iterative process

16

Problems Addressed by Requirement Management Root Causes

Solutions

3 Insufficient requirements 3 Ambiguous communications 3 3 3 3 3

Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation

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 detected RM tool provides a repository for requirements, attributes and tracing, with automatic links to documents

Practice 3: Use Component-Base Architectures

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

17

Software Architecture Defined z

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

z z z z

J2EE Architecture

Browser request

response

request

Browser request

Browser

JavaBean

jsp

response

Application Server response

servlet servlet

JavaBean

jsp

DB Enterprise Server

Application Server

JavaBean Application Server

Browser

DB Enterprise Server

request

response

DB Enterprise Server

servlet

DB

Application Server

18

Architectural Decision Http browser Browser request

response

servlet

DB

Application Server

MS Access

Risk List: • belum pernah implemen J2EE architecture • konon produk Microsoft tdk compatible dgn Sun

Java

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

OOA/D Analogy

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.

19

OOA/D Analogy

Document Service Company proceed Production notify repair

ask_consumables

Customer Service

order

Technician Stock

buy

ask_consumables total_cost

Secretary

Billing

OOA/D Analogy

Document Service Company Customer Service order( ) notify( )

Production proceed( ) Stock ask_consumables( ) buy( )

Technician repair( ) Secretary

Billing total_cost( )

20

Resilient, Component-Based Architectures z

z

Good architectures meet their requirements, are resilient, and are component-based A resilient architecture enables z z z z

z

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 z z z

Reuse or customization of existing components Choice of thousands of commercially-available components Incremental evolution of existing software

Problems Addressed by Component Architectures

3 3

3 3

Root Causes

Solutions

Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation

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 componentbased design

21

Practice 4: Visually Model Software Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

Practice 4: Visually Model Software z

Capture the structure and behavior of architectures and components

z

Show how the elements of the system fit together

z z

Hide or expose details as appropriate for the task Maintain consistency between a design and its implementation

z

Promote unambiguous communication

Visual modeling improves our ability to manage software complexity

22

What is the UML? The Unified Modeling Language (UML) is a language for : z Specifying z Visualizing z Constructing z Documenting the artifacts of a software-intensive system

Representing Architecture: The 4+1 View Model

Implementation View

Logical View Analyst/Designers

Programmers

Structure

Software Managmt

End-User Functionality

System Integrators Performance Scalability

Process View

Use-Case View Deployment View System Engineers System topology Delivery, Installation communication

23

UML History UML 1.1

Sept ‘97 UML 1.0

Jan ‘97

Oct ‘95

Microsoft, Oracle, IBM, HP & other industry leaders

UML 0.9

Jun ‘96

Unified Method 0.8

Dr.Ivar Jacobson joins Rational (Fall of 1995) Dr.James Rumbaugh joins Rational (Oct 1994)

Use Case OMT

Booch

Inputs to UML Booch Rumbaugh

Jacobson

Fusion Operation descriptions, Message numbering

Meyer Pre and post conditions Harel State Charts Gamma, et.al. Framework, patterns, notes Shlaer-Mellor Object Lifecycles

Embley Singleton classes, High-level view Wirfs-Brock Responsibilities Odell Classification

24

The UML Provides Standardized Diagrams

Use-case Use-case Diagrams Diagrams

Class Class Diagrams Diagrams

Activity Activity Diagrams Diagrams

Object Object Diagrams Diagrams

Model

Sequence Sequence Diagrams Diagrams

State State Diagrams Diagrams Collaboration Collaboration Diagrams Diagrams

Deployment Deployment Diagrams Diagrams

Component Component Diagrams Diagrams

Visual Modeling Using UML Diagrams State Diagram Use-Case Diagram

Set count = 0

Class Diagram Domain Expert

Cancel

Cancel

[ count = 10 ]

Cancel

Check Balance Customer Student

Withdraw Money

University Package

User Interface Definition

Collaboration Diagram

Package Diagram Enrollment Package

Enrollment Package

Name ID Address Identify() Enroll() Print()

Deployment Diagram

Class

Forward & Reverse Engineering

Administration Package

Source Code edit, compile, debug, link

: Component Diagram

executable system

Sequence Diagram

25

Problems Addressed by Visual Modeling Root Causes

Solutions

3 3 3 3

Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment 3 Undetected inconsistencies 3 Poor testing Waterfall development Uncontrolled change 3 Insufficient automation

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

Practice 5: Verify Software Quality Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

26

Practice 5: Verify Software Quality Software problems are 100 to 1000 times more costly to find and repair after development

Cost

Development

Deployment

Relative Cost to Repair Stage .1 - .2

Requirements

.5

Design

1

Coding

2

Unit test

5

Acceptance test

20

Maintenance

27

Iterative Development Permits Continuous Testing

Iteration 1

Iteration 2

R

R D

D C

T Test

TIME

Test Life Cycle

R D

C

Iteration 3 C

T Test

Plan Design Implement Execute Evaluate

Plan Design Implement Execute Evaluate

T Test Plan Design Implement Execute Evaluate

Automated Tests

Requirements

Testing in an Iterative Environment Iteration 1

Iteration 2

Iteration 3

Iteration 4

Test Suite 1

Test Suite 2

Test Suite 3

Test Suite 4

28

Dimensions of Software Quality Type

Why?

How?

Functionality

Does my app do what’s required?

Test cases for each scenario implemented

Reliability

Does my app leak memory?

Analysis tools and code instrumentation

Application Performance

Does my app respond acceptably?

Check performance for each use-case/scenario implemented

System Performance

Does my system perform under production load?

Test performance of all usecases under authentic and worst-case load

Problems Addressed by Verifying Quality

3 3 3 3

Root Causes

Solutions

Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation

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

29

Practice 6: Control Changes to Software Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

Practice 6: Control Changes to Software z z z z z z z

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

Without explicit control, parallel development degrades to chaos

30

Change Control Board Customer and End-User Inputs New Feature

PRD

New Requirement

SRS

Bug

Code

Change Reqest (CR)

Test CR

Marketing Coders inputs Testers inputs

Help Desk End-User Inputs

Concepts of Configuration & Change Management z z

Decompose the architecture into subsystems and assign responsibility for each subsystem to a team Establish secure workspaces for each developer z z

z z z z

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

31

Change Control Supports All Other Best Practices z

Develop iteratively

Progress is incremental only if changes to artifacts are controlled

z

Manage requirements

To avoid scope creep, assess the impact of all proposed changes before approval

z

Use component architectures

Components must be reliable, i.e., the correct versions of all constituent parts found

z

Model visually

To assure convergence, incrementally control models as designs stabilize

z

Verify quality

Tests are only meaningful if the versions of the items under test are known and the items protected from changes

Problems Addressed by Controlling Changes Root Causes

3 Insufficient requirements 3 Ambiguous communications 3 3 3 3 3

Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation

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 controlled Changes maintained in a robust, customizable system

32

Best Practices Reinforces Each Other Ensures users involved

Manage Requirements

as requirements evolve Validates architectural

Use Component Architectures

decisions early on Addresses complexity of Develop Iteratively

Model Visually

design/implementation incrementally Measures quality early and often

Verify Quality

Evolves baselines incrementally Control Changes

Summary: Best Practices of Software Engineering

The result is software that is • On Time • On Budget • Meets Users Needs

Performance Engineer Analyst Project Manager

Develop Iteratively

Manage Requirements

Use Component Architectures

Developer Tester

Model Visually

Control Changes

Verify Quality

Release Engineer

33

The six best practices are designed to enable high-performance teams to be successful on their software projects.

Team-Based Development

Modeling Language

Unified Process

34