Product Metrics

UNIT 4

 A measurement is a specific value or data point collected (e.g., "5 miles"), while a metric is a system or standard
used to evaluate or compare measurements (e.g., "distance traveled").

 A measurement is the act of quantifying something (e.g., "10 cm"), while a metric is a standard or framework
used to assess or track progress (e.g., "growth rate in centimeters per month").
 Product Metrics
• The working product is developed at the end of each successive phase.

• Each product can be measured at any stage of its development.

• Metrics are developed for these products so that they can indicate
whether a product is developed according to the user requirements.
The product metrics assess the internal product attributes in order to know the efficiency
of the following.

• Analysis, design, and code model

• Potency of test cases

• Overall quality of the software under development.

 Product Metrics Cont’d
• Metrics for analysis model: These address various aspects of the analysis model such as

system functionality, system size, and so on.

• Metrics for design model: These allow software engineers to assess the quality of design

and include architectural design metrics, component-level design metrics, and so on.

• Metrics for source code: These assess source code complexity, maintainability, and other

characteristics.

• Metrics for testing: These help to design efficient and effective test cases and also

evaluate the effectiveness of testing.

• Metrics for maintenance: These assess the stability of the software product.
Metrics for the Requirements Model

(OR) Metrics for analysis

model
 Metrics for the Requirements Model

• Technical work in software engineering begins with the creation of

the requirements model.
• Project Estimation - Analysis and Specification metrics –
indicator “size”

• Function-Based Metrics (Size measurement problem)

• Metrics for Specification Quality

 Function-Based Metrics

The function point (FP) metric

• The function point (FP) metric can be used effectively as a means for
measuring the functionality delivered by a system.

• Using historical data, the FP metric can then be used to:

• Estimate the cost or effort required to design, code, and test the
software.

• Predict the number of errors that will be encountered during testing.

• Forecast the number of components and/or the number of projected

source lines in the implemented system.
 Function-Based Metrics Cont’d

• Function points are derived using an empirical relationship based on countable

(direct) measures of the software’s information domain and qualitative
assessments of software complexity.

Number of external inputs (EIs). Number of external outputs (EOs).

Information
Number of external inquiries (EQs). Domain Values Number of internal logical files
(ILFs).

Number of external interface files (EIFs).

 Function-Based Metrics Cont’d
• Number of external inputs (EIs). Each external input originates from a user or is transmitted from
another application and provides distinct application-oriented data or control information. Inputs are
often used to update internal logical files (ILFs).

• Number of external outputs (Eos). Each external output is derived from data within the
application that provides information to the user. In this context, external output refers to reports,
screens, error messages, etc. Individual data items within a report are not counted separately.

• Number of external inquiries (EQs). An external inquiry is defined as an online input that results
in the generation of some immediate software response in the form of an online output (often retrieved
from an ILF).

• Number of Each internal logical file is a logical grouping of data that resides within the application’s
boundary and is maintained via external inputs.

• Number of external interface files (EIFs). Each external interface file is a logical grouping of
data that resides external to the application but provides information that may be of use to the
 Function-Based Metrics Cont’d

• The Information Domain Values have also been categorized

into 2 types.
• Transactional Functional type

• External inputs (EIs).

• External outputs (Eos).

• External inquiries (EQs).

• Data functional type

• Internal logical files (ILFs).

• External interface files (EIFs).

 Function-Based Metrics Cont’d

Other Applications

Ext
ern EIs EQs Eos EIFs
al Inp
u t
Extern
al Out
User put
Extern
a l E nq ILF ILF ILF
uires

Application Being
measured
Application
Boundary
ILF – Internal logic files
 Function-Based Metrics Cont’d

Function points (FP), UFP VAF (or) CAF

• VAF -Value Adjustment Factors

Steps involve calculating FP (or)

Step1: Calculate the Count total (or) UFP CAF- Complexity Adjustment
Factor
Step2: Calculate Complexity Adjustment Factor
• UAF – Unadjusted Function
Step3: Multiply UFP and CAF Point
 Function-Based Metrics Cont’d

Step 1:
• Calculate the Count total (or) UFP
Use the Complexity Value table

Example
 Function-Based Metrics Cont’d
Step 2:
• Calculate the Complexity Adjustment
Factor

CAF = 0.65 + ( 0.01 * ∑(Fi )

∑(Fi ) – the sum of value adjustment factors
0 1 2 3 4 5
0 - No Influence

1 - Incidental

2 - Moderate

3 - Average

4 - Significant

5 - Essential
 Function-Based Metrics Cont’d
Step 2 Cont’d: The Value adjustment factors
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer information to or from the application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to be built over multiple screens or
operations?
8. Are the ILFs updated online?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
 Function-Based Metrics Cont’d

Step 2 Cont’d:

For Example, let us consider All Factors are average, then ∑(Fi ) =
14*3 = 42
CAF = 0.65+(.01*42)
=1.07

Step 3: So, Function

Point
FP = 50*1.07
= 53.5
 Shortcomings of Function Point Metric
• Subjective Evaluations: It needs subjective evaluation with a lot of judgment involved.

• Conversion need: Many efforts and models are based on LOC, and a function point needs

to be converted.

• Less Researched Data: Less research data is available on function point as compared to

LOC.

• Late performance: It is performed after the creation of design specifications.

• Low Accuracy: It has low accuracy of evaluating as a subjective judgment is involved.

• Long learning curve: As the learning curve is quite long it's not easy to gain proficiency.

• Time consuming: It is a time-consuming method as less research data is available which

generates low accuracy and less effective results.

Example
External inputs (EIs):
• Password, panic button, and
activate/deactivate
External inquiries(EQs):
• Zone inquiry and sensor
inquiryoutputs(EOs):
External
• Messages and sensor
status
External interface files (EIFs):
• Test sensor, zone setting,
activate/deactivate, and alarm
alert
 Function Point Metric Cont’d

This FP can then be used in various metrics, such as:

Cost = $ / FP

Quality = Errors / FP

Productivity = FP / person-month
 Metrics for Specification Quality
The quality of the requirements model and the corresponding
requirements specification

• Scope to trace
• Scope of completeness
• Scope to interpret
• Scope of consistency
• Scope to understand
• Scope of accuracy
• Scope to test
• Scope to modify
• Scope to verify
• Scope to rank
• Scope to validate
 Metrics for Specification Quality

Metrics for Specification

Quality

• where nf is the number of functional requirements and nnf is the

number of nonfunctional (e.g., performance) requirements.
 Lack of Ambiguity
• To determine the specificity (lack of ambiguity) of
requirements

where nui is the number of requirements for which all reviewers had
identical interpretations. The closer the value of Q to 1, the lower is the
ambiguity of the specification.
 Completeness of Functional Requirements
• The completeness of functional requirements can be
determined by computing the ratio

where nu is the number of unique functional requirements, ni is the

number of inputs (stimuli) defined or implied by the specification, and ns

is the number of states specified.
• The Q2 ratio measures the percentage of necessary functions that have
been specified for a system.
• However, it does not address nonfunctional requirements.
 Overall Metric for Completeness

• where n is the number of requirements that have been

c

validated as correct and n is the number of requirements

nv

that have not yet been validated.