Measures of Software Size

Measures of Software Size
An Introduction

Computer Science Department

bernstdh@jmu.edu

Overview

Our Interest:
- Measuring the size of software (typically for planning purposes)
Not of Concern Here:
- Quality/evaluation/assessment metrics (i.e., how well a system/product/design satisfies a particular objective)
Two Observations:
- In most other engineering disciplines, the appropriate measure(s) of size is fairly obvious
- For software there are both non-functional (i.e., using units that are a direct reflection of the product's structure) and functional (i.e., using units related to the functionality being provided) measures of size

"Obvious" Measures of Software Size

General:
- Physical Lines of Code (LOC) - all lines (e.g., '\n' characters)
- Logical Lines of Code - statements of consequence
Procedural/Structured Languages:
- Number of functions/subroutines
Object-Oriented Languages:
- Number of Classes
- Number of Methods
For "Web Apps":
- Number of "pages"
- Number of styles
- Number of functions

"Obvious" measures of Software Size (cont.)

The Shortcoming of the Obvious Measures:
- The don't account for "complexity"/"difficulty"
Learning from Other Engineering Disciplines:
- Measure the number of components of different kinds (e.g., bedrooms, bathrooms, etc...) and the characteristics of those components (e.g., square footage, finishings)

Function Points (FPs)

Countable/Direct Measures:
- External Inputs (EIs) - provide distinct application-oriented data from a user or other system
- External Outputs (EOs) - provide information to a user (e.g., reports, messages, prompts) or other system
- External Inquiries (EQs) - inputs that result in the generation of an immediate response (by the system) and output
- Internal Logical Files (ILFs) - logical groupings of data that are internal to the system
- External Interface Files (EIFs) - logical groupings of data that are external to the system but are of use to the system
Weights:
- Each count is weighted based on its complexity (i.e., simple, average or complex)
Value Adjustment Factors:
- The total is further weighted based on measures of complexity

Function Points (cont.)

Weighting Factors

Function Points (cont.)

Value Adjustment Factor Questions:
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?
8. Are the ILFs updated on-line?
9. Are the inputs, outputs, files or inquiries complex?
10. Is the internal processing complex?
11. Is the code to be designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Value Adjustment Factor Scores:
- Each question is given a score from 0 (not important) to 5 (essential)

Function Points (cont.)

Notation:
- \(M_{md}\) denotes measure \(m\) of difficulty \(d\)
- \(W_{md}\) denotes the weighting factor for measure \(m\) of difficulty \(d\)
- \(V_q\) denotes the value adjustment factor for question \(q\)
Definition of FP:
- \[ \left[\sum_{m=1}^{5}\sum_{d=1}^{3} (M_{md} \cdot W_{md})\right] \cdot \left[ 0.65 + 0.01 \sum_{q=1}^{14} V_q \right] \]

Function Points for "Web Apps" (Roetzheim, 2000)

External Inputs (EIs) - each input screen or form; each tab
External Outputs (EOs) - each HTML page; each page-producing script; each report
External Inquiries (EQs) - each externally published or message-oriented interface (e.g., DCOM references)
Internal Logical Files (ILFs) - each database table; each XML file
External Interface Files (EIFs) - logical groupings of data that are external to the system but are of use to the system (e.g., record formats)

Relationship between LOC and FP

LOC/FP Varies by Language:
- Averages about 120 for Assembly
- Averages about 100 for C
- Averages about 50 for C++, C#, Java and JavaScript
- Averages about 20 for SQL
LOC/FP Varies within a Language:
- Range of about 20 to about 300 for Assembly
- Range of about 40 to about 300 for C
- Range of about 20 to about 80 for C++, C#, and JavaScript
- Range of about 15 to about 150 for Java
- Range of about 10 to about 40 for SQL

Object Points (Boehm, 1996)

Object Points (cont.)

Weighting Factors

Object Points (cont.)

Notation:
- \(R \in [0, 1]\) denotes the proportion of reuse
Definition of OP:
- \[ \left[\sum_{m=1}^{3} \sum_{d=1}^{3} (M_{md} \cdot W_{md})\right] \cdot R \]

Story Points

The Idea:
- Use a relative (i.e., normalized) measure of size
The Approach:
- A small module (or feature) is chosen to be of size 1 and all other modules (or features) are sized relative to it
Advantages and Disadvantages:
- It is a little difficult to get used to
- The abstraction tends to make estimation easier and hence more accurate

There's Always More to Learn