Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this


  2. 2. Project Estimation and scheduling Outline: Estimation overview Detailed schedule/planning terminology and processes
  3. 3. Estimation“The single most important task of aproject: setting realistic expectations.Unrealistic expectations based oninaccurate estimates are the singlelargest cause of software failure.”
  4. 4. Why its important to you! Program development of large software systemsnormally experience 200-300%cost overruns and a 100% schedule slip 15% of large projects deliver…NOTHING! Key reasons…poor management and inaccurateestimations of development cost and schedule If not meeting schedules, developers often pay theprice!
  5. 5. The Problems Predicting software cost Predicting software schedule Controlling software risk Managing/tracking project as it progresses
  6. 6. Fundamental estimationquestions How much effort is required to complete an activity? How much calendar time is needed to complete anactivity? What is the total cost of an activity? Project estimation and scheduling are interleavedmanagement activities.
  7. 7. Software cost components Hardware and software costs. Travel and training costs. Effort costs (the dominant factor in mostprojects) The salaries of engineers involved in the project; Social and insurance costs. Effort costs must take overheads into account Costs of building, heating, lighting. Costs of networking and communications. Costs of shared facilities (e.g library, staff restaurant,etc.).
  8. 8. Costing and pricing Estimates are made to discover the cost, to the developer,of producing a software system. There is not a simple relationship between thedevelopment cost and the price charged to the customer. Broader organisational, economic, political and businessconsiderations influence the price charged.
  9. 9. Software pricing factorsMarketopportunityA development organisation may quote a low price because itwishes to move into a new segment of the software market.Accepting a low profit on one project may give the opportunityof more profit later. The experience gained may allow newproducts to be developed.Cost estimateuncertaintyIf an organisation is unsure of its cost estimate, it may increaseits price by some contingency over and above its normal profit.Contractual terms A c ustomer may be willing to allow the developer to retainownership of the source code and reuse it in other projects. Theprice charged may then be less than if the software source codeis handed over to the customer.RequirementsvolatilityIf the requirements are likely to change, an organisation maylower its price to win a contract. After the contract is awarded,high prices can be charged for changes to the requirements.Financial health Developers in financial difficulty may lower their price to gaina contract. It is better to make a sm aller than normal profit orbreak even than to go out of business.
  10. 10. Nature of Estimates Man Months (or Person Months), defined as 152 man-hours of direct-charged labor Schedule in months (requirements complete toacceptance) Well-managed program
  11. 11. 4 Common (subjective)estimation models Expert Judgment Analogy Parkinson’s law Price to win
  12. 12. Expert judgment One or more experts in both software development andthe application domain use their experience to predictsoftware costs. Process iterates until some consensus isreached. Advantages: Relatively cheap estimation method. Can beaccurate if experts have direct experience of similarsystems Disadvantages: Very inaccurate if there are no experts!
  13. 13. Estimation by analogy The cost of a project is computed by comparing the projectto a similar project in the same application domain Advantages: May be accurate if project data available andpeople/tools the same Disadvantages: Impossible if no comparable project hasbeen tackled. Needs systematically maintained costdatabase
  14. 14. Parkinsons Law The project costs whatever resources are available Advantages: No overspend Disadvantages: System is usually unfinished
  15. 15. Cost Pricing to win The project costs whatever the customer has to spend onit Advantages: You get the contract Disadvantages: The probability that the customer gets thesystem he or she wants is small. Costs do not accuratelyreflect the work required. How do you know what customer has? Only a good strategy if you are willing to take a serious lossto get a first customer, or if Delivery of a radically reducedproduct is a real option.
  16. 16. Top-down and bottom-up estimation Any of these approaches may be used top-down orbottom-up. Top-down Start at the system level and assess the overall systemfunctionality and how this is delivered through sub-systems. Bottom-up Start at the component level and estimate the effortrequired for each component. Add these efforts to reacha final estimate.
  17. 17. Top-down estimation Usable without knowledge of the system architecture andthe components that might be part of the system. Takes into account costs such as integration, configurationmanagement and documentation. Can underestimate the cost of solving difficult low-leveltechnical problems.
  18. 18. Bottom-up estimation Usable when the architecture of the system is known andcomponents identified. This can be an accurate method if the system has beendesigned in detail. It may underestimate the costs of system level activitiessuch as integration and documentation.
  19. 19. Estimation methods Each method has strengths and weaknesses. Estimation should be based on several methods. If these do not return approximately the same result,then you have insufficient information available to makean estimate. Some action should be taken to find out more in order tomake more accurate estimates. Pricing to win is sometimes the only applicable method.
  20. 20. Pricing to win This approach may seem unethical and un-businesslike. However, when detailed information is lacking it may bethe only appropriate strategy. The project cost is agreed on the basis of an outlineproposal and the development is constrained by thatcost. A detailed specification may be negotiated or anevolutionary approach used for system development.
  21. 21. Algorithmic cost modeling Cost is estimated as a mathematical function of product,project and process attributes whose values are estimatedby project managers The function is derived from a study of historical costingdata Most commonly used product attribute for costestimation is LOC (code size) Most models are basically similar but with differentattribute values
  22. 22. Criteria for a Good Model Defined—clear what is estimated Accurate Objective—avoids subjective factors Results understandable Detailed Stable—second order relationships Right Scope Easy to Use Causal—future data not required Parsimonious—everything present is important
  23. 23.  A measure of the rate at which individualengineers involved in software developmentproduce software and associateddocumentation. Not quality-oriented although quality assurance is a factorin productivity assessment. Essentially, we want to measure usefulfunctionality produced per time unit.Software productivity
  24. 24.  Size related measures based on some output from thesoftware process. This may be lines of delivered sourcecode, object code instructions, etc. Function-related measures based on an estimate of thefunctionality of the delivered software. Function-pointsare the best known of this type of measure.Productivity measures
  25. 25. Estimation techniques There is no simple way to make an accurate estimateof the effort required to develop a software system Initial estimates are based on inadequate information ina user requirements definition; The software may run on unfamiliar computers or usenew technology; The people in the project may be unknown. Project cost estimates may be self-fulfilling The estimate defines the budget and the product isadjusted to meet the budget.
  26. 26. Changing technologies Changing technologies may mean that previousestimating experience does not carry over to newsystems Distributed object systems rather than mainframesystems; Use of web services; Use of ERP or database-centred systems; Use of off-the-shelf software; Development for and with reuse; Development using scripting languages; The use of CASE tools and program generators.
  27. 27. Compression Techniques Shorten the overall duration of the project Crashing Looks at cost and schedule tradeoffs Gain greatest compression with least cost Add resources to critical path tasks Limit or reduce requirements (scope) Changing the sequence of tasks Fast Tracking Overlapping of phases, activities or tasks that would otherwise besequential Involves some risk May cause rework
  28. 28. QUESTIONS
  29. 29. THANK YOUFaizan
  30. 30. Presented byEngr.Faizan SaleemSoftware EngineerBahria University Karachi