ACM SIGSOFT Software Engineering Notes
Page 1
January 2014 Volume 39 Number 1
Extended Iterative Maintenance Life Cycle Using eXtreme Programming Jitender Choudhari
Dr. Ugrasen Suman
School of Computer Science & IT Devi Ahilya University Indore (M.P.), India +91-9926090918
School of Computer Science & IT Devi Ahilya University Indore (M.P.), India +91-9826953187
[email protected]
[email protected]
ABSTRACT Software maintenance is the continuous process of enhancing the operational life of software. The existing approaches to software maintenance, derived from the traditional approaches to development, are unable to resolve the problems of unstructured code, team morale, poor visibility of the project, lack of communication, and lack of proper test suites. Alternatively, extreme programming practices such as test driven development, refactoring, pair programming, continuous integration, small releases, and collective ownership help to resolve the aforesaid problems. In this paper, a process model is proposed for software maintenance using extreme programming practices to resolve maintenance issues in an improved manner. The proposed approach speeds up the maintenance process and produces more maintainable code with less effort for future maintenance and evolution. The proposed model is validated by applying it on several maintenance projects in an academic environment. It has been observed that the approach provides higher quality code. The proposed model based on extreme programming enhances both learning and productivity of the team by improving the morale, courage, and confidence of the team, which supports higher motivation during maintenance.
Categories and Subject Descriptors D.2.7 [Software Engineering]: Distribution, Maintenance, and Enhancement – Enhancements.
General Terms Management, Experimentation, Standardization
Keywords Software maintenance, extreme programming
1. INTRODUCTION Maintenance is an inevitable part in the life cycle of a software product. It deals with fault correction, quality improvement and incorporation of new requirements after the product delivery [1]. Maintenance appears as an iterative development round of software development from outside [2]. A closer study reveals the differences in the procedures emphasized during maintenance from those applied in the development life cycle of software. As well as, in maintenance, more effort is required on the early stages than the development [4]; hence, it is mandatory to have maintenance-conscious models. Different maintenance-conscious models are quick-fix, Boehm, Osborne, iterative-enhancement, fullreuse etc [3, 4]. The quick-fix approach works on code and allows necessary changes in the associated documentation. Due to time and budget constraints, changes are carried out without proper planning, design, impact analysis, or regression testing, which result in degraded quality of documentation. Degraded documentation and demolished original design add complexity and expense to future modifications [3, 4]. Boehm's model [5] represents the maintenance process as a closed loop. It is based on economic models and principles which aim to improve productivity with a better understanding of the process. In this model, maintenance starts from management decisions, where management
DOI: 10.1145/2557833.2557845
approved a list of changes on the basis of cost-benefit assessments [4]. In Boehm's model, maintenance process is decomposed into four stages: management decisions for changes, implementation of changes, use of software, and evaluation for the proposed changes. The Osborne model [6] deals with the realities of the maintenance environment. This model organizes maintenance into different stages, i.e., identification of change requirements, change request submissions, analysis of requirements, change request approval, task schedules, analysis of design, review of design, code modifications, review of changes, test the changes, changes in the documentation, auditing, user acceptance testing, review after the installation, and completion of changes. According to Osborne, lack of proper communication and coordination among management are the key reasons behind the technical problems that occur during maintenance. This model recommends a strategy that includes maintenance requirements in the change specification, a software quality assurance program to establish quality assurance requirements, verification of maintenance goals and performance reviews to provide feedback to managers. In the iterative-enhancement model, the new build creation (i.e., maintenance) begins with the analysis of existing system’s requirements, design, code and test documents [3]. The process proceeds with modifications of the highest-level documents affected by changes, propagating the changes down through the entire documentation. Evolutionary life cycle models are comprised of redesigns based on analysis of the existing system at each step. The fullreuse model is also an evolutionary model. It derives from the reuseoriented software development [3]. It starts with the analysis of requirements and the design of a new system by reusing the artifacts of the existing system. In this model, a repository of mainly documents and components is used to maintain the artifacts of earlier versions and other similar systems. It promotes the maintenance with reuse of COTS (Commercial Off The Shelf) components. The IEEE has provided a standard that organizes maintenance process into seven phases, i.e., problem identification, analysis, design, implementation, regression/system test, acceptance test, and delivery [7]. The ISO-12207 standard organizes the maintenance into process implementation, problem and modification analysis, modification implementation, maintenance review/acceptance, migration, and retirement phases [8]. IEEE-1219 and ISO-12207 are based on waterfall-driven traditional methods. IEEE-1219 itself recommends heavy documentation by the use of 41 different IEEE standards for software maintenance [37]. The existing software maintenance models are generally derived from the classic waterfall life cycle and other traditional software development models. The existing maintenance process models have limitations when handling critical problems such as unstructured code, team morale, poor visibility, and lack of communication between stakeholders. These limitations can be resolved using agile methodologies that focus on customer collaboration, continuous testing, refactoring, and incremental development [10, 37]. Extreme programming (XP) is an implementation of agile philosophy to support evolving nature of customer requirements and quality of
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 2
software. The main strength of XP is its practices, which are derived from the best practices of software engineering [9, 26]. The core activity of maintenance is code change, which changes the existing code to remove a bug or add new functionality. Maintenance projects often deal with unstructured code due to patched and repatched software while addressing successive customer issues [10, 11]. The code base of maintenance projects contains bad code. Change in an unstructured code section without proper test coverage is risky. Software maintenance processes can be affected by staff turnover, low team morale, poor visibility, complexity of maintenance projects, and lack of communication among stakeholders. The software maintenance process can be bogged down by a lack of proper test suites [12, 13, 14]. On the other hand, Test Driven Development (TDD) is at the heart of XP. TDD can give courage to team members during code change activity. At the same time, refactoring improves the extensibility and readability of the source code with the help of TDD. Other XP practices such as pair programming and collective ownership can mitigate the problems which arise from staff turnover. Additionally pair programming can make maintenance tasks more enjoyable, and it encourages the exploration of more alternatives through continuous review. The literature shows that XP practices applied to software maintenance projects provide better solutions, as discussed in Section 2. During the maintenance of non-XP projects, practitioners require a dedicated process model based on XP practices for legacy system maintenance. The iterative maintenance life cycle using extreme programming is a process model for software maintenance [15, 19]. It uses Request for Change (RC) stories as requirement artifacts and these should be written by the end users of the software [16]. RC stories for iterations are estimated using the Software Maintenance Effort Estimation Model (SMEEM) [17, 18]. In order to refine the proposed maintenance process model [15], an extended version of the model is presented in this paper. The rest of this paper is organized as follows: Section 2 discusses related work on XP practices used in maintenance environments. An illustration of the proposed process model is provided in Section 3. Section 4 covers an experiment for validation of the proposed model. The results and observations are discussed in Section 5. Finally, the concluding remarks and future work will be presented in Section 6.
2. RELATED WORK XP provides several advantages to practitioners of software maintenance. It makes extensive use of unit tests [9, 20]. Extensive test coverage provides several advantages in the maintenance process such as instant feedback while working on legacy code, confidence and courage while making error-prone modifications, improved code readability, and faster impact analysis before any modifications [10, 21, 22, 23, 24, 25]. It is a prerequisite that the planned changes for performing any refactoring should be supported with test cases. It supports the addition of new features and the fixing of bugs in a safe manner. It is similar to the bottom-up program comprehension approach [26, 27]. However, adding test cases during maintenance of complex legacy code is difficult and also it slows down the maintenance process. Unit tests themselves require maintenance, i.e., extensive unit tests also have to be changed when production code is changed [48]. Before introducing new code in existing legacy code, an automated test suite should be written during the initial iteration [23]. Developing unit tests for a large legacy system all at once is time consuming and, as a practical matter, is usually infeasible. To solve this problem, some prioritization criteria can be helpful, such as divide and conquer on the basis of function size, modification frequency and bug fixing frequency [48]. Refactoring is a set of activities that transforms the design of software system without affecting its existing functionality [28]. Refactoring removes unnecessary complexity, thereby making changes to the code easier and faster [48]. It also improves the structure of the code and
DOI: 10.1145/2557833.2557845
January 2014 Volume 39 Number 1
hence, it improves readability. In XP, all the tests have to be executed after refactoring [15, 29]. Refactoring can be used in both top-down and bottom-up program comprehension [27]. Refactoring can be applied either by analyzing code for refactoring using bug density analyzed using a bug tracking system or on encountering bad smells in the code [10, 41]. The refactoring process requires courage to make changes in legacy code for design simplification [30]. Test cases have to be in place for refactoring to be safe. For this reason tests should be written for the code prior to refactoring [9, 24, 27, 31]. Writing unit tests and refactoring in small steps helps [31, 32, 33]. Reverse and forward refactoring activity can be useful for maintenance [34]. With tests, changes can be performed in a better way. Change operations on legacy code in maintenance projects are often mind-numbing. With pair programming, it might be more enjoyable, cause more alternatives to be explored, and work better on complex problems [48]. Using this practice, knowledge is spread among the maintenance team using frequent partner switching. Pairs provide better results in solving complex problems [35, 36]. They come up with better solutions that are easier to maintain at later stages as decisions are made by the pair. Coding standards are more strictly adhered to with improved structure of code and code quality with 15% fewer defects [35, 36]. It is observed that 15% more effort is consumed in pair programming, but XP proponents claim that the time loss is regained because of the improved code quality [35, 36]. The customer collaboration practice of XP provides support for revealing software maintenance needs in an organized way. It provides flexibility to respond rapidly to the changing needs of the customer [37]. Fully- automated software testing and continuous integration and build processes reduce the source code size and maintenance staff size by 40%. This makes it easier to maintain, test, and understand the code [10, 11, 38, 39]. The development practices of XP increase maintenance productivity by three times but their adaptations are challenging [13]. The “synthesize evolution and maintenance process model”, based on subset of agile process, shows that the degree of agility is higher in the implementation phase whereas lower in the pre-implementation phases [40]. Incremental development, risk reduction, and continuous testing contribute to effective software evolution. The XP practices of metaphor, pair programming, refactoring, small releases, continuous integration with test, continuous testing, and planning games are similar to traditional software maintenance activities of comprehension, debugging, code restructuring, fixes, regression testing, test suites, and change request [42]. In legacy system maintenance, an XP based methodology increases the speed of delivery, improves user requirements through small releases and customer collaboration, reduced delivery time, and produces higher quality applications through a test-first approach and code ownership reduces the risk due to staffturnover [43]. XP provides a right attitude for continuous improvement during maintaining the system by testing and refactoring [44]. The practice of short iterations is the default for a defect-fixing release during maintenance [14]. During legacy system reengineering, XP makes the process of the entire project more visible, controls the progress and cost in a better way, and produces better quality code. The main reason behind the success of XP is the coordination of practices and flexibility [45]. To support the migration of a legacy information system, XP practices and concepts such as planning game, short releases and documentation for need, are beneficial; where the main activities may be design oriented [46]. During legacy system reengineering, iterative developments can reduce the impact of communication delay [47]. During the evolution of nonXP legacy code, productivity is lower than with regular XP, but testing and continuous integration provide important instant feedback. XP does not concentrate on designing architecture and documentation as these are mostly required during long term maintenance and evolution of software [48].
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 3
Each of these practices of XP has their own advantages and limitations. But there does not exist any standard process model for software maintenance that could integrate all XP practices. In this paper, a maintenance process model is proposed covering the entire set of practices of XP. The main phases of this iterative process model are identification and categorization, planning, analysis, design revision, change implementation, acceptance testing, and release. This process model applies changes in an iterative manner. The proposed model with its phases is discussed in Section 3. In this way, the proposed approach includes the benefits of existing practices and provides a standard model for maintenance. Besides that, it is an XP based approach; it includes documentation for future maintenance activity.
January 2014 Volume 39 Number 1 RC Stories
Release
Acceptance Testing
Extreme Programming Practices
3. EXTENDED MODEL There exist several approaches and models for software maintenance which are derived from traditional software development process models. We have proposed an extended iterative maintenance life cycle using extreme programming, as our basis, as shown in Fig.1. The IEEE 1219 [7] is considered as a framework in the design of the proposed process model. The phases and activities of IEEE 1219 are adapted and extended in the proposed process model from an XP perspective. It consists of seven phases; namely, identification and categorization, planning, analysis, design revision, change implementation, acceptance testing, and release. The proposed approach uses RC stories and old software as input and performs all the phases and produces a modified product inheriting quality attributes, such as improved maintainability, increased productivity of maintenance team, reduced cost and effort of software maintenance. The specifications for changes or enhancements in the existing functionality or reported bugs are considered in the form of RC stories. The individual phases of the proposed process model along with an example of a Student Feedback System (SFS) are discussed in the following subsections. A maintenance project, SFS, is considered to explain the different phases of the proposed maintenance process model. It is a web based application for an educational institution in which students can register and provide feedback about an instructor through a questionnaire. After successful submission of feedback, college management can view the feedback in different formats and can generate reports for various purposes. The RC stories which are requested for maintenance are listed in Table 1.
Story Id. RC1
RC2 RC3 RC4 RC5
Description Add attendance criteria for eligibility for feedback submission
Change Implementation
Planning
Analysis Design Revision
Figure 1. Extended Iterative Maintenance Life cycle using XP identifier, Story ID, is assigned, which can be used to track the status of the RC story. Skilled people such as system analysts or service engineers examine an RC story for reasonableness with the support of an on-site customer. RC stories are assigned one of the maintenance categories such as, corrective, perfective, or adaptive maintenance. The identification and categorization phase is performed under planning game practice. On-Site Customer
RC Stories
Table 1. RC Stories for SFS
Identification, Categorization
Type of Maintenance
Identification and Categorization
The Planning Game
Validated and Categorized RC stories
Corrective
Figure 2. Identification and Categorization Phase using XP Practices
College management can view and print feedback report by department wise
Perfective
Provide best faculty for a subject
Perfective Perfective
In the case of SFS maintenance, RC stories submitted by college management are categorized into one of the maintenance categories. RC1 belongs to the corrective and the other four RC stories are perfective. Using on-site customer practice, the end-users of SFS provide explanations for the RC story and support during validation of the RC story.
Perfective
3.2 Planning
Add number of lectures conducted field in feedback form Admin can change feedback question dynamically
3.1 Identification and Categorization The Identification and categorization of change requests is performed in this phase. It deals with seeking change requests in the form of RC stories as an input and produces validated and categorized RC stories as output, as shown in Fig. 2. The RC story is a requirement artifact which is written and submitted by end-users [16]. The RC story has two parts: a description of the change requirement and user acceptance criteria. The requirements description of an RC story consists of a problem statement and its priority. After the submission of an RC story, a unique
DOI: 10.1145/2557833.2557845
The planning phase follows the planning game practice of XP, which mainly focuses on the development of strategies such as, release plan, and iteration plan for the completion of RC stories. Inputs for this phase are RC stories along with the priority and the type of the maintenance, as shown in Fig. 3. Developers along with customers make decisions about the grouping of RC stories into patch release iterations. Generally, RC stories, which belong to the same category of maintenance, are developed in a single release. If the maintenance category is urgent repair then the request is implemented irrespective of analysis and design.
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
On-Site Customer
The Planning Game
Page 4
Small Releases Iterative Planning
Validated and Categorized RC stories
Planning Planning
Release plan and Iteration Plan
Figure 3. Planning Phase using XP Practices There are certain issues during a planning game in the case of maintenance; it is difficult to decide about the priority of implementation of new features and improvements of code design. This problem can be solved by treating the initial iteration as corrective maintenance. The corrective maintenance can improve the design of the existing legacy code. Bug cluster information in a bug tracking system can support this structural improvement activity by detecting bad smells. Another issue is the inaccurate estimation of effort caused by unfamiliarity with the existing code. The planning poker technique can be beneficial for estimation at this stage of the maintenance life cycle as compared to the estimation done by an individual. During release planning, the release date is also decided based on the estimation. For a single release, cost analysis and estimation are performed to; estimates the response time for completing an RC story. The agreement between developer and customer is signed based on included stories and agreed upon release date. During iteration planning, RC stories are divided into tasks, which are assigned to the programmers. In the case of SFS maintenance, RC1 will be implemented in the first release because it is corrective maintenance and the customer assigned a higher priority to it. The second release considers the other four stories, which belong to the same category of maintenance. The project coordinator prepares a panel along with students and the project guide that follows planning poker techniques. RC1 is estimated as eight story points.
3.3 Analysis The analysis phase aims to determine the feasibility of maintenance for a project by identifying the impact of modification, using an analysis of alternative solutions and effort estimation. The release and iteration plan along with artifacts of the existing system are the main inputs to this phase. Outputs of the analysis phase are the feasibility and detailed analysis reports, as shown in Fig. 4. The effort involved in this phase is highly dependent on the quality and availability of the artifacts of the system [49]. Analysis is conducted at the following two levels [7]:
Feasibility analysis
Detailed analysis On-Site Customer
Release plan, Iteration Plan, RC Stories, Design document, Source Code of the Existing System
Analysis Feasibility Analysis
Identification of the impact of modifications
Analysis of alternative solutions
Identification of safety and security implications
The first activity during feasibility analysis is to identify the impact of modifications. The purpose of this activity is to evaluate the scope and impact of modifications and then to decide whether or not to proceed with implementing an RC story. A valid RC story and its relevant artifacts serve as inputs to this activity. The impact of modifications is analyzed roughly based on existing documents, specifications and source code with the purpose of identifying affected products, artifacts and modules that need to be modified. The impact of modification on the business process with short and long-term costs is also evaluated. Visual modeling tools are useful to demonstrate the scope and tasks of the system. In the case of SFS, the project guide along with the students perform this activity. The purpose is to identify the impact of RC1 from product and end users points of view. The other activity performed during feasibility analysis is the analysis of alternative solutions. It identifies and assesses the different alternatives for a given RC story. The RC story with its relevant artifacts becomes an input for this activity. During assessment, prototyping techniques can be useful in evaluating alternatives. The best alternative is selected amongst the possible solutions, which is implemented at a later stage. The on-site customer can supply support for identification and selection among alternative solutions. Requirements elicitation is performed by the analyst. The software architect along with the designer performs the design and analysis of alternatives. The project manager and on-site customer approve the recommended solution. Prototyping and simulation tools can be helpful for the analysis of alternative solutions [49]. For RC1, several business alternatives are considered as the means to include percentage criteria in SFS. The first alternative is to allow only an administrator to fill in the attendance of each student. Students with below average attendance will be notified they are not eligible to provide feedback through a message. The second alternative is to allow each student to fill in his/her attendance and on the basis of minimum attendance criteria he or she will be eligible to give feedback for that subject.
The identification of safety and security implications is the last activity of the feasibility analysis phase. The purpose of this activity is to identify all other aspects that can compromise success with regard to safety and security. Input for this activity is an RC story with detailed information about the system. Current safety and security issues along with the data security policy of the organizations are also used as inputs for this activity. Firstly, identification of vulnerable areas of the system is performed and their successful identification is followed by analyzing the RC story. The detailed specification of safety and security implications is performed in later stages of the process model. Output of Metaphor this activity is a list of the aspects that should be considered in detail during later stages, i.e., detailed analysis, design, and testing. Identification of safety and security areas is performed by the system analyst. In the future, the system analyst; the architect and designer specified the implications in more detail [49]. An automated tool (e.g., Analysis Eclipse IDE) to trace the functionality in the existing code is required Report during detailed analysis of safety and security implications.
Detailed Analysis
Figure 4. Analysis Phase using XP Practices During feasibility analysis, the feasibility and the scope of modifications are determined. It is comprised of the following three activities [7]:
DOI: 10.1145/2557833.2557845
January 2014 Volume 39 Number 1
According to the rule, the faculty members are not allowed to view their feedback; it is a confidential part of SFS. For RC1, the project guides along with the coordinator perform identification and analysis activities from safety and security points of view. On a positive feasibility report, a thorough analysis is required for design, which is performed during detailed analysis. It is comprised of the following four activities [7]:
Define firm requirements for the modification
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Identify the elements of modification/Impact analysis
Program comprehension
Effort Estimation
Page 5
The first activity of the detailed analysis phase defines firm requirements for the modification. It establishes and maintains agreement of what the system should do after implementation of the RC story. It determines the scope of an RC story that provides a basis for the design. The RC story, analysis report and original SRS are inputs for this activity. In case of corrective maintenance, the problem can be reproduced to understand the requirement. Use case diagrams can be used to represent the user requirements. This activity results in the analysis model, which represent the system or its affected units. The requirement definition activity is coordinated by the system analyst. The analysis model is developed by the designer and the integrity of the existing system architecture is ensured by the architect [49]. The RC story and its traceability can be captured by an automated requirement management tool. Analysis modeling tools provide different views of the system during the analysis process. As the first alternative is selected in feasibility analysis of the RC1 in SFS, firm requirements are established for the modification. According to the first alternative, from the administrator side, the faculty member of a related subject has filled the name, enrollment and attendance of the student for eligibility. A student can provide feedback, if he/she has an attendance greater than 75%. A student will get a message of eligibility during subject selection. The second activity during detailed analysis is to identify the modification and analyze their impact. This activity assesses the impact of modifications in the system, which provides a basis for the design. Inputs for this activity are an RC story, analysis model, and relevant artifacts. The impact of the modification on the other components of the system is identified in this activity. This activity produces improved analysis models that provide a general idea about the intended functionality, the elements that need to be modified and the impact of the changes. The impact analysis is performed for RC1 in the SFS. The affected modules are identified on the basis of firm requirements. During this activity, analysis models such as use case and class diagram are modified according to the firm requirements of RC1. The program comprehension is the third activity of detailed analysis, which is used to understand the existing source code. A program analyzer or program slicing technique can be used to understand the code [49]. A detailed document is produced that assists others to understand the system’s functionality and behavior during modifications. The pair programming practice can be used for the program comprehension task. The entire technical team is involved in this activity according to their roles. Code review and dynamic analyzer tool support the activity of program comprehension. The last activity of the detailed analysis phase is effort estimation. The effort estimation of a maintenance project is highly influenced by the existing design documents and source codes. Cost drivers such as product, computer, personnel, and project play important roles during estimation [51]. The SMEEM model can be applied to calculate the volume of maintenance [17, 18]. The SMEEM of effort estimation incorporates value adjustment factors such as, documentation quality, structuredness etc., with different intensity levels. This model helps project managers to calculate the estimated software maintenance effort in terms of Adjusted Story Point (ASP), size, cost and duration. We apply SMEEM on SFS to calculate unadjusted effort (EUnadjusted), which is 16 story points. The value of different value adjustment factors for Factor Count (FC) is computed as 24. By applying SMEEM, effort is computed as 7.5 hours for RC1.
DOI: 10.1145/2557833.2557845
January 2014 Volume 39 Number 1
This phase considers the impact of RC stories on rest of the modules with consideration to their security and safety implications as well. The analysis phase concludes with estimation of cost, size and duration.
3.4 Design Revision In this phase, changes are performed on the existing design artifacts without affecting the integrity of the existing system. Feasibility and detailed analysis reports are the main inputs to this phase with program comprehension as an important pre-requisite. The output of the design revision phase is the updated design baseline, as shown in Fig. 5. This phase is comprised of the following three activities [7]:
Modify software module documentation
Create test cases for the new design
Identification and creation of integration tests Customer Collaboration
Analysis Report, Existing Design Documents, Source Code
Design Revision
Prototypes
Updated Design Baseline, Testing Artifacts
Figure 5. Design Revision Phase using XP Practices The documentation of software modules is modified initially during the design revision phase. Inputs to this activity are an RC story and relevant affected modules. The purpose of this activity is to convert RC stories into specification documents represented in the form of modules. The specification module is represented using CRC (class-responsibility collaborator) cards. This design activity uses refactoring and metaphors practices to keep the system design simple and extensible. Outputs of this activity are design elements such as class diagram and subsystem design, which represents different views of the system. In this activity, an architect provides the architectural design of the overall software and the designer provides the design modules. In this activity, the Rational Software Architect (RSA) tool performs reverse and forward engineering. The second activity during the design revision phase is to create test cases for the new design including safety and security issues. The purpose of testing at this stage is to develop a test model that can be used during verification and validation of an RC story. Input for this activity consists of existing testing artifacts and revised design artifacts from the first activity. In this process, an RC story and design models are converted into acceptance and system test cases, respectively. Outputs of this activity are test plan, test cases, test procedures, and test scripts. The test designer performs planning, designing, implementation, and evaluation of the tests. During this activity, automated tools can support to the creation and execution of test cases. Modeling tools can also support conversion of use cases into test cases and test scripts. Planning for integration testing is the last activity of the design revision phase. At this stage, it is easier to identify affected areas so planning of integration testing activity is beneficial. Defects, which are discovered earlier, existing test cases and design information from the design model are the inputs for this activity. The test plan is established according to the modified system and then test cases are designed and implemented accordingly. Test plan, test cases and test script are the outputs of this activity. During continuous integration testing, it is necessary to re-run test cases again and again; therefore, automated tools can be useful for efficient execution of test cases. Overall, this phase incorporates the changes into the design of the existing system. It
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 6
includes creating test cases for new designs and planning of the integration testing.
3.5 Change Implementation Coding, unit and integration testing are performed in the change implementation phase. It takes updated design documents and existing source codes including production and test codes as inputs and produces updated software as an output. The pair programming, TDD, refactoring, and continuous integration practices of XP can be used during this phase, as shown in Fig. 6. The change implementation phase is comprised of the following three activities [7]:
Structure implementation
Test-first coding
Continuous integration and test
In case of urgent repair, the modification of code can be performed as an immediate effect. After performing changes, changes in the design document are applied strictly. During this phase, an RC story may be divided into multiple tasks. Pair Programming
Updated Design Baseline, Test Plan, Existing Source Code Collective Code Ownership
Test Driven Development
Change Implementation
Continuous Integration
Sustainable Pace
Refactoring
Updated Software
January 2014 Volume 39 Number 1
that every programmer can be aware of changes in different modules of the system. The daily stand-up meeting practice can also be followed for briefing regarding the tasks for the day, technical issues and for information sharing among the team members. Lastly, continuous integration and testing is performed in the change implementation phase. The purpose of this activity is to integrate the work of individual programmers into an executable unit. The integration plan, existing code, and tested units are inputs for this activity. Continuous integration along with testing is performed on a daily basis. The continuous integration and testing practice of XP can resolve compatibility issues and interfacing problems of maintenance. This practice during maintenance provides a smoke-testing environment to detect errors in early stages. An integrated system or subsystem, which is ready for acceptance testing, is the output of this activity. An integration team or pair programmer performs this activity. Automated tools such as TeamCity, Bamboo, and CruiseControl can provide support during integration and management.
3.6 Acceptance Testing The RC story driven acceptance testing is performed at this stage to ensure that the components and the system as a whole provide expected results. The acceptance test scripting activity starts from the analysis phase for all those RC stories that are planned for the implementation. Integrated modules and testing artifacts are the inputs to this phase as shown in Fig. 7. The acceptance testing phase is comprised of following three activities [7]:
Test design
Productive system test
Support material acceptance test
Daily standup meeting
On-Site Customer
Figure 6. Change Implementation Phase using XP Practices Initially, a structure for the change implementation is prepared that represents the structure of the code change along with the consistency. The detailed design documents are inputs to this activity. It starts from the analysis phase where modified components are already identified. Here, an implementation strategy is also prepared that describes a sequence of modifications. Planning the integration of the modified module is also performed at this stage. Implementation models and integration plans are outcomes of this activity. Software architects play important roles during the preparation of the implementation model and integration plan. Performing changes in the code is the core activity of this phase, which aims to develop components using design objects. The design model, implementation model, existing source code, and existing documentation are inputs for this activity. This activity can be performed by the code change approach [19], which employs the TDD, pair programming and refactoring practices of XP. Firstly, unit test classes are written or existing test classes are modified according to the requested changes. In case of test class unavailability, unit test classes are written according to the structure of actual class. The program comprehension can be applied using pair programming while writing unit tests. In the initial iteration, emphasis should be given to writing unit test classes to obtain more and more coverage for existing code that helps the design of actual classes. Test and actual class creation or modification is performed using the pair programming practice. The refactoring practice can also be applied in small steps to incorporate code changes. Outputs of this activity are unit test classes along with actual classes. Automated tools that support unit testing along with refactoring such as eclipse can increase the productivity. The round-trip engineering tools are also helpful here. During this activity a sustainable pace is maintained with the help of the 40-hour week practice of XP. The collective code ownership practice can also be followed here so
DOI: 10.1145/2557833.2557845
Integrated Modules, Testing Artifacts
Acceptance Testing
Accepted Software Release, Acceptance Test Report
Figure 7. Acceptance Testing Phase using XP Practices Initially, test design is performed for an RC story. The RC story as an input to this activity contains acceptance criteria for requirement change. A user interface designer creates a prototype by means of an RC story’s acceptance criteria to design the tests. A test designer designs the test script on the basis of customer feedback. User approved test cases for acceptance testing is the outcome of this activity. The test designer implements test scripts, and the customer provides feedback, which acts as a source for the improvement. Productive system testing is the core activity of this phase, which aims to ensure that the operational system is acceptable for the end-users. The operational system, test cases, and test scripts, which are developed during early phases, are used as inputs for this activity. The modified system is tested at the developer’s site and in the operational environment by the end-users. The productive system is the outcome of this activity. The on-site customer along with the tester execute test scripts to check the functionality. Automated testing tools can be used to speed-up test case execution activity. The support material acceptance testing is the last activity ahead of the release of the system. User manuals and training materials are reviewed at this stage. The entire support material including installation guide, user manuals, training materials etc., serve as inputs. The tester along with the on-site customer performs the installations and operations based on user manuals and supporting materials. On the basis of the
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 7
January 2014 Volume 39 Number 1
feedback, supporting material is updated before deployment of the system. Acceptable and appropriate support materials are the outcome of this activity.
outcome. The deployment managers deploy the software at the customer site on the basis of feedback from customer’s acceptance and test results.
3.7 Release
Finally, training sessions are provided to users based on their roles in the organization, viz. installation, operation, maintains, and use. The actual or test system acts as an input in training activity. Information about the system, modified areas and affected processes are desirable during training activity. Training sessions are highly influenced by the support material acceptance testing activity of the preceding phase. Trained users are the outcome of this activity. The person who prepares training material and the trainer play key roles during this training activity. Automated tools such as e-learning can support training activities.
The release phase accepts tested software as an input and produces customer feedback in the report, as shown in Fig. 8. This phase comprised of the following five activities [7]:
Installation of the software at the customer site
Final testing
Notification of users/customers
Deployment
User training
4. EXPERIMENT
Initially the modified system is installed in the productive environment at the customer site. The ready product along with information about productive environment are the main inputs for this activity. A back up of old version of software is also maintained for tracing of undiscovered faults. Data migration from the old version to the modified version is also performed at this stage. The installed software in the user’s environment is the outcome of this activity. The deployment manager and the implementer perform this activity with the support of users. Back-up and data migration tools can accelerate this activity. On-Site Customer
Tested/Accepted Software Release
Release
Customer’s Feedback Report
Figure 8. Release Phase using XP Practices The final testing is performed after successful installation of the modified software at the customer site. Approval from the customer is also collected at this stage. The software product, test data and a copy of the agreement are the key inputs for this activity. During the final testing, developers test the product at the customer site, thereafter the customer tests the same product to ensure that the contract is realized. To verify the functionality of the final product, end-users can work in parallel on the old and modified versions of the software with sets of similar data. At the end of a calendar day, a report is generated to compare the functionality of the old and modified versions of the system. This practice provides confidence towards the use of the modified system. Test results along with a running system are the outcomes of this activity. The test designer, tester and end-user perform final testing of the system. After the successful final testing, a notification is provided to users/ customers about the modification. The list of modifications and affected users/customers become the inputs for this activity. The affected customers are identified and informed. The notifier along with the notified users are the outcomes of this activity. The project manager is responsible for the notification task. Communication channels as well as database tools, which provide information about the affected users, are important for this activity. Through the deployment activity, the modified system is made available to its users for use. Information about affected users and customers along with installation artifacts are inputs to this activity. The deployment activity requires higher customer collaboration and preparation. The on-site customer and planning game practices of XP can motivates users and customers during the deployment activity. The revised system is updated with customer data by providing a link according to the deployment plan with the updated system as an
DOI: 10.1145/2557833.2557845
The experiment with the proposed process model involves five applications. The proposed process model is also compared with an existing process model for software maintenance. These five applications, described in Table 2, were developed by earlier groups of students by applying the waterfall model or ad-hoc techniques. These applications are used to handle the academic activities of multiple departments in an institute. These applications are Exam Control- Room Management, Student Feedback System, Library Circulation System, Student Information System, and Campus Search Engine. After the deployment of the applications, subsequent groups were involved in the maintenance of these applications by applying either ad-hoc techniques or quick-fix approaches. The inclusion of new features into the existing system involved constant code evolution during maintenance. Sometimes, the changes to an application resulted in unstructured code caused by patches, time pressure, and the changing makeup of the maintenance team. Table 2. Maintenance Projects Description S. No. 1.
2.
3.
4.
5.
Project Name Exam Controlroom Management Student Feedback System Library Circulation System Student Information System Campus Search Engine
Project Category
Technology
Modules
Desktop Application
Java, MySQL
Superintendent
Web Application
C#, MySQL
Student, Administrator
Web Application
Perl, MySQL
Web Application
J2EE, MySQL
Web Application
J2EE, MySQL
Student, Liberian, Administrator Student, Placement Department Administrator, Faculty, Student
Our end-users needed some modifications to the applications. Therefore, the responsibility of maintenance was assigned to new teams; each team was associated with a project coordinator and had a target time line of six months. In this experiment, maintenance tasks were performed by the PG students who were not involved in the specification, design or development of the original systems. The maintenance of each application was assigned to two project groups: one group applied the proposed XP based process model and another group worked using a waterfall based process model. Both groups solved the same RC stories and worked under the same conditions. Implementation of RC stories was performed in incremental order. Students had previous experience with the programming languages in which their respective applications were developed. They had never performed XP practices before, nor did they have experience with maintenance projects. A training session on maintenance was given to
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 8
all project teams and an XP training session was given to those teams that performed XP-based maintenance.
January 2014 Volume 39 Number 1
5.
Tester
Project Coordinators/ Students
Helps customers choose and write the functional tests and run them.
6.
Consultant
Trainers (from industry)
Provide technical knowledge, as and when required
Project Coordinators
1. Build the team 2. Provide tools and equipments 3. Act as a conduit to the outside world
4.1 Research Settings Maintenance teams were allowed to work in a project lab (open workspace). The lab was equipped as an XP development environment (e.g., board for stories/tasks). There was freedom for the project teams to arrange the project labs according to their needs and desires. The customers were not on-site in the same lab, as recommended in XP. However, they were working on the same campus and were available when needed. The project was specifically designed for the collection of both quantitative and qualitative data. Maintenance projects were initiated with defined metrics and practices for qualitative and quantitative data collection. A predefined format for data collection and log book for time tracking were used by all team members. Qualitative data were collected after completion of either an iteration or an RC story through meetings with the developers. For observation code, snapshots and voice-recording were used. A discussion session was performed on received comments for analysis, after each deliverable.
4.2 Roles and Responsibilities Generally, there are many different kinds of stakeholders in XP projects [50]. For example, there are programmers, customers, trackers, consultants, testers, coaches, and a big-boss. In the presented academic projects, students serve in the role of programmers or developers. The department in-charge played the customer, and the project coordinator acted as the tracker for the project status. The project guide act as coach, trainer from the industry act as consultant, and the project coordinator with students act as testers. The project coordinator also played the role of big-boss. Tasks and responsibilities mentioned for different XP roles are related to the project stakeholders, as shown in Table 3. Table 3. Roles and Tasks in Academic Environment S. No.
Roles in XP
Roles plays
Tasks 1. Writes RC story cards to explain and to schedule the desired features.
1.
Customer
Department incharge
2. Participates in the planning game to schedule stories for the next iteration. 3. Creates and runs acceptance tests, with student assistance, to verify that the features are complete. 4. Represents the end-user. 1. Turn RC stories into modified code along with unit tests.
2.
Developer/ Programmer
Students
2. Estimate the amount of work each RC story will take, based on the implementation decisions 3. Identify risky features that use new technology, are poorly understood, or are otherwise complicated
3.
Tracker
Project Coordinators
4.
Coach
Project Guides
Keeps track of the schedule Guides and mentors the team
DOI: 10.1145/2557833.2557845
Big-Boss
7.
4.3 Lessons Learnt in Adapting XP The adoption of XP in an academic environment required sessions to introduce it to the top management, department in-charge, and project guides. Some guides with industry experience and academic experience in teaching software engineering were selected as change agents to encourage applying XP practices among the students for the project course. The presentations aimed to highlight the spirit of XP with emphasis on the practices that were felt most beneficial to the students as maintainers of the code. Students were presented with an overview of agile methodologies specifically XP. Students were taught XP practices initially on small programs. It is emphasized what the aim of each practice is, and how it is applied. Initially there was resistance to the proposed approach from the guides and students. The discussion attempted to address the resentment among the groups. During a session, introduction of XP and some research work based on XP in academic environments were presented and discussed with the groups, pointing to how the XP methodology supports individuals and interactions. The outcome of this discussion was encouraging in getting the necessary commitment to commence the maintenance of projects.
4.4 Alteration of Project Lab for Knowledge Sharing with XP In the usual arrangement of our project labs, computer systems were laid out in rows. For better communication and knowledge sharing among the team members, the project coordinators altered the arrangement of the lab to create some open work space. Due to the new arrangement, the entire team of a project can see each other and consequently communicate orally. The added purpose of the new arrangement was the visibility of the entire team to on-site customers coming into the development area. Therefore, any member of the team could respond to a question and the others would be able to hear any issues discussed or agreed upon. White boards in the project lab were used to improve the visibility of the project status among the stakeholders. In addition, such pieces of information as the project name, customer, date submitted, owner, developer responsible for the project, and completion time were listed. The white board also aided in running the daily stand-up meetings.
4.5 Tools to Improve Productivity of XP Practices IBM Rational Software Architect (RSA) developed by IBM's Rational Software division was used to accelerate the drawing of analysis and design documents. The tool provided a modeling and development environment supporting the use of Unified Modeling Language (UML) for designing architecture. The TDD, pair programming and refactoring practices were performed using the Eclipse Java EE IDE for Web Developers. Cruise Control was used for continuous integration.
4.6 Project Description End-users of applications indentified errors that needed correction. They also needed new features. The requirement changes were written by end-users in the form of RC stories. In this case study, five RC stories were considered from each project. They are described below. Project 1
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 9
January 2014 Volume 39 Number 1 5)
Exam Control-room Management (ECM) is a desktop application used in the exam control room. The superintendent of examination can control exam activities through the application such as preparing a requisition of materials for an exam, checking student’s details of eligibility for the exam, preparation of invigilator’s duty chart and the seating plan, and preparation of dispatch formats according to the university standards. The following RC stories were submitted by endusers of the system. 1) Superintendent can maintain answer book record. 2) View the previous exam record in a specific format. 3) Maintain stock of accessories. 4) Prepare requisition forms. 5) Change exam bill format.
Generate book issue report for faculty.
Project 4 The Student Information System (SIS) is a web-based application. Students use their accounts to maintain their academic details for placement activities. The placement department uses their accounts to view student details, filter students according to company criteria, generate various reports etc. The following RC stories were submitted by end-users of the system. 1) Apply top five student criteria. 2) Start SMS alerts. 3) Add roles and responsibilities to placed students. 4) Add students training module. 5) Add documentation verification technique.
Project 2 The Student Feedback System (SFS) is a LAN based student feedback system for an institute. Students can register and submit feedback about teachers through a web application running on the LAN. After successful submission of feedback, college management can view the feedback in different formats and can generate reports for different purposes. The following RC stories were submitted by end-users of the system. 1) Add attendance criteria for eligibility of filling feedback. 2) College Management can view and print a department-wise feedback report. 3) Identification of best faculty for a subject. 4) Add number of lectures conducted in the feedback form. 5) Admin can change feedback questions dynamically.
Project 5 The Campus Search Engine (CSE) is a web-based application. Students use their accounts to view and download study materials. Faculty members use their accounts to upload, view and download study materials. The following RC stories were submitted by end-users of the system. 1) Add classification criteria for study material. 2) Download facility for video lectures. 3) Provide alternative links if material is not available. 4) Add content searching facility. 5) Generate site visitors report.
4.7 Results All the student maintenance groups completed their tasks. The behavior of the systems under maintenance was checked. Additionally, the maintainers were interviewed. During the interviews of the maintainers we asked questions based on various parameters such as courage, confidence, understanding of the system, interest in the maintenance activity etc. After task completion code, snapshot, and voice recordings were made and some parameters for each group such as time taken in completing each RC story were checked. In both the traditional and XP approaches the completion time of the first RC story was observed to be similar, but in the proposed approach, succeeding RC stories in all projects consumed less time, as shown in Table 4 and Fig. 9.
Project 3 The Library Circulation System (LCS) is developed in Perl and MySQL. Students use their account to maintain their profile, view issued books detail, and can apply reserve for a book. Librarians use their accounts to issue / return, view student and book details, generate various reports etc. The following RC stories were submitted by endusers of the system. 1) Calculation of overdue charges under different heads. 2) Start SMS alerts. 3) Add holiday calendar for reference in book return date. 4) Prepare requisition form.
Table 4. Comparison of time (hours) consumed in both approaches
S. No.
Maintenance Task
Waterfall based process model of maintenance
Proposed XP based maintenance process model
(in hours)
(in hours)
ECM
SFS
LCS
SIS
CSE
ECM
SFS
LCS
SIS
CSE
1.
RC story 1
13
8
9
12
14
10
7
7
11
12
2.
RC story 2
10
6
8
9
8
6
4
5
7
7
3.
RC story 3
8
7
5
12
14
6
5
4
8
9
4.
RC story 4
10
9
7
9
7
8
6
4
5
4
5.
RC story 5
12
15
13
14
8
8
10
9
9
4
In Fig. 9, the completion time of each RC story for a project is shown using a different color bar. The progress of projects using the waterfallbased model and proposed XP-based model for the completion of various RC stories are shown in this figure. Fig. 9 also shows that the team using the proposed process model consumed less time in subsequent RC stories.
DOI: 10.1145/2557833.2557845
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 10
January 2014 Volume 39 Number 1
ideas using pair programming. Pair programmers propose better alternative solutions and understanding of changes in existing systems as compared to individuals. The comprehension activity in the proposed approach requires less time due to extreme communication techniques as compared to existing approaches and hence, practitioners get a better understanding of the overall system. As is shown in Table 5, successive RC stories in all projects required less time to complete. The XP based approach provides higher quality code in terms of structure, correctness, robustness, and maintainability; and hence, improves software design. The change propagation task is performed more appropriately in the XP based approach. This approach generates better quality code and tests that can be reused. On the basis of process model characteristics, comparisons between the proposed approach and existing approaches are shown in Table 5. Figure 9. Comparison of time (hours) consumed in both process models
5. OBSERVATIONS AND DISCUSSION The proposed XP based and waterfall-based models were applied to the same maintenance projects, as discussed in earlier sections. Some interesting facts were observed regarding the proposed approach with respect to maintenance practitioners and enhancements in the product features. The XP based approach enhances learning and productivity by improving courage, team morale and confidence to support higher motivation in maintenance teams. Observation shows the requirements elicitation process using RC stories results in unambiguous requirements. Planning poker and SMEEM provide accurate results for resource management. Small releases of products are suitable from a maintenance point of view. The proposed maintenance approach improves interest in the maintenance activity through the sharing of
6. CONCLUSION AND FUTURE SCOPE The maintenance of legacy systems is tedious, expensive, and error prone, due to fractional test coverage, inaccessible original developers, and insufficient or outdated documentation. Software maintenance experiences the problems of unstructured code, poor team morale, abridged visibility of the project and a lack of communication. To resolve the aforesaid maintenance problems, a model has been proposed. The proposed model reveals the benefits of integrated XP practices in the different activities of maintenance. The proposed process model has been applied and validated by using academic case studies. Experimental results show that XP practices during maintenance enhance productivity by improving learning, team morale and confidence. Future work will focus on refinement of the proposed process model by applying it to complex and large projects. The development of tools to automate the process should also be considered.
Table 5. Comparison between Existing and XP-based maintenance approaches S. No.
Process Characteristics
Existing process model
XP-based process model
1.
Origin
Waterfall, CBSE model
Iterative process model such as XP and Scrum
2.
Process iteration
Long delivery or long increment
Small Increment
3.
Role of customer
Only for requirements submission
On-site customer
4.
Requirement artifact
Requirement change documents developed by the developer
RC story written by end-users
5.
Planning
For whole set of requirements change
Iterative planning according to the business needs
6.
Design improvement
if required
Continuous process through refactoring
7.
Programming style
Individual
Pair programming
8.
Code ownership
Module wise
Collective code ownership
End of implementation(weekly or monthly)
Continuous integration (daily basis)
Integration (Build 9.
process)
10.
Code review
At the end of development
Continuous process through pair programming
11.
Testing strategy
After implementation
Before implementation through TDD
12.
Maintenance effort
Reduces with low rate in successive stories
Reduces with high rate in successive stories
13.
Documentation
In huge amount
Limited
14.
Maintenance approach
Iterative
Iterative upto extreme level
15.
Phase execution
Sequential
Parallel for 3-7 Phases
DOI: 10.1145/2557833.2557845
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
16.
Regression testing
Page 11
Traditional approach
7. REFERENCES [1]
Lientz, B.P. and Swanson, E.B. 1980. Software Maintenance Management. Addison-Wesley publishing company.
[2] McKee, J. R. 1984. Maintenance as a Function of Design. In Proceedings of the national computer conference and exposition, (July 1984). 187-193. [3] Basili, V. R. 1990. Viewing Maintenance as Reuse-Oriented Software Development. IEEE Software. 7, 1 (January 1990), 1925. [4]
Grubb, P. and Takang, A. A. 2003. Software Maintenance: Concepts and Practice. World Scientific.
January 2014 Volume 39 Number 1 Frequent regression testing through continuous integration
[19] Choudhari, J. and Suman, U. 2013. Code Change Approach for Maintenance using XP practices, in The International Journal of Soft Computing and Software Engineering [JSCSE], 3, 3, 131-136. [20] Beck, K. 1999. Embracing Change with Extreme Programming. IEEE Computer, 32, 10, (Oct. 1999), 70-77. [21] Schuh, P., 2001. Recovery, Redemption, and Extreme Programming. IEEE Software, 18, 6, (Nov/Dec 2001), 34-41. [22] Wright, G. 2002. eXtreme Programming In A Hostile Environment. In Third International Conference on Extreme Programming and Flexible Processes in Software Engineering XP2002, 48-51.
[5] Boehm, B. 1983. The economics of software maintenance. In Proc. of Int. Conf. on Software Maint., IEEE Computer Society Press, Monterey (December 1983), 9-36.
[23] Eckman III, E.C. 2002. XP Transition Roadmap. In Third International Conference on Extreme Programming and Flexible Processes in Software Engineering - XP2002, 219-222.
[6] Osborne, W. M. 1987. Building and sustaining software maintainability. In Proceedings of Conference on Software Maintenance (October 1987), 13-23.
[24] Jalis, A. 2002. Probe Tests: A Strategy for Growing Automated Tests around Legacy Code. In Extreme Programming and Agile Methods - XP/Agile Universe. Springer Berlin Heidelberg, (2002), 122-130.
[7] IEEE Std. 1219-1998. Standard for Software Maintenance, IEEE Computer Society Press. Los Alamitos, CA, 1998. [8] ISO/IEC 12207. Information Technology – Software Life cycle Processes. Geneva, Switzerland, 1995. [9] Beck, K. 2006. Extreme Programming Explained – Embrace Change. Pearson Education Low price Edition Asia. [10] Poole C. and Huisman, J. W. 2001 Using Extreme Programming in a Maintenance Environment. IEEE Software. 18, 2001, 42-50. [11] Poole, C. Murphy, T., and Huisman, J. W. 2001 Extreme maintenance. In Proceedings of the 17th IEEE International Conference on Software Maintenance. Florence, Italy, (2001), 301309. [12] Van Deursen, A., Kuipers, T., and Moonen, L. 2002. Legacy to the Extreme. (2002), 267-275. [13] Svensson, H. and Host, M. 2005 Introducing an agile process in a software maintenance and evolution organization. In Proceedings of the Ninth European Conference on Software Maintenance and Reengineering, Manchester, (March 21 – 23, 2005) 256-264. [14] Shaw, S. 2007. Using Agile Practices in a Maintenance Environment. Intelliware Development Inc. [15] Choudhari, J. and Suman, U. 2010. Iterative Maintenance Life cycle Using eXtreme Programming. In Proceedings of the International Conference on Advances in Recent Technologies in Communication and Computing ( Kottyam, India, October 15 16, 2010). ARTCom-2010. IEEE Computer Society, 401 – 403. [16] Choudhari, J. and Suman, U. 2012. Designing RC Story for Software Maintenance and Evolution. In Journal of Software (JSW), Academy Publisher,7, 5, 1103-1108. [17] Choudhari, J. and Suman, U. 2012. Story Points Based Effort Estimation Model for Software Maintenance. In Proceedings of the 2nd International Conference on Computer, Communication, Control and Information Technology (Hooghly, India, February 25 - 26, 2012). C3IT- 2012. Procedia Technology, 4, 761-765. [18] Choudhari, J. and Suman, U. 2012. Phase wise Effort Estimation for Software Maintenance: An Extended SMEEM Model. In Proceedings of the CUBE International Information Technology Conference (Pune, Maharashtra, India, September 3 - 5, 2012). ACM., 397-402.
DOI: 10.1145/2557833.2557845
[25] Elliotte Rusty Harold. Testing legacy code” available at http://www.ibm.com/developerworks/java/library/jlegacytest/index.html. [26] Van Deursen, A., 2001. Program Comprehension Risks and Opportunities in Extreme Programming. In Proceedings 8th Working Conference on Reverse Engineering, (WCRE'2001), IEEE Computer Society, 176-185. [27] Van Deursen, A., Moonen, L., van den Bergh, A., and Kok, G. 2001. Refactoring Test Code. In Proceedings of the 2nd International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2001), (2001), 92-95. [28] Fowler, M. 1998, Refactoring: Doing Design After the Program Runs, Distributed Computing, (Sept. 1998), 55-56. [29] Feathers, M. Working Effectively With Legacy Code” available at http://www.objectmentor.com /resources/articles /WorkingEffectivelyWithLegacyCode.pdf. [30] Tokuda, L., and Batory, D., 1999. Evolving Object-Oriented Designs with Refactorings. In Proceedings of 14th International Conference on Automated Software Engineering, IEEE, 174-181. [31] Freeman, S. and Simmons, P. 2002. Retrofitting Unit Tests. In Third International Conference on Extreme Programming and Flexible Processes in Software Engineering - XP2002, 11-15. [32] Ricca, F. Di Penta, M. Torchiano, M. 2008. Guidelines on the use of Fit tables in Software Maintenance Tasks: Lessons Learned from 8 Experiments. In IEEE International Conference on Software Maintenance(ICSM), (September 2008), 317-326. [33] Bhat, T., Nagappan N. 2006. Evaluating the Efficacy of TestDriven Development: Industrial Case Studies. In Proceedings of the ACM/IEEE international symposium on Empirical software engineering. (September 2006), 356-363. [34] Villavicencio, G. 2011. Software Maintenance Supported by Refactoring. In Proceedings of the International Conference on Software Engineering Research and Practice. [35] Cockburn, A. and Williams, L. 2000. The Costs and Benefits of Pair Programming. In Proceedings of the 1st International Conference on eXtreme Programming and Flexible Processes in Software Engineering - XP2000, 2000.
http://doi.acm.org/10.1145/2557833.2557845
ACM SIGSOFT Software Engineering Notes
Page 12
[36] Williams, L., Kessler, R.R., Cunningham, W., and Jeffries, R. 2000. Strengthening the Case for Pair Programming. IEEE Software, 17, 4, (Jul/Aug 2000), 19-25. [37] Rico, D.F. 2008. Agile Methods and Software Maintenance. [38] Alshayeb, M., and Li, W. 2005. An empirical study of system design instability metric and design evolution in an agile software process. Journal of Systems and Software, 74, 3, 269–274.
January 2014 Volume 39 Number 1
[44] Jain, N. 2006. Offshore Agile Maintenance. In Proceedings of AGILE 2006 Conference AGILE'06. (July 2006). [45] XU, B. 2005. Extreme Programming for Distributed Legacy System Reengineering. In Proceedings of the 29th Annual International Computer Software and Applications Conference COMPSAC’05, 2 (July 2005), 160-165.
[39] Purushothaman, R., and Perry, D. E. 2005. Toward understanding the rhetoric of small source code changes. IEEE Transactions on Software Engineering, 31,6, 511-526.
[46] Koskela, J. Myllyaho, M. Kääriäinen, J. Bendas, D. Hyysalo, J. and Virta, A. 2004. Experiences of Using Extreme Programming to Support a Legacy Information System Migration Project, Software & systems engineering and their applications, 2004.
[40] Kajko-Mattsson, M. and Nyfjord, J. 2009. A Model of Agile Evolution and Maintenance Process. In Proceedings of the 42nd Hawaii International Conference on System Sciences, (5-8 Jan. 2009), 1 – 10.
[47] Xu, B. Yang, X. He, Z. and Maddineni, S.R. 2004. Achieving High Quality in Outsourcing Reengineering Projects throughout Extreme Programming, IEEE International Conference on Systems, Man and Cybernetics, 3 (Oct. 2004), 2131 – 2136.
[41] Hanssen, G. K., Yamashita A. F., Conradi, R. and Moonen, L. 2009. Maintenance and Agile Development: Challenges, Opportunities and Future Directions. In Proceedings of IEEE International Conference on Software Maintenance ICSM 2009. 487-490.
[48] Heiskala, M. 2003. Applying Extreme Programming to Evolution of non-XP Legacy Code. HUT / SoberIT Spring T-76.650 Software Engineering Seminar, Software Evolution, 2003.
[42] Thomas, D. 2006 Agile Evolution Towards The Continuous Improvement of Legacy Software. Journal of Object Technology. Published by ETH Zurich, Chair of Software Engineering, (September-October 2006) 5, 7.
[50] Warden, S. 2003. Extreme Programming Pocket Guide. O'Reilly Media, Incorporated, 2003.
[49] Kuhlmann, U. 2004. Maintenance Activities in Software Process Models: Theory and Case Study Practice. University of Koblenz.
[51] Boehm, B.W. 1981. Software Engineering Economics. PrenticeHall.
[43] Coleman, G. and McAnallen, M. 2006. Managing the Challenges of Legacy Systems Using Extreme Programming. In Software Process: Improvement and Practice, 11, 3(2006), 269–275.
DOI: 10.1145/2557833.2557845
http://doi.acm.org/10.1145/2557833.2557845
