Quality Factors: McCall’s and ISO 9126 Models with a Worked Scoring Example

McCall and ISO 9126 are often memorised as two lists. That works until a question changes the vocabulary from factor to criterion, or from characteristic to subcharacteristic, and the familiar list suddenly feels unusable. One maintainability audit provides fixed observations for two transparent scores, which can then be compared by meaning. The scores help a team compare releases, but neither model prescribes these values, weights or pass lines as universal standards.

Quality factors in software engineering: factor, criterion and metric

A quality factor, called a characteristic in ISO 9126, is a user-visible quality objective such as reliability or maintainability. A criterion or subcharacteristic is a narrower property that contributes to that objective. A metric is the observation and rule used to assign a value.

For example: maintainability -> modularity -> 18 of 20 audit checks passed -> 0.90. The final number depends on the audit rule, normalisation and weights chosen for the project. The conceptual chain is what the model contributes. For broader context across metrics, testing, QA/QC and reliability, use Software Quality in Software Engineering. The McCall-to-ISO comparison isolates model vocabulary and maintainability scoring.

McCall’s quality model: three perspectives and eleven factors

McCall groups eleven quality factors according to three ways of viewing a software product:

Product operation asks how the software behaves in use. Product revision asks how safely and economically it can change. Product transition asks how well it moves to, or cooperates with, other environments.

Three vocabulary traps matter. Integrity means protection against unauthorised access or modification, not database referential integrity. Flexibility is the effort needed to adapt the product to new needs. Portability is the effort needed to move it to another hardware or software environment.

McCall’s factor-criteria-metric chain: calculate maintainability

Consider a deliberately small codebase audit. Each normalised value is the passed checks divided by 20, and the five weights total 1.00.

Using Q_maint = Σ(w_i x m_i), every contribution is:

• 0.25 x 0.80 = 0.2000

• 0.15 x 0.65 = 0.0975

• 0.20 x 0.70 = 0.1400

• 0.20 x 0.75 = 0.1500

• 0.20 x 0.90 = 0.1800

Therefore, Q_maint = 0.2000 + 0.0975 + 0.1400 + 0.1500 + 0.1800 = 0.7675, or 76.75/100. The checklist, normalisation rule and weights are pedagogical project choices. McCall supplies the relationship among factors, criteria and metrics, not universal weights or a universal pass score.

ISO 9126 quality model: product quality and quality in use

ISO 9126 describes product quality through six characteristics and named subcharacteristics:

The model also gives a second view, quality in use, comprising effectiveness, productivity, safety and satisfaction. The measurement context keeps these views distinct. Internal metrics inspect the product without executing it, such as examining code structure. External metrics observe executing software, such as response behaviour during a test. Quality-in-use measures capture a user’s outcome in a stated environment.

Product-quality characteristics therefore describe the software product. Quality-in-use characteristics describe what users achieve with that product in context. Treating the two lists as equivalent loses this boundary.

ISO 9126 maintainability: score the same release

The same release can be expressed through four ISO 9126 maintainability subcharacteristics. Here, every score comes from a fixed operational observation.

The team’s illustrative weighted calculation is:

70 x 0.25 + 80 x 0.25 + 75 x 0.20 + 85 x 0.30

= 17.5 + 20 + 15 + 25.5 = 78.0/100

Suppose this project sets a local acceptance line of 75/100. The McCall-style score is 76.75, and the ISO-style score is 78.0, so both clear that project threshold. This does not make the constructs interchangeable. ISO 9126 does not prescribe these measures, weights or the threshold.

McCall vs ISO 9126: map similarities without forcing one-to-one matches

Map the overlap carefully:

Both are hierarchical. McCall groups factors by operation, revision and transition; ISO 9126 uses characteristics and subcharacteristics, plus quality in use. The IBPS SO IT Officer Software Engineering Professional Knowledge guide shows the same traps elsewhere.

Quality-factor exam patterns and traps: classify, match and recalculate

Questions commonly ask you to place a McCall factor under its perspective, match an ISO characteristic with a subcharacteristic, distinguish product quality from quality in use, or recompute a weighted score after one input changes.

The key distinctions are:

1. Where is interoperability in McCall? Product transition.

2. Is integrity part of McCall reliability? No. It is a separate product-operation factor.

3. Where does analysability belong in ISO 9126? Maintainability.

4. Where does effectiveness belong? Quality in use.

5. What if modularity falls from 0.90 to 0.50 at weight 0.20? The reduction is 0.20 x 0.40 = 0.08, so the total falls from 0.7675 to 0.6875, or 68.75/100.

For the wider route, use UGC NET CS Exam Preparation. For application practice, continue with the UGC NET Computer Science and Applications Test Series. Our practice bank has about 20 live questions on this topic, so you can drill the calculation until it is automatic.

Quality factors: the short version and next step

Retrieve McCall as three perspectives and eleven factors, followed by factor -> criterion -> metric. Retrieve ISO 9126 as six product characteristics, their subcharacteristics, and a separate quality-in-use view. The scores 76.75 and 78.0 show how two vocabularies can assess one release without becoming interchangeable constructs. For full Software Engineering coverage, continue with NTA-UGC-NET Paper - 2. For this concept alone, redraw both tables and then recompute 68.75 without looking.