SOFTWARE ESTIMATION

LECTURE NOTES 4
 SOFTWARE ESTIMATION
Software Project Management begins with a set of activities
that are collectively called Project Planning.

Software Project Planning encompasses Five major activities:

1. Project Estimation
2. Project Scheduling
3. Risk Analysis
4. Quality management Planning
5. Change Management Planning

ESTIMATION

Software Project Management begins with a set of activities that are

collectively called Project Planning.

Before a Project begins Project Manager must Estimate

- The Work to be done
- The Resources that will be required.
- The Time that will be “elapsed” from start to finish.
 SOFTWARE ESTIMATION

• The Software Team must establish a Project

Schedule that defines :-

a) Software Engineering tasks

b) Milestones,
• c) Responsible for conducting each task,
d) Inter-task dependencies. .

• Estimation lays a foundation for all other Project

Planning activities and that Project Planning pro-
vides the “ROAD MAP” for successful
Software Engineering.
 SOFTWARE ESTIMATION
• Estimation is as much ‘’Art’’ as it is Science. How-
ever this important activity need not be conducted
in a haphazard manner.

• Software Estimation begins with a description of

the “SCOPE OF SOFTWARE PRODUCT”.
Until the Scope is “Bounded” it is not possible to develop
a meaningful Project Estimate.

• The ‘’PROBLEM’’ is then decomposed into a set

of smaller Problems and each of these is
Estimated using historical data (Metrics) and/or
previous experience as a guide.

• The Problem Complexity and Risk are then consid-

ered before final Estimate is made.
 SOFTWARE ESTIMATION
Estimation of Recourses, Cost and Schedule for a Software Eng
neering Effort requires:-

- Experience,
- Access to good historical information (Project Metrics)
- Courage to commit to Quantitative predictions
(when Quantitative information is all that exists).

Estimation carries inherent “RISK”, and this Risk leads to unce

tainty.

The availability of Historical Information (Project Metrics)

has a strong influence on Estimation Risk.

Estimation Risk is measured by the degree of uncertainty

in the Quantitative Estimates establish for Recourses, Cost and
Project Schedule.

Estimation Risk becomes dangerously high when

Project Scope is poorly understood or Project Require-
ments are subject to changes.
 SOFTWARE ESTIMATION
SOFTWARE SCOPE AND FEASIBILITY
Software Scope Describes:

- The function and features that are to be delivered to end-users.

- The data that are input and output.

- The “Content” that is presented to user as a consequence of us-

ing the software.

- Performance, constraints, reliability and interfaces that bounds

the system.

Software Scope is defined using one of the following techniques:

- A narrative description of software scope is developed after com-

munication with all stakeholders.

- A set of Use-Cases are developed by end-users.

 SOFTWARE ESTIMATION

SCOPE CONSIDERATION

Functions described in the “Statement of Scope”

or within the Use-Cases are evaluated and in some
cases refined to provide more detail point to the be-
ginning of Estimation.

• Because both Cost and Schedule Estimates are func-

tionally oriented, some degree of functional decom-
position is useful.
• Performance considerations encompass Processing
and Response Time requirements.
• Constraints identify limits placed on the software by
hardware, available memory size on other existing
system.
 SOFTWARE ESTIMATION

SCOPE CONSIDERATION

Once the Project Scope has been identified it is reasonable to ask

yourself:-

- Can we build the Software to meet this scope?

- Is the Project feasible?

Often Software Engineers rush past these questions only to be-

come mired (become stuck) in a Project that is doomed from the
onset.
Since not everything in real life is feasible, the Software Feasibility
is emphasized in Estimation.

Software Feasibility has four solid dimensions:

- Technology
- Finance
- Time
- Resources
 SOFTWARE ESTIMATION
SOFTWARE SCOPE AND FEASIBILITY

Once the Software Scope and Feasibility have been identified the second
task is Estimation of the “RESOURCES” required to accomplish the Soft-
ware Development Effort.

RESOURCES

The three major categories of Software Engineering Resources:

- People
- Reusable software components.
- Development environment (H/W, S/W Tools)

Each Resources is specified with four Characteristics:

- Description of the resource.

- A statement of availability.
- Time when resources will be required.
- Duration of the time that resource will be applied.

NOTE: The last two characteristics can be viewed as a “Time Window”.

Availability of the Resource for a specified window must be
 SOFTWARE ESTIMATION
1. HUMAN RESOURCES

- The Project Planner begins by evaluating Software

Scope and selecting the ‘’skills’’ required to complete
development.

Both Organizational position (e.g. Manager, Senior

Software Engineer etc and the specialty
(e.g Database Telecommunication, client/server etc)
and the Location of each human resource is specified.

- The Number of People required for a Software

Project can be determined only after an Estimate of
Development Effort (e.g. Person-months) is made.
 SOFTWARE ESTIMATION
2. REUSABLE SOFTWARE RESOURCES

The Reusable Software Resource categories:-

1. OFF-THE-SHELF COMPONENTS
2. FULL-EXPERIENCE COMPONENTS
3. PARTIAL-EXPERINECE COMPONENTS
4. NEW COMPONENTS:

Guidelines for Planning Reusable Resource Components :-

1. If Off-the-Shelf Components meet Project requirement acquire them. The

cost of the off-the-shelf components will almost always be less than the
cost to develop equivalent software. Also risk is low.

2. If full-experience components are available, the risk associated with modi-

fication and integration are generally acceptable.

3. If Partial-Experience Components are available, the use of them for cur-

rent Project must be carefully analyzed.
- If extensive modification is required proceed carefully since
the cost to modification can sometimes be greater than the
cost to develop new components also Risk is high.
 SOFTWARE ESTIMATION
3. ENVIRONMENTAL RESOURCES

The Software Engineering Environment (SEE) corporate

Hardware and Software / NetWare.

H/W provides a platform that support the tools required to

produce Work Products that are outcome of good Software
Engineering practice.

When a System is to be engineered the Software team may

require access to H/W elements being developed by other
Engineering teams.

Software Project Planner must specify each Hardware ele-

ment and the Time window for HW / SW and verify that
these resources will be available.
 SOFTWARE ESTIMATION
SOFTWARE PROJECT ESTIMATION

Software is the most expensive element of virtually all Com-

puter-Based System.

For complex, custom System, a large Cost Estimation error can

make the difference between profit and loss. Cost overrun can
be disastrous.

Software Cost and Effort Estimation will never be an exact sci-

ence. Because too many Variables Factors can affect the ulti-
mate Cost of Software and Effort applied to develop it.

Variable Project Factors:

- Human Factor
- Technical Variable Factors
- Environmental Factors
- Political Factors
 SOFTWARE ESTIMATION
OPTIONS FOR RELIABLE ESTIMATES

a) Delay Estimation until late in the Project (obviously we can achieve

100% accurate Estimates after the Project is complete!)

b) Base Estimates on similar Projects that have already been completed.

c) Use one or more Empirical Models for Software cost and Effort
Estimation.

d) Use relatively simple Decomposition Techniques to generate Project Cost

and Effort Estimates.

Each of the viable Software Cost Estimation options are only as good as the His-
torical data used to seed the estimation.

If no Historical data (metrics) exist, costing rest on a very shaky foundations.

 SOFTWARE ESTIMATION
DECOMPOSITION TECHNIQUES

Software Project Estimation is a form of Problem solving, and in most

cases, the Problem to be solved is too complex in one piece. For this reason,
we Decompose the problem, re-characterizing it as a set of smaller prob-
lems.

Estimation uses one or both form of the two different partitioning point of
views:-

- Decomposition of the Problem

- Decomposition of the Process

Before an Estimate can be made , the Project Planner must understand the
Scope of the Software to be built and generate an Estimate according to
the ‘’Size of Software’’.
 SOFTWARE ESTIMATION
SOFTWARE PROJECT SIZING:
Accuracy of a Software Project Estimate is predicted on a number of things:

1. The degree to which the Planner has properly Estimated the Size of
the Product to be built.
2. The ability to translate the Size Estimate into Human-effort (Calendar
Time and Money)
3. The degree to which the Project Plan reflects the abilities of Software
team.
4. The stability of Product requirement s and the environment that
supports the Software Engineering effort.

• Sizing represents the Project Planner’s first major challenge since a

Project Estimate is only as good as the Estimate of the Size of the work
to be accomplished

• Size refers to a Quantifiable outcome of the Software Project.

- If a Direct approach to Sizing is taken size can be measured in (LOC)

- If an Indirect approach is taken that the sizing approach is represented as FP
 SOFTWARE ESTIMATION
SOFTWARE PROJECT SIZING:

There are Four Different Sizing Approaches:

1. Fuzzy Logic Sizing

2. Function Point Sizing
3. Standard Component Sizing
4. Change Sizing

• The result of each Sizing approaches must be combined statistically to

create Expected-Value Estimate.” This is accomplished by determining
the following values for-

- Optimistic (Sopt) (Lowest estimation value)

- Most Likely (Sm) (Moderate estimation value)
- Pessimistic (Spess) (High estimation value)

• Combine the Value Sizes using the following Equation to determine the
Expected Value Estimation  S =[(Sopt + (4 * Sm) + Spess)] / 6

- Once the Expected Value for the Estimation variable has been
determined, Historical (LOC) or (FP) Productivity data are applied.
 SOFTWARE ESTIMATION

PROBLEM – BASED ESTIMATION TECHNIQUES

• LOC and FP data are used in two ways during Software Esti-
mation.

• As an Estimation variable to “Size” each element of Software.

• As a Baseline Metrics collected from past project and used in

conjunction with estimation variable to develop cost and effort
projections.

• LOC and FP Estimations are different Estimation techniques.

Yet both have number of characteristics in common.
 SOFTWARE ESTIMATION

PROBLEM – BASED ESTIMATION TECHNIQUES

• The Project Planner begins with a bounded Statement of Software

Scope and from this Statement attempts to Decompose Software
problem Functions that can be Estimated individually.

- (LOC) or (FP) is then estimated for each Function.

- Baseline Productively Metrics are then applied to the appropriate

Estimation Variable and Cost or Effort for the Function is de-
rived.

Function Estimates are combined to produce an overall

Estimate for the entire Project.
 SOFTWARE ESTIMATION

PROBLEM – BASED ESTIMATION TECHNIQUES

The (LOC) and (FP) Estimation Techniques differ in the level

of detail required for Decomposition and the target of partitioning.

When (LOC) is used as the Estimation variable Decomposition is

absolutely essential and often taken to considerable levels of de-
tail.

For (FP) Estimation, Decomposition works differently. Besides

focusing on each Function’s Information Domain characteristics
it also takes into consideration the Complexity Adjustment Factor
values.
 SOFTWARE ESTIMATION

PROBLEM – BASED ESTIMATION TECHNIQUES

Regardless of Estimation variable that is used the Project Planner

begins by Estimating a range of Values for each Function or
Information domain value.

Using Historical data or intuition, the Planner Estimates

‘’Expected Value’’ considering the following variables:

Optimistic Value,
Most Likely Value
Pessimistic Value
S = [Opt value + (4 * Most Likely) + Pess value] / 6
Once the Expected Value has been determined, Historical (LOC)
and (FP) Productivity data are applied.
 SOFTWARE ESTIMATION
PROBLEM – BASED ESTIMATION TECHNIQUES
AN EXAMPLE OF (LOC) BASED ESTIMATION

FUNCTIONS ESTIMATED LOC

- User Interface and Control Facilities (UICF) 2,300

- Two Dimensional Analysis (2DGA) 5.300
- 3D Geometric Analysis Function (3DGA) 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
(3DGA) Function as follows:-

Optimistic Estimation = 5,000 LOC

Most Likely Estimation = 6,700 LOC
Pessimistic Estimation = 9.000 LOC

S = [Opt value + (4 * Most Likely) + Pess value] / 6

S = [5000 + ( 4 * 6,700) + 9,000] / 6  6,800

 SOFTWARE ESTIMATION
AN EXAMPLE OF (LOC) BASED ESTIMATION
Historical data obtained from the Metrics indicates the following Organizational Aver-
ages:

 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

 SOFTWARE ESTIMATION
AN EXAMPLE OF FUNCTION POINT (FP-BASED) ESTIMATION

INFORMATION DOMAIN VALUE Opt Most Pess. Est. Weighting FP

Likely Count Factor
(Expected Count
Value )

No. of External Inputs 20 24 30 24 4 97

No. of External Outputs 12 15 22 16 5 78

No. of External Enquiries 16 22 28 22 5 88

No. of Internal Logical Files 4 4 5 4 10 42

No. of External Interface Files 2 2 3 2 7 15

COUNT TOTAL (∑ FP) 320

• For this example we assume Average Complexity Weighting Factor.

• Each of the Complexity Weighting Factor is estimated and the Complexity Adjustment Factor is
computed using the Complexity Factor Table as shown on the next page

• Expected Value is calculated for each Information Domain using :-

S = [Opt value + (4 * Most Likely) + Pess value] / 6
 SOFTWARE ESTIMATION
AN EXAMPLE OF FUNCTION POINT (FP-BASED) ESTIMATION

COMPLEXITY FACTOR ASSUMPTIONS (Based on the Answers for 14 Questions)

FACTOR VALUE
(Fi)
------------------------------------------------------------------
1. Back-up and Recovery ? 4
2. Data Communication ? 2
3. Distributed Processing ? 0
4. Performance Critical ? 4
5. Existing Operational Environment ? 3
6. On-line Data Entry ? 4
7. Input transactions over multiple Screens? 5
8. Online Updates ? 3
9. Information Domain Values Complex ? 5
10. Internal Processing Complex? 5
11 Code Designed for reuse? 4
12. Conversion / installation in Design? 3
13. Multiple Installations? 5
14. Application Designed for change ? 5
===========================================
∑ (Fi) 52

Estimated Number of Adjusted FP is derived using the following Formula:-

FP ESTIMATED = (FP COUNT TOTAL * [COMPLEXITY ADJUSTMENT FACTOR]

Complexity Adjustment Factor is [0.65+ (0.01*∑(Fi))]

 Complexity Adjustment Factor = [0.65 + (0.01 * 52)] = 1.17
ESTIMATED FP COUNT = (320 * 1.17) = 375
 SOFTWARE ESTIMATION
AN EXAMPLE OF (FP) BASED ESTIMATION

Historical data obtained from the Metrics indicates the following Organizational Av-
erages:-

- Average Productivity for this type of Application is 6.5 FP / Per Month

- Average Labor Cost is $8,000 Per Month.

Cost for a Function Point (COST / FP ) is calculated as follows

Cost / FP = (8000 / 6.5) = $1230 (Cost for 1 FP)

Total Estimated Project Cost and Project Effort can be calculated as:-

Considering that the Total Adjusted FP ( ∑ FP) is 375 FP :-

 Total Estimated Project Cost = (375 * 1230) = $461,000

 Total Estimated Project Effort = (375 / 6.5) = ~ 58 Man Months

 SOFTWARE ESTIMATION
ACTIVITY CC ANPEXAMPLE
RISK OF PROCESS-BASED
ENGINEERING ESTIMATIONCE
CONSTRUCTION TOTALS
L ANALYSIS RELEASE (Man
A Months)
N

Code Test
TASK Analysis Design

FUNCTIONS

UICF 0.50 2.50 0.40 5.00 n/a 8.40

2DGA 0.75 4.00 0.60 2.00 n/a 7.35
3DGA 0.50 4.00 1.00 3.00 n/a 8.50
CGDF 0.50 3.00 1.00 1.50 n/a 6.00
DBM 0.50 3.00 0.75 1.50 n/a 5.75
PCF 0.25 2.00 0.50 1.50 n/a 4.25
DAM 0.50 2.00 0.50 2.00 n/a 5.00
TOTALS 0.25 0.25 0.25 3.5 20.50 4.50 16.50 46.00
(∑ Months)

% EFFORT 1% 1% 1% 8% 45% 10% 36%

Notes: CC = Customer Communication CE = Customer Evaluation

• Based on Average Labor cost of $8,000 Per month
- Total Estimated Project Effort = 46 Person - Month
- Total Estimated Project Cost = (8,000 * 46) = $368,000
 SOFTWARE ESTIMATION
ESTIMATION WITH USE-CASES

Developing an Estimation approach with Use-Cases is problematic for the

following reasons:-

 Use-cases are described using many different formats and styles;

there is no standard form.

 Use-cases represent an external view (User’s view) of the Software

and are written at different levels of abstracttion.

 Use-cases do not address the complexity of the functions and

features that are described.

 Use-cases do not describe complex behavior (e.g interactions) that

involves many functions and features.

However, Use-cases can be used for Estimation, but only if they are consid-
ered within the context of the ‘’Structured Hierarch’’ that the Use- cases are
described.
 SOFTWARE ESTIMATION
ESTIMATION WITH USE-CASES

It is argued that any level of Use-case Structural Hierarchy :-

a) Can be described by no more than 10 Use-cases.

b) Each Use-case would contain no more than 30 distinct Scenarios.
(obviously more Scenarios require considerably more development efforts.)

Before Use-cases can be used for Estimation:-

a) The Level within the Structural Hierarchy is established,

b) The Average Length (in pages) of each Use-case is determined,
c) Type of Software is defined (eg. Real time, Business, Engineering / Scientific, etc)
d) Rough architecture for the System is considered

Once these characteristics are established, Emperical Data may be used to establish
the Estimated number of LOC or FP per Use-case (for each level of hierarchy).

The Structured Hierarchical data then used to compute the Effort required to de-
velop the System.
 SOFTWARE ESTIMATION
ESTIMATION WITH USE-CASES
LOC estimates = N * LOCavg + [(Sa / Sh - 1) + (Pa / Ph - 1)] * LOCadjust

Where: N = Actual number of Use-cases

LOC avg = Historical Average LOC / Use-case for this type Subsystem
LOC adjust = Adjustment based on ‘n %’ of LOC avg
n = Defined locally and represents the difference between this Project and
the ‘Average’ Project
Sa = Actual Scenarios per Use-case
Sh = Average Scenarios per Use-case for this type Subsystem
Pa = Actual Pages per Use-case
Ph = Average Pages per Use-case for this type of Subsystem

The above expression is used to develop a rough Estimation of the Number of LOC,
based on the Actual number of Use-cases Adjusted by the number of Scenarios and Page
length of the Use-cases.

The Adjustment represents up to ‘n %’ of the Historical Average LOC per Use-case.

 SOFTWARE ESTIMATION
AN EXAMPLE OF USE-CASE BASED ESTIMATION

Consider the CAD Software example again for Use-case

Estimation purpose.

CAD Software is composed of three Subsystem groups:-

1. User Interface Subsystem includes (UICF)

2. Engineering Subsystem group includes the (2DGA) (3DGA) and (DAM)

Subsystems.

3. Infrastructure Subsystem group includes (CGDF) and PCF Subsys-

tems)
 SOFTWARE ESTIMATION
AN EXAMPLE OF USE-CASE BASED ESTIMATION
1. User Interface Subsystem (UICF).

- Described with 6 Use-cases

- Each Use-case is described by no more than 10 Scenarios
- Each Use-case has an average of 6 Pages

2. Engineering Subsystem (2DG, 3DG, DAM)

- Described with 10 Use-cases

- Each Use-case has no more than 20 Scenarios
- Each use case has an average of 8 Pages

3. Infrastructure Subsystem group (CGDF, PCF)

- Described with 5 Use-cases

- Each use-case has an average of 6 Scenarios
- Each Use-case has an average of 5 Pages
 SOFTWARE ESTIMATION
Based on n = 30% Difference the following tabe is created for USE-CASE Based Estimation

Use- Scenarios Pages Scenarios Pages LOC LOC

SUBSYSTEMS Cases Estimates
(N) (Sa) (Pa) (Sh) (Ph)

USER INTERFACE 6 10 6 12 5 560 3,366

ENGINEERING 10 20 8 16 8 3100 31,233

GROUP

INFRASTRUCTURE 5 6 5 10 6 1650 7,970

GROUP

TOTAL
LOC ESTIMATES 42,568
 SOFTWARE ESTIMATION
USE CASE BASED ESTIMATION
Let us consider the calculations for User Interface Subsystem based on 30% difference between
this project and Actual Project (n = 30%)

Historical data obtained from Metrics indicates that User Interface Software requires:-

 An Average (LOC avg) of 800 LOC per Use-case when the Use-case has no more than 12 Sce-
narios and described in less than 5 Pages.

- LOC avg = 800

 When considering 30% Differences between this Project and Average Projects
 LOC Adj = (800 * 0.30) = 560

Using the formulae below we can calculate LOC Estimates for each Subsystem group

LOC Estimates = N * LOC avg + [(Sa / Sh - 1) + (Pa / Ph - 1)] * LOC adjust

Historical data from Metrics indicates the following Averages

- Average Productivity rate 620 LOC / Month
- Average Salary of $8000 Per month,
Total Project Cost and Total Development Effort can be calculated as follows:
- Cost / LOC = (8000 / 620) = $13 (Cost for 1 LOC)
- Total Project Estimates = (42,568 * 13) = $552,000
- Total Development effort = (42,568 / 620 ) = 68 Person- Months
 SOFTWARE ESTIMATION
RECONCILING ESTIMATES

The Problem Based Estimation Techniques dicussed so far each gave different
Cost and Effort Estimate results which must be reconciled to produce a single
Estimate of Effort, Project Duration or Cost.

Examination of the four different Problem-Based Estimation techniques

indicate different Total Estimated Efforts for the CAD Software range from :

 46 Person-months to a high of 68 Person-months

 The Average Estimate Of Efforts is 56 Person-months.

 The variation from Average estimate is approximately 18% on the low side
and 21% on the high side.
 SOFTWARE ESTIMATION
RECONCILING ESTIMATES

What Happens When Agreement Between Estimates is poor?

The answer to this question requires a re-evoluation of information used to make the
Estimates.

Wedely divergent Estimate can often be traced to one of the two causes.

1. The Scope of the Project is not adequately understood or has been

misinterpreted by the Project planner.

2. Productivity data used for Problem-Base Estimation Techniques is

inappropriate for the Application.

Productivity Data is either obsolute (no longer accurately reflects the Software
Engineering Organization) , or has been misapplied.

The Project Planner must determine the cause of divergence and then reconcile the
Estimates.
 SOFTWARE ESTIMATION
EMPIRICAL ESTIMATION MODELS

An Estimation model for Computer Software uses Empirically derived formulas to

predict Effort as a Function of LOC or FP.

Values for LOC and FP are estimated using LOC based Estimations and FP Based
Estimations.

 The resultant Values out of these Estimation are plugged into the Estimation Model.

The Empirical data that support most Estimation Models are derived from a
limited sample of Projects. For this reason, no Estimation Model is appropriate for all
Classes of Software and in all Development Environments.

 Therefore, the results obtained from such Models must be used judiciously.

An Estimation Model should be calibrated to reflect local conditions.

The Estimation Model should be tested by applying data collected from completed
projects, plugging the data into model, and then comparing Actual to Predicted results.

 If aggrement is poor the Estimation Model must be tuned and reflected before it can be used.
 SOFTWARE ESTIMATION
THE STRUCTURE OF ESTIMATION MODEL

A typical Estimation Model is derived using Regression Analysis on data

collected from past Software Projects.

The overall structure of such Model takes the from of :

c
E = A + B * (ev)

Where: A, B and c are Emperically derived constant.

E is Effort in Person-Months
(ev) is the Estimation Variable either LOC or FP)

In addition the relationship noted in the above equation , the majority of

Estimation Models have some from of Project Adjustment Components that
enables Effort in Person Months (E) to be Adjusted by other Projects
Characteristic such as Problem Complexity, Staff experience, and
Development environment).
 SOFTWARE ESTIMATION
PROPOSED LOC-ORIENTED ESTIMATION MODELS

0.91
WALSTON-FELIX MODEL E = 5.2 * (KLOC)
1.16
BAILEY-BASILI MODEL E = 5.5 + 0.73 (KLOC)
1.05
BOEHM SIMPLE MODEL E = 3.2* (KLOC)
1.047
DOTY MODEL FOR E = 5.288 * (KLOC)
----------------------------------------------------------------------------------------------------------
PROPOSED FP MODELS

ALBRECHT AND GAFFNEY Model E = -91.4 + 0.0355 FP

KEMERER MODEL E = -37 + 0.96 FP
SMALL PROJECT REGRESSION MODEL E= -12.88 + 0.405 FP

Each of these Models indicates that each will yield a different result for the
same value of LOC or FP.
The implication is clear- Estimation Models must be calibrated for local
needs.
 SOFTWARE ESTIMATION
THE COCOMO II MODEL (COnstructive COst MOdel)

COCOMO is most widely used and discussed Software Cost Estimation Model in the
Software Industry. The latest COCOMO Model II is a Hıerarch of Estımatıon
Models that address the following areas:.

1. APPLICATION COMPOSITION MODEL

Used during the early stages of Software Engineering when:

- Prototyping of User Interfaces,

- Consideration of Software and System Intraction,
- Assesment of Performance and Evaluating of Technology maturity are
paramount.

2. EARLY DESIGN STAGE MODEL

Used once Requirement have been stabilized and basic Software Arcchitecture
has been established.

3. POST-ARCHITECTURAL STAGE MODEL

Used during the Construction of the Software.

 SOFTWARE ESTIMATION
THE COCOMO II MODEL (Constructive Cost Model)

Like all other Estimation Model COCOMO II Model requires Sizing

Information.

Three different Sizing Options are audilable as part of the COCOMO Model Hierarchy:

 LINES OF SOURCE CODES (LOC)

 FUNCTION POINT (FP)
 OBJECT POINTS (OP)

 The COCOMO II Application Composition Model uses Object Points (OP) - an Indi-
rect Software measure that is computed using Counts of of :

1. No. of User Interface Screen

2. No. of Reports
3. No. of Reusable Components to be required to build the Application

Each Object instance is classified into one of threee complexity levels

(Simple , Medium and Difficult) using criteria suggested by Boehm.
 COMPLEXITY WEIGHTING
OBJECT TYPE FOR OBJECT
Simple TYPES TABLE
Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL Components 10

In essece Complexity is a Function of the Number of Source of the Client and Server
Data tables that are required to generate the Screen or Report and the number of
Views or Sections presented as part of the Screen or Report.

Once Complexity is determined, the number of Screens, Reports and Reusable

Components are weighted according to Boehm’s Complexity weighly of object table
(as above).

The Object Point Count is them determined by multiplying the Original number of
Objects instances by the Weighting Factor in the figure and then summing to obtain
a Total Object Point Count.
 SOFTWARE ESTIMATION
When Component-based development or General Software Reuse is to be applied
the percent of Reuse (%Reuse) is estimated and Object Point Count is adjusted:

NOP = (OBJECT POINTS) * [(100 - % REUSE)/100]

*** Where: NOP is defined as New Object Points

 To derive and Estimate of Effort on the computed NOP value, “Productivity

Rate” must be derived by considering the different Levels of Developer Experi-
ences and Development Environment Maturity as shown on the Productivity Rate
for Object Points table below
DEVELOPERS VERY LOW NORMAL HIGH VERY
EXPERIENCE / LOW HIGH
CAPABILITY

ENVIRONMENT MA- VERY LOW NORMAL HIGH VERY

TURITY CAPABILITY LOW HIGH

PROD RATE 4 7 13 25 50

Once the Productivity Rate has been determine an Estimate of Project Effort can be derived
as:
 SOFTWARE ESTIMATION
THE SOFTWARE EQUATION

The Software Equation is a multivariable Model that assumes a specific

distribution of Effort over the life of a Software Development Project.

The Model has been derived from Productivity Data collected for over
400 contemporary Software Projects.

Based on this data an Estimation Model of the form:-

0.333 3 4
E = [LOC * B /P] * (1 / t )

Where E = Effort in Person Month or Year

t = Project Duration Month/Year
B = Special Skills Factor
(For Small Programs (KLOC = 5 to 15)  B = 0.16 )
(For Programs where (KLOC > 70)  B = 0.39)
P = Productivity Parameters that reflects
- Overall Process Maturity and manupulate practices to the
extent to which good SE practices are used
- The level of Programming Languages used
- The State of Software Environmen
- The Skills and Exprience of team
- The Complexity of the Application.
 SOFTWARE ESTIMATION

THE SOFTWARE EQUATION

Typicalal values of P (Productivity Parameter) might be:-

P = 2,000 for the development of Real-time embeded Software

P = 10,000 for Telecominication and System Software
P = 12,000 for Scientific Software
P = 28,000 for Business System Applications.

The Productivity Parameters can be derived for local conditions using Historical
Data collected from past Development Efforts.

It is important to note that the Software Equation has two independent Parameters:

1. An Estimate of Size in LOC

2. An Indication of Project Duration in Calendar Months or Years
 SOFTWARE ESTIMATION
THE SOFTWARE EQUATION

To simplify the Estimation process Putnam and Myers suggested a set of

equations derived from the Software Equation.

Minimum Development Time is defined as:

0,43
tmin = 8.14 (LOC / P) in Calendar months for tmin > 6 Calendar months
3
E = 180 Bt in Person-month for E > or equal to 20 Person-months

Using Equation with P = 12,000

tmin = 8.14 (33200 / 12000) = 12.6 Calendar Months

3
E = 180 * 0.28 * (1.05) = 58 Person-months

The results of Software Equation corresponds favourable with the

Estimates developed with COCOMOS Model
 SOFTWARE ESTIMATION
ESTIMATION FOR OBJECT-ORIENTED PROJECTS

It is worth to supplement Conventional Software Cost Estimation Methods with an approach

that has been designed explicity for O-O Software.

LORENY AND KIDD SUGGEST THE FOLLOWING APPROACH:

1. Develop Estimates using effort decomposition, FP Analysis and any other Method
that is applicable for conventional applications.
2. Using O-O Analysis modeling, develop Use-case and determine a count Recognize that the
number of Use-cases may change as the project progresses.
3. From the Analysis model, determine the number of Key Classes.
4. Catagorize the type of Interface for the application and develop a Multiplier for Support
Class.

INTERFACE TYPE MULTIPLIER

(FOR SUPPORT CLASS)

• NO GUI (Without Graphical User interface) 2.00

• TEXT BASED USER INTERFACE 2.25
• GUI 2.50
• COMPLEX GUI 3.00
=============================================================
Multiply No. of Key Classes with Multiplier to obtain an Estimation for No. of Support Class.
 SOFTWARE ESTIMATION

ESTIMATION FOR OBJECT-ORIENTED PROJECTS (Cont’d)

5. Multiply the Total Number of Classes (Key + Support) by the AverageN num-
ber
of Work-Unit per Class (Suggestion 15-20 Person-day per Class).

6. Cross-check the Class-Based Estimate by Multiplying the Average Number of

Work-Unit Per Use-case

. ===============================================================

The previously mentioned Estimation Techniques can be used for any

Software Projects.

However, when a Software Team encounters an extremly Short Project

Duration (weeks rather than months) that is likely to have a continuing
stream of changes, Project Planning in General and Estimation in particular
should be abbreviated.
ESTIMATION FOR AGILE DEVELOPMENT

Since the Project Development Duration required for the development of a Soft-
ware Increment is quite short (typically 3 to 6 weeks for each version);

- The Estimation for Agile Development Approach serves two purposes:.

1. To ensure that the Number of scenarious to be included in the Increment,

conforms to the available Resources.

2. To establish a basis for allocating Effort as the Increment is developed.

ESTIMATION FOR WEB ENGINEERING PROJECTS
A Modified Function Point Measure, coupled with the Steps mentioned in Estima-
tion for Agile Development (Since Web Engineering Projects often adopt the Agile
Process Model) can be used to develop an Estimate for the Web Applications.

THE FOLLOWING INFORMATION DOMAINS ARE SUGGESTED FOR WEB APPLICATION ESTIMATION

INPUTS: Are each Input Screen or Form,each Maintenance Screen and each Tab ( If you use a
Tab not a book methaphore any where).

OUTPUTS: Are each Static Web page, each Dynamic Web Page Script (e.g. ASP, DHTML script)
and each report.

TABLES: Each Logical Table in the Database plus (If you are using XML to store data in a file),
each XML objects.

INTERFACES: Retain their Definition as Logical files units or out-of the System boundaries.

QUERIES: Are each external Published on use a Message-oriented Interface

(e.g . DCOM, COM external references)
ESTIMATION FOR WEB ENGINEERING PROJECTS
The Volume of Web Applictaions is best determined by collecting measures called
Preditor Variables” associated with the Applications such as:-

- Page Count, Medium Count, Function Count),

- Web Page Characteristics (eg: Page Complexity, Linking Complexity,
Graphic Complexity)
- Media Characterstic (Media duration)
- Functional Characteristic (eg. Code length, Reused Code length).

These measures can be used to develop Empirical Estimation Models for:-

- Total Project Effort,

- Page Authoring Effort,
- Medium Authoring Effort
- Script Effort.

However, further work remains to be done, before such Estimation Model can be used
with confidence.
THE MAKE / BUY DECISION

In many Software Applications areas, it is often more Cost effective to ac-

quire rather than develop Computer Software.

Software Engineering Managers are faced with a Make or Buy Decision

that can be further complicated by a number of acquisation options such
as:-

1. Software may be Purchased (or licensed) Off the Shelf Software

2. Full-experience or Partial-experience Software components may be

acquired and then modified and integrated to meet specific needs.

3. Software may be Custom built by an outside Contractor to meet the

Purchaser’s specifications.

The steps involved in Acquisation of Software are defined by the criticality

of the Software to be Purchased and the end-cost.

.
THE MAKE / BUY DECISION

In small PC based software, Cost is not a great concern but for more expensive
Software Products the following Guidliness can be applied.

FINAL ANALYSIS OF MAKE / BUY DECISION IS BASED ON THE FOLLOWING CONDITIONS

1. Will the Software Product be no available sooner than that for internally
developed Software?

2. Will the Cost of Acqusation plus the Cost of Custimazation be less than that
of Cost of the developing Software Internally?

3. Will the Cost of Outside Support (e.g. Maintenance Contract) be less than the
Cost of internal support?

These Conditions apply for each of the three Acquisation Options.

 SOFTWARE
DECISION ESTIMATION
TREE FOR MAKE / BUY OPTION

A Decision Tree can be created by using a Statistical Tecnique to help the

Management to make a Make or Buy Decision.
 DECISION TREE FOR MAKE / BUY OPTION

.Based on the above Decision Tree The Software Engineerting Organization can

a) Build System “X” from Scratch.

b) Reuse Components (Use Existing Partial-experienced Components”)
c) Buy off- the- Shelf Software and modify it.
d) Contract out the development work to an Outside Vendor.

The Expected Cost Value will be computed for each branch of Decision Tree as:

EXPECTED COST = ∑ (Path Probability) * (Estimated Path Cost)
i
Where (i) is Decision Tree path

 Cost for Build Path = 0.30 ($380,000) + 0.70 (450,000) = $429,000

 Cost for Reuse = 0.40 (275,000) + 0.60 [0.20 (310000) + 0.80 * (490,000)] = $328,000

Based on the Probability and Projected Costs the Lowest Expected Cost is BUY option .
 DECISION TREE FOR MAKE / BUY OPTION

.Basedon the Probability and Projected Costs the Lowest Expected

Cost is “BUY” option.

However it is important to note that besides the Expected Cost several

other Criteria must be considered during the Decision Modeling
Process.

Some of the few criteria to be considered are:-

- Availability
- Experience of Developer / Vvendor /Contractor
- Conformance to requirements
- Local Politics (Internal Politics)
- Likely hood of change
 OUTSOURCING

Outsourcing concept is very simple. Software Engineering activities are contracted

to a third party who does the work at Lower cost and hopefully Hihg quality.

The decision to Outsource can be either Strategic or Tactical.

 At the Strategic level, Business Managers consider whether a significsnt portion

of all software work can be contracted to other.

 At the Tactical level, Project Manager determine whether part or all of a

Project can be best accomplished by subcontracting the Software work.

The PROS (Advantages) and CONS (Disadvantages) of Outsourcing are:

 One positive side of Outsourcing is Cost saving, which can usually be achieved
by reducing the number of Software People and the facilities (e.g Computers,
Infrastructure) that support them.

 On the negative side a Company loses some control over the Software that it
needs.
Since Software is one of the technology that differentiates the Systems, Services
and Products, a Company runs the risk of putting the fate of its competiveness