Proceeding of the 3rd International Conference on Informatics and Technology, 2009

IMPROVING SOFTWARE MAINTENANCE PROCESS

USING INTERRELATED SET FROM FOSS
1
M. Norazizi
1
Islamic Science University of Malaysia,
71800 Nilai, Negeri Sembilan, Malaysia.
Email: azizi@usim.edu.my

ABSTRACT

The main objective of this paper is to explain how the concept of managing SCM (Software Configuration
Management) context of software maintenance as mentioned in SWEEBOK [16] can be realized by using interrelated
Software Engineering Tool (SET) from FOSS (Free Open Source Software). Four tools are selected and integrated
including Bugzilla, Subversion, Codestriker and Scmbug to create a collaborative software maintenance environment.
Cross-referencing links between these tools enable quick access to information and thus enhance the understanding
of software artifacts. To ensure reliable software information, policy is set up using Scmbug. We demonstrate how
these tools can be fully utilized to improve software maintenance tasks in a very cost effective way and thus bring
benefit to software maintenance team. The rest of the paper is divided into four sections. Firstly, the author explains
the general overview of software maintenance followed by the explanation on software maintenance environment,
how the tools work in a process workflow and lastly conclusions.

Keywords: Software Maintenance, Open Source, Collaborative Environment.

1.0 OVERVIEW

It is well known that software maintenance consumes most of the software project resources. According to earlier
studies [2], [3], it is between 40%-70% of total software life cycle resources. This is not unusual because of the vast
number of processes and software artifacts involved. Software according to McDermid’s definition [1] does not limit to
programs (code & objects) but also includes documentation and procedures to operate the software system. In order
to maintain the usefulness of the operational system, changes usually are required [9] on software artifacts.

Changes can be classified into corrective, adaptive, perfective and preventive [4], [5], [6]. Corrective change is
defined as initiated modification that cause by defects in software. Adaptive change happens when there is need to
handle modification caused by external factor from outside the software system environment. Perfective change is
initiated when there is expansion in the requirement requested by the users. Preventive change is undertaken to
prevent malfunctions or to improve maintainability of the software [7]. Among of these changes, perfective
maintenance was accounted consumed the largest effort [5].

The high cost of maintaining operational software is partly due to the problem of retaining and attracting talented
software maintenance personnel [11]. When highly-skilled and experienced personnel leave or move to other
department, all valuable experiences and knowledge related to the software being maintained will be taken away too.
Sharing of software information is necessary for new software maintainer to continue on software maintenance tasks.
Lack of this which caused by improper preservation of software history reduces program comprehension and thus
amplifies the complexity of software maintenance tasks.

When projects become expanded after series of modification on software artifacts, increased complexity is not
avoidable thus dependence on specific tools is crucial to the successful of the operational software. Without the aid of
automated support tools, effective configuration management is impossible in most software maintenance
environments [7]. There are enormous amount of artifacts changed during maintenance tasks and keeping track each
of these is vital. One of the greatest challenges faced by software maintainer is the management and control of these
changes [8]. Some of the tasks required in SCM context of software maintenance including version control, bug
tracking and peer review. Deployment of SET to support these tasks, combined with good understanding in concept
and practices is crucial to maintain reusable and maintainable operational software.

However, the potential of these tools cannot be fully utilized if each of them is treated as separate entity. The retrieval
effectiveness of software information in a collaborative environment could at least be improved if tools are reciprocally
connected. Cross-reference information can be reliably generated by enforcing policy and preserved for later retrieval
during the process of understanding the software artifacts. For example, a single link in bug tracker can refer to code
changes extracted from the software repository to determine what fix has been implemented for a bug. This
mechanism is very useful in understanding the software quickly, helps in impact analysis and gives software
maintainer more time to focus on other maintenance tasks such as modifying the code.

©Informatics '09, UM 2009 RDT4 - 94

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

Lethbridge & Singer [12] define tools can be everything from large scale integrated CASE products to simple one-
function command or features. Although the definition is broad, several studies conducted at HLI (Higher Learning
Institution) in Klang Valley shows that in spite of more than half of the participants have experience using certain
software maintenance tools, they are not interrelated with each other [13]. Some of the problems including difficulty in
tracking bugs due to the nature of helpdesk solution [14]. Even though most HLI use helpdesk application, complaint
still comes from conventional methods such as telephone and forms. Furthermore, reported issues are not saved in
electronic manner thus causing difficulty in tracking bugs history.

In this paper, the author demonstrates how SET adopted from FOSS can be deployed and reciprocally connected to
create a collaborative software maintenance environment. This demonstrates the full potential of FOSS as low-cost
alternative for software maintainer to conduct software maintenance tasks. The tools and how integration was done
are explained in the following section.

2.0 SOFTWARE MAINTENANCE ENVIRONMENT

2.1 Tools

SET used for this case study and their pre-requisite packages run on hardware equipped with a 2 GB SDRAM
memory, 80 GB IDE hard disk, and 2.6 GHz AMD Processor. Software packages as displayed in Table 1 must be
installed and configured correctly prior to the installation of Bugzilla, Subversion, Scmbug and Codestriker. Table 2
displays their version and functions.

Table 1: Pre-requisite packages

Package Version

Linux Ubuntu LTS 8.10 (Hardy)

Apache2 2.2.8

Perl 5.8.8

MySQL 5.0.51a-3

Table 2: Software Engineering Tools

Tool Version Functions

Bugzilla 2.22.1 Bug tracker

Subversion 1.4.6 Software configuration Management

Scmbug 0.26.13 Integration system for SCM and bug tracker

Codestriker 1.9.8 Source code review

2.2 Integration

The interaction between tools is shown in communication diagram as depicted in Fig 1. Bugzilla and Subversion are
connected through Scmbug. Scmbug act as glue to allow communication between them and enable policy to be set
up in order to avoid improper events such as unintended commits. When Subversion triggered SCM events, they are
captured by hooks and various verification checks are performed before the event’s activity is allowed to proceed.
These checks are designed to behave synchronously such as if error is detected, the event’s activity is dropped.

Scmbug profile can be customized to suit software maintenance environment. For example, rules can be altered to
follow strict adherence to software maintenance guidelines in the organization and Default comment template if
customized can add additional software information. All of these could help preserving reliable software information.

Codestriker has interfaces that allow integration to Bugzilla and Subversion. From bug ID, Codestriker can identify
bug topic in Bugzilla and insert code review link into it. When this link is clicked in Bugzilla, Codestriker presents the
reviewer with a parallel view in which contains the whole content of the file before and after changes. This explains
why there are two way communications between Bugzilla and Codestriker.

©Informatics '09, UM 2009 RDT4 - 95

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

Subversion

Bugzilla Scmbug

Codestriker

Fig 1 : Communication between tools

3.0 PROCESS & EXECUTION

3.1 Case Study

After successful integration of the tools, a sample program is taken as a case study. This program contains complete
source code and few errors. The program cannot run correctly unless the errors, including logic error and compilation
error, are fixed. These errors are intentionally created to demonstrate the functions and interaction of the tools using
a process workflow as depicted in Fig 2. Before the process begun, the source code is checked in into the software
repository using Subversion.

3.2 Process Workflow

This section explains the process workflow used for this case study. Management of software artifacts requires
special skills as the number of them can be overwhelming and thus difficult to control. Therefore, we created a
simplified workflow as shown in Fig 2 to describe the software maintenance tasks. The workflow starts from creating
bug topic and advance to source code changes review. Detail execution is explained in the following section.

Create bug topic Assignee accepts bug Implement changes

Conduct review Create review topic Commit changes

Fig 2 : Process workflow

3.3 Execution

When a bug is found, a new bug topic is created in Bugzilla. In its interface, user can specify information related to
bug description, component affected, bug status, resolution and assignee. After submission, a notification email is
transmitted to assignee. This email contains information such as link to the bug topic. By clicking this link, the bug
topic is displayed and the assignee can confirm acceptance by choosing “Accept bug” resolution option as shown in
Fig 3.

Fig 3 : Bug topic resolution option

©Informatics '09, UM 2009 RDT4 - 96

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

After confirmation, assignee checks-out source code from software repository using Subversion and start
implementing bug fix. Creating a branch by copying from trunk is a good practice before check-out. Branch and trunk
are referring to folders in software repository. We are not discussing them in detail as it is beyond the scope of this
paper. But, the main purpose is to allow other developers continue working with major enhancement in trunk without
interference from bug fixing activity. When it is appropriate, changes in branch can be merged again with trunk by
using specific SVN command line option. However, to make it simple for this case study, fix is implemented directly
on trunk.

After finishing a fix, the developer commits it and gives comment on what has been implemented. According to the
rule set in Scmbug profile, every comment must include bug ID before it is allowed to enter software repository. Fig 4
shows an example of an accepted comment. Scmbug responds to subversion commit event and various checks
including bug ID verification are executed. If passed, appropriate event’s activity such as comment insertion into bug
topic is performed. In Fig 5, the comment is successfully inserted into bug topic. It clearly shows what component was
affected, revision number in which contains the fix and commit comment.

Fig 4 : Example of a good comment in a commit

Fig 5 : Inserted comment in bug topic after commit

After committing the changes, a review is conducted by using Codestriker. To start review process, a new topic is
created from its interface. Some information are mandatory such as title, description, start tag, end tag, module,
project, top directory of SCM repository, bug ID that initiate the changes, as well as email address of the author and
reviewer. One or many reviewers can be nominated and once a topic is created a notification email is sent by
Codestriker to each of them.

Codestriker can be configured to automatically insert a comment into bug topic after successful creation of a review
by specifying the bug ID. Fig 6 shows an example of inserted comment written in Codestriker in a bug topic. The
inserted comment contains a link to the code review topic in Codestriker as well as other information such as title,
description, author and reviewer.

Fig 6 : Inserted comment in bug topic after a new review is created

When the code review link is clicked, a parallel view as depicted in Fig 7 is displayed by Codestriker which allows the
reviewer to see complete contents of the file side by side with its corresponding changes. During review process
comment can be inserted into each line of code as well as comment submitted by other reviewers. When review

©Informatics '09, UM 2009 RDT4 - 97

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

process ended, the reviewer closes it by changing its status. This resulted to an insertion of a new comment into bug
topic as shown in Fig 8.

Fig 7 : Inserted comment at a line of code in Codestriker

Fig 8 : Inserted comment in bug topic when the review is closed

4.0 CONCLUSIONS

Interrelated SET such as Bugzilla, Subversion, Scmbug and Codestriker demonstrates how software maintenance
tasks particularly in SCM context can be conducted in a collaborative environment. Cross-referencing between tools
enable quick access to information and thus improve the understanding of software artifacts. Set of rules can be set
up to enforce policy which is important to produce reliable software information that can be easily tracked. These are
some of the advantages of interrelated tools over segregated tools.

Reduction in licensing fee by selecting FOSS could help save budget for software maintenance compared when
proprietary software is used. Some of proprietary software offer restricted license where only 1 or 2 individual is
allowed to operate at same time. Open source unrestricted licenses allow various tools with different purpose and
functionality to be customized and integrated. At certain extent, interrelated FOSS provides substantial capability in
collaborative software maintenance environment and we hope to explore some of the following research questions.

There is much to be gained from improving the software maintenance tasks by using interrelated SET. Software
maintenance tasks are such a vital and complex that can no longer be done effectively without automated support
from the tools. Interrelated SET facilitates automated processes to cater the complexity of maintaining operational
software projects. Many such tools already exist in FOSS collection but are not in widespread in use and are not
demonstrably benefiting the organization. Why is this happen? Are the tools too specialized, too general, or not
relevant at all?

There are other tools that have potential to be integrated from FOSS collection. Lack of information caused by
improper information sharing makes the software maintenance tasks difficult for new member in the team. Wiki has
been seen as one of the solution for software experience base that promotes information sharing between team
members to avoid valuable experiences from disappearing. But how this kind of tools can be integrated? Therefore
exploration of them is required and how installation process can be simplified requires significant effort.

At the same time adoption of these tools may require a paradigm shift [15] if it involves existing culture and practice in
the department. Assimilation process can be difficult if team member’s acceptability is low or demoralized by tools
that are not aligned with their existing practice within the department. Therefore, feedback from the use of these tools
helps in the development of the field and provides the evidence needed to guide future progress. In future we plan to
gather feedback from software maintainer in university on the usefulness of interrelated SET.

©Informatics '09, UM 2009 RDT4 - 98

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

REFERENCES

[1] J. McDermid, Software Engineer’s Reference Book. Butterworth-Heinemann, 1991.

[2] B. P. Lientz and E. B. Swanson, Software Maintenance Management. Addison-Wesley Publishing Company,
Reading, Massachusetts, 1980.

[3] G. Alkhatib, “The maintenance problem of application software: An empirical analysis”, Journal of Software
Maintenance: Research and Practice, 1992.

[4] B. Lienz, E.B. Swanson and G.E. Tompkins, “Characteristics of Applications Software Maintenance”.
Communications of the ACM, vol. 21, 1978.

[5] B. P. Lientz and E. B. Swanson, Software Maintenance Management. Addison-Wesley Publishing Company,
Reading, Massachusetts, 1980.

[6] W. Osborne, “Software Maintenance and Computers”. IEEE Computer Society Press, Los Alamitos, 1990.

[7] K. Bennet, B. Cornelius, M. Munro and D. Robson, Software Maintenance. Software Engineer’s Reference Book.
Butterworth-Heinemann Ltd, Oxford, 1991.

[8] A. Lobba, “Automated Configuration Management”, in Proceedings of the Conference on Software Tools, New
York, IEEE, 1987.

[9] G. F. Hoffnagle and W. E. Beregi, “Automating the Software Development Process”. IBM Systems Journal, 1985.

[10] I. Somerville and R. Thomson, “An Approach to the Support of Software Evolution”, The Computer Journal,
1989.

[11] J. S. Dean and B. P. McCune, “An Informal Study of Maintenance Problems”, in Proceedings of the Workshop on
Software Maintenance, IEEE Computer Society Press, 1983.

[12] Timothy C. Lethbridge and Janice Singer, “Understanding Software Maintenance Tools: Some Empirical
Research”, IEEE Workshop on Empirical Studies of Software Maintenance, 1998.

[13] Sulaiman H. and Abdullah R. H., “Suggested Functionalities of a Software Maintenance Tool for a University
Application System”, International Journal of Computer Science and Network Security, 2008.

[14] Mohd Zali Mohd Nor and Abdullah R. H., “Survey on Software Maintenance Profile and Knowledge Requirement
in Public Higher Learning Institutions”, ITSim, 2008.

[15] B. I. Blum, “Resolving the Software Maintenance Paradox”, Journal of Software Maintenance: Research and
Practice, 1995.

[16] Alain Abran, James W. Moore, Pierre Bourque and Robert Dupuis, Software Engineering Body of Knowledge
(SWEBOK). IEEE Computer Society, p 4-1, 2004.

BIOGRAPHY

M. Norazizi Sham Bin Mohd Sayuti obtained his Master of Computer Science in Software Engineering from University
Technology of Malaysia (UTM) and a Bachelor degree in Electronic Engineering from Shibaura Institute of
Technology (SIT). He has good work experiences as a Software Engineer and currently he is a lecturer at Islamic
Science University of Malaysia (USIM). His research interest includes Software Maintenance & Evolution.

©Informatics '09, UM 2009 RDT4 - 99