## **Software Size Metrics: LOC vs. FP**

**Size Metrics Overview:**

* Measure the "size" of software for estimation, comparison, and quality assessment.
* Two primary approaches: Lines of Code (LOC) and Function Points (FP).

**Lines of Code (LOC):**

* **What:** Counts the number of lines of source code.
* **Pros:** Simple, readily available.
* **Cons:**
    * Language-dependent.
    * Inconsistent counting.
    * Focuses on quantity, not functionality.
    * Ignores complexity.
* **Use Cases:** Simple projects, tracking basic productivity.
* **Example Metrics:** Effort/LOC, Errors/LOC, LOC/Person-Month.

**Function Points (FP):**

* **What:** Measures the functional size based on user-visible components (inputs, outputs, inquiries, files).
* **Pros:**
    * Technology-independent.
    * Focuses on functionality.
    * Useful for early estimation.
    * Better for cross-project comparison.
* **Cons:**
    * Complex calculation.
    * Subjective complexity assessment.
    * Not ideal for all software types.
* **Calculation:** FP = UFP (Unadjusted Function Points) \* VAF (Value Adjustment Factor).

**Comparison:**

| Feature          | LOC                               | FP                               |
| :--------------- | :-------------------------------- | :-------------------------------- |
| Measurement      | Physical size (lines of code)     | Functional size (user features) |
| Technology       | Language-dependent                | Language-independent             |
| Focus            | Code volume                       | User functionality              |
| Estimation       | Less accurate early on            | More accurate early on           |
| Complexity       | Simple counting                   | Complex calculation             |
| Subjectivity     | Low                               | High (complexity assessment)     |
| Applicability    | Simple projects                   | Wide range of projects           |
| Primary Use      | Simple productivity tracking      | Estimation, comparison, planning |
![[Pasted image 20250326234341.png]]

**Halstead Metrics: Explained**

Halstead's Software Science is a set of metrics developed by Maurice Halstead in the 1970s. It aims to measure the complexity and effort required to develop a program based on the number of operators and operands used in the code.

**Key Concepts:**

* **Operators:** Symbols/keywords performing actions.
* **Operands:** Variables/constants acted upon.

**Metrics:**

* `n1`: Unique operators.
* `n2`: Unique operands.
* `N1`: Total operators.
* `N2`: Total operands.
* `n`: Program vocabulary (`n1 + n2`).
* `N`: Program length (`N1 + N2`).
* `N^`: Calculated program length (`n1 * log2(n1) + n2 * log2(n2)`).
* `V`: Volume (`N * log2(n)`).
* `D`: Difficulty (`(n1 / 2) * (N2 / n2)`).
* `E`: Effort (`D * V`).
* `T`: Time (`E / 18`).
* `B`: Bugs (`V / 3000`).
![[Pasted image 20250326235929.png]]
**Pros:**

- **Objective Measurement:** They provide a relatively objective way to measure program complexity based on code analysis.
- **Language Independence:** They are largely independent of the programming language used.
- **Early Prediction:** They can be calculated early in the development process, allowing for potential complex issues to be identified.
- **Estimation of Effort and Time:** They can be used to estimate the effort and time required to develop a program.
- **Bug Prediction:** They offer a way to predict the number of bugs that might be present in the code.
- **Automation:** The calculation of Halstead's metrics can be automated.

**Cons:**
- complete code is required
- as the program level drops, the complexity rises
- **Limited Scope:** They focus primarily on the lexical complexity of the code and don't consider other factors like control flow or data structures.
- **Empirical Constants:** Some of the constants used in the formulas are empirical and may not be universally applicable.
- **Counting Challenges:** Accurately identifying and counting operators and operands can be complex, especially in modern programming languages.
- **Focus on Volume:** The Volume metric can be heavily influenced by the sheer volume of code, which doesn't always correlate with complexity.
- **Lack of Semantic Understanding:** They don't consider the semantic meaning or purpose of the code.
- **Modern Language Complexity:** Modern languages with extensive libraries and abstractions can make it harder to apply Halstead's metrics accurately.
- **Not universally accepted:** They are not as universally used as other metrics like cyclomatic complexity or function points.
## Cyclomatic Complexity

 It helps in determining the software quality.
• It is an important indicator of program code’s readability, maintainability
and portability.
• It helps the developers and testers to determine independent path
executions.
• It helps to focus more on the uncovered paths.
• It evaluates the risk associated with the application or program.
• It provides assurance to the developers that all the paths have been tested
at least once.
![[Pasted image 20250327020826.png]]![[Pasted image 20250327020835.png]]