An Introduction to the Quantitative,Rational and Scientific Process of

Software Development (Part 2)

Zenya Koono (Creation Project),

Hui Chen (Kokushikan University) and

Hassan Abolhassani (Shariff University of Technology)

SOMET 07 (Rome) in 7 November, 2007.

(C) 2007 Koono

Outline of Part 2

Object of Part 2: Use of “Process”

1.What is “process”

2. Quantitative Characteristics

3. Management Issues

(C) 2007 Koono

1. What is “Process”

(C) 2007 Koono

What is “Process”

ProcessI-thintermediateproduct

(I+1)-thintermediateproduct

People’s workwith right andresponsibility

I P O

Human intentionalactivity

Input and output define

the process

(C) 2007 Koono

Structure of “Process”Hierarchical “Process” is orthogonal to Hierarchical “Product”

Production

Maufacture

Development

Design Test

Spec. DFD design

CodingF/Cdesign

DFD

F/C

Co-de

Spec. Co-deDFD CodingF/C

．．．．．．．．

b

a

Spec

Code

“Process” is another hierarchical decomposition of object.It is another human intentional activity.

“Process” is commonly used, independent of “Product”.

“Process” is control technique.

I P O

Product’s “hierarchical objective” (C) 2007 Koono

Hierarchical Knowledge Tower

• “Process” is also knowledge.

• Human society may be regarded

as knowledge society,

consisting of many

knowledge rowers.

Minsky’s Hierarchical Agents

．．．．．．．．

．．．

．．

．．

．

．．．．．．．．

．．．．．．．．

．．．．．．．．

．．．．．．．．

．．．．．．．．

．．．．．．．．

Product

Process

(C) 2007 Koono

Process by “Divide and Conquer”

When variation of process characteristics is large,

constrain some intermediate interfaces.

If not enough, do the same on poor processes.

Residualdefect

Func-tion design

Detailed design

General F/C design

CodingData flow design

Flowchart design

Development

DesignPureDesign

Deskcheck

Pure Desk Desk Desk

Process

Variation

1.0

1/3

1/32

1/3

1/32

Pure Pure

Pure Desk Desk DeskPure Pure

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Residualdefect

Residualdefect

“Process” is a mean for managing development

(C) 2007 Koono

Field Experience

• Insufficient doc. specification/practice

• Enrich description with sample documents

Specifi-cation

CodingFunda-mental design

Detail-ed design

1

2

5

34 6

Accumulated normalized man-hours

Process - - >

Maximumvariation

Flow-chartdesign

Bottle-neck

Constancy ofProductivity

(C) 2007 Koono

• When errors are many, then divide the process

• When M-divided, the residual is decreased to 1/M

• Divide until they are enough small

Process by “Divide and Conquer”

Residualdefect

Func-tion design

Detailed design

General F/C design

CodingData flow design

Flowchart design

Development

DesignPureDesign

Deskcheck

Pure Desk Desk Desk

Process

Variation

1.0

1/3

1/32

1/3

1/32

Pure Pure

Pure Desk Desk DeskPure Pure

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Doc.

Residualdefect

Residualdefect

“Process” is a mean for managing development

(C) 2007 Koono

Difference of Two Projects

Many errors

in A

0.40

0.53

0.66

0.48

0.34

aa, 5, Fads, 6, Bshf, 2, Ud

State Message Macro Param. Code

Normalizederror rate ofeach stage

Normalizedtotalerror rate

A B0.046 0.023 0.038

00.015

Switching System

Finite StateMachine A

Finite StateMachine B

Small errors

in B

Desk check after design in small step of design progress is vital

(C) 2007 Koono

An Example of Desk Check

• A program for pasting a child DFD to the parent DFD

• Hierarchical data flows form HIPO 147 C code lines

• Error rate 14 E/klL (Built-in 102 E/kL, student average)

20 30

39

4445 47

40

20

01 2 3 4 5 6 7

4

Number of times of Design Review

Number of checked out at each time

test2 Found in

13 Logic error

5 Inacculate diagram

6 In correct naming

21 Inadequate writing

Total 47Accumulation

Desk check after design in small step of design progress is vital

13/(13 + 2) = 86.7%

(C) 2007 Koono

2. Quantitative Characteristics

2. 1 An Excellent Development in GTE

Excellent paper in Intl Switching Symposium 1979

Visited and discussed in the next ISS 81 Based on the paper and GTE internal documents, authors reproduced their characteristics at their responsibility

(C) 2007 Koono

GTE’s Excellent DevelopmentBuilt-in

rate

21 Er/kL

Deskcheck

82.5 %

Class and Subprogam

(Design Rev.)

Subprogram Module(Design Rev.)(Walk thru.)

Module Segement(Rev.)(Walk thru.)

(Code review)

Unit and Integration test

System test

0

10

20

3.1

5.59.0

16.817.9 18.5

20.5 21100

50

0

Accumulated error rate found. (error/Kilolines)

Percen-tage(%)

0.62.6 3.1

Test using machineDesk check

82.5 %

Coding(Code read)

Misc.

Class

subprog.subprog. subprog.

ModuleModule Module

SegmentSegment Segment

System structure

ClassClass

System

Excellent leaders: Exec. B.S.E.E. + MBA, management s/w.

Mgr.: Rational, quantitative & scientific. experience based.

Young people: Eagerly watching new technologies (C) 2007 Koono

Linear Nature of Process

• (Desk checked + test detected)/(Total of built-in)• Similar trend in man-hour data

Source Codes

Specification

Document i

．．．．．．．．

Document k

n1

n2

n3

n

Detailed design Coding

SpecificationFundamental design

Interme- diate process

Assembler language programs

0

100

50

Percentage

Compilor language programs

(C) 2007 Koono

Error/Defect Level Diagram

• Built-in and check-out during design• Attenuation by each test

a

b

1.1

0

10

20 Total built-in intensity

Defect built-in intensity(E/Kl)

21.0

3.64 3.35

5.06

11.99

2.42.813.64

3.1

3.5

4.11

10.43

7.8

0.54 0.95 1.56

4.193.1

Class Subprog.

Subprog. Module

ModuleSegment

Code read

Code review

Unit test Integr-ation test

Residual defect intrensity (E/Kl)10.0

3.0

1.0

0.3

3.1

2.5

0.5

Start

Labo-ratory test

Misc

0.6

2.0

GTE case

(C) 2007 Koono

Man-hour Data

• Total man-hour or no. of output (mod./sheet/line)• Budget curve based on past data

and actual data• Overall data for project leader group data for team leader a process data for each designer

ClassS. Prog.

S. Prog. Mod.

Mod.Seg.

CodingC. Read

Code Rev.

Lab Test

0

0.5

1.00

Unit StringTest

Resid.

Process

Accumulated man-hours(normalized)

a

Productivity (Man-hours/ k LOC

18.514.8

106

15.920

14.8

ClassS. Prog.Mod.

Mod.Seg.

CodingC. ReadC. rev.

Unit Test

Lab Test

Resid.StringTest

b

Test Pure design Desk check

(C) 2007 Koono

2. Quantitative Characteristics

2. 2 Learning Effect

Accumulation of Knowledge

(C) 2007 Koono

Learning Effect

• When a person begins a sport or a game, the person show a rapid growth at first, then, the gradient gradually decreases, but the similar growth continues.• When plotted on both-logarithmic chart, plots show a linear trend line. It is called a Logarithmic Learning Effect. (First official report 1936 from Boeing)

• Most human characteristics show Logarithmic Learning Effect. Used in many predictions.

Number of times of developments

0.5

01 3 6 10

1983

1993

1.0

Norma-lizedproduc-tivity

1 3 6 101.0

0.6

0.3

1993

1983

0.2

Norma-lizedproduc-tivity

Number of times of developments

(C) 2007 Koono

Logarithmic Accumulation

• First rapid progress then the gradient gradually decreases.

The logarithmic growth of knowledge supports the learning effect.

It arises from “Zipf’s law of least effort”• Learning effect is clarified 70 years after the first report in 1936

No.

of

des

ign

ru

les

No. of design experience (Liniear)0 4 8 12 160

10

20

30

40

Improved

Preceding

(No. of administration service commands)

30%a

1

No.

of

des

ign

rul

es

No. of design experience (Log-Log)10 100

100

10

1

Yx = 8X0.46

b

The improvement is achieved by Knowledge

(C) 2007 Koono

Productivity and Error Rate

Productivities of various software in 1970’s - 1980’s

Accumulated amount of production (normalized and Log. scales)

Normalized productivity(Log.)

1 3 5 7 10

2

1.5

131 10

0.3

Accumulated amount of production (Log.)

Bui

lt-in

err

or ra

te

(Log

.)

Hardware direct work

Software design

0.5

2

b

a

Built-in error rates of H/W production and S/W development in 1970’s - 1980’s

Both results by efforts of each leaders and people(Typical TQM)

The improvement is achieved by Knowledge

(C) 2007 Koono

3. Management Issues

3.1 Quality Assurance Organization

3.2 Both “Process” and “Product”

3.3 Repeat PDCA

3.4 Approach for Improvement

3.5 Not to Repeat The Same (Error) Again

Management issues

(C) 2007 Koono

3.1 Quality Assurance Organization

• Designers’ test: White box QA’s test: Black box test• Equal level people• Equal number of tests•Around 1/10 attenuation = Second kind of error rate

Number of defects found during designers' test (defect/KLine) (Log)

10 100 1000

10

100

1

Y = X

/ 10

a

Num

ber

of d

efec

ts f

ound

dur

ing

qual

ity

assu

ranc

e te

st (e

rror

/Klin

e)

10 100

10

100

1

Y =

X/1

0

b

Num

ber

of e

rror

s fo

und

afte

r de

live

ry (

erro

r/K

line)

Number of defects found during QA testing (defect/Kline) (Log)

Num

ber

of d

efec

ts fo

und

duri

ng q

uali

ty

assu

ranc

e te

st (

erro

r/K

line)

Number of defects found during designers' test (defect/Kline)

Y = X/15 + 0.03

0

0.4

4 8

0.8

0

c

Number of defects found during QA testing (defect/Kline)

Num

ber

of e

rror

s fo

und

afte

r de

live

ry (

erro

r/K

line)

0.80.4

0.04

0.08

00

Y = X/11.5

d

Design

Design

QA

QA

QA

QA

Field

Field

Koo

noD

r. W

atan

abe

Quality Assurance Organization improves corporate quality

Designers’ test QA’s test

(C) 2007 Koono

100-149

150-199

200-249

250-299

300-349

350-399

400-449

450-499

Over500

0

10

20

30

40

Program size (lines)

Frequency

DeMarco

Program level

100 200 500

6.92

2.031.00

2

0

4

6

Sys X Sys Y Sys Z

Software sizeSystem level

Software size follows to lognormal distribution

3.2 Both “Process” and “Product”Both must be strictly controlled

(C) 2007 Koono

3.2 Both “Process” and “Product”

Development cost is proportional to (Software size) (Man-hours) Function (Software size)

XQuality of Design Productivity

Soft.Size

Freq.

Freq.

Freq.

Ranging from 1/N to N, N = 4

Ranging from 1/N to N, N = 4 Center

Ranging from 1/5.7 to 5.7

∵ Power sum

= √{ (4)2 + (4)2}= 5.7

Productivity

Tota l�cost

Both must be quantitatively evaluated and improved.

(C) 2007 Koono

3.3 Repeat PDCA

Solution from preceding industrial experiences

1. Quantitative measure

2. “Management by Object” based on budget system

Example: Plan Do Check Action

3. Accumulate improvements

So-called “specialty of software”• It is difficult to manage invisible software

• When it ended, the cost was twice the budget

• It is the delivery day today, still bugs spring up

Not specialty but “Lack of management”

Any human intentional activities may be managed in the same way

(C) 2007 Koono

Plan, Do, Check and Action• 1. PLAN Ex. Proven productivity x Proven man-

month

• (1 + margin) (1 + margin)Budget

ActualExtension

After project Analysis (Check and Action)

2. DO Execute the plan

• 3. CHECK Quantitativemeasure

4. ACTION Overrun is not basically allowed5. Hierarchical organization’s rescue

• While recovery is possible,• Recover as planned already

(C) 2007 Koono

After Project Analysis

Project analysisNo Tbl Grade Cause

1 adh O -------

2 fru ∆ -------

3 mgp X -----

Product analysis Term Grade Cause

• Spec. 1 O -------

• Spec. 2 X -------

• Spec. 3 ∆ -------

• A problem is a result of Cause and Effect network.• From tracing back the network, primary / direct

cause then root cause, in the network ,are known.• A preventive mean not to repeat is to change primary / direct cause or root cause.• The feedback loop works as a preventive mean.

Feedback through experiences strengthen an organization

(C) 2007 Koono

Quantitative Project Planning• Quantitative evaluations after project enable advances

Design

1 C

Normalizeddefect intensity

e-aC Desk removalratio D

1

Desk checkPure design

Time

Linear build in

Time

Residual defect intensity

AP

CPOS

FP

(Number of error)/Kstep

Man-hourfor test

0

200

400

0 20 40

b. Medium quality case

Allowableresidual errorrate ofthe product

Build-inerror rateof design

Attenuationof error rateby deskcheck

Test intensity

X•3Effectivenessof test X • 1/3

(C) 2007 Koono

Purge “a Few” Vitals

A B C D E Others

100

0

50

Pareto curve

QC practiceJuran’s law:A few vitalconstitutesmajority ofloss

This practice may beapplicable in allhuman related fields.

It may be proved byZipf’s law.

A good practice in other field is effetive also in S/W.

(C) 2007 Koono

Not to Repeat The Same Again

Cla

ims

Customers

Why? Why? Cor-rectdoc

Why?

Doc

i Design j

Doc

j Design k

Doc

k

Test

Pro

duct

Ser

viceUsers

Ab-normalbehavior

Erredcode

Erreddoc Why?

123

4

Mgr

Corporate philosophy

Company rules

Product standard

Practice Rules

EngrEngr

Chief 5

E E E

Tbl

CCC

C

C

Hunting on a cause and effect network

(C) 2007 Koono

Approach for Improvement

Purge“Waste”,“Strain”,

“Imbalances”

Charac-terisitc value

Years / The number of repetition

H/Wproduction

End of19th C

Beginning20th C

Beginning21st C

S/WDesign

Log-normal

Normal

Quantitative control

(C) 2007 Koono

Problem in SoftwareH/W industries have accumulated all the efforts and succeeded

Example: TOYOTA

Some S/W companies pour people as demanded and withdraw themas their direct works ends, and thus do not allow people toanalyse the development result and to accumulate the knowledge.No feedback and thus no accumulation, no advance.

Charac-terisitc value

Years / The number of repetition

Log-normal

Normal

(C) 2007 Koono

Conclusion

• Management, design, physical works arehuman intentional activities.

• From a viewpoint of knowledge, they showthe same characteristics.

• Thus the same Quantitative, Rational and

Scientific management / control is possible.

(Reported here is abstracted knowledge)

• The problem left is how to penetrate them

(C) 2007 Koono

Thank you very much for

your kind attention.

Your any questions, comments aswell as objections are wellcome.

(C) 2007 Koono