SOFTWARE METRICS

Week 9 - Comprehensive Exam Study Notes

Chapter 5: Measuring Internal Product Attributes - Software Size | Use Case Point Estimation
University of Gujrat • Software Engineering
 PART A: CHAPTER 5 – Measuring Internal Product Attributes: Software
Size

1. What is Software Size?

Internal product attributes describe a software product in a way that is dependent only on the product
itself. One of the most important internal attributes is SOFTWARE SIZE — it can be measured statically
(without executing the system).
Size measurement must reflect: effort, cost, and productivity.
Software size is defined in terms of FOUR dimensions:
Dimension Examples What it measures
Length LOC, Halstead Physical size of the product (code, spec, design)
Functionality FP, Feature Pt, OP, UCP Amount of functionality / utility the system provides
Reuse Reuse Level, Density How much of the product was reused from elsewhere
Complexity Cyclomatic Complexity Logical / structural complexity of the code

2. Length: Lines of Code (LOC)

2.1 Basic Definitions
The most common measure of source code length is Lines of Code (LOC).
• NCLOC (Non-Commented LOC): Effective / executable lines of code.
• CLOC (Commented LOC): Comment-only lines.

LOC = NCLOC + CLOC

Comment Density = CLOC / LOC

2.2 LOC Counting Variations

Different organizations count LOC differently:
• Count of all physical lines INCLUDING blank lines.
• Count of all lines EXCLUDING blank lines and comments.
• Count of all statements EXCLUDING comments (multi-line statement = 1 LOC).
• Count of all lines EXCLUDING blank lines, comments, declarations, and headings.
• Count of only executable statements, NOT including exception conditions.

2.3 LOC Measurement Table

Statement Type Includes Excludes
Executable ✔ Yes

Declarations ✔ Yes

Compiler Directives ✔ Yes

 Comments (on own lines) ✖ No

Comments (on source-code lines) ✖ No

Blank Lines ✖ No

2.4 LOC Advantages and Disadvantages

ADVANTAGES DISADVANTAGES
Simple and automatically measurable Vague definition (varies by counter)
Correlates well with programming effort and cost Language dependability (C needs more lines than
Python for same task)
Not available for early planning (no code yet)

Developers’ skill dependability

Encourages “sumo” development (padding code

to look productive)

LOC vs FP Table (Jones, 1996): Typical SLOC per Function Point: Assembler=320, C=148,
Basic=107, Pascal=90, C++/Java 2=60, C#=59, PL/SQL=46, Visual Basic=50, HTML=14, SQL=13,
Excel=47, Delphi=18.

3. Halstead’s Software Science (1971–1979)

Maurice Halstead proposed that a program P is a collection of TOKENS composed of two basic
elements:
• OPERATORS: Language constructs — if/else, =, +, -, >, goto, main(), { }, ( ), #include, ;, etc.
• OPERANDS: Variables, constants, addresses — a, b, x, 100, etc.

3.1 Halstead’s Four Basic Measures

Symbol Name Definition
μ₁ (mu1) Distinct Operators Number of UNIQUE operators in the program
μ₂ (mu2) Distinct Operands Number of UNIQUE operands in the program
N₁ Total Operators Total number of occurrences of all operators
N₂ Total Operands Total number of occurrences of all operands

3.2 Derived Measures (Formulas)

Program Vocabulary: μ = μ₁ + μ₂
Program Length: N = N₁ + N₂
Estimated Length: N̂ = μ₁ × log₂(μ₁) + μ₂ × log₂(μ₂)
Program Volume: V = N × log₂(μ)
Program Difficulty: D = (μ₁/2) × (N₂/μ₂)
Effort: E = D × V
 Time to Develop: T = E / β where β ≈ 18 (Halstead’s claim; range 5–20)
Remaining Bugs (Delivered Defects): B = V / 3000

Conclusion: The bigger the program, the more time it takes to develop and the more bugs remain at
delivery.

3.3 Halstead Example 1 — C Program (Worked Out)

Given C program (if-else checking a < 10 or >= 20):
#include<stdio.h> main() { int a; scanf("%d",&a); if(a>=10) if(a<20) printf("10<a<20 %d\
n",a); else printf("a>=20 %d\n",a); else printf("a<=10 %d\n",a); }

OPERATORS (μ₁ = 20) OPERANDS (μ₂ = 3)

#, include, stdio.h, <...>, main, (...), {...}, int, ;, a, 10, 20
scanf, <=, \n, printf, <, >=, if...else, &, ,, %d, "...."
N₁ (operator occurrences) = 47 N₂ (operand occurrences) = 16

Program Length N = N₁ + N₂ = 47 + 16 = 63
μ = μ₁ + μ₂ = 20 + 3 = 23
Estimated Length N̂ = 20×log₂(20) + 3×log₂(3) = 20×4.32 + 3×1.58 ≈ 91.1

3.4 Halstead Example 2 — Triangle Classifier

1. read x,y,z; 2. type = "scalene"; 3. if (x==y or x==z or y==z) type="isosceles"; 4.
if (x==y and x==z) type="equilateral"; 5. if (x>=y+z or y>=x+z or z>=x+y) type="not a
triangle"; 6. if (x<=0 or y<=0 or z<=0) type="bad inputs"; 7. print type;

Measure Value
μ₁ - Distinct Operators 14
μ₂ - Distinct Operands 6
μ - Program Vocabulary μ₁ + μ₂ = 14 + 6 = 20
N₁ - Operator Occurrences 51
N₂ - Operand Occurrences 39
N - Program Length N₁ + N₂ = 51 + 39 = 90
V - Program Volume V = 90 × log₂(20) = 90 × 4.32 ≈ 388.8
N̂ - Estimated Length 14×log₂(14) + 6×log₂(6) = 14×3.81 + 6×2.58 ≈
53.3 + 15.5 ≈ 68.8

3.5 Criticisms of Halstead’s Work

• Developed in context of assembly languages; too fine-grained for modern languages.
• Treatment of basic vs derived measures is confusing.
• Notions of ‘time to develop’ and ‘remaining bugs’ are arguable.
• Cannot be extended to measure specification or design size.
4. Function Point (FP) Analysis
Function Point (FP), proposed by Albrecht (1979–1983), is a weighted measure of software
FUNCTIONALITY. The key idea: a product with more functionality will be larger in size.
FP is computed in TWO STEPS:
• Step 1: Calculate Unadjusted Function Point Count (UFC)
• Step 2: Multiply UFC by Value Adjustment Factor (VAF)

FP = UFC × VAF

4.1 Five Function Types (FP Components)

Type Abbreviation IFPUG Definition Example
External EI Elementary process that processes Data entry by users;
Inputs data coming FROM outside the file feeds from
application boundary. Primary intent: external apps
maintain ILFs or alter system
behavior.
External EO Elementary process that SENDS Reports with
Outputs data OUTSIDE the boundary. Must derived/calculated
contain mathematical formula, information
derived data, or maintain ILF.
External EQ Sends data outside boundary by Reports with only
Inquiries RETRIEVING data from ILF/EIF. NO retrieved data (no
math/calculations, NO derived data, calculations)
NO ILF maintenance.
Internal ILF User-identifiable group of logically Database tables,
Logical related data MAINTAINED WITHIN application control
Files the application boundary. data (e.g., user
preferences)
External EIF User-identifiable group of data Data maintained in a
Interface REFERENCED by the application different system
Files but MAINTAINED in another (same as ILF but for
application’s boundary. another app)

Key Distinction (EO vs EQ): EO performs calculations / creates derived data. EQ only retrieves and
displays data with NO calculations.

4.2 UFC Complexity Assessment

Each function type is assessed for complexity using two sub-metrics:
• DET (Data Element Types): Unique non-recursive user-recognizable fields.
• FTR (File Types Referenced): for EI, EO, EQ — number of ILFs/EIFs referenced.
• RET (Record Types): for ILF, EIF — logical sub-groups within the file.
EI Complexity Weight Table:
EI #FTR vs #DET 1–4 DET 5–15 DET > 15 DET
1 FTR Low (3) Low (3) Average (4)
2 FTR Low (3) Average (4) High (6)
 > 2 FTR Average (4) High (6) High (6)
EO Complexity Weight Table:
EO #FTR vs #DET 1–5 DET 6–19 DET > 19 DET
1 FTR Low (4) Low (4) Average (5)
2–3 FTR Low (4) Average (5) High (7)
> 3 FTR Average (5) High (7) High (7)
EQ Complexity Weight Table:
EQ #FTR vs #DET 1–5 DET 6–19 DET > 19 DET
1 FTR Low (3) Low (3) Average (4)
2–3 FTR Low (3) Average (4) High (6)
> 3 FTR Average (4) High (6) High (6)
ILF Complexity Weight Table:
ILF #RET vs #DET 1–19 DET 20–50 DET > 50 DET
1 RET Low (7) Low (7) Average (10)
2–5 RET Low (7) Average (10) High (15)
> 5 RET Average (10) High (15) High (15)
EIF Complexity Weight Table:
EIF #RET vs #DET 1–19 DET 20–50 DET > 50 DET
1 RET Low (5) Low (5) Average (7)
2–5 RET Low (5) Average (7) High (10)
> 5 RET Average (7) High (10) High (10)

4.3 UFC Formula

UFC = 4×NEI + 5×NEO + 4×NEQ + 7×NEIF + 10×NILF (using average weights)

Note: When average complexity weight is used, the formula above applies. Otherwise, sum (count ×
weight) for each type based on the specific complexity tables.

4.4 Value Adjustment Factor (VAF)

VAF adjusts UFC based on 14 Technical Complexity Factors (F1–F14). Each factor is rated 0 (not
relevant) to 5 (essential).

VAF = 0.65 + 0.01 × ΣFj (j = 1 to 14)

VAF range: 0.65 (all zeros) to 1.35 (all fives). Final FP = UFC × VAF.
Factor Description Factor Description
F1 Data Communications F8 On-line Update
F2 Distributed Data Processing F9 Complex Processing
 F3 Performance F10 Reusability
F4 Heavily Used Configuration F11 Installation Ease
F5 Transaction Rate F12 Operational Ease
F6 On-line Data Entry F13 Multiple Sites
F7 End-User Efficiency F14 Facilitate Change

4.5 Worked Example 1 — Spell Checker

SPECIFICATION: Checks all words in a document against internal dictionary and optional user
dictionary. Reports misspelled words. On request, shows word count and error count.
Type Count What they are
EI NEI = 2 Document name, user-defined dictionary name
EO NEO = 3 Misspelled word report, #words-processed message,
#errors message
EQ NEQ = 0 None
EIF NEIF = 2 Document file, personal dictionary
ILF NILF = 1 Internal dictionary

UFC = 4×2 + 5×3 + 4×0 + 7×2 + 10×1 = 8 + 15 + 0 + 14 + 10 = 47

Note — Solution A vs B: In Solution B, #words-processed and #errors-so-far are classified as EQ

(retrieval only, no calculations). In Solution A they are EO. Solution A is CORRECT because
requirement #5 says ‘shows number’ which is simple retrieval (EQ). The key is that these messages
are retrieval responses to explicit user requests.

4.6 Worked Example 2 — Chemical Plant System

System processes operator commands, consults 2 databases (pressure & temperature), and can send
emergency bulletins.
Type Count Comment
EI NEI = 2 Operator commands
EO NEO = 3 System outputs / responses
EQ NEQ = 1 Inquiry to bulletin board
EIF NEIF = 2 Pressure & temperature databases
ILF NILF = 1 Internal log

UFC = 4×2 + 5×3 + 4×1 + 7×2 + 10×1 = 8 + 15 + 4 + 14 + 10 = 51

4.7 Medical Appointment System Example

Type Description No. Weight Weighted
EI Patient name, Patient ID, 5 4 20
Appointment completed,
 Appointment purpose, Cancel
appointment
EO Comments, Calendar, 7 5 35
Supporting details,
Appointment info, Notification
List, Daily schedule, Weekly
schedule
EQ Check calendar, Query by 6 4 24
name/ID/date, Verify patient,
Available appointment
ILF Patient data records 1 10 10
EIF None 0 7 0
TOTAL UFC 89

4.8 FP Advantages and Critics

ADVANTAGES CRITICS / LIMITATIONS
Can be counted BEFORE design or code exists Subjective: affected by selection of weights
Useful for estimating cost, effort, schedule early in Requires full software specification
project
Helps with contract negotiations Physical meaning of FP unit is unclear
Standardized (ISO/IEC 14143-1, ISO/IEC 20926) Cannot account for new I/O types (data streams,
message passing)
Language-independent Not suitable for complex real-time / embedded
systems

5. Feature Point
Feature points are an EXTENSION of function points for applications with high algorithmic complexity
(real-time, process control, embedded software).
• For conventional systems: Feature Point ≈ Function Point.
• For complex systems: Feature Point is 20–35% HIGHER than FP.
Feature Point adds one extra component to the five FP categories:
• ALGORITHM (Na): A bounded computational problem, e.g., inverting a matrix, decoding a bit
string, handling an interrupt. Weight: ×3

UFC (Feature) = 4×NEI + 5×NEO + 4×NEQ + 7×NEIF + 7×NILF + 3×Na

Note: ILF weight is 7 (not 10 as in standard FP) in the Feature Point counting formula.

6. Object Point (OP)

Object Points are used for EARLY size estimation during feasibility studies. They count screens,
reports, and 3GL components.
6.1 Object Point Complexity for Screens
Screen Type Simple Medium Difficult
Total views < 3, both Simple
client/server < 3 data sources
Total views 3–7, OR 3–5 server Medium
data sources
Total views > 7, OR > 5 server Difficult
data sources

6.2 Object Point Weights

Object Type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL Component (acquired) — — 10

New Object Points = OP × (100 − %reuse) / 100

Effort [Person-Months] = New_OP / PROD

PROD (Productivity Rates by Developer Experience):

Experience/Skills Very Low Average High Very
Low High
PROD (OP per person-month) 4 7 13 25 50

6.3 Object Point Worked Examples

EXAMPLE 1: 4 screens (2 simple, 2 medium) + 3 reports (2 simple, 1 medium)

OP = 2×1 + 2×2 + 2×2 + 1×5 = 2 + 4 + 4 + 5 = 15... (see below)

OP = 2×1 + 1×2 + 2×2 + 1×5 = 13 (2 simple screens + 2 medium screens + 2 simple
reports + 1 medium report)
With 10% reuse: OPnew = 13 × (100−10)/100 = 11.7
Effort = 11.7 / 13 = 0.9 person-months (average PROD)

EXAMPLE 2: Smart Vending Machine (S1=Buying Screen, S2=Inventory Update, S3=Change Update,
R1–R7=Various Reports)
Object Classification Weight Sub-total
S1 Buying Screen Simple 1 1
S3 Change Update Medium 2 2
S2 Inventory Update Difficult 3 3
R1–R6 Reports (6 simple) Simple 2 12
R7 Report (1 difficult) Difficult 8 8
 Total OP 26

Effort = 26 / 13 = 2 person-months (average experience, 0% reuse)

7. Size Metrics Comparison

Criteria LOC Halstead FP OP
Applicable in early (requirements) No No Yes Yes
phase?
Subjective measure? No No Yes Yes
Derivable from system requirements? No No Yes Yes
Language dependable? Yes Yes No No
Clear physical meaning? Yes Partly No Yes

8. Software Reuse Metrics

• Reused Verbatim: Code used WITHOUT any changes.
• Slightly Modified: Fewer than 25% of LOC modified.
• Extensively Modified: 25% or more of LOC modified.
• New: None of the code from a previously constructed unit.
Reuse Metrics (requires a repository of reusable components):
• Reuse Level: % of different items coming from a repository source.
• Reuse Frequency: % of references to items from a repository source.
• Reuse Density: Normalized number of items from a repository source.

9. Recent / Alternative Size Estimation Approaches

• Decomposition: Break the problem into smaller manageable pieces and estimate each.
• Expert Opinion / Wideband Delphi: Experts independently estimate, share, and iterate until
convergence.
• Analogy / Fuzzy-Logic / Case-Based Method: Compare proposed project to past similar
projects; adjust estimate based on differences.
• Class-Code Expansion: Estimate size from analysis-phase classes. Boundary classes expand
1:2, Control 1:2.5 to 1:3, Entity 1:4 to 1:8 design classes. Average Java class has 20 methods,
each 10–20 LOC.
Class-Code Example: 6 boundary classes → 6–12 design classes (60–20 methods). Min LOC =
12×20×10×1.5 = 3,600. Max LOC = 29×20×20×1.5 = 17,400 (factor of 1.5 for non-method code).
 PART B: USE CASE POINT (UCP) – Estimation Technique

10. Introduction to Use Case Point (UCP)

• UCP is a Software Estimation Method developed by Gustav Karner in 1993.
• Concept is similar to Function Point Analysis.
• UCP measures the SIZE of an application from its use cases.
• Once the approximate size is known, we can derive an expected project duration if we also
know the team’s rate of progress.
• Estimation with UCPs requires all use cases to be written at the same level of detail (user goal
level). Use cases are normally completed within a single session.

10.1 What is a Use Case?

• A Use Case represents the set of steps defining the interaction between an actor and the
system.
• A Use Case is a series of related interactions between a user and a system that enables the
user to achieve a GOAL.
• Use Cases capture FUNCTIONAL REQUIREMENTS; the user of the system is referred to as an
‘Actor’.
• Actor can be a user OR an external system interacting with the system under development.
• Core components: actors, steps, and goals. Can also have exceptions, alternate paths,
extensions.

10.2 UCP Description — What Determines UCPs?

The number of UCPs in a project depends on:
• The number and complexity of use cases in the system.
• The number and complexity of actors on the system.
• Non-functional requirements (portability, performance, maintainability) that are NOT written as
use cases.
• The development environment (programming language, team motivation, etc.).

11. UCP Counting Process — 4 Phases

Phase Action
1 Calculate Unadjusted UCPs (UUCP = UUCW + UAW)
2 Adjust for Technical Complexity (TCF)
3 Adjust for Environmental Complexity (EF)
4 Calculate Adjusted Use Case Points (UCP = UUCP × TCF × EF)

FINAL: UCP = UUCP × TCF × EF

12. Phase 1: Calculate Unadjusted Use Case Points
(UUCP)
12.1 Step 1–2: Classify Use Cases — UUCW
Step 1: Count transactions (steps) in each use case. If written at User Goal Level, a transaction = one
step.
Step 2: Classify complexity and assign weight:
Use Case Complexity Number of Transactions Use Case Weight
Simple ≤3 5
Average 4 to 7 10
Complex >7 15
Step 3: Repeat for all use cases. Sum all weights.
Step 4: Unadjusted Use Case Weight (UUCW):

UUCW = 5 × NSUC + 10 × NAUC + 15 × NCUC

Where: NSUC = No. of Simple Use Cases, NAUC = No. of Average Use Cases, NCUC = No. of
Complex Use Cases.

12.2 Step 1–3: Classify Actors — UAW

An Actor is a person, program, or external system. Classify and assign weight:
Actor Complexity Example / Characteristic Actor Type Weight
Simple Another system with a defined Application System with API 1
Programming Interface (API)
Average System interacting through a protocol Protocol/Text UI 2
(HTTP, FTP etc.), OR a data store (files,
DBs), OR person through text-based UI
Complex A person interacting through a Graphical User via GUI 3
User Interface (GUI)
Step 2: Repeat for all actors and sum all weights.
Step 3: Unadjusted Actor Weight (UAW):

UAW = 1 × NSA + 2 × NAA + 3 × NCA

Where: NSA = No. Simple Actors, NAA = No. Average Actors, NCA = No. Complex Actors.

12.3 Unadjusted Use Case Points

UUCP = UUCW + UAW

UUCP represents the unadjusted size of the system.

12.4 Worked Example — ATM System
Actors: Cardholder (interacts via GUI → Complex, weight 3), Visa AS (interacts via communication
protocol → Average, weight 2).

UAW = 3 + 2 = 5

Use Case: ‘Withdraw money using a Visa card’ → Complex (more than 7 transactions). Weight = 15.

UUCW = 15
UUCP = UUCW + UAW = 15 + 5 = 20

13. Phase 2: Adjust for Technical Complexity (TCF)

Step 1: Consider 13 Technical Factors (T1–T13) and their weights. These represent project’s non-
functional requirements.
Fact Description Weight Fact Description Weight
or (W) or (W)
T1 Distributed System 2.0 T8 Portable 2.0
T2 Response time / throughput 1.0 T9 Easy to change 1.0
performance
T3 End user efficiency 1.0 T10 Concurrent 1.0
T4 Complex internal processing 1.0 T11 Special security objectives 1.0
T5 Code must be reusable 1.0 T12 Provides direct access for third 1.0
parties
T6 Easy to install 0.5 T13 Special user training facilities 1.0
required
T7 Easy to use 0.5
Step 2: For each factor, rate the project 0 (irrelevant) to 5 (very important).
Step 3: Impact of Factor = Impact Weight (W) × Rated Value (RV)
Step 4: Sum all impacts = Total Technical Factor (TFactor)

TFactor = Σ (Wi × RVi) for i = 1 to 13

Step 5: Calculate Technical Complexity Factor (TCF):

TCF = 0.6 + (0.01 × TFactor)

14. Phase 3: Adjust for Environmental Complexity (EF)

Step 1: Consider 8 Environmental Factors (F1–F8) that affect project execution:
Factor Description Weight (W)
F1 Familiar with the project model that is used 1.5
F2 Application experience 0.5
 F3 Object-oriented experience 1.0
F4 Lead analyst capability 0.5
F5 Motivation 1.0
F6 Stable requirements 2.0
F7 Part-time staff -1.0
(NEGATIVE)
F8 Difficult programming language -1.0
(NEGATIVE)

Important: F7 and F8 have NEGATIVE weights because they DECREASE productivity. Part-time staff
and difficult languages slow down a project.
Step 2: For each factor, rate 0 (irrelevant) to 5 (very important).
Step 3: Impact of Factor = Weight × Rated Value
Step 4: EFactor = sum of all impacts

EFactor = Σ (Fj × RVj) for j = 1 to 8

Step 5: Calculate Environmental Factor (EF):

EF = 1.4 + (-0.03 × EFactor)

15. Phase 4: Calculate Adjusted Use Case Points

UCP = UUCP × TCF × EF

UCP is the final adjusted size metric for the system, used to estimate project effort.

15.1 Summary of All UCP Formulas

Formula / Concept Expression
Use Case Weights Simple=5, Average=10, Complex=15
Actor Weights Simple=1, Average=2, Complex=3
UUCW 5×NSUC + 10×NAUC + 15×NCUC
UAW 1×NSA + 2×NAA + 3×NCA
UUCP UUCW + UAW
TFactor Σ (Wi × RVi) for T1 to T13
TCF 0.6 + (0.01 × TFactor)
EFactor Σ (Fj × RVj) for F1 to F8
EF 1.4 + (-0.03 × EFactor)
UCP (FINAL) UUCP × TCF × EF
16. UCP Advantages and Disadvantages
ADVANTAGES DISADVANTAGES
Based on use cases — measurable very early in Can only be used when requirements are written
project life cycle as use cases
UCP size estimate is independent of team size, Dependent on goal-oriented, well-written use
skill, and experience cases. Poorly structured use cases yield
inaccurate UCPs
UCP estimates are found to be close to actuals Technical and environmental factors have high
when done by experienced people impact — values must be assigned carefully
Easy to use; does not call for additional analysis UCP is useful for initial estimate of overall project
size but less useful for driving iteration-to-iteration
work
When use cases describe requirements (common
practice), UCP is the best-suited technique
 QUICK EXAM REVISION CHEAT SHEET

Key Formulas at a Glance

LOC = NCLOC + CLOC | Comment Density = CLOC/LOC
Halstead: μ = μ₁+μ₂ N = N₁+N₂ V = N×log₂(μ) B = V/3000 T = E/18
FP = UFC × VAF | VAF = 0.65 + 0.01×ΣFj (F1–F14)
UFC(avg) = 4×NEI + 5×NEO + 4×NEQ + 7×NEIF + 10×NILF
Feature Pt UFC = 4×NEI + 5×NEO + 4×NEQ + 7×NEIF + 7×NILF + 3×Na
OP Effort [PM] = OP×(100-r)/100 / PROD | PROD: VLow=4, Low=7, Avg=13, High=25,
VHigh=50
UUCP = UUCW + UAW = (5×NSUC+10×NAUC+15×NCUC) + (1×NSA+2×NAA+3×NCA)
TCF = 0.6 + 0.01×TFactor | EF = 1.4 + (-0.03×EFactor)
UCP = UUCP × TCF × EF

Key Distinctions to Remember

• EO vs EQ: EO = calculations/derived data. EQ = pure retrieval, no math.
• ILF vs EIF: ILF = maintained INSIDE boundary. EIF = maintained in ANOTHER system.
• FTR = for EI/EO/EQ (transaction types). RET = for ILF/EIF (file types).
• Halstead β = 18 (elementary discriminations per second) — Halstead’s claim; range 5–20.
• VAF range: 0.65 to 1.35 (all Fj=0 vs all Fj=5).
• F7 (Part-time staff) and F8 (Difficult language) in UCP Environmental Factors have NEGATIVE
(-1.0) weights.
• T1 (Distributed System) and T8 (Portable) in UCP Technical Factors have the HIGHEST weight
(2.0).
• UCP Simple Actor=1, Average=2, Complex=3. Simple UC=5, Average=10, Complex=15.