Proceeding Of The 3rd International Conference On Informatics And Technology,
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Proceeding Of The 3rd International Conference On Informatics And Technology, as PDF for free.
More details
- Words: 2,886
- Pages: 6
Proceeding of the 3rd International Conference on Informatics and Technology, 2009
IMPROVING SOFTWARE MAINTENANCE PROCESS USING INTERRELATED SET FROM FOSS 1
M. Norazizi Islamic Science University of Malaysia, 71800 Nilai, Negeri Sembilan, Malaysia. Email: [email protected] 1
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 onefunction 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
2.2
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
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
IMPROVING SOFTWARE MAINTENANCE PROCESS USING INTERRELATED SET FROM FOSS 1
M. Norazizi Islamic Science University of Malaysia, 71800 Nilai, Negeri Sembilan, Malaysia. Email: [email protected] 1
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 onefunction 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
2.2
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
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
