CSE-469

Project Management

Md. Saidul Hoque Anik

anik@cse.uiu.ac.bd
Popular option: Line of Code

From Wiki:

Source lines of code (SLOC), also known as lines of code (LOC), is

a software metric used to measure the size of a computer program by
counting the number of lines in the text of the program's source code.
SLOC is typically used to predict the amount of effort that will be
required to develop a program, as well as to estimate programming
productivity or maintainability once the software is produced.
1. Scope for automation of counting: since line of code is a physical entity,
manual counting effort can be easily eliminated by automating the
counting process. Small utilities may be developed for counting the LOC
in a program. However, a logical code counting utility developed for a
specific language cannot be used for other languages due to the
syntactical and structural differences among languages. Physical LOC
counters, however, have been produced which count dozens of
languages.
2. An intuitive metric: line of code serves as an intuitive metric for
measuring the size of software because it can be seen, and the effect of
it can be visualized. Function points are said to be more of an objective
metric which cannot be imagined as being a physical entity, it exists only
in the logical space. This way, LOC comes in handy to express the size of
software among programmers with low levels of experience.
3. Ubiquitous measure: LOC measures have been around since the
earliest days of software.[15] As such, it is arguable that more LOC data is
available than any other size measure.
• Lack of accountability: lines-of-code measure suffers from some fundamental
problems. Some[who?] think that it isn't useful to measure the productivity of a project
using only results from the coding phase, which usually accounts for only 30% to 35%
of the overall effort.[citation needed]
• Lack of cohesion with functionality: though experiments[by whom?] have repeatedly
confirmed that while effort is highly correlated with LOC, functionality is less well
correlated with LOC. That is, skilled developers may be able to develop the same
functionality with far less code, so one program with less LOC may exhibit more
functionality than another similar program. In particular, LOC is a poor productivity
measure of individuals, because a developer who develops only a few lines may still be
more productive than a developer creating more lines of code – even more: some good
refactoring like "extract method" to get rid of redundant code and keep it clean will
mostly reduce the lines of code.
• Adverse impact on estimation: because of the fact presented under point #1, estimates
based on lines of code can adversely go wrong, in all possibility.
• Developer's experience: implementation of a specific logic differs based on the level of
experience of the developer. Hence, number of lines of code differs from person to
person. An experienced developer may implement certain functionality in fewer lines
of code than another developer of relatively less experience does, though they use the
same language.
• Difference in languages: consider two applications that provide the same functionality
(screens, reports, databases). One of the applications is written in C++ and the other
application written in a language like COBOL. The number of function points would be
exactly the same, but aspects of the application would be different. The lines of code needed
to develop the application would certainly not be the same. As a consequence, the amount
of effort required to develop the application would be different (hours per function point).
Unlike lines of code, the number of function points will remain constant.
• Advent of GUI tools: with the advent of GUI-based programming languages and tools such
as Visual Basic, programmers can write relatively little code and achieve high levels of
functionality. For example, instead of writing a program to create a window and draw a
button, a user with a GUI tool can use drag-and-drop and other mouse operations to place
components on a workspace. Code that is automatically generated by a GUI tool is not
usually taken into consideration when using LOC methods of measurement. This results in
variation between languages; the same task that can be done in a single line of code (or no
code at all) in one language may require several lines of code in another.
• Problems with multiple languages: in today's software scenario, software is often developed
in more than one language. Very often, a number of languages are employed depending on
the complexity and requirements. Tracking and reporting of productivity and defect rates
poses a serious problem in this case, since defects cannot be attributed to a particular
language subsequent to integration of the system. Function point stands out to be the best
measure of size in this case.
• Lack of counting standards: there is no standard definition of what a line of code is. Do
comments count? Are data declarations included? What happens if a statement extends
over several lines? – These are the questions that often arise. Though organizations like SEI
and IEEE have published some guidelines in an attempt to standardize counting, it is difficult
to put these into practice especially in the face of newer and newer languages being
introduced every year.
• Psychology: a programmer whose productivity is being measured in lines of code will have
an incentive to write unnecessarily verbose code. The more management is focusing on lines
of code, the more incentive the programmer has to expand his code with unneeded
complexity. This is undesirable, since increased complexity can lead to increased cost of
maintenance and increased effort required for bug fixing.
In the PBS documentary Triumph of the Nerds, Microsoft executive Steve
Ballmer criticized the use of counting lines of code:

In IBM there's a religion in software that says you have to count K-

LOCs, and a K-LOC is a thousand lines of code. How big a project is it?
Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is
50K-LOCs. And IBM wanted to sort of make it the religion about how
we got paid. How much money we made off OS/2, how much they did.
How many K-LOCs did you do? And we kept trying to convince them –
hey, if we have – a developer's got a good idea and he can get something
done in 4K-LOCs instead of 20K-LOCs, should we make less money?
Because he's made something smaller and faster, less K-LOC. K-LOCs,
K-LOCs, that's the methodology. Ugh! Anyway, that always makes my
back just crinkle up at the thought of the whole thing.
A "unit of measurement" to express the amount of business functionality
 Measurements Parameters Examples
1. Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and

shared routines.
• FP characterizes the complexity of the software system and hence can
be used to depict the project time and the manpower requirement.
• The effort required to develop the project depends on what the software
does.
• FP is programming language independent.
• FP method is used for data processing systems, business systems like
information systems.
• The five parameters mentioned above are also known as information
domain characteristics.
 FP LOC

1. FP is specification based. 1. LOC is an analogy based.

2. FP is language independent. 2. LOC is language dependent.
3. FP is user-oriented. 3. LOC is design-oriented.
4. It is extendible to LOC. 4. It is convertible to FP (backfiring)
• Complexity Adjustment Factor (CAF)

F = 14 * scale
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

CAF = 0.65 + ( 0.01 * F )

• Calculate Unadjusted Function Point (UFP) from table. Example:

Function
Low Avg High
Units

EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10

FP = UFP * CAF
Given the following values, compute function point when all complexity
adjustment factor (CAF) and weighting factors are average.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Given the following values, compute function point when all complexity
adjustment factor (CAF) and weighting factors are average.
User Input = 50 Function
User Output = 40 Low Avg High
Units
User Inquiries = 35
User Files = 6 EI 3 4 6
External Interface = 4
EO 4 5 7
Solution: EQ 3 4 6
CAF:
scale = 3. ILF 7 10 15
F = 14 * 3 = 42
CAF = 0.65 + ( 0.01 * 42 ) = 1.07 EIF 5 7 10
UFP:
UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628

Function Point = 628 * 1.07 = 671.96

Inputs – This is how an application gets information. The most obvious
example is a data input field on a screen.
Outputs – Information that leaves the application, whether by report, file or
screen. Information that leaves the application can be used by another
application or by the user.
Internal Files – a group of logically related data that is contained within the
system that you are estimating AND is maintained by one or more Inputs
to the system.
External Files – a group of logically related data that is not contained within
the system you are estimating and/or is maintained by another
applications inputs. External files are for reference purposes only within
the bounds of the system you are estimating. An example would be an
Address Book application that provides an extract of employee addresses
(via an external file) to an HR application.
Queries – A process by which both inputs and outputs are utilized in data
retrieval from one or more Internal or External Files.
• A Data Function is broken down into DET’s and RET’s
• A Transactional Function is broken down into DET’s and FTR’s

DET – Data Element Type is a unique user recognizable, non-repetitive field.

Example: database table columns, form input fields, etc.
RET – Record Element Type is a user recognizable sub group of data
elements within an Internal or External File. Example: Table, Class, Union,
etc.
FTR – File Type Referenced is a file type referenced by a transaction. An FTR
must also be either an Internal or External file.
User identifiable
This term refers to defined requirements for processes and/or groups
of data that are agreed upon, and understood by, both the users and
software developers.
Elementary process
An elementary process is the smallest unit of activity that is meaningful
to the user. An elementary process must be self-contained and leave
the business of the application being counted in a consistent state.
Control information
This is data that influences and elementary process of the application
being counted. It specifies what, when, or how data is to be processed.
Screen

Stored as
DET
Screen

Stored as
RET
Screen

Stored as
RET
 RET

DET
As a simple example, let’s use a real world application, whereby
there is a component of a system that tracks and stores employee
information, utilized in reporting on job activities. The data
elements that will be stored within this system are: First Name, Last
Name, Email, User Type, Username, Password, Employee Number,
Status, Paygroup, Designation and Salary. For this example, let’s
assume that all of this data will be stored within the bounds of the
application you are estimating, in a single database file named
“Employee”.

1. How many DET?

2. How many RET?
ILFs represent data that is stored and maintained within the boundary of
the application you are counting. When counting ILFs you are basically
counting the data functions that your application is being built to maintain.
To take this a step further, let’s say there was an additional
requirement to be able to track the history of the employees
Designation and Salary. After all, employees do get promoted,
change jobs and such. Given this additional requirement, the
Designation and Salary information is stored in a secondary table in
the Employee File, with the Employee Number as the foreign key to
maintain the relationship of the employee and the employees
Designation and Salary.
Now that you know whether the ILF under consideration has a complexity
of Low, Average, or High, you'll come to this next table and determine the
number of FPs that should be counted for this ILF. A Low complexity ILF is
worth 7 points, an Average ILF is worth 10 points, and a High is worth 15.
https://alvinalexander.com/FunctionPoints/node24.shtml
• https://en.wikipedia.org/wiki/Source_lines_of_code
• https://www.javatpoint.com/software-engineering-functional-
point-fp-analysis
• https://live-
portlandwebworks.pantheonsite.io/2013/03/28/simplifying-the-
complex-function-point-analysis-part-1/
• https://www.portlandwebworks.com/2013/06/08/simplifying-the-
complex-function-point-analysis-part-2/
• https://www.geeksforgeeks.org/software-engineering-functional-
point-fp-analysis/
• https://www.geeksforgeeks.org/software-engineering-
calculation-of-function-point-fp/
• https://alvinalexander.com/FunctionPoints/FunctionPoints.shtml