Software cost estimation
•
89 likes•39,507 views
Software Cost Estimation in Software Engineering
![Outline ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Software cost estimation
Similar to Software cost estimation (20)
More from Dr. C.V. Suresh Babu
More from Dr. C.V. Suresh Babu (20)
Recently uploaded
Recently uploaded (20)
Software cost estimation
Editor's Notes
- 1. Appropriate to talk about s/w cost after s/w size estimation because: Both are types of estimation Methods of cost estimation often require size estimates (e.g., COCOMO)
- No recent values but in most course taken there is the general consensus that values haven’t changed much Additional cost is significant
- There are finite amount of resources and so may not have enough for entire desired functionality What features can be included Reduce risk by scheduling costly tasks first Give more resources to costly projects (e.g., faster computers) 2. Similar to resource allocation - Assigning the more experienced personnel to costly projects/tasks - Sometimes called manpower loading – number of engineering and management personnel allocated to a project in a given amount of time
- 0. When is cost estimation done? - Do estimates at the beginning of a project after reqs have been clarified could be done several times - E.g., bidding on a job, initial estimate on preliminary reqs more detailed estimate afterwards The estimates should get progressively more accurate during the software life cycle - Helpful to have an automated method for re-estimating and collecting 2. - Appropriate level of detail is dependent upon situation - Monitoring shouldn’t be difficult otherwise it may not be done (automated, tools) 3. Of course, a company that does a lot of contract work must win bids and so the initial estimate method is very important
- The person responsible could be a developer or manager. Called analogy-based estimation Historical information is often from memory experienced people The analog approach is fairly common. 2. Some people believe that it is better to have the estimates done by outsiders so that there is less chance of biased estimates. - Fewer politics involved, an estimator who is a developer may have more reason to give a very optimistic estimate to please the manager (short-term) - Empirical methods will include equations - Use equations because don’t know organization and previous projects as well as someone inside the organization - No estimation model is appropriate for all classes of software, and in all development environments. Often, the estimation models need to be calibrated for local needs
- 0. Didn’t put numbers because there is some overlap in the sequence of the main points (not completely sequential) 3. Important to use more than one method
- The Intermediate Model estimates the software development effort by using fifteen cost driver variables besides the size variable used in Basic COCOMO. Product Attributes RELY: Required Software Reliability The extent to which the software product must perform its intended functions satisfactorily over a period of time. DATA: Data Base Size The degree of the total amount of data to be assembled for the data base. CPLX: Software Product Complexity The level of complexity of the product to be developed. Computer Attributes TIME --- Execution Time Constraint The degree of the execution constraint imposed upon a software product. STOR --- Main Storage Constraint The degree of main storage constraint imposed upon a software product. VIRT --- Virtual Machine Volatility The level of the virtual machine underlying the product to be developed. TURN --- Computer Turnaround Time The level of computer response time experienced by the project team developing the product. Personnel Attributes ACAP: Analyst Capability The level of capability of the analysts working on a software product. AEXP: Applications Experience The level of applications experience of the project team developing the software product. PCAP: Programmer Capability The level of capability of the programmers working on the software product. VEXP: Virtual Machine Experience The level of virtual machine experience of the project team developing the product. LEXP: Programming Language Experience The level of programming language experience of the project team developing the product. Project Attributes MODP: Use of Modern Programming Practices The degree to which modern programming practices (MPPs) are used in developing software product. TOOL: Use of Software Tools The degree to which software tools are used in developing the software product. SCED: Schedule Constraint The level of schedule constraint imposed upon the project team developing the software product.
- The Application Composition Model Suitable for projects built with modern GUI-builder tools. Based on new Object Points. The Early Design Model You can use this model to get rough estimates of a project's cost and duration before you've determined it's entire architecture. It uses a small set of new Cost Drivers, and new estimating equations. Based on Unadjusted Function Points or KSLOC. The Post-Architecture Model This is the most detailed COCOMO II model. You'll use it after you've developed your project's overall architecture. It has new cost drivers, new line counting rules, and new equations.
- 9. Does COCOMO II replace traditional COCOMO? You should use COCOMO II for most of your new projects. COCOMO 81 is still the best approach for some software projects. If you're using a fairly traditional approach, and using a 3GL (third generation language), such as C, Fortran, or Cobol, the original COCOMO will give you good results. If your development tools and processes haven't changed much in recent years, COCOMO 81 might be the right model for you. If you're using more modern tools, a new development process model, a 4GL language, or tools like Visual Basic, Delphi, or Power Builder, you might find that COCOMO II makes more sense. When in doubt, try to model your project using both the traditional COCOMO and COCOMO II.
- How many of you see cost estimation done in your organizations? What types of experiences have you had with COCOMO?