Improving the Productivity of Software Development

1. Improving the Productivity of Software Development Essential Steps & Problems

2. Topics • Introduction • Organizational impact • Four steps an improvement effort should include • Measurement of initial productivity • Identification and measurement of relevant productivity drivers • Analysis and adjustments to identified productivity drivers • Reevaluation and comparison of overall process productivity

3. Introduction • One study found that a 20 percent improvement in software productivity would be worth 90 billion dollars world wide during the last decade of the twentieth century • From 1990 to 1995, the software industry had a 10 percent drop in productive • Many blame the increasing size and complexity of applications • Others counter with the development of new tools such as CASE • Regardless, Productivity is an important issue

4. Introduction • Common output measure • SLOC • Useful in overall productivity assessment • Relatively useless in improvement efforts (not adjustable) • Racecar example • Top speed similar to SLOC (one measure of total output/performance) • Other output/performance measures should be used • Acceleration • Grip • Any performance improvement requires adjustment to performance driving characteristics of the car (Compression ratio, fuel to air mixture, timing, etc.) • Similarly in software development • Composite input/output metrics should be used • Measure and adjust adjustable drivers of productivity

5. Organizational Impact • Software Engineering Laboratory (SEL) - A software improvement activity at NASA Goddard Space Flight Center, aided by the University of Maryland and Computer Sciences Corporation • Goal - Improve productivity software projects at NASA • Existed for 25 years • A review of the 25 years of SEL identified 13 lessons learned • SEL found that a rigorous process and professional staff must be used for collection and analysis of production data • Part-time undergrads were insufficient • Organizations will also need full-time software improvement staff • SEL found a 10% overhead allocation is necessary.

6. Step 1: Measurement of Current Productivity • You can’t improve what you can’t measure. • Two fundamental measures any productivity measurement • Input • Output Productivity = Total software process output / Total software process input

7. Measurement of Current Productivity • This simple equation carries significant implications • Comparability of productivity values when identical metrics and instrumentation are used in the collection of data • Productivity of X is half as productive as 2X • Importance of accuracy • Do the metrics used actually reflect productivity • Example - Two software improvement efforts measuring the same process, but using different metrics might give diametric results • Productivity values will result in organizational change • Organizational change based on inaccurate data is not a good idea

8. Measurement of Current Productivity • Common input measures • Person-hours • Money • Common output measures • SLOC • Function Point Analysis

9. Measurement of Current Productivity • Revenue/Investment • Problems • Inflation • Only one value for input and output • A software development effort has relatively little relation to revenue generation • Revenue is more dependent on market factors

10. Measurement of Current Productivity • SLOC should reflect the current development effort • Not all code delivered to the customer is developed under the current effort • Not all code produced under the current effort is delivered to customers • Still, additional metrics of output are needed.

11. Measurement of Current Productivity • Additional output • application-domain knowledge gained • Software development experience gained • documentation and other artifacts • complexity of the product • quality of the product • Example • TeamA • Extensive application-domain knowledge • Extensive software development experience • TeamB • Little application-domain knowledge • Little software development experience • Both teams produce functionally equivalent products using 20,000 SLOC • Effort from TeamA is 500 person-months • Effort from TeamB is 1000 person-months • TeamA is twice as productive as TeamB? • TeamB produced additional output • Application-domain knowledge gained • Software development experience gained • Size alone doesn’t capture total output of a software development effort

12. Measurement of Current Productivity • Solution • Use composite input/output values • Problems for managers • What are the constituent values of the composite input/output values • What weights to assign them • How to aggregate them into one value • Ensure productivity is accurately represented • Total input and output are captured in the productivity equation

13. Step 2: Identification and measurement of productivity drivers • Product, process, and production setting characteristics individually and collectively affect the overall productivity of the software process • Productivity drivers

14. Identification and measurement of productivity drivers • Product-related drivers • Intrinsically related to product • Typically not adjustable • Examples • Computing resource constraints • Complexity • Size • Based on customer requests • Organizations must deliver • While not directly adjustable, product-related drivers are still important determinants of productivity

15. Identification and measurement of productivity drivers • Production setting-related drivers • Moderately controllable • Can differ within departments of the same organization • Examples • Programming language used • Differences between host (development) and target (end-user) system • Extent of client participation • Restricted by organizations practices and standards

16. Identification and measurement of productivity drivers • Process-related drivers • Most Controllable • Present real opportunities for improvement • Examples • Frequency and distribution of changes in operational system requirements • Effort applied to detailed software unit design • Effort applied to architectural design • Many process-related drivers are essentially the levels of effort applied to activities of the software development process (requirements analysis, design, integration, testing, etc . . .)

17. Step 3: Analysis and adjustment of productivity drivers • Problem for managers • Identify relationships between levels of output and productivity drivers • What adjustments need to be made • Buggy product code might imply lack of effort applied to software requirements specifications or requirements tracing. • Clearly deeper analysis is required

18. Analysis and adjustment of productivity drivers • Diminishing returns is an economic law stating, if one production factor is increased while other are held constant, eventually productivity will start to fall. • This implies specific levels of effort applied to process-related drivers which should maximize productivity • However effort is applied thorough variable humans (not like machines) • Difficult to find the maximal level of effort

19. Analysis and adjustment of productivity drivers • Relationships between productivity drivers and levels of output are hard to comprehend and expensive to identify (10%) • Confounded by interrelations of productivity drivers • Especially the human factor • Solution . . . • Theoretical knowledge based system that models software production • Set up to mirror current situation • Product characteristics • Process characteristics • Production setting characteristics • query the model and conduct “what if” analysis on the current situation . . . Immediate answers • Successful implementation of such a model would eliminate 80 to 90% of software improvement costs.

20. Analysis and adjustment of productivity drivers • Management should formulate an organizational change plan based on analysis of data collected with the aid of the data collection and analyzation team. • Commitment is important • 2/3 of all change efforts fail due to lack of commitment across all levels of the organizations • Lesson 11 at SEL involved having upper managements support for continued improvement in productivity

21. Analysis and adjustment of productivity drivers • Resistance to change is natural • Technology Acceptance Model (TAM) and the Theory of Planned Behavior (TPB) both study such adoption issues and predict intention to use and actual usage of workplace technology • Certain aspects of these models used to overcome initial resistance of the improvement plan and assimilate change in the workplace

22. Step 4: Reevaluation and comparison of overall process productivity • Reevaluate productivity • Use identical metrics • Use identical instrumentation • Ensures comparability and accuracy of the comparison • Establish the degree of success or failure of the improvement attempt • What went wrong • What went right • Continuous iteration of these steps means continuous improvement in productivity in spite of the ever increasing size and complexity of products.

23. Conclusion Following these four basic steps, and with a knowledge of problems that will be encountered, managers will be able to improve productivity of their software development efforts. Development of the theoretical software simulation model will significantly reduce the cost and complexity of this process.