Making Estimates of Software Development Effort

If you don't know where you are going, any road will take you there.
Lewis Carroll

Planning to develop some software without making a serious effort to estimate how much
work will be required is careless. It is especially careless now since so much experience
has been built up about actually making software. There are many measures available to
make accurate estimates. Here we will briefly look at several which are based on the
work usually referred to as COCOMO II. This method is based on matching the
requirements to the amount of project effort required to produce the functionality in
question using a computer. For the effort to be worth it, we also need to have enough
abstraction so that we can reduce any computer functionality to a common language
description.

Common languages have abstractions for things that generalized languages have many
particular expressions for. Joining all those particular expressions into a single aggregated
language makes the discussion much more focused. The most successful common
language for computer functions is one that has only five words in it. The words are Input
(meaning a screen), Output (meaning either or both a screen or a file), Query, Files
(opened and read to distinguish them from Output) and Interface (talking to other
software or equipment). That is all we have figured out to do with computers at an
abstract level so all we have to do is to recognize the requirements that ask for those
functions. There is an elaborate methodology called Function Point analysis that studies
all sorts of instances of these five words, but for estimating effort, just being able to
recognize the basic idea in a requirement is enough.

As you read a requirement just make a tally mark when you see something that says
collect information as an input. When it says show the information to a user that is an
output. When there is an implication that some information will be stored and picked
back up again at some later time that is a query. Any place where the requirements talk
about defaults or standards or configuration that is a file. When there is an implication
that some part of the requirement talks to some other part or some existing application
that is an interface. If the requirements are specific then think of all of the words as
describing simple things. If the requirements are vague then think of all of the words as
describing complicated things.

Function Points are reduced to numbers (since we are headed at making some
calculations) using the following values and calculations:

The words are assigned values as either simple (the small number) or complex (twice the
simple). This means that if you had one simple input screen that only asked for 4 or 5
values and one complicated that asked for 20, the input function points would be 9. If you
had one simple and two complicated, the input function points would be 15.

Input screens: 3 or 6
Output to file: 4 or 8
Query to DB: 3 or 6
Files read: 7 or 14
Interfaces: 5 or 10

When you have the total number of function points for all the requirements, you calculate
how much project work it would take to produce those functions. To get this project work
into a simple enough form so that we can compare one project to another, we will
calculate the length of time it takes for a project to do all the work to support the design,
development, test and deployment associated with the functions in the requirements. The
abstraction on down to a true common value this estimate is reduced to the number of
lines of code. Again, this is making a concrete measure to map an actual piece of
software back to the requirements associated with the application. It is just a number.

The relationship between lines of code and a function point depends upon the
programming language that is used to develop the software. The quality of the design
could also have some effect but this method assumes that the design is normal, so it will
be reasonably constant. The following table presents actual count investigations for
common programming languages. These values come from 1,467 completed projects
where both Function Points and lines of code were collected. Doing the counts was a
2005 project and some of the projects where the counts were made were as old a 2003.

Programming language LOC/FP (multiplier)

assembly language 320
C 128
Cobol 105
Fortran 105
Procedural, line numbered 90
Ada 70
Php and python 67
Java, C++, C# 31
object-oriented languages 30
fourth generation languages (4GLs) 20
code generators 15
Spreadsheets and query languages 6
TIBCO (draw-a-program languages) 4

The LOC is calculated by FunctionPoints * language multiplier.

COCOMO II is an empirically validated software cost estimating formula. It uses these

three simple calculations to derive the effort, duration and staffing for the project that has
to produce some number of lines of code.
Effort = 3.6 ( KLOC ) 1.20

Simple non? So you take the LOC calculated from the function points and drop the last 3
0's, multiply by 3.6 and then multiply the product by 1.2. That number is the total "on
task" work required to produce the lines of code in terms of hours. Since not even
programmers work all time, we have to calculate how long the projects will last, which is
called Duration.

Duration = 2.5 (Effort) .32

Duration is the scheduled time, assuming 8 hour days with regular work weeks. Finally
we have to know how many guys it will take. This is the product of Effort divided by
Duration.

People = Effort/Duration

Two things to remember about manually calculated COCOMO II. One is that it doesn't
make any allowance for how good the people actually are. The second is that it assumes a
full software development life cycle. The actual coding time is 50% of the total duration
which includes time for detailed design, code, unit test and integration testing. 10% of
the total time is requirements gathering, 15% is high level design, 15% is integration and
quality assurance, and the last 10% is transition to production. You can see where the
work breakdown structure comes from as well as the allocation of skill sets.

Another useful measure to remember is that there will be five bugs per function point and
only 80% of these bugs will be fixed before the transition to production (last 10% of the
Duration). It is useful to keep track of the number of bugs found and fixed relative to the
project size since achieving at least 80% of projected fixes is the best measure for quality
of the product before releasing it to production. You will still have 20% of the defects in
the code when you get to production. Also, you need to back into the number of "new"
function points produced by the fix LOC, because any new FP "introduced" by fixing
will have still have the same five bugs in it.

WAYS TO IMPROVE THE ESTIMATE

Function Points are a pretty course method to describe computer functionality. One
method to improve them extends the idea of complexity by including the basic functional
unit into a project context. This allows for differences between projects like a simple
proof of concept and a fully configurable multifunction product.

FP = total x [0.65 + 0.01 x sum(complexity)],

1. Number of user input screens * weight

2. Number of user outputs * weight
3. Number of queries * weight
 4. Number of files * weight
5. Number of interfaces * weight

The weight depends on the estimated complexity of each part.

After the preliminary analysis is made, the entire application is scored for complexity.
The formula for this is

sum(complexity) = sum of "complexity adjustment values"

These complexity adjustment factors are based on responses to 14 questions. Each

positive answer adds 3, 4 or 5 points. This exercise is easier for all modern
applications, since we always answer yes to the first six questions, giving us 18
complexity adjustment points to start.

1. Does the system require reliable backup and recovery?

2. Are data communications required?
3. Are there distributed processing functions?
4. Do you care how fast this runs?
5. Will the system run in an existing environment?
6. Does the system require on-line data entry? Complexity of 18 to here.
7. Does the on-line data entry require multiple screens? +4
8. Are the master files updated on-line? +4
9. Are there any complex function points in this group? +4
10. Is there complex internal processing? +4
11. Is the code supposed to be reusable? +4
12. Is conversion of data included in the design? +4
13. Is the application supposed to be easy to use? +4
14. Is this for multiple different organizations? +5

COTS ADJUSTMENTS TO COCOMO II

Some projects anticipate the use of common off the shelf software products. When that is
planned the estimate of effort for the project needs to be adjusted by adding the time
required to assess, tailor, tune and write glue code for the COTS product. Normally this
effort is added to the entire COCOMO II Project effort, but the assessment portion is
supposed to be finished in the first 25% of the schedule. In order to make this happen the
project will need extra staffing in the requirements gathering and high level design phase.

COTS product assessment Effort = sum(feature points)*number of products evaluated

Feature points are the attributes of the COTS application that the project and the user
community evaluate the COTS application by. There are seventeen of these and one will
add either 0 if you don't care, 3 if nice to have and 5 if must have.

Seventeen feature points list:

Accuracy
Availability/Robustness: availability, fail safe, fault tolerance, redundancy
Security
Product Performance
Understandability: documentation quality, simplicity
Ease of Use
Version Compatibility upward compatibility
Inter-component Compatibility
Flexibility
Installation/Upgrade Ease
Portability
Functionality
Price
Maturity
Vendor Support
User Training
Vendor Concessions: willingness to escrow source code, or make specified modifications

Product tailoring/tuning Effort = sum(Tailoring Activities) * number of COTS products

Tailoring Activities Effort 1 point 5 points

Parameter Specification
Script Writing
I/O Report & GUI
Screen Specification
& Layout
Security/Access
Availability of COTS
Tailoring Tools
50 to 150 parms
5 to 20 line script
automated w/templates
1 security level w/ 20 profiles
excellent tools
1001 or more parms
51 or more line script
handwritten or custom
5 security levels w/ 100+
no tools

Glue Code development for functions found to be unavailable in COTS component

To calculate a function point for the glue path based on any glue code requiring six
complex interfaces (two from the local application, two from the glue code, and two from
the COTS application) which is automatically 60. If there is more than one path, it will
also require six complex interfaces. Each glue path automatically has a complexity of 30
(18 + easy to use, multiple organizations, conversion of data and complex operations).
This is the long way to say that every glue code path is 1,000 function points which will
add 3 to 4 months of schedule and 3/4th of a person to the full life cycle of project
duration.
SIMPLE HALSTEAD COMPLEXITY MEASURE

If you have to decide if a piece of code you already have is worth having:

Count the total conditional words/operators:

If
Then
Else
Case
While
Where
&&
Goto (counts as four)

Count total Lines of code

Divide total lines of code by total conditionals

Ratio 10+::1 a simple keeper 5::1 refactor? 2.5::1 discard

Total Conditionals = Total QA Tests for this to be completely tested.

Function points can be grouped into four functional areas to determine coverage for the
application requirements:
• Management (workgroup, application servers, systems on a network, computer)
• Coordination (check pointing and recovery, deactivation and recovery, migration,
transaction, replication, events, interface reference tracking)
• Repository (storage, information organization, relocation, types, trading)
• Security (access control, security audit, authentication, integrity, confidentiality,
non-repudiation, key management)

If the application does not address all four functional areas, what you have is not a
complete description of the application. The estimate will be off by 25% per slighted
functional grouping.