Institute of Information and Communication Technology (IICT)
Bangladesh University of Engineering and Technology (BUET)
Course: ICT-6010, Title: Software Engineering and Application Development
Class handouts, Lecture-7
Software Estimation (size, effort, schedule and cost estimation)
7.0 What is Requirements Engineering?
IEEE Standard 610.12-1990 defines requirement in the context of a software project as follows:
1. A condition or capability needed by a user to solve a problem or achieve an objective;
2. A condition or capability that must be met or possessed by a system or system component to satisfy
a contract, standard, specification, or other formally imposed documents;
3. A documented representation of a condition or capability as in (1) or (2).
Abbot in his book, An Integrated Approach to Software Development defines software requirements
as: "Any function, constraint, or other property that must be provided, met, or satisfied to fulfill the
need of the system's intended user(s)."
The term "requirements" is used to refer to all the requirements, these may be classified as functional
and non-functional. Functional requirements typically focus on the "what" of the system and identify
the "functions" and "data" related requirements. Non-functional requirements focus on the "how well"
aspects of the system and identify attributes like "performance", "maintainability", "scalability",
"inter-operability", "reliability", "portability" and the "constraints" under which the system needs to
operate. Often, persons gathering requirements focus on functional requirements. Non- functional
requirements are typically missed out because most commonly used requirements analysis
methodologies (structured analysis, object oriented analysis) focus on the representation of functional
requirements. Users may never accept systems that meet all the functional requirements but ignore
some important non- functional requirements.
The establishment and use of sound engineering principles to gather, analyze, document, review and
manage software requirements can be called software requirements engineering. Requirements
engineering can be divided into two main set of activities -- requirements definition and
requirements management (see Figure in the next page).
1
Requirements Definition consists of:
1. Requirements Elicitation or gathering of requirements.
2. Requirements Analysis or modeling: Requirements that are gathered are modeled and analyzed
using modeling tools such as data flow diagrams, object oriented modeling techniques, entity
relationship diagrams, etc.
3. Requirements Documentation: Here the requirements that are gathered and modeled are put
together in a document, typically known as the Software Requirements Specification (SRS).
4. Requirements Review: This consists of review of SRS by all stakeholders. The reviewed and
approved SRS forms the basis for the work products to be created in the later parts of the software
life cycle.
Requirements Management consists of:
1. Requirements Change Management: This involves systematic handling of changes to agreed
requirements (SRS) during the course of the project.
2. Requirements Traceability: This consists of maintaining traceability between the agreed (and
changed) SRS and the other work products (like design documents, test plans) created downstream
in the software life cycle.
7.1 Two Views of Sizing
Most systems can be seen from two viewpoints, the user's view and the developer's view.
Consequently the size of the system also can be seen from the same two viewpoints, the user's
functional perspective and the developer's technical perspective. The perspective of the user relates to
what the system can do for the user and functional size measures support the user's perspective. The
developer sees the system in terms of the internals of what needs to be built and is able to relate better
to technical size measures.
At the initial stages of the system, the functional view of the user is the only view really available.
Any attempts to visualize the system in terms of number of programs or lines of code are really
extrapolations from the functionality that the system is expected to provide. As the project progresses,
more is known about the technical aspects of the project. As the architecture and detailed design
become clearer, the technical size of the software becomes clearer.
Therefore it is natural that software size estimation done early in the life cycle typically uses
functional size measures, and size estimates done in the middle of the life cycle use technical size
measures.
Ideally, the two measures should give the same picture of the size, and there should be well accepted
conversion methods between the two measures (like conversion between miles and kilometers), since
the system is the same. Unfortunately, this does not happen for various reasons such as:
 Over-design: The system designed may have more features than what were needed to meet the
functional and non-functional requirements.
 Quality of design and code: The actual technical implementation of the functionality would
be verbose / redundant and there might be segments of the system that are never used. Also, a
style of coding varies across individuals.
In the initial stages, size estimation is subject to higher margins of error, as very little is known in
terms of requirements. As more detail becomes available, it becomes possible to get better estimates
with lesser and lesser margins of errors. The system can be decomposed and each component
estimated separately and technical measures become more relevant.
The functional size of the system is calculated based on the known functionality of the system before
the detailed design phase. International Function Point User Group's (IFPUG) Function Point
Analysis (FPA) and Charles Symons' Mark II Function Points (Mark II) are two of the most widely
used methods for obtaining function points, a functional size measure.
2
In technical size estimation, the estimation is done in terms of the actual software size-such as the lines
of code in the software. When there is sufficient knowledge about the system, one of the common
ways of sizing it is by decomposing the system into smaller pieces -- these can then be size estimated
individually. The sum of the size estimates of each of the decomposed part is assumed to be the size of
the overall system. Decomposing divides a large and complex problem into small manageable parts
that can be sized easily. This is the divide and rule approach, and a decomposed representation of the
system is called the system breakup structure. In such cases, the size estimate of each component is
typically expressed in terms of number of lines of code (LOC). The Delphi's wideband technique is a
means of arriving at a size estimate through synergy between various experts.
7.2 Function Point Analysis (FPA)
Function point analysis (or FPA) is a popular method for estimating and measuring the size of
application software based on the functionality of the software from the user's point of view. The
function point analysis measure quantifies the functionality requested and provided to the user based
on the user's requirements and high level logical design. Through this method, the size of an
application system's functionality is calculated in terms of Function Point Count (or FPC).
Allan J Albrecht of IBM proposed Function Point Count (FPC) as a size measure in the late 1970s.
Albrecht had taken-up the task of arriving at size measures of software systems to compute a
productivity measure that could be used across programming languages and development
technologies. Albrecht also wanted the size measure to reflect the concerns of the user.
Given this perspective, the focus was on the visible, user identifiable, external aspects of software. The
approach was to enumerate these aspects and combine these using weights to arrive at a composite
functional measure of the software size. The Function Point Analysis method that evolved was based
on analysis of considerable past project data and use of trial and error to fit a model that seemed to
best represent the software size in terms of its functionality. The first version of the model was
presented in 1979 at a conference in California.
Today, work continues to develop and calibrate the Function Point model of Albrecht. Variations of
the model (that address some perceived handicaps of the model) have also been proposed and evolved
and calibrated. By convention, the term Function Point Analysis (or FPA) is used with reference to the
Albrecht's Function Point model (as it has further evolved), while other models have various prefixes
added to "function point", or slightly varying names. Examples of variations are Mark II FPA, and
Full Function Points.
The current promoter of Albrecht's function point model is the International Function Point User's
Group (IFPUG). IFPUG evolves the FPA method and periodically releases the Counting Practices
Manual for consistent counting of function points across different organizations.
According to IFPUG, the objectives of function point analysis are to:
 Measure functionality of a software system as seen from the user's perspective.
 Measure the size of software systems independent of technology used for implementation.
 Create a measurement methodology that is simple enough to minimize the overhead of the
measurement process.
 Create a consistent measure among various projects and organizations.
Function Points can be computed for a new system being developed (called Development Function
Points) as well as for enhancement work (called Enhancement Function Points).
7.3 MARK II Function Point Analysis (FPA)
MARK II FPA was developed by Charles Symons, a partner in Nolan, Norton & Co., an information
technology firm of KPMG that advises on use of IT. The MARK II FPA method was developed in
1990 and is compatible with the SSADM methodology that is popular in the UK. Mark II FPA was
3
chosen as the best estimating tool by Fisher and Gorman in 1991 and has been available as a public
domain methodology since April 1991.
Mark II was developed to address some perceived difficulties in the FPA model both in what the
model does, and how users interpret it. The "difficulties" of FP A that Symons perceived and that lead
him to develop Mark II are as follows:
 Identification of files (ILFs) in FPA is tricky-and there is confusion in de- scribing what a
"logical file" is. The entity relationship aspect of a system is ignored in FPA.
 The basis for the weights used (given as "debate and trial" and chosen for "giving good
results") is not really satisfactory as it does not have statistical backing, and may need a second
look.
 The choice of the fourteen General System Characteristics (GSCs) is restrictive and binding
and may not always be suitable-other factors may need to be considered.
 Internal processing complexity is not given sufficient importance.
 The FP A method is more suitable for systems with discrete components rather than integrated
systems.
 When smaller systems are combined into larger applications, the FP count of the larger system
is less than the sum of the FP count of the smaller systems.
.Mark II is a continuous measure, a fact that overcomes the problem of IFPUG where once a threshold
is reached, the component size is limited. Mark II FPCs for larger systems are therefore higher than
the FPCs arrived at by the IFPUG FPA method.
Mark II treats the system as a collection of logical transactions, where a logical transaction is triggered
by a unique event of interest to the user. A logical trans- action is the lowest level of self-consistent
process. Each logical transaction consists of:
 Input across the boundary,
 Processing involving stored data within the boundary, and
 Output back across the boundary.
The analysis requires a well-defined boundary-the (conceptual) interface between the software and the
user.
The components of the input and output of each logical transaction are the number of data elements
crossing the boundary-called the input data elements and output data elements.
The processing element of each logical transaction is further understood in terms of the stored data it
manipulates. For this it is necessary to have an entity modeling of the system which enables
identifying what the primary entities are. Mark II looks at a system as comprising two types of entities:
 Primary entities, and
 System entities.
Primary entities are the "main entities" for which system is constructed to collect and store data Mark
II uses the Third Normal Form while identifying the primary entities. Users can easily recognize
primary entities.
All other entities are treated as a single entity called "system entity" (an application has only one
system entity). Tables/files created for the purpose of security, recovery and other such non-user
functions are not considered.
The component of processing that contributes to the function point counting is the count of primary
entities referenced by the transaction. If the system entity is also referenced, the count is incremented
by one. The count obtained for each logical transaction is the number of entities referred.
4
To identify logical transactions, end user functions and conversion and installation user functions are
considered. Application specific operations and functions carried out on behalf of the user are also
considered. The scope of a system excludes standard functions carried out for computer integrity-like
log-on, recovery, backups and technical functions introduced by the Information Systems staff but not
needed by the user.
The Mark II FPA is concerned with calculating the function points (earlier called unadjusted function
points). Essentially, the function points (now also called function point index or FPI) are obtained by
first computing each logical transaction size and summing this up for all identified logical
transactions. Each logical transaction size is computed as:
(Weight for input data elements) * (Number of input data elements) +( Weight for entities referenced)
* (Number of entities referred) + (Weight for output elements) * (Number of output data elements )
The weights used for this computation may be calibrated and fine-tuned based on past data. Industry
based calibration figures are available from the Mark II counting manual.
The weights used for this computation may be calibrated and fine-tuned based on past data. Industry
based calibration figures are available from the Mark II counting manual.
Steps followed in Mark II (see Figure below) to calculate the function points are:
 Determine the viewpoint, purpose, type and boundary of the count-identify
the customer and purpose of the count and whether the count required is accurate or approximate,
determine the boundary of the system.
 Identify and categorize data entity types-for this, construct an entity model of the system to
identify primary entities.
5
 Identify the logical transactions.
 For each logical transaction, identify and count the number of input data element types (Ni),
number of referenced data element types (Ne), and number of output data element types (No).
 Calculate the Mark II FPI –
 use these sums in the formula below to get the logical transaction size,
Wi * (Ni) + We * (Ne) + Wo * (No)
7.3.1 Other Function Point Extensions
While the concepts of FP A can be used for any type of software project, FP A is considered most
effective while sizing MIS applications.
There have been many individuals and organizations who have tried applying FP A to a variety of
application areas and technologies and who have therefore come up with their own comments and
suggestions. Practitioners need to be aware of the on-going work in the area of using FPA.
The main FPA (evolved from Albrecht's model), Mark II FP and Full Function Points have been
discussed in some detail. As of now, these are the more prominent models in use.
To help practitioners use FPA for new technologies, guidance is available from various experts. The
IFPUG provides this guidance through published case studies and other literature, so that people
counting the function points can do so consistently and suitably. For example, IFPUG has case studies
for real-time applications, GUI, object oriented systems, etc.
7.3.2 Feature Points
A handicap of function points mentioned by various users is its limitation in truly reflecting the
complexity of software that is algorithm rich (and not necessarily heavy on inputs and outputs). Since
the focus of function points is inputs and outputs, the counts generated for software such as real-time,
system software, embedded software, communication software, process control software does not fully
reflect the complexity within the process (thus ending up as an underestimate).
Feature points is a method developed by Capers Jones (through Software Productivity Research, Inc.)
to apply function point logic to software such as system software, communication software, etc.
Feature points method uses a superset of FP A. It differs from FP A broadly in as much as it has:
 An additional parameter to measure Algorithms with a weight of 3. Algorithms are treated
similar to ILFs (Internal Logical Files), EIs (external inputs) EO (external outputs), etc.
 Reduced weights for ILFs (an average of 7 instead of 10).
An algorithm is defined for this purpose as "a set of rules which must be completely expressed to
solve a significant computational problem". Typical types of algorithms are sorting, searching, steprate calculation functions, feedback loops, etc.
Capers Jones points out that feature points count for information systems would be the same as (or
similar to) the function point count. However, for systems with algorithms, the count will be higher
using feature points.
7.3.3 Object Points
"Object points" is an extension of the function point concept considered valid for what COCOMO II
model describes as "application composition" and for prototyping projects. These are applications that
are known well enough in terms of their interoperable components, yet too diverse to be created in
domain specific tools (like spreadsheets).
In the object point model, the term object is used for objects like screens, reports and 3GL components
(modules in third generation programming languages). The term "object" should not be confused with
the "objects" of object oriented methodologies.
Objects are counted using the standard definitions as applicable in the specific ICASE (integrated
CASE) environment being used. Each object is classified as simple, medium or difficult based on the
values of its characteristics. The model includes schemes to be used for such classification-for
6
example, screens are classified based on the number of views and sources, while reports are classified
based on the number of sections and sources. Weights are used for the three object types (screen,
report and 3GL components) to determine the total object point count. The total object point count is
not equivalent in its units of measure to FPC or Mark II FPC.
7.3.4 Directions in Functional Size Measurement
Further work on the various functional size measurements is going on in the following ways:
 The design authorities of the main function point models (IFPUG and UKSMA) continue to
improve their models by collecting data and calibrating the models. They also provide
guidance to users through papers, publications, seminars, workshops and certification courses
in counting.
 Researchers and users of the methods come up with new models that they feel would be an
improvement for functional size measurement, typically for some special types of
applications.
 A set of experts on various functional measurements have together formed an initiative called
COSMIC to come up with a consolidated functional size measurement.
 An international standard on functional size measurement (ISO 14143) is being worked on.
7.3.5 ISO Standard for Functional Size Measurement
An ISO standard, ISO 14143 is under construction, with the first part having been released in 1998.
This part specifies the functional size measurement concepts.
The standard requires that any technique for functional size measurement (FSM) must measure the
functional requirements of the application under consideration.
This measurement must be in terms of one or more types of base logical components (BLC). Each
BLC must have an explicit relationship with the application boundary (a boundary being a conceptual
interface between the software under study and its users). There must be rules to establish the identity
of instances of various BLC types and also for assigning numeric values to each BLC instance. The
functional size is then the summation of the size of the each of the instances.
Once all parts of the standard are published and formally released, these will form an important input
to further evolution of the various FP models.
7.3.6 COSMIC
COSMIC is the acronym for Common Software Measurement International Consortium. The aim of
COSMIC is to develop a new set of functional size measures that draw upon the best features of
IFPUG, Mark II, FFP, etc. The desirable characteristics of the measures COSMIC aims to evolve are:
 Size should be measured from user requirements.
 The method should be academically sound and compatible with the modem ways of stating
requirements (but independent of specific methods).
 The measurement should be compatible with the ISO 14143 standards that have been
developed.
7.4 LOC Estimation
Lines of code were one of the first size measures used by software developers. The measure became
popular because in the early systems, most of the developer time was spent writing code and code was
the most visible output of the development cycle. It was also easy to verify whether the estimate was
accurate by counting the lines 'of code at the end of the project. Early definition of this measure
included all lines of code, whether blank lines, comment lines, declarations or executable statements.
Later practitioners vary in whether they include or exclude data declarations, blank lines and
7
comments, and how they count statements combined on one physical line, or a single statement split
over two physical lines.
LOC is a technical measure as it measures the software from the developer's technical point of view,
not the user's functional point of view.
In general, LOC is found convenient for a variety of reasons:
 Traditionally, programmers think in terms of LOC.

LOC is easy to check for most environments have counts of lines of code as a metric.
 Productivity in terms of LOC is how most past data is available.
 If effort in a system is known, productivity in terms of effort per LOC is easy to compute
since LOC can be easily counted.
 Estimated LOC is easy to monitor progress against.
LOC as a measure of the system size no longer holds the monopoly in size measures, because of its
several drawbacks.
A system's LOC cannot be correctly known till the system is developed and LOC estimates cannot be
accurate till design is complete for any system of respectable size. Estimation of size is often needed at
very initial stages and expressing the size of a project in LOC at an early stage is almost impossible for
large sized systems.
There is often confusion on what is a line of source code. For example:
 Should only procedural lines be counted, or should declarative statements also be counted? If
declarative statements are counted, should they be counted just once, or for each module where
they are included?
 Should logical lines be counted or physical lines? What about macros--should they be counted
as one, or should the expansions be counted for every occurrence of the macro?
 Should the LOC for housekeeping functions and utilities be counted?
 Should programs written for testing be counted?
 In 4GL environments, developers often do not directly write code. What is a line of code in
such situation?
 Many projects use more than one language to develop its software. Should the LOC in the
different languages be added?
Typically, the term LOC is used in a generic sense for any size measurement involving counting the
lines of source code, with the basis for counting them defined (hopefully) clearly enough to be
uniformly implemented. While differences in interpreting the term may be resolved, the other
problems with LOC persist.
LOC are more difficult to visualize in modem environments with screen painters, form generators, and
other such tools becoming available. How can sizing in LOC be done if such tools are being used?
Some organizations that have historical databases of estimates use the past data to derive equivalence
to relate LOC to screens, etc., to be able to use LOC. But this is retrofitting to an obsolete way of
working.
8
The LOC approach is basically more a "programmer" approach, and not one that the user can either
understand or check or comment on.
LOC of different languages are not comparable, and so unlike functional size measures, there can be
no composite LOC count for a system which has been developed in multiple languages. Also, LOC of
systems developed in different languages cannot be compared.
We can see that LOC size measure was more usable when systems were small, in a single language,
and the estimator could reasonably accurately guess the LOC given the scope of the system. We also
need to remember that there were very few programming languages-each domain had its own two or
three "pet" languages; and the versions of these languages did not change as rapidly as they do today.
For systems being written in 3rd generation languages, LOC still remains a popular means of sizing in
the later part of the life cycle, as LOC is suitable for monitoring. For the earlier phases of the life
cycle, function points are more in use.
For organizations wishing to using LOC as a means of sizing software for new projects and for
existing software assets, the issues mentioned above need to be addressed satisfactorily, to ensure that
all measures use the same consistent basis. This is because misunderstandings and inconsistencies are
some of the major problems in this approach. For this, the LOC basis is clearly defined for the
organization before it is used.
7.5 System Breakup Structure (SBS)
The basic philosophy of System Breakup is that the whole system can be broken down into smaller
units that are easier to estimate in terms of LOC.
For any large system, breaking up the system into its components provides the estimator a better
clarity of the internals of the systems. Each component can then be estimated in terms of LOC. The
total size in LOC can be obtained by summing the estimates of the parts.
The hierarchical arrangement of the system components can be called System Breakup Structure
(SBS). We use SBS to distinguish this decomposition from Work Breakup Structure (WBS) which is
concerned with work units. The SBS partitions the system into manageable units, and enables better
estimation, planning and tracking. A sample SBS of a large system is shown in Figure in the next
page. This shows the various software components (such as system, sub-systems, modules, programs
and common routines) and shows how all these software components together form the overall
software system, with the LOC estimates for each lowest level component.
Once the SBS is complete, the size in LOC of all the lowest level components is estimated, and
summed up for arriving at the higher level components. Preparation of the SBS is not just an
estimation activity. Many analysis and design methodologies require that such a chart (sometimes
called the system structure chart) be created as part of the requirements analysis or system design.
9
7.5.1 Brainstorming and Wideband Delphi Estimation Technique
How do we ensure that we create a good SBS and estimate accurately for each component?
Brainstorming and Wideband Delphi Estimation are two good methods that can be used to arrive at a
reasonable estimate. These take into account the expertise available in the organization and use a
"process" to provide increased accuracy of the LOC estimate.
Brainstorming
At times, very little is known or understood about what the system may involve. In such cases, it often
helps to have a number of people openly discuss something to come out with new ideas and fresh
perspectives. Brainstorming is a technique where a group of people who have knowledge and interest
in the area get together to have a creative discussion in a free-flowing way. Brainstorming differs from
normal meetings and group discussions with its focus on creative, unhampered thinking, without
criticism or constraints. The purpose is to come up with new ideas, not to shoot down ideas. Effective
brainstorming sessions can give new directions and new ideas worth exploring further and can be used
to create the SBS.
For effective brainstorming sessions, the guiding principles are:
 Criticism should not be allowed.
 Ideas should be aired even if they seem rather far-fetched.
 Participants should encourage each other and help in further developing the ideas.
 All ideas mentioned should be recorded.
 No personal comments should be allowed.
 All participants should be encouraged to voice their ideas.
 Emphasis should be on quantity of ideas.
 The atmosphere should be positive and energetic.
The brainstorming session is followed by more detailed work by managers who try to then use the
ideas to come up with the SBS.
Brainstorming is relevant where the SBS is to be created based on very few inputs and/or for very new
technology or applications. It can throw up ideas that make the design clearer. It will need to be
10
followed up with other techniques like wideband Delphi technique to consolidate the estimation basis
and to make the estimate.
Wideband Delphi Estimation Technique
There are times when experts make reasonably good estimates based on their own experience and
intuition. There are also times when not enough is known to use algorithmic models, and expert
opinion is the best (may be only) estimate one can get. While some call expert opinion just a nice
name for guessing, there is much to be said for it since experts have knowledge they may not always
be able to explain but which gives them a useful intuition.
Since expert opinion of a single expert may be biased, it makes sense to have multiple experts give
estimates and combine these somehow.
In a discussion on expert judgement, Boehm, in his book Software Engineering Economics, points out
those combining estimates by using an average could result in one extreme estimate affecting the
value, while having a group meeting of experts could result in one or two estimators over-influencing
the estimates. Boehm suggests a modification of a technique---the Delphi technique--originally
proposed at the Rand Corporation. This modified technique is called the Wideband Delphi technique.
The Delphi technique gets its name from the ancient Greek oracle at Delphi.
The Wideband Delphi technique is a structured way of estimating based on collective expertise. It is
often used for first cut estimates, in situations where the expertise in estimating is particularly
valuable. It is also used to complement other estimation techniques. In the context of software sizing,
the Wideband Delphi technique can be used to arrive at the LOC estimates for the proposed system.
Wideband Delphi technique is based on the recognition of the fact that when many experts
independently come to the same estimate based on the same assumptions, the estimate is likely to be
correct. Of course, the experts involved in the estimation should be working on the same and correct
assumptions.
The Wideband Delphi technique is schematically represented in Figure below.
Wideband Delphi technique starts with identification of the team of estimators. The author of the
system presents the system to these estimators, and the author and the team jointly identify the
11
components and assumptions (the components could have been derived using the brainstorming
technique), and jointly agree on an acceptable level of difference in the estimates. The final list of
components (SBS) is then prepared by an estimation coordinator and distributed to the team. The
estimation coordinator does not provide estimates, and need not be an expert.
Once the components and assumptions are jointly clearly agreed upon, each estimator starts
estimating. The estimation is done independently. The independence of this part of the process is the
key to this technique-- there should be no discussion between the estimators on the LOC to be put
against each component. The estimates arrived at by each estimator are handed over to the estimation
coordinator who summarizes them and hands back the summary to the experts and the author.
Components where the estimates vary more than the acceptable level of difference (as jointly decided
earlier) are identified and the team discusses these components and their assumptions.
The team for this method should have at least 3 expert estimators. A team of 4-6 experts is preferred.
It has been seen that the estimates get more accurate as components are broken down into smaller
components.
.
Wideband Delphi Technique is known to work fairly well and the key factors for its success are:
 The individual estimates are never discussed.
 Focus is the components and assumptions.
 Estimates are kept confidential; estimators do not know each other's estimates.
 Components are broken down whenever there is a high variance.
The estimation coordinator can prepare an estimation summary after every iteration using the table in
Figure below.
7.6 Summary of size estimate
Size estimation is a precursor to effort, schedule and cost estimation and the accuracy of these
estimates depend on the accuracy of the size estimates. The sizing method selected depends on the
12
type of application. Function Points and Mark II Function Points methods are most suitable in MIS
type of applications.
The choice of the sizing method also depends on how well the requirements of the system are known /
understood. Approximate sizing methods such as Quick FPA Count and Rapid Application Portfolio
Sizing can be used when the requirements are not clear. IFPUG Function Points can be used when the
Software Requirements Specification is ready. Further into the life cycle, the Mark II
Function Points method can be used to take into account the details available during design and
provide a more accurate size estimate. Where these methods are difficult to apply, the System Breakup
Structure and Wideband Delphi Estimation Technique can be used for sizing.
Later in the life cycle, technical measures for sizing such as LOC or number statements are more
suitable since they provide detailed estimates.
7.7 Overview of Software Estimation
As requirements become clearer, the software organization as well as the user organization wants to
have a reasonably accurate 'estimate' of the cost of development and the time frame within which the
development will be completed.
Estimation is particularly important because it decides the 'execution' boundaries of the project in
terms of the resources that will be made available for the project execution and the duration of such
availability. It also determines whether or not the project is considered feasible in terms of cost and the
ability to meet the required end date. In case of software development projects to be executed by
external vendors, estimates form the basis of the contract between the vendor software organization
and the customer's organization. This contract lays down what the vendor will deliver when he will
deliver and the money that he will be paid by the customer. Many contracts also specify stiff penalties
for delays or poor quality!
Software organizations need to be able to 'quote' to the user organization in terms of project delivery
time and total costs. The estimates typically become targets when the project proceeds to the stages of
detailed planning and execution. Improper estimates can lead to a variety of problems for both the
software organization and the user organization, e.g.
 In case of an over estimate, the bidding software organization may lose the project, because a
competing software organization has estimated more accurately and quoted lower.
 In case of an under estimate, the software organization will make a loss and also delay the
delivery of the software. The delay can cause disruption to the user organization and also invite
penalties on the software organization.
The problem with estimation is that the project manager is trying to quantify the cost, effort and
delivery period before completing the design. Estimates made for the purpose of preparing a quotation
are usually made on very sketchy requirements definition. As more information becomes available,
estimates can become more accurate, but the need and the criticality of doing the estimate reduce.
Unfortunately, most projects start with wrong (usually lower) estimates and are therefore are planned
with lesser resources and unrealistically tight delivery schedules. Estimation often suffers due to
incomplete knowledge, lack of time and various competitive pressures that are directly and indirectly
put on the estimator to arrive at more 'acceptable' estimates.
A common confusion in estimation and in people examining estimates is the confusion between
calendar time and manpower requirement. Calendar time is the time between the start date and the end
date of a particular project. As against this, the manpower required is expressed as person-months of
effort that go into the project. The effort of a project is in person-months (or some such measure)
which are arranged over time to complete the project within the required calendar time (schedule).
Since managers are concerned with both effort (which impacts cost) and schedule (which determines
the delivery time) both are to be estimated.
13
Before we go any further, we need to define the term 'estimate'. A dictionary meaning of estimate is "a
tentative judgment of the approximate value, worth, cost, size or other attributes of significance".
For a software project, we are interested primarily in estimating the cost and duration of the project.
To arrive at these, we need to have a fix on the 'size' of the software that is to be developed. Since a
major part of the cost of any software project is the effort expended by skilled software developers,
accurate estimation of effort is the key to accurate estimation of cost and schedule. Figure in the next
page depicts a simple estimation model relating size, effort, schedule and cost.
Size estimate
The size of the software to be developed is one of the parameters to be estimated. This forms the basis
for estimating the amount of work to be done, so that effort and schedule can be estimated. If the size
is estimated in terms of the functionality that the user shall obtain from the system, it is also a
measurement that tells the user what the system shall do and what has to be paid for.
Size estimation can also be relevant for valuing existing software assets or estimating maintenance
costs for existing software. Some size measures of software are lines of code, number of function
points, number of objects, number of reports, number of screens, etc.
Effort estimate
The estimate for the manpower that is required for the software product. This is the major cost
constituent in any software project. Along with the schedule estimate, it determines the team size and
build-up. Effort is normally measured in terms of person-hours or person-days or person-months or
person- years, with conversion factors to convert from one measurement unit to another.
Effort estimate is driven by size and many project related factors such as skill and capability of the
team, the language and platform to be used, the availability and suitability of the platform, the stability
of the team, the level of automation that will be employed in the project, etc.
14
Schedule estimate
Schedule is the duration between the start of the project and the end of the project. Schedule estimate
may include high-level intermediate milestones, like end of various phases. The estimate is at a project
(or phase) level, and is not a substitute for the detailed task-wise scheduling which forms the basis for
project planning and control.
Schedule estimate may or may not meet the customer or end-user's need. In case the customer needs
the software earlier than what is estimated in the first iteration of the estimate, the effort estimate may
need to be revised to meet the customer imposed schedule.
Cost estimate
The estimate of costs for a software project. A major component of costs is the manpower cost (based
on the estimated effort) in any software project. Apart from that, other costs, such as travel,
communication facilities, project specific training, hardware and software for the project team need to
be estimated. These along with the manpower costs can be used to estimate the total cost of the
project.
Accuracy of an estimate is another major issue. In the dictionary definition of the term 'estimate',
phrases such as 'judgement' and 'approximate' are used. These phrases imply that the expected
accuracy of an estimate is not very high. How- ever, in software projects, estimates are used to make
commitments between stakeholders (like customers, vendors, shareholders and general public) and to
set aside resources (money and other resources) for the completion of the project. If the estimates are
far from reality by a. significant amount, then the stakeholders are likely to be dissatisfied with the
estimate itself.
Considering the above, a simplistic definition of software project estimate could be "prediction,
within a given tolerance, of the size of the software to be developed and the effort, cost and calendar
time required to develop the software." The concept of tolerance recognizes the fact the estimation is
an exercise in approximation, but tries to lay emphasis on the quantification of the inaccuracy of the
estimate.
Estimates can be made using varying degrees of formality. At the most informal level an estimate is a
'guess'. A guess is typically a quick opinion not based on careful thought, calculation or backed by
knowledge or data. But, we are trying to develop software through the engineering disciple, and hence
guessing is not a viable option. The second level of formality is an 'expert's guess'. Here, expertise or
knowledge that exists with individuals ensures an increase in the accuracy of the guess. The formality
is brought in by identifying the right person (one who has the knowledge and experience) to make an
educated guess. This method is also person dependent and does not satisfy the requirements of a good
estimation 'process'.
To convert the art of estimating into a scientific process that satisfies the rigors of an engineering
discipline, software estimation needs to be based on well-defined estimation methods. These
estimation method or combination of methods together should have certain characteristics. The
estimation method(s):
 Should be able to convert 'requirements' into one or more size estimates.
 Should specify how effort, schedule and cost can be derived from the size estimates and other
project characteristics.
 Must take into account variations in important project execution characteristics such as the life
cycle model selected, skill level, platform stability, user characteristics, requirements stability,
and use of automation in software development and process maturity of the development
team's processes.
 Must be person independent.
 Must qualify the estimates with a certain degree of accuracy or tolerance.
 Must support re-estimation at various phases of the project, to provide a more accurate
estimate.
In the 1950s and 1960s estimates were prepared by expert programmers/ designers, who could provide
a fairly accurate estimate, based on their "gut feel", that is, the experience that they had accumulated
15
on the job. In those years, there were very few programming languages and technologies and
applications were relatively simple. Every application domain had one or two 'pet' languages with one
or two technologies and an expert programmer would usually estimate for an application, language
and technology with which he or she was familiar.
With software development and maintenance work increasing exponentially in the 1970s and the
number of application areas, languages and technologies proliferating, there was a shortage of expert
estimators. In the mid-1970s, project estimates were based on developer productivity, which was
measured as lines of code per person month, achieved by the organization's developers on past
projects. The size of the software to be developed or enhanced was first estimated in number of lines
of code, and divided by the productivity, to arrive at the estimated effort in person months. Then,
depending on the number of developers available for the project, the time taken to complete the
project was calculated.
This method did not work satisfactorily, for a variety of reasons, some of which were:
 Early on in the life cycle, it was not really possible to come up with a realistic lines-of-code
estimate.
 Developer productivity is not really a constant-it varies, depending on several factors like the
type of project, the size of the software, the number of team members, the project organization
and communication, the hardware and software environment, and the software process used in
development.
 Many development environments no longer wrote code which could be measured in lines of
code.
 In many cases, experts could not estimate the expected lines of code since this was the first
time they were planning to use that language or technology.
Due to the above problems, the late 1970s and 1980s witnessed two major developments related to
software estimation:
 Shift from the "line-of-code" sizing approach to size based on functionality. Allen Albrecht,
Tom DeMarco, Capers Jones and Charles Symons were pioneers in defining and refining the
size estimation methods.
 Development of non-linear models for effort, schedule and cost estimation. In addition to the
size of the software to be developed, these models considered multiple factors that affected
productivity in any software project. These models were validated, refined and calibrated with
data from completed projects. Barry Boehm and Larry Putnam were the early researchers who
developed these models.
Further developments on the models are a refinement of the basic concepts that were established
earlier. Newer estimation models are fine tuned to Ute newer life cycle models and development
methodologies (like object oriented methodologies) and attempt to take into account current factors
that impact productivity (for example, development team attrition and process maturity are important
factors that emerged in the 1990s).
What is Productivity?
After the requirements are obtained, we estimate the system size. Once the software size is known, the
next step in the estimation process is to determine the effort it will take to make the software, and the
calendar time that is required to complete the project. To compute the effort estimate, we need to
know the productivity.
Productivity, according to the dictionary is "rate at which something is produced per unit of input",
described by the equation:
Productivity = Output/Input
In software development projects, we are producing software (including the supporting
documentation), so the output of a software project can be measured in terms of the "size of the
16
system". The main input for a software project is the "effort of the project team". Hence, productivity
of a software project can be expressed as:
Productivity = Size/Effort
We can compute the productivity of the projects that we have completed, provided we know their size
and the effort that was spent to complete the project. This effort should include all software
engineering and management activities expended on the project. Activities include the life cycle
activities (analysis, design, coding, etc.), creation of user documentation, project management,
configuration management, reviews and inspections, client interactions and presentations, etc.
Most organizations over the years build up productivity rates for LOC (or FPC) per person month (or
person day) for the various development environments they work on, and then use these productivity
figures for effort estimation. Many re- searchers also publish productivity figures for use by the
software industry.
Size and Effort
Data from many projects has shown that productivity usually reduces with size. This means that as
size of the software increases, the estimated effort should increase exponentially as shown in Figure
below.
If we agree with the above relationship, the productivity in a project is not independent of the size--productivity drops with increase in size. We may still use the linear relationship between size and
effort (or constant productivity), but only
When the projects are in a narrow range of size, this linear relationship becomes invalid when the sizes
vary drastically. When the size of the software increases, the number of components of the software
also increases. This in turn increases the number of interfaces between the components exponentially.
In a small system let us assume that there are two modules, hence we need to be careful of only one
interface. When the size of the system is doubled, the number of modules goes up from two to four, but
the potential number of interfaces has gone up from one to six! This multiplier effect is depicted
pictorially in Figure below.
17
Schedule and Effort
Schedule is another important estimation parameter. At a simplistic level, schedule is estimated by
assuming a team size and dividing the estimated effort by the assumed team size, as shown by the
equation,
It
is further assumed that if the team size is doubled, the duration of the project can be halved. .
In other words, estimators often work under the assumption that the productivity will remain constant
as the duration is compressed. That is, they treat men (and women) and months as interchangeable,
just like two variables in a linear equation. The implicit project conditions in the productivity figure
are forgotten because of the mathematical appearance of the effort and schedule calculation equations.
Fred Brooks in his famous book, The Mythical Man-Month addresses this and related issues, and puts
it very aptly as
Men and months are not interchangeable
To understand why this is so, let us examine what a software project involves. A project involves a
project team working together towards a common objective --- that of producing software that meets
the requirements in the specified time and budget and ensuring that the software is of good quality.
The activities that are required towards this aim are not isolated and independent. Coordination and
communication are required.
As the team size goes up, the communication needs between team members also goes up. The number
of communication channels increase exponentially as the number of team members increases. Any
communication is subject to "noise". Since the noise in a larger team is (exponentially) higher than
that in a smaller team, the productivity of the larger team is lower than that of a smaller team.
The activities that need to be performed are not simple and interchangeable. The activities require
certain skills, and cannot be shifted from one person to another without impacting productivity.
Obviously if a programmer requires five days to complete a program, no one can really expect that by
adding one more person the program will get done in half the time. While this is quite obvious at a
18
single program level, such arithmetic manipulation is often done at the project level when
management expects that adding persons to a project will reduce the scheduled delivery time
proportionately. Another factor to keep in mind is that certain activities are sequential, and we cannot
perform test execution before coding is completed. This also implies that every project will have a
certain "bare minimum" schedule beyond which it cannot be squeezed, irrespective of the number of
resources thrown at the project. Barry Boehm, who has constructed an estimation model called
COCOMO (Constructive Cost Model) calls a crashing by 25% (from the ideal! normal schedule) as
"severe acceleration" and considers any further crashing as almost impossible.
Impact of this phenomenon can be stated in many ways:
 Productivity reduces as team size increases.
 For the same system, effort taken to deliver the system in a shorter time will be more than the
effort taken to deliver the system without delivery time pressure.
 Productivity reduces as the duration available to develop a system reduces.
The productivity rate that can be expected or achieved in a project is a function of the schedule and
resource constraints the project operates under. The productivity achieved for a particular application
type and development platform would be different if the project was "crashed" to be delivered in a
shorter time. When a project is being executed, the actual manpower loading is not flat; it follows a
curve characteristic for projects. Crashing a project changes the curve. Using a constant productivity
rate is a simplification, and assumes that the rate be applied only to projects that follow the same
curve.
All these factors show that while a constant productivity rate is an easy to apply simplification for a
quick calculation of the effort and schedule, forgetting its underlying assumptions and using it for
"what-ifs" as if it were a constant is misleading. Unfortunately, it is common for managers to use a
constant productivity rate to apply (impractical) pressure to crash the schedule of a project by adding
manpower, and therefore, it is essential that estimators take into account the impact of schedule
compression on productivity.
Quality Versus Effort and Schedule
The size that is computed for a system represents "what" is to be provided. However, quality of a
system is "how well" the system works in providing the "what". Quality of a system is inversely
proportional to the "defects" delivered to the customer.
If high quality software (with low number of defects) is required, and then the process followed to
build the software needs to be more rigorous. Defect detection and removal is done using processes
like reviews and testing. Reducing the effort spent in reviews and testing lowers defect
detection/removal. Less testing done for a system means there is a chance that more defects remain
undetected and hence not removed. A high quality system requires more effort in reviews and testing.
It also reduces the scope of "parallel" activities. If all other factors are unchanged, creating a high
quality system requires more effort and a longer schedule. On the other hand, if the effort estimate is
slashed and/or the calendar time available is squeezed, the result usually is a poor quality, defective
system!
We can summarize the relationship between the quality of software, effort and schedule estimate in
many ways:
1. A higher effort and a longer schedule is required to produce high quality software.
2. A reduction of effort and schedule will result in poorer quality of software.
3. Productivity of the development phases reduces if we are required to create high quality software.
It is important to point out that though producing high quality software requires more effort; this
additional effort is more than recovered by lower maintenance effort and disruption.
19
Our estimation model or technique should therefore take into account "expected software quality" as a
factor when we estimate for effort and schedule.
Other Factors Impacting Productivity
In addition to the size of the software and the schedule and the expected quality, there are many other
project-related factors that significantly influence the productivity.
1. Availability and stability of the development environment.
2. Team capability, skill and experience
3. Team stability/manpower turnover.
4. Maturity of the processes.
5. Reusable software available to the project.
6. Reusable software to be built by the project.
7. Extent of communication possible with the users/customers.
8. Extent of automated tools used for software development and maintenance.
9. Extent and degree of detail of the required user documentation.
10. Cohesion of stakeholders and teams.
The estimation process, model and technique that we decide to use should therefore take into account
all the above parameters appropriately.
Approaches to effort and schedule estimation
There are many estimation models, methods and techniques and these may be broadly classified as
 Algorithmic approach ,
 Analogy based approach
 Bottom-up approach
An overview of these approaches is given below:
In the algorithmic approach estimation is done in a top-down manner. The algorithmic models
mathematically express the relationship between the various variables involved in estimation, such as
size, effort, schedule, complexity, etc.
Algorithmic models could be static or dynamic. A static model starts with a unique variable as the
starting element, using this to derive the values of the other variables. This starting variable acts as a
basic variable. In a dynamic model the variables are interdependent and there is no basic variable as an
independent variable.
An algorithmic model that uses a single basic variable in its calculation is called a single-variable
model. This variable is a predictor which when input to the model is used for predicting the values of
all the other variables. Models can also be multi-variable-here more than one variable is required to
model the behavior. For multi-variable models, more than a single predictor variable is used for the
calculations. Algorithmic models described are Mark II Estimation, COCOMO II, COCOMO suite,
COCOMO 81, Putnam Estimation model and the use of complexity for estimation.
Often, projects that need to be estimated are similar to past projects in some ways, but differ in others.
This leads us to the question-can we use our past experience to extrapolate and arrive at an estimate
for this project? Analogy based estimation may be used in such cases, especially when the past data is
not adequate to finalize all the parameters required by the algorithmic models. Estimation by analogy
is basically a top-down view of a system that uses the "gut-feel" of experienced individuals to identify
similarities and differences (between the project to be estimated and some identified past projects) and
their assessment of the impact of the differences on the estimates.
Bottom-up estimation takes us into the realm of project planning. In bottom-up estimation, the project
is broken up into smaller activities and tasks. An (effort) estimate is made for each lower level task.
The effort estimates of all low level tasks are added to give the phase and project estimates. In many
20
instances, the Wideband Delphi technique is used to arrive at a consensus on the task break- down and
the estimates for each task. The schedule is estimated by laying down the tasks in a PERT/CPM chart
with the dependencies.
Estimates obtained using the various estimation methods are an input to de- tailed scheduling the
project. Estimates have an associated uncertainty, often seen as a probability distribution. The project
schedule combines a set of interdependent tasks in a sequence depending on their interrelationships,
effort and resource requirements.
21
Even though well-defined estimation methods exist, the estimation process is still one of the most
error prone processes in the software management discipline. Some of the causes associated with
problems in estimation are listed below:
 Estimation without integrity Often what the customer is willing to pay or what the competitor
is quo~ng, drives the estimate. Though competition and customer's budgets are important
factors for a quotation, they cannot drive the estimate. The authors have witnessed extremely
ridiculous estimations exemplified by the following:
Customer's budget = US $52,000
Therefore Effort = 52000/4000 = 13 person months (we charge US $4000/ person month)
Hence Size must be = 13 * 15 = 195 Function Points (our productivity is 15 FP/person month)
In the above situation, the requirements are totally ignored and the whole estimation exercise is
reduced to a farce through backward calculation. Any project planning or execution based on this is in
no way related to what the actual development of the system based on the requirements may need.
This will backfire on the development team and may indirectly impact the cus- tomers.
>- No time to estimate Often quotation preparation and estimation is per- formed in the "want it
yesterday" mode. This forces the estimators to bypass the process and make hasty assumptions leading
to grossly inaccurate
A
estimates. There are instances where projects worth hundreds of person- months are estimated in one
or two days. In hindsight, it appears foolish not to have provided adequate time and resources for
preparing and reviewing the estimates.
>- Incomplete or incorrect requirements As discussed earlier, the first step in the estimation process is
to convert the requirements into a size estimate. If many of the requirements are incorrect or missing,
the estimate will be inaccurate irrespective of the sophistication of the estimation methods. Which is
why we need to confirm that the requirements are correct and complete before starting to compute the
estimates.
>- No past data available Estimates should not only be based on the re- quirements, but also on past
data on productivity and factors that influence productivity. Many organizations do not have past
22
productivity data. Some that do have the past productivity data notice considerable variance in productivity between projects, but do not analyze and document the reasons for this variance. This
becomes a handicap when estimating for a new project.
>- Invalid estimation assumption I-Productivity is independent of size of software It is obvious that as
the size of the software increases, the effort to build the software increases. What is not obvious, is
that as the size increases, the effort increases exponentially. The typical relationship between size and
effort is non-linear, as shown in Figure 1.14. When the size of the software increases, the number of
components of the software increases. This in turn increases the number of interfaces between the
components exponentially.
In a small system let us assume that there are two modules, hence we need to be careful of only one
interface. When the size of the. system is doubled, the number of modules goes up from two to four,
but the potential number of interfaces has gone up from one to six! This multiplier effect is depicted
pictorially in
Figure 1.15.
> Invalid estimation assumption 2-Productivity is independent of im- posed schedule Let us assume
that we have executed a project with 4 developers in six months; i.e., we expended an effort of 24
person months. We now have another project of a similar size but we need to deliver the project within
three months. Based on the past project we estimate that the. project will take 24 person months.
Hence to deliver the project in three months, we need 8 developers in the team.
The above calculation is a well-known fallacy in estimation as it assumes (in Fred Brooks words) that
men and months are interchangeable! Since there are more team members in the project, the
interactions and misunderstandings due to interactions will grow exponentially and the effort- to
deliver the project will no longer be 24 person-months.
> Other important project factors not considered In addition to the size of the software and the
imposed schedule, there are many other project- related factors that significantly influence the effort
estimate. These factors
are ignored by using so called "industry standard" productivity figures or average of productivity
achieved in the past projects, resulting in overesti- mates or underestimates. The other key project
factors that influence effort estimates (but often ignored) are:
1. Availability and stability of the development environment Short- age of hardware and software for
the developers can lead of drop in productivity. In such situations, developers work in shifts or wait
for resources, and hence it becomes difficult to coordinate resolutions of design issues, conduct team
meetings, etc. Monitoring of the developers by the Project Manager over multiple shifts becomes
impossible. This leads to considerable amount of rework and idle time.
Another factor is the stability of the development environment. If the operating system and the
compiler on which the development work is being carried out are themselves unstable, trial versions,
the development team wastes a lot of time idling and chasing bugs in the development environment
instead of developing the software!
2. Team capability and experience Productivity of individuals in soft- ware teams varies drnstically
with their capability and experience. This includes capability and experience in analysis, design,
programming in a particular language or environment, testing, project management, con- figuration
management and application domain.
3. Team stability A team with a high turn over of members due to res- ignations, transfers to other
projects, etc. will have considerably lower productivity due to hand-over activities, learning time for
the new per- sons and rework. ,
23
4. Maturity of the processes An important factor is how mature the software processes of the
organization are. When organizations reach higher maturity levels (using ISO 9001, SEI CMM or
other process/ quality models) they typically become more productive.
5. Accounting for reusable software available Reuse ensures that less software needs to be developed.
However, reuse is not' free, because software that is brought-in needs to be integrated during design
and test- ing and may need changes during integration
6. Estimating for reusable software to be built If the project team has to build software not only for
itself, but also for the needs of similar future projects, the effort will be higher.
7. Extent of communication possible with the users/customers Close coordination with the users/
customers can increase the productivity of the software teams. Geographical distances and time
differences between the customer and the developers may pose a barrier to easy communica- tions.
This disadvantage can be overcome with use of fast communica- tions like ISD/ STD, leased lines, email, video conferencing, etc.
8. Extent of automated tools used for software development and maintenance Use of automated tools
for estimation, project planning, scheduling, tracking, test planning, test execution, managing reviews,
defect tracking, version control, risk management can considerably in- crease the developers
productivity.
9. Cohesion of stakeholders and teams (including the development team, senior management of the
software organization, the users and the sponsors of the software project) can achieve much higher
productivity when compared to projects where each group and individual pulls the project in different
directions.
>- Lack of training and skills in estimating Very often estimators are expert programmers and
designers. Though they are skilled in design, pro- gramming and debugging, this does not necessarily
make them good estima- tors. Unless trained on estimation concepts and techniques, good programmers and designers typically tend to underestimate considerably as they approach the estimation in
terms of "how much time will I need to complete this activity?" Being good programmers and
designers their estimates are usually lower than what it takes a typical developer working in a team to
complete the activities.
>- Poor tracking of estimates during the project execution Tracking makes us conscious of the
estimate and prompts us to think in terms of why the estimates are inaccurate. Tracking also provides a
trigger'to perform re- estimation, which helps in taking corrective actions on the project execution,
before it is too late.
>- Concept of "tolerance" not used We often forget that an "estimate" is an approximation of the
expected reality. Reality will never exactly match the
estimate except by chance or deliberate manipulation. A mature estimation process will always
accompany an estimate with a "tolerance". The tolerance shows that we recognize the estimate to be
an approximation, and that the reality will be within a range of the estimate. Hence, instead of stating
that the estimated effort is 100 person-months, we would be more realistic in stating that the effort is
estimated to be between 95 and 110 person-months. If the reality is always within the specified range,
we can consider our esti- mation process to be stable (we however, need to work on the project execution activities to help us reduce the tolerance or variance).
24
25