Examples and Discussions

McCall Model Mapping

McCall Use-Factor-Criteria-MetricsMap

Figure. McCall Use-Factor-Criteria-Metrics Mapping

For Product Operation:

  • Usability:
    • Communicativeness: How easily users can communicate with the software.
    • Accessibility: How easily users with disabilities can interact with the software.
  • Reliability:
    • Accuracy: The correctness of the software’s outputs.
    • Consistency: The ability of the software to perform in the same way across different environments.
    • Completeness: The extent to which the software meets its functional requirements.
  • Efficiency:
    • Device Efficiency: The ability of the software to function across different devices (e.g., desktop, mobile).
    • Accessibility: Ensuring that performance is consistent, even with accessibility features enabled.

For Product Revision:

  • Reusability:
    • Accuracy: The accuracy of reused components.
    • Structuredness: How organized the code is for easy reuse.
    • Conciseness: The brevity and clarity of reusable components.
    • Device Independence: The software’s ability to function on various platforms without requiring significant adaptation.
  • Maintainability:
    • Structuredness: Organized code that is easy to navigate and modify.
    • Conciseness: Code that avoids redundancy and is more maintainable.
    • Legibility: Clear and easy-to-read code that facilitates understanding.
  • Portability:
    • Completeness: Ensuring all necessary dependencies are included for portability.
    • Device Independence: How well the software operates across various devices.
  • Testability:
    • Structuredness: Code that is easy to test by ensuring a clear structure.
    • Legibility: Readable code makes it easier to design and execute tests.
    • Traceability: The ability to trace tests back to specific requirements or components.

Metric Decomposition

Metrics Decomposition Example

Figure. Metrics Decomposition

Maintainability

Maintainability can be broken down into several key sub-metrics:

  1. Correctability:
    • Measures how easy it is to fix faults in the software.
    • Includes sub-metrics like:
      • Faults count: Number of faults found.
      • Closure time: Time taken to close a fault.
      • Isolate/Fix time: Time spent diagnosing versus fixing issues.
      • Fault rate: Faults per 1,000 lines of code.
  2. Effort:
    • Measures the resources required to make corrections or improvements.
    • Includes:
      • Resource prediction: Estimating the effort required.
      • Effort expenditure: Actual resources spent.
  3. Testability:
    • Focuses on the extent and quality of testing.
    • Sub-metrics include:
      • Degree of testing: E.g., statement coverage and test plan completeness.
      • Effort: Resources spent on testing.
  4. Expandability:
    • Measures how easily changes can be made to the software.
    • Includes:
      • Effort: Time or resources for implementing changes.
      • Change counts: Number of modifications.
      • Change effort: Average effort per change.
      • Change size: Volume of code modified.

Object-Oriented Metrics

When working with object-oriented programming, several key metrics help evaluate software quality:

  1. Number of Methods per Class: Indicates the complexity of a class.
  2. Depth of Inheritance Tree: Measures how deeply a class is inherited.
  3. Number of Child Classes: Tracks the number of subclasses for a class.
  4. Coupling Between Object Classes: Evaluates how interconnected different classes are.
  5. Calls to Methods in Unrelated Classes: Measures the extent of cross-class interactions.

Maintainability Index

Definition

The Maintainability Index is a single number representing the maintainability of code, calculated using:

Maintainability Index = MAX(0, (171 -
5.2 * log(Halstead Volume) -
0.23 * (Cyclomatic Complexity) -
16.2 * log(Lines of Code)) * 100 / 171)

Where:

  • Halstead Volume relates to the complexity of code based on distinct operators and operands.
  • Cyclomatic Complexity measures the number of independent paths through a program’s code.
  • LOC refers to Lines of Code.

Origins

The Maintainability Index was introduced in 1992 by Paul Oman and Jack Hagemeister. It was based on statistical regression analysis across various metrics in systems coded in C and Pascal.

Practical Use

  • Low values (close to 0) indicate hard-to-maintain code.
  • High values (approaching 171) suggest well-structured, maintainable code.

Design Considerations

From Microsoft’s design rationale:

  • If the index shows red, it indicates a high likelihood of maintainability issues.
  • The focus is on identifying problematic areas with a high degree of confidence.

“We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful.”

“The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code.”

Source. MSDN blog

Examples of Commonly Used Automated Metrics

Development Metrics:

  • Lines of Code (LOC): A simple yet widely used productivity metric.
  • Test Coverage: Ensures the completeness of tests, with variants like line coverage or branch coverage.
  • Cyclomatic Complexity: Highlights potential maintenance issues by measuring complexity.

Performance Metrics:

  • Response Time: Measures how quickly the system responds to user requests.
  • Throughput: The number of transactions or tasks handled in a given time.

Reliability Metrics:

  • Mean Time to Failure (MTTF): Average time until a failure occurs.
  • Mean Time to Repair (MTTR): Time taken to recover from failures.

Security Metrics:

  • Code Reviews: Evaluating adherence to security practices like input validation and secure coding standards.
  • Static Analysis Tools: E.g., Bandit, Snyk, used for automated security checks.

Maintainability Metrics:

  • Cyclomatic Complexity: Again used to assess maintainability.
  • Tech Debt: Metrics like SQALE and SONAR evaluate technical debt.
  • Dependency Analysis: Helps to understand and manage code dependencies and change impacts using methods like Design Structure Matrix.

Example: ISO 25002 Attributes-Metrics Mapping

In software engineering, quality attributes such as reliability, usability, or maintainability require metrics to measure the extent to which these attributes are present in a system. Metrics allow us to analyze quality during development and validate it during release.

Attributes-metrics mapping example

Figure. Mapping ISO 25002 Software Quality Attributes to Metrics

References

    Disclaimer: AI is used for text polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

    This site uses Just the Docs, a documentation theme for Jekyll.