Chapter-7 ESTIMATION FOR SOFTWARE PROJECTS Software Project

Chapter-7 ESTIMATION FOR SOFTWARE PROJECTS

Software Project Planning Ø Software project planning encompasses five major activities — Estimation, scheduling, risk analysis, quality management planning, and change management planning Ø Estimation determines how much money, effort, resources, and time it will take to build a specific system or product Ø The software team first estimates — The work to be done — The resources required — The time that will elapse from start to finish Ø Then they establish a project schedule that — Defines tasks and milestones — Identifies who is responsible for conducting each task — Specifies the inter-task dependencies

Observations on Estimation Ø Planning requires technical managers and the software team to Ø Ø make an initial commitment Process and project metrics can provide a historical perspective and valuable input for generation of quantitative estimates Past experience can aid greatly Estimation carries inherent risk, and this risk leads to uncertainty The availability of historical information has a strong influence on estimation risk

Observations on Estimation Ø When software metrics are available from past projects — Estimates can be made with greater assurance — Schedules can be established to avoid past difficulties — Overall risk is reduced Ø Estimation risk is measured by the degree of uncertainty in the quantitative estimates for cost, schedule, and resources Ø Nevertheless, a project manager should not become obsessive about estimation — Plans should be iterative and allow adjustments as time passes and more is made certain

Task Set for Project Planning 1) 2) 3) 4) Establish project scope Determine feasibility Analyze risks Define required resources a) b) c) 5) Estimate cost and effort a) b) c) 6) Determine human resources required Define reusable software resources Identify environmental resources Decompose the problem Develop two or more estimates using different approaches Reconcile the estimates Develop a project schedule a) b) c) d) Establish a meaningful task set Define a task network Use scheduling tools to develop a timeline chart Define schedule tracking mechanisms

Software Scope Ø Software scope describes — The functions and features that are to be delivered to end users — The data that are input to and output from the system — 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 can be define using 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

Software Scope Ø After the scope has been identified, two questions are asked — Can we build software to meet this scope? — Is the project feasible?

Feasibility Ø After the scope is resolved, feasibility is addressed Ø Software feasibility has four dimensions — Technology – Is the project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application's needs? — Finance – Is is financially feasible? Can development be completed at a cost that the software organization, its client, or the market can afford? — Time – Will the project's time-to-market beat the competition? — Resources – Does the software organization have the resources needed to succeed in doing the project?

Resource Estimation Ø Three major categories of software engineering resources — People — Development environment — Reusable software components – Often neglected during planning but become a paramount concern during the construction phase of the software process Ø Each resource is specified with — A description of the resource — A statement of availability — The time when the resource will be required — The duration of time that the resource will be applied

Categories of Resources

Human Resource Ø Planners need to select the number and the kind of people Ø Ø skills needed to complete the project They need to specify the organizational position and job specialty for each person Small projects of a few person-months may only need one individual Large projects spanning many person-months or years require the location of the person to be specified also The number of people required can be determined only after an estimate of the development effort

Development Environment Resources Ø A software engineering environment (SEE) incorporates hardware, software, and network resources that provide platforms and tools to develop and test software work products Ø Most software organizations have many projects that require access to the SEE provided by the organization Ø Planners must identify the time window required for hardware and software and verify that these resources will be available

Reusable Software Resources Ø Off-the-shelf components — Components are from a third party or were developed for a previous project — Ready to use; fully validated and documented; virtually no risk Ø Full-experience components — Components are similar to the software that needs to be built — Software team has full experience in the application area of these components — Modification of components will incur relatively low risk Ø Partial-experience components — Components are related somehow to the software that needs to be built but will require substantial modification — Software team has only limited experience in the application area of these components — Modifications that are required have a fair degree of risk

Reusable Software Resources Ø New components — Components must be built from scratch by the software team specifically for the needs of the current project — Software team has no practical experience in the application area — Software development of components has a high degree of risk

Project Estimation Options Ø Options for achieving reliable cost and effort estimates 1) 2) 3) 4) Delay estimation until late in the project (we should be able to achieve 100% accurate estimates after the project is complete) Base estimates on similar projects that have already been completed Use relatively simple decomposition techniques to generate project cost and effort estimates Use one or more empirical estimation models for software cost and effort estimation

Project Estimation Approaches Ø Decomposition techniques — These take a "divide and conquer" approach — Cost and effort estimation are performed in a stepwise fashion by breaking down a project into major functions and related software engineering activities Ø Empirical estimation models — Offer a potentially valuable estimation approach if the historical data used to seed the estimate is good

Problem Based Estimation Ø Here we subdivide the problem into small problems. When all the small problems are solved the main problem is solved. — Lines of Code — Function Point Ø LOC (Lines of Code), FP(Function Point) estimation methods consider the size as the measure. In LOC the cost is calculated based on the number of lines. In FP the cost is calculated based on the number of various functions in the program.

Problem Based Estimation For both approaches, the planner uses lessons learned to estimate an optimistic, most likely, and pessimistic size value for each function or count (for each information domain value) Ø Then the expected size value S is computed as follows: Ø Optimistic Value, Most Likely Value Pessimistic Value Ø Once the Expected Value has been determined, Historical (LOC) and (FP) Productivity data are applied.

Statement of 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.

EXAMPLE OF (LOC) BASED ESTIMATION FUNCTIONS ESTIMATED LOC - User Interface and Control Facilities (UICF) 2, 300 - Two Dimensional Analysis (2 DGA) 5. 300 - 3 D Geometric Analysis Function (3 DGA) 6, 800 *** - Database Management (DBM) 3, 350 - Computer Graphic Display facility (CGDF) 4, 950 - Peripheral Control Function (PCF) 2, 100 - Design Analysis Modules DAM) 8. 400 _______________________________ TOTAL ESTIMATED LOC ( ∑ LOC ) 33. 200 ============================= For Example: - Using the Expected Value Equation we can calculate the Estimated Value for (3 DGA) Function as follows: - Optimistic Estimation = 5, 000 LOC Most Likely Estimation = 6, 700 LOC Pessimistic Estimation = 9, 000 LOC

EXAMPLE OF (LOC) BASED ESTIMATION Historical data obtained from the Metrics indicates the following Organizational Averages: Average Productivity is 620 LOC / Pm (Lines of Code Per Month) Average Labor Cost is $8, 000 Per month. Cost for a Line of Code can be calculated as follows (COST / LOC) COST / LOC = (8000 / 620) = $13 Total Estimated Project Cost and Project Effort can be calculated as: follows- Considering that the Total LOC ( ∑ LOC) for the System is 33, 200 Ø Total Estimated Project Cost = (33200 * 13 ) = $431, 600 Ø Total Estimated Project Effort = (33200 / 620) = ~ 54 Man Months

EXAMPLE OF (LOC) BASED ESTIMATION

EXAMPLE OF (FP) BASED ESTIMATION • Decomposition for FP-based estimation focuses on information domain values rather than software functions. • For the purposes of this estimate, the complexity weighting factor is assumed to be average.

EXAMPLE OF (FP) BASED ESTIMATION

EXAMPLE OF (FP) BASED ESTIMATION The estimated number of FP is derived: FPestimated = count-total *[0. 65 + 0. 01*(Fi)] FPestimated = 320 *[0. 65 + 0. 01*(52)] = 374. 4 ~ 375 FPestimated = 375 organizational average productivity = 6. 5 FP/pm burdened labor rate = $8000 per month, approximately $1230/FP. Based on the FP estimate and the historical productivity data, total estimated Based on the FP estimate and the historical productivity data, project cost is $461, 000 and estimated effort is 58 person-months.

EMPIRICAL ESTIMATION MODELS Ø Estimation models for computer software use empirically derived formulas to predict effort as a function of LOC or FP Ø Resultant values computed for LOC or FP are entered into an estimation model

EMPIRICAL ESTIMATION MODELS

COCOMO Introduction Ø Stands for COnstructive COst MOdel Ø COCOMO is one of the most widely used software estimation models in the world Ø It was developed by Barry Boehm in 1981 Ø COCOMO predicts the effort and schedule for a software product development based on inputs relating to the size of the software and a number of cost drivers that affect productivity

COCOMO Model Hierarchy of Cocomo Model 1. Basic COCOMO model 2. Intermediate COCOMO model 3. Detailed COCOMO model

The Development Modes: Project Characteristics Organic Mode ü Relatively small, simple software projects ü Small teams with good application experience work to a set of less than rigid requirements ü Similar to the previously developed projects ü relatively small and requires little innovation Semidetached Mode ü Intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements. Embedded Mode ü Software projects that must be developed within a set of tight hardware, software, and operational constraints.

The Development Modes: Project Characteristics

COCOMO : Some Assumptions Ø Primary cost driver is the number of Delivered Source Instructions (DSI) Delivered Line Of Code developed by the project Ø COCOMO estimates assume that the project will enjoy good management by both the developer and the customer Ø Assumes the requirements specification is not substantially changed after the plans and requirements phase

Basic COCOMO Model: Formula Ø Effort(E) = ab * (KLOC)bb(in Person-months) Ø Development. Time(D) = cb * (E) db (in month) Ø Average staff size(SS) = E/D (in Person) Ø Productivity(P) = KLOC / E (in KLOC/Person-month)

Basic COCOMO

Basic COCOMO

Basic COCOMO-Example Ø We have determined our project fits the characteristics of Semi-Detached mode Ø We estimate our project will have 52, 000 Delivered Source Instructions. Using the formulas, we can estimate: Ø Effort = 3. 0*(52) 1. 12 = 250 man-months Ø Schedule = 2. 5*(250) 0. 35 = 17 months Ø Productivity = 52, 000 DSI / 250 MM = 208 DSI/MM Ø Average Staffing = 250 MM /17 months

Intermediate COCOMO Ø Ø Ø Extension of Basic COCOMO Why Use ? Basic model lacks accuracy Computes software development effort as a function of program size and set of 15 Cost Drivers Cost Driver: A multiplicative factor that determines the effort required to complete the software project. Why Cost Drivers? Adjust the nominal cost of a project to the actual project Environment. For each Characteristics, Estimator decides the scale factor Very Low Nominal High Very High Extra High

Intermediate COCOMO: Cost Drivers Ø Product: The characteristics of the product that are considered include the inherent complexity of the product, reliability requirements of the product, etc. Ø Computer: Characteristics of the computer that are considered include the execution speed required, storage space required etc. Ø Personnel: The attributes of development personnel that are considered include the experience level of personnel, programming capability, analysis capability, etc. Ø Development Environment: Development environment attributes capture the development facilities available to the developers. An important parameter that is considered is the sophistication of the automation (CASE) tools used for software development.

Intermediate COCOMO: Cost Drivers

Intermediate COCOMO Multiply all 15 Cost Drivers to get Effort Adjustment Factor(EAF) Ø E(Effort) = ab(KLOC)bb * EAF(in Person-Month) Ø D(Development Time) = cb(E)db (in month) Ø SS (Avg Staff Size) = E/D (in persons) Ø P (Productivity) = KLOC/E (in KLOC/Person-month)

Intermediate COCOMO

Intermediate COCOMO-Example A new project with estimated 400 KLOC embedded system has to be developed. Project manager hires developers of very low quality but a lot of experience in programming language. Calculate the Effort, Development time, Staff size & Productivity.

Intermediate COCOMO-Example EAF = 1. 29 * 0. 95 = 1. 22 400 K LOC implies Embedded System Effort = 2. 8*(400)1. 20 * 1. 225 = 3712 * 1. 22 = 4528 person-months Development Time = 2. 5 * (4528)0. 32 = 2. 5 * 14. 78 = 36. 9 months Avg. Staff Size = E/D = 4528/36. 9 = 122 persons Productivity = KLOC/Effort = 400/4528 = 0. 0884 KLOC/person-month

COCOMO 2 Ø COCOMO was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch. Ø Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development.

COCOMO 2 Ø COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. Ø The sub-models in COCOMO 2 are: — Application composition model. This models the effort required to develop systems that are created from reusable components. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance 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

Application Composition Model

Application Composition Model Assess object counts: Estimate the number of screens, reports and 3 GL components that will comprise this application. Classification of complexity levels: o simple o medium o Difficult Assign complexity weight to each object : The weights are used for three object types o screen o report o 3 GL components

Application Composition Model Determine object points: Add all the weighted object instances to get one number and this known as object-point count. Compute new object points: We have to estimate the percentage of reuse to be achieved in a project. Depending on the percentage reuse, the new object points (NOP) are computed. Object Points * (100 - %reuse) NOP = ---------------------- 100 NOP are the object points that will need to be developed and differ from the object point count because there may be reuse( percentage of the Product development which is accomplished by exploiting the existence of existing component's design-or-development effort).

Application Composition Model Calculation of productivity rate: The productivity rate can be calculated as: Productivity rate (PROD) = NOP/Person month Compute the effort in Persons-Months: When PROD is known, we may estimate effort in Person-Months as: NOP Effort in PM = ------ PROD

COCOMO 2 -Example Consider a database application project with the following characteristics: Ø The application has 4 screens with 4 views each and 7 data tables for 3 servers and 4 clients. Ø The application may generate two report of 6 sections each from 07 data tables for two server and 3 clients. There is 10% reuse of object points. Ø The developer’s experience and capability in the similar environment is low. The maturity of organization in terms of capability is also low. Calculate the object point count, New object points and effort to develop such a project.

COCOMO 2 -Example

COCOMO 2 -Example

COCOMO 2 -Example

Make/Buy Decision It is often more cost effective to acquire rather than develop software Ø Managers have many acquisition options Ø — Software may be purchased (or licensed) off the shelf — “Full-experience” or “partial-experience” software components may be acquired and integrated to meet specific needs — Software may be custom built by an outside contractor to meet the purchaser’s specifications Ø The make/buy decision can be made based on the following conditions — Will the software product be available sooner than internally developed software? — 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?

Creating a Decision Tree Ø The steps just described can be augmented using statistical techniques such as decision tree analysis. 16 For example, Figure depicts a decision tree for a software based system X. In this case, the software engineering organization can (1)- build system X from scratch, (2)- reuse existing partial-experience components to construct the system, (3)- buy an available software product and modify it to meet local needs, or (4)- contract the software development to an outside vendor.

Decision Tree

Decision Tree Ø If the system is to be built from scratch, there is a 70 percent probability that the job will be difficult. Ø Using the estimation techniques discussed earlier, the project planner estimates that a difficult development effort will cost $450, 000. Ø A “simple” development effort is estimated to cost $380, 000. The expected value for cost, computed along any branch of the decision tree is where i is the decision tree path. For the build path

Decision Tree

Decision Tree Ø It is important to note, however, that many criteria—not just cost— must be considered during the decision-making process. Availability, experience of the developer/ vendor/contractor, conformance to requirements, local “politics, ” and the likelihood of change are but a few of the criteria that may affect the ultimate decision to build, reuse, buy, or contract.