Chapter 5 Software effort estimation NET 481 Project

Chapter 5: Software effort estimation NET 481: Project Management Afnan Albahli S

Topics to be covered S Difficulties of Estimation S Where are estimates done? S Problems of over- and under- estimate S Estimation techniques 2 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

What makes a successful project? Delivering: l agreed functionality l on time Stages: 1. set targets 2. Attempt to achieve targets l at the agreed cost l with the required quality BUT what if the targets are not achievable? 3 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

What makes a successful project? S Targets are set for a project and the project manager tries to meet them S A project manager has to produce S An estimate of the effort S An estimate of the activity durations S An estimate of S effort affects Cost S An estimate of S affects activity durations 4 The delivery time

Some problems with estimating S Nature of software S Complexity and invisibility of software S Subjective nature of much of estimating S Over-estimating small tasks and S Under-estimating large ones S Political pressures S Different objectives of people in an organization S Managers may wish to reduce estimated costs in order to win support for acceptance of a project proposal 5 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Some problems with estimating S Changing technologies S Technology is rapidly changing aking the experience of previousroject estimates difficult to use in new ones S Projects differ S Experience on one project may not be applicable to another S 6 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Where are estimates done Estimates are carried out at different stages of a software project for a variety of reasons S Feasibility study S Estimates here conforms that the benefits of the potential system will justify the costs S Strategic planning S Project portfolio management will involve S (Estimating benefits and costs of new applications rojects o allocate priorities. S Such estimates may also influence the scale of development staff recruitment 7 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

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

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

Where are estimates done S Project planning S becomes As the planning and implementation of the project more detailed S mad More estimates of smaller work components will be S These will confirm earlier broad estimates S allocation (And support more detailed planning. g taff 10 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Over- and under- estimating S An over-estimate is likely to cause project to take longer than it would otherwise S This can be explained by the application of two laws S Parkinson’s Law: ‘Work expands to fill the time available’ S Thus. g or an easy task over estimating the duration required to complete it will cause some staff to work less hard to fill the time S Brook’s Lawutting late more people on a late job makes it S So overestimating the effort required to perform a task (ctivity eans more staff assigned to it than needed 11 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Over- and under- estimating S Underestimating Can cause the project a project to not be delivered on time or cost S but still could be delivered faster than a more generous estimate S On the other side the danger of underestimating a project is the effect on the quality S Zeroth law of reliability: f a system doesn't have to be reliable it can meet any other objective S 12 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Basis for successful estimating A. The need for historical data S Most estimating methods need information about past projects Care has to be considered when applying past performance to new projects differences in factors because such ofas possible S S Different programming languages S Different experience of staff S Different terminology There are international Data Base containing data about thousands of projects that can be used as reference 13 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Basis for successful estimating B. Measuring work S The time and cost to implement software depends on S The developer’s capability and experience S The technology that will be used S The usual practice is to start by expressing work size independently of the effort using measures such as () SLOC OR KLOC ource lines of code or thousands of lines of code (() Alternative size measure is Function Points P 14 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

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

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

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 17 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Top-down Estimation S It is associated with parametric or algorithmic models S A formula for a parametric model S Effort =* ( ystem Size roductivity Rate S The model of forecasting the SW development effort has two components S System wor size is a method of assessing the amount of S work Productivity a rate is a method of assessing the rate of which the task can be done 18 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Top-down Estimation S Example: System Size LOC = Productivity Rate 0 ays per KLOC = =* ( Effort ystem Size Effort = 0 20 ays roductivity Rate System Size is a size driver Productivity Rate is a productivity driver 19 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Top-down Estimation S Other parametric models S Function points is concerned more with task sizes S COCOMO is concerned more with productivity rate 20 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Top-down estimates overall project Estimate 100 days S Produce overall estimate using effort driver(s) S distribute proportions design code test 30% i. e. 30 days 40% i. e. 40 days of overall estimate to components SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009 21

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

Estimation by Analogy S There are software tools that automate this process by selecting the nearest project cases to the new project S Some software tools perform that by measuring the S (Euclidean distance between cases rojects S The Euclidean distance is calculated as follows distance quare-root of arget_parameter 1 -source_parameter 1)2 …. (( + (arget_parametern -ource_parametern )2 23 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Estimation by Analogy Exampl S Assume that cases are matched on the basis of two parameters he number of inputs and the number of outputs • outpu (The new project arget case equires 7 nputs and 15 • (You are looking into two past cases ource cases o find a better analogy with the target project • • Project A as 8 nputs and 17 utputs Project B as 5 nputs and 10 utputs Which is a more closer match for the new project A or project B 24 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Answer S Distance between new project and project A S = Square-root (( + ( of -8 5 -17 . 24 S Distance between new project and project B S = Square-root (( + ( of -5 5 -10. 39 Project A is a better match because it has less distance than project B to the new project 25 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009