ASSIGNMENT#1

SOFTWARE ENGINEERING
CS – 206

Instructor

Mr.Usman Sahab

Topic: Software Cost Estimation Tool And

Its Utilization
Submitted By

Mr. Muhammad. Irfan Arshad

Roll Number: 1387

BS – CS (4th Semester)

College of Computer Sciences and Information Studies

Government College University, Faisalabad
Background:
Software Cost Estimation is widely considered to be a weak link in software project management. It
requires a significant amount of effort to perform it correctly. Errors in Software Cost Estimation can be
attributed to a variety of factors. Various studies in the last decade indicated that 3 out of 4 Software
projects are not finished on time or within budget or both.
WHAT IS SOFTWARE ESTIMATION?
Estimation is intelligent anticipation of quantum of work that needs to be preformed and the resources
(human resources, monetary resources, equipment resources and time resources) required to perform the
work at a future date, in a defined environment, using specified method.
Software Estimation is that estimation of the software size, software development effort, software
development cost, and software development schedule for a specifies software product in a specified
environment, using defined method, tools, and techniques.
The key terms are:
 Estimation: Defined above
 Software size: The amount of (quantity) of software that needs to be developed.
 Software development effort: The amount of effort, in either person-days or person-hours,
necessary for developing the software product of an estimated size.
 Software development cost: The expenses necessary for developing software of defined size,
including the expense of human effort.
 Software development schedule: the duration, in calendar days or months, that is necessary for
developing the defined amount of software.
Thus we have the following deliverable from software estimation:
 Components that make up the software, as well as their sizes.
 Effort required developing the software.
 Duration (schedule) required for developing the software.
WHY IS SOFTWARE ESTIMATION IMPORTANT?
Software estimation is assuming more important as a natural consequence of increased outsourcing of
software development work. When any work is outsourced, it is necessary to come to an agreement with
the supplier on the price to be paid for the assigned work. In an outsourcing scenario, software estimation
in need for the following reasons:
1. To set the budget for the assignment.
2. To evaluate proposal received from different vendors for software development.
3. To reach an agreement with the selected supplier on size of the software to be developed and the
free for developing the agreed-upon size of the software.
Further, when competition is intense among provider, margins become slim and resources become scarce.
Even if a business develops software in-house, estimation in necessary to evaluate demands for the
software and to apportion the available resources to the highest priority works. For internal software
development, software estimation needed for following reasons:
1. To allocate a budget.
2. To evaluate competing demands for software.
3. To monitor the progress of the development work.
Who is responsible for Software Cost Estimation?
The group of people responsible for creating a software cost estimate can vary with each organization.
However the following is possible in most scenarios
 People who are directly involved with the implementation are involved in the estimate.
 Project Manager is responsible for producing realistic cost estimates.
 Project Managers may perform this task on their own or consult with programmers responsible.
Various studies indicate that if the programmers responsible for development are involved in the
estimation it was more accurate. The programmers have more motivation to meet the targets if
they were involved in the estimation process.

I tum to the problem of associating estimates of effort and time with the project activities. Estimation
involve answering the following questions:
a. How much effort is required to complete each activity?
b. How much calendar time is needed to complete each activity?
c. What is the total cost of each activity?
Software cost estimation and software scheduling are normally carried out together. The costs of
development are primarily the costs of the effort involved, so the effort computation is used in both the
cost and the schedule estimate. However, you may have to do some cost estimation before detailed
schedules are drawn up. These initial estimates may be used to establish a budget for the project or to set
a price for the software for a customer.
There are three parameters involved in computing the total cost of software development project:
a. Hardware and software costs including maintenance
b. Travel and training costs
c. Effort costs (the costs of paying software engineers).
For most projects, the dominant cost is the effort cost. Computers that are powerful enough for software
development are relatively cheap. Although extensive travel costs may be needed when a project is
developed at different sites, the travel costs are usually a small fraction of the effort costs. Furthermore,
using electronic communications systems such as e-mail, shared web sites and videoconferencing can
significantly reduce the travel required. Electronic conferencing also means that travelling time is reduced
and time can be used more productively in software development. In one project where I worked, making
every other meeting a videoconference rather than a face to face meeting reduced travel costs and time by
almost 50%.
Effort costs are not just the salaries of the software engineers who are involved in the project.
Organizations compute effort costs in terms of overhead costs where they take the total cost of running
the organization and divide this by the number of productive staff. Therefore, the following costs are all
part of the total effort cost:
1. Costs of providing, heating and lighting office space
2. Costs of support staff such as accountants, administrators, system managers, cleaners and
technicians
3. Costs of networking and communications
4. Costs of central facilities such as a library or recreational facilities
5. Costs of Social Security and employee benefits such as pensions and health insurance.
This overhead factor is usually at least twice the software engineer's salary, depending on the size of the
organization and its associated overheads. Therefore, if a company pays a software engineer $90,000 per
year, its total costs is at least $180,000 per year or $15,000 per month.
Once a project is underway, project managers should regularly update their cost and schedule estimates.
This helps with the planning process and the effective use of resources. If actual expenditure is
significantly greater than the estimates, then the project manager must take some action. This may involve
applying for additional resources for the project or modifying the work to be done.
Software costing should be carried out objectively with the aim of accurately predicting the cost of
developing the software. If the project cost has been computed as part of a project bid to a customer, a
decision then has to be made about the price quoted to the customer. Classically, price is simply cost plus
profit. However, the relationship between the project cost and the price to the customer is not usually so
simple.
Software pricing must take into account broader organizational, economic, political and business
considerations, such as those shown in Figure 26.1. Therefore, there may not be a simple relationship
between the price to the customer for the software and the development costs. Because of the
organizational considerations
Involved, project pricing should involve senior management (i.e., those who can make strategic
decisions), as well as software project managers.
For example, say a small oil services software company employs 10 engineers at the beginning of a year,
but only has contracts in place that require 5 members of the development staff. However, it is bidding for
a very large contract with a major oil company that requires 30 person years of effort over 2 years. The
project will not start up for at least 12 months but, if granted, it will transform the finances of the small
company. The oil services company gets an opportunity to bid on a project that requires 6 people and has
to be completed in 10 months. The costs (including overheads of this project) are estimated at $1.2
million. However, to improve its competitive position, the oil services company bids a price to the
customer of $0.8 million. This means that, although it loses money on this contract, it can retain specialist
staff for more profitable future projects.

The Software Estimation Process:

Generally the Software Cost estimation process comprises of 4 main steps:
1) Estimate the size of the development product.
This comprises of various sub-steps or sub tasks. These tasks may have been done already during
Requirement Analysis phase. If not then they should be done as a part of the estimation Process.
Important thing is that they should be done to ensure the success of the Estimation Process and
the Software Project as a whole
a. Create a detailed Work Break down Structure. This directly impacts the accuracy of the estimate.
This is one of the most important steps. The Work Break down structure should include any and
all tasks that are within the scope of the Project, which is being estimated. The most serious
handicap is the inability to clearly visualize the steps involved in the Project. Executing a
Software Project is not just coding.
b. The work Break down structure will include the size and complexity of each software module
that can be expressed as number of Lines of Code, Function Points, or any other unit of measure.
c. The Work Break down structure should include tasks other than coding such as Software
Configuration Management, various levels and types of Testing, Documentation,
Communication, User Interaction, Implementation, Knowledge Transition, Support tasks(if any)
and so on.
d. Clearly indicate or eliminate any gray areas (vague/unclear specifications etc.)
e. Also take into account the various Risk Factors and down times. There are many different Risk
Factors involved – Technical aspects such as availability of the Environment, Server/Machine
uptime, 3rd party Software Hardware failures or Human aspects – Employee Attrition, Sick time,
etc. Some of them may seem to be ‘overkill’ but real world experience shows that these factors
affect the time lines of a project. If ignored they may adversely impact the Project timelines and
estimates.
 2) Estimate the effort in person-hours.
The Result of various tasks involved in step 1 is an effort estimate in person hours. The effort of
various Project tasks expressed in person-hours is also influenced by various factors such as:
a. Experience/Capability of the Team members.
b. Technical resources.
c. Familiarity with the Development Tools and Technology Platform.
3) Estimate the schedule in calendar months:
The Project Planners work closely with the Technical Leads, Project Manager and other
stakeholders and create a Project schedule. Tight Schedules may impact the Cost needed to
develop the Application.
4) Estimate the project cost in dollars (or other currency):
Based on the above information the project effort is expressed in dollars or any other currency.
Measuring the Size Complexity of the Software Program:
This is one of the most elusive aspects in the Software Cost Estimation Process.
There are different methodologies for arriving at and expressing the size/complexity of the Software
Program. Some of the popular ones are
1. Function Points
2. Lines of Code
3. Feature Points
4. Mk II function points
5. 3D Function Points
6. Benchmarking
We briefly explain each of the above methods
Function Points
The Function Point methodology was developed by Allan Albrecht at IBM. This methodology is based on
the belief that the size of a software project can be estimated during the requirements analysis. It takes
into account the inputs and outputs of the system. Five classes of items are counted:
1. External Inputs
2. External Outputs
3. Logical Internal Files
4. External Interface Files
5. External Inquiries
The Total Function Point count is calculated based on the
a. Counts for each of these items
b. The weighting factors and adjustment factors in this methodology
What are function points and why count them?
“Function points are a measure of the size of Software applications and the projects that build them. The
size is measured from a functional, or user, point of view. It is independent of the computer language,
development methodology, technology or capability of the project team used to develop the application.”
Function points are not a perfect measure of effort to develop an application or of its business value,
although the size in function points is typically an important factor in measuring each. Since the function
point count for an application is independent of the technology used to develop the application it can be
used for almost all types of applications such as GUI, OOP, Client Server, etc.
Since function points are based on screens, reports and other external objects, this measure takes the
users' view. In these days of outsourcing and other confusion regarding the role of IT in an organization,
understanding the users' view is of critical importance!
Lines of code:
Counting lines of code measures software from the developers' point of view The number of lines of code
is the traditional way of measuring the application size. Many people consider this method as irrelevant
now. There are technical problems with the lines of code measure. It is difficult to compare lines of code
when a mix of technologies is used. There is no standard definition of what a line of code is. A Program
may have blank lines, comments, data declarations, and multi-line statements.
Feature points Methodology:
It was developed by Software Productivity Research (SPR) in 1986. This technique takes into account the
number of algorithms used in the application. It is compatible with the Function Points Methodology. The
size calculated by the two methods for an ordinary transactional program would be the same. Feature
Points Methodology is generally more useful for estimation in real-time process control, mathematical
optimization and various embedded systems. The estimates are higher and considered more accurate in
these cases.
Mk II function points Methodology:
This was developed Charles Symons in 1984 at Nolan, Norton & Co., part of KPMG Management
Consulting. The Original Function Point approach suffers from the following weaknesses:
It is often difficult to identify the components of an application.
a. The original Function Point Methodology assigned weights to function point components based
on "debate and trial."
b. The original Function Point Methodology did not provide a means of accounting for internal
complexity. ‘Feature points’ technique addresses these issues.
c. When small systems are combined into larger applications. Function Points Methodology makes
the total function point count less than the sum of the components.
MKII decomposes the application being counted into a collection of logical transactions. Each transaction
consists of an input, a process and an output. For each transaction, Unadjusted Function Points (UFP)
become a function of the number of input data element-types, entity-types referenced and output data
element-types. The UFPs for the entire system are then summed. Mk II is widely used in the UK, India,
Singapore, Hong Kong and Europe. Users include governmental organizations, finance, insurance, retail
and manufacturing.
3D function points:
This methodology was developed by Boeing Company and published in 1992. The new technique was
designed to address two classic problems associated with the Albrecht approach( the original Functional
Point Methodology).
a) The original Functional Point Methodology is not user friendly.
b) It is inaccurate when measuring complex scientific and real-time systems.
The 3D function points takes into account the following Dimensions - data, function and control. The data
dimension is similar to the original Function Point Methodology. The function dimension accounts for the
transformations or algorithms. The control dimension accounts for transitions or changes in application
state.
Benchmarking:
Over the years many Organizations with significant development experience and mature processes have
collected metrics on the various software development projects. These include the time, effort required to
develop applications on various platforms and in various Business Domains. Based on this data
benchmarks are created.
Each new software module to be developed can be categorized using the
a) Number of inputs
b) Number of outputs
c) Number of transactions
d) Algorithms
e) Features of the module
Based on the above factors the module can be categorized for example as Simple, Medium or Complex. If
it is too Complex you could express it in multiples of the above three categories. The baseline effort in
terms of person-hours it takes for each category is predefined based on historical data/metrics for a
similar platform. This figure can be improvised/refined over a period of time This can be correlated to an
algorithm for calculating Car Insurance Premium. This is used to estimate the size and the effort needed
for Software Development.
Summary:
In this we discussed the various steps in Software Cost Estimation We also discussed some of the popular
techniques and industry best practices for Software Cost Estimation.

REFERENCE MATERIALS:

Software Engineering by Ion Sommerville (chapter No. 26)

Software estimation best practices, tools & techniques By Murali Chemuturi (chepter No.01)

http://www.exforsys.com/tutorials/testing/software-cost-estimation.html