1 / 19

Cost Estimation

Cost Estimation. Problem. Our ability to realistically plan and schedule projects depends on our ability to estimate project costs and development efforts In order to come up with a reliable cost estimate, we need to have a firm grasp on the requirements, as well as our approach to meeting them

alvis
Télécharger la présentation

Cost Estimation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cost Estimation

  2. Problem • Our ability to realistically plan and schedule projects depends on our ability to estimate project costs and development efforts • In order to come up with a reliable cost estimate, we need to have a firm grasp on the requirements, as well as our approach to meeting them • Typically costs need to be estimated before these are fully understood

  3. Estimating uncertainty Boehm 1981

  4. What are project costs? • For most software projects, costs are: • Hardware Costs • Travel & Training costs • Effort costs

  5. What are effort costs? • Effort costs typically largest of the 3 types of costs, and the most difficult to estimate. • Effort costs include: • Developer hours • Heating, power, space • Support staff; accountants, administrators, cleaners, management • Networking and communication infrastructure • Central facilities such as rec room & library • Social security and employee benefits

  6. Effort cost estimation - Overhead • Everything other than salaries • OSU example: • 45% for benefits • 46% for “indirect” costs (space, infrastructure etc) calculated on top of everything else $1,000 +benefits ($450) + infrastructure ($667) = $2,117

  7. Software cost estimation – Boehm (1981) • Algorithmic cost modeling • Base estimate on project size (lines of code) • Expert judgment • Ask others • Estimation by analogy • Cost based on experience with similar projects • Parkinson’s Law • Project time will expand to fill time available • Pricing to win • Cost will be whatever customer is willing to pay • Top-down estimation • Estimation based on function/object points • Bottom-up estimation • Estimation based on components

  8. Aggravating & mitigating factors • Market opportunity • Uncertainty/risks • Contractual terms • Requirements volatility • Financial health • Opportunity costs

  9. Cost drivers • Software reliability • Size of application database • Complexity • Analyst capability • Software engineering capability • Applications experience • Virtual machine experience • Programming language expertise • Performance requirements • Memory constraints • Volatility of virtual machine • Environment • Turnaround time • Use of software tools • Application of software engineering methods • Required development schedule

  10. Productivity metrics • Lines of code • Simple, but not very meaningful metric • Easy to pad, affected by prog language • How to count revisions/debugging etc? • Function points • Amount of useful code produced (goals/requirements met) • Less volatile, more meaningful, not perfect

  11. Function points Function points are computed by first calculating an unadjusted function point count (UFC). Counts are made for the following categories (Fenton, 1997): • External inputs – those items provided by the user that describe distinct application-oriented data (such as file names and menu selections) • External outputs – those items provided to the user that generate distinct application-oriented data (such as reports and messages, rather than the individual components of these) • External inquiries – interactive inputs requiring a response • External files – machine-readable interfaces to other systems • Internal files – logical master files in the system Each of these is then assessed for complexity and given a weighting from 3 (for simple external inputs) to 15 (for complex internal files).

  12. Unadjusted Function Point Count (UFC) Each count is multiplied by its corresponding complexity weight and the results are summed to provide the UFC

  13. Object points Similar to function points (used to estimate projects based heavily on reuse, scripting and adaptation of existing tools) • Number of screens (simple x1, complex x2, difficult x3) • Number of reports (simple x2, complex x5, difficult x8) • Number of custom modules written in languages like Java/C x10

  14. Function points -> Lines of code 200-300 LOC/Function point in assembly Multiplication factor by language Programmer productivity? 30-900 LOC/month!

  15. COCOMO II Model • Supports spiral model of development • Supports component composition, reuse, customization • 4 sub-models: • Application composition model – assumes system written with components, used for prototypes, development using scripts, db’s etc (object points) • Early design model – After requirements, used during early stages of design (function points) • Reuse model – Integrating and adapting reusable components (LOC) • Post architecture model – More accurate method, once architecture has been designed (LOC)

  16. Application composition model Used primarily to estimate cost of prototyping efforts PM = (Application points x(1-%reuse/100)/ productivity Productivity estimates from 4-50 object points/month, depending on experience and the availability/maturity of tools

  17. Early Design Model Used once requirements are agreed to get going on an architectural design PM=2.94 x Size^B x M B=1.05-1.20 M=Proj characteristics

  18. Reuse model • PM = (LOC needing to be adjusted X % auto-generated)/productivity Productivity ~ 2,400 LOC/Month

  19. Post-Architectural Model • Organic projects - relatively small, simple projects with small teams and good application experience to less than rigid requirements. (A=2.4, B=1.05) • Semi-detached projects - intermediate (in size and complexity) projects with mixed experience teams and a mix of requirements. (A=3.0, B=1.12) • Embedded projects - software projects that must be developed within a set of tight hardware, software, and operational constraints. (A=3.6, B=1.20) PM=A x Size^B x M

More Related