2. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Software Project Management Introduction to Estimating Development Effort ( courtesy of “Software Project management – Hughes & Cotterell” 4 th Edition )

3. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 What Makes a Successful Project? Delivering: l agreed functionality l on time l at the agreed cost l with the required quality Stages: n set targets n attempt to achieve targets BUT what if the targets are not achievable?

4. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Over and Under-estimating nPnParkinson’s Law: ‘Work expands to fill the time available’ nAnAn over-estimate is likely to cause project to take longer than it would otherwise ( http://www.heretical.com/mis cella/parkinsl.html ) nWnWeinberg’s Zeroth Law of reliability: ‘a software project that does not have to meet a reliability requirement can meet any other requirement’ ( http://eppsnet.com/tag/jerry -weinberg )

5. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 A Taxonomy of Estimating Methods n Expert opinion - just guessing? n Bottom-up - activity based n Parametric e.g. function points n Analogy n Parkinson and ‘price to win’

6. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Estimation Techniques

7. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Heemstra and Kusters Survey n Expert judgement 25.5% n Analogy 60.8% n ‘Capacity problem’20.8% n Price-to-win8.9% n Parametric models13.7%

8. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Pricing to Win n The project costs whatever the customer has to spend on it. n Advantages: –You get the contract. n Disadvantages: –The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required.

9. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Heemstra and Kusters (cont.) n Only 50% kept project data on past projects - but 60.8% used analogy! n 35% did not produce estimates n 62% used methods based on intuition - only 16% used formalized methods n Function point users produced worse estimates!

10. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Top-down versus Bottom-up n Top-down –produce overall estimate based on project cost drivers –based on past project data n Bottom-up –use when no past project data

11. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Top-down Estimates n Produce overall estimate using effort driver(s) n distribute proportions of overall estimate to components designcode overall project test Estimate 100 days 30% i.e. 30 days 30% i.e. 30 days 40% i.e. 40 days

12. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Bottom-up Estimating 1. Break project into smaller and smaller components 2. Stop when you get to what one person can do in one/two weeks 3. Estimate costs for the lowest level activities 4. At each higher level calculate estimate by adding estimates for lower levels

13. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Parametric Models n COCOMO (lines of code) and function points examples of these problem with COCOMO etc: guess algorithmestimate but what is desired is system characteristic algorithm estimate

14. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Parametric Models (cont.) n Examples of system characteristics –no of screens x 4 hours –no of reports x 2 days –no of entity types x 2 days n the quantitative relationship between the input and output products of a process can be used as the basis of a parametric model

15. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Conventional Methods: LOC/FP Approach n Compute LOC/FP using estimates of information domain values Line of Code (LOC) Function Point (FP) n Use historical effort for the project

16. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Example: LOC Approach

17. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Example: FP Approach

18. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Parametric Models – the Need for Historical Data n simplistic model for an estimate estimated effort = (system size) / productivity n e.g. system size = lines of code productivity = lines of code per day n productivity = (system size) / effort –based on past projects

19. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Parametric models n Some models focus on task or system size e.g. Function Points n FPs originally used to estimate Lines of Code, rather than effort Number of file types model Numbers of input and output transaction types ‘system size’

20. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Parametric Models n Other models focus on productivity: e.g. COCOMO n Lines of code (or FPs etc.) an input System Size Productivity Factors Estimated Effort

21. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 System Size: Function Points n Based on work at IBM 1979 onwards –Albrecht and Gaffney wanted to measure the productivity independently of lines of code. –has now been developed by the International FP User Group (which is US based). –Mark II FPs developed by Simons mainly used in UK.

22. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Function points Mark II n Developed by Charles R. Symons n ‘Software sizing and estimating - Mk II FPA’, Wiley & Sons, 1991. n Builds on work by Albrecht n Work originally for CCTA(Consumer Credit Trade Association):Consumer Credit Trade Association –should be compatible with SSADM; mainly used in UK n has developed in parallel to IFPUG FPs IFPUG (International Function Point Users Group)

23. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Function Points Mk II (Cont.) n For each transaction, count –data items input (N i ) –data items output (N o) –entity types accessed (N e ) #entities accessed #input items #output items FP count = N i * 0.58 + N e * 1.66 + N o * 0.26

24. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Using Mark II Function Points n Calculate FPs for each transaction in a system n Total transaction counts to get a count for the system n Recall that estimated effort = size (FPs) x productivity rate (effort per FP) n Productivity rate obtained from past projects

25. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Estimating by Analogy source cases attribute values effort attribute values ????? target case attribute values effort Select case with closet attribute values Use effort from source as estimate

26. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Estimating by Analogy n Identify significant attributes (‘drivers’) n Locate closest match amongst source cases for target n Adjust for differences between source and target

27. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Stages: Identify n Significant features of the current project n Previous project(s) with similar features n Differences between the current and previous projects n Possible reasons for error (risk) n Measures to reduce uncertainty

28. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Some Conclusions: how to review estimates Ask the following questions about an estimate n What are the task size drivers? n What productivity rates have been used? n Is there an example of a previous project of about the same size? n Are there examples of where the productivity rates used have actually been found?

29. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 n Estimating the size of the measure (e.g. how many function points). n Estimating the total number of programmer months that have elapsed. n Estimating contractor productivity (e.g. documentation team) and incorporating this estimate in overall estimate. Measurement Problems

30. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 System Development Times

31. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 n Real-time embedded systems, 40-160 LOC/P-month. n Systems programs, 150-400 LOC/P-month. n Commercial applications, 200-900 LOC/P-month. n In object points, productivity has been measured between 4 and 50 object points/month depending on tool support and developer capability. Productivity Estimates

32. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Changing Technologies n Changing technologies may mean that previous estimating experience does not carry over to new systems –Distributed object systems rather than mainframe systems; –Use of web services; –Use of Enterprise Resource Planning (ERP) or database-centred systems; –Use of off-the-shelf software; –Development for and with reuse; –Development using scripting languages; –The use of CASE tools and program generators.

33. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Estimate uncertainty

34. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 The COCOMO Model n An empirical model based on project experience. n Well-documented, ‘independent’ model which is not tied to a specific software vendor. n Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. n COCOMO 2 takes into account different approaches to software development, reuse, etc.

35. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 COCOMO 81

36. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 COCOMO 2 n COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch. n Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development.

37. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 COCOMO 2 models n COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. n The sub-models in COCOMO 2 are: –Application composition model. Used when software is composed from existing parts. –Early design model. Used when requirements are available but design has not yet started. –Reuse model. Used to compute the effort of integrating reusable components. –Post-architecture model. Used once the system architecture has been designed and more information about the system is available.

38. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Use of COCOMO 2 Models

39. Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Application Composition Model n Supports prototyping projects and projects where there is extensive reuse. n Based on standard estimates of developer productivity in application (object) points/month. n Takes CASE tool use into account. n Formula is –PM = ( NAP  (1 - %reuse/100 ) ) / PROD –PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.