Estimating Software Size

#### What is software size?

We can measure software size in lines-of-code (LOC). This is useful in deciding how big a file you need to store the code, however it is not sufficient to decide how much effort is required to produce code. This is because some lines are more difficult to code than others.

Fenton and Pfleeger suggest three attributes which can be used to describe code:

• Length: physical size
• Functionality: functions supported by the product
• Complexity: problem/computational complexity (difficulty of the underlying problem), algorithmic complexity, structural complexity, cognitive complexity, etc…

#### Measuring length

We have already established that LOC is an inappropriate measure of software size.
It is useful to measure the length of the specification, design and code. This is because the length of the specification can help estimate the length of the design, which in turn can help estimate the length of the code.

We need a standard for measuring Lines of Code.

• Effective Lines of Code (ELOC): ignores comments and blank lines
• LOC = ELOC + CLOC: where CLOC is 'comment lines of code'

The definition of code length is influenced by the way in which it is used. Some organisations use length to compare projects (largest/smallest/average product, what is our productivity?, etc…) while others use it only within a project (largest/smallest/average module, module length w/ respect to number of faults, etc.).

#### Non-textual or external code

Visual programming and window environments is changing the notion of what constitutes a software program. New approaches to programming raise two separate issues:

• How do we account in our length measures for objects that are not textual
• How do we account in our length measures for components that are constructed externally

#### Length of Specifications & designs

Specification and design documents usually combine text, graphs and special mathematical diagrams and symbols. We can define a page as an atomic object.

We could also view length as a composite measure:

• Define a pair of numbers representing text length and diagram length
• We can define appropriate atomic objects for the different types of diagrams and symbols

#### Counting reused code

It is difficult to determine what we mean by 'reused code'.

• Reused verbatim: the code in the unit was reused without any changes
• Slightly modified: less than 25% of the lines of code in the unit were modified
• Extensively modified: 25% or more of the LOC were modified

#### Measuring length for OO development

OO languages suggest new ways of measuring length; ie - count of objects and methods.

## Functionality

Many software engineers have argued that length is misleading and the amount of functionality of a product paints a better picture of product size.

#### Function-point method

This is a widely industry-adopted method which is considered better than LOC. It measures the length of a software product from specification (early in the life-cycle).
Allbrecht identified five basic functions that frequently occur in commercial software development. He categorized them according to their relative development complexities.

 Software 1. Inputs Screens or forms for adding/modifying data 2. Outputs Screens or reports produced by an application 3. Inquiries Screens that allow a user to interrogate an application 4. Data files Logical collection of records 5. Interface Files shared with other systems

#### Calculating function points

We determine from the specification an unadjusted function point count (UFC) that involves the following item categories:

• External inputs: input provided by the user that describes distinct application-oriented data.
• External outputs: items provided to the user that generate distinct application oriented data (reports, messages, etc.)
• External inquiries: interactive inputs requiring a response
• External files: machine-readable interfaces to other systems
• Internal files: logical master files in the system

We assign a subjective 'complexity' rating to each item category on a 3-class ordinal scale (simple, average or complex). We assign a weight to each item category:

 Weight factor Item Simple Average Complex External inputs 3 4 6 External outputs 4 5 7 External inquiries 3 4 6 External files 7 10 15 Internal files 5 7 10

The UFC is the weighted sum of number of items of each category:

(1)
\begin{align} UFC = \sum_{i=1}^{15} numberOfItemsOfCategory_{i} \times weight_{i} \end{align}
(2)
\begin{align} FP = UFC \times TCF \end{align}

… where TCF is the technical complexity factor (also complexity multiplier)

(3)
\begin{align} TCF = 0.65 + 0.01 \sum_{i=1}^{14} F_{i} \end{align}

… where Fi is a complexity component rating between 0→5 (0 = irrelevant, 3 = average, 5 = essential).

 F1 : reliable back-up & recovery F2 : data communications F3 : distributed functions F4 : performance F5 : heavily used configuration F6 : online data entry F7 : operation ease F8 : online update F9 : complex interface F10 : complex processing F11 : reusability F12 : installation ease F13 : multiple sites F14 : facilitate change

#### Use of FP

Function-point can be the basis of effort estimation (ie: determining person days of effort). Other uses include:

• Defect density can be expressed as defects per function point
• Bidding for a project; \$x per FP
• Tracking progress

#### Limitations of FP

• Subjectivity in technology factor: FP is suitable to measure functionality but not complexity aspects of software size. Also FP is found to be effective in functionality-intensive applications but not so effective in algorithmically complex applications.
• Subjectivity in assigning weights: weights are not necessarily applicable to other environments.
• Double counting: internal complexity is counted as giving weights in UFC and again in TCF
• Researchers have shown TCF does not improve accuracy over UFC
• Requirements creep: changes in requirements mean original FP calculations are invalidated
• Problems with measurement theory: incorrectly combines measurements from different scales (weights and TCF are ordinal, counts are absolute)

However, FP can be more useful than software length if:

• FP is used with care
• FP's limitations are well understood and accounted for

• Usable in the earliest requirement phases
• Independent of programming language, product design or development style
• Large body of historical data
• Well documented method
• Active users group

## COCOMO 2.0: Object points

To compute object points an initial size measure is generated by counting: screens, reports and 3rd generation language components.
These are then classified as simple, medium or difficult.

 Object type Simple Medium Difficult Screen 1 2 3 Report 2 5 8 3GL component - - 10

Reuse is taken into account in calculating object points; assuming that r% of the objects will be reused from a previous project then:

• New object points = (object points) x (100 - r) / 100

## DeMarco's approach

DeMarco proposed a functionality measure based on his structured analysis and design notation (such as DFD and ER diagrams)

• Specification weight metrics involve two measures (function bang for "function strong" systems, data bang for "data strong" applications)
• The function bang measure is based on the number of functional primitives (number of lowest-level bubbles in a DFD)
• The data-bang entity count is weighted according to the number of relationships involved in each entity
page revision: 6, last edited: 08 Jun 2008 12:13