SIZE RELATED ATTRIBUTES

Introduction
Why we measure?
Evaluate the productivity
Evaluate the profits
A previous stage before estimate
Justify using new tools
Software projects are typically controlled by four major variables; time, requirements,
resources (people, infrastructure/materials, and money), and risks.
Overestimating needs can be very expensive for the organization
3 kinds of methods
Metrics Attributes
Simple and computable. It should be relatively easy to learn how to derive the metric, and its
computation should not demand inordinate effort or time
Empirically and intuitively persuasive. The metric should satisfy the engineers intuitive notions
about the product attribute under consideration
Consistent and objective. The metric should always yield results that are unambiguous.
Consistent in its use of units and dimensions. The mathematical computation of the metric should
use measures that do not lead to bizarre combinations of unit.
Programming language independent. Metrics should be based on the analysis model, the design
model, or the structure of the program itself.
Effective mechanism for quality feedback. That is, the metric should provide a software engineer
with information that can lead to a higher quality end product
Size Measurement
Size matters!
Direct impact on staffing, duration, and budget.
Size indicators:
Lines of Code (SLOC)
Function Points
Feature Points
Object Points
Number of boxes on a data flow diagram
Number of classes in a design diagram
Source lines of code
Source lines of code (SLOC or LOC) is a software metric
used to measure the size of a software 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 effort once the
software is produced.
Measurement methods
2 major types of SLOC measures:
physical SLOC (LOC)
logical SLOC (LLOC)
Logical LOC - Measure the number of statements.
Physical SLOC - Count the lines of the program's source code.
SLOC Example
Consider this snippet of C code as an example of the ambiguity
encountered when determining SLOC:

for (i = 0; i < 100; i += 1) printf("hello"); /* How many lines of code is this? */

In this example we have:

1 Physical Lines of Code (LOC)
2 Logical Line of Code (LLOC) (for statement and printf statement)
1 comment line
SLOC Example
Depending on the programmer and/or coding standards, the above "line of code" could
be written on many separate lines:
for (i = 0; i < 100; i += 1)
{
printf("hello");
} /* Now how many lines of code is this? */
In this example we have:
4 Physical Lines of Code (LOC): is placing braces work to be estimated?
2 Logical Line of Code (LLOC): what about all the work writing non-statement lines?
1 comment line: tools must account for all code and comments regardless of
comment placement.
 C COBOL

SLOC Example
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
#include <stdio.h> 000900
001000 DATA DIVISION.
int main(void) { 001100 FILE SECTION.
001200
printf("Hello World"); 100000 PROCEDURE DIVISION.
return 0; 100100
} 100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Hello world!" LINE 15 POSITION
10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.

Lines of code: 5 Lines of code: 17

(excluding whitespace) (excluding whitespace)
Advantages
It is widely used and universally accepted.
It directly relates to the end product.
LOC are easily measured upon project completion.
It measures software from the developer's point of viewwhat he actually
does (write lines of code).
Disadvantages
LOC is difficult to estimate for new software early in the life cycle.
Source instructions vary with the type of coding languages, with design methods, and
with programmer style and ability.
There are no industry standards (such as ISO) for counting lines of code.
LOC cannot be used for normalizing if platforms or languages are different.
How to interpret LOC? (is 250 more productive than 200?)
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?
Function Points
Uses the functionality of the software as a measure of its complexity.
Analogy: For a given house, we can say how many square meters it has (LOC) or we
can say how many bedrooms and bathrooms it has (FP).
A measure of the functionality of a given software.
The idea was first put forward by Allan Albrecht of IBM in 1979.
This method, known as Function Point Analysis (FPA) has evolved into the IFPUG
method, supported by the International Function Point User Group set up in 1986.
By the early 1990s, the IFPUG method became a major tool for quantifying software size.
Works best for traditional applications; not very suitable for algorithmitacally intensive
apps ; e.g., real-time and embedded apps.
Function Point Computation
Unadjusted Function Points
Weighting Factor
Simple Average Complex Function Points
Number of Outputs ____ x 4 ____ x 5 ____ x 7
Number of Inputs ____ x 3 ____ x 4 ____ x 6
Number of Inquiry Outputs ____ x 4 ____ x 5 ____ x 7
Number of Inquiry Inputs ____ x 3 ____ x 4 ____ x 6
Number of Files ____ x 7 ____ x 10 ____ x 15
Number of Interfaces ____ x 5 ____ x 7 ____ x 10
Total (FP):

NOTE: ____ denotes the count

Function Point Computation
1) Count Number of Functions in Each Category
General Guidelines for Counting
Count only software requirements functions.
Count logical representations. When any input, output, and so on requires different
processing logic, each one of those logical representations is a unique function point.
The first rough cut at estimating the size of the system to be developed entails
examination of the major system components. How much output is produced? How
much input is necessary to produce the output? How much data is stored?
Count the number of items: outputs, inputs, inquiries, and files.

14
Function Point Computation
Counting Outputs
The following list includes "hints" to keep in mind when counting outputs:
External outputs are things produced by the software that go to the outside of the system.
Outputs are units of business information produced by the software for the end user (application-
oriented).
Examples include screen data, report data, error messages, and so on.
Count each unique unit of output that leaves the application boundary. An output unit is unique if it
has a different format and/or requires different processing logic.
Function Point Analysis Outputs Weighting Factors
15 Data Items Referenced 619 Data Items Referenced 20 or More Data Items
Referenced
0 or 1 File Referenced Simple (4) Simple (4) Average (5)
2 or 3 Files Referenced Simple (4) Average (5) Complex (7)
4 or More Files Referenced Average (5) Complex (7) Complex (7)

15
Function Point Computation
Counting Inputs
Remember the following when counting inputs:
External inputs are things received by the software from outside of the system.
Inputs are units of business information input by the user to the software for processing or
storage.
Count each unique unit of input.

Function Point Analysis Inputs Weighting Factors

15 Data Items Referenced 619 Data Items Referenced 20 or More Data Items
Referenced
0 or 1 File Referenced Simple (3) Simple (3) Average (4)
2 or 3 Files Referenced Simple (3) Average (4) Complex (6)
4 or More Files Referenced Average (4) Complex (6) Complex (6)

16
Function Point Computation
Counting Inquiries (Output/Input)
When counting inquiries, keep the following in mind:
External inquiries are specific commands or requests that the software performs,
generated from the outside. It is online input that causes a software response.
Inquiries are direct accesses to a database that retrieve specific data, use simple keys,
are real-time (requires an immediate response), and perform no update functions.
Count each unique unit of inquiry. An inquiry is considered unique in either of two cases:
It has a format different from others in either its input or output portions.
It has the same format, both input and output, as another inquiry but requires
different processing logic in either.
Inquiries with different input and output portions will have different complexity weighting
factors, as explained later.
Queries are not inquiries. Queries are usually classified as either inputs or outputs because
they often use many keys and include operations or calculations on data.
17
Function Point Computation
Function Point Analysis Inquiries Weighting Factors
Output Part (Note: Select the
20 or More Data Items
Greatest ValueOutput or 15 Data Items Referenced 619 Data Items Referenced
Referenced
Input)
0 or 1 File Referenced Simple (4) Simple (4) Average (5)
2 or 3 Files Referenced Simple (4) Average (5) Complex (7)
4 or More Files Referenced Average (5) Complex (7) Complex (7)

Input Part (Note: Select the

20 or More Data Items
Greatest ValueOutput or 15 Data Items Referenced 619 Data Items Referenced
Referenced
Input)
0 or 1 File Referenced Simple (3) Simple (3) Average (4)
2 or 3 Files Referenced Simple (3) Average (4) Complex (6)
4 or More Files Referenced Average (4) Complex (6) Complex (6)

18
 Function Point Computation
Counting Data Structures (Files)
Things to keep in mind when counting data structures (files) include:
Internal files are logical files within the program.
Data structures (previously known as "files") are each primary logical group of user data
permanently stored entirely within the software system boundary.
Data structures are available to users via inputs, outputs, inquiries, or interfaces.
Function Point Analysis Files Weighting Factors
Note: Count of Logical
51 or More Data Items
Relationships, Not Physical 19 Data Items Referenced 2050 Data Items Referenced
Referenced
Record Types
1 Logical Record Simple (7) Simple (7) Average (10)
Format/Relationship
25 Logical Record Simple (7) Average (10) Complex (15)
Format/Relationships
6 or More Logical Record Average (10) Complex (15) Complex (15)
Format/Relationships
19
 Function Point Computation
Counting Interfaces
When counting interfaces, keep these thoughts in mind:
External files are machine-generated files used by the program.
Interfaces are data (and control) stored outside the boundary of the software system being
evaluated.
Data structures shared between systems are counted as both interfaces and data structures.
Count each data and control flow in each direction as a unique interface.
Function Point Analysis Interfaces Weighting Factors
Note: Number of Logical
51 or More Data Items
Relationships, Not Physical 19 Data Items Referenced 2050 Data Items Referenced
Referenced
Record Types
1 Logical Record Simple (5) Simple (5) Average (7)
Format/Relationship
25 Logical Record Simple (5) Average (7) Complex (10)
Format/Relationships
6 or More Logical Record Average (7) Complex (10) Complex (10)
Format/Relationships 20
Function Point Computation
2) Apply Complexity Weighting Factors
Multiply each the number of each type (simple, average,
complex) within each category (output, input, inquiries
[output/input], data structure [files], interfaces) by the appropriate
weighting factor.
Add the totals for each category.
Notice that the total results in a "raw function point" count.
Function Point Computation
Step 1. Count Number of Functions in Each Category
Step 2. Apply Complexity Weighting Factors
Simple Average Complex Function Points
Number of Outputs 12 x 4 = 48 11 x 5 = 55 5 x 7 = 35 48 + 55 + 35 = 138
Number of Inputs 8 x 3 = 24 9 x 4 = 36 6 x 6 = 36 24 + 36 + 36 = 96
Number of Inquiry 5 x 4 = 20 7 x 5 = 35 3 x 7 = 21 20 + 35 + 21
Outputs
Number of Inquiry Inputs 5 x 3 = 15 8 x 4 = 32 4 x 6 = 24 15 + 32 + 24 = 71
Number of Files 12 x 7 = 84 3 x 10 = 30 2 x 15 = 30 84 + 30 + 30 = 144
Number of Interfaces 9 x 5 = 45 6 x 7 = 42 4 x 10 = 40 45 + 42+ 40 = 127

Total (FP): 652 "Raw" Function

Points
Function Point Computation
3) Apply Environmental Factors
Adjust the raw function point total to account for environmental factors that affect the
entire software development process.
Function Points Analysis Environmental Factors Descriptions

Data Communications Online Update

Distributed Computing
Performance Requirements
Constrained Configuration
Transaction Rate
Online Inquiry and/or Entry
End-User Efficiency
Complex Processing
Reusability
Ease of Conversion/Install
Ease of Operation
Used at Multiple Sites
Potential for Function Change
Rating (0, 1, 2, 3, 4, 5)
Not present, or no influence = 0
Insignificant influence = 1
Moderate Influence = 2
Average Influence = 3
Significant Influence = 4
Strong Influence throughout = 5
Function Point Computation
Step 3. Apply Environmental Factors
Environmental Factor Rating (0, 1, 2, 3, 4, 5)
Data Communications 5
Distributed Computing 5
Performance Requirements 3
Constrained Configuration 0
Transaction Rate 5
Online Inquiry and/or Entry 4
End-User Efficiency 5
Online Update 4
Complex Processing 2
Reusability 2
Ease of Conversion/Install 3
Ease of Operation 4
Used at Multiple Sites 5
Potential for Function Change 4
Total (N): 51
Function Point Computation
4) Calculate Complexity Adjustment Factor (CAF)
CAF = 0.65 + (0.01 x N)
where N is the sum of the weighted environmental factors and 0.65 and 0.01 are
empirically derived constants

Step 4. Calculate Complexity Adjustment Factor (CAF)

CAF = 0.65 + (0.01 x N) = 0.65 + (0.01 x 51) = 1.16
Function Point Computation
5) Compute Adjusted Function Points
adjusted function points (AFP) = raw function points x CAF

Step 5. Compute Adjusted Function Points (AFP)

AFP = FP (Raw) x CAF = 652 x 1.16 = 756.32
Function Point Computation
6) Convert to LOC (Optional)
We may choose to convert function points to LOC for several reasons, including:
To measure and compare the productivity or size of programs or systems that are written in multiple languages;
To use the standard unit of measure for input into estimating tools.
To convert the size of a program or application in any language to the equivalent size if the application were written in a
different language.
LOC = adjusted function points x LOC per adjusted function point

Step 6. Convert to LOC (Optional)

LOC for the C Language = AFP x LOC/AFP = 756.32 x 128 = 96,808.96 LOC

Conversion from Programming Language

Advantages of Function Point Analysis
It can be applied early in the software development life cycle
It is independent of programming language, technology, and techniques, except for the
adjustments at the end.
Function points provide a reliable relationship to effort (if you can determine the right functions to
measure).
Creation of more function points per hour (week or month) is an easily understood, desirable
productivity goal
Users can relate more easily to this measure of size.
The productivity of projects written in multiple languages may be measured.
Function points provide a mechanism to track and monitor scope creep.
Function points can be used for graphical user interface (GUI) systems, for client/server systems,
and with object-oriented development.
Function points may be counted by senior-level users (clients or customers) as well as technicians.
Environmental factors are considered.
Disadvantages of Function Point Analysis
It requires subjective evaluations, with much judgment involved.
Results depend on technology used to implement it.
Many effort and cost models depend on LOC, so function points must be
converted.
There is more research data on LOC than on function points.
It is best performed after the creation of a design specification.
It is not well-suited to non-MIS applications (use feature points instead).
Feature Points
Builds upon FP disadvantages.
Feature points are an extension of the function point method designed to
deal with different kinds of applications, such as embedded and/or real-
time systems.
In 1986, Software Productivity Research developed feature point analysis
for system software.
A feature point is a new category of function that represents complex
algorithms and control (stimulus/response).
The complexity of the algorithm is defined in terms of the number of
"rules" required to express that algorithm.
Differences with Function Point
Also includes number of algorithms
weighting factor for an algorithm is 3.
Uses average weighting factors instead of simple, average,
and complex values.
Uses 2 environmental factors: logical complexity, and data
complexity.
CAF is calculated using a table.
Matches 2->0.6 and 10->1.4
Function Point Computation
Average Feature Points
Number of Inputs ___ x 4
Number of Outputs ___ x 5
Number of Files (Data ___ x 7
Structures)
Number of Inquiries ___ x 4
Number of Interfaces ___ x 7

Average Feature Points

Number of Algorithms ___ x 3
Total (FP):
Feature Point Computation
1) Count Feature Points
o This is the same as counting function pointscount inputs, outputs, files (data
structures), inquiries, and interfaces.

Step 1. Count Feature Points

Average Feature Points
Number of Inputs 12 x 4 48
Number of Outputs 15 x 5 75
Number of Files (Data Structures) 22 x 7 154
Number of Inquiries 17 x 4 68
Number of Interfaces 8x7 56
Total: 401
Feature Point Computation
2) Continue the Feature Point Count by Counting the Number of Algorithms
o An algorithm is a bounded computational problem that is included within a specific
computer program.
o Significant and countable algorithms deal with a definite, solvable, bounded problem
with a single entry and a single exit point.
o Developers who use data flow diagrams or structure charts in design often equate an
algorithm to a basic process specification or module specification.

Step 2. Count the Number of Algorithms

Average Feature Points
Number of Algorithms 43 x 3 129
Total (FP): 530 "Raw" Feature Points
Feature Point Computation
3. Weigh Complexity
o Use "average" weights instead of simple, average, or complex (note that the average
for feature points is different from the average for function points) for inputs, outputs,
files (data structures), inquiries, and interfaces. Weigh algorithms with a simple,
average, and complex multiplier.
o The average complexity factor for "files" is reduced from 10 to 7 to reflect the
reduced significance of logical files in computation-intensive software.
o The default weighting factor for algorithms is 3. The value can vary over a range of 1
to 10
Feature Point Computation
4. Evaluate Environmental Factors
Feature point uses only two: logic complexity and data complexity. The range is from 1 to 5.
Logic Values
1. Simple algorithms and calculations
2. Majority of simple algorithms
3. Average complexity of algorithms
4. Some difficult algorithms
5. Many difficult algorithms
Data Values
1. Simple data
2. Numerous variables, but simple relationships
3. Multiple fields, files, and interactions
4. Complex file structures
5. Very complex files and data relationships
Sum the logic and data complexity factor values, yielding a number between 2 and 10.
Feature Point Computation
5. Calculate the Complexity Adjustment Factor
Sum of Logic and Data Complexity Complexity Adjustment Factor
2 0.6
3 0.7
4 0.8
5 0.9
6 1.0
7 1.1
8 1.2
9 1.3
10 1.4
Feature Point Computation
Step 3. Weigh Complexity
Step 4. Evaluate Environmental Factors
Step 5. Calculate the Complexity Adjustment Factor (CAF)
Logic Values (Select One)
Simple Algorithms and Calculations1
Majority of Simple Algorithms2
Average Complexity of Algorithms3
Some Difficult Algorithms4
Many Difficult Algorithms5
Data Values (Select One)
Simple Data1
Numerous Variables, but Simple Relationships2
Multiple Fields, Files, and Interactions3
Complex File Structures4
Very Complex Files and Data Relationships5
Total (CAF): 4 + 3 = 7 Complexity Adjustment Factor
Feature Point Computation
6. Multiply the Raw Feature Point Count by the CAF
Raw FP x CAF =

Step 6. Multiply the Raw Feature Point Count by the CAF

Raw FP x CAF = 530 x 1.1 = 583 Adjusted Feature Points

7. Convert to Lines of Code (Optional)

LOC = AFP x LOC/AFP =

Step 7. Convert to Lines of Code (Optional)

LOC for the Java Language = AFP x LOC/AFP = 583 x 53 = 30899 LOC
Advantages and Disadvantages
Advantages of Feature Point Analysis
Advantages of feature point analysis are essentially the same as
those for function point analysis, with the additional advantage of
being an excellent approach to use in the size estimation of
algorithmically intensive systems.
Disadvantages of Feature Point Analysis
The primary disadvantage of feature point analysis is the
subjective classification of algorithmic complexity.
Comparative
Method Uses Staff During the project

Function points Not all systems and lacks Hard to train Need to re-estimate the
precision in small projects size as we have more
product knowledge

Feature points Software that uses Not easy to learn

complex algorithms

Lines of code Many metrics use LOC as Easy Based in other projects or
an input in own experience
Conclusion
The fundamental goals of software estimation are to produce
estimations of effort and schedule for anticipated software projects

Increasingly, it is recognized that software estimation techniques

must reflect, and be an integral part of the technical and managerial
processes used to develop and modify software.

The preceding techniques can help one achieve better estimates