validating software evolution of agile projects using...

Validating Software Evolution of Agile Projects Using

Lehman Laws

A DISSERTATION

SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENT FOR

THE AWARD OF THE DEGREE

OF

MASTER OF TECHNOLOGY

IN

COMPUTER SCIENCE AND ENGINEERING

SUBMITTED BY

Gurpreet Kour

Roll No. 11203037

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

DR. B R AMBEDKAR NATIONAL INSTITUTE OF TECHNOLOGY

JALANDHAR – 144011, PUNJAB (INDIA)

DECEMBER, 2014

i

DR. B R AMBEDKAR NATIONAL INSTITUTE OF TECHNOLOGY, JALANDHAR

CANDIDATE DECLARATION

I hereby certify that the work, which is being presented in the dissertation, entitled “Validating

Software Evolution of Agile Projects Using Lehman Laws” by “Gurpreet Kour” in partial

fulfillment of requirements for the award of degree of M.Tech. (Computer Science and

Engineering) submitted in the Department of Computer Science and Engineering at Dr. B R

Ambedkar National Institute of Technology, Jalandhar is an authentic record of my own work

carried out during a period from January, 2014 to December, 2014 under the supervision of Dr.

Paramvir Singh. The matter presented in this dissertation has not been submitted by me in any

other University/Institute for the award of any degree.

Gurpreet Kour

This is to certify that the above statement made by the candidate is correct and true to the best of

my knowledge.

Dr. Paramvir Singh (Supervisor)

Assistant Professor

Department of Computer Science & Engineering

DR. B. R. Ambedkar NIT, Jalandhar

The M.Tech (Dissertation) Viva-Voce examination of Gurpreet Kour, Roll No. 11203037, has

been held on ____________ and accepted.

Supervisor

Signature of External Examiner

Dr. Renu Dhir

Head of Department

Department of Computer Science & Engineering

DR. B R Ambedkar NIT, Jalandhar

ii

ACKNOWLEDGEMENT

Foremost, I would like to express my gratitude to my supervisor Dr. Paramvir Singh, Assistant

Professor, Department of Computer Science and Engineering, DR B R Ambedkar National

Institute of Technology, Jalandhar for the useful comments, remarks and engagement through the

learning process of this master thesis. I cannot thank him enough for his tremendous support and

help. He motivated and encouraged me throughout this work. Without his encouragement and

guidance this project would not have materialized. I consider myself extremely fortunate to have a

chance to work under his supervision. In spite of his busy schedule, he was always approachable

and took his time off to guide me and gave appropriate advice.

I also wish to thank whole heartily all the faculty members of the Department of Computer

Science and Engineering for the invaluable knowledge they have imparted on me and for teaching

the principles in most exciting and enjoyable way. I also extend my thanks to the technical and

administrative staff of the department for maintaining an excellent working facility.

I would like to thank my family for their continuous support and blessings throughout the

entire process, both by keeping me harmonious and helping me putting my pieces together. I also

like to thank all my batch mates for the useful discussions, constant support and encouragement

during whole period of the work.

Last but not the least, I would like to thank almighty GOD for giving me enough strength

and lifting me uphill this phase of life.

Gurpreet Kour

iii

ABSTRACT

The primary focus in software engineering involves issues related to upgradation, migration and

evolution of existing software systems. Software evolution is a continuous process which includes

activities like enhancement, adaptation or fixing, that occurs after the operational release of the

software to the users. Due to the increase in use of computers in all aspects of human activity,

collectively or individually, and the important role that computers play in many of the applications,

software evolution is becoming an important challenge. Software evolution is the study of the

processes of system change over its lifetime which encompasses development and maintenance.

Software maintenance refers to modifying a program after it has been put into use, and changes are

implemented by modifying existing components and adding new components to the system.

While maintenance refers to an activity that takes place at any time after the new

development project is implemented, the software evolution is defined as examining the dynamic

behaviour of systems, i.e., how they change or evolve over time. Lehman and Belady first applied

the term evolution of software in the 1970s and since then most investigators have used that term

to refer to the long and broad view of change in the software systems. However, it is not surprising

that empirical research on software evolution is scarce. Off these, most of the empirical research

on software evolution is applied on software developed using traditional development methods.

We perform an empirical study to better understand the evolution of software systems

developed using agile development methodology. We evaluated a selected set of software metrics

for three agile projects and used this metrics data to compare these projects within the context of

Lehman’s laws of software evolution.

iv

TABLE OF CONTENTS

CERTIFICATE i

ACKNOWLEDGEMENT ii

ABSTRACT iii

LIST OF FIGURES vii

LIST OF TABLES viii

LIST OF ABBREVIATIONS ix

CHAPTER-1

INTRODUCTION

1.1 Software Evolution 01

1.1.1 Importance of Software Evolution 02

1.1.2 Software maintenance and Software change 02

1.2 Laws of Software Evolution 03

1.3 Software Development Methodologies 05

1.3.1 Traditional Software Development Methodology 06

1.3.2 Agile Development Methods 07

1.3.3 Traditional Software Versus Agile Development Methodology 09

1.4 Two Agile Development Methodologies 09

1.4.1 Extreme Programming 10

1.4.2 SCRUM 11

1.5 Software Metrics 13

1.5.1 Types of Software Metrics 13

1.5.2 Measurement Scale 13

1.5.3 Design Metrics 14

1.6 Motivations 14

1.7 Research Objectives 15

1.8 Chapter Summary 15

v

CHAPTER-2

LITERATURE SURVEY

2.1 Software Evolution 17

2.2 Software Evolution in Agile Software Development Methodology 20

2.3 Traditional and Object Oriented Metrics 20

2.3.1 Traditional Metrics 21

2.3.2 Object Oriented Metrics 22

2.3.3 Other Metrics 24

2.4 Metrics Selected for Analysis 24


CHAPTER-3

METHODOLOGY AND IMPLEMENTATION

3.1 Sample Application 26

3.1.1 FlossAr 26

3.1.2 StudentLancer 27

3.1.3 MultiLevel Marketing Software 28

3.1.4 Tools Used for the projects 28

3.2 Methodology 29

3.3 Tools Used 30

3.3.1 CKJM extended 30

3.3.2 PHP_Depend 32

3.3.3 Microsoft Excel 33

3.4 Techniques used for Analysis 34


CHAPTER-4

RESULTS AND ANALYSIS

4.1 Analysis Techniques and Results 35

4.1.1 Continuing Growth and Continuing Change 35

4.1.2 Increasing Complexity 36

vi

4.1.3 Self Regulation and Feedback 39

4.1.4 Conservation of Familiarity 42

4.1.5 Declining Quality 43

4.2 Result Summary 43


CHAPTER-5

CONCLUSIONS AND FUTURE WORK

5.1 Conclusions 46

5.2 Future Work 47

REFERENCES

vii

LIST OF FIGURES

Figure 1.1 Traditional Approach of Software Development 06

Figure 1.2 Methods of Agile Software Development 09

Figure 1.3 Extreme Programming Practices 10

Figure 1.4 Scrum Process Flow 12

Figure 3.1 Methodology Followed 29

Figure 3.2 Screenshot of CKJM Extended 31

Figure 3.3 Screenshot of PHP_Depend 32

Figure 3.4 Screenshot of Microsoft Excel 33

Figure 4.1 Growth and Change for projects 1, 2 and 3 35

Figure 4.2 Law of Increasing Complexity measured by CBO per release 36

Figure 4.3 Law of Increasing Complexity measured by Cohesion for project 1 37

Figure 4.4 Increasing Complexity for project 2 and 3 38

Figure 4.5 Growth curve for average RFC for project 2 and 3 38

Figure 4.6 Growth curve for average WMC for project 2 and 3 39

Figure 4.7 Duration of Iterations for Project MIM during release 3 40

Figure 4.8 Duration of Iterations for Project StudentLancer during release 2 40

Figure 4.9 Change in files during Sprint for project MIM 41

Figure 4.10 Change in files during Sprint for project StudentLancer for release 2 41

Figure 4.11 Change in files during Sprint for project StudentLancer for release 3 42

viii

LIST OF TABLES

Table 1.1 Values of Agile Software Development 07

Table 1.2 Traditional Software Vs. Agile Development Methodology 09

Table A.1 Experimental Results: Metric Data of MLM 53

A.1.1 Multi-Level Marketing Software 53

Table A.2 Experimental Results: Metric Data of StudentLancer 54

A.2.1 StudentLancer Version 1 54



Table A.3 Experimental Results: Metric Data of FlossAr 60

A.3.1 FlossAr Version 1.0 60



ix

LIST OF ABBREVIATIONS

ADM Agile Development Methodology

AMC Average Method Complexity

CAM Cohesion Among Methods of Class

CBM Coupling Between Methods

CBO Coupling Between Objects

DIT Depth of Inheritance Tree

EXEC Executable statements

IC Inheritance Coupling

jAPS Java Agile Portal System

LCOM Lack of Cohesion in Methods

LCOM3 Lack of Cohesion in Methods Henderson-Sellers version

LOC Lines of Code

MLM Multi-Level Marketing Software

NCNB Non-Comment Non-Blank

NOC Number of Direct Child

NPM Number of Public Methods for a Class

RFC Response for a Class

XP Extreme Programming

CHAPTER-1

INTRODUCTION

In recent years, the growth in large scale software development industry has suddenly picked

up pace to become a „driving force‟. Due to its profound impact on world‟s economy and

society, it has grabbed the attention of researchers. In this environment, the role of careful

empirical studies as the basis for improving software maintenance processes, methods and tools

is highlighted. One of the most important processes that merits empirical evaluation is software

evolution. Software needs to evolve in order to be used for a longer period. The changes

corresponding to corrective, preventive, adaptive and perfective maintenance leads to software

evolution [1]. Software evolution takes place only when the initial development was successful.

The goal is to adapt the application to the ever changing user requirements and operating

environment. Software is not prone to wear and tear but still may become useless if not revised

in response to ever changing user requirements. Lehman et al has done extensive research on

evaluation of large and long lived software [2]. Most of the research work on software

evolution till date have focused on traditional or open source methods, and Lehman‟s Law of

software evolution have been interpreted and evaluated in the context of these methods. These

laws, dealing with continuous change and growth, self-regulation and conservation of

organisational stability and familiarity, feedback system, increasing complexity and declining

quality, of systems need to be examined on projects following agile methods, to see if they

continue to hold true across the agile lifecycle. This chapter describes the context and the main

contributions of this thesis, thus explaining how we contribute to that goal. The first chapter is

organized as follows: The concept of software evolution is treated in section 1.1. Section 1.2

provides a comprehensive description of software evolution Lehman‟s laws. In Section 1.3,

software development methodologies are explained. Section 1.4 provides an overview of main

methods of agile processes. Section 1.5 explains the software metrics. Section 1.6 discusses the

motivations which formed the basis of this work. The objectives of research are stated in

Section 1.7. This chapter ends with chapter summary in Section 1.8.

1.1 Software Evolution

Software Evolution is defined as “the dynamic behaviour of programming systems as they are

maintained and enhanced over their life times” [3]. The software evolution takes place because

of the following reasons:

i. Software change is inevitable as new requirements emerge when the software is

used.

Introduction

Page 2

ii. The business environment changes, in business terms, the software is being

evolved because it is successful in the marketplace; revenue streams are buoyant,

user demand is strong, the development atmosphere is vibrant and positive, and

the organization is supportive. Return on investment is excellent

iii. Error or bugs must be repaired

iv. New equipment is added to the system

v. The performance or reliability of the system may have to be improved.

1.1.1 Importance of Software Evolution

Software evolution occurs because of the following requirements:

Organisations have huge investments in their software systems as software is

critical business assets.

To maintain the value of these assets to the business, they must be changed and

updated.

The majority of the software budget in large companies is devoted to evolving

software rather than developing new software.

1.1.2 Software maintenance and Software Change

Software evolution refers to the phenomenon of software maintenance and software change.

The environment where software has to operate changes over time and software must adapt to

the changing environment. The software does not change by itself but changed by the

development and maintenance teams.

Software Maintenance is defined as “the correction of errors and the implementation of

modifications needed to allow an existing system to perform new tasks and to perform old ones

under new conditions [4]. The objective is to modify the existing software product while

preserving its integrity.

Software change is the basic operation of software evolution. The change is a process that

either introduces new requirements into an existing system, or modifies the system if the

requirements were not correctly implemented, or moves the system into a new operating

environment. A request for change often originates from the users of the system, and may have

a form of a „bug report‟ or a request for additional functionality. It is usually expressed in terms

of the application domain concepts. A key problem for organisations is implementing and

managing change to their existing systems.

Introduction

Page 3

1.2 Laws of Software Evolution

Lehman et al. inferred that the software systems must evolve otherwise there is risk of losing

market share to competitors [2]. There are various evolution laws to study the evolution of the

software systems. The laws of software evolution refer to a series of laws formulated by

Lehman and Belady in 1974 with respect to software evolution [5]. Lehman categorizes all

software systems into three classes of programs [6].

i. S-Type (Specified): S-type programs are derivable from a static specification and

can be formally proven as correct or not.

ii. P-Type (Problem solving): P-type programs attempt to solve problems that can

be formulated formally, but which are not computationally affordable. Therefore

the program must be based on heuristics or approximations to the theoretical

problem.

iii. E-Type (Evolutionary): E-type software refers to “software solving a problem or

addressing an application in the real world and its attributes.” E-type programs are

reflection of human processes, societal activity or of a part of the real world.

These kind of programs try to solve an activity that somehow involves people or

the real world. E-type programs are inherently even more change prone.

The laws also suggest that over the period, due to changes and growth, software system

become complex and difficult to add new functionalities to it. The software evolution, which is

the continual process of change is required to keep the software up-to-date with the changing

operational domain. Continual software change is needed for the stakeholders to remain at an

acceptable level in a changing world.

i. Continuing Change (1974): E-type systems must be continually adapted else

they become progressively less satisfactory. According to this law, the evolving

software has to adapt to the changing environment. The change in usage

environment may include changes like bug fix exercise or as a preventive

maintenance activity or addition of some functions or any other activity which

will increase the size of software leading to growth. Continuous change is the

result of feedback pressures caused by mismatch between the software and its

operational domain. Evolution is achieved in a feedback driven and controlled

maintenance process. If the consequent pressure for evolution to adapt to the new

situation is resisted the degree of satisfaction provided by the system in execution

declines with time.

Introduction

Page 4

ii. Increasing Complexity (1974): As an E-type system evolves its complexity

increases unless work is done to maintain or reduce it. This law may be an

analogue of the second laws of thermodynamics or an instance of it. It is generally

perceived that growth in the system adds to increase in complexity but if the

appropriate changes are made then the evolution process might not show increase

in complexity.

iii. Self Regulation (1974): E-type system evolution process is self regulating with

distribution of product and process measures close to normal. According to this

law, the growth rate is regulated by maintenance process. There is a balance

between what is desired to be changed and what can actually be achieved. In order

to have a smooth evolution process, the limitations on the growth rate should be

accepted.

iv. Conservation of Organisational Stability (1980): The average effective global

activity rate in an evolving E-type system is invariant over product lifetime.

Evolution process of software conserves the organizational stability. The work

rate of an organization evolving a large software tends to remain constant. This

means that it is hard to change the staff who has been working on evolving

software.

v. Conservation of Familiarity (1980): As an E-type system evolves all associated

with it, developers, sales personnel, users, for example, must maintain mastery of

its content and behaviour to achieve satisfactory evolution. Excessive growth

diminishes that mastery. Hence the average incremental growth remains invariant

as the system evolves. This law postulates that the incremental growth or growth

rate trend of E-type systems is constrained by the need to maintain familiarity.

Both the developers and users need to maintain familiarity with the system as it

evolves between the releases. A huge change that might cause lack of familiarity

of staff members involved with the evolving software is avoided. For small

changes the familiarity of software is easily achieved by the personnel involved

with the software. Hence the average incremental growth remains constant as the

software evolves.

vi. Continuing Growth (1980): The functional content of E-type systems must be

continually increased to maintain user satisfaction over their lifetime. According

to this law, the functionality provided by the software should continually grow so

as to provide user satisfaction over longer period. The increase in the functionality

Introduction

Page 5

being provided by the software can be interpreted as increase in the size of code.

Growth of evolving software, in terms of functionality, can be measured by

observing the change in the lines of code (LOC) and the change in the number of

methods.

vii. Declining Quality (1996): The quality of E-type systems will appear to be

declining unless they are rigorously maintained and adapted to operational

environment changes. According to this law, the uncertainty increases with the

time unless successful attempts to detect and rectify the embodiment are taken as

part of the maintenance activity. As time elapses and the user community become

more perceptive and expectant, alternative products become available, the criteria

of acceptability and satisfaction change. The quality of a product must relate to

user satisfaction. Hence, the quality of a software system declines with time and

information feedback plays a key role.

viii. Feedback System (first stated in 1974, formalised as law in 1996): E-type

evolution processes constitute multi-level, multi-loop, multi-agent feedback

systems and must be treated as such to achieve significant improvement over any

reasonable base. Feedback plays a very important role in software evolution. All

seven laws of software evolution is the result of feedback system. Agents can be

corporate managers, process managers, product managers, software architects,

software developers, software testers and users. The loops are the code reviews

and the level is the parallel versions.

1.3 Software Development Methodologies

Software has been part of modern society for more than 50 years. There are several software

development methodologies in use today. Some companies have their own customized

methodology for developing their software but the majority of organizations following two

kinds of methodologies: heavyweight and lightweight. Heavyweight methodology, also

considered as traditional approach of software development or plan driven approach is a

conceptual model used to develop information systems with well-defined phases like user

requirements, design and architecture, development and coding, quality assurance and software

testing, implementation, maintenance and support. At the other end of the continuum, the

lightweight methodologies also known as agile methodology, have gained significant attention

from the software engineering community in the last few years.

Introduction

Page 6

1.3.1 Traditional Software Development Methodology

Traditional software development is based on sequential approach in which coding and testing

are carried out after requirement capture and design, followed by integration and system-level

testing. This plan based approach was introduced to provide a structured approach to large

scale development. In the waterfall model, the project management can rely on an upfront plan,

and possible deviations from the plan are easy to detect. Software engineering includes various

plan-driven or predictive life cycle models such as waterfall, spiral, rapid prototyping where

project is executed based on a plan which we freeze upfront before starting the project, iterative

life cycle model where development happens in iterations that encompass the activities of

requirements analysis, design, coding and testing and incremental life cycle model where

project delivery is divided into parts-analyse, design, code, test and deliver product (release).

Figure 1.1: Traditional Approach of Software Development

There are known disadvantages of traditional, plan driven models. In large products

especially, the sequential order of development has resulted into problems in integration and

testing the overall system at the end [7]. When the world around us is changing fast,

requirements from the end user are also changing fast as well. With the traditional software

development model, it usually takes a long time from the initial requirement capture before the

actual software is available for the end user, and it is difficult to implement changes in later

Requirements

Design and

Architecture

Development

and Coding

Quality Assurance

& Software Testing

Implementation

Maintenance &

Support

Introduction

Page 7

phases. This can lead to a situation where the customers‟ current needs are not being addressed

at the end of the project, and as a result, many of the features implemented are not used.

To be able to respond to changes faster, and to develop software systems according to the

end user needs while the need still exists, many companies are searching for a solution with

agile methods. The organization-wide change process, in which agile practices are taken into

use to enable an agile software development mode of working, is called the agile

transformation. Successful transformation from plan-based to agile software development have

been reported and there are frameworks designed to guide organizations in the agile

transformation [8] [9].

1.3.2 Agile Development Methods (ADM)

Agile development is a term that was derived from the Agile Manifesto, which was written in

2001 by a group of 17 people [10]. The Agile Manifesto established a common set of

overarching values and principles for all of the individual agile methodologies at the time. The

formation of the Agile Alliance in 2001 and the publication of the Agile Manifesto formally

introduced agility to the field of software development. Agile software development has

challenged the traditional ways of delivering software as it provides a very different approach

to software development. The Manifesto for Agile Software Development uncover better ways

of developing software by doing it and helping others to do it through following values:

Individuals and Interactions Over processes and tools

Working software Over comprehensive documentation

Customer collaboration Over contract negotiation

Responding to change Over following a plan

Table 1.1: Values of Agile Software Development [10]

The Agile Manifesto presented and industry-led vision for a profound shift in software

development through 12 principles [10]. The twelve principles of agile software development

are following:

i) The highest priority is to satisfy the customer through early and continuous

delivery of valuable software

ii) The welcoming of changing requirements, even late in development, for the

benefit of the customer‟s competitive advantage

iii) Frequent delivery of working software, the release cycle ranging from a couple of

weeks to a couple of months, with a preference for a shorter timescale

iv) Daily collaboration of business people and developers throughout the project

Introduction

Page 8

v) Building of projects around motivated individuals by offering them an appropriate

environment and the support they need, and trusting them to get the job done

vi) Emphasis on face-to-face conversation for conveying information and within a

development team

vii) Working software is the primary measure of progress

viii) Agile processes promote a sustainable development pace for the sponsors,

developers, and users

ix) Continuous attention to technical excellence and good design enhances agility

x) Simplicity is essential for maximising the amount of work not having to be done

xi) Self-organising teams give best results in terms of architectures, requirements, and

designs

xii) Regular reflection of teams on how to become more effective, and tuning and

adjusting its behaviour accordingly.

The principles of agile software development can be considered as fundamental

ideologies that should be embedded in the practices of any software development method

claiming to be agile.

Agile development methods (ADM) are characterized by self-organizing, incremental

(small software releases with rapid development cycles), straightforward (the method itself is

easy to learn and to modify), adaptive (the ability to make and react to last moment changes),

earlier testing, quick delivery which increases cooperative collaboration, communication (a

close customer and developer interaction) and coordination by delivering high quality products

to the customer. Agile development methods helps software development community reduces

their effort in development [11] [12].

Early implementations of lightweight methods include Scrum (1995), Crystal Clear,

Extreme Programming (1996), Adaptive Software Development, Feature Driven Development,

and Dynamic Systems Development Method (1995). These are now typically referred to as

agile methodologies, after the Agile Manifesto published in 2001. Agile processes have reached

a considerable interest both in industry and academia due to a proven track record in delivering

complex software on time and within the prescribed budget. Despite the encouraging results

reported by the agile methods community, there is still a need for empirically understanding the

quality/speed trade-offs in real life projects when following agile principles. The lifecycle of

agile processes aimed at minimizing the number of activities performed and the quality of

artifacts produced in order to deliver working software to client quickly.

Introduction

Page 9

Figure 1.2: Methods of Agile Software Development [13]

1.3.3 Traditional Software Methodology Versus Agile Development Methodology

There is huge difference between traditional software methodology and agile development

methodology. Some of the most important characteristic differences are summarized below:

Traditional Software Methodology Agile Development Methodology

The systems are fully specifiable, predictable

and are built through extensive planning.

High-quality adaptive software is developed by

small teams using the principles of continuous

design improvement and testing based on rapid

feedback and change.

It emphasizes large scale planning It emphasizes flexibility

Formal communications and documentation Informal collaboration and working code

Plan driven approach Execution driven approach

Technology driving people People driving technology

Final product is delivered at the end of the

project

Incremental delivery of products

Communication only at the start of the project.

User explicit documented knowledge

Improves customer communication,

collaboration and coordination. Interpersonal

knowledge and continuous communication.

Face-to-face communication.

Planning driven project Customer driven project

Predictability, stability Quick response to change

Formalized documented requirement

Requirements in the form of user stories and test

cases.

Requirements in the form of user stories and test

cases.

Changes not acceptable Changes acceptable

People are comfortable when there are clear

policies and procedures that define their role in

the enterprise.

Embrace the philosophy according to which

programming is an art rather than a technic.

Table 1.2: Traditional Software Methodology Vs. Agile Development Methodology

1.4 Two Agile Software Development Methodologies: Extreme Programming (XP) and

SCRUM

The most widely used agile methodologies are Extreme Programming (XP) and Scrum. Both

methodologies share iterative approach of development.

Introduction

Page 10

1.4.1 Extreme Programming (XP)

Extreme programming (XP) is well known agile method developed by Beck [14]. Extreme

programming focuses on delivering immediate business value to the customer. The extreme

programming process can be characterized by the short development cycles, incremental

planning, evolutionary design and its ability to response to changing business needs. The

method is built around practices like planning game, small releases, use of metaphors to

describe business situations, simple design, testing, refactoring, pair programming, collective

code ownership, continuous integration, 40-hours work week and on-site customer [15].

Figure 1.3: Extreme Programming Practices

Extreme programming (XP) methodology defined following agile practices and these

practices have been applied for the development of sample projects:

Pair Programming: In this practice, all the development tasks were assigned to

two developers (one pair). The one developer writes the code while the other

reviews each line of code. At intervals, the developers can swap the roles.

Introduction

Page 11

Refactoring: Refactoring is the restructuring process to improve hierarchies and

abstractions.

Stand Up Meeting: A stand up meeting is a daily meeting held every day before

the start of the work to organize the daily activities and to provide a status update

to the team members.

On Site Customer: A customer‟s representative was always available to the team

for fast and effective communication.

Continuous Integration: The written code was integrated several times a day to

ensure that all the components work together correctly.

Collective code ownership: The code repository was freely accessible to all

developers, and each pair had the ability to make changes wherever needed. This

was eased by the uniformity of technical skills of all team members.

Test driven development (TDD): All code must have automated unit tests and

acceptance tests, and must pass all tests before it can be released.

Small Releases: The time between releases of functionality to users should be as

short as possible.

1.4.2 SCRUM

The Scrum methodology has been developed for managing the software development process

in a volatile environment. The Scrum methodology is based on the strategy used in the Rugby

sports i.e. flexibility, adaptability and productivity. In a Rugby scrum, the ball is passed back

and forth between team members to move the ball forward. The scrum methodology was

designed to handle rapidly changing business requirements by improving communication

between team members through daily meetings/ scrum meetings. In scrum, the work is break

down into series of iterations called as sprints. Scrum focuses more on management of the

development process than coding techniques aiming at consistently identifying any deficiencies

or impediments in the development process as well as in the practices that are used [16]. The

scrum methodology can be used on small and large projects. Scrum helps to develop software

more predictably, more reliably and with higher overall quality. Scrum leaves open for the

developers to choose the specific software development techniques, methods, and practices for

the implementation process. Scrum emphasizes the use of a set of software process patterns that

have proven effective for projects with tight timelines, changing requirements, and business

criticality.

Introduction

Page 12

Figure 1.4: Scrum Process Flow [17]

Scrum defines the following set of development actions:

Sprints: The development process is divided into small iterations called as sprints

and delivered the product incrementally.

User Stories: All user requirements, functional as well as non-functional system

requirements were expressed in small stories called as user stories.

Product owner: The product owner is responsible for communicating the

customer‟s vision of the product to the development team.

Small teams: Scrum advocates the use of small teams - no more than 10 team

members.

Scrum meetings: During the sprint, the team holds frequent daily short meeting

known as Scrum meetings, which involve all team members.

Scrum Master: The project leader or project manager can play the role of scrum

master and facilitates the development work.

Product Backlog: Product backlog is the cumulative of all stories which are yet

to be implemented. Items can be added to the backlog at any time. The features

which were incorporated in the previous iterative cycle (sprint) are no longer part

of the current product backlog or are marked as “Done”. The product manager

assesses the backlog and updates priorities as required.

Introduction

Page 13

1.5 Software Metrics

Among the things that govern our life, metrics occupies at the centre position. Some people

pointed out that without metrics, there should not exist modern science. Metrics makes the

abstract concepts more intuitive and more understandable. It is very important to incorporate

software metrics in software lifecycle. The development of software includes requirement

analysis, design, coding and testing, which all can be measured and analysed via metrics

methods. Software metrics can monitor the quality of software production and then makes

forecast and maintenance easier. With the rapid development of large scaled software, the

complexity of software grows fast, which makes the quality more and more difficult to control.

Therefore the production procedure should be checked by using software metrics. In order to

assure the reliability and the quality of software, correct metrics methods should be used for the

procedure and quality improvement.

1.5.1 Types of Software Metrics

Software metric is a quantitative measure of software. It helps in planning and predicting

software development. It also provide a measure of ease of using software. We can better

control software quality and development effort if we can quantify the software. The software

metrics evaluate the object oriented concepts like methods, classes, coupling and inheritance.

The metrics focus on internal object structure that reflects the complexity of each individual

entity and on external complexity that measures the interactions among entities. The metrics

measure computational complexity that affects the efficiency of an algorithm and the use of

machine resources, as well as psychological complexity factors that affect the ability of a

programmer to create, comprehend, modify and maintain software. Fenton [18] proposed three

main categories of software metrics. These categories are described as below:

Product metrics are measure of software products such as source code and design

documents.

Process metrics are measures of software development process such as the effort

required to design a software system.

Resource metrics are the quantitative measures of various resources used in the

project such as number of software developers, cost, schedule, productivity.

1.5.2 Measurement Scale

Depending on what kind of data is meaningful, measurement has been divided into four types

of scale:

Introduction

Page 14

Nominal: It is the simplest possible measurement. There is no notion of ordering. The empirical

relation system consists only of different classes. Any distinct numbering of the classes is an

acceptable measure but the sizes of the numbers have no meaning for the measure.

Ordinal: Ordinal data allows to rank the various data values; however the difference or ratios

between values are not valuable. Any mapping that preserves the order is acceptable. E.g.

programming experience may be measured as high, low or medium.

Interval: Data from an interval scale can not only be ranked, but also can exhibit meaningful

differences between values. McCabe‟s complexity measure might be interpreted as having an

interval scale. Differences appear to be meaningful; but there is no absolute zero, and ratios of

values are not meaningful. Mapping must preserve order.

Ratio: Some data values are associated with a ratio scale which possesses an absolute zero and

allows meaningful ratios to be calculated. Numbers starts at zero and increases at equal

intervals. All arithmetic can be meaningfully applied. E.g. lines of code (LOC)

1.5.3 Design Metrics

Design metrics consist of two categories:

Traditional Design Metrics: Traditional design metrics are based on structured

design. These metrics have been used for evaluating software complexity of

structured design. It deals with the structural property of software. Some metrics

like Lines of Code (LOC), Cyclomatic Complexity, Comment Percentage have

been accepted as standard traditional metrics.

Object Oriented Design Metrics: Object oriented design and development are

popular concepts in today‟s software development environment. Object oriented

development requires not only a different approach to design and implementation,

it requires a different approach to software metrics. Object oriented technology

uses objects as its fundamental building blocks, the approach to software metrics

for object oriented programs must be different from standard metrics set [19].

Object oriented metrics deals with size, cohesion and coupling metrics.

1.6 Motivations

During literature survey, it was found that most of the authors in their work defined a need for

carrying out investigation of the evolutionary behaviour of object oriented and agile developed

software and evolutionary trends of such techniques cannot be taken for granted. A few of the

works have been listed out as below:

Introduction

Page 15

Lehman et al. [1] in their future work mentioned to investigate the evolutionary

behaviour of software‟s developed using agile programming based development

methodology and claimed that the more extensive results will widen the scope of

validity of the contemplated theory of software evolution.

Kelley et al. [20] mentioned in their future work that several similar projects

developed using agile approach can be compared and find out whether they

display similar evolution traits with regards to Lehman‟s Law.

Sindhgatta et al. [21] in their paper have mentioned the need to review Lehman‟s

laws on larger case studies developed using agile methodology with a view

towards validating the initial results.

Capiluppi et al. [22] also mentioned in their future work to explore more

systematic ways of combining quantitative and qualitative observations for

building a richer and fuller picture of software evolution of agile developed

software systems.

All these key pointers mentioned by different authors constituted the motivations for this work.

1.7 Research Objectives

Previous research revealed that despite the research in the field of software evolution, most of

them focused on traditional or open source methods, and Lehman‟s laws of software evolution

have been interpreted and evaluated in the context of these methods. Lehman‟s laws of

software evolution need to be examined on projects following agile methodology to see if they

continue to hold good across the agile lifecycle. Various objectives of this work are as follows:

To investigate the relationship between agile processes and evolution of software

by carrying out an empirical validation using real world applications.

To empirically validate the Lehman‟s laws for software developed using agile

methodology.

To assess the behaviour of agile software processes at system level and sub-

system level.

1.8 Chapter Summary

Rest of the thesis is structured as follows:

Chapter 2 presents literature surveyed on software evolution and laws of software

evolution and agile processes. It also provides a summary of work done so far in

the related area.

Introduction

Page 16

Chapter 3 of thesis discusses the research methodology and tools used.

Chapter 4 presents the results of the experiments along with a brief description

about results wherever necessary.

Thesis concludes with its findings and work for future in Chapter 5.

CHAPTER-2

LITERATURE REVIEW

This chapter reviews the concept of software evolution, software evolution in agile software

development methodology and software metrics. Sections 2.1 and 2.2 presents the literature

surveyed on software evolution and software evolution in agile software development

methodology. Section 2.3 describes the traditional and object oriented metrics. Finally the

chapter ends with a discussion on metrics and concepts chosen for the analysis in this study.

2.1 Software Evolution

Software engineering still lacks a complete solid scientific basis. The laws of software

evolution were one of the first approaches to define a theory of software systems that provides

such a scientific basis. Software evolution deals with the process by which programs are

modified and adapted to their changing environment. The aim of Lehman’s research was to

formulate a scientific theory of software evolution. The laws were designed with change in

mind. Software cannot be immutable, and the laws have been shown to need changes

themselves as time passed. The laws of software evolution were first described in 1974, and

after several years of intense activity and refinement, the latest version of the laws was

published in 1997 [23] [24]. The best approach for software evolution is to study the modern

programming processes to help developers, managers and users in order to produce better

software.

Belady and Lehman [3] discussed the study of 20 releases of the OS/360 operating

systems software, which is the first empirical research to focus on the dynamic behaviour of a

relatively large and mature system. In this paper, they discussed number of observations about

the size and complexity of the system, which led to five “laws” of software evolution

dynamics: Continuing Change, Increasing Complexity, Conservation of Organization Stability,

The Fundamental Law of Program Evolution, and Conservation of Familiarity. They measured

the number of modules handled per day (handle rate) for every release and concluded that

handle rate is stationary with cyclic ripples.

Further Lehman [6] elaborated the meaning of the laws in the context of real systems. In

this paper, the five laws of evolution were supported through graphical presentation of the data.

A detailed study of first 19 releases of the software was used to plan release 20. Lehman

demonstrated how some initial estimates were likely to be optimistic or otherwise inaccurate

until corrected with access to historical data, and is useful demonstration of the practical

Literature Review

Page 18

application of this type of research to software maintenance management. Lehman also

proposed that the concepts and techniques presented in this paper could find wide application

outside the specific area of software systems, in other industries and to social and economic

systems.

Cook and Roesch [25] examined 10 releases over 18 months of a real time telephone

switch from a German telecommunications firm and analysed software metrics for complexity.

They concluded that information metrics performed well as compared to other metrics, such as

Halstead and McCabe Metrics, and simple lines of code. They also examined the evolution of

the system over 18 months of data and argued that they found support for the laws of evolution.

Basili et al. [26] examined 25 software releases of 10 different systems at NASA

Goddard and looked at the three Swanson maintenance change types (corrective, adaptive,

perfective) and a set of maintenance activities for each. They found that error correction efforts,

typically small changes, required significant isolation activity, while enhancements required

more time on inspection and certification.

Lehman et al. [2] investigated the FEAST project for software evolution study, and

examined 21 releases spanning 5 years of evolution. They examined the size in terms of

number of modules and the number of modules changed and developed a growth model for

module size per release using an inverse square model. This paper summarized the eights laws

of software evolution.

Kemerer and Slaughter [27] conducted an empirical study of software evolution using

the systems of a large United States retailer. The investigation was focused on the types of

changes, costs and effort to evolve the software and also analysed these factors from the point

of the view of Lehman’s Law.

Kafura [28] studied the relationship between software complexity metrics and software

maintenance and discussed that the classes of complexity metrics (code metrics and structure

metrics) grew when the system was maintained, which confirmed Lehman’s laws. The author

also claimed that extreme changes of complexity in one procedure/module may indicate

possible flaws during the maintenance activity.

Cook et al. [29] discussed an approach to understand software evolution based on the

empirical study of software evolvability and proposed that evolvability can be measured at the

different levels of abstraction of software systems, i.e. at pre-design, architectural, detailed

Literature Review

Page 19

design and source code levels by providing a real work example. They also suggested a set of

metrics for software evolvability based on ISO/IEC 9126 standard which improved the relation

between software and its environment.

Lehman and Ramil [1] discussed the 35 years study of the software process and

software evolution phenomenon and proposed refinement in the theory of software evolution,

draws attention to the SPE program classification, a principle of uncertainty and laws of

software evolution. They mentioned the need to investigate the evolutionary behaviour of

software’s developed using object oriented, open source, agile programming and COTS-based

development methodology and claimed that the more extensive results will widen the scope of

validity of the contemplated theory of software evolution. They claimed that the software

evolvability will play an increasingly more critical role in ensuring the survival of a society

ever more dependent on computers.

Godfrey and Tu [30] studied the evolution of software in the open source context by

looking at the evolution of the Linux kernel. They found that the Linux kernel has been

growing at a super-linear rate for several years instead of growing at slower rates as the Linux

code base increased. They used systems lines of code as a size metrics, and concluded that the

law of invariant work rate does not hold for open source software.

Xie et al. [31] applied the software evolution laws on open source systems and evaluated

all the eight laws of software evolution on seven open source systems. They concluded that of

the eight laws, Continuing Change, Increasing Complexity, Self Regulation, and Continuing

Growth are applicable to the evolution of open source software while they were inconclusive of

the other four laws on Conservation of Organizational Stability, Conservation of Familiarity,

Declining Quality, and Feedback system.

Kalpana and Arvinder [32] studied the effect of software evolution on open source

software. They analysed different versions of two open source software-13 versions of JHot

Draw and 16 versions of Rhino released over the period of 10 years, by applying package level,

class level and method level metrics. They concluded that three laws, Continuing change,

Increasing Complexity and Continuing growth were easily determined using the metrics, while

the relatedness of three laws, Self regulation, Conservation of organizational stability and

Conservation of familiarity to open source software system was hard to determine and will

require more empirical studies with relevant data.

Literature Review

Page 20

Anita et al. [33] presented the study of the software evolution for Mozilla Firefox open

source software for fifty latest versions. The applicability of Lehman’s laws of software

evolution to Mozilla Firefox was investigated empirically using the size and complexity metrics

and found that Law 1, 2, 6 and 7 were applicable but relatedness to law 3, law 4, law 5 and law

8 was not found in case of Mozilla Firefox.

2.2 Software Evolution in Agile Software Development Methodology

There have been limited empirical studies on the software evolution following agile

methodology. A previous work on such evaluation is as follows:

Capiluppi et al. [22] were the first to perform a measurement based study of the

evolution of successful agile systems. In their case study, they took data samples four times per

month to collect source code, unit tests and code check-in information over the span of 2.5

years. This study combined the use of quantitative and qualitative evidence and found that

growth was positive during most periods, but there were brief periods of less growth. They

analysed that growth was higher was higher for the lines of code as compared to number of

files or directories and proposed that the reduced complexity comes from the team’s

commitment to refactoring.

Sindhgatta et al. [21] were the first to study evolution using Lehman’s laws to

understand the evolution of software development using agile process-Scrum. They divided the

laws in four different groups: growth and complexity, self-regulation and conservation,

increasing complexity, and declining quality and found all the six Lehman’s laws true for the

software system.

Kelly et al. [20] compared the two similar open source project, one developed using

traditional approach and other using agile approach within the context of Lehman’s laws for

continuing growth, continuing change, increasing complexity, and conservation of familiarity

and found that all four laws were applicable to software project developed using agile

approach.

2.3 Traditional and Object Oriented Metrics

Software metrics is a valuable mechanism to manage, predict, assess and improve the quality of

software systems. Software metrics have gained renewed interest because they can enable

automated large-scale quality analysis of software. Metrics can help the automated analysis of

Literature Review

Page 21

the growing data available in software repositories. A large number of metrics are available that

need to be used in projects for estimating and tracking. Both traditional as well as object

oriented metrics are important to measure the quality of software systems. Some metrics such

as lines of code and cyclomatic complexity, have become accepted as standard for traditional

functional/procedural programs, but for object oriented there are many proposed object oriented

metrics in the literature. Object-oriented design and development is becoming very popular in

today’s software development environment, which requires different approach to software

metrics.

2.3.1 Traditional Metrics

There are many traditional functional development metrics which can be applicable to object

oriented development like complexity, size and readability.

Cyclomatic Complexity: Cyclomatic complexity (McCabe) is used to evaluate

the complexity of an algorithm in a method. It is a count of the number of test

cases that are needed to test the method comprehensively. The formula for

calculating cyclomatic complexity is the number of edges minus the number of

nodes plus 2. A method with a low cyclomatic complexity is generally better.

Cyclomatic complexity cannot be used to measure the complexity of a class

because of inheritance, but the cyclomatic complexity of individual methods can

be combined with other measures to evaluate the complexity of the class [34]

[35].

Size: Size of a class is used to evaluate the ease of understanding of code by

developers and maintainers. Size can be measured in variety of ways like counting

all physical lines of code, the number of statements, the number of blank lines and

the number of comment lines. Lines of Code (LOC) counts all lines of program.

Non-Comment Non-blank (NCNB) referred to as Source Lines of Code and

counts all lines that are not comments and not blanks. Executable statements

(EXEC) is a count of executable statements. Size metric affects the ease of

understanding by the developers and maintainers. Classes and methods of large

size will always pose a higher risk [36].

Comment percentage: The high comment percentage increases the

understandability and maintainability and comments assist developers and

Literature Review

Page 22

maintainers. The comment percentage is calculated by the total number of

comments divided by the total lines of codes less the number of blank lines.

2.3.2 Object Oriented Metrics

CK metrics [37] proposed by Chidamber and Kemerer were the first and most renowned

metrics suite for Object oriented software.

Coupling Between Objects (CBO): CBO metric for a class is a count of the

number of other classes to which it is coupled [37]. It is measured by counting the

number of distinct non-inheritance related class hierarchies on which a class

depends. Two classes are said to be coupled if methods declared in one class uses

methods or instance variables defined by other class. They stated that excessive

coupling between objects can lead to modular design and inhibit reusability.

Higher the coupling, weaker the reusability of class and it will be more complex

to maintain the class.

Response for a class (RFC): RFC is the count of the set of all methods that can

be invoked in response to a message to an object of the class or by some method

in the class [38]. This includes all methods accessible with in the class hierarchy.

RFC counts the occurrence of calls to other classes from a particular class, RFC=

{RS}. The response set (RS) of a class is a set of methods that can potentially be

executed in response to message received by an object of that class. The

cardinality of this set is a measure of the attributes of objects in a class. Since

RFC specifically include methods called from outside the class, it is also a

measure of the potential communication between the class and other classes. The

bigger the RFC, the complexity of the class increases and testing and debugging

of the class becomes more complicated since it requires a greater level of

understanding on the part of tester. The complexity of a class increases with the

number of methods that can be invoked from it.

Weighted Methods per Class (WMC): Another metrics of Chidamber and

Kemerer’s [37] suite is WMC which measures the complexity of an individual

class. If all the methods are considered equally complex, then WMC is simply the

number of methods defined in each class, WMC=ni=1 Ci where C1 has M1, …. Mn

methods with c1,..,cn complexity respectively. Since WMC is intended to measure

the complexity of a class, it is indicator of the effort needed to develop and

Literature Review

Page 23

maintain a class. If WMC is larger, then program is complicated which means

more time and effort should be put on the class.

Depth of Inheritance Tree (DIT): DIT measures the maximum level of the

inheritance hierarchy of a class [37]. The root of the inheritance tree inherits from

no class and is at level zero of the inheritance tree. Direct count of the levels of

the levels in an inheritance hierarchy. DIT is intended to measure the class

complexity, design complexity and the potential reuse because the more deeper is

a class, the greater number of methods is likely to inherit. If DIT is smaller, then

the class is more abstract and simpler.

Number of Direct Child (NOC): NOC is the number of immediate subclasses

subordinate to a class in the hierarchy [37]. NOC counts the number of subclasses

belonging to a class. NOC indicates the level of reuse, the likelihood of improper

abstraction and as possible indication of the level of testing required. The greater

the number of children, the greater the likelihood of improper abstraction of the

parent and may be a case of misuse of subclassing. But the greater the number of

children, the greater the reuse since inheritance is a form of reuse. If a class has a

large number of children, it may require more testing of the methods of that class,

thus increase the testing time.

Lack of Cohesion (LCOM): LCOM measures the dissimilarity of methods in a

class by instance variable or attributes [37]. A highly cohesive module should

stand alone; high cohesion indicates good class subdivision. Lack of cohesion or

low cohesion increases complexity, thereby increasing the likelihood of errors

during the development process. High cohesion implies simplicity and high

reusability. High cohesion indicates good class subdivision. Lack of cohesion or

low cohesion increases complexity, thereby increasing the likelihood of errors

during the development process. Classes with low cohesion could probably be

subdivided into two or more subclasses with increased cohesion.

Henderson-Seller [39] suggested two problems with LCOM metric. First, two

classes can have a LCOM=0 while one has more common variables than other.

And second, there are no guidelines about interpreting the values. Therefore,

Henderson-Seller has suggested a new LCOM measure (LCOM*). If all methods

access all attributes, then µ(Aj) = ma, so that LCOM*=0, which indicates

perfect cohesion. If each method access only 1 attribute then µ(Aj) = a and

Literature Review

Page 24

LCOM*=1, which indicates a lack of cohesion. A value near zero for this metric

indicates very high cohesion, where most methods refer to most instance variable.

2.3.3 Other Metrics

Number of Public Methods (NPM): The NPM metric simply counts all the

methods in a class that are declared as public. It can be used to measure the size of

an API provided by a package.

Cohesion Among Methods of Class (CAM): This metric computes the

relatedness among methods of a class based upon the parameter list of the

methods. The metric is computed using the summation of number of different

types of method parameters in every method divided by a multiplication of

number of different method parameter types in whole class and number of

methods. A metric value close to 1.0 is preferred. (Range 0 to 1).

Inheritance Coupling (IC): This metric provides the number of parent classes to

which a given class is coupled. A class is coupled to its parent class if one of its

inherited methods functionally dependent on the new or redefined methods in the

class. A class is coupled to its parent class if: i) One of its inherited methods uses

a variable (or data member) that is defined in a new/redefined method. ii) One of

its inherited methods calls a redefined method. iii) One of its inherited methods is

called by a redefined method and uses a parameter that is defined in the redefined

method.

Coupling Between Method (CBM): The metric measure the total number of

new/redefined methods to which all the inherited methods are coupled.

Average Method Complexity (AMC): AMC measures the average method size

for each class and it is useful for JAVA. Size of a method is equal to the number

of java binary codes in the method.

2.4 Metrics Selected for Analysis

This section presents the metrics chosen for this thesis work. As the main focus of this work is

to study the relationship between agile developed software and laws of software evolution, it

requires set of metrics for analysing the behaviour of the software system with respect to the

software evolution laws. We choose Lines of Code (LOC), Number of Methods (NOM),

Coupling between Object (CBO), Lack of Cohesion (LCOM), Weighted Method per class

(WMC), Number of Direct Child (NOC), Response for a class (RFC) and Depth of Inheritance

Literature Review

Page 25

Tree (DIT) metrics for our study. We will use the agile concepts like pair programming, sprints,

refactoring also for the validation of software evolution laws.

2.5 Chapter Summary

This chapter provides the description of literature surveyed on software evolution and software

evolution in agile software development methodology. The traditional and object oriented

metrics are also summarized with a discussion on metrics and concepts chosen for the analysis

in this study.

CHAPTER-3

METHODOLOGY AND IMPLEMENTATION

This chapter provides an overview of the methodology followed to carry out the validation of

software evolution laws for software development using agile methodology. It provides a

description of set of sample applications chosen along with tools used to carry out empirical

analysis. An overview of the statistical techniques used for data analysis is also given.

3.1 Sample Application

During the literature survey, some major issues with previous research were identified. There is

a lack of empirical studies for validation of software evolution laws for agile developed

processes. Also few researchers focused on the study of software evolution laws using agile

processes by comparing agile and non-agile projects or with single sample project. Taking

these things into consideration, the experiments were carried out using a set of real world

software systems developed using agile methodology. Though agile methodologies have gained

adoption in a wide variety of software development domains and came into mainstream of

software engineering and adopted by small software firms and by large organizations, but the

availability of software data enabling empirical software engineering studies about agile

development methodology is scarce. An intensive search was performed for the selection of

software system developed using agile processes. Three projects were selected as per the

requirement of thesis and the availability of data for implementation purpose.

3.1.1 FlossAr

FlossAr is an open source java project. FlossAr is a program to manage the Register of

Research of universities and research institutes. FlossAr was developed with a full object

oriented (OO) approach and released with GPL v.2 open source license [40]. This open source

software is available on SourceForge.net [41]. FlossAr is a web application, which has been

implemented through a specialization of the open source software project, jAPS (Java Agile

Portal System), a Java framework for Web portal creation. Since Java is an OO language, we

used the Chidamber and Kemerer (CK) OO metrics suite. As FlossAr project had to be

developed quickly, in front of requirements not well understood at the beginning, and with a

high probability of changing, the management of FlossLab, the firm behind the development of

FlossAr, decided to use an agile approach to develop the system.

Agile Methodology is a recent approach to software development, introduced at the end

of nineties and now widely accepted worldwide as “mainstream” software engineering. Agile

Methodology And Implementation

Page 27

methodology offers a viable solution when the software to be developed has fuzzy or changing

requirements, being able to cope with changing requirements throughout the life cycle of a

project. The choice of the development practices to used is of paramount importance for the

success of the project. The team and its advisors defined some principles to be followed:

Code Reuse: Not only the underlying framework , but also the specialized

software product must be reusable. In fact, there is no such thing as a general

purpose register of research, but each university or research institution wish to

customize such a system to cope with its specific features and requirements.

Evolvability: It is very important that the software can be easily modified and

upgraded, in a context where requirements were unclear since the beginning and

new requirements might be added continuously.

Maintainability: Errors and failures must be fixed quickly, in every software

module composing the system, minimizing the probability to introduce new bugs

when old bugs are fixed.

Modularity: The functional blocks of the underlying framework must be kept, and

new modules must be added on each of them, with no intervention on the

framework itself.

Portability: This was a specific requirement of FlossAr, to be able to propose it to

several research institutions, with different hardware and software contexts. For

other specialization projects, it might not be as important.

Based on the above defined principles, the team of FlossAr defined a set of agile

practices derived from Extreme programming and these includes pair programming, on site

customer, continuous integration, small releases, test driven development, refactoring, coding

standards, collective code ownership, sustainable pace, stand-up meeting, feature list and build

by feature.

3.1.2 StudentLancer

StudentLancer is a market place where students from various streams and departments can get

their job done related to the field. StudentLancer is a web application created online where

dealers and students can register themselves. The marketplace offers the various projects

related to the fields. The projects are handled by the dealers, The dealer gets notified about the

student and also a risk factor about the project/task. The details of the task are notified and by a

mutual agreement a timeline and cost are decided for both. The web application can give all the


Page 28

transaction details, documents shared and other details between both parties. The web

application is developed using Agile Methodology.

The team of StudentLancer defined a set of agile practices derived from Extreme

programming and they were pair programming, on site customer, continuous integration, small

releases, test driven development, refactoring, coding standards, collective code ownership,

sustainable pace, stand-up meeting, feature list and build by feature.

3.1.3 Multi-Level Marketing (MLM) Software

Multi-Level Marketing software is a web application which maintains a database of customers,

their online sales record and the sales of other salespeople that they recruit. MLM software

plays an important role for successful multi-level marketing business. Online MLM

software enables MLM companies to manage and run their direct selling business more

effectively towards a successful way. This software provides easy tracking of customers,

various kinds of reports regarding sales, revenue, analytical and pictorial presentation in

hierarchical structure of MLM customers. The web application is developed using the agile

methodology.

3.1.4 Tools used for the StudentLancer and Multi-Level Marketing software

The projects StudentLancer and Multi-Level Marketing software are developed by the same

organization. This section provides an overview of the tools used by the organization to

develop the two softwares. The tools used for the project development and management

processes are as follows:

GitHub is used for code repository and version controlling [42]. GitHub

repositories can be accessed from both Git and Subversion (SVN) clients. It

supports Subversion clients via the HTTPS protocol. It can be used to make

revision of the projects. Revision can be checked and updated using GitHub.

Addition of new features and fixing of bugs, can be made to GitHub by commits.

Jenkins is used for continuous integration for software development of projects.

[43]. It is an open source tool written in Java. It is a server-based system running

in a servlet container such as Apache Tomcat. It supports SCM tools including

AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase and RTC, and

can execute Apache Ant and Apache Maven based projects as well as arbitrary


Page 29

shell scripts and Windows batch commands. The primary developer of Jenkins is

Kohsuke Kawaguchi. Jenkins was released under the MIT license and it is free

software. Builds can be stated by various means, including being triggered by

commit in a version control system, scheduling via a cron-like mechanism,

building when other builds have completed, and by requesting a specific build

URL.

Asana was used by the team to enable teamwork and for project management

[44]. Asana is a web based solution (SAAS: Software as a service) for the

effective collaboration of teams. The main user focus is to plan and manage

projects and tasks online without the use of email. The asana workflow is as

follows: Each team gets a workspace. Workspaces contain projects, and projects

contain tasks. In each task, users can add notes, comments, attachments, and tags.

Users can follow projects and tasks, and, when the state of a project or task

changes, followers get updates about the changes in their inboxes. The API is

available for free to everyone with an Asana account and can be accessed through

their developer site. Asana is integrated with several popular productivity tools

including Dropbox, Evernote, Google Drive, Harvest, and Instagantt, Jira,

Zendesk, among others.

3.2 Methodology

This section provides the methodology adopted to study the validation of software evolution of

agile projects using Lehman laws.

Figure 3.1: Methodology Followed


Page 30

Data collection: Once the sample applications were selected, the next step was to

collect data. To extract the data needed for analysis, different tools were used. The data is

collected for each release version of the selected projects. The software metrics were obtained

for each sample project and metrics values were then exported in Excel files. Microsoft Excel

was used to carry out the graphical representation of metrics for validation of software

evolution laws. The data about the set of agile practices used for the development and

maintenance of sample projects was also selected. The class name for the projects

StudentLancer and MultiLevel Marketing were not mentioned here in the thesis to maintain the

secrecy of the projects. A graphical depiction of methodology is given in Figure 3.1.

3.3 Tools Used

This section presents an overview of tools used for metrics collection and tools used to carry

out statistical analysis.

3.3.1 CKJM extended

In order to collect traditional and object oriented metrics value, a tool was required which can

fetch sample java application and execute them to provide metric values. For this purpose, we

chose CKJM extended [45] as metric collection tool. CKJM calculates metrics that have been

recommended as good quality indicator. CKJM extended (2.0) does not offer a Graphical User

Interface (GUI) and its focus is not on elaborate diagrams but on efficient calculation of

metrics. It is an open source project and is an extended version of CKJM 1.8. It was extended

through increasing the number of software metrics that it calculates. The program CKJM

extended calculates nineteen size and structure software metrics by processing the bytecode of

compiled Java files. To run the program simply specify the class files (or jar files) on its

command line or standard input. The program will produce on its standard output a line for

each class containing the complete name of the class and the values of the corresponding class

metrics. The program calculates for each class the following metrics and displays them on its

standard output:

WMC: Weighted methods per class (NOM: Number of Methods in the QMOOD

metric suite)

DIT: Depth of Inheritance Tree

NOC: Number of Children

CBO: Coupling between object classes


Page 31

RFC: Response for a Class

LCOM: Lack of cohesion in methods

Ca: Afferent coupling (not a C&K metric)

Ce: Efferent coupling (not a C&K metric)

NPM: Number of Public Methods for a class (not a C&K metric; CIS: Class

Interface Size in the QMOOD metric suite)

LCOM3: Lack of cohesion in methods Henderson-Sellers version

LCO: Lines of Code (not a C&K metric)

DAM: Data Access Metric (QMOOD metric suite)

MOA: Measure of Aggregation (QMOOD metric suite)

MFA: Measure of Functional Abstraction (QMOOD metric suite)

CAM: Cohesion Among Methods of Class (QMOOD metric suite)

IC: Inheritance Coupling (quality oriented extension to C&ampK metric suite)

CBM: Coupling Between Methods (quality oriented extension to C&ampK metric

suite)

AMC: Average Method Complexity (quality oriented extension to C&ampK

metric suite)

CC: McCabe's Cyclomatic Complexity

To run ckjm extend run java with the -jar flag, providing as its argument the location of

the file ckjm.jar and specify Java class files as arguments. A graphical presentation of tool is

given in Figure 3.2. The command's output will be a list of class names (prefixed by the

package they are defined in), followed by the corresponding metrics for that class: WMC, DIT,

NOC, CBO, RFC, LCOM, Ca, Ce, NPM, LCOM3, LOC, DAM, MOA, MFA, CAM, IC, CBM

and AMC . In lines where at the beginning is "~" is the value of CC. CC is counted for all

methods in given class.

Figure 3.2: Screenshot of CKJM Extended


Page 32

3.3.2 PHP_Depend

PHP_Depend is a small program that performs static code analysis on a given source base [46].

Static code analysis means that PHP_Depend first takes the source code and parses it into an

easily processable internal data structure. This data structure is normally called

an AST (Abstract Syntax Tree), that represents the different statements and elements used in

the analyzed source base. Then it takes the generated AST and measures several values for

software metrics. Each of these values stands for a quality aspect in the analyzed software,

observed from a very high level of abstraction, because no source was reviewed manually until

now. PHP Depend can generate a large set of software metrics from a given code base, these

values can be used to measure the quality of a software project and they help to identify that

parts of an application where a refactoring should be applied.

Figure 3.3: Screenshot of PHP_Depend


Page 33

3.3.3 Microsoft Excel

Microsoft Excel is a spreadsheet application developed by Microsoft for Microsoft Windows

and Mac OS [47]. It is a spreadsheet program that allows to store, organize and analyze

information. It features calculation, graphing tools, pivot tables, and a macro programming

language called Visual Basic for Applications. It has been a very widely applied spreadsheet

for these platforms, especially since version 5 in 1993, and it has replaced Lotus 1-2-3 as the

industry standard for spreadsheets. Microsoft Excel has the basic features of all spreadsheets,

using a grid of cells arranged in numbered rows and columns to organize data manipulations

like arithmetic operations, where column represents a variable and each row represents a case.

It supplies functions to answer statistical, engineering and financial needs. It displays data as

line graphs, histograms and charts, and limited three-dimensional graphical display. It allows

sectioning of data to view its dependencies on various factors for different perspectives. It has a

programming aspect, Visual Basic for Applications, allowing the user to employ a wide variety

of numerical methods. It has a variety of interactive features allowing user interfaces that can

completely hide the spreadsheet from the user, so the spreadsheet presents itself as an

application via a custom-designed user interface. Microsoft Excel 2013 included three views:

Normal view, Page Layout view and Page Break view. In our analysis, we have used Microsoft

Excel 2013 for graphical representation of data.

Figure 3.4: Screenshot of Microsoft Excel


Page 34

3.4 Techniques used for Analysis

The following section provides a detailed review of the techniques used in this study.

Average: The Microsoft Excel Average function returns the average (arithmetic

mean) of the numbers provided.

Average (number 1, [number 2] ,…, [number n] )

The software metrics was calculated for each individual file and then combined

into an average for the release.

Sum or Total Count: The sum function is one of the math and trig functions

which adds all of its argument.

SUM(number 1, [number 2],…,[number n] )

Graphs: Graphs or charts are incredibly useful tools, and Excel makes it quick

and easy to add them to the spreadsheets in order to tell a graphical presentation

of the data. Excel makes graphs so efficiently that it is considered a basic feature

of the program. The graphical representation of the software metrics data shows

the software evolution trends.

3.5 Chapter Summary

This chapter provides the description of sample projects, tools and methodologies used by the

projects for software development and tools and techniques used for collecting and the metric

data. The techniques used to analyse the data are also summarized.

CHAPTER-4

RESULTS AND ANALYSIS

This chapter provides a detailed description of the results of empirical validation of software

evolution of agile projects using Lehman laws. We analyze the Lehman laws of software

evolution in the light of several metrics, computed for different versions of FlossAr,

StudentLancer and Multi-Level Marketing software released through evolution process. Some

of the laws have a direct relevance to the computed metrics whereas for some of the laws we

did not find direct relevance to software metrics.

4.1 Analysis Techniques and Result

This section summarizes the results obtained from the experimentation carried out on sample

projects. Each result is represented in graphical form. In each result the major points identified

during analysis are also highlighted.

4.1.1 Continuing Growth and Continuing Change (Law 1 and Law 6)

These two laws (Continuing Growth and Continuing Change) are directly connected, as growth

in the system is a direct result of change. The law of continuing change describes the fact that a

software system must continually adapt to its environment in order to meet user needs and to be

used for longer period. Software may change in response to bug fixing activity or in response to

change in the environment. The law of continuing growth states that a system must continue to

add new functionality over time. It is difficult to differentiate between growth and change. The

change as a result of change in usage environment may include addition of some functions,

classes or methods which will increase the size of software leading to growth. These laws are

measured in terms of size, number of LOC (per release) and graphical representation is shown

in Figure 4.1.

Figure 4.1: Growth and Change for projects 1, 2 and 3

Results and Analysis

Page 36

From the graph it is clear that the line of code of projects were increasing following a

smooth trend with release of new version. For project StudentLancer (LOC1), the graph is

showing the growth of LOC with small increase of code at each version. For project MLM

(LOC2), it is showing linear growth trend with huge increase in LOC at each version. For

project FlossAr (LOC3), the growth is slowly increasing from release 1 to release 2 as the

number of classes added were very less. But after release 2, the graph is showing linear growth

with an increase of 146764 lines of code. From the graph and analysis, it is clear that the law of

continuing change and continuing growth is reflected by all projects.

4.1.2 Increasing Complexity (Law 2)

The second law of evolution states that the complexity of the system increases as the program

evolves unless steps are taken to reduce complexity. It is perceived that growth adds to increase

in complexity but if appropriate changes are made; the evolution process might not show the

attributes that conforms increase in complexity. Therefore, it becomes difficult to determine

whether the law is reflected by the evolution process or not.

In case of object oriented systems, the complexity of the software system or subsystem

can be determined using coupling between objects (CBO), response for a class (RFC),

weighted method per class (WMC) and lack of cohesion metrics (LCOM).

The CBO was calculated for each file and then average was calculated for each release

overall. Figure 4.2 shows the CBO for each project.

Figure 4.2: Law of Increasing Complexity measured by CBO per release


Page 37

The project 1(MIM) has lesser degree of coupling as coupling between objects decreases

with new releases. The project 2 (StudentLancer) has the higher overall coupling value for all

releases, but it is showing same trend as project 1, which means the coupling is decreasing with

software evolution. For project 3 (FlossAr), the CBO grows from release 1 to release 2 and is

the higher for release 3. The classes with higher CBO indicate that they are highly

interconnected and related classes are accessing the internal details of one another. An ideal

project would have a low degree of coupling. The coupling for project 1 and 2 is decreasing

with new releases. The coupling for project 3 is increasing with new releases which is the result

of addition of huge number of classes at release 3.

For project 1, cohesion among methods of class was calculated. The LCOM was

calculated for project 2 and 3. The LCOM was calculated for each individual file, and

combined into an average for the release. The cohesion for project 1 is shown in Figure 4.3 and

cohesion for project 2 and 3 is shown in Figure 4.4.

Figure 4.3: Law of Increasing Complexity measured by cohesion for project 1

For Project 1, cohesion increases with higher value from release 1 to release 2 to release

3. Project 2 is also showing the higher cohesion value with the new releases of projects. For

Project 3, cohesion is decreasing from release 1 to release 2 and after that it is increasing for

release 3. An ideal project would have a low degree of coupling and a high degree of cohesion.

0

0.2

0.4

0.6

0.8

1

1.2

CAM: Cohesion AmongMethods of Class



Cohesion

Version 1 Version 2 Version 3


Page 38

Figure 4.4: Increasing Complexity for project 2 and 3

The RFC was calculated for each file and then average was calculated for each release

overall for project 2 and 3. For Project 2 (StudentLancer), the average RFC decreases with the

release 2 and after that increases with release 3. For project 3 (FlossAr),the average RFC

decreases with new releases. The larger RFC increases the complexity because a large number

of methods can be invoked in response to a message which is an indicator of the effort of

testing and debugging. The growth curve for average RFC for project 2 and 3 is shown in

Figure 4.5.

Figure 4.5: Growth curve for average RFC for project 2 and 3


Page 39

The change in the measure of average WMC for project 2 and 3 is shown in figure 4.6.

Both projects shows the increase in complexity measure. For project 2 (StudentLancer), there is

a decrease in average WMC from release 1 to release 2 and after that it is increasing during

release 3. The same trend is observed for project 3 (FlossAr). On looking into the details of

revision made to both projects, it is observed that major changes were brought about in the

overall structure of the software.

Figure 4.6: Growth curve for average WMC for project 2 and 3

The continuing growth of the software led to an increase in the number of classes and the

number of member functions and causing an increase to total CBO, LCOM, RFC and WMC.

This indicates an increasing complexity. The interpretation of observation related to average

CBO, LCOM, RFC and WMC is slightly different. Due to increase in the number of classes the

average CBO, LCOM, RFC and WMC was distributed over to added classes and showing a

slow increase in the complexity. This is interesting as it is showing result opposite to what

Lehman’s law would predict. The decrease in the complexity measure for all projects can be

attributed to activities meant to reduce the complexity. This means that the developers of all

projects are able to decrease their complexity through the use of iterations, intermediate minor

releases and focusing on maintenance of the project.

4.1.3 Self Regulation and Feedback (Law 3 and Law 8)

Evolution process of E-type system is self regulating. This means that growth rate is regulated

by the maintenance process. According to the law of feedback system, the evolution process is


Page 40

a multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve

significant improvement over any reasonable base.

The law 3 states that growth trends in the system are cyclically self regulating over a long

time period. A growth trend is seen when the lines of code added are considered in Figure 4.1.

In agile development methodology lifecycle, there are ripples in the growth. An iteration in

agile with a large increment in number of files can be followed by one with lesser number of

additions, and this pattern repeats, emphasizing the self regulatory nature of the development

process. It is also important to note that in agile development methodology, the development

process is divided into small iterations which may last for 2-4 weeks depending upon the

features to be implemented in that iteration. The agile development methodology process itself

is self regulating as it is showing iteration of different sizes in terms of weeks. The number of

weeks spend for one iteration can be larger as compared to number of weeks spend for another

followed iteration.

Figure 4.7: Duration of Iterations for Project MIM during release 3

Figure 4.8: Duration of Iterations for Project StudentLancer during release 2


Page 41

The duration of iterations for project MIM and StudentLancer is shown in Figure 4.7 and

Figure 4.8 respectively which shows the different durations for each iteration in terms of

weeks. Figure 4.9 represent the changes in files during the sprints for project MIM. Figure 4.10

and Figure 4.11 represent the changes in files during the sprints for project StudentLancer

during release 2 and release 3 respectively.

Figure 4.9: Change in files during Sprint for project MIM

Figure 4.10: Change in files during Sprint for project StudentLancer for release 2

It can be observed that change in files in terms of file addition, file deletion and file

modification differs from sprint-to-sprint or iteration-to-iteration. Thus even when there are

ripples in growth, these are regulated with certain bounds. Lehman’s third law of cyclical self

regulation does seem to explain the observed behaviour in the project.


Page 42

Figure 4.11: Changes in files during Sprint for project StudentLancer for release 3

In the eighth law on feedback system, Lehman determines the ripple effect of the growth

of a software system as an outcome of the system stabilizing itself due to feedback. In feedback

systems, correct decisions can only be taken in the context of understanding of the system as a

whole. Feedback plays an important role in self stabilization and to exploit them in future

planning, management and process improvement. In agile software development methodology,

the feedback is continuous process across sprints. The product backlog changed from one sprint

to next based on the feedback control. For all the three projects, the on-site customer was

available throughout the development of project and the modification in the project is as per the

new requirements received from the customer or to correct bugs/error in the previous releases.

The project 3 (FlossAr) is an open source project and major feature request and reporting of

bugs comes from user community. In Agile development methodology, the customer places the

important role as customer is available full time with the development team and it include short

releases of software system for the customer. This law is true for all three agile projects.

4.1.4 Conservation of Familiarity (Law 5)

This law states that the familiarity with evolving E-type system is conserved. A huge change

that might cause lack of familiarity of staff members involved with in the evolving software is

avoided. From the study of continuous growth and change, the size of project 2 and project 3

changes abruptly. But both the projects used pair programming through out the project

development phase, therefore familiarity was maintained. In agile development methodology,

the concept of collective code ownership and pair programming helps in maintaining the


Page 43

conservation of familiarity in the system. Through collective code ownership, multiple

developers in the team can update and change the same code. In such a scenario, domain

knowledge gets distribute across multiple team members and familiarity is thus shared.

4.1.5 Declining Quality (Law 7)

According to this law, the quality of evolving software will decline unless some substantial

efforts are made to improve it. The law is similar to Law 2: Increasing complexity, which is

indicator of declining quality. Figure 4.3 and 4.4 depicts that for project 1 and 2 the value of

cohesion increases but for project 3 the value of cohesion decreases which means that quality

of project 3 is declining and efforts will made to improve it.

For Project 1, cohesion increases with higher value from release 1 to release 2 to release

3. Project 2 is also showing the higher cohesion value with the new releases of projects. For

Project 3, cohesion is decreasing from release 1 to release 2 and after that it is increasing for

release 3. An ideal project would have a low degree of coupling and a high degree of cohesion.

This is interesting as it is showing result opposite to what Lehman’s law would predict. This

means that the developers of all three projects are able to decrease their complexity through the

use of iterations, intermediate minor releases and focusing on maintenance of the project.

The test driven development was used by all the projects which is essential to maintain

the quality of the system. For the projects under study, the majority of defects were identified

during sprint releases or while the development because a large number of test cases were

developed prior to the release. Thus, quality of projects were maintained.

4.2 Results Summary

This section summarizes the results generated from the experimentation carried out on sample

projects as mentioned in the previous section. In each result the major points identified during

analysis are highlighted.

i. Continuing Change: This law specifies that a program must continually adapt to it

environment, otherwise it becomes progressively less useful. Figure 4.1 showed

the growth for change in LOC for all three projects. It is evident from the results

in Figure 4.1 that there is an increase in LOC. This growth in terms of LOC is

assumed to be a result of constant need for new functionality.

ii. Increasing Complexity: The second law of evolution states that the complexity of

system increases as system evolves, unless effort is made to prevent it. It is


Page 44

evident from Figure 4.2 that projects MIM and StudentLancer has lesser degree of

coupling as CBO decreases with new releases, which can be supported by the fact

that in case of both projects, MIM and StudentLancer, efforts are being made to

make the changes in such a manner that evolution process does not increases the

complexity. Whereas for project FlossAr, there is an increase in the complexity

from version 2 to verison 3, which is the result of addition of large number of

classes at release 3.

For all three projects, cohesion is calculated. Figure 4.3 and 4.4 shows

that project MIM and StudentLancer shows the continues increase in the cohesion

value. For project FlossAr, first cohesion decreases from version 1 to version 2,

and after that it increases from version 2 to version 3 which means that the

complexity of system decreases through the use of iterations, intermediate minor

releases and focusing on the maintenance of the project.

iii. Self regulation: This law of self regulation suggests that the evolution of large

software systems is self regulating process. It can be observed from Figure 4.9,

4.10 and 4.11 that changes in files in terms of file addition, file deletion and file

modification differs from iteration-to-iteration. Thus even when there are ripples

in growth, these are regulated with certain bounds.

iv. Conservation of Familiarity: The fifth law on conservation of familiarity states

that during the active life of an evolving program, the content of successive

releases is statistically invariant. As system evolves, the associated team must

maintain mastery of its content and behaviour. The agile methodologies used in

the projects like pair programming and collective code ownership helps

maintaining the conservation of familiarity in the system.

v. Continuing Growth: This law states that the functional content of software

systems must be continually increased to maintain user satisfaction over time. It

can be observed from Figure 4.1 that there is a noticeable change in the size

metrics of all projects for all versions. It is concluded that the evolution pattern of

all three projects is correlated to law of continuing growth.

vi. Declining Quality: According to this law, the quality of evolving software will

decline unless some substantial efforts are made to improve it. For all three

projects, cohesion decreases which means that the developers of all projects are

able to decreases their complexity through the use of iterations, intermediate

minor releases and focusing on maintenance of the project. The test driven


Page 45

development is used by all projects and majority of defects were identified during

small releases helps to maintain the quality of the project.

vii. Feedback System: According to this law an evolutionary process must constitute

multi-level, multi-loop, multi-agent feedback systems and must be treated as such

to achieve significant improvement over any reasonable base. For agile developed

projects, feedback is continuous process across sprints and for all three projects,

the onsite customer was available throughout the development of the project. The

law seems to be true in the sense that since feature request and reporting of bugs

comes from user community, and continuous feedback from onsite customer plays

major role in the evolution process.

4.3 Chapter Summary

This chapter provided the results obtained from the experimentation carried out on all three

sample projects with graphical representation. The chapter concluded with result summary.

CHAPTER-5

CONCLUSIONS AND FUTURE WORK

The rapid growth of software industry has changed the software development technology from

traditional software development methodology to agile based development methodology. Many

organizations shifted to agile development methodology and with this increase in the use of

agile methodology for software development there is a need to study the software evolution

trend for these software systems. The combined use of quantitative and qualitative evidence

provides the software evolution. It seems that this is due to the high level of complexity control

work and high rate of iteration with customers quickly receiving the requested functionality.

There is a need to study more agile developed systems to see if the software evolution law is

true for such systems or not. This work focus on empirically validating software evolution laws

for agile developed systems in the light of number of software metrics and agile methodology

used for the development and evolution of the project. To carry out experimentation LOC,

CBO, LCOM, RFC, WMC was selected and various agile values and principles were studied.

This investigation was carried out using a set of agile developed systems which include real

world applications and projects are active for commercial use. All the results were collected for

sample projects for the validation of software evolution laws. In this chapter, conclusions of the

work presented in the previous chapter are drawn. Following these conclusions, some pointers

are mentioned on possible future work.

5.1 Conclusions

Based on the results drawn in the previous chapter, following conclusions have been identified:

The agile develop projects allows smooth evolution while avoiding the problems

of increasing complexity and decreasing customer satisfaction.

Due to high level of complexity control work and the high rate of iterations, the

customers were quickly receiving the requested functionality.

All the projects shows the effect of continuous change and continuous growth

with increase in LOC.

For two systems, coupling is decreasing with new release which reduces the

complexity of the systems. While one system shows the increases in coupling for

last release which is the result of adding large number of classes through

increased customer requirements and feedback.

Conclusions and Future Work

Page 47

The two systems were showing the increase in cohesion while for one system

cohesion is decreasing from release 1 to 2 and after that it is increasing. An ideal

project should have high degree of cohesion. This is interesting as it is showing

result opposite to what Lehman’s law would predict. This means that the

developers of all systems are able to decrease their complexity through the use of

iterations, intermediate minor releases and focusing on maintenance of the project.

The law of self regulation is analyzed using the sprint durations and change in

files during the iterations. There are ripples in growth, regulated with certain

bounds. The lehman’s third law of cyclical self regulation explain the observed

behaviour in the project. It was proposed that the self regulatory behaviour of

project can be studied form the durations of sprints/iterations as it is showing the

ripple effect for growth of the system.

The law of feedback system determines the ripple effect of growth of a software

system which is due to continuous feedback. In agile, the feedback is continuous

process across sprints. And all the projects shows the effect of continuous

feedback as the customer was available throughout the development process and

also system changes with reporting of errors/bugs which is also a kind of feedback

received from the customer.

All projects shows the effect of conservation of familiarity as collective code

ownership and pair programming is used across all the sprints and project.

The quality of evolving software is determined using the concept of cohesion and

coupling. The two projects shows the high coupling and low cohesion and one

project is showing decrease in cohesion from release 1 to 2 and after that increase

in cohesion from release 2 to 3, which means that the developers of two project

are able to maintain the complexity through the use of iterations, intermediate

minor releases and focusing on maintenance of the project.

5.2 Future Work

Some interesting challenges were identified while carrying out this thesis work, which could be

further considered for the future work. The challenges are:

The lack of data available for the agile developed projects was the bigger

challenge. There is a need to seriously look into this matter so that research can be

easily carried out for agile processes.

Conclusions and Future Work

Page 48

The real world application involve three systems developed using agile

methodology which includes FlossAr, StudentLancer and MultiLevel Martketing

software. In this work, only a set of real world applications were selected. Future

work may involve exploring the wide range of applications for validation purpose.

There is a need to explore more systematic ways of combining quantitative and

qualitative observation for building a richer and fuller picture of software

evolution.

The investigation in this work has been carried out only on systems with very

limited number of releases. Large systems with more number of releases over a

longer period in number of years must be studied to further analyse the validation

of software evolution for agile processes.

The investigation must be carried out with respect to iterations for validation of all

laws of software evolution.

The reflection of law of continuing change, continuing growth, increasing

complexity, self regulation and declining quality was easily determined using

software metrics. But the relatedness of law of conservation of organization

stability and feedback system was hard to determine with relevant data.

REFERENCES

[1] Meir M. Lehman and Juan F. Ramil, “Software Evolution: Background, Theory,

Practice”, Information Processing Letters, vol. 88, no. 1-2, pp. 33-33, 17 October 2003

[doi:10.1016/S0020-0190(03)00382-X]

[2] Manny Meir Lehman, Juan F Ramil, Paul D Wernick, Dewayne E Perry and Wladyslaw

M Turski, “Metrics and Laws of Software Evolution – The Nineties View”, Proceedings

of the 4th

International Symposium on Software Metrics, pp. 20-32, 05-07 November

1997.

[3] L.A. Belady and M.M. Lehman, “A Model of Large Program Development”, IBM

Systems Journal, vol. 15, no. 1, pp. 225-252, 1976.

[4] J. Dvorak, “Conceptual Entropy and its Effect on Class Hierarchies”, Computer, vol.

27, no. 6, pp. 59-63, June 1994 [doi:10.1109/2.294856]

[5] M.M. Lehman, “On Understanding Laws, Evolution and Conservation in the Large-

Program Life Cycle”, Journal of Systems and Software (1), pp. 213-221, July 1980

[doi:10.1016/0164-1212(79)9002-0]

[6] M. M. Lehman, "Programs, life cycles, and laws of software evolution", Proceedings of

the IEEE, vol.68, no.9, pp.1060-1076, Sept.1980 [doi:10.1109/PROC.1980.11805]

[7] Capers Jones, “Applied Software Measurement: assuring productivity and quality”,

McGraw-Hill, Inc., New York, NY, 1991.

[8] Bob Schatz and Ibrahim Abdelshafi, "Primavera gets agile: a successful transition to

agile development", Software, IEEE , vol.22, no.3, pp.36-42, May-June 2005

[doi:10.1109/MS.2005.74]

[9] S.C. Misra, U. Kumar, V. Kumar, and G. Grant, "The Organizational Changes Required

and the Challenges Involved in Adopting Agile Methodologies in Traditional Software

Development Organizations", Digital Information Management, 2006 1st International

Conference on , vol., no., pp.25-28, Dec. 2006 [doi:10.1109/ICDIM.2007.369325]

[10] Manifesto for Agile Software Development. Available at: http://agilemanifesto.org/

(last visited December 2014)

[11] P. Abrahamsson, O. Salo, J. Ronkainen and J. Warsta, “Agile software development

methods: Review and Analysis”, Espoo, Finland, Technical Research Centre of Finland,

VTT Publications 478. http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf, 2002.

http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf

References

Page 50

[12] Alistair Cockburn, “The Agile Software Development” Addison-Wesley Longman

Publishing Co., Inc., Boston, MA, 2002

[13] Article: Agile Principles and Values, by Jeff Sutherland. Available at:

http://msdn.microsoft.com/en-us/library/dd997578.aspx

[14] K. Beck, “Extreme programming explained: Embrace change”, Addison-Wesley

Longman Publishing Co., Inc., Boston, MA, 1999

[15] K. Beck, “Embracing Change with Extreme Programming”, IEEE Computer, vol. 32

no. 10, pp. 70-77, October 1999 [doi:10.1109/2.796139]

[16] C. Mann and F. Maurer, “A cases study on the impact of scrum on overtime and

customer satisfaction”, Agile Conference, 2005. Proceedings, vol., no., pp. 70-79, July

2005 [doi:10.1109/ADC.2005.1]

[17] Image from www.scrumalliance.org/why-scrum (last visited December 2014)

[18] N. Fenton and S.L. Pfleeger, “Software Metrics: A Rigorous and Practical Approach”,

PWS Publishing Co., Boston, MA, 1998

[19] L.H. Rosenberg, “Applying and Interpreting Object Oriented Metrics”, Proc. Software

Technology Conference, April 1998

[20] K. Duran, G. Burns, P. Snell, “Lehman's laws in agile and non-agile projects", Reverse

Engineering (WCRE), 2013 20th Working Conference on , vol., no.,pp. 292-300,

October 2013 [doi:10.1109/WCRE.2013.6671304]

[21] R. Sindhgatta, N.C. Narendra and B. Sengupta, “Software Evolution in Agile

Development: A Case Study”, Proceedings of the ACM international conference

companion on Object oriented programming systems languages and applications

companion, October 17-21, 2010, Reno/Tahoe, Nevada, USA

[doi:10.1145/1869542.1869560]

[22] A. Capiluppi, J. Fernandez-Ramil, J. Higman, H.C. Sharp, and N. Smith, "An Empirical

Study of the Evolution of an Agile-Developed Software System", Software

Engineering, 2007. ICSE 2007. 29th International Conference on , vol., no., pp. 511-

518,May2007[doi:10.1109/ICSE.2007.14]

http://www.scrumalliance.org/why-scrum

References

Page 51

[23] M.M. Lehman, “Programs, Cities, Students: Limits to Growth?”, Inaugural Lecture,

Imperial College of Science and Technology, University of London, 1974.

[24] M.M. Lehman, “Laws of Software Evolution Revisited”, Proceedings of European

Workshop on Software Process Technology, Springer-Verlag, London, UK, pp. 103-

124, October 1996.

[25] C.R. Cook and A. Roesch, “Real-Time Software Metrics”, Journal of Systems and

Software, vol. 24, no. 3, pp. 223-237, 1994

[26] V.R. Basili, L.C. Briand, S. Condon, Y.M. Kim, W. Melo and J. Valett, “Understanding

and Predicting the Process of Software Maintenance Releases”, Proc. 18th

Int’l Conf.

Software Eng., Berlin, 1996.

[27] C.F. Kemerer and S. Slaughter, “An empirical approach to studying software

evolution”, IEEE Trans. Software Engineering, vol. 25, pp. 493-509, 1999.

[28] D. Kafura, “The use of software complexity metrics in software maintenance”, IEEE

Trans. Software Engineering, vol. 13, pp. 335-343, 1987.

[29] S. Cook, He Ji and R. Harrison, “Software Evolution and Software Evolvabilty”,

University of Reading, UK, 2000.

[30] Michael W Godfrey and Qiang Tu., “Evolution in open source software: A case study”,

In Software Maintenance, 2000. Proceedings. International Conference, pp. 131-142,

IEEE, 2000

[31] G. Xie, J. Chen and I. Neamtiu, “Towards a better understanding of software evolution:

An empirical study on open source software”, In ICSM, pp. 51-60, 2009.

[32] Kalpana Johari, Arvinder Kaur, “Effect of software evolution on software metrics: An

Open source case study”, ACM SIGSOFT Software Engineering Notes, vol. 36, no. 5,

September 2011 [doi: 10.1145/2020976.2020987]

[33] Anita Ganpati, Arvind Kalia and Hardeep Signh, “Software Evolution: An Empirical

Study of Mozilla Firefox”, International Journal of Computer Technology and

Applications, vol. 3, no. 3, pp. 992-996, May-June 2012

References

Page 52

[34] Y. Lee, B. Liang and F. Wang, “Some Complexity Metrics for Object Oriented

Programs Based on Information Flow”, Proceedings: CompEuro, March, 1993, pp. 302-

310.

[35] McCabe & Associates, “McCabe Object Oriented Tool User’s Instructions”, 1994.

[36] R. Hudli, C. Hoskins and A. Hudli, “Software metrics for Object Oriented

Designs”,Proceedings of the 1994 IEEE Interbational Conference on Computer Design:

VLSI in Computer & Processors, pp. 492-495, October 1994

[37] S.R Chidamber and C.F Kemerer, “Towards a metrics Suite for object-oriented design”,

In Object Oriented Programming Systems Languages and Applications, pp. 197-211,

Phoenix, Arizone, USA, 1991.

[38] S.R Chidamber and C.F Kemerer, “A Metrics Suite for Object-Oriented design”, IEEE

Transactions on Software Engineering, Vol. 20, pp. 476-493, 1994.

[39] Henderson-Sellers, “Object-Oriented Metrics Measures of Complexity”, Upper Saddle

River, NJ:Prentice Hall, 1996.

[40] FlossAr site, http://www.flosslab.it/flosslab/en/flossar.wp

[41] FlossAr Source Code, http://www.sourceforge.net

[42] Github, https://github.com/

[43] Jenkins, http://jenkins-ci.org/

[44] Asana, https://asana.com/

[45] M. Jureczko, D. Spinellis, “Using object-oriented design metrics to predict software

defects”, In: Proceedings of the 5th International Conference on Dependability of

Computer Systems, pp. 69–81 (2010)

[46] PHP Depend, http://pdepend.org/documentation/handbook/index.html

[47] Microsoft Excel 2013, http://office.microsoft.com/en-IN

http://www.flosslab.it/flosslab/en/flossar.wp

http://www.sourceforge.net/

https://github.com/

http://jenkins-ci.org/

https://asana.com/

http://pdepend.org/documentation/handbook/index.html

http://office.microsoft.com/en-IN

APPENDIX – A

Experimental Results: Metrics Data

A.1 Experimental Results: Metrics Data of Multi-Level Marketing Software

Version LOC Number

of

Files

Number of

classes

Number of

package

Number of

Functions

Number of

Methods

Cyclomatic Complexity

/LLOC

Cyclomatic

Complexity /Number

of

Methods

Coupling between

Objects

CAM

Version 1 8979 464 32 3 64 368 0.03 1.07 2.125 0.535

Version 2 1289

28 864 52 5 58 548 0.06 2.04 2 0.675

Version 3 2589

88 2064 102 12 128 1148 0.75 6 0.4411 0.98

APPENDIX-A

Page 54

A.2 Experimental Results: Metrics Data of StudentLancer

A.2.1 StudentLancer Version 1

Class name WMC DIT NOC CBO RFC LCOM NPM LCOM3 LOC CAM IC CBM AMC

Class 1 3 2 0 3 16 0 3 0 175 1 0 0 42

Class 2 17 0 0 8 65 46 6 0.125 473 0.5147 0 0 26.7647

Class 3 2 0 0 6 17 1 2 2 54 1 0 0 26

Class 4 28 1 1 2 41 0 28 0.132 182 1 0 0 12.3451

Class 5 1 2 0 0 14 0 1 2 10 1 0 0 3

Class 6 8 0 0 7 32 8 3 0.4286 256 0.25 0 0 30.75

Class 7 2 0 0 5 10 1 1 2 154 0.6667 0 0 76

Class 8 10 0 0 9 39 45 8 2 179 0.4 0 0 16.9

Class 9 12 0 0 8 47 36 12 0.2727 233 0.4722 0 0 18.333

Class 10 2 1 0 1 2 1 2 2 2 0.75 0 0 0

Class 11 10 3 0 7 28 33 10 0.3333 39 0.55 0 0 86

Class 12 15 3 0 4 66 0 15 2 111 0.75 0 0 16

Class 13 7 0 0 5 20 21 2 1.1333 100 0.3429 0 0 12.5714

Class 14 5 0 0 9 32 10 3 2 135 0.4 0 0 26

Class 15 2 0 0 1 6 1 2 2 18 0.5 0 0 8

Class 16 4 0 0 10 28 2 2 0.6667 381 0.5 0 0 93.75

Class 17 2 0 0 5 9 1 1 2 109 0.6667 0 0 53.5

Class 18 2 0 0 5 9 1 1 2 141 0.6667 0 0 69.5

Class 19 2 0 0 5 9 1 1 2 101 0.6667 0 0 49.5

Class 20 11 0 0 20 70 7 6 0.675 863 0.5455 0 0 76.3636

Class 21 5 0 0 10 41 8 2 0.5 377 1 0 0 73.8

Class 22 17 4 0 10 82 124 17 0.75 121 0.5 0 0 40

Class 23 16 0 0 8 49 98 14 0.6667 511 1 0 0 30.875

Class 24 5 0 0 7 15 2 1 0.5 60 0.6 0 0 10.6

Class 25 7 0 0 4 14 21 1 2 49 0.6429 0 0 6

Class 26 2 0 0 5 11 1 2 2 55 1 0 0 26.5

Class 27 6 0 0 6 24 0 4 0 127 1 0 0 20

Class 28 10 0 0 13 39 45 1 2 345 0.625 0 0 33.5

Class 29 2 3 0 1 20 1 2 2 8 0.75 0 0 2.5

Class 30 7 1 1 3 20 1 7 2 30 1 0 0 11.5

Class 31 15 0 0 15 63 0 11 0.7222 850 1 0 0 55.0667

Class 32 11 0 0 9 48 21 6 0.6435 1115 0.4333 0 0 96.1818

Class 33 4 0 0 10 25 4 2 0.3333 114 1 0 0 27

Class 34 29 2 1 6 60 4 29 0.3333 205 1 0 0 28

Class 35 2 0 0 6 23 1 2 2 160 1 0 0 79

Class 36 4 0 0 11 42 0 2 0.1667 516 1 0 0 127

Class 37 6 0 0 16 59 3 2 0.3 293 0.375 0 0 47.5

Class 38 8 0 0 13 49 16 2 0.4762 252 0.2708 0 0 30.125

Class 39 4 0 0 9 28 4 2 0.6667 204 0.625 0 0 48

APPENDIX-A

Page 55



Class 1 3 2 0 3 16 0 3 0 175 1 0 0 42

Class 2 17 0 0 8 65 46 6 0.125 473 0.5147 0 0 26.7647

Class 3 2 0 0 6 17 1 2 2 54 1 0 0 26

Class 4 28 1 1 2 41 0 28 0.132 182 1 0 0 12.3451

Class 5 1 2 0 0 14 0 1 2 10 1 0 0 3

Class 6 8 0 0 7 32 8 3 0.4286 256 0.25 0 0 30.75

Class 7 2 0 0 5 10 1 1 2 154 0.6667 0 0 76

Class 8 10 0 0 9 39 45 8 2 179 0.4 0 0 16.9

Class 9 12 0 0 8 47 36 12 0.2727 233 0.4722 0 0 18.333

Class 10 2 1 0 1 2 1 2 2 2 0.75 0 0 0

Class 11 10 3 0 7 28 33 10 0.3333 39 0.55 0 0 86

Class 12 15 3 0 4 66 0 15 2 111 0.75 0 0 16

Class 13 7 0 0 5 20 21 2 1.1333 100 0.3429 0 0 12.5714

Class 14 5 0 0 9 32 10 3 2 135 0.4 0 0 26

Class 15 2 0 0 1 6 1 2 2 18 0.5 0 0 8

Class 16 4 0 0 10 28 2 2 0.6667 381 0.5 0 0 93.75

Class 17 2 0 0 5 9 1 1 2 109 0.6667 0 0 53.5

Class 18 2 0 0 5 9 1 1 2 141 0.6667 0 0 69.5

Class 19 2 0 0 5 9 1 1 2 101 0.6667 0 0 49.5

Class 20 11 0 0 20 70 7 6 0.675 863 0.5455 0 0 76.3636

Class 21 5 0 0 10 41 8 2 0.5 377 1 0 0 73.8

Class 22 17 4 0 10 82 124 17 0.75 121 0.5 0 0 40

Class 23 16 0 0 8 49 98 14 0.6667 511 1 0 0 30.875

Class 24 5 0 0 7 15 2 1 0.5 60 0.6 0 0 10.6

Class 25 7 0 0 4 14 21 1 2 49 0.6429 0 0 6

Class 26 2 0 0 5 11 1 2 2 55 1 0 0 26.5

Class 27 6 0 0 6 24 0 4 0 127 1 0 0 20

Class 28 10 0 0 13 39 45 1 2 345 0.625 0 0 33.5

Class 29 2 3 0 1 20 1 2 2 8 0.75 0 0 2.5

Class 30 7 1 1 3 20 1 7 2 30 1 0 0 11.5

Class 31 15 0 0 15 63 0 11 0.7222 850 1 0 0 55.0667

Class 32 11 0 0 9 48 21 6 0.6435 1115 0.4333 0 0 96.1818

Class 33 4 0 0 10 25 4 2 0.3333 114 1 0 0 27

Class 34 29 2 1 6 60 4 29 0.3333 205 1 0 0 28

Class 35 2 0 0 6 23 1 2 2 160 1 0 0 79

Class 36 4 0 0 11 42 0 2 0.1667 516 1 0 0 127

Class 37 6 0 0 16 59 3 2 0.3 293 0.375 0 0 47.5

Class 38 8 0 0 13 49 16 2 0.4762 252 0.2708 0 0 30.125

Class 39 4 0 0 9 28 4 2 0.6667 204 0.625 0 0 48

Class 40 15 1 0 9 28 21 2 0.6435 448 0.4333 0 0 96.1818

Class 41 18 1 0 11 31 6 2 0.567 544 0.157 0 0 98.125

Class 42 12 1 2 9 25 0 2 0.35 322 0.625 0 0 32

APPENDIX-A

Page 56

Class 43 6 1 2 2 19 19 2 0.8333 122 0.5 0 0 16.1429

Class 44 1 1 0 2 14 1 1 2 4 0.625 0 0 1

Class 45 1 1 2 2 14 1 1 2 6 0.625 0 0 1.5

Class 46 1 1 2 2 14 1 1 2 5 0.625 0 0 1.5

Class 47 1 1 2 2 14 1 1 2 6 0.625 0 0 1.5

Class 48 1 1 2 2 14 1 1 2 5 0.625 0 0 1.5

Class 49 1 1 0 2 14 1 1 2 4 0.625 0 0 1

Class 50 25 4 0 13 115 24 25 0.625 2112 0.3333 0 0 100

Class 51 11 0 0 6 62 55 11 1.0111 1174 0.7455 0 0 104.9091

Class 52 9 0 0 13 60 24 6 0.625 910 0.3333 0 0 100

Class 53 7 0 0 9 32 21 2 2 278 0.8571 0 0 38.7143

Class 54 4 0 0 5 15 6 3 1.3333 79 0.6875 0 0 18.25

Class 55 14 0 0 13 51 77 9 0.8173 393 0.3214 0 0 26.5

Class 56 7 0 0 5 17 15 4 2 155 0.5238 0 0 21.1429

Class 57 12 0 0 7 44 54 10 0.9273 754 0.5065 0 0 61

Class 58 8 0 0 7 32 8 3 0.4286 256 0.25 0 0 30.75

Class 59 12 0 0 7 44 54 10 0.9273 754 0.5065 0 0 61

Class 60 2 0 0 4 17 1 2 2 69 1 0 0 33.5

Class 61 1 3 0 0 2 0 1 2 5 1 0 0 3

Class 62 3 0 0 5 13 3 2 2 108 0.5558 0 0 35

Class 63 2 0 0 5 10 1 1 2 178 0.6667 0 0 88

Class 64 4 0 0 10 33 6 2 2 214 0.75 0 0 52.5

Class 65 4 1 0 3 5 4 4 0.8889 24 0.4375 0 0 4.25

Class 66 2 0 0 4 18 1 2 1 76 1 0 0 36

APPENDIX-A

Page 57



Class 1 3 2 0 3 16 0 3 0 175 1 0 0 42

Class 2 17 0 0 8 65 46 6 0.125 473 0.5147 0 0 26.7647

Class 3 2 0 0 6 17 1 2 2 54 1 0 0 26

Class 4 28 1 1 2 41 0 28 0.132 182 1 0 0 12.3451

Class 5 1 2 0 0 14 0 1 2 10 1 0 0 3

Class 6 8 0 0 7 32 8 3 0.4286 256 0.25 0 0 30.75

Class 7 2 0 0 5 10 1 1 2 154 0.6667 0 0 76

Class 8 10 0 0 9 39 45 8 2 179 0.4 0 0 16.9

Class 9 12 0 0 8 47 36 12 0.2727 233 0.4722 0 0 18.333

Class 10 2 1 0 1 2 1 2 2 2 0.75 0 0 0

Class 11 10 3 0 7 28 33 10 0.3333 39 0.55 0 0 86

Class 12 15 3 0 4 66 0 15 2 111 0.75 0 0 16

Class 13 7 0 0 5 20 21 2 1.1333 100 0.3429 0 0 12.5714

Class 14 5 0 0 9 32 10 3 2 135 0.4 0 0 26

Class 15 2 0 0 1 6 1 2 2 18 0.5 0 0 8

Class 16 4 0 0 10 28 2 2 0.6667 381 0.5 0 0 93.75

Class 17 2 0 0 5 9 1 1 2 109 0.6667 0 0 53.5

Class 18 2 0 0 5 9 1 1 2 141 0.6667 0 0 69.5

Class 19 2 0 0 5 9 1 1 2 101 0.6667 0 0 49.5

Class 20 11 0 0 20 70 7 6 0.675 863 0.5455 0 0 76.3636

Class 21 5 0 0 10 41 8 2 0.5 377 1 0 0 73.8

Class 22 17 4 0 10 82 124 17 0.75 121 0.5 0 0 40

Class 23 16 0 0 8 49 98 14 0.6667 511 1 0 0 30.875

Class 24 5 0 0 7 15 2 1 0.5 60 0.6 0 0 10.6

Class 25 7 0 0 4 14 21 1 2 49 0.6429 0 0 6

Class 26 2 0 0 5 11 1 2 2 55 1 0 0 26.5

Class 27 6 0 0 6 24 0 4 0 127 1 0 0 20

Class 28 10 0 0 13 39 45 1 2 345 0.625 0 0 33.5

Class 29 2 3 0 1 20 1 2 2 8 0.75 0 0 2.5

Class 30 7 1 1 3 20 1 7 2 30 1 0 0 11.5

Class 31 15 0 0 15 63 0 11 0.7222 850 1 0 0 55.0667

Class 32 11 0 0 9 48 21 6 0.6435 1115 0.4333 0 0 96.1818

Class 33 4 0 0 10 25 4 2 0.3333 114 1 0 0 27

Class 34 29 2 1 6 60 4 29 0.3333 205 1 0 0 28

Class 35 2 0 0 6 23 1 2 2 160 1 0 0 79

Class 36 4 0 0 11 42 0 2 0.1667 516 1 0 0 127

Class 37 6 0 0 16 59 3 2 0.3 293 0.375 0 0 47.5

Class 38 8 0 0 13 49 16 2 0.4762 252 0.2708 0 0 30.125

Class 39 4 0 0 9 28 4 2 0.6667 204 0.625 0 0 48

Class 40 15 1 0 9 28 21 2 0.6435 448 0.4333 0 0 96.1818

Class 41 18 1 0 11 31 6 2 0.567 544 0.157 0 0 98.125

Class 42 12 1 2 9 25 0 2 0.35 322 0.625 0 0 32

APPENDIX-A

Page 58

Class 43 6 1 2 2 19 19 2 0.8333 122 0.5 0 0 16.1429

Class 44 1 1 0 2 14 1 1 2 4 0.625 0 0 1

Class 45 1 1 2 2 14 1 1 2 6 0.625 0 0 1.5

Class 46 1 1 2 2 14 1 1 2 5 0.625 0 0 1.5

Class 47 1 1 2 2 14 1 1 2 6 0.625 0 0 1.5

Class 48 1 1 2 2 14 1 1 2 5 0.625 0 0 1.5

Class 49 1 1 0 2 14 1 1 2 4 0.625 0 0 1

Class 50 25 4 0 13 115 24 25 0.625 2112 0.3333 0 0 100

Class 51 11 0 0 6 62 55 11 1.0111 1174 0.7455 0 0 104.9091

Class 52 9 0 0 13 60 24 6 0.625 910 0.3333 0 0 100

Class 53 7 0 0 9 32 21 2 2 278 0.8571 0 0 38.7143

Class 54 4 0 0 5 15 6 3 1.3333 79 0.6875 0 0 18.25

Class 55 14 0 0 13 51 77 9 0.8173 393 0.3214 0 0 26.5

Class 56 7 0 0 5 17 15 4 2 155 0.5238 0 0 21.1429

Class 57 12 0 0 7 44 54 10 0.9273 754 0.5065 0 0 61

Class 58 8 0 0 7 32 8 3 0.4286 256 0.25 0 0 30.75

Class 59 12 0 0 7 44 54 10 0.9273 754 0.5065 0 0 61

Class 60 2 0 0 4 17 1 2 2 69 1 0 0 33.5

Class 61 1 3 0 0 2 0 1 2 5 1 0 0 3

Class 62 3 0 0 5 13 3 2 2 108 0.5558 0 0 35

Class 63 2 0 0 5 10 1 1 2 178 0.6667 0 0 88

Class 64 4 0 0 10 33 6 2 2 214 0.75 0 0 52.5

Class 65 4 1 0 3 5 4 4 0.8889 24 0.4375 0 0 4.25

Class 66 2 0 0 4 18 1 2 1 76 1 0 0 36

Class 67 18 1 0 11 31 6 2 0.567 544 0.157 0 0 98.125

Class 68 25 4 0 13 115 24 25 0.625 2112 0.3333 0 0 100

Class 69 4 0 0 9 28 4 2 0.6667 204 0.625 0 0 48

Class 70 27 1 0 0 28 325 27 0.9615 134 0.3704 0 0 3.4815

Class 71 20 1 0 5 47 88 20 0.7368 177 0.3 1 1 7.7

Class 72 12 0 0 9 37 60 12 0.2727 178 0.4167 0 0 13.75

Class 73 23 2 0 7 56 167 4 0.8106 448 0.2826 1 2 18.2174

Class 74 3 0 0 4 21 3 2 1 107 0.5833 0 0 34.3333

Class 75 6 0 0 13 44 9 3 0.65 279 0.5 0 0 44.8333

Class 76 3 1 0 7 35 0 2 0.6667 177 0.6667 0 0 56

Class 77 14 0 0 6 60 91 7 1 876 0.5204 0 0 60.2857

Class 78 4 0 0 4 31 6 1 2 167 0.625 0 0 40.75

Class 79 19 1 0 3 42 133 14 0.881 240 0.1789 0 0 11.2682

Class 80 8 1 0 4 11 24 6 0.7857 39 0.2708 0 0 3.625

Class 81 12 0 0 15 51 0 12 0.1818 223 0.2407 0 0 17.5

Class 82 6 0 0 4 23 15 1 1 237 0.6667 0 0 37.8333

Class 83 3 0 0 3 13 3 3 1 104 0.6667 0 0 33

Class 84 9 0 0 4 38 36 6 1 465 0.6667 0 0 49.8889

Class 85 13 0 0 7 59 0 12 0.5625 474 0.2949 0 0 35.1538

Class 86 3 0 0 1 8 3 3 2 26 1 0 0 7.6667

Class 87 7 0 0 9 25 13 5 0.6667 119 0.4286 0 0 14.4286

APPENDIX-A

Page 59

Class 88 9 0 0 12 24 6 9 0.7679 266 0.5556 0 0 16.6667

Class 89 8 0 0 7 26 2 8 0.619 354 0.625 0 0 17.875

Class 90 5 1 0 12 30 10 2 2 188 0.6 0 0 36.6

Class 91 4 4 0 1 13 6 4 2 47 0.5 0 0 11.5

Class 92 1 0 0 10 18 0 0.8095 42 1 0 0 3.875 0

Class 93 24 0 0 7 43 208 23 0.9275 310 0.2031 0 0 7.6667

APPENDIX-A

Page 60

A.3 Experimental Results: Metrics Data of FlossAr

A.3.1 FlossAr Version 1.0


BaseInstallFrame 9 6 0 0 49 0 8 0.6429 355 0.4444 0 0 37.6667

InstallController 22 1 0 7 82 205 16 0.8571 689 0.1189 0 0 29.7273

InstallException 4 3 0 0 5 0 4 0.3333 96 0.625 1 1 22.5

Installpanel 4 5 0 0 28 0 3 0 136 0.75 1 1 32.75

InstallPerform 16 1 0 1 68 54 14 0.902 920 0.3906 0 0 55.4375

IntroPanel 2 5 0 0 24 0 1 0 98 0.75 0 0 47.5

LicensePanel$1 2 1 0 1 4 0 1 0 14 0.6667 0 0 5.5

APPENDIX-A

Page 61



BaseInstallFrame 9 6 0 0 49 0 8 0.6429 355 0.4444 0 0 37.6667

InstallController 22 1 0 7 82 205 16 0.8571 689 0.1189 0 0 29.7273

InstallException 4 3 0 0 5 0 4 0.3333 96 0.625 1 1 22.5

Installpanel 4 5 0 0 28 0 3 0 136 0.75 1 1 32.75

InstallPerform 16 1 0 1 68 54 14 0.902 920 0.3906 0 0 55.4375

IntroPanel 2 5 0 0 24 0 1 0 98 0.75 0 0 47.5

LicensePanel$1 2 1 0 1 4 0 1 0 14 0.6667 0 0 5.5

LicensePanel 7 5 0 1 49 13 4 0.6111 270 0.3143 0 0 31.7143

OptionsPanlel$1 2 1 0 1 4 0 1 0 14 0.6667 0 0 5.5

OptionsPanel 6 5 0 1 52 7 3 0.4933 598 0.375 0 0 96.1667

APPENDIX-A

Page 62


Class name

WM

C

DIT

NO

C

CB

O

RF

C

LC

OM

NP

M

LC

OM

3

LO

C

CA

M

IC

CB

M

AM

C

AbstractCategory 13 1 0 0 18 66 12 0.8958 65 0.3462 0 0 3.6923

AbstractCategoryDAO 10 0 0 5 24 45 5 2 219 0.3833 0 0 20.9

AbstractCategoryManager 12 0 0 5 48 56 6 0.5152 321 0.2262 0 0 25.5

CategoryDAOInterface 4 1 0 3 4 6 4 2 4 0.75 0 0 0

Category 12 0 0 2 35 40 12 0.5152 224 0.3542 0 0 17.4167

CategoryDAO 7 0 0 9 28 21 2 1.1667 127 0.3429 0 0 16.4286

CategoryManager 7 0 0 11 33 21 5 2 160 0.3095 0 0 21.8571

ResourceCategory 5 0 0 1 15 8 5 0.25 54 0.6 0 0 9.6

ResourceCategoryDAO 7 0 0 5 20 21 2 1.1333 100 0.3429 0 0 12.5714

ResourceCategoryManager 5 0 0 9 32 10 3 2 135 0.4 0 0 26

PublicContentChangedEvent 7 1 0 4 9 17 7 1.0556 37 0.3571 0 0 3.4286

PublicContentChangedObserver 1 1 0 2 1 0 1 2 1 1 0 0 0

Content 35 1 0 4 69 455 34 0.9412 394 0.3 0 0 9.6857

ContentRecordVO 27 1 0 0 28 325 27 0.9615 134 0.3704 0 0 3.4815

ContentWrapper 20 1 0 5 47 88 20 0.7368 177 0.3 1 1 7.7

SmallContentType 6 1 0 0 8 7 6 0.7 32 0.5 0 0 4

SymbolicLink 13 1 0 0 27 32 12 0.9083 277 0.6923 0 0 19.5385

HypertextAttributeUtil 2 1 0 1 10 1 2 2 84 0.5 0 0 41

AbstractAttribute 31 1 0 5 55 431 30 0.9111 347 0.2581 0 0 9.8065

AbstractComplexAttribute 7 0 0 4 8 21 7 2 16 0.3571 0 0 1.2857

AbstractListAttribute 8 0 0 6 22 26 7 0.5714 79 0.3 0 0 8.75

AbstractMLAttribute 2 0 0 1 3 1 2 2 7 1 0 0 2.5

AbstractResourceAttribute 10 0 0 12 50 39 9 0.7778 210 0.35 0 0 19

AttachAttribute 2 0 0 3 6 1 2 2 21 1 0 0 9.5

AttributeInterface 30 1 0 6 30 435 30 1.0345 40 0.2444 0 0 0

BooleanAttribute 10 0 0 6 22 33 10 0.5556 84 0.55 0 0 7.3

DateAttribute 16 0 0 6 32 116 15 0.7667 146 0.3125 0 0 8

HypertextAttribute 10 0 0 9 39 45 8 2 179 0.4 0 0 16.9

ImageAttribute 2 0 0 3 6 1 2 2 22 0.75 0 0 10

LinkAttribute 10 0 0 8 40 33 10 0.4444 260 0.4 0 0 24.9

ListAttribute 12 0 0 8 47 36 12 0.2727 233 0.4722 0 0 18.333

ListAttributeInterface 2 1 0 1 2 1 2 2 2 0.75 0 0 0

LongTextAttribute 1 0 0 1 2 0 1 2 4 1 0 0 3

MonoLinkAttribute 8 0 0 7 24 16 8 0.5714 186 0.5625 0 0 22.125

MonoListAttribute 12 0 0 9 37 60 12 0.2727 178 0.4167 0 0 13.75

MonoTextAttribute 10 0 0 7 22 33 10 0.3333 97 0.55 0 0 8.6

NumberAttribute 11 0 0 6 27 51 11 0.7 111 0.3939 0 0 8.9091

ResourceAttributeInterface 2 1 0 2 2 1 2 2 2 0.75 0 0 0

TableAttribute 34 0 0 11 60 351 23 0.7273 954 0.2206 0 0 26.8824

TextAttribute 13 0 0 8 38 66 12 0.3333 188 0.3269 0 0 13.3846

APPENDIX-A

Page 63

AttributeTypeDOM 4 1 0 10 37 0 2 0.4444 173 0.5 0 0 41.5

ContentDOM 13 1 0 3 23 0 11 0.9259 190 0.5833 0 0 12.9231

ContentHandler 23 2 0 7 56 167 4 0.8106 448 0.2826 1 2 18.2174

ContentTypeDOM 10 1 0 12 60 21 3 0.7619 376 0.3143 0 0 35.9

AbstarctAttributeHandler 7 0 0 4 8 21 7 2 16 0.3571 0 0 1.2857

AbstarctMLAttributeHandler 3 0 0 1 4 1 3 0.5 14 0.6667 0 0 3.3333

AttributeHandlerInterface 5 1 0 2 5 10 5 2 5 0.4 0 0 0

BooleanAttributeHandler 5 0 0 3 11 10 3 2 43 0.6 0 0 7.6

DateAttributeHandler 5 0 0 5 12 10 3 2 44 0.6 0 0 7.8

HypertextAttributeHandler 3 0 0 1 7 3 3 2 23 0.5833 0 0 6.6667

LinkAttributeHandler 11 0 0 4 25 47 3 0.775 196 0.5909 0 0 16.4545

ListAttributeHandler 9 0 0 6 30 32 4 0.75 184 0.5556 0 0 19.1111

MonolinkAttributeHandler 11 0 0 4 25 47 3 0.775 196 0.5909 0 0 16.4545

MonoTextAttributeHandler 5 0 0 3 10 10 3 2 38 0.6 0 0 6.6

NumberAttributeHandler 5 0 0 3 11 10 3 2 45 0.6 0 0 8

ResourceAttributeHandler 5 0 0 8 17 10 3 2 69 0.55 0 0 12.8

TableAttributeHandler 16 0 0 6 48 94 4 0.65 396 0.5156 0 0 23.5

TextAttributeHandler 5 0 0 3 13 10 3 2 53 0.6 0 0 9.6

ContentAttributeIterator 5 1 0 3 17 2 4 0.625 78 0.4667 0 0 14.2

ContentModel 11 1 0 0 12 45 11 0.9 54 0.4848 0 0 3.4545

ContentModelDAO 3 0 0 4 21 3 2 1 107 0.5833 0 0 34.3333

ContentModelManager 5 0 0 5 29 0 4 0.5 114 0.36 0 0 21.4

ContentPageMapper 6 1 0 0 12 0 6 0 44 0.8333 0 0 6.1667

ContentPageMapperManager 8 0 0 11 35 26 6 0.2857 153 0.2708 0 0 18

AbstractContentDispenser 2 0 0 2 3 1 2 2 5 0.625 0 0 1.5

BaseContentDispenser 6 0 0 16 45 5 3 0.5 323 0.3542 0 0 51.8333

ContentAuthorizationInfo 5 1 0 1 9 0 3 0.5 107 0.45 0 0 20

LinkResolverManager 6 0 0 13 44 9 3 0.65 279 0.5 0 0 44.8333

AbstractContentRenderer 2 0 0 2 3 1 2 2 5 0.625 0 0 1.5

BaseContentRenderer 6 0 0 15 36 11 5 0.7 191 0.3125 0 0 30.5

AbstractMonoInstanceResouce 6 0 0 4 12 13 6 0.6 34 0.4444 0 0 4.5

AbstractMultiInstanceResouce 6 0 0 4 16 13 6 0.6 50 0.5556 0 0 7.1667

AbstractResouce 24 1 0 4 54 242 20 0.8315 298 0.2917 0 0 11.0833

AttachResouce 4 0 0 2 7 4 3 0.6667 58 1 0 0 13.25

ImageResouce 7 0 0 2 25 19 6 0.8333 121 0.5 0 0 16.1429

ImageResouceDimension 7 1 0 0 8 15 7 0.8333 34 0.7143 0 0 3.4286

ResouceInstance 16 1 0 2 32 100 13 0.8 283 0.375 0 0 16.3125

ResouceInterface 22 1 0 2 22 231 22 2 22 0.2424 0 0 0

ResouceRecordVO 11 1 0 0 12 45 11 0.9 54 0.4848 0 0 3.4545

ImageDimensionDOM 3 1 0 7 35 0 2 0.6667 177 0.6667 0 0 56

ResourceDOM 10 1 0 3 20 0 8 0.8889 142 0.5556 0 0 12.5

ResourceHandler 11 2 0 6 41 19 4 0.72 284 0.3295 1 2 24.3636

ResourceTypeDOM 4 1 0 8 34 0 2 0.4167 178 0.5 0 0 42.5

ResourceDataBean 7 1 0 0 7 21 7 2 7 1 0 0 0

ResourceInstanceFileHelper 11 1 0 11 78 55 3 2 622 0.281 0 0 55.5455

APPENDIX-A

Page 64

ResourceDAO 14 0 0 6 60 91 7 1 876 0.5204 0 0 60.2857

ResourceManager 18 0 0 14 83 93 14 0.6471 688 0.2099 0 0 37.0556

HtmlHandler 2 1 0 0 4 1 2 2 12 0.75 0 0 5

IndexableInterface 1 1 0 0 1 0 1 2 1 1 0 0 0

IndexerDAO 12 1 0 10 43 0 9 0.4773 378 0.2159 0 0 30.1667

SearchEngineManager 20 0 0 21 80 116 17 0.8553 557 0.15 0 0 26.65

SearcherDAO 9 1 0 14 35 34 5 0.5 290 0.3333 0 0 31.1111

ConfigLoader 1 1 0 1 1 0 1 2 1 1 0 0 0

ControllerServlet 4 0 0 4 31 6 1 2 167 0.625 0 0 40.75

ResourceWardenServlet 6 0 0 12 62 15 1 2 366 0.3 0 0 60

StartupListener 10 1 0 4 36 45 4 1 321 0.3143 0 0 31

RequestContext 11 1 0 1 17 37 11 0.9286 83 0.2468 0 0 5.9091

SysAnagrafeContext 3 0 0 2 7 1 3 0.5 32 0.6667 0 0 9.3333

SysAnagrafeContextFactory 3 0 0 5 9 3 2 2 29 0.6667 0 0 8.6667

SystemConstants 0 1 0 0 0 0 0 2 89 0 0 0 0

SystemContext 19 1 0 3 42 133 14 0.881 240 0.1789 0 0 11.2682

SystemContextFactory 7 1 0 7 53 21 2 2 283 0.2714 0 0 39.4286

ApsException 2 3 0 0 4 1 2 2 11 0.8333 0 0 0.45

ApsSystemException 2 0 0 1 4 1 2 2 11 0.8333 0 0 4.5

AbstractDAO 3 1 0 2 8 3 1 2 31 0.5 0 0 9.3333

AbstractService 8 1 0 4 11 24 6 0.7857 39 0.2708 0 0 3.625

BaseConfigManager 8 0 0 10 44 16 4 0.6429 195 0.4688 0 0 23.125

ConfigInterface 2 1 0 0 2 1 2 2 2 1 0 0 0

ConfigItemDAO 3 0 0 3 22 3 3 1 177 0.6 0 0 57.3333

CacheManager 12 0 0 15 51 0 12 0.1818 223 0.2407 0 0 17.5

ControllerManager 6 0 0 5 23 0 5 1.075 134 0.3333 0 0 20

AbstractControlService 4 1 0 6 22 4 2 0.7778 88 0.5625 0 0 20.25

Authenticator 4 0 0 8 29 4 3 0.6667 191 0.375 0 0 46.25

ControlServiceInterface 2 1 0 2 2 1 2 2 2 0.625 0 0 0

ErrorManager 4 0 0 5 14 4 3 0.3333 96 0.5 0 0 22.5

Executor 3 1 0 3 9 1 3 0.5 49 0.5 0 0 15

RequestDebugger 2 0 0 2 12 1 2 2 40 0.6667 0 0 19

RequestValidator 4 1 0 8 24 4 3 0.6667 142 0.5 0 0 33.25

Group 7 1 0 0 9 13 7 0.9583 37 0.4762 0 0 3.7143

GroupDAO 6 0 0 4 23 15 1 1 237 0.6667 0 0 37.8333

GroupManager 9 0 0 5 41 0 8 0.3125 232 0.3333 0 0 24.5556

GroupsUtilizer 1 1 0 0 1 0 1 2 1 1 0 0 0

I18nDAO 3 0 0 4 13 3 2 1 82 0.5833 0 0 26

I18nManager 5 0 0 4 25 4 3 0.5 101 0.4 0 0 19

I18nManagerWrapper 2 1 0 4 5 0 2 0 32 0.8333 0 0 14

KeyGeneratorDAO 3 0 0 3 13 3 3 1 104 0.6667 0 0 33

KeyGeneratorManager 5 0 0 4 23 0 3 0.25 130 0.4667 0 0 24.6

Lang 7 1 0 0 8 11 7 0.7778 37 0.4762 0 0 3.8571

LangManager 7 0 0 8 44 11 5 0.6667 193 0.3571 0 0 26.1429

ApsEvent 2 1 0 1 2 1 2 2 2 0.75 0 0 0

APPENDIX-A

Page 65

NotifyManger 5 0 0 5 34 4 3 0.25 164 0.36 0 0 31.6

ObserverServices 1 1 0 1 1 0 1 2 1 1 0 0 0

Page 24 1 0 4 32 226 23 0.9304 169 0.1713 0 0 5.625

PageDAO 14 0 0 11 78 91 8 1.0692 872 0.3968 0 0 60.5714

PageManager 15 0 0 8 64 57 10 0.5238 578 0.2667 0 0 37.3333

Showlet 7 1 0 2 8 15 7 0.8333 34 0.3571 0 0 3.4286

PageChangedEvent 5 1 0 4 7 8 5 0.75 23 0.4667 0 0 3.4

PageEventObserver 1 1 0 2 1 0 1 2 1 1 0 0 0

PageModel 11 1 0 1 12 37 11 0.86 61 0.2909 0 0 4.0909

PageModelDAO 3 0 0 6 24 3 2 1 112 0.5833 0 0 36

PageModelDOM 8 1 0 11 40 16 4 0.8878 288 0.425 0 0 33.25

PageModelManager 5 0 0 5 23 0 4 0.5 79 0.4 0 0 14.4

Permission 5 1 0 0 6 6 5 0.75 24 0.7 0 0 3.4

PermissionDAO 7 0 0 4 24 21 6 1 242 0.5238 0 0 33

Role 11 1 0 0 22 13 11 0.6667 98 0.5152 0 0 7.6364

RoleDAO 9 0 0 4 38 36 6 1 465 0.6667 0 0 49.8889

RoleManager 13 0 0 7 59 0 12 0.5625 474 0.2949 0 0 35.1538

ShowletType 12 1 0 0 14 52 12 0.8909 62 0.375 0 0 3.75

ShowletTypeDAO 3 0 0 5 24 3 2 1 112 0.5833 0 0 36

ShowletTypeDOM 5 1 0 6 27 0 4 0.6667 136 0.6 0 0 25.6

ShowletTypeManager 5 0 0 5 26 0 4 0.5 89 0.4 0 0 16.4

ShowletTypeParameter 5 1 0 0 6 6 5 0.75 24 0.7 0 0 3.4

AbstractURLManager 4 0 0 3 21 6 3 2 73 0.5 0 0 17.25

PageURL 11 1 0 4 25 35 11 0.82 113 0.2727 0 0 8.8182

URLManager 3 0 0 11 24 1 3 0.5 118 0.4667 0 0 37.333

User 14 1 0 1 25 57 14 0.8308 144 0.3571 0 0 8.9286

UserDAO 13 0 0 5 46 78 1 1 668 0.5495 0 0 49.6154

UserManager 10 0 0 7 39 0 10 0.5556 338 0.36 0 0 32.5

ActionURLTag 5 0 0 6 23 4 5 0.5 126 0.6 0 0 24

CheckPermissionTag 4 0 0 3 13 0 4 0.3333 70 0.625 0 0 16.25

ContentListTag 17 0 0 3 31 64 17 0.75 198 0.7059 0 0 10.2353

ContentNegotiationTag 9 0 0 2 23 18 8 0.75 118 0.6667 0 0 11.7778

ContentTag 10 0 0 3 21 9 9 0.4815 108 0.65 0 0 9.5

CSSHeadInfoOutputterTag 3 0 0 1 8 3 3 2 26 1 0 0 7.6667

CssURLTag 4 0 0 6 16 0 4 0.7778 87 0.625 0 0 20

ExecShowletTag$ResponseWrapper 3 0 0 1 7 0 3 0.5 27 0.5556 0 0 7.3333

ExecShowletTag 8 0 0 12 49 22 2 1 429 0.375 0 0 52.5

HeadInfoOutputterTag 7 0 0 2 18 0 7 0.5556 97 0.5714 0 0 12.4286

HeadInfoTag 9 0 0 3 18 4 9 0.625 106 0.6667 0 0 10.4444

I18nTag 11 0 0 7 28 17 10 0.65 191 0.3636 0 0 16

ImgURLTag 2 0 0 1 4 1 2 2 10 1 0 0 4

InfoTag 10 0 0 6 27 13 10 0.6944 150 0.65 0 0 13.6

NavigatorCodeTag 5 0 0 3 13 4 5 0.5 49 0.6 0 0 8.6

NavigatorDescrTag 7 0 0 9 25 13 5 0.6667 109 0.4286 0 0 14.4286

NavigatorLevelTag 5 0 0 2 13 4 5 0.5 49 0.6 0 0 8.6

APPENDIX-A

Page 66

NavigatorTag 9 0 0 12 24 6 9 0.7679 166 0.5556 0 0 16.6667

NavigatorTitleTag 3 0 0 4 10 3 2 2 49 0.6667 0 0 15.3333

NavigatorURLTag 5 0 0 4 15 4 5 0.5 55 0.6 0 0 9.8

PageBuilderTag 2 0 0 4 19 1 2 2 86 1 0 0 42

PagerTag 14 0 0 3 28 61 14 0.6923 141 0.3393 0 0 8.7143

PageTitleTag 8 0 0 7 26 2 8 0.619 154 0.625 0 0 17.875

ResourceURLTag 6 0 0 3 20 3 6 0.6 81 0.6667 0 0 12.1667

SearcherTag 4 0 0 3 17 0 4 0.3333 70 0.625 0 0 16.25

ShowletTag 4 0 0 3 21 0 4 0.3333 103 0.625 0 0 24.5

URLParTag 6 0 0 1 14 3 6 0.6 64 0.6667 0 0 9.3333

URLTag 15 0 0 6 33 43 15 0.7857 200 0.4667 0 0 11.9333

ContentListTagHelper 6 1 0 14 41 15 2 2 361 0.5333 0 0 59.1667

ContentTagHelper 5 1 0 12 30 10 2 2 188 0.6 0 0 36.6

PagerTagHelper 7 1 0 6 30 21 2 2 251 0.4286 0 0 34.8571

SearcherTagHelper 2 1 0 7 15 1 2 2 43 0.6667 0 0 20.5

HeadInfoContainer 3 1 0 0 9 0 3 0 38 0.5556 0 0 11.3333

NavigatorParser 8 1 0 6 39 28 2 2 595 0.4219 0 0 73.375

NavigatorTarget 5 1 0 1 6 0 5 0.5 30 0.6 0 0 4.6

PagerVO 21 1 0 0 26 192 13 0.8889 169 0.5079 0 0 6.619

ApsProperties 4 4 0 1 13 6 4 2 50 0.5 0 0 11.5

ApsPropertiesDOM 7 1 0 6 33 3 4 0.7333 183 0.4762 0 0 24.4286

DateConverter 3 1 0 1 13 3 3 2 51 0.4167 0 0 16

ForJLogger 19 1 0 1 28 0 19 0 164 0.5 0 0 7.5789

MapSupportRule 4 0 0 2 9 0 4 0.5 35 0.6667 0 0 7.25

BaseAdminAction 5 0 0 11 31 10 2 2 237 0.8 0 0 46.4

CurrentUserAction 3 0 0 10 26 3 2 2 136 0.6667 0 0 44.3333

CurrentUserActionForm 11 0 0 5 23 31 11 0.725 121 0.4318 0 0 9.6364

CategoryAction 9 0 0 16 67 36 2 2 542 0.8148 0 0 59.2222

CategoryActionForm 13 0 0 13 38 48 11 0.8611 205 0.2596 0 0 14.3077

CategoryActionHelper 4 0 0 7 22 6 3 2 101 0.4167 0 0 24.25

ContentAction 10 0 0 15 62 45 2 1.1111 646 0.9 0 0 63.5

ContentActionForm 3 0 0 10 28 3 2 2 131 0.6 0 0 42.6667

ContentFindAction 9 0 0 13 57 36 2 2 657 0.5802 0 0 72

HypertextAttributeAction 4 0 0 10 25 6 2 2 142 0.625 0 0 34.5

LinkAttributeAction 12 0 0 17 68 66 2 2 792 0.6429 0 0 65

ListAttributeAction 6 0 0 12 45 15 2 2 421 0.5185 0 0 69.1667

ResourceAttributeAction 10 0 0 17 48 45 2 2 557 0.5 0 0 54.7

TableAttributeAction 10 0 0 11 40 45 2 2 446 0.9 0 0 43.6

AttributeActionHelper 5 1 0 6 19 10 4 2 85 0.3677 0 0 16

TableAttributeHelper 3 1 0 8 14 3 3 2 51 0.5 0 0 16

AbstractAttributeManager 19 1 0 7 37 171 4 1 222 0.5564 0 0 10.5263

AbstractMonoLangAttributeManager 6 0 0 5 24 15 1 2 136 0.5556 0 0 21.6667

AbstractMultiLangAttributeManager 6 0 0 7 30 15 1 2 214 0.5476 0 0 34.6667

AttributeManagerInterface 3 1 0 3 3 3 3 2 3 0.9167 0 0 0

AttributeTracer 22 1 0 1 23 133 22 0.8571 177 0.3636 0 0 6.5909

APPENDIX-A

Page 67

BooleanAttributeManager 3 0 0 3 7 3 1 2 18 0.6667 0 0 5

DateAttributeManager 5 0 0 7 30 10 1 2 166 0.4 0 0 32.2

HypertextAttributeManager 10 0 0 13 39 45 1 2 345 0.625 0 0 33.5

LinkAttributeManager 8 0 0 9 24 28 1 2 300 0.7292 0 0 36.5

ListAttributeManager 5 0 0 10 19 10 1 2 157 0.6857 0 0 30.4

MonoLinkAttributeManager 1 0 0 1 2 0 1 2 4 1 0 0 3

MonoListAttributeManager 5 0 0 7 15 10 1 2 103 0.6857 0 0 19.6

MonoTextAttributeManager 5 0 0 5 9 10 1 2 41 0.5333 0 0 7.2

NumberAttributeManager 5 0 0 7 25 10 1 2 114 0.4 0 0 21.8

ResourceAttributeManager 5 0 0 8 12 10 1 2 83 0.6 0 0 15.6

TableAttributeManager 5 0 0 8 24 10 2 2 184 0.6 0 0 35.8

TextAttributeManager 5 0 0 6 11 10 1 2 36 0.5143 0 0 6.2

SymbolicLinkErrorMessenger 3 1 0 8 13 3 2 1.5 94 0.3333 0 0 29

ContentActionHelper 10 1 0 17 71 45 10 2 500 0.55 0 0 49

PagesAction 14 0 0 19 10

1 91 2 2

115

6 0.7245 0 0 81.5714

PagesActionForm 27 0 0 13 53 271 25 0.9313 303 0.1975 0 0 9.7037

ShowletAction 5 0 0 13 42 10 2 2 469 0.8 0 0 92.8

ShowletFromPortalAction 6 0 0 14 40 15 3 2 399 0.75 0 0 65.5

ShowletFromPortalActionHelper 2 1 0 10 17 1 2 2 85 0.5 0 0 41.5

ListViewerShowletFromPortalAction 3 0 0 13 19 3 3 2 77 0.5556 0 0 24.6667

SimpleParamShowletFromPortalAction 2 0 0 4 4 1 2 2 9 0.6667 0 0 3.5

ViewerShowletFromPortalAction 2 0 0 4 4 1 2 2 9 0.6667 0 0 3.5

PageActionHelper 8 0 0 12 50 28 4 1.1429 328 0.35 0 0 39.875

SpecialShowletActionHelper 9 1 0 14 55 36 9 2 409 0.2917 0 0 44.4444

ListViewerShowletAction 8 0 0 22 66 28 2 2 703 0.6429 0 0 86.875

SimpleParamShowletAction 4 0 0 13 43 6 2 2 277 0.75 0 0 68.25

ViewerShowletAction 6 0 0 15 50 15 2 2 385 0.6667 0 0 63.1667

ShowletParamVO 3 0 0 1 4 1 3 0.5 14 0.6667 0 0 3.3333

ResourceCategoryActionHelper 3 0 0 6 19 3 2 2 136 0.5238 0 0 44.3333

ResourceCategoryAction 9 0 0 14 66 36 2 2 519 0.6389 0 0 56.6667

ResourceCategoryActionForm 14 0 0 10 29 61 13 0.8901 145 0.2653 0 0 8.8571

ResourceActionHelper 6 1 0 10 39 15 6 1.2 207 0.3889 0 0 33.3333

ResourceAction 14 0 0 16 78 91 2 2 796 0.5071 0 0 55.8571

ResourceActionForm 27 0 0 13 63 297 22 0.8962 357 0.1852 0 0 11.8519

AbstractTreeHelper 6 1 0 10 26 15 4 2 165 0.4667 0 0 26.5

AbstractBaseAction 6 0 0 10 21 15 1 2 100 0.5667 0 0 15.6667

ApsActionMapping 3 0 0 1 4 1 3 0.5 14 0.6667 0 0 3.3333

ConfigFactory 2 0 0 2 6 1 2 2 15 0.75 0 0 6.5

DispatchForward 5 0 0 12 41 10 2 2 353 0.8 0 0 69.6

Utf8TilesRequestProcessor 2 0 0 1 5 1 1 2 15 0.6667 0 0 6.5

ContentDescrTag 6 0 0 4 23 9 6 0.2 84 0.5833 0 0 12.8333

PageTitleTag 8 0 0 6 25 16 8 0.4286 115 0.625 0 0 13.125

GroupsAction 8 0 0 12 55 28 2 2 596 0.875 0 0 73.5

GroupsActionForm 10 0 0 8 20 21 9 0.8667 100 0.36 0 0 8.5

RolesAction 10 0 0 13 71 45 2 2 626 0.7429 0 0 61.6

APPENDIX-A

Page 68

RolesActionForm 14 0 0 7 25 49 13 0.8791 130 0.2857 0 0 7.7857

UsersAction 13 0 0 18 89 78 2 2 826 0.7143 0 0 62.5385

UsersActionForm 24 0 0 7 43 208 23 0.9275 220 0.2031 0 0 7.6667

PermissionVO 8 1 0 0 10 18 8 0.8095 42 0.375 0 0 3.875

DbExtractor 15 1 0 11 43 0 12 0.3571 516 0.4333 0 0 33.2

DbExtractorDAO 12 0 0 6 40 62 10 0.9091 567 0.5278 0 0 45.75

ExtertractorInterfaceDAO 8 1 0 3 8 28 8 2 8 0.6458 0 0 0

SubTypeProductDAO 14 0 0 7 47 89 13 0.9808 580 0.5714 0 0 39.8571

SubTypeProductExtractor 2 0 0 3 5 1 1 2 11 1 0 0 4.5

EntityMonoListAttribute 11 0 0 7 30 33 11 0.7 142 0.2576 0 0 11.7273

MapExtractor 7 1 0 6 23 11 7 0.5556 131 0.5714 0 0 17.2857

MonotextSelectAttributeExtractor 10 0 0 7 23 23 10 0.5 117 0.3 0 0 10.5

MonotextSelectMultiAttribute 14 0 0 11 47 47 14 0.5769 255 0.3 0 0 17.0714

SelectAttributeBean 11 1 0 0 12 25 11 0.725 73 0.7727 0 0 5.2727

SelectAttributeInterface 5 1 0 1 5 10 5 2 5 0.4667 0 0 0

SelectBeansAttributeInterface 3 1 0 0 3 3 3 2 3 0.8333 0 0 0

SelectBeansExtractorInterface 4 1 0 2 4 6 4 2 4 0.6667 0 0 0

SelectMultiAttributeInterface 3 1 0 1 3 3 3 2 3 0.6667 0 0 0

BaseEntityDispenser 3 0 0 13 22 6 3 0.5833 153 0.4444 0 0 48

AjaxServlet 4 0 0 3 28 6 1 2 127 0.6667 0 0 30.75

StartupAnagrafeListener 4 0 0 4 12 6 1 2 43 0.5833 0 0 9.75

AjaxServletHelper 4 1 0 5 18 6 3 2 114 0.5625 0 0 27.5

AteneoDAO 9 0 0 11 36 36 9 1 761 0.6889 0 0 82.6667

AteneoManager 2 0 0 3 6 1 1 2 14 1 0 0 6

BaseBuilderManager 20 0 0 19 85 106 11 0.7895 729 0.2833 0 0 35.15

BibTexManager 23 0 0 26 10

4 221 7 0.7727

204

2 0.3106 0 0 87.6957

Entita 20 0 0 7 66 178 20 1.0357 593 0.29 0 0 27.25

EntitaAbstractManager 21 0 0 16 61 200 17 0.75 516 0.2517 0 0 23.4286

EntitaDaoInterface 8 1 0 3 8 28 8 2 8 0.75 0 0 0

EntitaManager 20 0 0 28 71 90 19 0.5789 500 0.3071 0 0 23.85

EntitaManagerHelper 5 1 0 5 24 4 1 0.8333 338 0.65 0 0 66

IndexOptimizerThread 3 1 0 2 28 1 3 0.625 175 0.7778 0 0 56

EntityChangedEvent 9 1 0 4 11 30 9 1.05 50 0.3611 0 0 3.4444

EntityChangedObserver 1 1 0 2 1 0 1 2 1 1 0 0 0

EntityDOM 8 1 0 3 17 4 6 0.8 104 0.5238 0 0 11.375

EntityHandler 9 2 0 5 32 16 4 0.65 220 0.3333 1 2 22.8889

EntityTypeDOM 4 0 0 8 34 6 1 2 156 0.375 0 0 38

EntityManagerWrapper 10 1 0 11 33 17 9 0.8444 227 0.6667 0 0 21.2

AnagrafeCacheManager 2 0 0 12 23 1 2 2 92 0.75 0 0 45

CentroEsternoDAO 9 0 0 10 34 36 9 1 761 0.6889 0 0 82.6667

CentroEsternoManager 2 0 0 3 6 1 1 2 14 1 0 0 6

CollectionDAO 7 0 0 4 26 21 1 1 466 0.8571 0 0 63.5714

CollectionManager 13 0 0 13 51 0 4 0.1667 106

7 0.3187 0 0 80.9231

CommonManager 9 0 0 12 48 14 6 0.5 243 0.4 0 0 25.7778

APPENDIX-A

Page 69

DipartimentoDAO 9 0 0 10 34 36 9 1 713 0.6889 0 0 77.3333

DipartimentoManager 20 0 0 3 7 1 1 2 17 1 0 0 7.5

EditoreDAO 10 0 0 9 37 45 10 1 657 0.68 0 0 64.1

EditoreManager 4 0 0 9 18 6 3 2 75 0.625 0 0 17.75

FacoltaDAO 9 0 0 10 34 36 9 1 718 0.6889 0 0 77.8889

FacoltaManager 2 0 0 3 7 1 1 2 17 1 0 0 7.5

GruppoDAO 9 0 0 10 34 36 9 1 702 0.6889 0 0 76.1111

GruppoManager 2 0 0 3 7 1 1 2 17 1 0 0 7.5

InvitoGruppi 8 1 0 0 9 10 8 0.7143 47 0.75 0 0 4.5

InvitoGruppiDao 6 0 0 5 26 15 6 1.08 328 0.7 0 0 52.8333

InvitoGruppiManager 7 0 0 6 18 0 7 0.1667 208 0.4 0 0 28.4286

NotificatoreInvitiManager 9 0 0 13 39 0 4 0.4 331 0.3148 0 0 35.2222

InvitoProgettiDao 6 0 0 5 26 15 6 1.08 328 0.7 0 0 52.8333

InvitoProgettiManager 7 0 0 6 18 0 7 0.1667 208 0.4 0 0 28.4286

InvitoProgetto 8 1 0 0 9 10 8 0.7143 47 0.75 0 0 4.5

NotificatoreInvitiManager 6 0 0 12 30 0 3 0.35 222 0.3667 0 0 35.3333

LaboratorioDAO 9 0 0 10 34 36 9 1 694 0.6889 0 0 75.2222

LaboratorioManager 2 0 0 3 7 1 1 2 17 1 0 0 7.5

MailDao 12 0 0 3 22 42 12 0.9394 174 0.4167 0 0 12.75

MailManager 18 0 0 19 95 103 14 0.7005 662 0.1975 0 0 35.1667

SMTPAutenticator 2 0 0 0 4 0 1 0 21 0.75 0 0 8.5

IProdottoTempManager 4 1 0 2 4 6 4 2 4 0.875 0 0 0

ProdottoManager 22 0 0 26 101

75 18 0.619 969 0.3142 0 0 43

ProductSubTypesManager 7 0 0 6 29 21 7 2 227 0.5 0 0 31.4286

AltriProdottiDAO 9 0 0 9 29 36 9 1 449 0.6889 0 0 48

AltroProdottoDAO 9 0 0 9 32 36 9 1 689 0.6889 0 0 74.6667

ArticoloCongressoDAO 9 0 0 10 34 36 9 1 829 0.6889 0 0 90.2222

ArticoloDAO 10 0 0 10 35 45 10 1 874 0.7 0 0 85.5

BrevettoDAO 9 0 0 9 32 36 9 1 777 0.6888

9 0 0 84.4444

CapitoloDAO 11 0 0 10 36 55 11 1 960 0.6909 0 0 85.4545

LibroDAO 10 0 0 10 36 45 10 1 873 0.7 0 0 85.4

ManufattoDAO 9 0 0 9 32 36 9 1 641 0.6889 0 0 69.3333

PerformanceDAO 9 0 0 9 32 36 9 1 665 0.6889 0 0 72

ProgettoDesignDAO 9 0 0 10 34 36 9 1 694 0.6889 0 0 75.2222

TempDAO 10 0 0 9 33 45 10 1 546 0.7 0 0 52.7

PunteggiDAO 7 0 0 6 38 21 7 1.1667 493 0.619 0 0 68.4286

PunteggiManager 10 0 0 6 37 45 10 1.1111 387 0.42 0 0 37.6

ProgettoDAO 9 0 0 10 33 36 9 1 606 0.6889 0 0 65.4444

ProgettoManager 2 0 0 3 7 1 1 2 17 1 0 0 7.5

RicercatoreDAO 16 0 0 15 54 120 16 1 115

4 0.7125 0 0 70

RicercatoreManager 6 0 0 7 20 0 5 0.2 164 0.6667 0 0 26.1666

7

RivistaDAO 11 0 0 9 34 55 11 1 726 0.6909 0 0 64.3636

RivistaManager 5 0 0 9 19 4 4 0.5 107 0.4667 0 0 20.2

EntitySearchEngineManager 44 0 0 26 12

7 726 37 0.8339

136

7 0.1789 0 0 29.9091

APPENDIX-A

Page 70

EntitySearcherDAO 18 1 0 14 50 151 8 0.5882 111

8 0.375 0 0 61.0556

SearchHelper 12 1 0 0 38 66 4 2 675 0.5417 0 0 55.25

StrumentoDAO 9 0 0 10 34 36 9 1 569 0.6889 0 0 61.3333

StrumentoManager 3 0 0 11 19 3 2 2 63 0.6667 0 0 20

EntityPair 7 1 0 0 9 0 7 0.5 53 0.5238 0 0 6.2857

UserAnag 18 0 0 4 48 89 18 0.9647 280 0.25 0 0 13.7222

UtenteDAO 23 0 0 10 70 253 5 1.0198 137

9 0.4946 0 0 57.9565

UtenteManager 38 0 0 23 15

3 271 27 0.7243

184

7 0.1761 0 0 47.4737

AuditDAO 3 0 0 4 14 3 3 1.5 128 0.7333 0 0 40.6667

AuditManager 16 0 0 19 76 64 8 0.7867 792 0.2292 0 0 48.1875

ChangeBean 8 1 0 0 9 22 7 0.9286 45 0.4762 0 0 3.875

ForceUpdate 3 1 0 2 6 3 3 2 22 0.8333 0 0 6.3333

ForceUpdateDAO 4 1 0 1 26 6 3 1 181 0.625 0 0 43.75

UserChangedEvent 9 1 0 4 11 30 9 1.0313 48 0.2889 0 0 3.4444

UserChangedObserver 1 1 0 2 1 0 1 2 1 1 0 0 0

AddEntityEnableTag 3 0 0 6 25 1 3 0.5 119 0.6667 0 0 38.3333

AreeCunTag 9 0 0 5 27 8 9 0.5833 151 0.6667 0 0 15.4444

CheckDelegationTag 4 0 0 8 23 0 4 0.3333 99 0.625 0 0 23.5

CheckEntityTag 4 0 0 5 21 0 4 0.3333 105 0.625 0 0 25

CheckPropertyTag 4 0 0 5 27 0 4 0.3333 112 0.625 0 0 26.75

CheckRoleTag 4 0 0 3 14 0 4 0.3333 65 0.625 0 0 15

EntityListTag 10 0 0 7 38 21 8 0.7778 222 0.375 0 0 20.8

EntitySearcherTag 4 0 0 12 32 0 4 0.3333 171 0.625 0 0 41.5

EntitySimpleSearcherTag 4 0 0 3 20 0 4 0.3333 93 0.625 0 0 22

EntityTag 10 0 0 3 21 9 9 0.4815 108 0.65 0 0 9.5

EntityTagForMultiModel 10 0 0 2 21 9 9 0.5833 136 0.65 0 0 12.2

EntityUserEmailTag 5 0 0 7 21 0 5 0 96 0.6 0 0 18

FilterStringForJavascriptTag 4 0 0 0 10 0 4 0.3333 49 0.625 0 0 11

GetDataTag 7 0 0 3 18 3 7 0.5833 82 0.6429 0 0 10.4286

GetEntityNameByUserTag 4 0 0 6 20 0 4 0.3333 102 0.625 0 0 24.25

GetEntityNameTag 5 0 0 3 17 0 5 0.25 89 0.6 0 0 16.6

GetEntityTag 5 0 0 5 16 0 5 0.25 70 0.6 0 0 12.8

GetEntityUserNameTag 5 0 0 5 19 0 5 0 86 0.6 0 0 16

GetTempProductTag 5 0 0 4 15 0 5 0.25 67 0.6 0 0 12.2

GetUserTag 4 0 0 4 14 0 4 0.3333 69 0.625 0 0 16

I18nTag 9 0 0 4 21 14 8 0.625 132 0.4444 0 0 13.3333

InputMonotextTag 14 0 0 8 37 39 12 0.8352 283 0.3571 0 0 18.7857

IsNotResearcherTag 4 0 0 6 17 0 4 0.3333 77 0.625 0 0 18

LabelI18nTag 9 0 0 4 21 14 8 0.625 128 0.4444 0 0 12.8889

MailTag 3 0 0 12 25 1 2 0.9167 197 0.5556 0 0 62.6667

RefinePagerTag 8 0 0 4 32 14 8 0.5714 144 0.4167 0 0 16.75

SelectsTag 10 0 0 5 53 15 7 0.7889 438 0.4667 0 0 41.8

WelcomeTag 2 0 0 12 26 1 2 2 157 1 0 0 77.5

EntitySearcherTagHelper 14 1 0 10 53 91 14 1 476 0.4286 0 0 32.9286

APPENDIX-A

Page 71

EntityTagHelper 5 1 0 12 30 10 2 2 188 0.6 0 0 36.6

RefinePagerTagHelper 5 0 0 7 24 10 3 2 232 0.6286 0 0 45.4

SearchConstants 2 1 0 0 3 1 1 1.6 15 1 0 0 4

AbstractRicerca 5 1 0 7 10 10 2 2 65 0.44 0 0 12

RicercaGruppi 5 0 0 13 33 10 3 2 441 0.4286 0 0 87.2

RicercaProdotti 3 0 0 7 22 3 2 2 150 0.6667 0 0 49

RicercaProdottiDelGruppo 3 0 0 14 27 3 2 2 119 0.6667 0 0 38.6667

RicercaProdottiDelRicercatore 3 0 0 9 17 3 2 2 75 0.6667 0 0 24

RicercaProgetti 3 0 0 11 22 3 2 2 174 0.6667 0 0 57

RicercaProgettiDelRicercatore 3 0 0 6 17 3 2 2 86 0.6667 0 0 26.6667

RicercaRicercatori 3 0 0 11 22 3 2 2 185 0.6667 0 0 60.6667

RicercaStrumentazione 3 0 0 12 28 3 2 2 180 0.6667 0 0 59

RicercaTematiche 4 0 0 14 36 6 2 2 254 0.4167 0 0 62.5

RefinePagerVO 7 0 0 1 11 3 7 0.6667 57 0.5714 0 0 6.7143

SubTypeBean 15 1 0 0 16 91 15 0.9286 74 0.4889 0 0 3.4667

StringSupport 9 1 0 3 31 36 9 0 230 0.6667 0 0 24.5556

OrderEntity 3 1 0 1 13 0 3 0 52 0.6667 0 0 16

OrderEntityBean 11 1 0 0 13 35 11 0.7 114 0.4091 0 0 9

CurrentUsersAnagAction 5 0 0 15 46 4 2 0.5 331 0.5111 0 0 64.8

CurrentUsersAnagActionForm 7 0 0 9 23 9 7 0.5833 100 0.4643 0 0 13

PunteggiAction 5 0 0 14 47 10 2 1.25 368 0.6571 0 0 72.4

SottotipiAction 8 0 0 12 47 28 2 2 315 0.5625 0 0 38.375

UserEmailActionForm 6 0 0 3 10 7 6 0.7 44 0.5 0 0 6

LinkEntityAttributeAction 8 0 0 14 49 28 1 2 443 0.6607 0 0 54.375

ListEntityAttributeAction 5 0 0 13 32 10 1 2 417 0.525 0 0 82.4

SelectEntityAttributeAction 15 0 0 24 91 105 2 1.0536 151

5 0.8286 0 0 99.7333

EdtrivActionForm 10 0 0 4 17 37 10 0.8889 68 0.4 0 0 5.4

EntitaAction 33 0 0 27 15

2 522 2 0.9821

294

1 0.4904 0 0 87.9091

EntitaActionForm 10

0 0 0 16

14

2

485

8 94 0.989 726 0.1811 0 0 5.8

EntitaSearchAction 13 0 0 20 84 78 2 1.0556 1771

0.5128 0 0 134.769

2

MultiAction 5 0 0 19 45 10 2 2 381 0.8 0 0 75.2

ProjectAction 3 0 0 11 30 3 2 2 156 619 0 0 51

EntitaActionHelper 12 1 0 20 76 66 12 2 615 0.3194 0 0 50.25

EntitaActionHelperMappatore 5 1 0 0 19 8 3 0.5 218 0.7 0 0 42.4

InvitoGruppiAction 13 0 0 19 70 78 2 2 492 0.3846 0 0 36.8462

InvitoProgettiAction 14 0 0 19 74 91 2 2 551 0.3766 0 0 38.3571

AbstractReportGeneration 6 1 0 16 34 13 3 0.8 131 0.4444 0 0 20

ContentType 7 2 0 4 13 13 5 0.8704 139 0.3333 1 1 17.5714

DepartmentReportGenerator 3 0 0 6 13 3 1 1.5 106 0.5 0 0 34

ProductOdtReportGenerator 4 0 0 15 28 2 1 1.3333 118 0.4583 0 0 28.25

ProductReportGenerator 4 0 0 14 28 2 2 1.3333 118 0.4583 0 0 28.25

QueryReportGenerator 8 0 0 22 52 0 3 1.0357 362 0.375 0 0 43.75

ReportData 31 1 0 0 32 435 31 0.9667 154 0.7419 0 0 3.4839

ResearcherReportGenerator 4 0 0 12 32 4 1 1.3333 288 0.5625 0 0 70.5

APPENDIX-A

Page 72

AllProductOfAResearcherReportAction 3 0 0 7 28 3 2 2 141 0.6667 0 0 46

Controller\QueryCA 19 1 0 0 20 153 19 0.9444 94 0.7368 0 0 3.4737

ReportAction 7 0 0 16 49 21 2 2 329 0.5893 0 0 46

DepartmentResearchAreaReportDataFiller 6 1 0 12 25 15 3 2 132 0.4167 0 0 21

DepartmentResearhProjectDataFiller 7 1 0 9 26 21 3 2 143 0.3929 0 0 19.4286

DepartmentStaffReportDataFiller 6 1 0 11 32 15 3 1.2 184 0.3542 0 0 28.8333

QueryReportDataFiller 4 1 0 11 36 6 3 2 226 0.5 0 0 55.5

ReportDataFiller 2 1 0 5 2 1 2 2 2 0.8333 0 0 0

ResearchLinesReportDataFiller 3 1 0 9 22 3 3 2 71 0.6111 0 0 22.6667

ResearchProductsReportDataFiller 4 1 0 10 23 6 3 2 91 0.4688 0 0 21.75

ResearchProjectsReportDataFiller 5 1 0 9 25 10 3 2 108 0.525 0 0 20.6

RtfDataHelper 6 1 0 4 14 15 6 2 402 0.8889 0 0 66

RtfResearcherProductDataFiller 5 1 0 10 27 10 3 2 173 0.525 0 0 33.6

AbstractEntityDataSource 10 1 0 15 72 15 7 0.7222 540 0.3429 0 0 52.6

DepartmentDataSource 1 0 0 7 7 0 1 2 24 1 0 0 23

EntityDataSourceFactory 3 1 0 8 10 3 3 2 45 0.4167 0 0 14

QueryDataSource 1 0 0 7 6 0 1 2 19 1 0 0 18

ResearcherDataSource 1 0 0 8 8 0 1 2 29 1 0 0 28

RtfResearcherProductDataSource 1 0 0 6 6 0 1 2 19 1 0 0 18

AllProductBibtexAction 7 0 0 15 59 21 2 2 385 0.5357 0 0 54

BibtexAction 12 0 0 22 77 66 2 2 766 0.4697 0 0 62.8333

BibtexFileActionForm 5 0 0 4 7 4 5 0.5 27 0.5 0 0 4.2

BibTextNamesResolver 7 1 0 0 29 9 5 0.6111 427 0.5714 0 0 59.5714

ResourceEntityAction 11 0 0 21 58 55 6 1 430 0.3636 0 0 38

ResourceEntityActionForm 9 0 0 9 27 28 8 0.75 95 0.4444 0 0 9.3333

ResourceEntityActionHelper 6 1 0 10 39 15 6 1.2 207 0.3889 0 0 33.3333

SmtpAction 4 0 0 10 39 6 2 2 197 0.75 0 0 48.25

SmtpActionForm 10 0 0 4 17 25 10 0.8056 99 0.4 0 0 8.5

UserAnagAction 15 0 0 21 103

103 21 2 2 0.3833 0 0 77.6

UTF8Filter 4 1 0 0 7 6 4 2 17 0.4 0 0 3.25

AutocompleterAction 7 0 0 9 32 21 2 2 278 0.8571 0 0 38.7143

AutocompleterDAO 4 0 0 5 15 6 3 1.3333 79 0.6875 0 0 18.25

SuggestionManager 14 0 0 13 51 77 9 0.8173 393 0.3214 0 0 26.5

AjaxDelegationAction 3 0 0 14 38 3 2 2 187 0.6667 0 0 61.3333

CinecaImportDAO 11 0 0 6 62 55 11 1.0111 117

4 0.7455 0 0

104.909

1

IProdottoCinecaManager 1 1 0 2 1 0 1 2 1 1 0 0 0

ProdottoCineca 70 1 0 2 72 2347

70 0.9855 349 0.375 0 0 3.5

ProdottoCinecaManager 9 0 0 13 60 24 6 0.625 910 0.3333 0 0 100

ImportCinecaAction 4 0 0 15 37 6 2 2 244 0.75 0 0 60

WorkbookCreator 8 1 0 21 36 10 2 0.5952 375 0.3036 0 0 45.125

LinesReportAction 3 0 0 11 31 3 2 2 139 0.6667 0 0 45.3333

ShellAction 4 0 0 6 42 6 2 2 293 0.75 0 0 72.25

GroupSortAction 3 0 0 8 23 3 2 2 107 0.6667 0 0 34.6667

UserEntityAction 4 0 0 10 33 6 2 2 214 0.75 0 0 52.5

APPENDIX-A

Page 73

PluginsManager 5 0 0 7 28 4 4 0.25 133 0.5333 0 0 25.4

PluginDOM 6 1 0 6 40 0 3 0.5333 202 0.3667 0 0 32.1667

AbstractPluginService 4 1 0 3 5 4 4 0.8889 24 0.4375 0 0 4.25

Plugin 18 1 0 0 23 125 18 0.9191 103 0.3611 0 0 4.2778

PluginTag 2 0 0 4 17 1 2 2 69 1 0 0 33.5

MultiLevelSelectAttribute 14 0 0 9 32 45 14 0.641 178 0.2738 0 0 11.5

MultilevelExtractor 7 0 0 5 17 15 4 2 155 0.5238 0 0 21.1429

MultilevelExtractorDAO 12 0 0 7 44 54 10 0.9273 754 0.5065 0 0 61

SelectLevelAttributeAction 12 0 0 12 50 66 2 1.0682 672 0.5104 0 0 54.6667

ExporterDao 5 0 0 5 31 10 5 1.25 289 0.7 0 0 55.8

ExporterService 6 0 0 8 51 5 3 0.76 272 0.4667 0 0 43.5

ExportAction 3 0 0 9 25 3 2 2 325 0.4286 0 0 107.333

3

AnagrafeExporter 8 0 0 7 32 8 3 0.4286 256 0.25 0 0 30.75

ArticleExporter 2 0 0 5 10 1 1 2 154 0.6667 0 0 76

BookExporter 2 0 0 5 10 1 1 2 154 0.6667 0 0 76

ChapterExporter 2 0 0 5 10 1 1 2 178 0.6667 0 0 88

CongrssArticleExporter 2 0 0 5 10 1 1 2 170 0.6667 0 0 84

DepartmentExporter 3 0 0 5 13 3 2 2 108 0.5556 0 0 35

DesignExporter 2 0 0 5 9 1 1 2 101 0.6667 0 0 49.5

Exporter 3 1 0 2 4 3 2 1 17 0.5556 0 0 4

ExporterFactory 2 1 0 18 24 1 2 2 173 0.5 0 0 85.5

FacultiExporter 3 0 0 5 13 3 2 2 108 0.5558 0 0 35

HelpToExport 5 1 0 6 13 10 5 2 58 0.5 0 0 10.6

ManufactExporter 2 0 0 5 9 1 1 2 101 0.6667 0 0 49.5

OtherExporter 2 0 0 5 9 1 1 2 109 0.6667 0 0 53.5

PatentExporter 2 0 0 5 9 1 1 2 141 0.6667 0 0 69.5

PerformanceExporter 2 0 0 5 9 1 1 2 101 0.6667 0 0 49.5

ProductExporter 4 0 0 8 24 4 2 0.6667 123 0.5 0 0 29.5

ProjectExporter 4 0 0 9 29 9 2 0.6667 302 0.5 0 0 74.25

ResearcherExporter 4 0 0 10 28 2 2 0.6667 381 0.5 0 0 93.75

Row 1 3 0 0 2 0 1 2 5 1 0 0 3

MyHTMLEncoder 2 0 0 1 6 1 2 2 18 0.5 0 0 8

TestCategoryManager 7 0 0 8 38 0 5 0 173 1 0 0 23.5714

TestResourceCategoryManager 6 0 0 7 26 0 4 0 126 1 0 0 19.8333

TestContentDAO 17 0 0 8 65 46 6 0.125 473 0.5147 0 0 26.7647

TestContentManager 14 0 0 7 58 0 11 0.1538 667 1 0 0 46.5714

TestContentTagDAO 3 0 0 3 16 0 3 0 130 1 0 0 42

TestContentDOM 2 0 0 3 8 1 2 2 25 1 0 0 11.5

TestContentAttributeIterator 2 0 0 6 17 1 2 2 54 1 0 0 26

TestContentModelDAO 2 0 0 5 16 1 2 2 67 1 0 0 32.5

TestContentModelManager 5 0 0 5 15 4 3 0.25 47 1 0 0 8.2

TestContentPageMapperManager 5 0 0 6 14 0 3 0 57 1 0 0 10.2

TestContentDispenser 6 0 0 5 16 0 4 0.5333 188 1 0 0 29.8333

TestLinkResolverManager 10 0 0 7 32 0 9 0.1667 382 1 0 0 37

TestResourceDAO 2 0 0 7 23 1 2 2 109 1 0 0 53.5

APPENDIX-A

Page 74

TestResourceManager 13 0 0 12 60 0 9 0.0833 597 0.5769 0 0 44.8462

MockResourceDataBean 13 1 0 1 21 54 13 0.8667 86 0.3462 0 0 5.2308

TestResourceDOM 2 0 0 3 8 1 2 2 25 1 0 0 11.5

TestHtmlHandler 2 0 0 3 6 1 2 2 19 1 0 0 8.5

TestSearchEngineManager 15 0 0 15 63 0 11 0.7222 850 1 0 0 55.0667

MockContentRelationsDAO 3 0 0 3 9 3 3 2 98 0.75 0 0 31.6667

MockControllerContinue 3 1 0 3 4 3 3 2 14 0.5 0 0 3.6667

MockControllerError 3 1 0 3 4 3 3 2 14 0.5 0 0 3.6667

MockControllerErrorManager 3 1 0 3 5 3 3 2 18 0.5 0 0 5

MockControllerOutput 3 1 0 3 4 3 3 2 14 0.5 0 0 3.6667

MockControllerRedirect 3 1 0 3 5 3 3 2 18 0.5 0 0 5

MockRequestValidator 3 0 0 2 5 3 1 2 20 0.6667 0 0 5.6667

MockResourcesDAO 2 0 0 3 8 1 2 2 49 0.625 0 0 23.5

MockShowletsDAO 2 0 0 3 9 1 2 2 53 0.625 0 0 25.5

MockUniqueKeysDAO 2 0 0 3 10 1 2 2 61 0.625 0 0 29.5

TestDbEncoding 2 0 0 3 18 1 2 2 182 1 0 0 90

TestSysAnagrafeContext 2 0 0 13 26 1 2 2 112 1 0 0 55

TestSysAnagrafeContextFactory 2 0 0 27 6 1 2 2 171 1 0 0 84.5

TestSystemContext. 2 0 0 13 26 1 2 2 112 1 0 0 55

TestSystemContextFactory 2 0 0 26 6 1 2 2 170 1 0 0 84

TestBaseConfigService 3 0 0 5 12 3 3 2 43 1 0 0 13.3333

TestConfigItemDAO 3 0 0 4 15 3 3 2 107 1 0 0 34.6667

TestCacheManager 6 0 0 4 19 0 4 0 125 1 0 0 19.6667

TestAuthenticator 3 0 0 10 24 3 3 2 166 1 0 0 54.3333

TestErrorManager 5 0 0 7 19 0 3 0 103 1 0 0 19.4

TestExecutor 2 0 0 8 15 1 2 2 50 1 0 0 24

TestRequestValidator 3 0 0 8 18 3 3 2 100 1 0 0 32.3333

TestControllerManager 6 0 0 19 37 15 6 2 269 1 0 0 43.8333

TestHelper 3 1 0 3 7 3 3 2 17 0.4167 0 0 4.6667

TestGroupManager 6 0 0 5 25 0 4 0 191 1 0 0 30.6667

TestI18nManager 4 0 0 6 13 0 2 0 52 1 0 0 11.75

TestKeyGeneratorDAO 2 0 0 5 12 1 2 2 56 1 0 0 27

TestKeyGeneratorManager 8 0 0 6 27 16 2 0.5 212 0.3438 0 0 25.25

TestLangManager 6 0 0 6 24 0 4 0 127 1 0 0 20

TestPageDAO 6 0 0 11 62 15 4 2 720 0.6667 0 0 119

TestPageManager 5 0 0 12 58 10 2 2 531 0.8 0 0 105.2

TestPageModelDAO 2 0 0 4 11 1 2 2 51 1 0 0 24.5

TestPageModelDOM 2 0 0 4 11 1 2 2 51 1 0 0 24.5

TestPageModelManager 5 0 0 7 24 0 3 0 130 1 0 0 24.8

TestPermissionDAO 4 0 0 5 26 6 2 2 304 0.75 0 0 75

TestRoleDAO 4 0 0 4 25 6 2 2 263 0.75 0 0 64.75

TestRoleManager 9 0 0 7 43 0 2 0 286 0.7778 0 0 30.6667

TestShowletTypeDAO 2 0 0 5 11 1 2 2 55 1 0 0 26.5

TestShowletTypeDOM 2 0 0 4 11 1 2 2 47 1 0 0 22.5

TestShowletTypeManager 5 0 0 7 28 0 3 0 154 1 0 0 29.6

APPENDIX-A

Page 75

TestURLManager 4 0 0 7 14 0 2 0 54 1 0 0 12.25

MockUserDAO 7 0 0 4 14 21 1 2 49 0.6429 0 0 6

TestUserDAO 5 0 0 7 29 0 3 0.375 257 0.6 0 0 50

TestUserManager 9 0 0 7 42 0 6 0.25 354 0.5556 0 0 38.1111

TestContentTagHelper 6 0 0 10 25 3 4 0.2 144 1 0 0 22.8333

BaseTestCase 5 0 0 7 15 2 1 0.5 60 0.6 0 0 10.6

TestUtils 6 1 0 9 33 3 5 0.4 272 0.375 0 0 44.1667

MockApsDataSource 3 0 0 1 6 1 3 0.5 32 0.6667 0 0 8.6667

MockResponse 2 0 0 1 3 1 2 2 7 0.75 0 0 2.5

MockSession 3 0 0 1 7 0 3 0 24 0.6667 0 0 6.6667

MockURLManager 3 0 0 6 15 3 3 2 53 0.4667 0 0 16.6667

AllTests0 2 1 0 2 5 1 2 2 156 0.5 0 0 77

TestBaseAdminAction 7 0 0 7 39 15 4 0.5 202 1 0 0 27.5714

TestCurrentUserAction 4 0 0 5 22 0 3 0.3333 173 1 0 0 42

TestCategoryAction 9 0 0 3 23 36 9 2 213 1 0 0 22.6667

TestHypertextAttributeAction 4 0 0 2 14 6 3 2 86 0.625 0 0 20.5

TestLinkAttributeAction 10 0 0 7 43 25 9 2 294 0.55 0 0 28.4

TestListAttributeAction 7 0 0 6 37 1 6 2 251 1 0 0 34.8571

TestResourceAttributeAction 13 0 0 2 22 36 10 2 319 0.6154 0 0 23.5385

TestTableAttributeAction 13 0 0 5 32 22 10 2 588 1 0 0 44.2308

TestContentAction 14 0 0 10 57 43 9 0.7692 545 0.381 0 0 37.8571

TestContentFindAction 23 0 0 7 54 221 12 0.5455 550 0.6739 0 0 22.8696

TestSimpleParamShowletAction 4 0 0 4 19 6 4 2 107 1 0 0 25.75

TestViewerShowletAction 3 0 0 4 18 3 3 2 85 1 0 0 27.3333

TestPagesAction 30 0 0 10 77 177 22 0.5517 116

0 0.4111 0 0 37.6

TestShowletAction 6 0 0 4 20 13 6 2 155 1 0 0 24.8333

TestResourceCategoryAction 7 0 0 3 18 21 7 2 165 1 0 0 22.5714

TestResourceAction 14 0 0 4 35 49 12 2 333 0.5357 0 0 22.7857

TestDispatchForward 9 0 0 3 27 36 8 2 161 0.5556 0 0 16.8889

TestGroupsAction 16 0 0 8 49 98 14 0.6667 511 1 0 0 30.875

TestRolesAction 10 0 0 8 37 45 10 2 285 1 0 0 27.5

TestUsersAction 17 0 0 10 59 124 14 0.75 714 0.5294 0 0 40.9412

AllTests1 2 1 0 2 6 1 2 2 42 0.5 0 0 20

AllTests2 2 1 0 2 6 1 2 2 48 0.5 0 0 23

ApsMockStrutsTestCase 8 0 0 9 23 20 2 0.2857 120 0.625 0 0 13.875

TestEntityMonoListAttribute 3 0 0 8 13 0 3 0.25 54 1 0 0 16.3333

TestMailService 6 0 0 4 16 3 4 0.2 126 1 0 0 19.8333

TestEntitySearchEngineManager 11 0 0 20 70 7 6 0.675 863 0.5455 0 0 76.3636

TestAteneoDAO 5 0 0 10 41 8 2 0.5 377 1 0 0 73.8

TestBaseBuilderManager 8 0 0 12 41 12 3 0.5 621 0.6875 0 0 76.125

TestEntityManagerWrapper 1 0 0 1 2 0 1 2 4 1 0 0 3

TestCollectionManager 2 0 0 12 19 1 2 2 170 1 0 0 84

MockGruppoDAO 7 0 0 4 14 21 7 2 45 0.6857 0 0 5.4286

TestGruppoDAO 5 0 0 9 29 4 2 0.4167 210 1 0 0 40.4

TestGruppoManager 6 0 0 13 36 1 2 0.2667 255 0.5833 0 0 41

APPENDIX-A

Page 76

MockUserAnagDAO 8 0 0 5 16 28 2 2 57 0.625 0 0 6.125

MockUserDAO 10 0 0 4 20 45 1 2 70 0.5571 0 0 6

TestUserAnagDAO 5 0 0 11 51 0 3 0.4167 440 0.6 0 0 86.4

TestUtenteManager 6 0 0 11 27 7 3 0.6 186 0.5833 0 0 29.5

AllTestsIT 2 1 0 2 5 1 2 2 42 0.5 0 0 20

TestEntitaAction 11 0 0 9 48 21 6 0.6435 111

5 0.4333 0 0 96.1818

TestBibTextNamesResolver 28 0 0 2 37 0 26 0.1481 438 1 0 0 14.6071

TestUserAnagAction 7 0 0 8 28 15 5 0.5 203 1 0 0 27.8571

Comune 9 1 0 0 10 28 9 0.875 44 0.7222 0 0 3.4444

Read 5 1 0 4 16 2 4 0.5833 68 0.5 0 0 12

TestAteneo 2 0 0 3 21 1 2 2 86 1 0 0 42

TestParsingComuniStati 4 0 0 9 28 4 2 0.6667 204 0.625 0 0 48

TestParsingLingua 2 0 0 6 23 1 2 2 160 1 0 0 79

TestParsingSSD 2 0 0 3 9 1 2 2 36 1 0 0 17

AteneoConverter 4 0 0 10 25 4 2 0.3333 114 1 0 0 27

ChangeSSD 2 0 0 4 18 1 2 1 76 1 0 0 36

CinecaToFlossARConverter 4 0 0 11 42 0 2 0.1667 516 1 0 0 127

DipartimentoConverter 4 0 0 9 24 4 2 0.3333 87 1 0 0 20.25

FacoltaConverter 4 0 0 10 27 4 2 0.3333 95 1 0 0 22.25

GruppoConverter 4 0 0 9 24 4 2 0.3333 87 1 0 0 20.25

LineeRicercatoreConverter 4 0 0 14 33 4 2 0.3333 130 1 0 0 31

LinguaConverter 4 0 0 13 44 4 2 0.3333 167 1 0 0 40.25

MoveAltriProdotti 4 0 0 9 30 4 2 0.3333 176 1 0 0 42.5

ProdottoConverter 6 0 0 16 59 3 2 0.3 293 0.375 0 0 47.5

ProdottoConverter1 8 0 0 13 49 16 2 0.4762 252 0.2708 0 0 30.125

ProdottoConverter2 6 0 0 12 40 7 2 0.4 174 0.375 0 0 27.6667

RicercatoreAreaConverter 4 0 0 9 23 4 2 0.3333 84 1 0 0 19.5

RicercatoreConverter 4 0 0 10 25 4 2 0.3333 93 1 0 0 21.75

RivisteConverter 4 0 0 11 26 4 2 0.5 96 1 0 0 22.5

validating software evolution of agile projects using...

Documents