Skip to main content

Codebase Volumetrics & Complexity Analysis

Date: 2026-01-09 Scope: WepNG_MVC Solution

Executive Summary​

Based on a static analysis of the codebase, the WepNG_MVC system is estimated to be approximately 16,000 Function Points (FP) in size.

This places the application in the "Very Large / Enterprise ERP" size category. Rewriting such a system from scratch would typically require ~110+ man-years of effort (based on industry standard of ~150 FP/developer/year for maintenance/evolution or ~200-300 for new dev).

Recommendation: DO NOT REWRITE. The "Strangler Fig" pattern is the only viable migration strategy.

1. Volumetrics Data​

The following raw metrics were collected from the current branch:

MetricCountDescription
Lines of Code (LOC)851,377C# Code only (excluding JS/HTML/CSS). Verified.
Files5,490Total C# files.
Controllers765Functional Modules / Areas.
Entry Points3,052Public Action Methods (Potential User Interactions).
Screens / Views2,797Razor .cshtml files (User Interfaces).
Domain Models~3,395Classes in WepNG_Business/Model (Entities + DTOs).

2. Function Point Estimation (Methodology)​

Two independent methods were used to estimate the functional size, yielding consistent results.

Method A: Backfiring (industry Standard from LOC)​

  • Formula: Total LOC / Language Gear Factor
  • Factor for C#: ~53 LOC per Function Point (QSM / SPR data).
  • Calculation: 851,377 / 53 = 16,063 FP

Method B: Component Counting (Approximate IFPUG)​

  • Transactional Functions (EI/EQ):
    • Based on 3,052 Controller Actions.
    • Assumed Complexity: Average (~4 FP/Action).
    • Contribution: ~12,208 FP.
  • Data Functions (ILF):
    • Based on ~3,400 Model files (Assuming ~10% are core "Entities" worth 7 FP, rest are small DTOs/Enums).
    • Contribution: ~340 * 7 = ~2,380 FP.
  • Total: 12,208 + 2,380 = 14,588 FP

Note: The Backfiring method (A) often captures complexity hidden in "God Classes" better than component counting (B), suggesting the real size is closer to 16k FP.

3. Analysis & Implications​

3.1. Complexity "Hotspots"​

As noted in the hotspot_analysis_results.md, the complexity is not evenly distributed.

  • WEPV2ModelBuilder.cs (17k LOC) and OrderTravelProductOMGT.cs (7k LOC) indicate "God Classes" that concentrate a disproportionate amount of logic.
  • This suggests that while the system is large (14.5k FP), the Maintenance Complexity is likely higher than the raw size suggests due to coupling.

3.2. Refactoring vs. Strangling​

  • Big Bang Rewrite Risk: Extremely High. Replicating 14,500 FP of logic (much of it hidden in 17k lines of ModelBuilder mapping) is virtually impossible without massive regression.
  • Strangler Strategy: Essential.
    • Isolate the 765 Controllers one by one.
    • Move them to a new platform (Target) incrementally.
    • Use the 3,050 Entry Points as a checklist for migration.

4. Next Steps​

  1. Freeze God Classes: As per Hotspot recommendations.
  2. Define Bounded Contexts: Group the 3,395 Models into domains (e.g., "Order", "Product", "CRM") to map the Monolith's internal structure.
  3. Prioritize Modules: Use Churn data to decide which of the 765 Controllers to strangle first (High Churn = High Value).