lOMoARcPSD|15963275

Metrics for requirements model, Metrics for design model,

Metrics for component, interface and Metrics for source code
computer science (Sathyabama Institute of Science and Technology)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY

CDT-29 Metrics for the requirements model, Metrics for the

Topics Covered design model, Metrics for source code.

Motivation
Product metrics that are computed from data collected from the
(Why you (students)
requirements and design models, source code, and test cases.
Should learn these
topics?)
Lecture Learning Outcomes (LLOs): After completion of this lecture, you should be
able to…
LLO on topic  gain knowledge on metrics for requirements, design and
source code to build a high quality software product.

CDT-29: Lecture Summary Key Take away (s)

30.2 METRICS FOR THE REQUIREMENTS MODEL

Technical work in software engineering begins with the creation of the requirements model. It is at
this stage that requirements are derived and a foundation for design is established. Therefore, product
metrics that provide insight into the quality of the analysis model are desirable.
Although relatively few analysis and specification metrics have appeared in the literature, it is
possible to adapt metrics that are often used for project estimation and apply them in this context. These
metrics examine the requirements model with the intent of predicting the “size” of the resultant system.
Size is sometimes (but not always) an indicator of design complexity and is almost always an indicator of
increased coding, integration, and testing effort.

30.2.1 Function-Based Metrics

The function point (FP) metric can be used effectively as a means for measuring the functionality
delivered by a system. 4 Using historical data, the FP metric can then be used to
(1) estimate the cost or effort required to design, code, and test the software;
(2) predict the number of errors that will be encountered during testing; and
(3) forecast the number of components and/or the number of projected source lines in the implemented
system.
Function points are derived using an empirical relationship based on countable (direct) measures of
software’s information domain and qualitative assessments of software complexity. Information domain
values are defined in the following manner:
 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). Inputs should be distinguished from inquiries, which are counted separately.

 Number of external outputs (EOs).

Each external output is derived data within the application that provides information to the user. In
this context external output refers to reports, screens, error messages, and the like. Individual data
items within a report are not counted separately.

 Number of external inquiries (EQs).

Prepared by: Dr. V.Shankar, Professor, CSE(N) 1 |Page

Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY
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 internal logical files (ILFs).

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
data that may be of use to the application.

Once these data have been collected, the table in Figure 30.1is completed and a complexity value is
associated with each count. Organizations that use function point methods develop criteria for determining
whether a particular entry is simple, average, or complex. Nonetheless, the determination of complexity is
somewhat subjective. To compute function points (FP), the following relationship is used:
FP = Count total×[0.65+0.01 ×∑(Fi )]
where count total is the sum of all FP entries obtained from Figure 30.1 .
The F(i:1 to 14) are value adjustment factors (VAF) based on responses to the following questions [Lon02]:

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, fi les, 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?

Prepared by: Dr. V.Shankar, Professor, CSE(N) 2 |Page

Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY

30.2.2 Metrics for Specification Quality

Davis and his colleagues [Dav93] propose a list of characteristics that can be used to assess the
quality of the requirements model and the corresponding requirements specification: specificity (lack of
ambiguity), completeness, correctness, understandability, verifiability, internal and external consistency,
achievability, concision, traceability, modifiability, precision, and reusability. In addition, the authors note
that high-quality specifications are electronically stored; executable or at least interpretable; annotated by
relative importance; and stable, versioned, organized, cross-referenced, and specified at the right level of
detail. Although many of these characteristics appear to be qualitative in nature, each can be represented
using one or more metrics. [Dav93] For example, we assume that there are nr requirements in a specifi
cation, such that:

where nf is the number of functional requirements and nnf is the number of nonfunctional (e.g.,
performance) requirements.
To determine the specificity (lack of ambiguity) of requirements, Davis and colleagues suggest a
metric that is based on the consistency of the reviewers’ interpretation of each requirement:

30.3 METRICS FOR THE DESIGN MODEL

It is inconceivable that the design of a new aircraft, a new computer chip, or a new office building
would be conducted without defining design measures, determining metrics for various aspects of design
quality, and using them as indicators to guide the manner in which the design evolves. And yet, the design
of complex software-based systems often proceeds with virtually no measurement. The irony of this is that
Prepared by: Dr. V.Shankar, Professor, CSE(N) 3 |Page
Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY
design metrics for software are available, but the vast majority of software engineers continue to be
unaware of their existence.
Design metrics for computer software, like all other software metrics, are not perfect. Debate
continues over their efficacy and the manner in which they should be applied. Many experts argue that
further experimentation is required before design measures can be used. And yet, design without
measurement is an unacceptable alternative.
30.3.1 Architectural Design Metrics
Architectural design metrics focus on characteristics of the program architecture (Chapter 13) with
an emphasis on the architectural structure and the effectiveness of modules or components within the
architecture. These metrics are “black box” in the sense that they do not require any knowledge of the inner
workings of a particular software component.
Card and Glass [Car90] define three software design complexity measures: structural complexity,
data complexity, and system complexity.
For hierarchical architectures (e.g., call-and-return architectures), structural complexity of a module
i is defined in the following manner:

Width = maximum number of nodes at any one level of the architecture. For the architecture shown in
Figure 30.4 , width = 6
Prepared by: Dr. V.Shankar, Professor, CSE(N) 4 |Page
Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY
Fan-out is defined as the number of modules immediately subordinate to module i; that is, the number of
modules that are directly invoked by module i.

The U.S. Air Force Systems Command [USA87] has developed a number of software quality
indicators that are based on measurable design characteristics of a computer program. Using concepts
similar to those proposed in IEEE Std. 982.1-2005 [IEE05], the Air Force uses information obtained from
data and architectural design to derive a design structure quality index (DSQI) that ranges from 0 to 1. The
following values must be ascertained to compute the DSQI [Cha89]:
S1 = total number of modules defined in the program architecture
S2 = number of modules whose correct function depends on the source of data input or that produce data to
be used elsewhere (in general, control modules, among others, would not be counted as part of S2 )
S3 = number of modules whose correct function depends on prior processing
S4 = number of database items (includes data objects and all attributes that define objects)
S5 =total number of unique database items
S6 = number of database segments (different records or individual objects)
S7 = number of modules with a single entry and exit (exception processing is not considered to be a
multiple exit)
Once values S1 through S7 are determined for a computer program, the following intermediate values can
be computed:
Program structure: D1, where D1 is defined as follows: If the architectural design was developed using a
distinct method (e.g., data flow–oriented design or object-oriented design), then D1 = 1, otherwise D1 = 0.

Prepared by: Dr. V.Shankar, Professor, CSE(N) 5 |Page

Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY

30.3.6 Component-Level Design Metrics

Component-level design metrics for conventional software components focus on internal
characteristics of a software component and include measures of the “three Cs”—module cohesion [Bie94],
coupling [Dha95], and complexity [Zus97]. These measures can help you judge the quality of a
component-level design.
Component-level design metrics may be applied once a procedural design has been developed and
are “glass box” in the sense that they require knowledge of the inner workings of the module under
consideration. Alternatively, they may be delayed until source code is available.
30.3.7 Operation-Oriented Metrics
Because the class is the dominant unit in OO systems, fewer metrics have been proposed for
operations that reside within a class. Churcher and Shepperd. Three simple metrics, proposed by Lorenz
and Kidd [Lor94], are appropriate:
Average operation size (OSavg ).
Size can be determined by counting the number of lines of code or the number of messages sent by
the operation. As the number of messages sent by a single operation increases, it is likely that
responsibilities have not been well allocated within a class.
Operation complexity (OC).
The complexity of an operation can be computed using any of the complexity metrics proposed for
conventional software [Zus90]. Because operations should be limited to a specific responsibility, the
designer should strive to keep OC as low as possible.
Average number of parameters per operation (NPavg ).
The larger the number of operation parameters, the more complex the collaboration between
objects. In general, NPavg should be kept as low as possible.

Prepared by: Dr. V.Shankar, Professor, CSE(N) 6 |Page

Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY
30.3.8 User Interface Design Metrics
Although there is significant literature on the design of human/computer interfaces (Chapter 15), relatively
little information has been published on metrics that would provide insight into the quality and usability of
the interface.
A study of Web page metrics [Ivo01] indicates that simple characteristics of the elements of the
layout can also have a significant impact on the perceived quality of the GUI design. The number of words,
links, graphics, colors, and fonts (among other characteristics) contained within a Web page affect the
perceived complexity and quality of that page.
Although UI metrics may be useful in some cases, the final arbiter should be user input based on
GUI prototypes. Nielsen and Levy [Nie94] report that “one has a reasonably large chance of success if one
chooses between interface [designs] based solely on users’ opinions. Users’ average task performance and
their subjective satisfaction with a GUI are highly correlated.”

30.5 METRICS FOR SOURCE CODE

Halstead’s theory of “software science” [Hal77] proposed the fi rst analytical “laws” for computer
software. 14 Halstead assigned quantitative laws to the development of computer software, using a set of
primitive measures that may be derived after code is generated or estimated once design is complete. The
measures are:
n1 = number of distinct operators that appear in a program
n2 = number of distinct operands that appear in a program
N1 = total number of operator occurrences
N2 = total number of operand occurrences
Halstead uses these primitive measures to develop expressions for the overall program length,
potential minimum volume for an algorithm, the actual volume (number of bits required to specify a
program), the program level (a measure of software complexity), the language level (a constant for a given

Prepared by: Dr. V.Shankar, Professor, CSE(N) 7 |Page

Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY
language),and

Halstead’s work is amenable to experimental verification and a large body of research has been conducted
to investigate software science. A discussion of this work is beyond the scope of this book. For further
information, see [Zus90], [Fen91], and [Zus97].
CDT-29 – LECTURE LEVEL PRACTICE PROBLEMS (LLPs) to test the LLOs
To test whether you achieved the learning outcomes of this lecture, you should be
able to solve the following LLPs, in the class itself, after completion of the lecture.
Minimum one question / problem (LLP) is designed to test each expected LLO.
LLPs (on LLOs):
1Q: 30.3. A system has 12 external inputs, 24 external outputs, fi elds 30 different external queries, manages 4
internal logical files, and interfaces with 6 different legacy systems (6 EIFs). All of these data are of average
complexity and the overall system is relatively simple. Compute FP for the system.
Ans:
2Q:A major information system has 1140 modules. There are 96 modules that perform control and coordination
functions and 490 modules whose function depends on prior processing. The system processes approximately 220
data objects that each have an average of three attributes. There are 140 unique database items and 90 different
database segments. Finally, 600 modules have single entry and exit points. Compute the DSQI for this system.
Ans:

** The performance of the students is assed here after completion of this lecture
(CDT-29):
Total number of students present:
LL LLP.No N No. of StudentsN No. of students Not answered
answered

Prepared by: Dr. V.Shankar, Professor, CSE(N) 8 |Page

Downloaded by Durga Devi P ([email protected])
 lOMoARcPSD|15963275

10 Department of COMPUTER SCIENCE AND ENGINEERING (N), KITSW

U18IN603A SOFTWARE ENGINEERING VI SEM – CSO AY: 2022-23
W12-L2-CDT-29 - LECTURE SUMMARY

Prepared by: Dr. V.Shankar, Professor, CSE(N) 9 |Page

Downloaded by Durga Devi P ([email protected])