THE FLORIDA STATE UNIVERSITY

COLLEGE OF ARTS AND SCIENCES

A MECHANISM FOR TRACKING THE EFFECTS OF REQUIREMENT

CHANGES IN ENTERPRISE SOFTWARE SYSTEMS

By

SUBHAJIT DATTA

A Thesis submitted to the

Department of Computer Science
in partial fulfillment of the
requirements for the degree of
Master of Science

Degree Awarded:
Summer Semester, 2006
 The members of the Committee approve the Thesis of Subhajit Datta defended on June
30, 2006.

Robert van Engelen

Professor Directing Thesis

Lois Hawkes
Committee Member

Alec Yasinsac
Committee Member

Approved:

David Whalley, Chair

Department of Computer Science

Joseph Travis, Dean, College of Arts and Sciences

The Office of Graduate Studies has verified and approved the above named committee members.

ii
 To Reshmi,
New and Renewing...

iii
 ACKNOWLEDGEMENTS

I take this opportunity to acknowledge the help and support of the members of my thesis
committee.
I thank my Advisor/Major Professor Dr Robert van Engelen for initiating me into
the culture of academic research. I am grateful for his encouragement and assistance
in disseminating research results to the broader academic community through conference
presentations and publications. I appreciate the independence Dr van Engelen gave me in
exploring my research interests, and his valued guidance once this thesis topic was chosen.
Dr Lois Hawkes has been the source of continuous counsel regarding the great opportu-
nities at our department’s graduate program. I thank her for taking interest in my research
and for her suggestions in improving this thesis.
I consider myself fortunate to have taken Dr Alec Yasinsac’s Software Engineering class
in my first term at the Department of Computer Science. It offered an especially insightful
view of the subject. I thank Dr Yasinsac for his valuable inputs in my research.
I also thank Mr Jeff Bauer, Mr Rajiv Kaushik, and Mr Somnath Chatterjee of FSU’s
University Computing Services (UCS) for allowing me to apply the metrics on one of UCS’s
projects as a case study.
This is also the time to remember the small band of family - my mother, brother, and
wife - and friends, Anirban, Saunak, and Arunanshu (alas, in memoriam) who were always
convinced I should return to graduate school, at times more than I was. Their conviction
won.

iv
 TABLE OF CONTENTS

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

1. PREAMBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 The Research in Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Thesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Research Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Research Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. ANALYSIS AND DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4. RELATED WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 General Idea of Software Metrics . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Metrics for Software Design and Development . . . . . . . . . . . . . . . 9
4.3 Metrics for Managing Requirements . . . . . . . . . . . . . . . . . . . . . 9
4.4 Our Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5. BACKGROUND AND ASSUMPTIONS . . . . . . . . . . . . . . . . . . . . . 11

6. METRICS - INTUITION AND DERIVATION . . . . . . . . . . . . . . . . . 13

6.1 Mutation Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2 Component Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3 Dependency Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7. APPLYING THE METRICS : METHODOLOGY AND SAMPLE CALCU-

LATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1 Why Have a Methodology ? . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2 Our Suggested Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3 Putting the Approach to Work : Sample Calculations . . . . . . . . . . . 19

8. THE UCS CASE STUDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.1 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

v
 8.2 Scope for applying the metrics . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3 Iteration 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.4 Iteration 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.5 Insights and Recommendations . . . . . . . . . . . . . . . . . . . . . . . 31
8.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

9. FUTURE WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1 The General Idea of an Automated Tool . . . . . . . . . . . . . . . . . . 34
9.2 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.3 Implementation Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 36

10.CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

APPENDIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A. FORMS AND SCREEN IMAGES OF THE UCS CASE STUDY . . . . . . . 38

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

vi
 LIST OF TABLES

7.1 M utation V alue, M utation Index and Dependency Index for requirements
of I1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2 M utation V alue, M utation Index and Dependency Index for requirements
of I2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3 M utation V alue, M utation Index for requirements of I3 . . . . . . . . . . . 24

8.1 The metrics for Iteration 1 of the UCS Case Study . . . . . . . . . . . . . . 30

vii
 LIST OF FIGURES

5.1 Abstraction of software system into layers . . . . . . . . . . . . . . . . . . . 12

6.1 A summary of the metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7.1 Putting it all together : Metrics and the methodology . . . . . . . . . . . . . 20

7.2 Variation of M I(n) across iterations for sample calculations . . . . . . . . . 25

7.3 Variation of DI(n) across iterations for sample calculations . . . . . . . . . . 26

9.1 High level design of the automated tool . . . . . . . . . . . . . . . . . . . . . 35

A.1 Paper based form 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.2 Paper based form 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A.3 Screen image 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A.4 Screen image 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

A.5 Screen image 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.6 Screen image 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

viii
 ABSTRACT

Managing the effects of changing requirements remains one of the greatest challenges of
enterprise software development. The iterative and incremental model provides an expedient
framework for addressing such concerns. This thesis proposes a set of metrics – M utation
Index, Component Set, Dependency Index – and a methodology to measure the effects
of requirement changes from one iteration to another. To evaluate the effectiveness of the
proposed metrics, sample calculations and results from a real life case study are included.
Future directions of our work based on this mechanism are also discussed.

ix
 CHAPTER 1

PREAMBLE

In this chapter we outline the broad context of this thesis. The background of the research
problem is discussed; we then present the thesis statement, a research roadmap, and list
related publications generated from this research.

1.1 The Research in Context

The study and practice of computer science stands at an interesting juncture today.
The past few decades of success with increasing memory, enhancing processing speed,
and better communication between computing units have encouraged the conception and
construction of software for more and more complex systems. We are familiar with many such
systems, indeed, we depend on them for many of our communicational, financial, healthcare,
transportational, recreational and other utilitarian needs.
However, addressing deepening complexity through software opens up newer challenges.
All complex systems of human ingenuity, barring software, - mechanical, electrical, civil
etc. - depend on the underpinnings of physical laws for the soundness of their design. As
an example, an electrical circuit, however simple or complicated, has its moorings in the
ultimate certitude of the Ohm’s and Kirchoff’s Laws !
But there are no such laws of universal validity to guide the process of software
development. Even if there are, they are yet to be discovered.
Thus software design of the present is much a subjective activity, drawing on personal
insights, experience, rules of the thumb, and sometimes apocryphal folklore of the trade.
Situations are made more difficult by the changes in requirements that invariably occur in
enterprise software systems, even as the software is being designed and built.
For our discussion, enterprise software systems are defined as software systems that

1
have one or more of the following features : support large scale business processes, need
to respond to changing user needs, bound by business and technological constraints, and
whose soundness of design and implementation is of material interest to different groups of
stakeholders.
The aim of this thesis is to demonstrate the mechanism and benefits of using metrics to
introduce a degree of objectivity in software design and development. Such objectivity facil-
itates the replication of expedient design decisions across different teams and development
projects. It also encourages the automation of certain facets of the design process, thereby
aiding the propagation of effective design idioms.

1.2 Thesis Statement

We propose a set of three metrics and a methodology for tracking the effects of changing
requirements in enterprise software systems. These metrics quantify the impact of changing
requirements on a system’s existing design and can guide design decisions to mitigate such
effects.

1.3 Research Roadmap

Research activities reported in this thesis have dealt with conception, formulation, and
verification of our ideas. We briefly describe these activities below.

1.3.1 Conception
Genesis of the metrics-oriented idea involved understanding its scope and relevance in the
software development life cycle, along with reviewing existing literature in the area.

1.3.2 Formulation
Specifying the metrics through mathematical constructs, ascribing semantics to the metric
values, and specifying the boundary conditions constituted the formulation of our ideas. We
have also suggested a process for metrics application and interpretation, and delineated the
workings of this process through sample calculations.

2
1.3.3 Verification
Verification has been done using a real life case study - a development project of Florida
State University’s (FSU) University Computing Services (UCS). Results from the case study
illustrate the use of the metrics and underscore their benefits.

1.4 Research Publications

Our following publications address topics related to this research.

1. Subhajit Datta and Robert van Engelen. Effects of Changing Requirements: A

Tracking Mechanism for the Analysis Workflow. Proceedings of the 21st Annual ACM
Symposium on Applied Computing (SAC-SE-06), vol. 2, Dijon, France, April 23–27,
2006, pp. 1739-1744.

This paper discusses the central theme of the thesis, deriving the metrics and illustrat-
ing their use [1].

2. Subhajit Datta. Crosscutting Score An Indicator Metric for Aspect Orientation.

Proceedings of the 44th ACM Southeast Conference (ACMSE 2006), Melbourne, FL,
March 10–12, 2006, pp. 204-208.

In this paper a metric is proposed to help decide which component is best modeled as
an aspect vis-a-vis a class in enterprise software design [2].

3. Subhajit Datta. Agility Measurement Index A Metric for the Crossroads of Software
Development Methodologies. Proceedings of the 44th ACM Southeast Conference
(ACMSE 2006), Melbourne, FL, March 10–12, 2006, pp. 271-273.

Agility Measurement Index is a metric to facilitate the choice of one particular

software development methodology over another; this paper presents its derivation
with directions on usage [3].

4. Subhajit Datta. Integrating the FURPS+ Model with Use Cases - A Metrics Driven
Approach. Supplementary Proceedings of the 16th IEEE Symposium on Software
Reliability Engineering (ISSRE 2005), Chicago, IL, November 7–11, 2005, pp. 4.51-
4.52.

3
This paper proposes the Fidelity Register, a metric to combine use cases with the
FURPS+ model [4].

4
 CHAPTER 2

INTRODUCTION

The iterative and incremental model is widely used for enterprise software development. The
essence of this approach involves :

• recognizing that requirement changes – even while a software system is being designed
and built – are inevitable,

• developing software through a controlled and coordinated sequence of steps going back
and forth over the development stages of requirement specification, analysis, design,
implementation and test.

Each set of such stages constitutes an iteration while the additive realization of the system’s
functionality results in its incremental development. Unlike the traditional Waterfall Model
which insists on a chimerical freezing of requirements before any subsequent activity can
start, (a condition almost never satisfied in non-trivial systems), the iterative and incremental
paradigm seeks to successfully accommodate shifting stakeholder needs. Thus the focus
revolves around efficient tracking of the changing requirements and understanding effects of
such change on the system’s design. In this thesis we present a mechanism for quantitative
evaluation of the effects of changing requirements. The following metrics are derived:

• Mutation Index

• Component Set

• Dependency Index

We also suggest a methodology for applying and interpreting the metrics. Following the
introduction, we discus the context of the metrics and review related work. We next

5
underscore the assumptions and derive the metrics. The subsequent chapter proposes a
methodology - a process wrapper around the metrics and gives sample calculations to outline
our approach. Next, results from a case study are presented to illustrate the use of metrics
in a real life software development project. Finally, we present the idea of an automated tool
based on the metrics, followed by concluding remarks.

6
 CHAPTER 3

ANALYSIS AND DESIGN

Analysis and design are vital activities in the software development life cycle (SDLC). This
is when the description of the system in the user’s language - captured in requirement
specifications and illustrated through use cases - is first sought to be interpreted in the
developer’s idiom by introducing the essential formalism that helps clarify the internal
workings of the system. “An analysis model can be viewed as a first cut at a design model
(although it is a model of its own), and thus an essential input when the system is shaped
in design and implementation” [5].
During requirement specification and use case modeling, the focus is principally on
understanding how the user derives value from the behavior of the system; each usage
scenario is deliberately viewed as atomic and independent of others. Analysis discovers the
significant perspective of interaction; how the components must collaborate to deliver not
just separate slices of functionality but one cohesive system that facilitates understanding,
implementation and maintenance. Design focusses on the nature, level, causes, and
consequences of this interactive collaboration to reach an optimal resolution of the various
demands and constraints.
The set of metrics Mutation Index, Component Set and Dependency Index, collectively
isolate the effects of changing requirements on the collaborating system components from
one iteration to another. The metrics clarify the consequences of requirement changes to the
stakeholders, adjusting project schedule and budget based on such change and discerning
the drivers of overall architecture early in the life cycle.
Metrics, requirements and their relation to system architecture have been issues of
enduring interest in the software engineering community. We briefly review some existing
work in the next chapter.

7
 CHAPTER 4

RELATED WORK

Software metrics have been the focus of research attention ever since software engineering
began addressing deepening complexity. We give below a brief overview of work that relates
to our research.

4.1 General Idea of Software Metrics

Although it is common to use the terms measure, measurement and metrics in place of
one another, some authors have underscored subtle distinctions based on natural language
usage of the words and their technical connotations [6], [7], [8]. For our discussion, we
take metrics to mean “a set of specific measurements taken on a particular item or process”
[9].Halstead’s seminal work [10] introduces metrics for source code; at that time software was
closely identified with actual programs that executed the tasks. Since then, the notion of
software has been extended to include analysis and design artifacts etc. Metrics for analysis
include the closely reviewed function point based approaches [11] - a popular technique for
estimation - and the Bang metric [12]. Card and Glass [13] have proposed software design
complexity in terms of structural complexity, data complexity and system complexity whereas
[14] identifies some important uses of complexity metrics. Fenton underscores the challenges
of trying to formulate general software complexity measures [8]. Measuring complexity has
remained an enduring theme of the study of software metrics; recent directions in research
seek to shift the onus of addressing complexity further upstream the development process,
i.e. during analysis and design.

8
 4.2 Metrics for Software Design and Development
Cohesion and Coupling are key themes in understanding software design, their measurements
have been the focus of several studies [15], [16]. Chidamber and Kemerer present a
widely referenced set of object oriented software metrics in [17], [18]. Harrison, Counsell
and Nithi have evaluated a group of metrics for calibrating object-oriented design [19].
Object oriented analysis and design (OOAD) offer significant benefits in reducing complexity
through expedient modeling of the problem domain and efficient delegation of responsibility.
COCOMO and COCOMO II [20] are primary among several models for estimating cost,
effort, and schedule of software development activity. These are useful in the planning and
execution of large software projects.

4.3 Metrics for Managing Requirements

Understanding requirements remains the first and arguably foremost activity of any software
development initiative. Several approaches have been suggested for better requirement
management, some of which are highlighted below.
Karlsson et al. [21] use the Analytical Hierarchy Process to model a cost value approach
for prioritizing requirements. An event based traceability approach is used by Cleland-
Huang et al. [22] to manage evolutionary change of development artifacts. Lam and Loomes
[23] have suggested an EVE (EVolution Engineering) framework for dealing with requirement
evolution. Robinson et al. [24] propose a set of activities codified as Requirements Interaction
Management (RIM), directed toward the discovery, management, and disposition of critical
relationships among sets of requirements.

4.4 Our Perspective

While these studies illuminate important aspects of software engineering in general and
understanding requirements in particular, it is necessary to connect the effects of changing
requirements with the analysis and design artifacts in a clear, quantified strategy. The
measurement scheme derived in the following chapters aims at capturing the effects of
requirements changes in terms of the essential continuity of a development process. Our
mechanism also provides a framework for automating the tracking of requirement changes
and their consequences.

9
 In view of the related work mentioned in this chapter, our research addresses the
unexplored questions, how do changing requirements affect existing design, and how can
the design be modified to mitigate the impact ?

10
 CHAPTER 5

BACKGROUND AND ASSUMPTIONS

During analysis and design, each requirement is scrutinized to ascertain the broad layers
of the software system that will be required for its fulfillment. (Fulfillment is intuitively
understood to be satisfying any user defined criteria to judge whether a requirement has been
implemented to her satisfaction.) At this level the software system may be segregated into
the layers of Display, P rocessing and Storage. Analysis reveals how these three categories
can combine in a feasible design to relate to a particular requirement.
We make the following assumptions:

• The context of our discussion is functional requirements. We recognize non-functional

requirements may warrant a different approach [4].

• By reviewing a particular requirement, an experienced analyst is able to recognize

whether it concerns the Display, P rocessing or Storage aspects of the system.
Display subsumes all features of the user interface and interaction facilities between
the user and the system. P rocessing is any non-trivial modification of information
performed by the system. Storage includes all activities associated with persisting
information and accessing such information. Figure 5.1 depicts this view of a software
system.

• When a requirement changes, the change can affect Display(D), P rocessing(P ) or

Storage(S); singly or collectively. Thus, between iterations, each changing require-
ment, Rn is attributed a M utation V alue M V (n) of D, P or S; or any of their
combination.

• The Display, P rocessing and Storage aspects may be associated with the three
basic stereotypes of analysis classes; Boundary, Control and Entity in object oriented

11
 Figure 5.1: Abstraction of software system into layers

analysis [5]. The following derivation is based on this mapping; for non object oriented
systems, corresponding components/modules may be substituted. The derived metrics
are independent of Object Oriented Analysis and Design (OOAD) principles.

• The metrics address requirement changes between iterations; the identification of

current, previous and next iterations is implicit in the discussion.

• System refers to the software under development along with its interfaces. Component
refers to logical/physical entities whose interaction is necessary for the working of the
system.

We proceed to the derivation of the metrics in the next chapter.

12
 CHAPTER 6

METRICS - INTUITION AND DERIVATION

Our objective is to devise metrics that can monitor the extent of change a requirement
undergoes across iterations, and the level of interaction between components fulfilling a
requirement. Thus we will be able to isolate the effects changing requirement on system
design and suggest strategies to manage such impact.
We treat a software system as a collection of discrete components and their collaborations.
Analysis helps in identifying the components, and design governs their interaction. By way
of illustration, the classes of an object oriented system are the components, whereas their
collaboration is given by the method calls issued by the instances of classes (i.e. objects) on
one another.
The metrics we now derive are meant to be heuristics for understanding and resolving
the issues related to the evolution of a software system driven by customer needs. Analysis
and design involve frequent decision making - choosing one option over another based on a
gamut of (often conflicting) inputs. These metrics introduce an element of objectivity into the
process such that the rationale behind the decisions can be clearly justified, communicated
and documented. When automated, the mechanism can also expedite the analysis and
design of complex systems with closely related requirements by reducing the manual labor
of calculating and interpreting the metrics.
For a system, let every requirement identified in the requirement workflow be uniquely
named as R1 , R2 , R3 , ..., Rn . Between iterations In−1 and In each requirement is annotated
with its M utation V alue; a combination of the symbols D, P and S. The symbols stand
for:
D ≡ Display(1)
P ≡ P rocessing(3)

13
S ≡ Storage(2)
The parenthesized numbers denote the W eights attached to each symbol. The combi-
nation of more than one symbol signifies the addition of their respective W eights, thus:
P D ≡ DP ≡ 1 + 3 = 4
SD ≡ DS ≡ 1 + 2 = 3
SP ≡ P S ≡ 3 + 2 = 5
SP D ≡ ... ≡ DP S ≡ 1 + 3 + 2 = 6
The Weight assigned to each category of components – Display, P rocessing and Storage
– is a relative measure of their complexities. (Complexity here refers to how intense
the design, implementation, and maintenance of a component are in terms of developer
effort.) P rocessing components usually embody application logic and are most design
and implementation intensive. Storage components encapsulate the access and updating of
application data stores; their level of complexity is usually lower than that of the P rocessing
components but higher than Display ones. Accordingly, Display, P rocessing and Storage
have been assigned the W eights 1, 3 and 2 respectively. Exact values of W eights may
be varied from one project to another; the essential idea is to introduce a quantitative
differentiation between the types of components.
We recognize the assignment of weights has an element of subjectivity. With the
application of these metrics to large number of projects, it is expected common strategies
will emerge for giving a particular weight to a component. However, the following derivation
of the metrics is independent of the actual values of the weights. We have chosen the 1-3
scale based on complexity, any other scale will serve just as well if it is consistently followed
for a particular system.

6.1 Mutation Index

The Mutation Index M I(n) for a requirement Rn is a relative measure of the extent to which
the requirement has changed from one iteration to another in terms of the components needed
to fulfill it.
Expressed as a ratio, the M I(n) for requirement Rn :
T he M utation V alue f or Rn
M I(n) = (6.1)
T he maximum M utation V alue

14
 Thus, if at iteration In , Requirement Rm has been assigned a M utation V alue M V (m)
= DS with reference to iteration In−1 , M I(m) is calculated as :

DS
M I(m) =
DP S
3
M I(m) =
6
M I(m) = 0.5

Intuitively, if change in Rm can only affect the Display aspects of the system, the
corresponding M I(m) = D/DP S = 1/6 = 0.17, which is less significant than the changes
affecting only P rocessing, i.e. M I(m) = P/DP S = 3/6 = 0.5 or only Storage, i.e. M I(m)
= S/DP S = 2/6 = 0.33.
At the boundary conditions, if a requirement has not changed from one iteration to
another, the M utation V alue is 0 and M I(m) = 0/6 = 0. And, if all of Display, P rocessing
and Storage aspects will be affected by changes in the requirement, the M I(m) = 6/6 = 1.
M I(m) for a requirement Rm can vary between these extreme values.

6.2 Component Set

The Component Set CS(n) for a requirement Rn is the set of components required to fulfill
the requirement.
During analysis, only the software components at the highest level are identified; they
typically undergo several cycles of refinement over subsequent workflows. The Component
Set is determined for components at their level of granularity at the analysis stage. Let the
following mutually exclusive components combine to fulfill requirement Rn :
CB ≡ Set of Boundary classes
CC ≡ Set of Control classes
CE ≡ Set of Entity classes
CX ≡ Set of helper, utility and other classes.
Then, the Component Set CS(n) for Rn is defined as,

CS(n) = CB ∪ CC ∪ CE ∪ CX (6.2)

15
 6.3 Dependency Index
The Dependency Index DI(m) for a requirement Rm is a relative measure of the level of
dependency between the components fulfilling Rm and those fulfilling other requirements of
the same system.
For a set of requirements R1 ,R2 ,...,Rm ,...,Rn−1 ,Rn , let us define,
Y = CS(1) ∪ CS(2) ∪ ... ∪ CS(n − 1) ∪ CS(n)

For a requirement Rm (1 ≤ m ≤ n), let us define,

Z(m) = (CS(1) ∩ CS(m)) ∪ ... ∪ ((CS(m − 1) ∩ CS(m)) ∪
((CS(m) ∩ (CS(m + 1)) ∪ ... ∪ ((CS(m) ∩ (CS(n))

Thus Z(m) denotes the set of components that are not only relevant to Rm but also to
some other requirement, say Rj .
Expressed as a ratio, the DI(m) for requirement Rm :

|Z(m)|
DI(m) = (6.3)
|Y |

where for a set S, |S| is taken to denote the number of elements of S. We next present
a process for applying and interpreting the metrics defined in this section.
Figure 6.1 summarizes the idea of metrics discussed in the preceding sections.

16
Figure 6.1: A summary of the metrics

17
 CHAPTER 7

APPLYING THE METRICS : METHODOLOGY

AND SAMPLE CALCULATIONS

In the last chapter, we derived the formulas for the metrics. Although the steps of derivation
brought to light certain aspects of their applicability, it is important to suggest a process for
applying and interpreting them. In this chapter, we propose a methodology for the metrics.

7.1 Why Have a Methodology ?

As software engineering has matured, ad-hoc techniques have come to be replaced by process
driven approaches. Among other benefits, process ensures consistent adherence to standards,
repeatability of success (and avoidance of failure !) and seamless integration of teams. To
facilitate understanding of the metrics’ context, we give below an algorithm for using them.
This methodology represents one way of harnessing the potential of the metrics, and can be
customized to suit specific project needs.
The main benefits of a methodology lies in streamlining application techniques for
practitioners, and summarizing the essence of our mechanism for easy dissemination. At
the core of this thesis lies the ideation and formulation of the metrics; we propose the
methodology below which illustrate the metrics use through sample calculations.

7.2 Our Suggested Approach

The M utation Index, Component Set and Dependency Index together with a methodology
for applying them comprise a mechanism to evaluate of the effects of requirement changes.
The following sequence of steps is a suggested methodology for the metrics :

1. Analyze each requirement for changes from the previous iteration.

18
 2. Annotate each requirement with its M utation V alue.

3. Compute the M utation Index for each requirement.

4. By reviewing the analysis and design artifacts, identify the high level components (CB ,
CC , CE , CX etc.) required to fulfill each requirement.

5. Compute the Component Set for each requirement.

6. Compute the Dependency Index for each requirement.

7. From the M utation Index and Dependency Index values, estimate the potential
impact of change for each requirement.

8. Refine the components to minimize the extent of such impact. If the change of a
particular requirement may have serious budget/schedule impacts, intimate the project
management/customer on the possibilities before proceeding further with development.

Perform the above steps for each iteration.

Figure 7.1 summarizes the above approach.

7.3 Putting the Approach to Work : Sample

Calculations
So far we have been concerned with the formulation of the metrics and suggesting a strategy
for their usage. It is now time to examine something in the nature of a “worked-out example”,
to appreciate how the ideas are put into practice.
The following discussion illustrates a scenario for applying the metrics and interpreting
the results. We track the effects of changing requirements across several iterations of a
sample application. This is a contrived example to aid exposition; we present a real life case
study in the next chapter.

7.3.1 The Scenario

A book reseller, referred to as Books International Inc. (BII) sells new and used books
through its retail outlets across the nation. BII also offers a premium product, autographed
books – first edition books signed by a select group of authors.

19
 Figure 7.1: Putting it all together : Metrics and the methodology

As a part of its expansion plan, BII decided to webify their business, launching an internet
store and fulfilling electronic orders. An online presence for BII is expected to result in
increased revenue from its standard as well as niche market of autographed books.
A software development organization, which we will call Next Gen Tech (NGT) has been
contracted to develop the online BII store. NGT decided to use an iterative and incremental
model for developing the system.

7.3.2 Results
We give the requirements for each iteration (In ) and calculate the corresponding values for
M I(n), CS(n) and DI(n) as per the relations derived earlier, and then interpret the results.
It is implied that the requirements are being forwarded by the stakeholders from BII; the
analysts and designers from NGT evaluate them using the metrics to gauge their effects.
Requirements for I1 :
R1 - The system will provide an online home page of BII, including a masthead with BII’s

20
logo, a static welcome message, and a hyperlink to a catalog page.
R2 - The catalog page will contain alphabetical listing of BII’s books. Initially BII will provide
a list of up to 2000 different titles on its online store. The system will allow a user to select
one/more listing(s) for purchase.
R3 - The system will record the Name, Mailing Address, Credit Card Number, Expiration
Date and Credit Card Billing Address of the user wishing to purchase book(s).
R4 - The system will verify the credit card information and provide confirmation to the user
along with total cost of the purchase (base price plus shipping and handling charges - BII will
only offer standard shipping).
In the very first iteration the requirements have not had a chance to mutate, hence the
M V (n) = 0 and M I(n) = 0 for all Rn .
A list of components identified at this time with a brief description of their functionality is
given below. These are at a very high level of abstraction, and will likely undergo refinements
in subsequent workflows. The respective component type as defined earlier is noted in
parenthesis beside the component’s name. (Here, we do not seek to justify analysis and
design decisions; focus is on the metrics values.)
List of components for I1 :
Page generator(CB ) : To generate web pages with dynamic content.
User input verifier(CB ) : To validate form inputs from user.
User info recorder(CC ) : To process user information before persisting.
Credit card verifier(CC ) : To verify credit card details.
Catalog store(CE ) : To persist book catalog information.
User info store(CE ) : To persist user information.
Total price calculator(CX ) : To calculate total price of purchase.
Based on the above, the following is derived :
Component Sets CS(n) for I1 :
CS(1) - {Page generator}
CS(2) - {Page generator,User input verifier,Catalog store}
CS(3) - {Page generator,User input verifier,User info recorder,User info store}
CS(4) - {Page generator,User input verifier,Total price calculator,Catalog store,Credit
card verifier}
The DI(n) values in Table 7.1 signifies, at a later stage, changes to R1 will have the least

21
Table 7.1: M utation V alue, M utation Index and Dependency Index for requirements of
I1

Rn M V (n) M I(n) DI(n)

R1 - 0 0.143
R2 - 0 0.429
R3 - 0 0.286
R4 - 0 0.429

impact on the overall current design while changing R2 and R4 will affect the system most.
For the next iteration I2 , the following versions of the requirements were addressed.
Requirements for I2 :
R1 - In addition to earlier requirement, the home page will present a list of authors whose
autographed editions are currently available through BII. The list will be updated by BII’s
management once a month.
R2 - In addition to earlier requirement, the catalog will provide a facility to search all of BII’s
books by author’s name and/or book title.
R3 - In addition to earlier requirement, the system will present a disclaimer that none of the
personal information of the user recorded by BII will be shared with any third party other
than credit card agencies.
R4 - Remains unchanged
As a marketing drive, all pages will have a list of five new arrivals at the top, under the
heading,“BookWorm Recommends”.
In the light of the changes, Table 7.2 shows the M utation V alue assigned to each
requirement and the corresponding M utation Index. It is worth noting, even as R4 is
declared to remain unchanged, it has a non zero M utation V alue since all pages now need
to display a list of new books.
It is apparent R2 has changed most and R3 least. The corresponding DI(n) values from
I1 suggests, absorbing the effect of R3 ’s change will be relatively easier than that of R2 ’s .
With this insight, the revised set of components required to fulfill the current requirements
are listed below.
List of components for I2 :
Page generator(CB ) : To generate web pages with dynamic content.

22
Table 7.2: M utation V alue, M utation Index and Dependency Index for requirements of
I2

Rn M V (n) M I(n) DI(n)

R1 D,P 0.67 0.22
R2 D,P,S 1 0.33
R3 D 0.17 0.44
R4 D,S 0.5 0.44

User input verifier(CB ) : To validate form inputs from user.

User info recorder(CC ) : To process user information before persisting.
Credit card verifier(CC ) : To verify credit card details.
Catalog searcher(CC ) : To provide dynamic search facility of the catalog.
New arrival identifier(CC ) : To identify new additions to the catalog.
Catalog store(CE ) : To persist book catalog information.
User info store(CE ) : To persist user information.
Total price calculator(CX ) : To calculate total price of purchase.
The italicized components are the ones that have been added to address the requirement
changes.
Guided by each requirement’s M utation V alue the components were reassigned as:
Component Sets CS(n) for I2 :
CS(1) - {Page generator, New arrival identifier}
CS(2) - {Page generator,User input verifier,Catalog searcher, New arrival identifier}
CS(3) - {Page generator, User input verifier, User
information recorder, User information store, New
arrival identifier}
CS(4) - {Page generator, User input verifier, Total price calculator, Catalog
store, Credit card verifier, New arrival identifier, User information store}
The redesign necessitated by the mutating requirements lead to a situation where R3 and
R4 are now the most dependent followed respectively by R2 and R1 . (As indicated by the
Dependency Index values for this iteration in Table 7.2.)
As each iteration lead to an incremental release of the product, BII was satisfied with
the project’s progress. Accordingly, another round of requirements were put forward.

23
 Table 7.3: M utation V alue, M utation Index for requirements of I3

Rn M V (n) M I(n)
R1 0 0
R2 D,S 0.5
R3 P,S 0.83
R4 D,P,S 1

Requirements for I3 :
R1 - Remains unchanged.
R2 - Remains unchanged.
R3 - Remains unchanged.
R4 - In addition to earlier requirement, BII will also accept checks or BookWorm Coupons
as payment for purchases. BookWorm Coupons are valid only for specific purchases. Items
that can be bought with coupons will be marked in the online listing.
This was put forward as a “minor addition” by BII’s management; after all, R4 is the
only one requirement that changes.
NGT’s analysts were quick to detect, R4 ’s change also affects R3 and has the potential
to impact the existing design as newer business rules (What qualifies a product for purchase
against coupons ? Can coupon purchases be combined with card/check purchases ? etc.) need
to be addressed and interfaces (What other user information need to be recorded for check
payments ? Which agency would verify such payments ? etc.) built. Table 7.3 quantifies
their qualms.
The M I(n) values, coupled with corresponding DI(n) values from the previous iteration
indicate that far reaching changes have to be introduced to fulfill the latest requirements.
The Technical Lead of NGT’s development team reviewed the situation with her Project
Manager, recommending the customer be notified of these implications.
We take leave of the case study now, when NGT is persuading BII for cost and timeline
revisions before further development can proceed.

7.3.3 Interpreting the Metrics

We highlight some key themes of the approach and summarize the results of this example.
The metrics are meaningful collectively, they together give a view of the process contin-

24
 1.2

0.8
I_1
0.6 I_2
I_3
0.4

0.2

0
MI(1) MI(2) MI(3) MI(4)

Figure 7.2: Variation of M I(n) across iterations for sample calculations

uum. M utation Index is calculated with reference to the previous iteration, Component Set
summarizes the design for the current iteration and Dependency Index reflects the potential
effects in the next iteration.
The metrics are essentially indicators, they are meant to facilitate better understanding
and judgment in the inherently subjective exercises of analysis and design.
Overall, the mechanism presented complements existing canons of software engineering.
For example, calculation of Dependency Index is based upon Component Set, which is
populated by component choices backed by common design considerations of cohesion,
coupling etc.
Ideally, a requirement’s low M I(n) value reflects it has not undergone significant change;
an unusually high value may indicate a need to spawn a new requirement or segregate
the original requirement into two or more parts. Similarly, low DI(n) values suggest low
interdependencies; in the limiting case we may have independent components with zero
interaction, an undesirable situation for interactive systems.
On the other hand, a high M I(n) for a requirement may not necessarily be alarming if
the corresponding DI(n) is moderate. Likewise, a high DI(n) for a requirement with a low
M I(n) does not necessitate involved redesign.
The metrics thus signify general directions in the architecture as a system is iteratively
understood, built and refined.

25
 0.5

0.4

0.3
I_1
I_2
0.2

0.1

0
DI(1) DI(2) DI(3) DI(4)

Figure 7.3: Variation of DI(n) across iterations for sample calculations

Figures 7.2 and 7.3 show the M I(n) and DI(n) variations across the iterations of the
case study.

26
 CHAPTER 8

THE UCS CASE STUDY

We are now prepared to test our strategy on a real world situation; this chapter describes a
case study.
FSU’s University Computing Services (UCS) ”works in conjunction with colleges and
departments at FSU to provide services to help meet the University’s computing and
networking goals.” As a recent development project, existing paper based Financial Aid
Application for students was migrated to an online system.

8.1 Project Overview

The project involved understanding requirements of the Financial Aid Application and
implementing them on a web based infrastructure. The development team took currently
used paper forms as the initial benchmark and built a system using database and Java code
components to deliver the same functionality. Development was marked by periodic releases
: parts of the system were incrementally released in production for business partners and
users to test and provide feedback. In Appendix A, some of the paper forms and screen
images of the online application are included to aid an intuitive understanding of the project
scenario.

8.2 Scope for applying the metrics

This particular project presents a strongly relevant scenario for applying and interpreting
the metrics. Briefly described below are certain salient points of our scope.

• The project followed an iterative and incremental development life cycle. As described
earlier our suite of metrics is aligned to such a methodology.

27
 • The project’s context - shifting an application’s functionality from a manual (paper
based) to an online (internet based) approach - introduces tendencies of repeated
requirement changes. This may happen due to the time and effort required by the users
to readjust to the new medium, as well as gradually crystallizing business directions to
fully harness the new medium’s potential. We will see such instances in the subsequent
discussion.

8.3 Iteration 1
8.3.1 Requirements
The following are the outlines of the requirements addressed in the first iteration :

• R1 – Display financial aid information to users.

• R2 – Allow users to enter enrollment period and record the information and record the
information after validation.

• R3 – Allow users to enter FSU sessions and record the information after validation.

• R4 – Allow users to enter expected summer resources and record the information after
validation.

• R5 – Display summary of the user’s enrollment status.

8.3.2 Code Components

The development team designed, built, and deployed the following components to fulfill the
above requirements.

• Display Components (Java Server Pages) – summary.jsp, summer instructions.jsp,

summer app.jsp, alerts summary.jsp

• P rocessing Components (Java classes) – RetrieveSummerData.java, SummerApplica-

tion.java, SummerApplicationUtils.java, ValidateSummerApplication.java, SaveSum-
merApplication.java

• Storage Components (Database components) – RetrieveSummerApplication,StuSummerApp

28
8.3.3 Calculating the Metrics
We now present the calculation of the metrics based on the techniques derived earlier.
The CS(n)s are calculated as :

• CS(1) – summary.jsp, RetrieveSummerData.java, StuSummerApp

• CS(2) – summer instructions.jsp, ValidateSummerApplication.java, SaveSummerAp-

plication.java, SummerApplication.java, SummerApplicationUtils.java,StuSummerApp

• CS(3) – summer app.jsp, ValidateSummerApplication.java, SaveSummerApplication.java,

SummerApplication.java, SummerApplicationUtils.java,StuSummerApp

• CS(4) – summer app.jsp,ValidateSummerApplication.java, SaveSummerApplication.java,

SummerApplication.java, SummerApplicationUtils.java,StuSummerApp

• CS(5) – alerts summary.jsp, RetrieveSummerApplication, SummerApplication.java,

SummerApplicationUtils.java,StuSummerApp

The Z(n)s are calculated as :

• Z(1) – RetrieveSummerData.java, StuSummerApp

• Z(2) – ValidateSummerApplication.java, SaveSummerApplication.java, SummerAppli-

cation.java, SummerApplicationUtils.java,StuSummerApp

• Z(3) – summer app.jsp, ValidateSummerApplication.java, SaveSummerApplication.java,

SummerApplication.java, SummerApplicationUtils.java,StuSummerApp

• Z(4) – summer app.jsp, ValidateSummerApplication.java, SaveSummerApplication.java,

SummerApplication.java, SummerApplicationUtils.java,StuSummerApp

• Z(5) – SummerApplication.java, SummerApplicationUtils.java,StuSummerApp

We observe Y to be :

• Y – summary.jsp, summer instructions.jsp, summer app.jsp, alerts summary.jsp, Re-

trieveSummerData.java, SummerApplication.java, SummerApplicationUtils.java, Vali-
dateSummerApplication.java, SaveSummerApplication.java, RetrieveSummerApplica-
tion,StuSummerApp. Thus |Y | = 11

29
 Table 8.1: The metrics for Iteration 1 of the UCS Case Study

Req M I(n) |Z(n)| DI(n)

R1 0 2 0.181
R2 0 5 0.455
R3 0 6 0.545
R4 0 6 0.545
R5 0 3 0.273

Table 8.1 summarizes the metrics calculated for iteration 1. We observe R3 and R4 have
the highest Dependency Index values (0.545 each) and R1 , the lowest of 0.181.

8.4 Iteration 2
8.4.1 Changed Requirements
The incremental release at the end of iteration 1 provided an opportunity for the users and
business partners to work with the new application and give their feedback. Expectedly,
some requirements were changed; we give below the changed version of requirements.

• R1 – Remains unchanged.

• R2 – Remains unchanged.

• R2 – Remains unchanged.

• R3 – In addition to existing functionality, remove “hard-coding” of Session A, B,

C dates; dates should be dynamically accessed to allow different dates for different
academic years.

• R4 – In addition to existing functionality, “Receiving a Tuition Waiver ?” drop down

list should have more options as supplied by the business partners.

• R5 – Remains unchanged.

8.4.2 Recalculating the Mutation Index

Based on these changes, we recalculate the metrics as :

30
 • Changes in R3 involve changes in Display(D) and Storage(S) aspects. Thus, M V (3) =
DS, leading to M I(3) = DS/DP S = 3/6 = 0.5.

• Changes in R4 involve changes in Display(D) aspects. Thus, M V (4) = D, leading to

M I(4) = D/DP S = 1/6 = 0.17.

8.5 Insights and Recommendations

In the light of applying the metrics on Iterations 1 and 2 of the UCS project, we now list
the insights gained and allied recommendations.

• At the end of Iteration 1, R3 and R4 had the highest Dependency Index values. This
suggests components fulfilling R3 and R4 had the maximum interaction with other
components of the system.

• In Iteration 2, changes in R3 and R4 cause the M utation Index values to be

M I(3) = 0.5, M I(4) = 0.17. (Other requirements remained unchanged.)

• Based on the Dependency Index values from Iteration 1 and the M utation Index
values from Iteration 2, for R3 and R4 its is apparent changes in R3 has the maximum
impact on existing system design.

• For a frequently changing requirement, it is best to have its Dependency Index value
as low as possible, such that its changes do not affect components fulfilling other
requirements. Thus, if R3 is vulnerable to more future changes, the overall design
should be modified to reduce the DI(3) value, through reassigning responsibilities
among components.

• This reorganization of design is best done during Iteration 2, to contain the effects
of changing requirements, from “rippling” across the system’s subsequent stages of
evolution.

8.6 Summary
8.6.1 Benefits of Applying the Metrics
Evidently, applying the metrics in the above scenario has helped us reach a quantitative
perspective on the interdependence of components in a system’s functionality. Such

31
understanding encourages modification of design to best address the demands of changing
requirements. It also helps estimate the degree of modification needed to existing design
and implementation to fulfill a new or revised requirement. At the core of this approach
lies the idea that a synergy among components is necessary to design and deliver a system
satisfying user needs : the metrics introduce an objective technique to monitor and improve
such synergy.

8.6.2 Pitfalls and Learnings

Applying the metrics in a real-life project, with its schedule, cost, and business constraints,
as well as the essential human element, was very helpful in viewing the approach from a
broader perspective. We briefly describe the important learnings from the case study.

• As with any process improvement endeavor, it is important to ensure all the stake-
holders clearly understand the vision, objectives, as well as the tools and techniques of
the mechanism upfront. Once, the developers, management, and the business partners
were at a consensus on the utility of our study, the execution became significantly
smoother.

• As everyone who has worked on a deadline driven project will appreciate, often the
immediacy of a deliverable reduces the priority of activities such as data collection for
the metrics. This is discouraging at times, but nonetheless a “fact of life” for enterprise
systems. To work around these situations, one option is to make the task of gathering,
calculating, and interpreting the metrics as seamless and transparent as possible. We
will discuss this angle further in the following section on automation.

• The approach outlined in the thesis assumes a sound process substratum; adherence
to healthy established, industry practices for traversing the software development life
cycle is the least projects can do to succeed. If requirements are not specified, designs
not documented, change requests not tracked - in short the project execution is just
“ad-hoc”, counting on individual heroics and heavy doses of optimism for deliverance,
it is unlikely there will be a scope for the kind of tracking mechanism we are proposing.
Fortunately, the project we monitored was using sound project management practices;
this lends further dependability to the results of the case study.

32
8.6.3 The Case for Automation
By far, the most important learning from our case study has been appreciation of the need
for automating our tracking mechanism for its wider currency.
We acknowledge the inherent subjectivity and dynamism of the software design process;
the element of a designer’s ingenuity in solving a particular problem is unlikely to be replaced
by an automated tool. The automation we envisage is an apparatus to reduce the labor of
collecting data, calculating the metrics, discovering trends, and suggesting interpretations.
These tasks are far form trivial when we consider a typical enterprise system with hundreds
of requirements. The output of the automated tool will offer the designer a discernment that
may be used to resolve deeper issues of the overall design.
In the next chapter, we present an idea of automating our mechanism.

33
 CHAPTER 9

FUTURE WORK

Towards the end of the last chapter we had highlighted how automating the collection,
calculation, and interpretation of the metrics will facilitate their wider application. We now
present the overview of such an automated tool. This is the primary direction of future work
we plan for extending the ideas presented earlier.

9.1 The General Idea of an Automated Tool

In specifying the automated tool, we first need to identify the stakeholders, the groups of
individuals who will be directly concerned with the tools use. For each group of stakeholders,
the tool will offer an interface specially suited to the utility that group seeks to derive from
the tool. We give below a listing of the different stakeholder category, along with their
probable interactions with the tool.

• Users : Represent individuals who directly work with the software system whose design
the tool will monitor/modify. For the UCS case study, Users are the students who will
use the system to apply for Summer application online. The tool will have its primary
input, i.e. instances of changing requirements from Users’ feedback. Depending on the
enterprise policy, Users may also be privy to the effects their suggested changes will
have on the systems design.

• Designers : Represent individuals directly responsible for architecture, design, and

implementation of the software system. The tool will primarily aid this group in
evaluating the effects of changing requirements and how the system needs to respond
to such change while preserving the spirit of its architecture. The tool will provide
vital insights to the Designers; upon which broad design decisions can be taken.

34
 Users

UI Calculator

Designers
Request Rules
UI Broker Engine Database

Interpreter
Managers UI

J2EE infrastrcuture

Eclipse platform

Figure 9.1: High level design of the automated tool

• Managers : Represent individuals in charge of the assuring the system meets the desired
business needs within constraints of time, budget, and other political parameters. The
tool will offer them quantified notions – “numbers” in managerial parlance – of the level
of impact that changing requirements may have on existing and envisaged execution
of the system. This is a vital aspect in the long term health of an enterprise software
system, often the chasm between technical and managerial understanding of the same
situation causes much difficulty for all stakeholders.

Initially, the above three stakeholder groups have been identified along with their demands
from the tool; other groups may be accommodated if the need arises.

9.2 Design Overview

We outline the broad design philosophy of the tool with reference to Figure 9.1.
As explained above, the tool offers specific User Interfaces (UI) for the different stake-

35
holders - Users, Designers, and Managers. The Request Broker component accepts requests
from these different groups, interacts with the Calculator and Interpreter components, and
delivers the response back. The Calculator and the Interpreter calculate the metrics, and
interpret their semantics in a given context through interaction with the Rules Engine. The
Rules Engine, specifies the “intelligence” of the tool, based on predefined (and modifiable)
design canons for the specific domain of interest, and interacts with a database to access
persisted data.

9.3 Implementation Perspective

The code components will be developed on the Java 2 Enterprise Edition (J2EE) infrastruc-
ture, which will utilize the Eclipse platform. The Request Broker is likely to developed as
an Eclipse Plugin to aid its seamless integration with other open source analysis and design
tools.
To aid a standardized specification and documentation, we also seek to integrate the
metrics within the latest Unified Modeling Language (UML) version 2.0 artifacts. The
Eclipse framework’s support for UML 2.0 will be leveraged towards this end.

36
 CHAPTER 10

CONCLUSION

The objective of this thesis was to examine the effectiveness of metrics in the analysis
and design of enterprise software systems. Over the preceding chapters we derived the
metrics, M utation Index, Component Set, and Dependency Index and illustrated their
utility through sample calculations. A real life case study of a UCS software development
project elucidated the benefits gained from applying the metrics and using the results to
suggest design improvements. In addition, we have also outlined the notion of a software
tool to automate some aspects of the metrics’ workings.
This discussion consummately establishes the key idea of the thesis : expedient conception
and systematic application of metrics can greatly assist the genesis of sound design paradigms
for enterprise software systems, especially in the event of changing requirements.
We expect to carry forward our work in future studies.

37
 APPENDIX A

FORMS AND SCREEN IMAGES OF THE UCS

CASE STUDY

Figures A.1 and A.2 depict the paper forms that were converted to the online application
in the UCS project. Figure A.3, A.4, A.5, and A.6 are screen images from the converted
web-based application.

38
Figure A.1: Paper based form 1

39
Figure A.2: Paper based form 2

40
Figure A.3: Screen image 1

41
Figure A.4: Screen image 2

42
Figure A.5: Screen image 3

43
Figure A.6: Screen image 4

44
 REFERENCES

[1] Subhajit Datta and Robert van Engelen. Effects of Changing Requirements: A Tracking
Mechanism for the Analysis Workflow. Proceedings of the 21st Annual ACM Symposium
on Applied Computing (SAC-SE-06), vol. 2, Dijon, France, April 23–27, 2006, pp. 1739-
1744. 1

[2] Subhajit Datta. Crosscutting Score An Indicator Metric for Aspect Orientation.
Proceedings of the 44th ACM Southeast Conference (ACMSE 2006), Melbourne, FL,
March 10–12, 2006, pp. 204-208. 2
[3] Subhajit Datta. Agility Measurement Index A Metric for the Crossroads of Software De-
velopment Methodologies. Proceedings of the 44th ACM Southeast Conference (ACMSE
2006), Melbourne, FL, March 10–12, 2006, pp. 271-273. 3

[4] Subhajit Datta. Integrating the FURPS+ Model with Use Cases - A Metrics Driven
Approach. Supplementary Proceedings of the 16th IEEE Symposium on Software
Reliability Engineering (ISSRE 2005), Chicago, IL, November 7–11, 2005, pp. 4.51-4.52.
4, 5

[5] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process.
Addison-Wesley, 1999. 3, 5

[6] R.S. Pressman. Software Engineering : A Practitioner’s Approach, Fifth Edition.

McGraw-Hill, 2001. 4.1
[7] A.L. Baker, J.M. Bieman, N. Fenton, and D.A. Gustafson. A Philosophy for Software
Measurement. The Journal of Systems and Software, April 1990. 4.1
[8] N. Fenton. Software Measurement : A Necessary Scientific Basis. IEEE Transactions on
Software Engineering, vol. 20, no. 3, March 1994. 4.1
[9] E.V. Berard. Metrics for Object-Oriented Software Engineering.
http://www.toa.com/pub/moose.htm, 1998. 4.1

[10] M. Halstead. Elements of Software Science. North-Holland, 1977. 4.1

[11] A.J. Albrecht. Measuring Application Development Productivity. Proceedings of the
IBM Application Development Symposium, Monterey CA, October 1979. 4.1

[12] T. DeMarco. Controlling Software Projects. Yourdon Press, 1982. 4.1

45
[13] .N. Card and R.L. Glass. Measuring Software Design Quality. Prentice-Hall, 1990. 4.1

[14] T.J. McCabe and A.H. Watson. Software Complexity. Crosstalk, vol. 7, no. 12,
December 1994. 4.1

[15] J.M. Bieman and L.M. Ott. Measuring Functional Cohesion. IEEE Transactions on
Software Engineering, vol. 20, no. 8, August 1994. 4.2

[16] H. Dhama. Quantitative Models of Cohesion and Coupling in Software. The Journal of
Systems and Software, vol. 29, no. 4, April 1995. 4.2
[17] S.R. Chidamber and C.F. Kemerer. Towards A Metrics Suite for Object Oriented
Design. OOPSLA ’91, 1991. 4.2

[18] S.R. Chidamber and C.F. Kemerer. A Metrics Suite for Object Oriented Design. IEEE
Transactions on Software Engineering, vol. 20, no. 6, June 1994. 4.2

[19] R. Harrison, S.J. Counsell and R.V. Nithi. An Evaluation of the MOOD Set of Object-
Oriented Metrics. IEEE Transactions on Software Engineering, vol. 24, no. 6, June 1998.
4.2

[20] B. Boehm, et al. COCOMO - Construcive Cost Modeling.

http://sunset.usc.edu/research/COCOMOII/. 4.2

[21] J. Karlsson and K. Ryan. A Cost-Value Approach for Prioritizing Requirements. IEEE
Software, September/October 1997. 4.3

[22] J. Cleland-Huang and C. Chang. Event-Based Traceability for Managing Evolutionary

Change. IEEE Transactions on Software Engineering, vol. 29, no. 9, September 2003. 4.3

[23] W. Lam and M. Loomes. Requirements Evolution in the Midst of Environmental

Change : A Managed Approach. 2nd Euromicro Conference on Software Maintenance
and Reengineering (CSMR’98), 1998. 4.3

[24] W. Robinson, S. Pawloski and V. Volkov. Requirements Interaction Management. ACM

Computing Surveys, vol. 35, no. 2, June 2003. 4.3

46
 BIOGRAPHICAL SKETCH

Subhajit Datta

Subhajit Datta joined graduate studies at the Department of Computer Science (CS), Florida
State University (FSU) in Spring 2005. He has worked as a software engineer with IBM
Global Services in roles of Release Manager, Technical Lead, Business Systems Analyst, and
Application Programmer. One of Subhajit’s papers was published as an Intellectual Capital
in the IT Process Model knowledge network of IBM’s ICM AssetWeb and recommended for
patent filing evaluation.
Subhajit has a Bachelor of Electrical Engineering degree from Jadavpur University,
Calcutta (Kolkata), India. He is a IBM Certified Specialist for Rational Unified Process,
and has additional certification in Object-Oriented Analysis and Design with UML.
Subhajit’s research interests include requirements/specifications, design tools and tech-
niques, metrics, and software architecture. Since joining CS, FSU, Subhajit has presented
and published four papers in IEEE or ACM organized conferences.
Reading, writing, and travel are among Subhajit’s interests.

47