estimation
DESCRIPTION
TRANSCRIPT
- 1. GROUP MEMBERSFAIZAN SALEEM (Leader)ARSALAN SHARIQ
2. Project Estimation and scheduling Outline: Estimation overview Detailed schedule/planning terminology and processes 3. EstimationThe single most important task of aproject: setting realistic expectations.Unrealistic expectations based oninaccurate estimates are the singlelargest cause of software failure. 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 deliverNOTHING! Key reasonspoor management and inaccurateestimations of development cost and schedule If not meeting schedules, developers often pay theprice! 5. The Problems Predicting software cost Predicting software schedule Controlling software risk Managing/tracking project as it progresses 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. 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. 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. 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. 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. 4 Common (subjective)estimation models Expert Judgment Analogy Parkinsons law Price to win 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. 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. Parkinsons Law The project costs whatever resources are available Advantages: No overspend Disadvantages: System is usually unfinished 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. 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. 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. 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. 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. 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. 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. Criteria for a Good Model Definedclear what is estimated Accurate Objectiveavoids subjective factors Results understandable Detailed Stablesecond order relationships Right Scope Easy to Use Causalfuture data not required Parsimoniouseverything present is important 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. 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. 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. 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. 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. QUESTIONS 29. THANK YOUFaizan [email protected]/faiz.saleem 30. Presented byEngr.Faizan SaleemSoftware EngineerBahria University Karachi [email protected]/faiz.saleem