1. 1 Feedback Control of The Software Development Process Department of Computer Sciences Purdue University CS Honors Seminar João Cangussu (CS) Ray. A. DeCarlo (ECE) Aditya P. Mathur (CS) Tuesday August 28, 2001

2. 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. 3 Research Question Can we control the SDP in a manner similar to how physical systems and processes are controlled?

4. 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. 5 Research Methodology 7.Improve the model and methods. 8.Repeat steps 6 and 7 until you are thoroughly bored or get rich.

6. 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. 7 Introduction Problem Scenario r - number of remaining errors t- time cp 1 cp 2 cp 3 cp 4 cp 5 cp 6 cp 7 cp 8 cp 9 where cp i = check point i r0r0 rfrf schedule set by the manager approximation observed deadline t0t0

8. 8 Introduction Our Approach Actual STP Controller r error (t)  wfwf + + wf+wfwf+wf  +  wf+wfwf+wf STP State Model r observed (t) r expected (t) scsc r0r0 scsc r0r0 Initial Settings (w f,  ) r expected (T f )=r f

9. 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. 10 Physical Systems: Laws of Motion Third Law: For every action force, there is an equal and opposite reaction force. Fundamental concepts: Force, Mass, Acceleration Derived concepts: Inertia

11. 11 Physical and Software Systems: An Analogy Block Dashpot Rigid surface External force Xcurrent Xequilibrium X: Position Number of remaining errors Spring Force Effective Test Effort Software Mass of the block Software complexity Quality of the test process Viscosity Spring To err is Human.

12. 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. 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. 14 Assumption I 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.

15. 15 Assumption II The magnitude of the effective test effort is proportional to the product of the applied work force and number of remaining errors. for an appropriate .

16. 16 Assumption III The error reduction resistance is proportional to the error reduction velocity and inversely proportional to the overall quality of the test phase. for an appropriate .

17. 17 State Model

18. 18 Feedback

19. 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 achieve the goal of this project. Goal of the test process: Test the generated code, not the tool.

20. 20 Case Study II: Razorfish Project Error Correspondence x x x x x x x x x x Assumption 1 x x x x x x x x Assumption 2 A B A B Where: A represents errors in the transformer B represents errors in the generated code

21. 21 Validation: Razorfish Project Testing Process Transformer = modify S SAP R/3 run output 1 output 2 run S Cobol Select a Test Profile input continue testing yes no

22. 22 Case Study II: Razorfish Project Results Approximation Error

23. 23 Case Study II: Razorfish Project Alternatives from Feedback

24. 24 Case Study II: Razorfish Project Alternatives from Feedback

25. 25 Case Study II: Razorfish Project Alternatives from Feedback

26. 26 Case Study II: Razorfish Project Alternatives from Feedback

27. 27 Validation: Razorfish Project Parameters

28. 28 Summary Analogy between physical and software systems presented. The notion of feedback control of software processes introduced. One case study described.

29. 29 Ongoing Research Sensitivity analysis of the model. Expansion of the model to include the entire SDP. Additional case studies.

30. 30 Physical Systems: Oven Controller T0T0 TeTe Heat loss to environment Oven temperature thermal resistance of insulation Temperature reading Electrical heater of heat capacity Ch C0C0 ChCh R0R0 R ho Controller ThTh W oven, heat capacity C0 thermal resistance To adjust power dissipated in the heating elements in the heater.