Cost Estimation

1. Cost Estimation • I've got Bad News and Bad News!

2. Cost Estimation • I've got Bad News and Bad News! • Accurate estimation of the cost to develop software projects is NEARLY IMPOSSIBLE.

3. Cost Estimation • I've got Bad News and Bad News! • Accurate estimation of the cost to develop software projects is NEARLY IMPOSSIBLE. • NEARLY EVERY project manager expects you to come up with an accurate estimate of cost.

4. Some Observations • The only time you can be 100% accurate in the cost of the project is after the project is completely finished.

5. Some Observations • The only time you can be 100% accurate in the cost of the project is after the project is completely finished. • Most software projects are never completely finished.

6. Some Observations • The only time you can be 100% accurate in the cost of the project is after the project is completely finished. • Most software projects are never completely finished. • Experience helps.

7. Cont. • If computer efficiency has increased multiple orders of magnitude, and size of memory has increased multiple orders of magnitude and disk space has increased multiple orders of magnitude and the object oriented paradigm has permitted software reuse, • WHY HASN'T THE COST OF DEVELOPING SOFTWARE DRAMATICALLY BEEN REDUCDE??

8. Some Answers • Software complexity has increased by many orders of magnitude. • Salaries continue to increase and most of the cost to develop software is people oriented.

9. Observations • A majority of the cost to develop software is the human effort involved. • So, cost estimation is really effort estimation. • It appears intuitive that the effort is proportional to the complexity of the project.

10. Cont. • Complexity is relative. It's not always related just to size. • A small project that is done by new software engineers unfamiliar with the company or the project is complex. • A large project that is done by experienced software engineers familiar with previous (almost identical) projects is not as complex.

11. So what to do??? • Begin day one to establish a history of your development effort at your company. • Keep records of the unexpected cost factors that come up. • Customer changes their mind about a functional requirement. • Environment changes (Windows NT -> Windows XP) • Additional functionality is requested. • Plan to become an expert in estimating your effort in software development.

12. Causes of Inaccurate Estimates • Frequent requests for changes by users. • Overlooked tasks • User's lack of understanding of their own requirements. • Insufficient analysis when developing an estimate (pressure to get it done NOW!). • Lack of coordination of systems development, technical services, operations, data administration, and other functions during development. • Lack of an adequate method or guidelines for estimating.

13. Aspects of the projectthat are key estimate influences • Complexity of the proposed application system. • Required integration with existing system. • Complexity of the programs in the system. • Size of the system expressed as number of functions or programs. • Capabilities of the project team members. • Project team's experience with the application.

14. Cont. • Anticipated frequency or extent of potential changes in user requirements. • Project team's experience with the programming language or hardware. • Database management system. • Number of project team members. • Extent of programming or documentation standards. • Availability or tools such as application generators. (Familiarity of the team)

15. Accuracy of Estimates • (Show overhead slide from Boehm.)

16. Estimation Techniques • Expert Judgement. • Algorithmic Methods. • Machine-Learning Methods.

17. Expert Judgement • The accuracy of the prediction is based on the competence, experience, objectivity, and perception of the estimator. • An “educated guess” • Based on a “top-down” or “bottom-up” analysis of what is needed. • Analogies are used to estimate effort.

18. Cont. • The analogy process can be formalized by asking several experts to make three predictions: • A pessimistic one (x). • A most likely guess (y). • An optimistic one (z). • Then these are combined as the mean of the beta probability distribution. • ( x + 4y + z ) / 6

19. Delphi • Experts are asked to make individual predictions secretly, based on their expertise and using whatever process they choose. • Then the average estimate is calculated and presented to the group. • Each expert has the opportunity to revise his or her estimate, if desired. • The process is repeated until no expert wants to revise.

20. Delphi cont. • Sometimes a discussion is allowed before the revised estimates are calculated. • Another variation is to allow the extreme estimators to make a case for their decisions anonymously.

21. Wolverton Model Cost Matrix

22. Other conflicts • Adding people to a late project simply makes it later. • Two people cannot produce code twice as fast as one person. • A model that may work for one organization may not apply to another. • Most expert judgement techniques are simplistic, neglecting a large number of factors So.......

23. Algorithmic Methods • Empirical models to express the relationship between effort and the factors that influence it. • Models are usually described using equations • E = (a + bS ) m(X) • S = estimated size of the system • a,b,c constants • X is a vector of cost factors, m is an adjustment multiplier based on X Ac

24. One of the firstby Walston and Felix • 0.91 • E = 5.25 S • For 60 projects ranging in size from 4000 to 467,000 lines of code, written in 28 different high-level languages on 66 computers and representing from 12 to 11,758 person-months of effort.