Software Engineering Fall 2005

1. Lecture 17EstimationBased on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman Software Engineering Fall 2005

2. Overview • Software planning involves estimating how much time, effort, money, and resources will be required to build a specific software system. • After the project scope is determined and the problem is decomposed into smaller problems, software managers use historical project data (as well as personal experience and intuition) to determine estimates for each. • The final estimates are typically adjusted by taking project complexity and risk into account. The resulting work product is called a project management plan.

3. Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Why? So the end result gets done on time, with quality!

4. Project Planning • Software project planning encompasses five major activities: - Estimation, - Scheduling, - Risk analysis, - Quality management planning, and - Change management planning.

5. Project Planning Objectives • To provide a framework that enables a software manager to make a reasonable estimate of resources, cost, and schedule. • 'Best case' and 'worst case' scenarios should be used to bound project outcomes. • Estimates should be updated as the project progresses.

6. Project Planning Task Set-I 1. Establish project scope 2. Determine feasibility 3. Analyze risks 4. Define required resources • Determine required human resources • Define reusable software resources • Identify environmental resources

7. Project Planning Task Set-II 5. Estimate cost and effort - Decompose the problem; - Develop two or more estimates using size, function points, process tasks or use-cases; - Reconcile the estimates. 6. Develop a project schedule - Establish a meaningful task set; - Define a task network; - Use scheduling tools to develop a timeline chart; - Define schedule tracking mechanisms.

8. Estimation • Estimation of resources, cost, and schedule for a software engineering effort requires experience, access to good historical information (metrics), the courage to commit to quantitative predictions when qualitative information is all that exists. • Estimation carries inherent risk and this risk leads to uncertainty.

9. Estimation • Estimation begins with a description of the scope of the product. • The problem is then decomposed into a set of smaller problems, and each of these is estimated using historical data and experience as guides. • Problem complexity and risk are considered before a final estimate is made.

10. Estimation Work Product • A simple table delineating: - the task to be performed, - the functions to be implemented, - and the cost, effort, and time involved for each.

11. What is Scope? • Software scope describes • the functions and features that are to be delivered to end-users • the data that are input and output • the “content” that is presented to users as a consequence of using the software • the performance, constraints, interfaces, and reliability that bound the system.

12. Scope • Scope is defined using one of two techniques: • A narrative description of software scope is developed after communication with all stakeholders. • A set of use-cases is developed by end-users.

13. Feasibility Why is a feasibility assessment part of the planning process? • If a project is not technically possible, there is no point in trying to build it. But technical feasibility is not the whole story. The project must also fulfill a business need to avoid building a high tech product that does not have any customers • Technical feasibility is not a good enough reason to build a product. • The product must meet the customer's needs and not be available as an off-the-shelf purchase.

14. Software Feasibility • Technology – Is a project technically feasible? • Finance – Can development be completed at a cost the software organization, its client, or the market can afford? • Time – Will the project’s time-to-market beat the competition? • Resources – Does the organization have the resources needed to succeed?

15. Estimation of Resources • The following resources are typically included in the project estimation process: - Human Resources- number of people required and skills needed to complete the development project; - Reusable Software Resources- off-the-shelf components, full-experience components, partial-experience components, new components; - Environment Resources - hardware and software required to be accessible by software team during the development process.

16. Resources • What people are available? • What software can you really re-use? • how much must be modified? • if over 20% modification, consider starting afresh • is the documentation sufficient for this customer? • if not or marginal, cost of re-use gets very high • what aspects can you re-use? • code • design • design concepts • requirements • What tools are available? Are they adequate?

17. Software Resources For software categories: • Of-the-shelf components – Existing software can be acquired from a third party or has been developed internally for a past project. COTS (commercial off-the-shelf) components are purchased from a third party, are ready for use on the current project, and have been fully validated. • Full-experience components – Existing specifications, designs, code, or test data developed for past projects are similar to the software to be built for the current project. • Partial-experience components – Existing specifications, designs, code, or test data developed for past projects are related to the software to be built for the current project but will require substantial modification.Modifications required for partial-experience components have a fair degree of risk. • New components – Software components must be built by the software team specifically for the needs of the current project.

18. Software Project Estimation Options • Delay estimation until late in the project –not practical. • Base estimates on similar projects already completed –unfortunately, past experience is not always a good indicator of future results. • Use simple decomposition techniques to estimate project cost and effort. Automated tools may assist with project decomposition and estimation. • Use empirical models for software cost and effort estimation.

19. Decomposition Techniques • Software sizing –A project estimate is only as good as the estimate of the size of the work to be done. • Problem-based estimation - using lines of code (LOC) decomposition focuses on software functions. Using function points (FP) decomposition focuses on information domain characteristics. • Process-based estimation - decomposition based on tasks required to complete the software process framework. • Use-case estimation - promising, but controversial due to lack of standardization of use-cases.

20. Software Sizing • “Fuzzy logic” sizing • when you have no idea what you are doing • Function point sizing • when you know roughly the overall behavior of the software. • Standard component sizing • when you know roughly what the solution looks like. The project planner estimates the number of occurrences of each standard component and then uses historical project data to determine the delivered size per standard component. • Change sizing • when you are several (>2) cycles into the spiral model. The number and type (e.g., reuse, adding, changing, deleting code) of modifications that must be accomplished.

21. Software Sizing • Each of the sizing approaches should be combined statistically to create a three-point or expected-value estimate. This is accomplished by developing optimistic (low), most likely, and pessimistic (high) values for size and combining them.

22. Expected-value Computation • A three-point or expected-value for the estimation variable (size), S, can be computed as a weighted average of the optimistic (Sopt), most likely (Sm), and pessimistic (Spess) estimates. For example, S = (Sopt + 4Sm + Spess)/6 (23-1) gives heaviest credence to the ‘most likely’ estimate.

23. Problem-Based Estimation • Using LOC decomposition focuses on software functions. • Using FP decomposition focuses on information domain characteristics. • Regardless of the estimation variable that is used, the project planner begins by estimating range of values for each function or information domain value. Using historical data (or intuition), the planner estimates an optimistic, most likely, and pessimistic size value for each function or count for each information domain value. An expected value can then be computed. • Once the expected value for the estimation value has been determined, historical LOC or FP productivity data are applied.

24. Metrics for the Size of a Product • Lines of code (LOC, KLOC, KDSI - thousand of delivered software instructions) • Function Points • COCOMO

25. Estimation - Conventional Methods:LOC/FP Approach • Compute LOC (Line of Code)/FP using estimates of information domain values • Use historical data to build estimates for the project

26. Lines of Code (LOC) • The end product is delivered software – amount of the product should be an indication of the effort required to produce it. • It is not clear how to count lines of code • Executable lines of code? • Data definitions? • Comments? • Changed/deleted lines? • A report, screen, or GUI generator can generate thousands of lines of code in minutes

27. LOC • Pro: LOC are "artifact" of all software development project that can be easily counted. • Con: LOC measures are programming language dependent. They penalize well-designed but shorter programs. They cannot easily accommodate non-procedural languages. • Con: When used in estimation, planner must estimate the LOC long before analysis and design have been completed.

28. Comparing LOC and FP Representative values developed by QSM (Quantitative Software Management)

29. LOC • One LOC of C++ provides approximately 2.4 times the ‘functionality’ (on average) as one LOC of C. • One LOC of a Smalltalk provides at least four times the functionality of a LOC for a conventional programming languages such as Ada, COBOL, or C.

30. Example 1: LOC Based Estimation • Let us consider a software package to be developed for a computer-aided design application for mechanical components. The software is to execute on an engineering workstation and must interface with various peripherals including a mouse, digitizer, high-resolution colour display, and laser printer.

31. Example 1: LOC Based Estimation • A preliminary scope: The mechanical CAD software will accept two- and three-dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter.

32. Example 1: LOC Based Estimation • Can use three point estimation for estimating LOC (equation 23-1). • Use historical data (or something) to compute effort based on estimated LOC / pm. • Compute software cost from labor cost.

33. Example 1: LOC Based Estimation

34. Example 1: LOC Based Estimation • A review of historical data indicates that the average productivity for systems of this type = 620 LOC/pm. Burdened labor rate of €8000 per month, the cost per line of code is approximately €13. • Based on the LOC estimate and the historical productivity data: - the total estimated project cost is €431,000 ( 33200 x 13) - the estimated effort is 54 person-months (33200 / 620)

35. Example 2: Function Point Estimation • Referring to the LOC Table, the project planner estimates external inputs, external outputs, external inquiries, internal logical files, and external interface files for the CAD software. • For the purpose of this estimate, the complexity weighting factor is assumed to be average.

36. Example 2: Function Point Estimation

37. 14 Complexity Weighting Factors

38. Example 2: Function Point Estimation • Can use expected value computation for Count • Use Complexity Weighting Factors (S Fi = 52) • Compute FP est = count_total * ( 0.65 + 0.01 * S Fi ) FP est = 318 * (0.65 + 0.01 * 52) = 372

39. Example 2: Function Point Estimation • Organizational average productivity (labor months) for systems of this type = 6.5 FP/pm. Burdened labor rate = €8000 per month, the cost per FP is approximately €1230. • Based on the FP estimate and the historical productivity data: - the total estimated project cost is €458,000 (FP est x 1230) - the estimated effort is 57 person-months (FP est / 6.5)

40. Process-Based Estimation • The most common technique for estimating a project is to base the estimate on the process that will be used. • That is, the process is decomposed into a relatively small set of tasks and the effort required to accomplish each task is estimated.

41. Process-Based Estimation Obtained from “process framework” framework activities application functions Effort required to accomplish each framework activity for each application function

42. Example 3: Process-Based Estimation • CAD Software introduced earlier. The system configuration and all software functions remain unchanged and are indicated by project scope. • Estimates of effort (in person-months) – next Figure – for each software engineering activity are provided for each CAD software function. The engineering and construction activities are subdivided into the major software engineering tasks shown.

43. Example 3: Process-Based Estimation • Gross estimates of effort are provided for customer communication, planning, and risk analysis. These are noted at the bottom of the table. • Horizontal and vertical totals provide an indication of estimated effort required for analysis, design, code and test. 53 percent of all effort is expanded on front-end engineering tasks (requirements analysis and design), indicating the importance of this work.

44. Example 3: Process-Based Estimation

45. Example 3: Process-Based Estimation • Based on an average burdened labor rate of $8,000 per month: - the total estimated project cost is $368,000, and - the estimated effort is 46 person-months. • If desired, labour rates could be associated with each framework activity or software engineering task and computed separately.

46. Estimation with Use-Cases • Use-cases provide a software team with insight into software scope and requirements. • Problematic, because, use-cases: - are described using many different formats and styles, there is no standard form; - represent an external view (the user’s view) of the software and are often written at different level of abstraction; - do not address the complexity of the functions and features are often written at different levels of abstraction; - do not describe complex behaviour (e.g. interactions) that involves many functions and features.

47. Estimation with Use-Cases • Empirical data may be used to establish the estimated number of LOC or FP per use case. Historical data are then used to compute the effort required to develop the system. For example: we may assume that one use-case corresponds to one FP. • The LOC Estimate can be computed in different ways. As an illustration consider the relationship on the next slide.

48. Estimation with Use-Cases LOC estimate = N x LOCavg + [(Sa/Sh -1) + (Pa/Ph -1)] x LOCadjust (23-2) Where N = actual number of use-cases LOCavg = historical average LOC per use-case for this type of subsystem. LOCadjust = represents an adjustment based on n percent of LOCavg where n is defined locally and represents the difference between this project and ‘average’ projects. Sa = actual scenarios per use-case Sh = average scenarios per use-case for this type of subsystem. Pa = actual pages per use-case Ph = average pages per use-case for this type of subsystem.

49. Example 4: Use-Case Based Estimation • The CAD software introduced earlier is composed of three subsystem groups: - User interface subsystem (includes UICF). - Engineering subsystem group (includes 2DGA subsystem, SDGA subsystem, and DAM subsystem). - Infrastructure subsystem group (includes CGDF subsystem and PCF subsystem).

50. Example 4: Use-Case Based Estimation • Six use-cases describe the user interface subsystem. Each use case is described by no more than 10 scenarios and has an average length of six pages. • The engineering subsystem group is described by 10 use-cases (these are considered to be at a higher level of the structural hierarchy). Each of these use-cases has no more than 20 scenarios associated with it and has an average length of eight pages. • The infrastructure subsystem group is described by five use-cases with an average of only six scenarios and an average length of five pages. • Using the relationship noted in Expression (23-2) with n = 30%, the Table in the next Figure is developed.