No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
A Proposed Code Inspection Model using Program Slicing Technique
Abstract
Code inspection is the way to ensure the quality and the control of products and software by detecting, correcting or reducing defects. Nowadays, several methods of code inspection emerged, most of which consisted of processing, preparation, analysis, meetings, and reform. However, each code inspection method may face problems in terms of number of developers, whether large or small, ease of attendance at meetings, and defects coverage. Moreover, some uses of the programs do not tolerate errors during implementation. In this paper, we will propose a new code inspection model that integrates the program slicing technique with code inspection process. We create reports that facilitate the implementation of the code review process and reduce its time, costs, and team size. The proposed model supposed to be more accurate detection and resolution of existing defects.
... We gave each participant an equal share of full and slice source code for two reasons. (i) Slice intervention reduces the time of code inspection, Jaber et al. (2020) show that program slicing techniques reduce the time of code inspection process. Therefore, assigning the participants to only full treatments, or slice treatments would have led to an unbalanced experiment design, as inspecting a slice of code takes less time than inspecting the full source code. ...
Slicing is a fault localization technique that has been proposed to support debugging and program comprehension. Yet, its empirical effectiveness during code inspection by humans has received limited attention. The goal of our study is two-fold. First, we aim to define what it means for a code reviewer to identify the vulnerable lines correctly. Second, we investigate whether reducing the number of to-be-inspected lines by method-level slicing supports code reviewers in detecting security vulnerabilities. We propose a novel approach based on the notion of a -neighborhood (intuitively based on the idea of the context size of the command git diff) to define correctly identified lines. Then, we conducted a multi-year controlled experiment (2017-2023) in which MSc students attending security courses (n=236) were tasked with identifying vulnerable lines in original or sliced Java files from Apache Tomcat. We provide perfect seed lines for a slicing algorithm to control for confounding factors. Each treatment differs in the pair (Vulnerability, Original/Sliced) with a balanced design with vulnerabilities from the OWASP Top 10 2017: A1 (Injection), A5 (Broken Access Control), A6 (Security Misconfiguration), and A7 (Cross-Site Scripting). To generate smaller slices for human consumption, we used a variant of intra-procedural thin slicing. We report the results for which corresponds to exactly matching the vulnerable ground truth lines, and which represents the scenario of identifying the vulnerable area. For both cases, we found that slicing helps in ‘finding something’ (the participant has found at least some vulnerable lines) as opposed to ‘finding nothing’. For the case of analyzing a slice and analyzing the original file are statistically equivalent from the perspective of lines found by those who found something. With slicing helps to find more vulnerabilities compared to analyzing an original file, as we would normally expect. Given the type of population, additional experiments are necessary to be generalized to experienced developers.
... To evaluate the effectiveness of the proposed methods using this dataset, we employed a crossvalidation approach with five folds (Jaber et al, 2020;Adaileh, 2020). This widely adopted method for assessing classification performance involves dividing the data into five parts, where four segments are utilized for training and the fifth segment for testing. ...
The identification of ambiguities in Arabic requirement documents plays a crucial role in requirements engineering. This is because the quality of requirements directly impacts the overall success of software development projects. Traditionally, engineers have used manual methods to evaluate requirement quality, leading to a time-consuming and subjective process that is prone to errors. This study explores the use of machine learning algorithms to automate the assessment of requirements expressed in natural language. The study aims to compare various machine learning algorithms according to their abilities in classifying requirements written in Arabic as decision tree. The findings reveal that random forest outperformed all stemmers, achieving an accuracy of 0.95 without employing a stemmer, 0.99 with the ISRI stemmer, and 0.97 with the Arabic light stemmer. These results highlight the robustness and practicality of the random forest algorithm.
... Therefore, this process ensures that identified errors are resolved as close as possible to the time the codes were developed. The nature of code inspection by people other than its developer is already known in the literature as an approach that brings quality to software [2,10,14,15]. On the other hand, it is a time-consuming process [2,26,30], which can depend on many people [25] and, therefore, directly impacts its adherence to the development process [28]. ...
Code review is essentially the process of assessing code made by a developer from the perspective of others. Considering the Modern Code Review (MCR) activities within the industry, many opportunities can be evaluated with the practitioners that adopt MCR within everyday software development. Based on that, we evaluated the perspective of software practitioners on code review by applying a survey to understand more about the aspects of MCR in their software development routine. Our qualitative results show that MCR activities are not only about reviewing code but also with knowledge sharing applied at team/project level or between different levels of seniority. We also found other important aspects such as identification of Cognitive Empathy and Career Development related to the MCR process. This research contributes to increase perspective that can be obtained with MCR process applied in the software development industry.
Many organization, programmers, and researchers need to debug, test and make maintenance for a segment of their source code to improve their system. Program slicing is one of the best techniques to do so. There are many slicing techniques available to solve such problems such as static slicing, dynamic slicing, and amorphous slicing. In our paper, we decided to develop a tool that supports many slicing techniques. Our proposed tool provides new flexible ways to process simple segments of Java code, and it generates needed slicing according to the user needs, our tool will provide the user with direct and indirect dependencies for each variable in the code segments. This tool can work under various operating systems and does not need particular environments. Thus, our tool is helpful in many aspects such as debugging, testing, education, and many other elements.
Employing lightweight, tool-based code review of code changes (aka modern code review) has become the norm for a wide variety of open-source and industrial systems. In this paper, we make an exploratory investigation of modern code review at Google. Google introduced code review early on and evolved it over the years; our study sheds light on why Google introduced this practice and analyzes its current status, after the process has been refined through decades of code changes and millions of code reviews. By means of 12 interviews, a survey with 44 respondents, and the analysis of review logs for 9 million reviewed changes, we investigate motivations behind code review at Google, current practices, and developers' satisfaction and challenges.
Program slicing is to abstract a part of source code depending on the point of interest. It used widely in maintenance, debugging and testing. There are many slicing techniques such as static, dynamic, and amorphous. In this paper, we choose to develop a new approach applying static slicing on Java programs. The new approach simplifies the data dependency using arrays. A new Tool called Java Multi-Slicing Tool (JavaMST) has been introduced to apply this approach.
JavaMST presents new ways to slice any simple java code segment, it allows you to extract the variables and its direct and indirect dependencies from the code, using backward, forward or both slicing techniques to produce the needed code. This tool is a simple tool designed to deal with simple java code segments. JavaMST can be run under any operating system and does not require a specialized platforms or plug-ins. Therefore, it is useful to be used for educational purposes.
All languages, natural and programming, have rules and styles in how to write. These rules and styles mainly aim to make sure that anyone, who understand a language, can understand what the sentence say. In other words, the aim of rules and styles in a language is to deliver an information to reader, and the reader must get the right information. The literature review shows a lack of studies focusing on the code writing standards measurement processes. In this paper, we proposed a framework that can be applied on any programming language, using any standard of that language.
Java language is one of the most used programming languages. This makes it used to develop many applications and systems by many different developers. This diversity of developers skills and backgrounds lead to the Java Programming language standards. There are many rules and guidelines for Java programming language. In this research, we include 20 different Java standards that are also the common standards, with their characteristics, specifications, and limitations. Also, a comparative study has been made to provide a different perspective to researchers and Java developers to help them choose the best standard for their research or application. Furthermore, this research addresses the tools that can be used to check the format of Java code using different standards that listed in this document.
Software code review is a well-established software quality practice. Recently, Modern Code Review (MCR) has been widely adopted in both open source and proprietary projects. Our prior work shows that review participation plays an important role in MCR practices, since the amount of review participation shares a relationship with software quality. However, little is known about which factors influence review participation in the MCR process. Hence, in this study, we set out to investigate the characteristics of patches that: (1) do not attract reviewers, (2) are not discussed, and (3) receive slow initial feedback. Through a case study of 196,712 reviews spread across the Android, Qt, and OpenStack open source projects, we find that the amount of review participation in the past is a significant indicator of patches that will suffer from poor review participation. Moreover, we find that the description length of a patch shares a relationship with the likelihood of receiving poor reviewer participation or discussion, while the purpose of introducing new features can increase the likelihood of receiving slow initial feedback. Our findings suggest that the patches with these characteristics should be given more attention in order to increase review participation, which will likely lead to a more responsive review process.
Software inspection is useful to detect the defects in any stage software development methodology especially in early stages. Inspection of software defects can improve the software product quality by decreasing rework cost and time from documents, code, and other deliverables. The objective of this study is to identify existing software inspection techniques which help practitioners and software engineers to improve the software quality and to compare them according to some quality attributes. Rather than proposing new techniques we focus on synthesize the existing approaches. A comparison of some approaches is conducted and analyzed which approach is more feasible for the detection of defects. The results of this study show that there are many formal and informal techniques available in literature related software inspection, it is difficult to say well to one of them, but our analysis focused on finding such techniques which cover maximum quality factors in an inspection. Software inspection is an umbrella activity of whole software development life cycle and we found different approaches and frameworks in software inspection which can full fill our desired parameters to improve software quality.
The Clause slicing technique is a static slicing technique. The clause slice criterion is the clause, which is the smallest part of the code line, with the clause number. In this paper, we introduce the "Clauser," which is a new clause slicing tool for C programs. The Clauser is a slicing tool that divides the program code lines into clauses, depending on certain rules, and then it slices the clauses by applying the rules of clause slicing and returns the slices of the slice criterion. Compared to other static slicing techniques, clause slicing is more accurate because it considers all code phrases that may affect the program flow. Implementation results showed that the Clauser succeeded in automating a part of clause slicing.
For two decades, software inspections have proven effective for detecting defects in software. We have reviewed the different ways software inspections are done, created a taxonomy of inspection methods, and examined claims about the cost effectiveness of different methods.We detect a disturbing pattern in the evaluation of inspection methods. Although there is universal agreement on the effectiveness of software inspection, their economics are uncertain. Our examination of several empirical studies leads us to conclude that the benefits of inspections are often overstated and the costs (especially for large software development projects) are understated. Furthermore, some of the most influential studies establishing these costs and benefits are 20 years old now, which leads us to question their relevance to today's software development processes.Extensive work is needed to determine exactly how, why, and when software inspections work, and whether some defect detection techniques might be more cost effective than others. We ask some questions about measuring the effectiveness of software inspections and determining how much they really cost when their effect on the rest of the development process is considered. Finding answers to these questions will enable us to improve the efficiency of software development.
The language Java is enjoying a rapid rise in popularity as an application programming language. For many applications an effective provision of database facilities is required. Here we report on a particular approach to providing such facilities, called "orthogonal persistence". Persistence allows data to have lifetimes that vary from transient to (the best approximation we can achieve to) indefinite. It is orthogonal persistence if the available lifetimes are the same for all kinds of data. We aim to show that the programmer productivity gains and possible performance gains make orthogonal persistence a valuable augmentation of Java. 1 Introduction The programming language Javaä [Gosling et al. 96] is achieving considerable prominence [Arnold & Gosling 96, van der Linden 96, Flanagan 96] 3 . Its libraries and architectural neutrality encourage the use of Java for distributed and mobile computing [Straßer et al. 96]. However, other characteristics, such as: strong typing, single-i...
For years, it was believed that the value of inspections is in
finding and fixing defects early in the development process. Otherwise,
the cost to find and fix them later is much higher However in examining
code inspection data, we are finding that inspections are beneficial for
an additional reason. They make the code easier to understand and
change. An analysis of data from a recent code inspection experiment
shows that 60% of all issues raised in the code inspections are not
problems that could have been uncovered by latter phases of testing or
field usage because they have little or nothing to do with the visible
execution behavior of the software. Rather they improve the
maintainability of the code by making the code conform to coding
standards, minimizing redundancies, improving language proficiency,
improving safety and portability, and raising the quality of the
documentation. We conclude that even if advances in software technology
have diminished the value of inspections as a defect detection tool, in
most cases, it continues to be of value as a maintenance tool
Due to the complexity of the code, software is released with many errors. In response, both software practitioners and software researchers need to improve the reputation of the software. Inspection is the only way to improve the quality of software. Inspection methods can be more effective but success depends on having a sound and systematic procedure for conducting the inspection. The Workshop on Inspection in Software Engineering (WISE), a satellite event of the 2001 Computer Aided Verification (CAV '01) Conference, brought together researchers, practitioners, and regulators in the hope of finding effective approaches to software inspection. The workshop included invited lectures and paper presentations in the form of panel discussions on all aspects of software inspection. Submissions explained how practitioners and researchers were performing inspections, discussed the relevance of inspections, provided evidence of how inspections could be improved through refinement of the inspection process and computer aided tool support and explained how careful design of software could make inspections easier or more effective.
Program code may have useless statements of code. These useless statements called dead code. The dead code affects the code quality negatively. In this research, a new model has been introduced to identify the dead code in a program and remove it. The decomposition slicing technique is used to identify the live code, and refactoring techniques can also help in tide up the code design. As a result, the proposed model succeed to remove the dead code of a program. However, still need some extra work to increase the accuracy of identifying the live code.
Code review has been known to be an effective quality assurance technique for decades. In the last years, industrial code review practices were observed to converge towards “change-based/modern code review”, but with a lot of variation in the details of the processes. Recent research also proposed hypotheses on factors that influence the choice of process. However, all current research in this area is based on small and largely non-random samples of cases. Therefore, we set out to assess the current state of the practice and to test some of these hypotheses with a survey among commercial software development teams. We received responses from 240 teams. They support many of the stated hypotheses, e.g., that change-based code review is the dominating style of code review in the industry, and that teams doing change-based code review have a lower risk that review use fades away. However, other hypotheses could not be confirmed, mainly that the balance of effects a team tries to reach with code reviews acts as a mediator in determining the details of the review process. Apart from these findings, we contribute the survey data set as a foundation for future research.
Code review is the manual assessment of source code by humans, mainly intended to identify defects and quality problems. Modern Code Review (MCR), a lightweight variant of the code inspections investigated since the 1970s, prevails today both in industry and open-source software (OSS) systems. The objective of this paper is to increase our understanding of the practical benefits that the MCR process produces on reviewed source code. To that end, we empirically explore the problems fixed through MCR in OSS systems. We manually classified over 1,400 changes taking place in reviewed code from two OSS projects into a validated categorization scheme. Surprisingly, results show that the types of changes due to the MCR process in OSS are strikingly similar to those in the industry and academic systems from literature, featuring the similar 75:25 ratio of maintainability-related to functional problems. We also reveal that 7–35% of review comments are discarded and that 10–22% of the changes are not triggered by an explicit review comment. Patterns emerged in the review data; we investigated them revealing the technical factors that influence the number of changes due to the MCR process. We found that bug-fixing tasks lead to fewer changes and tasks with more altered files and a higher code churn have more changes. Contrary to intuition, the person of the reviewer had no impact on the number of changes.
Substantial net improvements in programming quality and productivity have been obtained through the use of formal inspections of design and of code. Improvements are made possible by a systematic and efficient design and code verification process, with well-defined roles for inspection participants. The manner in which inspection data is categorized and made suitable for process analysis is an important factor in attaining the improvements. It is shown that by using inspection results, a mechanism for initial error reduction followed by ever-improving error rates can be achieved.
Software inspections, which were originally developed by Michael Fagan in 1976, are an important means to verify and achieve sufficient quality in many software projects today. Since Fagan's initial work, the importance of software inspections has been long recognized by software developers and many organizations. Various proposals have been made by researchers in the hope of improving Fagan's inspection method. The proposals include structural changes to the process and several types of support for the inspection process. Most of the proposals have been empirically investigated in different studies.
This is a review paper focusing on the software inspection process in the light of Fagan's inspection method and it summarizes and reviews other types of software inspection processes that have emerged in the last 25 years. This paper also addresses important issues related to the inspection process and examines experimental studies and their findings that are of interest with the purpose of identifying future avenues of research in software inspection. Copyright
Successful management of any process requires planning, measurement, and control. In programming development, these requirements translate into defining the programming process in terms of a series of operations, each operation having its own exit criteria. Next there must be some means of measuring completeness of the product at any point of its development by inspections or testing. And finally, the measured data must be used for controlling the process. This approach is not only conceptually interesting, but has been applied successfully in several programming projects embracing systems and applications programming, both large and small. It has not been found to “get in the way” of programming, but has instead enabled higher predictability than other means, and the use of inspections has improved productivity and product quality. The purpose of this paper is to explain the planning, measurement, and control functions as they are affected by inspections in programming terms.
Over the last decade many techniques and tools for software clone detection have been proposed. In this paper, we provide a qualitative comparison and evaluation of the current state-of-the-art in clone detection techniques and tools, and organize the large amount of information into a coherent conceptual framework. We begin with background concepts, a generic clone detection process and an overall taxonomy of current techniques and tools. We then classify, compare and evaluate the techniques and tools in two different dimensions. First, we classify and compare approaches based on a number of facets, each of which has a set of (possibly overlapping) attributes. Second, we qualitatively evaluate the classified techniques and tools with respect to a taxonomy of editing scenarios designed to model the creation of Type-1, Type-2, Type-3 and Type-4 clones. Finally, we provide examples of how one might use the results of this study to choose the most appropriate clone detection tool or technique in the context of a particular set of goals and constraints. The primary contributions of this paper are: (1) a schema for classifying clone detection techniques and tools and a classification of current clone detectors based on this schema, and (2) a taxonomy of editing scenarios that produce different clone types and a qualitative evaluation of current clone detectors based on this taxonomy.
ICICLE1 (“Intelligent Code Inspection Environment in a C Language Environment”) is a multifarious software system intended to augment the process of formal code inspection. It offers assistance in a number of activities, including knowledge-based analysis and annotations of source code, and computer supported cooperative discussion and finalization of inspectors' comments during inspection meetings. This paper reports the implementation of ICICLE and GroupWare issues encountered during testing; it is directed towards an audience interested in the implementation of GroupWare as well as those concerned with usability of software systems for computer-supported cooperative work (CSCW).
The list itself is based on a concise selection of empirical data and is in rough priority order. The first fact had the most effects on defect reduction on the empirical data that was used for evaluation, while the last fact was less important. The priority of the facts is discussable and depends on the context.
Computer programmers break apart large programs into smaller coherent pieces. Each of these pieces: functions, subroutines, modules, or abstract datatypes, is usually a contiguous piece of program text. The experiment reported here shows that programmers also routinely break programs into one kind of coherent piece which is not coniguous. When debugging unfamiliar programs programmers use program pieces called slices which are sets of statements related by their flow of data. The statements in a slice are not necessarily textually contiguous, but may be scattered through a program.
A dynamic program slice is an executable subset of the original program that produces the same computations on a subset of selected variables and inputs. It differs from the static slice (Weiser, 1982, 1984) in that it is entirely defined on the basis of a computation. The two main advantages are the following: Arrays and dynamic data structures can be handled more precisely and the size of slice can be significantly reduced, leading to a finer localization of the fault. The approach is being investigated as a possible extension of the debugging capabilities of STAD, a recently developed System for Testing and Debugging (Korel and Laski, 1987; Laski, 1987).
Program slicing is a method for automatically decomposing programs by analyzing their data flow and control flow. Starting from a subset of a program's behavior, slicing reduces that program to a minimal form which still produces that behavior. The reduced program, called a 'slice', is an independent program guaranteed to represent faithfully the original program within the domain of the specified subset of behavior. Some properties of slices are presented. In particular, finding statement-minimal slices is in general unsolvable, but using data flow analysis is sufficient to find approximate slices. Potential applications include automatic slicing tools for debugging and parallel processing of slices.
DISSERTATION (PH.D.)--THE UNIVERSITY OF MICHIGAN Dissertation Abstracts International,
Review participation in modern code review
- P Thongtanunam
- S Mcintosh
- A E Hassan
- H Iida
P. Thongtanunam, S. McIntosh, A. E. Hassan, and H.
Iida, "Review participation in modern code review,"
Empirical Software Engineering, vol. 22, pp. 768-817,
April 01 2017.
Modern code review: a case study at google
- C Sadowski
- E Sderberg
- L Church
- M Sipko