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.