Software Engineering - Cost Estimation Techniques

1. Chapter 3
Cost Estimation Techniques

2. Software Measurement
Software Measurement: A measurement is an manifestation of the size, quantity, amount or
dimension of a particular attributes of a product or process. Software measurement is a titrate
impute of a characteristic of a software product or the software process. It is an authority within
software engineering. Software measurement process is defined and governed by ISO Standard.
Need of Software Measurement:
1. Create the quality of the current product or process.
2. Anticipate future qualities of the product or process.
3. Enhance the quality of a product or process.
4. Regulate the state of the project in relation to budget and schedule.

3. Classification of Software Measurement:
1. Direct Measurement:
In direct measurement the product, process or thing is measured directly using standard
scale.Direct measures include cost and effort applied in the development of software. Direct
measures of the software include how many lines of code (LOC) produced, execution
speed, memory size, and defects reported.
2. Indirect Measurement:
In indirect measurement the quantity or quality to be measured is measured using related
parameter i.e. by use of reference. Indirect measures include functionality, quality,
complexity, efficiency, reliability, and maintainability of the software.
3. Note:Direct measure is easy to compute compare with indirect measure of software. We
can calculate the cost of the software development but it is difficult to calculate the
functionality and quality of the software.

4. Software Metrics
Software metrics is a standard of measure that contains many activities which involve some
degree of measurement. It can be classified into three categories: product metrics, process
metrics, and project metrics.
● Product metrics describe the characteristics of the product such as size, complexity,
design features, performance, and quality level.
● Process metrics can be used to improve software development and maintenance.
Examples include the effectiveness of defect removal during development, the pattern
of testing defect arrival, and the response time of the fix process.
● Project metrics describe the project characteristics and execution. Examples include
the number of software developers, the staffing pattern over the life cycle of the
software, cost, schedule, and productivity.

5. Size Oriented Metrics
● Size oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced.
● If a software organization maintains simple records, a table of size-oriented measures, such
as shown in below fig.
● The table lists each software develop project that has been completed over past few years
and corresponding measure for that project referring to the table entry for project alpha:
12,100 lines of code were developed with 24 person-months of effort at a cost 0f $168,000.
● It should be noted that the effort and cost recorded in the table represents all software
engineering activities (analysis, design, code and test) not just coding. Further information for
project alpha indicates that 365 pages of documentation were developed, 134 error were
recorded before the software was released and 29 defects were encountered after release to
the customer within the first year of the operation.
● Three people worked on the development of software for project alpha.

6. ● To develop metrics that can be assimilated with similar metrics from other projects, we
choose Line of Code as our normalization value.
● So, from information given in table , a set of simple size-oriented metrics can be
developed for each projects:
Errors per KLOC (Thousands line of code)
Defects per KLOC,
$ Per KLOC,
Pages of documentation per KLOC

7. ● Size-oriented metrics are not universally accepted as the best way to measure the
software process but most of the controversy swirls around the use line of code as key
measure.
● Proponent of line of code measure claims that LOC is an “artefact” of all software
development projects that can be easily counted, that many existing software
estimation
● models use LOC or KLOC as a key input, and that a large body of literature and data
predicated on LOC is already exists.

8. Function Oriented Metrics
Function-oriented software metrics use a measure of the functionality delivered by the
application as a normalization value. Since ‘functionality’ cannot be measured directly, it
must be derived indirectly using other direct measures. Function-oriented metrics were first
proposed by Albrecht , who suggested a measure called the function point. Function points
are derived using an empirical relationship based on countable (direct) measures of
software's information domain and assessments of software complexity.

9. Function points are computed by completing the table as shown below. Five information domain characteristics are determined
and counts are provided in the appropriate table location. Information domain values are defined in the following manner:

10. Number of user inputs. Each user input that provides distinct applicationoriented data to the
software is counted. Inputs should be distinguished from inquiries, which are counted separately.
Number of user outputs. Each user output that provides applicationoriented information to the
user is counted. In this context output refers to reports, screens, error messages, etc. Individual
data items within a report are not counted separately.
Number of user inquiries. An inquiry is defined as an on-line input that results in the generation
of some immediate software response in the form of an on-line output. Each distinct inquiry is
counted.
Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a
large database or a separate file) is counted.
Number of external interfaces. All machine readable interfaces (e.g., data files on storage
media) that are used to transmit information to another system are counted.

11. LOC and FP Estimation
Estimation of the size of software is an essential part of Software Project Management. It
helps the project manager to further predict the effort and time which will be needed to build
the project. Various measures are used in project size estimation. Some of these are:
● Lines of Code
● Number of entities in ER diagram
● Total number of processes in detailed data flow diagram
● Function points

12. Lines of Code(LOC)
1. Lines of Code (LOC): As the name suggest, LOC count the total number of lines of source code
in a project. The units of LOC are:
● KLOC- Thousand lines of code
● NLOC- Non comment lines of code
● KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of same kind. The experts use it to
predict the required size of various components of software and then add them to get the total
size.

14. Advantages:
● Universally accepted and is used in many models like COCOMO.
● Estimation is closer to developer’s perspective.
● Simple to use.
Disadvantages:
● Different programming languages contains different number of lines.
● No proper industry standard exist for this technique.
● It is difficult to estimate the size using this technique in early stages of
project.

15. Function Point (FP)
Function Point Analysis: In this method, the number and type of functions
supported by the software are utilized to find FPC(function point count). The
steps in function point analysis are:
● Count the number of functions of each proposed type.
● Compute the Unadjusted Function Points(UFP).
● Find Total Degree of Influence(TDI).
● Compute Value Adjustment Factor(VAF).
● Find the Function Point Count(FPC).

16. ● Count the number of functions of each proposed type: Find the number of
functions belonging to the following types:
● External Inputs: Functions related to data entering the system.
● External outputs:Functions related to data exiting the system.
● External Inquiries: They leads to data retrieval from system but don’t
change the system.
● Internal Files: Logical files maintained within the system. Log files are not
included here.
● External interface Files: These are logical files for other applications which
are used by our system.

17. ● Compute the Unadjusted Function Points(UFP): Categorise each of the five
function types as simple, average or complex based on their complexity.
Multiply count of each function type with its weighting factor and find the
weighted sum. The weighting factors for each type based on their complexity
are as follows:

18. ● Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to find
the degree of influence of each of them. The sum of all 14 degrees of influences will give
the TDI. The range of TDI is 0 to 70. The 14 general characteristics are: Data
Communications, Distributed Data Processing, Performance, Heavily Used Configuration,
Transaction Rate, On-Line Data Entry, End-user Efficiency, Online Update, Complex
Processing Reusability, Installation Ease, Operational Ease, Multiple Sites and Facilitate
Change.
Each of above characteristics is evaluated on a scale of 0-5.
● Compute Value Adjustment Factor(VAF): Use the following formula to calculate VAF
VAF = (TDI * 0.01) + 0.65
● Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF

19. Advantages:
● It can be easily used in the early stages of project planning.
● It is independing on the programming language.
● It can be used to compare different projects even if they use different
technologies(database, language etc).
Disadvantages:
● It is not good for real time systems and embedded systems.
● Many cost estimation models like COCOMO uses LOC and hence FPC
must be converted to LOC.

20. Effort Estimation
Estimation is the process of finding an estimate, or approximation, which is a value that
can be used for some purpose even if input data may be incomplete, uncertain, or
unstable.Estimation determines how much money, effort, resources, and time it will
take to build a specific system or product. Estimation is based on −
● Past Data/Past Experience
● Available Documents/Knowledge
● Assumptions
● Identified Risks
The four basic steps in Software Project Estimation are −
● Estimate the size of the development product.
● Estimate the effort in person-months or person-hours.
● Estimate the schedule in calendar months.
● Estimate the project cost in agreed currency.

21. COCOMO-II Model
COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model)
and is developed at University of Southern California. It is the model that allows one to
estimate the cost, effort and schedule when planning a new software development
activity. It consists of three sub-models:

22. 1. End User Programming:Application generators are used in this sub-model. End
user write the code by using these application generators.
Example – Spreadsheets, report generator, etc.
2. Intermediate Sector:
(a). Application Generators and Composition Aids –This category will create
largely prepackaged capabilities for user programming. Their product will have
many reusable components. Typical firms operating in this sector are Microsoft,
Lotus, Oracle, IBM, Borland, Novell.

23. ● (b). Application Composition Sector –
This category is too diversified and to be handled by prepackaged
solutions. It includes GUI, Databases, domain specific components such
as financial, medical or industrial process control packages.
● (c). System Integration –
This category deals with large scale and highly embedded systems.
3. Infrastructure Sector:
This category provides infrastructure for the software development like Operating
System, Database Management System, User Interface Management System,
Networking System, etc.

24. Stages of COCOMO II:
1. Stage-I:
It supports estimation of prototyping. For this it uses Application Composition
Estimation Model. This model is used for the prototyping stage of application
generator and system integration.
2. Stage-II:
It supports estimation in the early design stage of the project, when we less
know about it. For this it uses Early Design Estimation Model. This model is
used in early design stage of application generators, infrastructure, system
integration.
3. Stage-III:
It supports estimation in the post architecture stage of a project. For this it
uses Post Architecture Estimation Model. This model is used after the
completion of the detailed architecture of application generator, infrastructure,
system integration.

25. The COCOMO II application compositio model uses object points, an indirect
software measure that is computed using counts of the number of screens(at the
user interface),reports and Component likely to be required to build the
application.
Each object instance (Screen or report) is classified into one of three complexity
levels(i.e. Simple,Medium ,Difficult).Complexity is a function of the number and
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.

26. Once complexity is determined , the number of screens, reports and component object point are
weighted according to the below table.
When component based development or general software reuse is to be applied , the percent of
reuse is estimated and the object point count is adjusted.
NOP=(object point)*[(100-%reuse)/100], Where NOP is defined as new object points.

27. Putnam Model
The Putnam model is an empirical software effort estimation model. The original
paper by Lawrence H. Putnam published in 1978 is seen as pioneering work in the
field of software process modelling. As a group, empirical models work by collecting
software project data (for example, effort and size) and fitting a curve to the data.
Future effort estimates are made by providing size and calculating the associated
effort using the equation which fit the original data (usually with some error).
In 1976, Putnam studied the problem of staffing of software projects: observed that
the level of effort required in software development efforts has a similar envelope.
found that the Rayleigh found that the Rayleigh-Norden curve Norden curve relates
the number of delivered lines of code to effort and development time.

28. Putnam analyzed a large number of army projects, and derived the expression:
L=Ck K1/3 td4/3
K is the effort expended and L is the size in KLOC.
td is the time to develop the software.
Ck is the state of technology constant and reflects factors that affect programmer
productivity.
Ck=2 for poor development environment no methodology, poor documentation, and
review, etc. Ck=8 for good software development environment software
engineering principles used Ck=11 for an excellent environment

29. Automated/Specialized Estimation Tool

31. Configuration & Administration-Virtual Hosting
Virtual hosting is a method for hosting multiple domain names (with separate
handling of each name) on a single server (or pool of servers). The purpose of
Virtual hosting is hosting more than the website (for e.g. website1.example.com,
website2.example.com, etc.) on a single machine. That would also mean to share
single machine resources such as memory and CPU. The resources are shared and
utilized in such a manner so that maximum efficiency is achieved.
Now with the invention of cloud computing, virtual now serves more purposes than
ever such as solutions like virtual application hosting, virtual server hosting, virtual
storage hosting and sometimes also virtual/entire data center hosting.

32. There are many ways to configure a virtual host and most of the ways that are used
today are given below:
● IP Based
● Port-Based
● Name Based
● IP Based:It is one of the simplest methods among three and it can be used to apply
different directives based on the IP address. In IP based virtual hosting, we use
different IPs for each domain.The multiple IPs will actually point to the unique
domains on the server and there would only be one IP for a server. This virtual
hosting is achieved by creating multiple IP addresses for the single server.

33. Port-Based:
Port-based virtual hosting is also similar to the IP based virtual hosting, the
difference is – Instead of using the different IP address for each of the virtual
hosts, we use different ports in which the servers are configured to respond to
multiple websites that are dependent on the port of the server.
Name Based:
Name-based virtual hosts are the most commonly and frequently used virtual
hosting technique that is used today. The name-based Virtual host will use the
single IP address for all the domains on the given server. When the browser is
trying to connect to the server, it will send a message to the server informing
about the domain name to which it is trying to connect. When the domain name is
provided, the server checks the host configuration and thereby returns the request
with the correct website.