SE COMPUTER SEM-II

SOFTWARE ENGINEERING

UNIT –III ESTIMATION AND SCHEDULING

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

Unit –III Estimation and Scheduling

• Project planning

• Scope and feasibility

• Project resources

• Estimation of project cost and effort

• Decomposition techniques
• Empirical estimation models

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

Project Planning / 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
▪ 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
Task Set for Project Planning

• Establish project scope

• Determine feasibility
• Analyse risks
• Define required resources
o Determine human resources required
o Define reusable software resources
o Identify environmental resources
• Estimate cost and effort
o Decompose the problem
o Develop two or more estimates using different approaches
o Reconcile the estimates
• Develop a project schedule
o Establish a meaningful task set
o Define a task network
o Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms
Scope and Feasibility / Software Scope

• Software scope describes

o The functions and features that are to be delivered to end users
o The data that are input to and output from the system
o The "content" that is presented to users as a consequence of using the software
o The performance, constraints, interfaces, and reliability that bound the system
• Scope can be define using two techniques
o A narrative description of software scope is developed after communication
with all stakeholders
o A set of use cases is developed by end users
• After the scope has been identified, two questions are asked
o Can we build software to meet this scope?
o Is the project feasible?
• Software engineers too often rush (or are pushed) past these questions
• Later they become mired in a project that is doomed from the onset
Scope and Feasibility / 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 it 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?
Project Resources/ 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

People
o Number required
o Skills required
o Geographical location
Development Environment
o Software tools
o Computer hardware
o Network resources
Reusable Software Components
o Off-the-shelf components
o Full-experience components
o Partial-experience components
o New components
Human Resources

❑ 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
• Modifications that are required have a fair degree of risk
• 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
Factors Affecting Project Estimation

The accuracy of a software project estimate is predicated on

❑ The degree to which the planner has properly estimated the size (e.g., KLOC)

of the product to be built

❑ The ability to translate the size estimate into human effort, calendar time,

and money
❑ The degree to which the project plan reflects the abilities of the software

team
❑ The stability of both the product requirements and the environment that

supports the software engineering effort

Project Estimation Options

❑ Options for achieving reliable cost and effort estimates

1. Delay estimation until late in the project (we should be able to achieve 100%
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 estimation models for software cost and effort
estimation
❑ Option #1 is not practical, but results in good numbers
❑ Option #2 can work reasonably well, but it also relies on other project
influences being roughly equivalent
❑ Options #3 and #4 can be done in tandem to cross check each other
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

Decomposition Techniques

❑ Before an estimate can be made and decomposition techniques applied, the

planner must
❑ Understand the scope of the software to be built
❑ Generate an estimate of the software’s size

Then one of two approaches are used

❑ Problem-based estimation

❑ Based on either source lines of code or function point estimates

❑ Process-based estimation
❑ Based on the effort required to accomplish each task
Approaches to Software Sizing

❑ Function point sizing

❑ Develop estimates of the information domain characteristics.
❑ Standard component sizing
❑ Estimate the number of occurrences of each standard component
❑ Use historical project data to determine the delivered LOC size per standard
component
❑ Change sizing
❑ Used when changes are being made to existing software
❑ Estimate the number and type of modifications that must be accomplished
❑ Types of modifications include reuse, adding code, changing code, and deleting
code
❑ An effort ratio is then used to estimate each type of change and the size of the
change
Problem-Based Estimation

❑ Start with a bounded statement of scope

❑ Decompose the software into problem functions that can each be estimated
individually
❑ Compute an LOC or FP value for each function
❑ Derive cost or effort estimates by applying the LOC or FP values to your
baseline productivity metrics (e.g., LOC/person-month or FP/person-month)
❑ Combine function estimates to produce an overall estimate for the entire
project
❑ In general, the LOC/pm and FP/pm metrics should be computed by project
domain
❑ Important factors are team size, application area, and complexity
❑ LOC and FP estimation differ in the level of detail required for decomposition
with each value
❑ For LOC
❑ decomposition of functions is essential and should go into considerable detail
(the more detail, the more accurate the estimate)
❑ For FP
❑ decomposition occurs for the five information domain characteristics and the 14
adjustment factors , External inputs, external outputs, external inquiries,
internal logical files, external interface files
❑ 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:
S = (Sopt + 4Sm + Spess)/6
❑ Historical LOC or FP data is then compared to S in order to cross-check it
Process-Based Estimation

❑ Identify the set of functions that the software needs to perform as obtained
from the project scope
❑ Identify the series of framework activities that need to be performed for each
function
❑ Estimate the effort (in person months) that will be required to accomplish
each software process activity for each function
❑ Apply average labor rates (i.e., cost/unit effort) to the effort estimated for
each process activity
❑ Compute the total cost and effort for each function and each framework
activity
❑ Compare the resulting values to those obtained by way of the LOC and FP
estimates
❑ If both sets of estimates agree, then your numbers are highly reliable
❑ Otherwise, conduct further investigation and analysis concerning the function
and activity breakdown
 Functional Point (FP) Analysis
• Allan J. Albrecht initially developed function Point Analysis in 1979 at
IBM
• FPA is used to make estimate of the software project, including its
testing in terms of functionality or function size of the software
product.
• However, functional point analysis may be used for the test
estimation of the product
• Objectives of FPA:
• The basic and primary purpose of the functional point analysis is to
measure and provide the software application functional size to the
client, customer, and the stakeholder on their request.
• Further, it is used to measure the software project development
along with its maintenance, consistently throughout the project
irrespective of the tools and the technologies.
Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports
3. Number of external inquiries (EQ) Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces (EIF) Shared databases and shared routines.

The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point) of
the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement
parameter type.
The Function Point (FP) is thus calculated with the following formula.
• FP = Count-total * [0.65 + 0.01 * ∑(fi)]
= Count-total * CAF
• where Count-total is obtained from the above Table.
• CAF = [0.65 + 0.01 *∑(fi)]

• ∑(fi) is the sum of all 14 questionnaires and show the

complexity adjustment value/ factor-CAF (where i ranges from
1 to 14).
• Usually, a student is provided with the value of ∑(f i)
• Also note that ∑(fi) ranges from 0 to 70, i.e.,
• 0 <= ∑(fi) <=70
• and CAF ranges from 0.65 to 1.35 because
• When ∑(fi) = 0 then CAF = 0.65
• When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 =
1.35
• Based on the FP measure of software many other metrics
can be computed:
• Errors/FP
• $/FP.
• Defects/FP
• Pages of documentation/FP
• Errors/PM.
• Productivity = FP/PM (effort is measured in person-months).
• $/Page of Documentation.
• Example: Compute the function point, productivity, documentation, cost per function for
the following data:
• Number of user inputs = 24
• Number of user outputs = 46
• Number of inquiries = 8
• Number of files = 4
• Number of external interfaces = 2
• Effort = 36.9 p-m
• Technical documents = 265 pages
• User documents = 122 pages
• Cost = $7744/ month
• Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43
FP = Count-total * [0.65 + 0.01 *∑(fi)]
= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408
Total pages of documentation = technical document + user document
= 265 + 122 = 387pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94
Example 2: Given the following values, compute function point when all complexity
adjustment factor (CAF) and weighting factors are average.
User Input = 50 User Output = 40 User Inquiries = 35 User Files = 6
External Interface = 4

Scale varies from 0 to 5 according to character of Complexity Adjustment Factor

(CAF). Below table shows scale:
0 - No Influence 1 - Incidental 2 - Moderate 3 - Average 4 -
Significant 5 - Essential
As complexity adjustment factor is average (given in question), hence,scale = 3.

F = 14 * 3 = 42
CAF = 0.65 + ( 0.01 * 42 ) = 1.07
 COCOMO Model
• Boehm proposed COCOMO (Constructive Cost Estimation Model) in
1981
• COCOMO predicts the efforts and schedule of a software product
based on the size of the software.
• The necessary steps in this model are:
• Get an initial estimate of the development effort from evaluation of
thousands of delivered lines of source code (KDLOC).
• Determine a set of 15 multiplying factors from various attributes of
the project.
• Calculate the effort estimate by multiplying the initial estimate with
all the multiplying factors i.e., multiply the values in step1 and step2.
• To determine the initial effort Ei in person-months the
equation used is of the type is shown below
Ei=a*(KDLOC)b
• In COCOMO, projects are categorized into three types:
• Organic
• Semidetached
• Embedded
• 1.Organic: A development project can be treated of the organic type, if the
project deals with developing a well-understood application program, the
size of the development team is reasonably small, and the team members
are experienced in developing similar methods of projects. Examples of
this type of projects are simple business systems, simple inventory
management systems, and data processing systems.
• 2. Semidetached: A development project can be treated with
semidetached type if the development consists of a mixture of
experienced and inexperienced staff.
• Team members may have finite experience in related systems but may be
unfamiliar with some aspects of the order being developed. Example of
Semidetached system includes developing a new operating system (OS), a
Database Management System (DBMS), and complex inventory
management system.
• 3. Embedded: A development project is treated to be of an embedded
type, if the software being developed is strongly coupled to complex
hardware, or if the stringent regulations on the operational method
exist. For Example: ATM, Air Traffic control.
• For three product categories, Bohem provides a different set of
expression to predict effort (in a unit of person month)and
development time from the size of estimation in KLOC(Kilo Line
of code) efforts estimation takes into account the productivity
loss due to holidays, weekly off, coffee breaks, etc.
• According to Boehm, software cost estimation should be done
through three stages:
• Basic Model
• Intermediate Model
• Detailed Model
Basic COCOMO Model:
• The basic COCOMO model provide an accurate size of the project parameters. The
following expressions give the basic COCOMO estimation model:
• Effort is the total effort required to develop the software product, expressed in person
months (PMs).
• Estimation of development effort
• For the three classes of software products, the formulas for estimating the effort based
on the code size are shown below:
• Organic: Effort = 2.4(KLOC) 1.05 PM
• Semi-detached: Effort = 3.0(KLOC) 1.12 PM
• Embedded: Effort = 3.6(KLOC) 1.20 PM
• Estimation of development time
• For the three classes of software products, the formulas for estimating the
development time based on the effort are given below:
• Organic: Tdev = 2.5(Effort) 0.38 Months
• Semi-detached: Tdev = 2.5(Effort) 0.35 Months
• Embedded: Tdev = 2.5(Effort) 0.32 Months
• Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached &
embedded.
• Solution: The basic COCOMO equation takes the form:
• Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
• (i)Organic Mode
• E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
• (ii)Semidetached Mode
• E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
• (iii) Embedded Mode
• E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM
 2. Intermediate Model:

• The basic Cocomo model considers that the effort is only a function of the
number of lines of code and some constants calculated according to the
various software systems.
• The intermediate COCOMO model recognizes these facts and refines the
initial estimates obtained through the basic COCOMO model by using a set
of 15 cost drivers based on various attributes of software engineering.
• Classification of Cost Drivers and their attributes:
• (i) Product attributes -
• Required software reliability extent
• Size of the application database
• The complexity of the product
• Hardware attributes -
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
• Personnel attributes -
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
• Project attributes -
• Use of software tools
• Application of software engineering methods
• Required development schedule
The cost drivers are divided into four categories:
• Intermediate COCOMO equation:
• E=ai (KLOC) bi*EAF
D=ci (E)di
• Coefficients for intermediate COCOMO

Project ai bi ci di

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
3. Detailed COCOMO Model:
• Detailed COCOMO incorporates all qualities of the standard version with an
assessment of the cost driver?s effect on each method of the software
engineering process.
• The detailed model uses various effort multipliers for each cost driver property.
In detailed cocomo, the whole software is differentiated into multiple modules,
and then we apply COCOMO in various modules to estimate effort and then sum
the effort.
Reconciling Estimates

❑ The results gathered from the various estimation techniques must be

reconciled to produce a single estimate of effort, project duration, and cost
❑ If widely divergent estimates occur, investigate the following causes
❑ The scope of the project is not adequately understood or has been
misinterpreted by the planner
❑ Productivity data used for problem-based estimation techniques is
inappropriate for the application, obsolete (i.e., outdated for the current
organization), or has been misapplied
❑ The planner must determine the cause of divergence and then reconcile the
estimates
Empirical Estimation Models

(Empirical: Based on experiments and practical experience)

❑ 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
❑ The empirical data for these models are derived from a limited sample of

projects
❑ Consequently, the models should be calibrated to reflect local software
development conditions
COCOMO

❑ Stands for COnstructive COst MOdel

❑ Introduced by Barry Boehm in 1981 in his book “Software Engineering
Economics”
❑ Became one of the well-known and widely-used estimation models in the
industry
❑ It has evolved into a more comprehensive estimation model called
COCOMO II
❑ COCOMO II is actually a hierarchy of three estimation models
❑ As with all estimation models, it requires sizing information and accepts it in
three forms:
1. object points
2. function points
3. lines of source code
COCOMO Models

Application composition model

❑ Used during the early stages of software engineering when the following are

important
❑ Prototyping of user interfaces
❑ Consideration of software and system interaction
❑ Assessment of performance
❑ Evaluation of technology maturity
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
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?