project planning components.pdf
- 1. SOFTWARE PROJECT PLANNING AND COSTING Software Cost Estimation SE518 Lecture-3
- 2. Project Planning Components • Software Scope • Resources • Project Estimation • De-composition Techniques • Empirical estimation models • Make or Buy Decision • Estimation Tools (Manual and Automated)
- 3. De-composition Techniques Software project estimation is a form of problem solving. If the problem is complex, it must be decomposed to smaller problems. Decomposition have two point of views 1. Decomposition of the problem 2. Decomposition of the process In estimation we use one or both methods of partitioning
- 4. De-composition Techniques Decomposition of the process 1. Framework selection (communication, planning etc) 2. How do we accomplish this framework activity?” For example, a small, relatively simple project might require the following work tasks for the communication activity: • Develop list of clarification issues. • Meet with stakeholders to address clarification issues. • Jointly develop a statement of scope. • Review the statement of scope with all concerned. • Modify the statement of scope as required
- 5. De-composition Techniques In case of complex project, the communication activities can be broken down into • Review the customer request. • Plan and schedule a formal, facilitated meeting with all stakeholders. • Conduct research to specify the proposed solution and existing approaches. • Prepare a “working document” and an agenda for the formal meeting. • Conduct the meeting.
- 6. De-composition Techniques • Jointly develop mini-specs that reflect data, functional, and behavioral features of the software. Alternatively, develop use cases that describe the software from the user’s point of view. • Review each mini-spec or use case for correctness, consistency, and lack of ambiguity. • Assemble the mini-specs into a scoping document. • Review the scoping document or collection of use cases with all concerned. • Modify the scoping document or use cases as required.
- 7. De-composition Techniques • Software project estimation prediction Accuracy of Project Estimate (Prediction) Proper size estimation Ability to translate estimate into effort, time & money Degree of abilities of software team Stability of product requirements
- 8. De-composition Techniques • Software Sizing • size refers to a quantifiable outcome of the software project. • size can be measured in lines of code (LOC). • size can represented as function points (FP)
- 9. De-composition Techniques • Software Sizing • Analogy sizing (planner must identify type of application & its magnitude on a qualitative scale) • Divide the historical produce size data into size ranges. • Compare the planned product with these prior products. • Based on this comparison, select the size that seems most appropriate for the new product. • Function point sizing (information domain characteristics), Function points are derived using an empirical relationship based on countable (direct) measures of software’s information domain (external inputs, external outputs, external interface, internal logical files etc) and qualitative assessments of software complexity.
- 10. De-composition Techniques • Software Sizing • Standard component sizing (generic components of a particular application like every mis application have to input data, reporting etc). Historical data may also be used. • Change sizing (existing software modifications e.g addition, modification, deletion etc.) • User stories sizing • It represent the relative sizing of the user story. It is a unit of estimation used by Agile teams to estimate User Stories. When the product owner wants some features to be developed he/she desires to know how soon the team can complete the features and how many resources it will take to complete the work.
- 11. 11 Decomposition Techniques • Process-based estimation • decomposition based on tasks required to complete the software process framework • Problem-based estimation • using lines of code (LOC) decomposition focuses on software functions • using function point (FP) decomposition focuses on information domain characteristics
- 12. Empirical Estimation Models • An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC. • Structure of estimation model E = A + B x (ev)C Models • Walston-Felix model • Bailey-Basili model • Boehm simple model • Doty model for KLOC > 9
- 13. 13 Empirical Estimation Models • Experiential Models • Typically derived from regression analysis of historical software project data with estimated person-months as the dependent variable • Static Estimation Model • does not include time as an independent variable • Constructive Cost Model (COCOMO) • Dynamic Estimation Models • usually takes time or development phase into account • Software Equation Model
- 14. 14 Make Buy Decision • Based on Data • It may be more cost effective to acquire a piece of software rather than develop it. • Decision tree analysis provides a systematic way to sort through the make-buy decision. • As a rule outsourcing software development requires more skillful management than does in- house development of the same product.
- 15. Make up or Buy Decision • Software may be purchased (or licensed) off-the-shelf. • “full experience” or “partial-experience” software components may be acquired and then modified and integrated to meet specific needs. • Software may be custom built by an outside contractor to meet the specifications.
- 16. Make up or Buy Decision For expensive software products, the following guidelines can be applied: 1. Develop specifications for function and performance of the desired software. 2. Define measurable characteristics whenever possible. 3. Estimate the internal cost to develop and the delivery date. 4. Select three or four candidate applications that best meet your specifications. OR Select reusable software components that will assist in constructing the required application.
- 17. Make up or Buy Decision 4. Develop a comparison matrix that presents a head-to- head comparison of key functions. 5. Alternatively, conduct benchmark tests to compare candidate software. 6. Evaluate each software package or component based on past product quality, vendor support, product direction (identification and selection of implementation strategy, execution) , reputation etc. 7. Contact other users of the software and ask for opinions.
- 18. Make up or Buy Decision Following points may also influence make/buy decision: • Delivery time of both products. • Will the cost of acquisition plus the cost of customization be less than the cost of developing the software internally? • Will the cost of outside support (e.g., a maintenance contract) be less than the cost of internal support?
- 19. 19 Decision Process 1. Develop specifications. 2. Estimate internal cost & delivery. 3. Select 3 or 4 candidate packages. 4. Select reasonable components. 5. Build a cost-benefit comparison matrix (key function performance) or use conduct benchmark tests of candidate software 6. Evaluate each software package or component based on history with the product or vendor. 7. Contact other users.
- 20. Cost Estimation Techniques • Manual software Estimating Methods • Manual Project Level Estimates using rules of thumb • Manual Phase Level Estimates using ratios and percentages • Manual Activity Level Estimates using work breakdown structure • Automated Software Estimating Methods • Automated Project Level Estimates using rules of thumb • Automated Phase Level Estimates using ratios and percentages • Automated Activity Level Estimates using work breakdown structure
- 21. Cost Estimation Techniques •The most accurate forms of software cost estimation are the •Manual activity-level estimates using work-breakdown structures and •Automated activity-level or task-level estimates (micro-estimation) cost estimating at either the activity or the task level, and used for larger projects only.
- 22. Manual Project Level Estimates using rules of thumb • Oldest method • Not accurate • In use due to simplicity for smaller projects. • Example Examples of rules of thumb using the lines-of-code-metrics might be “JAVA applications average 500 code statements per staff month” or “JAVA applications cost an average of Rs 1000 per line of code to develop.”
- 23. Manual Project Level Estimates using rules of thumb • Its simple method and easy to do. • However, simplistic estimates using rules of thumb should not serve as the basis of contracts or formal budgets for software projects. • Calendar months = (Function points) 0.4
- 24. Manual Phase Level Estimates using ratios and percentages • Its start with overall project level estimates • Then ratios and percentages are assigned to various phases of the project. • Number of phases would run from five to eight • Requirements gathering, analysis & design, coding, testing, installation and training. • Example We are going to develop an application of 100 functional points or having 10,000 LOC. Using rule of thumb from manual project estimation, we assume that this project will average 500 code statements per month. Then effort will take 20 months 10,000=500xmonths
- 25. Manual Phase Level Estimates using ratios and percentages • Typical effort percentages of five phases are • Requirements 10% • Analysis and design 20% • Coding 30% • Testing 30% • Installation & training 5%
- 26. Manual Phase Level Estimates using ratios and percentages • Issues • In real world, percentages vary widely for every activity on the basis of type of projects • Many kinds of software work span over multiple phases or run the entire duration of the project like documentation • Activities that are not phased, may accidently be omitted from the estimates
- 27. Manual Phase Level Estimates using ratios and percentages • Issues Example- 1: smaller projects coding is 60%, larger projects coding is 15-20%, however testing % may be increased. Fix percentage can not be used Example-2: week estimation of activities span over multiple phases like documentation, starts during requirements phase and end after testing These must be considered Example-3 Quality assurance, technical writing & integration are not identified as phases. In complex projects it takes 25-30% effort. That’s why most manual estimates tends towards excessive optimism for both cost and schedule.
- 28. Manual Phase Level Estimates using ratios and percentages Slightly more useful than overall project estimates and are just about as easy to prepare. However, they are far from sufficient for contracts, budgets, or serious business purposes
- 29. Manual Activity Level Estimates using work breakdown structure • Estimation of each activity or task using a formal work- breakdown structure is the most accurate of the manual methods.
- 30. Conditions of Manual Estimation • Can be used for early estimates before requirements • Small projects, which can be completed with one or two programmers • Low value projects with no critical business impacts Not use full in situation like • contract purposes for software development and maintenance • Larger projects • Projects with significance business impact.
- 31. Automated Estimating Methods • Its same as in manual method • Just easier and simpler due to automated tool • Its also called Macro-estimation • Its starts with general equitation's of staffing, effort etc