1 feedback control of the software development process department of computer sciences purdue...
TRANSCRIPT
1
Feedback Control of The Software Development Process
Department of Computer SciencesPurdue University
CS Honors Seminar
João Cangussu (CS)Ray. A. DeCarlo (ECE)Aditya P. Mathur (CS)
Tuesday August 28, 2001
2
Software Development Process: Definitions
A Software Development Process (SDP) is a sequence of well defined activities used in the production of software.
An SDP usually consists of several sub-processes that may or may not operate in a sequence. The Design Process, the Software Test Process, and the Configuration Management Process are examples of sub-processes of the SDP.
3
Research Question
Can we control the SDP in a manner similar to how physical systems and processes are controlled?
4
Research Methodology
1. Understand how physical systems are controlled?
2. Understand how software systems relate to physical systems. Are there similarities? Are there differences?
3. Understand the theory and practice of the control of physical systems.
4. Can we borrow from this theory? If “yes,” then proceed further, else drink coffee or tea and think of another research direction.
5. Adapt control theory to the control of SDP and develop models and methods to control the SDP.
6. Study the behavior of the models and methods in real-life settings.
5
Research Methodology
7. Improve the model and methods.8. Repeat steps 6 and 7 until you are thoroughly bored or
get rich.
6
Current Focus
Software Test Process (STP): System test phase
Objective:Control the STP so that the quality of the tested software is as desired.
Quantification of quality of software:• Number of remaining errors• Reliability
7
Introduction Problem Scenario
r -
num
ber
ofre
mai
ning
err
ors
t- timecp1 cp2 cp3 cp4 cp5 cp6 cp7 cp8 cp9
where cpi = check point ir0
rf
schedule set bythe manager
approximation
observed
deadlinet0
8
IntroductionOur Approach
Actual STP
Controllerrerror(t)
wf
+
+
wf+wf
+
wf+wf
+ STP State Model
robserved(t)
rexpected(t)
sc r0
sc r0
Initial Settings(wf,)
rexpected(Tf)=rf
9
Physical Systems: Laws of Motion
First Law:
A body continues in a state of rest, or motion with a constant velocity, unless compelled to change by an unbalanced force.
Second Law:
The acceleration of an object is directly proportional to the net force acting upon it and inversely proportional to its mass.
10
Physical Systems: Laws of Motion
Third Law:
For every action force, there is an equal and opposite reaction force.
Fundamental concepts: Force, Mass, AccelerationDerived concepts: Inertia
11
Physical and Software Systems: An Analogy
Block
Dashpot
Rigid surface
External force
Xcurrent
Xequilibrium
X: Position
Number of remainingerrors
Spring Force
Effective Test Effort
Software
Mass of the blockSoftware
complexity
Quality of thetest process
Viscosity
Spring
To err isHuman.
12
Physical Systems: Spring-Mass System
Block: Software under test.
Mass: Software complexity
Spring: Effective test effort; larger spring coefficient implies larger workforce.
Dashpot: Opposing force; quality of the test process is inversely proportional to the coefficient of viscosity.
Position: Number of remaining errors.
13
Physical Systems: Control
Controllability
Is it possible to control X by adjusting Y?
Observability
Does the system have distinct states that can't be unambiguously identified by the controller ?
Robustness
Will control be regained satisfactorily after an unexpected disturbance?
14
Assumption I
The magnitude of the rate of decrease of the remaining errorsis directly proportional to the net applied effort and inverselyproportional to the complexity of the program under test.
cn
c
nsre
s
er
15
Assumption II
The magnitude of the effective test effort is proportional to theproduct of the applied work force and number of remaining errors.
for an appropriate .
16
Assumption III
The error reduction resistance is proportional to the error reduction velocity and inversely proportional to the overallquality of the test phase.
rer
1
for an appropriate .
17
State Model
r
r
r
r
F
sr
r
ss
wr
rd
ccc
f
10
01
1
010
18
FeedbackteTrtTrTr max)()()(
c
f
c
cc
f
s
w
s
ss
wAI
ˆ
ˆ
ˆ
ˆ1
detdet
2
fwff wwandwhere ˆˆ
19
Case Study II: Razorfish Project Description
Project Goal: translate 4 million lines of Cobol code to SAP/R3
A tool has been developed to achievethe goal of this project.
Goal of the test process: Test the generated code, not the tool.
20
Case Study II: Razorfish Project Error Correspondence
xx
xx
x
xx
xx
x
Assumption 1
xx
xx
x
xx
x
Assumption 2A B A B
Where:• A represents errors in the transformer• B represents errors in the generated code
21
Validation: Razorfish ProjectTesting Process
Transformer
=
modify
SSAP R/3
run
output 1 output 2
run
SCobol
Select a Test Profile
input
continuetesting yes
no
22
Case Study II: Razorfish Project Results
85.2ˆ
Approximation Error
23
Case Study II: Razorfish ProjectAlternatives from Feedback
24
Case Study II: Razorfish ProjectAlternatives from Feedback
25
Case Study II: Razorfish ProjectAlternatives from Feedback
26
Case Study II: Razorfish ProjectAlternatives from Feedback
27
Validation: Razorfish ProjectParameters
weeks sc wf Fd
Period 11 to 6 0.55 100 4 48 3 80%Period 26 to 10 0.6 100 3.5 48 3 65%Period 310 to … 0.75 100 3.5 48 3 25%
three segments local approximation
28
Summary
Analogy between physical and software systems presented.
The notion of feedback control of software processes introduced.
One case study described.
29
Ongoing Research
Sensitivity analysis of the model.
Expansion of the model to include the entire SDP.
Additional case studies.
30
Physical Systems: Oven Controller
T0
Te
Heat loss toenvironment
Oven temperature
thermal resistance ofinsulation
Temperature reading
Electrical heater ofheat capacity Ch
C0Ch R0
Rho
Controller
ThW
oven, heat capacity C0
thermal resistance
To adjust power dissipated inthe heating elements in the heater.