Home / Formulas / Predict size
§1 — Prediction Formula 1 of 7

Predict size

The size of the software is a scale factor. To predict any software reliability metric, you need to predict the size of the software in KSLOC (1,000 Source Lines of Code). Effective KSLOC is how much of the KSLOC is new or significantly modified.

Software Sizing

Effective, normalized size

Software size reflects the amount of work required to develop or modify it. It’s normalized so new code is weighted heavier than modified code or reused-but-unmodified code. “Effective” size means the size has been normalized for whether the code is new, modified, or reused. “Normalized” means the effective size has been converted to one base language. Size can be measured by detailed estimates or by estimating people-years of work. See IEEE 1633 Appendix A for more on sizing.

Requs AI Predict provides two methods for size prediction:

  1. KSLOC detailed size estimates
  2. People Year (PY) estimates

Software size is roughly doubling every four years — see the SEI reference on this trend.

People Years

People Years (PY) prediction

Enter the number of people-years for just one release of the product.

  1. Go to the Survey tab and select Required Inputs.
  2. Scroll right until the Project Size frame is in view.
  3. Select PY from the radio button option.
  4. Enter the number of people-years for just one release of the product.
    • Do not include management, testing or QA.
    • Include only software engineers working on this release of the product.
    • Convert all effort to people-years.
Worked example Six software engineers work on version 1.1 of a product. The cycle time is 8 months — that’s 48 months of effort, or 4 PY.
Calculations & Outputs

Dashboard size estimate frame — PY method

The Dashboard’s Size Estimate frame shows the calculations used to estimate normalized effective size.

Case
Normalized EKSLOC per PY
Nominal
33
Lower bound
6.7
Upper bound
159

The lower and upper bounds on size determine the lower and upper bounds for defects, failure rate, MTTF, and every downstream metric.

KSLOC Detailed Prediction

KSLOC detailed size prediction

  1. Go to the Survey tab and select Required Inputs.
  2. Scroll right until the Project Size frame is in view.
  3. Select K from the radio button option.

1. Select the language

Language is an input because it’s used to convert predicted defects per KSLOC to one universal base language — Assembler. Some languages are more dense than others. Select the language for this component; if a component mixes two language types, create a project for each type.

Language type
Examples
OO — Object Oriented
C++, C#, VB.net, Java, etc.
SGL — Second generation language
C, Basic
H — Hybrid
A mix of OO and second-generation language — common for components developed over several years.
A — Assembler
Very low-level language. Typically only firmware is developed in assembler.

2. Enter the size predictions

New, modified, reused, and auto-generated KSLOC.

Type of code
Effectiveness
Estimated New KSLOC
New code is 100% “effective” — none of it has seen operational use. Count only executable code; skip blank lines and comments.
Estimated Modified KSLOC
Modified lines are 100% effective, since the modification hasn’t been in operational use. Count only executable code.
Estimated Reused KSLOC & weighting
Code reused (e.g. from a previous release) but not modified. Typical adjustment is 0–10%. If 90% of the code has had no operational failure in the last y2 years, 10% is still effective, since defects may remain in the rest.
Estimated Auto-generated KSLOC & weighting
Code a tool generated rather than a human. Typical adjustment is 0–0.1, usually less than for reused code. Auto-generated code has very few coding defects but is subject to requirements defects.
Relative error of predicted vs. actual size
Once code is complete, this is zero. Before that, your KSLOC estimate carries error related to development phase and your organization’s past sizing accuracy.
Phase
Confidence
Concept or Software Requirements
50% or more
Top level design
25% or more
Detailed design, code, or unit test
10%
Systems testing
5%
Operational test or operations
0%
Why effectiveness matters Counting all existing code makes your defect estimate too large. Don’t count unmodified existing code that doesn’t interface with any third-party or evolving code — it has already been through its growth period and doesn’t carry the same failure potential as new or modified code.
Calculations & Outputs

Dashboard size estimate frame — KSLOC method

1. Code expansion is determined by the language type you selected.

Language type
Code expansion
Object Oriented
6
Second generation
3
Hybrid
4.5
Assembler
1
2. Normalized EKSLOC
Code Expansion × ((New KSLOC × Adjustment) + (Modified KSLOC × Adjustment) + (Reused KSLOC × Adjustment) + (Autogenerated KSLOC × Adjustment))
3. Normalized EKSLOC upper & lower bounds
Upper bound = Normalized EKSLOC + (Normalized EKSLOC × confidence bound %)
Lower bound = Normalized EKSLOC − (Normalized EKSLOC × confidence bound %)
The upper and lower bounds for size feed the upper and lower bounds for defects, failure rate, critical failure rate, MTTF, MTTCF, availability and reliability — every metric downstream of size inherits these bounds.

Continue to the next stage of the prediction.

Size feeds directly into the defect density assessment.

Predict Defect Density → ← Back to All Formulas