Product Metrics

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 application.
 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

EIs EQs Eos EIFs

User
ILF ILF ILF

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

• UAF – Unadjusted Function Point

Step2: Calculate Complexity Adjustment Factor

Step3: Multiply UFP and CAF

 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?
14. Is the application designed to facilitate change and ease of use by the user?
 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 inquiry
External outputs(EOs):
• 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 that

nv

have not yet been validated.