Newton's Law of Motion in Software Development Processes?

1
Newton's Law of Motion in Software Development
Processes?
Aditya P. Mathur (CS) Department of Computer
Sciences Purdue University, West
Lafayette Research collaborators João Cangussu
(CS) Ray. A. DeCarlo (ECE)
Presentation at The Center for Advanced
Computer Studies University of Louisiana,
Lafayette, LA Room HLG 147
Friday February 1, 2002
2
Research Question
Can we control the Software Development Process
in a manner similar to how physical systems and
processes are controlled ?
The fundamental control problem (Ref Control
System Design by G. C. Goodwin et al., Prentice
Hall, 2001)
The central problem in control is to find a
technically feasible way to act on a given
process so that the process adheres, as closely
as possible to some desired behavior.
Furthermore, this approximate behavior should be
achieved in the face of uncertainty of the
process and in the presence of uncontrollable
external disturbances acting on the process.
3
Research Methodology

1. Understand how physical systems are controlled?

2. Understand how software systems relate to
physical systems. Are there similarities?
Differences?
3. Understand the theory and practice of the
control of physical systems. Can we borrow from
this theory?
4. Adapt control theory to the control of SDP and
develop models and methods to control the SDP.
5. Study the behavior of the models and methods
in real-life settings and, perhaps, improve the
model and methods.
6. Repeat steps 6 and 7 until you are thoroughly
bored or get rich.
4
Feedback Control
Specifications
Program
5
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.
6
Software Development Process A Life Cycle
Requirements Elicitation
Not all feedback loops are shown.
7
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

8
Problem Scenario
cpi check point i
9
Our Approach
Actual STP

Initial Settings (wf,?)
rerror(t)
Controller
Test Manager

STP State Model
rexpected(t)
wf workforce ? quality of the test process.
10
Physical and Software Systems An Analogy
Dashpot
External force
To err is Human.
Rigid surface
Spring
Xequilibrium
Xcurrent
11
Physical Systems Control
Controllability Is it possible to control X (r)
by adjusting Y (workforce and process
quality)? Observability Does the system have
distinct states that cannot be unambiguously
identified by the controller ? Robustness Will
control be regained satisfactorily after an
unexpected disturbance?
12
Physical Systems Laws of Motion 1
First Law Every object in a state of uniform
motion tends to remain in that state of motion
unless an external force is applied to it.
Does not apply to testing because the number of
errors does not change when no external effort is
applied to the application.
13
Physical Systems Laws of Motion 2
Newtons Second Law The relationship between
an object's mass m, its acceleration a, and the
applied force F is F ma.
14
Physical Systems Laws of Motion 3
Third Law For every action force, there is an
equal and opposite reaction force.
When an effort is applied to test software, it
leads to fatigue on the tester.
This is not a scientific relationship.
15
Assumption I CDMs First Law
The magnitude of the rate of decrease of the
remaining errors is directly proportional to the
net applied effort and inversely proportional to
the complexity of the program under test.
This is analogous to Newtons Second Law of
motion.
16
Assumption II CDMs Second Law
Analogy with the spring
The magnitude of the effective test effort is
proportional to the product of the applied work
force and the number of remaining errors.
17
Assumption III CDMs Third Law
Analogy with the dashpot
The error reduction resistance is proportional to
the error reduction velocity and inversely
proportional to the overall quality of the test
phase.
18
State Model
19
Computing the feedback
20
Case Study II Razorfish Project Description
Project Goal translate 4 million lines of
Cobol code to SAP/R3
A tool has been developed to achieve the goal of
this project.
Goal of the test process (a) Test the generated
code, not the tool. (b) Reduce the number of
errors by about 85.
21
Validation Razorfish ProjectTesting Process
continue testing
yes

output 2
output 1
no
run
run
modify
Transformer
SCobol
SSAP R/3
input
Select a Test Profile
22
Case Study II Razorfish Project Results
If the process parameters are not altered then
the goal is reached in about 35 weeks.
23
Alternatives from Feedback STP Quality
Improving quality alone will not help
in achieving the goal.
Desired eigenvalue-0.152
24
Alternatives from Feedback Workforce
Changing the workforce alone can produce the
desired results.
25
Alternatives from Feedback STP quality and
workforce
Set of valid choices for changing the quality and
the workforce
26
Summary
Analogy between physical and software systems
presented.
The notion of feedback control of software
processes introduced.
One case study described.
Parameter estimation techniques used for model
calibration. Made use of system identification
techniques.
27
Ongoing Research
Expansion of the model to include the entire SDP.
Additional case studies.