Day 2, Part 1 Estimating Software Size Section 2 Calculating the Benefits of Software Reuse

1. Day 2, Part 1Estimating Software SizeSection 2Calculating the Benefits of Software Reuse

2. The Overall Planning Cycle Manage Risks Analyze Job Generate Initial Plans Generate Detailed Plans Execute Measure, Manage Productivity and Quality

3. Detailed Planning - Processes Source Information Statement of Work Requirements Constraints Standards Processes History etc. Estimate Size Estimate Effort and Cost Size WBS Effort & Cost Revise & Negotiate Not OK Complete Detailed Planning Evaluate Estimate Schedule OK Schedule

4. Architecture of Spreadsheet Effort Schedules Size / Reuse Software Reuse Analysis Final Effort Estimate Generic Schedule Productivity Based Effort Estimate Effort Schedule Final Size Estimate Analogy based Size Estimate Cocomo Based Estimate Expert Based Size Estimate Other Effort Estimates ... Other Size Estimates ...

5. Calculating the Benefits of Reuse

6. Dealing with Reuse • Many software programs are derived from previous programs • This MAY result in savings of cost and/or time • It MAY also result in increased quality • BUT ! . . .Reuse can also cost more and take longer and yield lower quality

7. Reuse Quality Diagram Old Software New Software Quality = x Reused: Quality = x Developed: Quality = y • Quality of new software depends on x and y. • If old software has poor quality it brings down the quality of the new software. • But if it has high quality, it brings quality up.

8. What Can be Reused?Just about Anything • Code • Test code • Test cases and procedures • Documentation • Design specifications • Designs • Requirements specifications • Etc., etc.

9. Reuse is Almost Never “Free” • Because you seldom have everything you need • You typically need to create tests or documents or other things • And you need to design the software to incorporate the “reused” components • And you need to integrate the “reused” components with everything else

10. Reuse Terminology Legacy Software Software developed for a previous application & BELIEVED TO BE OF USE for new application Modified Software Software developed for a previous application that is suitable for a new application after a MODEST AMOUNT OF MODIFICATION Reused Software Software developed for previous application suitable WITHOUT CHANGE OF ANY KIND

11. Legacy Software vs. Reusable Software Legacy Software • Designed for a Specific Application • Lax Standards for • Documentation • Test Procedures • Test Cases Like looking in a junkyard to find something of use • Reusable Software • Designed for Several Applications • Good Standards for • Documentation • Test Procedures • Test Cases • Like looking in a library to find something of use

12. Documenting Reuse Estimates • The Total column is total delivered units of Software • This could be applied equally to lines of code, function points or other measures

13. How Do You Count How Much of a Component is Modified or Reused? • Consider Component #4 and Component #5 on the previous slide • A Rule of Thumb: • Go to the smallest level known • Unit or module (typically about 100 LOC) • If the unit is not changed, it is “reused” • If the unit is changed, it is “modified” • If more than 50% of the unit is changed, it is “new”

14. Incorporating Several Distinct Kinds of Modified Software

15. Calculating the Benefit of Reuse After estimating size, and before estimating effort, you must convert reused software to “equivalent” new software Total Delivered Size Conversion Process Equivalent Size Reuse Information

16. How Do You Convert? • The conversion factor is based on how much less effort you will expend for reused or modified software than for new software • Assuming you have historical justification of the conversion factors, you can do a simple calculation

17. Example • This can be estimated directly via “reuse factors,” e.g.: • Reused software takes about 30% as much effort as new software • Modified software takes 60% as much effort as new software

18. Example Concluded • This says that the total effort to develop these 5121 units of software will be comparable to that of producing 3567 units of new software. • The same approach can be used for any size units: lines of code, function points or any other measures of software size.

19. Where Did Those “Reuse Factors”Come From? • Experience! • Over many hundreds of projects • But these are averages, and they vary a lot • Your experience may vary from mine • You must keep track in order to know • Different kinds of modified software may have different factors

20. Typical Reuse Factors (*) See later slides for information on concurrent reuse

21. We Can Get More Accurate • If we are willing to look more closely at the • Process & • Reuse characteristics, • Then we can gain a deeper understanding of the reuse impact • We can also use this information to calculate the reuse factors used in the previous example

22. First Examine the Process • List the steps of the process • Then determine the % of the total effort expended in each step, when developing new software • Note that this is effort, not time • Example:

23. Next Develop a Factor to Represent the Reuse Benefit in Each Process Step

24. For Example … • Let RM be the % of the requirements effort for this reused software • We must analyze requirements to see if reused software can be used • Let DM be the % of the design effort for this reused software • We may have to plan to test the software and maybe design the rest of the software in a special way Continued...

25. Example (continued) • Let CM be the % of the coding and unit testing effort required for this reused software • Normally 0 for “pure reused” software, but what about new test code? • Typically the % modified for modified software • Let IM be the % of the integration effort required for this software • often 50-100% even for pure reused

26. Applying the More Accurate Method • For each phase of the process • Determine % effort for each process phase • Determine the effect of reuse

27. Why is it “Modified” if You Change it Only a Little Bit • Totally reused software has: • Identical documentation • Identical test procedures, code, etc. • One master copy to maintain in the configuration management library • One part number for record keeping, inventory, etc. Continued...

28. Even if you Change only 1 Comment Line • You need to maintain two copies in the CM library (of code, test software, etc.) • And if you change 1 line of executable code • You need to change tests and documentation

29. What Is Concurrent Reuse? • “Concurrent” reuse is reusing something multiple times within the same software product • For example, if the same subroutine is used in each of several system components • It has very low cost, but it is not “free” • You have to integrate and test each component • And if you find a problem, you must fix it multiple times

30. Concurrent Reuse Example

31. Requirements Design Code Test More Notes on Reuse • The earlier in the process you reuse, the more leverage you get • Reusing an architecture or a design will support multiple target machines, languages, etc. Continued...

32. A Final Note on Reuse • The most important factor in planning for reuse is the application domain • A series of products in the same domain will get more reuse than a series of unrelated products • And it will be easier to find what you need when you need it • And the staff are more likely to be familiar with the old software and how it can be used again

33. Architecture of Spreadsheet Effort Schedules Size / Reuse Software Reuse Analysis Final Effort Estimate Generic Schedule Productivity Based Effort Estimate Effort Schedule Final Size Estimate Analogy based Size Estimate Cocomo Based Estimate Expert Based Size Estimate Other Effort Estimates ... Other Size Estimates ...