1. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M14 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 14 Size Estimating Notes, Reuse and COTS or FOSS Software

2. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 2 Objectives of This Module  To discuss some general points about size estimating  To discuss how to deal with reuse when estimating  To discuss how to deal with software available from others –COTS (Commercial, Off-the-shelf) Software –Free or Open Source Software (FOSS)

3. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 3 Detailed Planning - Processes Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost ScheduleOK Complete Detailed Planning Revise & Negotiate Not OK Estimate Size Estimate Effort and Cost

4. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 4 What Method if No Data?  What if you have absolutely no data on the code to be written? –no prior experience –no expertise available  You may be able to try something like function points if you know the functional requirements  Or wideband Delphi  Or just count requirements

5. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 5 Risk Management The less you know when estimating, the more you need to plan on several updated estimates as you learn more

6. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 6 What About Non-Software WBS Tasks that do Not Influence Size?  Some of these may depend on size –Number and size of documents required –Management costs –Number of reports –Magnitude of support functions –Cost of inspections  Such tasks will be estimated (for effort or cost) AFTER size is estimated (see later)

7. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 7 What about Non-software WBS Tasks that do Not Influence Size? (continued)  Other tasks may be independent of size but dependent on effort or headcount –Number of workstations –Number of copies needed for compilers, tools –etc.  Such tasks are estimated once you have estimated effort or headcount

8. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 8 Other Non-Software WBS Tasks  Some tasks may be independent of size or effort –Travel to attend reviews and meetings with customer –Legal fees for setting up contracts –etc. All of these non-software tasks will be addressed during effort and cost estimating

9. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 9 Final Notes 1) Use more than one method and resolve discrepancies –No method is reliable enough in most cases –When two methods disagree, it tells you you are missing some facts Method 1 Wideband Delphi Resolution? Method 3 Method 2 Statistical Analysis OK (Revise Estimates) Not OK

10. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 10 Final Notes (continued) 2) Include data declarations in size estimates 3) Include all functions - many are easy to overlook or underestimate –Control –Power up –Power failure –Diagnostics –Operating Systems

11. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 11 Final Notes (continued) 4) Select software items carefully –Simplify interfaces –Minimize impact on support & maintenance –Fit the hardware in a reasonable fashion –Size should be manageable –One geographic area (preferably one organization) for development –Allow incremental builds Continued...

12. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 12 Final Notes (continued) 4) Select software items carefully (continued) –Consider design and documentation requirements –Too many SIs results in management overhead and potentially higher cost –Too few SIs increases risk (less visibility; harder to test; harder to maintain)

13. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 13 5) Don’t under-scope what you don’t understand –built-in test requirements –control panels –displays –... Final Notes (continued) The biggest estimating errors are errors of ignorance “I didn’t realize that this part of the software was so complex.”

14. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 14 Final Notes (continued) 6) Consider the design methodology carefully –newer methods can be more productive –but older ones often have less risk due to experience, availability of tools, etc.

15. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 15 Final Notes (continued) 7) Account properly for reuse, COTS and FOSS –use it – reuse, COTS and FOSS can save lots of money –don’t consider them to be free

16. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 16 Spreadsheet Model Based Effort Estimate Other Effort Estimates... Size / Reuse EffortEffort & Cost Schedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Labor Schedule Cost Schedule Analogy based Size Estimate Software Reuse Analysis Other Size Estimates... Final Size Estimate Expert Based Size Estimate

17. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 17 Final Size Estimate MethodAnalogyWB DelphiPrototypeJudged Value Size23,45621,50027,60025000 Memory Required 103,000110,200125,000 Options for judged value: 1)Average the results, if they are similar 2)Re-visit estimates when they differ significantly from each other (more than about 10%) 3)Use your judgment

18. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 18 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

19. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 19 Quality = x Reused: Quality = x New: Quality = y Old SoftwareNew Software 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. Reuse Quality Diagram

20. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 20 What Can be Reused?......Just About Anything  Code  Test Code  Test Cases and Procedures  Documentation  Design Specifications  Designs

21. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 21 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

22. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 22 Reuse Terminology Legacy Code Code developed for a previous application & BELIEVED TO BE OF USE for new application Modified Code Code developed for a previous application that is suitable for a new application after a MODEST AMOUNT OF MODIFICATION Reused Code Code developed for previous application suitable WITHOUT CHANGE OF ANY KIND

23. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 23 Legacy Code vs. Reusable Code Legacy Code  Designed for a Specific Application  Unknown Standards for –Documentation –Test Procedures –Test Cases Like looking in a junkyard to find something of use Reusable Code  Designed for Several Applications  Good Standards for –Documentation –Test Procedures –Test Cases Like looking in a library to find something of use

24. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 24 Documenting Reuse Estimates The total LOC column is total delivered lines of code This could be applied equally to function points or other measures

25. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 25 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”

26. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 26 Example Module A Formatter Module B Fourrier Transform Module C Special Algorithms Component 1 Analysis Component 2 User Interface Component 3 Data Base Software Key: Mixed New Modified Reused Items at the bottom of the structure are never mixed – they are new, modified, or reused

27. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 27 Incorporating Several Distinct Kinds of Modified Code

28. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 28 Total Delivered Size Conversion Process Equivalent Size Reuse Information Calculating the Benefit of Reuse  After estimating size, and before estimating effort, you must convert reused code to “equivalent” new code

29. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 29 How Do You Convert?  The conversion factor is based on how much less effort you will expend for reused or modified code than for new code  Assuming you have historical justification of the conversion factors, you can do a simple calculation

30. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 30 Conversion Factor Example  Equivalent size can be estimated directly via “reuse factors,” e.g.: –Reused code takes about 30% as much effort as new code –Modified code takes 60% as much effort as new code

31. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 31 Example Concluded  This says that the total effort to develop these 5121 lines of mixed (part new, part modified, part reused) code will be comparable to that of producing 3567 lines of new code.  The same approach can be used for function points or other measures of software size. New Code Mixed Code

32. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 32 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 code may have different factors

33. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 33 Typical Reuse Factors (*) See later slides for information on concurrent reuse

34. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 34 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

35. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 35 First Examine the Process  List the steps of the process  Then determine the % of the total effort expended in each step, when developing new code  Note that this is effort, not time  Example:

36. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 36 Next Develop a Factor to Represent the Reuse Benefit in Each Process Step Require- ments DesignCode and Unit Test Integration Relative Effort 18%25% 32% Modified Factor 40%35%55%80% Reuse Factor 10%15%5%75%

37. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 37 Applying the More Accurate Method  For each phase of the process –Determine % Effort for –Determine the Effect of Reuse

38. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 38  Once again, the method can be used for any measure of size, such as function points, feature points, etc.  For truly reused code –CM is near 0, but maybe you must do some test code, so perhaps it is not actually 0 –RM and DM are probably > 0  It takes effort to analyze and determine whether reused code will work –IM is generally not 0  You have to run the integration tests... Notes

39. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 39 Why is it “Modified” if You Change it Only a Little Bit  Totally reused code 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...

40. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 40 Why is it “Modified” if you Change it Only a Little Bit (continued)  Even if you change 1 comment line –You need to maintain two copies in the CM library (of code, test code, etc.)  And if you change 1 line of executable code –You need to change tests and documentation

41. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 41 What About 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

42. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 42 Reuse Factor To Use for Concurrent Reuse  Typically, a concurrent reuse situation calls for a factor less than 5% –If the initial code is new or heavily modified, the second and subsequent uses (concurrent reuse) tend to need factors of about 2-4% –If the initial code is reused or lightly modified, the proper factor tends to run from 0.5% to 2%

43. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 43 Concurrent Reuse Example ItemNewModifiedReusedConcurrent Reuse Total 2,1381,7821,2012,0007,121 Factor100%60%30%1% Net2,1381,069360203,588

44. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 44 Maintenance vs Reuse?  If you have a large amount of code and are modifying only a part of it, as in a maintenance situation, is this a form of reuse? If so, what reuse factor is appropriate? –Typically the factor would be very small, as with concurrent reuse –Often, people estimate maintenance with a bottom-up technique rather than as a form of “reuse”

45. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 45 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. Requirements Design Code Test

46. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 46 A Final Note on Reuse  The most important factor in planning reuse is 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 code and how it can be used again

47. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 47 COTS and FOSS  COTS is software you purchase from some other organization –For example, you might use a commercially available operating system or data base system within your application  FOSS is software you obtain for free, but possibly with strings attached –For example, you may be required to send all improvements back to the originator

48. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 48 Estimating “Size” of COTS and FOSS  COTS and FOSS are treated like reused software (or FOSS can be treated like modified software if you modify it) – you develop an estimate of equivalent size based on how much effort you will have to expend to incorporate it into your software –The more accurate method is recommended  However, you may not know the actual size of COTS –So you may have to do more guesswork, or use expert judgment techniques to help with the more accurate reuse estimating method

49. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 49 Additional Complications for COTS and FOSS  Design documentation, test code, and other desirable artifacts may not be available  You may have licensing fees for your end product –Typically, a fee for every copy sold  You may have unacceptable restrictions –For example, you may be prohibited from using it in certain kinds of applications –Or you may be required to send all changes back to the originator of FOSS  If the originator goes out of business you may have no access to the source code of COTS  Upgrades may be complicated to implement

50. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 50 Bottom Line on COTS and FOSS  They may add risk to your project  And they may add costs you had not planned for  But they can also save you a lot of time and money As an educated software manager, you are expected to know these things and to make appropriate decisions and plans.

51. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 51 Suggestion for COTS and FOSS  Have someone in charge of all COTS and FOSS –Establishing acceptable licensing conditions –Making sure that hidden costs and obligations are understood –Making sure that the end product is not unnecessarily burdened by many different COTS and FOSS components that have entirely different licensing conditions

52. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 52 Summary of Size Estimating  History is your best ally  Use multiple methods –to learn –to reduce risk  Target memory size is handled differently from source code size, although the two are generally related  Account for reuse

53. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 53 Module Summary  There are many special cases and issues to consider when estimating size  Reuse is accounted for by computing an equivalent size, based on the gains from reuse –These are estimated by conversion factors based on past experience

54. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M14 - Version 9.01 54 END OF MODULE 14