software maintenance prediction: an architecture...
TRANSCRIPT
Software Maintenance Prediction: An Architecture Perspective
By
Sajid Anwar, MS (CS), MSc (CS)
A thesis submitted in partial fulfillment of the requirements for the degree of Doctor of
Philosophy to the FAST National University of Computer & Emerging Sciences
Department of Computer Science FAST National University of Computer & Emerging Sciences,
Islamabad, Pakistan.
(August 2010)
i
Dedicated to my Parents, Brothers, Sisters & my Sweet Wife.
ii
Acknowledgements
I would like to bow my head before Allah Almighty, the Most Gracious, and the Most
Merciful, whose benediction bestowed upon me talented teachers, provided me sufficient
opportunity, and enabled me to undertake and carry out this research work.
This dissertation describes research undertaken at the Department of Computer Science,
National University of Computer & Emerging Sciences, Islamabad, between August
2004 and August 2010, under the supervision of Prof. Dr. Arshad Ali Shahid, to whom I
am indebted for suggesting the subject and for his encouragement, guidance and support
throughout the research program. His advice, discussion, and effective comments were
always a source of motivation.
I am also thankful to Dr. Rauf Baig, who not only managed and administrated my
research activities, but also guided and encouraged my innovative ideas and gave me full
moral support at every stage of my research work.
I would not have reached this stage but for the prayers, love and moral support of my
mother and father. I would like to thank my brother, sisters, and all other well-wishers. I
would also like to pay tribute to my friends M. Ramzan, Abdul Rauf, M.Arfan jaffer,
Amjad Iqbal, Abdul Basit, Nazir, Aamir, Zahoor, Sani, Ayyaz Hussain, Zahid, Wasim
Shahzad and Hassan Kiyani.
I am also extremely thankful to Dr. Aftab Maroof, and Dr. Anwar Majeed Mirza who not
only allowed me to do my research work in FAST, but also appreciated my innovative
ideas and gave me full moral support.
I acknowledge the enabling role of the Higher Education Commission of Pakistan and
appreciate their financial support through its Indigenous PhD Scheme.
iii
Table of Contents
CHAPTER 1: INTRODUCTION.............................................................................................1
1.1 PROBLEM STATEMENT................................................................................................1
1.2 LITERATURE REVIEW..................................................................................................2
1.2.1 Software Maintenance Prediction ...........................................................................2
1.2.2 Ripple Effect Analysis.............................................................................................5
1.3 BACKGROUND AND MOTIVATION ..............................................................................8
1.4 CONTRIBUTION ..........................................................................................................9
1.5 THESIS ORGANIZATION ............................................................................................10
CHAPTER 2: BACKGROUND STUDY................................................................................12
2.1 SOFTWARE MAINTENANCE .......................................................................................12
2.2 CATEGORIES OF SOFTWARE MAINTENANCE ..............................................................13
2.3 THE SIGNIFICANCE OF SOFTWARE MAINTENANCE ....................................................14
2.4 SOFTWARE ARCHITECTURE AND SOFTWARE ARCHITECTURE EVALUATION ...............15
2.5 APPROACHES TO SOFTWARE ARCHITECTURE EVALUATION .....................................16
2.5.1 Questioning Techniques .......................................................................................17
2.5.2 Measuring Techniques..........................................................................................19
2.6 SOFTWARE ARCHITECTURE ANALYSIS USING SCENARIOS ........................................22
2.7 ANALYZING SOFTWARE ARCHITECTURE FOR MODIFIABILITY USING SCENARIO .......27
CHAPTER 3: SOFTWARE MAINTENANCE PREDICTION MODEL.............................33
3.1 INTRODUCTION .........................................................................................................33
3.2 COMPLEXITY BASED SCENARIO CLASSIFICATION WITH RESPECT TO QA..................34
3.2.1 Methodology for assigning weights to scenario.....................................................39
3.3 PROPOSED ARCHITECTURE BASED SOFTWARE MAINTENANCE PREDICTION PROCESS..
………………………………………………………………………………………...40
3.3.1 Requirements Specification...................................................................................40
3.3.2 Components: ........................................................................................................41
iv
3.3.3 Software Architecture:..........................................................................................41
3.3.4 Maintenance Prediction Method:..........................................................................41
3.4 FACTORS AFFECTING SOFTWARE MAINTENANCE COST ...........................................44
3.5 SUMMARY ................................................................................................................50
CHAPTER 4: ARCHITECTURE BASED RIPPLE EFFECT ANALYSIS .........................51
4.1 INTRODUCTION ........................................................................................................51
4.2 PROPOSED ARCHITECTURE BASED RIPPLE EFFECT ANALYSIS .....................................55
4.3 SUMMARY ................................................................................................................63
CHAPTER 5: CASE STUDY .................................................................................................64
5.1 WEB CONTENT EXTRACTION APPLICATION ...............................................................64
5.1.1 Description of the architecture .............................................................................65
5.2 PREDICTION EXAMPLE .............................................................................................66
5.2.1 Step 1: Growth scenario profile:...........................................................................66
5.2.2 Step 2: Complexity based scenario classification ..................................................67
5.2.4 Step 4: Change impact analysis ............................................................................68
5.2.5 Step 5: Factors affecting software maintenance ....................................................70
5.2.6 Step 6: Predicted maintenance effort ....................................................................70
5.3 ARCHITECTURE BASED SOFTWARE QUALITY MAINTENANCE RIPPLE EFFECT
ANALYSIS……………………………………………………………………………..71
5.3.1 Required Change..................................................................................................71
5.3.2 Ripple Effect Analysis...........................................................................................71
CHAPTER 6: CONCLUSION................................................................................................77
6.1 INTRODUCTION .........................................................................................................77
6.2 SUMMARY OF FINDINGS REGARDING SOFTWARE MAINTENANCE PREDICTION ............77
6.3 SUMMARY OF FINDINGS REGARDING RIPPLE EFFECT ANALYSIS .................................81
6.4 FUTURE WORK .........................................................................................................82
REFERENCES........................................................................................................................84
v
List of Figures
Figure 2.1 Simulation of a system………………………………………………… 20
Figure 2.2 SAMM inputs and activities …………………………………………. 22
Figure 2.3 ATAM activities that consider scenarios ……………………………. 23
Figure 2.4 ATAM phases …………………………………………………….. 24
Figure 2.5 Framework for architecture information gathering and analysis …… 24
Figure 2.6 SBAR activities …………………………………………………… 25
Figure 2.7 ESAMMI approach ………………………………………………….. 26
Figure 3.1 Mc Call’s software quality model …………………………………… 36
Figure 3.2 Boehm’s quality characteristics …………………………………… 37
Figure 3.3 ISO/IEC 9126 quality model for external and internal quality …… 38
Figure 3.4 Architecture based development and maintenance prediction process... 41
Figure 3.5 Maintenance prediction process…………………………………… 42
Figure 3.6 Ripple effect analysis ……………………………………………… 43
Figure 4.1 the IEEE maintenance process …………………………………… 53
Figure 4.2 A task oriented software maintenance model …………………… 53
Figure 4.3 A methodology for software maintenance . ……………………….. 54
Figure 4.4 SADT diagram of software maintenance activities …………………. 54
Figure 4.5 Architecture based software quality maintenance ripple effect analysis
process…………………………………………………………………………….. 55
Figure 4.6 Ripple effect analysis algorithm ……………………………………. 62
Figure 5.1 Web content extraction application architecture ……………………… 65
vi
List of Tables
Table 3.1 Complexity based scenario classification with respect to QA ………… 39
Table 3.2 COCOMO II scaling factors for complexity …………………….. 39
Table 3.3 Scenario Weightage …………………………………………….. 40
Table 3.4 COCOMO II scaling factors for system novelty …………………….. 45
Table 3.5 COCOMO II scaling factors for turnover ……………………………. 45
Table 3.6 COCOMO II scaling factors for maintenance staff ability …………… 46
Table 3.7 COCOMO II scaling factors for documentation ……………………. 46
Table 3.8 COCOMO II scaling factors for testing quality ………………………. 47
Table 3.9 COCOMO II scaling factors for application type ……………………. 48
Table 3.10 COCOMO II software understanding …………………………………. 49
Table 4.1 Reliability attributes …………………………………………………… 57
Table 4.2 Performance attributes ………………………………………………… 58
Table 4.3 Security attributes ……………………………………………………. 58
Table 4.4 Property to component associativity matrix …………………………… 59
Table 4.5 Component Connectivity matrix …………………………………….. 59
Table 4.6 Quality attributes inter-dependency ……………………………………. 60
Table 5.1 Growth scenario profile ………………………………………………... 67
Table 5.2 Complexity based scenario classification ……………………………… 68
Table 5.3 Probability of each scenario occurrence ……………………………….. 68
Table 5.4 Approximate component size ………………………………………….. 69
Table 5.5 Change impact analysis for each scenario …………………………….. 69
Table 5.6 Factors affecting software maintenance & their weightage ……………. 70
Table 5.7 Properties to component associativity matrix for performance ………… 74
Table 5.8 Component connectivity matrix ……………………………………….. 75
Table 5.9 QA inter-dependency matrix …………………………………………… 76
vii
List of Abbreviations QA Quality Attribute LOC Line of Code NOP Number of Operators OO Object Oriented SOC Service Oriented Computing ANN Artificial Neural Network UML Unified Modeling Language NFR Non Functional Requirement SAAM Scenario Based Architecture Analysis Method ATAM Architecture Tradeoff Analysis Method SA Software Architecture SAMMER Software Architecture Analysis Method for
Evolution and Reusability SBAR Scenario Based Architecture Re-engineering ESAMMI Extending SAAM by Integration in the Domain ASAMM Aspectual Software Architecture Analysis Method COSAMM Concern Oriented Software Architecture Analysis
Method ALMA Architecture Level Modifiability Analysis OOD Object Oriented Design UI User Interface
viii
Abstract
Every successful software product is required to be maintained at some later stage of its life
cycle. This maintenance is constrained in different ways by its cost, lead-time, and quality.
These constraints are not always straightforward enough to be precisely quantified and
understood. If a company can predict the maintenance in advance it can plan its business
accordingly. This can be attributed to software engineer’s ability to model the predicted
maintenance effort required early in the development cycle. The customers now have keen
interest in software quality requirements (i.e. quality attributes (QAs)), like maintainability,
reliability, performance, and flexibility too. Therefore, the maintenance may be required from
the product’s functionality or its quality point of view. Software architecture is an excellent
vehicle to showcase the changes, especially related to QAs that take place over the time. The
QAs are interlinked with each other that make the maintenance effort estimation more
complex.
Unless, we have effective maintenance profiles maintained from very early in the
development cycle, it is quite difficult to achieve quality according to customer satisfaction.
In this thesis, efforts have been made to identify mechanisms which ensure early maintenance
prediction. Software architecture, in our opinion, is one such artifact which can effectively be
used to address the above mentioned problems. Software architecture has assumed greater
significance over the past two decades as an artifact which not only plays vital role in
development of quality software but also in its maintenance and up gradation. In this thesis a
methodology for prediction of software system’s maintenance based upon their software
architecture design has been defined. As a secondary step the thesis also presents a complete
methodology for ripple effect analysis based on quality attribute in order to cover the
maintenance of software quality in addition to its functionality.
The proposed method enables us to predict the overall maintenance effort quite early in the
software development life cycle and provides an insight whether the components will remain
consistent after the change or it will be come fluent and inconsistent. The proposed method
can also help in better understandability of the software and consequently more reliable early
planning.
ix
List of Publications
1. Sajid Anwar, Muhammad Ramzan, Abdul Rauf, Arfan Jaffar, and Arshad Ali Shahid , “A Novel Aproach for Architecture Based Software Maintenance Prediction”, International Journal of Innovative Computing, Information and Control (IJICIC), Vol.7, No.6, June 2011,pp:3193-3208 (indexed by ISI Impact factor 2.79).
2. Sajid Anwar, Muhammad Ramzan, Abdul Rauf, Arfan Jaffar, and Arshad Ali
Shahid , “Architecture Based Software Quality Maintenance Ripple Effect Analysis”, International Journal of Innovative Computing, Information and Control (IJICIC), Vol.7, No.11, November 2011 (indexed by ISI Impact factor 2.79).
3. Sajid Anwar, Abdul Rauf, Muhammad Ramzan, and Arshad Ali Shahid,
“Software maintenance prediction: A Software architecture perspective”, International Conference on Information Science and Applications (ICISA 2010), Seoul, South Korea, April 2010.
4. Sajid Anwar, Abdul Rauf, Muhammad Ramzan, and Arshad Ali Shahid,
“Software quality maintenance ripple effect analysis: A Software architecture perspective”, International Conference on Information Science and Applications (ICISA 2010), Seoul, South Korea, April 2010.
1
Chapter 1: Introduction
1.1 Problem Statement
Software maintenance was initially supposed to be an activity that would start after the
software was delivered to the customer and used for a while. This notion has changed in
the recent past and now the process of maintenance continues even during the software
development process. This is because now the software is not just the end code delivered
to the users but also includes other artifacts such as fully specified requirements,
architecture, and design etc. The customers not only demand for provision of correct and
required functionality but also have keen interest in software quality attributes like
maintainability, performance, flexibility, and reliability desired also [1]. Maintainability
or software maintenance to be precise has assumed greater significance in the eyes of
software users and customers in the age when users are more aware of their needs and
software are being developed for long term purposes.
With the passage of time, the notion of software product quality has also evolved.
Initially software product quality was meant to prove the absence of defects in the
delivered product. Since then, ISO/IECFDIS 9126-1 standard defined many
characteristics of the software system which also need to be catered for software product
to be considered a quality product. As mentioned above, maintenance among these
factors is very critical one and requires new methodologies/ techniques to guarantee that
the chosen solution will provide the user with a solution that will meet his/her long term
strategic and business objectives.
As highlighted in the abstract, the current software development models allow software
evolution during the development in an iterative manner and by allowing requirement
changes during the development. This evolution applies to all quality attributes of the
software and software architecture is an excellent vehicle to showcase the changes that
take place over the time in software [2]. These quality attributes are interlinked with each
2
other which make the maintenance effort required to meet the evolving need of software
more complex. The software architecture can be utilized as an affective tool to map and
implement these changes during the software maintenance process. Therefore,
architecture should be analyzed to identify the scope of the side effects that are caused by
QA maintenance and to make sure that the system preserves the overall functionality and
quality.
It is clear from the above discussion that during system quality maintenance a balance
between system qualities is needed. To maintain balance between the system qualities,
certain quality attribute estimation techniques are required at earlier stage (i.e. software
architecture) and also a systematic methodology to cater for ripple effect in case of
system quality maintenance. Such techniques will eliminate the risk of putting resources
on flawed design. This thesis aims to propose a mathematical model for architecture
based software maintenance prediction using weighted scenarios. It also proposes a
complete methodology for ripple effect analysis in case of software quality maintenance.
1.2 Literature Review
1.2.1 Software Maintenance Prediction
Various techniques have been developed by software architecture community for the
purpose of software maintainability evaluation. P. Bengtsson and J. Bosc [1] developed a
probability based approach that makes use of scenario to predict maintenance effort at
software architecture level. B. Graff [3] came up with an approach that mainly focused
on design decisions, documentation, and implementation concepts. The author has
explained how these concepts are related to architecture and consequently affect
maintainability. This shows that architecture can play a vital role in early maintenance
prediction.
M. Zanker and S. Gordea [6] developed an approach that employees data mining
techniques for measuring maintenance efforts. P. Oman and J. Hagemeister [7] provide
3
metrics description and definition of maintainability attributes for target software system.
They have identified the factors that determine or influence maintainability. They
organized these factors into a hierarchical structure of measurable attributes and have
shown a metric definition consistent with the published definitions of the software
characteristics being measured. Alonso et al. [8] developed an approach using RMA
model that helps the architects to obtain early information about software architecture.
This information can be used for early maintenance prediction, thereby reducing the
overall maintenance time and enhancing customer satisfaction.
J. Bosch et al. [9] developed an approach that provides information about the software
architecture with respect optimal maintainability. M. Anan et al. [10] proposed an
architecture-centric metric using entropy to evaluate structural dependencies among
software components. Y. Zhou and H. Leung [11] developed software maintainability
prediction models by using MARS (Multiple Adaptive Regression Splines). W. Li and S.
Henry [12] research focused on OO software metrics and their validation with respect to
software maintenance effort. All of these studies show the effectiveness of software
architecture as a vehicle for effective software maintenance prediction.
K. K. Aggarwal et al. [13] research concentrates on the application of Artificial Neural
Network (ANN) for software quality prediction using object-oriented (OO) metrics. The
quality factor they have focused was software maintainability. The study of S.A. Wake
and S.M. Henry [14] was mainly focused on providing information about the system and
the amount of maintenance necessary to that system. S. Henry and S. Wake [15] have
used software quality metrics for the identification of high-complexity components in
component based software system. Their study conclude that using software maintenance
historical data, it is possible to develop a predictor equation that can identify components
which needed maintenance activities.
K. Hashim and E. Key [16] have proposed a model that can be used to evaluate a system
and emphasize the need to improve the quality of the product so that accurate and
proficient maintenance is possible without much difficulty. The same model can be used
to provide a measurement related information for software maintainability. These
4
information then can be used to determine the level of maintenance readiness before the
system delivery. Y. Singh et al. [17] have analyzed and provided information about the
major factors that can influence software maintenance. These factors were then categories
as: Readability of Source Code (RSC), Documentation Quality (DQ), Understandability
Of Software (UOS), and Average Cyclomatic Complexity (ACC). Based upon these four
factors, a fuzzy model was proposed to predict software maintenance. The experimental
results of the proposed fuzzy model show that the model is appropriate for predicting
software maintenance.
Several issues related to software maintainability were denitrified by A. Sharma et al.
[18] for CBS. Based upon the identified issues, a fuzzy logic based approach was
proposed to approximate the maintainability for component-based systems. The proposed
fuzzy logic based approach was validated using Analytical Hierarchy Process using case
study based approach. An empirical study based on historical data was conducted by M.
Dagpinar and J.H. Jahnke [19]. The maintenance history of a medium-sized OO system
was used to collect the historical data. This study also takes the concept of indirect
coupling in order to assess its impact. As evidence, their study uses the software
maintenance history of two software systems for relating software quality attributes to
software metrics recommended for OO software. Their results clearly indicated that size
and direct coupling metrics are important factors for software maintainability
measurement while other factors such as inheritance, cohesion, and indirect coupling
measures are not as much important.
The concept of cohesion in OO and procedural design was extended by M.
Perepletchikov et al. [20] for Service Oriented Computing (SOC). This extension
ultimately resulted in relating cohesion to the software maintainability of service-oriented
software. These assumptions also provide a base for a set of metrics that can be used to
measure the degree of cohesion of service oriented design constructs. Such metrics
provides valuable information about the prediction of software maintainability early in
the Software Development Life Cycle (SDLC).
5
A.D.Lucia et al. [95] carried out an empirical study for the purpose of developing cost
estimation models for software corrective maintenance. For this purpose they collected
existing data from five maintenance projects presently carried out by a software
enterprise. The proposed models, developed using multivariate linear regression
techniques, can help to provide valuable information about the costs of a project. Y. Ahn,
et al.[96] proposed Software Maintenance Project Effort Estimation Model (SMPEEM).
They propose an exponential function model which can show the relationships among
several factors such as software maintenance efforts, software maintenance environment
factors, and total function points of the software maintenance project.
J.H.Hayes et al. [97] proposed a model for adaptive software maintenance effort
estimation. The model was named as Adaptive Maintenance Effort Model (AMEffMo).
The proposed model provides valuable information about LOC changed and NOP
changed and their linkage to software maintenance effort. They observed that regression
models are suitable for predicting adaptive maintenance effort and provide valuable
information for software maintainers. R. Shukla and A.K.Misra [98] developed an ANN
based effort estimation model using Matlab. The feed forward back- propagation NN was
trained using Bayesian regularization training for one dataset. Different software
maintenance cost drivers and correspondingly its effect on software maintenance effort
has been evaluated taking into consideration different facts about layers and hidden
neurons. Their results showed that NN is able to effectively model the maintenance effort
as the ultimate results were sound within the published error limits.
1.2.2 Ripple Effect Analysis
Various techniques/methods have been developed by software engineering community to
evaluate/ measure software maintenance ripple effect. F.M. Haney [21] described a
technique called “Module Connection Analysis”. This technique uses the concepts of
applied probabilities and elementary matrix algebra to approximate the total number of
changes required to stabilize a system. S.S. Yau et al. [22] also contributed to the domain
6
of ripple effect analysis and their contribution mainly focused on estimating the
complexity of program modification.
S. Black [23] reformulated Yau and Collofello’s ripple effect algorithm [22] and
developed a tool that makes use of approximation algorithm for change impact analysis.
Myers [24] used dependence matrix describe dependencies between modules within a
system. N.L.Soong [25] used connectivity matrix and random markovian process with
respect to change impact analysis.
The research of G.Canfora et al. [26] concentrates on identification of potential and
actual relationships between modules that may cause side effects during system
modifications. Yau and J. S. Collofello [27] presented an algorithm for computing design
stability measurement. J.K. Joiner and W.T. Tsai [28] developed a tool known as DPUTE
(Data-centered Program Understanding Tool Environment). This tool uses the concept of
change impact analysis, program slicing and dependence analysis. S.Ajila [29] developed
a knowledge based model for the development of tool that can be used for impact
analysis. C.Mao et al. [30] have used the concept of component dependence matrix to
represent component-based software system. They have proposed algorithms for
analyzing ripple effect in component based software.
A three dimensional (3D) visualization techniques for software changes has been
provided by S.A. Bohner [31]. J. Zhao [32] developed an approach for change impact
analysis in aspect-oriented software. The study of D. Kung et al. [33] focused on the
types of code changes in OO. M.A. Chaumun et al. [34] have developed an approach to
evaluate the changeability of an OO system at class level. A.E. Hassan and R.C. Holt
[35] have developed several heuristics for the purpose of change impact analysis. The
model presented by Rajlich [36] caters for change propagation during software
maintenance and software evolution. The approach proposed by J. Han [37] also caters
for ripple effect analysis during software development and maintenance.
7
Hidden dependencies based change propagation algorithm was developed by Y. Zhifeng
and V. Rajlich [38] that can ultimately identify hidden dependencies in the artifacts. The
study of F.S .de Boer et al. [39] was also focused on change impact analysis and
ultimately identifying the cost of implementing a specific change. An approach that can
ultimately identify different architectural elements that can result in a change has been
developed by T. Feng and J.I. Maletic [40]. A probability based approach for OO design
to estimate the change likeliness was proposed by N. Tsantalis et al. [41] .
A domain-level behavioral model for analyzing change impact in software system was
proposed by Aryani et al. [42]. J.P Queille etal. [43] have presented a general model of
software impacts. This model employs flexible declarative propagation rules to describe
the way software objects affect each other. The study of J. Richard, T. M. Munro [44] has
also targeted early ripple effect analysis
A. Tang et al. [45] have introduced a Bayesian Belief Networks based approach to
identify dependencies between architecture design elements and decisions. M.H. Tang,
the study of W.L. Wang, and M.H. Chen [46] also caters for multi-phase change impact
analyses. The approach developed by N. Lassing et sl. [47] also caters to prediction of
complex changes and identification of the scope of these complex changes. J. Zhao et al.
[48] have presented an approach to support change impact analysis at the architectural
level. This approach is based on an architectural slicing and chopping technique. M.
Sherriff, and L. Williams [49] have proposed a methodology using the concept of
singular value decomposition for determining the impact of a new system modification.
The proposed methodology makes use of software change records analysis. The method
proposed by M. Jashki et al. [50] used the concept of dimensionality reduction
techniques. Such techniques can help to reduce the complexity of the collected
information as well as to faster the change impact analysis process.
M.Sherriff and L.williams [99] proposed a methodology for determining the impact of a
new system modification by analyzing software change records through singular value
decomposition. This methodology generates clusters of files that historically tend to
8
change together to address faults and failures found in the code base. B. Haider and S.
Black [100] proposed a ripple effect metric and consider its applicability as a software
complexity measure for OO software. Extensions were proposed to the computation of
ripple effect to accommodate different aspects of the object oriented paradigm. A.Jashki
et al. [101] proposed a static impact analysis technique that creates clusters of closely
associated software program files based on their co-modification history in the software
repository. D.Allemang [102] developed a method based on the Semantic Web
representation of a model that enables a system to automatically detect when one model
modification can potentially impact another.
1.3 Background and Motivation
Software maintenance is considered one of the most significant issues in software
development which has some serious implications in terms of cost and effort. It consumes
enormous amount of organization’s overall resources. According to Jones [51], “In 2001
more than 50 percent of the global software population was engaged in modifying
existing applications rather than writing new applications.” There are also some
remarkable facts about distribution of efforts across various maintenance types compiled
by Victor Basili, L. Braind and S. Condon in [52] as:
Enhancement 61%
Correction 14%
Adaptation 5%
Others 20%
According to G. Alkhatab [53], at least 60% of software life cycle cost is associated with
maintenance activities. In L. Erlike [92] it was shown that the effort required for software
maintenance had exceeded even 90% of the overall effort required in any typical software project.
Since then, with the introduction of software frameworks and customized solution, the overall
portion of software maintenance cost has increased further. On the other hand, software
architecture of an application has considerable effect on quality factors such as
maintainability, performance, reliability, and flexibility etc. Using software architecture
9
for quantification of certain quality factor will help organizations to plan resources
accordingly.
Further, the success or failure of any software development effort is judged by the degree
of achievement of various software quality attributes associated with it. We can say that
software quality is one of the most key issues in software development. It has some
serious implications in terms of customer satisfaction and system acceptance. Due to its
significance, it is also considered as one of the major challenges to be met by software
developer since she/he is responsible for fulfilling the quality requirements of the
software systems.
One way to address this challenge is to adopt architecture based software development.
Recently, the focus of business is transforming rapidly from manual to computer based
automations. Consequently, software intensive systems are becoming large and complex.
This is enhancing our emphasis on system quality which ultimately gives rise to the need
for software quality maintenance. In order to improve the quality of the software
maintenance in a rapidly changing environment, study of its ripple effect is very
significant. Ripple effect analysis based software quality maintenance technique would
help maintenance practitioners to understand the scope of effect of their changes and
would also help them in identifying what parts of the system must be checked for
consistency [22]. During this research, our motivation is to first develop a mathematical
model for architecture based maintenance prediction and then to propose a process and a
technique for architecture based software quality maintenance ripple effect analysis.
1.4 Contribution
As a result of this study, some major contributions made to the body of knowledge are as
follows:
1) A process for architecture based maintenance prediction has been developed.
2) A mathematical model for architecture based software maintenance prediction has
been developed which employs.
10
o A novel concept of weighted scenarios.
� Weighted scenarios classification with respect to quality attributes
has been developed.
� A methodology for assigning weights to scenario has been
provided.
o Certain factors that can affect software maintenance.
� Scaling factors have been developed for all of the factors that
ultimately affect software maintenance.
3) A complete process for architecture based software quality maintenance ripple
effect analysis has been presented.
o The concept of quality attribute properties has been presented.
o The concept of QA’s properties to component associativity matrix for
ripple effect analysis has been proposed.
1.5 Thesis Organization
The thesis consists of a further 5 chapters
In chapter 2 a brief overview of the literature with respect to software architecture
evaluation approaches is given. This chapter starts with categorization of different
approaches used for software architecture evaluation. Different scenarios based
approaches used for software architecture evaluation have also been discussed. The
chapter ends with a discussion of a scenario based approach used for modifiability
analysis.
The chapter 3 represents maintenance prediction model. This chapter begins with the
introduction of software maintenance and different software maintenance categorizes
discussed in literature. The concept of weighted scenario, factors affecting software
maintenance and the quantification of these factors used in the maintenance prediction
model are all part of this chapter. This chapter gives the detail description of architecture
based software maintenance prediction process.
11
The chapter 4 represents architecture based software quality maintenance ripple effect
analysis methodology. Various software maintenance models that cater for ripple effect
analysis implicitly or explicitly are discussed in this chapter. This chapter gives the detail
description of architecture based software quality maintenance ripple effect analysis
process.
The description of the case study used for illustration of architecture based maintenance
prediction and architecture based software quality maintenance ripple effect analysis
methodologies is given in chapter 5.
A summary of findings regarding architecture based software maintenance prediction and
architecture based ripple effect analysis is provided in chapter 6.
12
Chapter 2: Background Study
Software maintenance is a significant activity of software development lifecycle.
Effective maintenance relies heavily upon correct detection and early prediction of
critical areas of software. Literature presents us with various software maintenance and
prediction techniques. Unfortunately, many of them fail to meet the objectives
satisfactorily. Our study shows that software architecture can become a viable alternative
for software maintenance prediction.
In this chapter, a brief literature overview of software maintenance, its significance and
software architecture as a vehicle for maintenance prediction has been presented. The
chapter will help in establishing basic understanding that is essential for realizing the
context under which software architecture based maintenance prediction has been
proposed.
2.1 Software Maintenance
Software maintenance is an essential part of software development which consumes
significantly enormous amount of organization’s overall resources. Performance
improvement, error correction, adaptation to changes in environment and addition of
some new features are few examples of software maintenance. According to IEEE [68]:
“Software maintenance is the process of modifying a software system or component after delivery to
correct faults, improve performances or other attributes, or adapt to a changed environment.”
The above mentioned definition reveals the fact that software maintenance is a post
delivery activity, but according to Schneidewind [69], the notion of software maintenance
as post delivery activity makes it to be the hardest activity. Therefore, software
maintenance should start well before a system becomes operational. The definition of
13
software maintenance given by Pigoski [70] reflects the needs to start software
maintenance when development begins. According to this definition:
“Software maintenance is the totality of activities required to provide cost-effective support to a software
system. Activities are performed during the pre-delivery stage as well as the post-delivery stage. Pre-
delivery activities include planning for post delivery operations, supportability, and logistics
determination. Post-delivery activities include software modification, training, and operating a help desk.”
This definition dispels the notion that software maintenance is all about correcting and
fixing errors.
2.2 Categories of Software Maintenance
According to the definitions of software maintenance given in section 2.1, our work is
more relevant to the definition proposed by Pigoski [70] as we are interested in
maintenance prediction during early phases of software development such as software
architecture design. Over the last decade, many authors have studied software
maintenance so as to identify the reasons that derive the needs for change. As a result of
these studies, several classifications of software maintenance activities were defined.
According to B.P. Lientz and B.E. Swanson [71], there are three types of maintenance:
• Corrective maintenance: includes all the activities that deals with the correction of
faults or defects found
• Adaptive maintenance: includes all activities that deal with adapting the software
to certain changes in environment.
• Perfective maintenance: includes all activities that deal with accommodating to
certain new or changed user requirements.
According to ISO/IEC 9000-3 [72], software maintenance can be categorized as:
• Problem resolution: deals with the detection, analysis, and correction of certain
software nonconformities causing operational problems.
• Interface modifications: deals with the certain additions or changes made to the
hardware controlled by software.
14
• Functional expansion or performance improvement: This may be required by the
purchaser in the maintenance stage.
T.M. Pigoski [70] came up with idea of enhancement as a type of software maintenance
by joining adaptive and perfective maintenance. Pigoski argue that as adaptive and
perfective maintenance are not corrective in nature: they are improvements, so it is
meaningful to name it as enhancement.
The software maintenance categorization of B.P. Lientz and B.E. Swanson [71] was
redefined by IEEE Std. 1219-1998 [73], and emergency maintenance was added as new
type of software maintenance in addition to already defined types. According to IEEE
Std. 1219-1998 [73], emergency software maintenance is defined as:
• Emergency maintenance: “unscheduled corrective maintenance performed to keep
a system operational”.
It is also clear from the above definition that software maintenance can be either
scheduled or unscheduled.
2.3 The Significance of Software Maintenance
With the passage of time, the need for software maintenance increases and it becomes
difficult to keep the system up and running without maintenance. The following two
examples demonstrate the importance of software maintenance during software
development.
Lost pet fees cost Toronto $700,000
“The city [of Toronto] lost out on nearly $700,000 in pet fees [in 2000] because nearly
half of Toronto's dog and cat owners were never billed [due to computerized billing
system failure]. The staff who knew how to run the computerized billing system was laid
off. Only one city employee ever understood the system well enough to debug it when
problems arose. That [employee was also laid off in 2000 due to downsizing] leaving no
one to get things going again when the system ran into trouble and collapsed.”[74]
15
This story clearly emanates the need for corrective maintenance.
UK and Y2K
“The Associated Press reported on [April 14, 1997] that Robin Guenier, head of the UK's
TaskForce 2000, estimated that Y2K reprogramming efforts will cost Britain $50 billion
dollars, three times the guesstimates of business consultants and computer service
companies. Guenier suggested that 300,000 people may be required to tackle the
problem. Coincidentally, that number is roughly equivalent to the number of full-time
computer professionals in the UK.” [75]
This story clearly emanates the need for adaptive change to the Y2K environment.
2.4 Software Architecture and Software Architecture Evaluation
With the passage of time, software is becoming large and more complex which ultimately
may affect quality (e.g. maintainability and understandability) of the system. This is
putting even larger burden on resources if we want to maintain the quality of the system
to a certain standard. On the other hand, a considerable risk is associated with such
systems as it carries a large initial investment. These facts ultimately emanate the need
for software architecture development. According to L. Bass [2], “the software
architecture of a program or computing system is the structure or structures of the system,
which comprise software elements, the externally visible properties of those elements,
and the relationships among them”. Software architectures are key artifacts that
symbolize the early design decisions. These early design decisions have significant
impact on later phases of software development and guide the software development
process.
Software architecture is quite important artifact as it provides foundation for the rest of
the activities in software development cycle. The importance of software architecture laid
the foundation for architecture evaluation methods to predict design quality at very early
stages of software development. Architecture evaluation is used to determine whether
software architecture meet specified customer quality requirements or not. The main goal
16
is to identify potential risks and to evaluate system’s quality against the customer
requirements. Software architecture evaluation is a cost effective method to improve the
potential software quality of the system before it is implemented. Once the software
architecture of the required system is at hand, we can apply architecture evaluation methods.
When evaluating software architecture, one should have in mind the purpose of the
evaluation. Whether it is comparing candidate architectures, identifying trade-offs or
points for re-factoring, the chosen technique should provide adequate support for the
required activity.
Architecture evaluation plays a vital role in the improvement of overall system architecture in
the design process. Various methods like SAAM [4,59] and ATAM [5,60] are available for
assessing quality of software architecture. These techniques not only provide us with
alternative designs for better software development but can also serve as a tool for
comparisons and eliminating useless design alternatives.
2.5 Approaches to Software Architecture Evaluation
Literature reveals different approaches to software architecture evaluation. G. Abowed et
al. [54] have classified software architecture evaluation approaches as 1) Questioning
Techniques (i.e. scenario, checklist and questionnaires) and 2) Measuring Technique (i.e.
experiments, prototypes, simulations and metrics).
J. Bosch and P.Molin [55] have presented four approaches for software architecture
evaluation i.e. 1) Scenario based evaluation, 2) Simulation, 3) Mathematical Modeling,
and 4) Objective Reasoning. From the study of the above mentioned approaches, it is
clear that generally architecture evaluation can be categorized as:
• Questioning Techniques (i.e. scenario, checklist, questionnaires and objective
reasoning) and
• Measuring Techniques (i.e. experiments, prototypes, simulations and metrics).
The description of each technique is given below.
17
2.5.1 Questioning Techniques
Questioning techniques [54] generates qualitative question about architecture. It can be
applied to evaluate architecture for any given quality. The developments of the questions
are based on the considered quality factors for architecture. Questioning techniques can
be applied in early stages of software development where there is not enough information
available for collecting metrics or simulation.
2.5.1.1 Scenario A scenario is “a specified sequence of steps involving the use or modification of the
system” [54]. Scenarios are used to evaluate any particular NFR by completely
elaborating the true spirit of that NFR. These scenarios also capture certain changes that
may take place over a period of time in the software development lifecycle. As an
example, a requirement regarding software maintainability may be concretized using a
scenario that will provide valuable information such as changes in different artifacts,
hardware and environment. Such scenarios can then be used as a tool to estimate total
changes required to make the architecture in compliance with new situation [55].
Furthermore, the notion of context is also associated with QAs which shows that QAs do
not exist in isolation. A system may be modifiable with respect to certain changes but
may not be modifiable with respect to certain other changes, may be secure with respect
to some specific threats but may not be secure with respect to certain other threats, may
be usable with respect to some specific user but may not be usable with respect to certain
other class of users, may be efficient with respect to its utilization of specific resources
but may not be efficient with respect to certain other resources utilization, and so forth.
This emanates the need of context-based assessment of QAs. This concept of context-
based assessment of QA has led to the adoption of scenarios as the descriptive means of
specifying and evaluating QAs within a context [54].
18
The degree of representation of scenarios largely affects the performance of scenario
based approach. If the scenarios accurately cover all the variations of the system, the
evaluation has the capacity of generating an accurate result. This gives rise to the need of
generating two sets of scenarios. First set of scenarios for design purpose and another one
for evaluation purposes. Scenario evaluation takes place once a version of the
architecture is ready for evaluation. The objective judgment of the software engineer
evaluating the scenarios plays a vital role in the assessment quality [55].
2.5.1.2 Questionnaire A questionnaire is a list of typically general and relatively open questions that ultimately
provides useful information about architectures. A questionnaire not only provides
information about the architecture but also provides information regarding the process
architecture was generated and documented. In that case, we seek some specific questions
but certain questions focus on the technical details of the architecture description. The
evaluation team is assigned the task of looking for a satisfactory response and in this
regard, it usually probes a single question to a certain level of detail that is essential to
satisfy their concern. This is an easy to use mechanism through which the domain of
interest can be characterized and constrained [54].
2.5.1.3 Checklist “Just as a building inspector uses a checklist to ensure that a structure is in compliance
with the building codes, software architects use a checklist to help them keep a balanced
focus on all areas of the system.” [56]. A checklist is a significantly elaborate set of
questions which are prepared after extensive evaluation of a common set of systems.
These are usually focused on certain qualities of the system. For example, all questions
related to performance in a real-time information system will inquire whether the system
is writing the same data multiple times to disk or not. Certain question will provide
information regarding handling peak loads as well as average loads [54].
19
2.5.1.4 Objective Reasoning A fourth approach to evaluate NFR is to employee objective reasoning based on logical
arguments. The significant insight gained by experienced software engineers is very vital
in avoiding bad design decisions. Sometimes based on anecdotal evidence, this
experience is often justified by a logical line of reasoning.
This approach is problematic in its application due to subjective nature of evaluation
involved as intuition and experience plays major role in this exercise. Most software
architects have well-developed intuitions about ‘good’ and ‘bad’ designs. This intuition is
based on their practice and experience in certain domains. Such experience is very
helpful in constructing a base for an objective argumentation which ultimately is based
on either the above mentioned approaches or on logical reasoning. On the other hand, this
approach may be helpful for providing input to other evaluation approaches. For
example, a software engineer may identify certain maintainability problems in the
architecture based upon his experience and, to convince others, define a number of
scenarios that demonstrate this [55].
2.5.2 Measuring Techniques
Measuring techniques proposes certain quantitative measurements regarding software
architecture. Instead of providing a way to come up with the questions to be asked,
measuring techniques provide answers regarding particular characteristics of an
architecture for which an evaluator might already have some specific questions. For the
reason that questions almost always precede the answers, these measuring techniques are
considered to be more established than the questioning techniques. In fact, we only saw
support of measuring techniques to answer certain questions regarding performance or
modifiability [54].
20
2.5.2.1 Simulations One very popular approach for estimating NFRs of the system is though simulating the
architecture. This simulation involves the implementation of main or core components of
the architecture while creating a simulation for other components. The context,
constraints, and environment in which the system is supposed to operational, could also
be simulated at an appropriate abstraction level. Executing these simulations can generate
very important data for system architecture related design decisions. Simulation
development requires that the software engineer must describe precisely and accurately
the operational behaviour and interactions of the architectural components. Such
specification also helps in revealing inconsistencies in the design.
Simulation is particularly helpful for evaluating operational NFRs, such as fault-tolerance
and performance while development NFRs such as flexibility and maintainability can be
more precisely evaluated using scenarios. This is not to say that other aspects of software
architecture can not be evaluated using simulations. For instance, we can evaluate
reliability of the system by making changes to the implementation according to certain
change scenarios and then analyzing the overall impact. A sample scenario to help
evaluate the system architecture is given in figure 2.1.
Figure 2.1 Simulation of a system [55]
We can see that by simulating the interface between the top level architecture
implementation and the communication software both communication and sensor
behaviour could be evaluated. Scenarios can also be derived using simple Markov
models. When working with simulations, we should remember that the accuracy of the
evaluation depends of course on how well the model reflects real world conditions [55].
21
2.5.2.2 Mathematical Modeling Mathematical modeling is an appropriate approach for assessing operational NFRs and
for this reason it is also considered as an alternative approach to simulation. However, we
can combine both the approaches for certain reasons. For example, to estimate the
computational requirements of individual software components in architecture, we can
employ performance modeling. The results derived from mathematical modeling can then
be provided as input to simulation for identification of computational requirements of
certain execution sequences in architecture [55].
2.5.2.3 Metrics
Metrics are observations on a particular measurable attribute of an entity. This approach
aims at measuring attributes of software architecture which enables assumptions
concerning the quality of the architecture. In a metrics-based evaluation, the focus should
not be solely based on the measurements or metrics results, but also on the underlying
assumptions. For example, when measuring performance an evaluator also makes
assumptions regarding the utilization of resources by the system [54].
2.5.2.4 Prototypes A prototype is a functional or non-functional model, of the system or parts of the system
[57]. It can be used to get feedback from users, for feasibility studies, or identifying
requirements. Developing a prototype of the system may help to create and to clarify the
architecture. A prototype is actually a model of the architecture whose components
consist of functionless stubs. The development of a detailed prototype is typically
expensive if the purpose of the develop prototype is just to review the architecture. On
the other hand, such artifacts often exist as a part of the software development process. In
this case, using prototypes during a architecture review or to answer questions that arise
during the architecture review process becomes a normal and natural procedure [54].
22
2.6 Software Architecture Analysis using Scenarios
The use of scenarios to analyse software architecture with respect to certain QAs is not
new. D.L. Parnas [58] introduced the essential principle of scenario based evaluation in
1972 [58]. In scenario- based analysis approach, possible sequences of events are defined
and their effect on the system is evaluated. R. Kazman et al. [4,59] came up with scenario
based software architecture analysis method (SAAM). SAAM consists of six steps: (1)
develop scenarios, (2) describe candidate architecture(s), (3) scenarios Classification, (4)
Individual evaluation of indirect scenarios, (5) Assessment of scenario interaction, and
(6) overall evaluation. SAAM does not target a specific QA; rather it focuses on the QAs
specified by the corresponding stakeholder. The main goal of the SAAM is to verify that
the corresponding architecture embodies the basic architectural assumptions and
principles against the artifacts describing the desired properties of an application.
However, the success of SAAM largely depends upon the experience of the assessor. It is
for the reason that SAAM does not prescribe architectural views. SAAM evaluates
software architecture with respect to single QA. Figure 2.2 represents the SAMM inputs
and activities.
Figure 2.2 SAMM inputs and activities [59]
To be able to analyse software architecture with respect to multiple competing quality
attributes, kazman et al [5,60] evolved SAAM into ATAM (Architecture Tradeoff
Analysis Method) which consists of nine steps: (1) Present ATAM - Present the concept
of ATAM to the stakeholders (2) Present Business Drivers - Everyone in the process
23
presents and evaluates the business drivers for the system in question, (3) Present the
Architecture – the high level architecture of the system is presented by the architect with
suitable level of detail, (4) Identify Architectural Approaches - the team presents different
architectural approaches and discuss it, (5) Generate Quality Attribute Utility Tree - the
system’s core business and technical requirements are defined and these requirements are
then map to an appropriate architectural property. A scenario is required for any such
given requirement, (6) Analyze architectural approaches – Each and every scenario is
analyzed and assigned a priority level. In the next step architecture is assessed against
each scenario, (7) Brainstorm and prioritize scenarios - the current scenarios has to be
presented and expended among the larger stakeholder group. (8) Analyze architectural
approaches - Perform step 6 again with the additional knowledge of the larger
stakeholder community, (9) Present results - present all documentation to the
stakeholders. The objective of ATAM is to assess software architecture potential with
respect to multiple competing QAs. ATAM does not consider in-depth evaluation of a
single QA, but rather on describing trade-offs between QAs. The following figure 2.3
represents the ATAM activities that consider scenarios and figure 2.4 represents ATAM
phases.
Figure 2.3 ATAM activities that consider scenarios [60]
24
Figure 2.4 ATAM phases [60]
C. Lung et al. [62] extended SAAM to focus only on two quality attributes i.e. evolution
and re-usability and named it SAMMER (Software Architecture Analysis Method for
Evolution and Reusability). SAMMER uses scenarios to evaluate various areas of SA
activities. The framework provided by SAAMER consists of four activities: (1) gathering
information about stakeholders, SA, quality, and scenarios; (2) modeling usable artifacts;
(3) analysis; (4) evaluation. The following figure 2.5 represents the activities of the
SAMMER.
Figure 2.5 framework for architecture information gathering and analysis [62]
25
SBAR (Scenario Based Architecture Re-engineering) was another contribution from P.
Bengtson and J. Bosch [63] that not only considers architecture design but also considers
scenario based assessment of the software QAs of a detailed architecture of a system.
SBAR uses four different techniques for evaluating QAs (i.e. scenarios, simulation,
mathematical modeling, and experience based reasoning). For each quality attribute, the
suitable technique is selected. Figure 2.6 represents SBAR activities.
Figure 2.6 SBAR activities [63]
ESAMMI (Extending SAAM by Integration in the Domain) is another scenario based
architecture evaluation method. ESSAMI employs analytical and reuse concepts and is
achieved by integrating the SAAM in the domain-specific and reuse-based development
process [64]. Figure 2.7 represents ESAMMI approach.
26
Figure 2.7 ESAMMI approach [64]
One of the observed problems with the above mentioned software architecture analysis
methods is that these approaches do not make distinction between conventional
architecture concerns and architectural concerns that crosscut multiple architectural
components. Using the above mentioned software architecture analysis methods; it is
possible that prospective crosscutting concerns might not be identified as aspects and
ultimately remains uncertain at the software design and programming level. Such
situation will ultimately lead to tangled code in the system. The QA that the architecture
analysis methods attempt to confirm will still be obstructed.
To overcome this issue, B. Tekinerdogan [93] proposed Aspectual Software Architecture
Analysis Method (ASAAM). ASAAM evaluates the architectural aspects with respect to
existing software architecture design. SAAM provides the foundation for ASAAM and
includes explicit mechanism for describing architectural aspects and tangled components.
ASAAM consist of 5 steps: 1) Candidate architecture development 2) Develop scenarios
27
3) Individual scenario evaluation and aspect identification 4) Scenario interaction
assessment and component classification 5) Architecture Re-factoring. The main purpose
of ASAAM is the identification of architectural aspects which make it as complementary
technique to other architecture analysis methods.
Another software architecture analysis method that explicitly treats concerns as first-class
entities is Concern Oriented Software Architecture Analysis Method (COSAMM) [94].
COSAMM is an iterative method for assessing and transforming software architectures.
COSAMM is inspired by the ASAAM. COSAMM makes use of Design Structure
Matrices ( DSMs) and Domain Mapping Matrices(DMMs) . DSMs are used for concern
identification and dependency analysis of architectural modules and DMMs are used to
measure scattering and tangling. COSAMM consists of 3 phases: 1) Preparation Phase 2)
Analyse Phase and 3) Transformation phase. The preparation phase results in the artifacts
used in the COSAAM evaluation such as candidate software architecture design and
stakeholders concerns. The analysis phase of COSAAM involves a description and
measurement of scattering and tangling of concerns and modules. The information
provided during this analysis is used in the transformation phase that results in software
architecture transformation.
2.7 Analyzing Software Architecture for Modifiability Using Scenario
Software modifiability is an important characteristic of software development, as
software extensive systems must be flexible with respect to evolving requirements,
platforms, and other environmental pressures. Hence software change is inevitable which
results in software development of more than several years. According to G. Alkhatib
[53], at least 60% of software life cycle cost is associated with maintenance activities.
Because of constant change, modifiability plays a key role in both current and future
software technologies.
According to M.M. Lehman et al [65] the failure of a system to evolve, results in an
early death for the system. The environment in which software systems works changes
28
continuously [66]. The expected future evolutions of the software systems can be
indicated if this change in environment is properly assessed. Therefore, we must consider
such design solutions that can support future incorporation of new and changed
requirements. In case the designed architecture is flexible enough to support different
types of modifications, then the required modifications can be made easily. One problem,
however, is the scarcity of the techniques or means that the software architect can use for
the purpose of making sure that the ultimate goal of high modifiability has been achieved
by the corresponding design solutions. We can perform software architecture analysis to
achieve this goal.
In software architecture analysis, the corresponding software architecture of a system is
analyzed to make sure that it fulfills customer requirements. Different software
architecture analysis methods available in literature that target different QAs i.e. SAAM
[59], ATAM [60], etc. Architecture Level Modifiability Analysis (ALMA) is one such
method that analyses software architecture for modifiability.
ALMA (Architecture level Modifiability Analysis): ALMA is a software architecture
analysis approach which considers only Modifiability perspective of software
architecture [67]. For a complete software architecture analysis, ALMA needs the support
of certain other different architecture level analysis methods as well. ALMA has the
following characteristics:
• Focus on modifiability.
• Differentiate multiple analysis goals.
• Make important assumptions explicit.
• Provide repeatable techniques for performing the steps.
Architecture-level modifiability analysis can be used for various purposes. ALMA
analyses the following mentioned goals for architecture-level modifiability analysis:
maintenance effort prediction, risk assessment, and comparison of candidate
architectures.
29
ALMA consists of the following five steps:
1. Set goal
2. Describe software architecture:
3. Elicit scenarios
4. Evaluate scenarios
5. Interpret the results
The detail description of each and every step is given below.
1) Setting the goal: Determine the goal of the analysis is the first activity in architecture
level modifiability analysis. The following mentioned goals can be chased in architecture
level modifiability analysis:
• Maintenance cost prediction: estimate the ultimate effort that is needed to modify
the system to accommodate future changes
• Risk assessment: it is possible that the specified architecture is inflexible with
respect to certain types of changes. This step involves identification of such
possible changes.
• Software architecture selection: compare two or more candidate software
architectures with respect to certain requirements and select the optimal candidate
2) Architecture Description: different required information about the software
architecture is collected in second step of ALMA. The architectural information on the
basis of which the analyst has to evaluate the scenarios is generally required for
modifiability analysis. Scenario evaluation consists of two steps: 1) analysis of the impact
of the scenarios and 2) expressing this impact. Architecture-level impact analysis is an
activity that is carried out mainly for the purpose of the identification of the certain
architectural elements that are affected by a modifiability scenario. The architectural
elements that affected by modifiability scenario includes directly affected components
and indirectly affected components. Depending on the goal of the modifiability analysis,
some measurement scale can be used to express the ultimate affect of such scenarios.
30
3) Change scenario elicitation: this step involves selecting different change scenarios to
be used in the architecture evaluation step. The following two activities are involved in
eliciting change scenarios:
• identifying stakeholders to interview,
• documenting the scenarios that result from those interviews, etc
4) Change scenario evaluation: this step of ALMA is mainly used to evaluate the effect
of the change scenarios on the candidate architecture. To evaluate change scenarios, the
architects and designers need the cooperation of the analyst also. The analyst determines
the impact of change scenarios along with software architect and software designers in
order to articulate the results in a way suitable for the goal of our analysis. This is
generally known as architecture level impact analysis. In general, impact analysis
consists of the following steps:
• Identify the affected components
• Determine the effect on the components
• Determine ripple effects
The first step involves the identification of the directly and indirectly affected
components that need to be modified to employ the change scenario. The second step
involves identification of the corresponding functions of the components that are affected
by the changes. To determine the effect on the certain components, we also need to
consider the systems in the operational environment and their interfaces, for the
following reasons:
• There is possibility for change propagation over system boundaries;
• The system may be affected by changes in environment or
• The environment may be affected by changes to system
The third step involves identification of ripple effects. This ripple effect will occur as a
result of the certain modifications that are needed. It is important to note that ripple effect
phenomenon may be a recursive phenomenon. As not all information is available at the
architecture level, so it is important to note that we may have to make assumptions about
the occurrence of ripple effects.
31
5) Interpretation: Once the evaluation of the change scenario is completed, the results
are to be interpreted and conclusions about the software architecture are drawn. The
system requirements and the goal of the analysis play a vital role in the interpretation of
the results.
The mathematical model for software maintenance prediction suggested by ALMA can
be written as:
Mtot = .),().(11
∑∑
==
kc
m
mnn
ks
n
CSVSP (2.1)
Where
P(Sn) the probability weight of scenario n
V(Sn,Cm) the affected volume of component m in scenario n
ks = number of scenarios
kc = number of components in architecture
The model sufficiently describes maintenance effort at the time of its proposal. However,
as new breakthroughs in research were made, several emerging factors now need to be
taken into considerations. In the following lines, we shall briefly summarize some of the
emerging concepts which now need to be incorporated.
Scenarios have emerged as a significant tool to present system at the earlier stages. If we
can use scenarios to predict future maintenance effort, we can come up with a more
realistic system design. This can also reduce maintenance effort significantly. ALMA
model uses scenarios to predict software maintenance effort. However, no classification
of these scenarios is made in this model with respect to complexity. This means that all
scenarios get equal significance without any concern to their actual effort needed. This
can result in wrong maintenance effort projection. To overcome this problem, we have
also incorporated the concept of scenario classification with respect to their complexity to
make maintenance effort prediction more meaningful and more realistic.
32
The software maintenance prediction model suggested by ALMA does not take into
consideration several factors which affect maintainability of the software to a great extent
and whose inclusion can be very significant for accurate maintenance prediction. Such
factors include system novelty, turnover and maintenance staff ability, documentation
quality, system life span and testing quality etc. keeping in mind the significance of these
factors, their absence from ALMA model seriously affects the quality of ultimate
software maintenance prediction. To overcome this, we have carefully analyzed and
selected such factors which are critical for software maintenance prediction and have
included them in our model. We have not only selected various factors that can affect
software maintenance prediction but have also quantified them using COCOMO II [82]
and expert opinion. In this way our mode has laid down strong theoretical foundations for
various software applications and their predicted maintenance effort. Using this
quantification scheme also provides us with an opportunity to make maintenance
prediction automated as well as intelligent in future.
2.8 Summary
In this chapter, a comprehensive review of software maintenance and its related activates
with a particular emphases on software maintenance prediction has been presented. The
literature shows that software maintenance is a critical and extremely expensive activity,
capable of destabilizing the whole project if not handled carefully. Correct and reliable
maintenance prediction can help ensure that the maintenance effort does not go out of
control. Maintenance prediction is related to determining how much effort will be needed
in future to correct, update, and create any artifact in the software. Most of the
maintenance prediction models predict the maintenance effort after delivery of the
software. Software architecture evaluation is one such mechanism which can be used for
early and reliable maintenance prediction. For software architecture evaluation, scenarios
have been used in ALMA model for maintenance prediction. Classification of scenario
and inclusion of various factors critical for software maintenance prediction in AlMA can
further enhance the reliability of software maintenance prediction at software architecture
level.
33
Chapter 3: Software Maintenance Prediction Model
3.1 Introduction
Software architecture is an essential part of any modern day software products or
services. Software architecture is a visual artifact which represents a system at a highest
level of abstraction. Such abstract representation of a system helps in understanding and
maintaining a system. These characteristics of software architecture make it suitable to
deal with software qualities. Consequently, software architecture design should be based
on the quality requirements [2]. Unfortunately, software architecture community lacks
effective solutions that can guide the architectural design. Only little methodological
support is available; where as most architecture design activity is ad-hoc based or based
upon architects intuition and previous experience [71].
The main reason for the above mentioned problems is that very few techniques are
available to software engineering community for predicting the quality of the system at
an early stage (i.e. software architecture). The prediction about system’s quality at
software architecture level is particularly problematic because at this stage early design
decisions are considered and we have lack detail information required for evaluating such
early design decisions until much later in the software development process [9]. The
proposed software maintenance prediction model is one such contribution in this domain.
The proposed software maintenance model takes requirements, domain knowledge, and
general software engineering knowledge as input in order to prescribe application
architecture. Once application architecture is prescribed, then weighted scenarios and
certain factors like system novelty, turnover, maintenance staff ability, documentation
quality, and testing quality etc that affect software maintenance are applied to quantify
maintenance effort.
34
3.2 Complexity Based Scenario Classification with Respect to QA
Literature study reveals different definitions of the term “Scenario”. According to R.
Kazman [76], “A scenario is a short statement describing an interaction of one of the
stakeholders with the system”. According to J.D. Meier [77], in software development
organizations, scenarios are considered as either
• Use Case
• A specific path through a use Case
• Instance of a use Case
However there is a consensus among researchers that scenarios can be used as an
effective tool [78] for:
• Description of a usage context so as to reason about design decisions
• Informal narrative description of responsibilities, services and use within object
oriented software design
• Identifying dependencies between a certain requirement specification and the
corresponding environment in which it will have to function
Use of mock-ups and prototypes, scenes and narrative descriptions of context and
examples are some of the examples of scenario based approaches and are widely used by
Information System, Human Computer Interaction, Requirements Engineering, and
Software Engineering communities [78].
Several architecture evaluation methods have been developed i.e. SAAM [4], ATAM [5],
and ALMA [67] etc. Most of these methods use scenarios as the basis for architecture
evaluation; however, none of these methods differentiate/classify scenarios in respect of
their complexity. There is limited amount of evidence on classifying scenarios. SAAM
[4] differentiates scenarios as Direct and Indirect scenarios but does not assign weightage
to scenarios. C. Rolland et al. [78] have classified scenarios by providing a 4-dimensional
framework which includes:
35
• The “form view” describes the expression mode of the scenario. The form view
tells us how scenarios are described i.e. formally or informally, static or
animation.
• The “contents view” describes the type of knowledge that is expressed in a
scenario i.e. whether a scenario describes the description of a system’s
functionality or system constraints.
• The “purpose view” describes the role that a scenario plays within the whole
process of requirements engineering.
• The “life cycle view” of a scenario tell us about the evolution that a system or its
certain artifacts will experience throughout the life cycle. Creation, refinement, or
deletions are examples of such operations. This view helps us in determining the
persistence, modifiability, or transitional capability of system or any of its
artifacts.
It is clear from the above discussion that none of these approaches provide scenario
classification with respect to complexity. Ultimately we developed an approach that can
provide complexity based scenario classification with respect to QAs. These QAs are
organized in to quality models, like McCall, Boehm, FURPS and ISO/IEC 9126.
J. A. McCall et al. [79] organized quality attributes into a software quality model that
describes the following three categorizes:
• Product operation: it describes operational characteristics i.e. correctness,
efficiency, usability, integrity etc.
• Product revision: it describes ability of a system to make changes i.e.
maintainability, testability, and flexibility.
• Product transition: it describes system adaptability to a new environment i.e.
portability, reusability, and interoperability.
The following figure 3.1 represents the McCall’s quality model.
36
Figure 3.1 McCall’s software quality model [79]
B. Boehm et al. [80] also developed a software quality model that is a sub set of McCall’s
quality model with two additional quality attributes i.e. understandability and
modifiability. Hence this model consists of modifiability, portability, reliability,
efficiency, usability, testability, and understandability. The figure 3.2 represents Barry
Boehm et al’s quality characteristic tree.
37
Figure 3.2 Boehm’s quality characteristics tree [80]
FURPS [103] quality model was used by Unified Process but later on IBM extended it to
FURPS+ with some additional quality requirements. FURPS abbreviation is named after
the first letters of the functionality, usability, reliability, performance and supportability.
ISO/IEC 9126 [104] describes software quality in terms of internal quality, external quality
and quality in use. This model defines a framework for specifying quality requirements and
for trade-off between software product capabilities. The main difference between this model
and other models is that it describes a 1-to-1 relationship between a characteristic and a sub
characteristic. This model includes portability, maintainability, efficiency, usability,
functionality and reliability. The following figure represents ISO/IEC 9126 software quality
model.
38
Figure 3.3 ISO/IEC 9126 quality model for external and internal quality [104]
The study of the above mentioned quality models and literature study reveals the fact that
we do not have complete list of QAs. Therefore, it was decided to take few QAs as a
sample and used it for complexity based scenario classification. The sample list includes
usability, reliability, performance, and supportability. This sample list is heavily
influenced by FURPS [79] model. This FURPS model has been modified in various
manners to suit our proposed model. For example functionality is not one of our concerns
as our model deals with early maintenance prediction when the functionality has not been
explicitly implements. Supportability in FURPS has been accommodated through
39
maintainability (changeability). The following table describes complexity based scenario
classification with respect to quality attributes.
Table 3.1 Complexity Based Scenario Classification with respect to QA
3.2.1 Methodology for Assigning Weightage to Scenario
For the purpose of assigning weightage to different scenarios based upon its complexity
level, we have used COCOMO II [82] post architecture driver CPLX (product
complexity) by analogy. By using this factor, we will assign simple average or complex
ranking to our scenarios. The scaling factors for CPLX are given follows:
Table 3.2 COCOMO II scaling factors for Complexity [82]
CPLX V.L L N H V.H X.H
S.F 0.73 0.87 1.00 1.17 1.34 1.74
As the principles of COCOMO stand, the scaling factors are ranked as Very Low (VL),
Low (L), Normal (N), High (H), Very High (VH) and Extra High (XH). However, our
requirement is to assign weightage to scenarios as simple, average and complex. To
40
overcome this hindrance, an expert meeting was convened where it was mutually agreed
that the scaling factors should be reduced to three i.e. Simple, Average and complex. We
have borrowed this concept of classification from function points which uses similar kind
of classification i.e. Low, Average and High [105]. The simple scaling should cater to
very low and low, average should cater to normal and complex should cater to high, very
high and extra high respectively. It was also suggested that experimentation on selected
case study should be carried out to select appropriate values for these three scaling
factors. To arrive at suitable values of the scenario described above, we perform
experimentation on our case study using different value sets given in table 3.2. The
experiments showed that the appropriate values for simple, average and complex
scenarios are the ones given in table 3.3.
Table 3.3 Scenario Weightage
Scenario Simple Average Complex
Weightage 0.20 0.25 0.50
These weightage are later used in the proposed mathematical model for software
maintenance prediction (at the end of section 3.4). However the detail of these
weightages is given here to maintain the continuity of study.
3.3 Proposed Architecture Based Software Maintenance Prediction Process
In this section, the proposed architecture based software maintenance prediction model
has been described and elaborated in detail. This process can be visualized in figure 3.4.
The basic steps underpinning architecture based maintenance prediction process include:
3.3.1 Requirements Specification: it represents the specification that describes the
requirements for the corresponding architecture to be developed. Different stakeholders
identify the functional and non-functional requirements. Domain knowledge is used to
identify domain concepts and reference model. General software engineering knowledge
is required to analyse, classify, and specify requirements. These three concepts (e.g.
41
client, domain knowledge, and general software engineering knowledge) can be used as a
required input for requirements specification development.
Figure 3.4 Architecture based development and maintenance prediction process
3.3.2 Components: Once the requirements specification is developed, the software
architect/ architecture team reviews these requirements for architecture relevance and
completeness. If software architect/ architecture team is satisfied with the requirements,
the next step is to identify different system components. Each component will address
certain responsibilities and will also interact with other components in the system.
3.3.3 Software Architecture: After the requirements are precisely defined, then
software architect extracts the system quality requirements as it provides a foundation for
component configuration. Such configuration represents the system at highest level of
abstraction.
3.3.4 Maintenance Prediction Method: The maintenance prediction method as
shown in figure 3.4 can be viewed as a function taking software architecture; growth
42
scenarios profile and factors affecting maintenance as an input and generates
maintenance effort as output. Growth scenario profile is set of change scenarios which
consist of perfective and adaptive change scenarios; but does not include remaining
corrective maintenance because it is too abstract to be pertinent in this process [4]. A
scenario profile for quality attribute can be specified as either complete or selected
profile. A complete scenario profile includes all possible scenarios as part of the profile.
On the other hand, a selected profile includes randomly selected scenarios from a large
population of scenarios [9]. The growth scenario profile should be designed such that it
includes all possible change scenarios for architecture based software maintenance
prediction; and the research has tried its best to make sure that growth scenario profile is
as representative as possible.
The step by step maintenance prediction method can be represented as follows in figure
3.5.
Figure 3.5 Maintenance prediction process
The detail description of each step is given below:
3.3.4.1 Design growth scenario profile: Software architect/ architecture team, client and
domain experts design growth scenario profile that represents perfective and adaptive
change scenarios. Domain knowledge and general software engineering knowledge can
play a significant role in designing growth scenario profile to make it as representative as
possible.
3.3.4.2 Complexity based scenario classification: Once the growth scenario profile is
developed, the next step is to classify scenarios based upon their complexity levels as
described in table 3.1. As a rule of thumb, simple scenarios will require less maintenance
effort as compared to average and complex scenarios. Such scenario classification will
also help the software architect or architecture design team to evaluate the architecture
Design growth
scenario profile
Perform complexity
based scenario classification
Defining the probability of each scenario occurrence
Perform ripple
effect analysis
Predict maintenance effort
43
for complex scenarios support. On the other hand, it will also help the organization to
plan resources accordingly.
3.3.4.3 Defining the probability of each scenario occurrence: During the life time of the
system, certain scenarios have greater likelihood of occurrence than others scenarios.
Hence, in order to balance the impact on the prediction method of such occurrence
variation, each scenario is assigned a certain probabilistic weight. The weightage measure
of the scenario is defined as relative probability during a specific time interval, e.g. a
year, or between two releases. Thus high probability scenarios will reflect the most
frequent maintenance tasks and visa versa. The weightages are assigned based upon
historical maintenance data, i.e. if it is available. If no such historical maintenance data is
available, then we should use certain other means for estimating scenario weightage (i.e.
domain expert or software architect etc)[1].
3.3.4.4 Change impact analysis: The basic purpose of change impact analysis is to identify
different consequences of a change to a particular artifact (e.g. software architecture in
this case). As this research is also concerned with maintenance prediction, therefore, it is
important to visualize the scope of ripple effect as described below in figure 3.5. (Please
see chapter 4 for detail)
Maintenance Effort
Figure 3.6 Ripple effect analysis process
Not only is the scope of impact analysis important, but also the extent to which different
components are affected; and, this will also require estimating architecture size initially
by using OO metrics or we can use similar application / earlier releases to extract data
[1].
So
ftware A
rchitectu
re
Change Scenario
Directly Affected Components
Indirectly
Affected Components
Total Ripple Effect
Maintenance Prediction
44
3.3.4.5 Predicted maintenance effort: Software maintenance prediction activity is next to
change impact analysis activity. Software maintenance effort prediction can be estimated
using the following steps:
1) Identification of the number of maintenance tasks with assigned relative
probabilities and complexity category.
2) Average effort per maintenance task that will be multiplied with the number of
maintenance tasks identified in step1 [1].
3) Factors affecting software maintenance; summing up values of these factors
(section 3.4) and then multiplying with the above two components of maintenance
effort prediction.
3.4 Factors Affecting Software Maintenance Cost
One of the most important purposes of the proposed maintenance prediction model is to
determine how much effort/cost will be required for satisfactory development and
operation of the system once the system has been commissioned or has been deployed.
The proposed model uses software architecture and its various artifacts to (1) predict the
maintenance required and (2) to calculate the effort needed to perform the predicted
maintenance. The question may arise how it is possible to collect information about these
factors so early in the software project life cycle.
We have to remember that in today’s modern software development methodologies, there
are several approaches to document, record and retrieve useful information which is not
only helpful for current project but can be used for future projects as well. For example,
organizations regularly maintain records of project turnover rate, average project
experience curves, previous maintenance records, and compliance etc. This information
combined with expert judgment analysis and precise specifications can provide us with
suitable values for these factors. In this context, S.L. Pfleeger and J.M. Atlee [81] have
presented some of the technical and non-technical factors that can ultimately affect
software maintenance costs. These factors are discussed as follows:
45
1) System Novelty: System novelty can be described as development of a new
product or developing a new process for developing that product. This affects
maintenance since maintenance team can not rely on their past experience while
fixing the faults and bugs of a novel system. A novel system also needs more test
data to effectively test the product. Therefore, a novel system increases the
maintenance effort.
We already know that precedentedness (how novel the project is for the
organization) is one of the factors that affect maintainability described by
COCOMO II [82]. Hence we can adopt the same scaling factors accordingly,
defined by COCOMO II for our approach.
Table 3.4 COCOMO II scaling factors for system novelty [82]
S.F V.L L N H V.H X.H
PREC Unprec
6.20
4.96 3.72 2.48 1.24 Familiar
0
2) Turnover and Maintenance Staff Ability: Maintenance is a highly human intensive
activity. It requires a lot of training to make new people adept in maintenance task
of a software product or service. The maintenance effort and cost increase
substantially if the team members are often shuffled among groups very or if they
shift from their current jobs to other frequently. Similarly maintenance staff’s
ability in terms of maintenance experience can have significant impact on the
maintenance activity.
Personal continuity is one of the factors described by COCOMO II [82]. This
factor can be helpful in identifying the scaling factor for turnover i.e. an
organization having very high personal continuity shows low turnover and visa
versa. Hence we can adopt the scaling factors accordingly.
Table 3.5 COCOMO II scaling factors for Turnover [82]
Turnover 48% / year 24%/year 12%/year 6%/year 3%/year
S.F X.H V.H H Nom L V.L
1.29 1.12 1.12 1.00 0.81
46
Programmer application experience is also described by COCOMO II [82]. This
factor can be helpful in identifying scaling factors for maintenance staff ability i.e.
programmer having application experience (as per scaling factor) shows
maintenance ability correspondingly; as shown in table 3.6.
Table 3.6 COCOMO II scaling factors for maintenance staff ability [82]
MSA <=2 months 6 months 1 year 3 years 6 years
S.F V.L L Nom H V.H X.H
1.22 1.10 1.00 0.88 0.81 n/a
3) Documentation Quality: If the documentation is poor; or system code or design is
poorly documented, then it will be very costly to find and correct any errors that
are present in the system. This observation points towards the fact that
documentation quality also has a serious effect on maintenance effort.
Documentation as a factor is also described by COCOMO II [82]. So we can
adopt the same scaling factors for our approach.
Table 3.7 COCOMO II scaling factors for documentation [82]
4) Testing Quality: As the experience of software engineering has shown that the
number of errors can be significantly reduced by applying an effective testing
strategy. With reduced errors, maintenance effort can be quite low. So, better
testing quality reduces maintenance effort. Architecture risk resolution is one of
the factors described by COCOMO II [82]. We can adopt the same scaling factors
by analogy, for testing quality.
47
Table 3.8 COCOMO II scaling factors for testing quality [82]
S.F V.L Low Nom Hi V.H X.H
Testing quality 7.07 5.65 4.24 2.83 1.41 0
Some testing techniques used in most organizations could be used for this method
as well.
5) System Life Span: A system with longer lifespan requires more maintenance
efforts than a system with shorter one. Many small scale faults in the system can
be ignored if the lifespan of the system is short (a few months for example).
However, even these small shortcomings can cause a lot of damage for a system
in long run if it has a longer life span (a few years at least). The system life span
can have significant impact on degree of hardware dependability with respect to
application type.
6) Dependence on Changing Environment: Dependence on changing environment
is mainly concerned with type of system i.e. either system under consideration is
of S-type or P-type or E-type system. But such type of classification is mainly
related to development activities and can have significant impact to measure
development effort. Therefore, we will ignore this factor.
7) Code quality: Locating faults in an unstructured code or the code that does not
implement the guiding principles of its architecture, is very difficult. This
ultimately affects software maintenance effort. But as we are concern with
architecture based software maintenance, so we will ignore this factor as well.
8) Application Type: Application type represents different application areas. B. Clark
and D. Reifer [83] have categorized applications into four major types. These are:
Glob-1: Defense-like applications (real-time; complex)
Glob-2: Telecom-like applications (high reliability)
Glob-3: Scientific-like applications (compute-intensive)
Glob-4: Business-like applications (data-intensive)
48
Each application is characterized by special attributes as given in their work. They
have also given scaling factors for these types separately as shown below.
Table 3.9 scaling factors for application type [83]
Size Bucket Glob1 Glob2 Glob3 Glob4
2-25 KSLOC 0.87 0.75 0.92 1.07
25-100 KSLOC 0.69 0.76 0.72 0.98
100+ KSLOC 0.87 0.73 1.04 0.68
From their description, it is evident that applications belonging to different
categories have different scaling factors. We have concluded from the study of the
work presented in [26] that application type in combination with the size of the
application has an impact on the overall maintenance effort.
9) Hardware Characteristics: If the hardware components/ hardware dependent
components required for product are unreliable, then the maintenance effort shots
up. Similar behavior can be observed when the hardware vendor is unreliable.
Another factor that can affect software maintenance, defined by COCOMO II is
understandability. When programmers try to perform some maintenance of a system
developed by other programmers, the difficulty of understanding the system limits
maintenance. Therefore, it is essential that the maintainer gains in depth understanding of
the system being maintained with respect to certain factors such as structure, behavior
and functionality.
Understandability as a maintenance factor is described by COCOMO II. Hence we can
adopt the same COCOMO II defined understandability measures for our approach. The
COCOMO II defined understandability measures is given in table 3.10.
49
Table 3.10 COCOMO II Software Understanding [82]
As software understanding (SU) alone is less meaningful, hence it is multiplied by
programmer unfamiliarity or UNFM (0.0 – 1.00):
• 0.0 completely familiar will add no SU factor
• 0.4 Somewhat familiar will add 0.4 SU factor
• 1.0 Completely Unfamiliar will add SU factor
In light of the above mentioned facts and proposition, a new mathematical model for
maintenance efforts has been proposed as:
Maintenance Effort =
∑∑∑∑=
∆+
=
∆+
==
+
kf
n
n
kc
m
nncxn
kc
m
nncxn
ks
n
FactorWAVSVSWSPDHDAVSVSWSP11
.
11
)(.),()().(.),().().( (1)
Sn= Scenario n
P(Sn) = the probability weight of scenario n
Wcx = weightage assigned to scenario n based upon its complexity level
V(Sn,AV)= Volume of architecture affected (addition of new components/increase in
component size) in scenario n.
DHD= Degree of hardware dependability is calculated as
Type of application* (% of H/W dependent components)*system life span (2)
W(Factorn) = weightage of factor n affecting software maintenance.
50
Ks = number of scenario
Kc = number of components
Kc+ ∆ = affected volume architecture after addition of new components.
Kf = number of factors affecting software maintenance excluding system life span
( Maximum= 1 to 9)
3.5 Summary
Software architecture is an artifact which can be effectively used for maintenance
prediction as well as effort estimation of the software product based on quality attributes
associated with the system. In this chapter, an architecture based maintenance prediction
methodology has been formulated. A method for scenario classification based upon its
complexity with respect to quality attributes has been presented. Several factors that can
impact software maintenance have been identified and those factors affecting software
maintenance have been quantified using COCOMO II. A mathematical model has been
developed that can be used at an early stage (i.e. software architecture). This
mathematical model uses the concept of complexity based scenario classification with
respect to quality attribute and also incorporates factors that can affect software
maintenance. The method provides several benefits such as it can help an organization to
plane resources accordingly and it incorporates organization wide factors while
considering scenario complexity which ultimately provides more realistic maintenance
quantification.
51
Chapter 4: Architecture Based Ripple Effect Analysis
4.1 Introduction
The notion of software development has changed over the last decade and software
quality has emerged as an essential part of software development. On the other hand, in
the recent years, the success or failure of any software development effort is judged by the
degree of achievement of various software quality attributes associated with it. The quality
of software is critically dependent upon the maintenance effort that goes into it once the
software has been developed and is in use of the customer. In fact the customer satisfaction
actually depends as much on original software quality as on the maintenance that goes into
maintaining and upgrading the quality of the product. Due to this fact, software quality
maintenance is one of the key factors to be considered during software development.
Nowadays architecture based development has drawn considerable attention in software
engineering communities. Architecture based software development has ultimately
changed the traditional software quality evaluation methodology where software quality
was evaluated on the completed system. While following the traditional software quality
evaluation methodology, in case of failure, the software engineer has to rework the
system until it meets customer expectations at even more expenses. Also as a rule of
thumb, the cost to fix an error during the early phase of software project is orders of
magnitude less than to correct and fix it in later phases of project. As software
architecture is produced during the early phase of software development life cycle
(SDLC) and its sets the boundaries for system qualities, so these characteristics make
software architecture design a promising area to deal with quality maintenance.
Software quality maintenance is not without ripple effect. From the study of literature, it is
clear that ripple effect analysis phenomenon is not new. The term ripple effect analysis was
used for the first time by Haney in a technique known as “Module Connection Analysis”.
Structured Analysis and Design Technique (SADT) [84] and Methodology for Software
52
Maintenance [85] are such models that cater for ripple effect analysis. Software
maintenance is an essential part of modern day software development. According to L.
Erlike [92], the effort required for software maintenance had exceeded even 90% of the overall
effort required in any typical software project. So, any software maintenance technique that
explicitly caters for ripple effect analysis would ultimately help to ensure system consistency.
Further, the system is designed on the basis of a number of quality attributes i.e. high
reliability, security, low latency and high modifiability etc, which ultimately increases
system complexity. This ultimately leads to the fact that the software architecture of the
system evolves over time, which indicates that the corresponding qualities of the system also
evolve with the passage of time as well. This puts extra emphasis on software architecture as
a mirror to changes in software during its evolution. As software architecture consists of
components and relationship among them, any type of modification to components may have
side effects/ ripple effect on other components as well. Therefore, architecture should be
analyzed to identify the scope of the side effects that are caused by QA maintenance and
to make sure that the system preserve the overall function.
Software maintenance is inevitable for all software extensive systems and especially for
those software systems that need to be maintained for longer period of time. Software
maintenance activities reflect important changes that must be incorporated in the software
system as these changes have some serious implication in terms of customer satisfaction.
These obligatory changes must be interpreted and implemented carefully; otherwise it
will result in an architecture that ultimately compromises on customer satisfaction with
respect to functionality and quality. Therefore, software architecture should be considered
as an important artifact while dealing with changes [86].
As we know that system is actually a collection of different components integrated
together, therefore any change introduced will not only affect certain components directly
but will also affect certain components indirectly. As the system evolves with the passage
of time requires making changes, therefore ripple effect is inevitable. Ripple effect
analysis may be used to measure program stability. Poor program stability will ultimately
result in high ripple effect while low ripple effect otherwise.
53
Literature reveals different software maintenance models that either implicitly or
explicitly deals with ripple effect analysis. The IEEE Std. 1219-1998 [87] software
maintenance model implicitly deals with ripple effect analysis while Task oriented
software maintenance model [88], Yau et al. [89], and Pfleeger and Bohner Model for
Software Maintenance [84] explicitly deal with ripple effect analysis.
Figure 4.1 the IEEE maintenance process [87]
Figure 4.2 A task oriented software maintenance model [88]
54
Figure 4.3 A methodology for software maintenance [89]
Figure 4.4 SADT diagram of software maintenance activities [84]
From a study of the various approaches discussed above and various methods presented
in literature review, it was discovered that all of the approaches mentioned above make
use of the concept of ripple at later stages in SDLC. We believe that the impact of change
can be better measured and analyzed when we use ripple effect analysis at the level of
software architecture. One such approach which makes use of ripple effect analysis at
architecture al level is ATAM [5,60]. However, the major limitation of this model is that
it calculates ripple effect of quality attributes only. Our proposed model on the other hand
55
calculates ripple effect at directly and indirectly affected components apart from quality
attributes which helps in achieving multifaceted coverage using one technique only.
4.2 Proposed Architecture Based Ripple Effect Analysis
The visualization of the proposed ripple effect analysis process is given as below:
Figure 4.5 Architecture based software quality maintenance ripple effect analysis process
Once requirements are fully specified, the software architect will extract components
based upon the specified requirements on one hand while provide some specific
configuration of the extracted components based upon the desired quality attributes on
the other hand. The proposed ripple effect analysis methodology will start once a change
request for some modification in quality attribute is initiated by any customer. This
change request will be put forward to experts who will identify the affected quality
attribute and the corresponding affected quality property/properties. Another scenario that
Software Requirements
Requirements Mapping
QA interdependency matrix
Desired QA
QA Properties List
So
ftware A
rchitectu
re
Software Components Mapping
Change Request Identification of Affected QA
Affected QA
Identify Affected QA
Properties
Component Connectivity
Matrix
QA Property to Components Matrix
Directly
Affected Components
Indirectly Affected
Components
Total Ripple Effect
QA Interdependency
List of Affected QAs
56
will ultimately initiate the proposed ripple effect analysis methodology is when the
software architecture evaluation is performed using any architecture evaluation method
(i.e. SAAM, ATAM and ALAMA etc) and it is found that the architecture is not in
compliance with specified requirements.
Before calculating ripple effect analysis, the change request initiated by customer need to
be critically evaluated to identify specific QA and its related Properties. A QA Property
can be defined as
Definition 1: Each QA is a multi-faceted phenomenon which has several aspects associated with
it. These aspects of any QA are termed as QA Properties.
Detailed descriptions of various QA’s properties are given in table 4.1, table 4.2 and table
4.3. These Properties are related to any number of components within the software
architecture. These properties and the corresponding components will undergo
modification whenever there is a change request with respect to any QA modification.
More formally, ripple effect analysis is described as:
Let S be a software system. Let Cs= {C1, C2, …..Cn}. Let QAs = {QA1,QA2,……QAn}
be the set of QAs that can be satisfied by the composition of the components of the
software system. Let Ps= {P1,P2,…..Pn} be the set of properties of a specific QA and are
satisfied by the composition of the Cs. Let the system S needs to be tuned for some
specific quality attribute property i.e. {Pi, Ck}, then we can define
f ripple affect {Pi, Ck}→ {C1, C2,…….Cj,Cl,……….}
Where:
• f ripple affect is the ripple affect analysis function
• the components in Cs are integrated with each other through some
dependencies
• {C1, C2,…….Cj,Cl,……….} represents directly and indirectly affected
components.
In case the proposed ripple effect analysis methodology is initiated, the the next step is to
identify properties of the corresponding QA. Each and every QA can be described using
certain properties that describe key aspects of the corresponding QA. These quality
57
attributes are organized in the form of quality models, like McCall, Boehm,
FURPS/FURPS+ and ISO/IEC 9126. McCall’s et al [79] organized quality attributes into
a software quality model that describes the following three categorizes:
• Product operation describes operational characteristics i.e. correctness,
efficiency, usability, integrity etc.
• Product revision describes ability of a system to make changes i.e.
maintainability, testability, and flexibility.
• Product transition describes system adaptability to a new environment i.e.
portability, reusability, and interoperability.
B. Boehm et al [80] also developed a software quality model that is a sub set of McCall’s
quality model with two additional quality attributes i.e. understandability and
modifiability. Hence, this model consists of modifiability, portability, reliability,
efficiency, usability, testability, and understandability.
FURPS/FURPS+ [103] and ISO/IEC 9126 [104] quality models also describes different
quality attributes. The study of the above mentioned quality models and literature study
reveals the fact that we do not have complete list of QAs. So we took few QAs as a
sample list and used it for QA’s properties definition. The sample list includes reliability,
performance, and security. Properties for each and every QA are given as below. For
reliability, we have listed the following 9 attributes:
Table 4.1 Reliability Attributes
58
For performance the following 13 properties were identified by [22]
Table 4.2 Performance Attributes
For security we have listed the following 9 properties.
Table 4.3 Security Attributes
Once the description of each and every QA with respect to its associated properties is
completed, then it is possible to identify dependency of any QA’s property on certain
components of the system and property-to-component associativity matrix can be used
59
for this purpose. The association between QA properties and associated components has
been represented by using Adjacency Matrix (AMnxm ) . This matrix is named as
“Property to Component Associativity Matrix”. Suppose that the architecture needs to be
tuned for performance with associated properties P1, P2, and P3. Let the architecture
consists of components C1, C2 and C3. Then, the corresponding adjacency matrix may
be as follows:
Table 4.4 Property to Component Associativity Matrix
AMnxm =
If a property Pi is associated with component Cj then AM[i,j]= 1. Generally, the values of
all the elements in the matrix are defined as follows:
AM[i,j]= 1 if Pi→Cj 0 otherwise
The following equation will give the total no of directly affected components.
∑=
n
j
C1
ij Cij = 1
Software architecture is an artifact that reflects different components and the relationship
between them. To represent these relationships between different components in software
architecture, we can make use of component connectivity matrix. In other words, this
matrix will help to identify indirectly affected components. The rows and columns in
component connectivity matrix represent components. If a component Ci has a
relationship with component Cj then CM[i,j]=1. Suppose software architecture consists
of 3 components i.e. C1, C2, C3. Then
Table 4.5 Component to Component Connectivity Matrix
CMnxn=
Generally, the values of all the elements in the matrix are defined as follows:
C1 C2 C3
P1 1 0 0 P2 0 0 1
P3 1 1 0
C1 C2 C3
C1 0 0 1 C2 0 0 1
C3 1 1 0
60
CM[i,j]= 1 if Ci→Cj 0 otherwise
The total no of indirectly affected components by making modifications to component Cj
can be found as below:
∑=
n
i
C1
ij Cij = 1
Software architecture is designed based upon certain QAs. These QAs are derived from
the stakeholder’s requirements and software architecture is one such artifact that provides
a foundation for the analysis and realization of these quality QAs. Since quality attributes
have a strong interrelationship among them, it means that any decision taken regarding
any QA will have an impact on other QAs [90]. Therefore, when architecture tuning is
required for some quality maintenance, it means that the associated quality attributes will
also be affected.
We have used QA dependency matrix QADnxn to represent the QA inter-dependency. To
get a complete picture of ripple effect, it is not sufficient to just identify the components
being affected by a change in any specific QA Property; we also need to identify other
associated QA Properties with the affected QA Property and extract the components
associated with such Properties to determine if some possibilities exist for a change in
these as well. The QA interdependency matrix serves this purpose by establishing
mapping between connected attributes In the QAD matrix, QA are represented by rows
and columns. If a QAi directly affects another AQj then QAD[i,j]=1. If a QAi inversely
affects another AQj then QAD[i,j]= -1. If a QAi does not affect another AQj then
QAD[i,j]=0. Suppose QA1, QA2,QA3,QA4 and QA5 are quality attributes, then the
corresponding QAD matrix may be represented as follows:
Table 4.6 Quality Attributes Inter- dependency
QADnxn=
QA1 QA2 QA3 QA4 QA5
QA1 0 0 1 -1 1
QA2 0 0 1 0 0 QA3 1 1 0 -1 0
QA4 -1 0 -1 0 0 QA5 1 0 0 0 0
61
Summarizing this whole process, when the software architecture tuning is required with
respect to some QA, its corresponding property/properties and associated component/s
will undergo that change. Directly affected components would be identified using table
4.4. Indirectly affected components would be identified using table 4.5. Table 4.6 can be
used to explore whether the QA has direct or inverse or No affect on other QAs. This
whole process of ripple effect can be represented in the form of an algorithm described in
figure 4.6.
62
Start
Create list of QAs
Create list of properties of QA
Create list of components
Create properties-components associativity matrix
If component associated with given property
Assign 1 in associativity matrix
Else
Assign 0
Create component connectivity matrix
If component associated with another component
Assign 1 in connectivity matrix
Else
Assign 0
Identify ripple affect for change in any selected property
Identify property
Calculate direct ripple affect
Identify direct associativity of components with property
Exclude components having 0 associativity with given feature
Include components having 1 associativity with given feature
List all included components
Generate direct ripple affect list
Calculate indirect ripple affect
Identify connected components with “included components” in
components connectivity
Select one “included component”
List all components having 1 connectivity with it
Exclude other components
Repeat until all “included components” exhausted
Generate indirect ripple affect list
Identify QA impact using QA inter-dependency matrix
List together “direct” and “indirect” ripple effect for given property
Stop
Figure 4.6 Ripple effect analysis algorithms
63
4.3 Summary
Over the period of time, software systems have strongly influenced the overall working
of organizations. The complexity of these software systems are also increasing with the
passage of time due dynamic business environment, changing customer requirements,
and rapid change in technology etc. To keep the software updated enough to meet
organizational demand, software maintenance along with the associated phenomena of
ripple effect assumes critical role. On the other hand, different quality factors such as
maintainability, performance, and reliability are also significantly affected by software
architecture. Applying software quality maintenance ripple effect analysis methodology
at architecture level can help in determining the correct scope of ripple effect as a
consequence of any maintenance activity. A methodology for architecture base software
quality maintenance ripple effect analysis has been proposed. The proposed methodology
can be used to identify directly and indirectly affected components in an automatic
manner. The proposed methodology will provide valuable information to maintenance
programmers to visualize the ultimate side effects of any quality maintenance activity.
64
Chapter 5: Case Study This chapter presents an example application architecture that we have used to illustrate
the architecture based software maintenance prediction technique discussed in chapter 3
and the architecture based software maintenance ripple effect analysis discussed in
chapter 4.
5.1 Web Content Extraction Application
The system we used to illustrate the technique is Web Content Extraction System. The
Web is a huge growing repository of updated information available for public use. But
besides the actual content, a web page contains many other elements such as scripts,
styling information and navigation etc. The aim of Content Extraction (CE) is to extract
relevant content from the web. Due to rapid development in web technologies and
absence of dejure standards, the task of content extraction requires intricate delicacy.
Emergence of Web 2.0 technologies has complicated the task of content extraction a bit
more. Content Extraction application contains many components, and these components
frequently get changed or replaced with the passage of time. The frequency of change in
Content Extraction applications is usually greater than other applications due to the fact
that the web is undergoing frequent changes and new tools and technologies are emerging
from research to enhance the user experience. This makes the issue of maintenance even
more important in context of Content Extraction Applications. Figure 5.1 represents
architecture for a content extraction application.
65
Figure 5.1 Web content extraction application architecture
5.1.1 Description of the Architecture
The first layer is the Interface layer which is used to interact with the user and provides
web service interface to others applications. Web User Interface (UI) are commonly used
in modern applications due to their ease of use. However, this may not be the case for all
Contents Exaction Systems, some may use Windows based UI. In some cases, Contents
Exaction System may not have a UI, for example if used as part of crawler or another
automatic application. The controller module on this layer coordinates the
communication with the layers below and above.
The second layer of the web content extraction application is the most important layer of
application. It is used to extract relevant contents. It takes a request from UI and encodes
and passes it on to the Hyper Text Transfer Protocol (HTTP) Requester. The form request
emulator is used to get the content behind a form by emulating a form request.
HTTP Response gets the raw data and hands it over to the data Document Object Model
(DOM) Parser; the DOM parser uses the JavaScript Engine to execute any client side
66
code. This step insures the retrieval of Web 2.0 content. The resultant DOM is passed on
the Relevant Content Extractor which uses different algorithms to extract the relevant
content. The resultant relevant content is passed to UI for rendering on the screen.
The data extraction layer is used to handle HTTP related issues and errors. HTTP
requester is used for making an HTTP request for the resource, while the HTTP response
handler handles the HTTP Response. It waits for incoming HTTP response from a Web
Server and removes the HTTP header from the message and passes on HTML to the
DOM parser.
5.2 Prediction Example
In this section we will apply the step by step process of architecture based software
maintenance prediction process for the architecture presented in section 3.3.4.
5.2.1 Step 1: Growth Scenario Profile: The growth scenario profile for the
example architecture is given in table 5.1. This growth scenario profile has been
developed for an undergraduate final year project as a case study. The profile
presents various scenarios of potential maintenance in the web content extraction
application. There are two methods for generating a growth scenario profile. One
is individual based study and the second is group based study. We have adopted
the group based approach for developing a growth scenario profile.
67
Table 5.1 Growth scenario profile
Category Scenario Description
Replacement of Web UI with standard Windows UI.
Web is replaced with a standard Window UI. Web UI responds relatively slowly to user requests.
Content Decorator Applies predefined Content Styles to the retrieved content. It will require changes to Web UI component.
Addition of API (COM) COM Application programming interface is added for the fast access to the application functionality by other application.
Addition of Text-to-Tag Ratio algorithm
Text-o-Tag ratio algorithm is used to extract content text from diverse Web pages by using the HTML document's Text-To-Tag Ratio rather than specific HTML cues that may not be constant across various web pages.
Addition of Content Code Blurring Technique
Content Extraction technique is used to identify the main content and/or remove the additional contents. As the main text content is typically a long, homogeneously formatted region in a web document, the aim is to identify exactly these regions in an iterative process.
Application is enhanced to act as ETL tool
The application is enhanced to extract, transform and load information from web to the data warehouse.
Support for new MIME types (e.g. DOC)
Support of new MIME type i.e pdf,doc,rtf etc
Communication over SSL The application is enhanced to communicate over SSL.
Web History Cache Web History Cache will hold the pages already accessed.
Enhancement in HTTP requester HTTP requester is enhanced to get the content from Deep Web and extraction of content that is behind a Flash, ActiveX, or Applet form.
5.2.2 Step 2: Complexity Based Scenario Classification: Once we have a growth
scenario profile, the next step is to classify these scenarios based upon their complexity
level as per guidelines given in table 3.1 (section 3.2). Table 5.2 describes scenario
complexity:
5.2.3 Step 3: Probability of each Scenario Occurrence: Each scenario will have
certain likelihood of occurrence during the lifetime of the system,. Therefore, each
scenario is assigned a probabilistic weight. These probabilistic weights can be assigned
either by domain experts who can make qualified guesses about scenario occurrence or
historical data can be used, if available. In order to calculate probability of various
scenarios; component size, impact of growth scenario on individual component and
weightages of factors having impact on software maintenance; an expert group of various
industry professionals were convened. After going through various project documents
such SRS and domain models on one hand and a growth scenario profile such as the one
68
shown in table 5.2 on the other hand, the professionals after majority voting scheme,
derived results which are shown in table 5.3, 5.4, 5.5 and 5.6.
Table 5.2 Complexity based scenario classification
Scenario Complexity level
Replacement of Web UI with standard Windows UI.
Simple
Content Decorator Simple
Addition of API (COM) Average
Addition of Text-to-Tag Ratio Algorithm Simple
Addition of Content Code Blurring Technique Simple
Application is enhanced to act as ETL tool Complex
Support for new MIME types (e.g. DOC) Simple
Communication over SSL Simple
Web History Cache Simple
Enhancement in HTTP requester Simple
Table 5.3 Probability of each scenario occurrence
Scenario Occurrence probability
Replacement of Web UI with standard Windows UI. 0.1
Content Decorator 0.05
Addition of API (COM) 0.09
Addition of Text-to-Tag Ratio algorithm 0.15
Addition of Content Code Blurring Technique 0.1
Application is enhanced to act as ETL tool 0.07
Support for new MIME types (e.g. DOC) 0.1
Communication over SSL 0.09
Web History Cache 0.1
Enhancement in HTTP requester 0.15
5.2.4 Step 4: Change Impact Analysis: Once the growth scenario profile is defined,
we can investigate the consequences of each change scenario occurrence. The possible
consequence of a change scenario is, either it will add a new component to the existing
architecture or it will modify the existing component/components to accommodate that
change scenario. In case the change scenario increases the component/ components size,
69
then we must know the component size before accommodating that change scenario.
Prototype implementation or a similar application can be used to estimate component
size. As LOC is highly correlated with effort, therefore LOC has been used a sizing
metric instead of function points [106]. The following table describes component size
based upon similar applications:
Table 5.4 Approximate component size
Component LOC
Web UI 100
Web Service 100
Controller 200
Relevant Content Extractor 1300
SST 200
DOM parser 1000
JavaScript Engine 3000
HTTP Requester 50
Form Request Emulator 50
HTTP response Handler 150
Once the component size is known, we can synthesize change impact analysis. The
following table describes change impact analysis per change scenario.
Table 5.5 Change impact analysis for each scenario
Category Scenario Description LOC
Replacement of Web UI with standard Windows UI.
New windows UI. 100
Content Decorator Web UI (50% changes) component. 100*0.5=50
Addition of API (COM) New COM application 400
Addition of Text-to-Tag Ratio algorithm
New Text-o-Tag ratio algorithm 100
Addition of Content Code Blurring Technique
New Content Code Blurring Algorithm 200
Application is enhanced to act as ETL tool
New ETL component 600
Support for new MIME types (e.g. DOC)
Http Reponse Handler (33% change) 150*0.33= 50 (aprox)
Communication over SSL Http Requester (100 % change) and Http Response (33% change)
50*1+150*0.33= 100 (aprox)
Web History Cache HTTP Requester (20% change) , HTTP Response Handler (7% change) and new component i.e Web history Cache
50*0.2+150*.07+80= 101 (aprox)
Content extraction from private web
HTTP requester ( 40% change) + new component to maintain session related data
50*0.4+30= 50
70
5.2.5 Step 5: Factors Affecting Software Maintenance: various factors
considered for our application with corresponding weights are given below.
Table 5.6 Factors affecting software maintenance and their corresponding weightage
Factor Rationale weightage
System Novelty. There are many precedents where the developers have developed such systems in the past.
0
Turnover Turnover in the organization is low. 0.81
Maintenance staff ability All the developers have minimum 3 years experience 0.88
Documentation Many life cycle needs uncovered 0.81
Testing quality Very high (because very few errors of low severity) 1.41
System life span 1 year
Dependence on changing environment
Irrelevant factor as this factor is related to development effort
Application type Glob-4, 2-25 kloc 1.07
Hardware characteristics No hardware dependent components 0
Understandability Completely familiar 0
Total (excluding system life span, Hardware characteristics)
4.98
5.2.6 Step 6: Predicted Maintenance Effort: the predicted maintenance effort is
calculated in two steps. In first step LOC/change will be calculated and in the
second step predicted maintenance effort will be calculated. LOC will be
calculated using mathematical model described at the end of section 3.4. The
mathematical model is
Maintenance Effort =
∑∑∑∑=
∆+
=
∆+
==
+
kf
n
n
kc
m
nncxn
kc
m
nncxn
ks
n
FactorWAVSVSWSPDHDAVSVSWSP11
.
11
)(.),()().(.),().().(
Step 1: LOC/ Change: 0+0.1*0.2*100 + 0.05*0.2*50 + 0.09*0.25*400 + 0.15*0.2*100
+ 0.1*0.2*200 + 0.07*0.5*600 + 0.1*0.2*50 + 0.09*0.2*100 + 0.1*0.2*101 +
0.15*0.2*50= 45.82 * 4.98= 228.1836 LOC/Change
Step 2: Predicted maintenance effort: To predict maintenance effort, we assume that
the above 10 maintenance tasks are given for a period of one year. Given that 0.2
LOC/hour [1], the maintenance effort can be calculated as follows:
Per change = 228.1836 LOC
10 changes = 2281.836 LOC
2281.836 / 0.2 = 11409.18 hours effort
71
5.3 Architecture Based Software Quality Maintenance Ripple Effect Analysis
We have used the same web content extraction application system to illustrate the
architecture based software quality maintenance ripple effect analysis technique. The
description of the web content extraction application system is already discussed in
section 5.1.
5.3.1 Required Change
One of the observed problems with the above mentioned system is that it involves an
overhead incurring reference/page faults that ultimately leads to poor performance. On
further analysis it was found that this specific issue related to the performance quality
attribute. More specifically, it is related to the performance’s property “For each dependent
iterative structure in the module containing overhead incurring references, the number of
iteration” as listed in table 4.2.
5.3.2 Ripple Effect Analysis
In order to minimize the incurring references, it was decided to tune the architecture. But
tuning the architecture with respect to incurring references will not be without ripple
effect. In order to analyze the ripple effect, we have shown property to component
associativity matrix for the given application in table 5.7. From this table, we were able to
extract those components which were directly associated with the specific property given
above. As can been seen in the table, the mapping of given property was “1” for only two
components. This meant that if the given property needed maintenance as our situation
demanded, only these two components will be affected. As a result, the extracted
components included “HTTP request handler” and “HTTP response handler”.
In the next phase, we were able to get further details of ripple effect that may be resulted
by tuning of this property. Component connectivity matrix is given in table 5.8. Using
72
this table, we successfully identified all the components associated with directly affected
components. These are indirectly affected components identified with the help of this
ripple affect analysis. The application of our technique shows that DOM parser, Form
Query Emulator and Controller are the indirectly affected components. Out of these,
indirectly associated components with HTTP Requestor are Controller and Form Query
Emulator whereas the component/s associated with HTTP Response Handler is Dom
parser. These components are visualized as indirectly associated components.
To complete the ripple effect analysis, we have introduced “QA inter-dependency
matrix” in our approach derived from [24]. We have arranged these interdependencies in
the form of matrix in table 5.9. This matrix enables us to identify at abstract level, all
QAs which may be affected by any change introduced in any QA. This matrix also tells
us about the nature of impact of proposed change in specific QA. For example, in our
case study, the changed property relates to performance QA. Using QA interdependency
matrix as presented in table 5.9, we are able to identify that any change in performance
QA will have serious and possibly negative impact on several other QA including
flexibility, portability reusability etc. This matrix clearly shows us that any change
introduced in performance will need to be taken very carefully since it will have only
possibly negative impact (which needs to be avoided) or neutral impact on other
components. Summarizing all this analysis, we can state that:
• The case study statement has a problem involving overhead incurring reference/page
faults which results in low productivity. This problem is related to performance QA.
This problem can be resolved if the specific property of performance QA is tuned for
optimization. This specific property is “For each dependent iterative structure in the
module containing overhead incurring references, the number of iteration”.
• Using property to component associativity matrix, we have found that directly
affected components are “HTTP request handler” and “HTTP response handler”
• Using component connectivity matrix, we have found that indirectly affected
components include “DOM parser”, “Form Query Emulator” and “Controller”.
73
• Using QA interdependency matrix, we were able to find that in order to optimize this
specific property of performance QA, we shall have to be mindful of the fact that
optimizing this can possibly undermine other QAs (i.e. flexibility, portability,
reusability, productivity etc ) as there are several negative impacts which can occur.
So, this change needs to be introduced after careful consideration.
This summary gives the complete ripple effect analysis for the case study using our
proposed approach. It is suffice to say that using this relatively easier to apply technique;
we were able to determine the complete ripple effect of any proposed change.
74
Table 5.7 properties to components associativity matrix for performance
* Red-highlighted text shows performance attribute for which architecture need to be tuned Red-highlighted cells shows directly affected components
Components Performance Features
Web UI
Web Service
Controller HTTP Requestor
Form Query Emulator
HTTP Response Handler
DOM Parser
Java Script Engine
Relevant Content Extractor
SST
Parallel Execution 0 0 0 0 0 0 0 0 0 0 The relative time that the module releases the resource
0 0 0 1 0 1 0 0 0 0
The relative time that the module seizes the resource
0 0 0 1 0 1 0 0 0 0
The relative time that the module begins execution
1 1 1 1 1 1 1 1 1 1
The relative time that the module transmit message to another module
1 1 1 1 0 1 1 0 1 0
The execution time of the module 1 1 1 1 1 1 1 1 1 1 The resource utilization by the module 0 0 0 1 0 1 0 0 0 0
For each dependent iterative structure in the module, the number of iterations
0 0 0 0 0 0 1 1 0 1
The storage and retrieval times for entries in the data structure
0 0 0 1 0 1 1 1 0 0
The rate of input to the module 1 1 1 0 0 1 1 1 1 1
The number of entries in the data structure
0 0 0 1 0 1 1 1 0 0
The service time of an entry in the data structure
0 0 0 1 0 1 1 1 0 0
*For each dependent iterative structure in
the module containing overhead incurring references, the number of iteration
0 0 0 1 0 1 0 0 0 0
Response time 1 1 1 1 1 1 1 1 1 1
Throughput 1 1 1 1 1 1 1 1 1 1
75
Table 5.8 Component Connectivity Matrix
Components
Web UI
Web Service
Controller HTTP Requester
Form Query Emulator
HTTP Response Handler
DOM Parser
Java Script Engine
Relevant Content Extractor
SST
Web UI 0 1 0 0 0 0 0 0 0
Web Service 0 1 0 0 0 0 0 0 0 †Controller 1 1 1 0 0 0 0 1 0
HTTP Requester 0 0 0 1 0 0 0 0 0 Form Query Emulator
0 0 1 1 0 0 0 0 0
HTTP Response Handler
0 0 0 0 0 1 0 0 0
DOM Parser 0 0 0 0 0 1 1 1 0
Java Script Engine 0 0 0 0 0 0 1 0 0
Relevant Content Extractor
0 0 1 0 0 0 1 0 1
SST 0 0 0 0 0 0 0 0 1
† Red-highlighted components are indirectly affected components
76
Table 5.9 QA Inter-dependency Matrix [24]
C A Ch S Ts F Pt R I T E Ct Pd Rl Tl Ip
Analyzability 0 Changeability 0 1
Stability 0 1 1
Testability 0 0 0 0
Flexibility 0 1 1 1 0
Portability 0 1 1 1 0 1 Reusability 0 0 0 0 0 0 1
Interoperability 0 0 0 0 0 1 1 1
Time (Lead Time) -1 -1 -1 -1 -1 -1 -1 -1 -1
Effort (Cost) -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
Content -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Productivity -1 -1 -1 -1 -1 -1 -1 -1 -1 0 0 0
Reliability 1 0 0 0 0 0 -1 0 0 -1 -1 -1 -1
Tailor ability 0 -1 -1 -1 -1 1 -1 0 1 -1 -1 -1 -1 -1
Interactive Performance 0 0 0 0 0 -1 -1 -1 0 -1 -1 -1 -1 0 -1 Usability 0 0 0 0 0 0 0 0 0 -1 -1 -1 -1 0 0 0
C= Correctness, A=Analyzability, Ch= Changeability, S= Stability, Ts= Testability, F= Flexibility, Pt= Portability, R=Reusability, I= Interoperability, T= Time (Lead Time), E= Effort (Cost), Ct=Content, Pd= Productivity, Rl= Reliability, Tl= Tailor ability, Ip= Interactive Performance
77
Chapter 6: Conclusion
6.1 Introduction
Software maintenance is assuming more and more significance in the context of
continuously evolving software. The aim of this research is to investigate the potential
use of software architecture for software maintenance prediction and ripple effect
analysis. This is an often ignored area of research and innovation at both academic and
industrial level. In order to overcome this shortcoming, a novel architecture based
maintenance prediction and ripple effect analysis methodology has been proposed.
6.2 Summary of Findings Regarding Software Maintenance
Prediction
Given below are major findings and contributions that came out after this research work.
The thesis revolves around these contributions.
1. Software Architecture Evaluation and Weighted Scenarios: Software
architecture is an important activity which yields artifacts that reflect certain
design decisions having a significant impact on the later phases of software
development. These early decisions may reduce the risk and guide the software
development process. The importance of software architecture design emanates
the need for ways to predict the quality of design at an early stage (i.e, software
architecture). These types of evaluations can be performed using a method of
evaluating the software architecture.
These assessments are important in the design process to improve the overall
system architecture. Literature reveals different approaches for software
architecture evaluation. One of these approaches is the usage of scenarios for
software architecture evaluation. SAAM [4], ATAM [5], and ALMA [67] are
such software architecture evaluation methods that use scenarios as the basis for
78 architecture evaluation but none of these methods differentiate/classify scenarios
regarding their complexity. So we decide to target this area and we have
developed an approach that can provide complexity based scenario classification
with respect to quality attributes (table 1). Such scenario classification will also
help the software architect to evaluate the architecture for complex scenarios
support. On the other hand, it will help the organization to plan resources
accordingly.
Using the concept of simple, average and complex use case, a methodology was
designed to assign weights to scenario with respect to quality attributes, based
upon its complexity. This approach will help evaluator to gain more realistic
evaluation as it assigns weights to scenarios depending on complexity level. For
example, in an approach that estimates maintenance effort; simple scenarios will
require less maintenance effort as compared to average and complex scenarios. It
is not claimed that this classification is complete in all respects; rather, it is
expected to be analyzed in future research and would be improved accordingly.
2. Change Scenario Elicitation: Change scenario elicitation is an important step in
architecture based software maintenance prediction. Change scenario profile has
been used as a tool that can affect the accuracy of predicted maintenance effort.
Therefore it is important to involve different people from customer side as well as
from development side during the development of change scenario profile. The
proposed growth scenarios in our technique are to be developed by a group of
individuals having affective domain knowledge and their consultations should
yield not only growth profile but other artifacts as described in chapter 5.
Furthermore, a change scenario profile should be a realistic representation of the
scenario population. Therefore it is important to spend significant effort on
making sure that the scenario profile is as representative as possible.
3. Change Scenario Probabilities: The architecture based software maintenance
prediction methodology requires that each change scenario must be assign a
probabilistic weight based upon the likelihood of this change scenario occurrence.
These weights can be assigned by either domain expert, who can make qualified
79 guess about scenario occurrence, or historical data can be used or different
stakeholders may be involved to assign the probabilistic weight. As mentioned in
the previous point, we have convened domain experts for calculating these
probabilities. The problem arises when stakeholders assign probabilistic weights
to a change scenario and intuitively feel that the weight for change scenario
should be one, but another change scenario also occurs. In such a situation, the
concept of normalization has been proposed (i.e. calculate the weight for each
scenario by dividing the number changes estimated for that scenario by the sum of
the estimates of the complete set of scenarios).
4. Component Size (LOC) Estimation: For maintenance prediction, we need
certain information that is normally not available at software architecture design
time. For instance, once growth scenario profile is compiled, then the next step is
to identify the consequence of each change scenario. Each change scenario will
either add a new component to existing architecture or it will modify the existing
component/components to accommodate that change. In both cases, wee need
certain additional information (i.e. component size) that is normally not available
at the software architecture level. This information can be estimated by using
either:
•••• Prototype Implementation
•••• Similar Application/ Historic Data
•••• Domain Expert
In our technique, a domain expert based component size estimation approach has
been used. Using this approach, a more realistic assessment of required
maintenance for individual component has been made possible.
5. Ripple Effect Analysis: the phenomena of ripple effect must be considered when
dealing with change scenario for maintenance prediction. Simply put, a ripple
effect is when a component directly affected by a change scenario needs to be
changed, and those changes require other components to change as well. This
ripple effect is useful to conclude certain information regarding the architecture in
hand. For instance, if the ripple effect is constrained to a single component, one
80 may conclude that the corresponding architecture is modifiable for the said
scenario. Alternatively, if the ripple effect spans a number of components, it
indicates that the architecture poorly supports this scenario.
The main problem with ripple effect is that it is very difficult to forecast. Often,
the identification of directly affected components phenomenon is relatively easy
but it very difficult to identify ripple effect in a situation where some components
are also indirectly affected. The main factor contributing towards this problem is
the required amount of detail available in the description of software architecture.
According to M. Lindavall and M. Runesson [91], even the detail design
description lack information necessary for identifying ripple effect analysis. Since
no significant amount of detail is available at the software architecture level, this
is an even more significant problem. A complete ripple effect analysis
methodology at architecture level has been given in the thesis which helps us in
identifying and extracting those components which are directly or indirectly
affected by any proposed change. Using this information as well as the
information extracted from above contributions, we come up with a mathematical
model which can predict maintenance effort in a more realistic manner.
6. Factors Affecting Software Maintenance Prediction: Architecture based
software maintenance prediction also requires some additional information that is
not available at software architecture design time. For instance, for maintenance
prediction, the factors identified by S.L. Pfleeger and J.M. Atlee [81] must be
considered to get more realistic results. As we are predicting software
maintenance at architecture level, so certain factors (i.e. code quality and
dependence on changing environment) are not applicable for our techniques but
the rest of the factors have significant affect on the final results. COCOMO II
scaling factors have been used for the quantification of these factors. The problem
faced by us is when certain factor goes beyond the COCOMO II mentioned
weightage. For example, for the maintenance staff ability, we have used the
programmer application experience scaling factor by analogy but the problem
arises in a situation where we want to quantify the maintenance staff ability with
81 more than 6 years. Similarly the factors provided by COCOMO II for
documentation quality are also very subjective and can lead towards biased
results.
A complete new scaling paradigm has been proposed for complexity based
scenario classification with respect to QA. These scaling have been influenced
by COCOMO II scale for complexity but are determined after experimental
validity and expert judgment. The weightage for any particular scenario is
dependent upon its associated complexity.
7. Result Validation: Once the architecture based software maintenance prediction
process is completed and we have certain results in hand, we have to make some
conclusion regarding these results. These results can only be validated if we have
some historical data but the general experience is that we lack a frame of
reference for validating the results.
For instance, the case study (i.e. Web Content Extraction Application) that we
have consider to illustrate the technique, represents 711 lines of code to be
affected per change on average. Based on this information available, we can not
decide that whether the architecture is good or bad in terms of modifiability. For
such type of decision, we need historical data as a frame of reference. In this
thesis, we have suggested that some historic data / expert judgment based result
validation mechanism is a need of the hour which can affectively calculate the
accuracy of predicted maintenance at early stages of software development.
6.3 Summary of Findings Regarding Ripple Effect Analysis
1. QA Properties: For architecture based software quality maintenance ripple effect
analysis, we need certain information that is normally not available at software
architecture design time. For instance, once software architecture evaluation is
performed with respect to certain quality attribute and after the architecture
82 evaluation, it is required that architecture should be transformed so as to satisfy
the quality requirement; the next step is to study the proposed change carefully.
This change statement points towards the specific QA and its related Property/s
which needs to be optimized in order to make this change happen. In such a case,
we need certain additional information (i.e. QA’s Properties) that is normally not
available at the software architecture level. This information can be compiled by
software architect or software designer. Therefore it is important to spend explicit
effort on making sure that the QA’s properties are as representative as possible.
Keeping this finding in mind, we have proposed a methodology that describes QA
properties and their mappings which help in effective maintenance prediction and
ripple effect analysis at architectural level.
2. Mapping QA’s Properties to Components: Once it is decided that the
architecture should be tuned for a specific QA, the next step is to identify
Property of the corresponding QA. After describing each and every QA by its
corresponding Properties, the next step is to identify dependency of any Property
on various components of the system. In such a case, wee need certain additional
information (i.e. QA’s Properties to component mapping) that is normally not
available at the software architecture level. Such mapping is not straightforward
and requires critical analysis as on software designer/ software architect behalf.
Therefore it is important to spend explicit effort on making sure that the QA’s
properties are properly mapped to corresponding components.
6.4 Future Work
Up till now we have presented method for 1) prediction of maintainability, and 2)
software quality maintenance ripple effect analysis at architecture level. As far as
architecture based maintenance prediction methodology is concerned, it is practical and
can be easily used during architecture design. It provides improved requirements
understanding. It can help the organization to plane resources accordingly. It incorporates
83 organization wide factors and considers scenario complexity which ultimately provides
more realistic maintenance quantification. But following this methodology, we does not
know exactly whether” the maintainability of the architecture is good, reasonable or
bad?” Therefore it is important to develop such a technique that can provide us optimal
maintainability information. This is one of the possible future extensions of our work.
One of the weaknesses of the architecture based maintenance prediction method is its
dependency on representative maintenance profile. So investigating how individual
expertise, knowledge and exposure affect the actual representativeness of a software
maintenance profile is another possible future extension of this work.
We are in the process of automating this whole technique which will further reduce its
complexity and will make it more beneficial by reducing time and efforts of the design
and development teams to determine and analyze ripple effect due to any new change.
84
References
85
86
87
88
89
90
91
92
93
94
95