SOFTWARE ENGINEERING TECHNIQUES

LESSON 10:

Topics Covered Major Concepts

Effort Estimation, Data Structure Metrics, Information flow Coupling: refers to the degree of interdependence between parts
metrics of a design, usually the amount of data shared by parts.
Objectives Cohesion: refers to the degree of dependence within parts of
Upon completion of this Lesson, you should be able to: the design, usually the strength of interaction.
• Know what do you mean by estimation of effort The definitions of these concepts depend on the design
• Know what is data structure metrics paradigm or notation used to express the design. It is always
• Know what is information flow metrics
programming language dependent.

In our last class we have seen what is LOC and FP estimation Data Bindings
techniques. In today’s lecture we’ll have a llok at what is effort A segment-GLOBAL-Segment data binding (p, r, q) is an
estimation and the two different metrics, i.e., data structure occurrence of the following:
metrics and information flow metrics. 1. Segment p modifies global variable r
What is effort estimation? 2. Variable r is accessed by segment q
Effort Estimation 3. p/=q
Effort estimation is the most common technique for costing
any engineering development project. A number of person-
days, months, or years as applied to the solution of each project
task. A dollar cost is associated with each unit of effort and an
estimated cost is derived.
Like the LOC or FP technique, effort estimation begins with a
delineation of software functions obtained from the project
scope. A series of software engineering tasks – requirements Existing of a data binding (p, q, r) -> q dependent on the
analysis, design, code and test must be performed for each performance of p because of r.
function. Functions and related software engineering tasks may DB(p, r, q) /= DB(q, r, p)
be represented as part of a table. (p, r, q) represents a unique path representation between p and
The planner estimates the effort (e.g., person-months) that will q.
be required to accomplish each software engineering tasks for The total # data binding represents the degree of a certain kind
each software function. These data comprise the central matrix “connectivity” ie between segment pairs via globals within a
of the effort table. Labor rates (i.e., cost/unit effort) are applied complete program.
to each of the software engineering tasks. It is very likely the
labor rate will vary for each task. Senior staffs are heavily
involved in requirements analysis and early design tasks; junior
staff (who are inherently less costly) are involved in later design
tasks, code, and, early testing.
Cost and effort for each function and software engineering task
are computed as the last step. If effort, estimation is performed
independently C LOC or FP estimation, we now have two
estimates for cost and effort the may be compared and
reconciled. If both sets of estimates show reasonable
agreement, there is good reason to believe that the estimates are
reliable. If on the other hand, the results of these
decomposition techniques show little agreement, further
investigation and analysis must be conducted.
Data Structure Metrics
Data Structure metrics measure the data interaction of the
product.

© Copy Right: Rai University

3E.253 35
 Data Binding Example CC Cyclomatic Complexity
SOFTWARE ENGINEERING TECHNIQUES

Cyclomatic complexity is probably the most widely used

complexity metric in software engineering. Defined by Thomas
McCabe, it’s easy to understand, easy to calculate and it gives
useful results. It’s a measure of the structural complexity of a
procedure.
How to calculate cyclomatic complexity?
CC = Number of decisions + 1
Thus, cyclomatic complexity equals the number of decisions
plus one. What are decisions? Decisions are caused by
conditional statements. In Visual Basic they are If..Then..Else,
Select Case, For..Next, Do..Loop and While..Wend/End While.
The cyclomatic complexity of a procedure with no decisions
equals 1. There is no maximum value since a procedure can have
any number of decisions.
Cyclomatic complexity, also known as V(G) or the graph
theoretic number, is calculated by simply counting the number
of decision statements. A multiway decision, the Select Case
statement, is counted as several decisions. This version of the
metric does not count. Boolean operators such as And and Or,
even if they add internal complexity to the decision statements.
Now let us see what is information flow metrics
Information Flow Metrics
Cyclomatic complexity and the structural fan-in/fan-out metrics
deal with the control flow. However, they don’t take data flow
into account. Data flow, or information flow, means parameter
Levels of Data Binding(DB) passing and variable access.
• Potential DB is an ordered triple (p,x,q) for components p There are several metrics for measuring the information flow:
and q and variable x in the scope of p and q. IFIN, IFOUT, IFIO and IC1.
• Usage DB is a potential DB such that p and q both use x for The information flow metrics attempt to define the complexity
reference or assignment in terms of the total information flowing through a module, in
• Feasible DB (actual) is a usage DB such that p assigns to x an effort to quantify coupling.
and q references x The earliest work on information flow metrics was done by
• Control flow DB is a feasible DB such that flow analysis Henry ad Ksfura. In their metric, the complexity of a module is
allows the possibility of q executed after p has started. considered as depending on the intramodule complexity and
the intermodule complexity. The intramodule complexity is
Segment Global Usage Pairs approximated by the size of the module in lines of code(which
• A segment global usage pair (p, r) is an instance of a global is actually the estimated size at design time). The intermodule
variable r being used by a segment p (i.e., r is either modified complexity of a module depends on the total information
or set by p flowing in the module(inflow) and the total information
• Each usage pair represents a unique “use connection” flowing out of the module(outflow). The inflow of a module
between a global and a segment is the total number of abstract data elements flowing in the
• Let actual usage pair (AUP) represent the count of true usage module(i.e., whose values are used by the module), and the
pairs (i.e., r is actually used by p) outflow is the total number of abstract data elements that are
flowing out of the module (i.e., whose values are defined by
• Let possible usage pair (PUP) represent the count of
this module and used by other modules). The module design
potential usage pairs (i.e., given the program’s globals and
complexity, Dc, is defined as
their scopes, the scope of r contains p so that p could
potentially modify r) (worst case) Dc = size * (inflow * outflow) 2
• Then the relative percentage usage pairs (RUP) is RUP = The term (inflow * outflow) refers to the total number of
AUP/PUP and is a way of normalizing the number of usage combinations of input source and output destination. This
pairs relative to the problem structure. term is squared, as the interconnectionbetween the modules is
considered a more important factor(compared to the internal
• The RUP metric is an empirical estimate of the likelihood
complexity) determining the complexity of a module. This is
that an arbitrary segment uses an arbitrary global.
based on the common experience that the modules with more

© Copy Right: Rai University

36 3E.253
interconnections are harder to test or modify compared to other Variations of Information Flow Complexity

SOFTWARE ENGINEERING TECHNIQUES

similar-size modules with fewer interconnections. It is to be noted that IC1 doesn’t conform to the IEEE 982.2
Watching for procedures with high informational complexity standard method of calculating informational flow complexity.
can reveal the following issues: procedure has more than one Next we’re going into the details of IEEE 982.2 and showing
function; procedure is a stress point in the system (with the differences between IC1 and IEEE 982.2. As of now,
information traffic); procedure has excessive functional Project Analyzer doesn’t calculate information flow complexity
complexity. High informational complexity indicates candidate (IFC) according to IEEE 982.2.
procedures for extensive testing or redesign. The IEEE 982.2 formulas for informational complexity are
Several metrics have been developed to measure information these:
flow complexity. Generally speaking, two concepts are common IFC = (fanin * fanout) ^2 weighted IFC = length * (fanin *
to all information flow metrics: fan-in and fan-out. Fan-in is the fanout) ^2
information that flows into a procedure. Fan-out is what comes IEEE 982.2 defines fan-in, fan-out and length as follows.
out of it. In addition, the concept of length is used. Length is
fanin = local flows into a procedure + number of data
the length of a procedure. The exact definition of what is in
structures from which the procedure retrieves data fanout =
fan-in, fan-out and length may vary.
local flows from a procedure + number of data structures that
Project Analyzer traditionally uses the following formulas for the procedure updates length = number of source statements
calculations of information flow. in a procedure (excludes comments in a procedure)
Fan-in IFIN = Procedures called + parameters read + global A local flow between procedures A and B exists if
variables read
1. A calls B
Informational fan-out (IFOUT) estimates the information a
2. B calls A and A returns a value to B that is used by B
procedure returns.
3. Both A and B are called by another module (procedure) that
Fan-out IFOUT = Procedures that call this procedure + [ByRef]
passes a value from A to B
parameters written to + global variables written to
These formulas differ from the formulas for IC1.
length = LLOC = logical lines of code
First, the definition of a local flow is different. IC1 takes any call
From IFIN and IFOUT, one can calculate a new metric:
from A to B as a flow into A. On the contrary, IEEE 982.2 sees
informational fan-in x fan-out.
it as a flow into B. In addition, IEEE 982.2 may take it as a
IFIO = IFIN * IFOUT flow into A if B returns a value and A uses it. What is more,
IFIO is reportedly good in predicting the effort needed for there is the case where another procedure passes a value from A
implementing a procedure, but not so good at measuring to B.
complexity. Second, IEEE 982.2 doesn’t specify if a parameter counts as a
Project Analyzer’s formula to calculate informational complexity data structure. IC1 counts every parameter read and return
is as follows: values given in parameters.
Informational complexity IC1 = LLOC x IFIO Third, IEEE 982.2 specifies that length should be calculated
The internal Complexity of a module depends on the total from number of statements, not lines. In Visual Basic, LLOC
info. flowing in the module (inflow) and the total no. of info. is often reasonably close to the number of statements, so the
flowing out of the module (outflow). Thus, the module difference shouldn’t be too large.
design complexity, Dc, is defined as, Summary
Dc = Size * (inflow * outflow) 2 The design of a system is a plan for a solution such tahat if the
where (inflow * outflow) refers to the total no. of plan is implemented, the implemented system will satisfy the
combinations of input source and output destination. requirements of the system. The goal of the design process is
to find the best possible design. The most important criteria to
Another measure of Dc is given as, judge a design are verifiability, reliability, and maintainability.
Dc = fan_in * fan_out + inflow *outflow The design activity is a two level process. The first level produces
where fan_in represents the no. of modules that call this the the system design which defines the components needed
module and fan_out is the no. of modules that are called by for the system, and how the componentts interact with each
this modules. other. The detailed design refines the system design, by
Let avg_complexity be the average complexity of the module. providing more description of the processing logic of
components and data structures, so that the design can be easily
Let std_deviation be the standard deviation in the design implemented. A design methodology is a systematic approach
complexity of the modules of the system. Then, the proposed to creating a design. Most design methodologies concentrate on
method is to classify the modules in three categories as follows: system design.
Error if Dc > avg_complexity + std_deviation
Complex if avg_complexity < Dc <avg_complexity
+ std_deviation
Normal otherwise

© Copy Right: Rai University

3E.253 37
 Exercises Notes
SOFTWARE ENGINEERING TECHNIQUES

1. Explainwhat do you mean by effort estimation?

2. Briefly explain what is
a. Data structure metrics and
b. Information flow metrics
Further Readings And Information Sources
Software process improvement has received a significant
amount of attention over the past decade. Since measurement
and software metrics is key to successfully improving the
software process, many books on SPI also discuss metrics.
Worth while additions to the literature include:
Garmus, D and D. Herron, Measuring the software process: A
Practical guide to Functional Measurements, Prentice-Hall, 1996.
Humphrey, W., Introduction to the Team Software Process,
Addison-Wesley Longman, 2000.
The news letter IT metrics (edited by Howard Rubin and
published by Cutter Information services ) presents useful
commentary on the state of software metrics in the industry.
The magazines Cutter IT Journal and software Development
have regular articles and entire features dedicated to software
metrics.
A wide variety of information sources on software related
topics and management is available on the Internet. An up-to-
date list of World Wide Web references that are relevant to
software can be found at the SEPA Web site:
http://www.mhhe.com/engcs/compsci/pressman/resources/
process-metrics.mhtml
These are some of the additional readings which would help
you to understand the concept much more.
• Fenton, N.E. and S.L. Pfleeger, Software Metrics. ITP, 1997.
• K.H. Moller and D.J. Paulish, Software Metrics. IEEE CS
Press, 1993.
• Jones, C., Applied Software Measurement. McGraw-Hill,
1991.
• Grady, R.B., Practical Software Metrics for Project
Management and Process Improvemnet. Prentice Hall, 1992.
• Marick, B., The Craft of Software Testing. Prentice Hall, 1995.
• Conte, S.D., H.E. Dunsmore, and V.Y. Shen, Software
Engineering Metrics and Models. Benjamin/Cummings,
1986.
• Lorenz, M. and J. Kidd, Object-Oriented Software Metrics.
P-H, 1994.
• B.W. Boehm, Software Engineering Economics. Prentice-
Hall 1981
• M.L. Shooman, Software Engineering. McGraw-Hill, 1983
• Dujmovic, J.J., Software Metrics. CSc 890 Reader. SFSU 1998
• IEEE 982.2 1988. IEEE Guide for the Use of IEEE
Standard Dictionary of Measures to Produce Reliable
Software. A25. Data of Information Flow Complexity. p.
112.

© Copy Right: Rai University

38 3E.253