Chapter 26 Estimation for Software Projects These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

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! These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Project Planning Task Set-I Establish project scope Determine feasibility Analyze risks Risk analysis. Define required resources Determine require human resources Define reusable software resources Identify environmental resources

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

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

Write it Down! Project Scope Software Estimates Project Risks Plan Schedule Control strategy Software Project Plan These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

To Understand Scope ... Understand the customers needs understand the business context understand the project boundaries understand the customer’s motivation understand the likely paths for change understand that ... Even when you understand, nothing is guaranteed! These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

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. 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. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Resources These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Project Estimation Project scope must be understood Elaboration (decomposition) is necessary Historical metrics are very helpful At least two different techniques should be used Uncertainty is inherent in the process These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Estimation Techniques Past (similar) project experience Conventional estimation techniques task breakdown and effort estimates size (e.g., FP) estimates Empirical models Automated tools These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Estimation Accuracy Predicated on … the degree to which the planner has properly estimated the size of the product to be built the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects) the degree to which the project plan reflects the abilities of the software team the stability of product requirements and the environment that supports the software engineering effort. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Functional Decomposition Statement of Scope functional decomposition Perform a Grammatical “parse” These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values use historical data to build estimates for the project These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

LOC/KLOC LOC: lines of code KLOC: kilo lines of code, or (lines of code) / 1000 Still regarded as most accurate way to measure labor costs What are some uncertainties about measuring LOC? Should comment lines count? Or blank lines for formatting? How do we compare lines of assembly language vs. high-level language like C++ or Java? How do you know how many LOC the system will contain when it’s not implemented or even designed yet? How do you account for reuse of code?

Function-Oriented Metrics Mainly used in business applications The focus is on program functionality A measure of the information domain + a subjective assessment of complexity Most common are: function points and feature points (FP) .

Function Points STEP 1: measure size in terms of the amount of functionality in a system. Function points are computed by first calculating an unadjusted function point count (UFC). Counts are made for the following categories ·External inputs – those items provided by the user that describe distinct application-oriented data (such as file names and menu selections) ·External outputs – those items provided to the user that generate distinct application-oriented data (such as reports and messages, rather than the individual components of these) R.L. Probert SEG3300 A&B W2004

Function Points(.) · External inquiries – interactive inputs requiring a response · External files – machine-readable interfaces to other systems · Internal files – logical master files in the system R.L. Probert SEG3300 A&B W2004

Function Points The function point metric is evaluated using the following tables: Weighting Factor Parameter Count Simple Average Complex Weight # of user inputs * 3 4 6 = # of user outputs * 4 5 7 = #of user inquiries # of files * 7 10 15 = # of external interfaces * 5 7 10 = Total_weight =

Function Points The following relationship is used to compute function points:

Function Points where Fi (i = 1 to 14) are complexity adjustment values based on the table below: Reliable backup/recovery needed? Any data communications needed? Any distributed processing functions? Performance critical? Will system run in an existing heavily utilized operational environment? Any on-line data entry? Does on-line data entry need multiple screens/operations?

Function Points Are master files updated on-line? Are inputs, outputs, queries complex? Is internal processing complex? Must code be reusable? Are conversion and installation included in design? Is multiple installations in different organizations needed in design? Is the application to facilitate change and ease of use by user?

Function Points Each of the Fi criteria are given a rating of 0 to 5 as: No Influence = 0; Incidental = 1; Moderate = 2 Average = 3; Significant = 4 Essential = 5

Function-Oriented Metrics Once function points are calculated, they are used in a manner analogous to LOC as a measure of software productivity, quality and other attributes, e.g.: productivity FP/person-month quality faults/FP cost $$/FP documentation doc_pages/FP

Example R.L. Probert SEG3300 A&B W2004

Example (.) R.L. Probert SEG3300 A&B W2004

Example (..) Technical Complexity Factors: 1. Data Communication 3 2. Distributed Data Processing 0 3. Performance Criteria 4 4. Heavily Utilized Hardware 0 5. High Transaction Rates 3 6. Online Data Entry 3 7. Online Updating 3 8. End-user Efficiency 3 9. Complex Computations 0 10. Reusability 3 11. Ease of Installation 3 12. Ease of Operation 5 13. Portability 3 14. Maintainability 3 DI =30 (Degree of Influence) R.L. Probert SEG3300 A&B W2004

Example (…) Function Points FP=UFP*(0.65+0.01*DI)= 55*(0.65+0.01*30)=52.25 That means the is FP=52.25 R.L. Probert SEG3300 A&B W2004

Process-Based Estimation Obtained from “process framework” framework activities application functions Effort required to accomplish each framework activity for each application function These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

COCOMO 81 COCOMO stands for COnstructive COst MOdel It is an open system First published by Dr Barry Bohem in 1981 Worked quite well for projects in the 80’s and early 90’s Could estimate results within ~20% of the actual values 68% of the time

COCOMO 81 COCOMO has three different models (each one increasing with detail and accuracy): Basic, applied early in a project Intermediate, applied after requirements are specified. Advanced, applied after design is complete

COCOMO COCOMO has three different modes: Organic – “relatively small software teams develop software in a highly familiar, in-house environment” [Bohem] Embedded – operate within tight constraints, product is strongly tied to “complex of hardware, software, regulations, and operational procedures” [Bohem] Semi-detached – intermediate stage somewhere between organic and embedded. Usually up to 300 KDSI These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

COCOMO 81 COCOMO uses two equations to calculate effort in man months (MM) and the number on months estimated for project (TDEV) MM is based on the number of thousand lines of delivered instructions/source (KDSI) MM = a(KDSI)b * EAF TDEV = c(MM)d EAF is the Effort Adjustment Factor derived from the Cost Drivers, EAF for the basic model is 1 The values for a, b, c, and d differ depending on which mode you are using The Intermediate Model estimates the software development effort by using fifteen cost driver variables besides the size variable used in Basic COCOMO. Product Attributes RELY:  Required Software Reliability The extent to which the software product must perform its intended functions satisfactorily over a period of time. DATA:  Data Base Size The degree of the total amount of data to be assembled for the data base. CPLX:  Software Product Complexity The level of complexity of the product to be developed. Computer Attributes TIME --- Execution Time Constraint The degree of the execution constraint imposed upon a software product. STOR --- Main Storage Constraint The degree of main storage constraint imposed upon a software product. VIRT --- Virtual Machine Volatility The level of the virtual machine underlying the product to be developed. TURN --- Computer Turnaround Time The level of computer response time experienced by the project team developing the product. Personnel Attributes ACAP:  Analyst Capability The level of capability of the analysts working on a software product. AEXP:  Applications Experience The level of applications experience of the project team developing the software product. PCAP:  Programmer Capability The level of capability of the programmers working on the software product. VEXP:  Virtual Machine Experience The level of virtual machine experience of the project team developing the product. LEXP:  Programming Language Experience The level of programming language experience of the project team developing the product. Project Attributes MODP:  Use of Modern Programming Practices The degree to which modern programming practices (MPPs) are used in developing software product. TOOL:  Use of Software Tools The degree to which software tools are used in developing the software product. SCED:  Schedule Constraint The level of schedule constraint imposed upon the project team developing the software product. Mode a b c d Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 0.35 Embedded 3.6 1.20 0.32

COCOMO 81 A simple example: Project is a flight control system (mission critical) with 310,000 DSI in embedded mode Reliability must be very high (RELY=1.40).  So we can calculate: Effort = 1.40*3.6*(319)1.20 = 5093 MM Schedule = 2.5*(5093)0.32 = 38.4 months Average Staffing = 5093 MM/38.4 months = 133 FSP

COCOMO II Main objectives of COCOMO II: To develop a software cost and schedule estimation model tuned to the life cycle practices of the 1990’s and 2000’s To develop software cost database and tool support capabilities for continuous model improvement From “Cost Models for Future Software Life Cycle Processes: COCOMO 2.0," Annals of Software Engineering, (1995).

COCOMO-II COCOMO II is actually a hierarchy of estimation models that address the following areas: Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Post-architecture-stage model. Used during the construction of the software. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

COCOMO II Differences The exponent value b in the effort equation is replaced with a variable value based on five scale factors rather then constants Size of project can be listed as object points, function points or source lines of code (SLOC). EAF is calculated from seventeen cost drivers better suited for today's methods, COCOMO81 has fifteen A breakage rating has been added to address volatility of system 9. Does COCOMO II replace traditional COCOMO? You should use COCOMO II for most of your new projects. COCOMO 81 is still the best approach for some software projects. If you're using a fairly traditional approach, and using a 3GL (third generation language), such as C, Fortran, or Cobol, the original COCOMO will give you good results.  If your development tools and processes haven't changed much in recent years, COCOMO 81 might be the right model for you. If you're using more modern tools, a new development process model, a 4GL language, or tools like Visual Basic, Delphi, or Power Builder, you might find that COCOMO II makes more sense. When in doubt, try to model your project using both the traditional COCOMO and COCOMO II.

The Software Equation A dynamic multivariable model E = [LOC x B0.333/P]3 x (1/t4) where E = effort in person-months or person-years t = project duration in months or years B = “special skills factor” P = “productivity parameter” These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Estimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Using object-oriented requirements modeling (Chapter 6), develop use-cases and determine a count. From the analysis model, determine the number of key classes (called analysis classes in Chapter 6). Categorize the type of interface for the application and develop a multiplier for support classes: Interface type Multiplier No GUI 2.0 Text-based user interface 2.25 GUI 2.5 Complex GUI 3.0 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Estimation for OO Projects-II Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class. Cross check the class-based estimate by multiplying the average number of work-units per use-case These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Estimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for estimation purposes. The scenario is decomposed into the set of software engineering tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.” Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count). Estimates for each task are summed to create an estimate for the scenario. Alternatively, the volume estimate for the scenario is translated into effort using historical data. The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

The Make-Buy Decision These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Computing Expected Cost (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost = 0.30 ($380K) + 0.70 ($450K) build = $429 K similarly, expected cost = $382K reuse expected cost = $267K buy expected cost = $410K contr These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.