1 / 29

Project Management

Project Management. Estimation. LOC and FP Estimation. Lines of code and function points were described as basic data from which productivity metrics can be computed. LOC and FP data are used in two ways during software project estimation:

mora
Download Presentation

Project Management

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. Project Management Estimation

  2. LOC and FP Estimation • Lines of code and function points were described as basic data from which productivity metrics can be computed. • LOC and FP data are used in two ways during software project estimation: • as estimation variablesthat are used to "size" each element of the software, and • as baseline metricscollected from past projects and used in conjunction with estimation variables to develop cost and effort projections.

  3. The LOC and FP techniques differ in the level of detail required for decomposition. • With LOC, decomposition must be taken to extremes; with FP less detail is required because the data required to estimate function points are more macroscopic. • Note that LOC is estimated directly, FP indirectly.

  4. Expected value? • Regardless of whether LOC or FP is used, the planner provides a range of values for each decomposed function. Using historical data (or intuition) the planner estimates an optimistic, most likely, and pessimistic LOC or FP for each function. • The expected value for LOC or FP is then computed as a weighted average of the three.

  5. For example, E = (a + 4m + b) / 6 gives greatest credence to the most likely estimate and follows a beta probability distribution. Once the expected value has been determined, productivity data are applied.

  6. COCOMO • Boehm, in his 1981 book "Software Engineering Economics", introduced a hierarchy of software estimation models called COCOMO, COnstructive COst MOdel. (Version 2 in 1995) • Basic COCOMO, • Intermediate COCOMO, • Advanced COCOMO, • COCOMO is a well developed model which takes project, product, hardware and personnel attributes into account. It also includes means of estimating development schedules. A disadvantage is that it depends on historical data which may not always be available.

  7. Basic COCOMO • a static single-valued model that computes software development effort (and cost) as a function of program size expressed in lines of code.

  8. Intermediate COCOMO • computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes.

  9. Advanced COCOMO • incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, ...) of the software engineering process.

  10. COCOMO & 3 classes of project • organic mode • relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements • (e.g., a thermal analysis program developed for a heat transfer group);

  11. COCOMO & 3 classes of project • semi-detached mode • an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements • (e.g., a transaction processing system with fixed requirements for terminal hardware and database software);

  12. COCOMO & 3 classes of project • embedded mode • a software project that must be developed within a set of tight hardware, software, and operational constraints (e.g., flight control software for aircraft).

  13. Extensions • The basic model is extended to consider a set of "cost driver attributes" that can be grouped into four major categories: • Product attributes • Hardware attributes • Personnel attributes • Project attributes

  14. Product attributes • Required software reliability • Size of application database • Complexity of the product

  15. Hardware attributes • Runtime performance constraints • Memory constraints • Volatility of the virtual machine environment • Required turnaround time

  16. Personnel attributes • Analyst capability • Software engineer capability • Applications experience • Virtual machine experience • Programming language experience

  17. Project attributes • Use of software tools • Application of software engineering methods • Required development schedule

  18. Effort Adjustment Factors • Each of the 15 attributes is rated on a 6-point scale that ranges from "very low" to "extra high" (in importance or value). Based on the rating, an effort multiplier is determined from tables published by Boehm, and the product of all effort multipliers results is an effort adjustment factor (EAF.) • Typical values for EAF range from 0.9 to 1.4.

  19. But ... • Boehm's own comments about COCOM0 (and by extension all models) should be heeded: • "Today, a software cost estimation model is doing well if it can estimate software development costs within 20%of actual costs, 70% of the time, and on its own turf (that is, within the class of projects to which it has been calibrated) .... This is not as precise as we might like, but it is accurate enough to provide a good deal of help in software engineering economic analysis and decision making."

  20. Example ... • estimated LOC 33360 • estimated project cost $656,680 • estimated effort (PM) 144.5 • and the table of coefficients earlier, and using the semi-detached model, we get E = 3.0 (KLOC) exp(1.12) = 3.0(33.3)1.12 = 152 person-months

  21. Example contd ... • To compute project duration, D = 2.5(E) exp(0.35) = 2.5(152)0.35 = 14.5 months • The recommended number of people for the project is therefore, N = E/D = 152/14.5 = 11 people

  22. Automated Estimation Tools • These tools allow the planner to estimate cost and effort and to perform “what if” analyses for important project variables such as delivery date or staffing. • Those based on COCOMO all require the user to provide a preliminary LOC estimate. • They all conduct a dialog with the planner, obtaining appropriate project and supporting information and producing both tabular and graphical output.

  23. Automated Estimation Tools • When a number of tools were applied to the same project, a relatively large variation in estimated results was found, and predicted values were sometimes very different from actual values. • Output from estimation tools should be used as one “data point” from which estimates are derived - not as the only source for an estimate.

  24. Jones’s First-Order Estimation • Take the function-point total and raise it to the power chosen from the following table • best average worst • Systems 0.43 0.45 0.48 • Business 0.41 0.43 0.46 • Shrink-wrap 0.39 0.42 0.45 • The exponents are based on analysis of a database of several thousand projects

  25. Jones’s “kinds of projects” • Systems = operating systems, device drivers, compilers, embedded software, firmware, real-time systems, … • Business = in-house systems for an organisation, payroll, stock control, accounting systems, IS, IT, MIS software, … • Shrink-wrap = packaged and sold commercially

  26. e.g. • If FP=350 and project is “shrink-wrap” in an average organisation then 350 0.42 = 11.7087, giving a rough schedule of 12 calendar months. • In a best-in-class organisation 350 0.39 giving a schedule of 10 months.

More Related