Estimation for Software Projects 1 Software Project

Estimation for Software Projects 1

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! 2

Project Planning Task Set-I • Establish project scope • Determine feasibility • Analyze risks • Risk analysis is considered in detail Later. • Define required resources • Determine require human resources • Define reusable software resources • Identify environmental resources 3

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 is considered in detail Later. • Establish a meaningful task set • Define a task network • Use scheduling tools to develop a timeline chart • Define schedule tracking mechanisms 4

Estimation “Good estimating approaches and solid historical data offer the best hope that reality will win out over impossible demands. ” • 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 • Project complexity, project size, and the degree of structural uncertainty all affect the reliability of estimates. 5

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. 6

Resources 7

Software Project Estimation To achieve reliable cost and effort estimates, a number of options arise: 1. Delay estimation until late in the project (obviously, we can achieve 100 percent accurate estimates after the project is complete!). 2. Base estimates on similar projects that have already been completed. 3. Use relatively simple decomposition techniques to generate project cost and effort estimates. 4. Use one or more empirical models for software cost and effort estimation. 8

Estimation Techniques • Past (similar) project experience • Conventional estimation techniques • Task breakdown and effort estimates • Size (e. g. , FP) estimates • Empirical models • Automated tools 9

Decomposition Techniques Software Sizing • The accuracy of a software project estimate is predicated on a number of things: • 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. 10

• Putnam and Myers [Put 92] suggest four different approaches to the sizing problem: • “Fuzzy logic” sizing. This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy logic. To apply this approach, the planner must identify the type of application, establish its magnitude on a qualitative scale, and then refine the magnitude within the original range. • Function point sizing. The planner develops estimates of the information domain characteristics. • Standard component sizing. Software is composed of a number of different “standard component” that are generic to a particular application area. For example, the standard components for an information system are subsystems, modules, screens, reports, interactive programs, batch programs, files, LOC, and object-level instructions. The project planner estimates the number of occurrences of each standard component and then uses historical project data to estimate the delivered size per standard components. • Change sizing. This approach is used when a project encompasses the use of existing software that must be modified in some way as part of a project. The planner estimates the number and type (e. g. , reuse, adding code, changing code, deleting code) of modifications that must be accomplished. 11

Problem-Based Estimation • lines of code and function points were described as measures from which productivity metrics can be computed. LOC and FP data are used in two ways during software project estimation: • (1) as estimation variables to “size” each element of the software and • (2) as baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort projections. 12

Conventional Methods: LOC/FP Approach • Compute LOC/FP using estimates of information domain values • Use historical data to build estimates for the project 13

An Example of LOC-Based Estimation Function Estimated LOC User interface and control facilities (UICF) 2, 300 Two-dimensional geometric analysis (2 DGA) 5, 300 Three-dimensional geometric analysis (3 DGA) 6, 800 Database management (DBM) 3, 350 Computer graphics display facilities (CGDF) 4, 950 Peripheral control function (PCF) 2, 100 Design analysis modules (DAM) 8, 400 Estimated lines of code 33, 200 Estimation table for the LOC methods 14

An Example of FP-Based Estimation table for the LOC methods Information domain value Est. FP Opt. Likely Pess. count Weight count Number of external inputs 20 24 30 24 4 97 Number of external outputs 12 15 22 16 5 78 Number of external inquiries 16 22 28 22 5 88 Number of internal logical files 4 4 5 4 10 42 Number of external interface files 2 2 3 2 7 15 Count total 320 Factor Backup and recovery Value 4 Data communications Distributed processing Performance critical Existing operating environment Online data entry Input transaction over multiple screens Master files updated online Information domain values complex Internal processing complex Code designed for reuse Conversion/installation in design Multiple installations Application designed for change Value adjustment factor 2 0 4 3 4 5 3 5 5 4 3 5 5 1. 17 15

Empirical Estimation Models General form: exponent effort = tuning coefficient * size usually derived as person-months of effort required either a constant or a number derived based on complexity of project empirically derived usually LOC but may also be function point 16

The Structure of Estimation Models

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. 18

Like all estimation models for software, the COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarchy: object points, function points, and lines of source code. Object type Complexity weight Simple Medium Difficult Screen 1 2 3 Report 2 5 8 3 GL component Complexity weighting for object types. 10 The COCOMO II application composition model uses object points and is illustrated in the following paragraphs. It should be noted that other, more sophisticated estimation models (using FP and KLOC) are also available as part of COCOMO II. Like function points, the object point is an indirect software measure that is computed using counts of the number of (1)screens (at the user interface), (2)reports, and (3)components likely to be required to build the application. (4)Each object instance (e. g. , a screen or report) is classified into one of three complexity levels (i. e. , simple, medium, or difficult) using criteria suggested by Boehm [Boe 96].

The Software Equation A dynamic multivariable model E = [LOC x B 0. 333/P 3] x (1/t 4) where E = effort in person-months or person-years Typical values might be P=2000 for development of real-time embedded software, P=10, 000 for telecommunication and systems software, and P=28, 000 for business systems applications. t = project duration in months or years B = “special skills factor” P = “productivity parameter” 20

You should note that the software equation has two independent parameters: (1) an estimate of size (in LOC) and (2) an indication of project duration in calendar months or years.

Estimation for Web. App Projects Web. App projects often adopt the agile process model. Roetzheim [Roe 00] suggests the following approach when adapting function points for Web. App estimation: • Inputs are each input screen or form (for example, CGI or Java), each maintenance screen, and if you use a tab notebook metaphor anywhere, each tab. • Outputs are each static Web page, each dynamic Web page script (for example, ASP, ISAPI, or other DHTML script), and each report (whether Web based or administrative in nature). • Tables are each logical table in the database plus, if you are using XML to store data in a file, each XML object (or collection of XML attributes). • Interfaces retain their definition as logical files (for example, unique record formats) into our out-of-the-system boundaries. • Queries are each externally published or use a message-oriented interface. A typical example is DCOM or COM external references. Mendes and her colleagues [Men 01] suggest that the volume of a Web. App is best determined by collecting measures (called “predictor variables”) associated with the application (e. g. , page count, media count, function count), its Web page characteristics (e. g. , page complexity, linking complexity, graphic complexity), media characteristics (e. g. , media duration), and functional characteristics (e. g. , code length, reused code length). 22

The Make-Buy Decision 23

Computing Expected Cost expected cost = (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost build = 0. 30 ($380 K) + 0. 70 ($450 K) = $429 K similarly, expected cost = $382 K reuse expected cost = $267 K buy expected cost = $410 K contr 24

Thanks… 25