Improving Software Maintenance for Pattern-Based Software Development: A Comment Refactoring Approach

Author(s):  
Jhe-Jyun Guo ◽  
Nien-Lin Hsueh ◽  
Wen-Tin Lee ◽  
Shi-Chuen Hwang
Author(s):  
Frank Niessink

In this chapter, we examine the differences between software maintenance and software development from a service point of view, and the consequences thereof for the maturity of software maintenance organizations. We argue that software maintenance can be seen as providing a service, whereas software development is primarily concerned with the development of products. Differences between products and services affect the way in which customers assess their respective quality. In particular, service quality is assessed in two dimensions: the technical quality — what the result of the service is — and the functional quality — how the service is delivered. Consequently, customers will judge the quality of software maintenance differently from that of software development. This in turn means that to deliver high quality results in software maintenance, both the functional quality and the technical quality dimension are important.


Author(s):  
Ioannis N. Kouris

Software development has various stages, that can be conceptually grouped into two phases namely development and production (Figure 1). The development phase includes requirements engineering, architecting, design, implementation and testing. The production phase on the other hand includes the actual deployment of the end product and its maintenance. Software maintenance is the last and most difficult stage in the software lifecycle (Sommerville, 2001), as well as the most costly one. According to Zelkowitz, Shaw and Gannon (1979) the production phase accounts for 67% of the costs of the whole process, whereas according to Van Vliet (2000) the actual cost of software maintenance has been estimated at more than half of the total software development cost. The development phase is critical in order to facilitate efficient and simple software maintenance. The earlier stages should be done by taking into consideration apart from any functional requirements also the later maintenance task. For example the design stage should plan the structure in a way that can be easily altered. Similarly, the implementation stage should create code that can be easily read, understood, and changed, and should also keep the code length to a minimum. According to Van Vliet (2000) the final source code length generated is the determinant factor for the total cost during maintenance, since obviously the less code is written the easier the maintenance becomes. According to Erdil et al. (2003) there are four major problems that can slow down the whole maintenance process: unstructured code, maintenance programmers having insufficient knowledge of the system, documentation being absent, out of date, or at best insufficient, and software maintenance having a bad image. Thus the success of the maintenance phase relies on these problems being fixed earlier in the life cycle. In real life however when programmers decide to perform some maintenance task on a program such as to fix bugs, to make modifications, to create software updates etc. these are usually done in a state of time and commercial pressures and with the logic of cost reduction, thus finally resulting in a problematic system with ever increased complexity. As a consequence the maintainers spend from 50% up to almost 90% of their time trying to comprehend the program (Erdös and Sneed; 1998, Von Mayrhauser and Vans; 1994, Pigoski, 1996). Providing maintainers with tools and techniques to comprehend the programs has become and is receiving a lot of financial and research interest given the widespread of computers and software in all aspects of life. In this work we briefly present some of the most important techniques proposed in the field thus far and focus primarily on the use of data mining techniques in general and especially on association rules. Accordingly we give some possible solutions to problems faced by these methods.


2017 ◽  
Vol 27 (09n10) ◽  
pp. 1507-1527
Author(s):  
Judith F. Islam ◽  
Manishankar Mondal ◽  
Chanchal K. Roy ◽  
Kevin A. Schneider

Code cloning is a recurrent operation in everyday software development. Whether it is a good or bad practice is an ongoing debate among researchers and developers for the last few decades. In this paper, we conduct a comparative study on bug-proneness in clone code and non-clone code by analyzing commit logs. According to our inspection of thousands of revisions of seven diverse subject systems, the percentage of changed files due to bug-fix commits is significantly higher in clone code compared with non-clone code. We perform a Mann–Whitney–Wilcoxon (MWW) test to show the statistical significance of our findings. In addition, the possibility of occurrence of severe bugs is higher in clone code than in non-clone code. Bug-fixing changes affecting clone code should be considered more carefully. Finally, our manual investigation shows that clone code containing if-condition and if–else blocks has a high risk of having severing bugs. Changes to such types of clone fragments should be done carefully during software maintenance. According to our findings, clone code appears to be more bug-prone than non-clone code.


2008 ◽  
Vol 02 (04) ◽  
pp. 431-468 ◽  
Author(s):  
JUERGEN RILLING ◽  
RENÉ WITTE ◽  
PHILIPP SCHUEGERL ◽  
PHILIPPE CHARLAND

Nowadays, software development and maintenance are highly distributed processes that involve a multitude of supporting tools and resources. Knowledge relevant for a particular software maintenance task is typically dispersed over a wide range of artifacts in different representational formats and at different abstraction levels, resulting in isolated 'information silos'. An increasing number of task-specific software tools aim to support developers, but this often results in additional challenges, as not every project member can be familiar with every tool and its applicability for a given problem. Furthermore, historical knowledge about successfully performed modifications is lost, since only the result is recorded in versioning systems, but not how a developer arrived at the solution. In this research, we introduce conceptual models for the software domain that go beyond existing program and tool models, by including maintenance processes and their constituents. The models are supported by a pro-active, ambient, knowledge-based environment that integrates users, tasks, tools, and resources, as well as processes and history-specific information. Given this ambient environment, we demonstrate how maintainers can be supported with contextual guidance during typical maintenance tasks through the use of ontology queries and reasoning services.


Software development phase is very important in the Software Development Life Cycle. Software maintenance is a difficult process if code smells exist in the code. The poor design of code development is called code smells. The code smells are identified by various tools using various approaches. Many code smell approaches are rule based. The rule based approaches are based on trial and error method. Genetic Algorithm is a heuristic Algorithm by Darwin’s Theory. This paper presents a metric based code smell detection approach by Genetic Algorithm with particle swarm optimization based on Euclidean data distance. The Euclidean data distance gives best proximity value between two points. Our approach is evaluated on the three open source projects like JFreeChart v1.0.9, Log4J v1.2.1 and Xerces-J for identifying the eight types of code smells namely Functional Decomposition, Feature Envy, Blob, Long Parameter List, Spaghetti Code, Data Class, Lazy Class, Shotgun Surgery.


Author(s):  
J. Rech

Software quality assurance is concerned with the efficient and effective development of large, reliable, and high-quality software systems. In agile software development and maintenance, refactoring is an important phase for the continuous improvement of a software system by removing quality defects like code smells. As time is a crucial factor in agile development, not all quality defects can be removed in one refactoring phase (especially in one iteration). Documentation of quality defects that are found during automated or manual discovery activities (e.g., pair programming) is necessary to avoid wasting time by rediscovering them in later phases. Unfortunately, the documentation and handling of existing quality defects and refactoring activities is a common problem in software maintenance. To recall the rationales why changes were carried out, information has to be extracted from either proprietary documentations or software versioning systems. In this chapter, we describe a process for the recurring and sustainable discovery, handling, and treatment of quality defects in software systems. An annotation language is presented that is used to store information about quality defects found in source code and that represents the defect and treatment history of a part of a software system. The process and annotation language can not only be used to support quality defect discovery processes, but is also applicable in testing and inspection processes.


2014 ◽  
pp. 1608-1638
Author(s):  
Iwona Dubielewicz ◽  
Bogumila Hnatkowska ◽  
Zbigniew Huzar ◽  
Lech Tuzinkiewicz

Software maintenance is sometimes considered as a special kind of activity that is separated from a software development process. Meanwhile, the opposite is true; maintenance should be taken into account from the beginning of the software development process. Because a model-based software development is the prevailing software development paradigm, the maintainability should be considered within models that arise in software development process. We claim that the quality of the models arising in the software development process has a positive influence on their maintainability: the higher quality of the models, the more effective maintainability activity. The background for our consideration is MDA approach, and the scope of the consideration is limited to perfective maintenance only. The set of so called 6C quality characteristics is assumed to define a quality of MDA-models. Our selection of 6C quality characteristics is justified by the fact that they are related to activities performed on models within the maintenance. To assess MDA-models in the context of the maintainability, we define checklists for the 6C characteristics. These checklists are used for derivation of some measures which are useful in checking to what scope a given characteristics is satisfied. The main advantage of the approach is its independence of the knowledge of future changes of user requirements that trigger perfective maintenance. In the chapter, we demonstrate a simple example of how to assess the quality of PIM-models that are the realization of the CIM-model. Additionally, we discuss how to select, for further development, the best PIM-model from the set of possible solution.


Sign in / Sign up

Export Citation Format

Share Document