software development (part 2) rational and scientific ... · pdf filerational and scientific...
TRANSCRIPT
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
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
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