Software Estimation Techniques -...

67

Software Estimation Techniques

Chapter 3

3.1 Introduction

3.2 Size Estimation

3.2.1 Source Lines of Code

3.2.2 Function Point Analysis

3.2.3 Use Case Point

3.2.4 Object Point

3.2.5 Mark-II Function Point Analysis

3.3 Effort Estimation

3.3.1 Algorithmic Models

3.3.1.1 COCOMO Model

3.3.1.2 Task Based Estimation

3.3.1.3 Modularized Method

3.3.2 Estimation by Analogy

3.3.2.1 Estimation Approach

3.3.3 Expert Judgment

3.4 Schedule Estimation

3.4.1 Gantt Charts

3.4.2 Network Diagrams

3.5 Project Costing

3.6 Conclusion

68

Chapter 3

Software Estimation Techniques

3.1 Introduction:

In the organizations, still there is no accurate and proper way of finding

estimated cost for developing software applications or systems. Initial basic

estimates are done on the basis of high level requirements which don‟t give you

the clear depiction of overall estimation. For new project which require to be

developed in latest technologies, there might be requirement of upgraded

resources may be in terms of skilled employees, latest software technologies

and good infrastructure etc. So, while new development during early stages of

software development it is quite impossible to estimate actual cost of project. In

software development, software estimation is the estimation of the software

size, software development effort, software development cost, and software

development schedule for a specified software project in a specified

environment, using defined methods, tools, and techniques.

Figure 3.1: Conceptual View of Software Estimation Techniques

69

Basic steps for software project estimation as mentioned in above Figure 3.1

are:

1. Estimate the size of the development product.

2. Estimate the effort in person-months or person-hours.

3. Estimate the schedule in calendar months.

4. Estimate the project cost in dollars (or local currency)

3.2 Size Estimation :

To measure the size of project, some of the popular methods are as follows:

3.2.1 Source Lines of code (SLOC): In SLOC, only source statements or

major functionalities are counted. Earlier procedure was to prepare the checklist

for measuring lines of code. Line of code comes under direct measures. While

coding only executable lines are considered for the estimation. But commented

code also plays very important role in understanding the programmer's logic or

lines of code. Now days, most of the frameworks like .NET framework, Eclipse

SDK and many other programming editors are including the feature of counting

the number of source statements. Earlier traditional manual process to count

number of source statement was to prepare the checklist, which was time

consuming. Consider the following Java code for calculating factorial of a

number:

Figure 3.2: Java Code for Calculating Factorial

Source: Compiled by Researcher

70

Adopting the assumed counting criteria, the above code has 13 LOC. But one

can obtain the equivalent code consisting of 7 LOC. This happens after slightly

rearrangement of the code as below:

Figure 3.3: Shortened Java Code for Calculating Factorial


Although LOC is very simple and straightforward measure to compute,

the Java Code in Figure 1 and 2 points some drawbacks to the LOC measure.

LOC measure is considered to be very sensitive to layout of the code.

Depending on that, one can observe a significant variation in the produced

LOC. Furthermore, the LOC measure may not fully reflect the complexity of

code. The program size measure correlates nicely with the LOC measure from

the Figure 3.4.The data points are nicely centered along a regression line:

Figure 3.4: N versus LOC for MIS software module

N=a+b*LOC

Source: James F. Peters,” Software Engineering: An Engineering

Approach” 2000.

71

This study is carried out by Munson and Others in 1996 by considering

390 software modules of a medical image system (MIS). [1]

3.2.2 Function Point Analysis (FPA):

FPA method gives the function point (FP) count based on the

functionalities delivered by an application. FPA has been introduced by

Albrecht in 1979 for measuring the functionality of project. FPA comes under

indirect measures. Here system gets decomposed to number of function points.

Function points are used to measure the amount of functionality in a system as

described by some standards and specifications.

FPA comes under indirect measures. It is a method which breaks the

system into smaller components. Function Point Analysis is a structured method

to perform functional decomposition of a software application. The main

objective of function point is to measure these smaller components or

functionalities. Now a day's most of the small scale industries improving their

quality and productivity by outsourcing their software components to different

Multinational companies .So most of the organizations are using FPA as a tool

for measuring the size of the purchased applications or components. FPA can

help organizations to understand the unit cost of a software application or

project. Once unit cost is understood tools, languages, platforms can be

compared quantitatively instead of subjectively. Function point can be

calculated as the product of unadjusted function-point count and technical

complexity factor. [2]

FP= UFP×TCF

72

Table 3.1: Components of Unadjusted Function Point

Type of components Complexity of Component

Low Average High Total

External Inputs (EI) __×3=__ __× 4=__ __× 6=__

External Outputs (EO) __× 4=__ __× 5=__ __×7=__

External Inquiries(EQ) __×3=__ __× 4=__ __×6=__

Internal logical Files(IFL) __×7=__ _×10=__ __×15=__

External Interface

Files(EIF)

__×5=__ __×7=__ __×10=__

Total Number of Unadjusted Function Points

Source: Chemuturi, K., Murali,” Software Estimation Best Practices, Tools, and

Techniques: A Complete Guide for Software Project Estimators”, 2009.

External Inputs (EI): It consists of each user input that provides application

data and control information.

External Outputs (EO): It includes user output that provides application

oriented information to the user such as Reports.

External Inquiries (EQ): An Inquiry is defined as online input those results

into the generation of immediate response in the form of online output.

Internal Logical Files (ILF’s): It is the logical grouping of data that resides

within application boundaries.

External Interface Files (EIF’s): It is logical grouping of data that resides out

of application.

73

Table 3.2: Components of Technical Complexity Factors

Factors Components Description

F1 Data

communications

How many communication facilities are there to

transfer or exchange information with the

application or system?

F2 Distributed data

processing

How are distributed data and processing functions

Handled?

F3 Performance Did the user require response time or throughput?

F4 Heavily used

configuration

How heavily used is the current hardware platform

where the application will be executed?

F5 Transaction rate

How frequently are transactions executed daily,

weekly, monthly, etc.?

F6 On-Line data

entry

What percentage of the information is entered on-

line?

F7 End-user

efficiency

Was the application designed for end-user

efficiency?

F8 On-Line update

How many ILF‟s are updated by On-Line

Transaction?

F9 Complex

processing

Does the application have extensive logical or

mathematical processing?

F10 Reusability

Was the application developed to meet one or many

users‟ needs?

F11 Installation ease How difficult is conversion and installation?

F12 Operational

ease

How effective and/or automated are start-up,

backup, and recovery procedures?

F13 Multiple sites

Was the application specifically designed,

developed, and supported to be installed at multiple

sites for multiple organizations?

F14 Facilitate

change

Was the application specifically designed,

developed, and supported to facilitate change?



Rate each factor on a scale of 0 to 5.

0 No influence

1 Incidental

2 Moderate

3 Average

4 Significant

5 Essential

74

UFP can be obtained by:

UFP= ∑∑ Xij wij --- (1)

Xij: count of the number of functional units of type (i) having complexity

corresponding to column (j).

wij: Entry of ith

row and jth

column in UFP table.

TCF can be obtained by:

TCF= (0.65+0.01∑Fi) --- (2)

∑Fi: Sum of all the rates of each factor.

Finally, we calculate function point:

FP=UFP×TCF (Using (1) and (2))

The major advantages of using FPA method are that it is certified by

professional bodies and even certified people are available to evaluate and help

organizations to carry out FPA for the projects. Even non-technical person can

also understand the FP method easily. [Illustration of Function point calculation

explained in Chapter 5]

3.2.3 UCP (Use Case Point):

This approach uses Unified Modeling Language (UML) which is most

frequently used methodology in software development and for web application

development. It is accepted by IBM and is supposed to be the result of a study

of a large number of projects. It was developed by Gustav Karner (IBM) in

1993.UML is a language for constructing, documenting and visualizing entire

system. It is a graphical language with set of rules and semantics. UML Use

case diagram was first introduced by Ivar Jacobson. Use case represents the

specific flow of events in the system and they are initiated by the actors or

users. An actor is anything that interacts with a use case (Human Beings or

75

External System). [5]

For instance for the Gate IN/OUT System following use

cases can be shown in Figure 3.5:

Use Cases:

(i) Manage Master Entries

(ii) Gate IN/OUT Process

(iii) Machine IN/OUT Process

(iv) Generating Reports

(v) Manage Leaves

(vi) Portal Management

(vii) Visitors Gate pass

Figure 3.5: Use Case Diagram for Gate IN/OUT system


76

Actors:

(i) Administrator

(ii) Supervisor

(iii) HR

(iv) Staff

(v) Security

One of the important drawbacks of this method is that we are not able to

estimate until all use cases are in defined form. But as in present scenario, every

time user changes the requirement which leads to frequent changes in use cases.

So, this method is not preferable as compare to other size estimation techniques.

3.2.4 Object point (OP):

Object point is developed for client-server technologies and is useful for

all present-day projects including web based projects. It can be used

independently. The advantage of object points over function points is that they

are easier to estimate from a high-level software specification. Object points are

only concerned with screens, reports and modules in conventional programming

languages. They are not concerned with implementation details, and the

complexity factor estimation is much simpler.

Following are the steps for calculating object point:

(i) Assess object count: number of screens, reports and 3GL components.

(ii) Classify object: Simple, Medium and Difficult depending on the values

of characteristic dimensions.

77

(iii) Weight the number in each cell using the following scheme. The

weights reflect the relative effort required to implement an instance of

that complexity level as given in the following Table 3.3.

Table 3.3: Weight value by object complexity

Object Type Simple Medium Difficult

Screen 1 2 3

Reports 2 5 8

3GL Components NA NA 10

Source: Chemuturi, K., Murali,” Software Estimation Best Practices, Tools,

and Techniques: A Complete Guide for Software Project Estimators”, 2009.

(iv) Determine object points: add all the weighted object instances to get one

number, the object point count.

(v) Estimate percentage of reuse you expect to be achieved in this project.

Compute New object points to be developed as,

NOP = (Object Point) * (100 − % reuse)/100

Where, % reuse is the percentage of screens, reports, and 3GL modules

reused from previous applications.

(vi) Determine a productivity rate depending on developers‟ experience and

ICASE maturity as given in the table.

The advantages of this method are that it can be used with COCOMO

effort estimation which can be considered as the most effective technique in

terms of accuracy. Even clients or non technical users can also identify the

components easily. Objects such as screen, reports or programming units can be

easily identifiable. [3] [6]

78

3.2.5 MK-II FPA (Mark-II Function Point Analysis):

Introduced by U.K Software Metrics Association (UKSMA) and it was

defined by Charles Symons in Software Sizing and estimating: MK-II FPA,

published in 1991. MK-II FPA sizes the logical transactions instead of counting

the inputs, outputs and process. It is more easily understandable and useful of

non-computer-savvy person. UKSMA defines MK-II FPA as:

“A method for the quantitative analysis and measurement of information

processing applications .It quantifies the information processing requirements

specified by the user to provide a figure that expresses a size of the resulting

software product. This size is suitable for the purposes of performance

measurement and estimating in relation to the activity associated with the

software product.”[3]

Mark-II FPA was developed to overcome the difficulties of FPA which are as

follows:

1. Uncertainty in identification of files. For e.g. Describing what is a

“logical files”.

2. Weights used don‟t have statistical analysis.

3. Strictly mentioned 14 GSC‟s, but may need some other factors.

4. FPA is not suitable for integrated systems

5. If small systems combined to build larger system, the FP count of larger

system is less than sum of the FP count of smaller systems.[3][6]

Some more additional technical complexity factors in continuation with 14

factors mentioned in FPA are as given in below table 3.4:

79

Table 3.4: Additional technical complexity factors

Factors Components Description

F15

Requirements

of other

applications

Ranging from 0 (stand alone) to 5 (More than four

other applications interfaced)

F16 Security and

Privacy

Based on personal privacy requirements and

cryptographic techniques for encryption and

decryption

F17 User Training Ranging from 0 ( No special training ) to 5 ( with all

special training facilities like online tutorials)

F18 Direct use by

Third parties

Ranging from 0 (No third party connection) to 5

(third party may update)

F19 Documentation

Ranging from 0 to 5 depending on need for

functional specifications, user manuals, test data

documentation , query tracker etc.

Source: Swapna Kishore and Naik Rajesh, “Software Requirement and

Estimation”, 2010.

Now there will be 19 technical complexity factors from F1 to F19.Each

of these factors need to be assigned some value ranging from 0 to 5. Then, we

need to calculate the summation of all these factors (Degree of influence).So,

technical complexity adjustment factor is obtained by:

TCAF=0.65 + (Sum of Degree of Influence × 0.005)

The advantage of this method is that it measures the transactions instead of

counting inputs, outputs, processes and so on which are easily understandable to

the end users or non-technical person. Again, professional bodies are there to

modify the standards. [3] [7]

3.3 Estimating Efforts:

The project development effort is directly dependent on the two

important inputs: Application size and productivity of programmer or team

80

.Transforming the size into deliverable efforts within a schedule makes the

project a complete success. Productivity is based on the programmer‟s

capability and technological adaptability and flexibility in using integrated

development environments (IDE‟s). The main purpose of software size

estimation is to estimate the effort (people, schedule, cost) needed to develop

software. For any software, LOC varies for different technologies but in terms

of complexity FPA is considered as the best method for estimating the software

size.

In the figure 3.6 below as you can see as size increases, the effort for

developing an application also gets increases.

Figure 3.6: Size-Effort Relationship

Source: Swapna Kishore and Naik Rajesh, “Software Requirement and

Estimation”, 2010.

For some software projects, any mistakes in the estimation lead to either

overestimation or underestimation. The use of excessive resources may affect

the completion time or schedule. Underestimating the development effort can

lead to under-staffing, cost and schedule overruns, and poor-quality software,

while over-estimates can result in inefficiency and wasted resources, as projects

tend to expand to fit the estimated effort.

81

Figure 3.7: Effort-Time Relationship

Source: James F. Peters, “Software Engineering: An Engineering

Approach”, 2000.

In the Figure 3.7 above the required effort is based on the worst, best and most

likely estimates that can be obtained using the famous project evaluation

technique PERT(Project Evaluation and Review Technique).

Effort =

PERT method allows compensate for risk by developing a biased estimate. [1]

Algorithmic models like COCOMO exist to calculate the effort. The

early version of COCOMO used to take LOC as a size metric. COCOMO was

modified to take function points as input. In COCOMO II, the software effort is

calculated based on the software size and a set of cost drivers such as product,

hardware, personnel and project attribute. Another effort estimation method

without using software size is Task Based Estimation (TBE) which uses above

PERT technique/Formula to calculate the expected Effort. (Explained in Section

3.3.1.2) .This estimation is used during early phases of SDLC. But in TBE,

phases get changed based on the project type. The other technique to find effort

required for the project is by using analogy and expert judgment which includes

82

identify at least one project of similar size (explained in next section). Then use

the similar tools and use team with similar skills and experience for estimating

the new software project. [8]

3.3.1 Algorithmic models:

The algorithmic methods generally provide mathematical equations to

carry out software estimation. These equations are based on research and past

data and use inputs such as Source Lines of Code (SLOC) and number of

functions points etc. One of the Effort estimation algorithmic models is

COCOMO models. [9]

3.3.1.1 COCOMO MODEL

Cost Constructive Model (COCOMO) was first anticipated by Barry W.

Boehm in his book in 1981.He gave the equations to evaluate the effort (person-

month to execute the projects).

For Basic COCOMO:

Effort=A × (Size) B

------------------ (1)

Where,

A =Constants based on different classes of Software Projects

B=Economy or Diseconomy of Scale based on different classes of Software Projects

Size= No. of Source Lines of Code (KSLOC)

Table 3.5: Classes of Software Projects with Boehm’s Constants

Different Modes of Software Projects and Standard

Constants

Development Time

Constants

Types of Software A B Effort C D

Organic 2.4 1.05 2.4 × (Size)1.05

2.5 0.38

Semidetached 3.0 1.12 3.0 × (Size)1.12

2.5 0.35

Embedded 3.6 1.20 3.6 × (Size)1.20

2.5 0.32



83

Organic:

In this mode, products are small and require less innovation. Also products are

similar to the previous developed product in a well-known and secure

environment. For example: Any accounting system.

Semidetached:

The projects characteristics are in-between organic and embedded modes. Here

mixed teams working with mix or less rigid set of requirements and constraints.

Embedded:

An embedded mode project requires a great amount of innovation. Here project

is characterized by tight, inflexible constraints and interface requirements.

Recent android apps development tools and which uses customized hardware

can be considered in this mode. [3] [10]

Intermediate COCOMO:

Estimating Maintenance Effort for different development modes as follows:

Effort maintenance = A × EAF × (Size) B

----------------- (2)

Where,

A =Constants based on different classes of Software Projects

B=Economy or Diseconomy of Scale based on different classes of Software

Projects

EAF= Effort Adjustment Factor derived from 17 Cost Drivers [11]


84

Table 3.6: Classes of Software Projects with Boehm’s

Constants with EAF

Different Modes of Software Projects and Standard

Constants

Development Time

Constants

Types of

Software A B Maintenance Effort C D

Organic 3.2 1.05 3.2 × EAF × (Size)1.05

2.5 0.38

Semidetached 3.0 1.15 3.0 × EAF × (Size)1.12

2.5 0.35

Embedded 2.8 1.20 2.8 × EAF × (Size)1.20

2.5 0.32



COCOMO II:

It is the upgraded version of COCOMO developed under the leadership

of Dr. Barry Boehm at University of Southern California. COCOMO II again

has Early Design model and Post Architecture Model. The standard values for

17 Cost Drivers (Post Architecture Model) as shown in following Table 3.7.[11]

For Early Design Model there were 7 Cost Drivers and in Post Architecture

Model, Number of Cost Drivers increases to 17.

Basic Equation for COCOMO II:

Effort (nominal) = A × (Size) B

------------ (1)

Where,

A =Constants representing Nominal Productivity

B=Scale factor


Modified Equation for COCOMO II:

Effort (maintenance) = A × EAF × (Size) B

------------ (2)

Where,

A =Constants representing Nominal Productivity

B=Scale factor

EAF= Effort Adjustment Factor derived from 17 Cost Drivers

85

Table 3.7: Setting Cost Drivers for Project

(Post Architectural COCOMO II)

Cost Drivers EH VH H N L VL Project Cost Drivers

ACAP Analyst

Capability NA 0.71 0.85 1 1.19 1.42

APEX Application

Experience NA 0.81 0.88 1 1.1 1.22

PCAP Programmer

Capability NA 0.76 0.88 1 1.15 1.34

PLEX Platform

Experience NA 0.85 0.91 1 1.09 1.19

LTEX Language and

tool experience NA 0.84 0.91 1 1.09 1.2

PCON Personal

Continuity NA 0.81 0.9 1 1.12 1.29

TOOL Use of

software tools NA 0.78 0.9 1 1.09 1.17

SITE Multisite

Development 0.8 0.86 0.93 1 1.09 1.22

SCED Development

Schedule NA 1 1 1 1.14 1.43

TIME

Execution

Time

Constraints

1.63 1.29 1.11 1 NA NA

STOR Main Storage

Constraint 1.46 1.17 1.05 1 NA NA

PVOL Platform

Volatility NA 1.3 1.15 1 0.87 NA

RELY Required

Reliability NA 1.26 1.1 1 0.92 0.82

DATA Database Size NA 1.28 1.14 1 0.9 NA

CPLX Product

Complexity 1.74 1.34 1.17 1 0.87 0.73

RUSE Required

Reusability 1.24 1.15 1.07 1 0.95 NA

DOCU

Documentation

match to life

cycle needs

NA 1.23 1.11 1 0.91 0.81

EH - Extra High, VH - Very High, H – High N- Normal, L – Low, VL - Very Low

Source: COCOMO-II Model Definition Manual, 2000

86

Schedule Estimation using Post Architecture Model of COCOMO II:

The COCOMO II schedule equation predicts the number of months required to

complete our software project. The duration of a project is based on the effort

predicted by the effort equation:

Duration = 3.67 * (Effort (Maintenance)) SE

-------- (3)

SE is schedule equation exponent derived from five scale driver‟s i.e.

1. Precedentedness (PREC)

2. Development Flexibility (FLEX)

3. Architecture / Risk Resolution (RESL)

4. Team Cohesion (TEAM)

5. Process Maturity (PMAT)

1. Precedentedness (PREC):

If a project is similar to previously developed projects then PREC is

HIGH. Following are the scale drivers:

Table 3.8: Scale Drivers for Precedentedness

Scale Driver PREC Scale Factor

Very Low Thoroughly Unprecedented 6.2

Low Largely Unprecedented 4.96

Nominal Somewhat Unprecedented 3.72

High Generally Familiar 2.48

Very High Largely Familiar 1.24

Extra High Thoroughly familiar 0

Source: Swapna Kishore and Naik Rajesh, “Software

Requirement and Estimation”, 2010.

87

2. Development Flexibility (FLEX):

Table 3.9: Scale Drivers for Development Flexibility

Scale Driver FLEX Scale Factor

Very Low Rigorous 5.07

Low Occasional relaxation 4.05

Nominal Some relaxation 3.04

High General Conformity 2.03

Very High Some Conformity 1.01

Extra High General Goals 0

Source: Swapna Kishore and Naik Rajesh,

“Software Requirement and Estimation”, 2010.

3. Architecture /Risk Resolution

Table 3.10: Scale Drivers for Architecture /Risk Resolution

Scale Driver RESL Scale Factor

Very Low Little (20%) 7.07

Low Somewhat (40%) 5.65

Nominal Often (60%) 4.24

High Generally (75%) 2.83

Very High Mostly (90%) 1.41

Extra High Full (100%) 0



88

Process Maturity:

Table 3.11: Scale Drivers for Process Maturity

Scale Driver PMAT Scale Factor

Very Low SW CMM Level-1 Lower 7.8

Low SW CMM Level-1 Upper 6.24

Nominal SW CMM Level-2 4.68

High SW CMM Level-3 3.12

Very High SW CMM Level-4 1.56

Extra High SW CMM Level-5 0



4. Team Cohesion:

Table 3.12: Scale Drivers for Team Cohesion

Scale Driver TEAM Scale Factor

Very Low Very Difficult interaction 5.48

Low Somewhat difficult interaction 4.38

Nominal Basically Cooperative Interactions 3.29

High Largely Cooperative 2.19

Very High Highly Cooperative 1.1

Extra High Seamless Interaction 0



From all above Scaling factors, determine the weight for each scaling factors

and find out the sum of all the selected weights for each scaling factor (Say B).

This can be used as exponential scaling factor (Say SE). [7]

89

B=0.91 +0.01 × (Sum of weights on scaling drivers of the project)

SE=0.28 + 0.2 (B-0.91)

Put the value of SE in equation (3), we get the estimated duration. [Calculating

Efforts using COCOMO explained in Chapter 5]

3.3.1.2 Task Based Estimation:

In this method, effort is evaluated directly without using size estimation

into consideration. The advantage of using this method is that it can be used in

case of full or partial life cycle of projects, maintenance projects, testing

projects etc. It is also referred to as Activity Based Estimation. In this

estimation, projects are divided into number of phases. For instance, phases for

testing projects given by Chemuturi in 2009 are as below:

a) Project Initiation

b) Project Planning

c) Test Planning

d) Test Case Design

e) Test Environment Setup

f) Execute different testing

g) Test Results

h) Regression testing

i) Test reports

j) Close project

Each phase is then divided into number of tasks:

Phase: Project Initiation

90

Figure 3.8: Project Initiation tasks for Testing Projects

Steps for Task Based Estimation:

1) Allocate duration for each tasks ( in either person-hours or person-days)

2) For each task , estimate the effort using three estimates – optimistic (best

case),pessimistic (worst case ) and most likely (normal case) as below:

Expected Effort =

3) Make adjustment with the resources like skills of developers, similar type

of platforms, complexity of project, tools usage etc.

4) Find out the summation of the following to obtain total effort estimation

of project:

a. All optimistic effort values

b. All pessimistic effort values

c. All most likely effort values

d. All expected effort values

5) Record all the assumption and make it available to project managers for

costing.

Following table shows the task based estimation for one of the companies for

their KPI module.

91

Table 3.13: Task Based Estimation for KPI (Key Performance Indicator)

Module.

Phases Task Optimistic

Effort

Pessimistic

Effort

Most

likely

Effort

Expected

Effort

1 Implementation Plan

1.1 Activity list and Requirement

Gathering 2 4 3 3

1.2 Flow chart 3 5 4 4

1.3 Screen Design-Input Form

Designing 2 3 2.5 2.5

2 Approval Process

2.1 Approval by Higher Authority 2 3 2.5 2.5

3 Database Design

3.1 Finalize database structure 2 4 3 3

3.2 Set naming conventions for table

and fields 1 2 1.5 1.5

3.3 Relationship of tables 1 2 1 1.17

4 Implementation / creation of DB

4.1 Creation all tables 1 1.5 1.25 1.25

4.2 Giving relationship of tables 1 1.5 1 1.08

5 Programming

5.1 UI Template Design 5 8 6 6.17

5.2 Input Form(beans,DAO) 6 9 7 7.17

5.3 Data Processing programs 3 5 4 4

5.4 Output Results 2 4 2.5 2.67

6 Unit Testing

6.1 Defining Test Cases 4 8 5 5.33

6.2 UI Design testing 3 5 4 4

6.3 Input form testing 3 5 4 4

6.4 Data Process Testing 1 2 1.5 1.5

6.5 Reporting Bug 1 1.5 1.25 1.25

7 Beta Testing

7.1 Testing by end user 1 1.5 1 1.08

7.2 Bug report 1 1.5 1 1.08

8 Go Live

8.1 Uploading Project on server 0.5 1 0.75 0.75

Total Effort Estimate (Person-days) 45.5 77.5 57.75 59

Source : Compiled by Researcher

The effort required to develop this module is found out to be 59 person-days,

with a minimum of 45.5 person-days, pessimistic effort of 77.5 person-days and

most likely effort obtained to be 57.75 person-days.

92

3.3.1.3 Modularized Estimation Method:

Development effort was found to decrease with breaking work

assignments down into tasks that can be accomplished individually,

compressing the development schedule of modules, and allowing teams to focus

on a small number of tasks. [12]

Estimation of overall effort for delivering the

software is given in the following Figure 3.9. Productivity factor provided by

Parthasarthy are purely illustrative figures and compared against organizations

productivity across platforms.

Figure 3.9: Effort Estimation Flow

Estimate size: For measuring the size either Function Point or Lines of Code

method can be used. Another popular method of measuring size is the Use case

method (prepared during project scope definition).

Technology: Technology includes several parameters like Language (Java,

CPP, and C #), Platform (Windows/Unix), Database (Oracle, SQL Server, and

DB2), and Architectures (2 tiers or 3 tiers). Technologies play a vital role in

93

developing applications. Larger the size of application, higher the effort to

develop it on a specific technology. Productivity factors Variance due to

technology Table 3.14 as shown below:

Table 3.14: Productivity factors variance due to Technology

Technology

Relative

User

Interface

Build and

Test Ease

Tools

Availability

Other

Overheads

Productivi

ty Factor

Mainframe Low Medium High High 1.20 ×

J2EE High High Medium Low 0.90 ×

Microsoft

.NET High High Medium Low 0.80 ×

UNIX/C Medium Medium Medium Medium 1.35 ×

Source: M.A Parthasarathy,” Practical Software Estimation: Function Point

Methods for in sourced and outsourced Projects”, 2007.

Execution Type: Depending upon the requirements, a software project could be

executed under different project execution processes. The type of projects could

be under development, maintenance, reengineering, enhancement, migration

and porting phase. Each of these types may have different execution process.

Productivity factors Variance due to Project Execution Type Table 3.15 as

shown below:

Table 3.15: Productivity factors variance due to Project Execution Type

Project

Execution

Type

Require

ment Design

Build

and Test

Ease

Other

Overheads

Productivity

Factor

New

Development Medium Medium High Low 0.90 ×

Re-engineering Very

High Medium High Medium 1.20 ×

Maintenance Low Low High Low 0.70 ×

Migration Medium Low Medium High 0.75 ×



94

Skills: related to productivity figure which is nothing but the rate of

achievement which can be applied to convert software size into efforts. In IT

organizations, productivity of team working on one technology differs from

productivity of team working on another technology. So productivity factor

plays a significant role in defining the overall effort estimation in spite of any

variation due to size, technology and execution type. Productivity factors

Variance due to Project Size Table 3.16 as shown below:

Table 3.16: Productivity factors variance due to Project Size

Project

Size

Require

ment Design

Build and

Test Ease

Other

Overheads

Productivity

Factor

< 350 FP Low Low Low Low 0.70 ×

351-750

FP Medium Medium Medium Medium 1.00 ×

751-

1500 FP Medium High Medium High 1.25 ×

> 1500

FP High

Very

High High Very High 1.50 ×



Calculating Efforts: The project development effort is directly

dependent on the two important inputs: Application size and productivity of

programmer or team .Transforming the size into deliverable efforts within a

schedule makes the project a complete success.

Productivity is based on the programmer‟s capability and technological

adaptability and flexibility in using integrated development environments

(IDE‟s) as mentioned in above factors.

95

Figure 3.10: Deriving Efforts

Source: M.A Parthasarathy,” Practical Software Estimation: Function

Point Methods for in sourced and outsourced Projects”, 2007.

To find effort estimation using size estimation there is need of

productivity figure that can be expressed as person-hours per unit of software

size or as software size per person-day. So, finally effort can be calculated by:

Effort= Application size × Productivity

Person –hours per unit of software size: Let us assume software size is 100

function points and productivity is 10 person-hours, then

Effort = 100 ×10

= 1,000 person-hours

Units of software size person-day: if the software size is 100 function points and

productivity is 0.8 function point per person-day, then

= 125 person-days

So we have calculated the total effort by using the modularized method. [7][10]

96

3.3.2 Estimation by Analogy:

This method comes under Non-Algorithmic Software Cost Estimation

Method and was first proposed by Shepperd and Schofield (1997). Analogy

based estimation technique works on the principle that earlier and similar types

of projects that have produced the actual values or results are very useful in

producing the more accurate results for the future upcoming projects or targeted

projects within the organization. The matching projects are known as „analogs‟.

The organizations must have prerequisites for using Analogy based software

estimation like the number of projects executed in the past, keeping thorough

records of past projects, well maintained knowledge repository for extracting

valid data from the similar type of projects to be used for future project.[3][13]

Estimation based on Analogy uses metadata about a project to be estimated

(size, type, process, domain, etc.) to base an estimate of its required resources

on the resources required for the most similar types of projects in a huge

database such as ISBSG (International Software Benchmarking Standards

Group) database of 3000 software projects.[14]

In one research study, analogy-based estimation performed

comparatively superior than alternative estimation methods in 60% of the cases,

but worst in 30% of the cases, indicating need of further improvement. [15]

The

disadvantage of this method is lots of information about past projects is

required. It means this method is totally dependent on historical data. There

might be some situations when there are no similar types of projects. Even for

new IT organizations, this method is not suitable as they are just beginners and

mainly they might not have any past projects. But the advantage is that it based

on the actual experience or actual projects. [16]

97

Following Figure 3.11 shows general Framework of analogy based estimation.

Figure 3.11: General Framework of analogy based estimation

Source: Y. F. Li, M. Xie and T. N. Goh, “A Study of the non-linear adjustment

for analogy based software cost estimation, Empirical

Software Engineering”, 2009.

Above figure shows similarity function is defined and which compares the

features of two projects. There are two similarity function namely Euclidean

similarity (ES) and Manhattan similarity (MS) (Shepperd, M, Schofield, C,

1997, Chiu, N, Huang, S.J, 2007).[17]

Sim (p, p‟) =1/ + δ] δ=0.0001

Dis ( = ( ) 2

If are numeric or ordinal

1 If are nominal and


98

p and p' are projects wi is the weight is assigned to each feature and varies

between 0 and 1. Fi and f i ' display the ith

feature of each project and n

demonstrates the number of features. δ is used for obtaining the none zero

results. The MS formula is very similar to ES but it computes the absolute

difference between features.

Sim (p, p‟) =1/ + δ] δ=0.0001

Dis ( = | |

If are numeric or ordinal



This is also called case-based reasoning. The estimator identifies

completed projects (source) with similar characteristics to the new project

(target). The effort recorded for the matching source case is then used as a base

estimate for the target. The estimator then identifies differences between the

target and the source and adjusts the base estimate to produce an estimate for

the new project. A problem is identifying the similarities and differences

between applications where you have a large number of past projects to

investigate. One way is to automate this selection process using ANGEL

software tool. This identifies the source that is nearest the target by measuring

the Euclidean distance between both the cases. The Euclidean distance is

calculated as:

Distance = square-root of ((target_parameter 1 – source_parameter 1 ) 2 +

….(target_parameter n – source_parameter n ) 2

)

99

Consider that the cases are being matched on the basis of two parameters,

the number of inputs to and the number of outputs from the application to be

built. The new project is known to require 7 inputs and 15 outputs. One of the

past cases, project A, has 8 inputs and 17 outputs. The Euclidean distance

between the source and the target is therefore the square-root of ((7 – 8)2 + (17 –

15) 2

), that is 2.24. [18]

But problem arises when we have large number of past

projects to investigate.

3.3.2.1 Estimation Approach

The important attributes required for computing effort and size for analogy

based estimation are project type, project domain, size of organization,

development location ,modules, application tier, backend , web servers,

programming language, development environment, process for development,

rules engine and so on. All the above attributes helps to identify the best out the

past projects. Project manager/ Estimator select the similar type of project and

find the important attributes list. Once identification of attributes done;

necessary comparative analysis performed between all the attributes of past

project and current project. Also they make the necessary adjustment to get

more close to the new estimate. Then finalization and arrangement of new

estimate on the basis of peer review and feedback analysis. Finally, presenting

it; in-front of clients or requesters using standard formats of organizations

estimation process. According to Chemuturi (2009) there are two stages:

a) Compilation of past projects:

This process is mentioned in the following table with an illustration of

College ERP system where similar type of projects selected and accordingly

estimator identifies the parameters list for the current project with least possible

extrapolation. Let‟s perform the correlation analysis between the projects. We

have following set of projects with details:

100

Table 3.17: Details of past completed projects

Past

Projects Size (LOC) Effort (hours)

Productivity

in LOC per

hour

Speed of

Delivery (LOC

per month)

Project

Duration

( months)

Project1 5340 3600 1.48 1068 5

Project2 5500 2880 1.90 1410.25641 3.9

Project3 2000 480 4.16 1538.461538 1.3

Average 4280 2320 2.51 1338.90 3.4


Value of correlation will be interpreted as follows:'0' indicates No

Correlation,'1' indicates Perfect Correlation, Value directing towards '0'

indicates Weaker Correlation and Value directing towards '1' indicates Strong

Correlation. Correlation between project size and productivity is obtained by

using Microsoft Excel and it is found out to be -0.98 which is strongly negative

correlated .Therefore, as size increases, productivity decreases. Correlation

between project size and productivity is obtained by using Microsoft Excel and

it is found out to be -0.98 which is strongly negative correlated .Therefore, as

size increases, productivity decreases.

Figure 3.12: Correlation analysis of past projects

101

All projects developed in Visual Studio .NET. But if we change the

environments to J2EE, productivity will not be same.

Table 3.18: Parameter List for Target project in comparison with other

Projects

Attributes Target Project Project 1 Project 2 Project 3

Type of Project New

Development

New

Development

Enhancement

Project

Enhancement

Project

Application

Domain Education Education Education Education

Organization Size Small Small Medium Large

Number of

locations 1 1 1 1

Modules

Student

Information,

College and

Branch

Information

,Class test and

Attendance

Student

Information,

College and

Branch

Information

Faculty

Enrollment and

Payroll

Fees and

Admission

Register

Backend SQL Server 2008 SQL Server

2005

SQL Server

2005

SQL Server

2008

Web Server Apache Tomcat IIS IIS IIS

Programming

Language Java C# C# C#

Development

Environment J2EE Dot Net 08 Dot Net 10 Dot Net 10

Development

Location In house In house In house In house


Table 3.18 shows the parameter list of any project and also shows the

comparison of targeted project parameter values and similar type of completed

projects parameters values.

b) Evaluating or computing size and efforts for analogy based estimation

I. Compare each parameter of new and old project.

II. Assign weight to each parameter with following assumptions in Table

3.19:

102

Table 3.19: Weight assumptions

Weight Description

0 For No Match

1 Exactly Same

0 > and < 1 Parameter can be relevant but less than 100%

Greater than 1 Parameter is relevant but more than 100%


Techniques: A Complete Guide for Software Project Estimators”, 2009

III. Calculate the arithmetic average and obtain Composite Weight Factor

(CWF) as mentioned in Table 3.20.

IV. Multiply the estimate of old project by CWF to get the new estimate.

Here past project selected on the basis of parameter:

Type of project

Application domain,

Organization size

Number of locations

Development location

As these parameters are exact match with the parameters of target project.

Table 3.20: Calculating CWF

Attributes Target Project Project 1

(Selected project)

Weight

Assigned

Type of Project New Development New Development 1

Application

Domain Education Education 1

Organization

Size

Small (Department

wise) Small 1

Number of

locations 1 1 1

Modules

Student

Information,Colleg

e and Branch

Information,Class

test and Attendance

Student

Information,Colleg

e and Branch

Information

0.7

Backend SQL Server 2008 SQL Server 2005 0.8

Web Server Apache Tomcat IIS 0

103

Attributes Target Project Project 1

(Selected project)

Weight

Assigned

Programming

Language Java C# 0

Development

Environment J2EE Dot Net 08 0

Development

Location In house In house 1

CWF 0.65


For the past selected project:

1. Total Lines of Code: 5340 SLOC

2. Effort : 3600 person-hours

Therefore, estimates for current project found out to be:

1. Size: 5340 × 0.65 = 3471 SLOC

2. Effort : 3600 ×0.65 = 2340 person-hours

The results obtained are much more near to the average values .We

consider approximate project duration would be 3.4 months with the estimated

productivity 2.51 LOC per hour. The above case study is for estimating the web

based project for viewing examination marks and attendance of students in

educational domain.

3.3.3 Expert Judgment:

This method doesn‟t require any collection of data and complex models.

It uses the experts‟ advice and experience for the estimation. One of the most

common methods or techniques which work for providing the consultation or

discussion is Delphi. This technique was originally developed at The Rand

Corporation in the late 1940‟s mainly about the future event predictions. [19]

Delphi arranges an especial meeting among the project experts and tries to

achieve the true information about the project from their debates. Delphi

includes following steps:

i. Coordinator describes the project flow.

104

ii. Coordinator calls a group meeting to discuss estimation issues.

iii. Experts fill out estimation forms secretly without mentioning name.

iv. Coordinator distributes a summary of the estimates.

v. Coordinator calls a group meeting to discuss points where their

estimates varied widely.

vi. Experts fill out forms again secretly and Step 4 to 6 are iterated for as

many rounds as appropriate

Following Figure 3.13 shows an example of using Delphi technique in which

eight experts contribute and final decision was determined after passing four

stages and conclusion can be made at the end.[17] [20]

Figure 3.13: Delphi Method

Source : Vahid, Khatibi and Dayang, N. A. Jawawi, “Software Cost Estimation

Methods: A Review”,2010-11.

Another technique based on expert judgment is Work breakdown

structure (WBS) in which project can be break down into hierarchical structure

of activities. If any organization uses similar types for activities for various

other projects in future, they may get accuracy in terms of cost estimation. WBS

basically done by project managers or expert people and it mainly focuses on

105

scheduling the tasks. An initial WBS for software project KPI is illustrated in

Table 3.21.

4.3 Schedule Estimation:

Scheduling of projects require building a WBS (work breakdown

structure) which includes defining predecessor activities, assigning dates and

allocating resources. List of all activities and milestones needed execute and

complete the project is commonly known as work breakdown structure. Two

types of graphical representation of schedule are popularly used:

(a) Bar charts (Gantt chart)

(b) Network diagrams ( CPM or PERT )

PERT, which stands for Project Evaluation and Review Technique, was

developed in 1950s to plan and control large weapons development projects for

the U.S. Navy. A PERT chart is a graphical network model that depicts a

project‟s tasks and the relationships between those tasks. PERT was developed

to make clear the interdependence between project tasks before those tasks are

scheduled. The arrows indicate that one task is dependent on the start or

completion of another task.

The Gantt chart, first conceived by Henry L. Gantt in 1917, is the most

commonly used project scheduling and progress evaluation tool. A Gantt chart

is a simple horizontal bar chart that depicts project tasks against a calendar.

Each bar represents a named project task. The tasks are listed vertically in the

left-hand column. The horizontal axis is a calendar time line.[18]

During research

it was found that one of the organizations is using the predefined structure for

schedule estimation. They are using Microsoft excel tool for maintaining the

different tasks and evaluating the total hours for the project.

106

3.4.1 Gantt Chart:

A Gantt chart or bar chart can be drawn in a Microsoft Excel as given below

Figure 3.14.

Figure 3.14: Gantt chart for KPI Module

107

3.4.1 Network Diagrams:

In order to identify schedule estimation, we have to breakdown the

project into number of activities. List of all the activities in a specified sequence

is known as work break down structure (WBS). Multiple resources have been

allocated based on their skill set .The start date and end date of an activity is

mentioned excluding the holidays. The objective of project management

technique is to prepare time chart or network diagrams to evaluate the time

schedule of the project. [21]

In the below Table 3.21, Predecessor activities

defined which will help to create appropriate network diagram. One task may

have multiple predecessors. For instance, we had multiple predecessors for the

activities E and H. For starting development, we must complete database

creation and designs. Similarly, for integration we must be done with

development and database creation.

Table 3.21: Work breakdown structure for Automated Employee

Management System (AEMS)

Activity Activity

Eff

ort

s

per

son

/day

Start End

Du

rati

on

Pre

dec

esso

r

Act

ivit

y

A Start 0 13-Aug-2014 13-Aug-2014 - -

B Project Planning and initiation 8 13-Aug-2014 30-Aug-2014 16 -

C Requirement Analysis 10 1-Sep-2014 16-Sep-2014 14 A

D Implementing plan 8 17-Sep-2014 25-Sep-2014 8 B

4.1 Flowchart

4.2 Form Designs

E Approval by Authority 2 26-Sep-2014 27-Sep-2014 2 C,D

F Database Schema Diagram 6 1-Oct-2014 14-Oct-2014 12 C

108


Figure 3.15: CPM Network Diagram


Activity Activity

Eff

ort

s

per

son

/da

y

Start End

Du

rati

on

Pre

dec

esso

r

Act

ivit

y

6.1 Creation all tables

6.2 Giving relationship of tables

G Constructing Database 2 15-Oct-2014 16-Oct-2014 2 F

H Programming 6 17-Oct-2014 30-Nov-2014 39 E,G

8.1 UI Template Design

8.2 Input Form(Beans, DAO)

8.3 Data Processing programs

8.4 Output Results

I Integration 3 15-Jan-2015 20-Jan-2015 4 H

J Unit Testing 3 21-Jan-2015 24-Jan-2015 4 I

10.1 Defining Test Cases

10.1.1 UI Design Testing

10.1.2 Input form testing

10.1.3 Data Process Testing

10.2 Reporting Bug

K Beta Testing 4 26-Jan-2015 30-Jan-2015 5 J

11.1 Testing by end user

11.2 Bug report

L Go Live 1 2-Feb-2015 2-Feb-2015 1 K

12.1 Uploading Project on server

M End - 2-Feb-2015 2-Feb-2015 - -

109

Table 3.22: Earliest and Latest Times with Floats

Activity Duration

(t)

Earliest Time Latest Time Floats

ES EF LS LF Total Float

(LS-ES)

Free Float

(Total Float-

Head Slack)

Independent float

(Free Float-

Tail Slack) (ES+t) (LF-t)

1-2 0 0 0 10 10 10 10 0

1-3 16 0 16 0 16 0 0 0

2-4 14 0 14 10 24 10 0 0

3-4 8 16 24 16 24 0 0 0

4-5 12 24 36 24 36 0 10 10

4-6 2 24 26 36 38 12 12 12

5-6 2 36 38 36 38 0 0 0

6-7 39 38 77 38 77 0 0 0

7-8 4 77 81 77 81 0 0 0

8-9 4 81 85 81 85 0 0 0

9-10 5 85 90 85 90 0 0 0

10-11 1 90 91 90 91 0 0 0


Total Completion Time found out to be: 91 days.

*Note: If we use any software tool, it may vary or reduce based on manual/automatic setups. For above

example we have excluded the holidays.

For scheduling and controlling of project, we have used CPM (Critical Path)

method where activities are deterministic. Another technique is PERT (Project

Evaluation and Review Technique) in which activities are based on probability.

Both are also called as Network diagrams. Above Figure 3.15 shows CPM

which identifies the critical path. „Critical‟ indicates delay of an activity causes

delay in other activities and ultimately delay in completion. We used

Fulkerson‟s rule [22]

to number the events in the network diagram. Rule says,

(i) Event numbers should be unique.

110

(ii) Event numbering should be carried out on a sequential basis from left to

right.

(iii) The initial event which has all outgoing arrows with no incoming arrow

is numbered as 1.

(iv) Delete all arrows emerging from all the numbered events. This will

create at least one new start event out of the preceding events.

(v) Number all new starts events 2, 3 and so on.

Repeat this process until the entire terminal event without any successor

activity is reached, number the terminal node suitably.

To determine the Critical Path:

Step 1: Make a forward pass through the network. For each activity (i)

beginning at the Start node, compute:

Earliest Start Time (ES) = the maximum of the earliest finish times of all

activities immediately preceding activity (i). (This is 0 for an activity with no

predecessors.). This is the earliest time an activity can begin without violation

of immediate predecessor requirements.

Earliest Finish Time (EF) = (Earliest Start Time) + (Time to complete activity

(i)). This represent the earliest time at which an activity can end.

Step 2: Make a backwards pass through the network as follows: Move

sequentially backwards from the Finish node to the Start node. At a given node,

j, consider all activities ending at node j. For each of these activities, (i,j),

compute:

Latest Finish Time (LF) = the minimum of the latest start times beginning at

node j. (For node N, this is the project completion time.). This is the latest time

an activity can end without delaying the entire project.

111

Latest Start Time (LS) = (Latest Finish Time) - (Time to complete activity

(i,j)). This is the latest time an activity can begin without delaying the entire

project.

Step 3: Calculate the slack time for each activity by:

Slack = (Latest Start) - (Earliest Start), or

= (Latest Finish) - (Earliest Finish).

Slack or Float is the maximum amount of time that activity can be delay in its

completion before it becomes a critical activity. [22] [23]

3.5 Project Costing:

Project cost estimation and scheduling are generally accepted together. The

costs of development mainly include costs of the effort involved which in

prolongation can be used to obtain both cost and the schedule estimation.

However, some organizations may evaluate cost estimation before identifying

estimated schedule. These early estimates can be used to determine a budget for

the project or to set a cost for the software for Clients. [4]

There are three parameters involved in computing the total cost of a software

development project:

• Hardware and software costs including maintenance

• Travel and training costs

• Effort costs (the costs of paying software engineers).

Project cost can be obtained by multiplying the estimated effort with the

manpower cost per month. Once the schedule estimation is complete, it is easy

to compute the rate per hour for each of the resources roles such as project

manager, team lead, senior software engineer and programmers etc. However,

in addition to manpower cost, a project would incur several other types of costs

which we shall refer to as the overhead costs. The overhead costs would include

112

the costs of hardware and software required for the project and the company

overheads for administration, office space, etc. Cost estimation is performed to

assist decision makers in setting a winning price and managing the profit.

Multiply the individual resources by the rate to obtain individual resource costs.

Then, aggregate the individual cost to get the overall project cost for resources.

Add other overheads as applicable.

Parthasarathy (2007) had specified an important technique called

preparing Resource Loading Chart (RLC) for Costing of Project. Resources are

one of the vital consumers of cost during software development process.

Preparing RLC is very important activity and has to be done carefully. Any

wrong assignment of resources may affect the planned schedule and thereafter

overall expected outputs of project. Consider, for the project Total Effort is 42

Person-Month and Duration is 7 Months. Therefore, Total Person required to

complete the project will be 6.

Table 3.23 shows the Resource Loading Chart for the 6 person and later

on this RLC will be valuable resource sheet in obtaining over all costing sheet

of project.

Table 3.23: Resource Loading Chart

Resource Month1 Month2 Month

3

Month

4

Month

5

Month

6

Month

7

Total

PM

Project

Manager 1 1 1 1 1 1 1 7

Technical

Analyst 1 1 1

1 1 5

Business

Analyst 1 1 1 2 2 2 2 11

Programmers

1 2 3 2 2 10

Testers

1 1 1 1 4

Configuration

Controllers 1 1 1 1 1 5

Total Effort 2 3 5 8 8 8 8 42

PM: Person Month


113

Next step would be preparing overall cost estimation sheet. Multiply each

resource allocated duration with individual resource cost and aggregate overall

cost. Then, add all overheads and other miscellaneous amount with above

aggregated amount. Include or exclude some taxes or discounts and finalize the

COSTING of project. A sample costing sheet is mentioned in Table 3.24 below:

Table 3.24: Sample Cost Estimation Sheet

COST ESTIMATION SHEET

Resources Duration

(in Months)

Rate per

Month(in Rs)

Cost

(in Rs.) Remarks

Project Manager 7 50000 350000

Technical

Analyst 5 20000 100000

Business Analyst 11 15000 165000

Programmers 10 12000 120000

Testers 4 10000 40000

Configuration

Controllers 5 8000 40000

Total Cost for Resources (A) 815000

Other Over Heads

Hardware and Networking 100000

Software 200000

Travelling and Stay 50000

Training Cost 30000

Miscellaneous 20000

Total Cost of Other Over Heads (B) 400000

Estimated Cost(A+B) 1215000

Tax (+) (10%) 121500

Discount (-) (5%) 60750

Overall Estimated Cost (in Rs.) 1275750

* Terms and Conditions Source: Compiled by Researcher

Hence, using appropriate size, effort and schedule estimation, we can be

able to calculate overall estimated cost of project.

114

3.6 Conclusion:

I have highlighted the significance of Estimation and Software Estimation

Techniques in the organizations. In most of the reference books , authors have

classified the Estimation Techniques into various types such as Top-Down

Estimation and Bottom Up Estimation , Algorithmic and Non-Algorithmic and

so on. I have simply classified them on the basis of process. Standard tables and

set of quality parameters have been used. Examples have been used at

appropriate places to understand each method easily.

References:

1. James F.Peters and Witold Pedrycz. (2000). “Software Engineering: An

Engineering Approach”, WILEY-INDIA EDITION, pp. 505-507,561-

564,

2. Norman, E.F and Shari, L. P. (1997). “Software Metrics: A Rigorous and

Practical Approach”, Second Edition, pp.259-265.

3. Chemuturi, K., M. (2009).”Software Estimation Best Practices, Tools,

and Techniques: A Complete Guide for Software Project Estimators”, J.

Ross Publishing Inc, pp. 49-65, 73-95,115-133.

4. Ian Sommerville (2004), “Software Engineering”, 7th Edition, Pearson

Addison Wesley ©2004 ISBN0321210263, pp.633-634.

5. Ali Bahrami (1999). “Object Oriented Systems Development using

Unified Modelling Language”, McGraw Hill, pp.92-93.

6. Boehm, E., Raymond (2006), “Measuring Software Size, Without

Function Points”, Software Composition Technologies, pp.1-6.

115

7. Swapna, Kishore and Naik, Rajesh. (2010). “Software Requirement and

Estimation”, Tata McGraw-Hill Education Private Limited, pp.152-153.

8. Magne Jorgensen (2005), “Practical Guidelines for Expert-Judgment-

Based Software Effort Estimation”, Simula Research Laboratory, IEEE,

pp.57-63.

9. Potdar, S.M., Puri, Manimala and Potdar,M. P. (2014). “Literature

Survey on Algorithmic Methods for Software Development Cost

Estimation”, International Journal of Computer Technology &

Applications, Vol 5 (1), and ISSN: 2229-6093, pp.183-188.

10. Parthasarathy, M.A. (2007). “Practical Software Estimation: Function

Point Methods for in sourced and outsourced Projects”, Pearson

Education, Inc and Dorling Kindersley Publishing, Inc, pp. 286-287,37-

40.

11. COCOMO-II Model Definition Manual. Version 2.1 © 1995 – 2000

Center for Software Engineering, USC, 2000.

12. Randy K. Smith, Joanne E. Hale and Allen S.Parrish. (2001). “An

Empirical Study Using Task Assignment Patterns to Improve the

Accuracy of Software Effort Estimation,” IEEE Transactions on Software

Engineering, VOL. 27, NO. 3 March, pp.264-267.

13. Hill, R., Peter. (2011).”Practical Software Project Estimation –A Toolkit

for Estimating Software Development Effort & Duration”, Tata

McGraw-Hill Edition, pp.75-79.

14. International Software Benchmark & Standards Group, "Data R8”, 2005.

116

15. Ruhe, M., Jeffery, R, and Wieczorek, I. (2003). “Cost Estimation for

Web Application, presented at Proceedings. 25th International

Conference ICSE 2003”, ACM/IEEE, pp.285-294.

16. Y. F. Li, M. Xie and T. N. Goh. (2009). “A Study of the non-linear

adjustment for analogy based software cost estimation, Empirical

Software Engineering”: An International Journal, © Springer

Science+Business Media, pp.603-643.

17. Vahid, Khatibi and Dayang, N. A. Jawawi. (2010-11).” Software Cost

Estimation Methods: A Review”, Journal of Emerging Trends in

Computing and Information Sciences, Volume 2 No. 1, pp.21-29.

18. Hughes, Bob. Cotterel, Mike and Mall, Rajib. (2011). “Software Project

Management”, Written by Published by Tata McGraw-Hill, p.107.

19. Mohanty, S.K, Bisoi, A. K. (2012). ” Software Effort Estimation

Approaches – A Review”, International Journal of Internet Computing

ISSN No: 2231 – 6965, VOL- 1, ISS- 3, pp.82-88.

20. Chetan Nagar and Anurag Dixit. (2011). ” Software Efforts and Cost

Estimation with a Systematic Approach”, pp.312-316.

21. Thayer, Richard. H (Eds). (2004).” Software Engineering Project

Management”, Second Edition, WILEY publications, pp.203-205.

22. Sharma, S.D. (2010). ”Operation Research –Theory, Methods and

Applications”, Sixteenth Edition, pp. PERT-CPM/1-12.

23. Pannerselvam, R. (2006). “Operation Research”, Published by PHI

learning Private Limited, New Delhi, pp. 355- 370.

Software Estimation Techniques -...

Documents

Transcript of Software Estimation Techniques -...