Chapter 5 -Software cost estimate- ref.pptx

SPM

1. SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 1 Software Project Management Unit 2_III Chapter Five Software effort estimation

2. “Any fool can know….. The point is to understand…..” — Albert Einstein

3. SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 3 What makes a successful project? Delivering: agreed functionality on time at the agreed cost with the required quality Stages: Set targets Attempt to achieve targets BUT what if the targets are not achievable?

4. Wha t make s a successfu l project? Targets are set for a project and the project manager tries to meet them A project manager has to produce: An estimate of the effort. An estimate of the activity durations. An estimate of efforts affects Cost An estimate of activity duration affects The delivery time 4

5. SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 5 Some problems with estimating Subjective nature of much of estimating It may be difficult to produce evidence to support your precise target Political pressures Managers may wish to reduce estimated costs in order to win support for acceptance of a project proposal Changing technologies these bring uncertainties, especially in the early days when there is a ‘learning curve’ Projects differ Experience on one project may not be applicable to another

6. Where are estimates done? Estimate s ar e carried ou t a t differen t stages o f a software project for a variety of reasons. Feasibility study Estimates here conforms that the benefits of the potential system will justify the costs Strategic planning Project portfolio management will involve: Estimating benefits and costs of new applications (projects) to allocate priorities . Such estimates may also influence the scale of developmen t st a S f P f M r ( 5 e e) c S o r ft w u a r i e t e m 6 ffor t e es t n im a t tion © The McGraw-Hill Companies, 2009

7. Where are estimates done? SPM (5e) Software e 7 ffort estimation© The McGraw-Hill Companies, 2009 System specification Design shows how user requirements will be fulfilled. Estimating The efforts needed to implement different design proposals. Estimates at the design stage will also confirm that the feasibility study is still valid

8. Where are estimates done? SPM (5e) Software e 8 ffort estimation© The McGraw-Hill Companies, 2009 □ Evaluation of suppliers proposals □ A manager could consider putting development to tender □ Potential contractors would examine the system specifications and produce estimates (their bid). The manager can still produce his own estimates why? To question a bid that for instance that seems too low which could be an indication of a bad understanding of the system specifications. Or to compare the bids to in-house development

9. Where are estimates done? allocation) SPM (5e) Software e 9 ffort estimation© The McGraw-Hill Companies, 2009 Project planning As the planning and implementation of the project becomes more detailed More estimates of smaller work components will be made These will confirm earlier broad estimates And support more detailed planning (e.g. staff

10. Accept yourself, love yourself, And keep moving forward….. If you want to fly…. you have to give up wha t weigh s you down. 10 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

11. Over- and under- SP M (5e) Softwar e e 1 ffor t estimation © The McGraw-Hill C 1 ompanies , 2009 estimating □ An over-estimate is likely to cause project to take longer than it would otherwise This can be explained by the application of two laws: Parkinson’s Law: □ ‘Work expands to fill the time available’ Thus, e.g. for an easy task over estimating the duration required to complete it will cause some staff to work less hard to fill the time. Brook’s Law: putting more people on a late job makes it later □ So overestimating the effort required to perform a task (activity) means more staff assigned to it than needed

12. Over- and under- estimating SP M (5e) Softwar e e 1 ffor t estimation © The McGraw-Hill C 2 ompanies , 2009 Underestimating a project: Can cause the project to not be delivered on time or cost but still could be delivered faster than a more generous estimate On the other side the danger of underestimating a project is the effect on the quality □ Zeroth law of reliability : if a system doesn't have to be reliable it can meet any other objective

13. SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 13 Over and under-estimating Parkinson’s Law: ‘Work expands to fill the time available’ An over-estimate is likely to cause project to take longer than it would otherwise Weinberg’s Zeroth Law of reliability : ‘a software project that does not have to meet a reliability requirement can meet any other requirement’

14. Basis for successful estimating McGraw-Hill C 4 ompanies , 2009 The need for historical data . Most estimating methods need information about past projects Care has to be considered when applying past performance to new projects because of possible differences in factors such as: Different programming languages Different experience of staff Different terminology □ There are international Data Base containing data about thousands of projects that can be used as reference SP M (5e) Softwar e e 1 ffor t estimation © The

15. Measuring work. The time and cost to implement software depends on: The developer’s capability and experience The technology that will be used The usual practice is to start by expressing work size independently of the effort, using measures such as: □ LOC OR KLOC: Source lines of code or thousands of lines of code McGraw-Hill C 5 ompanies , 2009 Altern a S t i P v M e (5e ) s S o i z ft w e ar e m e 1 ffo r e t e a sti m s a u ti o r n © e T h i s e □ Function Points (FP) Basis for successful estimating

16. Basis for successful estimating 16 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Information about past projects □ Need to collect performance details about past project: how big were they? How much effort/time did they need? Need to be able to measure the amount of work involved Traditional size measurement for software is ‘lines of code’ – but this can have problems

17. A taxonomy of estimating methods 17 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Bottom-up - activity based, analytical Parametric or algorithmic models e.g. function points Expert opinion - just guessing? Analogy - case-based, comparative Parkinson and ‘price to win’

18. Th e greatest enem y of knowledge is not ignorance…… 18 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 it is the…. illusion of knowledge

19. Parameters to be Estimated 19 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Size is a fundamental measure of work Based on the estimated size, two parameters are estimated: Effort Duration Effort is measured in person-months : One person-month is the effort an individual can typically put in a month.

20. Person-Month 20 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Suppose a project is estimated to take 300 person-months to develop: Is one person working for 30 days same as 30 persons working for 1 day? Yes/No? why? How many hours is a man month? Default Value: 152 hours per month 19 days at 8 hours per day.

21. Mythical Man-Month 21 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 “Cost varies as product of men and months, progress does not.” Hence the man-month as a unit for measuring the size of job is a dangerous and deceptive myth. The myth of additional manpower Brooks Law: “Adding manpower to a late project makes it later”

22. Knowin g yoursel f i s th e beginning o f al l wisdom.” - - Aristotle

23. Measure of Work 23 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 The project size is a measure of the problem complexity in terms of the effort and time required to develop the product. Two metrics are used to measure project size: Source Lines of Code (SLOC) Function point (FP) FP is now-a-days favoured over SLOC: Because of the many shortcomings of SLOC.

24. Major Shortcomings of SLOC 24 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Difficult to estimate at start of a project Only a code measure Programmer-dependent Does not consider code complexity

25. Bottom-up versus top-down 25 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Bottom-up use when no past project data identify all tasks that have to be done – so quite time-consuming use when you have no data about similar past projects Top-down produce overall estimate based on project cost drivers based on past project data divide overall estimate between jobs to be done

26. Bottom-up estimating 26 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Break project into smaller and smaller components- Work breakdown structure Stop when you get to what one person can do in one/two weeks Estimate costs for the lowest level activities At each higher level calculate estimate by adding estimates for lower levels

27. Top-down estimates Produce overall estimate using effort driver(s) distribute proportions of overall estimate to components desig n code overal l projec t test Estimate 27 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 100 days 30% i.e. 30 days 30% i.e. 30 days 40% i.e. 40 days

28. Algorithmic/Parametric models COCOMO (lines of code) and function points examples of these Problem with COCOMO etc: guess algorithm estimate but what is desired is system characteristi c algorithm estimate 28 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

29. Parametric models - the need for historical data 29 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 simplistic model for an estimate estimated effort = (system size) / productivity e.g. system size = lines of code productivity = lines of code per day productivity = (system size) / effort based on past projects

30. Parametric models model Some models focus on task or system size e.g. Function Points FPs originally used to estimate Lines of Code, rather than effort Number of file types Numbers of input and output transaction types ‘ system size’ 30 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

31. Parametric models Other models focus on productivity: e.g. COCOMO Lines of code (or FPs etc) an input System size Productivity factors Estimated effort 31 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

32. Sometime s th e questions are complicated and the answers are simple… 32 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

33. Expert judgement 33 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Asking someone who is familiar with and knowledgeable about the application area and the technologies to provide an estimate Particularly appropriate where existing code is to be modified Research shows that experts judgement in practice tends to be based on analogy

34. Estimation by Analogy 34 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 It is also called case-based reasoning. For a new project the estimator identifies the previous completed projects that have similar characteristics to it. The new project is referred to as the target project or target case The completed projects are referred to as the source projects or source case The effort recorded for the matching source case is used as the base estimate for the target project The estimator calculates an estimate for the new project by adjusting the (base estimate) based on the differences that exist between the two projects

35. Estimation by Analogy 35 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 There are software tools that automate this process by selecting the nearest project cases to the new project. Some software tools perform that by measuring the Euclidean distance between cases (projects). The Euclidean distance is calculated as follows: distance= square-root of ((target_parameter -source_parameter ) 2 …. + 1 1 2 (target_parameter n -source_parameter n ) )

36. Estimation by Analogy Example 36 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Assume that cases are matched on the basis of two parameters, the number of inputs and the number of outputs . The new project (target case) requires 7 inputs and 15 output You are looking into two past cases (source cases) to find a better analogy with the target project: Project A: has 8 inputs and 17 outputs. Project B: has 5 inputs and 10 outputs. Which is a more closer match for the new project A or project B?

37. Stages: identify 37 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Significant features of the current project previous project(s) with similar features differences between the current and previous projects possible reasons for error (risk) measures to reduce uncertainty

38. Parametric models 38 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 We are now looking more closely at four parametric models: Albrecht/IFPUG function points Symons/Mark II function points COSMIC function points COCOMO81 and COCOMO II *FPUG (Function point users’ Group)

39. Albrecht/IFPUG function points 39 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Albrecht worked at IBM and needed a way of measuring the relative productivity of different programming languages. Needed some way of measuring the size of an application without counting lines of code. Identified five types of component or functionality in an information system Counted occurrences of each type of functionality in order to get an indication of the size of an information system

40. Logic will get you from A to B….. Imagination will take you everywhere…. – Albert Einstein 40 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

41. Albrecht/IFPUG function points - continued 41 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Five function types Logical interface file (LIF) types – equates roughly to a data store in systems analysis terms. Created and accessed by the target system External interface file types (EIF) – where data is retrieved from a data store which is actually maintained by a different application.

42. Albrecht/IFPUG function points - continued 42 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 External input (EI) types – input transactions which update internal computer files External output (EO) types – transactions which extract and display data from internal computer files. Generally involves creating reports. External inquiry (EQ) types – user initiated transactions which provide information but do not update computer files. Normally the user inputs some data that guides the system to the information the user needs.

43. Albrecht complexity multipliers 43 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 External user types Low complexity Medium complexity High complexity EI 3 4 6 EO 4 5 7 EQ 3 4 6 LIF 7 10 15 EIF 5 7 10

44. Examples 44 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Payroll application has: Transaction to input, amend and delete employee details – an EI that is rated of medium complexity A transaction that calculates pay details from timesheet data that is input – an EI of high complexity A transaction of medium complexity that prints out pay-to-date details for each employee – EO A file of payroll details for each employee – assessed as of medium complexity LIF A personnel file maintained by another system is accessed for name and address details – a simple EIF What would be the FP counts for these?

45. FP counts 45 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Medium EI High complexity EI 4 FPs 6 FPs Medium complexity EO Medium complexity LIF 5 FPs 10 FPs Simple EIF Total 5 FPs 30 FPs If previous projects delivered 5 FPs a day, implementing the above should take 30/5 = 6 days

46. 46 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

47. Function points Mark II 47 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Developed by Charles R. Symons ‘Software sizing and estimating - Mk II FPA’, Wiley & Sons, 1991. Builds on work by Albrecht Work originally for CCTA (central computer and Telecommunication Agency): should be compatible with SSADM; mainly used in UK has developed in parallel to IFPUG FPs A simpler method

48. Function points Mk II continued For each transaction, count data items input (N i ) data items output (N o) entity types accessed (N e ) #entities accessed 48 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 #input items #output items FP count = N i * 0.58 + N e * 1.66 + N o * 0.26

49. Function points for embedded systems 49 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Mark II function points , IFPUG function points were designed for information systems environments COSMIC (acronym of Common Software Measurement International consortium) FPs attempt to extend concept to embedded systems Embedded software seen as being in a particular ‘layer’ in the system Communicates with other layers and also other components at same level

50. Layered software Higher layers Lower layers peer component Makes a request for a service Receives service Receives request Supplies service Peer to peer communication Persistent Software component storage Data reads/ 50 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 writes

51. COSMIC FPs 51 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 The following are counted: Entries: movement of data into software component from a higher layer or a peer component Exits: movements of data out Reads: data movement from persistent storage Writes: data movement to persistent storage Each counts as 1 ‘COSMIC functional size unit’ (Cfsu)

52. The COCOMO constants 52 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 System type c k Organic (broadly, information systems) 2.4 1.05 Semi-detached 3.0 1.12 Embedded (broadly, real-time) 3.6 1.20 k exponentiation – ‘to the power of…’ adds disproportionately more effort to the larger projects takes account of bigger management overheads

53. 53 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

54. Development effort multipliers (dem) 54 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 According to COCOMO, the major productivity drivers include: Product attributes : required reliability, database size, product complexity Computer attributes : execution time constraints, storage constraints, virtual machine (VM) volatility Personnel attributes : analyst capability, application experience, VM experience, programming language experience Project attributes : modern programming practices, software tools, schedule constraints

55. Major Changes in Program Development Practices Software reuse Application generation of programs Object oriented approaches Need for rapid development Agile models 55 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

56. Constructive Cost Model II (COCOMO II) Software Project Management 56 A parametric cost model Important aspects of software projects are characterized by variables (or parameters) Once the value of the parameters are determined, the cost can be computed from an equation

57. COCOMO II (cont’d) Software Project Management 57 Recognizes different approaches to software development Prototyping, Incremental development etc.

58. A history of COCOMOs Software Project Management 58 COCOMO originally proposed by Boehm in 1981, now called COCOMO 81 Later evolved to Ada COCOMO in 1989 In 1995, Boehm proposed COCOMO II

59. COCOMO II Software Project Management 59 A family of models Uses different models in 3 different stages of the project 3 stages: application composition, early design and post architecture Supports estimation early in the process Allows further detailed estimation after the system architecture has been defined

60. COCOMO II Models COCOMO 2 incorporates a range of sub-models: Produces increasingly accurate estimates. The 4 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. SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 60

61. Software Project Management 61 COCOMO II (cont’d) The basic model equation Effort = Constant × (Size) scale factor × Effort Multiplier Effort in terms of person-months Constant: 2.45 in 1998 Size: Estimated Size in KSLOC Scale Factor: combined process factors Effort Multiplier (EM): combined effort factors

62. SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 62 COCOMO II An updated version of COCOMO: There are different COCOMO II models for estimating at the ‘early design’ stage and the ‘post architecture’ stage when the final system is implemented. We’ll look specifically at the first. The core model is: pm = A(size) (sf) ×(em ) ×(em ) ×(em )…. 1 2 3 where pm = person months, A is 2.94, size is number of thousands of lines of code, sf is the scale factor, and em i is an effort multiplier

63. The Application Composition Stage Software Project Management 63 Estimation at the early stage Corresponding to exploratory work such as prototyping Uses object points to estimate the size of the product

64. The Early Design Stage Software Project Management 64 Estimate after the requirements specification is completed and possibly with some design Use the basic model equation Estimate the size by FPs (preferred) or KSLOC Estimate scale factor and effort multiplier

65. The Early Design Stage – Scale Factor Software Project Management 65 Estimation of the scale factor A combined effect of 5 parameters Application precedentedness Process flexibility Architecture risk resolution Team cohesion Process maturity

66. Software Project Management The Early Design Stage – Scale Factor (cont’d) Parameter Very Low (0.05) Low (0.04) Nominal (0.03) High (0.02) Very High (0.01) Extra High (0.00) Precedentedness Thoroughly unprecedented Largely unprecedented Somewhat unprecedented Generally familiar Largely familiar Thoroughly familiar Development flexibility Rigorous Occasional relaxation Some relaxation General conformity Some conformity General goals Architecture risk resolution Little 20% Some 40% Often 60% Generally 75% Mostly 90% Full 100% Team cohesion Very difficult interactions Some difficult interactions Basically cooperative Largely cooperative Highly Cooperative Seamless interactions Process maturity Level 1 Level 2 Level 2+ Level 3 Level 4 Level 5

67. The Early Design Stage – Scale Factor (Cont’d) Software Project Management 67 Calculate the scale factor based on the equation Scale factor = 1.01 + sum of the values (* The range of process exponent is from 1.01 to 1.26.) The smaller is the number, the less extra effort is needed. Thus, an ideal team will have the ideal process exponent value (1.01).

68. The Early Design Stage – Effort Multiplier Software Project Management 68 7 factors in Effort Multiplier product Reliability and ComPleXity (RCPX) required reusability (RUSE) Platform DIFficulty (PDIF) PERSonnel capability (PERS) PeRsonnel EXperience (PREX) FaCILities available (FCIL) SChEDule pressure (SCED)

69. COCOMO II (cont’d) Software Project Management 69 Advantages Good improvement over COCOMO Good match for iterative development, modern technology, and management process Disadvantages Still immature, diverse projects in database Hard to believe that it will be any more reliable than the original COCOMO model

70. Staffing Norden was one of the first to investigate staffing pattern: Considered general research and development (R&D) type of projects. Norden concluded: Staffing pattern for any R&D project can be approximated by the Rayleigh distribution curve SPM (6e) Software effort estimation© The 70 Manpower McGraw-Hill Companies, 2017 T D Time

71. Boehm’s Result McGraw-Hill Companies, 2017 There is a limit beyond which a software project cannot reduce its schedule by buying any more personnel or equipment. This limit occurs roughly at 75% of the nominal time estimate for small and medium sized projects SPM (6e) Software effort estimation© The

72. 72 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017

73. Capers Jones’ Estimating Rules of Thumb 73 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Empirical rules: Formulated based on observations No scientific basis Because of their simplicity,: These rules are handy to use for making off-hand estimates. Give an insight into many aspects of a project for which no formal methodologies exist yet.

74. Capers Jones’ Rules 74 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Rule 1: SLOC-function point equivalence: One function point = 125 SLOC for C programs. Rule 2: Project duration estimation: Function points raised to the power 0.4 predicts the approximate development time in calendar months. Rule 3: Rate of requirements creep: User requirements creep in at an average rate of 2% per month from the design through coding phases.

75. Capers Jones’ Rules SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Rule 4: Defect removal efficiency: Each software review, inspection, or test step will find and remove 30% of the bugs that are present. Rule 5: Project manpower estimation: The size of the software (in function points) divided by 150 predicts the approximate number of personnel required for developing the application.

76. Capers’ Jones Rules SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Rule 6: Number of personnel for maintenance Function points divided by 500 predicts the approximate number of personnel required for regular maintenance activities. Rule 7: Software development effort estimation: The approximate number of staff months of effort required to develop a software is given by the software development time multiplied with the number of personnel required.

77. Some conclusions: how to review estimates 77 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017 Ask the following questions about an estimate What are the task size drivers? What productivity rates have been used? Is there an example of a previous project of about the same size? Are there examples of where the productivity rates used have actually been found?

78. End of Unit 2 78 SPM (6e) Software effort estimation© The McGraw-Hill Companies, 2017